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
