Hello. For my third person setup, I’m using the dynamic collision type for player-wall collisions, but for floor collisions, I simply use a raycast to pin the player to the floor (I’ve found this to be the best way for a variety of reasons). However, that means that the character won’t stick to moving platforms unless I manually add their linear velocity to the player’s velocity. So far, so good, but I’ve ran into a tiny problem: when the platform changes it’s direction, there’s a one-frame lag before the character starts to move with it. I’m using getLinearVelocity to get the platform’s velocity, and apparently it’s return value lags one frame behind the platform’s actual velocity. By the way, my platforms are static physics objects, and I move them using the location field on the simple motion logic brick, in case it matters. So, does anyone know of a way to compensate for this lag? Or perhaps there’s a mistake in my implementation? Thank you.
It’s probably your implementation. When are you executing your script in the logic?
Try applying a moment of SetLinearVelocity(0,0,0) for both right before move?
what is moving the platform?
Logic lags behind physics slightly due to animation update loop
You could use “Force Pin”
you need to calculate where they are to stand, and have that as the “StrikePos” target
X1 = the strength
this will apply force to keep them in that place, it can be small and they will “gravitate” to where they need to be,
while on platform------------------python 1
python 1
import bge
cont = bge.logic.getCurrentController()
own = cont.owner
target = own[‘StrikePos’]
Pos=own.worldPosition
distance = own.getDistanceTo(target)
vec = own.getVectTo(target)[1]
X1=own[‘X1’]
force = vec * X1
own.applyForce(force, 0)
The script is the only logic for the character, and the platform is moved via logic bricks. I’ve checked at the control flow for the script, and everything seems to be happening in proper order.
So I guess this is solved.
How exactly did you solve your problem if I might ask?
I wrote my “solution” as a response to BPR’s quote. It’s actually placed in his quote, in bold. Note that I haven’t tried to implement it yet. It’s just a general idea.
Yes, I read it. But I didn’t see this idea could work. Because how would you get the velocity of the platform in the second direction while it is still moving in the first direction? But now I think you can get it by multiplying the motion of the platform (per second) with the direction Matrix.
As far as I read it the character is a physics object (dynamic) the platform is not a physic object (static).
In terms of physics the platform is teleporting. I do not know what happens with physics objects on the pllatform. In best case this is interpreted as motion and friction takes place.
So you need to use a friction (player and platform) that survives the motion differences of player and platform. This is more a “real world approach”.
If that does not work you can try to cancel out the speed difference, by adding the theoretical velocity of the platform to the character on contact. It might be enough on first contact and when platform changes direction.
The difference to BPRs solution is, that you look for speed differences not for loction differences.
If small mass momentum effects are not acceptable you can parent the character to the platform. But then it looses is physics status.