* Initial PVKII branch support
* Change PVKII code to 23, DOTA uses 22 in MM
* Bunch more SE_PVKII preprocessor that was missed
* Add some missing SOURCE_ENGINE_PVKII cases
* Update PVKII FireOutput signature for Linux
* Update checkout-deps with 'pvkii'
* Fix FireOutput signature for PVKII, accidentally used one from newer build
* Change PVKII code to 10, and bump others by 1
* Only check against SE_SDK2013 here, like Metamod
* More SE_PVKII preprocessor cleanup
* Update dhooks.inc documentation for consistency
- Modifies whitespace (change tabs to spaces for non initial indents, fix alignments, create consistency with rest of SM docs)
- Change `/*` to `/**` for consistency and to indicate comment doc
- Removes incorrect `@noreturn` doc
* Split long comments across multiple lines
* Remove `@noreturn` in IGameConfigs.h
* Remove `@noreturn` from IGameHelpers.h
* Remove `@noreturn` from asm.c
* Add `@noreturn` to ThrowError
* Add `@noreturn` and `@error` to ThrowNativeError
This imports the brand new SourcePawn compiler. The new compiler is much
faster to compile and generates significantly improved code around
array generation and array access.
There are a number of compatibility changes in the new compiler. Most of
these are due to improved type checking and error detection. The full
list of notes can be found here:
https://github.com/alliedmodders/sourcepawn/blob/master/docs/upgrading-1.11.md
Additionally, .smx files generated by the new compiler will NOT load on
earlier versions of SourceMod, including earlier versions of 1.11. Old
plugins will continue to load as normal.
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
On Linux if a detour crossed a page boundary we would only change the
memory protection of the first page (as we were aligning the address as
required, but not taking into account the length).
I don't have an easy way to test this but it looks correct. `addr + len`
doesn't appear to need to be aligned though, so another option could be
to use `(addr - startPage) + length` as len.
Also fixed a non-zero offset being passed into CDetour's ApplyPatch
function - this is never done internally anywhere, but it doesn't hurt
to fix it.
Fixes#984
This patch removes almost all of the existing platform-specific
ThreadSupport code, as well as code derived from it. It is now
implemented on top of C++11 threads and is much simpler.
This is the first inclusion of STL in SourceMod. Mac and Windows are
allowed to dynamically link to their respective implementations. On
Linux, libstdc++ is statically linked, except in the cases where it was
already dynamically linked (csgo, blade).
IEventSignal has been retained because sourcemod-curl-extension relies
on it. As written, it is impossible to use as a condition variable,
because the caller does not have access to the underlying mutex. There
is no way to make this API safe or non-racy, so extensions relying on
it should switch to C++11 threads.
ThreadWorker is now pared down and does not interact or inherit from
BaseWorker in any way. Basic functionality has been tested. Since it is
not used anywhere in SourceMod, or seemingly in any repository on
GitHub, it's unclear whether it should even exist. But it has been
tested in this patch.
This change bumps the minimum macOS version to OS X 10.7, and the
minimum C++ standard level to C++14.
In #705 SourceMod received support for x64 binaries. The `IBinTools` interface was updated to call functions in 64bit binaries. The `PassInfo` struct's size was increased and the `Create(V)Call()` functions signatures changed, thus making the interface incompatible for consumers which were compiled against an earlier version.
`SMInterface::IsVersionCompatible` wasn't adjusted to that fact, so extensions compiled against pre SM 1.10 could request an `IBinTools` interface pointer, but crash when they try to use it.
This change makes requests to older interface versions invalid, thus letting `RequestInterface` return `NULL` for older extensions. It doesn't fix the backwards incompatibility, but at least makes the problem more blatant, so extensions can handle it themselves.
This doesn't break any extensions NOT using IDataPack, and we do not know of any that are.
* The extension storage utility of this interface has been broken for the last 9 months, with ISourceMod::CreateDataPack being disabled.
* The plugin interop utility of this interface (its stated purpose) has been broken for the last 11+ years, with ISourceMod::GetDataPackHandleType being disabled.
I imagine it only survived the first cleanup 11 years ago because CSS:DM was using it internally, which it has now been migrated away from.
Compiled all the included extensions without changes (API compat), and loaded extensions build pre-change without issue (ABI compat).
* Make mac/win lookups lowercase'd
* Revert #709 & 81042cc
* Adjust HashPolicy implementation across sourcemod
Basically, in order to implement our own (actual) hash policy in
`PluginSys.h`, we needed to remove the blanket implementation of `hash`
that was used before. Now, each policy must implement `hash` along with
`matches` in order to be used with `NameHashSet`. While this does force
us to change every implementation of policies across the entirety of
sourcemod, it allows core to use flexible implementations of `hash`.
* Remove logic duplication
* Improve lowercase checks
