feat(extra-natives/five): GET_ENTITY_HEALTH_FLOAT

[packfile]

Currently only the C# runtime has a way to obtain this (Entity.HealthFloat)

[Disquse]

We usually try to patternify offsets, but since it's CPhysical I guess there's a very little chance this offset would ever be changed. So LGTM, tested on all game builds.

[thorium-cfx]

We usually try to patternify offsets, but since it's CPhysical I guess there's a very little chance this offset would ever be changed. So LGTM, tested on all game builds.

@Disquse Any reason not to add this as a function (maybe with a field) to fwEntity? May it change then we can address it in there directly and patch all usage.

[Disquse]

I don't like how we are using rage::fwEntity when actually expecting it to be at least CDynamicEntity in our code. It won't work for other CEntity inherited classes such as CLightEntity, CBuilding, etc. This needs to be refactored in the future. Talking about this specific case, we definitely don't want to add CPhysical fields into rage::fwEntity making it even worse. We can add GetHealth method and use the offset but we will need to add extensible base type check (IsOfType) inside. However, even this solution will require a refactor in the future (i.e. moving this method into CPhysical class).

[gottfriedleibniz]

we will need to add extensible base type check (IsOfType) inside.

Should also decide whether this native should be allowed to write to any arbitrary entity/script-extension instead of using IsOfType, FromGUID<CPhysical>, or whatever (what happens now).

[packfile]

Should also decide whether this native should be allowed to write to any arbitrary entity/script-extension instead of using IsOfType, FromGUID<CPhysical>, or whatever.

I'll add an IsOfType check shortly, apologies. This code is mimicking the behaviour of the C# runtime however, so an issue lies there too? (Its using GET_ENTITY_ADDRESS without any additional checks for the type either)

[gottfriedleibniz]

so an issue lies there too?

Yes. That is one of its many issues.