The DB API requires FetchRow to be called before accessing any values
from a row, but the SQLite driver did not enforce that requirement and
alowed accessing the first row immediately. A plugin developer hit this
when developing against SQLite locally but using MySQL in production,
where the API misuse threw an error as expected.
Resolves#1691
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.
`SOURCE_ENGINE_MOCK` is part of the MM:S API and only available in 1.12
which is the dev branch of MM:S. We can build the mock SM build without
it anyway, but this is still a little gross as it is just missing loader
support which could be confusing.
This also changes AMBuildScript to first look for a checkout of MM:S
1.11 which has been the stable branch for a while, 1.10 is still allowed
as a fallback as that seems to still build without issue.
`OnEntitySpawned` is 1.11 only, so this is fine given our API stability guarantees.
Unfortunately the forward name clashes with quite a few plugins using the same name for their SDKHook callback. Normally we'd just put up with this but there are difficult to solve binary compatibility issues where those plugins will get the callback double-called, and there is a separate issue where the forward isn't called for all entity spawns (unlike the SDKHook), so most plugins can't switch to the forward anyway.
Resolves#1558.
This reverts commit 7bab9cc344.
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
When a custom TraceRay filter / EnumerateEntities enumerator callback
throws an exception we currently continue execution and then return
execution to the calling code as if there were no problems. This
currently causes a heap tracking issue in SourcePawn, but even ignoring
that it is likely the wrong behaviour and differs from our other
synchronous callbacks.
This change causes the exception to be caught, immediately terminates
the trace / enumeration, and propagates the exception state back to the
calling plugin correctly. The implementation here is based on how
SortCustom1D handles exceptions.
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
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
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
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.
Newer Source engine versions now use a dynamically allocated buffer for
the map entity lump, and some maps have over 16MB of entity data - far
larger than our 2MB limit.
There is no sane way we can currently handle this, so just remove the
functionality from the forward until a more comprehensive API can be
designed.
Fixes#1470
This fixes a number of parsing issues and compiler crashes, deprecates enum multipliers, fixes relative include paths on Windows, adds a `static_assert` statement for compile-time checks, and introduces new Linux profiling support.
The relative include paths change will probably break some non-portable projects that relied on the old broken behaviour, but the fix is straightforward. The `#include` directive is now always relative to the file where it is used, whereas on Windows it was previously relative to the initial input file passed to the compiler if `/` was used instead of `\` in include paths.
https://crash.limetech.org/stats/dbi.mysql.ext.%25/my_real_readhttps://crash.limetech.org/stats/dbi.mysql.ext.%25/net_real_write
Both of these are caused by the VIO ptr ending up as null in the middle of reading/writing to a connection - I can't find any indication of a fix for this made to MySQL, so don't think it is a bug fix we're missing, but there are some musings around the internet that it could be caused by improper thread-safety initialisation.
`my_init` (what we had here) is called internally by `mysql_library_init` but I think would have still led to an automatic `mysql_library_init` call the first time `mysql_init` was called (which we can do on a thread in case of threaded connections), which is exactly the thread-safety issue called out by the MySQL docs, so hopefully doing things properly here will help.
PR #705 made some changes for 64-bit support that required callers to
provide a buffer for object storage, but only added the required code to
the non-virtual call builder, not the virtual call builder.
Copy it over to CreateValveVCall so that ValveParamToBinParam stops
writing to a null pointer.
Fixes#1059 (Hopefully.)
The cause of the infamous "Index error writing string table baseline"
error appears to be a timing issue between the engine's network message
processing, the stringtable encoding, and command processing when adding
stringtable entries in OnConfigsExecuted.
When the first client connects the map is re-loaded which causes a full
refresh, the game's stringtable entries are added at tick 65, the client
connection is registered at tick 66, and stringtable entries added in
OnConfigsExecuted are registered as being added in tick 67. The engine
later calls WriteBaselines with the client's signon tick, and neglects
to encode the SM added entries as it considers them from the future.
To avoid this, always pass INT_MAX as the current tick when encoding
the baseline, so all stringtable entries are included regardless of when
they were added. Tested on both Windows and Linux.
This has been another constant source of confusion since the C99 ones were added to the strftime documentation we link.
It'd be nice to have a consistent implementation inside SM in the future.
`SDKCall` has existing semantics that a `-1` retval indicates null, so use that and writes an empty string to the buffer.
Consumers can tell the difference between `""` and `NULL` by checking if the return value is `0` or `-1`.
These two base plugins are using the MAPLIST_FLAG_NO_DEFAULT when they shouldn't, which causes much user (and SM developer) confusion as it is completely counter to the documentation.
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).
Special characters only, minus a couple of potentially-problematic characters.
Technically this is a breaking change - but anyone using multi-char triggers is probably crazy anyway and has been driven off by now.
Erin