Bug: Pushable objects are not described when handled

From the docs:

But there is an important exception: As soon as the player picks up an object (or otherwise moves it from its original location), the responsibility for mentioning that object is transferred to the library. We say that the object has become handled or, equivalently, that it is no longer pristine.

This is not, in fact, the case. This is the library code responsible for this:

(appearance (item $Obj))
	($Obj is handled)
	($Obj is $Rel $Loc)
	(if) ($Rel = #in) (room $Loc) (then)
		You see (a $Obj) here.
	(else)
		(A $Obj) (is $Obj) (name $Rel) (the $Loc).
	(endif)

This only applies to handled items. A (pushable $) object that’s been pushed becomes handled, but is not described by the library.

Do you think the better solution would be to patch the docs, or patch the library?

2 Likes

I vote for updating object to item in the documentation, and let the author decide if/how a pushed non-item object should appear in room listing.

1 Like

In the abstract, I would think if it’s worth the library handing this for handled items, it’s also worth it for handled pushables. If the author doesn’t want that, providing an explicit (appearance $) for the object in question - which is what they would have had to do anyway - will override it.

The practical question in this case of course is whether it’s any more straightforward to release an update to Dialog than an update to the docs - is that something you were going to do anyway?

I’m currently working on some improvements to the compiler, so eventually yes, though I’m not sure if I should make it a renamed fork or what.

1 Like

I’m for a renamed fork, If the new name don’t cause confusion with this *nix standard program:

(which, incidentally, CAN be used for CYOA IF…)

Best regards from Italy,
dott. Piergiorgio.

1 Like