Anyone else get buggy "Otherwise" clauses periodically?

rebump

This happened before 0.8.6 occaisionally but it seems to be a bit more common in 0.8.6. Basically, I'll have a "Rule" behavior with some behaviors in both the rule's "true" area and in its "false" area (i.e. the "Otherwise" section of the rule). However, if this rule is nested within other "Rules"/"Timers" and/or tests certain things, sometimes the "Otherwise" condition is not evaluated no matter what. I haven't been able to determine a pattern to the occurance.

It is not a human logic issue either. A recent one I came across was layered a few levels deep. It basically tested the "Y" velocity:

`
-RULE-
If self.Motion.Velocity.Y >= 0 Do some other behaviors
Otherwise do some different behaviors
-END-
`
The actor in question goes up and then comes down. A "Display Text" of its "Y" velocity value shows a positive value as it goes up and a negative value as it comes down - as it should. I don't know it this is related to testing that particular attribute or because of the rule's nesting level or some other bug. I'm pretty darned sure I have successfully used this construct before elsewhere in other GS projects.

I did discover a workaround in this instance (recreating the actor did not solve it). I added an actor attribute and just before the rule, I save the actor's "Y" velocity value into the attribute. I then use the attribute in the rule instead of the pre-defined "Y" velocity attribute. It works but is essentially the same dang thing...but then you can run into test frequency issues with these types of workarounds depending on the setup. An alternate workaround is to move the "Othewise" behaviors to another rule with inverse logic in its conditional area. This works too but technically could lead to both being executed if the timing is right from execution of the first rule to the second.

Definately some strange things going on at times within GS.

Anyone else running into non-working "Otherwise" clauses - talking like 1 in 50 or even less being affected!? Not too common but when it does occur, it can leave you dead in your tracks at times.

mrfunkleberry

I get this too. Seems like i've come up with the same work-arounds as you. It's pretty damned annoying. 'Otherwise' is something i just plain avoid now, but it would be really handy, if they were solid. Sorry i can't help, but i share your pain.

JackBQuick

Instead of moving "the 'Othewise' behaviors to another rule with inverse logic in its conditional area", have you tried two separate rules with nothing in the "Otherwise" section (i.e. placing the "Otherwise" in its own rule)?

rebump

JackBQuick said:
Instead of moving "the 'Othewise' behaviors to another rule with inverse logic in its conditional area", have you tried two separate rules with nothing in the "Otherwise" section (i.e. placing the "Otherwise" in its own rule)?

That is what I meant by "move the "Othewise" behaviors to another rule with inverse logic in its conditional area".

Instead of "another rule" maybe I should have said "to its own rule".

rebump

Yeah, I try to avoid them as well but they come in handy when trying to ensure something is done each pass through a given nest level of "Rules".

Not sure if the bug is a result of bad parsing of the actor's XML file or something else but I sure wish they would fix it.

I hate to avoid the "Otherwise" clause but I find myself doing that more and more when I can.

JackBQuick

Sorry, I thought you meant that you took the same rule but just flipped it, like this:

If A then B; otherwise C
If not A then C; otherwise B

What I meant is two rules like this:

If A then B
If not A then C

(Sometimes it's hard to describe a situation properly. No offense intended.)

Edit: I reread your post. My bad.

rebump

JackBQuick said:
Sorry, I thought you meant that you took the same rule but just flipped it, like this:

If A then B; otherwise C
If not A then C; otherwise B

What I meant is two rules like this:

If A then B
If not A then C

(Sometimes it's hard to describe a situation properly. No offense intended.)

Edit: I reread your post. My bad.

Yeah, I meant the two seperate rules ("another rule")...yeah, you are correct that this stuff is hard to describe at times!!!

I always end up re-wording my posts a few times before I submit them but confusion and/or typos still seem to slip through. :-)

Edit: BTW, I never really had a need to comment in the related threads but your demos are always cool. Keep up the good work for the community!

JackBQuick

Thanks, rebump! That means a lot to me to have you say that about my demos.

synthesis

I found the otherwise is fairly stable if used sparingly or in certain patterns...but if you start inbedding rules in one another...the parsing tends to get a little cranky. Generally they begin to break when embedding rules in one another...I try to reorganize them and shift stuff around until I get consistent execution.

Most problems I have found are associated with putting Rules or multiple routines inside an otherwise. This I try to avoid and reserve an otherwise for just an attribute assignment or a simple set of behaviors. Keep complex behavior sequences out of the otherwise section....in short...keep the otherwise section simple and you will have fewer problems...but do use them...as they appear to help in overall app optimization.

Its hit or miss with little rhyme or reason to why it works generally but other times it is flaky. I have chalked it up to Beta Bugs.

_______________________

*** visit www.spiritApps.com to check out the Spirit Connoisseur Apps ***
(now available for 17+)

rebump

JackBQuick said:
Thanks, rebump! That means a lot to me to have you say that about my demos.

Skills need to be recognized and props given when props are due!

Oh, and speaking of your skills, if you have the time, look at this thread:

http://gamesalad.com/forums/topic.php?id=7001&replies=12#post-46189

Sounds like an area up your alley (i.e. puzzle and board game logic).