Certain sounds are registered incorrectly on client in multiplayer about xash3d-fwgs HOT 5 CLOSED

It's probably incorrect behavior.

Looks like engine tries to register sound after reslist, because "thinks" that your sound file as resource, is missing(RES_WASMISSING flag is set). Check CL_EstimateNeededResources call, in CL_ReadPackets.

from xash3d-fwgs.

OK, I've narrowed it down: it appears I was forgetting to precache a sound (gun pickup), so when the player spawned and picked up their first gun, this sound was sent in a sound message to the client so that it would be loaded. This caused cl.resourcesneeded to be non-empty, so sounds were registered again to pick up this non-precached sound. However, running sound registration again meant that all sounds from the previous registration were wiped from the list.

Obviously a simple fix would be to make sure the offending sound is precached. However, I'm still confused as to why forgetting to precache a sound would cause the rest of the correctly precached sounds to be discarded from the known SFX list. What would the best fix for that be?

from xash3d-fwgs.

@x6herbius

Precaching is very important thing in Quake. It helps engine build list of important files, which should be sent to client and preloaded(to avoid stutterring). So don't forget to precache your files.

However, Xash3D supports hot precaching. It's possible that hot precaching is broken with customization, which allows any client send it's files to server and server will share it to other players. It's hardly allowed only for custom decals though.

from xash3d-fwgs.

I guess my question is, should hot precaching be triggering a content registration if this wipes the list of previously registered content? Without knowing all that much about the intent behind the system, it seems to me like items that need hot precaching should be added to the end of the existing list, rather than causing a re-registration.

from xash3d-fwgs.

Was fixed way back in 2022 in 7013d44

from xash3d-fwgs.