How do I correct the weapons firing problems that T3D seems to have.
by James Brad Barnette · in Torque 3D Professional · 06/17/2009 (8:21 am) · 11 replies
How do I correct the weapons firing problems that T3D "and all GG demos for that matter" seem to have.
To let me be more specific I will list the issues I have noticed over the years that seem to still be very present in T3D.
1: About half the time when you fire the weapon no sound occurs.
2: all of the time the particles from the projectile do not start until they are some distance from the character.
3: Also about half the time you get no particles at all just the explosion at the target. " this is really bad and obvious in the PhysX demo.
and of course some times you may get any number of these happening together. I have had times in the physX demo when I fire and here no sound, see no particles at all and the just see the explosion at the target.
These have been present since the Stronghold demo and seem to be at their worst in Beta 2 version of the PhysX demo. But they are present in all GG demos that have included weapons fire.
To let me be more specific I will list the issues I have noticed over the years that seem to still be very present in T3D.
1: About half the time when you fire the weapon no sound occurs.
2: all of the time the particles from the projectile do not start until they are some distance from the character.
3: Also about half the time you get no particles at all just the explosion at the target. " this is really bad and obvious in the PhysX demo.
and of course some times you may get any number of these happening together. I have had times in the physX demo when I fire and here no sound, see no particles at all and the just see the explosion at the target.
These have been present since the Stronghold demo and seem to be at their worst in Beta 2 version of the PhysX demo. But they are present in all GG demos that have included weapons fire.
About the author
#2
2: if that is the case GG needs to double check these before sending out the final release as it seems very sloppy as it is now.
3: yeah I haven't been able to tract down a cause for this one yet either. the only consistent thing about it is it's inconsistency. LOL
06/17/2009 (9:03 am)
1: I speaking specifically to the demos. I have not tried my own weapons in a project yet as our current project doesn't use weapons.2: if that is the case GG needs to double check these before sending out the final release as it seems very sloppy as it is now.
3: yeah I haven't been able to tract down a cause for this one yet either. the only consistent thing about it is it's inconsistency. LOL
#3
EDIT: in fact I've significately altered the behavior of the three weapons in the FPS kit in between then and now.
06/17/2009 (9:52 am)
2: Speaking as the guy who setup up the weapon fx in the FPS kit, everything works exactly the way I intended it -- barring a few minor inconsistencies. In my opinion it's an improvement over what would have been the stock effects. You will see further changes/improvements in Beta3 :DEDIT: in fact I've significately altered the behavior of the three weapons in the FPS kit in between then and now.
#4
I agree that this needs to be looked into. Have it on my list right behind the (now gone) notorious disappearing weapon bug but haven't had the opportunity yet to really look into what's going on. Maybe it's a networking issue as errors seem to most often show with short projectile paths so that possibly the quick object death is affecting replication.
06/17/2009 (10:09 am)
I agree that this needs to be looked into. Have it on my list right behind the (now gone) notorious disappearing weapon bug but haven't had the opportunity yet to really look into what's going on. Maybe it's a networking issue as errors seem to most often show with short projectile paths so that possibly the quick object death is affecting replication.
#5
What happens is that the client fires their weapon which then basically sends a request to the server to create the projectile. The projectile is created and ghosted to the client but by the time it arrives (due to lag or packet swamping or whatever) the projectile has already collided on the client. The client internally creates the projectile, backs the simulation up to the point where it was created, re-runs the simulation up to the current time on the client, sees the collision, and deletes the projectile and its related effects that have also timed out in the meantime (particles, explosion). Since all of this happened before the current time on the client then at the current time nothing gets rendered. You'll still see the server-side effects of the projectile and explosion (damage, radius damage, radius impulse, etc) but you don't get to actually see the projectile, particle effects, or explosion.
There is a way to "fix" this which is to spawn client-side "imposters" of the projectile, particle effects, and explosion effects, send the request for their creation to the server, and when you get back the acknowledgement and/or corrections, link and sync the client version to the "correct" server's version and all of the future server updates of that object (after all, your client's prediction of the projectile's trail could actually be completely wrong because of the effects of another client which hasn't reached you yet...like someone unpredictably stepping in the line of fire).
Aside from the complexity of managing that sever<->client syncing (which isn't hard but also isn't the easiest thing to get right), it can actually cause some disconcerting client experiences (emptying a clip of bullets into a client which isn't actually where you think they are because of lag...you see all of the bullets, explosions, and blood splatters but they take no damage). The makers of Torque back in the day decided that it was less disconcerting to not always see the prediction but to always get the results rather than allowing you to get the full feedback of a bad predictive state.
Unfortunately, pretty much every other game outside of Tribes/Torque has gone the other route (I found COD4 particularily bad at this...I would blast a guy in the face with a shotgun only to have him lazily turn around and shoot me and the death cam showed that I never came close even though on my screen I did). At this point in time the accepted standard among online shooters is to allow the client to see the results of the bad predictions.
This is something I personally would like to see addressed in Torque at some point but we haven't had the engineering resources to properly solve some of the trickiness of the networking management.
06/17/2009 (3:21 pm)
This sounds like a classic Torque networking issue.What happens is that the client fires their weapon which then basically sends a request to the server to create the projectile. The projectile is created and ghosted to the client but by the time it arrives (due to lag or packet swamping or whatever) the projectile has already collided on the client. The client internally creates the projectile, backs the simulation up to the point where it was created, re-runs the simulation up to the current time on the client, sees the collision, and deletes the projectile and its related effects that have also timed out in the meantime (particles, explosion). Since all of this happened before the current time on the client then at the current time nothing gets rendered. You'll still see the server-side effects of the projectile and explosion (damage, radius damage, radius impulse, etc) but you don't get to actually see the projectile, particle effects, or explosion.
There is a way to "fix" this which is to spawn client-side "imposters" of the projectile, particle effects, and explosion effects, send the request for their creation to the server, and when you get back the acknowledgement and/or corrections, link and sync the client version to the "correct" server's version and all of the future server updates of that object (after all, your client's prediction of the projectile's trail could actually be completely wrong because of the effects of another client which hasn't reached you yet...like someone unpredictably stepping in the line of fire).
Aside from the complexity of managing that sever<->client syncing (which isn't hard but also isn't the easiest thing to get right), it can actually cause some disconcerting client experiences (emptying a clip of bullets into a client which isn't actually where you think they are because of lag...you see all of the bullets, explosions, and blood splatters but they take no damage). The makers of Torque back in the day decided that it was less disconcerting to not always see the prediction but to always get the results rather than allowing you to get the full feedback of a bad predictive state.
Unfortunately, pretty much every other game outside of Tribes/Torque has gone the other route (I found COD4 particularily bad at this...I would blast a guy in the face with a shotgun only to have him lazily turn around and shoot me and the death cam showed that I never came close even though on my screen I did). At this point in time the accepted standard among online shooters is to allow the client to see the results of the bad predictions.
This is something I personally would like to see addressed in Torque at some point but we haven't had the engineering resources to properly solve some of the trickiness of the networking management.
#6
Thanks for the great explanation, Matt. Gone straight to the snippets collection.
06/17/2009 (3:39 pm)
Thanks for the great explanation, Matt. Gone straight to the snippets collection.
#7
I use a similar system to what Matt was describing with having client-side projectile dummies that are synched up over time with the server-side versions of things. Higher rate-of-fire projectiles actually use random seeds to synch clusters or bursts of munitions while maintaining a minimal network overhead.
Once T3D is out of beta I'll be working on porting over my codebase and if I get sufficiently bored I may just post it as a resource. Of course, it's going to be a _lot_ of porting because I was stupid enough to do things like tidy up the math classes and so on (so much nicer to have a standardized interface for conversion to/from strings for example).
Here's a fairly old movie of them in action:
About halfway through you can see the rapid-fire projectiles and so on with no appreciable lag in their appearance after pressing fire. There can be a slight discrepancy in accuracy with high numbers of players on a server (> 30, which is why I'm building the game for a limit of 24), but otherwise... No dramas.
Still... I use a server-client feedback loop per projectile hit to flicker the reticle and trigger a short "tick" sound to ensure you know when you're actually hitting someone -- just in case.
06/18/2009 (1:13 am)
This issue (among a few others) is one of the reasons I completely re-wrote the projectile code for my game in TGE. There were just too many situations where excess network usage (primarily unnecessary usage by player and especially vehicle-derived classes) caused delays or non-existent projectiles/effects/explosions.I use a similar system to what Matt was describing with having client-side projectile dummies that are synched up over time with the server-side versions of things. Higher rate-of-fire projectiles actually use random seeds to synch clusters or bursts of munitions while maintaining a minimal network overhead.
Once T3D is out of beta I'll be working on porting over my codebase and if I get sufficiently bored I may just post it as a resource. Of course, it's going to be a _lot_ of porting because I was stupid enough to do things like tidy up the math classes and so on (so much nicer to have a standardized interface for conversion to/from strings for example).
Here's a fairly old movie of them in action:
About halfway through you can see the rapid-fire projectiles and so on with no appreciable lag in their appearance after pressing fire. There can be a slight discrepancy in accuracy with high numbers of players on a server (> 30, which is why I'm building the game for a limit of 24), but otherwise... No dramas.
Still... I use a server-client feedback loop per projectile hit to flicker the reticle and trigger a short "tick" sound to ensure you know when you're actually hitting someone -- just in case.
#8
It is used to prevent collision with the player/aiplayer.
For a client game you can create entirely client side projectiles and disable all network issues.
06/18/2009 (1:47 am)
2. SourceIdTimeoutTicks (231ms) is the delay of projectile.It is used to prevent collision with the player/aiplayer.
For a client game you can create entirely client side projectiles and disable all network issues.
#9
06/18/2009 (7:14 am)
@Matt- That is interesting especially since I conducted this test in a single player mode of the FPS on a 8x3.2GHz system with a 1.5GB quadro FX 5600 and 8GB of ram. I would think there would be no delay or lag at all even if it is still doing the client/server stuff internally no? 
#10
So, if you send more information than you can in a tick, the objects that missed the packet need to wait for the next tick. If your game is strictly single-player, there are ways to increase the packet size in the source code so it doesn't bother you, but I'm not sure where it goes in T3D.
If your game is going to have multiplayer... you have a problem. Time to write custom classes or modify the existing ones to suit your new usage pattern.
06/18/2009 (7:24 am)
No, you can have local lag, since there's a limit on the packet size sent from the server to the client. When running a local game, it just doesn't use a network connection and the server simply writes the packet into a buffer that is then read by the client code, but everything else works as if it were in a networked environment.So, if you send more information than you can in a tick, the objects that missed the packet need to wait for the next tick. If your game is strictly single-player, there are ways to increase the packet size in the source code so it doesn't bother you, but I'm not sure where it goes in T3D.
If your game is going to have multiplayer... you have a problem. Time to write custom classes or modify the existing ones to suit your new usage pattern.
Associate Michael Hall
Distracted...
2. Depends on the projectile velocity, along with the offset and ejection velocity (and a few other settings) of the particle emitter and particles.
3. I've only seen that recurringly in the PhysX demo, with an occasional failure in rare situations in the other projects.