go2 in the rift

[DaCapn]

I'm just wondering what exactly has changed that causes go2 to behave weird in those odd unmapped rooms in the Rift? When run from those locations, go2 used to have odd failures (which I janked my way around one way or another with my scripts) but now it peers around and sets descriptions on and other odd things. It has a tendency to lag (I'm assuming things are being hidden by hooks and so on) and, according to others, idle in rooms with voids at times.

First: What's weird about those rooms? Do the descriptions change? I never have descriptions on so I wouldn't know. Second: Is there a better way to handle these rooms? Third: Is there anything I can do towards them being handled better?

Just as a preemptive point if the room descriptions change: Isn't there some unique (Simu-generated) room identifier that gets passed through the stream for each room? Would it be possible to use that in the map database? Is that too much of an overhaul? Or is that identifier not what I think it is?

This is an example of the behavior on plane 1. I just did unhide followed by go2 to move past some of those unmapped rooms.


>unhide
You do not believe anyone noticed you slip out of hiding.
>--- Lich: go2 active.
[go2: ETA: 0:00:01 (5 rooms to move through)]
[go2]>east
[go2]>east
[The Rift - 2594]
Obvious exits: east, west
>[go2]>east
[(script unknown)]>set description on
[(script unknown)]>peer east
[uberbarwiz]>set description on
[uberbarwiz]>peer east
[narost]>set description on
[narost]>peer east
[go2: reducing typeahead setting...]
[go2]>set description on
[go2]>peer east
[The Rift - 2596]
Obvious exits: east, west
>[(script unknown)]>set description on
[(script unknown)]>peer east
[uberbarwiz]>set description on
[narost]>set description on
[uberbarwiz]>peer east
[narost]>peer east
[go2]>set description on
[go2]>peer east
[The Rift - 2597]
Obvious exits: east, west
p>You will now see room descriptions.
p>[go2]>set description on
[(script unknown)]>set description on
[uberbarwiz]>set description on
[narost]>set description on
[go2]>peer east
[(script unknown)]>peer east
[uberbarwiz]>peer east
[narost]>peer east
[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You will now see room descriptions.
p>You will now see room descriptions.
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You will now see room descriptions.
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You will now see room descriptions.
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You will now see room descriptions.
p>You will now see room descriptions.
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You will now see room descriptions.
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You will now see room descriptions.
p>Sorry, you may only type ahead 2 commands.
p>You will now see room descriptions.
p>You will now see room descriptions.
p>You will now see room descriptions.
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>You peer east and see ...

[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>[go2: restarting script...]
[go2: ETA: 0:00:00 (2 rooms to move through)]
[go2]>east
[The Rift - 2597]
A throne sits in the middle of an open field. Dead and dried flower bushes grow over it, lacing thistles through the hair and bones of the half-rotted woman sitting within it. Enough flesh remains to identify her gender, but the rest is gone, devoured by the plants and elements. You also see a sturdy wooden door.
Obvious paths: east, west
p>[go2]>east
[The Rift - 2598]
Despair and desolation hang heavy in the air over the small plain before you. Off in the distance, near the coast, what was once a small city lies smouldering in ruins. The thick, black smoke from the razed hamlet lies heavy near the building tops, as if the weight of the carnage held it fast. A huge stack of bodies is piled near the western gate, some of which almost look familiar.
Obvious paths: southeast, west
p>[go2: travel time: 0:00:10]
--- Lich: go2 has exited.

[DaCapn]

Okay, so I just went to the rooms in question to look at the waytos and neither the rooms in question nor the border rooms have "peer" anywhere in the wayto procs. But I just noticed that passing though the plane 1 rooms are mapped to plane 3 rooms in narost and once you enter those rooms, you get the peering situation. Also, previously, there were rooms in plane 1 which weren't mapped in narost but now they are.

So, it doesn't seem like this is really related to the map database (or at the very least, isn't solely due to the map database).

[Tgo01]

I was wondering why room description were turning on sometimes for me while in the Rift, although that only seems to happen while I'm running through plane 1. On plane 3 however I do notice sometimes my script gets stuck in one of those unmarked rooms and just hangs.

[Tillmen]

The short answer is... kill rnum.

rnum uses a DownstreamHook to display the current room number. So every time a game line comes in from Simu, rnum runs its code on this game line, and no other game lines can come in until it finishes. The code is using Room.current, which in those duplicate rooms is going to peer into the next room and check the new game lines to figure out which room you're in. This isn't going work, because no game lines are coming in. The game apparently freezes until the peer command times out. I plan on fixing this, and by fixing this I mean breaking rnum so it shows the wrong room number.

There is no unique (Simu-generated) room identifier that gets passed through the stream for each room. If there was, I would have jumped on that years ago.

The trigger to peer is in the room tags. When possible, it will peer and check the obvious exits. There are a few duplicate rooms in the rift where every adjacent room also has identical obvious exits for both duplicate rooms. For those, it has to turn on the room description.

I never understood the popularity of rnum. Even when it's working, it's going to add a small amount of lag by design every time you move so you can see a number you don't even care about 99% of the time. Setting rnum as a fav is going to make the game appear to freeze while it loads the map database every time you log in, which I think I remember other people complaining about.

[Tgo01]

I don't use rnum though :(

Although come to think of it I haven't noticed my script getting stuck in plane 3 in a while so maybe you fixed that problem already or it was just a fluke for a while there.

Just yesterday my room descriptions turned on by themselves though, know what else could be causing that? It's not a huge burden or anything, just curious.

[Tillmen]

So.. I'm testing my fix, and does rnum always show the wrong room number? It seems to just show the room number of the last room you were in, and that's without any duplicate rooms or fixing or peering or anything.

[Tillmen]

I don't use rnum though :(

Although come to think of it I haven't noticed my script getting stuck in plane 3 in a while so maybe you fixed that problem already or it was just a fluke for a while there.

Just yesterday my room descriptions turned on by themselves though, know what else could be causing that? It's not a huge burden or anything, just curious.

The new system of peering and whatnot in duplicate rooms is probably what's keeping you from getting stuck. That's part of the reason I added it. The old way of dealing with these rooms was just to move you around them. Getting rifted or climbing a thread and landing in a random room has a chance of dropping you in one of these duplicate rooms, which would have just left your scripts stuck with the old method.

Your descriptions turning on are from the new way of dealing with duplicate rooms. They'll only turn on in some of the duplicate rooms, and only if some script is trying to get the room number. So starting go2 in one of those rooms or having narost running will cause it, but just running past the rooms won't.

[Tgo01]

The new system of peering and whatnot in duplicate rooms is probably what's keeping you from getting stuck. That's part of the reason I added it. The old way of dealing with these rooms was just to move you around them. Getting rifted or climbing a thread and landing in a random room has a chance of dropping you in one of these duplicate rooms, which would have just left your scripts stuck with the old method.

Your descriptions turning on are from the new way of dealing with duplicate rooms. They'll only turn on in some of the duplicate rooms, and only if some script is trying to get the room number. So starting go2 in one of those rooms or having narost running will cause it, but just running past the rooms won't.

Oh my bad, I thought you were saying rnum was causing that. In that case thanks for fixing the hanging problems I was encountering.

[DaCapn]

So when Room.current (or I suppose Map.current) tries to match the current room with a map in the database, it comes up with some kind of ambiguous result and resorts to some fall-back routines. One of those routines checks the map database for the existence of peer tags in that location (which the rift map has). Having found those tags, it does the peer routine to try to allow Room.current to completely identify your current room. More-or-less-correct?

This behavior should also result from narost, correct?

[DaCapn]

So.. I'm testing my fix, and does rnum always show the wrong room number? It seems to just show the room number of the last room you were in, and that's without any duplicate rooms or fixing or peering or anything.

Yeah, that's what rnum tends to do.

[Tillmen]

Apparently rnum was getting the room number before the room_count went up, which caused it to get the last room number if it was known. That's fixed, and rnum should show 4 or something instead of lagging in rooms that need a peer in Lich 4.4.11.

[Tillmen]

So when Room.current (or I suppose Map.current) tries to match the current room with a map in the database, it comes up with some kind of ambiguous result and resorts to some fall-back routines. One of those routines checks the map database for the existence of peer tags in that location (which the rift map has). Having found those tags, it does the peer routine to try to allow Room.current to completely identify your current room. More-or-less-correct?

This behavior should also result from narost, correct?

That's more or less right. Room.current looks for a matching room in order of room number. It comes up with a room, but doesn't know it's ambiguous yet, and checks the tags for a peer command anyway. If there's no peer command, that's your room. If there is and the peer command matches, that's your room. If there's a peer command and it doesn't match, it continues looking for matching rooms in order. That's why the duplicate room with a higher id doesn't need a peer command in the tags.

Narost or any script that does a Room.current will cause this. If more than once script does a Room.current, or even the same script does it multiple times without you changing rooms, the lookup and peer doesn't happen again. The results of the last Room.current is saved, and unless room_count goes up (you change rooms), it just gives you the saved value.

[DaCapn]

Thanks a lot Tillmen. Just tested it out. As you said, rnum will show a room number of 4 and it won't be caught waiting in the hook. Running both narost and rnum will do the peer routine twice (Room.current is being called twice so nothing really can be done here). I might duplicate Room.current and create a less robust function just for persistent display purposes (it looks like the peering routine is actually the only exception, though).

[poloneus]

I'm not sure I understood all of that, but I had killed rnum when it was suggested to me last weekend and I was still having the issue. This was manually moving too, without using go2 or having narost active.

[Tillmen]

Thanks a lot Tillmen. Just tested it out. As you said, rnum will show a room number of 4 and it won't be caught waiting in the hook. Running both narost and rnum will do the peer routine twice (Room.current is being called twice so nothing really can be done here). I might duplicate Room.current and create a less robust function just for persistent display purposes (it looks like the peering routine is actually the only exception, though).

It really shouldn't be peering twice. Even though Room.current it's being called by both rnum and narost, the rnum call won't cause it to peer. Even if there were another script calling Room.current, it's not supposed to peer twice. I suppose it might if both calls were made before either call completed. Hopefully it's peering twice because you moved through two different rooms. I know there's a spot where there's three rooms in a row that need to peer.

For the less robust function, you'd also have to take out the location check, which it does if room.check_location is true. And if you do edit rnum or create a similar script, please check if Room.current is nil instead of just blindly getting the id of nil and displaying it as a room number. I hate that everyone thinks 4 is some kind of error value or something.

[Tillmen]

I'm not sure I understood all of that, but I had killed rnum when it was suggested to me last weekend and I was still having the issue. This was manually moving too, without using go2 or having narost active.

That's probably a different issue then. What exactly is happening?

[poloneus]

Same issue. The seemingly random peering. I can see how it may have been the unmapped rooms, but I had killed rnum and I was definitely moving through manually while foraging. I think the pausing by voids was coincidence because I did not have that experience. The voids were probably in the unmapped rooms when it paused for people. I will likely be back tonight and if it's still happening I'll try to get more specifics.

[Tillmen]

Same issue. The seemingly random peering. I can see how it may have been the unmapped rooms, but I had killed rnum and I was definitely moving through manually while foraging. I think the pausing by voids was coincidence because I did not have that experience. The voids were probably in the unmapped rooms when it paused for people. I will likely be back tonight and if it's still happening I'll try to get more specifics.

From what you said, I don't see any issue. The seemingly random peering is caused by some script trying to figure out what room you're in, when peering is the only way to tell the difference between your current room and some other room in the database. This can be cause by narost, uberbar, or other random scripts if they want to know what room you're in. I don't squelch the peer command, so it should tell you exactly which script is doing it. If it's making the game appear to freeze when it peers, then it's the same issue.