2020-04-29, 01:09 PM
I have suggested this before on Discord, but I feel this should be properly laid out and discussed here as well. This suggestion is motivated by the needs of my server, but I hope this will be useful to a wider range of servers as well.
There is a limit of 1000 objects and 2000 vehicles. This limit is client-side and cannot be circumvented. A streamer can be used to give the illusion of having infinite entity slots to use, while still only showing a limited amount of them to players; however, this feels like an overkill to me when you actually don't need to be able to display seamlessly thousands of objects to players.
I suggest a lightweight alternative to classic streaming using virtual worlds. This has the following specifics:
There is a limit of 1000 objects and 2000 vehicles. This limit is client-side and cannot be circumvented. A streamer can be used to give the illusion of having infinite entity slots to use, while still only showing a limited amount of them to players; however, this feels like an overkill to me when you actually don't need to be able to display seamlessly thousands of objects to players.
I suggest a lightweight alternative to classic streaming using virtual worlds. This has the following specifics:
- There is a fixed limit of entities existing per-world. Creating an entity or moving entity there if it exceeds the limit fails. Creating a global entity (global object) also fails if there is no slot that is unoccupied in all used worlds.
- An entity has a per-world ID, which is consistent throughout its lifetime and equal to its client-side ID when shown to any player. This is necessary since things like SelectObject and /dl expose the ID.
- Assigning a per-world ID to an entity should prioritize IDs that are used for other per-world entities in other worlds (configurable). This maximizes the number of slots that are still usable for global entities.
- The per-world ID of an entity either has to be the primary means of manipulating it server-side (similarly to per-player objects), or there should be a two-way conversion function.
- When a player changes the virtual world, all the entities there are displayed to them (unless there are type-specific rules, like distance for vehicles), and the old ones are hidden.
- Having a better track of visibility relations between players and entities decreases the amount of processing needed. Looping specifically over per-world entities (with per-world IDs) further improves the performance.
- Parallel processing can be used for individual worlds to increase tick rate. If the scripting language allows it, even callbacks can be invoked on different threads.
- This can be used for objects, vehicles, pickups, 3D labels, actors, and also NPCs.