Experiments with maps...

a map of Waterpoint a map of JHM

These two maps, Waterpoint on the left and JHM on the right were produced by the client when it was sent a bunch of data taken from Amit's mapping objects. Amit's code produces a list of room coordinates and exits that can be used to draw a map. The code searches for exits in the 8 cardinal directions (n,ne,e,se,s,sw,w,nw) to determine the initial room coordinates and then applys a bit of physics to ensure that the rooms don't get too close together.

The red room represents the player's position at the time the map was generated, but in addition the client is able to update the position as the player moves from room to room. You can click on any of the blue rooms to cause the message 'walk to #oid' to be sent to the mud. Moving the cursor over a room display's the room's name in the title box under the map.


Some ideas about what to do next, after speaking to Ben.

Experimental Rose Widget

the client with the embedded rose widget

This screenshot shows the client with an embedded rose widget. The widget is based on the Rosette Feature Object with adjacent room names appearing in clickable buttons. Click on a button and the client will send a command to invoke the exit (eg. 'north'). The rose widget is defined in a plugin script, a Tcl program that the client reads when it starts up.

The plugin's code cooperates with a Feature Object on the server which updates the buttons each time you enter a new room. The same code updates the current position indicator on the map.

Plugins and Feature Objects

Some people wanted to try this stuff out so here's a note on what do do to get the client working.

The Rose Widget consists of a plugin and a feature object. Copy the plugin script to ~/.tkMOO-lite/plugins/ and start the client. Connect to Waterpoint and select the Preferences->Preferences Editor menu option to start the preferences editor. Select the Special Forces category and toggle the 'Display rosette' option. The client is now ready to receive information from the feature object.

@addfeature the Rose Widget FO to youself, use '@audit networker for rose' to find it. You'll also need to be a user of the XMCP/1.1 Feature Object '@audit neworker for XMCP'. There's other blurb available about how to use XMCP/1.1, briefly though: Then connect and the client should display the rose buttons.

The command @xmap will start the map using whatever information is currently stored in Amit's mapping stuff. To use the map, stand in an interesting place and 'poke map', the results can then be displayed again using @xmap.

However, to use the map you'll need the map plugin which you should install in the same way as you did for the rose:

That's it. All these details, especially the plugin stuff are subject to change. Give me a shout if this doesn't work. Oh, this only works as advertised on Waterpoint, and you may experience some non fatal warnings from the client if you're not using an up-to-data version.

Arrgh! it seems that this is *only* going to work on client version 0.2.60 and newer (.60 hasn't been released yet, but you could try the .60-dev version if you're feeling brave). Alternatively take your 0.2.59 version, rip out xmcp11.authenticated and put this in its place:

proc xmcp11.authenticated { {flag verbose} } {
    global xmcp11_authentication_key
    if { [request.get current _authentication-key] == $xmcp11_authentication_key
 } {
        return 1
    # should really be up to applications to care about notification
    # but this is simpler for now...
    if { $flag == "verbose" } {
        xmcp11.no_auth_dialog [request.get current _type] [request.get current _
    return 0

Map Improvements, Terrain

a map with images denoting terrain type and density

This is a version of the map that contains small images representing types of terrain. Presently the terrain type and density is defined per room in a private table, but eventually this information might be derived from the site's environment/zone information. Zone information might also be a useful cue to Amit's mapping code, ensuring that rooms that are intentionally close (in the same zone) are less likely to be dispersed by the mapping code's physics.

Letting the Client do the work

the map, assuming a grid based topology, some rooms overlap same map after one iteration of applied vectors

These two maps were created in a slightly different way. The MOO provided data indicating how the rooms in the map are interconnected, and the client decided how the room coordinates should be calculated. The first map shows the rooms placed on a simple grid, some rooms overlap.

Red lines display the direction and magnitude of forces experienced by each room. Rooms repel each other, all rooms act upon all other rooms, not just adjacent rooms. Paths act to attract adjacent rooms. The same basic idea used by Amit's in-db code. The second map shows the results of applying these forces. The result has been scaled down to fit on a 200x200 canvas, in real life the map's surface area has increased.

Where are the people?

people located by dots activity represented by colour

This map shows the distribution of connected users at waterpoint. Each person is represented by a small black dot located 'near' to the square that represents their location. The second image indicates how long the user has been inactive, by setting the colour intensity of the dot. This works in a way similar to the Experimental @whoWidget.