Gosh I remember my first build was joined together with surface welds in my first game.
Other than that it was great to see all the Roblox technology evolving and getting better over time. From surface welds in 2017 to weld constraints in late 2018 to late 2019. Welds were (and are still) too confusing to manage for me back then, and WeldConstraints have the most convenience for me and were literally a million times much more easier to work with. Just attach a Part0 and Part1. No C0 or C1 properties either to waste time scripting up. And the best thing is, weld constraints don’t break upon manual movement through scripts! This was extremely handy when i needed to make some sort of custom clothing “morph” to attach to players’ body parts, and allowed me to make better looking Tools!
wait, Part surfaces?
I haven’t used those in a while, makes sense they are testing removing them now, because I have used WeldConstraints for moving parts and anchors for non moving parts for so long that I have had no use for those for a long time.
I still like the old surface behaviors. I also like using weld surfaces, as WeldConstraints are hard to use to build destructible structures and the all-or-nothing surface behavior makes it hard to avoid making unintended welds. This can get annoying when building moving things next to static things.
Is it possible to preserve the old surface behaviors when they are phased out?
Also, how does Roblox plan to full remove the legacy joints system? It looks like to do so, you’ll need to either break old games, or leave some APIs to maintain compatibility, which likely includes leaving the surface types on Parts for use by MakeJoints.
It seems likely Roblox will choose the latter, so why not leave the legacy joints system as-is? It would be better if the legacy system was functional and not left in a messed-up state from being part-way removed.
I still use the surface welds so that when all the support to the structure is blown up, not sure how to replicate this behaviour with weld constraints.
This all seems like it’s for the best. I always felt like the surface parameter APIs under the BasePart class were bloated.
With that said, it isn’t easy to detect when surfaces are adjacent to each other or where their contact points are. If surfaces aren’t part of the future, it would be nice if we could emulate the existing behavior practically from Lua so it doesn’t have to be built in.
I’m currently utilizing JointsService:ShowPermissibleJoints in Welcome to Roblox Building to visualize where two surfaces meet so its easier to see how the model will weld. I use JoinToOutsiders, so surface types shouldn’t be an issue here.
My concern here has more to do with the JointsService’s deprecation, I’m not 100% sure if I should expect these surface outlines to continue working in the future. They already crash Roblox on rare occasions, and there’s no practical way to emulate this behavior in Lua without a lot of annoying work.
(I haven’t been able to reproduce this crash consistently, feel free to check any crash dumps from PlaceId 2897155393)
As for Super Nostalgia Zone, the change being made to JoinToOutsiders will likely mess up some of the mechanisms in the game that are relying upon legacy hinges and motors. I can definitely work around it though, I’ve had to redo plenty of legacy things from scratch using modern components already.
Yes! Setting SurfaceTypes to smooth when creating parts is tedious and hurts performance (slightly).
SurfaceTypes are building tools that bloat the API, just like what FormFactor once was. I’d be okay with SurfaceTypes being completely removed from the client long-term, even though it might harmlessly affect house wall data on one of my old projects.
I’d like to hear from an engineer how removing SurfaceTypes might affect client memory and performance. 
Related: Instance.new("Part")/Studio->Insert Part Inconsistencies
Just use the anchor tool.
If the welds play an important role in your builds I’m sure the people in the Development Support subforum would be glad to help you.
I’m really glad that it won’t be breaking any older games. Anyways I think this is a pretty good update as these( at least in my experience) are rarely used and I found them quite a bit confusing at times.
Aren’t you able to create a collapsing tower using “glue surfaces” ?
Yes but as stated by this announcement their functionality is slowly being phased out, and an alternative is needed.
Allow me to clear up some things. First, please note that since this is being tested as a beta feature, there’s no guarantee that the currently planned changes are the ones that will be released globally. We want to hear your feedback and adapt things to make sure we change happens as smoothly as possible.
That being said, thank you for raising your concerns! Our goal with this change is to simplify surface joining for new users while still allowing people to instantiate and use all the legacy joints. We will never totally remove these joints as old games still rely on them.
Workspace.JointToOutsiders uses the new surface joining rules, creating only ManualWelds on all surfaces, except for the different Rotate joints when using a Hinge, Motor, or SteppingMotor surface.
MakeJoints, will still create all the old joints, following the old surface pair rules. Our hope is that MakeJoints can suffice for all legacy needs, but let me know if that’s not the case! And of course, try the change out when released in beta and report back with any issues.
My concern with this change is regarding wheels. I have what may be the #1 most popular car chassis on roblox, and I’m concerned that this will break them. The cars use ball wheels and classic surfaces to hold the model together.
Consider this sectional view of a car:
- Red: part shapes
- Yellow: hinge/motor surface (located on wheel)
- Light blue: bounding box of wheel
- Dark blue: joints concerning
The wheels on the cars may be touching parts of the car’s body in various places, either on top or on the side of the wheel part’s bounding box.
Assuming the joint type “Unjoinable” is removed in addition to all the others, there’s nothing telling the roblox engine not to weld the wheels to the chassis. Any kind of “smart algorithm” will fail too, as without the Unjoinable type, there is complete loss of information as to the developer’s intention regarding assembly vs. mechanism.
My second concer is regarding part orientation. After the removal of any orientable features on Studs (namely the R), the only way to know the orientation of a part is using the Surface selector or by adding surfaces on known sides.
Using the surface selector to find the Front side of a part
Knowing which way a part faces is critical for many systems in Roblox, the Front side in particular, although there are a number of systems that use other sides. For example, nearly every single vehicle that I make uses the Front of a part as the Front of the vehicle. The wheels’ Right side must face the Right side of the vehicle. The headlights’ Right side must face the Front of the vehicle. And so on. I am hardly the only one nor even the first to come up with an orientation system for models, and removing the orientation from Parts will make Parts as useful as Klein Bottles. They are both non-orientable solids!
NWSpacek’s Coaster Creator Plugin
In my roller coaster plugin, I use surface types to tell the user which way the roller coaster is facing. In this image, you can tell the roller coaster is facing up, and pointing left. The studs surface type indicates the upward direction of the roller coaster, and the Hinge surface type indicates the front direction of the roller coaster. Likewise, the bottom of the part has the Inlet surface type, to indicate the downward direction of the roller coaster:
The bottom side of a roller coaster
I considered decals, but they tend to be ugly, and I don’t like how they can get drawn in the incorrect order sometimes, and SurfaceGuis don’t look that swell either given their lack of anisotropic filtering. There is no other “robloxic” way to communicate this info to the user. Since the beginning of roller coaster building on Roblox, Studs has been used to indicate the Binormal axis, Inlets the Negative Binormal, and Hinges the Tangential axis.
Without surfaces, using the tool is a disorienting mess:
The ??? side of a roller coaster
Which way is this roller coaster facing? Left or right? Is it facing right-side up or upside down? Can we use the Surface properties to determine which way it’s facing? Without surfaces and without the Surface properties, it’s impossible.
My coaster plugin is probably the #1 roller coaster building tool, with over 5.5k takes. Although updating the tool to use ugly decals or SurfaceGuis is possible, I expect most users won’t understand this and send their vitriol directly to my inbox. Not something I want to have happen.
I do agree with some of your points, but I also think there are ways to circumvent the issues you mention. For example, to know where the track is facing and if its up or down, you could add a simple arrow decal on the top or even use a decal of the intlets and studs. For the car conections, you could use hinges and ballsockets as alternatives. So, whilst you would have to convert stuff; I dont think this will break roblox coasters. And to make it so certain parts dont collide, you could use the nocollisionconstraint or collisiongroups.
I’ve not used that car chassis for years, and I don’t do much with roller coasters either. I’m talking about the tens or hundreds of thousands of users who use my cars in games created by junior developers who want some cars for their new city group. You don’t need to be telling me how to use the Roblox engine, you need to be telling those junior developers.
Your chassis should be fine. The Hinge will still create the Rotate joint, and the spheres can never surface weld, regardless of surface type. You’ll be able to verify this though tomorrow with the beta release.
As for the orientation issue, you can use Attachments with Visible = True to mark the orientation on the part, even in game.
Turning on Constraint Details will provide even more info with Attachements
You could also change the way the roller coaster is constructed to make orientation less ambiguous.
However, after this change you will still be able to see and set surfaces on plastic parts, so for now this will be totally unaffected.
Can’t wait to see how all of these changes affect simple building.
I’m kind of excited to see what new things I can make. I just hope developers don’t lose their creations from this.
By surface-weld I specifically mean creating ManualWelds. A sphere will only create Rotate type joints if it has the corresponding surface, and never any kind of weld. By looking at your diagram, the wheel will only create the RotateV on with Motor surface, and nothing else.
Attachments can be inserted from the Create dropdown in the Constraints section of the Model tab, and simply clicking on the area of the part you want the attachment to be. The Attachment.Axis will be aligned with the normal of the face you select, but the actual orientation of the attachment is irrelevant to your use case.
You wanted to simply mark a particular surface of a part to know the part’s orientation, just like what the Hinge surface does. You don’t need to see the arrows to do this, and the attachment’s orientation is independent of the part’s orientation.
If you wanted to use the arrows, you could just make the part and attachment’s orientations equal, then the attachment’s primary axis will point along the part’s Right Vector (+X), and the secondary axis will point along the Up Vector (+Y).
Affects new builds in Roblox Studio? How about new updates for the game? Will it make things a little bit hard or no?
I don’t get it what it says much but you mean Smooth Surface will weld?
Sorry if I don’t understand much. I am really shook to why it is gonna be changed when I usually work things with Surfaces.
Personally, I like using surfaces as they are now; While I’m glad thought has been put into the changes, I would prefer to use weld/stud/inlet/etc surfaces as they’ve always worked. Glad to have a heads up on this though!