Something I've been wondering since having a bit of trouble with a project. I know the order of actions matters, but what about conditions? I'm talking about when you're trying to select a few instances from multiple instances of an object. For example,
Pick object "Active" at random
"Active" collides with backdrop
Internal Flag 0 is on
I haven't messed around with it much so I really don't know. Anyone have a quick answer?
Order of conditions do matter. In your example, that will pick an object at random, then test if it collided with the backdrop. If it did, check if flag.0 is on, do stuff. If it didn't, then move on to the next event.
If you reordered it like so:
"Active" collides
Pick random
Flag on?
You would end up testing objects that collided with a backdrop first, then pick one at random and see if it's flag is on.
Also, having the collision test first is an 'immediate event' (it's red!), meaning that event isn't tested until an active collides. Picking at random means that the event is tested every cycle.
I never really saw that it did but as of lately I have started to understand that everything must be in order, really. All the events, conditions and actions.
A lot of things work out of order, which I think is what leads a lot of people to believe that the glitches are in MMF itself, whenever they put the conditions or actions they want in, and something goes wrong. Once you start playing things out in your head and you make sure all the conditions and actions are in the appropriate order, you'll suddenly find yourself doing a lot more programing, a lot less debugging, and suddenly the whole process becomes a little more fun than frustrating because things just work.
I must say I do enjoy the debugging process when you *can* find bugs. It's a good feeling to run your program, it screws up, you go "Hmm!?" and then return to MMF, find what caused it and rectify the order or events. Or perhaps a condition that wasn't quite right.
One problem with The games factory is that although the action order matters just as it does in MMF1.5 or MMF2 you can't actually change the order without deleting them and remaking the actions in the right order.
But yeah, you can get completely different things happen depending on what order you have your actions.
A really simple example for instance.
Create object at 0,0
move object to 32,32
destroy object
move object to 32,32
destroy object
create object at 0,0
No problem, that's useful to know too, as is the event order itself.
I have trouble determining when MMF's internal "action loop" will perform the action on each object. I have trouble sometimes knowing when to use a fastloop and when MMF will do it automagically. Since I learned fastloops, I think I overuse them to loop through each instance of an object since that's how most real languages would work.
For example:
User presses [Space] : Destroy "Active"
..will obviously destroy all instances of "Active"
User presses [Space]
+ "Active" Flag 0 = ON : Destroy "Active"
..will destroy only those instances of "Active" with flag 0 on
but something like
"Active" is overlapping "Active"
+ Y("Active") > Y("Active") : Destroy "Active"
..doesn't work at all. (I want to destroy the lower instance)
So in situations like that, I usually fart around with fastloops and "Pick one at random" until it works, but I've never actually got to the bottom of how MMF selects instances.
Yup, condition order is perhaps one of the most important things, memory wise. Normally you want all 3 conditions, so you won't notice it, but it goes from top to bottom. So, it's good to get the least likely condition at the top, to get MMF to scan through less objects. Say, if you have "A overlaps B" and "Flag 0 is on", it's best to have the "flag 0 is on" first, because it's much less memory intensive than the overlap check. If the overlap is first, it only checks the flags for all the objects that overlap. If the Flag check is first, then it calculates overlapping for each and every object that has Flag 0 on.
"Pick at random" is the most interesting one with object ordering. If you put it first, it will check the conditions for some random object, which is useful in some situations. If it's lower, then it actually picks out random objects. So if you're trying to pick random objects that meet a certain condition, it should be last. Putting it first means that you're picking them in random order.
If you don't have "pick at random" in the first line, MMF will check conditions from the first object created.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Just to add for the hell of it, I've noticed that you need to have keypress checks first in the event order for them to work. Unless you don't have to and my coding is crap, which could very well be.
--
"Del Duio has received 0 trophies. Click here to see them all."
"To be a true ninja you must first pick the most stealthy of our assorted combat suits. Might I suggest the bright neon orange?"
DXF Games, coming next: Hasslevania 2- This Space for Rent!
"While key is pressed" will work as a second line, but you need to have events like When Key is Pressed as the start event because it's an immediate fire event, not looping. That's why it turns red when it's the first line.
Originally Posted by Muz If the overlap is first, it only checks the flags for all the objects that overlap. If the Flag check is first, then it calculates overlapping for each and every object that has Flag 0 on.
So if Overlap is first, MMF checks every combination of objects to see if they're overlapping? That's very interesting, thanks. How did you discover that?
Advertisement
Post Reply
Edited by nim
