Zugg Software :: View topic

Apprentice Joined: 26 Sep 2001 Posts: 124

Hey all :)

Im looking for a way to output processed room information to the screen and have this output parsed through the trigger patterns which are already in place.

I understand this happens automatically in ideal situations. Unfortunately for me, the 'processing' that is done seems a bit much for zmud to keep up with processing triggers for the line outputted. The result is that all the information is displayed, but not coloured appropriately as the colour triggers do not parse this line.

I have found that if I use an alarm trigger to show the output one second later then the line gets processed by the triggers. Unfortunately 1 second is much too long a pause to be of any practical use. (The alarms just queue up and end up showing room information in the incorrect room)

So.. Im wondering if there is any way to 'force' this line to be reparsed by the triggers when it's outputted? I've tried playing with %expand and %exec but I'm not doing too well.

Failing that.. is it possible to create an alarm shorter then 1 second? Or at least pause execution in some way while the rest of zmud catches up to itself? Ideally im looking for a few milliseconds worth of breathing room.

Thanks

Posted: Thu Jul 27, 2006 10:48 am

store it all in a variable and #SAY @variable

Apprentice Joined: 26 Sep 2001 Posts: 124

I've used a variable to store (and build) the output throughout the processing phase already.. besides that, storing values in variables doesn't cause a 'pause' period for zmud to catch up on its work-load, it only extends it's work-load... so that wouldn't really work. But thanks for trying :)

However, in other news... I've sort of found a way around the problem!

Good old Wait triggers give us the option to fine tune the timing in milliseconds, so instead of outputting to screen once all the processing is done, I instead activate a really quick Wait trigger which then outputs to screen. The trigger is actually set to go at zero milliseconds, but this is still enough time for zmud to catch up on it's workload stack and the output is parsed through all other triggers! Yay :)

As you can probably guess, I'm pretty happy about all this but even still, it would be more ideal if I could manually 'force' the reparsing of output using either #say,#echo or #show.

If anyone can suggest a way to do this I would appreciate it :)

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

I believe there is a reparse trigger state that will reparse the line for another trigger isn't there?

Though not entirely sure this is what you wanted.

Apprentice Joined: 26 Sep 2001 Posts: 124

There is indeed, however I don't think I can use that for my needs as the line that I want the triggers to process is one that does not originate from the mud output, it is put together by a few processes.

I should mention that since the beginning of this post I have made unbelievable headway.. so much so that I don't believe processing overload will ever be a problem again! :)

What I've done is gone through the entire process and eliminated as much high end code structure as possible by making use of nested %subregex and customized functions.

Granted that doing this makes the code really (-very-) bloody hard to read and maintain (let alone understand a few months down the track), however, the rewards seem to be well worth it.

I have managed to drop the processing time for a certain piece of code from an average of 5 seconds to an average of 200 milliseconds !!!

5 years down the track and I think I have just now realised the power that zmud is really capable of. Im in a state of Awe at the moment... I can't imagine the type of improvement I can make throughout my entire settings using this technique.