Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Majestic-12, Yahoo!, Google, DotBot

Members: 0
Guests: 12
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » Virtual rooms causing mobs to...
Forum Rules | Mark all | Recent Posts

Virtual rooms causing mobs to end up in limbo
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Jan 18, 2007, 10:46 am   Last edited Nov 25, 2007, 6:31 pm by Samson
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

This fix:
http://www.smaugmuds.org/index.php?a=topic&t=2382

Had an unintended consequence. This seems to have cropped up mostly with SWR, so I'm posting it here. Apparently when mobs walk around in virtual rooms, they get transported to Limbo instead of staying where they belong. This is rather annoying to say the least. The only area in this distro affected by it is coruscant_streets. A quick look through shows me that room #301 and #310 have a linkage with each other that spans a virtual distance of 6 spaces. Same thing with #301 and #304, and again between #301 and #302. I'm sure there's probably plenty of other occurrences.

Virtual rooms are apparently given vnums, and are stuffed into a virtual room hash which is separate from the normal room index hash. This is done in generate_exit() in act_move.c. It may be as simple as writing up a get_vir_index() function to check and see if someone is standing in a valid virtual room before deciding in char_to_room that the destination doesn't exist and bouncing them to limbo.

So before I whip that up, does anyone else have any other ideas that would work?
       
Post is unread #2 Jan 20, 2007, 12:00 am
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

I've got an idea. Hack virtual rooms out. This is just another great example of why virtual rooms are just stupid. How much less memory do they use than normal rooms, if any? I haven't really looked at it in a while. I know I've encountered more than a few problems because of virtual rooms, such as about 500 mobiles loading up in limbo on a hotboot. It seems to me that making a command that will clone an entire room and give it a new vnum would kick the hell out of using something that's little more than a hack to accomplish it half-assedly. Just me, though.
       
Post is unread #3 Jan 20, 2007, 10:14 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Much as I would love to hack out and remove the virtual room code, it needs to stay because there are people who are probably relying on it for one thing or another. In its current state it's a hackish mess. But I'm sure there's some kind of potential hidden beneath the outer shell that could be turned into something really cool.
       
Post is unread #4 Jan 3, 2008, 10:44 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Virtual rooms aren't meant to save anything in terms of memory, they're meant to provide an alternative to hard-coding a zillion rooms which all say "You are standing in a grassy field. Grass extends as far as you can see in all directions. You are likely to be tickled by a grue."

Now, yes, you can use tokens in the room descriptions to provide generic, yet quasi-random descriptions... but you'd still end up cloning lots of rooms and linking the exits and whatnot. You can use rgrid (diggrid? I forget) for some of that, I suppose.

The use I always had for virtual rooms was to have a generator function which would pull terrain data from an image file (like the overland system from AFK), but instead of putting everyone in one "room" with a modified interface, just create virtual rooms as people (or mobs) wander around. The driver can clean them up if they've been idle for X minutes (IE: no living things in them), and the user can't tell that they aren't real rooms unless they drop breadcrumbs and even then... some muds wipe room contents on reset.

They're also very handy for generating a semi-persistent maze. That is, it seems random (and it is), but if another player comes upon it, they'll see the same maze with the same route... as long as they don't take too long. For that kind of use, you'd want to remove the rooms only when nobody is in that zone (probably).

Of course, I'm not saying THIS particular implementation of virtual rooms is worth keeping. I haven't looked at that code yet... just that the concept is very useful.
       
Post is unread #5 Jan 12, 2008, 1:01 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

It's been awhile since this subject was originally raised, the usefulness of the code aside, it looks like there's a further potential problem that needs to get covered. When a virtual room is generated it needs a vnum, just like any other room. However the generate_exit() function does not verify if the chosen vnum the system comes up with has been used or not. This can be a serious problem because the virtual room code assumes that vnums are still a short, not an int.

Later, when the function to clean up virtual rooms is called, existing real rooms with vnums over 32767 can get wiped out as the code again fails to verify if the vnum exists in the main room hash.

I don't know what the best way to solve this is, but it's yet another strike against the current implementation. It also makes me glad I dropped this code from AFKMud instead of ignoring it. But it's still alive and well in FUSS so it will need to get fixed.
       
Post is unread #6 Jan 13, 2008, 12:46 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

As a (hopefully) quick fix, it seems that generate_exit() could be changed to generate vnums > 1 billion and also verify that they aren't already hashed. I don't particularly like just moving the fencepost from 32K to 1B, but I doubt many people have vnums that go that high in production.

I could also see adding another room hash. It looks like we're currently storing rooms in a linked list (several, actually), so it wouldn't be that hard to keep a seperate hash array for virtual rooms. It would work exactly the same way, except every so often the rooms in it would be removed from memory if empty. It would require a virtual bit which the OLC system would need to know about, and things which normally use vnums instead of actual room index pointers would have to look in each list.

Something to ponder anyways.
       
Post is unread #7 Jan 13, 2008, 1:04 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Quixadhal said:

but I doubt many people have vnums that go that high in production

We do, although we use a dotted vnum notation, e.g. 0.1 and 1.1 which mean 1 and 32K+1 respectively.

I think it makes more sense to make virtual rooms use a separate vnum system, myself. As implemented, they're different beasts, and as we see it's dangerous to treat them as the same.
       
Post is unread #8 Jan 13, 2008, 10:58 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

I meant higher than 1 billion, although the dotted notation would work fine for either.

Although it wouldn't be appropriate for everyone, and might limit some of the things that could be done with virtual rooms, the way I was considering solving this little puzzle was to add coordinates to the room structure and the exit structure.

The idea being that if an exit points to a vnum, you treat it as a normal exit... if that vnum doesn't exist, the exit is broken and fails just like they do now. If the exit has no vnum, but does have coordinates, you try to look up the room via coordinates. If that works, business as usual. If that fails, you call your virtual room handler and have it generate a room, if possible, or it can also fail and send you to the same place as an incorrect vnum would take you (nowhere, with log messages spewed).

One could either add a parallel room index for virtual rooms, as I described earlier, or if you really wanted to, you could do away with vnums entirely and just use room coordinates -- they serve the same purpose.

The upside of that would be anywhere in the code which currently looks up a vnum would now look up a coordinate, and it would be more obvious which rooms were adjacent to one another while building (or for area affect spells or shouts).

The downside is that you need to use 4 dimensions unless your entire world is one connected map, and non-euclidean maps would present some difficulties. IE: N,E,S,W would have to take you to the same room using coordinates, but with standard vnum exits, that isn't the case.

Note that coordinates don't imply distance... they can be used that way IF you declare all your rooms to be the same physical size, but of themselves, they are just a way of enumerating rooms by relative position.

Like I said, switching to just coordinates would probably be too radical a change for Smaug, but adding them and keeping a second vnum index wouldn't be too bad -- and if you never use virtual rooms, and don't fill in the coordinate fields, no harm no foul.
       
Post is unread #9 Jan 13, 2008, 7:58 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Quixadhal said:

and non-euclidean maps would present some difficulties

I think this here is enough to make the solution basically unworkable. Even if the vast majority of the world is Euclidean -- and it probably isn't -- all it takes is one or two instances to break the whole model. :(

Quixadhal said:

Note that coordinates don't imply distance... they can be used that way IF you declare all your rooms to be the same physical size, but of themselves, they are just a way of enumerating rooms by relative position.

If coordinates don't imply distance then you're no longer really working in Euclidean space. Consider the following picture:

o-o-o-o
|     |
o-ooo-o

If you allow size, this is still Euclidean. But if you disallow size, this isn't Euclidean anymore. But if you allow for rooms to have different sizes, and you force Euclidean, but your coordinates don't imply size, something very strange is going on in the above picture.
       
Post is unread #10 Jan 13, 2008, 9:26 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

DavidHaley said:


If coordinates don't imply distance then you're no longer really working in Euclidean space. Consider the following picture:

o-o-o-o
|     |
o-ooo-o

If you allow size, this is still Euclidean. But if you disallow size, this isn't Euclidean anymore. But if you allow for rooms to have different sizes, and you force Euclidean, but your coordinates don't imply size, something very strange is going on in the above picture.


I agree. If you don't imply size, the above is not Euclidean, because the coordinates only map node locations, not physical distances.

The thing is, for a room based mud, size isn't what matters. The number of nodes traversed is what determines how Euclidean your map is going to be. In your example, you could factor in room sizes to the coordinate system and have it work out for the lookups, but the graph won't be balanced (IE; NEESWW won't return you to the southwest node), and two coordinates would share a common room.

You might also have a graph that IS euclidean, but the room descriptions of the northern branch describe you walking through a back alley, while the southern branch has you crossing miles of plains to get to the other city gate. Yet, if you travel a symmetrical path, you still arrive where you started. Thus:

 o---o--oo--ooo
 |      oo  ooo
 |       |  ooo
 |       |   |
 |       |   |
ooo--o---o--ooo
ooo         ooo
ooo         ooo


NEESWW works. The physical sizes of the rooms vary, but the linkage of the nodes is symmetrical and thus Euclidean. That's because the physical sizes are only in the mind of the reader. The game just sees a room as a container object which has links to other containers.

If you want to allow non-Euclidean mappings, it can be done, but that area has to be exempt from the coordinate system. So, in the hybrid system I was suggesting, it would be ok... in the coordinate-only system, it wouldn't since you'd either have overlap (the same coordinate mapping to two rooms), or gaps (coordinates which had no room). The latter isn't a deal breaker, but having holes in the world is not exactly logical.

For myself, I think using coordinates is sufficient for 95% of the things we do in game world creation. I think it would be perfectly acceptable to require that virtual rooms follow a Euclidean layout, and I suspect what most people would use them for would also tend to have the perceived "size" of adjacent rooms be the same (IE: a virtual grid of grassland, or a virtual street... they might be different scales, but all the street nodes would typically be similar in size to each other).

For those places we WANT things to be "wrong", we use the vnum system and leave the coordinates blank. That way, we can build our clever mazes or shifting tunnels or magical portals, and as an added bonus, mapping could be disabled there since it won't quite make sense anyways.

In any case, it's a ways away from the expectations of a "bug fixed Smaug", so this is probably best left to another thread for the future. If I do muck about with some code for this, I'll be sure to toss it up here somewhere (assuming it doesn't make the world explode).
       
Post is unread #11 Jan 14, 2008, 10:24 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Quixadhal said:

The physical sizes of the rooms vary, but the linkage of the nodes is symmetrical and thus Euclidean.

Well, yes, but that only works for local maps. It also breaks the size of exits. Basically, something breaks somewhere as soon as you allow stretching of space.

Quixadhal said:

The latter isn't a deal breaker, but having holes in the world is not exactly logical.

Actually holes don't bother me at all; it makes a lot of sense to have some spaces marked as 'unreachable' for whatever reason -- if anything because you didn't feel like making anything there.

Quixadhal said:

For myself, I think using coordinates is sufficient for 95% of the things we do in game world creation. (...) (IE: a virtual grid of grassland, or a virtual street... they might be different scales, but all the street nodes would typically be similar in size to each other)

You should see the areas on my game, then. :smile: And to be honest, even in otherwise sensible areas, all it takes is a few closets, a few stores hanging off the main street, a few rooms inside a building for the whole grid system to fail. There's a good example: a city in which you enter buildings; does the entire city coordinate system have to stretch around every tiny house's room system?

You mentioned scale which is interesting since these breakdowns occur when the scale changes. The scale of city streets isn't the same as the scale of the building interiors, and yet your coordinate system has to do something sensible when you go between them. Similarly for leaving the open grasslands and entering the city. Is the MUD meant to have one room of grassland surrounding the city for every single room on the inside? The way rooms are handled now that's almost unmanageable. :thinking:
       
Post is unread #12 Jan 14, 2008, 11:12 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

DavidHaley said:

You mentioned scale which is interesting since these breakdowns occur when the scale changes. The scale of city streets isn't the same as the scale of the building interiors, and yet your coordinate system has to do something sensible when you go between them. Similarly for leaving the open grasslands and entering the city. Is the MUD meant to have one room of grassland surrounding the city for every single room on the inside? The way rooms are handled now that's almost unmanageable. :thinking:


It would certainly annoy the players to have to walk around hundreds of rooms of grassland to get from one side of the city to the other.

If the system used a change of scale, it would use additional dimensions of the coordinate system. This would work exactly the same for disconnected parts of the world. An example:

You have a starting village which has a road passing through the centre from north to south. Let's say you describe the village in such a way that it seems about 300 yards from one side to the other. The actual size doesn't matter, but that's the perception. You give the center of town a coordinate of (1,0,0,0) and build rooms for the town layout. The road edges happen to fall at (1,0,15,0) and (1,0,-12,0). When a player exits the town via the north road, the room sector on the edge of town would have (at least) two exits. The south exit would point to (1,0,14,0), and the north exit would point to (0,0,2,0).

Leaving town, you end up on the road, but now the descriptions tend to lend themselves towards each step being more like 100 yards instead of the roughly 10 the town interior used. So, when designing the space of the world the town occupied, you figured maybe it took 3 steps to go around it. Thus, if the center of town was at (0,0,0,0),you'd actually map the terrain for (0,-2,2,0) .. (0,2,-2,0) so that the descriptions showed the town, and the exits either weren't there (maybe they have a wall), or map into the interior coordinates at a reasonable point (0,0,2,0) -> (1,0,15,0).

From the outside, the town takes up a 3x3 grid (doesn't have to be a grid, but that's simple). Asking for coordinate (0,0,0,0) would either fail (simple) or you *could* make an association of the coordinate systems (tricky) to give you a random spot within the interior system.

That's what I mean by the physical size doesn't need to matter, just the number of nodes. If your descriptions changes from needing 3 rooms to walk around the city to needing 5 rooms, it wouldn't have any impact on the interior coordinates. The city wouldn't suddenly become larger or smaller, but it would take up more nodes. Likewise, expanding the interior system wouldn't HAVE to increase the number of nodes used outside. If you had an "enter" or "leave" direction, you could choose to just have a single room.

For that matter, there's nothing forcing you to make the external shape anything like the internal. You might describe a river which, when entered, becomes a maze of underwater caverns stretching in all directions... the exits inside the maze might be widely scattered, yet the external linkage is a thin ribbon. You could go the other way too... define a large chunk of the coordinate set so all the edges point to a single internal room.

It does make me think though, that it might be useful for a room to know if there is a "parent" coordinate it might be known as. Mostly for things like "teleport", which might want to allow travel between cities. Hmmm.
       
Post is unread #13 Jan 14, 2008, 1:00 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

A system of several levels of scale is pretty interesting and it was the idea I came up with a while ago. Still, unfortunately, there are problems, again at the transition points. In some cases, like a walled city or a castle, it's very obvious where you transition: the gates, and there aren't other ways in and out. But then you end up with grasslands surrounding a village, and suddenly you have odd things happening:

ooo-o-o-o
ooo | | |
ooo-o-o-o

If you are in the village (small rooms) it's obvious what happens if you go west; you end up in the big grassland room and a change of scale occurs. But what if you're in the grasslands and go east? Which room is the designated entry room? And if you pick one as the designated entrance, does potential for abuse (or "instatravel";) arise by letting people game the scale system by hopping in between scales?

Sometimes I wonder if the room system is fundamentally flawed if you want interesting and rich positional data. Some games have pure coordinate systems without rooms, or where a room is nothing more than a description associated with a surface area of the more fundamental area system. I've pretty much come to the conclusion that the room model is not appropriate for too many things, and chances are that when I eventually get around to implementing something it will not have rooms, at least not in the traditional sense.
       
Post is unread #14 Sep 25, 2008, 4:49 am
Go to the top of the page
Go to the bottom of the page

Igabod
Fledgling
GroupMembers
Posts40
JoinedSep 25, 2008

so has a solution for this problem been found yet or is it still a work in progress? i'm eager to get to work on my mud but can't really walk around without getting kicked to limbo and thats really really annoying.
       
Post is unread #15 Dec 9, 2008, 7:37 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

So.. Uhmm.. Anyone have any ideas on this one?
       
Post is unread #16 Jan 2, 2009, 1:06 am
Go to the top of the page
Go to the bottom of the page

Keberus
Conjurer
GroupFUSS Project Team
Posts341
JoinedJun 4, 2005

Well, you could go with removing it still. I know that may no please everyone, but, it isn't really a necessity, and it is a mess. I commented out my code without any diffuculties, but I wasn't using anywhere anyways. If you remove it, it won't be a issue, and mobs will just move room room like normal. A 'band-aid' for it could be to set the distance to 1 instead of x4 in load_room, which in effect is like turning it off for any area that is using it, which stops the mobs from going into limbo. This will at least let people play thier game wihout being transfered to limbo when going certain routes. Heres where I'm talking about:

db.c, load_room

Locate:
               sscanf( ln, "%d %d %d %d", &x1, &x2, &x3, &x4 );

               locks = x1;
               pexit->key = x2;
               pexit->vnum = x3;
               pexit->vdir = door;
               pexit->distance = x4;


Change to:
               sscanf( ln, "%d %d %d %d", &x1, &x2, &x3, &x4 );

               locks = x1;
               pexit->key = x2;
               pexit->vnum = x3;
               pexit->vdir = door;
               pexit->distance = 1;


That will stop all of the generate_exit calls because for them to work the distance has to be greater than 1. Like I said above this is by no means a fix, but you might consider it a workaround for being able to remove the code without major adverse area side affects. Or as a band-aid until someone does come up with something better.

Hope this helps, at least a little.
KeB
       
Post is unread #17 Jan 2, 2009, 7:49 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Yeah, something along those lines could be used as a temporary solution. Keep in mind, though, that it would make the coruscant_streets area a good deal smaller in practice.
       
Post is unread #18 Jan 2, 2009, 9:29 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

I'd honestly rather it be a good deal smaller, then have limbo filled with wandering mobs.
       
Pages:<< prev 1 next >>