feat(state): add NET_TO_* and *_TO_NET helpers

[AvarianKnight]

Goal of this PR

Add the same helpers that the client has to convert to/from network ids instead if having to use the extremely verbose NetworkGetEntityFromNetworkId and NetworkGetNetworkIdFromEntity

How is this PR achieving the goal

Adds the same helpers from the client

This PR applies to the following area(s)

Server

Successfully tested on

Platforms: Windows

Checklist

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

[FabianTerhorst]

Hi, Thanks for the PR. Can you add a check for the entities NetObjEntityType to match the expected entity type of the NET_TO_* methods? So that e.g. a vehicle is not returned by NET_TO_PED.

[AvarianKnight]

I don't understand why this is really necessary, this wouldn't match the same behavior on the client.

[Disquse]

The server-side API must be as consistent as possible with the client-side API. However, it would be helpful to add some warnings if the returning entity is not of the expected type (on client-side too, but it's not the scope of this PR obviously).

[FabianTerhorst]

The server-side API must be as consistent as possible with the client-side API. However, it would be helpful to add some warnings if the returning entity is not of the expected type (on client-side too, but it's not the part of this PR obviously).

What do you think about adding the typecheck to the client native? Or would that break to much?

[Disquse]

Or would that break to much?

It will break way too much, yes. Not an option in our case, unfortunately. Warnings at least might be useful for developers without breaking anything, but still hard to predict the outcome.

[FabianTerhorst]

Or would that break to much?

It will break way too much, yes. Not an option in our case, unfortunately. Warnings at least might be useful for developers without breaking anything, but still hard to predict the outcome.

Thanks, so a warning on both the server and the client sounds like the best way for now.

[gottfriedleibniz]

Is the desire to have @AvarianKnight update the server implementation to sanitize based on entity type or match current client behaviour while we make a work item about improving feedback (for both GTA & RDR)? There seems to be some confusion here.

At the moment we already do provide some feedback about non-existent net-objects and game entities which is currently not reflected on server side.

[AvarianKnight]

At the moment we already do provide some feedback about non-existent net-objects and game entities which is currently not reflected on server side.

I think these types of warning would be weird to have on the server, any entity call (i.e. ENT_TO_NET) will go through makeEntityFunction, and if this is called with an invalid entity it will cause an exception that gets bubbled into the current runtime.

NET_TO_ENT will return 0 if the entity doesn't exist, this is currently an implementation detail but with the added docs it becomes "defined behavior", which is how a lot of stuff returns that "hey, this entity is invalid" and, imo, is better then being spammed with warnings that the entity doesn't exist.