Talk:Soundcache

Does anyone know what these do? All I've worked out is that they have the first second or so of some sound files in them. --TomEdwards 14:22, 6 Aug 2005 (PDT)

---

Just ran the Big Command Line O' Doom on Metastasis 2 - cue glorious, glitch-free audio! A quick note regarding some of the graphics settings in the command line - it makes the maps load faster, and in a window too, but you'll have to reset the graphics back again once done... —Cargo Cult _{(info, talk)} 15:48, 26 Feb 2006 (PST)

• Look to the imminent Metastasis 2 for a sample of soundcache stuff, complete with edited manifest files - all thanks to a certain Tom Edwards! (Thanks!) —Cargo Cult _{(info, talk)} 14:57, 2 Mar 2006 (PST)

This is weird: the caches are built at the proper size (i.e. empty because everything is in _shared), but as soon as you run the cache's associated map it fills up with all the sounds I removed from the manifests! The VOs and the weapon sounds for weapons that don't appear turn up in each and every map cache. What a bloody waste! There doesn't seem to be any way to stop it, either. --TomEdwards 13:37, 3 Mar 2006 (PST)

A new Soundcache system

I've been working steadily with the soundcache system for some time now, and after looking at the whole thing I can only say that the current method through which caches are created and managed simply isn't understandable enough for the general development community. Here's an outline of what you’ve got to do to make a proper, efficient set of caches (read above for some background):

1. Remove all choreography sounds from scripts/game_sounds_manifest.txt, otherwise they will be included in every manifest and balloon your caches.
   • If you aren't using Mossman, Eli or other NPCs this can be achieved by deleting their npc_* entries, which will only leave a couple of megs of useless files in the caches from chapter-specific entries.
   • If you ARE using one of the NPCs, you're in a world of hurt trying to labour through figuring out what to remove and what not to.
2. Load each map in turn and run snd_writemanifest. The official instructions say to generate reslists too, but I don't think that's strictly necessary?
3. Quit from the game and delete any existing caches.
4. Restart the game and test what you've got.

If we discount step one, which is a very tricky problem to solve from Valve's end and something that only a handful of people know to do anyway, we've still got a system that people simply don't use. MINERVA is just about the only mod I've seen that ships with manifests, and the chances of custom maps having them is near nil.

Why is this a bad thing? Because without pre-built manifests the engine has no choice but to blindly create its own caches, which are typically in the region of twenty MBs for each map in a HL2-based mod. This increases initial load times to ridiculous levels and makes subsequent loads take longer as well [1], not to mention chewing up hundreds of megs of memory and disk space for a modest-sized mod.

Not having a soundcache for a map isn't as bad as not having ones for a mod, but can still screw things up, including increasing stutter (as each sound is added to the cache as it plays rather than during the first load: this is something a predefined manifest avoids) and choking the hard drive again. If your map is for a game that already has a _sharedprecache it isn't too bad, but for a mod without one...you're back to the 20MB cache.

To put that in perspective, a mod with properly build manifests often has nearly empty map caches, and a far smaller _sharedprecache (Minerva's set is 7MB shared and empty map discounting the choreography difficulties).

A solution

Enough whingeing. Here's my opinion on a fix:

1. Make snd_writemanifest automatic every time the map changes
2. Embed manifests in their parent BSP
3. Allow the _sharedprecache cache to change as map manifests change
4. Add a cache patching system

Numbers 1 and 2 are simple and effective improvements. By making caches behave like a cross between cubemaps and nodegraphs we ensure that they a) exist, b) stay up to date and c) make it to the player 100% of the time. Three things that hardly ever happen today.

Number 3 performs the same task for _sharedprecache as Number 1 does for the map manifests. Every time a map manifest changes and every time the game loads up, each map manifest is scanned and the shared manifest adjusted accordingly (or created if it wasn't there). Like #1, this ensures that _shared exists, is up to date, and is 'distributed' every time.

Number 4 might already exist, I don't know. Its purpose is simple: ensure that changes to the manifests can be applied to the caches without having to rebuild the whole darn things every time.

What isn't fixed

• Sounds used in VCDs still exist outside of the cache system.
• Manifests (and reslists!) are still created file-by-file instead of a more manageable object-oriented system.

Both of these are very big problems of course, and completely out of the remit of this little article.

--TomEdwards 00:39, 29 Mar 2006 (PST)

Discussion

Source should "fallback" to its SteamAppId's caches if none are available for a mod and no explicit command is specified.—ts2do 21:05, 8 Apr 2006 (PDT)

August 06 SDK Update

I'm having a lot of issues since then. Among the others, it looks like changing the command line doesn't affect the game at all. For example I'm not even able to run the game without the initial video, -novid or not. So, creating .manifest files with this method for me, well, just doesn't work. Anyone with the same problem? uoz 00:03, 20 Oct 2006 (PDT)

try -novideo—ts2do 15:06, 20 Oct 2006 (PDT)

I tried, but it didn't work either. Neither did -console or +map_background or anything else. I forgot to mention that I'm using SteamAppID 215 with custom dlls. —uoz 01:33, 21 Oct 2006 (PDT)

I had the same problem. Seems as if only the command line from the SDK Base is used, not the one from the mod. Enter it there... updated the article.--Vaarscha 10:54, 29 Dec 2006 (PST)

---

Reslists

Pre-publication_evaluation advises that the reslist directory should be deleted prior to distribution, but is this correct? Loading a mod for the first time without reslists (with .manifest files only and no caches) will produce the following warning: "CacheSoundsFromResFile: Unable to find 'reslists/engine.lst'" plus a warning for every map in the maplist. Other than avoiding this error by including them, or saving a bit of space by not including them, is there any benefit in distributing or not distributing the premade reslists with mods? It is perhaps significant that Valve always distribute reslists for all maps in the content GCFs for all games.--Fitzroy doll 11:51, 17 July 2009 (UTC)