I think everyone would agree that when you want to have moving parts in roblox, things get tricky. Currently there are only really two ways of moving parts. Body objects and setting a parts CFrame (Position is part of the CFrame). Rotating said moving parts complicated the entire thing even more.
Body objects I think everyone would agree are very awkward to use. You have to fight roblox’s physics, they can collide in annoying ways and are not very user friendly. They are however nice and smooth. Setting a parts CFrame is very precise, simple to predict and you can rely on it to do what you want no matter what parts are around. CFrames however are hard to use for smooth movement and get laggy pretty fast (due to the large amount of c interop).
[b]I suggest adding
BasePart:TweenCFrame( CFrame endCFrame, Enum easingDirection, Enum easingStyle, float time, bool override, function callback)[/b]
This conforms to the same arguments as the gui tweens and would allow for much more user friendly part movement.
And example of its usage is making a basic elevator. Currently you can set its CFrame again and again however this feels laggy and is glitchy. Using bodyobjects are annoying because you have to fiddle with the values depending on how many players are standing on the elevator, you need to stop it tilting where players are standing. Very hard for new developers and annoying for seasoned developers who just want to quickly get it out of the way.
With this new method you could just call it and be done with the elevator. No calculating necessary forces and is nice and smooth.
(Maybe this could also extend to models? Would be a good compliment to the new model methods.)
You can CFrame smoothly however only on client side when linked to renderstepped. CFraming like this also becomes laggy very quickly when using a lot of parts.
CFraming individual parts should never be done on server side because the moment you do that all the interpolation and prediction roblox does to reduce network load and hide latency goes out of the window.
Using bodyobjects requires replicating a single cframe for a multipart body, which can be optimized because you know how the cframe will change in the future (because it uses physics)
Using CFraming requires replicating a single cframe for every single part, and because its implemented by you, not roblox, roblox has to replicate a full cframe every single time because it cannot assume anything about the behavior of the parts. You could be moving them linearly along a path, or you could be just setting them to random positions and rotations. Its probably a hundred times more demanding from the networking perspective.
Being able to CFrame models would be a lot better but still problematic.
[quote] CFraming individual parts should never be done on server side because the moment you do that all the interpolation and prediction roblox does to reduce network load and hide latency goes out of the window.
Using bodyobjects requires replicating a single cframe for a multipart body, which can be optimized because you know how the cframe will change in the future (because it uses physics)
Using CFraming requires replicating a single cframe for every single part, and because its implemented by you, not roblox, roblox has to replicate a full cframe every single time because it cannot assume anything about the behavior of the parts. You could be moving them linearly along a path, or you could be just setting them to random positions and rotations. Its probably a hundred times more demanding from the networking perspective.
Being able to CFrame models would be a lot better but still problematic. [/quote]
However a tween is predicatable. They can just tell the client to begin the tween rather than sending constant cframes. (I even did this as part of my custom replication layer)
^thats the exact problem a lot of new users have which this would solve.
[quote=“Crazyman32”]Then you have the argument that if something can be done via Lua by the users, it shouldn’t necessarily be coded into the ROBLOX API.
I don’t think tweening parts is very difficult. Myself and others have coded simple APIs to do such tasks and the majority are open-source.[/quote]
Yes you can do it with Lua. Yes for some it is simple. However the same could be said for gui’s yet they have tween functions.
Maybe look at the second post here, someone did try to make a bigger tweening library, but tweening CFrames without a complex API in each script would be awesome.
How about a checkbox named “Unstoppable”.
It would make the part not be affected by outside forces, only by Body_____ objects within some part of the body.
So it would give you an “unstoppable force meets immovable object” situation where the unstoppable part/body would just go through anything, like it was CFramed.
Benefits over a whole new part tweening API:
-Easier to use. You dont even need a script to set up lets say a spinning unstoppable platform.
-Automatically works with other physical objects since the parts being moved will have velocity like any other physical object. You can use it to make an unstoppable elevator, and nobody will fall through the floor.
-New physics control stuff added to normal physical parts also automatically becomes available for unstoppable parts
-Doesnt bloat the API like part tweening would
-You can toggle the unstoppable checkbox off at any moment and the body of parts will start interacting with the environment. That means you can have lets say a hardcoded path for something, and then smoothly hand over the control to physics like it was controlled by physics only all along (since unstoppable bodies still have velocity and such).
-Motion of bodies will appear ‘physical’ since they are controlled using forces. Of course you can use body___ objects to make it not so if you dont want it.
-Can create complex motion affected by multiple forces without having to create your own physics to apply to the tweening
-Doesnt force roblox to maintain yet another piece of physics code (since youd want roblox to make tweened parts have correct velocity to be useful. And since that velocity is different from normal velocity it might behave differently from real parts which could be a headache)
The property would benefit from a “Body” instance since if two parts are connected to each other, it doesnt make sense for one to be unstoppable and the other not. Unstoppability is a property of the whole body of parts, not of a single part. Giv us body instances plz.
Unfortunately that doesn’t work. There’s no way for the physics engine to distinguish between “forces from Body* objects” and “forces due to collisions”, it’s not like there’s some special “collision forces” outside of the normal force application, after resolving penetration collisions are handled using the same forces that everything else is.
Also, what you’re suggesting is just a really bad hack to replace the lack of collision filters on Roblox, which is what you really want in all of the cases that you mentioned.