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.
Asher Baker