I’ve been reading “Learning TADS 3” by Eric Eve and enjoying it a lot! I’ve had various questions about the nuts and bolts of things as I’ve read, most of which I’ve been able to answer for myself by reading the technical manual, library reference, or source code of adv3. But I am stuck on this one.
“Learning TADS 3” essentially explains the difference between moveInto and moveIntoForTravel as “use moveIntoForTravel and NEVER moveInto for actors, and use moveInto for inanimate objects unless it causes problems.” The technical manual says moveInto “tries to find a simple containment path between the old and new locations” because it’s made for moving objects around and notes that this can cause problems when moving objects between rooms.
Indeed, looking at the source for these methods shows that the only difference is that moveInto calls another method called moveIntoNotifyPath at the start. That method does some sort of pathfinding and throws an ExitSignal if it can’t find a traversable path.
But I don’t understand the scope of what this pathfinding step is accounting for, or why I would want this check done when I direct an object to move itself, instead of as part of an earlier phase. It seems like using moveInto even for inanimate objects could cause nasty surprises in edge cases if I don’t properly understand what it’s doing and why, especially if I do complicated things with containers and nested rooms.
Is there anyone who can help me get a clear picture of what moveIntoNotifyPath is responsible for? When is the check important? How do I prepare for the possibility that it will fail?
I’m not sure if I can fully cover the nuances of your perplexities, but I’ll take a stab. moveInto is used when you want to simulate the physical movement of the object in the game world. Using this method allows the various obstructors and containment characteristics to have their chance to stop the action if it’s unfeasible, and they will print the proper failure messages if so. The putting and taking library verbs use it because they don’t want to have to do their own checking of whether the object can end up at the desired destination: they just announce their intentions and then hand it over to the “path” to either get it there or tell you why you couldn’t. moveIntoForTravel is more like the author saying “I WANT this object to end up here, code…”, but still does more housekeeping than the ultra-stark baseMoveInto…
There’s a possibility that if your intentions are to not utilize or observe any of the conventions provided by adv3 involving paths/obstructors and whatnot, maybe you are best off just using moveIntoForTravel for any of those situations.
moveIntoNotifyPath will create/traverse the containment path from the moved object’s current location to its intended destination, and on each step of the way it will have to pass the various methods such as checkMoveThrough, canFitObjThruOpening, the isOpenness of Openables etc…
That helps, thank you so much! It sounds like moveInto is geared very specifically to move things as part of an action, rather than as a consequence of an action or as part of a non-action occurrence, and in other cases it will be better to check for obstruction in other ways if checking for obstruction is necessary.