* Add CommandIterator.ConVarFlags property
Allow to access the convar flags `FCVAR_*` value from the iterator.
The CommandIterator.Flags property should have been called `AdminFlags`,
but it's too late to change that now.
* Switch admin help menu to use CommandIterator.ConVarFlags
No need to lookup the convar again.
* Deprecate CommandIterator.Flags
Rename it to .AdminFlags now that we have two kinds of flags exposed
on the iterator.
The extended gameconfig format reads the master gameconf file twice;
once each for the base engine and actual engine. The file list
isn't checked for duplicates, so 'common.games.txt' is loaded in
twice, resulting in any 'common' file values potentially overriding
values listed under '#default' in other files due to
bShouldBeReadingDefault. This happens in the case when matching
game versions by CRC (such as public game branches).
Required for #1857.
* 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
This change ensures that the iterator values used by `std::distance`
is correct. Having the emplace within leads to the possibility of
`m_Entities.begin()` being invalidated due to reallocations.
* Add a PluginIterator methodmap
* Follow convention
* Update sourcemod.inc
* Turn method ReadPlugin into property Plugin
* Requested change
* Update sourcemod.inc
* Curse you VSC
* Follow behavior of other iterators instead of the natives
* Fix a stray space
* Implement a hacked CPluginIterator
* Oops
Copy paste go brr
* Revert a change made before the custom impl
FindSendPropOffs is deprecated and FindSendPropInfo behaves correctly
here, but there are still a lot of old plugins using FindSendPropOffs.
One of the SendPropArray props broken by the changes here is
m_hViewModel which there are known plugins in the wild accessing.
Always perform signature searches on an unaltered copy of the binary. This avoids signature mismatches if the same function is detoured twice and thus the first bytes of the function were replaced by the detour.
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.
This bumps the handle bits to 20 and reduces the serial/cookie bits to
12. A warning is emitted if a single owner creates more than 100k
handles.
Tested on mock srcds with sm_dump_handles.
This rounds out the work started in #1548 to complete support for
reading the older SendPropArray type array netprops, along with bringing
SDKTools' GameRule netprop code in sync with core to add string array
support.
There aren't many SendPropArray type props around but this opens up a
few interesting opportunities for plugin developers, particularly in
L4D2 with manipulation of the EMS HUD.
Tested reading the `m_vCPPositions` array in TF2, and reading/writing
the `m_szScriptedHUDStringSet` EMS HUD netprop in L4D2. Closes#1386.
In #545 we started automatically fixing up invalid UTF8 characters
caused by truncated names from Steam, but since the dawn of time CPlayer
has preferred directly returning the engine's name pointer if we have
once available, so our corrected name is almost never used.
Lightly tested in CS:GO and TF2 with no ill effects. Fixes#1315
WriteCellArray and WriteFloatArray were allocating N+1 slots, but due to
a copy-paste error were writing N+2 slots. Much later in the process the
CRT would catch this and cause a crash - this was pretty painful to
debug but thankfully running SRCDS in CRT debug mode caught it much
sooner in CDataPack::RemoveItem.
This has been asked for and debated in some form since Valve introduced
hibernation into the Source engine. The changes here are based on quite
a deep dive into the engine's frame/think logic (mainly in CS:GO which
has "legacy" hibernation and TF2 which has modern "frameless" ticking)
and all seem to be sane.
I think I've managed to maintain all the oddities around time keeping,
and the simulated bool (even though we don't really use it for anything)
should have a sane value. There is a slight behaviour change for
anything needing exact timings as we're now run earlier in the frame
before gpGlobals are updated, this should generally be fine but it might
affect some plugins such as bhop timers that are trying to be extremely
precise (often more precise than the underlying data they're using).
We'll probably want to add a native for plugins to detect if the server
is not completely simulating so they can opt out of work, but I think
defaulting to having things work like this makes more sense than adding
a 2nd set of per-frame forwards and natives (#540), and this makes
timers and any extension callbacks work automatically.
Some games have implemented CHudMenu::SelectMenuItem to close the menu
even if an invalid slot has been selected, which causes us a problem as
we'll never get any notification from the client and we'll keep the menu
alive on our end indefinitely. For these games, pretend that every slot
is valid for selection so we're guaranteed to get a menuselect command.
We don't want to do this for every game as the common SelectMenuItem
implementation ignores invalid selections and keeps the menu open, which
is a much nicer user experience.
Fixes#1385
Some engines are very sensitive to exactly when in a frame vprof is
enabled, the vprof commands use a special command registration method
to defer their execution to the start of the next frame. Instead of
starting/stopping vprof directly ourselves, use the built-in commands
to ensure that the timing is correct and the server does not crash.
Fixes#1162
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
