TF2 Map Workshop Server Configuration

[worMatty]

I agree. For testing at TF2maps it's best to keep on using version numbers and hosting the maps locally, here on our servers. Hosting the maps on the workshop would require someone to do a tf_workshop_map_sync on the servers, and add the map to the rotation file for each new version, but someone could perhaps write some scripts to automate it. Clients would have two copies of each version of your map, but the new BSP compression is very good.

Due to the way the workshop works, you might cause problems for server operators if you use different file names. Maps will update automatically when the server changes level. But the server's map list will still point to the old version of the map. The workshop won't send old versions of maps, and they won't be downloaded from the server because TF2 insists on contacting the workshop for any map that has a workshop/ path prefix. Players will get a missing map error and will be booted off. This will happen to every server, the moment you update your map, and it will not be fixed until server operators realise the change and alter their map lists.

The whole point of the workshop from the point of view of a server operator, aside from making the FastDL server redundant, is that it takes care of map updates. They don't have to bother checking every map in their rotation for updates any more, they can let the workshop take care of it for them. But this system is broken if a map author uses a different file name. If a server operator finds this behaviour annoying because it loses him traffic, he might be inclined to remove a map from his rotation until it arrives at a final, or stable release.

The workshop will be what Valve use to earmark maps for inclusion in to the game. Server operators play a vital role in this system, it's not just about the mappers. Server ops will be browsing the workshop for popular maps to put on their servers, and you can support them by keeping the file names the same. If you are concerned about the time relevance of feedback you receive in the comments on your map's workshop page, remember that if you stick to the same name, the player is most likely to have played the current version at the time he posts his thoughts. There is a section on the workshop map pages where you can post changelogs, so you can easily compare these dates with the dates that the feedback was submitted.

It's probably best to version the maps you release on normal channels like here on the forum and Game Banana, and keep your workshop maps the same filename.

 

[Crash]

Compiling and everything that comes with it twice for every release sounds like a pretty big pain in the ass, so hopefully that's something we can get them to take care of.

 

[Powerlord]

Just an FYI, there's also an issue where servers logged into server accounts (the sv_setsteamaccount kind) can't download maps from the workshop at all.

Valve was going to look into this issue late last week.

Here's hoping they fix all the problems we've seen all at once.

 

[YM]

Maps will update automatically when the server changes level. But the server's map list will still point to the old version of the map. The workshop won't send old versions of maps, and they won't be downloaded from the server because TF2 insists on contacting the workshop for any map that has a workshop/ path prefix. Players will get a missing map error and will be booted off. This will happen to every server, the moment you update your map, and it will not be fixed until server operators realise the change and alter their map lists

In this case, we need to convince Valve to implement UGC ID based mapcycles. Put in the map's number without the name and then the game will look in the right folder and tell you the human-readable name, and the server will ask the workshop for the right file to pull.

That way, both servers and clients don't care when the human-readable name changes because it's all linked to the same UGC ID.

So far the biggest problem I have with this system is the workshop/ prefix and the .ugc<horrible-numbers-you-can-only-copy-and-paste> that make typing "!nominate" and "!setnextmap" commands from sourcemod impossible.

The authors of sourcemod certainly CAN do something about this with time (or may have already) but there is a lot of room for Valve to improve this situation.

EG:
In a mapcycle.txt
workshop/pl_haste_b1.ugc454116894
is replaced by just
ugc454116894

If I go update haste to _b2, it'll still work because ugc454116894 points to whatever file that map is currently using so both clients and servers get the right map.

The game would ask the workshop what ugc454116894 means when displaying the name anywhere and return "pl_haste_b2" (or better yet, allow us to specifiy "Haste" like pl_badwater is displayed as Badwater Basin)

If sourcemod is able to hook into the game's interpretation (or update to their own interpretation) of the ugc454116894 number then players and admins would always know which filename to use in their commands. The maplist would show "workshop/pl_haste_b2" instead of "ugc454116894" so the player could type "!map workshop/pl_haste_b2" and either sourcemod or the game itself would turn that back into the full filename (which it definitely knows, because it just fetched it from the server's map list)

 

[worMatty]

Converting to ID-based map lists would help overcome the problem of differing filenames. Rather than scan folders for version numbers it would probably be easier to either query the workshop for the current file name, or check the ACF file that Valve identified to Crash.

Authors of SourceMod map list/vote plugins could change the way map names are displayed so that the workshop/ prefix and ugc suffix are not shown. That would make them look neater and would help admins choose maps through the menu, and perhaps also manually through a chat command. Manual map change commands could use a wild card asterisk * character in place of a version number to account for automatic map updates.

File name versioning has always been necessary to stop file mismatch errors received by using the same filename. The workshop makes it unnecessary now. I think, rather than try to alter the system to accommodate filename versioning, it's best to stop the practice, if the only reason is to keep feedback organised. Consider also the many versions of a map that a server or client could accrue on their system compared with the self-managing replacement method of same-name BSPs.

I think showing the name of the map as it appears on the workshop, rather than the file name (minus prefix) is a positive suggestion. It gives you the freedom to change the name of the map as it appears in the workshop at any time, and you can also include a version number in that if you like. Or perhaps we could ask Valve to give us a version field in the in-game workshop interface, which is later displayed on the game screen. At least, I would like to see what type of game mode a map is, on the scoreboard, rather than having to work it out from the HUD. But maybe I shouldn't be skipping past the map information screen so quickly when I join a server

You don't need to compile two versions of your map to upload to the workshop and release via normal channels, Crash. Prepare one map, then copy it and repack its cubemaps under a different internal directory name. You don't need to edit the cubemap VMTs, since only the VTFs are used. If you use scripts or nav meshes, you can create two sets, one for each file name type.

If this sounds like a hassle, consider that converting to using same-name BSPs and hosting them exclusively on the workshop will mean you will never have to rename your script files, or menu photos, to account for a change in version number ever again. Once the automatic update issues are resolved by Valve, getting server operators to install your map will be as simple as having them perform a console command and adding it to their rotation, and then never having to do anything more. It's a one-time thing. Compare that with the current method of having to download a file and upload it to the game server and FastDL space, and monitor hosting sites for version updates.

If I ever get off my arse and produce some maps, I will have them tested here, using different file name versions. But as soon as I have a release candidate or something similar, I'll be putting it on the workshop using a wonderfully simple, versionless filename. The dream is real. No more cp_mymap_rc2 or cp_mymap_final. Of course, that is assuming that Valve have ironed out all the bugs by the time I have something of that quality. So that probably gives them a couple of years!

Thanks for the information, Powerlord.

 

[YM]

Once these things are addressed, we really need the biggest issue to be fixed: The workshop needs a quickplay hook so that there are more than a tiny handful of players looking for workshop servers.

 

[YM]

All the fixes today:

• Workshop map names (e.g. workshop/cp_foo.ugc123456) can now be used in the map, changelevel, and nextlevel commands as well as the mapcycle config
• Allow fuzzy name matching in the map, changelevel, and nextlevel commands as well as the mapcycle config -- e.g. "changelevel dustbowl"
• Shorthand workshop map names of the form workshop/ (e.g. workshop/123456) will now auto-resolve to the full map name
• Running tf_workshop_map_sync is no longer necessary, maps will be fetched and updated on demand during level change
• tf_workshop_map_sync is no longer blocking, and can be used to precache maps in the background
• Workshop maps are no longer copied to tf/maps/workshop/ by default, instead using the single copy in the steamapps/workshop folder
• Fixed some cases of embedded resources in workshop maps, such as cubemaps, not being loaded properly
• Fixed an issue preventing game servers from properly receiving updates to workshop map files
• Fixed game servers using registered accounts via sv_setsteamaccount not being able to download workshop content
• Fixed syncing workshop maps prior to the first map load on a dedicated server
• Updated in-game workshop import tool
  • Fixed not being able to select the class/other tags for cosmetic items
  • Hide unused buttons when editing an existing workshop entry
  • Fixed text getting truncated when editing items with long descriptions

cubemaps, way better name matching, properly updating files. Seems like all the majoy things so far

 

[worMatty]

I have been experimenting today.


SourceMod and workshop maps

SourceMod map lists were broken with the release of the updated TF2 software. SourceMod users can fix it by downloading the latest snapshot of SourceMod 1.7.3. It is also fixed in the beta 1.8.

If you use UGC IDs in your rotation file, then it will display as a UGC ID in SM map lists. SourceMod does not resolve UGC IDs to map file names.

SourceMod does not support fuzzy map names. You must use exact file names, so updated maps with differing file names are not currently supported.


Continued problems with workshop maps on servers, regardless of SOurceMod being installed

All of the map changing, listing and voting functionality that uses UGC IDs and fuzzy map names built in to the stock TF2 server works fine.

When using a fuzzy map name for a map with a version, and you have multiple versions, it will select the map which has the lowest letter and number. E.G. a1 has priority over a2, b1, b2, rc1, final, etc.

Servers *are* updating maps when changing to them, but they are not actually switching to the maps. If you change level to a UGC ID, it may/may not download an updated version of the map, but it will actually only change map to the map you were playing when the command was given. Clients will still download the latest version of a map, and get a version mismatch error.

I have had some success switching to an updated workshop map after a server restart, on a remote server I have access to.

Repeatedly on my local testing server I have been given an error in console: "No such map." It has also not updated the map file. I can't get it to update by any known means, so my only remaining option is deleting the file, and perhaps deleting/editing the ACF file. It's a bit hit or miss. This was with and without SM.

When a workshop map is updated, the old copy is deleted!

EDIT: The stock TF2 voting system shows workshop/1234567, and does not display map names.

Happy days.

 

[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.

 

[YM]

I keep running into the issue where it leaves one map, only to return to it. It happens for all workshop maps, not just ones that have been updated.

Slapping down this for records:

L 06/16/2015 - 16:01:58: [SM] Changed map to "workshop/cp_furnace_rc.ugc454147907"
[TF Workshop] Preparing map ID 454147907
[TF Workshop] Map is not tracked, adding
CModelLoader::Map_IsValid: No such map '/usr/local/games/tf/1173533/173.199.78.185:27015/orangebox/steamapps/workshop/content/440/45414'
Unable to change level!

The map is definitely on the server

 

[worMatty]

This is what is supposed to happen:

changelevel workshop/cp_furnace_rc.ugc454147907
[TF Workshop] Preparing map ID 454147907
[TF Workshop] Map is not tracked, adding
---- Host_Changelevel ----
SOLID_VPHYSICS static prop with no vphysics model! (models/furnace/power_core_frame.mdl)
SOLID_VPHYSICS static prop with no vphysics model! (models/furnace/power_core.mdl)
L 06/16/2015 - 17:33:34: -------- Mapchange to workshop/cp_furnace_rc.ugc454147907 --------
Executing dedicated server config file server.cfg
Set motd from file 'cfg/motd_default.txt'. ('cfg/motd.txt' was not found.)
Set motd_text from file 'cfg/motd_text_default.txt'. ('cfg/motd_text.txt' was not found.)
'workshop/cp_furnace_rc.ugc454147907.cfg' not present; not executing.

There was a pause after the server added the map to its tracking, while it downloaded the map. Then everything else in the console followed.

Last night I moved an altered rotation file with one workshop map entry on to a live server. When the server switched to the map after users voted for it to select it, the server froze and my client seemed to be in a cycle of attempting to connect and failing. This cycle apparently caused Steam to spam the TF2maps chat room with "worMatty is now playing Team Fortress 2..."

The server had to be restarted. The map file had not been downloaded. I did a tf_workshop_sync_map to pre-download the map. The next time the server changed to it, the map worked, but it still did not use the sound scripts, scapes, menu photos, etc and it had a missing texture on some buttons! Gosh darn it I thought they had fixed this.

I will update the original post soon to make it comprehensive.

 

[Pocket]

I sort of see the logic behind the numbers thing; what if two people try to name their map the same thing? We have an unofficial rule against it here, but the Workshop is a fully automated system that has to be idiot proof.

Not guaranteeing that both ends have the same version is going to be a bugbear, though. Ideally, switching to a map should force a check against the Workshop server even if it just checked in a few minutes ago, and in theory that should do the trick. If it's the client that's not up to date, the server should be able to push its copy and override it. What's left to account for? Propagation among Valve's own Workshop servers?

 

[UKCS-Alias]

The server had to be restarted. The map file had not been downloaded. I did a tf_workshop_sync_map to pre-download the map. The next time the server changed to it, the map worked, but it still did not use the sound scripts, scapes, menu photos, etc and it had a missing texture on some buttons! Gosh darn it I thought they had fixed this.

Be glad its not an mvm map. As then after the download you would have to extract the nav and popfiles and manualy move them to the folders they should be in. Otherwise the map wont work at all.

 

[Freyja]

Be glad its not an mvm map. As then after the download you would have to extract the nav and popfiles and manualy move them to the folders they should be in. Otherwise the map wont work at all.

I never had an issue packing nav and popfiles into my map and distributing it when I made my mvm map, what changed?

 

[YM]

Just going to post this here for completeness:

I'm still having trouble after a fresh server install and putting sourcemod 1.7.3 on
Here's the pastebin:
http://pastebin.com/PcRc9EKP

The problem is repeatable and infuriating:
I'll reboot the server and it loads upward.
I'll try and change to metalworks, it loads upward (trying again loads upward again)
Changing to furnace works
Changing to metalworks NOW WORKS
now I can change to any workshop map with seemingly no problems.

I just... I just don't know...

Maybe someone can see something in the pastelog that I'm missing

Just as I finished typing this I noticed the number at the end of metalworks that was failing was several digits short. I think somehow I've managed to copy/paste an incorrect string _every_ time I select that text through tf2's little ingame chat window. When I select it from my mapcycle.txt it seems to get the whole string and works ok.

Soooooo Moral of the story appears to be: if you get the ugc<numbers> wrong it'll just reload the previous map.

touchwood.

 

[worMatty]

YM, I presume you have updated your server to 2836387? One of the fixes mentioned in the HLDS mailing list, a week ago was a fix for servers with long file paths. I noticed yours seemed a bit long, to me, so hoped it would resolve your problem of not being able to do anything with workshop maps at all. I'm happy to see you are having some success. Thanks so much for contributing your experiences to this thread. I believe we are helping a lot of people.

I have still struggled to update workshop maps that have new filenames.

[TF Workshop] Preparing map ID 461887534
CModelLoader::Map_IsValid: No such map 'C:\steamcmd\tf\steamapps\workshop\content\440\461887534\dr_castle_steveh.bsp'
Unable to change level!

dr_castle_steveh.bsp is actually the new filename of my test map on the workshop. The server never actually downloaded it, it still has the old version, I guess that's why it says it can't find it.

I've been hesitant to email them about the updating problem. I'm disappointed that the system doesn't work properly. But Valve have a lot of work to do with their modern projects, so I appreciate what we have so far and that it can take a while.

 

[tyler]

I think somehow I've managed to copy/paste an incorrect string _every_ time I select that text through tf2's little ingame chat window.

Hasn't copy/pasting in TF2's chat window been shitty forever? I always have to copy more text than I want and edit it down because it just never selects anything right.

 

[YM]

I did notice that my filepaths were long before they pushed out that fix. As soon as I read it I assumed that was my issue.

 

[UKCS-Alias]

I never had an issue packing nav and popfiles into my map and distributing it when I made my mvm map, what changed?

Custom content currently doesnt get loaded at all in workshop submissions. When you open an mvm map from the workshop it will be stuck in wave 0 as both the nav and pop files arent loaded.

It requires the server owners to manualy place the files in the folders to make it work. And they got 2 ways to do so:
- They move the map so it no longer is a workshop submission. Everything loads but clients download the maps again. Its ugly and also counter productive to the workshop. Additional missions work this way at least. Updates can result in bsp collisions as clients need to remove it.
- They rename the nav and popfiles and put them in their reppsective workshop folders (maps/workshop/map.ugc123.nav and scripts/population/map.ugc123.pop). It has a restriction to only the standard popfile and requires the use of tf_mvm_popfile to change to the extra missions. Clients can use the workshop version without problems this way. But a map update can break the extra content

Luckily the mvm maps provide the nav and pop seperately to at least help server owners on that part. but its ugly.

 

[Crash]

Have you emailed Valve about it, Alias?