GoTo/adv3

Authoring TADS
1

Does anyone know offhand if there is a GOTO/CONTINUE module for adv3? I’m lazily asking before having perused the extension archives myself. I’m looking for the kind where the PC is not whisked to the destination but has to travel the route step by step, albeit by hitting ‘g’ instead of having to analyze the directions to take…

3 Likes
2

I don’t know if there are other ones, but I wrote a module for something like this. It’s a little heavyweight if you just want a fast travel action, because it includes a bunch of other stuff both related to fast travel (the ability to customize things that interrupt fast travel, the ability to output either each individual “step” in the total travel or to summarize it, and so on) and to general “navigation” stuff (non-compass travel, movement-by-room-name, pathing by “zones” to allow movement to a closed door when attempting to path through the door, and so on).

The repo isn’t public because it’s still got a lot of churn, but if you can’t find something else I’d be happy to make the repo public if it would help.

3 Likes
3

Thanks. At this point, all I’m looking for is what’s stated in the OP… a player convenience to cross the map a little easier without having to wrangle with the directions to each location. I do, however, want the game to execute each travel action in turn – I have lots of atmosphere msgs and NPC msgs that I don’t want to cut out, and I also need to track the distance the PCs travel. So I was pretty much wanting what Lite has with the GoTo/Continue. I may just try to port that…

4

adv3Lite has one built-in (in pathfind.t, also look for verbs Continue and GoTo). If you can’t find an adv3 module that works for you, you might try porting it to your project. It’s only about 400 lines of code, plus a couple dozen more for the verbs.

I also found this library in IF Archive that, if I’m reading it right, implements a number of path finding algorithms that can be plugged into a generic “find path to room” object. You might need to implement the GoTo and Continue verbs on your own.

(Funny enough, one of the library’s routing algorithms is dubbed “Floyd.” I thought this was a reference to the Planetfall Actor, but it’s an implementation of the Floyd-Warshall algorithm.)

2 Likes
5

Thanks Jim, yeah, at this point I’ll probably just try to port the Lite mechanics. I’m not in the brainspace to want to have to think through a lot of stuff right now, I just hoped to include a little more player convenience before the deadline. I’ll see how it goes and maybe share the results for future adv3 users if it works…

2 Likes
6

Well, after looking at the code I already had I decided to break out the fast travel stuff into its own module. It’s here: fastTravel github repo.

When I’d originally written it, the module was intended to hold all the “non-traditional” movement/travel stuff that I needed for my WIP. But now I think it needs to be a couple independent modules, just to make it easier to test if nothing else.

Anyway, the simple version is that the module provides a FastTravelRoom class. Fast travel is only permitted to/from/through instances of this class (although there’s nothing preventing you from declaring all your rooms to be instances or dumping the logic onto the base Room class).

At runtime, fast travel is allowed if any of the below is true:

  • The destination is known to the player (i.e. the player has visited the room previously, but it uses gActor.knowsAbout(location) under the hood, so setKnowsAbout()/setKnownBy() will work as well)
  • The destination is adjacent to the player’s current location
  • The object has fastTravelStartKnown = true

By default, that’s more or less all there is. The verb is >TRAVEL TO [location name], and the output is the same as what you’d get by entering the individual actions “by hand”.

The module’s options are controlled by the properties on a global singleton, fastTravelConfig. They are:

  • allowInterrupt if true, then instances of the FastTravelInterrupt class will halt fast travel when the player enters the same location/sense context as the object. The object’s fastTravelInterruptMsg property, if any, will be displayed at the end of any fast travel message(s)
  • showArrivalMsg if true, this will display an arrival message after any travel message(s). If the destination room has a fastTravelArrivalMsg defined that will be displayed, otherwise playerActionMessages.fastTravelArrivalDefault will be used.
  • summarize if true this will suppress normal travel messages and will display a summary (possibly an empty string) instead
  • summarizePath if true (and summarize is also true), then the destination room’s fastTravelSummary() method will be used to summarize the fast travel action. The method will get the traversed path (a List whose elements are the room objects) as its argument. By default fastTravelSummary() just lists the rooms passed through using stringLister.makeSimpleList()
  • lookAroundAfterSummary if true then this will display the lookAround() message for the destination room, after any travel summary message(s)

By default the module uses T3’s builtin pathfinder. You can use the routeTable (precomputed) pathfinder by compiling with the -D FAST_TRAVEL_ROUTE_TABLE flag.

Demos (including makefiles with the necessary flags and so on) in the ./demo/ directory in the module.

3 Likes
7

I’ve already ported a simplified version of Lite’s pathfind.t plus GOTO and CONTINUE verbs (which I renamed to TravelTo, like you did). But to be honest, I hope to write a game eventually that requires more complicated NPC movements. It looks like a lot of fun. For my current game I’m going to limit the player where they they can TravelTo to, because the number of vocab objects in my finished game is insane, and I don’t want to start at this late hour dealing with disambig issues. There will be several key points around the map they can easy-travel to, with clear and unambiguous vocab, otherwise, the action won’t be available.
At least pre-comp, anyway…
Your modules look great, though.