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.
* Fix pointer to string marshaling in ClientPrefs for x64
* Fix other cases where pointers were formatted with %x
* Fix warnings in ClientPrefs IsAuthIdConnected
* Initial attempt at compiling against tf2_sdk2013
* compilation fix for css
* Switch to AMTL platform arch defines
* Add CBasePlayer forward decl for dods and hl2dm as well
* Update hl2sdk-manifests
* Add dods to CI
* Actually include am-platform.h
---------
Co-authored-by: Kenzzer <kenzzer@users.noreply.github.com>
Co-authored-by: Nicholas Hastings <nshastings@gmail.com>
* 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>
* Add safetyhook, remove libudis86
Co-authored-by: bottiger1 <55270538+bottiger1@users.noreply.github.com>
* Add modified CDetour
Co-authored-by: bottiger1 <55270538+bottiger1@users.noreply.github.com>
* Add CDetour [Safetyhook] to build script
* Re-enable loader/core/corelogic, and fix new C++20 error
* Reenable all extensions (except dhooks)
* Make cstrike compile against new CDetour
* Remove unused variable in sdktools output?
* Make sdktools compile against new cdetour
* Downgrade to C++17
* remove auto
* fix compilation on linux
* Re-enable dhooks
* Re-authorise old compilers
* Fix invalid downgrade of std::optional
* readd libudis86 for dhooks only
---------
Co-authored-by: Kenzzer <kenzzer@users.noreply.github.com>
Co-authored-by: bottiger1 <55270538+bottiger1@users.noreply.github.com>
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.
* Add more functions to ArrayStack
* Make formatting consistent with other functions
* Don't remove the element for TopArray
* Replace 4 with sizeof(cell_t)
* Add support for other engine binaries in game configs (#1414).
* Add engine bin path for CRC bin lookup and filter out addons from GAMEBIN.
* MAX_PATH -> PLATFORM_MAX_PATH.
* Fix library lookup on Linux.
Before this, there was a bad assumption that, like on Windows, POSIX module
handle pointers were within the module's address space (and thus usable
with dladdr). That's not true!
Instead, to get a usable address on all platforms, we'll do a lookup of the
CreateInterface function that exists in all modules. This also has the
(arguable) benefit of further locking this implementation to modules owned
by the game.
To get a valid address inside the module now on both p
On NMRiH and possibly other games that use the Maphacks system,
entries that are modified using that system are rendered with tab
characters stripped out - see CNMRiHMapHackManager::GetEntDataString.
That results in there being no separators at all between keys and
values, as Maphacks receives the serialized string from Entity Lump
Manager.
This commit changes the key / value separator character to use
spaces instead.
This discovery upsets me greatly.
Fixes#1833.
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.
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
