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
pen,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.