[Sreaper]

I noticed some of the workshop maps aren't playing soundscapes properly when the files are referencing the short name.

If I'm to host my own workshop maps, am I going to have to start naming my embedded script files to "soundscapes_workshop/cp_glassworks_rc6.ugc454118349.txt"? (Example map name)

[Powerlord]

Originally Posted by Sreaper I noticed some of the workshop maps aren't playing soundscapes properly when the files are referencing the short name. If I'm to host my own workshop maps, am I going to have to start naming my embedded script files to "soundscapes_workshop/cp_glassworks_rc6.ugc454118349.txt"?

I hope glassworks was just an example, as I know you aren't the author of glassworks.

Anyway, the game is supposed to expand the map to its long name before looking up files for it.

That's why it tries to execute workshop/cp_glassworks_rc6a.ugc454118349.cfg and not workshop/454118349.cfg when I do changelevel workshop/454118349. (incidentally, that's from the cfg/ directory)

[Sreaper]

Originally Posted by Powerlord I hope glassworks was just an example, as I know you aren't the author of glassworks. Anyway, the game is supposed to expand the map to its long name before looking up files for it. That's why it tries to execute workshop/cp_glassworks_rc6a.ugc454118349.cfg and not workshop/454118349.cfg when I do changelevel workshop/454118349. (incidentally, that's from the cfg/ directory)

It was an example map you provided in an earlier post since I didn't have anything on hand. I'm still not really understanding your response though.

Here is the map I'm trying to host: http://steamcommunity.com/sharedfile.../?id=454152123

I used this command on my dedicated server: "sm_map workshop/454152123" which loads the map, but no soundscapes play unless I stop running the workshop version and manually place the file in tf/maps.

[worMatty]

Hi, Sreaper.

This isn't really a problem concerning server operators. I have updated my workshop map FAQ thread recently, which has information for clients and map authors. Inside I list the packed custom content which is currently known not to work. This includes scoundscapes and soundscripts.

You could rename your packed files to add the ugcID, but I don't know if it will work. By all means give it a go and report what you find. But I recommend against the practice long-term because I think it is a bug that will be fixed. I have experimented using the bsp_repack function on a non-workshop map and that caused its script files to stop working, so I am not sure if it's as simple as a name mismatch.

I have heard through the grapevine there is a significant update to the TF2 map workshop coming, but I have been given no ETA. There are unfortunately other problems facing server operators that must be fixed before workshop maps can really take off.

[Powerlord]

Originally Posted by worMatty Hi, Sreaper. This isn't really a problem concerning server operators. I have updated my workshop map FAQ thread recently, which has information for clients and map authors. Inside I list the packed custom content which is currently known not to work. This includes scoundscapes and soundscripts. You could rename your packed files to add the ugcID, but I don't know if it will work. By all means give it a go and report what you find. But I recommend against the practice long-term because I think it is a bug that will be fixed. I have experimented using the bsp_repack function on a non-workshop map and that caused its script files to stop working, so I am not sure if it's as simple as a name mismatch. I have heard through the grapevine there is a significant update to the TF2 map workshop coming, but I have been given no ETA. There are unfortunately other problems facing server operators that must be fixed before workshop maps can really take off.

It disturbs me that neither of your threads over on TF2Maps even mention the two known crashing issues with workshop maps at the moment. I would expect at the very least that the server operators thread would mention them.

Those crashing issues being:

1. If you installed the last optional update from June 17th or so and use sv_setsteamaccount, your server will crash when it tries to download a new map (even a new version of an existing map).
2. If you use tf_workshop_map_sync in your server.cfg file, the server will likely crash as soon as a SourceMod plugin that reads map lists starts.

[worMatty]

Valve released a fix on June 12th that addressed servers using sv_setsteamaccount being unable to download workshop maps. I haven't seen any reports of the problem remaining after that so when I updated it recently I left that out.

I've not recommended using tf_workshop_map_sync in server.cfg as it never seemed necessary. Once added to tracking, maps are supposed to be updated when the server changes to them. Valve removed the need to use this command in an update, and it was sufficient to only add workshop maps to the rotation file. I saw some information from you where you had experimented using it in server.cfg, and then the next day you recommended against it because it caused crashes.

There doesn't seem to be a need to use tf_workshop_map_sync any more. The only benefit it has that I can see is to pre-download an updated map prior to it changing, so players don't experience a delay. But I would be wary of checking every workshop map each time the map changes because it would seem like a lot of queries for little benefit. That's how I understand it, anyway. I'm not a server op, or a programmer.

Perhaps it would be better if, when the next map was decided, the server was told to check for an updated version then?

[Powerlord]

Originally Posted by worMatty Valve released a fix on June 12th that addressed servers using sv_setsteamaccount being unable to download workshop maps. I haven't seen any reports of the problem remaining after that so when I updated it recently I left that out.

You say this, but then you say...

Originally Posted by worMatty I've not recommended using tf_workshop_map_sync in server.cfg as it never seemed necessary. Once added to tracking, maps are supposed to be updated when the server changes to them. Valve removed the need to use this command in an update, and it was sufficient to only add workshop maps to the rotation file. I saw some information from you where you had experimented using it in server.cfg, and then the next day you recommended against it because it caused crashes.

It causes crashes when SourceMod attempts to load a maplist immediately after syncing. Valve's John S. has said this will be fixed in the next update. Today's update wasn't a server update, so I assume this is referring to tomorrow's update.

Besides which, I created a plugin to address this.

Now, I'm surprised you heard about this thing but not the sv_setsteamaccount crash as I discovered the two problems only hours apart... and the server.cfg issue was actually the second one I discovered. I certainly mentioned both on HLDS and here on AlliedModders.

Originally Posted by worMatty There doesn't seem to be a need to use tf_workshop_map_sync any more. The only benefit it has that I can see is to pre-download an updated map prior to it changing, so players don't experience a delay. But I would be wary of checking every workshop map each time the map changes because it would seem like a lot of queries for little benefit. That's how I understand it, anyway. I'm not a server op, or a programmer. Perhaps it would be better if, when the next map was decided, the server was told to check for an updated version then?

Actually, there is reason to do it. If you don't, TF2 and SourceMod's FindMap can't resolve workshop maps correctly... instead, they just pass you back what you passed into them and say that the map is possibly available.

While you may think this means nothing now, if my pending pull request gets approved, it will affect how workshop maps are listed in SourceMod's NextMap, MapChooser, Nominations, RockTheVote, BaseVotes, and RandomCycle plugins. With MapChooser Extended (and probably UMC) to follow.

According to Valve's John S., all workshop maps in the mapcyclefile will be automatically synced sometime in the future, possibly as soon as the Gunmettle Update tomorrow.

[Powerlord]

Edit: Forgot to mention, this isn't just a display thing, but it's also used to determine if a given map is a map that has already been played. Crucial for map voting systems.

Incidentally, if you want to see what that looks like, connect to the test server listed in my signature(password is "testing") and use the nominate command.

The mapcyclefile on that server consists of these maps:

upward
workshop/454118349
workshop/454160949
dustbowl
pipeline
lumberyard

but the nominations list will look like this:

pl_upward
cp_glassworks_rc6a
ph_cchotel_b3
cp_dustbowl
plr_pipeline
ph_lumberyard_a2

Do note that using the plugin I linked in my previous post means that the maps will still show their short workshop maps until the map has changed once. Luckily, since this is supposed to be fixed TOMORROW, I'll be able to fix my example server soon.

[worMatty]

Wow, that's pretty nifty.

I don't like the current state of my server post so I'll update it. I think the information is spread across too many 'answers'. I wanted to keep it simple, to encourage more people to take up the workshop. But lately when I've checked player numbers on workshop servers they have been depressingly low, so I didn't feel it was worth staying on top of it until Valve released another update. Unfortunately they've just taken longer than I expected to release one.

I'll try to include a bit about what you have posted here. I don't fully understand it as my grasp of things like 'FindMap' is a bit limited. In my experimentation, the default SourceMod map tools seemed to work fine without needing to use the tf_ command, but I haven't messed around with it for a couple of weeks.

I learned about the problem with sv_setsteamaccount from you, when you posted about it on the TF2maps thread :-) It was supposedly fixed a couple of days later so I didn't bother mentioning it. I think at that point, I wasn't using the original post in the thread as an updated FAQ, so I felt your post was enough. But then I got a complaint that the discussion was hard to track so I set about summarising it.

Thanks for your help and continued research, Powerlord/RB. Let us cross our fingers that all of this will become unnecessary ASAP.

[Powerlord]

There have been two different sv_setsteamaccount bugs.

• The original one just stopped you from downloading maps and put an error in your logs about it.
• The second one (introduced in the last Optional update) outright crashes the server when Steam tries to look up the gameserver account for your server. Something in steamclient.dll / steamclient.so.

If you tried using my test server just recently, you'd probably see it go down, a CS:GO server come up in its place, see that go down and the TF2 server come back up... and in general see me restarting it multiple times.

This is because I moved some of the code I wrote into SourceMod itself¹ and have been testing it to make sure it actually works.

While my test plugin works on both games, I now need to test all the other plugins I'd modified (NextMap, BaseVotes, BaseTriggers, MapChooser, Nominations, RockTheVote, and RandomCycle)... but can't do that because I'm at work.

This latest fix is so that we can change how the base map names are calculated when new games are added and not have to recompile all plugins that use GetFriendlyMapName GetWorkshopMapBaseName every time a new game gets workshop support.

¹I'm not a member of the SourceMod staff, this is so I can file a pull request to have it added to SourceMod itself in a later version.