Character not landing correctly on thin platforms.

I'm working on a static platform engine that uses fast loops & floating point movement (#'s using decimal point values apparently does NOT work under fast loops). The player doesn't always actually 'land' strait on the thin platform at the top. Sometimes he lands in the middle of the thin platforms.
The thin platforms are the platforms where you can jump up over them, then land on top of them. But my code makes him sometimes land in the middle of the thin platforms. It's never always on the top of the thin platform, like I wanted.

I suspect that it has something to do with the way I coded floating point movement. Maybe someone can take a look at it and see what I am doing wrong here?

http://www.megaupload.com/?d=MJMWUXQ0
It's still under W.I.P. as the X velocity movement does not work yet. I am kind of re-coding things under floating point & fast loop movement. X_X

Do you really need floating point movement? It's not good for a platformer, especially for collisions. It's better for racing games and such. If you move more than one pixel per loop, then of course you will have problems. You should NOT use floating points or it will be VERY VERY HARD to get this working correctly. Just saying...

But I need float movement mainly for the ice platforms and heavy wind areas. I tried making the character slide on ice platforms without the floats, and it's just feels & looks weird without it. X_X
Unless you can give me an example of accelerating/decelerating properly without using floats under the circumstances, I'd like to see how.
Also, while I am comparing numbers here, there is a difference between Vel X as 1, and Vel X as 1.5.

Okay, I just noticed something. What's the difference if I use
- On Loop "loop"
* - [Detector] - Set Position at (0,0) from [Player]
and using this event at the end of the code line.
- Always
* - [Detector] - Set Position at (0,0) from [Player]

I was looking at DavidN's fast loop tutorual, and noticed his foot detector was doing the same thing in the fast loops instead of being under the event always.

From what I can tell, the foot detector gets binded to the player during fast loop sections. Where if the foot detector is always being binded, it misses the position at fast loop sections, and just gets binded to the player after the fast loop.
Am I right on this? Maybe this is why my code was having problems. It was because my foot detector did not bind to the player during the fast loop sections. It only binded at the end, during the always event where it missed the fast loops.

Yes, you have to set your detectors' positions during the fastloops if the player object is ever moving - the "Always" event will only do it when the event-reading gets to that point in the event list, and events within fastloops are done without looking at any other events, as if all the actions were done on the event line that calls the fastloop. Make sure that you move your detectors on any event that moves the player object - that sounds like what might be going wrong for you.

Yes it was.... I'm still kind of new to the whole 'using fast loop' process thing. X_X
Adding movement/position to the detector with the player during the fast loops does help. Thanks. :)

EDIT: Okay, this is weird.
When I change the skinny platforms into a #x1 pixel (height of platform being 1 pixel), the character stands on it for a split second, but then falls back down off of it so suddenly. I disabled my float y codes and it still falls through after tapping on the platform. Why is this happening?

Same problem here with using 1 pixel thick detection. It's doing my head in but I think I have a solution, I'm going to try it now.

Edit: I've made a big mess of this I think I need some help to do it from the beginning lol.

http://www.easy-share.com/1907777079/PlatformCollisionFail.mfa

Please fix this without changing the falling speed, and without setting the green object's position relative to the red platform or an absolute position.

Wow.... that's really messed up back in there. o_O

For one thing, your conditions are backwards.
The other thing, whenever you use "on loop" condition, ALWAYS have it at the top of the condition before any of the other conditions.
The last thing, you don't need an escape loop. All you need is one fast loop.

This is all you really need to make your thing work.

[color:#FF0000]X[/color][[color:#009900]-[/color]] is overlapping [[color:#FF0000]-[/color]]
= * [_] Start loop "down" 5 times

[color:#FF0000]On loop "down"[/color]
= * [[color:#009900]-[/color]] Set Y position to Y[[color:#009900]-[/color]]+1

[color:#FF0000]On loop "down"[/color]
+ [[color:#009900]-[/color]] is overlapping [[color:#FF0000]-[/color]]
= * [[color:#009900]-[/color]] Set Y position to Y[[color:#009900]-[/color]]-1
= * Stop Loop "down"

Ah. Will try. Are you sure the order of the conditions matters when you're not using OR etc? OMG ur right it does. :@ TY

The order of conditions always matter, as MMF reads through the conditions from top to bottom. So in his example it's going to move the player first and then it's going to check if the player is overlapping an obstacle and move them back.

If the conditions were reversed, it would check if the player is overlapping first (which it isn't) and then move the player after. Which would cause the player to get stuck in the obstacle.

I don't understand what you're saying. We're talking about conditions, not actions. It's obvious the order of the actions would matter but doesn't make sense why the conditions would as they're essentially a list of "if X AND Y AND Z" which is the same as "if Y AND X AND Z" etc.

Order of conditions matter on many levels. Your order of conditions could make your game run slower, if not ordered efficiently.

For example:

Always
If flag 0 = on

MMF will have to cycle through the always first and then move on to checking if flag 0 is on. Where as if it were like this:

If flag 0 = on
Always

MMF will first check to see if that flag is on. If not it will stop checking the rest of the conditions. This is a simple example but when you have a lot of conditions in one line, it can make a difference.

You always want to list conditions with the least probable condition first. So if it's more probable for X to equal 0 and less probably for Y to equal 5, you'd want to do the Y equals condtion first. Hope that makes sense.

Ok, collision sorted. Now what is the best way to find if the player is standing on a platform (so you know to allow normal running+jumping movement)?

Before I used the proper fastloop collision, my current OnPlatform? check looks at whether a collision mask at the player's feet is overlapping the platform. This worked when using a wide area of collision detect. But now that I'm using fastloops and my collision detect is on a 1 pixel thick mask at the players feet, it is only working for some platforms (I can't explain why). It's irritating the hell out of me so I want to start it from scratch using a better way.

Solved it now. That was the hardest thing I've ever done.