Zugg Software :: View topic - timestamping my prompt with #SAYP

Posted: Fri Apr 29, 2005 6:53 am

#TRIGGER {H:(%d) M:(%d) E:(%d) W:(%d) ~<%a %a~>} {#SAYPROMPT test} "" {nocr|prompt}

Will correctly append "test" to each of my prompts.
Unfortunately, if the prompts come too fast it doesn't get appended to all of the prompts.. in fact, about 1 in 10 or even less often.
(this can be reproduced in a test environment by putting the above trigger in a blank settings file, connecting to the IRE mud "Imperian" and spamming any command)

Unfortunately, combat in Imperian is so fast-paced that my timestamp becomes useless.

The complete #SAYP that I wish to use.. is:
#SAYPROMPT %ansi( brown)~<%time( hh:nn:ss)%rightback( %format( 2, %eval( %secs/1000.0))s, 4)~>
And the purpose behind using it is so that I can check my logs later and time the length of my own (and others) attacks etc. I would also like to add things to my prompt to reflect afflictions and balances.. but I can't add anything at the moment.

My question:
Is there another way of doing this? I've seen 2 logs from separate people that do similar to what I am attempting, and theirs were on every prompt. Unfortunately, I don't know either well enough to ask them how they've done it ;)

My comp is a p4 2.4, 500mb ram, with win XP. I would have thought that it would be quick enough to run zmud well enough to do this, so I am thinking there is a chance its something I've done. However.. I did test it on a blank settings file.

Apprentice Joined: 10 Feb 2005 Posts: 158

If the muds output is fast enough zMud can miss some incoming lines if it is still stuck processing. If you absolutely need to have this on every prompt I would append #PRIORITY to it which will force it to finish processing before fetching another line.

Just as feedback I dont think this is going to do you any good. While #PRIORITY will add test to the end of each prompt, you have to consider the drawback carefully. zMud, in this case, seems not able to keep up with the spam on Imperian. If you *force* it to be able to by holding the input lines until zMud is ready you may find the combat is happening faster than you can see. So if enough prompts come in you may be dead already 20 lines down the buffer but from your point of view your still ok because your 20 lines behind. While this is an extreme case, I am sure you can see why I think this solution is not ideal.

You might try some other testing though. I dont know this for a fact but perhaps #SAYPROMPT is not the fastest. Perhaps an #ECHO or some other optimizations could speed it up. Personally though, I dont see a problem here. If your prompt has the needed items (and from your trigger line sure looks like it) you can do all the processing you need after the fact on the log file itself to get the timings. Perl comes to mind offhand...

Posted: Fri Apr 29, 2005 11:59 pm

Are you saying there is a way to retrospectively timestamp? Doesn't seem possible to me.
You're right though, using #PRIORITY is not really an option. Part of wanting to add stuff to the prompt is so that when things scroll past too quickly to see, the important info is still in the prompt for me to see.

This is the standard prompt.
H:281 M:200 E:1309 W:1083 <eb db>
Here is what I first tried to make it do:
H:281 M:200 E:1309 W:1083 <eb db> <09:24: 29.98s>
I also wanted to add things like: %if(@aeon=1,A)

I tried converting it to &varname syntax, in the hope it might somehow be a fraction quicker, but it didnt help (as I suspected).
#TR {H:&%dchealth M:&%dcmana E:%d W:%d ~<&%aeqbal &%wpstats~>} {#SAYP Test}

Ah well. There has to be some way of beating the spam there. Gagging doesnt work (since you still get loads of prompts, and if you gag too much (particularly selective prompts) the screen shakes and sometimes stuff you don't want gagged, gets gagged. The only option (and I keep trying to find an alternative to this) is to have a dual window setup where everything useful gets captured to the adjacent window. That'd be cool but... so much work Sad

Posted: Sat Apr 30, 2005 12:01 am

Deleted due to double post

Posted: Sat Apr 30, 2005 12:07 am

I was just checking out #SETPROMPT

Its a shame #SAYP can't be added to this, since, according to the helpfile:

"Creates an internal trigger to capture numeric values from your MUD prompt. If your MUD prompt can be captured using this simple trigger, then SETPROMPT will be faster than creating a normal trigger."

Its also a shame we can't use #SETPROMPT to capture text from the prompt. I think the syntax for setprompt should be an &varname syntax trig pattern.

Posted: Sat Apr 30, 2005 12:42 am

ask the mud if they'll spent a few minutes adding a timestamp. lol

Posted: Sat Apr 30, 2005 4:38 am

Along with all of the other stuff I'd like to add to my prompt, including values of variables from my own curing system?

Enchanter Joined: 10 Oct 2000 Posts: 698

Under View|Preferences|General there is an entry for 'MUD Prompt' that allows catching &VAR values. This used to be bugged, but I believe Zugg fixed it up around v7.04 or so.

EDIT: If I remember correctly, the bug caused the mapper to stop working. Not positive.

I used to use it ~v3.16 before the bug popped up, and it was MUCH faster than a regular #TRIGGER. Not sure if it is the same as #SETPROMPT or not.

Posted: Sat Apr 30, 2005 7:48 am

That is the same as the #SETPROMPT command, unfortunately. It only lets you capture numerical values into variables. Its a real shame, actually.

Novice Joined: 27 Mar 2005 Posts: 31

You could make an alarm that blurts out all your desired details at your set interval

Enchanter Joined: 10 Oct 2000 Posts: 698

Okay, as to your original question... have you tried time-stamping ONLY the output sent to the log? I can see how updating the display would slow things down. Since you've seen logs with time appended, could it be that the people just appended to the log and not the screen?

Posted: Sun May 01, 2005 8:15 am

I'm not sure how that could be done. I Could capture to a window, and have a prompt trig in that window's settings - but that would miss lines as well.

An alarm to blurt out details isnt a bad idea at all. I'll play with that.

Perhaps the most disconcerting part about this whole problem is not so much that I can't timestamp my prompt, so much as the fact that it is possible for a mud to send lines too fast for zmud to fire trigs off. I cannot think how to test this, but it would seem as though the trigger itself isn't firing. On second thought.. I do know how to test it.

#TR {H:} {#ADD promptcount 1;#SAYP @promptcount} "" {nocr|prompt}

Here, I am sending a meaningless command ('spam') very quickly. The prompts that the #SAYP did not reach, did not fire the trigger at all. This is a little worrying.. what if, in the middle of all that spam, where it was too fast for the trigger parser, an affliction message had arrived? Would the trigger set to fire off that affliction message have failed?

Posted: Sun May 01, 2005 4:10 pm

Over the years my solution was to use the #SUB command to replace a part of my prompt with a timestamp. It helps if you can add custom text to your prompt or just change an insignificant part of it.

Posted: Sun May 01, 2005 10:38 pm

Thanks for the idea, though the problem is still not what commands to use to do so, but the trigger parser not keeping up.

Here is me substituting my prompt with the text "Substituted_Prompt"

Posted: Mon May 02, 2005 1:55 am

I've discovered, at the off-hand suggestion of someone else, the problem.

The problem lies within the "trigger on newline" option. When it is unchecked (i.e. "nocr") then the trigger misses prompts. When it is checked, it doesnt miss prompts. This is possibly a problem with zmud.. or it could be a problem with IRE muds and carrier returns on prompts that get sent too quickly.

Of course.. without unchecking the "trigger on newline" option, I cannot use #SAYP in a prompt trig, without it appending stuff to all sorts of things that are not prompts, BUT I can use #SUBS so its all good.

Thanks everyone for the help!