This is intentional, “snapping is disabled” and what the grid increment is set to are now completely decoupled. There’s even an affordance where if you enter 0 it will disabled, and if you enter something non-zero it will be enabled again, so that no workflow should be slower than before.
What’s the issue you’re having with this?
Not sure if its related but having issues with union colours since this update, unions retaining their negative colour even when UsePartColour is selected
As was stated earlier in this thread, you can not set the MeshId of MeshParts in runtime.
Not relevant to what I said… cloning a MeshPart will keep its ID. You can keep multiple in ReplicatedStorage and clone them at any time.
On larger games it is imperative to store assets on the server to reduce client memory usage and loading times
If those parts are in any way exposed to the client (such as being inside the workspace) their mesh and textures are going to be loaded into client memory anyway. Better to keep them in ReplicatedStorage if the server is cloning them often.
In addition, SpecialMeshes have the distinct advantage of being able to stretch meshes far beyond regular part size limits
Realistically, there should be no use case where you need a mesh to exceed 2048x2048.
and without the expensive calculations that setting part sizes involve.
Sure. Yet the collisions don’t work… so this is utterly meaningless. Size is the second most expensive property to change for all BaseParts, the first being Parent. Not just MeshParts.
These seem to be useless caveats that you brought up simply to defend SpecialMeshes.
You’re looking at old code to support your point- seems ironic.
The old tools were built for simplicity and not for efficiency. The standard for Roblox was far, far lower than it is today.
That’s actually a really annoying change. I like to build in 1 stud increments, and having to click move, press 0, then move, then clicking move again, typing 1, then moving again. Before, I could just disable grid snap, and just move.
You can still do that by checking the box like before. By disconnected now I mean that toggling the checkbox only changes whether snapping is enabled rather than changing what the grid snap increment is like it did before.
Before there was just one value: The grid snap increment. Now there’s two values: A grid snap enabled status and a grid snap increment, separate from one and other.
This is actually more powerful because Studio tooling and community plugins can do stuff like dynamically snap or not snap to the chosen increment depending on whether a hotkey is held (stay tuned for some upcoming dragger features!).
What if i made a building system in my game where players could load a mesh into they’re build.
I cant load all meshes to ever exist on Roblox into replicatedstorage the game would instantly crash every players device the instant they join.
Why would you want a player to be able to load any mesh? Seems utterly stupid, with no real use-case. A building game would have pre-created objects which can readily be placed.
That defeats the entire point of keeping meshes in ServerStorage in order to reduce loading times and client memory usage. Read my statement in my earlier post again as I get the impression you didn’t quite understand what I was talking about.
Stuff in Server-Exclusive services such as ServerStorage do not replicate to the client at all.
There are plenty of use cases, for example planets, using one mesh for a water part for a giant map, and I can go on and on and on.
That is exactly my point. Why use expensive size setting calculations when you can simply change the scale of meshes to very little performance impact especially when collision is not concerned
I understand you don’t use SpecialMeshes, but we are in the real world where plenty of developers all over the site, myself include, use them in part because of all the reasons I laid out above, and hence you have no right trying to tell us not to use them even when you are unaware of how certain services or functions operate.
EDIT:
Why would you want a player to be able to load any mesh? Seems utterly stupid, with no real use-case. A building game would have pre-created objects which can readily be placed.
Same reason as above, reduction in client memory and loading times.
Stuff in Server-Exclusive services such as ServerStorage do not replicate to the client at all.
When did I mention ServerStorage? It is obviously not exposed. Read what I said more carefully.
There are plenty of use cases, for example planets, using one mesh for a water part for a giant map, and I can go on and on and on.
Yet you name two? 2048x2048 is extremely big, more than big enough for both of these examples and more. You just don’t want to accept that you are wrong.
Why use expensive size setting calculations when you can simply change the scale of meshes to very little performance impact especially when collision is not concerned
Unless you are changing the size of a mesh extremely frequently, like every frame, you have nothing to worry about. Changing the size of BaseParts takes literal microseconds… somewhere between 10 and 15 if I recall. If collisions are not important for your meshes, consider disabling CanCollide or changing the CollisionFidelity to something less expensive, such as Box.
You clearly do not understand how meshes are allocated to client memory so let me clue you in. Like I said previously, if there is a mesh exposed to the client in any way, for example if it is in the workspace, if it is in ReplicatedStorage/ReplicatedFirst, whatever, both the mesh and the texture are stored in memory.
Loading times would be the same if a player has a mesh in their building area because it exists in the workspace. If you have meshes stored in something such as ServerStorage, it isn’t magically prevented from being put into client memory either, unless the client never sees the mesh, in which case why is it there? This potentially has a negative effect on player experience because if a mesh is cloned from ServerStorage into the workspace, the player may not have loaded it already and so they will see an untextured model or no model at all, depending on which loads first.
You gave useless false information whilst ignoring the first part of my answer “Why would you want a player to be able to load any mesh?”, because you know that, realistically, there is no good reason.
You didn’t. I mentioned it because I am not talking about putting meshes in ReplicatedStorage to save memory and loading time like you tried to mention. This is why meshes are put in ServerStorage
-Gives a few examples
-Ignores them
-Tries to say that I am wrong despite providing two use cases without explanation
Truly incredible.
To break it down further, I own several games where “2048 x 2048” is in fact not extremely big. One of my maps for example streches to around 86,000 x 86,000 studs. If you think im going to use 42^2 2048x2048 plates for water, you would be sorely mistaken.
Incredible, you just ignored everything I just said.
Allow me to break it down.
I have 100 unique meshes stored in ServerStorage. When the player joins the game. The meshes are not replicated to the client. In order for the player to see the meshes, RemoteEvents are used to request a particular mesh, the server sends information about the mesh back to the client and the client reconstructs the mesh locally.
The reason this is done is so that in use cases where players have no need to load and render and have in memory those said 100 meshes, you can simple choose and select which one you actually need at the time.
I would know because I actually designed this system for my game Aeronautica that has hundreds of unique vehicles. The loading time and client memory is literally day and night before and after implementation of this system.
For someone who is supposed to be a professional programmer you seem to be woefully ignorant of how systems actually work and I encourage you to do more reading and practice. It is good to keep an open mind after all
Let me give you a REAL use-case in a REAL game
the game I’m gonna use in this example is Astrocraft.(It’s a building game where you make spaceships.) In Astrocraft’s ship editor i want to make let’s say a frigate from halo maybe the paris class frigate i could get reference images and use them that would work but is time consuming instead i could load a high detail model using a special mesh with its type set to filemesh with the model id set to a high detail model of a paris class frigate from halo this object has no need to have any collisions and therfore using a meshpart would be completely pointless and hurt performance for no good reason.
(I know the grammar here is bad just deal with it.)
It would be much, much more beneficial for you to keep said ship in ReplicatedStorage and to disable CanCollide, and clone it when needed, than it would be to set up a part with a SpecialMesh. They are not good.
I ignored everything you said? Is that why I answered each point?
Having all of those meshes in ReplicatedStorage is negligible. The use-cases that you mentioned are niche and, quite frankly, bad. 90,000^2 stud map? Laughable. I already explained how the process works and I’m not going to repeat myself- it’s up to you if you want to take the time to read it. So much for keeping an “open mind”. You are extremely rude and clearly very arrogant, and we will have to agree to disagree.
You just completely missed my point by a mile i said in the ship EDITOR where PLAYERS make ships of they’re OWN design i dont even know what that game’s internals look like i cant as a PLAYER add a ship MeshPart into the games ReplicatedStorage because i am a PLAYER of the game i cant do that.
EDIT:
added a blockquote
EDIT2:
The
Point Of View
of a player is heavily implied.
You made no such point, as you failed to point out that fact. You said that you wanted a ship from Halo, of which you would “load a high detail model using a special mesh”. This is very specific, and for such example you would keep it in ReplicatedStorage.
It goes without saying that allowing players to spawn in any mesh is a niche mechanic, but if that’s what you wanted then yes your only choice would be to use SpecialMeshes.
If you truly did read everything I have stated, then you would not be replying in the matter you are.
This is false for all the reasons I stated above. Try again.
Calling them niche, bad and laughable does not make them any less true. They still exist whether you like it or not. Not to mention that those hardly make the bare minimum of a rebuttal.
I already told you and explained to you how you are just simply wrong. Please re-read what i posted above.
I have taken the time to read it, and I have provided both explanations and LITERAL real world use cases why you are mistaken.
You clearly disregard my explanation throughout your multiple posts, refusing to provide even the most simple of rebuttals that go beyond the surface-level “You are wrong, your use cases are wrong, I will not elaborate”, and yet I am the rude and arrogant one?
That is like me saying 2 + 2 = 4, you saying 2 + 2 = 3 and then you are saying agree to disagree.
No you are just simply wrong. Refusing to accept and evaluate the factual explanations and real world use cases is not a disagreement, you are just simply incorrect.
Stop sticking your head into the sand and just read what I have said. You will be doing yourself a favor.
That’s enough, take this discussion to a DM if you want to continue.
so #TrussRights is a success? Great! Trusses deserve more attention 
while i havent found a fix for it yet, someone told me to try setting smoothingangle to 1 for it to fix for now
