I know you can already do almost anything mentioned here, but not directly, you have to script it yourself.
Better Resource Control
Scripts that spawn Entities that are only controlled by one client which is either one fixed client and passed after he is dropped or passed to the first nearest player in a certain radius. e.g. player A enters 200 radius gets control, until he leaves, drops or another player enters that radius after he leaves.
Default events for the start of the current resource. Not just any resource. And yes, having to add that one line is bothersome.
Cache that caches by server and not dumps the general resources when changed over and over again.
Delta-patching of cached resources. So you need to download big files only once.
Misc Native Stuff
Invoke Client-side Natives and get data on server directly. Like the location of a player or vehicle. Giving you the ability to run some scripts purely server-sided.
Fixed random ped creation, for you cannot request random models, you need to intercept ped creation and randomize it currently.
Fixed timer natives.
Some neat wrappers for vehicles, peds and players to create them more quickly.
Ability to define global variables over scripts, so you can properly use metatables without grabbing them via triggerevent.
This also already sort of exists in the form of exports. You can use an export function to get the return value of a variable from another resource without the need of events.
Oh nice, I am writing my own wrappers, currently migrating my stuff to C#, so I can have Ped : Entity etc, so I got neat objects. But I sorely missed these functions in luaâŚ
Yeah I said most of the stuff is already programmable, even in a few lines. The issue is, you cannot export metatables directly, you need to export a function / use an event to grab the metatable. But e.g. I write a HUD controlling metatable, for me, and now I got to use exports / events in every single resource that needs access to the HUD. Also you need to wait in some cases until the HUD controlling resource is done initializingâŚ
Instead you could have one global variable / metatable
⌠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.
Hint: 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 GetGameTimer/GetNetworkTimer.
How is 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.
Yes, ofc it can be done in a smart resource, but scripting that is a pain. e.g. if you want to make a tennis script, you have one player as a host of a script, the other as the participant; in which case you need to script networking seperately. Instead of having supported that one is a client part the other is a host part of the script.
Or if you want to add cable cars, you have one person controlling the entities, but if that person has a shit latency towards you, it is not really enjoyable. Or you script proper networking by hand.
That is why I feel like the need for scripts that only have a single host (with entity support) that automatically switches players, but not as often as the game does, which kills the entities in some cases.
I currently have data in my cache that is probably from every single access to localhost since I last emptied it. Just judging by the dates, size, amount of files I have in the cache folder. If the resource was changed. Having one permanent file for a single resource on a server seems enough, or am I seeing things?
How big is big? I am talking about ~200MB in images for the NUI and (uncompressed) data files (XML/JSON). If I was to append 30kB to a 3MB file, at the end of the day I would be happy if only the 30kB gets redownloaded to the client or at least only the 3MB file, but to me it looks like it downloads the entire resource, and does not remove the old version.
Well, they are documented in the runtime reference, and some of the original gta code makes use of them. Would be quite easy from the fivem side to actually have a working version by using GetGamerTimer as a replacement, so they actually work or adding some words in the runtime documentation would be the least of what I would expect.
Well after all this was just a comfort post. You can cache manually (remove files send them manually to the client and save them); but well the stuff i mentioned might make developing a lot easier (at least for me).
as said, you can already script that, itâd be useless to have that in the C++ side as itâd need specific implementations to each script runtime and all, when anyone can make a common resource thatâll migrate entity brains
the game canât know if a file still exists somewhere else in the universe - resource cache is intentionally shared between servers so e.g. if server A has a car mod/resource/⌠thatâs public, you played on server A and loaded it, then play on server B which has it as well, you wonât have to pre-download this shared resource.
same applies to servers that exist with multiple instances on different IPs/ports/âŚ
⌠you have a fucking 200 MB resource RPF?! youâre definitely doing something wrong then ._.
the system currently isnât meant for people abusing it, resource RPFs should remain below ~1 MB in pretty much all cases.
also as itâs mostly NUI data, considered just requesting it over HTTP from a standalone web server so it gets cached in browser cache instead and only loaded on-demand?
which is just an export of the GTA natives
and the original GTA code uses a lot of other things that donât work here either.
even if, thatâd be like the lowest priority imaginable
again the referenceâs sections other than CFX are exported from an external source and not maintained or written by us, itâs just a convenience export of user findings
but that seems to me like a not the smartest way of caching. I mean you could cache the resource per server and if the exact same resource appears on another server you just softlink to the corresponding real file. If the original file changes, move the original to the first linking server, change links. Most servers use modified resources in the first place.
Especially as many popular servers modify their resources anyways, so they are kind of unique. I mean something like that /cache/ServerA/someresource.rpf /cache/ServerB/someresource.lnk
Because, well development still happens on live servers too.
Rounded 100MB of NUI data, yeah I would want them cheaply in my resource RPF, but I would only do that once delta patching for RPFs is available or another way of caching them. Downloading the entire resource for a small change is bonkers.
I would really like that, as it is an easy way to cache larger amounts of data, without one having to resort to another way.
edit: Also I heard from servers having large amounts of additional mapdata. Send to the client, like ~40MB+.
and how is the game supposed to know, if they havenât connected to âserver Bâ yet, that the file is actually in existence on that server as well, for when they might?
rather, a cache cleanup utility might be made for such purposes, instead of an imperfect system of guesses.
Why would you cache a changed resource 5 times, just for the sake of not downloading it once more because one of the versions might actually be on Server B of sub â1MBâ files, instead of caching one for server A, and if it does not matches and the user connects to server B one for server B?
because currently the system doesnât have to have a sense of âserversâ as thatâs mostly nonsensical and breaks certain scenarios that work fine now
the cache system was designed for large sets of reusable small files, such as full map mods of LC/VC/⌠being shared across many servers running that world, potentially with different versions of those ports that only change a subset of files.
other than not satisfying some compulsive behavior, what issue does exist with the current system, especially once a cache cleanup utility is implemented?
Oh, I heard someone having to preload 40MB (of I suppose ymap stuff) for elaborate racing courses. Just hearsay. But I trust that source, that a single resource was a 40MB download at least.
presumably the server owner implemented the map some legacy way (i.e. archetype json files), or otherwise marked streamed files to be included in the resource RPF for literally no reason whatsoever.
âMake something idiot-proof, and they will build a better idiot.â
We will see then. But I would still like to see something like delta-patching. As it would allow to download actually big resources, and for a small change it would not redownload the entire thing, maybe some type of versioning?
Unlikely to happen directly, the point of resource RPFs is to prevent file system/network load caused by having a massive amount of small files stored/requested separately.
As above, rather, some sort of âresource file setâ system might be made instead.
