That’s a bu-ug!

Some days I wonder if it’s worth getting out of bed… during a bit of routine testing of the Blast Engine a couple of days back a bizarre bug appeared; enemies can be given a name like “level 1 boss” and it’ll get used as reference elsewhere, not only can the timeline jump be set to only happen if an object is still active) allowing it to loop events during a boss battle) but these named objects can have “children” that follow them around or explode when they do. All well and good, but a new routine in a function called ParticleMultiSpawn that slings out fireballs from particularly large explosions (wind the video in the previous post forwards to 0:22 to see them) was trashing the name of any object being destroyed in that way…

So generally speaking that shouldn’t have been an issue since the object is dead anyway by that point and the timeline jump didn’t care less because as far as it was concerned that was how things worked anyway, but the explosion handling was being done before a scan to destroy child objects and by the time that code ran there was no name to look for and they were getting left behind! So a marathon two hour local variable renaming session ensued to make all of the loops use unique, identifiable names for their counters and… the bloody thing still didn’t work and the only fix that helped was to swap the processing order so that the main explosion is handled after the children are toasted… and that feels so damn fudged! Presumably there’s an object name being nuked that shouldn’t be in there still, but now I can’t see an effect to look for the cause but sleep will probably still be lost over it.

(Originally posted to the Bullet Mechanics blog.)

Be Sociable, Share!

Tags: , , , , ,

Comments are closed.