The only confusing thing I can see here is that auto-completing Workshop maps returns different results in L4D2+ than it does for OrangeBox games.

When TF2 auto-completes a workshop map, it will return eFindMap_NonCanonical or eFindMap_PossiblyAvailable on success depending on whether the map is being tracked and it can get the "real" name ("real" is in quotes because the path doesn't actually exist on disc).

L4D2+ doesn't know if it's dealing with a workshop map or not, so just returns eFindMap_FuzzyMatch any time it does fuzzy matching.

Also, I'm assuming the FileExists is being done to avoid logging IsMapValid errors being logged to the server console.

On a side note, I've been told by Valve's John Schoenick that TF2's

IsMapValid() now requires a proper qualified filename, and no longer blindly wraps input in maps/%s.bsp due to engine changes. In a future SDK update these changes will be restricted to IVEngineServer v23 and requesting v22 will give you a legacy wrapper.

but since we use FindMap these days anyway, I guess this isn't really important.

When TF2 auto-completes a workshop map, it will return eFindMap_NonCanonical or eFindMap_PossiblyAvailable on success depending on whether the map is being tracked and it can get the "real" name ("real" is in quotes because the path doesn't actually exist on disc).

L4D2+ doesn't know if it's dealing with a workshop map or not, so just returns eFindMap_FuzzyMatch any time it does fuzzy matching.

Intended, for now. That's also documented in the enum. Does TF2 never give FuzzyMatch for workshop maps, even if they're fully downloaded and you use a partial, canonical name, ex. "workshop/"?, rather than a non-canonical name like "workshop/"

Also, I'm assuming the FileExists is being done to avoid logging IsMapValid errors being logged to the server console.

Correct, as noted in the comment above that call.

but since we use FindMap these days anyway, I guess this isn't really important.

Indeed. For that code path (just TF2 right now), we don't even call IsMapValid.

For workshop/123456789 style for a workshop map you already have

• If the map is being tracked (via tf_workshop_map_sync or loading the map once), it will copy the workshop/mapnamehere.ugc123456789 style name into the string variable and return eFindMap_NonCanonical
• If not tracked, but a copy of the map exists on your server, it will not change anything, but return eFindMap_PossiblyAvailable

I haven't tested what it will return for workshop/mapnamehere.ugc123456789 style.

I see now. For TF2 workshop maps, they're not actually at the path displayed in console, nor even in the maps folder at all. That explains why FuzzyMatch doesn't/won't/can't work for them.

I still don't think that there is anything that we should (or can) do about it in code. I'll see about making the docs clearer.

It looks like there is also a compile error on Clang that I need to clear up. I only tested on MSVC/Windows.

I've updated Pull Request #350 to be based on this PR instead of #349.

Of course, that means it has the same Clang compile issue. I'll have to make sure I merge it again after this one is fixed... and then do some testing on it.

Hokay. Linux compile should be fixed now, and the native doc has been updated according to the findings above.

Hmm... Apparently TF2 is returning eFindMap_Found when it does non-Workshop fuzzy matching.

I should probably report this to Valve.

It returned FuzzyMatch for me when trying "cp_dust" and gave back "cp_dustbowl".

@psychonic Hmm... I was trying "dustbowl" and "dust" and it's executing the FindMap_Found case in my switch block.

(This is in a SourceMod plugin)

@psychonic Were you testing that on Windows or Linux?

I'm testing this on TF2 Linux with this plugin.

FindMap_NotFound, FindMap_NonCanonical, and FindMap_PossiblyAvailable are all working as expected (for not found, workshop resolved, and workshop unresolved).... I just happen to be getting FindMap_Found for both direct matches and fuzzy matches on TF2.

You're right, even on Windows. I must have not actually seen what I thought I saw. Using the exact case in Valve's own enum doc for eFindMap_FuzzyMatch, "Ex: cp_dust -> cp_dustbowl"), gives back eFindMap_Found (while still updating the buffer with the exact name).

I'll report it and just add a shim around it for now to return FuzzyMatch if the input doesn't match the output.

That is fixed now.

Thanks psychonic. I can confirm this latest change appears to be working properly.

I'll report it and just add a shim around it for now to return FuzzyMatch if the input doesn't match the output.

This has been acknowledged and will likely be fixed in a future game update.