gemidyne/microtf2

Non-precached sounds causing game crashes

KayaDLX opened this issue · 8 comments

Describe the bug
Whenever we're playing MicroTF2 on our network (Creators.TF), a lot of players are constantly crashing.
Basically in console it's spewning SV_StartSound: not precached (0) and also spamming most players' console with the following:
image
At a certain point, this will just cause people's game to crash, considered how much errors are getting spammed a second.

Do you know what version of the gamemode this bug occurred on?

  • Version 5.1.0

Additional info
This is only happening to certain players, for whatever reason.

I hope this report is detailed enough, I do not know the exact details of why this is happening, but I can help providing more information if needed.

Thanks for the bug report.

We have had reports of this in the past, and believe it is related to the sound cache becoming corrupt, usually on client-side. We are not sure why this happens though, as it the error which causes the cache to become corrupt seems to originate deep within the Source Engine.

We have not been able to 100% confirm if this can also be caused by server-side sound.cache files due to the intermittent nature and the inability to reliably recreate the decoder errors. This might be something to try in the first instance.

A confirmed fix for this is deleting sound.cache files on client side, but understandably this is not always helpful as it involves players going into their tf folder.

Can you confirm roughly how many players are experiencing this? If this is a large number (a full server for example), we can push a test hotfix which will include a new version of the v5 map, and will use new sound paths so Source does not load the old sound files from cache. I would not be able to confirm this fixes the issue though, but if this does fix the problem, it will influence how we release future map updates.

You're welcome. 👍

Thanks for the explanations, that's really good to know!
I would say out of 32 players, 6 were experiencing it, but I don't exactly know why these 6 specific people tho.

Changing sound files paths might be a good idea to do a workaround fix for this issue.
Apart from it making everyone download a new version of the map, I think it's a good way, as it also does not make you entirely redownload external sound files that are not packed inside the map, thus make duplicate files in everyone's download folder.
(also bless your gamemode for having literally everything packed inside the bsp, this is so much more convenient!)

Thanks for the info. In order to update the paths and future proof the "versioned embedded assets" approach I need to do a little bit of work for making this possible. This might take a few days so I can test before I release the update.

For anyone looking at this issue in the future, current solution to fixing this will be:
Custom sound paths will need to have a special token in them - so instead of for example:
gemidyne/warioware/bosses/sfx/beatblock_count.mp3
to ensure the sound is "versioned", they will need to specified within the data and plugin as:
gemidyne/warioware/{version}/bosses/sfx/beatblock_count.mp3

{version} will be linked to a #define set within the main plugin file. It will essentially tie the plugin and map together. I expect this to only change whenever a new map version is released. But it does mean that in /assets/datapacks/warioware_sounds/sound/gemidyne/warioware/ files will need to match before compiling the bsp.

However, if anyone viewing this issue has a better idea to fixing this, I'm all ears - the versioned paths really is just a workaround so the engine will not look at the sound.cache's existing corrupt entry.

Got an initial version of this up in a branch. Tried testing but Source doesn't seem happy, not sure if my caches have broke trying to create a workaround. Old sound paths still work though.
5f1b67f

Another update: I think I've got a working update. I have tested and all sounds are continuing to work. I need to do some final checks as well as document this new approach then can release. Looking for v5.2 (map ver: warioware_redux_v5b) to release on Friday/Saturday.

Good to hear! Thanks for all that :)

Just to follow up, v5.2.0 is now released - https://github.com/gemidyne/microtf2/releases/tag/v5.2.0

A map update is required, but hopefully this resolves the issues that those players were having. If there's any other issues, please let me know :)