Mudlet

[GroderickMashin]

Hello guys! I recentrly remembered I had my repository at sourceforge https://sourceforge.net/projects/wotmud ... source=dlp

I may become more active and try to update some of my old scripts.
I will try to work on the mapper too, by adding a brief movement, following leader, etc
Anyone who is willing to colaborate with me, toss me scripting ideas or wants to make a central wotmud mudlet repository, feel free to pm me.

[Jomin]

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.

[Adael]

I had a bit of a workaround for brief mode. Just had a T/F variable that was set depending on whether the captured room desc was an empty string or not. Then altered the existing method for following room movements. It worked most? of the time, idk if it's the best option but was nice.
Never had too much trouble with the map following along when I was following someone else.

Would be nice to have a way to track movements even if you're moving in the dark. IE base map tracking on commands, not necessarily room name/desc captures for the cases where you can't get the name/desc.

[Adael]

Was chatting with Darth about this. Something that could be useful for fades (if it's possible to code up) would be to tell where people are based on the room name from raven/rat reports. But I feel like this would take a bit of thought...

[Rig]

Incoming fire from fadeh8ers

[Adael]

Only fire I spit is as a RigH8r.

[Jomin]

Was chatting with Darth about this. Something that could be useful for fades (if it's possible to code up) would be to tell where people are based on the room name from raven/rat reports. But I feel like this would take a bit of thought...

You can now do an exact match with the searchRoom command - recent versions will take a pair of optional boolean arguments to specify a CaseSensitive rather than previous CaseInsensitive and an Exact rather than previous Sub-String match on Room Names - though the search is a linear one done in the C++ core of the application so is not the fastest way of doing it. I have been trying to develop a system that will hash the room description and maintain a pair of room-name to hash and hash to room-name tables (which does slow down the variable display in the editor noticeably and increases the profile save file by several megabytes) but which seems to promises almost real time location except for a few places such as Wisdom houses which have identical names and descriptions...

As it happens this is the same scheme that I make a patch for TinTin++ for a few years back and I am carefully ensuring that the same hashing algorithm is used - so giving a room name and a hash could be helpful to give locations between users of both clients if I can finished it off...!