S&W 329 Magnum over Claire's SLS 60

That would depend on how it's coded and how the game's routines function.

We know that things like ammo count, damage/health, etc. are considered variable data, and are thus loaded into active memory so the game can actively track and shuffle around the objects that are actively being modified.

However, static values such as the maximum amount of ammo, damage of a gun, maximum health of the player, and so on could be handled in two different ways:

1. The values could also be loaded and stored in memory, and every time you fire a gun, take a hit, etc. the routine that processes that simply references that value's memory object to do math against, thus updating the variable value also stored in memory.  This would technically be faster because reading a value from a file means the code would have to parse the file every time to obtain the static max values to work against, but it means more data stored in memory and thus more consumed memory.

2. The code that handles these variable bits references the values stored in the object properties for the item and then stores the results in memory, while the static values are never kept in memory.  This would technically be slower because the code is referencing a file it has to parse for the value (although at this point in technology, the difference would be trivial comparatively), but it would mean less was stored in active memory.

With current trainers, they are able to basically read the memory values called at the system level and substitute a return value, or block a call to write a different value into that memory space so the actual value never changes. The call sends the command to write a value, the intercepting program just changes the write in such a way that the game's code thinks it's written successfully but the value it's acting against never changes.

In order to change the min/max values, though, you'd have to find a way to hijack the routines that return those static properties from where they're stored in the game's actual object code, and return a different value. In other words, when the guy reading the cook book turns to a page to look at a list of ingredients for what he's cooking, the page he reads is actually from another book and not the real page in his cookbook.   That would take more code and is much more tricky than just futzing around with objects in memory.  You would need to first be able to look at the active calls being done by the game's process and find the one which is pulling in the data about the object, then you'd have to have a way to intercept and redirect that call so it read data from a different source. Plus, you'd need to find a hook in the game itself so that you can actually interact with its functioning process as it reads and runs through its code.

That's why mods to change a model or a skin or something are actual file replacements: you're not injecting code into the process or hijacking the code of the running process, you're actively replacing the files its loading data from.

And, as mentioned by the various people on this forum, while we can modify objects that are in the DLC because we can unpack them into raw files instead of a bundle, no one has yet been able to do that with the main game's asset bundle.

The only way it might be possible to do something like this would be through somehow reverse engineering the entire codebase of how the DLC is written and recognized by the main game, and then create third-party DLC files that the game would recognize and access/load code from. And then, it would mean we could *add* things into the game, but not actively change the properties of objects already there.