www.slothmud.org

Yesterday I found the desire to start playing around with the Mudlet Mapper and after many, many hours of struggle I managed to get it functioning today... but not without problems that I thought I would share with you, as there is obviously a fair bit of interest in getting the mapper working for SlothMUD.

Problem 1: Akaya's original mapper. (It won't work)

Akaya who was instrumental in creating the buzz that brought MSDP to slothmud, originally wrote a Mapper for Slothmud. This mapper used the msdp COORDS variables that were later removed because they were thought to be lagging the mud. Furthermore, I got a sense his mapper was snippets of code, copy and pasted from other authors and slightly adapted. Because the variables he was using are no longer in Sloth I really had no choice but to write my own mapper completely from scratch using msdp.ROOM_EXITS.

Problem 2: Room Collisions.

When I finally got my mapper to "map" a massive problem was exposed, which to some degree would probably make some area's not worth mapping... let me explain... the way I mapped things was using the x,y,z coordinate system in Mudlet. Lets assume that our first room is West Gate BH (0,0,0). We go 1 east (1,0,0). We go another east (2,0,0). We go one north (2,1,0) and we are in the Auction House.

Ok, now try this out... Lets assume that our first room is West Gate BH (0,0,0). We go 1 east (1,0,0). We go 1 north (1,1,0). We go 1 east (2,1,0). Where are we? The auction house right? No! The Bal Harbor Animal Market.

So straight away there is a problem... there are "collisions" with rooms... the coordinates for the Bal Harbor Animal Market are the same as the coordinates for the Auction House from West Gate... on the map this will place a room on top of another room. The reality is BH is a confused area with many collisions and essentially the map looks like crap. It would appear Akaya's original mapper didn't address this problem either.

So not to be beaten, I made a room collision detection system... when ever I added a new room to the map I checked to see if there was a double up, and if there was I placed that room with an angled line as to not place the rooms on top of each other. Perhaps I would even need to go further, and move all rooms that are on that axis over one, and re-index the rooms if I wanted to keep the lines straight. Area's like Kobolds mapped great as there are no collisions.

I think it would be fairly common to have coordinate collisions in a mud... and I wondered if anyone else has found a way to work around this, while trying to keep map lines straight? If so please share...

Problem 3: Detecting you have changed a room.

The other issue is each time you want to move a room, you want to add the new room and all it's links to the map... well as you may know, there is really no way to detect you have changed a room in Slothmud if you are solo. Capturing the msdp.ROOM_VNUM change event or msdp.ROOM_EXITS events are flawed because they fire multiple times and are subject to msdp update lag. If I walk fast then mapping some rooms will be missed out and my coordinates will be wrong. It appears the only way to map a room constantly once, would be to so in a group, as you could trigger the mapping on the following leader message. However as I was using msdp.ROOM_VNUM as the key for my rooms, and this variable is subject to lag... I wonder if that would even work. There doesn't seem to be a good way to do this but to add each room manually. Once again I wondered if anyone else has found a way to work around this?

I still have more work to do, to have colors for the terrain and run scripts that goto rooms etc... but I kind of feel without these other problems being resolved... whats the point... Does anyone have experience mapping muds and can tell me good ways to overcome these problems?

I think there are 2 pieces to making this work better:
1) Have the game proactively send new room information each time you change rooms. I'm not sure what you'd really need other than the Vnum.

2) The right solution for putting maps in the client is to throw away the idea of self discovery and include pre-built maps in a Sloth package for Mudlet. We could built tools to take the existing areas from either file or database and convert them to XML files that Mudlet can read. Someone would need to massage the X,Y coordinates to solve the collision problem but once the problem is solved, the entire community would benefit.

1) Have the game proactively send new room information each time you change rooms. I'm not sure what you'd really need other than the Vnum.

Great idea. And i even mailed you with such idea month ago. You didnt answer though, so not sure if mail was received or i used correct email

2. pre-built maps

I also think thats only working idea for Sloth. Areas dont fit good into coordinates system, since we have alot of intersections, portals and other area entrances.

I'm not sure it's practical to share the mudlet map data from client to client, although I haven't tried. I did open one of the map data files to see it was in a binary format. I also suspect it's format might change from version to version. However I do think the XML idea is better, as this information could be used to generate map data for any client.

What I would need Teker is a test area export. Just a simple area for now to test the concept on... something like this...

AREA <NAME>, <ID>
ROOM <VNUM>, <NAME>, <TERRAIN>, <N>, <E>, <S>, <W>, <U>, <D>, <X>, <Y>, <Z>

The idea would be to open this XML area file, and change the X,Y,Z data manually. Then write a LUA script to import the XML and generate the mudlet map from that data. The lua script could become distributable with the area file XML so mudlet users could import and create maps for any areas they choose. At some point we could talk about handling the tricky stuff like, trig traps and doors etc. But best to keep it simple for now.

I don't believe it's possible to automatically generate these maps for export.

The way you sposed to do it, is to build the map by exploring the area and then pulling and extending lines manually until it makes sense, then save it. You'll never get around the issue that space is not equally represented per room. I don't even like calling these 'collisions', because in my mind they aren't any kind of problem, but just the normal dynamic.

If you get the mapper working to the point that people can start making and sharing such maps, then your mission would be complete. I think trying to design something that can automatically detect and adjust for the differences in scale would be incredibly hard, not to cast doubts on anyone's talents.

*juggleblood* wrote:If you get the mapper working to the point that people can start making and sharing such maps, then your mission would be complete.

As with my last post about the coliseum, I went at length to describe a coliseum system that was expandable, modular and maintainable. Likewise this time, in regards to mapping, we know that mudlet is subject to change (they just changed all the mapping stuff after version delta), we need a solution that is not just for the mudlet client, and we need a solution that can be shared. XML room data and manual coordinates solves that.

I know your not a programmer JB and that's fine, you've done remarkably well to master MUDL without that background, but some of us spend our professional lives fixing other people's bad ideas. It's not that there ideas were not solutions, it just that there ideas were poorly constructed and led to projects needing 3-4x as much maintenance time after they were implemented, than the time it took to write them in the first place. Knowing a programming languages syntax does not make people good programmers, just like being able to play an instrument means you make good music.

The difference between what you are calling a solution, and the XML idea is that the XML idea proposed by Teker is a "programmers solution." It can work if mudlet changes, it can work if sloth changes. I don't believe releasing a working mudlet mapper is a good solution, and I believe all I will get is hours and hours of trying to help people use it afterwards if I did. If we did this right with a 3rd party exchange language such as XML we would have most bases covered for our future. The manual coordinates for rooms that get generated would need to be manually put into the XML files in the distribution. Any area added to sloth afterwards could have it's basic data extracted, and anyone using any client could build that into a usable map for whatever version of any program is the best at the time, with or without the people who originally created any part of the software. This is a true solution.

So you are telling me that this thing will be able to generate the maps based on the data alone, without human intervention? How are you going to tell it what to do with different scales (what you call room collision) and how are you going to tell it to deal with areas like Hellwell and Spire, where you travel up and down on a slant. And then how is it going to cope with special exits? Currently there are a number of ways that a player can teleport, such as an old style trig trap, mob proc, obj proc, or room proc.

The way I see it, every map is going to require a human to help generate it, so why not get some basic tools out there?

I think any decision a human can make in regards to mapping an area, a program could be programmed to make in the same way. But it would be difficult and probably not worth the effort... yes I think a few areas would be extremely difficult and not worth the time to try and program rules for, but I still think it's possible.

Regarding more "simple" collisions like I mentioned in an area like BH town, it would not be to hard to avoid collisions. Essentially N/S,W/E all act as an axis. It would be possible for a program to grab all the information and draw the rooms into lines that run on a single axis North/South and West/East, then combine these lines together. Where ever the opposite axis does not match - calculate the collision and extend the axis to compensate and add in the extra rooms. There is nearly always a way, if we can think it, we can do it... is it worth it, no it probably isn't. Hence as Teker said originally, the coordinates would need to be put in manually, although it could probably automate the most part of it first so there is less to fix up.

I'll try to spend some time over the next two weeks on the following:
1) Getting a base Mudlet package together that includes non-UI elements: triggers, aliases, scripts, etc based on the replies to my previous Sloth Client thread.
2) Updating the MSDP room vnum more frequently.
3) Exporting BH in a format that can be loaded easily by Mudlet.

We'll see where we get from there.

While i dont have anything against more frequent vrum updates on msdp, it could be hard to do that probably, while keeping the same server running speed and eliminating wrong vrum chance.

So i still offer to think about vrum number in room description. Thats easy solution that dont break anything. Could be regulated by separate ingame setting, so only visible by ppl who want it.
I think exits line, room name line, or even another separate line after exits could do the same job as msdp. Without such troubles.

Ok, I'll look at putting it after the description and making it toggle-able.

I'm really excited by this. That is great idea Fluffy about vnum. It will help a lot to have accurate vnum info.

Teker is there a central teleport function, which could trigger a msdp room vnum update? I know currently all the variables spit out on a timer, but how hard would it be to have it update when it changes, i.e. when player teleports (i.e. tranfers via any method)?

I did think of Fluffy's idea as well... and It would work in most cases... however there are cases in slothmud with trig traps etc where you move a room and the room description is not shown... you have to "look" to get it. I guess this is why JB is asking about the central function for room changes, would there need to be a forced "look" in that function just to make the process smoother so that the VNUM can be extracted for sure in every room change?

For the client to pick it up could you make sure it's easily triggered and safely?.... something like [VNUM:xxx] Nothing else in slothmud should fire that trigger apart from what we need it too.

Personally for me, i think such silient teleport is a mistake. Each room changing should have same logic. So automatical looking after any silient teleport isnt that bad idea imo. Wonder if it could be done via mudl.
Probably not so many of such places. They could be reported and eventually fixed, if fix is easy.

Anyway, while building the map, it could be a problem requiring manual map correction.
But if moving on already created map, doent seem as big issue, since position will be fixed on next room description.

Yeah, it's easy enuff to make sure there are looks after special teleports. I was thinking that an invisible msdp room vnum is preferable to displaying it, if such is possible. If there is no central function tho, then displaying it is a great option.