Saturday, March 16, 2013
Kite jumping & land skiing
All the wild weather over the past few weeks have at least made a couple of great days for flying the kite:
PC Down
Tried the usual trick of reseating RAM & graphics card, but still the long beep kept coming up. Finally it looked like I found the culprit; the upgraded CPU cooling fan was no longer turning. It would make sense that the lack of RPMs reported by the CPU fan would give an alarm, but I thought it was a little drastic to disallow POST.
Over the next few days I tried to pin down a local replacement. Apparently 90mm fans are a little hard to come by compared to 80 or 120, but eventually I got one home today (5 days after it went down). A quick change of the latches to lock it to the Cooler Master Hyper TX3 radiator and I was good to go.
Almost.
Still beeping? Visions of a cooked CPU flooded my mind, along with the ramifications of being without a PC for an even longer period. I went back into diagnosis mode and hoped that memory or GPU had gone out in sympathy with the HSF. Changed out the memory and finally got the machine to POST to another beep code. Cool, memory it is.
Cleaned the contacts and inserted one of the G-Skill 4Gb memory sticks back in.
Success! No more POST errors.
Cleaned the other and replaced it too.
Success!
Looks like it was just a corroded contact, a popular outcome from living 50m from the beach. I'd thought I'd tested for that at the start, but it might have needed a good scrub and slot swap to kick it back into gear.
My suspicionss were also confirmed about the HSF not stopping the POST all on its own. I would expect a CPU heat sensor to finally halt progress after it had a chance to do work on boot, but not stop an attempt to start. How would they know that you weren't using a passive block, or water cooling with its own power system? Other pieces of the puzzle now fit too. The radiator was very hot to touch when the PC finally succumbed on Tuesday, and there had been a fan rattle for the past month or so that definitely sounded like the manual spinning of the defunct coolermaster fan. It would seem that the heat pump and radiator were enough to keep my PC going without the fan? Good news indeed. With the new fan it might even be worth overclocking before something else falls off.
Of more concern than the PC itself was the agitation that it caused me to not have a primary PC. Even though I had a sufficient laptop to do 90% of the games I'd likely play, that I have an iPhone and iPad for more casual retreats, that the game I've been waiting for still hasn't been delivered, and would have just as likely lounged in front of the TV for the same amount of time as I did, it still irks me when it's out of action.
This isn't the first time. There have been other occasions like this and it's the same feeling. Like something is missing, or wrong with the world, and I can't settle down and enjoy other pursuits. Typically this ends in a rather expensive bill and shipment of a shiny new PC. Thinking back it's not usually driven by an urgent need to play newly released game X, but to fill that PC shaped hole in my life and make the world right.
I lasted 5 days this time. Maybe I'm not as addicted as I have been ...
Saturday, March 02, 2013
Notoriously Tomed 0.0.2
After a long deliberation about where to go next with Notorious, a few Roguelike Radios have peaked my interest enough to return to ToME as a dev environment for at least building out a single player experience, possibly more with web server integration.
First off, review the old code and see if it works on the new ToME 1.0.0 engine. Moving the code over was easy enough, but it immediately fails with a lua file error. Looks like all new spells from the summoner code I pinched now have particly effect associated with them. Finding and copying the code is simple enough. Great! It works!
Next is reviewing the development path laid out from a year ago. Even though the design has changed a bit, the next couple of steps still seem to be the same as they were back then. I should Google doc it to make the tracking a little easier.
I'd left the code with lighting issues. What I'd like is that any arbitrary minion or hero can be linked to and highlight the map regardless of where they are. Turns out that it was only a case of changing game.level.map:applyExtraLite to game.level.map:applyLite. The first code looked only for entities within field of view, whereas the 2nd applies the light regardless. Nice & neat.
Next is to turn the heroes onto the other side. They still should be visible if they are carrying gems. Looks like the faction setting allows membership, so removing it from player affiliation makes it work.
Next is to place the heroes at a distance. The target code doesn't seem to work very well, and I'm thinking it's due to the realtime nature of the game not having the targeting in the same turn as the summon. Might be worth more investigation later as some talents might need a target. Arbitrarily placing the point 5 tiles below and to the left is pretty easy though. When approaching them the temporary war hounds go after them pretty well.
Rather than the warhounds chasing down heroes then returning to me, lets see if they can be anchored to the point where they spawned to give them a 'home base'. Hmm, seems easy, but having great difficulty locking down a suitable structure. It looks like there's late binding (or no binding?) on variables as well as the ability to pass completely different structures to the same variable. This is making for some imploding bugs later on, and isn't boding well for robust code down the track. Might need to see if there's a way to make Lua a little more tightly bound.
After a look into Lua's tables, the way they have been used in ToME started to make a little more sense. There is some scary bits:
What .. the .. ?
.. Actually reading it again it's not as bad as I thought. They are using a,b & c as the keys, whereas I thought it was saying that "apple" is defined both inside and outside of the array.
Back to coding with a little more enthusiasm and after about 1 & 1/2 hours of digging into and around the problem, the solution was identical to what I had originally intended, I'd just applied it to the wrong summoning code :/.
Oh well, it still feels like time well spent getting to know the system. 4 hours all up to move the goalposts a little closer and get it to a more comfortable release point:
Notorious 0.0.2
First off, review the old code and see if it works on the new ToME 1.0.0 engine. Moving the code over was easy enough, but it immediately fails with a lua file error. Looks like all new spells from the summoner code I pinched now have particly effect associated with them. Finding and copying the code is simple enough. Great! It works!
Next is reviewing the development path laid out from a year ago. Even though the design has changed a bit, the next couple of steps still seem to be the same as they were back then. I should Google doc it to make the tracking a little easier.
I'd left the code with lighting issues. What I'd like is that any arbitrary minion or hero can be linked to and highlight the map regardless of where they are. Turns out that it was only a case of changing game.level.map:applyExtraLite to game.level.map:applyLite. The first code looked only for entities within field of view, whereas the 2nd applies the light regardless. Nice & neat.
Next is to turn the heroes onto the other side. They still should be visible if they are carrying gems. Looks like the faction setting allows membership, so removing it from player affiliation makes it work.
Next is to place the heroes at a distance. The target code doesn't seem to work very well, and I'm thinking it's due to the realtime nature of the game not having the targeting in the same turn as the summon. Might be worth more investigation later as some talents might need a target. Arbitrarily placing the point 5 tiles below and to the left is pretty easy though. When approaching them the temporary war hounds go after them pretty well.
Rather than the warhounds chasing down heroes then returning to me, lets see if they can be anchored to the point where they spawned to give them a 'home base'. Hmm, seems easy, but having great difficulty locking down a suitable structure. It looks like there's late binding (or no binding?) on variables as well as the ability to pass completely different structures to the same variable. This is making for some imploding bugs later on, and isn't boding well for robust code down the track. Might need to see if there's a way to make Lua a little more tightly bound.
After a look into Lua's tables, the way they have been used in ToME started to make a little more sense. There is some scary bits:
> t = { apple=5 } > a = "apple" > b = "apple" > c = "app".."le" > print(t.apple, t[a], t[b], t[c]) -- all the same value because there is only one "apple"! 5 5 5 5
What .. the .. ?
.. Actually reading it again it's not as bad as I thought. They are using a,b & c as the keys, whereas I thought it was saying that "apple" is defined both inside and outside of the array.
Back to coding with a little more enthusiasm and after about 1 & 1/2 hours of digging into and around the problem, the solution was identical to what I had originally intended, I'd just applied it to the wrong summoning code :/.
Oh well, it still feels like time well spent getting to know the system. 4 hours all up to move the goalposts a little closer and get it to a more comfortable release point:
Notorious 0.0.2
Subscribe to:
Posts (Atom)
