Zugg Software :: View topic - Any reason to still use MudBot for IRE now that CMUD supports ATCP?

Posted: Tue Jan 15, 2008 11:46 pm

For people that are using MudBot on IRE MUDs, is there still any reason to use it now that CMUD supports ATCP natively? I was just wondering if there was any other advantage of MudBot that I was missing?

Posted: Tue Jan 15, 2008 11:58 pm

Some people like its mapper better - it has a nice text-based MXP mapper that some people prefer, but its features (and more) are all available in CMUD's mapper. I think it's more a case of needing to get used to CMUD's mapper.

One thing that Mudbot's mapper does that CMUD's doesn't is store a walk location. When you use MAP PATH 2862, the mapper computes which direction it needs to travel to get closer to the destination for every single room on the map. Thay way, if you're going into combat you can compute the path to somewhere safe first and then during combat just type GO to start legging it, no path computation required.

Finally, the mudbot mapper arguably moves faster. IRE muds only allow a certain number of moves per time period (various skills and items modify the number). Mudbot spams the movement command again every time it gets a "You can't move yet" message, gagging them, until the move registers, but that's pretty simple to reproduce with a trigger.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Yeah. The mapper module is the reason I use MudBot. The ATCP just turned out to be a really nice bonus.

I like the mapper module for the efficiency with which it captures room titles and exits, the speed at which it walks from point A to point B, the way it auto-locates you based on context when it gets lost (searching for rooms with that name and exits, basically), and the ability to locate people easily through triggered echo messages. To expand on the last one: for example, when I scry someone's location, it captures the room name and shows me the room number (or best estimate, when multiple matches are found) and also shows a line that tells me in what area/zone the person was found. I can then just speedwalk to that number to get to the person very quickly. Similarly, if I use the "room find (name)" command, it locates all matches and shows me their full room titles (with zone name) and vnums, and that's something I think should be native in the CMUD mapper.

I have yet to try the CMUD ATCP triggers, though I'll move it up on my priority list now. Smile

Posted: Wed Jan 16, 2008 4:06 am

Yeah, CMUD should actually be more efficient than Mudbot at capturing room names and exits now that it captures the data straight from ATCP. You might want to add something to remove the In the trees above and Flying above and maybe road parts, but apart from that it's been working flawlessly for me.

The speed is interesting and I've been thinking why that might be the case. I know that it spams exit commands when it gets the "you can't move yet" message and that it does that literally all the time behind the scenes which potentially makes it a bit quicker, but what else? You're quite familiar with the mapper code, aren't you? What's different about the way it handles sending movement commands except that?

A lot of the other stuff that mudbot does can easily be done with scripting, especially if you nick some of the code in Vijilante's toolbox. Room find is pretty easy to make yourself and then you can use the same principle to create a trigger for who lists and scrying and whatnot. Once you've found the right room, you can return whatever data you like, perhaps even with an MXP link to print all data on a room.

Harder to reproduce is the auto-locating, mostly because it's difficult to tell if the mapper has lost you or not because when moves start failing, the dot on the mapper doesn't move and onRoomEnter doesn't raise despite the fact that you really are moving. I've pondered a system that compares the name and exits of the current room against the room the mapper thinks you're in. If they don't match, then you're lost. The problem is that if you've got your own room.brief and room.exits ATCP triggers (which I'd assume that you do), they'll be using the #tag command to send data to the mapper. Once the #tag command's sent, it's "gone" and there's no easy way to tell when the mapper's updated the current room, so you'll have to delay the check for being lost. But delay it too much, and you might've moved again. Needs some thought, though my gut feeling is that a simple alarm will probably do - if you're lost, you won't be speedwalking (or the speedwalking will fail and you won't be speedwalking any more) and so the chances of you moving while the alarm is waiting are minimal. Testing will reveal if it's a problem or not.

Once your script has decided that you're lost, it'll use some of Vijilante's code to search for rooms with the right name, exits, and perhaps zone and even terrain (I know you colour your rooms based on terrain) using survey. If that only returns one room, it'll #tele you there and set you as found. If that doesn't work, it'll print a list of possible rooms. You could do some really nifty stuff in this situation with the advanced data that the map database holds - comparing the XYZ coordinates for example and saying "A mountain room in the northeast of the zone on level 2" "A forest room in the south of the zone at ground level" and you can choose the best match or just move again and have another go at finding yourself.

I think the mapper could perhaps include something like room find, but it's not really needed given that you can script it yourself. The mapper trying to work out where you are once it's lost might be a stretch (it wouldn't know how to get the zone data out of survey, for example), but having some kind of event raised when the mapper thinks it's become lost (perhaps even changing the blue location marker red or something too until your location changes) so you could plug your own scripts in would be awesome.

I suppose the major strength of MudBot is that it does all this already, for free, with no scripting required. Getting this to work in CMUD would require an epic effort and anyone willing to put in the time would probably want reimbursing.

EDIT: Wow, that turned out longer than I expected. Apologies - I might've gone into too much detail with some of it, or repeated myself or something, but I'm loathe to go back and change it now.

Posted: Wed Jan 16, 2008 4:23 am

Further thoughts on finding yourself:

#trig {Room.Brief (?:Flying above|In the trees above)? (.+)} {#tag %trim(%1) name;#alarm +0.5 {#if (!@RoomEntered) {#say Lost, start finding me}};RoomEntered=0} {regex|telnet|param=200}
#event OnRoomEnter {RoomEntered=1}

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Actually the things Fang mentioned are part of why I layed out all the different searching on the map in functions. The goal was to make it so that anyone could make triggers to capture information and not really have to worry about how to do the searches. I probably have to make the FindRoomFromNearby a bit faster with some new query logic in order for it to handle getting lost fast enough to beat out MudBot.

I think detecting getting lost is actually very easy to do with ATCP. Basically trigger on the ATCP information and if onRoomEnter does not occur within an extremely short period of time you are either lost or were not moving. Either way you can basically figure you need to find where are before your next step occurs.

Edit: I waited way to long to post the above. Anyhow use a second state with a type of wait and a param of 100 rather then an alarm. 100ms should be enough for the mapper to update and if it didn't then there is a problem.

Posted: Wed Jan 16, 2008 4:59 am

Absolutely Viji, that's why I mentioned using your toolbox functions (or at the very least stealing their searching logic) in my post above. @FindRoom() was what I had in mind - I'll post my question about @FindRoomNearby() in the toolbox thread.

Good call on a wait state, but I'm not sure if 100ms will be long enough - I wouldn't know where to put the "am I lost?" check, anyway - when does the mapper update you? I was under the impression it actually updates your location when it receives a prompt following the room description, so you'd need to put the logic where your #tag prompt command is and not where the #tag name is. The trouble with doing that is that you recieve many prompts that don't follow room descriptions - perhaps putting it in an exits trigger (which would be quite annoying because previously, there wasn't an exits trigger, CMUD handled those on its own) would be close enough to the prompt that updates the location in the mapper. But the room name might be too far for 100ms to catch it - like I said, testing will reveal the number and location that works best, though knowing more about when the mapper updates would help too.

Novice Joined: 01 Dec 2007 Posts: 49

For users, doing complex scripts is way beyond their means. Mudbot is completed and simple to use, and doesn't require any complex knowledge to use it. Simple features like "[Warning: Identical rooms found... 1 in this area, 0 in other areas.]", or eating a pear when underwater, mxp elements, etc. are enticing features. To answer Zugg's question, I believe that's reason enough for the majority.

In my hopes to never use Mudbot, I made a room search function (in zMud) which worked fairly well. I still prefer looking at it to looking at Mudbot's map although my Imperian map takes considerable time to load - which stalls zmud/cmud working while it does start up. The script library is a good source to provide the mudbot mapper features one day, but until then...

Posted: Wed Jan 16, 2008 12:34 pm

CMUD's package library means that once a nice person has done this coding then nobody else needs to. That's why we're discussing ways of doing it.

Novice Joined: 01 Dec 2007 Posts: 49

Yep. Mentioned that exact point in the last line.

Although, I have to wonder, is it worth the effort when mudbot is readily provided and essentially "completed"? The common cliche comes to mind, "Don't reinvent the wheel".

A bit off point: when you trigger char.vitals and simply have it #SAY, should it be replacing the prompt line? I'm more interested in catching the <eb> tags of the prompt and still show char.vitals.

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

This forum and Zugg are all about making CMUD "completed" or the very least better.

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Wed Jan 16, 2008 1:46 pm

(I can't split your post, Doxedon, because you had other questions in it, if you have more to say on this topic, please start a new thread)
Basically, the Char.Vitals element doesn't have a line of its own, it's invisible data inside the visible text that the MUD is sending. Trying to convert this invisible text into visible text causes display problems (try using #sub on it :P) - you should only really do it for the purposes of setting up a trigger on that data. Once your variables are being set properly in respose to Char.Vitals, you should remove the #say part. If you want to add the NL data into your prompt, use a prompt trigger and the #sub command. The display problems have been reported and will probably be fixed at some point, but it's not a high priority.

And yeah, this thread is basically Zugg asking what features of MudBot CMUD still lacks, and we named a few. If CMUD had native support for some of the concepts we've discussed (and some of the other stuff we've discussed here) then minimal coding would be needed on the part of the end-user.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I've just tried the ATCP support in CMUD for the first time. I have no ATCP triggers right now, so it's just a matter of removing MudBot from the connection chain and getting the ATCP messages sent directly to CMUD. I walked around for a minute and saw one or two ATCP lines echo'd directly to my output window, stuck in the middle of my prompt. I know it's more of a bug than a missing feature, but it's a reason one might stick with MudBot and not use the ATCP in CMUD just yet, so I thought it worth mentioning here.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Where do you get MudBot? I would like to look at it.

Posted: Wed Jan 16, 2008 3:54 pm

There's a thread about running MudBot with any MUD written by yours truly, as well as customised versions for different IRE MUDs if you play one already (Imp Lus).

Apprentice Joined: 03 Nov 2007 Posts: 132

I use the ATCP support heavily with CMUD. There is a visual bug where sometimes you can see part of the ATCP line but in terms of actual functionality it works perfectly and is much easier to integrate into a system.

People who still use MudBot use it for the mapping abilities which are quite good. I would use MudBot for that if using it didn't mean I couldn't use the native ATCP support in CMUD as well as some issues with wrap width it has.

Posted: Wed Jan 16, 2008 5:20 pm

I've coded for Zmud/Cmud many of the items that were mentioned for MudBot.

When I scry someone it lists either their room number or a list of room numbers and the associated zone. If it's unique I just type a simple command to walk to that stored number.

I also have a similar function that I use to try to find a room name I feed the function. It returns in one list exact matches, and in another list partial matches. So I can either enter part or all of the name and I can use both exact matches and partial matches to find what I'm looking for.

Find was the biggest headache but I finally settled upon an algorithm that is both fast and accurate:

1) If the room name is unique, teleport to that unique name.
2) If there are more than one room with that name then compare exits. If it is now unique then teleport to that room.
3) If there are still more than one match then start comparing the names of adjacent rooms. This is where is starts getting complicated as I then have to send a command to the mud to squint at adjacent rooms and return the names seen. If with the adjacent rooms information I'm now unique, then switch to that room.
4) If I'm still not unique then just change position to the first room on the list if I'm not currently in any of the remaining possible rooms. If I'm already in one of the possible rooms then do nothing.

This sequence of searching is pretty fast and is about 99.9% effective. I subsequently improved the algorithm by adding in a new feature. Sometimes because of the way abilities work you know that you've only been moved by one room from where you previously were. So I created a variable called possible rooms which I use to narrow the search from the start. If I know I've only been moved by one room I populate the possible rooms variable with the rooms that I could have possibly moved to. Then I call my normal find function. The normal find function uses this information if it is available to narrow the search from the beginning. Instead of trying to match on any one of 20,000 rooms, it simply tries to match on the 5 rooms I have in the possible rooms variable.

Most of this functionality could be integrated into Cmud itself to make it far more capable. I'd love to see functions such as these:

find <list_of_possible_room_numbers> - Tries to match based on room name and exits and limits the search to the list of room numbers if a list is provided. Searches all rooms if a list is not provided.

find_adjacent - Same as the general find above except that it auto-populates the list of possible rooms with rooms that are adjacent to your room.

room <partial or full name of a room> - Returns the room number and zone of an exact match, if there is one. Otherwise it returns all rooms numbers and zones of rooms that partially match.

Additionally, a small note about ATCP. I've found it repeats the room name and exits twice when I change rooms, but it gives the information only once when looking at a current room. I've been able to use this to very accurately detect when I'm actually moving.

Posted: Wed Jan 16, 2008 6:28 pm

Larkin: Be sure when you use ATCP in CMUD that you turn OFF the MCCP option. There is a bug in all of the IRE games when using ATCP and MCCP at the same time. Their MCCP code buffers the ATCP messages causing them to get sent in the wrong packet. I'm hoping they will eventually fix that. Otherwise, I haven't seen any ATCP messages get echoed on my system here.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Got it! Thanks for the tip. (I knew this, but had forgotten to disable the MCCP right away.)

Beginner Joined: 17 Jan 2008 Posts: 10

I used to play IRE games a few years ago and one of the things I spent a lot of time on was getting the automapper in zmud to work correctly with them.

I have decided to start playing them again and I was excited by what I read about CMUD and ATCP. I was looking forward to not having to worry about the automapper at all. Reading the documentation I turned off MCCP and ran the autoconfig after deselecting the room description option. All other options and settings were left in their default state using the built in profile for lusternia. Just doing a very simple test of walking around a town it was very easy to have the mapper break. I have not looked into exactly what is going wrong yet as my goal was to see if it would "just work".

Non cardinal direction room exists (in and out) are not handled by default. The mapper seemed to stop working after I merged two rooms, resetting my location did not help. I also had the mapper get lost on a few rooms because of changing room descriptions (time of day text issues most likely).

I loved ZMUD and I believe I will love CMUD, but the promise of ATCP "just working" so far is not true. I am more than willing to put the time into figuring out what is going wrong and then setting up custom scripts to work around things (or submitting bug reports as appropriate) but the average user will not. Until the mapper can work with no configuration beyond the auto setup it is not going to be used by most players.

Posted: Thu Jan 17, 2008 11:28 pm

Please create a separate post for problems and bug reports. The mapper is very complex and there are many things that can be done to improve how it works. The merge issue can be helped by using the #LOOK command to reload the proper room name/description. The mapper doesn't handle rooms with different descriptions by default unless you uncheck that option in the mapper preferences. Every MUD is different, and even with ATCP the CMUD mapper needs to be able to handle most *any* MUD which means it is always going to require some sort of tweaking and configuration. For example, the simple matter of moving in an incorrect direction can produce different text on different MUDs, so there is no way for CMUD to magically automatically undo incorrect movement. Different MUDs support different custom directions and CMUD cannot magically guess where you want to create a new room when using "in". Please see the documentation on how to use non-standard directions in the mapper. Programs such as MudBot will always have the advantage with novice users since they can be tuned to work with the specific MUD "out of the box" since they don't need to work with other games.

Beginner Joined: 17 Jan 2008 Posts: 10

Enchanter Joined: 09 Sep 2007 Posts: 605

Wizard Joined: 14 Oct 2000 Posts: 1368