[Powerlord]

It should get them to download the map.

I'm not sure if tf_workshop_sync_map has to be in server.cfg. I didn't think so, since it is tracked in steamapps/workshop/appworkshop_440.acf.

I do know my test server got me to download glassworks when I was testing it (my client wasn't subscribed to it), but I haven't done further testing on it... and I had synced it earlier in the same session.

[worMatty]

Greetings.

I have been experimenting with the TF2 workshop from the perspective of a server operator, as I am really excited about the benefits it has. Always-up-to-date maps, no need for FastDL, compressed BSPs, potential extra traffic, etc. I have been surprised to find there is little discussion about this, so I logged my research in a couple of threads on TF2maps here and here.

In case you are unaware, King Cnut, you need to prefix all map change commands for workshop maps with workshop/. You don't need to move any map files as the server seems to mount them from the steamapps dir. Your rotation files should address workshop maps with that prefix, too.

tf_workshop_map_sync is what you would use to add a workshop map to the server's watch list, the ACF file in steamapps/workshop. When the TF2 map workshop went live two weeks ago, this command would download a map to your server (in the two locations we know of, though this has been changed to one location as you are aware). Unfortunately, since the update on the 12th June, this command has not downloaded maps, for me, on my local server or an online server I have access to. In order to download a map I have had to changelevel workshop/{mapid}. That has forced the download, and if a map was not on my tracking list, then it would be added to it. You can just use this format in your rotation files and never have to use tf_workshop_map_sync, but obviously that is not user-friendly for players as it does not display the map filename, and SourceMod map stuff doesn't like it at the moment. TF2 server resolves map IDs to filenames when changing the map but it does not resolve them in its built-in voting tools. tf_workshop_refresh seems to do nothing for a server and only responds on a client console. It seems to be a manual method for checking personal workshop subscriptions.

Once you have successfully downloaded a workshop map to your server, you can load it using a fuzzy command. For example, changelevel workshop/glassworks. It has become apparent to me that upon downloading an updated version of a workshop map, where the author has altered the filename to increment the version number, the old map file will be deleted, and only the current map will occupy the map's directory. Therefore, a server op should not need to worry about updating his rotation files if he sticks to using map IDs or fuzzy filenames (excluding SourceMod), since there won't be multiple versions of a map causing a conflict.

Unfortunately, though, automated map updating by servers appears to still be broken. Client map updating works great, and so this causes version mismatches. I ran a local server and changed map to a test workshop map I had uploaded. During the same server session, I updated the map on the workshop. I changed levels in and out of my map on my local server but it would not download the new version. tf_workshop_refresh was typically useless, and tf_workshop_sync_map {mapid} gave me an error. When trying to change levels to its map ID I got:

CModelLoader::Map_IsValid: No such map 'C:\steamcmd\tf\steamapps\workshop\content\44 0\459942466\workshop_test4.bsp' Unable to change level!

I had temporarily removed SourceMod for this server session. This error message actually showed the current filename of the map on the workshop. The file on my computer was still the old, differently-named version.
When attempting the same process on an online server, I had mixed results. The most common thing to happen was that, upon receiving the request to change level, the server would download the up-to-date version of the map, then rather than play it, dump players back on the map they had just come from. Changing level again, straight after this, would still just repeat the last-played map. Only after a restart would the server change to my workshop map. This server was running SourceMod. I received no error messages, or information in the console when doing this.

I hope my problems are caused by unusual testing environments, though I have seen no outside evidence to confirm a remaining problem with the workshop or suggest I am doing something wrong. At the moment, hosting workshop maps is not comfortable if you rely on SourceMod for your map tools, and updating seems to be shaky. Heck, getting them on to the server is no easier since the second workshop update. I would like to know if others are having the same experience as me.

Thanks,

Matty


EDIT (15.06.2015, 03:14 UTC): tf_workshop_map_sync is now downloading maps for me, on both servers.

[worMatty]

New information.

You can't:

• Change to a workshop map by using a fuzzy filename. E.G. workshop/glassworks.
• Change to a workshop map by typing its full filename. E.G. workshop/cp_glassworks_rc6.

You can:

• Change to a workshop map by using its map ID. E.G. workshop/123456789.
• Change to a workshop map using the following: workshop/anything.ugc123456789. Anything can be put in the first part of the map's name, it doesn't matter. The server only uses the ugcID.

If you use workshop/anything.ugc123456789 in the rotation file, both the default TF2 map voting system and SourceMod's map tools will successfully change maps, and also display the entry in menus as it appears in the rotation. You don't need to use tf_workshop_sync_map because the server will start tracking it the first time you change.

This method is great because you can specify a friendly name for a map in your rotation without having to manage a list of numbers.

Updating maps is still a concern. When a map is updated on the workshop, there seems to be a period of time before a server will be able to download the new version. If you try to get the server to download it in this time period it will just play the old map, and your clients will be kicked because of a version mismatch.
On the remote server I tested with, when I changed map later, it did download the new version, but it didn't play it. Instead, it replayed the last map. I could not get the server to switch to the updated workshop map until it was restarted.

So the current situation is that it seems to be safe to host workshop maps and use SourceMod map tools, but if a map is updated by its author it could cause you some temporary inconvenience.

[King Cnut]

Woah Matty! Thanks for all the work you did figuring all this out. You have helped so many I'm sure! I'll give this all a shot today and see if I can get it working. I guess Valve really is going to rely 100% on the community to do their jobs for them huh?

[AeroAcrobat]

Could it be that +randommap is not working with workshop maps?
My server does not launch with a workshop maplist. Running & changing maps works fine.

[King Cnut]

Originally Posted by AeroAcrobat Could it be that +randommap is not working with workshop maps? My server does not launch with a workshop maplist. Running & changing maps works fine.

+randommap used to be bugged back in 2012. I wouldn't be surprised if it's broken again considering how terrible Valve is with bugfixes. Can you share your command line, just to rule out user error?

[Powerlord]

I should probably note that I'm testing changes both to the SourceMod core and SourceMod Mapchooser to deal with resolving map paths.

I'm still actively modifying it... TF2 is probably done, but testing may make a few bugs show their heads. I also still need to tweak the GetFriendlyMapName stock for other games, such as L4D2 and CS:GO.

For TF2, GetFriendlyMapName turns this:
workshop/cp_glassworks_rc6.ugc454118349
into this:
cp_glassworks_rc6

You can probably see why that would be handy.

(It's meant for display purposes only, don't use the output from this for changelevel).

Edit: Even with today's update, it appears that TF2's internal FindMap isn't resolving workshop/454118349 to workshop/cp_glassworks_rc6.ugc454118349 on the first try. I might have to report this to Valve.

[Powerlord]

After doing some research, I highly recommend that you put tf_workshop_map_sync lines for all workshop maps you have in your server.cfg file or in a file you exec from your server.cfg.

The reason being that TF2 does not track workshop maps unless you do one of these things:

1. Run tf_workshop_map_sync for it after the server starts. autoexec.cfg appears to be too early for this.
2. changelevel to the map the first time.

This may cause issues if the map is updated. Your server must be tracking a map in order to download updates for it.

That is, assuming the server will download updates to a map in the background.

TF2's FindMap also doesn't give my updated MapChooser code the actual name of the map to produce a friendly name in nomination lists and votes if the map isn't tracked...

As for the MapChooser stuff I mentioned in my previous post, I got sidetracked and didn't get around to testing it... I did fix the CSGO thing I mentioned earlier, though. Not sure if I need to worry about friendly map names for L4D, L4D2, DOTA2, etc... though.

[Potato Uno]

I just want to throw out that to MvM server owners out there (who unfortunately get no love from anyone), none of the stuff mentioned above will work, especially since we have extra dependency files to install like nav and pop files (bsp, nav, and however many pop files). The workshop does not support the downloads of these files, so if they aren't packed inside the bsp already (most mappers choose not to pack them in for good reasons), you will have to manually check the map submission's page each time a map gets an update for the new nav & pop files.

In addition, the map list on the votemenu uses tf_mvm_missioncycle.res, not mapcycle.txt (or whatever the pvp one is), which should be stored on /tf/custom/some_folder_name/tf_mvm_missioncycle.res in order to display the names of custom maps. I have no idea how workshop maps can be listed on this file at the moment, but I personally just shove workshop maps into /tf/maps (where all other maps are) every time a mapper releases an update, and then run a program to automatically re-generate the res file again.

I download the workshop maps to my client and FTP them to the server when needed, especially since steam reminds me at the bottom that workshop maps have been updated. This is not an elegant solution but it works for me and mvm isn't left out in the dark. You can try to automate the map sync but at the end of the day, you'll still have to do some manual work to set up the rest of the files in order to fully get the mvm workshop maps up and running. MvM maps require more assembling and installation in order to get working and aren't drag n drop like pvp maps are, unfortunately.

[Powerlord]

Remember what I said yesterday about putting tf_workshop_map_sync in your server.cfg?

I did that and now my server constantly crashes on startup.

So... don't do that.

I'm not sure if this is due to certain maps or what.

Edit: My Linux server is crashing any time I try to do a tf_workshop_map_sync on a map that's not already downloaded.