LAN testing results: client inconsistencies

[Wyeman94]

Hello!
I had an opportunity to test Ironwail 0.8.0 in a LAN with multiple identical machines using Windows11, 64bit i5-13400, RTX 3050 GPU, 1 Gbps LAN.

FPS and map-rendering performance is excellent, nice work! However, we noticed some oddities in the LAN experience which are very likely to be missed when testing solo. These LAN issues were especially present in larger maps like "ad_tears" but were also present in other mods so I decided to report. These issues do not present themselves playing solo because these problems are discovered in the client's experience.

1) In-game effects:
The host has the best experience because it seems like all effects get played/processed by the host instead of the client.

Example#1: client gunning sounds are sometimes absent in the client, yet still heard by the host. Not so prevalent in original Quake, but in larger maps like ad_tears, perhaps this is due to network overflow and packets get dropped?

Example#2: similarly, gfx are sometimes absent in the client, but showed in the host. Sometimes a client doesn't see any gfx of shooting but still "kills" an enemy. So the client's experience is lacking.

Example#3: when a client player dies, the death sound is not heard by the client but is heard at full volume by the host, even though the client player was very far away from the host player.

These were also prevalent in Quakespasm. Does the engine tell the host to play an effect (sfx and gfx) and then stream it to the clients? If so, perhaps the clients could just be told to process the effect locally at a location?

2) Player colors:
The host has the best experience because it appears that while the host's player colors are correctly applied, EVERY CLIENT's player-colors are not -- each client simply gets assigned the default Quake-guy color (consistent to dead player bodies and everyone's view).

Could player colors get applied/recognized beyond the host player? This issue was not present in Quakespasm but discovered in Ironwail.

I haven't looked into any code but wanted to report the findings of this unique experiment (which I could replicate). Thanks.

[mhQuake]

For entity effects, I came across this in another context recently. After digging through the code, it turns out that entity effects are not baselined. What this means is that for any entity with any effects bits set, the entity must always be sent, even if nothing else is different from it's baseline.

Now, this is somewhat ameliorated by the fact that most effects are transient, but still - there's a whole bunch of needless code comparing effects to baselines, and copying current effects from a baseline, when it turns out that the baseline on both client and server is always 0. Also the network traffic that comes from this: effects aren't in the lower 8 bits so they cause the entity update to be larger again: an extra 8 bits for the U_EFFECTS flag and an extra 8 for the actual effects themselves. Each entity with, for example, EF_MUZZLEFLASH will get this behaviour, as will powerup lights.

This behaviour goes right back to the original ID Software code (https://github.com/id-Software/Quake/blob/master/WinQuake/sv_main.c#L925) but unfortunately it's a protocol change so a fix can't be just dropped in.

[Wyeman94]

thanks for the reply mhQuake. It seems to highlight a major bottleneck for communal gaming of modern Quake content: despite how the modern engines can render so well, the core engine struggles with networking entity effects. It's enough to negatively impact the user's experience when there are many entities. Yet when playing solo, there is no issue.

What would a core protocol change conceivably break? Would existing mods have to be regenerated?

[mhQuake]

It's a breaking-change to the protocol, meaning that if it were implemented, modified clients wouldn't be able to connect to unmodified servers, and vice-versa. Mods would be unaffected, the connection between the client and server executables would. Essentially the server would send data that the client wouldn't expect, resulting in an illegible data stream, or the client would be expecting data that the server wouldn't send, likewise resulting in an illegible data stream.

Personally I tend to view engines like Ironwail as primarily singleplayer-focussed, and I don't think it's unreasonable to say "if you want multiplayer, use QuakeWorld or a multiplayer-focussed engine". I know that's not a great answer if the flavour of multiplayer you want is co-op.

[Wyeman94]

I believe such work is appropriate with Ironwail's focus/mission of "high performance instead of maximum compatibility" ... performance including more than FPS. It's a good opportunity for a community-wide update to increase network efficiency of entity effects as you describe.