tweak(server/gamestate): CreatePed RPC & CreatePedServerSetter

[goncalobsccosta]

Goal of this PR

Allow the usage of CreatePed RPC and create CreatePedServerSetter. Currently, the documentation states that CreatePed is an RPC, but it actually is a server setter. By separating these natives, users gain finer control over which method they want to use for spawning peds.

How is this PR achieving the goal

This PR changes the ServerSetters code to separate 2 natives, the server setter and the RPC.

This PR applies to the following area(s)

FiveM, Server

Successfully tested on

Game builds: 3258

Platforms: Windows, Linux

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]

I think the ship has sailed on this one. We cannot change expected behavior, even if it's not obvious what this is doing, most users that use this know its not a RPC native, and switching it back to a RPC will lead to even more confusion.

[Ehbw]

To add to Avarian's comment, this would very likely break compatibility for all existing scripts using CREATE_PED server-setters that depended on the ped creation to be done instantly and where the ped may not be assigned an owner yet as it has been since January 2021 4cbf129). It is also worth noting that it is documented that CREATE_PED and CREATE_OBJECT_NO_OFFSET RPC was deprecatedin favour of their equivalent server-setters.

If you really need an CREATE_PED RPC, it would make more sense to make it a new native and clearly document that it is an RPC rather then being a server-setter, Along with removing the old CREATE_PED reference here

fivem/ext/natives/rpc_spec_natives.lua

Line 18 in 1c490ee

entity_rpc 'CREATE_PED'

assuming the native docs pulls data from here to determine if a native should be marked as an RPC or not. But at this moment the server RPC in FiveM is not very reliable.

[goncalobsccosta]

I agree with the points everyone has made. Changing the existing behavior now would definitely cause more problems than it solves, especially with so many scripts relying on the current server-setter behavior of CREATE_PED.

My only concern was that there’s currently no alternative RPC native that uses a different name everything that exists is still tied to the original native names, so it felt inconsistent. But I understand why introducing breaking changes isn’t an option.

How should I proceed?

[AvarianKnight]

The answer is.. its complicated.

You can add a new name to the entity_rpc but we would need a way to link it to the CREATE_PED native so when doc gen happens the rpc will point to the right native, this would also be needed to actually have the client execute the right RPC native. If you try to send CREATE_PED_RPC to the client for it to do invokes it wont work

[spacevx]

The answer is.. its complicated.

You can add a new name to the entity_rpc but we would need a way to link it to the CREATE_PED native so when doc gen happens the rpc will point to the right native, this would also be needed to actually have the client execute the right RPC native. If you try to send CREATE_PED_RPC to the client for it to do invokes it wont work

Can we just remove the CREATE_PED RPC since it's not used anymore?