Zugg Software :: View topic

Magician Joined: 29 Nov 2005 Posts: 482

I will replace this with another of my scripts. This one works but apparently its a poor example of how its INTENDED to work.

Posted: Tue Oct 10, 2006 4:55 am

edb, is this an example of something that is working? It doesn't look like the right syntax for #CASE at all. Or are you explaining how you'd like #SWITCH to work? #SWITCH is already implemented and has been added to the documentation, so take a look at it for the correct syntax.

But I'm confused by your post.

The #CASE command has the syntax:

#CASE (expression) {command1} {command2} {...}
executes the command based upon the value of the expression. If the expression is 1, then execute command1, if expression is 2 then execute command2, etc.

The #SWITCH is more like an if-then-elseif statement:

#SWITCH (expression1) {command1} (expression2) {command2} ...
evaluates each expression until it finds one that is true, then executes the commands given after the expression.

Your expressions like (%2 = "full") are either true or false, so I can't see where #CASE would be the correct answer. And if you are trying to use #SWITCH, then you don't need to keep specifying the #CASE keyword all the time.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Furthermore, wouldn't %2 actually hold the spaces captured by the (%s) wildcard?

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

Here is one that I made for our one shapechanging race on our mud. It can change into any other player race, so their racial skills change to whatever that race does. This can get very confusing, so I made a universal alias that would auto-change if you were still under shapechange delay.

Also, I assign the @LastRace variable to a local variable to try and speed up the lookups, but not sure if this would help.

Posted: Tue Oct 10, 2006 7:27 pm

Using local variables instead of regular variables should definitely speed it up.

Although it's cases like this that make me want to encourage using %0 instead of %-1, or maybe using the new %params variable in 1.10. Or, maybe some other way of handling these kind of aliases where you want to append the rest of the parameters. All of the %-1 just seem ugly.

But I should probably make a different post about %-1 since this thread is about #CASE/#SWITCH

Magician Joined: 29 Nov 2005 Posts: 482

That is a fully working example that i posted currently.

I didnt say it was the optimal usage just an example of a working case system.

Its a great example of why switch is better :)

I will test a few more things but both times i have gone in I have gotten the right thing. Course my system uses the switch method.

Posted: Wed Oct 11, 2006 2:33 am

Darn, I wish you hadn't removed the example you posted. Because when looking at it I couldn't figure out how it could possibly work. There were several problems with it and if it actually worked, then that means there are some other bugs.

I mean, you were doing a #CASE on an expression that could only have the value of 0 or 1, and yet you had more than 2 statements in some cases. So those other statements should never fire. And as Larkin mentioned, your %2 was referring to the (%s) and not the other string, so I don't know how that would have worked either.

I think I'm even more confused now.

Magician Joined: 29 Nov 2005 Posts: 482

rofl nah its my fault. It was late enough last night i posted the older version(PRE CONVERSION) before i switched it over to #SWITCH EXAMPLE. I just got done checking my packages. Somehow that one fired off twice correctly in the old package but i think it was because it didnt use the global variables which i use and somehow in conversion it held the right info in the wrong place(@world1 instead of $world1 :) CHECK out the switch topic in the knowledge base. That is what it is in my NEW 1.09 packages. I realize its a bit complex as an example but i think its a good example of switches and nested switches. Besides i was testing the parsing of them to make sure they worked even in nesting situations. My final version of that script will be really small more than likely. since that was for a test. I redesigned it a while back in zmud.

the (%s) you had noticed wasnt even part of my script although it was in the example. That was the old zmud version i had made like AGES ago before i realized it wasnt necessary to put everything i didnt want to capture in () somehow it skated through. so it wasnt on my current script either since i was attempting to reduce the number of variables held while making this command.

However you may want to note according to the syntax stuff it never fires off an error and thats a bit odd? It should say some type of syntax error. MY understanding of case is the same i think as your own.

#CASE (THING TO TEST) {1} {2} {3} etc.

I havent played with this much yet though since my understanding of it doing something like the following confuses me and i know its simple.. kinda annoys me lol.

#VAR Z 26
#case (@z) {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {#ECHO 26 HAS TO BE HERE?}
#VAR z 13
#case (@z) {} {} {} {} {} {} {} {} {} {} {} {} {#ECHO 13 HAS TO BE HERE?} {} {} {} {} {} {} {} {} {} {} {} {} {}

or is there a way to define them

#CASE (@z) {#ECHO 13 is here} {#echo 26 is here}
or is that
#CASE (@z=26) {#ECHO 13 is here} {#echo 26 wont fire since its 0 not 2 is here}

*NOTE* Been working like 16 hour days lately so my brain is probably fried

#VAR spelllist {armor|bless}
#TR {^You read {a|an} (*) scroll!$} {#IF (%ismember({%1},@spelllist) {#CASE %ismember((%1},@spelllist} {#additem spellslearned armor} {#ADDITEM spellslearned bless}}}

however seems to work fine based on 1 & 2.

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

#CASE wraps around with it's case codeblocks, so if your condition evaluates to 14 and you only have 13 sets of case codeblocks then #CASE will dutifully execute the codeblock for case #1:

#case 14 {#echo this is case 14} {} {} {} {} {} {} {} {} {} {} {} {}

Posted: Wed Oct 11, 2006 4:15 am

Yeah, the fact that #CASE wraps around is one of those wierd things in zMUD that is probably while few people used #CASE. It was useful for some cases, like doing random responses, but it was hard to use for "normal" programming stuff. #SWITCH should take care of that problem, even though it can get a bit verbose when you are just testing a particular variable for a certain value.

It's possible that we need an additional "case" statement more like normal C or Pascal that does something like this:

#NEWCASE (expression) (value1) {command1} (value2) {command2} ...

for example:

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

I'd absolutely love that... of course, I've got to check against every single player race on my mud when using that alias ;)