Rapid fire weapons uneven fire rate

#21

Quote: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)

That's exactly the way the Image system works IIRC, so I'm interested to find out what the difference between that and your scripted system is.

Also, it seems like we're discussing two issues here: the client-side weapon effects, and the client-side prediction of weapon fire. I think it's quite reasonable for the client to be allowed to predict that their weapon will fire, and play the appropriate effects; however, I agree it's probably unreasonable for the client to predict the resulting projectile and its damage effects.

In a high-lag situation, this may result in the player seeing themselves fire and then seeing none of their shots hit (when the server has created projectiles and their effects are ghosted back to the firer), instead of the player clicking the mouse, then seeing a delayed firing response that also causes no hits. It would not cause players to see their shots damage an enemy, but have that damage cause no effect to the server simulation.

#22 In regards to the high-lag situation, I decided to give that a test.
I used the setSimulatedNetParams to simulate a stable(because packet loss would screw you no matter what), but slow(500ms) connection.
When I tested my script-based implementation, I did have a very tangible delayed response to firing the weapon and whatnot, so that's something I'll need to work out.
More interestingly though, is I tested the same on the Lurker, which goes off the Image system, and that was subject to pretty much the exact same lag. So I'm not actually sure what benefit we're even getting with everything being networked back to the client. Something that needs to be looked into more, I think.

#23 I forgot the engine can simulate lag; that's awesome, something I'll definitely be doing come the time.

Currently, your script system and the Image system work similarly, as far as I can tell. The client clicks their button, the signal takes 500ms to get to the server, the server switches the image to the fire state, creates projectiles and effects, then all this data gets back to the client in another 500ms, at which point the weapon appears to fire.

I propose that client-side weapons should act on inputs as well. So, the client clicks their mouse button, which sends the signal to the server as well as starting up the fire state on the client. The weapon appears to fire. 500ms later, on the server, the actual weapon starts to fire and projectiles are created. This data is sent back, taking another 500ms, and the results of the shots appear on the client.

There's very little practical difference here: either way, the client will only see the effect of their shots a second after pressing the trigger. But I personally believe that the latter situation would be more satisfying to me. Instead of my gun not seeming to work, I can immediately see that my gun works, even if the server then takes some time to catch up with that.

#24 @Dan
Oh, I concur that the weapon should at least give the immediate perception of response. I just don't agree with bullet impacts, or hit indications being client predicted, as that's directly harmful to gameplay. The gun playing the fire animation, doing a muzzle flash, making the sound, etc on the client at time of clicking is perfectly acceptable, because at worst it feels like the bullet just moves slowly.
However, like you said, it seems like the Image system doesn't do any of that currently, so it's something that needs to be looked into how would be the best way to do that. At the moment, I think some sort of object attached to the client, and when they do the server command to fire, it also does a replicated function of the weapon scripts on the client, or something like that. I'll have to look into it. I don't imagine 500ms ping times to be incredibly common, but it's definitely something that needs to be accomodated for.

#25 Well, the weapon scripts only deal with creating projectiles and so on - all the effects data is in the datablock and is already networked. All that needs to be done is for the client-side simulation to respond to inputs, rather than waiting for a network event to change states. There's probably an if(isServerObject()) somewhere that needs to be killed...