wenn ihrs verstanden habt bitte helft mihr weiter
http://forums.multiplay.co.uk/showthread.php?t=65271
die kern ausage ist diese This is a common bug happening, and it's a client related issue - especially if other people are already on the server. Don't worry there is nothing wrong with your client, it's a code issue.
The only fix (thanks to maddin for finding this) is to start a listen server, close it, then join the Internet server you originally intended to join. This doesn't always work.
Please also ensure cl_allowupload and cl_allowdownload are both set to 1.
A listen server is made by using the create game option on the title screen.
There is another server side issue:
When a map starts, the server generates sound/auto_soundlist.txt for that map containing all sounds the map uses.
If you run multiple instances of HLDS on a single installation (like we do), sound/auto_soundlist.txt will be overwritten each time an instance changes map, invalidating it for all the other instances. This results in the wrong sound/auto_soundlist.txt being sent to clients preventing them from joining because they consistently receive the wrong one (which they will never get because it doesn't exist).
Due to this, we are now running just 1 server.
I've recommended 3 solutions on the official bug tracker:
1: Re-generate the sound/auto_soundlist.txt each time a player joins
May be time consuming at run time, but each time a player joins check that the auto_soundlist.txt is valid server-side, and if it's not, regenerate it before they download it.
2: Each map has it's own auto_soundlist file
Each time a map is run, generate it's sound file and place the map in the filename. There will also be no need to place the IP/port of the server in this file.
Suggested filenames:
\svencoop\maps\<map>_sounds.txt
\svencoop\maps\soundlists\<map>.txt
\svencoop\sound\soundlists\<map>.txt
...whatever, first one is probably best.
I see no obstacle on this, because:
1: The client would know what map is running and could fetch the correct file.
2: The server generates a sound list on map change, so new versions of a map wouldn't effect this.
3: If 3 instances run the same map, the sound list would be the same thus no conflict.
4: If 3 instances run different maps, the sound list for that map would be used. Not one shared file.
5: We already have loads of RES files, so it isn't exactly a strain on file space.
3: Provide a CVAR for defining an alternative location for the sound list file, but fake to clients their downloading sound/auto_soundlist.txt
Instead of hard coding auto_soundlist.txt, use a CVAR (eg soundlistfile sound/my_auto_soundlist.txt) to determine where the server will keep it's sound list.
When clients want sound/auto_soundlist.txt, give them the one specified in the CVAR pretending it really is sound/auto_soundlist.txt.
Solution 2 would be ideal for the next release, but solution 1 and 3 wouldn't require a client update and could be done server side now if they wanted.
