feat(extra-natives/five): current amount and maximum pool size

[nikez]

Goal of this PR

To allow you to see the current pool size and it's maximum size.
...

How is this PR achieving the goal

By exposing the current amount and the maximum pool size.
...

This PR applies to the following area(s)

FiveM, Natives
...

Successfully tested on

Game builds: 2372

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

[thorium-cfx]

Hello Nikez, could you add a bit more context on why you want to be able to see it? Thank you

[nikez]

Hi,

Sure, we had an instance where one of our scripts caused the CObject pool to overflow, effectively crashing people when a networked cloning event came in, as there's a nullptr check that will assert/crash you. So this is only for people to add a safeguard. So to avoid this in the future, we'll be using this for our "synced objects" (local objects create on every client rather than a networked object).

In general it's also a pretty good metric to track.

[z3t4s]

To elaborate on the pool overflow for documentation purposes:

Pool overflowing for CObject is only a problem when it comes to network replication. On 2372 CNetObjObject::vft_0x30 will invoke the internal object creation function at 0x14114CD2E and assert if allocation was not possible.
This seems to be intentional behaviour to ensure integrity between remote sessions, as failure to create an object would cause desync.
All other calls to the internal object creation (gameplay, script engine) just gracefully fail.

Crash reproduction is easy. Create 3300 objects on the client, trigger network replication on any other CObject inheriting entity

[Disquse]

This PR also needs to be tested in RedM. @nikez said he doesn't have anything for the RedM workflow so I will test it myself soon.

[gottfriedleibniz]

local objects create on every client rather than a networked object

There seems to be a common use-case with player generated dynamic interiors, sets, whatever, causing the # of objects to sky-rocket (or players with 3000 weapons attached to their Ped). Being able to capture statistics like this, e.g., GET_USED_CREATOR_BUDGET, seems to be a one desired effect of this PR.

This seems to be intentional behaviour to ensure integrity between remote sessions, as failure to create an object would cause desync.

Do you think this failure is possible with the other *CreationDataNode code paths (e.g., Ped, Vehicle, Pickup, etc)?

So this is only for people to add a safeguard.

Presumably for safety any use of this native would have to subtract whatever the value of the CNetObjObject pool is - and this seems like to be really fighting against game internals. This part is definitely something we should attempt to handle more gracefully.

[z3t4s]

Do you think this failure is possible with the other *CreationDataNode code paths (e.g., Ped, Vehicle, Pickup, etc)?

Good point. I just checked and yes it is:

2372 addresses
CVehicleCreationDataNode ->0x141157A0B
CPedCreationDataNode -> 0x14114DC77
CObjectCreationDataNode -> 14114CD44
CPlayerCreationDataNode -> 0x141152198
CPickupCreationDataNode -> no assert at 0x141151215, but inside the internal pickup creation function at 0x1406A978C. That only triggers if a7 is true, which isn't the case here

For CVehicleCreationDataNode and CPedCreationDataNode there is some additional code that I have not completely identified yet. It does look like some kind of cache logic for recently deleted entities so it doesn't have to allocate.
But if you overflow, the issue would still happen