The Daily Click ::. Forums ::. Klik Coding Help ::. maybe quick question, maybe long question.
 

Post Reply  Post Oekaki 
 

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

Game of the Week WinnerVIP MemberI'm on a BoatPokemon Ball!
29th August, 2009 at 20:27:59 -

Nope, top to bottom

 
n/a

nim



Registered
  17/05/2002
Points
  7233
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
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
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
  49566

Has Donated, Thank You!Little Pirate!ARGH SignKliktober Special Award TagPicture Me This Round 33 Winner!The Outlaw!VIP MemberHasslevania 2!I am an April FoolKitty
Picture Me This Round 32 Winner!Picture Me This Round 42 Winner!Picture Me This Round 44 Winner!Picture Me This Round 53 Winner!
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

VIP MemberThe Cake is a Lie
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
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
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
  49566

Has Donated, Thank You!Little Pirate!ARGH SignKliktober Special Award TagPicture Me This Round 33 Winner!The Outlaw!VIP MemberHasslevania 2!I am an April FoolKitty
Picture Me This Round 32 Winner!Picture Me This Round 42 Winner!Picture Me This Round 44 Winner!Picture Me This Round 53 Winner!
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

VIP Member
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

VIP Member
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!

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
30th August, 2009 at 17:05:10 -

Actually, I think LeviRules is right on this, and perhaps a few people are missing the point.

I've modified his example so you can run through it one line at a time (press spacebar).
Hopefully this should illustrate his point a bit better.

http://cid-b1e7ee094271bbda.skydrive.live.com/self.aspx/Public/problem2.mfa

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.

 
n/a

Levirules



Registered
  27/09/2008
Points
  37
30th August, 2009 at 17:19:33 -

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.

Image

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.

Edited by Levirules

 
n/a

Don Luciano

Heavy combat pancake

Registered
  25/10/2006
Points
  380

VIP Member
30th August, 2009 at 18:21:01 -

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

think loopish:

condition1
c2
c3

action1
a2
a3

in order

Edited by Don Luciano

 
Code me a sausage!

Levirules



Registered
  27/09/2008
Points
  37
30th August, 2009 at 20:35:22 -

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

source: http://www.filefront.com/14431445/Problem%202.mfa

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?

Edited by Levirules

 
n/a

aphant



Registered
  18/05/2008
Points
  1242
31st August, 2009 at 07:48:18 -

Aha! I think I found a solution to this conundrum!

http://www.clickteam.com/website/usa/img/uploads/tutorials/download/Fusion_runtime.pdf

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.

 

Don Luciano

Heavy combat pancake

Registered
  25/10/2006
Points
  380

VIP Member
31st August, 2009 at 08:57:10 -

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.

 
Code me a sausage!

Levirules



Registered
  27/09/2008
Points
  37
1st September, 2009 at 03:13:32 -

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:

http://www.filefront.com/14447613/problem%203.mfa

[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.



Edited by Levirules

 
n/a

Rox Flame

Creative Talentician

Registered
  06/10/2004
Points
  383
18th September, 2009 at 14:14:41 -

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

Edited by Rox Flame

 
Current project:
Dynabrick (%70)
   

Post Reply



 



Advertisement

Worth A Click