Learning from others' mistakes

(Moderators, if this should be somewhere else, my apologies and I’ll be happy to move it.)

We normally post requests for help here. But this isn’t a request for help, it’s a bug success story!

Out of the blue, my WIP stopped working today. When I finally figured out what I’d done wrong, I couldn’t believe that I’d never tripped over it before, and I wanted to share it for the benefit of others.

My WIP was compiling beautifully (all 23 rooms and 66 objects to date), but all of a sudden, none of my scope adjustments worked. My game depends heavily on adjusting the scope; without adjusting the scope, there is no game.

I hadn’t been working on that functionality, so I had no clue when the code had stopped working. I searched my source for “scope”, and found exactly three instances:

Chapter 1 - Scope

After deciding the scope of the player:
	repeat with target person running through people:
		place target person in scope.

I couldn’t replicate the problem in a smaller sample, so I finally grabbed my full source code and started hacking it down until I could find the single line or section that was breaking things.

Finally, I found the offending line. I could pull it out, and the game worked; I put it back in, and the game broke. The problem was that it had nothing to do with scope.

The CD player is a closed container. 

I uninstalled and reinstalled my copy of Inform. I tried my WIP on a different computer. No luck. I went all the way to The Big Fear: something was dreadfully wrong with Inform, and my game was completely unviable. I would send sad, pleading emails to Graham Nelson for help and receive a promise that it would work in the next release, but the next release would never arrive in time. I would eventually attempt to rewrite the entire scope functionality in I6 and then die bereft in a basement.

Of course, I was wrong, and I figured it out a few minutes later. The moral of the story?

Never name anything in I7 a “player”.

What’s your weirdest code trouble story?

I7 only has a concept of scope for temporary variables.

So the moral is don’t name any object ‘noun’ and then name a different object ‘adjective the-same-damn-noun’.

My story is similar to Carolyn’s in terms of it being just one word that sank everything.

My game was going great at 10s of 1000s of words of source. Then it suddenly failed to compile, throwing up a series of seemingly irrelevant error messages.

Anyway, I had to get the kind mantis bugtracking folks to look at it. They did some high level tracing thing and discovered I had struck a known bug. Putting the word ‘world’ in an object name can cause trouble… I had a ‘world globe’ in the game. At some point, circumstances in my code brought out the bug.

So the fix was to rename the object ‘globe’, and to add an “Understand ‘world globe’ as ‘globe’” line.

  • Wade

I’m not sure I understand the moral of your story. How did Inform parse your code? It looks legal to me.

Back in the day I had a WIP where I didn’t need to keep track of the time of day, so I figured I could just remove the rule that advances the clock and shave a few bytes off the story file.

The advance time rule is not listed in any rulebook.

Later it turned out that rule also increments the turn counter, so all every turn rules that were set to run every X turns mysteriously failed to work. Debugging that wasn’t very easy.

Moral of the story: don’t mess with the standard rules unless you really know what you’re doing.

If you name something “CD player” then Inform will think that whenever you say “the player” it refers to that. So “After deciding the scope of the player” will turn into “After deciding the scope of the CD player,” etc. That came up at least once before, with the added twist that some mispunctuation had created an object called “The player carries a headlamp The headlamp,” and that the lines that were throwing errors weren’t the mispunctuated ones but a bunch of lines referring to “the player” in an extension.

I bet you didn’t even save that byte: unlisted rules are still compiled and usable; it’s just that they don’t run as part of this or that or any rulebook.

As for coding troubles, I used to get lots of halting-in-abject-failure messages that should-never-happen, when I first tried out Inform. I still have no idea what I did to provoke them, but apparently I do those things different now, because I don’t see them at all as often.

My computer throws a should-never-happen about 1 time in 25, but rerunning the compile immediately will work just fine. Which is comforting and dismaying all at the same time.

You should report that, next time you see it. It’s not 1/25th as a bad as a “real” error.

Well I didn’t know that then!

It would be great if Inform did some code analysis and removed unused rules before compiling.

In fact, it’s even worse - if the rule still uses up bytes and your delisting of it adds extra code, you actually increased the bytes! And the moral of that story is… um… don’t worry about a few bytes, I guess. :slight_smile:

if the rule still uses up bytes and your delisting of it adds extra code

It doesn’t.

Really? But… but… No, I don’t get it.

If you don’t replace the rule with a new one then you’d save two bytes in the rulebook array!