The default FormFactor should be Custom so that right out of the gate we can set a part’s size to anything we want. Every time I create a part from a script I end up setting its size to Custom so that I can scale it to whatever size I want. It’d be a whole lot easier if it started out as Custom.
When I create a part, I never want the top/bottom surfaces to be studs/inlets. Generally 100% of the time I’ll want them to be smooth, and that’s a recurring theme with most developers. Even the developers of the animation editor had to manually set the top and bottom surfaces of the dummies’ limbs to smooth:
It doesn’t make sense for them to start off as a surface type that sparsely used, and it’d save us a lot of bloat if they just started off what we want to set them to in the first place.
With FormFactor there’ll be no compatibility issues whatsoever because Custom parts can be any size Brick parts can. With the TopSurface and BottomSurface, the changes are purely aesthetic, so there’s 0 chance of games being broken.
imo in a perfect world, FormFactor would be depreciated in favor of all-around custom while equivalent snapping behavior would be offered in the studio building tools. Vertical size increments just don’t seem like a sane thing to store on a part-by-part basis. That’s just me though
[quote]TopSurface = Studs > Smooth
BottomSurface = Inlets > Smooth[/quote]
Games that depend on those defaults deserve to die.
The only time stud+inlet parts join together automatically is when you use a dragger of some sort and manually drag them onto another part (setting the CFrame doesn’t connect them). The only dragging tools I know of are used with existing parts. I’ve never seen a spawn and move part build tool – you have to move an existing part. It’s safe to assume that the number of games it will break is negligible, if any, and saving a handful of archaic games nobody plays anymore is not worth putting us through the pain of having to manually set Top/Bottom surface every time we instantiate a part from a script.
“imo in a perfect world, FormFactor would be deprecated”
They made a thread on that a while back, but there haven’t been any changes since. We could wait a couple months to a year for something that low-priority to get done, or we could ask them to go into a settings file and change the default FormFactor which would take no more than a minute.
local SurfaceType = Enum.SurfaceType.Smooth
local Surfaces = {"Back", "Bottom", "Front", "Left", "Right", "Top"}
for _, Surface in pairs(Surfaces) do
Part[Surface .. "Surface"] = SurfaceType
end
Oh, oops. I thought Lego was quoting something you said on this thread.
[quote=Programmix]local SurfaceType = Enum.SurfaceType.Smooth
local Surfaces = {“Back”, “Bottom”, “Front”, “Left”, “Right”, “Top”}
for _, Surface in pairs(Surfaces) do
Part[Surface … “Surface”] = SurfaceType
end[/quote]
Pretty sure that’s a little over the top for something that’s normally 2 lines to fix.
You can make an argument for this specific case, but you’re going against a matter of principle, which is that default values absolutely cannot change. The best you can do is argue that the current defaults somehow have a significant negative impact. So far, they come off as a minor nuisance, which isn’t very convincing.
Can I argue that a ‘default brick properties’ setting should be added to Studio? I want every brick to be the same (SmoothNoOutlines on all sides, Custom formfactor, Anchored) and it’s annoying changing it every time I make a new file.
“Can I argue that a ‘default brick properties’ setting should be added to Studio?”
I don’t think they’ve done that because someone can make it a plugin if they really wanted to
That would be extremely rad, but we’re talking about defaults supplied by Instance.new. It’s fine to change the defaults for objects inserted with studio, because it doesn’t affect objects that already exist. In the case of Instance.new, objects are generated on the fly by a script, so changing defaults here would break assumptions made by the script.
For example, a script might assume Parts are unanchored by default. So, when it creates parts, it doesn’t have a line that says [tt]part.Anchored = false[/tt], since that would be redundant. If we go and change the default Anchored to true, then suddenly all the parts generated by this script are anchored for no obvious reason.
That’s an extreme case, and you can argue that properties like FormFactor and Surfaces have less of an impact. But it’s much easier and more consistent to assume that all properties have an impact. There’s also the implicit guarantee that defaults will never change, which allows developers to avoid setting properties they don’t need to in the first place! If a few defaults are changed now, then you can’t assume that more wont be changed in the future.
