JayleBreak

They never said what the maximum time is - they should have. 18 hours is the minimum time (its in your quote from the devblog) and they didn't say what determined the actual time which would also be nice to know.

There is a lot of Lua code out there that is based on the motion of space ships following a well defined physics model and also using the Lua API that supplies the current velocity, rest mass, and acceleration (e.g. thrust, gravity). Will the new physics model details be published? Is there any change to the way ships behave in the atmosphere?

People seem to be ignoring this response. Let me say that adjustors are intended to produce TORQUE without producing linear FORCE (thrust). This makes it much easier to to build ships that can point in any direction without inducing drift. I personally like the fact that DU uses physical laws instead of video game physics when possible.

People seem to be ignoring this response. Let me say that adjustors are intended to produce TORQUE without producing linear FORCE (thrust). This makes it much easier to to build ships that can point in any direction without inducing drift. I personally like the fact that DU uses physical laws instead of video game physics when possible.

I don't particularly like some of the answers, like the one regarding ships wrecks which highlight the problem of DU designers focusing on making exclusive content that most players will never bother with or experience, while what the game badly needs is more general content for all players.
 
This is the same issue as with the previous Easter egg hunt NQ did. While cool and clearly inspired by Ready Player One, it was only like 1% of the player base at best that had the time and resources to compete in the hunt. And for the rest it was only something we heard about but did not improve our game experience in any way other that making us feel left out.
 
But.. at least there is something resembling communication here now. Keep this up NQ!

So this is an interesting question which I will attempt to answer to the best of my ability...
 
I'm really fighting the urge to make the "It never was" meme here, but I'm sure one of you will do that for me soon enough.
The reality here is that you never actually were making 1/8th or 1/16th slopes, you've been creating what is the closest approximation of that.
 
In the old system, we used 253 points. In the new system, we use 252 points. This means that in the old system, a single voxel was: 84.3333333333333 (recurring) points.
84.333 also does not divide by 8, 16, 32, or 64.

In fact, in the old system you couldn't really reliably cut a voxel in half to an exact precision, and even a single voxel was not precise. As for example:
84.333 / 2 = 42.166 (in reality this would have been 42 because we don't store decimals) 84.333 / 4 = 21.083 (in reality this would have been 21 because we don't store decimals) 84.333 / 8 = 10.541 (in reality this would have been 11 because we don't store decimals) 84.333 / 16 = 5.270 (in reality this would have been 5 because we don't store decimals) 84.333 / 32 = 2.635 (in reality this would have been 3 because we don't store decimals) 84.333 / 64 = 1.317 (in reality this would have been 1 because we don't store decimals) Sure, the difference is so negligible that you can't see it by eye. But that's essentially the same in the new system as the new pattern looks like this:
84 / 2 = 42 exactly 84 / 4 = 21 exactly 84 / 8 = 10.5 (in reality this would be either 10 or 11 again because we don't store decimals) 84 / 16 = 5.25 (in reality this would be 5 again because we don't store decimals) 84 / 32 = 2.625 (in reality this would be 3 again because we don't store decimals) 84 / 64 = 1.315 (in reality this would be 1 again because we don't store decimals) Now, if we had changed the division to 64 instead of 84.333 you could expect the following to happen to all currently existing constructs:
A loss of precision around 25% Every existing voxel would have lost around 25% of its available detail. You would see huge changes in your designs and most existing designs would likely loose a lot of their detail. Curves would be less curvy, more blocky. But you would have access to a 1/8 slope. With the new division of 84 instead of 84.333, you can expect the following:
The precision loss is only 0.395% Every voxel will look near enough exactly the same, except for a few edge case ones. You likely not see any noticeable change in your existing designs. Curves are still curvy. But your 1/8 slope might be a bit wonky, and its probably better to adjust to 1/7.  In short, the precision cost of changing to 1/64 is not worth it. It really isn't. Trust me, we've looked. It's ugly.

I can already see the new question brewing in your minds: Why didn't you increase it to 128 per voxel?
Sure, this could increase the detail and be more divisible, however it also doesn't fit inside a single byte. So now we are talking about every single construct in the game taking up twice as much in terms of data. And if you feel your cache is big now, you really don't want to know what its like with double the resolution of voxels.  

We could perhaps consider introducing a pseudo 1/64 grid mode further down the road, which would give you a 1/64 grid. However it will still not actually place a vertex at a 1/8, 1/16, 1/32, 1/64 position. It would place it at its closest available position.

Also, to answer the question about the scale at which the tool works. No, it will always be 1.5vx in each direction from the vertices point of origin.
I thought maximum adjustment range on this image made that quite clear, but perhaps that was an error on my part:


I highly recommend you try it before you cast to much judgement on it, as someone who's tinkered with voxels for a long time. I absolutely love using the tool.
I find myself mostly using Grid 2 and Grid 7, using the control key to make bigger jumps.
 
I hope this answers some of the burning questions you all have.
I wish you all a wonderful day, and look forward to seeing what you will all create with it.
- Deckard

I like what I saw in the video (in particular the absence of the actual tool from the field of view). I'm unsure how noticeable the loss in precision will be (no doubt there will be cases where it is noticable).

One cautionary note. Some time ago I created a floor tile pattern with thin voxel "grout" lines separating the tiles (created using the old voxel smooth tool  so I can't give an actual size - maybe 1/32?). It looked perfect until the vertex server was introduced. Everything was (and is) still fine in build mode but on exit the floor was (and still is) a total mess. The grout lines were distorted in some places and missing in others.
 
Any chance the new grid will be treated better by the vertex server?

Logging was/is CRITICAL to my development of an enhanced flight script.
It allowed gathering information essential to understanding how physics in DU work (e.g. air density vs altitude, engine thrust vs. air density, the coefficient of drag etc.). 
It permitted me to identify (and report) BUGS. E.g. the time when the API (correctly) reported the construct mass sans nanopack mass, but the physics engine was including the nanopack content mass (which caused the ship to crash I might add).
So to maintain and improve the flight script I log once a second vital flight information (think of it as my BLACK BOX). Removing this capability is  unconscionable, as will become clear as time (and code changes) will prove.

Logging was/is CRITICAL to my development of an enhanced flight script.
It allowed gathering information essential to understanding how physics in DU work (e.g. air density vs altitude, engine thrust vs. air density, the coefficient of drag etc.). 
It permitted me to identify (and report) BUGS. E.g. the time when the API (correctly) reported the construct mass sans nanopack mass, but the physics engine was including the nanopack content mass (which caused the ship to crash I might add).
So to maintain and improve the flight script I log once a second vital flight information (think of it as my BLACK BOX). Removing this capability is  unconscionable, as will become clear as time (and code changes) will prove.

I'm pretty sure that was in the context of a game expected to have 10's of thousands of active players. Not the handful of players who think they should be able to build a megalopolis by themselves (with an alt or 2 and maybe a friend) which has to be effectively subsidized by a relatively small player community.
 
NQ has to make this game profitable, and it seems they have a business plan (finally!) based on a realistic view of the number of players they can expect to have. It consists of revenue increases (raise the subscription price) and cost cutting (reduce server and network resource usage - still in progress).

The removal of the legacy mining system in favour of the mining unit, and territory taxes are clearly motivated by the need to cut costs. The mining unit change eliminates a whole slew of direct costs. The taxes do not, but do have secondary effects on costs associated with resources that are reserved by players, but unused (especially by inactive players).

I've updated the planetref.lua file so it can be used with the atlas.lua file now being distributed as one of the game files. That file's id field is used to initialize the BodyParameters.bodyId field, and BodyParameters.planetarySystemId is set to 0 (since there no comparable value in the file). The BodyParameters.__tostring method has been updated to format the additional fields that are not otherwise used but are of course useful. You can get a copy of the file from the gitLab repository

Well, I reviewed the discord transcript. In 35 minutes not a whole lot was explained. So it is perhaps not surprising that  my (and other peoples) questions about the voxel complexity restriction was not covered.  I really think the developers know this is going to piss off builders. The impression given when released was that it was really a concern for those who do voxelmancy. Because some (many) voxel boards might be unusable when the restriction was enforced, but that wouldn't happen until the vertex editor was ready. But in my experience, with normal building techniques (i.e. the Deploy  and Copy & Paste voxel tools) you can exceed the complexity limit, and I mentioned that in my question (and in a ticket I submitted too).

In the build I had the issue with, the design was first outlined using Blender, then exported so the projector element could provide the outline for the build, then after progressing well into filling out the outline with voxels - I get this complaint that I would NEVER have anticipated - even today knowing there are limits.

The failure here, is this Q&A would have been a good place to provide guidance on how we can in the planning phases reduce the likelyhood of this happening. And worse, no indication that any information on how this feature defines complexity is forthcoming.

 

If you look carefully you will see its mostly the same small group of players expressing their dissatisfaction with the game over and over again. There are still dedicated builders and players who still quietly enjoying the game in their own way. They just don't generally feel the need to come over to the forums to express themselves probably for fear of the small dedicated group of dissatisfied players who will jump all over them.
 
The other problem is the fact that currently the playerbase is far too small right now. A lot have left leaving the salty ones to throw salt on each other until they give up and leave due to an excess of salt.
 
Don't be put off by the players talking about the making of quanta. Monetary value in game is usually a representation of how well someone is doing. When the ways to increase that value are hampered or changed in some way it causes repercussions.

In short: Percentage of complexity today depends on surface area, but must depend on amount of polygons.
 
(In polygon I mean 2trianles, so 1 cube have 6 polygons or 12 tris) https://en.wikipedia.org/wiki/Polygon_mesh
Yes modern GPU can handle millions of polygons but fps border closer then it looks.
So we have 2 variants of what Chunk complexity can depend on:
 1) amount of polygons
 2) storage on server side
But after some tests it find out that this system based on surface area count.
 
Have two solid cubes full of woxels 31x31x31, left of one material and second if full of chequerboard pattern. And they have the same 37%. (also I was ask NQ-Deckart about server storage of it, the ansver: "For example, the left cube will compress very easily. The one on the right, not so much.")
 

 

 
So it's no seen relative on server storage,
 
Next test on relation of surface area on different types of voxel structures.
Flats and Columns, when they have the same area surface, the polygon count is different. And what we see? When area is 2048m2 they have 267% for Flats and 320% for Columns.
That means chunk complexity is more complicated than it seems.

 
Also some exel info shows as, that the percentage is decreasing with increasing surface area, but with more polygons it's decreasing less.
 

 
And last test is about lags.
Here stable 60fps if look on 135 flat cubes x 6 sides = 810 polygons VS 135 flats of chequerboard x (64x96x2+(64+64+96+96)) = 1702080 polygons and 33fps.
(tested area is analog only of 3.24 L core areas)

 

 
BUT the same 267% complexity.
 

Well, I reviewed the discord transcript. In 35 minutes not a whole lot was explained. So it is perhaps not surprising that  my (and other peoples) questions about the voxel complexity restriction was not covered.  I really think the developers know this is going to piss off builders. The impression given when released was that it was really a concern for those who do voxelmancy. Because some (many) voxel boards might be unusable when the restriction was enforced, but that wouldn't happen until the vertex editor was ready. But in my experience, with normal building techniques (i.e. the Deploy  and Copy & Paste voxel tools) you can exceed the complexity limit, and I mentioned that in my question (and in a ticket I submitted too).

In the build I had the issue with, the design was first outlined using Blender, then exported so the projector element could provide the outline for the build, then after progressing well into filling out the outline with voxels - I get this complaint that I would NEVER have anticipated - even today knowing there are limits.

The failure here, is this Q&A would have been a good place to provide guidance on how we can in the planning phases reduce the likelyhood of this happening. And worse, no indication that any information on how this feature defines complexity is forthcoming.

 

Don't over estimate the value of retaining BPs to people. First, placing a static construct BP on a different terrain then what it was originally built on is usually ... unsatisfying. Second, the constructs that took a long time to build probably require multi XL containers worth of resources (meganodes [which have gone away] of ores and industry [with skills] to process them ). Also, those that require advance elements or rare ores that may not be available for some time.  As a consequence, third, there are those that will be (or already are) obsolete by time they can be used due to game changes just prior to or even after release (weapon rebalancing or ... brakes anyone?). 

It's even harder to start from scratch, especially solo, now than when "beta" first launch.
 
Like many others, I don't really have the desire to do that again.

The nebula has nothing to with realism or decoration. 
The nebula was added to create some contrast between the dark part of space stations and the darkness of space. 
To solve the issue of players colliding against stations because they could not see them. 
 
 
 
Also, being smart has nothing to do with recognizing enhanced telescope images. You need knowledge and experience to do that.
If you dont know that most of the picture details in Hubble pictures were not captured using visible light, but instead, infrared, how can you understand how those images were "changed" so we could see colors we usually cant see. 
 
 
Also, if you are in the middle of a dense (light blocking levels) gas nebula, you will see the nebula it self being illuminated instead of far away stars. 

No what it does and what its principle reason for being developed (yes some people were asking for something like this but that had nothing to do with why this feature was introduced) was to reduce the recurring operational cost of the game to make it more likely that the lights can be kept on. And for those who are about to respond that the lights should be turned off - go play another game, I won't miss you - I promise.

While building, I placed a ceiling using the deploy voxel tool and was warned that the complexity of the voxel chunk had reached 79%. The chunk had almost no shaped voxels (I do detailing like door frames and such afterwords) but it did span the exterior wall, interior wall, floor, and ceiling (for 2 floors). The walls did have header and footer textures. But all this is typical in a build. I continued to build putting a second floor above the first floor ceiling and the chunk's complexity rose to 85%.
Why is such a straight forward construct on the threshold of being too complex? Will adding shaped voxels (e.g. door frame) push complexity over the limit? What is the complexity measure trying to tell me, and can it be put into words that I can act on?
Addendum: I completed the chunk by adding a 45% slanted wall using a material already present. The complexity went from 85% to 104%.  The location of the chunk is: ::pos{0,26,1.9579,12.0628,347.0015} if you care to see for yourself. A picture of the offending wall is below.

Honestly a lot of the "Planets" were ugly, unfinished, boring, and other then to mine for quanta, simply not worth really going to.

While building, I placed a ceiling using the deploy voxel tool and was warned that the complexity of the voxel chunk had reached 79%. The chunk had almost no shaped voxels (I do detailing like door frames and such afterwords) but it did span the exterior wall, interior wall, floor, and ceiling (for 2 floors). The walls did have header and footer textures. But all this is typical in a build. I continued to build putting a second floor above the first floor ceiling and the chunk's complexity rose to 85%.
Why is such a straight forward construct on the threshold of being too complex? Will adding shaped voxels (e.g. door frame) push complexity over the limit? What is the complexity measure trying to tell me, and can it be put into words that I can act on?
Addendum: I completed the chunk by adding a 45% slanted wall using a material already present. The complexity went from 85% to 104%.  The location of the chunk is: ::pos{0,26,1.9579,12.0628,347.0015} if you care to see for yourself. A picture of the offending wall is below.

I have 4 Small Mining Units (crafted in my nanopack). 2 for Coal, 2 for Quartz. I collected 6390L of Coal and 6426L of Quartz in 15minutes (Calibration spawns). I also collect 70L per hour of Coal (100L Max) and 42L per hour of Quartz (61L Max) after that.  For a 24 hr period that comes to 8070L of Coal (@45q = 363 150q) and 7434L of Quartz (@36q = 267 624q) worth 630 774q right now based on buy orders at Alioth M6.
I actually have 8 charges so if I wanted I could have 8 units covering all 4 ore types.
However, I'm told new players start out with 1Mq and basic Mining Units L are costing 240 000q at Alioth M6. So that would be another way to go (not worth it IMHO).

Q: Why (after 2+ years) would I return to DU after the rumoured full wipe prior release?
A: Because DU would feel new because of the following:
 
There is a "New" Alioth  Aphelia declares Alioth a Sanctuary (the other one becomes Moon 3), and all planets/moons have a 3SU "Safe Zone" enforced by Aphelia. PvP exists everywhere else. Note: current Alioth has too many water territories, just swap the name with Sanctuary and move the Ark.  New Alioth has a central market at the Ark which is restricted. Satellite markets provide access to the central market and are distributed such that no territory is more than 30km away from one (about 60 markets in total). Thus, no need to go further than the local market to trade.  12 regional markets (reachable by teleport from other regional markets, each regional market has 4 satellite markets with teleports within the region) provide free, safe, shuttle service to the corresponding market on Moon 3. All Basic schematics should be found on Alioth for negligible prices (~1Kh). All Uncommon schematics should be found on Alioth Moon 3 for reasonable prices (~50Kh). Note: Next to building, Industry is the most widely enjoyed content that DU provides (it also provides an incentive to build). Make the early stages broadly accessible. Add a new moon to Alioth (nothing special). Assign one Tier 2 ore to each moon. The T2 ore should be found on each territory of the smaller moons and are findable (e.g. 1 in 10 territories) on Moon 3. No higher tier ore should be found on Alioth or its moons. Helios is smaller Move all the planets closer to Alioth. Reduce their distance from Alioth by at least half. Make No Promises, but Provide a Vision for the Future (let us hope) Here is a story: Colonists revolt against Aphelia's heavy hand (and taxes). One by one, Aphelia withdraws her planetary protection until only Alioth and its moons remain. As Aphelia withdraws her protection, territory warfare brakes out between colonists.
All of this could be done with what DU software provides today, but it does require work so it can't be done today, or even a week, but certainly by the time of release. In my opinion, it would be enough to get the majority of people who have drifted away to come back and try DU again.
 
 

Q: Why (after 2+ years) would I return to DU after the rumoured full wipe prior release?
A: Because DU would feel new because of the following:
 
There is a "New" Alioth  Aphelia declares Alioth a Sanctuary (the other one becomes Moon 3), and all planets/moons have a 3SU "Safe Zone" enforced by Aphelia. PvP exists everywhere else. Note: current Alioth has too many water territories, just swap the name with Sanctuary and move the Ark.  New Alioth has a central market at the Ark which is restricted. Satellite markets provide access to the central market and are distributed such that no territory is more than 30km away from one (about 60 markets in total). Thus, no need to go further than the local market to trade.  12 regional markets (reachable by teleport from other regional markets, each regional market has 4 satellite markets with teleports within the region) provide free, safe, shuttle service to the corresponding market on Moon 3. All Basic schematics should be found on Alioth for negligible prices (~1Kh). All Uncommon schematics should be found on Alioth Moon 3 for reasonable prices (~50Kh). Note: Next to building, Industry is the most widely enjoyed content that DU provides (it also provides an incentive to build). Make the early stages broadly accessible. Add a new moon to Alioth (nothing special). Assign one Tier 2 ore to each moon. The T2 ore should be found on each territory of the smaller moons and are findable (e.g. 1 in 10 territories) on Moon 3. No higher tier ore should be found on Alioth or its moons. Helios is smaller Move all the planets closer to Alioth. Reduce their distance from Alioth by at least half. Make No Promises, but Provide a Vision for the Future (let us hope) Here is a story: Colonists revolt against Aphelia's heavy hand (and taxes). One by one, Aphelia withdraws her planetary protection until only Alioth and its moons remain. As Aphelia withdraws her protection, territory warfare brakes out between colonists.
All of this could be done with what DU software provides today, but it does require work so it can't be done today, or even a week, but certainly by the time of release. In my opinion, it would be enough to get the majority of people who have drifted away to come back and try DU again.