PLACES - Inform 6

Authoring Inform 6
1

Does anybody know how the command PLACES classifies the rooms? I ask because I have one removed object that ends up on this list. I also have another object that I move into a room, during gameplay, that ends up on this list. It happens after being moved into the room. It’s not a game breaker, but it looks strange and I’d love to fix it.

I’m using the PunyInform library 6.1.1 along with Inform 6.44.

I am also using the constant OPTIONAL_NO_DARKNESS.

1 Like
2

It looks like the PunyInform library is a bit shaky on the PLACES command.

The relevant bit of code looks like

	objectloop(i has visited) {
		if(parent(i) == 0) {
			print (name) i; k++;
			! ...
		}
	}

So the criterion is “Objects with visited which are not contained in anything”.

The problem is that PunyInform cleverly aliases visited (for rooms) and moved (for objects) as the same attribute. So if an object has the moved attribute, and is then removed from play, it will be listed in PLACES.

2 Likes
3

Sweet. It looks like all I have to do is:

give object ~visited;

before I remove the object and it cleans up the list. Thanks for looking into this.

4

You could also make a “trashcan” room and move objects there instead of removing them from play.

5

I was going to suggest doing this the other way around (making a Rooms object that all rooms are children of), but objects are in short supply on Z3, so I can see why the library doesn’t do that. A “limbo” object is a better solution, since that’s entirely on the author’s side.

(Or make them children of some object that’s never on-stage, if you’ve got one. Infocom did this in Sorcerer.)

6

I think the best solution is a combination of the two suggested, depending on the object.

If the object needs to be removed from play, but it can later be returned to play (typically by testing if (thing in nothing)), use:

give thing ~moved;
remove thing;

If the object needs to be removed from play and can never be returned to play, use:

move thing to limbo;

Limbo is merely a dummy room created using:

Object limbo;
7

In both the standard library and PunyInform, it’s illegal for a room to have a parent.

Maybe in the current iteration of the standard library, you can get away with it, but I doubt it. I’m sure you can’t in PunyInform.

The definition of PlacesSub in PunyInform is a mistake, which we werent aware of until now.

2 Likes
8

PunyInform 6.2 has a better version of the ‘places’ meta-verb. It checks various properties and attributes to check if a certain object appears to be a room. Also, it calls an entry point routine called IsARoom, if the author has supplied it, and this routine can make a decision.

1 Like
9

Thanks for looking into this. I didn’t see that you released a new version of PunyInform 4 days ago, and I don’t think it’s a good idea to change the library this close to the competition. I’m trying to compile my final build today, and test it on 8-bit over the next 24 hours. But thanks for all the work.