Spot The Bug

Platforms

Windows, dunno about others

Team

Design, Code, Writing

Tom Francis

Art

John Roberts

Code

John Winder

Music

John Halpart

Chris Harvey

Site

Tom Francis

John Roberts

Mailing List

Get on our mailing list so we can tell you when we release a new game.

Twitter

We're @HeatSig on there.

My current task in Heat Signature is to tweak the airlocks so there’s room to put a closed door between you and the rest of the ship when you board. That way, you have as much time as you like to plan out your attack and wait till the guards are where you want them.

I needed the airlocks to clear 4 squares on the ship’s collision grid, to give you room to stand. But I hit a weird bug: some of them, maybe a third, did not clear. I checked the ‘clear grid’ function was executing on each of them, but still some of them ended up blocked.

I could see nothing wrong with the code no matter how hard I looked, so the only way to solve it was to look at a lot of test cases and see if I could spot what the bad ones had in common. As I said in my tutorial episode on debugging, it’s often impossible to see the problem until you get a clue about where to look. So I spawned lots of ships, checked each airlock, and screenshotted each one. And it was only looking back at the screenshots that I spotted what all the bad ones had in common – or rather, what all the good ones did.

I thought it might be fun to just put up all the shots I looked at and see if you can spot it yourself. Not the actual explanation of the bug, of course, that’s tricky without seeing all my source code, but I was just looking for any commonality at all. And in case you think I’m Tom Sawyering you into solving it for me, I have no compunction about just asking for help when I really am stuck. This one was kind of fun to figure out, for a certain definition of fun.

Here are all the bad ones. The grid thing is showing what bits of the ship are solid, and these are ‘bad’ because the part I’m standing in is all red – I’m stuck. None of the debug text is relevant.

And here are all the good ones – the area I’m standing in is green, I’m free to move.

So there’s something all the bad ones have in common and something all the good ones have in common, and it’s evident in these shots. Comment if you spot it!

Update! People have got it! Both here and on Twitter, in fact I think most people who took a stab either got it or got something close enough. Kudos to Pompolic for the first correct solution I saw. I’ll detail what was going on below, but hide it until you click to reveal the solution, for anyone who still wants to try it for themselves.

Solution!

As many spotted, all the good ones are indented from the outer edge of the ship. It’s not as clear from the bad ones in isolation, but the real problem they share is that they’re all on the very outermost module of the ship. This is a problem because the collision grid only covers the smallest rectangle the ship’s modules fit into, so the protruding part of the airlock is outside the grid entirely. My collision grid visualiser doesn’t seem to have a problem with that, but the ‘clear grid’ function REALLY does. Not only does it not clear the cells that are outside the grid, it also fails to clear the cells that ARE. It doesn’t crash but essentially gives up.

Fixing this is a scarily big job, and it’s something I’ve attempted before. What we need is for the collision grid to leave some room around the ship. But this is awkward because the way the collision grid is generated depends on using the module and objects’ ship-wise co-ordinates to figure out where on the collision grid they lie. If we add extra space to the collision grid, all those references would be wrong by the size of the border. We could add an offset in the collision grid generator, but then we also have to add that same offset EVERYWHERE we EVER reference collision, including for things like line of sight checks. Nightmare.

We could make the collision grid generate correctly automatically if we changed the ship’s module grid to add empty modules all around the ship. But we have to decide whether to mess with the loops that generate the ship: right now they go from row 0 to ModulesLong, and column 0 to ModulesWide. Should we keep that the same but add new module spaces outside of those values? That’s tempting, but now every modules ‘row’ and ‘column’ variable is technically wrong, and won’t relate to its ‘fore’ and ‘starboard’ co-ordinates in ways that I’ve relied on all over the place.

So in the end I did change those loops – they now go from ModuleBorder to (ModulesLong – ModuleBorder), etc. It seems messy at first, and lots of littel variables did need adjusting to account for this, but crucially all of that was in the ship generation scripts. After a few crashes and weird, asymmetrical ships:

My third set of tweaks finally fixed it, and seemingly nothing else needs changing. That’s a huge deal, I think both the other routes to solving this would have had me still fixing little exceptions and unforeseen consequences months down the line.

Thanks for indulging me!

Pompolic:

It seems that on the good shots, the airlock in is not the outermost tile of the ship on that side. In other words, there are parts of the ship that stick out farther than the airlock.

Robert:

I have no idea why this would be, but does it have something to do with the walls of the ship being boarded extending past the boundaries of your boarding ship?

Craig:

Your debug text for the enemies is rendered upside down sometimes.

Pyradox:

It looks like all the valid ones have rooms further back then where the airlock is.

So what I think might be happening is that the airlock doesn’t know its own orientation, so it does a test to figure out which way space is. The wall that opens onto space then becomes the airlock’s door.

Space ships seem to be represented as either a grid or a 2D array. Either way the test is probably checking the value of a grid reference.

In the bad ones, the airlock is probably at either row or column 0 – the area outside it is an invalid point on the grid because data structures in GM don’t go into negatives. The test fails and the door remains solid.

The presence further back rooms in the good ones means the airlock can’t be in column/row 0, so the test will work properly.

Azure:

You have some override code, “the ship boundaries are always solid.” This is so that any corridors on outside rooms don’t just lead off into space – the perimeter of each ship’s “bounding box” gets automatically blocked off.

Then you forgot about this entirely, since that was really early in development. Back then, you had assumed there would never be open tiles on the boundaries. But now the override code is still active, setting those tiles as solid later in the generation process than your new tile-clearing code.

You fixed this bug by either 1) changing the border-solidification code to ignore airlocks, or 2) running the airlock generation code AFTER the border-solidifying code.

How accurate am I? :P

Eagle0600:

I think your clear grid function should probably have thrown an exception for a coordinate outside the grid. That would have told you the problem right away.

wwarnick:

Yeah, Pompolic is right on. However, I won’t try to guess where it went wrong in the code. The explanation for a bug usually doesn’t seem very logical to anyone unfamiliar with the code. All too often it’s caused by something random.

X0men0X (real name : Ilya Fidorenko):

I finds the one thing… By which game can crash O_O
You set the … “Detpack” and you drop the “detonator” , you grab the “detpack” and … Boom !
Game crashed ! :D
——————————————————————————————————————————
And when you was caught and anybody is gonna to throw you in space (after airlock) …
Im clicking “New life” and … Game craaaaasheeed ! D:

Buy It

Latest Trailer

Screenshots

Platforms

Team

Design, Code, Writing

Art

Code

Music

Site

It's Out

Mailing List

Twitter

Gunpoint

Buy It

Latest Trailer

Screenshots

Platforms

Team

Design, Code, Writing

Art

Code

Music

Site

It's Out

Mailing List

Twitter

Gunpoint

Spot The Bug

Keep track of Heat Signature