How do I get platform actor to adapt speed to a moving solid

So if I use a solid tiled background with a sine moving it horizontally, my character lands on it and is "pinned" and moves with it. Half way through the cycle (while the platform has a decent amount of speed) I jump and the platform sprite just stays in place. I want it to retain its speed when leaving the moving platform. Like... you know... the laws of physics suggest should happen.

You dont need the pin. When you make a new project, there is a template 'platformer'. It solves your problem.

It's not using the pin behavior. I was just describing what happens when you land on a moving solid block. I'm thinking I'm going to have to the moving block save its position, and compare it next tick to give a distance moved and have it apply that value to the player when it they jump off. I dont know. I'll figure something out.

edit: the template platformer has the same problem anyway. You jump when the block your on is moving and you just stay in the same place..

This you mean ?

https://www.dropbox.com/s/bojgx6n9wtd3b ... .capx?dl=0

something like that. directly manipulating the x and y while using movement behavior can cause it to glitch out on collisions.

That is true, but since you choose for sine (wich pushes things to any and every solid), i did't think that would be a problem. Must manipulate vector X and vector Y. But that gonna be hell if you want it to land on an exact place on the sine.

Not land on the same point. Just keeping the momentum gained from riding the platform. It shouldn't be too hard to get working. It would be nice if it was built in but yeah. Thank you for your response. I rarely get responses or help on these forums.

Got to add the vector of the platform to the vector of the player on jump.

https://www.dropbox.com/s/3jxpiwz7k2kyp ... .capx?dl=0

I used a platform to move the platform. I like that movement.

But. It has a bug when you jump from beneath against it. Suddenly a zero gravity gets non zero. Lower the upper platform to see it happen.

The reason why i tried platform to move it, is because you said something about collisions, and i need an already dt corrected vector. (sine is not)

I think we would be able to use the solid sine movement if we could use DT to "transpose" pixels moved per tick to pixels per second for the platform velocity to manipulate. I began using my own variables to run platform.velocity X/Y directly instead of using "default controls". So it's just going to take some flag switching and setting the platform velocity directly to general x/y velocity for the player to work under and an absolute x/y that gets set when leaving a platform or getting smacked by one or something. But since the platform velocity works in pixels per second... What do you think the math behind that would be?

Im thinking pixels per frame to second would just be "self.X - self.prevX * fps", and pixels per second to frame would be self.Platform.VelocityX * dt.

edit: It seems I have found solace in this:

On Jump Overlapping TiledBG2

self.VelX = (self.VelX + (TiledBackground2.X - TiledBackground2.prevX) * fps)

From pixels/tick to pixels/seconds should be pixels/tick * fps.

If you move something at 5 pixels per tick at a 60 fps, you move it 300 pixels in 1 second.

If you move something at 5 pixels per tick at a 30 fps, you move it 150 pixels in 1 second.

But, that illustrates the problem, of course. It should move the same amount of pixels in a second, whatever the FPS.

So it is pixels/tick * fps * correction.

Now we really can talk about pixels/seconds, because unit/second also says that it is fps in-depended.

This correction = (1 /fps) * 60.

Or 'pixels/second' = ( 'pixels/tick' /fps) * 60 .... and .... 'pixels/tick' = 'pixel/second' * (60 / fps)

Now .. 60/fps = dt (mathematical). So also 'pixels/tick' = 'pixel/second' * dt

But dt is in reality caged. Once below 30 fps/sec, dt will not go any higher. You can set this minimal fps with a system action.

I rather advice you to use dt, above 60/fps. Because once 60/fps gets to high, the system just cant detect collisions and that kind of stuff anymore, because the time taken by 1 tick is just to big. Objects will move to much between ticks.