maybe, if this kind of “hiding players” function is exist, it’ll relate so much methods like “GetEntityCoords” and Transforms etc…
hope we’ll find it 
Let me just start by saying I haven’t coded mods for FiveM since March and by now somethings might have changed.
you can already do this by making every player on the client that the “instance” was created in invisible, and disabling their collision for the that client alone will fix the issue of people opening doors and other people seeing that on different “instances”, then you’ll need to create teams to make sure people in different “instances” can’t kill each other, find a way for players to join the same “instance” as one another and not see each other falling through the floor. the big issue I found that I could not find a way to solve was that you could hear everyone on the other “instances”.
edit: I also haven’t tested what happens when a player disconects from the server while inside an “instance” and then comes back
Still looking forward to this being implemented some day. Having the server manage multiple virtual worlds seems as simple as managing multiple sessions, so the only thing that is really needed is to be able to create a new separate session from a group of players and have some function to move a player from one session to another. Any sort of id-based virtual world system can be easily built on top of that.
I have tried to tinker with the Network* functions, but it seems only NetworkSessionLeaveSinglePlayer and NetworkSessionHostSinglePlayer actually do something (the former leaves the session and the latter re-joins it).
This is actually something that i miss a lot from SA:MP, doing interiors with virtual worlds was great! Also, was helpful for a lot of creative ideas.
and wrong to do interiors in V given you can look outside.
Well, the thing is we could make entire buildings full of apartments, sell, rent and so on with some very easy steps. Some servers had more than 1000 houses/apartments 100% functional.
That in a time we didnt had SQL databases, everything was in txt files.
There are other applications for it as well. I get it you don’t like it being used for apartments because it is the “wrong” way. BUT if someone wants to make a server with multiple gamemodes they need virtual worlds. If I want deathmatch gamemodes, freeroam, racing, etc done on the same server it needs virtual worlds/dimensions. Pretty sure there are other useful applications for it as well, but this one pops to my mind.
and again that can’t be trivially implemented at this point due to population turn taking concerns.
I’ve seen a few instance scripts that actually work pretty decently
I am still very dissatisfied this hasn’t already been properly addressed. The possibilities are almost limitless: you could run different scripts/resources in different virtual worlds/sessions without affecting others, you can restrict certain players to certain worlds, or conversely, create VIP worlds, you can make full sandbox worlds for all players without them destroying each other’s work. Hiding players from each other has no use if they can still shoot and kill stuff. I can’t ever hope to properly switch from SA-MP to FiveM without this.
Please explain what that means.
Even in the simplest concept of a single-ID routing policy, if the current world grid owner happens to be in routing bucket A and moved to routing bucket B, what would happen to population entities spawned by their game, and how would anyone else in their scope be affected by this change?
Unlike “other mods”, here, clients control more than just 1/2 entities each, and a routing policy implementation needs to take this into account, and again, there is no single proven method for this.
Also, if your need for this is so critical, you could probably implement a very hacky variant of something like this within a day of tweaking around server code only.
For something of this complexity to be worked on by me formally, however, I need to have a use of it myself or at least be in close contact with a party that is planning on using such a feature so that it isn’t implemented in a way that nobody even wants at all, for this is a lot more complicated than “assign a player a routing bucket and give the same routing bucket to an entity and be done with it”.
In a proper implementation of this, various things would have to either be taken into account or have responsibility passed on to a resource implementing this:
- population generation: should a transitioning player have all population oddly vanish? should it be forked into the new routing bucket? unlike random mods, we also clone AI stuff
- unowned entities: should they be moved as well? we don’t just clone players and vehicles they’re on, but also unoccupied vehicles, props, etc.
- how should the object ID pool be handled in case of a full split-bucket policy? what if a routing bucket merges again?
- is a routing bucket even the right solution for all cases, or should this be a bit mask of target players?
- how should event routing be done, both of built-in synchronization events used by R*, as well as user events, and how should this remain compatible?
- same for voice routing, etc.
As you can see, there are too many unknowns here for a generic solution that fits all users to be implemented without having exact needs known at time of implementation, and since I do not have such needs, nor am I in close contact with any server owner/resource developer needing this feature, it clearly has not been implemented yet.
That doesn’t take away that this is an open-source project, and if you need this feature so critically, you can implement it yourself within a day in the simplest case (not taking into account population, all handling being equivalent to a player leaving, no event routing compatibility), even with no prior knowledge of the server code.
1 Like
Thanks for the detailed response! I understand this is a complicated matter and I would gladly provide insight about the behaviour. I have thought about modifying the server code myself as well, and I might give it a go some day.
I don’t know the proper terms, but I think the simplest approach of a “multiserver” keeping multiple sessions of interconnected players would be sufficient. This means that session transfer would be basically equivalent to stuff that can already happen, albeit uncontrollably. At one time I managed (due to a bug) to have two groups of players seeing each other in their respective groups, but not the players in the other groups. Newly connected players would go only into one of those groups.
The only thing needed is a couple of server-side functions - to isolate a player in their own session and to move a player from their session to one of another player’s. Of course all existing vehicles and peds will disappear when you switch sessions. No separate pool of session objects needed, just something kept alive by the actual players. To client-side scrips, players from other sessions should be literally invisible, and any session transfer would be handled as server join/leave.
1 Like
This is only a thing on non-OneSync, which is a) quite deprecated and b) impossible to control in a controllable fashion, even.
On OneSync, there’s no such thing as ‘sessions’ at all as all routing is server-controlled, which makes adding even a routing bucket policy a bit weird, and still leaves the concern of server-side broadcast events unresolved.
Hello
I remember you from the SA-MP forums, you’re the guy who made PawnPlus and iQuat 
Btw, by searching these forums I found an answer to how to make Virtual Worlds (the person who wrote its documentation claims that this is how Rockstar hides players in the same interiors from seeing eachother):
NETWORK_CONCEAL_PLAYER
It probably hides a certain player from the player who is calling this native (it’s a client native)
NETWORK_CONCEAL_ENTITY
http://runtime.fivem.net/doc/natives/?_0x1632BE0AC1E62876
It probably hides a certain entity (object/vehicle/ped/etc…) from the player who is calling this native (it’s a client native)
I didn’t test them yet.
1 Like
Turns out it only took a whole of 30 minutes of code+docs and only one bug (coincidentally in world grid handling).
If this were such an important feature to so many people, I wonder why nobody PR’d it before I found the focus to implement it.
7 Likes
That is not doing Virtual Worlds you can hear each other while in instance.
You can see spawned props while in instance.
The only thing it does is hiding players from each other.
Sweet! Thanks a lot bubble, can’t wait to try this out!
Thanks for making it 
!
I would have definitely made it and sent a PR if I were more proficient in C++ and had more time available to study how the FiveM server works
Using the Mumble Voice Channel system you can control this behavour.
Cool, this looks very promising. Thanks!
Taking this to the next level - would it possible to start a resource per-bucket? I.e. to download a specific resource only to the players in a specific bucket, and stop it when the player leaves. This would make it possible to have a multi-mode server of sorts, with people switching between resource packs/modes as they like.