Zugg Software :: View topic

Newbie Joined: 25 Feb 2004 Posts: 6

I play Dragonrealms, it has a Roundtime which will restrict some action based on the time provided.

Displayed as
Roundtime: 12 seconds.

I can store the roundtime in a variable, and I use it as a counter on my screen so I can know how much longer I have. I didn't set it up, I pulled it from finished scripts, but I understand how it works.

I have added another action in the Roundtime class, which triggers when the roundtime counter is, which is:
#math RT @roundtimemax*1000

This will store a value that will wait the appropriate amount of seconds.

So if I did, #wait @RT, it will wait that long.

And it does.

But the problem is, when I run this the RT is not updated soon enough before the trigger I am using the #wait with reaches the #wait, so it waits with the old value, whatever that may be.

Code for the Roundtime class:

Wanderer Joined: 02 Dec 2001 Posts: 80 Location: Canada

Heh appears you and I are having same problem... will be nice to figure out whats wrong.

Posted: Wed Feb 25, 2004 7:28 am

Please read the article in the Support Library titled "Alarms, delays, and the Wait command". It will explain the issue with #WAIT and why it can be a problem. You can force zMUD to wait and NOT receive more text by putting the #WAIT command within a #PRIORITY command, like:

#PRIORITY {#WAIT @RT}

However, keep in mind that the side effect of this is that zMUD will not process any text from the MUD during this delay, which could have serious side effects when MUDding.

You need to try and rethink your triggers and keep in mind that you are working in a real-time event-driven environment. It is a bad idea to pause all processing while you do something. Instead, you should set a state, then use an #alarm or other trigger to change the state.

Newbie Joined: 25 Feb 2004 Posts: 6

Ah, if I was a better programmer. I will look into that article, but my confidence in discovering anything is not particularly good.

My problem is, if I am in the middle of a trigger and it does an action and it CANNOT do anything for a period of time, how else can I do it?

The problem is, most muds don't seem to have roundtimes...sigh..so this isn't a popular issue.

And I am entirely inept with originality when it comes to scripting.

Posted: Wed Feb 25, 2004 8:45 am

Well, if you can't do anything at all during that time, then it might be appropriate to #WAIT in a #PRI command like I mentioned. As long as you understand that no text from the MUD will be displayed while waiting.

It might be better to just set a flag and then use an #ONINPUT command to test to see if the RoundTime is up and #BEEP if it isn't and clear the command. One of the Programming Gurus might be able to post a more specific example.

I'm afraid when it comes to timing issues, those ARE complex issues and you should read whatever is available to try and understand these issues in order to learn how to write better scripts.

Newbie Joined: 25 Feb 2004 Posts: 6

Thank you for your assistance.

Newbie Joined: 25 Feb 2004 Posts: 6

Just for others info, here is my semi-work around. This will juggle over and over, avoid RTs as well. I just now have to expand it to handle checking for experience, doing appraisal, and then figure out how to adapter this on a larger scale for all of my scripts without duplicating code.

Magician Joined: 17 Oct 2001 Posts: 371 Location: USA

lazyfanatic, what I've done is set up a 'Command Buffer' system. Instead of directly sending text to DR in scripts, I send them to a stringlist variable, and each item in the variable is executed when RT reaches 0. Its fairly complicated - you can see the basic structure at my site: home.comcast.net/~myrddyn/drzmud/

I'm in the process of making it much simpler by creating a COM plugin for the current stuff, which is almost ready to be released. Eventually this system will include an inventory tracker, circle calculators, bank fund info (for those of us who don't have bank books), TDP calculators, and other neat stuff. The first version of the plugin will only move most of the complicated ADO stuff out of zMUD and into the plugin, so the settings file will be far less confusing.

Lets just say that #WAIT is not the solution to handling RT in Dragonrealms - it can be downright disasterous.