Why does this rule override all the others?

icemacsea

http://icemacsea.com/rules_issue2.gameproj.zip

I have an actor with 4 rules in it. It is part of an adventure/puzzle game. The puzzle involves getting a TV to turn on. There are three conditions that must be met for the TV to turn on. 1) It must be plugged in 2) the fuse in the nearby fusebox must be replaced and 3) the power button on the TV must be turned on.

So I have 3 rules on this power button that handle the touch event in this order:

1) Check to see if the player is using an inventory item on this actor. (Is game.use_item_num is not equal to zero?) This is not allowed, so we tell the player.

2) Check to see if the power button is already on (Is scene.powerBtn_OK true?) The player is not allowed to turn the TV off once they have turned it on. If it's already on, then tell the player.

3) Check to see if the "power chain" is still not complete (Is scene.cord_OK false OR scene.fuseBox_OK false?) If either of these is false, then we tell the user, "You turned on the power, but there's still no picture." We also set scene.powerBtn_OK to true here.

All three rules check for the touch event and also for the self.ready attribute, which must be true. The first rule to go off does its thing and sets self.ready to false, keeping any following rule from going off. Then the 4th rule senses the touch-release event and resets self.ready to true.

My problem is that no matter what I do, the third rule keeps going off. I can set game.use_item_num to an integer and still the 3rd rule goes off. The 3rd rule uses a nested rule (If ANY of the conditions are valid) to check powerBtn_OK and cord_OK, and I thought that might be the problem. That lead me to post questions about evaluation of rules yesterday and ultimately lead me to change my method of preventing multiple rules from firing. Using the method suggested by tatiang, I was able to nest a rule inside another and everything worked fine.

But when I went into my actual program and implemented this method, I found I still had the exact same problem. So I have isolated the problem in the gameproj file you see linked at the top of this post. Anybody who can take a minute to look at it and give me advice would be greatly appreciated. (You'll see that I have preset game.use_item_num to 4 in the inspector, but still that first rule never goes off.)

Here's a shot of that first rule that never fires:

tatiang

You have one rule that says When touch is pressed and self.ready is true, change self.ready to false. So each time you click on the actor, it changes self.ready to false.

The image of the rule above includes When touch is pressed and self.ready is true. This won't ever trigger because it won't ever be true (when you click, self.ready is false instead of true).

icemacsea

tatiang, I'm using your method from yesterday. All I did was change the name of the attribute (you used "available" and I used "ready".) Just as you did, I set the attribute to be true in the inspector. So it should trigger just fine. The whole idea was, have it start out as true, so that the first rule to be deemed valid would trigger, but then by setting it to false, it would prevent additional rules from firing. Then at the end touch_release resets the rule.

You might look at your example again if this seems confusing:

http://icemacsea.com/prevent_multiple_touches.zip

tatiang

The reason the first rule isn't triggering is because the other two rules are triggering at the same time and making self.ready false. In my demo, only one rule can trigger at a time because self.counter=# is only true for one "state." You haven't managed to separate the states yet. I'll see if I can help a bit later.

icemacsea

This is the reason why I asked this question yesterday: Are rules evaluated in the order that they appear in the editing window? And you said, yes.

So are rules evaluated in order or are they evaluated simultaneously? I don't see how they could be truly evaluated simultaneously, but I do see how such a thing could be simulated in the engine. Maybe it's just me, but it seems like sequential evaluation would be preferable, so that the rules would work more like flow-chart.

In any case, no need to worry further about my particular case -- if the rules have to be structured so that only one should be valid at a time, then that's what I'll do. But if that is the case, then we can't say that they are evaluated in any particular order. Does that sound right or am I missing something else? Thanks again for your help!!

tatiang

Well, they are definitely evaluated sequentially from top to bottom. I'll be honest... I have a tough time wrapping my head around this stuff sometimes, too. I re-built the rules from scratch after sketching a flowchart from your description. It may not be perfect but hopefully it offers a glimpse of how this might work.

icemacsea

Well, thanks again. That version is almost perfect. Way better than mine! The only issue with it is the fact that it always delivers the "Button is already on" message (even if the button was in fact in the off state when pushed.) But this gives me a clearer picture of how such a scenario might be coded efficiently.

What would be great, IMHO, is if the software engineers who created GameSalad could just give us a clearer picture of exactly how the rules are evaluated, and what the underlying assumptions are. I assume one of those assumptions is that, given an actor with multiple rules, by design, only one rule (at most) will be true at any given time.

Because, you know, to say that rules are evaluated from top to bottom but then to have to concede that rule 3 went off and invalidated rule 1, when both were equally valid ... it makes for a very murky picture, indeed. I might need to go back to regular scripting! LOL.

Again, thanks for all the time and effort you've spent in trying to educate me on this.