I did some tests and attached a repro but it seems that when a BasePart size vector is below 0.1 and when trying to scale at a 1/10 of a decimal it just ends up staying the same size. In the example provided I use a script in workspace that scales all the BaseParts in the Example folder in workspace. Only some of them end up scaling up though in size.
I can no longer scale BaseParts sizes by a small increment via script.
Currently in my game Dinosaur Arcade I scale up part sizes to create seamless growth in my dinosaur models. After a Roblox maintenance on 7/15/21 I’m no longer able to scale up some BaseParts via script. My dinosaurs now look like this:
Expected Behavior
Before the maintenance I was able to scale up any size parts up to the third decimal without any problems through a script. My dinosaurs would scale up normally.
Actual Behavior
The parts end up not scaling up at all. The size of the part stays the same.
This is an example of me scaling multiple BaseParts (MeshParts, Parts, Unions) by a Vector3 of (1.01,1.01,1.01) and the size not changing at all. Which is also in the repro.
Issue Area: Engine Issue Type: Other Impact: High Frequency: Constantly Date First Experienced: 2021-07-13 12:07:00 (-04:00) Date Last Experienced: 2021-07-15 00:07:00 (-04:00)
You’re hitting an edge case that isn’t exactly a bug here: Changing a part’s size by less than 0.001 will not have any effect, and 0.1 * 0.01 = 0.001 so you hit the edge case with the 0.1 size part, but not the larger parts.
You ideally avoid this by storing and updating your target size in the Lua code rather than relying on the current part size (yielding better performance – the part is ignoring these small part size changes for a reason), but if you don’t want to do that, you can work around it by changing the part size twice like so:
However, with the upcoming smaller part size limit, this may become a bug that we need to deal with. We’ll update you with more information after discussing.
Okay, we looked a bit closer and there was actually an unintentional change in behavior.
The above behavior ignoring small part size changes used to apply to MeshParts but now applies to normal parts too when it did not before. Unfortunately this was an unflagged change, so we can’t fix it immediately. We should have a fix for it out on the 28th, until then the two workarounds above apply:
You can store and modify the intended part size separately in your Lua code.
You can change the size to a different intermediate value first before setting it to the intended value when making small part size changes.