Map Development - A Disturbing Find

Help and Feedback Building Support
#1

Hello developers,

Today I come to you yet again in dire straits, and I need your help. Over the past few months, a group of 5 builders and myself have been working on a new game. I’ve told them all to use 0.2 scaling. 0.1 sparingly, and 0 only when absolutely necessary (oddly angled walls, etc). I made this rule so buildings will be easier to modify in the future, and having imperfect sizes bothers me. Most of this map was built by them, but I’ve built a few items. The castle shown here being one of the buildings I built myself.

image
image1053×595 687 KB

A significant portion of the map’s buildings (~35%) and props now have scaling issues. For example, a wall that used to be 11.4 x x 18 x 1 is now 11.32 x 17.873 x 0.993. This is causing problems when we want to come in and modify a building. I’ll find individual props with these issues in intact buildings sometimes. I’ll also find frequently that groups of parts in the game have been made into unions, usually causing many problems as well with scaling and positioning. My suspicion is that someone on our team is using a plugin that’s causing these problems. We’ve also had an issue where someone was using a plugin which inserted a virus script into a random part in the workspace. It was a “shift to sprint” plugin a builder was using.

What do you think? Is there anyway to right this wrong other than redoing these buildings? Will rescaling them work at all? Do you think it’s a plugin doing this? I don’t want our entire map to eventually be ruined by these issues.

10 Likes
#2

What you can do:

  1. save a local copy of the latest version of your place.
  2. If you’re the owner, go to the game’s settings and pull up an earlier version of the place (before that problem began to pop up).
  3. Copy the map items from the old place to the newer one.
3 Likes
#3

Is it just the stuff other people built, or were your builds also affected? The weird sizes I thought may have occurred from parts getting adjusted at some point using the ResizeAllign plugin, but that seems unlikely by your description. I can’t think why or how someone would intentionally adjust the measurements such a small unneeded amount, assuming it was built by your requirements to begin with.

If you think a plugin is causing the issue (especially since your place was infected by one), you might want to consider having your builders temporarily deactivate the plugins that aren’t essential to what they’re working on, or at least ones that aren’t largely used and reputable.

Rescaling is a solution you can try:

Use Percentagecalculator’s Percentage Calculator #2 to find the correct percentages to use for rescaling. Example being:

“11.32 (current incorrect size of X) is what percent of 11.4 (original correct size of X)”
The answer is 99.47368. Subtract that from 100 and you get .52632, so scale up using 100.52632 as your percentage.

Undo and Increase or decrease the percentage a small amount then try again if it doesn’t work perfectly the first time, like if you end up at 17.999 instead of 18

The only other solution I can think of is to search previous versions of the place for the originals.

Sorry I can’t help out more than that.

(I’d recommend in the future using .25 as a base increment also.)

3 Likes
#4

I built a few of the buildings on this map. I do know that some of the builders on the team use Resize Align. Does that cause issues like this?

2 Likes
#5

It’s a great plugin I use often, used primarily to fix gaps by resizing one or both parts together. It wouldn’t cause an issue like you’re experiencing, or be used in a way where the size of all directions gets changed a very very small amount.

3 Likes
#6

I did this also. I built a town with a friend. We both used .2, .1, and .05 sometimes. Yet, almost every part now has positions that have like 4-5 decimal spaces now…

3 Likes
#7
  • Are you using version control? If so, this can be used to pinpoint exactly when the problem began, or how a model changed over time. It can also let you recover pristine copies of models.
  • Are your files saved as rbxl or rbxlx? Unlikely, but there may be a problem with how the file format is serialized.
  • Are these files being processed by any programs (e.g. Rojo)? Such programs usually have a 3rd-party serializer, which may be misbehaving.
#8

Hello. I’ve never spoken to you before but I wanna say I played your game about zooming through space many years ago and I loved it. I think it was called Hyperspace. Anyway,

  • I do have the versions available to look at on the website. The problem is we’ve made many changes to these buildings over the past few months, so I have to go back to August 1st to grab an intact version of the castle but it still has a broken interior space that I fixed but apparently I only fixed the broken versions, which I have to do all over again.
  • I only save to the website
  • I don’t use anything like that, and these files are simply going through Team Create on Roblox studio to the website.

I just want to know what the root of this problem is. It seems like entire buildings are getting shrank by tiny amounts, but they aren’t models so I don’t know how that’s possible.

#9

Why don’t you try disabling team create for a short time then investigate to see if the issue persist i’ve never heard of a plugin that can cause this only other thing i can recommend besides that is you look through your team members plugins and see if any of them pops out to you as the cause.

1 Like
#10

I’ve notified everyone that plugins are off limits until we get this sorted out. I’m gonna look through everyone’s plugins and see what stands out

#11

If you’re going to look at their plugins, you’ll need them to send you their local copies of the plugins. Plugins can be updated manually, so their version may have code that doesn’t match with the current version.

As far as parts being shifted by unions: I’ve talked with one of the admins in charge of CSG V2 and they say that it’s intentional as part of the V2 solver.

2 Likes
#13

You don’t need to use plugins to encounter this. Studio’s drag tool (the Ctrl-2 one) accumulates error as you drag things. The fancier Transform tool does not, but no one uses it because it’s not intuitive and hard to figure out.

Secondly, rotating a model and then rotating it back will introduce error, even if the rotations are exactly opposite but something other than multiples of 90 degrees. Trig functions introduce rounding errors with each transform. The farther you’re building from the world origin, the greater all these errors become.

Lastly, 0.2 and 0.1 are unfortunate choices for snapping intervals, as compared to, say, 0.25 and 0.125. Why? Execute the following from the command line:

a=0.2 b=7 c = 1.4 print(a*b, c, a*b==c)

Then try this:

a=0.25 b=7 c = 1.75 print(a*b, c, a*b==c)

Take a moment to lament the outcome of these statements. Why this happens is because neither 0.2 nor 0.1 are exactly representable in IEEE-754 floating-point formats. When the depression subsides, I recommend that you spend a couple hours of your time writing a part quantization script. This is a bit more work than it sounds at first, because of how you have to treat non-axis-aligned parts. If buildings are contained in Models and are not world-axis-aligned, you can choose a primary part that represents the axis of the building, temporarily set it to Identity rotation (Model:SetPrimaryPartCFrame(CFrame.new()), quantize the position of all parts in the model that are axis-aligned by direct CFrame setting, then rotate the building back into place.

Run a fixing script on a copy of your place, and save backups. Such an operation is not always easy to just Ctrl-Z undo. You will also realize after you run a script like this, that there are some types of parts that you have to special-case (parts that should not be quantized).

Understand that if you quantize a place to 0.2 or 0.1, some values still might not show as exact multiples of 0.2 or 0.1 because of the aforementioned limitation of floating point.

1 Like
#14

So you’re saying these floating point errors compile not just with position & rotation but also scale?

Why would it be happening for only one of our developers and not the rest? And I can understand these issues occurring with position & rotation (simply moving them does that sometimes), but how would this happen with the scale of all the parts in an entire building?

#15

Not sure if this will be helpful to this specific one. But it could also be applied to scale down buildings using division.
What i like to do when i turn miniature buildings into big ones is that i get a part and i use it to see how many studs tall it is, then set that as the grid size. So say the building is 14 studs tall, and i want it to be 140 studs tall. All i have to do is set the grid to 14 studs then scale it up 10 times.

#16

I have not seen this problem happen with scaling a single part, but if one of your builders scales Models, that could easily account for it. Errors in rotation will also be magnified by scaling, so if something was rotated and ended up just slightly off axis w.r.t the model’s bounding box (or primary part), it won’t scale perfectly anymore.

For issues of gross scale problems, it’s definitely worth finding out what build tools the affected builder uses. It doesn’t require a plugin to get weird position and size errors over time, but of course a plugin could contribute and be the root cause. But general building workflow should also be considered. Like, is there a builder who regularly rotates whole buildings and then scales them (intentionally or accidentally).

In general, when using the Ctrl-3 scaling tool on a model, with an increment like 0.2, the increment is applied to the longest side of the bounding box, so only the dimension of a part that is the full width of the BB along that axis is going to scale by the increment, and only along that axis. All other times (including nearly all real-world use cases, scaling of the parts inside the model is by some other increment, their size in the BB’s longest direction proportional to the BB size in that direction IIRC).

Your example of 11.4 x x 18 x 1 becoming 11.32 x 17.873 x 0.993 is a pretty uniform loss of ~7% on all axes, which suggests scaling of a part inside a model that did not fill the model or was rotated a tiny bit.

1 Like
#17

If they’ve resized anything (shift-clicking on one of the scaling circles) then it won’t scale with the increment. Unlikely, but if things were found to be too small this might’ve caused the issue.

1 Like