Quantum Mechanical Rules Rule!
Those prone to flipping and rotating Forge's building blocks around their various axes have noticed that after a save and quit, the blasted slabs, partitions, and chutes occasionally end up shifting around and gettin' all "jiggy with it" (to invoke the parlance of 1998). So, just what maniacal and twisted conspiracy scheme have you unwittingly stumbled into, both literally and figuratively? Step into our office.
Well, "our office" is a bit of a stretch. We roped Jon Cable into it, our resident really smart guy who can do maths and such. The next portion of the update is on him. If you're interested, here's the explanation of exactly what's going on, and what you can do to smooth out your Forge experience with Sandbox.
Enter the Engineer
The Problem
When using double walls (or some other objects) to create a "floor," sometimes the objects become "bumpy" after saving and reloading the map.
The Cause
There are a near-infinite number of possible orientations that an object can be placed in. While you are editing a map, the objects are allowed to be in pretty much any orientation. When we save the map, we quantize the orientation in order to save space in storage. What this means is that the orientation you get when you load the map might not quite be what it was when you saved it.
Specifically, we store what direction the object's 'up' vector is pointing, and a rotation around that vector from its default position. When you first create an object in forge, its up vector is pointing straight up, and its rotation is zero. If you leave the object in a straight-up position, we use a special quantization method that preserves more precision for the rotation.
But if you tilt it (on its side, for example), then more of the storage space has to be used for that direction, and the rotation can lose precision. What this means is that when you are creating a floor out of walls, it's using the less precise method. The good news is that it's usually easy to predict which way the quantization error will go.
"Why can't you fix this?"
This problem is really inseparable from the way we store Map Variants on the disk. If we change the way the maps are encoded, then all the content saved in the old method could become invalid. It's a complex problem, and complexity means high risk. And risky changes are not something you want to make in a patch to a console game.
The Forge engine was built before we ever knew that maps like Foundry and Sandbox would exist. And this problem, of course, has been present since day one. It only now became apparent because people are building truly amazing maps and demanding more fidelity out of Forge.
"How about some good news?"
As outlined above, you should leave objects pointing 'up' if you can. If possible, create your floor out of double boxes instead of double walls. No effort, no bumps!
If you must use double walls for the floor, pay close attention to the location and direction of the helper gizmo (the blue/white orb that shows the origin of the object). When saved, walls placed horizontally tend to rotate such that the "forward" end of the gizmo is pointing slightly downward. You can use this to your advantage by placing walls that are end-to-end rotated 180 degrees from each other, so that both edges will be either high or low. Walls placed side-by-side should have the same gizmo orientation. See the following diagram:
Blame Stosh
.