Canonical list of travel checks in TADS3/adv3?

Authoring TADS
1

Is there a canonical list—or a utility function—that evaluates whether or not a given travel action will be permitted for a given actor?

Basically I’m working on some fiddly NPC pathfinding stuff, specifically involving locked doors. As near as I can tell the only way to reliably answer the question of whether a given actor can use a given travel connector is not TravelConnector.canTravelerPass() or Actor.canTravelVia(), but rather laboriously reproducing all the logic in TravelConnector.dobjFor(TravelVia). Which in turn involves laboriously reproducing a bunch of preconditions. Which have to be re-implemented because most of them have references to gActor baked in.

3 Likes
2

It’s actually even worse that I summarized above, as one of the things that happens in actual travel that isn’t checked for by any of the travel check methods is implicit actions. If you have a locked doors, for example, the travel failure happens when an implicit >OPEN on the door happens.

This means that, so far as I can tell, there’s literally no canonical list of checks for travel success or failure, shy of actually attempting the move.

That’s what I had been doing between when I initially posted the question and a couple days ago: a try/finally block that does a TravelVia and then checks the actor’s location afterwards, inside a savepoint() and undo().

Which works, but is slow.

3

The approach I’m leaning toward here is providing a “basic reachability” test based only on a connector existing, being apparent, and so on. This is all that adv3’s roomPathFinder does, for example.

Additionally add a per-connector check method. This is for checking isOpen() on BasicOpenable, isLocked() on Lockable, and so on.

Finally accepting an optinal callback method which, if given, will be called on every candidate connector.

This is messier than what I’d really like—it seems like “can this actor move from their current location to a given other location” is a pretty basic question that shouldn’t require actually attempting it to resolve. But for my actual purposes implementing per-class checks looks like it will be a lot more straightforward than trying to second-guess all the possible stuff that could possibly happen via implicit actions.

1 Like