Zugg Software :: View topic

Novice Joined: 30 Apr 2006 Posts: 45

Is there going to be any way to make processing largely atomic in CMUD? It's one of my largest gripes with zMUD right now. I'll make a triggerset to open/unlock/etc. doors and spam in a direction, and it'll try to open the door six times and lag me. I add a variable to not open more than once, and all six lines start processing before the variable even gets set. I stick everything in #priority (including the conditional) and it does no good.

I saw that CMUD is eliminating #priority in favor of not receiving more lines from the remote host, but I just saw another post saying %param is flaky because other triggers can fire at the same time as the one that's firing. So what about trigger priority? How does that matter if they all go off at once?

Not to mention the fact that it's actually less efficient to run multiple triggers at once in most cases. I dunno if anybody's bothered to think about this, but modern multitasking systems on single-processor systems are actually less efficient because of the additional overhead of switching. Multitasking can save you time if your other threads are waiting on hardware interrupts or information transmission, and it can save you time if you have multiple processors all actually acting at once (including graphics coprocessors for example)...but just running a multithreaded application on one processor that's not actually waiting on anything is nothing but a slowdown.

Not that I have speed problems...zMUD is efficient enough if you don't have 300MB settings files. ^_^ But...it is so difficult and annoying to program for a system that isn't deterministic. I just want the simple mode..."Get information from the remote host...start matching triggers...if one matches, stop, run it, start matching again...stop when done. Get more info, rinse, repeat." That's all I want. Will this even be possible?

Posted: Thu Jun 22, 2006 5:37 pm

One of the new features of CMUD is to allow you to prevent of the processing of other triggers (in the same package, if memory serves correctly). In other words the option is now there to not run Triggers B, C and D if Trigger A matches.

I'm not sure I understand the problem you're having with door scripts spamming, but then again I'm minimalist in terms of trigger writing. Maybe you can post an example.

Enchanter Joined: 10 Oct 2000 Posts: 698

It would appear he has something like:
#TRIGGER {The door to the (%w) is locked} {open %1}

and then he types something like;
e;e;e;e;e;e;e;e;e or,
22e;4n;etc...

and zMUD sends all the direction stuff as one block in FAST MODE

SLOW MODE (#SLOW .path) will prevent this behavior as will mapper scripting the exits and/or SAFE MODE if he uses the mapper.

But I think jakj is more interested in CMUD's behavior or at least I hope that was the point of the post as it is in the CMUD forum.

Novice Joined: 30 Apr 2006 Posts: 45

Yes, I want to know about CMUD, because zMUD is pretty much becoming obsolescent. When CMUD is usuable as a main client (first release) it will be vastly superior to zMUD and will fix a lot of my extreme frustrations with it. So many other clients don't have these frustrations, but they also have about as much flexibility for MUDding as a toaster oven, which is why zMUD is still the best.

I am aware that most problems as stated have workarounds. Besides the fact that working around every single problem is not fun and is not efficient, it's also not the point. What I want is this.

CMUD receives a line of text, or determines it's a prompt input, or whatever, and starts matching triggers. It is not matching other triggers at the same time and firing them off, and it is not processing further text from the MUD...it is just firing the first trigger that matches based on priority. That trigger finishes, it should move on, and start on the next trigger that matches. Still nothing else going on but matching that trigger...not matching other triggers, not starting to process further input from the MUD. When it finishes and no further triggers match that line, it can move on to the next line.

Simple deterministic processing. I always know what's going on at any time because it's not trying to do 30 things at once. Right now, a trigger can match and set a variable, but other triggers are already firing on the -same- line, different triggers, that do different things and that check that variable. They do the wrong thing, because from their point of view, the variable is not set yet. So the first trigger sets its variable, all the other triggers screwed up, and at that point it doesn't matter because the state is completely mangled and I have to reset variables and issue status commands to my character to get all the numbers right. Let alone if this happened in the middle of combat and I died as a result.

And I know about slow-walk mode. The behavior I'm trying to get is not opening the door and continuing on the path, but simply opening the door once and stopping. So if I type "#10 east" it should have 10 copies of "the door is closed" followed by one "you open the door" and stop. Right now I get 10 copies of "the door is closed", one "you open the door", and nine "the door is already open" which lags me for a full 9 seconds on my MUD. And this is with setting a variable on the first open to not try opening again, with EVERYTHING inside #priority.

Posted: Thu Jun 22, 2006 9:44 pm

What are you describing

Magician Joined: 29 Nov 2005 Posts: 482

So if I type "#10 east" it should have 10 copies of "the door is closed" followed by one "you open the door" and stop. Right now I get 10 copies of "the door is closed", one "you open the door", and nine "the door is already open" which lags me for a full 9 seconds on my MUD. And this is with setting a variable on the first open to not try opening again, with EVERYTHING inside #priority.

well for one it sounds like you have a bad set of triggers anyways. The only way to have that config is if you have a trigger for opening a door which needs to be moved into a condition statement of some sort.

Here is my suggestion for whats its worth
Dont do #10 east anymore

do #SLOW .10e

Create a trigger that does the following.
#TRIGGER {The door is closed} {#STOP;open door;#STEP}

Novice Joined: 30 Apr 2006 Posts: 45

Thank you Tech. I hope you're right.

edb, I appreciate you trying to help, but I am NOT doing paths, fastwalk or slowwalk. I am manually typing directions with the number pad. The areas I frequent have a bunch of detect-invisibility aggressive mobiles that render the zMUD map next-to-useless. I have a very fast connection, so when I know I have to go all the way down a hallway and turn right, I just push the 4 key a bunch of times until I see that I can't go anymore, and then I switch to the 8 key. If all I'm doing is hitting a wall, there is zero lag and it's as fast as a slow-walk. If there is a door that gets opened, it lags a second for every time I went past the door before it opened.

I'll give you more detailed examples since you say my triggers are bad. Be nice to know what I'm doing wrong.

Trigger: The door is closed. --> #if {@MovementDirection & @JustTried != "open"} {JustTried = "open"; #send {open @MovementDirection}}
MovementDirection is set when I press a number pad direction and is cleared any time I enter a non-movement command.

(I already tried changing it to {#send {open @MovementDirection};#send {@MovementDirection};@MovementDirection = ""}. When you open an exit that isn't a door, it still lags for a second. And if you happen to be trying to open a wall (i.e. no exit), it lags for TWO seconds. Don't ask me why; it's dumb, but that's how it is.

And as I said, putting the entire conditional in #priority doesn't work. It still processes other lines, for which JustTried is still "". By the time JustTried is set to "open", I'm not moving anymore.

(If a trigger fires that says @var = "abc", and a second trigger with lower priority fires on the same or a subsequent line with #send {say @var}...what do YOU think should happen? As it stands with zMUD, @var won't be updated. I hope it will be in CMUD.}

Magician Joined: 29 Nov 2005 Posts: 482

also have you tried the stop triggers processing option on this trigger in cmud. Its what it is for. although i admit it might now be working atm.

The slowwalking applied to your post about #10 east

Thats you manually inputting a command do repeat east 10 times. i gave you an alternative method to be able to type that and get the desired result. Or just not spam so much realize where doors are. There are some things that can be adjusted to suit you needs as you will find given in the examples above and below.

If you just want to spam into a door manually by hitting the 6 key over and over its going to be hard to avoid getting that message over and over until it realizes the door has been opened short of telling it to not trigger anything else after that command is processed and i still have a few questions about stop processing triggers myself as i believe it decides that based on a priority tree.

However the post i gave was relevant to your original post. Now you have changed it and as such its going to be hard to not get the results you got without changing the way you do it. I seriously suggest looking into stop processing triggers. (If its working the way its intended) or at least how i understand it. Then all triggers below its priority will not process when that trigger is activated. However this still leaves the simple problem of you running into a door and it trying to open it while you are still hitting keys. You will get that message for each time you hit the door because you didnt wait until the door was opened.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Magician Joined: 29 Nov 2005 Posts: 482

Also realize that & is no longer valid i believe its now && but id have to double check that. My basis for that statement is purely off memory.

From zuggs changing zmud to cmud scripting

The | and & operators are changed to || and &&

Newbie Joined: 17 May 2006 Posts: 9

I understand what he's talking about. As I have the same issues with my mud, its just that it doesn't bother me as much but would be cool to have fixed. Basically I have a trigger setup to open a door if I walk into and its closed. So if I'm spamming a direction (I also use the numberpad) and I run into that door and its closed, it will send the open door trigger, but if I continue spamming the direction, the directional spams are going through before the triggered command. So it will get say 5 'door is closed' messages before it finally opens it. And then when it opens it, it will send 5 more open door commands. I can perhaps paste an example when I get home tonight.

Magician Joined: 29 Nov 2005 Posts: 482

i think we understand the problem. However unless you change your scripts to handle many of cmuds new features this is going to happen because you are continuing to hit a door while its waiting to open the door. Most muds have a sense of lag associated with opening of doors. ZMUD/CMUD cant control that nor can it control the user who is spamming into a door. If you change your scripts for your FORCE OPENER to properly prioritize your triggers etc. And then on the this door is closed trigger change that to stop processing all triggers until that one completes (since its a new option) then you wont get multiple problems like that. you will still slam into the door and get the door is closed message. That comes from the mud. However you wont get the 5 attempts to open the door after its already open.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I am guessing that your still hitting directions after having bumped into the door, and some portion of your script that you didn't mention must be clearing JustTried. That leaves the trigger with a condition that will send its response do to user error. A much better way to handle this type of thing is to use some trigger conditions and a few other triggers.

#TRIGGER "doorOpener" {^The door is closed.$} {#SEND {open @MovementDirection}}
#COND {^You open the door to the %w.$} {#ALARM {+5} {#STATE doorOpener 0}}
#COND {} {} {manual}
#TRIGGER {^It is locked.$} {#ALARM {+5} {#STATE doorOpener 0}}
#TRIGGER {^There is no door to the %w.$} {#ALARM {+5} {#STATE doorOpener 0}}

This properly controls the activities of the triggers, and even keeps them disabled just a bit longer to cover your spamming. Spamming up a bunch of directions is generally a bad idea though unless you have a script that captures and queues them. Take this example 'n,n,n,n,n,e,e,e,s'; spamming those in goes pretty fast, but there is a door on the 3rd north. Now MovementDirection will be set to south though, and you will have to wait for the mud to process through all the commands and send you back the bad results of the easts, followed by you stepping south, then trying to open a door that isn't there. Just plain dumb.

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

Another idea is to use named ALARMs and either over write them or if it exists do nothing.

#ALARM MyNextAction +1 {stuff here}

Posted: Wed Jul 05, 2006 6:54 pm

CMUD is certainly *supposed* to have the "atomic" processing that you are asking for. It reads a line from the MUD, then processes all triggers for it, then reads another line, etc. This is the same as putting everything within a #PRIORITY command in zMUD. Since it sounds like that didn't work for you either, I think the problem is somewhere else in your processing. I'll take a look at this in CMUD, but the code is pretty simple (ReadLine, ProcessTriggers, ReadLine, ProcessTriggers, etc).

Novice Joined: 30 Apr 2006 Posts: 45

As far as I could tell, zMUD was fast enough that it would actually start processing other input before it even got to the point where it parsed the #priority instruction in the trigger script. What you say so far is good, but I also need to know: Are the triggers themselves atomic? Like this...

ReadLine
Foreach (sort $Triggers by 'priority' descending)
{ ProcessTrigger }
Readline
.......

Or whatever. Is it?

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Zugg's indicated this is how it'll work. Unlike zMUD, CMUD will process each line completely before looking at the next line

Novice Joined: 30 Apr 2006 Posts: 45

I got that, thank you. That's not what I asked. :P I'll just wait until CMUD is usable and just try it and see if it works. Gotta love BFI...