U can tilt but its wonky and doesnt allow for the same control
…? What?
Could you explain what you mean by this? I don’t think body movers are restricted. Body movers and CFrames also both support vector quantities.
I’m asking about what you’re saying in genuine curiosity, since I’m not too sure what you mean. It can also be confusing for others who read it and don’t see an appropriate rationale or example of what you’re talking about.
1 Like
Generally Body Movers are good for doing alot Basic things like changing a position of an object without going too much into programming CFrames and stuff like this. But to go alot of functionality like control on tilt influence and stuff like that working with CFrames is better, It provides u the programmer more control and Leaves less for the roblox physics to worry about. Not for those who would argue the Physics engine is there for a reason. The engine has been known to be unreliable with alot of things so people tend to create their own solutions with CFrames and Vectors. A general jist would that using CFrames is a better way to go so that u can get the utmost functionality out of your work and really make something unique.
…?
Both are used in or are manipulated by code. Body movers can also be used for complex structures - their simplicity is dependent on your use case, not on the object itself. CFrame is a data type. Body movers apply physics to objects.
Still don’t understand what you mean by this. You as the developer have control either way. There is no more or less control. Just use the object properly.
But those are just data types? You still need a way to apply movement. This is a hover car. The physics engine is involved either way because you’re using parts. What basis are you going off of?
No that’s not a gist, that’s confusing. What do you mean? You can still use a vector with a CFrame. You can still use CFrames and/or vectors while using body movers. Your point is extremely confusing. Body movers are fine.
I think you’re ignoring what he is saying. CFrame is not a good solution for hover cars, or any cars. They can cause issues with other physics, such as the Humanoid. You, in most cases, should use BodyMovers unless you have a specific use case to not use them.
Ive never heard of CFraming having any issues with Humanoid so I would love to see where you got this information from
There indeed are a few issues related to that. For example moving a platform with CFrames wont move the player(s) standing on it. This is why for example jailbreak had to change the CFrame of the player along with their train.
Video demonstration by @fireboltofdeath:
External Mediatl;dr you shouldn’t use CFrame for cars for the same reason your character isn’t loop teleporting forward when you walk.
This is a topic on hover cars, not humanoids, so this is off-topic and irrelevant. Please stay on-topic.
The point I’m trying to make is that this is a hover car, yes? That means physics are a heavy tie in to this system - or any movement system, really. If you’d like to spend many days writing a custom physics engine that “uses CFrame” (which, again, it’s just a data type), then feel free - the backend physics engine is still going to take effect though.
I’m strongly failing to see what point is trying to be proven here or what the issue against body movers is.
You asked a question which he gave a response to.
2 Likes
I just find it more practical and useful to use CFraming to make a vehicle than Body Movers they can be annoying to deal with in terms of their parameters and the Body Movers API tend to change all the time meaning something could go wrong in the future with it. Atleast with CFraming its a more solid solution that has proven to work for many different things.
Can you elaborate on this? I havent seen the body movers “api” ever change much?
Also, the fact that you find using CFrames more practical doesn’t mean using body movers is very bad and nobody should ever do it. They are better in terms of the physics engine, since they actually move parts, as opposed to CFraming which simply changes their location without applying momentum forces or such.
2 Likes
But… body movers incorporate CFrames and vector quantities as well? Body movers are practical and appropriate in a scenario where you need hovering.
Body mover API does not “change all the time”, not sure where you got this information from.
Most of these comments sound like some kind of unsubstantiated bias against body movers due to lack of understanding of how to use them.
And, for the third time, I fail to see what you mean by calling CFrame a solution. It’s a data type, it’s used in methods that support CFrame arguments (i.e. tweening to a specified CFrame goal). CFrame itself is not a solution.
2 Likes
I’m calling it a data type because that’s literally what it is. As for APIs that support CFrame arguments, obviously you’re going to need to feed a CFrame value into it. That’s a required parameter. It’s the same thing like passing a string to Instance.new, that string being the name of a class.
Yes, the methods that support it are available but they aren’t proper solutions. This is going extremely off tangent and is not related to OP’s question about how to make hover cars.
Forces are actually relevant to achieving a hover effect and have been one of the best ways to do so for the longest of time. CFrame appropriately interacts with the physics engine and achieves the desired end effect. They’ve been used in jetpacks (hovering), as a simple example.
No? You don’t need to stack them. Don’t understand what you mean either by “unnecessary hierarchy”. Body movers don’t need to be loaded, only replicated upon first load. It’s not like they’re assets.
Where in this do you see “whole functionalty related to object movement”? Just because something has an instance, doesn’t necessarily mean loading is involved. Replication and loading are two different matters altogether. CFrame data types may have the ability to be applied to methods to achieve methods but that isn’t necessarily appropriate for this scenario. That’s just reinventing the wheel for where body movers exist.
You still aren’t explaining how. Enough chassis and hover items around Roblox and the DevForum use constraints and (constraint) body movers, not “CFrame”. How do they make sense? They honestly really don’t - there’s no point in trying to develop your own movement algorithm or pseudo physics engine when the backend engine is already there and body movers help you perfectly fine with this issue.
Body movers are not restricted. I don’t know what basis you’re working off of when you say that body movers give lesser control over CFrames, this is objectively untrue. This can be proven by enough experimentation and usage.
Why would you use CFrames when there’s SpringConstraints? That’s an example. CFrames are not required in everything involving movement. I don’t know where you’re getting this information from, but it’s not relevant at all.
No? Vector3 also exists.
The physics engine runs on the backend which is comparatively much faster than a full Lua implement of a physics engine, which you can’t even accomplish on Roblox. Even then, this is irrelevant. It doesn’t solve the problem nor does it speak anything about why you think a data type is a better solution than an object meant for these kinds of use cases.
Unsubstantiated comment. Just because you don’t use them for whatever reason, doesn’t mean others don’t hold value in them.
Body movers don’t have any less accessibility.
A good majority of your responses are unsubstantiated biases against body movers or completely irrelevant mentions. Please stop getting off tangent and don’t propagate false facts.
7 Likes
Yes, I am using body movers and yea I am currently changing the Y value. Is it possible that I can use a remote event for the hotkey though?
What do you mean? You should handle the physics on the client of whoever is driving the vehicle, but you can use RemoteEvents if you want.
Oh okay. Just asking though 
Yes, you can use RemoteEvents for the hotkey.
Using RemoteFunctions can also help, I’m pretty sure RemoteFunctions get to the player faster than a RemoteEvent.
That depends on whether it’s appropriate or not for the scenario. RemoteEvents only have a single trip to make for sending the signal to the other environment without depending on any round trip response back. As it relates to a hotkey for movement, RemoteEvents are far more appropriate. That being said, if you just give network ownership of the whole hover car to the client, then there’s no need for remotes at all.
2 Likes
RemoteFunctions are not appropriate for this use case because you do not need a response back from the client/server and I do not believe they send to the server/client faster, as that’s entirely dependant on the client’s latency however I may be wrong.
1 Like
Ah, that makes sense. My apologies then.
1 Like