Proposal: semi-networked objects

[XenoS-ITA]

hey everyone, i’ve been involved in the fivem scripting community for over five years now however i recently encountered a limitation that feels restrictive.
in one of my latest project, i needed a large number of synced objects. this requires networked objects, but unfortunately, we’re constrained by gta/fivem's limit of 80 loaded netobjs at any given time (this limit is perfectly logical and reasonable). once we exceed this limit, any additional entities simply won’t replicate without any warnings or error messages (since the last time i tested)

Proposal

i propose a new type of entity that i call semi-networked this type would be a hybrid, managed in its own pool, which allows for more controlled synchronization behavior without relying on the entire network overhead. here's what i have in mind:

These objects would sync:

• SetEntityCoords and any other natives that modify the entity directly,
• State bags and other attributes generally synced for networked entities,
• Any other properties explicitly updated by the server.

These objects would not sync:

• Client-side, physics-driven actions like "forces" applied (for example, punches).

the idea is that the server or an explicit native command would be responsible for triggering updates. this approach would make these entities more like local objects that only sync when requested to, cutting down on networking overhead and allowing us to maintain more objects with better performance.

similar to how static flags works (NetworkSetObjectForceStaticBlend - FiveM Docs), but with more server control and explicit update triggers. this would allow us to manage state and sync behavior more directly, especially in cases where physics or environmental forces aren’t critical. (for example: objects that need to change only on interaction)

im also interested to hear what the community/team thinks about this idea and would also like to know if anyone has explored solutions for similar needs or if anyone has thought of a better idea to handle this limitation.

let’s discuss!

---

i have never collaborated in the source code of fivem but im more than willing to help in case a solution is found (a minimum of “routing” would be appreciated)

i apologize in advance for any unfounded assumption about how fivem works under the hood, corrections are more than welcome.

[IstuntmanI]

I recently started digging around for what FiveM is able to do (after years of SA-MP server development), and this is one of the major limitations that I could notice. I was also thinking about similar things.

Seems weird to me that the server is able to create only up to 80 networked objects at once, while the client is easily able to create 2000+ objects at once. I was able to create 3000+ objects on the client's side (probably depending on the zone I was in):

(which was the absolute maximum; spawning a vehicle couldn't even load the model anymore 😃)

I think that the whole culling mechanism should be able to use the game client's actual limit. To be on the safe side, the server may have an imposed limit of 1500 objects that could be sent for creation to a client at once.

But, if a semi-networked approach would be implemented, similar to your suggestion, maybe some API could be offered to allow the server developers to extend the networked properties/events.

A thing that drastically improved SA-MP's server development for everyone was the SA-MP Streamer Plugin, which basically allowed an infinite amount of entities created on the server, while the server efficiently (with entities allocated to a world grid and cells) sent entity creation/updating/deletion messages to the clients.

FiveM's current mechanism seems to require us to just load .ymap files (or just CREATE_OBJECT(_NO_OFFSET) calls) directly from the client side scripting, which makes everything more limited and less dynamic.