Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page Previous  1, 2
Zugg Posted: Tue Sep 02, 2008 7:48 pm
How to best support multiple map windows
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 2:42 pm   
 
Zugg wrote:
A "location object" has a *single* integer value that represents the room ID. If you want multiple rooms to be marked, then you need to create multiple location objects. Basically, a "location object" is a "cursor" pointing into the mapper Room table. There is absolutely no way to have it maintain multiple locations for a single marker...it breaks the entire architecture.

Sure, but a "location object" could have an *array* of integer values that represent the possible room IDs... Note that I am talking about Follow mode, not Mapping mode (the Mapper program I mentioned attempts to do it in Mapping mode too, but that is much more complex).
Zugg wrote:
When you enter a direction to move on the MUD, like "north", CMUD moves the current "location" marker to the room to the north of the current room. If the marker represented multiple locations on the map, this would be impossible.

No, it wouldn't be impossible. CMUD could attempt to move the "location" marker for each of room IDs in the array to the north. Any that fail are eliminated from the array. Eventually the array will return to a length of 1 (or 0 if you are on Follow mode and moved to an unrecognized room) and 'normality' is returned to.
Zugg wrote:
There are other ways to handle your case of #FIND having multiple possibilities. The best way being to loop through the room possibilities and create a location marker for each one. For example, maintain the names of the multiple markers in a string list. Use the same color for each marker, but a unique name (like MarkerNNN where NNN is the number index into the string list of #FIND results).

Well, having a solution for this problem would certainly be a good idea, whatever the solution eventually is.
Zugg wrote:
Mapping mazes is very low on my priority list. Mainly because most MUDs go to a *lot* of trouble to make them nearly impossible to map. And the more work I put into trying to map them, the more work the MUD puts into making them impossible to map. For example, on Aardwolf, "maze" areas are randomly generated periodically so that the map that worked yesterday won't work today. No way to map that, so it's a waste of my limited time to worry about it.

I hear you, although I think the number of maze areas that are randomly generated is currently pretty small as a percentage of them. My MUD has a few like this, but most are fixed, albeit some with a RANDOM flag which means when you try and leave, you leave through a random exit.

Zugg wrote:
Quote:
Also, if the commands to sent to more than one session window, shouldn't the #OK triggers also be sent to the same session windows?

No. If you have multiple connections sharing the same location object, then you need to send the movement command to *each* connection, but you only want a single #OK trigger to cause the location object to be updated. It's only when each connection has it's own location object that each window needs to have it's own #OK trigger.

And honestly, I wouldn't worry about this detail much since I can't even really think of a case where you would want multiple connections to different MUDs to share the same location object. The code handles it because of how it's written, but I just don't see it being a realistic possibility.

Who said anything about different MUDs? Just because you have unique network connections doesn't mean they go to different MUDs, or even different host/port combinations... (I'm not personally likely to want the same location object attached to different network connections though.) However, what about the case where you have a single network connection but multiple windows and where the room name, description and exits are *not* displayed on the window that has the network connection? If, as you state, the #OK trigger is sent only to the session window that issues the #WALK command, it's never going to match is it? Because the text on which it fires is not necessarily one with a command line, the one with a network connection or the one with (or last had) focus. That is why I suggested the #OK trigger be sent to all the session windows. Actually that's not quite what I suggested, but, probably, I didn't explain it so well before. Or, maybe there should be a way to set which session window(s) get sent the #OK trigger? For example one might set it to go the 'RoomDescription' session window and the main session window, in case one's triggers that #GAG and #CAPTURE the room description failed to work properly.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Wed Oct 29, 2008 3:18 pm   
 
I believe Zugg's point with the location markers is that if a location has an array of values and that location marker then needs to be moved north, the code has no idea which location in the array to change. It's possible that multiple locations might be able to go north, and it'd have to choose or move them all, neither of which might be the result you want. Thus one location per marker.

I also think the idea of his comments wasn't that mapping mazes is made difficult by those random areas and thus isn't worth the effort, but that if he works to make mapping mazes easier, then MUD admins will take steps to make it harder - an example of which is those random areas. It becomes an arms race with no real conclusion, and that's why he doesn't want to enter into it.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 3:39 pm   
 
Fang Xianfu wrote:
I believe Zugg's point with the location markers is that if a location has an array of values and that location marker then needs to be moved north, the code has no idea which location in the array to change. It's possible that multiple locations might be able to go north, and it'd have to choose or move them all, neither of which might be the result you want. Thus one location per marker.

All possible location IDs in the array of the location object should be attempted to move north as I explained in my last post. I can't see any reason why some should be exempt. They all need to work in sync. If any can't move the direction that got the #OK, then clearly that location ID was invalid and it should be removed from the array. This does imply multiple #OK triggers though (although some might have the same pattern as each other) - one for each possible next direction. Or just a single #OK trigger that has more than one pattern using | and captures the result of which pattern was matched so that the "script" (which is not really a script) can decide which room(s) matched.

Fang Xianfu wrote:
I also think the idea of his comments wasn't that mapping mazes is made difficult by those random areas and thus isn't worth the effort, but that if he works to make mapping mazes easier, then MUD admins will take steps to make it harder - an example of which is those random areas. It becomes an arms race with no real conclusion, and that's why he doesn't want to enter into it.

Well, if this is limited to Follow mode (which is all I covered), I think MUDs are less likely to make it harder. *My* point really though is that you already can get multiple possible locations with #FIND and we need a solution for this problem - so we may as well have one solution that solves more than one problem. Cool Which is what my solution does (in combination with a RANDOM flag as described in my last post).
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Wed Oct 29, 2008 4:02 pm   
 
you do realize that what you described was doable (albeit slow) userside even in zmud?
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Oct 29, 2008 4:54 pm   
 
Sorry, Seb. I don't like it. It still makes sense to me that a location object is a single pointer to a single room. The situation you are trying to solve is much more complex and will be different for different muds. It will depend on the mapper configuration.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 5:32 pm   
 
intoK wrote:
you do realize that what you described was doable (albeit slow) userside even in zmud?

Sure. Anything is 'doable', but *slow* is the operative word here. Very inefficient to do in zMUD/zMapper.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 5:39 pm   
 
Rahab wrote:
Sorry, Seb. I don't like it. It still makes sense to me that a location object is a single pointer to a single room. The situation you are trying to solve is much more complex and will be different for different muds. It will depend on the mapper configuration.

It's not really that complex - mapping new rooms when you are not sure of your current location - that would be complex. Does every single room on your MUD have a different first line of the description or room name? Most MUDs do not. This will therefore be useful for most MUDs. RANDOM may be different for different MUDs, I concede, but the concept of not being certain as to one's current location is the same on virtually any MUD.
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Wed Oct 29, 2008 6:31 pm   
 
Seb wrote:
Sure. Anything is 'doable', but *slow* is the operative word here. Very inefficient to do in zMUD/zMapper.

yes, slow - as i said - in zmud... in cmud mapper functions are so far 20+ times faster, and possibly will be even faster with upcoming engine

what you propose seem to be very mud specific, most muds offer other and _way_faster_ ways for intelligent scriptor to determine his/hers location than to eliminate possibilities by moving around, not to mention that with proper precautions getting lost is rather rare

mud specific issues should be solved user-side, mapper should only provide groundwork for that
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 8:20 pm   
 
intoK wrote:
what you propose seem to be very mud specific, most muds offer other and _way_faster_ ways for intelligent scriptor to determine his/hers location than to eliminate possibilities by moving around, not to mention that with proper precautions getting lost is rather rare

mud specific issues should be solved user-side, mapper should only provide groundwork for that

None of the MUDs I have tried (a dozen or so) offer 'other and _way_faster_ ways for intelligent scriptor to determine his/hers location than to eliminate possibilities by moving around' for a non-immortal/wizard character. That's 0%. On a related note, it would be useful if the #OK trigger was not so hard and fast: if both the #OK and #FIND took into account Room Name (if available), Room Description (if available) *AND* Room Exits (if available), and assigned a probability of a successful move or successful #FIND depending on all three factors matching (which perhaps could be weighted by the user in the map config). The user could configure what probability is required to move the location objects' position or to mark the spot after a #FIND (and whether to mark the spot with the greatest probability, all spots or none if there are multiple matches).

I agree that 'mud specific issues should be solved user-side, mapper should only provide groundwork for that'. But I don't think these are issues that only apply to one or two MUDs. And the concept of mulltiple possible locations *is* groundwork, IMHO. I wouldn't have a problem with scripting support for RANDOM exits, because this is more mud-specific (although I suspect it is still fairly prevalent among MUDs), if there were a way to give the mapper a list of possible next rooms, instead of a single direction that implies a single next room with a success / fail binary result for the move.

I think we've gone a bit off-topic now (my fault), but since the original topic was basically dead, I reckon this is OK. And actually it is more on-topic if one considers that a user may be trying to map the location of another player or non-player character (or object) based on some MUD output that he receives (which was one of the thoughts behind my original post). I think it is best to get these low level improvements to the mapper discussed early on, particularly as Zugg is at the stage where he is coding this right about now.
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Wed Oct 29, 2008 9:08 pm   
 
Seb wrote:
I wouldn't have a problem with scripting support for RANDOM exits, because this is more mud-specific (although I suspect it is still fairly prevalent among MUDs), if there were a way to give the mapper a list of possible next rooms, instead of a single direction that implies a single next room with a success / fail binary result for the move.

random exits (flag set on exit that randomly rearranges pool of all random exits in room - is that what we talking about?) are on pretty much every mud, and i dont see any problem with scripting support for it, so what exactly is yours? detect whether mapper is lost or not and call relocation procedure after every move if you cannot dig out enough info from room in question.

also, main function (the groundwork) of the mapper, IMHO, is to provide things like %walk, #SLO, #STEP, #MAP etc, having pool of possible locations dosnt help those functions, it makes them impossible to realize, #FIND itself is only a gimmick
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Wed Oct 29, 2008 9:22 pm   
 
As an aside, narrowing down the results of #find is something I think about often, and I think it wouldn't be awfully hard to write a system that, once you've become lost, records your movements and works out where you are after a few movements. When you're lost, the mapper can examine both the room name and the exits (and the description if you're using that, but since identical room names normally mean identical descriptions, it's not that much help) to see how many results there are. Most of the time that'll be enough. If it's not, the script would remember the room and exits and wait for you to move. Perhaps it'd also tell you some stuff about the room possibilities, but that's icing.

Once you move, the system records the direction you left in and then the details of the room you're now in - its exits and room name. It can then build an SQL query that looks through the map trying to find the exact combination - a room with a certain name and certain exits, and in x direction, another room with a certain name and certain exits. I think it'll take at most one or two moves for this system to be able to find you if it's going to be able to - for example, if the area is just a grid of identical rooms that all link to each other, it'll never be able to work out where in the grid you are until you leave it. but beyond that, it'd work pretty well, I think.

The key to this system is knowing when you're lost, which is something the new mapper could do with communicating - telling you, probably with an event, when the room the mapper thinks you're in and the room that was just sent from the MUD don't align. Writing the rest of it is probably best left up to the individual MUDs so you can add behaviour - like using some kind of WhatZoneAmIIn command when the mapper thinks it's lost, if your MUD has it, or using a MAP command to display a visual map that can be parsed and then SQL-ed. I like thinking about this problem, because it's one that annoys me on a regular basis, so I hope you'll forgive a brief wander ;)

As for multiple locations, I still think that it's fine without. The idea is that, if you were to want to move a single marker north, you could do that - you could also move all your markers north that can, by using a script. If you hardcode one behaviour or the other, it may not always be the behaviour that users want, and it can be difficult to bypass this kind of thing. Look at the stuff Viji's had to do in the past to make the mapper jump through his hoops :P

At some level of the code each object would have to be drawn individually, so you might as well just make each object have one location, and if you want to you can write a script that allows you to treat multiple visually identical location objects as a single one when you want to. I don't see any problem with doing it that way as opposed to having multiple locations built in - anything that system can do, this one can do as well. If, by extension, you wanted to use multiple locations to show the possible places you might be when you're lost, you can still do that by scripting it in your I'm-lost,-help event.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 9:38 pm   Approximate strings matching
 
Seb wrote:
On a related note, it would be useful if the #OK trigger was not so hard and fast: if both the #OK and #FIND took into account Room Name (if available), Room Description (if available) *AND* Room Exits (if available), and assigned a probability of a successful move or successful #FIND depending on all three factors matching (which perhaps could be weighted by the user in the map config). The user could configure what probability is required to move the location objects' position or to mark the spot after a #FIND (and whether to mark the spot with the greatest probability, all spots or none if there are multiple matches).

Oh, while I'm on the subject, a 'blur' factor on the room description would be useful too. So, that very slight changes (perhaps for typo, grammar or stylistic reasons) to room description still produce a highly probably match.
E.g. The Room Description when you mapped it was:
Quote:
Tall grasses predominate in this area, with a forested region starting nearby to the east.

But when you later entered the room:
Quote:
Tall grass predominate in this area, with a forested region starting nearby to the east.

...still produces an 90% match for the description. Personally, I've always wanted this for the entire room description, not just the first line, since many rooms on my MUD have the same first line but different lines afterward, and / or different room contents (although, clearly, those are usually subject to change, but this could be achieved by lowering the weighting for room description, or even better, having a new Room Contents match test and weighting that very low).

The following is quoted from the initial feature list for a mapper made for my MUD (presumably not the very first release though) and explains my suggestions / thoughts / motivation in more detail:
Quote:
* Approximate strings matching.
The plague of other mappers - typos in roomname and roomdescs. Once you've mapped the area you have a saved roomname and descs etc, but thuse often have typos in them. Or just get changed. So, i got bored of loosing sync just because something got fixed and switched to approximate strings matching and added configurable automatic refreshing. The user just gives 2 numbers - percents of allowed mistakes in roomname and desc (default is set to 10) and if he feels safe can turn the automatic refreshing on. So, when you run around with 100% sync and run over a room with a few typos fixed in it - most likely you will just get a message

--[ (AutoRefreshed) not exact roomdesc match: 2 errors.

and you'll be in sync and roomdesc will be refreshed in the base. If autorefreshing is off - you'll just get warned that roomdesc doesn't match and still stay in sync.

... [snip]

* The Engine and concept of syncing.
The general idea stayed as it is, just most things became configurable. I wanted to keep the track of your position ALWAYS. For that i always store all possible positions, not just one or none. This allows to use mapper as reliable replacement for secrets databases to show hints about possible secret exits in room. Also this allows the use of dynamic algorithms for syncing.
And about the word configurable - mapper doesn't need all the info the game can give you. It can live with parts of it as well. You can turn off descriptions, exits analyzing, terrains in prompt and fuck up the movements aliases - mapper will still try to sync somehow. And if it gets the info - even better, the syncing will be more precise and/or faster.

The engine itself is configurable as well (it was almost fully rewritten). Basically engine is a state-automate. It has two stacks - the cause and results stacks and it has little scriptlets for each pair of stacks top values. A little example - general mappers cycle for basic movement:

engine EMPTY EMPTY done
engine C_MOVE EMPTY done
engine C_MOVE R_ROOM try_dir; swap; apply_roomname; swap; Rremove; Cremove
engine EMPTY R_DESC apply_desc; swap; Rremove
engine EMPTY R_EXITS apply_exits; swap; Rremove
engine EMPTY R_PROMPT apply_prompt; swap; Rremove

I think these features may not currently be as useful for my MUD as they used to be when this was posted in Jan 2005 though, although they may well return to being more useful again, and I expect they are useful for other MUDs.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 9:42 pm   
 
intoK wrote:
Seb wrote:
I wouldn't have a problem with scripting support for RANDOM exits, because this is more mud-specific (although I suspect it is still fairly prevalent among MUDs), if there were a way to give the mapper a list of possible next rooms, instead of a single direction that implies a single next room with a success / fail binary result for the move.

random exits (flag set on exit that randomly rearranges pool of all random exits in room - is that what we talking about?) are on pretty much every mud, and i dont see any problem with scripting support for it, so what exactly is yours? detect whether mapper is lost or not and call relocation procedure after every move if you cannot dig out enough info from room in question.

Yes, that is what we are talking about. So if you say they 'are on pretty much every mud', why did you previously say they are 'mud specific'?! It seems to me that Zugg should be implementing features that will help players mapping on most MUDs. Sure, it can be scripted. I did something similar for zMUD to determine which direction I probably fled (because in those days the MUD didn't tell you) and move me on the Mapper if the direction was certain. But the point is that not everyone is at good as scripting as me or you, or wants to spend several hours doing the work. And why duplicate the effort if Zugg can do most of it and benefit hundreds or thousands of users in one go?

The same answer, in relation to scripting vs built-in functionality applies, more or less, to Fang's response. Good idea on the onMapLostSync (my name) event though!
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 10:08 pm   
 
intoK wrote:
main function (the groundwork) of the mapper, IMHO, is to provide things like %walk, #SLO, #STEP, #MAP etc, having pool of possible locations dosnt help those functions, it makes them impossible to realize, #FIND itself is only a gimmick

It only means that if you are in a speedwalk that is controlled by the map, as opposed to a path, and multiple possible current locations exist at any point, the speedwalk will need to be aborted. I don't think that 'makes them impossible to realize', especially if you consider how unlikely it is that you will try and speedwalk through a random area! Actually, if a speedwalk is aborted for this reason, an event should be automatically raised.

BTW, I don't see any reason why people should not able to turn off the 'multiple possible current locations' feature. All it would take is restricting the size of the array to 1. But I don't know why you'd want to (except to avoid bugs initially). Actually having a (configurable) maximum number of 'possible current locations' would probably be useful for performance reasons in case it got very big. If the number of possible current locations exceeds the maximum, the mapper should just lose sync and raise the event that Fang suggested.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Oct 29, 2008 10:44 pm   
 
You guys are pretty much "beating a dead horse". As I said, the architecture of the new mapper has a Location object as a cursor into the map database, so a Location object can only point to a SINGLE room. That isn't going to change. I'm way too far into the rewrite at this point to make that kind of huge change.

As Fang said, you can easily use a string list or other array to keep a collection of locations if you want to do that.

On the Description stuff, you know that you can turn off the description matching, right? I rarely use the description when mapping MUDs because so many of them are changing the description based upon time of day, weather, etc. A simple "percentage" of change isn't going to handle that, and just makes the mapper even more complicated. What percentage is good enough? There is no way for the average player to know.

If there was a typo in the room description that got fixed by the MUD, then when you move into the room and lose sync, you just use the #LOOK command to reload the updated description. And if you aren't using the description in the matching, or if the change is past the first line, then it won't even matter...the mapper will still track fine.

As far as making the mapper more useable for the majority of players, yes, that's exactly what I'm doing and there are far more things to be working on that dealing with the nearly impossible mud-specific problem of trying to find your location when you are lost.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Wed Oct 29, 2008 11:15 pm   
 
Zugg wrote:
You guys are pretty much "beating a dead horse". As I said, the architecture of the new mapper has a Location object as a cursor into the map database, so a Location object can only point to a SINGLE room. That isn't going to change. I'm way too far into the rewrite at this point to make that kind of huge change.

As Fang said, you can easily use a string list or other array to keep a collection of locations if you want to do that.

Well I suppose that's what I get for not posting this stuff earlier. Anyway, I've just been catching up with the mapper project I quoted above and it looks like they've implemented (in April) all the remaining cool stuff I was looking forward to in CMUD 3.x Public, so maybe it's just time to remap the world... Oh, no, wait, they still don't support speedwalking. Sad Well, I guess I could use both mappers... Hmm, although it seems the new stuff has some issues still...

Zugg wrote:
On the Description stuff, you know that you can turn off the description matching, right? I rarely use the description when mapping MUDs because so many of them are changing the description based upon time of day, weather, etc. A simple "percentage" of change isn't going to handle that, and just makes the mapper even more complicated. What percentage is good enough? There is no way for the average player to know.

If there was a typo in the room description that got fixed by the MUD, then when you move into the room and lose sync, you just use the #LOOK command to reload the updated description. And if you aren't using the description in the matching, or if the change is past the first line, then it won't even matter...the mapper will still track fine.

As far as making the mapper more useable for the majority of players, yes, that's exactly what I'm doing and there are far more things to be working on that dealing with the nearly impossible mud-specific problem of trying to find your location when you are lost.

Yeah I know I can turn off the description matching: I usually do turn it off and use the room name, but more complete matching would be useful for mazes and for finding when lost (although I coded another (not perfect) solution to that which involves changing the map config over to another I have saved, issuing a #FIND that I've customized to display all the info I know about the room and then switching the map config back). I'm really just thinking of your users: I don't know if *I* am actually going to play mortal (seriously, i.e. mapping or PK) ever again. (It's a question I've struggled with over the past year or so.)
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Thu Oct 30, 2008 11:27 am   
 
I have been doing the description parsing for years. It isn't very hard to make a script that breaks the description into sentences and then determine a match based on the positions and numbers of sentences matched. Among the things I am pushing for is better configuration, using color and other visual markers. I am also pushing for the configuration to create an actual script that is then user modifyable. Stripping the first sentence out of the description is very easy with a script. Zugg has stated that he intends to make the configuration into something that can be transferred through the package library, and that is enough to allow people like me to publish complete mods to the behavior.

Getting lost is also rather easy to handle. I have a script that already deals with it much like Fang described. The reason any solution is mud specific is because of differences in capabilities. For example when my script comes back with multiple possible rooms it queries for information on all the rooms that surround the possibilities. Then it issues "glance dir" which looks in a direction and causes the mud to send back room information without actually moving. Many muds do not have a similar command. You can be certain that after the new mapper is available I will update my scripts and produce a publishable one for handling the got lost situation.

Random exits is a classic thing. One of the stock Rom areas uses a group of random exits. I would like to see the mapper be able to handle this somewhat better. The main thing needed to solve this is to be able to tell the mapper that the connection is bad. There is a path through, but a given exit will not result in stepping into a definite room. I currently handle such things by setting the other command for the exit to call one of my scripts, and putting the destination to a special room. That room includes exits to any of the rooms that have fixed exits. This lets me issue a speedwalk to where I want to go, and the mapper finds a path through my special room. Scripts take care of the rest and it is horribly complex.

A better way to handle random exits might be to make multiple links on a given direction. For example 5 east exits from room 394 with destinations to rooms 227, 395, 399, 401, 405. When the mapper sees this it should do something other then expect the first one to succeed. I don't really know what it should do. About all I can think of is raise an event and abort and current speedwalk. The user obviously set the map up that way for a reason, and should provide a script to handle that reason. The event might be something like onRandomExit($DestList,$SpeedWalkDestination) where $DestList would be all the possible room numbers, and the %lastdir could still be used to get what direction was sent.

In any case, let's let Zugg produce the first stage of the new mapper. Then we can play around with it and develop scripts that solve these problems under the new architecture. When we are doing that we will better be able to tell what things need to be added to make solving these problems easier.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Thu Oct 30, 2008 1:48 pm   
 
interesting idea, but having multiple exits in single direction will mess up with walk queries me thinks, also not to user friendly to map, with say 3 random exits you need to define 9 exits for that mapped room and link them to respective rooms
having userflags for exits would be more flexible, especially since random exits are not only thing too look after, fe. doors can be hidden when closed, there can be special progs on exits etc... and they are soo easy to implement, one field in exits table and function to access it for starters, possibly autoevent Wink
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Oct 30, 2008 4:14 pm   
 
Btw, keep in mind that this initial "Phase 1" beta of 3.x doesn't have any changes to the mapper configuration code. Even though it has the multiple location stuff and multiple map window, redesigned Room Properties, etc, which were all beyond the initial scope of Phase 1, the improved configuration handling is the big part of Phase 2.

It's going to be very tricky creating a new configuration system that retains compatibility with the old system. I do not want to break everyone's existing mapper configuration and scripts because it's something that people have put a *lot* of time into. For example, Vijilante will be an important tester of Phase 2 because of all of the scripts he has written for the mapper...I want those scripts to continue working even as I provide newer and better ways to handle stuff. This makes Phase 2 a pretty large effort. But the new architecture I'm using in Phase 1 should help make those changes a bit easier to implement I hope.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Thu Oct 30, 2008 5:01 pm   
 
Vijilante wrote:
Random exits is a classic thing. One of the stock Rom areas uses a group of random exits. I would like to see the mapper be able to handle this somewhat better. The main thing needed to solve this is to be able to tell the mapper that the connection is bad. There is a path through, but a given exit will not result in stepping into a definite room. ...

A better way to handle random exits might be to make multiple links on a given direction. For example 5 east exits from room 394 with destinations to rooms 227, 395, 399, 401, 405. When the mapper sees this it should do something other then expect the first one to succeed. I don't really know what it should do. About all I can think of is raise an event and abort and current speedwalk. The user obviously set the map up that way for a reason, and should provide a script to handle that reason. The event might be something like onRandomExit($DestList,$SpeedWalkDestination) where $DestList would be all the possible room numbers, and the %lastdir could still be used to get what direction was sent.

I don't know about you, but on my MUD random exits apply to a room and not an individual exit. Of course, most people on my MUD may not even be aware of this distinction, but I happen to know this. This means that every exit from a room with the RANDOM_EXITS flag goes in a random direction when you leave the room (or possibly, as intoK described, they are randomized when you enter the room and you are only aware of the fact when you leave the room - it makes little difference). This means that one would only need to set the RANDOM_EXITS flag in the Room Properties once on each room affected, and not create e.g. 5 exits for each direction, which is a lot more tedious to do when mapping.

If we want to use events for this, doesn't it make more sense to put all the most likely to be needed information in the event to save looking it up in the script, when by the time the script executes, if it is not in the main thread, the user may have entered another direction or something?
onRandomExit($CurrentRoom,$lastdir,$DestList,$SpeedWalkDestination) where $DestList would be all the possible room numbers associated with the exits from the $CurrentRoom. Note that $SpeedWalkDestination may be null if it was the user who entered the %lastdir... Hmm, actually, no, it should be the room number of the direction of intended travel, i.e. one of $DestList.

Can't the code for handling the event abort the current speedwalk, or would that be too isolated from the mapper?
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Thu Oct 30, 2008 5:13 pm   
 
If phase 2 resulted in a function one could call to check if a particular room ID matched the last room parsed based on your mapper config (I'm not talking aboutt $CurrentRoom but the new room), then one could call this function repeatedly from the onRandomExit event handler and see which of the rooms in $DestList matched. Then it would be a lot easier to handle that result to tell the mapper what to do next. As well as there being other applications for the function I have just described.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net