Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
jed
Adept


Joined: 18 Dec 2005
Posts: 246

PostPosted: Tue Apr 10, 2007 10:26 pm   

#wait command
 
In a different thread, zugg writes
Quote:
Btw, you really need to get rid of those nasty #wait commands at the beginning of this script. Otherwise it will probably cause all sorts of problems for you. I don't know why you have #wait statements between your various variable initializations. You might want to make a new post where you describe what you are trying to do so that some of the programming Gurus can try to help you come up with a better script design. With all of those #WAIT commands, you will have a very hard and frustrating time getting this script to work properly in all situations.
in reference to a script I have: which uses a decent quantity of #wait commands. I do this for a couple reasons, but the first is generally that when I initialize some variables, they don't get initialized before the next command is executed. I'm not sure if this is a product of my old computer or of some other reason. The second reason I use them is in situations where I really should be waiting for an event to happen, but I'm not yet too comefortable with the process of turning triggers on and off in the middle of a script to identify when something happens for the sake of making a decision in a script. So far I hav'nt found a good way to confirm if all of the stacked commands have been executed. for instance when I walk from one room to another, I typically write a script to walk from one to the other then assign a wait command to wait for (number of rooms)*(50 miliseconds per room) for a total wait time of 500 miliseconds prior to executing other commands just to be sure that i don't have a gozilion commands stacked... I guess i need to get better at making things happen within scripts based on mud feedback to that point. In the early days I tried to do this by adding a #trigger command in the script only to find that this creates a trigger in a class rather than executing some sort of trigger within just the script im working on (is there anything out there like this?)... Ultimately I would certainly like to get all of the #wait commands out. Any suggestions would be appreciated.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Tue Apr 10, 2007 10:55 pm   
 
Fang Xianfu wrote:
jed wrote:
if I just have comands back to back to back, some of them don't execute fully before others run

This shouldn't happen ever. I believe it's even impossible. zMUD used to be able to run more than one trigger simultaneously, which caused problems - CMUD doesn't even do this. Only one thing is happening at a time.


If you explain your other problem in greater detail, there's probably something that can be done. For now, all I can really suggest is a generic "read the help file for #t+ and #t- and use them to change which triggers/classes of triggers are active at any point in the script".
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Wed Apr 11, 2007 12:15 am   
 
It sounds like #EVENT is right up you're alley. You can respond to a specific event that you 'RAISED' when certain conditions are meant.

As an aside, you have you Tell window as a child of your FoxMUD window. Windows should stand on their own and not be children of each other.
_________________
Asati di tempari!
Reply with quote
jed
Adept


Joined: 18 Dec 2005
Posts: 246

PostPosted: Sat Apr 14, 2007 2:39 am   
 
So here's one example of what I'm talking about. The first time@oldpath is displayed, sometimes it has a value even though it has been initialized. However it always gets initialized and has no value the second time it is displayed.
Code:
#wa 200
say wow
#te 8985 "deathmaze"
resetrooms
#wa 1000
#var oldpath {}
#say this is the oldpath variable right now @oldpath
#wa 500
#var oldpath {}
#say this is the oldpath variable right now @oldpath
#wa 500
#var oldpath2 {}
#wa 200
#var curdir {}
#wa 200
#var roomstring {}
#wa 200
#var numexits {}
#show @numexits {}
#var newdir {}
say crap
#wa 100
look
Looks like from what zugg has posted above however, that this is probably happening because there are multiple execution branches due to the existing #wait... does that sound right?
Reply with quote
jed
Adept


Joined: 18 Dec 2005
Posts: 246

PostPosted: Sat Apr 14, 2007 2:40 am   
 
Saaaay another reason why I use the #wait commands is to slow things down to my pace... many times things whiz by so fast i cant read them.. can the script be slowed down by some other means?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Apr 14, 2007 2:42 am   
 
Yes, there is a Send Delay option in the preferences that will slow down some stuff, like speedwalking.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net