Hiya, I want to create a sliding door for my game, preferrably performance-efficient as the game will also contain NPCs and such with pathfinding.
How would I make it always slide to the side no matter the rotation?
CFrame.new(3,0,0):ToObjectSpace(main.CFrame)
CFrames.
Object.CFrame = someCframeValue * CFrame.new(whateverAxes)
CFrame’s position is also affected by its rotation, meaning if you make a rotation of (0, pi/2, 0) (90 degree rotation to the right using radians), it will Translate using that rotation, which in that case, it will move across the Z axis due to said rotation, without it, it would be on the X axis.
That has to do with how you make your code, which by the sounds of it, you didnt make very well, or is something that is unrelated to the current topic.
I used tweening for the doors, which I am concerned about due to possible lag should they be used constantly
There are many ways to do this. If you want to prevent lag then using physics constraints would be the best idea. You could weld all parts of a door together and use AlignPosition or PrismaticConstraints to move the door. You should also use;
BasePart:SetNetworkOwner(Player?)
To further get a smooth sliding effect.
Hi! I have certain doubts about what you said, could you elaborate why?
Tween service indeed doesn’t make use of the physics engine. While using MoverConstraints (or CFrame changes) does involve the physics engine, which calculates forces, handles collisions, and simulates realistic physical behavior. This can be computationally expensive, especially if many objects or complex interactions are involved.
Tweens bypass the physics engine entirely, merely interpolating properties like position or size. This results in fewer calculations and less processing power required. It ignore collisions and move objects directly to the target properties, reducing the amount of processing needed.
If you are giving the physics solving to the player instead of solving it in server, will help with lag on server too, but now is the client who is solving all the physics calculations on their device, isn’t? And if its many of them the client should be solving all of that.
And you suggest giving the NetworkOwnership to which player? The one that is close to the door? if its an NPC then it should be handled on client then? so the NPC and the door are solved by the client who is close to it?
I do know that yet the only way to get smooth tweens is using tweenservice on the client. I said all this with one assumption that the door are triggered by a proximity prompt and everything is server sided.
Yes, but it’s not too computationally expensive that it would show noticeable amounts of fps drops. OP of they are using proximity prompts, can use the player argument returned by the .Triggered argument to set the network owner, after which they can allow the server to handle it. For NPCs it’s obvious that they can’t trigger a proximity prompt and thus OP would use remot events, so they can simply set the network owner to the server.
Also it’s not like the physics calculations will be soo difficult that it will cause lag as I said above. So that argument is quite weird.
I would like to see if you have any other possible suggestion to provide smooth tweening. One way OP could do this is by using remote events and run the method :FireClient() which could work but not up to my assumption. Because OP has provided us with quite less information.
I agree, and it could be an approach too, using the Tweens on the client, same it could be done with ProximityPrompts.
In OP case I could try both to see which is more convenient, using physics engine or the tweens on client.
Yeah, I think the same, its only a door, or a few being solved near a player, I was just asking, if physics engine involves more calculation than a client tween, then tween would be a little more performant, unless there are more issues related with tweens on client.
OP just mentioned that there are NPCs in their game, as you said, we dont have enough information on what’s the OP’s idea
Tween indeed is more performant but according to my assumption of everything being server - sided I found physics to be a good solution.
Oh yeah I saw that. I meant as in they didn’t provide much information of their code and how the model is made etc.
I don’t think the context in which the script to tween the door’s CFrame runs really matters in this case. For the best and safest option, I would pick server side.
Anything that is done by the server ARE GOING TO BE replicated to all clients. Sure, you can hook up remote events which will be listened by al client’s local script in order to open/close the door depending on an input which can be less laggy, but not too significant, but why do the extra work? Just let the server handle the tweening and it should be fine.
If you have tons of doors that have this same mechanism, then use a script which connects event for input to each door instead of using a separate script for one door. Doing less work makes a game more performance-friendly.
I do not agree with the physics as an alternative as that can require calculation. In fact, if there’s many doors in the game and we use physics to open/close, it’s going to be super laggy.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.