I want to contribute as well - when I can get away from
the hack and slash of writing the Mudlet application itself!
I note that there does not appear to be an up to date WoTMUD map laying around any more - but you can now load/import basic XML format map data now which might make it possible to transfer the data from other places besides an existing copy on Mudlet. Does ZMud or CMud have an exporter that can produce XML data? It might be possible to get the data from a TinTin++ client but as that one has what I think of as a free-form mapper (room positions are relative to the "current" room and not fixed in position like they are on Mudlet) it is hard to get positional data from it that we could use.
Currently the XML has to be in the format that one can examine by downloaded one of the (currently four as MidkemiaOnline was shut down last year) maps of IRE MUDS at http://www.<mudname>.com/maps/map.xml where <mudname> is one of "achaea", "aetolia", "imperian" or "lusternia". They do not include room description data so the current parser does not scan for "<description>"
sub-elements of/"description"
attributes to the "<room>" one but if someone can cobble/export data that includes that, I will move adding support for that to near to the top of my "Stack".
In summery the XML format is:
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<map>
<areas>
<area id="1" name="Area Name 1" x="0" y="0"/>
....
<areas>
<rooms>
<room id="1" area="1" title="Room Name 1" environment="1">
<coord x="1" y="2" z="3" building="100"/>
<exit direction="north" target="2"/>
<exit direction="east" target="3"/>
<exit direction="south" target="4" door="1"/>
<exit direction="west" target="5" hidden="1"/>
<exit direction="up" target="601" tgarea="2"/>
<exit direction="down" target="602" tgarea="2"/>
</room>
...
</rooms>
<environments>
<environment id="1" name="City" color="15" htmlcolor="#808080"/>
....
</environments>
</map>
Notes:
The
id attribute has to be unique for a particular <tag> type and >0 for all instances.
Mudlet currently ignores:
- In the <area> element: the "x" and "y" area attributes - I have not seen them being anything other than "0" in I.R.E. maps and it is not clear what they represent!
- In the <exit> sub-element of <room>: the "tgarea" attribute {target or destination room area}, it detects area exits purely on the basis that a room is in ONE area only.
- In the <exit> sub-element of <room>: the "door" and "hidden" attributes though I have some code tucked away to add Mudlet's door markers for the following values for "door":
- "1" - "open" (green) door mark; "1" is the only value I have seen in IRE XML Map files
- "2" - "close" (orange) door mark
- "3" - "locked" (red) door mark
that code also used the "locked" marking for exits where "hidden" is "1".
- Special exits, i.e. exits with "direction" attributes other that the above (or the other Mudlet supported ones that WoTMUD does not use, i.e. "northeast", "northwest", "southwest", "southeast", "in" or "out") are NOT CURRENTLY supported but my prototype code not released will convert other directions to "special exits".
- In the <coord> sub-element of <room>: the "building" attribute.
- In the <environment> element: the "htmlcolor" attribute name/hex string, there is an internal table that maps the given "id" attribute to the given "color" id attribute - currently the first 16 colors are the {ANSI} ones that the user can adjust in the "mapper colors" tab of the "preferences"/"option" dialog but they cannot modify the mapping of the environment "id" as used for each room to a "color" which represents an ANSI color - I do have plans to add user controls for this in the future but it is not a high priority as the user can just change the room color to a different (>16) user defined colour themselves.
- In the <environment> element: the "name" attribute" - I do have plans to add better support for "environments" in the future.
It is likely that eventually any other <room> or <area> attributes that are not recognised will get stored in the user data for that room or area. In that case the key will be the attribute name with the prefix "xmlParse_". For attributes in the <coord> sub-element the prefix will be "xmlParse_coord_" and for an <exit> sub-element I will probably use "xmlParse_exit_" and then the exit "direction" as one of the lower case words used in the example given. Note that we have recently added per "Area" and a global "Map" user data but you will need to enable a later map format of 17 or more to save the data. This can be done on versions that support it currently with the "Special options" tab of the "preferences"/"options" dialog) - the current 16 is compatible (IIRC) with the 2.1 release version but does not have the ability to store those new user data items.
The reason I mention about "other" attributes is that Mudlet does not directly support door names or room descriptions so if it read an XML file with a <description>...</description> sub-element to a <room> or a <room description="A long description text"> tag or an <exit "doorName"="Studded door" "reverseDoorName"="Metal door"> tag it cannot do anything else with the data. From a coding point of view I would advise that attributes (i.e. things inside the opening tag of a <tag attribute1="something">...</tag> pair or the empty tag <tag attribute1="something" />) are easier to code for in Mudlet/Qt compared to a separate <sub-tag>something</sub-tag> element - though the latter is theoretically the better regarded choice for something like a description text.
tl;dr; Anyone got an update map they are willing to share with the masses - or at least me?
If I can't get the code out publicly that quickly I will fire up a local cobbled together one and convert an XML map to a Mudlet format one that I will place in
my study currently I only have a map from December 2013 which has been cleaned of errors and re-saved in both version 16 and 18 forms.
