How MMF reads conditions

[Nick]

Right, say you have lots of events where there are several conditions per event, for example:

Active collides with qualifier 1
Counter is greater than Counter 2
Animation 5 of active is player
Only one action when event loops

Does MMF read EVERY condition then decide if it should activate the events, or does it read down one by one then give up if one is false? If so, would it be better if all the simple conditions were on top and the complex ones at the bottom to save MMF the effort of working all the complex bits?

So if this is all right, what conditions use up the most processing power to work out?

[maVado]

What I expirienced so far is that it goes down the list as you described and looks if all of your statements are true.

I would start with something that cannot be checked all the time.

Like a colision for example

Active collides with qualifier 1
Counter is greater than Counter 2

That is the correct order

Counter is greater than Counter 2
Active collides with qualifier 1

Would Always check for the Counter to greater then 2 and then look for a colision after that and would slow down your application I guess.

[Anders]

It stops evaluating the event when it meets a condition that evaluates to false.
It is difficult to tell which conditions takes the most processing power, but I think the ones that deal with object selection (the conditions that filter out objects that aren't relevant for the event). So try to keep the simple ones at top and the more processor consuming ones at the bottom to minimize the probability of them being evaluated.

[Nick]

In reply to mavado, wouldn't checking a counter be 1000 times simpler than checking for a collision?

Thanks for the reply though guys, I'll go through my event editor and re-order what i can to see if i can increase performance

[maVado]

Well it depends on how often the counter has a value greater 2

lets imagine 90% of the time its greater 2

the next step would be checking for a collision. MMF would now check all the time for the counter AND the collision. All the time 90% of the application time.

If you do it the other way around it would only check on a collision and then verify the counter value.

I hoestly believe that this will be a lot faster.

But on the other hand, if the counter value is only like 1% of the application time greater then 2 then this might be faster.

[Dynasoft]

Also, "true events" (red text) need to be at the top to work, even if they're processor intensive sounding like collision.

[Random]

I usually put on top what is least likely (true events first of course). It is not exactly transparent what takes long to compute, although some common sense helps here.
I'd say checking a counter against a number should be roughly 1000x less expensive that an overlapping check (if you use the collision thing, that MUST be at the top anyway to avoid wrong results). So I consider the computation time of regular expressions (e.g. x < y or other formula) (if they don't contain special functions that seem expensive) neglectable.

But in general I'd say it's best to try to get a "false" in the condition check as soon as possible.