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