Zugg Software :: View topic - Brainstorming: Timed Teleport Rooms (Very Long)

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

As has been mentioned often, there are usually at least a dozen valid ways to solve a problem in zScript. This is a good thing, but it sometimes leaves one trying to figure out which is best/most efficient/easiest to maintain or use, etc.

This thread is perhaps the first of many in which I am going to think out loud about a script-design problem I'm facing as I build my next-gen scripts for CMUD. I'll give a description of the problem I'm trying to solve, along with MUD output and other details that seem relevant, plus several approaches that I've thought of. I'm soliciting opinions, feedback, suggestions, criticism, and observations.

My hopes are this will result in a design-level conversation, with several benefits:

I get feedback on my design decisions, so I can refine my thinking.
Wiser heads can suggest approaches I have not thought of.
We all get to show how smart we are, and that we can solve complicated problems.
We might generate good feature requests for the new mapper (or other parts of CMUD)

Specific code is welcome, of course, but don't feel the need to generate it to participate - I'm more interested in getting the design right. I can implement with the best of 'em.

And don't be shy about suggesting radical changes to my setup. I have no proprietary interest in my scripts (beyond bragging rights), and I don't sell 'em, so ask for any details you think may be relevant.

Ok...on to our first problem:

The Problem

Mozart MUD has several features that I have not seen mentioned much on these forums. I'm primarily concerned right now with Timed Teleport rooms, which I'll call TTRs to save typing. TTRs have the following properties:

Each TTR has a server-side alarm in it, which fires at predetermined intervals.
The interval varies for each TTR, from as low as <1 sec to several minutes.
If a player is standing in the room when the alarm fires, the player is teleported to another room (the 'destination room').
The destination room is fixed for each TTR (as far as I know)
For most TTRs, the player is given the name/desc/exits/contents of the destination room when teleported, as if the player had entered normally. However, this is not always the case - some TTRs teleport silently.
There is no message to the player that the teleport is occurring - he just sees the new room.

TTRs are used in a lot of places in the MUD, some deadly, some not. Examples would include a rickety bridge (it may collapse while you're standing on it), an ambush (player is suddenly moved to a similar-looking room, but full of mobs), falling off of things (a series of TTRs as you fall), etc.

I have several goals:

The Automapper should follow correctly when a teleport occurs.
The speedwalk code should be able to plot paths through (non-deadly) TTRs.
The Automapper should detect TTRs (when they fire) and create new rooms as necessary.
Speedwalks should pause and recompute if a TTR sucks me off my planned path as I pass through.
Ideally, I want the mapper to have some visual indication of which rooms are TTRs, and where their destinations are.

MUD Output

The quickest example for an outsider to find is from the mini-mud (the newbie intro area), which has a TTR a few rooms in to move you from the equipping area to the adventuring area. This output starts just after character creation (in case anyone logs in to test or check it out for themselves):

Posted: Tue Mar 11, 2008 10:33 pm

The way speedwalking works at the moment, you're going to have to set the timeout very high to get it to work. Otherwise, when it gets to the room and can't move any further, the walk will timeout.

If that's not your bag, you're going to have to write your own speedwalk engine - as long as there's a link between the TTR and its destination room, the mapper will find the route properly. Your script would need to split the path into two parts - one before the TTR and one after - and resume the walk once you've been teleported.

There are a couple of ways of knowing if you've been teleported or not. The easiest way is to check, when you receive the room description, if you've entered a command recently that would display a room description. Scry, directions, look, etc. If you have, the room it's seeing probably isn't caused by a TTR. You can extend this logic to detecting a TTR you haven't seen before, either by triggering on the rname tag or by making a trigger that fires only on room names, and then seeing if you've done something to display one.

Having done that, though, the mapper will only create a room in that direction if there's a direction in the queue, so if it turns out that a room name is from a teleport, you'll need to add the teleport direction from approach 3 to the queue before you tag the room name to the mapper. Then it'll create a new room.

Your second goal is the only one that can't be solved with this kind of solid TTR detection alone, so I wish you good luck with that one ;)

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Re: the timeout problem: Does the timeout still affect the speedwalker if one uses #PAUSE? In other words, if I pause the speedwalk (in my custom exit command), can I wait for a long time, then confirm and resume the speedwalk once the teleport hits?

I'll put a little thought into detecting whether I've issued a command-that-would-display-a-room recently. There are definitely some hairy problems to be solved - for instance, imagine the following situation: I'm exploring a new area, and I enter a step command, and I get a room, then immediately a prompt and another room. It's not at all clear to me how to distinguish (in code) between (a) I stepped into a room which teleported me, and (b) I teleported before the step was processed, then stepped out of the destination room.

The problem is further complicated by the fact that Mozart supports apparently unlimited type-ahead, AND lets you clear the type-ahead buffer, so maintaining a client-side mirror of the command queue is tricky at best...unless I just throttle all the commands on the client side. Hmm.

Follow-up question: It occurs to me that it may be best to have the code detect POTENTIAL TTRs, and queue them up for human persual. Then, if I confirm one, it will go ahead and add the link and/or room to the map. However, I believe that this would require some of the facilities of the zMapper COM server to work. Is that correct, or is there some way to make the regular mapper create a new link/room at will from a script? (Fang's trick of adding the direction to the queue first only works if the mapper position is still in the TTR, right?)

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I am going to suggest that by the time you are done with this you will have overridden nearly every part of the automapper. It is possible though. I once played on a mud that had elevators, where you pushed a button, waited, entered the elevator, pushed a button, waited, exitted the elevator. I did the mapping for it manually, since I only ever found 1. I did have speedwalking able to path through it and work, but I did it the hard way.

Fang is right that you need to establish knowing when you have issued a command that will give you room information that should be ignored. In order to do this right I would suggest using an MXP trigger for the rname element, and an #ONINPUT trigger for all the commands that will cause room information to be received. In your input trigger you set a variable to tell the MXP trigger that you issued the command. The variable would default to 0 or null. Next the MXP trigger checks this flag enables full capturing of the description if appropiate and clears the flag.

That roughly covers a capturing scheme. You will have to capture everything because in order to meet some of your goals you will have to issue #MAKEROOM, with some other room creation stuff. In order to have a visual display of the destination and that it is a teleport I would suggest using a diagonal direction. I suggest this because you mentioned that the mud only uses cardinal directions. Using the other direction type would make more sense, and codewise be about the same; however you would lose the visual aspect. If I remember correctly the mapper, in follow mode, will queue up a direction from the command portion of a #DIR setting even when that command is an alias. I would suggest testing that first, by setting the command of the northeast direction to 'test' instead of "ne|northeast", and creating the #ALIAS test {#SAY yes}. After you enter test at the command line with the mapper open and in follow mode, if it displays 'test' in the mappers queue then it will be easier to use that for following. I can explain how in another post.

Speedwalking...hrm...totally override it. I say this because working with the variable time on the teleports will be much harder with the #PAUSE, #OK, etc controls then it will be with a full script. There also is the possibility that you are on your way through a room and the timing is bad causing an undesired teleport. Such an instance requires the the path be recomputed, and since that requires that you hold the original %destroom until the walk finishes I would suggest it is easier to write your own slow walker. I will say that the script to handle a double-click on the map is a little bit tricky, but it can be captured and overridden.

For your second goal, simply using Do Not Enter is the easiest and likely best way.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Posted: Wed Mar 12, 2008 5:19 am

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I never quite got around to fully rewriting that script for CMud. I did update it significantly to get it working. There are some odd things in how CMud interprets a COM variable that caused it to look like a total failure when I first imported the script into CMud. The use of zMapper was needed for creating one way links, and offset rooms on overlap. Beyond that #MAKEROOM was the standard method for room creation.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Apprentice Joined: 08 Dec 2005 Posts: 108

The other option though even more harry is to open up the mapper database up using lua, and edit the database that way. I have a post in this forum where I open up the mapper database and modify the values of the cost to enter portals. The problem of doing it this way is that Zugg is going to be changing the mapper soon(hopefully) and the database format may change which will break the script.

Posted: Wed Mar 12, 2008 4:21 pm

No may about it - the database format is going to change, to use the same sql format that packages now use. Whether or not that means changes to the data structure remains to be seen, but it probably won't break your Lua script if that's not the case.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Ok...I've done some more investigation and some preliminary coding. Here is what I've learned.

Room Capture Types

I have identified a long list of things that can provoke a room to be displayed. Some are easy to distinguish, and some aren't. The primary indicators (aside from things that I've typed, of course) are messages displayed immediately ahead of the room name, or messages displayed immediately after all of the room contents. In other words, the sequence from the MUD appears to be:

pre-message (if any)
room name (with rname MXP tags)
room description
exits (with rexit MSP tags)
room contents (mobs and objects)
post-message (if any)
prompt

The types of room-captures I've identified are:

'look' - shows the current room, with no pre or post-message
'look <dir>' - shows the adjacent room (usually - some rooms are blocked), with a pre-message. The pre-message has no fixed text that can be used as a trigger. Most of them are of the form "You can travel to the <dir>", but others are "You see the Nevrast Inn", "The dark forest stretches into the gloom", etc. However, all examples that I have seen are either the standard message, or are prefixed by three spaces (?!?), so I'll try to trigger on that to identify this category.
Timed teleports - the subject of this discussion. Shows some other room (possibly connected to the current room), with no pre or post-message.
Normal movement - shows a connected room. Sometimes shows a pre or post-message. SHOULD have the movement direction as %nextdir().
Movement through a gate (created by 'gate' spell) - shows whatever room you move into (usually a long distance away - the spell basically creates a temporary non-standard exit link between two rooms). Fortunately, there is a unique pre-message for movement through a gate. In addition, it is easy to identify the existence of a gate in the room description whenever one is present, and there are unique messages when gates appear and disappear.
Looking through a gate - similar to the 'look <dir>' case above, but with a unique pre-message.
Long-distance scrying ('wizard-eye') - I know this can occur, but I do not have a character that can cast it ATM, so I don't have a capture.
Fleeing - Shows whatever room you flee into, with a unique POST message ("You flee head over heels"), that does not include the direction in which you fled.
Following/shadowing another character - shows the room you move into, with a unique pre-message ('You follow <char>'), but does not tell you the direction in which you moved (only the character you followed). There may have been a message earlier showing the followed character leaving, or not, depending on his sneak and my spot skill levels.
Summon - When some OTHER character 'summon's me, I'll get the room I appear in, with a unique pre-message.
Other magical transport (e.g. word-of-recall, astral-walk) - Shows the room you arrive in. The only pre-message is the standard 'Ok.' for spell success.

Here is some sample output showing looks, scries, some gate travel, and a flee, for comparison. This is off one of my real characters, so the prompt looks different than the previous example (and ends in a newline, FYI, so my commands always appear on an otherwise blank line).

Enchanter Joined: 09 Sep 2007 Posts: 605

Posted: Thu Mar 13, 2008 4:26 pm

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Sorry for the delay. Now that I seem to have gotten my zone-crossing crashes resolved, I'll be back to this project in the next day or two. (Gotta get through a business trip first.)

Next up is the code to figure out which room I've wound up in, and if it's one I already have on my map. That code will be usable for all sorts of magical transportation, flees, follows, and, of course, TTRs.

Then I can finally get down to TTR detection and processing.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

For determining what room you are in you could probably use the queries from my Toolbox package. Those sorts of things were mostly what I was aiming at making the queries for. Having an excellent example of how to make use of them would be helpful. Also I do still plan on writing a fair bit more for the flee type logic.

I am always open to suggestions for improvement in the toolbox, I want it to be the most downloaded package in the library.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Will do. I have yet to make use of the Package Library, so it's good to have a reason to learn about it. I also intend to publish my Mozart stuff eventually, so I'm sure that I (and the lurkers) can pick up some good tips on package construction, too.