Open eriktorbjorn opened 5 years ago
This type of bug can be seen in at least the following bug reports:
On second thought, calling IDROP
in PRE-THROW
is probably not such a good idea after all. What if a later action routine decides that you don't want to throw the object after all? Then you'll have dropped it.
So if we want to fix this in PRE-THROW
it would have to be by calling a routine that goes through the motions of dropping the object, without actually dropping it. That should be easy enough.
Another example of a throwing bug: https://github.com/the-infocom-files/zork2/issues/18
Though in this one, the hands remain where they are.
On the other hand, the usual fix (e.g. in CLIFF-OBJECT-F
) seems to simply be to check <IN? ,PRSO, WINNER>
so maybe that's what we should do as well?
While testing Zork I, I've found a depressing number of cases where you can throw away objects that you shouldn't be able to, e.g. your hands.
The
V-THROW
routine handles this by callingIDROP
to see if the object can be let go of, but that's only the default behavior. Any object that handles the "THROW" verb doesn't automatically get that protection.Adding a
PRE-THROW
action might do the trick. It wouldn't have to be very complicated:I think we can assume that
IDROP
prints its own error message when it fails.Of course, the same thing would probably have to be done for
V-THROW-OFF
andV-OVERBOARD
as well. Plus any other that I may have missed.