Adds precaching of weapons in loaded zones because normal precache doesn't work for custom weapons. Reload mod after level is loaded. #19
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "(deleted):master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Weapons can currently only be loaded by replacing a base game weapon file bc precacheitem() doesn't work for custom weapons. This is the only way I have been able to get custom weapons to load with a new weapon file.
Adds precaching of weapons in loaded zones because normal precache doesn't work for custom weapons.to Adds precaching of weapons in loaded zones because normal precache doesn't work for custom weapons. Reload mod after level is loaded.Mhh, I see. I need to consult with others to see if it's possible to avoid caching duplicates. As I understand this code could possibly run twice on weapons already loaded by the level.
Can you send me a mod where I can test custom weapons?
(on discord, the email i have attached to this account is not monitored often)
I take this code is from h1-mod (Ofc h1-mod did not author this code and I am aware of another client where this was from)
However, you made a correction I think.
It's easy to spot because we are requesting weapons to be enumerated however in this diff file from this PR you added the correct struct which is WeaponCompleteDef, right?:
I reckon h1's version is incorrect. The definition you added to structs.hpp is not canon but I can easily fix that.
I'm perplexed about sorting the weapons array using weapDef->szOverlayName vs the internal name
internal name would be first in your union vs name which is the second. Do you know which one should be used and how did you find that out?
Looking at IW5 where I can make sense of the assembly better it seems the internal name is actually used rather than the public name. I'll await on your response to confirm. It's not safe to take code from H1 I'm afraid without double-checking everything.
Btw also do we know why precacheitem does not work on custom weapons? I knew it did on iw5 but maybe not! It's disabled on piw5 because weapons are cached like this from code but I have done 0 modifications to iw5mod and they also seem to work lol.
IW6 is definitely different and has weird net strings that define weapons for each level eh, I'm just asking out of curiosity. I know this is probably required to get custom weapons to work if h1 also did it but ehh maybe we should look into further than they did and document why this patch is necessary
Hello, I will close this as this was completed via
3d77a21f3d(Co-Authored by you)Final thoughts:
The IW5 method will take priority as there is no need to copy H1. I finally made sense of their code and understood there was a union there the whole time in the struct (No idea why tho) 🤦
The internal name is indeed used for sorting
In conclusion, my code is functionally the same. I also tried a completely different stub and another approach and they did not work.
I'll settle for the code in our commit as I've tested it and I can confirm it is almost an entire canonical reverse of IW5's code.
Minus the qsort as I kept std::sort because it does the same.
@ -152,1 +152,4 @@utils::hook::call(0x1405E7113, db_load_x_assets_stub); // R_LoadGraphicsAssets According to myself but I don't remember where I got it from//Reload mod.ff after map is loadedutils::hook::call(0x140320ED1, db_load_x_assets_stub); // DB_LoadLevelXAssetsBTW I left this part out completely because this is subject to further investigation.
The reason is that reloading a mod after a map (or before) has caused issues on another clients.
Mainly on pluto, on piw5 the mod.ff is always loaded twice in a similar manner (need to double check) and is known to kill to stock maps for some reason.
Pull request closed