Normally when something is deprecated there’s a replacement for it, it’s just useless, or it’s so old, bad, and broken that it’s deprecated, so why was GetModelCFrame deprecated? It’s not broken AFAIK, it’s useful, and there’s no replacement for it. Sure you can manually loop through the parts and calculate the center, but that’s tedious and the reason GetModelCFrame() was even created.
Use Cases:
Create a explosion effects around a building being destroyed (think Age of Empires fire but randomly placed instead of manually drawn sprites). I would need to know the extents and center of a model to know where to spawn mini explosions
Generate box collisions for a model (e.g. a bench) with an invisible part placed at center of model and same extents as model so that 100s of detail parts can have their collisions disabled for improved performance
Create a dragger for either in-game or Studio building that rotates a model around its center, similarly to the R/T keys in Studio
Determine how far a player is from a gate model to know when to auto open/close it (for performance reasons I’d use a PrimaryPart, but I need to know where the center is to place it there)
As mentioned in the last use case, PrimaryParts can be used to find the center of a model, but only if the PrimaryPart is at the center of the model. If the model was built off-grid, I’ll need a way to center the primary part on the model. In some cases where the center is only temporarily used (such as creating a box collider for a model), a PrimaryPart would just convolute the process since it’d be deleted shortly after, so it is desirable to be able to find the center without a PrimaryPart.
Benefits of resolution:
If Roblox resolved this problem, it would save me the need from having to rely on deprecated APIs (GetModelCFrame) or re-implement an existing feature from scratch by manually computing the center.
PrimaryParts are not related to the model’s center at all.
“Well why don’t you just create a primary part at the center?”
What if it’s off-grid? You have to generate it. How do you know where to place the primary part after scaling it with GetExtentsSize? GetModelCFrame!
It returns inconsistent values depending on the positions of the parts. That’s reason enough to deprecate it. PrimaryPart is the solution. PrimaryPart gives you a handle that your code can use to move the model.
[quote=Echo]PrimaryParts are not related to the model’s center at all.
“Well why don’t you just create a primary part at the center?”
What if it’s off-grid? You have to generate it. How do you know where to place the primary part after scaling it with GetExtentsSize? GetModelCFrame! [/quote]
The model center doesn’t make any sense from a code perspective. You could use that to generate a bounding box and that’s about it. I did read what you wrote, and I decided it was silly. PrimaryPart is a much better solution in 99% of cases where you want to move a model around.
Want to position a map? PrimaryPart.
Want to position a gun into the character’s hand? PrimaryPart.
Want to locally adorn detail to a replicated chassis? PrimaryPart.
Want to generate a bounding box? GetModelCFrame.
These are all things I’ve done in the last two months. PrimaryPart is objectively easier to work with because it exists at a static, controlled position.
Ethan, GetModelCFrame() is not for moving models. It’s for reading the center of a model. Of course I’ll use a PrimaryPart when I want to move models, though I’ll still have to generate that primary part with GetModelCFrame() .
*and rotate a model about its center
*and get a player’s distance from the model (you’d have to position the PrimaryPart to model:GetModelCFrame() to be able to get the player’s distance from the model if you were thinking of using PrimaryPart)
*and prevent yourself from spamming your game with invisible dummy parts to use as PrimaryParts just because you need to access the model’s origin
and for the bounding box, not only do I use it for collision boxes around my models, but I also use it for generating selection boxes around models
That’s a given, but it’s discouraged usage – otherwise it wouldn’t be deprecated. Use of GetModelCFrame should not be discouraged – there’s no better alternative, and it works perfectly fine for me (don’t know what Ethan is going on about when he says it doesn’t work)
I’m sure it’s not a hard thing to fix the inconsistencies.
As @EchoReaper stated, PrimaryPart isn’t the same thing.
I use GetModelCFrame all the time, because PrimaryPart doesn’t always achieve the same thing. I shouldn’t HAVE to put a part that is the size of the entire model inside the model and make it the primary part to get the origin of the model.
As I see it, GetModelCFrame wasn’t created with the goal of computing the center of the model. The model’s CFrame should represent its orientation, just as all CFrames do. It doesn’t really make sense for a model’s CFrame to depend on the orientations of its children, which exist in its object space.
CFrames are for doing coordinate transformations. That’s much more specific than just computing the center. In the case that, say a small part flew off of the model, GetModelCFrame would be altered greatly because of the way it’s computed. That’s not really desirable for a CFrame, and that’s what Ethan was getting at when he said it was inconsistent.
I still don’t understand. Someone’s code breaking because they expected an unanchored model with no joints to stay together sounds like faulty human logic instead of a problem with GetModelCFrame. GetModelCFrame being affected by far off parts is not incorrect. By definition, something’s center will change when you push out the bounds. What you’re describing is like the problem of median and standard deviation. We don’t hide median behind closed doors in math though because it has its uses, just as GetModelCFrame does on ROBLOX. I want outliers to affect the center in certain cases.
The behavior of GetModelCFrame is not incorrect, and it should not be deprecated. Any problems resulting because of what you described are due to people using GetModelCFrame outside of its designed function, and not because there’s anything wrong with GetModelCFrame.
