More Complex Behaviors/Logic Question

jkanalakis

Assume that there are three objects in a scene and one object wants to set the position of the other two objects. Three game attributes exists, named OBJ_ID, OBJ_X, and OBJ_Y.

Each of the two moving objects has a local attribute name MyID. Each object also has a rule that checks Game.OBJ_ID, if it equals MyID, then set the local position X/Y to OBJ_X, OBJ_Y. And lastly, both instances of the moving object in the scene have MyID set to 1 and 2.

Now the question...

The third controlling scene object has 2 groups of behaviors (to move both objects). Each group looks something like this...

Group-Move 1
Change Attribute - OBJ_X = 100
Change Atribute - OBJ_Y = 100
Change Attribute - Game.OBJ_ID = 1

Group-Move 2
Change Attribute - OBJ_X = 200
Change Atribute - OBJ_Y = 200
Change Attribute - Game.OBJ_ID = 2

In concept, this seems to work. But the problem I have is that only object 2 is moved. It seems that the first change attribute behavior is immediately overridden by the last change attribute behavior. I've tried setting a delay with a timer in between the attribute change, but it had no effect. Does anyone have any ideas? This would be tremendously easier if any scene object could directly set attributes of any other scene object, but as far as I can tell, that is impossible, right?

Thank you,

John K.

CatOnAKeyboard

Behaviors in GS "theoretically" happen in the order they are placed in the actor. In reality, they happen in a consistent, but non-linear order. Only trial and error can really help to determine the order your behaviors will go off, and of course adding a new behavior would completely throw that order off again

My recommendation is to change this operation into a rule:

If obj_id == 1:
-- make changes to obj_1
-- change obj_id := 2
otherwise:
-- make changes to obj_2
-- change obj_id := 1

jkanalakis

Thank you, CatOnAKeyboard. I'll give that a try. It sounds like a domino approach to behaviors is needed in this case (one object primes the next, and so on). As far as you know, do "Groups" of behaviors have any real impact on the flow of logic, or is it just an organizational tool?

John K.

CatOnAKeyboard

As far as I know, Groups are mostly organizational. However, (I could be wrong about this) I think that putting things in a group ensures that all behaviors in that group will happen "together" and not overlap with behaviors "outside" the group.

Example:

1. Behavior: change attribute 1
2. Group
-- change attribute 2
-- change attribute 3
-- change attribute 4

Something like this SHOULD ensure that 2+3+4 will always happen together and you would never get 2+1+3+4 or something like that. I've never run into a case where this assumption is wrong, although if you ever come across a a counter example, let us know!

Hopefully this helps shed a little light on the topic.

ORBZ

actions have higher precedence than behaviors.

actions execute once, behaviors execute constantly.

actions are executed in the order they are defined. yet within the group (or rule)

try linearizing your logic flow using a timer to keep the beat.