Spot The Bug

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.

Runner 2015-07-25 11-12-14-51 bad

Runner 2015-07-25 11-12-38-09 bad

Runner 2015-07-25 11-12-51-97 bad

Runner 2015-07-25 11-12-55-62 bad

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

Runner 2015-07-25 11-11-10-86 good

Runner 2015-07-25 11-11-30-26 good

Runner 2015-07-25 11-11-40-09 good

Runner 2015-07-25 11-12-03-81 good

Runner 2015-07-25 11-12-32-95 good

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.

8 Replies to “Spot The Bug”

  1. 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.

  2. 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?

  3. 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.

  4. 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

  5. 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.

  6. 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.

  7. 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:

Comments are closed.