search

gemidyne / microtf2

A custom gamemode for Team Fortress 2 - Players compete against each other to get the most points by playing a series of rapid fire microgames in order to win the round!
https://www.gemidyne.com/projects/microtf2
GNU General Public License v2.0
30 stars 16 forks source link

Non-precached sounds causing game crashes #227

Closed KayaDLX closed 2 years ago

KayaDLX commented 2 years ago

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?

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

KayaDLX commented 2 years ago

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.

safalin1 commented 2 years ago

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.

KayaDLX commented 2 years ago

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!)

safalin1 commented 2 years ago

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.

safalin1 commented 2 years ago

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. https://github.com/gemidyne/microtf2/commit/5f1b67f1648849df74ba09b6a6726cc6c24ce9b2

safalin1 commented 2 years ago

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.

KayaDLX commented 2 years ago

Good to hear! Thanks for all that :)

safalin1 commented 2 years ago

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 :)