I have seen that the problem is about players that are online. Without players the native function becomes useless, but just by having one active player, it already works properly. At least it could be indicated that detail in the documentation of these native Serve side functions. Or did I miss that detail about OneSync?
OneSync allows you to create entities on the server such as Peds, Vehicles and Objects among others. One of the advantages about this, is that the server allows you to call natives via RPC (Remote Procedure Call) to perform actions on the client without having to request control of an entity from the client.
Server-side natives just route to a client so it makes sense not working if there are no players in the server
Use CreateObjectNoOffset, which is a ‘server setter’. CreateObject requires information on the object’s bounding sphere, which isn’t available on the server, as the server doesn’t run a copy of the game so doesn’t have game data, nor is there any support at this time for providing game data for this purpose.
However, even an RPC creation call shouldn’t ‘return 0’, instead it should return a temp-entity handle (though perhaps 0 is the first temp-entity handle?) and this temporary entity should create fine once a player connects and gets in range.
This also isn’t documented since it’s not intended behavior: this detail should be transparent to scripts. It not working like that would be a bug.
Alright, I made some tests and I can say that way, everything worked correctly with the CreateObjectNoOffset, and this way it allows me to call the other functions (Heading, Culling, etc…). If it is with the following CreateObject function and even if it is executed with players online, it will not be possible to execute the other native functions on the server side, it will give the following error: Tried to access invalid entity(Like this issue). I think that just through this topic it is possible to see some differences between the two native functions of creating objects, I haven’t done any tests with the part of creating vehicles yet, but I am on my way to that part.
Yes, but this declaration gets taken in from the build pipeline elsewhere (and can’t be taken out for client compatibility with old servers), and the only reason the definition from ServerSetters.cpp takes precedence is because it’s executed later.
Again, there should be no effective difference between RPC setters and direct setters (other than the fact getters won’t return directly, and that’s also a WIP to add for RPC-only setters), so ‘RPC native’ doesn’t have any of the negative meaning you think it does, and the issues @0rangeFox is experiencing here are mostly representing a bug.
It’s very low priority to actually change such a documentation note, and since documentation expresses intent, codifying bugs would be wrong.