Slight pause before muzzle flash
by Andrew Edmonds · in Torque 3D Professional · 07/15/2009 (12:09 pm) · 6 replies
Hi all,
I'm trying to get some muzzle flash into my game with limited success. I now have the flash working but there is a short pause before the flash appears. It is very brief (less than 1/2 second) but it is long enough that the bullet has already hit the target before the muzzle flash appears which is less than ideal :)
My weapon is exported as a collada object and to get the muzzle flash I have a flat cylinder mesh at the muzzle point with a flash image as its material.
I am using the visibility value in 3ds max to control the visibility of the muzzle flash mesh. The muzzle flash mesh has visibility=0 at frames 0-4 and visibility = 1.0 at frames 5-25.
The following code sets up the animation:
This leaves just the 'fire' animation which is referenced in the 'Fire' state of the weapon image. The frame numbers are just chosen arbitrarily to use the frames when the flash is visible.
The setup works - the flash is not displayed until you fire the weapon. However, there is this pause. Any thoughts?
Thanks...
I'm trying to get some muzzle flash into my game with limited success. I now have the flash working but there is a short pause before the flash appears. It is very brief (less than 1/2 second) but it is long enough that the bullet has already hit the target before the muzzle flash appears which is less than ideal :)
My weapon is exported as a collada object and to get the muzzle flash I have a flat cylinder mesh at the muzzle point with a flash image as its material.
I am using the visibility value in 3ds max to control the visibility of the muzzle flash mesh. The muzzle flash mesh has visibility=0 at frames 0-4 and visibility = 1.0 at frames 5-25.
The following code sets up the animation:
function xm8_newDAE::onLoad(%this)
{
%this.addSequence("ambient", "fire", 5, 15);
%this.removeSequence("ambient");
}This leaves just the 'fire' animation which is referenced in the 'Fire' state of the weapon image. The frame numbers are just chosen arbitrarily to use the frames when the flash is visible.
The setup works - the flash is not displayed until you fire the weapon. However, there is this pause. Any thoughts?
Thanks...
About the author
Formed in 2005, EiKON Games is an indie games development project based in the UK working on the tactical first person shooter "Epoch: Incursion". See the Join Us or Contact Us pages at http://www.eikon-games.com/
#2
07/15/2009 (12:42 pm)
Thanks Logan - I suspected it might be a client/server issue. Time to hit the source I think! 
#3
07/15/2009 (2:00 pm)
Not very logical for a default. 
#4
I took a look at doing this for a game project a few years ago and always wanted to get back around to it. Here's the short-form...
Logan is spot on. This is the problem, and the way to fix it is basically what he describes, a client-side prediction. This is something I'd really like to get to doing at some point, since it really is a core-engine thing. (Another side-effect of this is "my smoke trail starts like 50' from my gun, why is that")
So the idea would be to take the input packets, and run them through the control-object *before the input packet is sent*, and look for state changes and object creations. If an object (like a projectile) is created, FIRST create it client side, and take the SimObjectId, and stuff that into the packet sent to the server to create the object. The server gets that packet and says, "Ah I must ghost a projectile to all clients." (Other clients won't see the muzzle-flash, and the fire offset...they will see them happen at the same time.) So the server will ghost the object to all the clients, and when it sends the create ghost to the client who created the object (and only that client, as it is not useful or needed to the other clients), it will send back the SimObjectId that the client sent to it with the create packet.
Note: The server does no processing at all on that SimObjectId. All it does is send it back with the create ghost packet.
When a client creates a ghost which has a SimObjectId passed to it, it knows, "Hey I created a client-side prediction object for the ghost I just recieved, and this is the SimObjectId of that client side prediction." The client can then rectify any differences in the position of the ghost with the position of the client side prediction.
@James: It is actually perfectly logical. It's just misunderstood, and misused.
07/15/2009 (2:46 pm)
Eikon,I took a look at doing this for a game project a few years ago and always wanted to get back around to it. Here's the short-form...
Logan is spot on. This is the problem, and the way to fix it is basically what he describes, a client-side prediction. This is something I'd really like to get to doing at some point, since it really is a core-engine thing. (Another side-effect of this is "my smoke trail starts like 50' from my gun, why is that")
So the idea would be to take the input packets, and run them through the control-object *before the input packet is sent*, and look for state changes and object creations. If an object (like a projectile) is created, FIRST create it client side, and take the SimObjectId, and stuff that into the packet sent to the server to create the object. The server gets that packet and says, "Ah I must ghost a projectile to all clients." (Other clients won't see the muzzle-flash, and the fire offset...they will see them happen at the same time.) So the server will ghost the object to all the clients, and when it sends the create ghost to the client who created the object (and only that client, as it is not useful or needed to the other clients), it will send back the SimObjectId that the client sent to it with the create packet.
Note: The server does no processing at all on that SimObjectId. All it does is send it back with the create ghost packet.
When a client creates a ghost which has a SimObjectId passed to it, it knows, "Hey I created a client-side prediction object for the ghost I just recieved, and this is the SimObjectId of that client side prediction." The client can then rectify any differences in the position of the ghost with the position of the client side prediction.
@James: It is actually perfectly logical. It's just misunderstood, and misused.
#5
I know why you guys have it that way it is far more accurate for the network. but I Think almost every modern combat game out there uses the prediction method.
07/15/2009 (2:55 pm)
I meant have projectiles handled this way. I dont know of any game where that kind of delay would be acceptable? except for maybe a RTS or something. but then again that is a whole different attach mechanic anyway.I know why you guys have it that way it is far more accurate for the network. but I Think almost every modern combat game out there uses the prediction method.
#6
07/15/2009 (3:16 pm)
I think the networking on every modern combat game sucks. Granted the last one I played was Halo 3. Any game where a single client (not the host) can lag the entire game (clients and host), does not get my networking seal of approval. At that point, it doesn't matter if the projectiles look "perfect" or not. 
Associate Logan Foster
perPixel Studios
Long story short, even in 'singleplayer' mode, Torque by default will act like its its own client-server connection and as such there is a small delay in the creation of things like projectiles, muzzle flashes, etc.
I am sure someone else will pipe up with the exact details, but if you want this to be deadly accurate you are going to need to make some changes to the projectile code with a client-side predicition. I wish I could tell you how but I bully pixles for a living.