Random Packet Loss
If your packet happens to have 2 bytes that were specific numbers (don't remember) it will force disconnect you.
And it will happen on any random packet with a 1/256*1/256 chance.
This means all long sessions will eventually desync.
Steam Desync
After a while, all packets just stop being sent.
It doesn’t even run trigger the disconnect events, to at least detect this!
Steam Snapshot Jitter
This is confirmed by running the exact same code in LAN (clumsy), versus Steam (live testing)
LAN 50 ping (clumsy), there is no jitter in position interpolation.
Steam 50 ping, there is jitter, no matter what. There is definitely a clash of ReliablePackets with SteamP2P packets, on packet composer (see difference when commenting out forge reliable packet code, or steamp2p packet composer)
Setting all RPCs to unreliable, doesn't solve the jitter (but it does drop the ping by like 60% LOL), but disabling reliable packets of Forge or SteamP2P (so only one works instead of both) helps even more. It is logical to conclude the bug is related to a bug in the Forge-Steamworks integration.
=============
For the above reasons, I suggest archiving the Forge Remastered repository (split Alloy), or having a huge warning/notification at the top of README.MD that the project is abandoned and unstable. At the very least, pin this issue. Because whoever invests heavily in Forge Remastered, enough to use it on his project, ends up regretting it, especially when Mirror exists (haven't used it, but I am certain it has reliable packets)
@BrentFarris @phalasz @NFMynster @Crazy8ball @tommohawkaction
The following bugs can be confirmed by me (developer of Double Damnation), and Flamboozle (developer of Sun Haven)
Reliable RPCs flood the network (exponential bandwidth) Reliable RPCs flood the network with acks which duplicate themselves. This means packets arriving later and later as you play. Every packet has a timestamp. You will notice that receiving a packet, the timestamp difference of sent and received, is constantly growing, instead of being constant (assuming constant ping) tl;dr: You will eventually get packets with 1 second delay, even if they are not reliable, because reliable RPCs flood the network.
Random Packet Loss If your packet happens to have 2 bytes that were specific numbers (don't remember) it will force disconnect you. And it will happen on any random packet with a 1/256*1/256 chance. This means all long sessions will eventually desync.
Steam Desync After a while, all packets just stop being sent. It doesn’t even run trigger the disconnect events, to at least detect this!
Steam Snapshot Jitter This is confirmed by running the exact same code in LAN (clumsy), versus Steam (live testing) LAN 50 ping (clumsy), there is no jitter in position interpolation. Steam 50 ping, there is jitter, no matter what. There is definitely a clash of ReliablePackets with SteamP2P packets, on packet composer (see difference when commenting out forge reliable packet code, or steamp2p packet composer) Setting all RPCs to unreliable, doesn't solve the jitter (but it does drop the ping by like 60% LOL), but disabling reliable packets of Forge or SteamP2P (so only one works instead of both) helps even more. It is logical to conclude the bug is related to a bug in the Forge-Steamworks integration.
=============
For the above reasons, I suggest archiving the Forge Remastered repository (split Alloy), or having a huge warning/notification at the top of README.MD that the project is abandoned and unstable. At the very least, pin this issue. Because whoever invests heavily in Forge Remastered, enough to use it on his project, ends up regretting it, especially when Mirror exists (haven't used it, but I am certain it has reliable packets) @BrentFarris @phalasz @NFMynster @Crazy8ball @tommohawkaction