In the current ongoing effort for sourcemod to fully support 64 bits, we are introducing "virtual address".
# Explanation
Because SourcePawn does not yet support a 64 bits-wide type it's been impossible for any plugins to hold addresses in regular 32-bits wide variable.
A first attempt at solving this issue was made in commit ce1a4dcac0 therein dubbed "PseudoAddress", however this turned out to be an unsatisfactory solution, as any 'high' address if offsetted could turn invalid (or outright be impossible to map).
This leaves us with three alternatives :
- New type
- Convert Address into a handle
- Virtual Address
A new type is the most destructive solution, as it entails breaking every single Address related method. While that solution is still not off the table, we're reserving it as the last attempt should this commit fail.
Converting into a handle type is a good compromise between a brand new type whilst also preserving the Address methods. However, this comes with two issues: the first being that you can no longer offset Address, the second is that we would require authors to free the handle type which will be very confusing. This will likely not be implemented.
# Virtual address
Under a reasonable assumption, we've noted that the average plugin is unlikely to play with more than 4 GB of memory; this shouldn't be too surprising as all valve games were once 32bits and therefore limited to 4GB. Assuming this stays mostly true and a plugin isn't interested with the mapped memory of lesser known modules (like soundlib or matlib), it is fair to assume plugins are unlikely to access more than 4GB of mapped memory. Working with this in mind, we map the memory the plugins are likely to access to our custom virtual address ranges (from 0 to 4Gb, the values of which can fit on 32bits variable). If any memory was missed and plugins were to try an access it later those ranges will be late-mapped to our virtual address ranges until we run out of them.
In order to use virtual addressing, whether on 32 bits or 64 bits. Plugins must now "#include <virtual_address>", as well as use the new SDKCall_VirtualAddress, SDKType_VirtualAddress, LoadAddressFromAddress & StoreAddressToAddress where it's appropriate to.
* Added columns from the SELECT clause that were missing from the GROUP BY clause on line 529 that was causing the query to fail.
* Increased query buffer size on line 513 from 512 to 544 to accomodate the extra characters needed.
* Add new IntHashMap and IntMap natives
This is a continuation of #579.
[HashMap] Adds new IntHashMap and IntMap natives.
This patch makes the following changes
* Refactors StringHashMap to a generic HashMap template
* Adds the IntHashMap class
* Adds new IntMap natives
* Adds IntMap tests to the tries test suite
[HashMap] Reverted rename of CharsAndLength
[HashMap] Use more descriptive template names
[HashMap] Removed old-style natives
[HashMap] Removed IntHash class
[HashMap] Reverted some search & replace errors
Co-authored-by: Geoffrey McRae <geoff@hostfission.com>
* Fix spelling mistake + include
* Fix tries test
* Update tests with clone + ContainsKey
---------
Co-authored-by: Geoffrey McRae <geoff@hostfission.com>
Co-authored-by: Nicholas Hastings <nshastings@gmail.com>
* Stop EntRefToEntIndex returning garbage if a bad parameter is passed
Seen multiple bad usage of this function that works only because whatever was passed in was returned as it wasnt an entity reference.
This code should have worked and would be expected to have returned something invalid but instead the the input was returned which allowed the code to work when really it is bad code.
See for one such case https://discordapp.com/channels/335290997317697536/335290997317697536/736518488314871868
* Update documentation of EntRefToEntIndex
Added the error text saying what shall be returned when a invalid parameter is passed.
* Validate entity index instead of just returning INVALID_EHANDLE_INDEX
Not sure if it needs this much validation but this just mirrors how IsValidEntity works, so the entity index returned should be valid else INVALID_EHANDLE_INDEX is returned.
* EntRefToEntIndex improve doc comments to better represent functionality
---------
Co-authored-by: Kyle Sanderson <kyle.leet@gmail.com>
* Add void prototype to NativeCall typeset
`void` prototype can be used for simple natives which don't return any value.
This is done to silence compiler warnings 209 (`function has explicit 'int' tag but does not return a value`) and 242 (`function "NativeCallback" should return an explicit value`).
* Make MenuHandler into typeset and add void prototype
This can be used for basic menu handlers that don't return modified item styles and don't redraw menu items.
* Update basetriggers.sp for Dystopia compatibility
Dystopia has a built-in command called nextmap which breaks due to the Sourcemod nextmap command. This modification is intended to restore Dystopia compatibility.
* Update basetriggers.sp
* Update basetriggers.sp
* Update basetriggers.sp
* Update basetriggers.sp
This brings in a few breaking changes.
One, INVALID_FUNCTION is now 0 instead of -1. This is long overdue.
Plugins should transparently work except in two cases:
1. Third-party extensions that have a hardcoded test for -1 will no
longer work. A new API has been provided for this,
GetFunctionByIdOrNull.
2. If a plugin "framework" uses INVALID_FUNCTION anywhere in its
exported API, then all plugins using that framework need to be
recompiled together, so they agree on the value of
INVALID_FUNCTION.
Hopefully the damage here is minimal. The core plugin version has been
bumped to 7 to try and limit conflicts.
Second, braceless functions are no longer supported. There wasn't really
any way around this and it's better to bite the bullet now. This affects
source compatibility, but not binary compatibility.
Third, the "using" keyword is no longer implemented. SourceMod now has a
Handle methodmap again. Plugins compiled against this new methodmap will
require a "Handle.~Handle" native, which 1.12 now provides.
* Ignore chat triggers for interactive ban reason
If the admin types a chat trigger for a command while BaseBans is
waiting for them to type a ban reason, don't treat that message as the
ban reason.
This fixes a problem where the admin decides to cancel their ban with
"!abortban", "/abortban" etc, but ends up accidentally banning the
player with the ban reason "!abortban" (or by attempting to access any
other command via a chat trigger before typing the ban reason).
* Optimize
Check if we're actually waiting for chat reason before calling the native
* Add more functions to ArrayStack
* Make formatting consistent with other functions
* Don't remove the element for TopArray
* Replace 4 with sizeof(cell_t)
* Update SDKCall return information
This adds the information that if the return value is a string then SDKCall will return the number of bytes written.
* Update description
* Add info if the string is null
The current ``KvSavePosition`` definition does not reflect the behaviour seen in [core/smn_keyvalues.cpp#L973-L981](404e96ad45/core/smn_keyvalues.cpp (L973-L981)). This can cause problems if some procedure on sp expects ``KvSavePosition`` to always add one node to the stack, no matter if there is no higher node.
Co-authored-by: peace-maker <peace-maker@wcfan.de>
