Inventorizing is an action applying to nothing.
Understand the command "stockpiles" as something new. Understand "stockpiles", "stockpiled", "individual stockpiles", "scrutinize individual stockpiles", and "scrutinize stockpiles" as inventorizing.
Carry out inventorizing:
say "Stockpiled: [line break]";
list the contents of the player, with newlines, indented, giving inventory information, including contents, with extra indentation.
Result:
>stockpiles
Test is now in its “brief” printing mode, which gives long descriptions of places never before visited and short descriptions otherwise.
What on earth is going on?
Contents of the carry-out rule are cadged straight from the documentation,with the “say” tweaked slightly. As you can see I had a bit of a ??? moment and tried specifying the offending command as something new (which I don’t think was the actual problem, as 1. that did nothing and 2. it also happens with the other synonyms).
The word “stockpiles” doesn’t even contain the word “brief”! I’m so confused!
Yeah, this is confusing! If you can’t isolate the code that’s causing this, maybe see if the TRACE testing command will help clear things up? (I think BRIEF goes directly to the I6 “layer” so RULES and ACTIONS probably won’t do much).
Thanks for the tip on trace! I saved my draft elsewhere and then removed everything except for one player item, a bare starting room, and the verb code. And I get, drumroll…
…okay whatever I was expecting, it was not that. You can get more information out of TRACE by invoking it with TRACE 5, which I’m morbidly curious about, but all I can think is that something might have gone wrong with your Inform installation or your Standard Rules got messed with somehow?
>stockpiles
[ “stockpiles” stockpile ]
[Parsing for the verb ‘stockpile’ (1 lines)]
[line 0 * → Restart]
[line 0 token 1 word 2 : END]
[Line successfully parsed]
Are you sure you want to restart?
I do notice that for some reason it’s automatically reading it into “stockpile” (without the “s”), but I’m afraid I have no idea what the significance of that is. I literally just freshly installed I7 today – this is a new computer – off the Windows package from the latest release on Github (dated 2022, iirc?), so I’m not sure how I could have already mucked something up.
Okay I can reproduce the restart behavior is 10.1.2, but not in 9.3. Weird. Someone with more familiarity with the inner workings of Inform will need to answer this one.
That’s just a default – you can extend it by writing “Use DICT_WORD_SIZE of 12” (or whatever number you want – not sure if there’s a meaningful upper limit?)
Exciting update though, I’ve confirmed that I’m getting the same error with this code in Inform 10 (it works as expected in the I7 IDE)! So seems like this might be a very funky bug? I’m going to tag @Zed as the best Inform-bug-knower-guy!
Turns out if you get rid of “stockpiled”, it works. It’s something about having two grammar strings that are “identical” after being truncated to DICT_WORD_SIZE…
Ope, was experimenting and came to the same conclusion. Glad to have someone more experienced confirm. What a truly bizarre way for a bug to manifest! (And I’m amused(?) that the tangential sidetrack turned out not to be tangential at all!)
Yeah, I6 is handling this case wrong. Although I7 shouldn’t be generating it in the first place.
The problem may or may not reproduce depending on how many verbs your game has and what order they’re defined in. I’ve now reproduced it in both 9.3 and 10.1, with different test cases.
Oh, this is fascinating! To summarize what Zarf’s reported at that issue link:
When Inform compiles a game, part of that game is the “dictionary table”, a list of every word the game can recognize. Each word has a small amount of data attached to it, such as a flag for “if this is used as a noun, should it be interpreted as plural?”
When the compiler is building the dictionary table, when it sees a word used in a new way (like as a plural), it adds that flag to its data. Under the hood, it’s using a “bitwise OR” operation here: new flags can get set, but old flags can never get cleared. This generally works fine, because that’s how all the flags are designed to work.
Except that one section of that data isn’t a bunch of flags—it’s the “verb number”, an index into a lookup table that’s used whenever this word is at the beginning of a command. Normally each word has a maximum of one verb number, it never gets set more than once.
But if you have two verbs that are distinct in the source, but the same to the parser (like “stockpiles” and “stockpiled”, when it’s only looking at the first nine letters), then it ends up getting inserted into the dictionary table twice—and when it does, the verb numbers are bitwise OR’d together! The result is that this verb ends up pointing to a different action entirely…sometimes. Sometimes it doesn’t. Sometimes it produces nonsense. Hard to predict!
It’s a very neat bug, and it’s easy to see how it’s slipped under the radar all this time. Good catch!
Huh! That’s really interesting. In new-parser ZIL, you get a fatal error at compile time if this thing happens (two words with differences in characters 10+). Which is really annoying since it doesn’t actually tell you where in the code this happens (due to some odd restrictions which hopefully get fixed).
