Sine movement platforms and event order

Hey everybody!

So I've been doing some experimentation with vertically moving platforms with the player sprite which has platform behavior and have been running into some problems. I did notice that there is a link to a vertical moving platform example in the[How to] section but I wanted to try to come up with my own solution before I looked at somebody elses, since I feel like this helps me get a better grasp of the Construct engine. I've narrowed it down to a very small capx project that contains some logging text fields to help keep track of events.

Vertical Movement Sample Capx

Basically my idea was:

Player spawns a small "foot detection" block (no special attributes) directly below himself, and the 'foot' is then pinned to the player. When player's foot overlaps with the vertical platform (later I'm going to add more precise detection to determine that the player is colliding on the top of the platform itself), the player is considered to be riding the platform, and the player's bottom Y is continually set to the platform's top Y value. This works without any problems, the problem is that when the platform is moving downward and in the mean-time *between* setting the player's Y, and going through another ??TICK?? (looping through another logic iteration), the engine sets the player to be in a "fall-state", so the player platform behavior will not respond to a jump action.

Do I need to control the platform's movement manually in the event sheet so that I can make it so that the player's Y is set to the Platform.Y *after* the platform has moved? I have a feeling that this might be part of it. It's just so nice to be able to use the Sine behavior to automatically control the vertically moving platform.

Thanks a lot everyone!

-- cacotigon

P.S. Don't worry about the DefaultInstances layer or the disabled gravity code.

I didn't open your capx but it seems you came up with the same solution as me

http://www.scirra.com/forum/forum_posts.asp?TID=47845&PID=299944&title=platFormer-jumps-on-vertical-moving-platform#299944

Hey Yann, thanks for the reply, I implemented the changes that I had outlined earlier in this post about manually controlling the platform and removing the Sine behavior altogether.

I've also added an OnPlatform boolean which is checked before the platform is moved. This is recommended since if you have a fast moving platform, the next Y coord of the platform may already have carried it too far away from the player (especially when moving downward), in which case the subsequent 'check if feet overlap' condition will return false and the player's Y will not be aligned with the Platform's new Y, and the player will enter the falling state again.

Here is a snapshot of the event sheet:

<img src="http://i41.tinypic.com/2n1tjyc.jpg" border="0">

EDIT: Picture is wider than I thought, so you'll have to scroll to the right to see it, sorry about that.

As you can see in this screenshot, immediately after the platform is moved, the player's bottom Y is anchored to the Platform Top. This basically eliminated the problem I was having earlier with the sine behavior.

Despite this, the event sheet still records the occasional on_fall and subsequent on_land triggers while riding the platform. I don't understand how this could be happening if the event code runs in a line-by-line interpretive fashion.

FIXED!!!: Okay, I started logging the respective Y coordinates to see if I could narrow down the random fall-state detections. (in this instance, I'm referring to the Player's bottommost Y, and the platform's topmost Y). Being floating point numbers (and possibly due to pixel rounding???), they were off by ~0.5 whenever the jump-state happened. I decided to Math.floor my ManualPlatform Set Y event whenever the motion happened to see if this would fix the problem, and the problem went AWAY!!!

Here is the final project file, which contains logging text fields, lots of comments, and instructions.

Final Vertical Platform Project

Final thoughts:

A standard vertical platform has Construct built-in sine behavior. In normal circumstances, when the player is considered "riding" the platform, the Player Y would then be set to match the platform Y in the event code. The built-in sine behavior is responsible for updating the Platform Y moving it away from the Player Y . HOWEVER, this sine behavior logic does not happen in the event sheet. After Construct's Sine behavior updates the Platform's Y value, Construct's Platform behavior detects a gap between the Player and the platform and triggers the platform fall-state. All of this happens before the next event cycle, meaning we have no time to update the player's corresponding Y value to match the platform.

Some things to note about the project:

1.The way I've got it now, holding the Shift key will accidentally disable the platform attachment code, with ensuing hilarity.

2. To change the movement behavior of the manual vertical platform, use the instance variables MaxMovement and MaxTimeToMove (in seconds, use longer values for slower platforms), StartingY is used by the system.

Also, kyatric or another moderator, if you think that this information might be potentially useful to others, maybe we could add it to the [How to] Vertical Platforms forum post. I was also thinking about writing up my findings in a tutorial, if that could be helpful for the community.

Back to work!!

-- cacotigon

NOTE: I originally had all vertical platforms classified under a VerticalStylePlatform family, however, I went ahead and removed it as I wasn't certain whether this would cause problems for people who had the free version of Construct 2.

You're example won't work with more than one instance of the vertical moving platform.

You really should look at my example (:

Whoops, I see that. Guess I'm not used to the way instances vs objects are handled in the event sheet yet. :) Thanks for the heads-up.

Just a small note, I've updated the project file to support multiple platform instances using the index ID.

Vertical Platforms Example Project

Try that, you had a redundancy between your boolean "isOnPlatform" and your variable PlatformIID.

They followed the same pattern if you reset the PlatformIID to -1 when you're not on platform.

So you don't need the isOnPlatform variable.

I also changed to UID instead of IID. UID is the unique ID of each of your platform whereas IID it the temporary ID of the platform within a filtered (or not) selection.

In your case that works... But I feel like UID is more relieable.

cleaned_VPlatform.capx

Thanks Yann, I took a look at the changes you made. I guess the use of PlatformIID makes isOnPlatform redundant.

Nice work on this. I've been struggling with vertical platforms and your code has really helped me out.

I took Yann's revised example and added an event so that jumping off the platform is now allowed.

Here's the capx:

http://dl.dropbox.com/u/47015043/construct2/cleaned_VPlatform.capx

But there is a problem. When you are on platform, you can't jump correctly.

Do you see it?

The green platforms work fine (as they should) on my machine. The blue platform (which should not work correctly, since it's using standard sine behavior) continues to be broken when jumping.

Are you experiencing something different?