Graphical Mapper

As most people know there is a mapper built into zMud, and it is a graphical one, that displays quite nicely, you can double click to speed walk to that room from wherever you are, and if you have visited 100% of the rooms on your mud then you guarenteed can SW there, unless of course there is a maze, but that is a whole nother story...

I have stumbled upon another client, that is more along the lines of MUSHclient, in display, layout, and just simply design, yet it has an automapper. I am not even thinking about switching because i changed to mushclient because of the scripting power that zmud simply did not have, but would love to see MUSHclient beat the pants off of every other client by having its extensive scripting engine AND a mapper... here is the link to the Portal Client
http://www.gameaxle.com/

Nick I do hope that you will look over some of these features, as if this person was able to do it in the same layout as mushclient, well with what skills I have seen you have poured into mushclient, most, if not all that that client can do, can be used in mushclient. I especially like the idea of its tab completion being dynamic, and matching multiple words...

I do hope that some of those ideas in use in that client can be put into mushclient, as it would make this most likely the favorite client on the internet :)

Laterzzz,
Onoitsu2

Aye, it'd sure be nice to have a mapper. I've found something in between for my MUD, i.e. Achaea.

Basically it's a proxy program that you run between the server and the client. However, it will only work for the IRE muds.

I want a mapper too!:)

A graphical mapper would be nice I agree, perhaps one of the MUSHclient users would like to take a stab at it? I think most of the hooks needed to power it are already in the client.

Yo Max, where did you find it at, cause it might work on more muds than just that kind...

Thanks in advance,
Onoitsu2

It probably has some specifics hard coded into it, since its a "lot" easier to make a specific mapper for one "known" interface, than make a universal one, that can be adjusted to work with those that differ. Which is the basic problem. Any mapper would just about have to be nearly as complicated and detailed in design as the client itself, maybe more in some ways.

A mapper has several parts, some of which are more easy to make universal than others. The most general part is the thing that takes a graph of points (rooms) and edges between them (exits). Such programs exist completely independently of MUDs. Laying out these points in a sane way is a very difficult problem, and still an area of research in computer science.

Now, you also need a way to generate this graph, and this is where things get very hairy. In an ideal world, every room would have a unique tag of sorts, and you would use that identify the current room to the mapper. Then when you move around, you would use hooks in the mapper to let it know that you've gone from room X to Y, and therefore a new exit should be added.

Unfortunately very few MUDs expose their unique tags (vnums) to the players, so you have to play all these guessing games with triggers and other heuristics. This is where things get fairly dirty, and where a system for one MUD is not likely to work for another.

But the GUI itself is probably quite common to all MUDs. The part that would worry me, if I were writing one of these, would be finding how to uniquely identify rooms in order to know where to connect the exits.

The proxy mapper mentioned (if it's what I think it is) uses a fairly simple algorithm for identifying rooms. Basically, a room is identified by its exits and name (which are not unique but visible on pretty much any game) plus a unique internal ID. As a player moves around, the mapper simply presumes that he is where it believes he is, as long as the exits and name of each new room match the mapper's expectations. As soon as "real" exits and name do not match the expected ones, the mapper notifies the user that it is lost and starts trying to find the position by searching a room by exits and name and then again - matching reality with expectations until it can say that it found the position.

There are of course no guarantees that the mapper will ever have the correct position, but it seems like a scheme that should work well unless world designers take extra special steps to disallow the use of mappers in their game, in which case no mapper will work.

Well I used to use zMud, and have seen the mapper built into it as well, all it is, is a trigger system that catches the things specified by a certain layout... i.e.

ROOM TITLE
(X NUMBER OF NEW LINES AS DEFINED IN MAPPER SETTINGS)PARAGRAPH OF ROOM DESCRIPTION
PARAGRAPH OF ROOM DESCRIPTION
PARAGRAPH OF ROOM DESCRIPTION
(X NUMBER OF NEW LINES AS DEFINED IN MAPPER SETTINGS)
EXITS (STYLE AS DEFINED IN MAPPER SETTINGS)


Now I had quite a few areas in Aardwolf mapped in the older free version of zMud, and noticed one problem,
in order to map a new room it HAS to have a description, yet there are MANY rooms with no description, bacause they simply are there to increase travel time, or to re-route the character. Then once a room with a description has been mapped, the next time you enter the room it may not show the description based upon the BRIEF settings (0 always see room description,1 only see them upon first room entry,2 NEVER see room descriptions) And in order for the mapper to properly track your movements it required you use BRIEF 0, so it could match the description in its map to what the game reported. Then in Aardwolf there is something called Grafitti, so that you can put a hidden note in a room for a small cost, and if there is grafitti in a room you will see a (G) appended to the room title name. That helped AND hindered the mapper, bacause if there were many rooms named the same, all having no description, yet every other had grafitti, then the mapper worked, if all or none had grafitti then you were out of luck for auto mapping, and had go manually draw in the rooms.

The trigger idea is pretty easilly done, to get the room descriptions, and with the EXTENSIVE scripting possiblilties allowed within MUSHclient I could easilly create it, the only thing I need help in locating is the outside application, or the creation there of one, that does the graphical mapping. My triggers, as far as my MUD knowledge is, would be easily universal after setting the number of new lines between sections, and setting the EXITS format, then the problem lies therein of communicating this information to the mapper program, and from there returning matching it to a database of rooms.

If anyone has ever looked at a map file created using zMud, all it is an MSAccess DB, that just has 6 entries (n,s,e,w,u,d,HAS MORE FOR PORTALS) for each room that has the number of the room it is attached to in that direction as a value.

Laterzzz,
Onoitsu2

Actually, its even worse than that. The only muds that posses such unique internal IDs are so called "modern" muds, for which the ID is an artifact of how the room data is actually stored. Other muds, like LPC use something like an internal queue, IDs that are internal only and generated in the "order" that the rooms get created, which may not be the same every day, etc. They have the advantage that nothing short of a "major" bug requires that you recompile the driver, since everything, including stuff like MXP, is handled in the "library", not the driver. They do, ironically, sometimes use sections that have "virtual rooms", where there is a room type, default exits and an override ability that lets you specify that certain rooms are not part of the automatic generation, and that they should be loaded from a file instead, all of it on a nice, simple, 2D grid. This is however, usually, employed for the overland areas, not the ones with actually puzzles, mobs and other things in them. Modern muds generally have a clear deliniation between "short description", "long description", "mobs", "objects", and "code", with no way to override the first two based on context, limits on what you can do with the third and fourth, and code that, because if this, is hamstrung with respect to what you can actually do with the result, all so you can shove the stuff into a Database, for easy management. Its like coding in Basic, and I mean BasicA, from like DOS 2.0 or something, not even QBasic, which was at least a significant improvement. Imho, there has to be a solution that both a) makes object management easier, but doesn't b) rely so heavilly on the driver to handle every behaviour that you have to practically rewrite the thing to make *either* trivial or "significant" changes to the way the mud works. This imho, makes no bloody sense for a design...

Anyway, you can't rely on there even existing a unique ID for a room, so its pointless to talk about how much easier it would make coding a mapper if muds all provided you with the number. And, as others have pointed out, the lack of a unique way to see which room you are in using a number is only the "start" of the chaos involved with figuring out how to manage it. Though, Onoitsu2's example is "less" of a problem than it might be, as long as the mapper keeps track of "when" and "which way" you moved and you do recieve, at least, exit imformation and, "You can't go that way!", type messages, type messages. The mapper has to be smart enough to know you didn't move, and so "stay" where you last where, until you do successfully move some place. Put simply, "where" you are should only be "verified" with the room descriptions, actual movement should be based on what you as a player try to do, and if it is successful. It might help, to allow the player to tag a room as "unique", so that if the mapper does mis-sync, passing through one of those rooms would reset its location. In the best of worlds, you could make one smart enough to know its been tricked and wait until its sure of where it is again before proceeding to map how it go there, but its more likely that you would end up with one that realized, once it lander in a known "unique" room, that it needs to backtrack its last few locations, until its reasonably sure of where it got confused, just like the player would.

However, making it that smart just adds "more" complexity to the system.

Well as Shadowfry has stated, yes as far as VNUMS are concerned, they would be out of the question. But as far as tracking movements I have an idea...

Make Aliases for each direction you could move in (N|North|E|East|S|South|W|West|U|Up|D|Down|Enter|Enter (.*?))

and from there you can "Virtually Move To And Create" a new room in the mapper, and once you recieve a description, and room name, and exits, THEN you populate them in the mapper, BUT if you recieve "Alas, you cannot go that direction" or something of the sort (MUD Dependent, so would have a setting in the mapper triggers)
or you cannot enter that, or it is locked, or it is closed, etc. then in the mapper it "Moves you in opposite direction" and removes the newly created room.

I think I might possibly be able to design the triggers and aliases, I just need a graphical mapper that can make "objects" (Really is a ROOM, not a MOB or ITEM), that uses an internal unique ID for each room it makes (IE. a random number generator, somthing like MUSHclient has for alias numbers, and the like) Then hooking into the mapper is the next challenge...

I seriously think it is possible to make a mapper, only due to the fact that there already are mappers in a couple of other clients, BUT MUSHclient I think would become #1 in popularity, if it also had one, and zMud would finally die due to its crummy scripting engine, and large installation and small portability of OS's.

Laterzzz,
Onoitsu2

As I mentioned earlier, it should be quite easy to separate the graphical display from the actual data management. You could write the mapper part without a GUI, and somebody else who knows GUI stuff could write it up.