Zugg Software :: View topic

Newbie Joined: 29 May 2009 Posts: 1

I just started using CMUD and an IRE mud.

After playing around, I noticed that CMUD had a hard time mapping the mud. This prompted me to delve more into how my triggers were reading the output. The end result was a different method (for me) for analyzing the mud. I can now waltz through the mud while mapping with no problems.

In reference to my subject question, I would like to know if my script method is going to bite me in the rear later as I add more complex behavior. Here it is:

I have only one trigger, a perl regex ansi that reads every line. That's it. It is the only trigger I intend to have. The code in the trigger does only two things: (1) detects the prompt, (2) dumps anything else (append) into a variable. So, I get a dump of everything in between the prompt. Once that dump is complete (next prompt received), I kick off an event, which starts the analysis of what I just received. Then, the dump variable is reset.

So far, it works beautifully and simply.

Regarding CMUD's capabilities, is this a good path?

Posted: Fri May 29, 2009 4:14 pm

Possibly, it depends exactly what you're after. You may find that speed is an issue depending on how exactly you parse the data. If you're doing a lot of comparisons, you may well find that it'll be much slower than using a trigger because of the way CMUD compiles its regexes and script in advance.

To address your mapper concerns specifically, you'll probably find it best to use ATCP, which is discussed here. If you want some slightly more complex processing of the way the mapper handles the ATCP that comes in, you can create telnet suboption triggers for the room.brief and room.exits events that come in - they'll overrite the default behaviour and you'll be able to handle things like "In the Trees Above" and whatnot. If it ain't broke, don't fix it, but the more complexity you build into your variables-and-events system, the slower you'll probably find it'll be.

Most of the IRE MUDs have an option to set the length of lines the MUD sends you, and they have the option to set it to 0 - this removes the automatic, server-side word wrapping and makes it much easier to handle long messages with variable wrap-points. You can use a single trigger for channel capture, for example, with this set. You'll probably find that doing that, coupled with normal triggers, will be simpler, faster and more versatile than something you built yourself.

Novice Joined: 29 Jan 2006 Posts: 40 Location: Aardwolf

CMUD is already reading all MUD output and testing it against all triggers to see if there's a pattern match. Having a trigger that reads all MUD output again with subfunctions that test it for certain patterns seems redundant?

But if it makes you happy and works for what you need it to work for, then go for it. There's no Script Police out there that'll tell you how not to do something. :)