Dynamic player teleportation

[Ice Cream Jonsey]

I was hoping to write a routine that would allow me to do the following, as I test my game:

>teleport arcaderoom01

(Hugo performs a MovePlayer(arcaderoom01))

You are now in the first arcade room! Blah blah!


... Has anyone tried to do something like this? I couldn't get it to work in a single line, so I tried this:

>teleport
Where do you want to go? >

>arcaderoom01

... but doing it that way, Hugo seems to not understand that I have put a location in, but instead treats it as text.

Has anyone else written a test routine that accomplishes what I am looking for?

[Merk]

There may be a couple different problems here. One is, when you set up grammar defs, it's expecting the words you type after the verb to be nouns or adjectives of objects -- not object names. So something like this is going to be problematic:

verb "teleport"
* object DoTeleport

Even if DoTeleport checks to make sure object is a room and gives an error otherwise, it's probably going to tell you that you haven't encountered that yet.

There is a way to specify object names in the syntax of a verb, but I think that's going to pose the same problem. And you probably don't want to set the "known" flag on all rooms from the start (messes up verbose descriptions, for instance). And even if you did, the room would have to be "visible" (in scope) for that to work anyway.

So... what you have to do is use the "string" identifier in the verb def, and then test against all possible rooms. If there's an easier way (and probably there is -- I'd just have to think longer) I'm not aware.

Download the source for Trading Punches or Swordsman and take the IsEqual function out of utils.hug. This basically lets you test up to 5 strings against a target and see if any match. It's overkill for what you need, and you *could* write a down-and-dirty IsEqual function that just tests one. Basically you use the string() function to turn dictionary words into strings, and then test two using the StringEqual() function.

So your grammar def would look like this:

Code: Select all

xverb "teleport"
* string   DoTeleport

And DoTeleport would look like this:

Code: Select all

routine DoTeleport
{
    local newroom = nothing
    if IsEqual(parse$,"deck") {
        newroom = deck
    } elseif IsEqual(parse$,"loft") {
        newroom = loft
    }
    if (newroom ~= nothing) {
        "You teleport to..."
        MovePlayer(newroom)
    } else {
        "You can't teleport to there."
    }
    return true
}

The problem here is that all the room names would have to be in quotes. Players would have to type:

>teleport "loft"

There are other, trickier ways to handle it though. You could define the verb as "* anything" and then capture for it in PreParse (you'd need to look at the parsing portion of the Hugo library to see how to handle that). That would let you get around the problem of the room not being in scope. You could even customize the error handling and check for this particular verbroutine there. There is a *lot* you can do by messing around with the parsing.

[Ice Cream Jonsey]

You are the MAN, Merk!! Thank you very much. The quotes thing isn't a big deal, as I'd only use the verb for testing, but now you have me thinking of a future game built around letting the player teleport to any room in the map. Hmmm. But yes, thank you! :)


Robb

[Merk]

Cool. Then I won't worry about seeing what it would take to add a library hack. I think it would allow the verb to work with real room names and no quotes (like your original idea), but it would take a little time to figure out. It might be something to think about if you need that kind of teleportation available to players.

[Roody_Yogurt]

That's a pretty cool solution, Merk.

Also, since I thought the initial question was about setting up a temporary system (not for the final release of the game), it might be worth nothing how $mp <obj> in the debugger will move the player to whatever room.

I definitely don't use the debugger as much as I should and have only gotten the hang of like one or two functions (and had even forgotten whether or not there was a MovePlayer command before I looked just now), but it's always there for us to use it.

(I hope everybody doesn't mind that I'm digging up these old threads)

[Ice Cream Jonsey]

Oh wow, I had no idea you could do that in the debugger. Thanks for bumping this. And for the info.

[Roody_Yogurt]

I took a closer look at this today and learned some things. What I mentioned is not so much debugger stuff. It's actually called HugoFix, and it's a library extension. I started a HxE page about it here.

So yeah, once you compile it with that, those commands will work in any normal Hugo executable. Also, like I mention, it seems you're better off referring to rooms by object number.

The HugoFix move-stuff-around capabilities seem way better than what's available in the debugger itself. The Windows debugger doesn't seem to handle moving the player at all. The debugger is nice for watching values change and slowing things down to step by step and stuff, but it seems like HugoFix is where it's at for getting around all fast.

[Ice Cream Jonsey]

Now that I understand what this does, I am "this" close to pronouncing this the greatest addition to the Hugo developer's toolkit since the debugger itself.

I am going to compile code with it next chance I get and test this theory.

[Bainespal]

I took a closer look at this today and learned some things. What I mentioned is not so much debugger stuff. It's actually called HugoFix, and it's a library extension. I started a HxE page about it here.

So yeah, once you compile it with that, those commands will work in any normal Hugo executable. Also, like I mention, it seems you're better off referring to rooms by object number.

The HugoFix move-stuff-around capabilities seem way better than what's available in the debugger itself. The Windows debugger doesn't seem to handle moving the player at all. The debugger is nice for watching values change and slowing things down to step by step and stuff, but it seems like HugoFix is where it's at for getting around all fast.

Thanks for doing the research! I'm pretty sure I once uncommented "!#set HUGOFIX" in the shell code for one of my projects and experimented with the debug commands a little, but they seemed pretty obscured, and I wasn't motivated enough to figure them out. Clarifying this under-documented feature of the Hugo system is a great contribution. Thanks to your documentation, I just used HugoFix to help debug a fuse in my current project. :-)

P.S. -- I've moved the player object with the Windows debugger before, but it causes problems because it doesn't set the variables that should be changed when the player moves. You have to manually select a new parent for the player object and then manually change the value of location to the new parent in order to move the player at all in the Debugger, and then some things still seemed weird to me, which I suspect were results of other variables unknown to me still not being right. HugoFix does it much more elegantly.

[Roody_Yogurt]

I'll write a Hugo By Example page on the debugger itself eventually, but yeah, it's mainly useful for watching the values of your own variables or having it pause during routines that are giving you trouble and going through your game line by line to figure out why something isn't being set correctly.

[Tdarcos]

I was hoping to write a routine that would allow me to do the following, as I test my game:

>teleport arcaderoom01
... Has anyone tried to do something like this? I couldn't get it to work in a single line, so I tried this:

>teleport
Where do you want to go? >

>arcaderoom01

... but doing it that way, Hugo seems to not understand that I have put a location in, but instead treats it as text.

Has anyone else written a test routine that accomplishes what I am looking for?

I have. Download the file http://in-the-matter-of/teleport.zip, it's a full, short game with three demonstration teleporter pads. One goes to any room in the game, one only goes to teleporters (incoming), one only goes to teleporter pads, and the other goes to rooms that are teleporters or teleporter pads. (A room can be either or both.)

It shows you a list and asks you to type in the number of the room. Now it would have been possible to create a list of rooms and create that as an object, but I wanted to demonstrate being able to teleport anywhere as being able to accept a number as a command.

I am also going to announce this as a separate game and see what people think of it.

[Ice Cream Jonsey]

Can you teleport a man and a fly at the same time??!

[Tdarcos]

Can you teleport a man and a fly at the same time??!

If there's a fly in the game, yes. I'll do a much shorter (fewer rooms one as a test.)

"When I first saw the (Vincent Price version of) The Fly and I saw the little fly, trapped in the spider's web, crying out, `Heeeeeelllllp meeeee! Hellllp meeeeee!` I knew that for the rest of my life I would remember that scene."
- Paul Robinson, 1987

[Tdarcos]

I was hoping to write a routine that would allow me to do the following, as I test my game:

>teleport arcaderoom01

Jonsey, you never did say if you looked at my game and (if you did) what you thought of the idea?

I had to add a minor feature (a new property) to prevent listing "pseudo" rooms such as the class definition of a room. I also added two attributes, one for a teleporter (incoming only) and a teleport pad (outgoing only), and demonstrated all four flavors of teleporter (any room, to teleporters only, to teleporter pads only, or to either). I also allow the program to accept a number and translate it to the correct room object (which almost certainly will not be the same number.)

It was a first try, and with a tiny bit of work I think I can develop it the way you wanted to do it (where the user can type in "teleport" followed by the name of the room), which I am going to do in a subsequent game.