I have a woodcutter standing in front of a woodcutter’s hut. If I examine the woodcutter and woodcutter’s (without the ‘hut’ noun), I get responses like this:
He's a well-built man.
He's a well-built man.
The second response is clearly wrong. I’m presuming the bit in parentheses is because I have name 'woodcutter' for the woodcutter and name 'woodcutter^s' 'hut' for the hut. In both cases, the dictionary words are truncated at 8 characters, so ‘woodcutter’ and ‘woodcutter^s’ are both stored in the dictionary as ‘woodcutt’.
Is there any way to increase the dictionary word size (so that the hut is not seen as the woodcutter) or avoid the parenthesised bit in the responses?
There’s an example of this for I7 at http://inform7.com/book/RB_2_2.html (either increasing the word size for Glulx targets, or replacing part of the input with abbreviations before parsing for either machine).
It should be possible to translate these back to I6, since I7 compiles down to I6 anyway.
You can look directly into the text buffer (which holds the input line as typed by the player) and see if you can find the “r’s” you are missing.
The compiler truncates the word size to 9 characters. Each alphabetic character, without accent, occupies 1 character; with accent 4; 2 for the remaining characters.
(For Zcode! I know nothing about Glulx.)
Thankyou both. This was very helpful. I knew there was something like this somewhere, but didn’t know where to look.
I had the maximum number of characters wrong. I had a gut feeling that it was 8, but it is actually 9, as auraes pointed out. It’s also described in DM4, if you know where to look.
As I’m compiling to Glulx, I thought that changing DICT_WORD_SIZE would be much easier to use. A search of the library files does not give a default, so I wrote a quick and dirty little program and this indicated that DICT_WORD_SIZE is 6 for Z-code and 9 for Glulx. I think DICT_WORD_SIZE is actually the number of bytes used for dictionary words. As 3 characters are stored in 2 bytes in Z-code, this would explain why Z-code returns a DICT_WORD_SIZE of 6, but stores 9 characters. But if Glulx returns a DICT_WORD_SIZE of 9, I’m guessing that it stores one character per byte. Perhaps zarf could confirm this.
I then tried setting DICT_WORD_SIZE to 12 before including any of the libraries. This is apparently a read-only constant. I tried setting it as a constant and as a global, compiling to Z-code and Glulx and all four scenarios gave me a compile error. So it looks like I can’t change it. How the hell does Inform 7 get around this restriction?
So it looks like I’ve got two options: either write a short parse_name routine for each object or delete ‘woodcutter^s’ as a name for the hut. I think I’ll just use the latter, at least for the time being.
I have no idea what that does. The exclamation mark denotes the start of a comment. I tried adding it just the same. It compiled fine, but DICT_WORD_SIZE was unchanged. Maybe it’s some sort of compiler directive for the Inform 7 compiler.
In the meantime, I scanned all the name definitions in my file. It’s amazing how many 8- or 9-character words I had and some even longer. The only other conflict I had was the blacksmith and the blacksmith’s cabin, so I’ve fixed that one too.
DICT_WORD_SIZE is a special I6 compiler constant. You set it like this:
Use DICT_WORD_SIZE of 12.
(Glulx only. In Z-code, the DICT_WORD_SIZE is fixed by the Z-machine spec.)
There are some other ways you could handle this. You might do
Understand "woodcutter hut" as the hut.
This would accept “woodcutter’s hut” and “woodcutter hut”, but not “woodcutter’s”. This is a reasonable outcome for most situations.
You could also write an After reading a command rule to replace “woodcutter’s” with “cutter’s” in the input. (The “North by Northwest” example in the recipe book.) This is a little slower, since it does additional string manipulation on every input, but it’s not a big deal in a small game.