Some queries about Mudlet & its Mapper 2.1...

All and any discussion and development of the Mudlet Mapper.
Post Reply
User avatar
SlySven
Posts: 920
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Some queries about Mudlet & its Mapper 2.1...

Post by SlySven » 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! :o 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?
Anyhow I've gone on long enough for now so I wonder what thoughts I might have prompted.

User avatar
chris
Posts: 493
Joined: Fri Jun 17, 2011 5:39 am

Re: Some queries about Mudlet & its Mapper 2.1...

Post by chris » Mon Mar 11, 2013 9:39 pm

Quite a few of your comments I think are just things you need to script in lua. For the xml map importer, you can look at my cMUD Map Importer to see one example of this. The same goes for the area bit. Most games have sub-areas that are not spatially compatible with an overall map. If yours differs, you can always use some lua magic to achieve the desired goal of one overall map with visual cues for the sub area.

The 3D view I've always seen as just a toy and have never delved into it.

getExitStubs(roomid) gives you a table of the exit stubs.

User avatar
SlySven
Posts: 920
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Some queries about Mudlet & its Mapper 2.1...

Post by SlySven » Thu Mar 14, 2013 12:08 am

Thanks Chris, I'm beginning to get a better idea of what does what and how it all hangs together. ;)

One thing I pointed out I CAN see the details for:
SlySven wrote:...
  • 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!)
...
Ah, I found that it did Lock the room but I wasn't examining the information about that in the correct way! Anyhow it does indeed lock the room but there is no easy way to undo the effect in the same manner, digging in the source code reveals it is all in T2DMap.cpp, specifically, in the function void T2DMap::mousePressEvent(QMouseEvent *event) which begins at line 1900, the following chunk (lines 2152-2166):

Code: Select all

            //QAction * action5 = new QAction("user data", this );
            //action5->setStatusTip(tr("set user data"));
            //connect( action5, SIGNAL(triggered()), this, SLOT(slot_setUserData()));
            QAction * action6 = new QAction("lock", this );
            action6->setStatusTip(tr("lock room for speed walks"));
            connect( action6, SIGNAL(triggered()), this, SLOT(slot_lockRoom()));
            QAction * action7 = new QAction("weight", this );
            action7->setStatusTip(tr("set room weight"));
            connect( action7, SIGNAL(triggered()), this, SLOT(slot_setRoomWeight()));
            QAction * action8 = new QAction("exits", this );
            action8->setStatusTip(tr("set room exits"));
            connect( action8, SIGNAL(triggered()), this, SLOT(slot_setExits()));
            QAction * action10 = new QAction("letter", this );
            action10->setStatusTip(tr("set a letter to mark special rooms"));
            connect( action10, SIGNAL(triggered()), this, SLOT(slot_setCharacter()));
...
calls this function at line 2709:

Code: Select all

void T2DMap::slot_lockRoom()
{
//    if( mMultiSelection )
//    {
        mMultiRect = QRect(0,0,0,0);
        for( int j=0; j<mMultiSelectionList.size(); j++ )
        {
            if( mpMap->rooms.contains( mMultiSelectionList[j] ) )
            {
                mpMap->rooms[mMultiSelectionList[j]]->isLocked = true;
                mpHost->mpMap->mMapGraphNeedsUpdate = true;
            }
        }
//    }
//    else if( mpHost->mpMap->rooms.contains( mRoomSelection ) )
//    {
//        mpHost->mpMap->rooms[mRoomSelection]->isLocked = true;
//        mpHost->mpMap->mMapGraphNeedsUpdate = true;
//    }
}
So which would be more appropriate, adding another "slot" :? to "unlock" (all the selected rooms if more than one is selected) by setting the isLocked to false or changing it to a dialogue that reports the current setting (of each for a multiple selection) to permit changing either way? I guess the former is the simplest and easiest to implement...

User avatar
chris
Posts: 493
Joined: Fri Jun 17, 2011 5:39 am

Re: Some queries about Mudlet & its Mapper 2.1...

Post by chris » Thu Mar 14, 2013 12:15 am

I like the notion of a 'smarter right click menu' based on the selected rooms properties for things like locked rooms which are natural toggles. So if locked, unlocked is displayed, etc. I can't think of any other scenarios where this toggle comes into play, but it might in the future.

User avatar
SlySven
Posts: 920
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Some queries about Mudlet & its Mapper 2.1...

Post by SlySven » Thu Mar 14, 2013 8:01 pm

OK I've done a trivial copy of the lock code and made this new slot_unlockRoom() set the ->isLocked to false and it does what is needed atm.

Also:
...
  • 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.
...
It seems that the prompt and title text for the QInputDialogue of line 2651 of T2DMap.cpp (at top of T2DMap::slot_shrink()) was not changed when it was derived from line 2606 from T2DMap::slot_spread() but the adjustments that it makes to the room(s) location(s) are in the opposite sense so it should function correctly.
...
  • 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?
...
Examining/editing the mapper.ui in the ui subdirectory with the handily created by building the Qt SDK "designer" tool I filled out the tool-tip entries for all the controls and found that the four sliders are Zoom (well Scale, but it does the same); and Z, Y, X rotations in that order from left to right.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests