I7: Dynamic Objects and Programming Error

So I have a large group of items of a single kind, and many of them have additional “understand” conditions. A number of these items are cloned via Dynamic Objects and randomly distributed throughout the world map upon start. They’re all table defined.

When I run the first room, I get:

Sometimes I get one message per item; sometimes less. When there’s duplicates, they all occur before the list of objects in the location.

It seems to happen especially when multiple items have the same “understand” conditions for their plural (ie “Understand ‘x’ as the plural of y” and “Understand ‘x’ as the plural of z”).

This error seems to go away when I remove either the long list of “understand ‘x’ as the plural of ‘y’” or when I hand-place these objects in the world. However, it doesn’t seem to be caused by these, either. Similar test conditions could provoke no similar bug. Dynamic Objects and Tables are updated to the most recent versions.

It only happens on the first look of the game. If the first room doesn’t contain these particular objects, it never fires. If the PC leaves and comes back to a room where the error occurred, everything is fine.

Anybody know what might be going on?

Is this something that Multitudes would help with?


I’m sure it could be useful in that way, but it would require a pretty aggressive reworking of what I’ve got now.

Fair enough. I’m too scared of dynamic objects to actually be able to help you with this, but if you get to the point where you are considering Multitudes, feel free to write to me with suggestions or requests - I’d like to make Multitudes more widely usable before I submit it to the inform7 site, and having feedback from other authors who are actually trying to use it would help a lot.

Update: this appears to be a weird obscure thing happening between Dynamic Objects and Numbered Disambiguation. I can’t see anything that explains it on the Numbered Disambiguation end, and I can’t “read” the I6 in Dynamic Objects, but it only happens when both are in play. (While testing, I upgraded from version 3 to version 5 of Numbered Disambiguation, but get the same error.)

Anyone have any idea what might be happening, and better yet how I could fix it?

Test code:

Include Dynamic Objects by Jesse Mcgrew.
Include Numbered Disambiguation Choices by Aaron Reed.

Test Room is a room.
A spiffle is a kind of thing. A blip is a spiffle. A bloop is a spiffle.

When play begins:
repeat with N running from 0 to 2:
let new spiffle be a new object cloned from a random spiffle;
move new spiffle to the Test Room.

Understand “spiffy” as a blip.
Understand “spiffy” as a bloop.[/code]

I’m looking into it… the bug is somehow related to the generated parsing routines. The error still appears if you remove Numbered Disambiguation Choices and add this instead:

A thing has a number called foo. Understand the foo property as describing a thing.

OK, this seems to be a bug in Inform’s generated parse_name routines. It might not technically even be a bug, just an optimization that’s usually safe, but dangerous when Dynamic Objects is involved.

When a number property is understood as describing an object, that’s supposed to affect the parse_name in two ways, since the parse_name routine serves two roles: it parses an object’s name and also decides whether two objects are “identical” and can be combined in lists (since objects are considered identical only when the player can’t type anything to distinguish them).

When the routine is being called to check whether objects are identical, it’s not supposed to read words from the command line, since this use has nothing to do with what the player typed (and in this case, it’s called before they’ve typed anything). But the parse_name routines generated for “blip” and “bloop” – specifically the parts that deal with the understood-as-describing property – ignore that guideline. This is normally safe since their parse_name routines are unique, and Inform always assumes that objects with different parse_names are non-identical, so they’ll never be asked to distinguish between objects anyway.

However, when you clone blip or bloop, you end up with two objects that both use the same parse_name routine: one which was generated with the assumption that it would always be unique. Inform calls the parse_name routine to check whether the cloned objects are identical, it tries to read words that aren’t there, and you get a runtime error.

So… you can work around this by manually setting the parse_name routine back to the version that was generated for the “thing” kind, which handles this situation correctly:

[code]When play begins:
repeat with N running from 0 to 2:
let new spiffle be a new object cloned from a random spiffle;
correct parse_name of new spiffle;
move new spiffle to the Test Room.

To correct parse_name of (O - object): (- {O}.parse_name = K2_thing.parse_name; -).[/code]

Fantastic. Thanks so much for looking into this for me.