The quick question: Does MMF2 execute events from the bottom of the events list to the top?
if (yes = 1)
end;
else
longQuestion()...
Actually, it raises the question of which order are the actions executed as well.
So, If I had this in the event editor:
condition 1
condition 2
condition 3
Are they executed in a 123 order, or a 321 order? And furthermore, if I was in the list editor, and I had this:
condition 2
action 1
action 2
action 3
Are the actions executed in a 123 order or a 321 order?
I know this has been asked before, and I read the answer years ago. But I couldn't find the answer myself. I searched the forum already, so I'm sorry if you guys get the question a lot. Truly just couldn't find the answer.
Also, if there are any tutorials for what MMF does behind the scenes during your game or app, throwing me a link would be totally radical, like awesome from the 90's.
...and behaviors go at the end somewhere, although I'm not entirely sure how it works when you have several objects with behaviors - maybe based on how recently they were created (ie. fixed values)?
That's why I don't like behaviors, and never use them.
One day I will get around to experimenting...
A quick example:
Counter Behavior
1. Run Once
-> Set Counter to Counter Value * 2
Main program loop:
1. Run Once
-> Add 1 to Counter Value
The counter will end up at 2.
(0+1)* 2 = 2 NOT (0*2)+1 = 1
Originally Posted by UrbanMonk behaviors are ran after the main mmf loop and after the built in movements loop.
Yes, but if you have several different objects with behaviors - how does MMF decide which object's behavior to run first?
Also, does it complete all of one object's behavior before moving onto the next object, or does it handle all the objects' behaviors simultaneously, one line at a time?
Counter_A's Behavior:
* Run once
-> Add 1 to Counter_A
Counter_B's Behavior:
* Run once
-> Set Counter_B to Counter_A * 2
As in my previous example, there are two possible outcomes, depending on the order in which the events run:
OK, thanks for answering the short question. Unfortunately, the long question remains, because this explanation hasn't given me understanding of what is going wrong here. I'm going to explain this without trying to remember where I can upload an example.
First, we have four objects. MovingPlatform, PlatformDetector, DownArrow, and UpArrow. MovingPlatform is a 16x8 black rectangle. PlatformDetector is a 16x1 blue line. UpArrow and DownArrow are just red squares with arrows on them, which designate a "YSpeed" to MovingPlatform. Here is the few lines of code:
(1)start of frame: Set position of "PlatformDetector" to 0,0("MovingPlatform")
(2)If MovingPlatform overlaps DownArrow: set MovingPlatform's Value A to 10
(3)If MovingPlatform overlaps UpArrow: set MovingPlatform's Value A to -10
(4)Always: Set MovingPlatform's Y Position to Y("MovingPlatform") + Value A("MovingPlatform")
(5)If PlatformDetector overlaps MovingPlatform: Set position of "PlatformDetector" to 0,0("MovingPlatform")
Ok. Let's break this down. If what you guys have said here is true, we will walk through this code from top to bottom. Keep in mind that at the start of the frame, MovingPlatform is already overlapping the DownArrow.
(1): PlatformDetector is set to 0,0 of MovingPlatform. This 1 pixel tall detector is currently overlapping the TOP ROW of pixels of MovingPlatform.
(2): MovingPlatform is overlapping DownArrow at the start, so his ValueA is now 10.
(3): Condition not met, line of code is skipped.
(4): MovingPlatform is moved down 10 pixels.
(5): PlatformDetector is no longer overlapping MovingPlatform, because MovingPlatform moved down the screen 10 pixels on the last line, and detector is only 1 pixel tall.
The problem here is that line (5) is executed every cycle, despite my understanding, that the detector should NOT be overlapping the platform anymore. The detector should be 9 pixels above the platform. I know MMF handles graphical collisions before the buffer is updated, as you can move an object and check for collision multiple times in one game cycle. This code here is extremely simple, and it's causing me to bash my head into the wall. THE DETECTOR SHOULDN'T BE OVERLAPPING THE PLATFORM!@!! WHY IS THAT CONDITION RETURNING TRUE AND WHY IS MMF EXECUTING THAT CODE?@#@#??
in this scenario, moving the detector should only be done when it is overlapping the platform. Setting the action to execute always will not result in the desired outcome.
I'm pleased to see that Filefront has taken after tinypic, and a username/password is no longer needed to share files. Here is the example MMF file"
EDIT 2: I changed the "always" condition to "if collision detector is overlapping platform." The frame starts with them overlapping. Nothing moves before this check. When it checks for the overlap, it executes these actions in this order: move platform to platform Y + platform Value A, and then set the position of the detector to 0,0 of the platform. Here's what really happened: This worked until the platform started moving upward. This is the trend, actually. This is exactly what was happening with my platform engine, and you can totally see the problem in the simple example code above.
I'm seriously giving up if I can't figure this out. I'll put down MMF for forever, and migrate to something else like XNA. But I'd rather figure this out :/
I have read your problem and looked your example, but i dont understand it, since the blue thing active 4 always overlaps the moving box the event should be executed always.
Maybe if you say what do you want to blue thing to do.
(5): PlatformDetector is no longer overlapping MovingPlatform, because MovingPlatform moved down the screen 10 pixels on the last line, and detector is only 1 pixel tall.
This is not true since you move it with the same action. If you reorder the actions, it would be 10 pixels away... but then dont use two different conditions but only one.
(4)condition always:
move black box
move blue thing
(5)... nothing
Maybe you would be more comfortable using the event list editor to get the picture of how the actions are executed.
I've looked at your file and I can't see anything wrong with it. I'm seeing the detector stay with the platform. Then I moved the detector with the always event, as per my suggestion, and saw no issue with it. Then, I replaced the "position at ..." event with "set x position" and "set y position" events.
"I have read your problem and looked your example, but i dont understand it, since the blue thing active 4 always overlaps the moving box the event should be executed always."
But this is where it doesn't make any sense to me whatsoever. Before the line that asks whether or not the blue thing overlaps the black thing, the black thing is moved down ten pixels, so the blue thing should not be overlapping it anymore, and that line should not be executed.
Start of frame - they are overlapping
black platform's Value A is set to 10
Black platform is moved down 10 pixels
blue detector should no longer be overlapping the black platform
In this example, what I think should be happening here is the blue detector should NOT be staying with the platform.
"I've looked at your file and I can't see anything wrong with it. I'm seeing the detector stay with the platform. Then I moved the detector with the always event, as per my suggestion, and saw no issue with it. Then, I replaced the "position at ..." event with "set x position" and "set y position" events. "
The detector shouldn't be staying with the platform, since the event that snaps it to the platform depends on if they are overlapping, and they should not be, as the platform has moved 10 pixels down the screen before the overlap check. Also, I do not want the detector to snap to the platform in the always event, as I said before. In a platform engine, if you snapped the platform detector to the platform in an always event, there would be no way to leave the platform. The detector would not be detecting.
Once again, the order of the events, from top to bottom, should mean that the platform has moved 10 pixels down the screen before it checks for an overlap. When it checks for the overlap, the detector should be 10 pixels above the platform, so that line should NOT execute, and the detector should stay behind, but it does not. This is the problem. I'm currently seeing nothing wrong with my logic, since I am following the events from top to bottom, as well as the actions. What happens when I read the code through step by step is different from what MMF2 does.
Look your event: it checks overlaping and then sets its position to overlap again... what dont you understand.
mmf cycles throught conditions and does actions.
If you want to leave it behind i already wrote you to use the same condition. Or replace 4 condition with 5.
Basicly it means the last action must be to set y position of the moving platfrom.
So the condition for overlap dont work.
Like he says, it doesn't matter that the screen is only redrawn at the end of each frame, as that doesn't affect collision detection - if it did, embedded collision detectors wouldn't be possible.
I don't know how else to say this. First, they are overlapping. Then, one of those things moves to a position where they are NOT overlapping. Then it checks for the overlap, and runs the code, despite the fact that they are not overlapping.
The code should not be executing that last line. They should not be overlapping at that point.
I don't think anyone is understanding the problem I'm having, so I drew up a diagram. I don't want a fix for this, I want someone to tell me why it is not behaving the way that I think it should be behaving. If I can't understand why it is running the last line of code, despite the fact that the platform MOVED BEFORE THAT LINE, and they should NOT BE OVERLAPPING, then I can no longer program with MMF. This makes no sense to me.
Hopefully this diagram will shed some light on how I understand the code should be executed, and maybe someone can tell me why the last line is being executed, despite the fact that those objects should not be overlapping at this point.
*edit* thank you sketchy, I am relieved that at least one person sees that this doesn't really make sense. I feel a little bit better now : ) Hopefully someone can figure this out, because it makes zero sense to me.
Either i am missing the point of what do you want to do... or something else....
But the line is executing because mmf first it goes throught all conditions then executes all actions. just like a loop would do.
Thats why you need to do what i have said before.
condition:line is not overlaping set position to moving box
always: move moving box by 10
and then when it loops again the first condition will not be met... since the box moved after the line set its position on it
this may have answered my question. My understanding is that MMF executes code like this:
Condition 1 is met
action 1 is executed
action 2 is executed
action 3 is executed
Condition 2 is met
action 4 is executed
action 5 is executed
action 6 is executed
But you are saying it processes each condition to collect a list of actions to take, and then it executes the actions in order?
So you are saying MMF executes code like this:
Condition 1 is met
Condition 2 is met
action 1 is executed
action 2 is executed
action 3 is executed
action 4 is executed
action 5 is executed
action 6 is executed
*BUT* I have read that any events that have a red condition are executed right away. SO, "Start of Frame" is in red, which means it *does* run before the rest of the code is checked. Now the detector is overlapping the platform. Next, it checks all of the conditions. The detector IS overlapping the platform, so that event is added to the list. Next, the platform is moved down 10 pixels... however, since the overlapping condition was determined to be true before, it executes the action.
Now, I tried something else. Two boxes are set apart from each other. There is a text box above them.
(1)always move left box to 0,0 of right box
(2)if they are overlapping, set text to "overlapping"
(3)if not overlapping, set text to "not overlapping"
(4)always move left box to -64,0 of the right box
In this scenario, the boxes are not overlapping when the first cycle starts. No event is in red, so nothing is executed immediately. From what you are saying, I would think that MMF would run through the conditions, see that (1) is true, (2) is not true, (3) is true, and (4) is true, meaning that the text box would say "not overlapping," because they weren't when MMF did all of the condition checks. However, this example results in the text box saying "overlapping," which leads me to believe that actions run previously DO affect conditions after those actions.
These two ideas conflict. Where can an action have an outcome that affects a condition in a line later in the events list, and where does it not affect those later conditions?
I must ask... While I now understand what you mean about the 10px difference thing, I do not understand why you want it to work this way:
"Also, I do not want the detector to snap to the platform in the always event, as I said before. In a platform engine, if you snapped the platform detector to the platform in an always event, there would be no way to leave the platform. The detector would not be detecting."
What is the detector for? Is it supposed to be attached to the player (to detect what's under his feet) or to be attached to the platform (to detect if something has landed on it)? I think knowing this would help to clear up any confusion other people (inc. myself) had.
well overlaps are always a bit strange, but it would help if you write what you want to do.
And yes it does do condition action i guess i was a bit wrong.
I don't mean to confuse you guys. Normally, yes, you'd want a detector to snap to a certain position on the thing it's detecting, so that next cycle, it will be able to determine how far it moved, etc. However, the reason I don't want it to snap to the platform in this scenario is simply because it's an odd problem I discovered while trying to program something that DOES make sense.
To make a long story short, I had some code in my engine that was supposed to execute when the detector wasn't overlapping any moving platform. I noticed this code was not executing EVER, despite the fact that
I read that link, and although I did learn a couple things in that clickteam article, it hasn't taught me what is going on here.
[EDIT 09/01/09] OK, this is it. I have uploaded a file that PROVES it's an MMF bug. Here ya go:
[EDIT 09/02/09] I may have figured it out. Take this file above. The left side doesn't work properly. In the overlap event, change the "if detector is overlapping platform" to "if platform is overlapping detector." This really shouldn't matter logically; If one is overlapping the other, the other is overlapping the one, and vice-versa. However, if you change them, the left side works correctly. The only thing I can think is that, since they are overlapping each other at first, perhaps the overlapping property of an active object doesn't change until you move it. We don't move the detector before the overlap check, but we DO move the platform before the overlap check. Perhaps MMF doesn't change the "detector is overlapping platform" property until the detector has moved. This would totally explain it.
Don't believe me? Reverse the objects in the overlap check on the right side. All of a sudden, the right side DOESN'T work properly. It's because only one object has moved.
This means, to a platform engine, the following: if you move the player over a pixel and check to see if it overlaps something, it will work. If you move a platform into a player, and they ask "is the player overlapping a platform," it will NOT work properly. You would have to say "is the platform overlapping the player," since that was what you just moved.
If I'm right, I will be so happy. I need to find someone official and link them to the file above with my question. Someone who knows everything about MMF's runtime. Maybe the guy that wrote that article you linked to above.
MMF2 performs the actions in a rather funky order, ive had problems similar to this and referring back to this document http://www.clickteam.com/eng/resources/GTM/GTM2_4.htm always helps me out.
About halfway through the document it breaks down the exact order that everything is executed in mmf2
Edit: Oops! same document Adam Phant referred to but just in another format lol
Advertisement
Post Reply
Edited by Levirules
