Print order

[Bainespal]

I thought I remembered an old thread somewhere on this board raising the issue of how the order of appearance for short_descs or initial_descs in the same room is determined. I couldn't find that thread, so I'll bring up the discussion again.

I finally got a total scene description -- the room description plus the short_desc/initial_desc descriptions -- to fit together correctly for one of the messier rooms in "Tree and Star." I've also relied on short_descs to convey important information about the location in "World Builder" and in the game I was making before that. Doing so is helpful for several reasons from a design perspective, not the least because short_descs will always be displayed, even if the player prefers to use brief mode.

The order in which short_descs appear is usually important to me. I see that the youngest child on the object tree usually gets its short_desc printed first, and then children of container\platform objects may be listed. I think any grandchildren that have short_desc or initial_desc properties still get displayed only after all the children.

There's a lot of this that I don't understand. I think NPCs might be handled differently from other objects. Component objects definitely complicate things. In the scene description I was working on, I wanted a component object to print a short_description, so I took away its default hidden attribute. The component object was then always displayed first, directly beneath the room description, no matter what else I did. I didn't want the component object to appear first, so I used its short_desc property to mention the object that I really wanted to appear first. This is messy, but I'm sure it makes no difference to the player what code object prints the text that mentions any given characteristic of a location.

If you have an object that absolutely has to be printed first, no matter what, one good cheat is to make it scenery (or give it the hidden attribute) and then simply write its "short description" as a separate paragraph at the end of the room's long_desc. More complicated scene descriptions require more complexity than this, however.

[Roody_Yogurt]

Sounds like you basically have it right, in terms of printing order being decided by object tree 'youth'. The only thing is maybe you meant 'scenery' where you said 'component'. Components use the found_in property to be available in a room, but as they are not actually a child of said room, their short_desc's are never called. Anyhow, like you said, for scenery, it is often best to put their descriptions in the room description.

Now, as far as order goes (like where NPCs are listed), you do have some control if you use my DescribePlace replacement:
http://hugo.gerynarsabode.org/index.php ... cribePlace

In any case, looking at it might give you a better idea of what the current order is.

[Bainespal]

The only thing is maybe you meant 'scenery' where you said 'component'. Components use the found_in property to be available in a room, but as they are not actually a child of said room, their short_desc's are never called.

Well, my component object is also literally located in the room in question, and I deliberately removed its inherited "hidden" attribute in order to allow its short_desc to be called.

But found_in -- that's probably why the component's short_desc kept being called first of all the objects in the room even when I deliberately moved the other objects back into the same room to try to get their short_descs printed first. I believe found_in objects are moved into the rooms specified in the found_in property each turn, so it would make the component object the youngest child of the room object every turn.

Now, as far as order goes (like where NPCs are listed), you do have some control if you use my DescribePlace replacement:
http://hugo.gerynarsabode.org/index.php ... cribePlace

In any case, looking at it might give you a better idea of what the current order is.

It does help. Your DescribePlace replacement looks like it can help with a lot of the print ordering that I've been doing. I bet you can even change the values in the DescribePlaceOrder array whenever you want, in order to have a different order for different rooms or different parts of the game.

I have a question about the replacement. The HxE article says that the first step to use the code is to set the DESCFORM_F FORMAT mask. Will the ordering specified in DescribePlaceOrder still work even if you don't use DESCFORM_F?

[Roody_Yogurt]

Well, my component object is also literally located in the room in question, and I deliberately removed its inherited "hidden" attribute in order to allow its short_desc to be called.

Yeah, technically, found_in objects are not supposed to also have physical locations, but I don't think doing so should really break anything, either.

But found_in -- that's probably why the component's short_desc kept being called first of all the objects in the room even when I deliberately moved the other objects back into the same room to try to get their short_descs printed first. I believe found_in objects are moved into the rooms specified in the found_in property each turn, so it would make the component object the youngest child of the room object every turn.

Actually, no. I wasn't reading correctly the last time so I didn't catch it, but no, in any kind of object loop, the oldest objects will be printed first (as they have lower object numbers).

Also, found_in objects are not moved in from turn to turn, giving them new object numbers. Instead, they are checked for specifically by FindObject, which is called by the engine during grammar-matching.

In your case, I'd compile your game with HugoFix on and do the "$ot 0" (object tree) command. Maybe seeing your object tree how your game sees it might help you figure out what's going on.

It does help. Your DescribePlace replacement looks like it can help with a lot of the print ordering that I've been doing. I bet you can even change the values in the DescribePlaceOrder array whenever you want, in order to have a different order for different rooms or different parts of the game.

Yeah, I didn't foresee that, but that's completely doable.

I have a question about the replacement. The HxE article says that the first step to use the code is to set the DESCFORM_F FORMAT mask. Will the ordering specified in DescribePlaceOrder still work even if you don't use DESCFORM_F?

The page is a bit unclear, yeah. That step is indeed optional. You only should set the FORMAT mask if you want the "Infocom" look where it is double spaced between groupings of objects. You're completely fine without it.