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