Rapid fire weapons uneven fire rate

#1 I'm not here to answer, just to verify that I have noticed it as well.
My personal thought is latency from drive reading between Server and Client on the single computer.
But definitely interested in the answer that the Community has for this.
Thank you for posting the question :-)

#2 Could it be the sound effects buffer getting filled up?

#3 Latency could definitely be an issue. Also, IIRC, are images updated every tick? If so, that's a 31Hz limit on your time resolution which may be messing some stuff up (as opposed to updating every frame... though I guess 30fps is pretty good. Not sure if this is actually an issue). I remember that to get rapid-firing images playing nicely in TGE required some special sound effect work - basically making a looping gunfire sound instead of having each state transition play a sound.

#4 Really, the resource manager should not be trying to reload that sound from disk every time it plays - should not. I hope not.

However, I think Daniel's solution might be a good place to start - Even back in the Tribes days the chaingun had that warmup sound, the looping firing sound and a winding-down sound.

#5 Is it the rate of each projectile round that appears to stutter, or the firing sound itself?

#6 If you start the FPS tutorial and use the default Lurker (?), just hold the fire button for a bit and you'll notice the animation/sound/decal delay.

The FPS tutorial for T3D 1.2 doesn't have the GUI enabled for NetGraph, but while using any new game project you can press "N" to show the NetGraph for a visual of whats being seen and heard.

BTW, the delay isn't a soldier or weapons pack issue. The delay is noticeable with any high rate of fire.

#7 A further note - back in TGE I also modified weapons so that they did more client-side. I think I ended up almost fully simulating the weapon on the client, not firing script events or anything, of course, but responding to user input and so on. Made for less lag in starting to fire and so on, and you can trust that the server will keep up.

#8 The way that ShapeBaseImageData weapons fire is as follows:

1. Client trigger move event is sent to server
2. Server weapon image is set to fire.
3. Server generates projectile.
4. Client is told to fire and receives new projectile.

So before the weapon appears to fire on the client, it first needs a round trip to the server. Also, the server tends to batch up its processing from the clients so there is likely some delay there as well.

All of this makes the server completely authoritative on weapons fire, and the client is just reacting to the server. Most modern FPS games just have the client play the effects without waiting on the server, which gives you more control over the look and feel of fast firing weapons. You would have to expand Torque's weapon handling to do more client-side if you wanted the same effect (as Daniel has pointed out).

- Dave

#9 It really surprised me that Torque doesn't even play weapon effects client-side, given the attention to the client experience that the rest of the netcode pays. All that prediction and stuff for player movement is fantastic, but weapons deserve just as much attention.

#10 @Daniel:
I agree that it is a little old-school now. Back then, when you saw a player get hit you knew they were actually hit. People would complain that their weapon lagged when they didn't hit their victim in the face due to timing. Obviously, it was hackers slowing the system down...

In most shooters today you expect to see your weapon in action immediately, and they add a hit indicator so you'll know the server's response. People now complain if they didn't hit the victim in the face when the client clearly showed that they did ("See my FRAPS video of the incident!!1!"), due to server authority. Obviously, it is hackers messing with the projectile/player collision...

We just can't win either way! :P

But seriously, this would be a good place to have the option of client-side prediction, especially for single player games.

- Dave

#11 "Their time has come. Destroy them all!"

#12 In one respect it is the black hat hackers that caused the need for such measures. If they didn't cheat then you could use client side prediction. Not the world we live in though. Probably never has been the world we live in.

I think some games have tried to rectify this by allowing the client side to predict, but the server still has to make sure it was valid. I don't know how it was done, but I thought I remember something about Quake 3 having something like that. It could be an interesting blog if someone wanted to research this issue and possibly come up with some options.

#13 For head shots perhaps the client can tell the server it hit a specific body part. If the server determines that body part was within a certain distance at the time of the shot then it could grant the shot. If not then it could act normally and return where ever the server thinks the shot landed.

However, I saw something about Halo 3 using the same method T3D is using with simple and complete server authority. Perhaps the solution is to remove as much latency as possible rather than trying a some new algorithm? That would only be for hit detection, not the actual animation to fire the weapon. That should be adjustable.

#14 Putting in my 2 cents, I would personally shy away from client-driven effects/prediction. If the netcode isn't to snuff(not saying that's an issue for torque) or the client has higher latency, you get some major differences between what the player thinks is happening, and what the server says happens. I've run into this a lot when playing the more recent CoD games, all effects, from weapon effects/sounds, to bullet impacts, to the hit 'thumper' indicator are client side.

This is bad if the client shows 20 bullets hitting the target in the torso, but the server decided that the target actually shot you before any of your shots connected(which can be seen when watching the killcam replay) It seriously destroys gameplay legitimacy. Sure, the player expects something to happen the second they click the mouse, but if it costs stable gameplay, I don't think it's worth it.

#15 @Jeff,
I think you are right on this. I had not thought about that in terms of perception of what happened. It might lead to thinking the game was rigged or something. Players are not necessarily going to understand what is happening when that occurs. David Wyand is right. You can't win on this. You just have to make it good enough for now.

I am not sure how this helps with the rapid fire though. Are we seeing this issue on single player? Is it really network related on single player? Or is this a console speed issue?

#16 I am a big CoD fan and used to play Xbox Live for the Multiplayer experience. To be honest, I don't have the reflexes that a younger player will have so I lose a lot. But there were occasions when I clearly hit the other player before I was killed on my client side but the kill-cam shows the other player had already shot me first. This is the latency that makes people perceive the game player to be cheating. Generally players accept what the Kill-cam shows to be factual... it acts as a final judge.
Some players will actually cheat and make a lag switch to help them blink into existence for the shot before the victims client is updated. Kill-Cam will show the cheater got the shot first.
I believe CoD depends on client side weapon effects because of the rapid fire for some weapons are similar to a bullet hose, especially true for the (Sub Machine Guns) SMG's. The seemingly endless spray of bullets can offset the cheaters advantage at the cost of going out of ammo or reloading time.

If T3D is going to be used for games that simulate a CoD experience then I'd say that the Client will need to handle the weapons effects the same way with the addition of a kill-cam for judging. It's been my experience in TGE that the built in Video Capture was borked so add it to the list of things to do for Client side.

The server is handling the collision between Server and Client so the round-trip of packet updates is the cause for the "random interval in which rounds are fired". This becomes more noticeable if the engine is unchanged and used as a multi-player game. Weapon fire rate will need to be tweaked to reduce the noticeable lag. This can limit the types of weapons a Dev might choose for their game if the Dev is reaching for realism. As it stands right now the lurker weapons fire rate is already too fast to show smooth game play.

Coin Toss. Heads means we change the engine code. Tails means we change the Client code. If by chance the coin lands on it's edge, we can blame it on cheaters and lag switches.

#17 One thing I would suggest, is first tossing in an echo or printf that tracks the time since the last shot was fired. Depending on how much the differences are can either be totally unnoticable, or an obvious indication something is wrong.

I'm running a weapon system that's entirely derived in script(state machine is handled in script), and firing the weapon at 700rpm, which is faster than the lurker, and I see variances of about 10-20ms a shot, though this is on my crappy laptop, I'd need to test again on my actual desktop which would be a better metric.

If you're seeing a larger variance than that(again, I'll test on my good computer and update this when I get off work) then it could be an indication of how Images handle the state machine.

Edit: Tested it on my desktop, and it's still the same 10-20ms variance, so it seems pretty stable in all regards. I'll test on my machine what the lurker pulls in regards to it's firing delay consistency and report back.

Edit2: Testing the lurker using the Images system I was seeing variances of ~50ms, which is a definite difference comparatively. So it looks like something with the Images system tends to have a longer delay than when I implement a weapon state machine in script directly. Possibly the network back-and-forth, as opposed to the 100% server authority that the script implementation has(nothing is managed on the client, save the fact that the mouse calls the server-side onTrigger() callback)
So that may be a starting point as we look into it.

#18 In our mech game we have the opposite problem. You are firing so many rounds at the same time that you dont even see your bullets half the time so it doesn't even look like your firing. So I will eventually have to implement client side weapons, it is just not high on my list right now. We dont have to worry as much about the false hits in a mech game either since you cant one shot kill someone.

#19 @Scott,

Quote:
especially true for the (Small Machine Guns) SMG's

sorry to nit pic but its Sub Machine Gun.. :-)

#20 Your correct. Fixed.