PathShape resource jitter problems.

#1 Is this in a dedicated server-client setup or singleplayer or both?

#2 Both.

#3 Any ideas? Anybody?

#4 Your simulation process differently on client and server.
I solved that problem 2 years ago, finally did a better solution - animated movable platforms with dynamic attachment.
I did this resource for a client, therefore I cannot share the code.

#5 Hmm, perhaps derive your platform from a vehicle, then mount the player to it while it moves. That way the platform follows the path and also directly handles the player's movement.

I haven't looked at it, ever, but if you need more help just say the word and I'll try to make some time to look into it.

#6 Thanks guys.

@Ivan: I knew about the discordance between the client and server, I just didn't know where to look. So far, I've traced the problem to the Gamebase.cpp pack/unpackupdate functions. We'll see where this will take me.

@Richard: That's something that I didn't think about. I will continue working on the first solution, and if I get to a point of no return, I'll give you a shout.

In the meantime, if anybody's got any suggestions, I'm listening.

#7 If I remember correctly, I thought that resource never updated the player's dead-reckoning routine to take into account the movement of the object it was on and so the player would be jittery. It might be as simple as adding that in.

#8 I'm sorry Kenan, I don't understand.
You mean to update the transform of the Player with that of the Platform?

#9 read through player::processtick, updatePos, and _move.
Someone correct me if i'm wrong, but basically the client stores a vector of an object's last known good position and velocity from the server and extrapolates on that. A player object does that using only its own velocity and doesn't take into account the added velocity from something it's riding in this resource (unless it's been updated since i last looked at it).
If the client's object is too far off from a server update, then the client just jumps the object to the now known good position. this is what i noticed happened when I was viewing another player object riding a pathshape because the client was never predicting a correct position and having to be constantly corrected by the server, hence jitters.
It should be as simple as adding in the player code to check if it is riding something and add it's velocity to the player's.

#10 Thanks Kenan. It makes sense.
I'll see if that fixes it.

#11 Well, updating the Player's velocity (mVelocity,) in relation to the platform shape, does not seem to remove the jitters.

Maybe I'm doing somrthing wrong, but the way I did is, in updateMove(...), just before "mVelocity += acc;", I added the following code:

ScneObject *platformShape = getParent();
if(platformShape != NULL)
{
 VectorF platformVel, direction;
 platformShape->getTransform().getColumn(1, &platformVel); //For the platform shape, getVelocity() returns zero all the time; thus, I'm asuming that the platform has no velocity defined, 
//hence, the aquisition of the forward vector as a replacement.

 F32 platformSpeed = platformVel.len();
 platformVel *= platformSpeed; 
 mVelocity += platformVel; //Add the velocities together.
}

I should mention that I'm using Physics with this resource.
I'm using,

PhysicsCollision* colShape = mShapeInstance->getShape()->buildColShape( false, getScale() );

, to create the colision shape arround the object that has colBox-1 defined as its colision box.

Only time I see no jitters, is, when I remove the "setTransform(mat);" in PathsShape::interpolateTick(...); But, then the bounds of the platform-shape is left behind (does not update.)

Any suggestions?

#12 I also tried without Physics, and the jitters are still there.

#13 You need to do some tests and/or give us more information. There is too little here to help much more. Can you post a video of the problem?
Also, did you make sure to do the part in gamebase that makes the attached object process after the object it is attached to?

#14 From memory, I believe its down to a camera issue, if you are in 3rd person mode, perhaps inside an object that moves? Might not be the same issue you are having though.

#15 @Kenan: I added a video to show you what I mean. But, it's basically what you said in post #9. And, yes I did make sure the Player is processed after the platform (i.e processAfter(platform);).

@S2P: I'm not sure what you mean. The problem happens in both 1st and 3rd person camera mode. See the video in my original post.

#16 it looks like it might be a collision issue. Have you tried having the platform go on a horizontal path instead of vertical and seeing if the issue is still there?

#17 @Kenan: Yes. I have tried that, as well. Like you mentioned in post #9, in Multiplayer, the Client Player (if I remember right) lags behind (falls off the Platform) and then catches-up. I think it's got something to do with the positioning of the Player.
I think, the Player's transform and that of the platform are updated at different ticks.

@Richard: It looks like I have to take you up on that offer. If you could look into this problem, I'd really appreciate it. Two heads are always better than one. :)

Arghh... This is the worst bug yet.

#18 Ok, I'll try to poke my nose into it tonight or tomorrow - hopefully I can find something useful.

#19 @Richard: Ok. Let us hope. :)

I noticed that the velocity of the Player does not get an update, unless a key is pressed; thus, the velocity of the Player (mVelocity) does not get updated, when standing on a Platform. It is always zero (0).

#20 No, velocity has noting to do with your problem.
You have a Parent node,that controls your transform (and render transform).That's why you have a zero velocity.

There were several problems with this old resource.
I remember that the first one was a duplicated network mask.
The rest ones were around the attachment and the notification system.