BasePart not moving on Constraint update

Help and Feedback Scripting Support
#1

I’ve decided to use PGS constraints, HingeConstraint and PrismaticConstraint to create swinging and side-moving doors respectively.

  • The constrained parts are in their individual CollisionGroup and only collide with Players and NPCs.

  • The constraints use the Servo ActuatorType with infinite force and variable levels of speed.

  • When the door is to be moved, the TargetAngle or TargetPosition of these constraints is set to the appropriate value.

My question is, why do the constrained parts get “stuck” sometimes, only moving after a player attempts to walk against them? What can I do to prevent this behaviour? Is there an efficient way to detect this is happening?

#2

I don’t have a lot of time, so sorry for the short response. But, this definitely sounds like it is related to network ownership.

You can find information on it here:
http://wiki.roblox.com/index.php?title=Network_ownership

#3

The server is the network owner of all parts, so the player shouldn’t influence them in any way.

This is due to the fact that if the Player is the network owner, they may change the values of the constraint and it will replicate to the server. The player having network ownership would allow for it to open and close doors at will for all the players in the server.

#4

Network ownership changes based on whichever player is near, setting it to server if there isn’t any.

1 Like
#5

A couple follow-up questions:

  1. Does this happen in Play Solo / Studio too, or only live servers?
  2. Do you have a place where people can see this effect for themselves?

My other guess would be the objects are being put into a sleep state. A good explaination of this:

#6

By using SetNetworkOwner, and setting the argument to nil, you can force the Server to be the network owner at all times.

1 Like
#7

Yes, I refer to the default behavior.

This is not what happens, due to the ownership being (in the default case) whoever is closest up to a certain treshold.

#8

By that, I mean that I have set the parts to be owned by the server at all times.

#9

Which is not desirable often. Setting ownership to a particular client assures a smooth experience for said client. It merely hands the physics calculations to them, if the client were to set any other properties for the part it does not replicate as far as I am aware.

#10

I have not yet observed this behaviour in Studio. However, I have set up this place which contains the affected objects.

#11

Hackers can manipulate the physics calculations.

#12

You are not wrong, but avoiding that by never allowing a client to take ownership is not a very viable solution. I reckon a smooth player experience outweighs a bad apple using it to their advantage, which can be countered in other ways. (server-sided checks for probability of an action being possible, to name one)