SetRoutingBucketEntityLockdownMode breaking lib.progressBar()
Vicken52 opened this issue · 6 comments
With the SetRoutingBucketEntityLockdownMode set to relaxed in ox_core,
https://github.com/overextended/ox_core/blob/main/server/init.lua#L5
spawning entities on the client side is blocked, but ox_lib spawns entities on the client side to handle progress bar animations and also npwd which spawns the phone client side when the player pulls it out, which causes the character to just do the animation without anything in their hand.
I know other resources also handling spawning entities on the client side, but I mainly named off those two, because they're directly supported/integrate with ox_core. Is this something that might be better off switched to inactive?
Plan is to add server-side object spawning into ox_lib in the future.
Can't do anything about NPWD, unless they do the same.
Cool, I did some work on bringing server side object spawning (basically very similar to how vehicles work currently) for ox_core, but with resources as the owner of the spawned object to persist between restarts if desired. I can create a PR with that if that would help with development for this.
Vehicle spawning is part of ox_core for persistence (owned vehicles); don't really have the same need for peds and objects, so having them in ox_lib is preferred.
No need for a PR to either, it'd just sit there for a while. Once I have specific need of the functionality, I'll work on it.
There's still problems with attaching server-side entities to players anyway (since you can't control ownership), and RequestControl natives shouldn't really be used.
I understand that for peds, because the most I can think of for them would be shop owner in ox_inventory, which is something that can be done in the config files and ox_lib server side spawning can handle without the need for persistence.
The reason I was thinking about objects being in ox_core was because the persistence of the x,y,z,heading and data associated with it would be useful for player farming, so that the crops persist between restarts and they are able to maintain the condition of those crops through the properties associated with the ox_core object. I know there are some drug resources that do the same with weed growing, and build their own table, but I built it into ox_core with the idea of just using it as a wrapper for persistency and avoiding multiple database tables that would accomplish the same thing.
Fairly niche use. Vehicles need a strict data structure so you can easily use them between resources, but objects won't have that same need.
Having lots of tables with different structures is fine for that, if not using JSON files or KVP. Lots of tables isn't bad and you can specialise each one for your use case.
@Vicken52 I made the decision to drop the enforced SetRoutingBucketEntityLockdownMode; complications with entity attachment and networked scenes when using server-side objects make it lose the appeal.
Testing server-side objects with the progressbar could have weird effects if the model hadn't been loaded before, and I hadn't even begun testing entity attachment via statebags.
Will revisit in the future, but for now it's more hassle than I care to deal with; though people are recommended to use the server when possible.