Zugg Software :: View topic

Newbie Joined: 24 Feb 2004 Posts: 3 Location: USA

This may be a weird request, but I hope someone here can tell me if this is possible. I would like to write a trigger the fires after a certain period of time of receiving nothing at all from the mud. Ideally, there would be some setting that makes cmud check for an active connection if nothing's received for a while. Alternatively, I guess I could write an #alarm that would fire after some period of time but gets pushed out on anything coming from mud. Would this do it?

#alarm x {-30:00} {look}
#trigger {*} {#stop x;#alarm x {-30:00} {look} }

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Are you looking for anything specific, or just a general anti-idle thing? That would do it, but I would probably use the %alarm() function to reset the time instead (guess it doesn't matter which way, though.)

Posted: Sun Feb 08, 2009 7:16 pm

He's looking more for a script that will verify he is still connected if there hasn't been output on the screen for 30 minutes or so. The anti-idle thing would work perfectly on this, I think.

Charneus

Newbie Joined: 24 Feb 2004 Posts: 3 Location: USA

Charneus is correct. What I'm looking for is a watchdog that the connection is actually still active and not just really quiet. If I understand MattLofton's comment, I can achieve this a little more elegantly like so:

#alarm x {-30:00} {look}
#trigger {*} {%alarm(x,1800000)}

This should reset the "x" alarm to 30 minutes into the future on every line received. Did I get this right?

Also, some followup questions as long as I have some expertise available:

1. Could I write it like this to make the timeout value a programmable number of minutes as defined by a variable?
#alarm x {-@delayTime:00} {look}
#trigger {*} {%alarm(x,1000*60*@delayTime)}

Or maybe I'd need a wrapper call of some kind to do math with the time parameter to %alarm()?

2. Do I need to be concerned about performance issues given under normal operating conditions this trigger is going to be resetting the alarm time constantly (and never letting the alarm actually fire)?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

1)No need for the #alarm use of @delaytime. %alarm() allows you to change the duration interval of a named alarm to anything you want, even if you originally wrote the alarm as a 30-second alarm. An alias or oninput trigger will make this more natural and easier to remember (ie, timeout 17) but it's not strictly necessary.

2)performance as in lag, probably not. I would suggest you still use your prompt or some other specific line that appears regularly instead of the * pattern, though.

Also, CMud doesn't let you start a line with % anymore, so you need to preface that with #CALL.

Newbie Joined: 24 Feb 2004 Posts: 3 Location: USA

Yes, playing with it I discovered just what you said re: %alarm call behavior. The initial call to #alarm is in fact arbitrary since it gets overwritten immediately anyway with the first trigger hit.

I also discovered your point about starting with %alarm call (It sent the return value as a command to mud for every %alarm() call!) so I just prefaced the line with #NOOP, which seems to be the functional equivalent of your suggestion for this application. Your mention of #CALL made me go re-read the help on both. I wish it explained why #CALL is preferable to #NOOP for calling functions.

I did some testing with the * pattern, and it seemed to work fine, but you're right that I could reduce some of the furious churn of the trigger firing with some other very common pattern instead. However, even using * I didn't notice any performance hit, so I guess that says something good for CMUD's efficiency.

It's all working quite well, and I feel like I have a really good solution and understand CMUD better now. Thanks for all the help!

Enchanter Joined: 09 Sep 2007 Posts: 605

Novice Joined: 01 Jan 2009 Posts: 35

I cheat and use tick timers in ways they where never supposed to specifically for this purpose, since tick timers dont work so well on my mud due to randomly sized ticks.

basically every time my prompt pops up, it resets the tick timer, ie #ts 20 or some such, and i gag the message so it doesnt bug me.

if the tick timer ever fires, that means i havent seen a prompt in 20 seconds, which is basically not possible on my mud, and is definately not possible if i'm doing anything at all.

then i have a simple trigger, which reconnects on the tick 5 second warning.

i played with alarms and such, but the tick timer idea was so simple, and it hasnt let me down yet. i even got fancy and have different duration ticks for different situations. in combat for example i expect a prompt every 8 seconds. during regen only once every 40 seconds. afk once every 2 minutes, etc etc.

jack