I’m working on a game with my friends, and we are using Surfaces for their visual look since we are building with a restricted 2007 style. We are not using them for any functional purpose since the place is anchored, and actively remove Snaps if one of us hasn’t already disabled surface joining in studio.
Since our Surface use is non-functional, we will not be affected by the change mentioned here, but with Surfaces being phased out entirely in the coming months, what can we do to recreate them? Normal mapping is not available for Textures at this time, so even if we upload the current surface textures, we can’t recreate them completely.
Mind leaving Workspace:JoinToOutsiders("Surface") as-is? Or provide an identical alternative? I still like to use the legacy surface weld feature to build things with, and I’d keep the old versions of the Studio tool plugins just to keep the feature.
My reason is that I don’t want to have to move assemblies away from static objects to prevent them from welding with the all option as I’m trying to build them. I’d rather use surfaces to define which sides weld with what. For example, sliding doors made of multiple parts in their frames.
Also, changing this particular feature would change the welding behavior of many legacy building tools, including Clonetrooper1019’s deliberately classic build tools.
Why is this feature in the books for being changed? I don’t see a reason for it if newer developers are likely going to come across the old surface behaviors (with MakeJoints in Library scripts) sooner than they will this particular API.
Could you further explain your use case for needing joining and non-joining surface types? The purpose of the WeldConstraint was to make this joining behavior more explicit: you choose what connects to what. You don’t need to worry about what the surfaces of things are, or if they are touching or not.
Imagine assembling a huge destructible building, or a complex door, or something like that, and then imagine manually putting a weld constraint between every pair of bricks, while with surface-joining you could just make a brick, duplicate it, and stack the copies on each-others’ sides. In the case of complex doors, you can avoid it welding with the frame by adding weld surfaces that are not touching the frame.
WeldConstraints are useful for welding intersecting or otherwise not-exactly-touching bricks, but I find it easier to weld numerous bricks together with surfaces.
If I want total control over how a thing welds together, I know where to find the option, but I usually don’t. I usually just want to guide how a brick welds with its neighbors.
Before I forget, here’s one recent door I needed to use legacy surfaces with to avoid welding to the frame while constructing it.
My game uses studs to have a retro-styled theme to it. It has absolutely no functionality, but it’s a major part of the game. Your post says it’ll exist as an aesthetic, but also says you will be slowly phasing out Surfaces all together. Will Surfaces still exist as an aesthetic in the future? Should I be worried?
The WeldConstraint tool allows you to select all of those blocks in your description and weld them all at once. You simply select the parts that you want to weld, and if they are touching then a WeldConstraint gets created.
For your door example, you should just be using HingeConstriants (and you only need one in this case). The Hinge/Motor surfaces are legacy. And surface joining can be just turned off.
Oh. I didn’t know that. Ima try doing a side-by-side comparison. This might be easier to do than changing surfaces around!
One more concern I still have is with the JoinToOutsiders being changed. For nostalgic reasons, I’d still like to be able to use building tools and games that were made with legacy surfaces in mind. I don’t see a reason to alter all those building tools that depend on this API. Mind leaving it the way it is since MakeJoints is also being left untouched?
I will really miss all of those surfaces. Well, I guess Studio is just becoming for experienced people. I’m just getting confused over this whole constraints stuff, it almost seems like us, less experienced people will have to be wasting hours and hours in learning just to make something like a car, this is not a great change, but I can see why they are doing this.
Edit: After seeing a lot of negative posts, I can really agree that this change will destroy most of the things. First of all, just making surface GUI disappear won’t make no impact, it will make a major impact in most games. It’s going to be impossible to stick with constraints for me, surface has always been a part of my life in Studio.
Just because you don’t understand something doesn’t mean others won’t. In fact, it is better for new developers to come in and learning constraints rather than surface types. Surface types are a legacy of feature in which they are very limited and confusing for new developers. Using a WeldConstraint as an example is much simpler and faster than it ever would be with surface types.
In addition, most front-page games don’t utilize surface types anymore. The ones that do most of the time only do it for visuals, and Roblox does not plan to remove the visual aspect of part surfaces.
I’ve seen these posts quite often about confusion with the constraints. However, this is extremely problematic. Nobody is specifying on the confusion is and it doesn’t help Roblox engineers make constraints easier to use.
However, do make sure to look at the tutorials on the Developer Hub. For example, here is an article on how to easily make a car system using constraints. This car system will function a lot smoother compared to cars built using legacy surface types. https://developer.roblox.com/en-us/articles/building-carkit-1
I would implore you to continue to move with technology as legacy features are removed due to being limited and outdated. Innovation should not be stifled in favor of those who refuse to use new systems because they don’t want to take the time to learn how they work.
