Some queries about Mudlet & its Mapper 2.1...
Posted: Mon Mar 11, 2013 5:05 pm
Hello, I'm new to Mudlet, though I am active on the alternative Open Source MUD client TinTin++ and I've been looking over your recent stuff. I'm running a Debian i686 squeeze (with backports) system and after an overnight build of the QT 4.8 SDK (cause the Debian Qt packages are currently only at 4.6.3 which I understand is not new enough to build the latest Mudlet) I managed to build a Git clone (from 6th March). I have some things that I'd like to throw into the pot as it were so any feedback would be appreciated, things here are mainly about the mapper but I touch upon a couple of other areas as well:
- For the right click menu on the "Geyser"? mapper in 2D view mode I note that the "spread" and "shrink" items both bring up the same "spread out selected rooms by" dialog box.
- The same right click menu has a "lock" item which does not appear to change the speedwalk flag that the roomLocked(ID) reports on, which is what I would have thought it would affect? (I recognise this as being equivalent to the TinTin++ room AVOID flag!)
- There does not seem to be anyway of programmatically examining the exitStub status of the exits from a room. I'd suggest a hasExitStub(RoomID, Exit) function analogue to the hasExitLock() one - also it would be useful I think if a control for the exitStub could be placed onto the exits' Dialog box that is called up by the "exits" option on the 2D mapper right click menu.
- I am impressed by the 3D view that the mapper offers, we can't manage such a thing I think in TinTin++! but what are the slider controls: the left most one seems to be "zoom" and the right one "rotation about the North-South (y) axis" but I can't describe the action of the two middle ones?
- In the 3D view I note that "phatom" green rooms are drawn in between rooms that are NOT on the currently displayed Z axis value but that they are drawn at full opacity and the blue paths are not drawn between such blocks whereas the rooms that are "off" the z-axis are drawn translucently.
- In the 3D view no right click menu functions are available but I guess this is a work-in-progress.
- Would it be useful to have bottom and right scroll bars in the actual map drawing area with controls that expand/contract to show how much of the map of the current area is being displayed? A separate third one could give an indication of the z-axis which I understand the five bottomĀ±1/topĀ±1/1 level buttons would adjust the size of the slide control and the + and - buttons on the top row of the controls would adjust the position.
- Having requested and implemented a TinTin++ command to change a Room's ID number I think it would be useful to have a function in Mudlet to do the same sort of thing, it can be quite useful to be able to sort the room ID into contiguous blocks of numbers for each area. It makes importing and exporting area maps easier...
- I note that at least one of your developers had some input into a Mud Mapping Protocol which is no longer directly available from http://www.mudstandards.org (dead URL) but the Wayback machine had a cached copy. I've done some unreleased work on TinTin++ to permit PARTIAL map imports/exports (the release version is designed to hold the entire map data in one file but I think I have found a way around that with a room flag to indicate that a room is a dummy which can be replaced by a later import of a real room with the same RoomID) and I can see a way to use mudlet's exitstub() to implement the same without needing a "dummy room". Has anyone put together a schema file that describes sufficient detail to build a mudlet map from an XML file? I'm part way through something that can export a TinTin++ map in an XML form but the biggest issue I see with importing it to Mudlet is that the position that one room has in TinTin++ relative to another is entirely relative and is recalculated each time one moves in the map whereas the Mudlet idea of where rooms are is fixed and editable by user intervention. In TinTin++ rooms can be spread out with so called void rooms that normally have just two exits and no weight - indeed they would be similar in positioning (but not appearance) as the "phantom rooms" mentioned about which has just given me an idea about how it might be possible to describe a "well formed" TinTin++ map (where "well formed" means that all rooms have a static physical relationship to each other and do not adopt different relative positions if one take a different path between them.)
- Each area is mapped individually but other than this are there any other features that can be assigned to an "area"? In some situations in a MUD I imaging that considering each area as a separate entity could cause the user to feel unreasonably isolated from activity in adjacent areas with possibly game hazardous results! If a Mudlet map "Area" is allocated to the whole of a contiguous game area could it be useful to have subdivisions into "SubAreas" which might have different default "environments" (whatever they are ) or background/path/room colours?
- Has anyone considered getting Mudlet to support the Mud Master Chat Protocol, a peer to peer MUD Client communication system? I see that Mudlet has a built-in Internet Relay Chat client and there is some overlap in functionality but in TinTin++ it can be used to communicate between multiple instances of the MUD Client on either the same or different hosts and I wonder whether it would be useful if Mudlet also could communicate with other MUD players this way?