Code Breaking Entirely at Random

[Corlen]

Why is it that code in MMF2 suddenly stops working for no apparent reason? I've had this happen four times in 12 days on my project. A notable example of this is how I have all active objects you can place in my built in editor I programmed set to the qualified group.5 and I told it to destroy group.5 before the level loads. This worked fine and dandy until suddenly without warning destroy no longer works for group.5 in that event even when I delete it and remake it. I wouldn't mind so much if it happened once in a blue moon but it happens frequently and I find my productiveness is dropping sharply as my project grows because I'm constantly having to go back and recheck everything I programmed to make sure it still works after I put a new line of code.

Another example is this. I had qualifier group.9 if flag 31 is off to create a shadow and turn flag 31 on. Well I changed absolutely nothing in my code and ran a run test again. Suddenly one of group.9 stops creating a shadow but turns on its flag 31 while the rest do what they're supposed to and no amount of bullcrapping MMF2 makes it work entirely again. So I had to go and change my code to where if the number of shadows is lower than the number of group.9 objects then it should create a shadow.

[izac]

I had little problems like this here and there, but since the newer builds, I've had no such problems! What build of MMF2 are you using? B251 is the latest!

Standard MMF2:

http://www.clickteam.com/webftp/files/mmf2/update/mmf2b251.exe

MMF2 Developer:

http://www.clickteam.com/webftp/files/mmf2/update/mmf2devb251.exe

[Corlen]

I'm using build R251.

[Crash86]

One thing _ There aren't 31 flags, maybe only 14 or 15. Flag 31 will actually be turning flag 1 or 2 or something on or off instead because it loops after 15 or so.
It could be that by using flag 1 for one function and 31 for another, you're actually setting the same flag twice. That would account for some unpredictability.

Last time this was discussed, it was recommended that the max. Number of flags be indicated in the on/off test dialogs. It would surely have taken no time to implement but was never looked at.

[Corlen]

Why does the debugger show that there are 31 flags then? An oversight?

[Dynasoft]

There are 32 flags, numbered 0 to 31. Higher numbers wrap, e.g. setting flag 32 sets flag 0.

[SEELE]

. There are 32 Flags, 0-31 ( 32 will refer to 0 )

. MMF2 has non of the bugs described here

. The complicated selection regime can cause exactly the behavior described

Consider the following two ( similar ) code snippets as an example

///////////////
//Program One//
///////////////
+Start of Frame
-Start loop "Destroy our object"

+On loop "Destroy our object"
-"our object" --> Destroy

///////////////
//Program Two//
///////////////
+Start of Frame
-Create new "our object" at location (0,0)
-Start loop "Destroy our object"

+On loop "Destroy our object"
-"our object" --> Destroy



Program One: will show no instances of 'our object' (since there all destroyed at the start of frame)

Program Two: seems to be exactly like Program One; but with a single new instance of 'our object' being created JUST before the loop is called which should destroy all the instances of 'our object'

However, that is not what happens.

Multimedia Fusion 2 knows that an instance of 'our object' has recently ( in this event condition ) been referenced ( by creating it ), and will apply any following actions specified ONLY to that particular instance of 'out object'

This will mean that ONLY the object added in the start of frame condition will be destroyed during the "Destroy our object" loop.

That certainly might appear ( to someone who isn't expecting MMF to take such initiative ) to be a serious BUG and likely a hard one too track ( since the action miss-behaving is not even in the same condition line as the action causing the effect )

Anyway, best of luck with your project

[SEELE]

Dynasoft... Jinx

[MuddyMole]

Sorry, but that's just plain wrong.

Program 2 will destroy *all* instances of the object, as you would expect - not just the one created by the "create new object" action (yes, I've tested it).
Object focus is *never* preserved from one line to the next, and that includes within fastloops.

If you'd said:

+ start of frame
-> create object at 0,0
-> destroy object

Now that *would* destroy only the newly created instance. This is because the "create object" action always then focuses on the newly created instance - the only time I can think of where an action (not a condition) influences object focus.
This feature exists so that you can create new objects and immediately initialize their position, alterable values etc - without it changing the values of the pre-existing instances.

Of course, the easy solution is just to untick the "create at start" box in the object's properties...

[Corlen]

The only place I used a fastloop was to create a placeholder object on every tile that creates a sprite based upon what it finds in the middle of a string line (based on its X and Y position) in a glorified INI file and then the placeholder active object deletes itself. I just simply told it to delete all the group.5 objects when the loading flag is turned off, which triggers the loading fastloop above, without a fastloop specifically designed to delete the objects and it worked until I don't know what happened.