...figures, I noticed a typo in the comments for the native as soon as I finished the pull request.

Here are some results from my TF2 test server using my test plugin linked above:

mappath glassworks
glassworks is not a valid map
mappath workshop/454118349
workshop/454118349's real path is workshop/cp_glassworks_rc6.ugc454118349
mappath dustbowl
dustbowl's real path is cp_dustbowl
mappath sawmill
sawmill's real path is ph_sawmill_a2
mappath nucleus
nucleus's real path is arena_nucleus

I don't like this returning false if the name matches, other then that this is a great addition as it should prevent casing mismatches from user input. Hopefully this makes it to other the Source engine forks.

Just bringing this up as well, where the engine doesn't have support, we could roll something by hand in another PR. This isn't a complicated function, and we already have IDirectory.

@KyleSanderson Well, I couldn't tell if AutoCompleteSuggest would suggest things that were an identical match or not... the goal is obviously to make the two implementations identical.

Edit: By which I mean I'll have to check what CS:GO and such do.

As for adding our own implementations, it depends on if we JUST want it to work on things that work for ForceChangeLevel / changelevel / mapcycle entries or not.

The TF2 and L4D+ ones are already not identical, having different
matching logic.

Ross Bemrose mailto:[email protected]
Monday, June 15, 2015 11:19 PM

@KyleSanderson https://github.com/KyleSanderson Well, I couldn't
tell if AutoCompleteSuggest would suggest things that were an
identical match or not... the goal is obviously to make the two
implementations identical.

As for adding our own implementations, it depends on if we JUST want
it to work on things that work for ForceChangeLevel / changelevel /
mapcycle entries or not.

—
Reply to this email directly or view it on GitHub
#348 (comment).

Ross Bemrose mailto:[email protected]
Monday, June 15, 2015 3:50 PM

This also modifies the internal ResolveFuzzyMapName to have multiple
implementations, decided at compile time.

While I have tested to make sure I can compile a plugin against it
https://github.com/powerlord/sourcemod-snippets/blob/master/scripting/resolvefuzzyname.sp,
I have not yet had a chance to test it on a real server... and chances
are I won't have a chance to until tomorrow.

---

    You can view, comment on, or merge this pull request online at:

#348

    Commit Summary

• Add new ResolveFuzzyMapName native, modifying internal
  ResolveFuzzyMapName command to be a member function.

  File Changes
  

• M core/HalfLife2.cpp
  https://github.com/alliedmodders/sourcemod/pull/348/files#diff-0
  (18)

• M core/HalfLife2.h
  https://github.com/alliedmodders/sourcemod/pull/348/files#diff-1
  (1)

• M core/smn_halflife.cpp
  https://github.com/alliedmodders/sourcemod/pull/348/files#diff-2
  (17)

• M plugins/include/halflife.inc
  https://github.com/alliedmodders/sourcemod/pull/348/files#diff-3
  (16)

  Patch Links:
  

• https://github.com/alliedmodders/sourcemod/pull/348.patch

• https://github.com/alliedmodders/sourcemod/pull/348.diff

—
Reply to this email directly or view it on GitHub
#348.

@KyleSanderson After verifying on CSGO that it does return true for identical maps, I have changed the TF2 behavior to match.

Having said that, it was also autocompleting de_dust to de_dust2 on CS:GO... so I modified the behavior to check the engine's IsMapValid command before it does any fuzzy matching.

Note: It's important that it's the ENGINE'S IsMapValid as if it called SourceMod's IsMapValid, we would end up in an endless loop.

I will be testing outputs on this again shortly.

Edit: There is one additional side effect of this change... games that don't support fuzzy names will now return true along with copying the map name into the output if the map exists.

Edit 2: OK, so as you can see below, TF2's IsMapValid fails for maps that match identically, so I've wrapped it so it's only called on other game engines. I assume this is why SM's IsMapValid doesn't call it for TF2.

I know you guys aren't particularly fond of bumping the version numbers of SourceMod's interfaces, but I added ResolveFuzzyMapName to the IGameHelpers interface since its only core implementation also implements it in this pull request.

Now for a question: When I started implementing changes to plugins to start using this, I ended up writing two stocks for things I kept using in multiple plugins.

The problem is that one of these stocks will change every time an additional game starts supporting workshop maps... requiring a recompile of every plugin calling it. Should this function be moved to a native itself?

Basically, it's for getting the display name of a resolved workshop map. At the moment, I've only implemented TF2 as I keep forgetting to check what GetCurrentMap returns for CSGO Workshop maps... and I'm not about to log into Steam from work to get my API key.

(As an example, In TF2, it turns workshop/cp_basename_here.ugc123456789 into cp_basename_here)

I'm mildly concerned about not exposing the result of FindMap (due to the case of a map possibly existing but not being "ready"). However, if IsMapValid returns false for those (and it might or might not, I didn't look/remember), then that should be fine.

Go ahead and hold off for now on any further changes to this. I discussed it will some of the rest of the team and am going to see if I can quickly bang out what we ended up deciding on. Thank you though for getting the ball rolling.

@psychonic
IsMapValid is currently returning true for everything except eFindMap_NotFound.

In TF2, I'm not sure if there's a good way to resolve workshop maps if the user currently isn't using tf_workshop_sync_map on the map. According to Valve's John S., FindMap will return eFindMap_PossiblyAvailable, but not rewrite what you passed into it... although for it to be picked up as a Workshop map, you have to pass in either workshop/123456789 or workshop/anythinghere.ugc123456789. If a Workshop map is currently being tracked, it will be resolved to the latter style name.

Incidentally, John S. also said that eventually, all workshop maps in the MapCycle will be synced automatically.

There's also a bug right now where doing tf_workshop_map_sync in your server.cfg will likely crash the server as soon as a plugin attempts to read a map list in OnConfigsExecuted. The TF2 Workshop Map Loader plugin exists to delay that by a few seconds to prevent this crash. I was told last week Friday that this would be fixed in the next TF2 update.

One last note: This is supposed to be cross-game compatible. While we could alter it to return an enum of some sort, we'd have to be aware that only TF2 would have results that are really anything other than true or false.

It occurred to me after my last post that yes, we could return our own enum based on whether it's a fuzzy match or not. Still not sure how we'd handle TF2's eFindMap_PossiblyAvailable result though.

This is being closed as #351 was merged instead.