Tuesday, 23 July 2013

Debugging Smartly (or how I wasted an evening trying to fix a bug that didn't exist)

So I decided with half the map on it was time to put the scheduler in place. I'll explain the mechanics in the next post, but basically I have an MDA that stores the schedule in a semi-cron fashion, with "next execution time", "threshold time", "Timer name" and "Timer input" stored as well.

I had the option to populate the array with the next execution time and threshold time by hand, or use javascript to initialise the values (I had already written the javascript to return the "next execution time" anyway.

So, Player: <> > Timer: Execute Timer: Schedule-Initalise. Put the initialisation code in the Schedule-Initialise timer, Preview the Javascript and Test the Javascript - returns a nicely populated list of time. Let's test it via debugger!

Not what I was hoping for. Started experimenting with Set RAGS Data, even resorting to creating a blank array to see whether it's unable to set the array, or it's returning wrong values.

30 minutes later, out of frustration, started moving around the game just to see if anything changes (assuming it wouldn't), and hey presto:

The RAGS DebugDataFrm displays the variables at game start state, so if you have <> actions that changes the variable values, it's not reflected until you've perform an action in game to refresh the data. The code was working all along, I just wasn't looking at the result!

The tragedy is that I discovered this back from development of TPoC, but had completely forgotten about it. So try not to follow my mistake!

No comments:

Post a Comment