I think the issue you're having is communicating why you think multiplayer makes a significant difference here. It shouldn't. We're talking (basically) about a system where you chunk up the world and give each chunk its own local coordinate system. Everything in those chunks, including players, is tracked by a reference to its chunk ID and a local position within that chunk. It works just as well with one bullet in a chunk as it does a hundred bullets in a chunk, and it similarly works as well with one player as with a hundred players.

Where specifically do you see this falling apart with more than one player? Is it in this scenario below?

now without changing precision how would you keep one block away from the other without losing it's positional data (float would become in comprehensible after a limit)

What do you mean by "keep one block away from the other without losing its positional data?" They're separate chunks of the world with separate sets of objects (including potentially players) and don't need to interact until a chunk detects that an object is leaving its boundaries. At that point it figured out what chunk the object is going into and hands the object's current state over to that chunk. (As one possible example of how to handle the problem.)

I think the issue you're having is communicating why you think multiplayer makes a significant difference here. It shouldn't. We're talking (basically) about a system where you chunk up the world and give each chunk its own local coordinate system. Everything in those chunks, including players, is tracked by a reference to its chunk ID and a local position within that chunk. It works just as well with one bullet in a chunk as it does a hundred bullets in a chunk, and it similarly works as well with one player as with a hundred players.

Where specifically do you see this falling apart with more than one player? Is it in this scenario below?

now without changing precision how would you keep one block away from the other without losing it's positional data (float would become in comprehensible after a limit)

What do you mean by "keep one block away from the other without losing its positional data?" They're separate chunks of the world with separate sets of objects (including potentially players) and don't need to interact until a chunk detects that an object is leaving its boundaries. At that point it figured out what chunk the object is going into and hands the object's current state over to that chunk. (As one possible example of how to handle the problem.)

oh we meet again! pleasant surprise

hmm I think , I might've just understood what you meant on SE. just now I think .

lol thanks mate. I'll give it a try this week and come back to you. possibly only gonna run into implementation kinks and no problems with the actual logic

You'll probably need to create a separate authoritative server, not written in UE4, and have your players clients talk to it.

Well that's essentially writing entire UE4 engine module, since Ue4 server is actually same as the client game just with authority over the decisions of game rules.

Trust me I've been using UE4 for 2 years now and I know about its level streaming and world composition features, they are indeed cell division method that work with origin rebasing but both are supported for single player only right now. The missing multiplayer support for origin rebasing should give you a good idea of the troubles it takes to implement with handling of edge cases being the worst contender

This is the reason I was head hunting so desperately about large multiplayer worlds, if you search UE4 forums and answerhub you'll see it as frequently being mentioned and the devs replying that they'll add it at a later stage (never) .

I think the issue you're having is communicating why you think multiplayer makes a significant difference here. It shouldn't. We're talking (basically) about a system where you chunk up the world and give each chunk its own local coordinate system. Everything in those chunks, including players, is tracked by a reference to its chunk ID and a local position within that chunk. It works just as well with one bullet in a chunk as it does a hundred bullets in a chunk, and it similarly works as well with one player as with a hundred players.

Where specifically do you see this falling apart with more than one player? Is it in this scenario below?

now without changing precision how would you keep one block away from the other without losing it's positional data (float would become in comprehensible after a limit)

What do you mean by "keep one block away from the other without losing its positional data?" They're separate chunks of the world with separate sets of objects (including potentially players) and don't need to interact until a chunk detects that an object is leaving its boundaries. At that point it figured out what chunk the object is going into and hands the object's current state over to that chunk. (As one possible example of how to handle the problem.)

Ok I think now I know whats stumping me ,

When an object is at edge of grid 1 but still large enough so that part of it goes into grid 2 and then it hits an object in grid 2 , as such how would you handle the physics for physics engine? because for physics engine the objects needs to be tied to the same origin.

can someone explain this?