Devs pleas fix this.

[LordMaddog]

[DivineEvil]

I'm not sure what the developers can even do about this "problem".  Using the 'match block' function can only adapt the dimensions of a new block to the block that it is placed upon - there's no mechanism to make it adapt the dimensions from any other blocks.

 

I mean no offense, but in my opinion you simply should keep to integer numbers from the beginning of building process to the end, and there's absolutely no point to go into decimals for building anything, including the circular and curved shapes. I have no clue how one can step away from integer values into 5+ decimals apart from simple negligence in the process.

[TheDeadlyShoe]

I have no clue how one can step away from integer values into 5+ decimals apart from simple negligence in the process.

rescaling it a couple times?

[Kamo]

Ouch, modifying rescaled ships and especially pasted block groups sure is a bad idea.

When rescaling a block group, the group's size will be rounded by the Scale Size: so if you have seven 1x1x1 blocks in a X-row, and scale the group to 10x1x1, the seven blocks will have individual sizes of 10/7 x1x1, so 1,428571...x1x1.

Multiply that issue with three dimensions and you'll soon get "stranded" on "Match Block" dependency and forced to make imprecise fixes and endure misalignments.

 

There's also the floating point errors, and I also hate them with a passion...

I don't understand how floating point errors even happen with numbers with no decimals, and even powers of two at that !

It seems the contents of the "block info" dialog are loaded into the block size pointer, then reloaded back to the block info, causing the floating point error to appear.

Of course using numbers who aren't made of additions of powers of two (or fractions thereof) will cause bigger rounding errors due to how floating point variables are stocked (so, for the computer which counts in binary, 0.2 = 0.125 (1/8) + 0.0625 (1/16) + 0.0078125 (1/128) + 0.00390625 (1/256) + 0.00048828125 (1/2048), so happens to be a "real" number with infinite decimals in binary).

 

There should be a 3-decimal rounding rule to avoid the floating point errors, as 0.999999x1x1 blocks cannot house size-1 turrets and aaagh >:(

 

Right now, with hardpoints, I try rounding to the desired value when putting the block when there's only one erroneous value, and when both hardpoint sizes are erroneous values, I add .01 to those values to overcompensate from the error.

[DivineEvil]

Ouch, modifying rescaled ships and especially pasted block groups sure is a bad idea.

When rescaling a block group, the group's size will be rounded by the Scale Size: so if you have seven 1x1x1 blocks in a X-row, and scale the group to 10x1x1, the seven blocks will have individual sizes of 10/7 x1x1, so 1,428571...x1x1.

Multiply that issue with three dimensions and you'll soon get "stranded" on "Match Block" dependency and forced to make imprecise fixes and endure misalignments.

 

There's also the floating point errors, and I also hate them with a passion...

I don't understand how floating point errors even happen with numbers with no decimals, and even powers of two at that !

It seems the contents of the "block info" dialog are loaded into the block size pointer, then reloaded back to the block info, causing the floating point error to appear.

Of course using numbers who aren't made of additions of powers of two (or fractions thereof) will cause bigger rounding errors due to how floating point variables are stocked (so, for the computer which counts in binary, 0.2 = 0.125 (1/8) + 0.0625 (1/16) + 0.0078125 (1/128) + 0.00390625 (1/256) + 0.00048828125 (1/2048), so happens to be a "real" number with infinite decimals in binary).

 

There should be a 3-decimal rounding rule to avoid the floating point errors, as 0.999999x1x1 blocks cannot house size-1 turrets and aaagh >:(

 

Right now, with hardpoints, I try rounding to the desired value when putting the block when there's only one erroneous value, and when both hardpoint sizes are erroneous values, I add .01 to those values to overcompensate from the error.

Well as you can see, OP is building a new station, so I still don't see how one can arrive from integers to decimals. Unless he's copy-pastes fragments of the curve, as if its going to increase the building rate...

[Warrax]

I agree - this can be frustrating - BUT ...

 

There are subtleties in design that can solved with more than one piece ... in my experience - solutions are often borne upon experience - fails and wins.

My BEST advice - never work in scales of 0.05 

 

For instance ... my Tie-Fighter Wing design, which I placed on my Freighter ship, The Jackal.

This build (below) was build solely on scales not smaller that 0.10.

 

 

Jackal Wing Pods

 

 

 

 

 

 

 

 

And ... mounted (close up from the Jackal)

 

 

 

 

All XMLs are linked here in this post

http://www.avorion.net/forum/index.php/topic,2539.msg13053.html#msg13053

 

Cheers  :)

[deep]

I am using Google translation

I am sorry my English is bad

 

More than a year ago, I also had the same trouble

Because I could not make the Millennium Falcon dome on AVORION scale

Decimal point was not enough even though resizing was repeated

 

I do not know the blue print of your station

I can not imagine the shape of a completed round dome

I am happy if this method helps

But there is a problem

This method of deforming the template transcends the decimal point made by the AVORION system

Instead it will be difficult to remodel the dome

 

 

https://steamcommunity.com/sharedfiles/filedetails/?id=971567358 

[MetalLaires]

Thanx to those numbers I can calculate the size and dimensions of my ships inner and outer workings. 1 = 10 meters

Nothing to fix, rather a tool. Those numbers also often change when you rotate your block.

 

I like to see how it compares in size to ships from famous galaxies like macross or star wars trek or eve online or warhammer or....

 

 

 

[Hakkete]

So is the verdict it's getting fixed or not?

[koonschi]

The verdict is, that it cannot be fixed since this is fundamentally engrained into the way computers treat floating point numbers. Some numbers simply can't be displayed in floating point numbers and at some point you WILL get rounding errors, and there is nothing that we can do about it, except for going minecraft-style voxel grid, which is out of the question.

[deep]

 

 

I am sorry my English is very bad

 

Decimal error always brings fatal destruction to ship's build

Micro cracks, micro steps, edge overlap, black lines of shadow effect capture everything.

The ship I am making now does not have the same shape as I made slopes and curves by piling a lot of 2.5 blocks on the port and starboard.

Finally we do not have 50.00 ... lol

 

Blender performs smoothing on jagged edges

It is the final processing of the build of the ship

Is it impossible to adjust the size of the whole block and fill the micro cracks or smooth the rounding of the seam line of jagged blocks?

[Duke Wamba IV]

I ran into the same issue yesterday and today while buildnig a sphere. There are gaps I cannot close. I tried resizing in hopes of a magic cleanup when I resize it to even numbers but to no avail. The even numbers displayed while resizing sets of parts are rounded before display and do not represent the real size. I will not try to build spherical shapes anymore until there is some kind of fix.

[Straybow427]

One possible fix is to allow reshaping by moving corners instead of expanding the entire shape along one axis. Enable the corner grab mode, in which ASD moves only that corner. It is similar to the anchor block choice.