by edward850 » Sat Jan 16, 2016 2:11 pm
LanHikariDS wrote:Through some experimentation, I've learned that ZDoom typically uses a minimalistic approach to multiplayer packets,
Or you could have checked the
Doom wiki or just asked. That was a waste of time, wasn't it?
LanHikariDS wrote:essentially just streaming live Demo files for the other player's movement, which is susceptible to desyncs in certain environments.
Not exactly. They are only susceptible in an environment that isn't designed for the data, just like demos (also calling it streamed demos is somewhat off point but whatever). As long as you design the environment to be deterministic, which Doom is, then everything is good to go. So incidentally this means
you can play the most seemingly random mod for hours on end with absolutely no issues, as the data is already informationally correct.
LanHikariDS wrote:For vanilla Doom, and possibly ZDoom in it's early days, I could understand this being used, as it's great for low-speed internet connections that were common around that time, and worked for the primitive engine.
For ZDoom nowadays it's still needed, as object state changes can range at an easy 100 bytes-per-object. Incidentally, the cost of customization means you need to store and transfer the data somehow, and ZDoom outgrew any possibility of that changing.
LanHikariDS wrote:Is there any way to have ZDoom sync up players' X/Y coordinates every few tics, instead of streaming their button inputs, to iron out some of these desyncs? If not, are there any other source ports that use this method? I have a neat Cooperative map idea that desyncs commonly with the 'Demo Streaming' method.
Then you're simply not making a Doom compliant map. No, you can't resync the player positions because the data is most certainly not only reliant on that, however your bigger issue is that's not simply how Doom is designed to start with. Breaking things deliberately just leaves you with a broken thing. Design smarter, not faster.
[quote="LanHikariDS"]Through some experimentation, I've learned that ZDoom typically uses a minimalistic approach to multiplayer packets,[/quote]
Or you could have checked the [url=http://doomwiki.org/wiki/Doom_networking_component]Doom wiki[/url] or just asked. That was a waste of time, wasn't it?
[quote="LanHikariDS"]essentially just streaming live Demo files for the other player's movement, which is susceptible to desyncs in certain environments.[/quote]
Not exactly. They are only susceptible in an environment that isn't designed for the data, just like demos (also calling it streamed demos is somewhat off point but whatever). As long as you design the environment to be deterministic, which Doom is, then everything is good to go. So incidentally this means [url=https://www.youtube.com/watch?v=VtttIB_fnU0&list=PLXq0buJ3S6vNYO37UoQKX6cu4pVo9dyFn&index=2]you can play the most [i]seemingly[/i] random mod for hours on end with absolutely no issues[/url], as the data is already informationally correct.
[quote="LanHikariDS"]For vanilla Doom, and possibly ZDoom in it's early days, I could understand this being used, as it's great for low-speed internet connections that were common around that time, and worked for the primitive engine.[/quote]
For ZDoom nowadays it's still needed, as object state changes can range at an easy 100 bytes-per-object. Incidentally, the cost of customization means you need to store and transfer the data somehow, and ZDoom outgrew any possibility of that changing.
[quote="LanHikariDS"]Is there any way to have ZDoom sync up players' X/Y coordinates every few tics, instead of streaming their button inputs, to iron out some of these desyncs? If not, are there any other source ports that use this method? I have a neat Cooperative map idea that desyncs commonly with the 'Demo Streaming' method.[/quote]
Then you're simply not making a Doom compliant map. No, you can't resync the player positions because the data is most certainly not only reliant on that, however your bigger issue is that's not simply how Doom is designed to start with. Breaking things deliberately just leaves you with a broken thing. Design smarter, not faster.