A trick to improve the minigun's hit registration problems

[10th_account]

About a year ago I posted a suggestion to improve the minigun's hit registration problems. [link]

It was shot down by MM since it required a change in the netcode. Well I thought about it recently and noticed that there's a solution that's so stupidly simple.

First a quote from my earlier topic explaining the situation:
"Currently, according to MM, a packet indicating that you are firing your minigun is sent to the server and distributed to all other clients. You, the server and all other clients will spit out bullets with different pseudorandom sway until a packet indicating that you have stopped firing is received. This method is used to prevent the minigun from flooding everyone with hundreds of "bullet" packets due to its high rate of fire. The drawback is that the bullet spread you see isn't necessarily the same as that the server sees when checking if bullets have hit other players."

So to solve this, the server and every client should know of a constant integer that will works as an initial seed for generating pseudorandom numbers for the sway. It just needs to be the same on every machine, every time. So say that number is 42. Now, every time a player starts firing his minigun, the server and every client will generate the next pseudorandom number for that player's next bullet's sway from the seed 42.

It's important to have every player associated with their own pseudorandom number so multiple people can fire the minigun at the same time.

The downside to this solution is that every time you fire the minigun, the bullets will always have the same spread. So the first bullet will deviate +1.2 degrees, the second one -0.9 degrees, third one -0.5 degrees, etc. But if you try looking at it now, it's blatantly impossible to distinguish any sort of pattern since its rate of fire is so tremendously high. It would be impossible to notice that the same pattern is always used. And a better initial seed constant could always be chosen that gives a better spread. Say... 43.

[-Major-]

to be honest I don't think minigun needs to do dmg...
about MMs quote..., what I've heard the victim client decides if a bullet hits, not the server. otherwise we probably wouldn't have those bounce nade eats.. I think... I guess the server decides bullet/nade push? this is basically what I've been trying to get enesce to tell and apply my debug idea... however... ended with him going to his own isolated corner.

[10th_account]

You're wrong. The server dictates damage. Each client decides their own bullet and nade push.

[-Major-]

then I wonder how on earth you can bounce on nades...

[10th_account]

Because a player decided that he was hit by a nade and applies the boost to himself. The server didn't see that collision and didn't apply any damage to the player.

PM me if you don't understand. We're going off topic here.

[zyxstand]

Damage is dealt by server.
seeing a grenade explode along with change in momentum is processed by the client. so you can explode a grenade and fly off without the server (or other clients ftm) necessarily recognizing the explosion you witnessed.

anyway. this wouldn't work 10_account.
HERE IS WHY THIS WOULD NOT WORK:
your idea limits the need for the client shooter to spew out tons of bullet-fire information to server, and for other clients to receive tons of bullet-fire info, but you still need to know which direction the shooter is aiming at!  Your idea assumes that a few consecutive bullets need ONLY information about initial direction and the seed - this doesn't allow for the shooter to change directions very much.
If you notice, the direction in which someone is looking gets updated only maybe around 4 times a second - so that wouldn't be enough for the minigun.
And containing a "looking" direction for every bullet fired WOULD allow for accurate bullets (given the seed), but that's just as much information as giving giving information about each bullet in the first place.

ANOTHER SOLUTION:
What would seem to work perhaps is restricting the resolution of the direction you're aiming at for each bullet (at the client-level and server-level), plus the randomization-seed.  That way you reduce the data size needed for each bullet while still keeping it seemingly continuous.  I'm sure in order for you to snipe someone who's 3 screens away from you with a sniper you need to be able to have dead-aim precision (perhaps up to 4-bytes of directional-data) while with the minigun, having only 1-byte of direcitonal-data plus the initial randomization seed would suffice.  (Also, due to the way packets are sent, this doesn't mean it would be 4 times better)

[10th_account]

I think either you or I have misunderstood how the minigun currently operates over the network. My suggestion was intended to improve the minigun's hit registration without requiring changes in the netcode. As I've understood it from MM, the client who fires his minigun only sends data for when he starts and stops firing. This was used to prevent network flooding due to the minigun's ludicrous fire rate. Knowing that I assume that the server already used the snapshot packets that arrive a few times per second to figure out in which direction the player is firing his minigun. So if my assumptions are correct, you would basically have said that the minigun as it is now wouldn't work. :P Though now that it's been brought up, temporarily increasing the rate at which snapshots are sent while firing the minigun would also make the minigun more reliable. But all my idea would change is how random numbers are generated locally, to provide consistency across all machines.

And although your idea does sound reasonable, it would require a change in netcode and could introduce network flooding. Even if the payload was low, there's still quite a bit of meta data in the UDP packets used.

[Neosano]

Minigun is fucking slow.
It wouldn't hurt ANYTHING.