feat(gamestate/server): add GET_ENTITY_TYPE_RAW native

[tens0rfl0w]

Goal of this PR

While working on #2940 it was mentioned that there is currently no way to get the specific entity type on the server-side.
This implements a new custom (server) native to get the specific NetObjEntity type of a networked entity.

How is this PR achieving the goal

Reading entity->type and returning the specific type as an int on calling GET_ENTITY_TYPE_RAW.

This PR applies to the following area(s)

FiveM, RedM, Natives, Server

Successfully tested on

Game builds: 3258

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

/

[AvarianKnight]

GET_ENTITY_TYPE_RAW might be a better name here, it matches other natives

[tens0rfl0w]

I agree that _RAW fits better here, I also changed the return value for an invalid entity to -1 to match the behavior of GET_VEHICLE_TYPE_RAW.

Thanks for the feedback!

[iridium-cfx]

I'm not a huge fan of returning the raw integer value. Maybe use GetNetObjEntityName to return the string value instead?

[tens0rfl0w]

My intention was to match existing other custom native implementations like: GET_VEHICLE_TYPE_RAW. I would argue that comparing to an int is less user-error prone and also faster in some cases (though this probably doesn't really matter).

But of course, if you prefer returning the type as a string here, I will change this👍🏼

[AvarianKnight]

I'm not a huge fan of returning the raw integer value. Maybe use GetNetObjEntityName to return the string value instead?

Would it not be better to just make two natives new natives for this and have one return the string and one return the raw integer value?

GET_NET_OBJ_TYPE -> returns as string (though maybe not specifically from GetNetObjEntityName as the CNetObj substring is a bit redundant
GET_NET_OBJ_TYPE_RAW -> returns as int

I don't think many people (though i could be a bit biased here) really care about the string representation unless they're debugging.

[slashkeyvalue]

I also prefer strings due to the fact that we don't have enums or equivalents