I’m not writing this topic to get specific help onto a specific script, but to ask help about a roblox core mechanism: physics.
I would like to create a game which involves ROBLOX’s physics, but it is not known to be the best emulation system. I am aware of all its limitations, and am looking forward to find the best way to do things, between stability and efficiency.
Project:
For starters, I would like to make a game which is based in a forced 2D environment in multiplayer (5 people max). I am using AlignOrientation and PlaneConstraint instances to do so, and it works perfectly.
On top of that, I would like to have Anchored parts (not part of the problem), Constrained Parts & Fully unanchored parts.
The last 2 ones are in my line of sight for this post.
Issue & explanations:
Basically, the main core issue is the NetworkOwnership. As you may know, ROBLOX’s servers don’t handle physics calculation and part interactions alone. Players and their client are the one responsible of these.
When a player interacts with a part, it goes from “sleeping” state to “moving”, and the Player’s client makes most of the calculations to make the part moving.
When a part is far away from a player, the server will take its own calculation, and will find a way out to put the part into “sleeping” mode, to gain in performances.
What I want to do:
I want to make physics as fluid as possible, which is also good in terms of performances. I don’t want the NetworkOwner to always change between clients, thus making the part freeze onto itself.
If you have any plausible ideas on how to make ROBLOX’s physics better, let me know !
NB:The solution cannot involve the local clonage of unanchored instances as I do not want exploiters to have a facilitated work
TL;DR:
Help with ROBLOX’s physics
Ways to possibly improve it for a multiplayer game (5 players max)
To prevent a part from switching between clients, call Part:SetNetworkOwner(Player) to set ownership to a specific player. To give the server ownership call Part:SetNetworkOwner() with no arguments. Keep in mind that this will throw an error if the part is anchored or if this is attempted through a localscript.
I see what you mean, but switching between clients makes a little lag during which the said part freezes a little. Not taking in account the fact that laggy clients could take the ownership of a part, thus ruining a few things.
I already thought about client clonage of parts, I just don’t want exploiters to mess with it (and sure they will anyway).
What I’d like to have is like, an algorithm that would be performance-friendly & effective !
NB: I don’t want the script, just the general idea of course
I’m incredibly sorry that I didn’t reply for so long, I haven’t used devforum in forever. Hopefully this reply will still be of use to somebody.
My last post was intended to inform you that you can set the network ownership to nil so it’s always handled by the server, providing smooth and uninterrupted movement and preventing exploiters from screwing with physics. What i did not intend to do was recommend that you handle the movement on a certain client unless that client is controlling a part, or to allow swapping between clients.
I really hope I understood your reply, as otherwise I delayed you for 25 days only to say something completely off topic.
Again, I’m very sorry.
Hello,
First off, don’t worry! You are literally the only one that replied to this topic, I express you all my gratitude for this.
Secondly, I would have loved to use the server to handle part movements. However the amount of moving parts is undefined, and can be very low like very large.
I am planning to use Streaming to guarantee a better gestion of clients’ memory, and if possible even use a server Streaming system (using Roblox methods if such a thing exists, or by myself)
I think that this server streaming would be a really good solution, alongside the server managing parts, what do you think?
What you’re trying to do is in essence impossible…
For starters, I would like to make a game which is based in a forced 2D environment in multiplayer (5 people max). I am using AlignOrientation and PlaneConstraint instances to do so, and it works perfectly.
This is a problem, as it's not possible for you to guarantee what happens on the server and what happens on the client. You can't force a client to do something you want them to do, and for a player to force something to happen on the server, it must be on the server.
I would like to have Anchored parts (not part of the problem), Constrained Parts & Fully unanchored parts.
This is where you're going to run into problems, as all of these are things that must happen on the client. If you want to have a "perfect" physics engine, then every part must be unanchored... but if you want to give the client control of that, then you can't have the server doing any physics.
Basically, the main core issue is the NetworkOwnership. As you may know, ROBLOX’s servers don’t handle physics calculation and part interactions alone. Players and their client are the one responsible of these.
This is where the problem is. You want to have the server in charge of the physics, but you also want the client to have control over them. This is impossible, as the client can never be trusted.
If you have any plausible ideas on how to make ROBLOX’s physics better, let me know !
There's a reason there's no (good) 2D physics engine on ROBLOX, and there's a reason there's no (good) multiplayer physics engine on ROBLOX. They're both impossible to do well.
If you're trying to make a game where the server controls the physics, you're going to run into problems. If you're trying to make a game where the client controls the physics, you're going to run into problems.
You need to decide which of these problems you want to deal with, and then work with it.
Hiya, your best bet is to make use of remote events. Now this will cause lag on the client as to affect things in your world it will be a few milliseconds behind, to accomodate for this I would affect the world locally and then let the server handle the actual replication, in this case all you need to tell the server is where the player is located (this of course depends on what kind of interactions you want to take place). Since the server is handling the replication, you can have fine control over the permissions of allowing the player to move, e.g. if the player is being asked to move too fast, or being asked to be teleported to a location which is not allowed.
On the client you would simulate stuff happening such as interactions, however while this is happening you are keeping the server updated on positions of the players. With the server then doing the physics calculations while your client is. Your client will have its own copy of the world if you will. Granted if a player is experiencing high latency you will experience sync issues, however there are other ways to combat this.