Zugg Software :: New Mapper

In CMUD v2.x the mapper was directly ported from zMUD. This caused many problems. In CMUD v3.x the mapper was rewritten to take better advantage of the CMUD architecture. The main changes are:

New Database format

The Mapper now uses SQLite3 database instead of old Microsoft ADO/MDAC (MS Access) database format. Unfortunately, this also means that zMapper cannot read the CMUD v3 map files directly. And external Map Conversion program is available in the Downloads area that allows conversion to/from zMapper and CMUD v3.

Over time, more zMapper functions will be added directly to CMUD so that this extra conversion step is not needed. CMUD v3 will automatically convert your old v2 maps into the new format, so this database change should be transparent to the majority of users.

Removing the dependence on ADO/MDAC makes CMUD easier to run on non-Windows systems and makes the mapper more stable.

Changes to Room Scripts

Room scripts have been moved out of the map database and into the user session packages where the rest of your scripts are stored. This will be the biggest change for most mapper users since the conversion of your scripts from the old mapper to the new mapper might not work completely.

Room Scripts are now handled in v3 via new OnEnable and OnDisable scripts attached to Class folders. Each Room with a script is given a Class folder stored within the main Map Object (superclass). When you enter a room, the corresponding Room folder is enabled, causing the OnEnable script to run. Your previous Room Script will be copied into the OnEnable script for the new room folder. When you exit a room, the Room folder is disabled and the optional OnDisable script is executed.

This new method works great for simple scripts. However, if your previous Room Script created settings, such as buttons, triggers, aliases, etc, then you should move those out of the OnEnable script and just store them within the Room folder as normal buttons, triggers, etc. When you enter the room, the scripts within the Room folder will be enabled, and then disabled when you leave the room.

This makes room scripts a lot faster than in v2 since v2 would cause the scripts to be deleted and recreated each time you entered a room. v3 just enables and disables the folder, which is much faster. These changes also allow you to edit and manage your room scripts the same way you are used to managing normal scripts. It allows you to use the Script Editor rather than the plain text window the mapper used to provide for your room script.

You can still view your OnEnable script for your Room in the Room Properties dialog in the mapper. However, to edit the room script you will need to click the Edit Script button, which will actually take you into the normal Package Editor screen for the Room folder that corresponds to the room you were editing.

Dockable Windows

Both the main Mapper window and the Room Properties windows are not fully dockable windows in CMUD v3, just like your session windows. Some people like to dock the mapper to the right side of the screen, and then dock the Room Properties window below the mapper.

The Room Properties window was redesigned to make it function better as a docked window. The main tab of the properties now includes a graphical compass that can be clicked on to move around the game. Tabs in this window are selected on the right side of the properties, rather than along the top.

Multiple locations on a map

One of the big changes to the map is the addition of a new setting called a "Location Object". You can view your Location Objects using the new View/Locations menu option, or you can view them in the settings editor using the View/Show/Locations. A Location is a marker on the map. By default the marker has a blue color. But you can define additional markers using the #LOCATION command. Each location can have a different color and are shown on the same map. You can have multiple location markers within a single session, or you can have location markers in different sessions, allowing you to track multiple sessions in a single map window.

While the mapper can display multiple locations simultaneously, it can only speedwalk with a single location at a time. This special location is called the "tracking location" and is displayed in the lower-left corner of the mapper window. If you have multiple location markers, you can click on the tracking selection in the lower-left and select which location you wish to track. You can also change this location using the #TRACK command. When you double-click on the map to speedwalk, the current tracking location will be used to send speedwalk directions to the MUD.

Scripting the mapper using various %roomXXX functions can also be done using multiple locations. The #LOCATION command sets the current location marker to be used by the scripting functions in the current session. The #WITHLOC command can be used to call scripting functions on different location markers. For example, this architecture allows you to script and track other party members, or pets, or anything else that might benefit from it's own location marker. Location markers are saved with your session, so they are persistent.

Each location marker can also be referenced wherever you would normally use a room key or number using the syntax ":locname". For example, to speedwalk from your current location to the location marker named "Party" you could use: #WALK :Party

Shared Maps

Each session can have it's own map window, or you can share a single window between multiple session. The v3 mapper separates the map "window" from the map "database". To share a single map database between multiple sessions, create a separate Shared Package and then drag the Map Database Object in your session package into this new Shared Package. Add the shared package to each session you want to share the map. The Map Object in the settings is basically the map database. When you open a map "window", you associate the window with the database via the Tracking location. Each Location is associated with a single map database, so by selecting a tracking location, you are associating the map window with the database used by that location.

By allowing multiple sessions to share the same database, CMUD v3 will no longer create multiple copies of the same map database in memory, which is what it did in zMUD and CMUD v2. This saves a lot of memory and prevents database collisions when multiple sessions are using the map. Allowing a single map window to display multiple location markers means that you don't need a separate map window for each session.

Also, separating the map "window" from the map object "database" allows you to script the mapper without the map window being open.

GMCP Support

GMCP (Generic MUD Communication Protocol) was developed in 2010 by several MUD client developers and several MUD admins/coders. It's purpose was to facilitate rich data communication between the client and server "behind the scenes". One of the biggest uses of this protocol is that it allows the MUD to send room and map information to the client.

CMUD v3 supports GMCP mapping. This is enabled by default. As you build a map of a MUD, CMUD is using the room name, exits, and vNum data sent by the MUD. When speedwalking, CMUD uses the vNum data sent by the MUD to ensure your location marker is in the correct room.

GMCP enables almost perfect and seamless mapping for MUDs that support it. In addition, you can create GMCP triggers in CMUD v3 to extract other data being sent by the MUD. With GMCP, just doing a simple "look" on the MUD will cause the mapper to update your map location. No more getting lost! At least not in the areas where the MUD sends GMCP data. Keep in mind that the MUD might not send GMCP data in all areas to make it harder to map certain areas, such as mazes or guild halls.