drive-by: New API looks a lot better. Also, there is no risk of this integer truncation blowing up on 64-bit. SourcePawn integers are 32-bit, so int -> size_t -> int is harmless in this context. Plus, it's a relatively safe assumption that no one is going to use the C++ API to create a 2GB string buffer to hold a map name.

That said, the const_cast is gross - probably better to create a local buffer of size PATH_MAX instead.

🚢

@powerlord ke::SafeStrcpy was a replacement for strncopy which still does exist in SM 1.7 so it can be backported

@powerlord can you confirm this doesn't regress anything for you?

@WildCard65 I'm well aware of what it was a replacement for. Except that's not how AlliedModders usually backports things... usually it's done by cherry-picking commits from master into 1.7-dev (for example).

@KyleSanderson I'm not sure exactly what you want me to test. I can tell you right now that any code I have that uses FindMap is going to break as you've changed the SourcePawn syntax for it.

While we're on the subject of testing, you really should update plugins/testsuite/findmap.sp

In fact, that should have tossed an error in the Travis and AppVeyor tests. Why didn't it? Are we not actually building the testsuite plugins during our testing process?

I can tell you right now that any code I have that uses FindMap is going to break as you've changed the SourcePawn syntax for it.

Indeed. it will be broken at compile-time, but the already compiled plugins should work at runtime as-is.

Are we not actually building the testsuite plugins during our testing process?

We are not. Only a subset of the test plugins are meant to test for compile-time issues. It's still not necessarily a bad idea to have an opt-in switch in the ambuild script to compile them, just making sure that we don't ship them.

@psychonic Well, to not ship them, we just have to not copy them to the package directory, correct?

As for checking for regressions, I haven't compiled this branch (or even looked which branch it is) to do testing on it.

I can't currently test this as both this and SM master crash on Linux TF2 server start. I'll file a bug against master in Bugzilla about it.

@powerlord this is now resolved, sorry for the inconvenience.

@KyleSanderson Might want to merge master and/or cherry-pick that commit into this branch to update it as well. I mean, I know I can get around it by switching branches without updating submodules afterwards, but it's still a good idea.

Old commands that use FindMap appear to still work. It looks like Valve fixed the return types of its internal FindMap in the TF2 PASS time update as well.

• "cp_dustbowl" returns FindMap_Found and spits "cp_dustbowl" back out. This is unchanged.
• "cp_dust" returns FindMap_FuzzyMatch and spits "cp_dustbowl" back out. This is unchanged.
• "workshop/454118349" (a tracked map) now returns FindMap_NonCanonical and spits out "workshop/cp_glassworks_rc6a.ugc454118349". This was bugged to return FindMap_PossiblyAvailable during an update back in July.
• "workshop/cp_glassworks_rc6a.ugc454118349" (tracked map) now returns FindMap_Found. This used to return FindMap_NonCanonical then FindMap_PossiblyAvailable.
• "workshop/123456789" (untracked map) returns FindMap_PossiblyAvailable.

I have not tried the new 3-argument version yet. Then again, the sooner this gets merged into master, the sooner I can fix PR #354 to use it.

On a side note, when you merge commits on an already pushed branch, it does a very messy merge for the person who had pulled a previous version. Not only did it prompt me for a commit message, but this is what the merge looked like on the command line:

tf2@powerlord:~/dev/sourcemod$ git pull
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 7 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (7/7), done.
From https://github.com/alliedmodders/sourcemod
 + 939d73a...f59df24 findmapconst -> origin/findmapconst  (forced update)
Auto-merging core/logic/CDataPack.h
Auto-merging core/logic/CDataPack.cpp
Auto-merging core/HalfLife2.h
Auto-merging core/HalfLife2.cpp
Merge made by the 'recursive' strategy.
 bridge/include/LogicProvider.h         |   3 +
 core/AMBuilder                         |   1 -
 core/ChatTriggers.cpp                  | 196 +++++++++++--------------------------
 core/ChatTriggers.h                    |  30 ++----
 core/ConCmdManager.cpp                 |  90 ++++++-----------
 core/ConCmdManager.h                   |  18 +---
 core/ConsoleDetours.cpp                |  19 ++--
 core/ConsoleDetours.h                  |   6 +-
 core/CoreConfig.cpp                    |   6 +-
 core/GameHooks.cpp                     |  72 +++++++++++++-
 core/GameHooks.h                       |  54 +++++++++-
 core/HalfLife2.cpp                     |  10 +-
 core/HalfLife2.h                       |  24 ++++-
 core/MenuManager.cpp                   |  10 +-
 core/MenuStyle_Radio.cpp               |   4 +-
 core/MenuStyle_Valve.cpp               |   6 +-
 core/NextMap.cpp                       |  16 +--
 core/NextMap.h                         |   7 +-
 core/PlayerManager.cpp                 |  57 ++++++-----
 core/UserMessagePBHelpers.h            |   7 +-
 core/UserMessages.cpp                  |   5 +-
 core/concmd_cleaner.cpp                |   5 +-
 core/logic/AMBuilder                   |   1 +
 core/{ => logic}/CDataPack.cpp         |  25 ++++-
 core/{ => logic}/CDataPack.h           |   3 +
 core/logic/common_logic.cpp            |   3 +
 core/logic/smn_datapacks.cpp           |  11 +--
 core/logic_bridge.cpp                  |  22 ++++-
 core/provider.h                        |   7 ++
 core/sm_stringutil.cpp                 |  33 +------
 core/sm_stringutil.h                   |  12 ---
 core/smn_console.cpp                   |   7 +-
 core/smn_entities.cpp                  |   4 +-
 core/smn_keyvalues.cpp                 |   4 +-
 core/sourcemod.cpp                     |  34 ++-----
 core/sourcemod.h                       |   2 -
 plugins/include/entity_prop_stocks.inc |  43 ++++++++
 public/amtl                            |   2 +-
 38 files changed, 444 insertions(+), 415 deletions(-)
 rename core/{ => logic}/CDataPack.cpp (89%)
 rename core/{ => logic}/CDataPack.h (94%)

The only file that actually changed since my last pull was the public/amtl change.

@powerlord That is normal for git to list what changes were merged in like that, but for prompting a commit message, that usually means there was a merge conflict

@WildCard65 The "conflict" was because someone rewrote history

When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.