Game Development Community

Projectile initialPosition issue - explanation inside

by elvince · in Torque 3D Professional · 03/24/2010 (9:22 am) · 2 replies

Hi,

If I echo the initial position '%obj.getMuzzlePoint(%slot);' of a projectile and look in debug mode the mCurPosition during the onAdd(), I have many time different values.

It seems that when I look at it in the code, we are at the next tick(1 to 2) position and not the current "initial" one.

Is it normal?

I saw that because I tried to implement a laser gun shot, and when rendering a laser beam from initial position to current position, I saw that the initial position differs a lot from the muzzle point.

Thanks,


#1
03/31/2010 (12:59 am)
My initial thought here was that you must be connected to a DS and simply losing some initialupdate packets (or having them pushed back due to packet size limits), resulting in the initialupdate being resent a tick or two late, after the projectile has sim'd forward a bit.

However, I remembered noticing something similar when doing projectile trails for relatively fast projectiles in singleplayer. The trails generally start a good distance ahead of the muzzlepoint, at what appears to be the position of the projectile during its second tick.

My theory, which I'm too tired to test at the moment, is that the server isn't bothering to tell the client about this new object (to ghost it to the client) until after it's already done a tick of physics processing. This would still impact singleplayer, since it's doing a sort of client/server "simulation."

Assuming this is singleplayer, you should see which instance of onAdd you're actually looking at, as there will be an initial server-side onAdd and a later client-side onAdd when the ghost is created. If you actually are connected to a DS then obviously you'll want to debug the server itself to see the server's onAdd event.

IMO the client should predict the projectile's creation to avoid any lagging projectile issues, but that's another topic.
#2
03/31/2010 (12:14 pm)
To confirm your thoughts, I was on a single player game, but my target is DS.

I did additional tests, and simulate function can be called before the first packupdate that will initiate the create object on the client.

So it's clear that the initial position can be trusted on the client and I need to send a special packet on the initial update to get the real "initial position" and not taking the current position.

This is not a bug, but just the T3D internal logic that I didn't catch at first sight.

I updated the initial thread as it's not a bug.