Mapping tool
 

I am considering to look into how a mapping tool could be developed similar to the one I used in my . The problem is that I have run into a few problems :rolleyes:.

1. zMUD/CMUD already has a mapping tool. Would it be ethical/legal for me to make a similar one? As it is now zMUD has almost a monopoly on auto-mapping. There are some other MUD clients with limited mapping support but none of them do it very well.
2. Opening .area-files and files of other MUDs and/or mapping tools. Could this cause legal problems?
3. Is there a need for another auto-mapping tool?
4. What feature(s) should a modern auto-mapping tool have?

Re: Mapping tool
 

1) My understanding of the matter is that duplicating functionality is fine as long as it's clear that your product is not zMUD or CMUD, and in the course of developing your application you don't violate any licensing terms you've agreed to in order to use zMUD or CMUD. IANAL, YMMV.
2) Much like #1.
3) No idea.
4) You might want to think about an extension protocol that MUDs could use to communicate geoinformation, such differences in scale between rooms, to your tool. If a MUD knows that room A is 5x5 meters and room B is 200x100 meters, it may turn up helpful if it can tell your application this in a standardized way. The same might go for terrain types, levels of exposure to weather, interactive service offerings like shops and taverns, and so on. If you design a protocol like that and do it well, you could wind up making a contribution that goes significantly beyond your particular application.

Re: Mapping tool
 

I could probably make an extension to MXP for it. A problem might be that you might want two-way communication between the mapper and the MUD. So that as builder you could work on the map and it would send the changes to the MUD so that the map there gets updated.

Re: Mapping tool
 

Imo, the most successful mapping tool that could be made would be some "addon" to your standard mud applet, which somehow remembers where you've been, makes a dinky map of it, allows you to mark up rooms with labels and colours and allows you to click on a square which does a speedwalk. Any applet which could do that, without needing to look at area files, would be a massive boon to the MUD community.

Re: Mapping tool
 

In dragonmaw client for Sharune II we use a mapping tool that maps graphically your surrounding as you walk around in the mud. It is a nice thing to have when you build online with OLC. (Not to mention players love it).

Next feature added for it will be a character "memory" so that your character will remember the rooms as you walk around the world. Right now as we first test it players get all rooms mapped no matter if they have visited them before or not.

We're also adding more OLC integration for our builders later. So they can click around on the map, move to the rooms by clicking and create new rooms etc etc. And get a massively larger map displayed. possibly with all information about mobiles, items and scripts in the rooms.

It obviously work closely with the mud server which sends all the information on what rooms to display on the map.

Re: Mapping tool
 

3. Is there a need for another auto-mapping tool?

Not everyone likes or uses ZMud or CMud. And not everyone, for that matter, necessarily likes, or and use, the display/storage method in them. Some servers also do supply additional info that helps mappers, others try their hardest to *prevent* easy mapping. And some clients, you just "can't" integrate one with.

The issue is complicated. The first is "controlling the mapper". Integrated ones work best. Some clients like Mushclient could use UDP, or even talk to ActiveX, but the later won't work well on Linux with WINE. There is no display system in the client to produce maps anyway, and a text based one... you would have to code all the logic *and* storage/retrieval yourself. If you make one that is separate, you could run it as a proxy, and get all clients to work with it, but then you need adjustable aliases in the mapper, so you can control it from the client, and so that you can change them to not conflict with existing aliases. You also have no direct way to the client to talk to it, so even if the client could script things to handle the mapper better, its going to have to rely on "sending" it as though it was a typed command. Not impossible, but unless you also trap messages going the other way, you have a one way street happening. Clients that support scripting could deal with this, by addons that support reception of the inbound errors, etc., and sending outbound messages, but its still mucking with the main communications.

And that is another issue. Which one traps the room data? The mapper, which also passes it on, or the client, which then tells the mapper what it got? Some clients can't do the later, the ones that can, may have better control over the mapper, but again, if you have to use your proxy connection to do the talking, you are mucking with the channel also needed to play properly, which is imho a bad idea. If your mapper's own script/internals generated an error loop, you could be sitting there with either an endless display of errors, in a client that doesn't have scripting, or an endless serious of script calls, which prevent it doing anything else.

But, controlling it isn't the biggest hang up. That is displaying it, and dealing with the data in a useful way. Do you just duplicate what z/cMud's mappers do, add some better predictive stuff, but keep it 2D, develop a 3D display method, presume everything it on a grid and try to use graphics? Any and all of those are likely to be bad for "some" muds. Having a way to do all of them, or even make a new type, if you wanted via script, would be nice, but just replicating z/cMud would be enough of a pain in the rear.

I suppose this also covers 4 as well. It needs to be more flexible, with more options to display the data, have better prediction, for alternate display to work at all (or the existing ones to work better), path finding (we came up with some potential ones for Mushclient, but no one ever wrote a client to put it in), the means to "use" additional information that some muds may already supply to their own custom mappers, and some way to use it with a fair number of different clients (but possibly with the option, when available, of more closely tying it to the clients, so that you can control it better). The most obvious of the later issues would be something like setting the player client up so it went "map:open,map:top", to have it "pop" the window up where you can see it, over the game client, then similar commands you could use to minimize + hide it. Not everyone has enough desktop space to have it open 100% of the time.

Biggest issue is, it would be nice to see two things we don't have, smarter mapping, and something that works with as many clients as possible, not just the ones that have mappers already.