Please expose the concept of a "Body" (of parts) to us devs as an instance

A body is a set of interconnected parts welded together. They act as a single rigid body. The Body_____ objects act on a body, not a part, even though a single part is a body if not connected to anything else.

It would make a lot sense to expose the concept of a body as an instance (one without the Parent property):

-Body____ objects act on a body. It would be logical for that body to actually exist on the Lua side.

-Could provide access to:
*Center of mass
*Connected parts
*Joints
*Velocity/RotVelocity/Position of body
*Allow applying forces directly to the body through some means instead of having to mess with Body____ objects
*Allow control over which machine the body is simulated on (fully on server/client distribution could be valid enums)
*Body CFraming. Model CFraming is kind of out of place, because what people want to do is CFrame a body, not a model, most of the time. Throw in some CFrame tweening methods as suggested in another thread.

-Could be used as a base for adding advanced features later on
*Grids that exist in the local coordinates of the body as opposed to world coords (For simulating fire, lighting, fluids, whatever. Those work better if theyre in the same coordinate system as the thing they are applied to)

[edit] -Ability to set the body as ‘unstoppable’. This would make the environment not affect the body, but the body still affects the environment. This can be used to code elevators or some kind of scripted sequences, instead of using CFraming to make them move. The body would basically ignore any forces applied to it from outside sources (not including Body____ objects inside the body’s parts)

-Any other body specific parameters like the importance of that body (so certain objects could be prioritized in networking or physics)

I feel it is an essential addition to provide more control over the physics and the structure of our worlds, because currently from the Lua point of view there are only parts, with the connections between the parts left kind of blurry.

[edit] It could be accessed something like
local body=BasePart:GetBody()
or
local body=BasePart:GetPhysicsBody()
or
local body=BasePart.Body --this might break some random script

1 Like

Someone answer? ._.’

1 Like

Why not just add some of this API to the Model instance?

I don’t think sticking this onto the Model instance would be a good idea. Having it a method of JointsService or Workspace that is something like GetBodyFromPart(), which you would give it one part of a body, and then it would return the instance Radio described.

Because a Model isn’t necessarily a Body and a Body isn’t necessarily a Model.

The word you’re actually looking for is “assembly”, although it doesn’t work exactly as you’re thinking.

Each “assembly” represents a collection of parts that are physically connected via joints. Assemblies are the “thing” that has a concept of which client it is being simulated on, and stuff like that. However, each assembly may contain multiple “bodies”, which are the actual rigid-bodies that have properties such as Center-of-mass, velocity, momentum, etc. So, all of the requested properties that you’re asking for don’t actually live inside the same “thing” on the C-side.

Assemblies are actually sort-of exposed already although not as first-class objects, if you use part:GetRootPart / part:GetConnectedParts you can find out what all parts are in a given assembly. Actually exposing them as first class objects is a bit tricky, because what do you do when an assembly splits into multiple pieces? Which pieces go into the existing assembly and which pieces go into the new assembly? What happens when you join two existing assemblies using a joint? The old assemblies don’t exist anymore, only a single new one does, which contains all of the things that were in both old assemblies. On the C-side assemblies are more of an ephemeral construct used by the physics engine than anything else, it’s not like other objects game objects like humanoids are holding onto references to them.

I’m not convinced that there is actually a good way to expose them.

1 Like

Splitting and joining of assemblies/bodies shouldnt be a problem, because they dont really need to be stored.

They would probably be used such that you get the instance, call a method or two and then ditch it.

For the cases where you do want to store them (I can see that happening for optimization purposes and such), there could be events such as
assemblySplit (passes the two resulting assemblies to the connected functions)
and
assemblyJoined (passes the new assembly to the connected functions)

I was thinking of a body as a single rigid body though, since I have always though of bodies connected through a force based joint as not really connected (are two objects pulled together by gravity connected?)
But I can see why the concept of an assembly is used instead in some situations (physics distribution especially)