… but that is exactly how entities work, except you have to manually check if the current player has control before doing anything. Or are you talking about automatic management of ‘entity brains’ that (through a magic state table?) migrate along with the entity? This could technically already be done with a somewhat-smart resource, except for the fact that migrating state wouldn’t be implied so might take an additional frame + network latency.
CreateThread/Tick will (of course) execute at the first tick following a resource start, and the script constructors/global chunk code will execute right at environment creation (but in Lua/JS, before all files are loaded - so use tick handlers there).
Huh? The cache is meant to be transparent to the user/developer, if you’re having to look at or remove any cache data that’s considered a bug and you should report a repro for that.
You shouldn’t put ‘big files’ in the resource RPF anyway, however it is planned to support multiple file sets that can be cached individually for when one can’t use separate (stream-like) files, that can be requested over script.
Can be implemented by people already, however
feature/cloning-stuff once done will intercept client data on the server and have some kind of limited migrating RPC.
There’s a few glitches currently that are holding things including 0sync up, various game state isn’t being properly transmitted to other clients.
Huh? If you mean
TIMERA/TIMERB, those are strongly tied to the existing
scrProgram runtime, and are not meant to be used from custom scripts in CitizenFX. Try manually keeping track of
CreateVehicle hard to use? Also… ‘creating players’?
(btw, C# already has some wrapper functionality as
await World.CreateVehicle and such inherited from SHVDN, for Lua/JS it’s something the community can already create as some sort of generic library)
Not possible because a) not all scripts are Lua and b) they run in separate Lua VMs, so sharing any state directly is completely impossible.
We have been planning on a ‘reference variable’ system however which would work similarly to the current ‘callback references’ and would instead marshal each and every get/set call to the originating runtime (allowing easy local marshaling of complex C# objects in addition to allowing use of metatables), but this is pretty much low priority and has a few open questions about syntactic semantics.