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

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » zMUD General Discussion
greenman
Beginner


Joined: 30 Jan 2002
Posts: 20

PostPosted: Wed Feb 06, 2002 6:10 am   

#IF problems
 
I've written a complicated script/bot to automate a MUD for me. Unfortuntely, I wrote it in v5, and I've had some problems with the update. It's also been about three years since I wrote it, so I'm a little fuzzy on some it. I think that I've managed to isolate the problem that I'm having. What's happening is that I have a line of #IF statements in an alias. The first #IF, if is true, activates a series of alias's which ultimately set the determining variable to be true for the second #IF as well. So, what's happening is that it executes both the first and second #IF statements as true, and ends up screwing up my bot. I have tried setting all of the #IF statements following the first one to only activate if the first #IF is false, but that ends up with the same problem. I think what's happening is that v6 zmud is parsing it so fast that the variable switches before the entire first alias is finished. It sounds overly complicated, if anybody needs anything further explained please feel free to ask. I would appreciate any help on this matter.

Here's an example of my code:

#AD infostat 1
#IF (@infostat = 30) {
experience all
info
infostat=0
#WAIT 5000
controller
} {
#IF {@action = parrying} {curcontrol}
#IF {@action = attacking} {random}
#IF {@action = searching} {searchset}
#IF {@action = switch} {switcher}
#IF {@action = rest} {retreater}
#IF (@action = retreat) {
retreat
retreat
#WAIT 1500
DirConvert
#VA action attacking
}
}
Reply with quote
TonDiening
GURU


Joined: 26 Jul 2001
Posts: 1958
Location: Canada

PostPosted: Wed Feb 06, 2002 6:21 am   
 
Avoid #WAIT in v6 (Delays processing of further commands..)
Use #ALARM
ie: (ALARM works in seconds unfortunately)
#ALARM +5 {controller}
#ALARM +2 {DirConvert;#VA action attacking}

You might get stack overflows on that
depending if it clears out fast enough or not
as well.



TonDiening
Uses 6.16
Reply with quote
Castaway
GURU


Joined: 10 Oct 2000
Posts: 793
Location: Swindon, England

PostPosted: Wed Feb 06, 2002 10:52 am   
 
Try using #IF ( ... ) in all your Ifs, instead of #IF { .. } for the condition.

Lady C.
Reply with quote
greenman
Beginner


Joined: 30 Jan 2002
Posts: 20

PostPosted: Wed Feb 06, 2002 5:21 pm   
 
Tried it, didn't do anthing. :/ Thanks for the suggestion though.
Reply with quote
LightBulb
MASTER


Joined: 28 Nov 2000
Posts: 4817
Location: USA

PostPosted: Wed Feb 06, 2002 6:01 pm   
 
This doesn't appear to be where the problem is. #IF (@infostat = 30) is either true or false and it will be evaluated immediately and only once. Therefore, if true, none of the following #IF commands will be processed at all. It would be preferable to do the #ADD command after evaluating the variable, however. You can place it just before your second #IF (in the false commands for the first #IF). The variable reset (infostat=0) would then become infostat=1.

LightBulb
All scripts untested unless otherwise noted
Reply with quote
gyropump
Newbie


Joined: 07 Feb 2002
Posts: 6
Location: USA

PostPosted: Thu Feb 07, 2002 12:30 am   
 
problem i've found is you cannot stack if commands by any means, no elseif nothing of that format ... for yours .. since you have single actions stacked .. use the %if instead of #IF, and use proper string value handling, cause it appears you're checking against aliases not values, fix it up as such :

#AD infostat 1
#IF (@infostat = 30) {experience all
info
infostat=0
#WAIT 5000
controller
} {
%if(@action =~ "parrying","curcontrol")
%if(@action =~ "attacking","random")
%if(@action =~ "searching",searchset")
%if(@action =~ "switch","switcher")
%if(@action =~ "rest","retreater")
%if(@action =~ "retreat","retreat")
%if(@action =~ "retreat","retreat")
#WAIT 1500
DirConvert
#VA action attacking
}


Secondly ... might be highly recommended in this instance to use a CASE instead of stacked if's

might definately help to read over the function reference and command reference



.*^*. If at first you dont succeed, your sky diving days are over .*^*.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Thu Feb 07, 2002 1:24 am   
 
hmm, since you are testing @action in every #IF you have (and judging from your IFs it appears @action will always have just one action in it instead of multiples), why not use #CASE?

#case %ismember(@action, "parrying|attacking|searching|switch|rest|retreat") {curcontrol} {random} {searchset} {switcher} {retreater} {retreat;retreat;#noop other code}

li'l shmoe of Dragon's Gate MUD
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » zMUD 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