fix(core/rdr3): AMV hardcoded limit causing blinking

[alexguirre]

Goal of this PR

There is a global bitset used to store the enabled/disabled state of every AMV. This bitset has a hardcoded size of 6016 entries, once there are more AMVs than the bitset size, it starts reading/writing out-of-bounds. This causes the AMVs to start blinking and can potentially crash.

How is this PR achieving the goal

This patch re-allocates that bitset with enough space to fit the capacity of all the AMV pools. The functions that access it are patched to point to the new buffer and use the new size constants.

This PR applies to the following area(s)

RedM

Successfully tested on

Game builds: 1491, 1436, 1355, 1311

Platforms: Windows

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

Fixes issues

Fixes #2821.

[alexguirre]

I simplified the patch by re-allocating the bitset buffer instead, should be less fragile than the stubs. Though now it hardcodes the AMV pool sizes, I didn't find any existing function to read the sizes from gameconfig and GetPoolBase is not initialized at that point. Let me know if there is a better way.

[Ktos93]

Patch tested, verified, and working as expected. All tests passed, and the build is successful. Ready to merge.

[prikolium-cfx]

Currently we don't allow to increase these 3 pools and such way is safe, but what should we do in future when anybody need to extend one of these pools?

And what will happen if we define bigger value here than real pool size? Probably we can set here maximum possible value, for example double pool size, then it's fine.

[alexguirre]

Currently we don't allow to increase these 3 pools and such way is safe, but what should we do in future when anybody need to extend one of these pools?

In case of enabling increase_pool_size with these pools, looking up the increase values in fx::PoolSizeManager::GetIncreaseRequest() and adding them to these pool size constants would be enough. The increase request map is already initialized when this hook function runs, so should be straightforward to add.

And what will happen if we define bigger value here than real pool size? Probably we can set here maximum possible value, for example double pool size, then it's fine.

Nothing, just a bit of unused memory.