Zugg Software :: View topic

Wanderer Joined: 21 May 2001 Posts: 59 Location: USA

I was teaking my settings today, and then I tried to use the #WALK command to go somewhere. Suddenly, I encountered the problem of moving a few rooms and then stopping. The room move was successful, but it seemed like the #OK message wasn't being sent. Then I remembered that I've been having a somewhat similar problem with my prompt trigger...it seems as though if the prompt shows up more than once in the same chunk of received text, the trigger doesn't fire.

Now, my prompt trigger does a lot of stuff, perhaps an excessive amount, but it's necessary in my eyes. I seem to have had this problem before, too. As soon as my settings get "too large," zMud calls it quits, and everything I've been working on becomes next to worthless. I'm running on a P4 1.8 Ghz processor in Windows XP professional edition with 640 MB RAM, and my computer most certainly isn't bogged down. But I have to wonder...just how does zMud work internally? Is there a point at which zMud gives up on trigger processing? If too much text is received at once, do some triggers and.or other processes get left to the wind? I noticed the database does this. I used to have a database that was a list of all my skills and their specs, including what balances they needed or used, what message signaled a success, and other things like that. This database would be scanned entry by entry rather frequently, but as soon as the database reached a certain point, the bottommost entries got left out. (We're talking scanning this database roughly every second. If the scan hadn't finished by the time the next call came, it strted over.)

So what are zMud's limitations? What's considered "too much?" How many triggers is too many? How many lines of script and function calls can be made in a trigger that could be popping up several times a second, especially during combat? Should I just give up on scripting and buy the development kit instead, with hopes of programming a plugin to do a better job with the gruntwork? I'm not too keen on that idea.

How far can I take zMud before it'll give up on me?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I have yet to see any trigger other then those set to 'fire on prompt' fail to fire. The reason prompt triggers fail is simply because they are tested against the last partial line of a network packet(s). In other words the logic is something like: at end of each packet-if (not end of line) {test current line for prompt triggers}. By that logic, if your muds prompt is recieved in the middle of a packet then there was an EOL and it was never tested against triggers that 'fire on prompt'.

What you describe with your database is a different situation. zScript is not multi-threaded. Starting back in the 6.26 beta version looping commands caused a script to be paused on the internal stack, and a check to be made for other scripts to execute. Once this check completes the loop is started and completed. If your database checking script contained a loop within a loop then it would be possible for the outer loop to be paused, and the condition which controls the loop to be altered prior to its next iteration. The introduction of this change to zScript created a large amount of confusion during the beta testing, but also shifted the most time consuming scripts to those moments when they would not slow things down. Once all that was understood the #PRIORITY command was introduced to defeat this speed enhancing behavior and provide users with more control over the execution of thier scripts.

To answer your first question: about the only thing zMud can't do is take over the world. To answer you last question: zMud can nearly get you control of the world, you just have to point the way.

Wanderer Joined: 21 May 2001 Posts: 59 Location: USA

But what about the Speedwalking failing out of the blue? If I manually enter #OK as soon as I see it stop, it keeps going, which leads me to believe that the room name triggers are not being fired for whatever reason (That is the default, right? #OK being fired on the room name?).

Also, to address the prompt triggers.. if I set that trigger to fire on both newlines and prompt, well obviously it fires twice. Is there a workaround for this?

Adept Joined: 11 Nov 2000 Posts: 228 Location: USA

Use the 'Show Triggers' option to aid in debugging.
View --> Prefs -- General... --> Script Parser --> General Parsing --> Check 'Show Triggers'

Wanderer Joined: 21 May 2001 Posts: 59 Location: USA

Nice suggestion, but showing triggers cause em to get spammed with about thrity lines every time the prompt shows up.