The gap isn't there in the manual positioning lock. Happens every time for certain items and is about 1.6 mm (0.003 blocks).
Tiny gap after item is placed
- philtwice
- Thread is marked as Resolved.
-
are these blocks in the game or planks and beams? if they are pnb do you have the grid on or off?
-
are these blocks in the game or planks and beams? if they are pnb do you have the grid on or off?
Planks & beams, grid off. The gap is actually the same size as the "setp 1" size, which means you have to compensate for it. Here's another example (nothing else is touching the placed plank):
-
In which context do these gaps arise? Or when do you have gaps? How do you build?
I would suggest you use the grid or magnet function. -
Not sure if you were using the snap feature to generate this but if you were than that would explain it. When beams snap on to each other they over lap by 0.01 so you would have to compensate for this in the over all length of the beam. This becomes more noticeable when snapping several pieces in a row and then comparing them to blocks. The gap will become more noticeable.
-
- This is no bug. With the grid you have more accuracy.
I don't see how this could be intentional. Snapping two equal planks implies that they'll be aligned perfectly, yet there's always this 0.0025 block misalignment. Why would the size command be as low as 0.0100 if the positioning accuracy only goes down to 0.0125? Why would this mysterious inaccuracy not show in the transparent preview plank, but show in the placed plank? And most tellingly: why can you compensate for it with the keyboard by just moving it 0.0025 blocks (i.e. "setp 1")?
Put simply, the positioning shown in the transparent preview isn't being used. It's always misaligned by 0.0025 in at least one axis.
As for the grid, it isn't useful here because its minimum size is way too large (0.0625). -
Size command. Explains a lot.
-
Well, unfortunately this comes from some precision issues. The x, y and z coordinates of construction elements are stored as 16 bit ints (i.e. 2 bytes per component), primarily to keep the memory consumption per construction element as low as possible. We will get rid of this artificial restriction in the new version, so this should greatly improve the precision when working with very small construction elements
Unfortunately I'm not sure if we can fix this issue in the current version... the only real solution is to store the coordinates as 32 bit values, but that would require a world conversion
Why would the size command be as low as 0.0100 if the positioning accuracy only goes down to 0.0125?
Originally the minimum value for the setp, setr and setl command was 1, but many people asked for smaller values back then. Actually the 0.01 value can be useful sometimes, as the precision issue really depends on various factors (e.g. your world position).
But I understand that this misalignment can be pretty annoying when it occurs...Why would this mysterious inaccuracy not show in the transparent preview plank, but show in the placed plank?
The preview element uses 32 bit values for its position. When placing the element, it's converted to a 16 bit value (with taking the actual chunk offset into account), that's why there is this difference between the preview and the placed element
-
here is a suggestion. Try oversizing the beam so it overlaps into the other object so no gap appears on either side of the questioned areas. This is how I solved that problem in the past. Beams can overlap not only into other beams but also can be inset into blocks to solve the gap problem.
-
The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.
-
The maximum number of attachments: 10
Maximum File Size: 1 MB
Allowed extensions: 7z, asset, avi, bmp, dds, gif, jpeg, jpg, json, log, lua, mp3, mp4, ogg, pdf, permissions, png, properties, rar, txt, unitypackage, xml, zip
Participate now!
Don’t have an account yet? Create a new account now and be part of our community!
