Lets say i have 3 Instances of Object Enemy.
...
In the event Editor i do:
If Enemy Alterable Value A = Enemy Alterable Value B
-->
Enemy Destroy
...
In the above condition, what actually happens?
What Instance of Enemy does 'Alterable Value A' refer to?
What Instance of Enemy does 'Alterable Value B' refer to?
When you use an object of the same class of an object you are setting the value on in the expression editor of an action, for example a term like:
Always:
-> Set Value A of Enemy to (Value A of Enemy + 1)
MMF2 will refer to this instance of that object for each object scoped in that action, setting it different for each one. In that case, it would be the exact same as "Add 1" to each object, because it reads that objects value and sets it to itself. Its like the "This" pointer in C++. Probably is, for all I know.
But in the conditions, rather than the actions, any terms in the expression editor will not know to refer to "this" instance of an object. Instead it will refer to the first-most scoped one. In your example of "Enemy A = Enemy B", the Enemy B value will always be taken from the oldest existing object. So you'll have have three comparisons, that look like this:
Enemy #1 Value A = Enemy #1 Value A? -> Scope #1
Enemy #2 Value A = Enemy #1 Value A? -> Scope #2
Enemy #3 Value A = Enemy #1 Value A? -> Scope #3
So it will NOT be directly comparing the value A of each object to its value B. Which might seem counterintuitive.
However, you can use the exact same knowledge of the first bit I said, to work around this. If you avoid comparing to Value B in the condition, you can use some simple tricks
Try something like this:
Always:
-> Set Value C of Enemy to (Value B("Enemy") - Value A("Enemy"))
//This sets the value C of each object to the difference of its A & B, so you can refer simply to that C value instead of directly comparing A&B
If Value C of Enemy = 0:
-> Destroy Enemy
//If its value C was zero, then A = B, so it has the same effect.
Pixelthief, Im guessing you mistyped in your post and this is what you say happens when
'If Enemy Alterable Value A = Enemy Alterable Value B':
Enemy #1 Value A = Enemy #1 Value B? -> Scope #1
Enemy #2 Value A = Enemy #1 Value B? -> Scope #2
Enemy #3 Value A = Enemy #1 Value B? -> Scope #3
...Just bear with me here... :)
Lets say i have 3 Instances of Object Enemy.
...
In the event Editor i do:
If Enemy Alterable Value B = Enemy Alterable Value A
-->
Enemy Destroy
...
In the above condition, what actually happens?
What Instance of Enemy does 'Alterable Value B' refer to?
What Instance of Enemy does 'Alterable Value A' refer to?
Yes that was a minor typo. In the second example you posted, Value B will be referenced once per each Enemy Object and compared to- it will compare to Value B of Enemy #1, then Value B of Enemy #2, then Value B of Enemy #3, each time scoping or unscoping the respective object. Value A, being in the latter part of the expression, will not be individually referenced as 'this' and instead will be only a single instance each time- Enemy #1 all three times. So it will compare the value B of each object to the value A of only one of them. The code probably won't work as you intended.
OK, so...
'If Enemy Alterable Value A = Enemy Alterable Value B':
Enemy #1 Value A = Enemy #1 Value B?
Enemy #2 Value A = Enemy #1 Value B?
Enemy #3 Value A = Enemy #1 Value B?
'If Enemy Alterable Value B = Enemy Alterable Value A':
Enemy #1 Value B = Enemy #1 Value A?
Enemy #2 Value B = Enemy #1 Value A?
Enemy #3 Value B = Enemy #1 Value A?
...
This is where it gets intersting, lets see what happens if we combine the two...
Lets say i have 3 Instances of Object Enemy.
In the event Editor i do:
If Enemy Alterable Value A = Enemy Alterable Value B
+ If Enemy Alterable Value B = Enemy Alterable Value A
-->
Enemy Destroy
...
In the above condition, what actually happens?
What Instance of Enemy does 'Alterable Value A' refer to?
What Instance of Enemy does 'Alterable Value B' refer to?
Its the same thing- the former term will refer to each object individually as it is scoped, but the latter term will refer only to the first specific scoped copy of that object.
So you'll boil it down to:
O1 = Object 1, O1VA = Object 1 Value A
O1:
If O1VA = O1VB && O1VB = O1VA then Scope O1
O2:
If O2VA = O1VB && O2VB = O1VA then Scope O2
O3:
If O3VA = O1VB && O3VB = O1VA then Scope O3
In this case, Object #1 will only be scoped if its A = B. All other objects will only be scoped if it has the opposite of Object #1's values (IE if O1 was 5/2, then any other object with 2/5 would be scoped). It wouldn't care for any object if its A = B other than #1, because it would never be referring to itself in the comparisons.
As I was saying before, if you want to do comparisons to an objects values in the conditions, the trick is to do the math and store that result in a single variable, and compare to that variable- as my example, set Value C of the object to Value B minus Value A, then see if its equal to zero; if it is, then we know A = B for that object.
Logically i would agree with you, but this is not what happens.
What happens is:
Enemy ( this instant ) AltVal A = Enemy ( this instant ) AltVal B
Am i wrong? Pleace tell me if i am
I really want to understand this
Hrmm yeah well that depends on what the values are you put into it. I probably coulda seen that coming. Specifically, the latter term in the expression will refer to the firstmost scoped object in the scope list. Now when you have the term "A("Enemy") == B("Enemy")", what happens is that you'll remove all objects that don't fit that condition from the scope list, and leave only the ones that remain. So when it reads the next line, which says "B("Enemy") == A("Enemy")", the enemy it will refer to for the "A" value, will be the firstmost one that still first the first condition. It won't necessarily be #1, because that object might have been unscoped with the first condition.
The best way to think of it, is picture the scope list as a list of all the objects in your frame. At the top of the conditions, it will be full, containing all objects of every type. As you apply conditions, like "Is Flag 1 of Object On?", what it will do is compare to *each* object still in the list of that type, and remove it if it doesn't match the condition- if none of them match the condition, it will terminate and skip that line, not executing any events. Then it will go to the next line, and further modify the scope list. When the conditions are done, it will proceed to execute the actions once per each object in the scope list.
The part where it goes wrong, is that when you reference an object in the expression editor of a condition, it will refer to the firstmost copy of that object (newest created) that is still scoped- not necessarily to the same one you were comparing the value of. In your example, it was because there was only a single object fitting both conditions at the same time; but it won't hold true when you have conditions that multiple objects fit.
So lets say you had 10 objects, #1 to #10. And on condition #1, you have all 10 visible to it. For the comparisons using your same example, each one compares its individual Value A to the Value B of object #1. Now it unscopes all the objects that don't fit that. Lets say there are now only 3 objects remaining, #2, #6, and #9.
Now it will read the next line, comparing Value B to Value A. In this line, Value B will be the individual value of those three respectively, yet Value A will always be that of #2- now its only #2, not #1, because #2 is the oldest remaining object in the scope list.
So as an example of that, I modified your .mfa. The trick here is not destroying the objects at the same time to understand the logic- if you remove them, you'll only ever have 1 object fitting the conditions per frame, so you'll never see that breakdown at work, which you might see in a real application if you used the same code. So take a looksy; your red dots will now turn green when they match the condition. Note that when I say 'firstmost' I mean the most newly created object- if you add a newer object, that one will become the first one in the scope list.
edited file:
Attachment 6095
First of all, I appreciate your detailed explanation of this.
In your example, i left click on Object nr 6. ( AltValA and AltValB are set to 1 )Quote:
Originally Posted by Pixelthief
Object nr 6 then checks if its AltValA = AltValB of the oldest remaining Object ( im guessing this is the bottom Object, at least its NOT Object nr 6 ).
http://i43.tinypic.com/1q4br8.png
Shouldnt the entire condition be false at this point?
Then why does Object nr 6 change animation?
Thats actually a very good question. And you might have stumbled onto something I wasn't even sure on. Frankly, I haven't got a clue.
Personally I try to avoid any code that looks like that, since its all a bunch of witchcraft to try to figure out whats happening.
But I'll make a good stab at trying to figure it out. Its apparent that there some fine detail of how the latter term in the expression of a condition is scoped, and I'm not sure on how its figuring out which one to take.
Having any pair where O1VA = 02VB doesn't seem to fit the condition for either of them- even if O2 is the firstmost scoped object. So on a blank board, its *not* referring to the firstmost scoped object, but rather only to itself. So it is self referential in the latter expression, but as soon as one object fulfills a self referential conditions (apparently this only occurs when the condition is positive for that object), any further other objects on the stack stop self referencing, and reference the firstmost one.
Heres my guess. Latter half of expressions in conditions were *meant* to self reference in MMF2, but theres a bug with the self referencing- likely only having a single pointer when the stack has all the instances of every object being compared to, so as soon as that pointer is set by one object, the other objects stop self referencing and instead reference the other one. This is different than the way it self references for objects in actions, where it will do it properly down the whole stack of actions (each object self references itself). Here, it looks like only one object can self reference in the conditions at a time, and all other objects will point to that one.
Pointers are my oldest enemy, and this is all a bunch of voodoo to start with, so i'm pretty unsure at this point. MMF2 has a few other seemingly nondeterministic problems with its scope list and stack, like how it works when you go to a fast loop and back (it doesn't preserve the scope list on the stack frame for further actions when you return, but what it does to it, it does *something*, who knows, so you have to be ultra careful)
Multi Media Fusion Voodoo and Witchcraft XD lol
Well thank you for your time and your knowledge Pixelthief.
Although i havent come to a complete technical understanding of how this works, i know enought to stay away from black magic like this.
In general, avoid self referencing in the conditions, but its totally cool in actions, thats the moral of the story.
Good luck, and thanks!