Currently amxmodx doesn't reload modules that use metamod, so MODULE_RELOAD_ON_MAP_CHANGE being defined or not doesn't make any difference.
Even though this commit currently doesn't change any behavior, amxmodx might in the future support reloading modules that use metamod, and all these modules in their current state either fail completely because of erroneous cleanup, or are untested (and most likely leak stuff).
Furthermore, these changes make it clear that these modules are in fact not being reloaded.
* clang 4.0: fix ordered comparison between pointer and zero
* clang 4.0: fix taking address of packed member
Maybe someday someone will properly fix it
* clang 3.9: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior
Someday proper fix?
* Add ReHLDS API files and its dependencies
Note: This has been stolen from ReAPI AMXX module and modified/adjusted to match AMXX existing includes and to provide as less dependencies as possible as well
* Add the necessary files to get ReHLDS interface
* Split SV_DropClient into pre/post code
* Init ReHLDS API and add SV_DropClient hook
* Add Cvar_DirectSet hook and adjust code with helpers
Note: we don't need to split code here. This is pretty much the naive and straight way, but fairly enough for our case. If it happens we got a lot more hooks, we may consider to use some class to manage better the things.
* Move platform and interface stuff in their own files in public directory
* Make sure to init cvar stuff after ReHLDS
* Add ReGameDLL API files and its dependencies in cstrike module
* Init ReHLDS in cstrike module and adjust code
Note: About cs_uset_set_model(). ReHLDS API doesn't offer a way to know directly the precached models, so instead of looping through all the ressources, the models list is saved one time at map change into a hashmap.
* Init ReGameDLL and adjust code
* Fix linux compilation
* Init ReGameDLL in fakemeta module and adjust code
* Rename /reapi directory to /resdk to avoid confusion
* Retrieve gamerules pointer through InstallGameRules in fakemeta module
* Retrieve gamerules pointer through InstallGameRules in cstrike module
Note: actually gamerules is not used if regamedll is enabled, but it could be used in future natives.
* Fix a typo when ReGameDLL is not enabled
* Fix missing interface check for ReHLDS.
I'm pretty sure I was checking at the very first since I worked first on vanilla version of engine, looks like change has been lost.
- The logic around CS_OnBuy forward has been simplified. Since there is no way to have a consistent way to hook/block for all items, the new logic is to have as less as possible code, especially in blocking mode where we want to avoid to do extra stuffs (e.g blocking sound, event, etc).
* All guns + shield -> CanBuyThis()
* Nvgs and Fefuser only -> CanPlayerBuy()
* The others items -> GiveNamedItem() + AddAccount()
* Ammos -> -> BuyGunAmmo() + GiveNamedItem() + AddAccount()
- Fixed missing buyzone check when alias from console are used (CS_OnBUy* were incorrectly fired).
- Fixed an infinite loop when buying of ammos are blocked. Sorted by hooking BuyGunAmmo().
- Fixed blocking mode for some items. Some game behaviors were not blocked (e.g. weapon drop).
- Fixed forwards being triggered even though errors were found. Detours are now a destroyed and associated variables resetted when necessary. Toggling forwards state is now based on detours state.
- Moved things in its own functions (game functions to execute, class members retrieval)
- Renamed CommandAliases -> ItemInfos (more generic)
This is actually not possible to have a proper system to allow this.
This is two majors problems:
- The item price text can't be changed, whatever old and VGUI menu (it's either harcoded in config file or in client binary)
- Once you open VGUI menu, to know if user has enough money to select an item, client relies on the current HUD money value, this means, since we can't directly changed price, before opening the menu, money needs to be somehow faked and restored once closed. It's awful.
Overall it can't work properly, and at the end current forward doesn't make sense.
If an author wanted to have its own prices, the only only way would to force players to use old menu, then overwriting the whole buy menu, so you would be able to display what you want exactly.
When game gives ammos, it loops until the max amount is reached, but it sill calls GiveNamedItem and AddAcount, so forward should be called for each of these ones.
Code logic is simplified and more understandable.
