|
Posted By
|
Message
|
Levirules
Registered
27/09/2008
Points
37
|
29th August, 2009 at 20:21:46 -
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.
 Edited by Levirules
n/a
|
Neuro
Ludologist
Registered
29/10/2006
Points
437
   
|
29th August, 2009 at 20:27:59 -
Nope, top to bottom
n/a
|
nim
Registered
17/05/2002
Points
7234
|
29th August, 2009 at 20:43:17 -
Top-to-bottom order unless it's an immediate (red) event. Actions are always top-to-bottom (use the Action Editor to change the order)
//
|
Sketchy
Cornwall UK
Registered
06/11/2004
Points
1971
|
29th August, 2009 at 20:57:02 -
...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
n/a
|
UrbanMonk
BRING BACK MITCH
Registered
07/07/2008
Points
49667
       
|
29th August, 2009 at 21:12:51 -
behaviors are ran after the main mmf loop and after the built in movements loop.
I used to use behaviors to attach object to other objects that used the built in movements.
Edited by UrbanMonk
n/a
|
-J-
Registered
05/10/2008
Points
228
|
29th August, 2009 at 23:32:20 -
Pixeltheif's article http://www.create-games.com/article.asp?id=1942 about 'object scope' may be useful to you.
Some pretty interesting stuff!
n/a ...
|
Sketchy
Cornwall UK
Registered
06/11/2004
Points
1971
|
30th August, 2009 at 00:56:56 -
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:
(2*0)+1 = 1
or
2*(0+1) = 2
How does MMF choose between them?
Edited by Sketchy
n/a
|
UrbanMonk
BRING BACK MITCH
Registered
07/07/2008
Points
49667
|
30th August, 2009 at 01:38:09 -
Behaviors are best used in referencing the object that its attached to.
If you can show me a good example of why the code you posted would be necessary then I'll agree that they are useless.
EDIT: a quick test reveals that the last object created runs it's behavior events last.
Edited by UrbanMonk
n/a
|
Levirules
Registered
27/09/2008
Points
37
|
30th August, 2009 at 02:11:35 -
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?@#@#??
*ahem* help would be greatly appreciated. 
Edited by Levirules
n/a
|
aphant
Registered
18/05/2008
Points
1242
|
30th August, 2009 at 02:48:03 -
Try putting the action to move the detector in with the "Always" event, after the "move platform" action.
|
Levirules
Registered
27/09/2008
Points
37
|
30th August, 2009 at 03:43:22 -
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"
http://www.filefront.com/14426685/problem.mfa
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 :/
Edited by Levirules
n/a
|
Don Luciano
Heavy combat pancake
Registered
25/10/2006
Points
380
|
30th August, 2009 at 08:14:03 -
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.
Edited by Don Luciano
Code me a sausage!
|
aphant
Registered
18/05/2008
Points
1242
|
30th August, 2009 at 10:48:05 -
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.
All of them worked.
|
Levirules
Registered
27/09/2008
Points
37
|
30th August, 2009 at 15:15:27 -
"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.
n/a
|
Don Luciano
Heavy combat pancake
Registered
25/10/2006
Points
380
|
30th August, 2009 at 16:15:21 -
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.
Edited by Don Luciano
Code me a sausage!
|
|
|
|
Advertisement
Post Reply