SM internally maintained both a case-sensitive and a case-insensitive
lookup method for commands, where the case-sensitive hashmap was used as
a fast path, and case-insensitive iteration over a list used as the slow
path if a command was not found in the hashmap. But only command
dispatch handling used this dual path approach, chat triggers for
example only did a loopup in the hashmap.
Over the years Valve has made more and more of the command dispatch
logic case-insensitive to the point where all console commands are now
case-insensitive, so maintaining case sensitivity when using chat
triggers does not make a lot of sense. There are somewhat popular
plugins that attempt to "correct" this behaviour - but at least one is
having issues after the previous case-sensitivity fixes for commands -
see #1480.
We still have to keep the list around for the sorted help use case and
command iteration, but this PR changes the hashmap to use a
case-insensitive hashing policy (as previously done for convars, and
more recently for game command lookup) and changes all by-name lookup to
exclusively use the hashmap (as there is no need to fall back to the
list any more).
Tested a bunch in TF2, I don't know of any games that still have a
case-sensitive command dispatch pipeline to test. I think the worst case
would be that we'd accept a chat command in the "wrong" case then fail
to execute the underlying command. If that turns out to be an issue in
practice, we should be able to fix it easily enough by replacing the
command name in the buffer with the correct casing of the command we
looked up.
Also fixed a couple of very minor Lookup vs. Key issues in NameHashSet
(noted in #1529) that were being masked due to CharsAndLength's
converting constructor. I tried to make the constructor explicit to
avoid this happening in the future but HashTable's add function relies
on being able to do an implicit conversion so that wasn't possible. We
might want to just rely on the implicit conversion up here as well, but
it doesn't really matter either way.
Fixes#1480, #1529
Similar to the recent work for commands, track and expose the creating
plugin for convars. The first plugin to register a given cvar becomes
the owner until that plugin is unloaded. If a plugin attempts to
register a convar that was already registered and the originally
registering plugin has been unloaded, that plugin becomes the owner.
This isn't quite as nice as the way commands shift "ownership" as
plugins are unloaded, but we don't have a sane data structure currently
to implement that, and it seemed like a lot of unnecessary work as there
shouldn't really be multiple plugins with conflicting cvars.
Closes#1492
When a netprop is an array the name resolves to the outer DataTable
array, which we then need to recurse into to find the actual prop.
For string_t props we need their sendprop info to call the proxy
function to get their real storage address, but when accessing an array
we were trying to read the prop off the outer DataTable prop, rather
than the real string_t prop. Fix this by using the pProp variable that
FIND_PROP_SEND helpfully provides for us.
Tested by writing/reading the `m_szCrosshairCodes` array, which got
changed to a string_t prop sometime since #1372.
Fixes#1484
When variant support was added for props, the validation checks in the
float related functions weren't updated to allow them.
Tested with the plugin from the forum thread with a spawned
`math_counter`.
Fixes#1501
The change in behaviour to the OnLevelInit forward params isn't obvious
when compiling a plugin, deprecate it to make it a lot more obvious that
something has changed.
Some plugins rely just on the timing of OnLevelInit rather than doing
anything with the entity lump, for these plugins offer a new OnMapInit
forward that is implemented in core rather than sdkhooks. If / when we
offer a new entity lump manipulation API in the future this'll be the
forward where it can be used to make changes.
* Start using Github Actions
Build on windows and linux. Cannot build for macos,
since the builders only support xcode 10+ which dropped
x86 support.
* Build sourcepawn tooling as separate package
Upload build artifacts containing only spcomp and the includes.
This adds a new `--scripting-only` flag to configure.py which skips
everything and goes straight to building spcomp and packaging the
include folder with it.
* Only run the workflows for the master branch
* Split common operations into PackageHelpers file
Don't duplicate the code for packaging releases for the tooling-only packages. Instead use a common `PackageHelpers` class which provides the functionality common to both packages.
This replaces the explicit list of files to package with a directory scan, so we don't have to list them all.
The pgsql sql-init-scripts were missing from the release package before, so they were added here as well. Three scripts from the testsuite were missing from the explicit list (mapdisplayname, floats, findmap), so they're now included.
* Fix Python 2 compatibility
os.scandir is Python 3 only.
* Execute ConVarQueryFinished if client disconnects
So people passing handles to the extra data can close them, adds a new return value to check if this happened
* Update based on suggestion
Co-authored-by: Asher Baker <asherkin@limetech.io>
* Update based on notes
* Normalize
* Pass along cookie handle instead of invalid
Co-authored-by: Asher Baker <asherkin@limetech.io>
* Harden plugin loading path requirements
Restrict loading of plugins to the `sourcemod/plugins` folder and require the `.smx` file extension.
Symlinks inside the `plugins` folder are fine.
This behavior was abused as part of justCTF 2020 in the PainterHell challenge by cypis. Thank you!
* Restrict extension loading to extensions folder
* Add NULL file extension check in LoadExtension
hi @KyleS
This is a pretty big diff because SourceMod had lots of multi-arch
workarounds that can now go away. I've also changed 'x64' to 'x86_64' in
many places since this is how AMBuild normalizes it, and it's far too
late to pick the shorter string, so we might as well suck it up.
The --target-archs parameter has been replaced with --targets. It works
the same way.
The default behavior for SDK inclusion is now "present" instead of
"all" since this lowers the burden of storing many SDKs. Official builds
will still be made with --sdks=all.
* Add basic Insurgency support on Windows x64
This allows SourceMod to load on x64 Insurgency. There are still a lot of variable truncation warnings that have to be dealt with.
* Fix 32bit builds
* Compile MySQL extension as well
The hack for __iob_func being removed from the core runtime, but required by the old mysql we're building against can be simplified a lot due to the `_ReturnAddress` intrinsic available since MSVC 2015.
* Don't include the offset we want to extract in the signature
