And here you go :
https://www.mediafire.com/file/pmru16mp ... x.pk3/fileSo, to avoid having to look for the exact changes (for it to work as an add-on I had to replace your lumps, which mean, I copied the problematic files and changed only the desyncing parts) :
SFXBase.zsc : Added two functions to this class, CheckPlayerSightsOrRanges and CheckPlayerSightsAndRanges (kinda redundant, but when adding FXs you're likely to keep doing that kind of check, so I figured, best to do it that way). Also changed the CheckPlayerSights residing in EVP_BaseFlare so that it uses the new function.
Props.zsc : All occurences of CheckPlayerSights that used to have a CheckDistance alongside them with the new functions. AFAIK, these are in EVPBarrel:Idle an EVP_TorchBase:Spawn
Bullets.zsc : This one has a slightly different change. I tried to maintain your intended behaviour of whizzing when going by the player's head, while trying to enforce it to happen only for the player whose head is close to the bullet. To that effect I removed the distance check entirely from ZTracer:Spawn and instead put a bit of ZScript in the Whiz state, making it so the bullet is in this state for everyone, but the sound plays only for the players near the bullet.
I had only one occurrence of desyncing after that, which I unfortunately couldn't reproduce BUT it seemed to happen when I gave myself ammo. I know GZDoom has netcode meant to ensure cheats do happen on all clients when they're typed, but there could have been an issue there. I'll still give a look at the ammo replacers from EVP, but I doubt they're at fault sincerely.
For a little more in-depth explanation of the actual desyncing bug : In most cases, it came from affecting the game's state for a single player. For example, you used to check an actor distance against consolePlayer's camera, meaning the check will very likely validate only for one actor, meaning the resulting spawned actor or state change (in the case of ZTracer) will only spawn or happen on the client of the player who experiences the sight or range closeness causing the desync. CheckRange and CheckSightOrRange, meanwhile, check against all players, hence the helper functions I created in EVP_PlayerSightCheck. This was surprising as you did go through the trouble of actually checking all players for the CheckPlayerSights function.
For ZTracer specifically, it would seem, from a post by Graf from 2018, that ResolveState is meant for a few edge cases, main of which is intending for the function to keep going after setting the state. In your case you want to instantly go to the new state as no instruction is left for the Spawn state once you go in Whiz. Graf recommends using SetStateLabel (equals to "SetState(FindState("label"))" ) in that case. I did that and it seems to work as expected, I tested and the whiz works the same as vanilla. I also only checked for Range as checking for sight for a potentially off-screen projectile sound seemed unintuitive BUT this was only a personal change, you may have intended for things to be that way, you are the maker of this mod, and you're the one authoring the code, so I'll leave that up to you
The only "problem" left for full MP compatibility would be to make said Whiz be able to happen for each player as opposed to just the first player(s) near the bullet when it first passes by a player. This is out of the scope of my initial fix BUT I know how to do this, and it doesn't involve a change of your codebase's architecture so I can do that too if you wish
If you prefer to do it yourself it will only be a matter of making the Whiz state loop on itself and add a proximity check for every player (a bit like you do in CheckPlayerSights) after the conditional that plays the sound for the consolePlayer, then saving that in a simple array contained inside the tracer, and altering the condition for "Ä_StartSound" by adding to the proximity of the consolePlayer, whether or not the tracer has already been near that player.
In all cases, as long as you keep checking for ranges with these new helper functions, no further desyncs should happen, and the mod would stay MP compatible without further effort from your part in maintaining said compatibility
Edit and tl;dr : This download is not meant for public download (can't really do it any other way for now) it is meant only for the dev's eyes for him to implement these changes.
Edit 2 : Replaced link with a permanent link (did an oopsie and uploaded my files on a temporary unregistered Mediafire account...)
by DevilBlackDeath » Thu Jan 28, 2021 2:57 am 
). There's not a lot to fix afaik so when I'm done fixing it I'll post an "add-on" pk3 here so you can implement the changes if you wish to 
