Doer and Shipboard Directions

I’m working through the adv3Lite Library Tutorial, and just finished the Airport chapter Aboard the Plane. I’m having some trouble with the final item, a Doer that disables shipboard directions outside of one region. Here’s the code of the doer:

[code]Doer ‘go dir’
"Shipboard directions don’t have much meaning here. ";

direction = [portDir, starboardDir, foreDir, aftDir]
when = (!me.isIn(planeRegion))


The issue is that when I try to use shipboard directions outside of planeRegion, I get this response:

which is slightly different from the one I tried to define. Based on further experimentation, this seems to be the adv3Lite default response when the player uses shipboard directions in a room where none are defined. I’m not sure what’s up with the comma, but it’s consistent even in other sample games that have no shipboard directions.

I tried commenting out the “when =” line, so that the Doer would be effective even on the plane. The custom message is displayed in rooms with shipboard directions defined, but not in rooms where they are not defined.

So my guess is that something in adv3Lite is dealing with the shipboard directions before the Doer comes into play. What I don’t know is whether this is due to a mistake on my part, a typo, or an issue with the tutorial. It’s not a huge issue, but I would appreciate any help figuring it out.

Indeed what you have been seeing all along is a default library message. The comma is a typo in the library; I have run into it as well. Eric will probably fix it eventually but in the meantime you can fix it as follows:

messages = [
Msg(no shipboard directions, 'Shipboard directions {plural} {have} no meaning {here}. ')

As for the reason why you don’t see the message defined in your own doer, I think there might be a little error in the tutorial. First, note that if you replace execAction© with exec©, you’ll see your message. What happens here, in short, is that the exec© implementation in the base Doer class first checks if shipboard directions are valid, and if not, aborts the command with the error message you’re seeing. Then it does other stuff, and eventually, it calls execAction(cmd). So, the execAction of your doer is never reached, because the conditions under which it should trigger are also the conditions under which exec aborts early with the built-in refusal of shipboard directions. That’s also why you can see your message if you override exec: in this way you bypass the default handling.



Thanks, Michael!