Created objects (unintentionally) affecting each other's variables through Behavior

Hi,

I noticed something weird with the way created objects affect each other through Behavior actions.

Suppose I have an Active object called Rock, which is set not to be created at start.
At the start of frame I create two Rocks. Lets call it RockA and RockB.

If I create RockA first, and then RockB, if I ever change a variable of RockA during a Behavior action then I'm fine.
On the other hand, if I create RockB first, and then RockA, if I ever change a variable of RockA during a Behavior action then the same variable is changed on RockB =/.

I wish each Rock only changed its own variables, independently of the order in which they are created.
Can someone help me deal with it?

Hi, thanks for answering.

Could you be more clear?

Thanks for the attention, and I'm sorry about the delay.

I wish to implement some sort of State Machine on the objects, so I can make each of them work independently of the others, allowing for all the code to be left inside of each object, instead of in the main Event Editor (where it is starting to get crowded).

The problem is that, for some reason, inside the behavior code the objects are (probably?) accessing each other variables, messing up my concept.

As an example I created this .mfa where it has an object called Rock, which in theory is supposed to support two states, "idle" and "falling".
When falling, it should move 1 pixel on the Y axis every frame, in a total of "falling_duration" times (a variable that I set when I create the object).

The bug here shows up when I create two Rocks with different "falling_duration" values. Instead of each falling its specific amount, both fall the same =/

Here's the example .mfa:
Attachment 16549

I fear you'll have to use a slightly different approach.
This issue is not directly related to "behaviouring", but to "scoping", as Snail said.
See example: Attachment 16550

I'm a always-foreach-abuser so I tend to slip them anywhere XD
but theorically you could trigger the foreach only in more limited situations.

Thanks for the advice, it worked.

On a low-level perspective, how would your example behave?
I mean, each object has a behavior, and all of them would activate the Always condition, which would activate all of the objects again.
So, if there are 10 objects, the for-each would execute 10 times, checking for 10 objects each time, resulting in 100 checks.
Is that how it works?

If that is the case, that only partly solves my problem, as I have to keep the processing as low as possible (several objects, mobile platform).
If not, then that's perfect.

warning:
I pratically never used behaviours, so I may be completely wrong,
but I would guess they work in a different way.

I think of them as "additional" lines in your general event list,
they are processed like any other event, and just once x frame x different object
So, if you have a behaviour with "always ---> do this" on an object,
it just means that if the object is on screen, that event would be checked (added to your event list), otherwise not.
If you have 100 duplicated same objects with a four code-lines behaviour,
this doesn't mean that they will add 400 "code lines" to your event list,
but just four (this is why yoour original approach didn't give the expected results - they always refer to all instances of the same object)
This is more of a "code structuring" tool than "performance optimization",
it mostly takes care for you of disabling events related to non-existing objects.

Well, or better, this is how I think they work! X)

As for always-foreach:
I think you could do without always,
but not without foreach, if you're going to have multiple instances of same objects.
You could try replacing always with some specific recurring event,
or place them inside groups,
i.e. "player" moves "rocks" + "rocks" X pos > "ground" X right edge
---> activate group "rock is falling"/deactivate at end of process

I see what you mean. If that is the case, I was completely mislead.
That changes how I'm going to approach it now.

The group idea seems nice on "not even asking if some condition is true", and that may save a lot of processing. Before you posted it I had an idea, which I believe that it turns out to be very likely:
Instead of Always, I check for the "state" of the object.
- If at least one object has that state, then it runs the for-each loop, which goes over all the objects but only acts on the ones that have the state I want.
- If none object has that state, then the for-each loop doesn't run at all.
As every object will be in a different state, there will be at most NumberOfStates for-each loops activated, each running NumberOfObjects times, which I believe is quite good and the best I can get on MMF.

I believe it is an improvement over my old ideas, and now I'll try to mix it with your group ideas.

That was really helpful, thanks!

By the way, as an old-fashioned programmer, I keep wondering how MMF turns each high-level code into low-level code. Is there any document, or guide, where I can see something like this with details?

I think your "state" idea should work,
I *could* have used it successfully for sending LAN updates through lacewing, if I recall well
(at least 1 state "has changed" on: send direction/speed update foreach object with state "has changed" on).
Good practice would be stressing to worst scenario before implementing,
and seeing how things behave in overcrowded situations.

Sorry I have no clue on your last question :(