Jeronimo

In the upcoming 0.28 Panacea update, we will introduce the Vertex Precision Tool (VPT), which adds a whole new way of bringing detail to your creative designs.
 
This all may sound quite complex initially, but once you get used to the tool it’s quite intuitive. If you’ve been holding back because voxelmancy seemed too complicated, now’s the time to give it a try. By allowing you to simply equip the VPT and move the vertex around on a changeable grid, the process of designing with voxels is greatly simplified and far more user-friendly.
 
Here’s a brief demonstration of what the VPT looks like and how it’s used:
 
 
Heads up! The information in this blog leans heavily into the extremely technical side of things. Those who are into voxelmancy will probably dive in with unfettered joy. If building isn’t your jam, you may wish to stop here and get the TL;DR from one of your builder buddies later.
 
VOXELS DEFINED
 
Much of what you see in Dual Universe was built by players using voxels. The term “voxel” is very generic, a shortened form of “volume element”. Voxelmancy is an advanced form of building that can be quite complex, and there has always been a gap between building with standard geometric shapes and fine-tuned designs. The VPT aims to bring a game-changing  bridge for the gap between these building styles.
 
How exactly the voxels are implemented depends a lot on the software that’s being used. In DU, a voxel contains two things: material information and a vertex position information.
 
The material information is pretty straightforward; it is exactly the same as in a pixelated image where there is a material (think of it as a synonym of “color“) for each little square. We use what we call a uniform grid, meaning that voxels are put next to each other in a 3D grid and all have the same size. For example, on a planet voxels are 1 meter long (1m x 1m x 1m) whereas they can be 25 centimeters long (0.25m x 0.25m x 0.25m) on a user construct. It’s exactly how pixels work in 2D images, and you may already be familiar with these kinds of voxels because they are present in games like Minecraft.
 
VERTICES POSITIONS
 
Let’s drill down even deeper into the well of technical stuff.
 
As stated above, voxels contain material information and a vertex position information. The Vertex Precision Tool doesn’t touch materials, so let’s talk about vertices.
 
3D geometry is composed of vertices, and those vertices are linked together to form faces that will be rendered on your screen. For instance, take a simple single voxel cube. It is composed of one material, but has eight vertices on the eight corners. Since our voxels in DU store both a material and a vertex position, our “single voxel” here is composed of eight voxels because it takes eight vertices to form a cube!
 
This is where it starts getting complicated. We can consider that there are two voxel grids, one is the material grid and the other is the vertex position grid, and the two grids are shifted, dual to each other. There are eight vertices around a material, and there are eight materials (we can consider the void as a special kind of material) around a vertex.
 
So what are we talking about when we talk about a voxel? A little bit of both, depending on the context. Confusing right? We’ll try to be specific and talk about vertices, but remember there is only one vertex per voxel, although one voxel cube is composed of eight vertices (and thus is in reality eight voxels: one with matter and seven without matter.)
 
Take a look at this picture. It is in 2D because it’s easier to understand (and to draw), but this is the same thing in 3D. This image represents a voxel sphere (more like a circle since we are in 2D).
 

  The dotted lines are the uniform grid that represent the voxels. At the intersection of those dotted lines, you can have a blue dot, representing a material. So, we have our material grid: either emptiness or a blue material. Inside of all of those cells, there may be a vertex. There is a vertex if and only if all four corners are not the same. If one of the corners is blue and another one empty, it means we have some material change here and thus something to see. So we need a vertex to know where we see the surface. On each of those cells, we have a vertex represented. The vertices are then linked together to form the surface.
 
POSITIONS VALUES
 
Before the Panacea update, you could only get such a sphere with the sphere tool, but with the VTP you’ll now have the opportunity to change the vertex position manually. This raises the question: what coordinate system do we use?
 
In theory, we could use an infinite range of values. For example, we could say that the vertex should be at one third (on a given axis) in between the two materials as shown in the grid, so its value (on this axis) could be 0.333333333. It could also be 0.1415926535, or whatever we want.
 
However, we need to store those vertex positions, and we want to be efficient so that we don’t take too much disk usage so we encode the vertex position (on a given axis) on a single byte. This means we only have 256 different possibilities for a vertex position, but we don’t really need more. A vertex position is a coordinate with three numbers (for the three axes) where all of these numbers are integers (with a maximum 256 different possible integers).
 
So what are those possible values? Before answering that, we need to consider where a vertex can lie. On the sphere representation drawing, you can see that vertices are inside the zone defined by the four surrounding material points. This is indeed where a vertex should be most of the time, although we may sometimes want to overflow a bit, reach a little further than the vertex is supposed to. This will encroach on the zone of the neighbor voxel, but it does not have to be a problem. We decided that a vertex could lie on its one zone, but also the zone of its direct neighbors. On the 2D schematics above, it means that a vertex can be placed anywhere on the nine squares around it.
 
A vertex encoding actually encodes three vertice’s positions. We want to have an encoding for all the important positions, the middle of each of the three voxels and their borders. This means that we need a multiple of six. We’ll use 252 as it is very close to 256. Now let’s see this coordinate system in a picture. The picture below represents four simple cubes in voxels (yellow, red, blue and cyan).
 
We will be talking about the vertex shared by the red and blue cubes. There are actually two of those vertices in 2D, one top and one bottom; let’s talk about the top one. We state that the position it is in in the picture will be 0 (it’s a convention, the one chosen in the Vertex Precision Tool), and above the cubes we showed all the position values this vertex could have
 
 
So 0 is the position of a vertex in a simple voxel cube. If we move the vertex into position 42 (both the top and bottom vertex of this red-blue junction), then the red rectangle will now be 1.5 times bigger, and the blue rectangle will be half its current size. If we move the vertices to -42, it would be the other way around. Note that all the values between -42 and 42 are the values where the vertex is supposed to be without overflow. This is the zone we described earlier.
 
If we were to move the vertices to value 84, then we would enter the territory of the vertex shared by the blue and cyan cubes. This becomes a little dangerous and could result in strange results. In this example, it would lead to the blue surface to completely disappear and be replaced by the red one. The blue voxel would still exist, it would just have a null volume.
 
And, in the example of these four cubes, if we were to go to a value above 84, it would result in an ill-formed shape because the blue shape would have a negative volume. This would probably create visual artifacts, and we may prevent this situation in the future.
 
ENCODING CHANGE
 
One last note for those who are familiar with voxelmancy. In Panacea, we use an encoding of 253 positions (from -126 to 126), which is different than it has been. We used an encoding of 255 positions (it was from -128 to 128 but previous -128 = actual -126). Since there is no exact mapping between the old encoding to the new one, this means that vertices in your constructs may be shifted up to 1mm (vertices at position 0 will not move, but those at extreme values will move the most). This will probably be unnoticeable, but we wanted to err on the side of caution and share this information.
 
You may wonder, why 253? It is for the reasons explained before, to have those nice -126, -84, -42, 0, 42, 84 and 126 values. The 255 system did not allow for that. We could have chosen 193, so that you could split a voxel in 2, 4, 8, 16, 32, and 64, but that would have meant a huge loss in precision and significantly deformed most constructs. So 253 it is, and you can now split a voxel in 42!
 
USING THE VPT
 
There are exactly 253 positions on a single axis including zero that a vertex can be in due to it being divisible over three voxels. Negative 126, 0, and positive 126. As such, the width of one voxel is exactly 84 positions. And each vertex can be moved exactly 1.5 voxel away from the center position.
 
Thus, the grid on which a vertex is moved is adjustable to a size that covers 1, 2, 4, 7, 14, 21 or 42 positions, 42 being the size of half a voxel. This allows the accurate placement to the finest detail or to quickly scale up and move a vertex by a half, a quarter, a sixth, or a twelfth of a voxel.
 
See the image below to get an idea of the different size grids available to the VPT.
 
 
Once selected, the vertex cursor can then be moved with:
The up, down, left arrow and right Arrow keys for the x- and y-axis.
The Page Up and Page Down for the z-axis.
The Home key to send the cursor to the current position of the vertex.
The End key to send your cursor to the last confirmed coordinates.
(This also happens by default when you change vertices.)
The Alt+Home key combination to send the cursor to the centered 0,0,0 coordinates.
Holding Control+Scroll will adjust the grid size between the available sizes.
Left-click confirms the placement and moves the selected vertex to the cursor.
 
The VPT will give you the finest precision possible, no more complex voxelmancy of copy-pasting things around to get a specific shape. You may not use this tool all the time, but when you do you’ll find it exceptionally helpful for fine-tuning.
 
WHEW, THAT’S A LOTTA INFO!
 
Still with us? We know there’s a lot of information to process, but we felt it was worthwhile to share the details with our voxelating community members that would appreciate seeing how the sausage is made (so to speak).
 
We can’t wait to see the cool new stuff Noveans build with the Vertex Precision Tool. As always, we encourage everyone to join the conversation on the forum in this thread. If you have questions about the VPT or want to share your thoughts and tips about voxelmancy in general, that’s the place to go.
 
 

Dual Universe’s Panacea update is right around the corner, bringing with it a sizable variety of changes based on feedback from our community. 
Ahead of the update, however, we are immediately introducing revisions to territory upkeep and mining units. 
 
Read on for the full scoop! 
 
GOING INTO EFFECT ON TUESDAY, JANUARY 25th
 
Taxes will be effective again starting Wednesday, January 26th.
The day before, we are going to deploy three adjustments to address the issues mentioned in the Community Feedback regarding Territory Upkeep.
 
Territory Upkeep Reduction: 1 MM --> 500k.

Territory Upkeep was first introduced in the November 2021 Demeter update. After reviewing community feedback, we announced that territory upkeep payments would be postponed for two weeks to allow the Design team time to dig deep into the metrics and fine-tune the system accordingly. 

The upkeep rate per territory will be reduced by 50%, from 1MM to 500k quanta. Player feedback indicated that people felt they were having to sell ore too frequently to generate the funds needed to pay upkeep. In halving the upkeep costs, we will relieve the pressure to make frequent trips to the market as well as the need to sell large quantities of ore.
  Calibrations Charges:
Base calibration charge slots increase : 5 --> 25.
Talent calibration charge slots increase : 1/level --> 5/level.

Also introduced in the Demeter update, mining units were designed as an alternative to digging endless tunnels underground for ore. To keep them producing at their peak capacity requires occasional calibration; however, initial feedback from the community told us that further tweaks were needed for the calibration process. To this end, we’ve made the two changes mentioned above.

This will change the total amount of stored charges from 10 (5 base + 5 max talents) to 50 (25 base + 25 max talents).

The intention behind the charge cap was not to force a behavior in which you felt like you needed to spend charges in order not to “lose out” on charges by hitting the cap and wasting your recharge. 

In view of that, both the base and the talent bonus are drastically going up. This will not only allow you to store more charges in general, but specifically allow you to store a much longer period of time in charge recharge time, giving you much more breathing room to store charges and not waste charge recharge time.
  Calibration grace period: 48h --> 72h
  The calibration grace period is the amount of time during which a mining unit does not lose calibration. Similarly to charge slots, the intention was not to aggressively require you to calibrate mining units every 2-3 days. In our initial calculations our goal was more to hit the 5 to 6 day mark depending on what efficiency curve the player selected, and how many mining units the player was trying to maintain.
 
We are changing the calibration grace period from 48-hours to 72-hours. 
 
This change should bring us closer to the initial values we were looking for and give players more breathing room to calibrate when their mining units seem to be producing less than usual, indicating that calibration is needed.
 
CHANGES COMING WITH PANACEA UPATE (0.28) LAUNCH
 
Using industry units on offline tiles

The intention of requiring online territories for industry units was not to negatively impact industry units on planets. We initially saw it as further incentive to pay for taxes, but it was not a core requirement. This is also why industry units on Ssanctuary and space cores were left untouched.

We understand from player feedback that requiring you to operate mining units on a territory in order to not run industry units at a loss on that territory was an annoyance and many players did not want to run their industry units on the same territories as their mining units.

In view of the preferences expressed, we have decided to allow the operation of industry units on all offline territories. In combination with HQ territories, this will allow you to effectively run industry units on offline territories for extended periods of time.
  Faster extraction animations
  We are also addressing the feedback we’ve received regarding the time it takes to complete a calibration minigame, specifically the frustration from the long loading animations when calibrating a number of mining units.
 
An option has been added in the mining unit UI (tick box) that will let you significantly reduce the time these animations take, drastically reducing the period of time the animations run.
 
Additionally, a number of mining unit mini-game animations have been slightly reduced in duration, thus allowing a faster minigame completion.
 
New talents for surface harvesting
  In order to further incentivize harvesting surface rocks, and to be able to specialize in it, we are adding four talents linked to surface harvesting that will touch on harvesting speed and output.
 
The main goal is to create some surface harvesting specialization for those players who enjoy it, giving them the capability to harvest better and faster, and for longer periods of time.
 
CHANGES COMING POST-PANACEA
 
New surface harvesting controls
  To further address surface harvesting issues, we are working on quality of life-type improvements that will allow a degree of auto-harvesting similar to normal mining as well as other changes to reduce control and UX-based frustrations during surface harvesting. 
Watch for additional details as we refine our plans!
 
 New mining unit surface harvesting, rocks spawning behavior
 
Lastly, we are looking for a solution to simplify the process of gathering rocks. This is in direct response to player requests to eliminate the hassle of having to comb their territories after calibrating a number of mining units. 
 
While this is still in relatively early stages, the solution we are looking at is to spawn the rocks right under the mining unit beam, where the beam hits the ground. Players would then be able to rapidly harvest surface rocks. 
 
BUT WAIT! THERE'S MORE
 
Don’t forget that there’s a lot more to Panacea than the changes and tweaks discussed above. It’s also got some cool new stuff, like the Vertex Precision Tool which we’ll be talking about in the next devblog! 
 
Meanwhile, please join the conversation on the forum here to tell us what you think about revisions we’ve presented in this Devblog.
We’d love to hear from you! 
 
---

The Novaquark team

We had it a while back in alpha, the getConstructWorldPos(id) for everything, without transponder, then players started to make construct following construct scripts and amazing AR scripts, which displeased JC who nerfed it hard.
 
While players outsmart limitations and already found other ways, to get a coordinate, with triangulations, why keeping this function nerfed?
 
At least allow us the use of getConstructWorldPos(id) for all statics and space cores and why not for stopped and unboarded dynamic cores .
Numbers of abandoned constructs of all types and sizes, in atmo at any altitudes, and space, agg plateforms, elevators towers, floating bases etc... are increasing day by day
 
The multiplications of sophisticated autopiloting scripts for example, where those coordinates information are crucial for good functioning and obstacles avoidance, this getConstructWorldPos(id) nerf just making piloting scripts uselessly heavier, therefore impacts on performances
 
 
 

Hi @TobiwanKenobi and others,
 
We are investigating this issue, we have made an update to reduce the instability of the obstruction value which was a bug causing your ship's engines to randomly change the obstruction over time even in mid-air.
However, it seems that the obstruction has another problem; this one.
We can't give an ETA, especially since the team is taking a break for the holidays. But be sure it's in our bug list we're investigating.

I've been noticing the 100% obstruction bug occurring a lot more often after the recent changes to obstruction in Beta 1 r0.27.11 - "• Reduced engine obstruction fluctuations." Whatever you guys changed made this particular problem worse. My issue is that after entering build mode, these obstructions clear up. Why can't they already be clear?
 
We've always had issues with engines being 100% obstructed when you first start up a ship after logging in. The way players fix it is by entering build mode once before using the ship, which appears to force DU to recalculate obstruction. But that's suboptimal as you can often forget and not notice that a bunch of elements are 100% obstructed until you're airborne. It would be nice if the game would calculate obstruction before flight.
 
My suggestion is that obstruction be calculated once, VERY THOROUGLY, with many rays when a player exits build mode. Then this obstruction data can be recalled every time the ship is used. This way the obstruction doesn't need to be recalculated in flight or every time you visit a construct. It's just loaded from a previous calculation. I don't see a problem people cheesing obstruction with this method since it would calculate it every time anyone exits build mode. Any changes made would be accounted for.

Examples:

^These large adjustors become completely unobstructed after you enter build mode for about 10 seconds. So why are they 100% obstructed if I don't enter build mode? Moreover, why is the medium space engine there obstructed? There's nothing in the way forward. The cone is just hitting the sides of the ship. Why must the obstruction cone/cylinder be so wide?

^Notice in the second screen shot that only one of the four forward adjustors is firing when I try to yaw to the right. The other three are 100% obstructed because I didn't enter build mode before taking off.
 
Thank you for your efforts to improve and perfect the best ship building game on the market.

right now lets say we have player managed shops, and player never ending greed driven public markets
 
so yes obviously we will need at one point some market terminal elements for players, that would list up all the items from a linked container or something like that

Any reasonable person not emotionally attached at the hip to their 'digital stuff' recognized there is a glaring need for a wipe of some sort at least at release. The idea that they would convince new players to start at the bottom when the world is already full of people with gaggles of junk on all the good ore spots from easy mode beta days is laughable. Ideally they would wipe everything, give the Beta players back their talent points as a thank you, and then reshuffle ore distribution so people can't just go right back and camp the best spots with Beta knowledge.
 
Regardless, the one thing we can all be assured of is that NQ will still not understand that ore bots are the root of economic evil in this game. Nor will they recognize the need for properly searchable player markets.

I believe the main thing that will push this game and allow it to stand out from Star Citizen, No Man's Sky, Starbase and Space Engineers is to flesh out the civilization building aspects which have barely been implemented into the current game. Star Wars Galaxies and WURM, games from the early 2000s had more civilization building game mechanics than this game has currently. The dev team chose to focus on mining, building and manufacturing which are very common in many games. I understand these are fundamental to the game design but much of the civilization building mechanic development would be UI and systems design but would add exponential depth to the gameplay experience. I hope into 2022 NQ will pivot to refine current mechanics and implement more organization and territory based mechanics as these are what make the game unique. 

I'm a builder and I have three accounts. Because of the Demeter changes I am considering to retreat back to sanctuary so I don't have to pay taxes and sell the ores I mine. All my territories on sanctuary are grouped together and I discovered that they mostly only contain quartz. I also discovered that the ores are not evenly spread and there actually are territories that have hematite and presumably bauxite. The materials I build with. I was expecting lower ore values on sanctuary because of the lack of taxes but this not acceptable. You once said to pick our territories carefully because we won't be able to change it after and so I did. But now this seems unfair and I am really not happy with this. So my question is.
 
The ore distribution on sanctuary is uneven and without the ability to change territories. Will we be granted the ability to change territories or will the ore distribution be changed to be more fair?
 

Please explain your vision for how new and casual players and solo builders should be able to find an enjoyable game loop with Demeter.

If you elobrate your points in more detail we might can discuss it here.
But to say "sustainable economy" or "Stuff to explore" is like saying "We need to do something about the climatic problem on earth" and then claim to found the problem of the climatic change just by pointing at it.

I totally agree that we need a sustainable economy in DU, and i totally agree it would be cool to have stuff to explore.
But this stuff to explore need to fit the DevelopmentTime/PlayerSatisfaction ration which is worth it. And to make such a system is not that easy. They could just place some structures here and there in space you can explore, then you explore them and then what? Probably could be easy if you have a team of 10 Heads just dedicated to build stuff to explore and systems for it which makes it fun in the long term.

The thing is to say what NQ already knows is no valueable help if you dont keep factors like budget in mind.

Its like if you have 2 kids and booth want a car from you. But you only have 1k Dollar, so you get them booth a bicycle. And that is what NQ is doing right now. They find compromises.

PS: Just readed your "DU is BORING" post
The points at "Easy" (VoIP is not really a easy thing in Uni engine i think) are more like personal taste things.
I like the slow paste of crafting and traveling. Mining tho has been replaced now anyway.
"Moderate" and "Hard" are still some very expensive features to add while i also disagree that a creative mode would make DU greater as it kills a bit the immersion i think. But why not. If it gets more new player in DU it might be cool.



 

oh yes we want a wipe
yes the early game is more than broken now, not only the early game, will need some enormous rebalancing
 
if we all start again from scratch, industries will be extremely slow to develop, long space distance exploration for finding better than T2 ores will be a very hard task since we wont have territory scanners (needing T1/T2 and T3 ores) to check which tile on Alioth have Malachite therefore to be able to make space fuel, unless you want spend hundreds of hours of your time mining 20L skittles on the surface to fuel up a space speeder
 
but too many players have gotten effortlessly insanely rich using the game exploits (free schematics worth millions after patch, VR missions allowing players to make more than hundreds millions quantas per mission, duplication glithes etc...), and it is those players now are playing with broken economy mechanics, because they are the only ones now well equipped for feeding the markets, where solo players and smaller orgs pay the highest cost, where rich will keep on pressuring to get richer and richer, and new players and poorest will never be able to get out of it and surely give up on the game

Demeter is coming and promising features been revealed, specially concerning the optimization of the game, i would like to point out once more several aspects of the game that are here from day 1 and should be considered for improvement in a very near future. 
 
 
Gameplay:
- Collision box:
Walking on micro voxel construct floors is like wearing high heels shoes and having heels getting stuck in every little surfaces details, while sometimes having really undesired collision and repelling the player away.
 
- Jetpack run:
Double tap forward sometimes too sensitive and is generator of jump scares. So maybe need to allocate a different keybind for it
 
- Mining tools:
Demeter will revolutionize the mining mechanics, so maybe we dont need all those mining and scanning tools. Could fusion them into 1
 
- Surface ores:
Surface ores should be minable anywhere (including claimed tiles) by anyone. They arent a source for mass production, but mainly as starting resource. Someone crashing into a huge claimed zone (such as the zone all around Alioth markets) without scrap, has no other way but to run for hours to be able to reach an unclaimed tile for couple scraps.
 
- Inventories:
Inventories are real mess, we should be able to reorganize by type
Items are way too many, specially honeycombs
Search bar is buggy by the way, not functioning in certain situations like barter inventory search
 
 
 
Flight Mechanics:
- The stall vector bug:
It is possible to stop a dynamic construct (any weight) in mid air, with only brakes, no anti grav, by aligning the forward vector with the gravity while stalling
 
- Cross Section lift:
While cross sections are used to generate drag, it would be better that they also produce lift!
This would have multiple advantages:
First, that would reduce the number of wings and stabilizers elements on construct, by this reducing the construct data weight (so, beneficial for server, beneficial for data transfer). 
Then,  and most important, would release players creation potential, allowing them to design their own voxel wings, because they might want wings long  instead of wide, but right now we don't have choice.
 
- Engines power:
I strongly, but very strongly do believe all engines thrusts needs to be scaled up.
Engines power do not actually match at all their size in comparison with their core size.
Players always use the superior size elements depending on the core size. No one will use M engines on a M core.
As well players will always try to reach better performances, by adding more and more engines, therefor greatly and unfortunately compromising on the design (more elements = greater construct data weight).
Design is a too important point for the image of the game, skilled creators struggle way too much to do something that looks good and performs good, and we dont want evolve in a game invaded by borg cubes. 
 
- Fuel consumption:
Just scaled down fuel consumption, its a game where we are mainly supposed to fly. For instance, a very basic VTOL construct has no more than 15min fuel autonomy in atmosphere, this is not acceptable.
 
 
 
Honeycombs:
To me and all the players i have talked to, honeycomb is the game biggest mess, while it is the game creativity most important content.
Honeycombs can be a multiple pages topic, so important they are and so badly they are treated, and as myself an architect and paying extremely attention to materials i have couple words to say about it.
 
Names choices show there has been no research made on this topic
Galvanized, is a zinc coating exclusively for iron and steel to protect from rust, so it is not colored in any cases, and cant be applied over aluminium
Brick is not a material, Ceramic is, with what we can make bricks or porcelain
 
I suggest using 4 basic finishes names instead: "natural / polished / brushed / painted"
I addition of that there is a big difference between "painted", "tainted" and "textured"
 
For honeycombs to be efficiently accurate and become the best creativity content, we need a paint tool! 
I suggest the replacement of the "Voxel replacement tool" (which is absolutely useless and it is equivalent to select and copy paste) by a "Voxel paint tool"
 
This tool could have the right side slot bar, and a TAB window (the same way we open filters for the scanner), with the above named properties and colors selectors:
/ a button for selecting the finish (natural / polished / brushed / painted matt / painted glossy)
/ a RGB rainbow for selecting a color (the same way it has been done for character color selection i guess)
/ a button for selecting a pattern/texture/bump that would be applied on top of it
And once we are satisfied with a result we could drag and drop it to a right side bar slot and exit TAB to use the tool on our construct
 
Most of all a paint tool would empty our inventories and industries, leaving in there only the raw/natural version of it
HUGE HUGE benefit for the game data, no more list of hundreds of different honeycombs to deal with our industries, our inventories,  markets, and bandwidth to load all that mess
 
5 years dev team been trying, updating and failing those precious honeycombs, the render and colors of them is nowadays the worst it has ever been
 
 
 
Element:
- Design:
The elements design is bad and not in harmony with the game global structure and mechanics. Those elements could fit in any other games and are not adapted at all to be fit into a voxel creation, they are staining our creations.
The edit vertex update will help us go around them for a better looking seamless fitting, but will not remove this obvious stains looking detailed mesh on top of low details voxels surfaces
In the first published artworks and ingame screenshots 6 years ago, there was that white long squared engine, which is exactly the type of compatible design for voxels, but you guys made it over complicated....
 
- Colors: 
Colors is also a big part of the stain effect elements have on creations, so please, let us right click on elements and choose a color by ourselves
 
- Decorative:
There should be more decorative and structural simple elements of different scales(bars, panels, truss etc...), for players not skilled enough with voxels, where voxels could be a minority and a link between those elements
 
And btw, orange flames from engine fire is supposed to be due to oxygen burning, so to be accurate, orange particles for atmo engines, and blue particles for space engines...
 
- Obstruction
I do think obstruction for engines and adjusters needs to be reviewed.
Distance to target of obstruction needs to be lowered
Cone angle needs to be clarified
Obstruction cone need a graphic representation
 
 
 
LUA:
- Slots:
We should be able to call every single elements within same construct by their names without having to link them. So no more lua slots problem, and linkage would be for manual interactions without use of lua.
If i link this button with that door, i can manually open and close that door
But if i have 20 doors, i should be able to open or close them independently with 1 single programming board just by calling them by their names
Since automatic naming differentiate elements of same type with [number], those could be stacked in a table using this number as keys.
 
- Keybindings:
Would be nice to enable all the keyboard keys recognition for lua programming
 
- Resell:
When the "save to inventory with drm" button when we right click on scripted elements? so we could barter our scripts more easily.
 
 
 
Good luck, we are getting there!
Cheers
Jeronimo

The construct cube removal tool NQ showed in the video is pretty much worthless for anyone who has spent some time doing proper terraforming and use the landscape as a part of their builds. So I have raised some markers above the ground telling me where to dig.
 
That is, if there still is a tile to dig out between demeter and the time when the non tax HQ tile feature is released. I took a break from the game because of mining and boring missions, and I for sure won't start playing again just to grind auto bots for paying taxes that give me nothing in return. That's even worse then mining.
 
So while I can live with having to dig out my tiles, I will most likely call it quits when I start to lose tiles because demeter is released without the tax free HQ part, that we all know will happen because sigh NQ..
 
 
 

Hi Deckard,

After some feedback and explanation I have the impression that you are not taking the time to read our feedback in full.

When I see "There are two important things to note in regard to this change. First, since mining-related talents will become obsolete, those points will be refunded and can be used elsewhere."
I see the Railgun fitting capacity 50000, so for 3 weapon it take 150000 without talents, so now Railgun L capacity handling hightest level are useless, and some other talent link to weapons are useless too. It's not a meta problem, it's just your changes who let us with 3.000.000+ talent points obsolete, AND I JUST TALK ABOUT RAILGUN L, so imagine for the rest.
I see the Control unit capacity handling
etc etc etc...

And you got this problem on so many change you add without thinking about the time people take to up them.

You don't want us to be able to adapt to a new meta? Ok, but then why mining skill are reset? Asteroids are still here for them. I don't understand this contradiction. And we are on a beta, where the whole economy is ruined by the duplication of high-tier voxels, the duplication of objects on the markets, schematics "offered" with market bugs, exploits with challenges, mission warp... All these abuses that haven't corrected on time and some have managed to profit from for months (and I didn't talk about people with 40+ free alt account for mission). We all know you will need to do a total wipe or this imbalance will be preserved. So why make this beta an experiment aimed at testing our mental resistance? xD

Think about people who just enjoy this game, think about people who don't have 40 alt account, we just talk here about talents. Add a button with a high cooldown who allow us to reset them or reset them when you broke their utility.

I love how you take care about carebear and I still love PVP even with all this bugs we have to deal with, but if you don't add gameplay loops other than simple farming, then try not to scare away the few players who remain loyal to you and who make the effort to get into PVP.

Demeter is coming and promising features been revealed, specially concerning the optimization of the game, i would like to point out once more several aspects of the game that are here from day 1 and should be considered for improvement in a very near future. 
 
 
Gameplay:
- Collision box:
Walking on micro voxel construct floors is like wearing high heels shoes and having heels getting stuck in every little surfaces details, while sometimes having really undesired collision and repelling the player away.
 
- Jetpack run:
Double tap forward sometimes too sensitive and is generator of jump scares. So maybe need to allocate a different keybind for it
 
- Mining tools:
Demeter will revolutionize the mining mechanics, so maybe we dont need all those mining and scanning tools. Could fusion them into 1
 
- Surface ores:
Surface ores should be minable anywhere (including claimed tiles) by anyone. They arent a source for mass production, but mainly as starting resource. Someone crashing into a huge claimed zone (such as the zone all around Alioth markets) without scrap, has no other way but to run for hours to be able to reach an unclaimed tile for couple scraps.
 
- Inventories:
Inventories are real mess, we should be able to reorganize by type
Items are way too many, specially honeycombs
Search bar is buggy by the way, not functioning in certain situations like barter inventory search
 
 
 
Flight Mechanics:
- The stall vector bug:
It is possible to stop a dynamic construct (any weight) in mid air, with only brakes, no anti grav, by aligning the forward vector with the gravity while stalling
 
- Cross Section lift:
While cross sections are used to generate drag, it would be better that they also produce lift!
This would have multiple advantages:
First, that would reduce the number of wings and stabilizers elements on construct, by this reducing the construct data weight (so, beneficial for server, beneficial for data transfer). 
Then,  and most important, would release players creation potential, allowing them to design their own voxel wings, because they might want wings long  instead of wide, but right now we don't have choice.
 
- Engines power:
I strongly, but very strongly do believe all engines thrusts needs to be scaled up.
Engines power do not actually match at all their size in comparison with their core size.
Players always use the superior size elements depending on the core size. No one will use M engines on a M core.
As well players will always try to reach better performances, by adding more and more engines, therefor greatly and unfortunately compromising on the design (more elements = greater construct data weight).
Design is a too important point for the image of the game, skilled creators struggle way too much to do something that looks good and performs good, and we dont want evolve in a game invaded by borg cubes. 
 
- Fuel consumption:
Just scaled down fuel consumption, its a game where we are mainly supposed to fly. For instance, a very basic VTOL construct has no more than 15min fuel autonomy in atmosphere, this is not acceptable.
 
 
 
Honeycombs:
To me and all the players i have talked to, honeycomb is the game biggest mess, while it is the game creativity most important content.
Honeycombs can be a multiple pages topic, so important they are and so badly they are treated, and as myself an architect and paying extremely attention to materials i have couple words to say about it.
 
Names choices show there has been no research made on this topic
Galvanized, is a zinc coating exclusively for iron and steel to protect from rust, so it is not colored in any cases, and cant be applied over aluminium
Brick is not a material, Ceramic is, with what we can make bricks or porcelain
 
I suggest using 4 basic finishes names instead: "natural / polished / brushed / painted"
I addition of that there is a big difference between "painted", "tainted" and "textured"
 
For honeycombs to be efficiently accurate and become the best creativity content, we need a paint tool! 
I suggest the replacement of the "Voxel replacement tool" (which is absolutely useless and it is equivalent to select and copy paste) by a "Voxel paint tool"
 
This tool could have the right side slot bar, and a TAB window (the same way we open filters for the scanner), with the above named properties and colors selectors:
/ a button for selecting the finish (natural / polished / brushed / painted matt / painted glossy)
/ a RGB rainbow for selecting a color (the same way it has been done for character color selection i guess)
/ a button for selecting a pattern/texture/bump that would be applied on top of it
And once we are satisfied with a result we could drag and drop it to a right side bar slot and exit TAB to use the tool on our construct
 
Most of all a paint tool would empty our inventories and industries, leaving in there only the raw/natural version of it
HUGE HUGE benefit for the game data, no more list of hundreds of different honeycombs to deal with our industries, our inventories,  markets, and bandwidth to load all that mess
 
5 years dev team been trying, updating and failing those precious honeycombs, the render and colors of them is nowadays the worst it has ever been
 
 
 
Element:
- Design:
The elements design is bad and not in harmony with the game global structure and mechanics. Those elements could fit in any other games and are not adapted at all to be fit into a voxel creation, they are staining our creations.
The edit vertex update will help us go around them for a better looking seamless fitting, but will not remove this obvious stains looking detailed mesh on top of low details voxels surfaces
In the first published artworks and ingame screenshots 6 years ago, there was that white long squared engine, which is exactly the type of compatible design for voxels, but you guys made it over complicated....
 
- Colors: 
Colors is also a big part of the stain effect elements have on creations, so please, let us right click on elements and choose a color by ourselves
 
- Decorative:
There should be more decorative and structural simple elements of different scales(bars, panels, truss etc...), for players not skilled enough with voxels, where voxels could be a minority and a link between those elements
 
And btw, orange flames from engine fire is supposed to be due to oxygen burning, so to be accurate, orange particles for atmo engines, and blue particles for space engines...
 
- Obstruction
I do think obstruction for engines and adjusters needs to be reviewed.
Distance to target of obstruction needs to be lowered
Cone angle needs to be clarified
Obstruction cone need a graphic representation
 
 
 
LUA:
- Slots:
We should be able to call every single elements within same construct by their names without having to link them. So no more lua slots problem, and linkage would be for manual interactions without use of lua.
If i link this button with that door, i can manually open and close that door
But if i have 20 doors, i should be able to open or close them independently with 1 single programming board just by calling them by their names
Since automatic naming differentiate elements of same type with [number], those could be stacked in a table using this number as keys.
 
- Keybindings:
Would be nice to enable all the keyboard keys recognition for lua programming
 
- Resell:
When the "save to inventory with drm" button when we right click on scripted elements? so we could barter our scripts more easily.
 
 
 
Good luck, we are getting there!
Cheers
Jeronimo

Voxels make up almost everything you see in the world of Dual Universe. Currently, most creations are made using the basic tools we provide with standard shapes such as cubes, spheres, cylinders, wedges, and tetrahedrons. 
 
More intricate designs can be achieved through the art of ‘voxelmancy’ where players customize the shapes of voxels using a variety of methods and techniques based on how voxels react to each other when placed. This very advanced technique allows voxelmancers to place each corner of a voxel exactly where they want it. To do that, they use what is called a ‘voxel reactor’.
 

 
Voxel reactors, as amazingly useful as they are, have three major drawbacks:
They are time consuming to use. They are not very intuitive for beginners. They are laid out in a checkered pattern in all three dimensions.  
The last item on that list poses some technical problems. 

VOXEL COMPLEXITY
When we are effectively applying a checkered pattern of voxels of different colors or even air, it creates a relatively large amount of small surfaces. This doesn’t really pose a problem for a single reactor, but can be a performance burden for some voxel libraries that consist of thousands of reactors.
 
With more and more detailed constructs of complex design being built, it’s become problematic for the ‘mesh service’ system that generates the shapes that you see when not in build mode. On a few rare occasions, highly-detailed constructs may not render at all or their honeycomb will disappear. 
 
To prevent this from happening, we will gradually implement a limitation to the complexity that can be created in a single chunk of voxels. It will start with a simple complexity gauge in Demeter:
With the launch of Demeter, you will start by seeing a new feedback gauge while building which highlights the region you’re actively working on and will appear as a bar in the HUD that indicates the complexity level of that region as a percentage.  In a future update (exact update number still to be discussed), we will introduce the eagerly-awaited vertex precision tool (Known to many of you as the fabled vertex editor) as a way to ensure that the limitation to voxel reactors doesn’t hinder players’ ability to create amazing constructs in the game. (More on that below.) In a subsequent future (and yet undefined) update, we will enforce the complexity value limit to be 100% for any new voxel operations. As such, old constructs and blueprints will not be altered by this but may become unalterable if they are above the limit in a region. Rest assured that if you have an existing construct that’s above the limitation, you will still be able to use it as is.  
With all that out of the way, let’s get to the fun part!

THE VERTEX PRECISION TOOL
There is currently a bit of a gap between learning how to build using the basic tools and more advanced voxelmancy techniques, something we’ve wanted to address for a long time. The introduction of the vertex precision tool in a future update will allow you to take any vertex (a corner of a voxel) and move it to a new location on any of its three axes inside the vertex's moveable area at different resolutions. This will provide an intuitive way that fills that crucial gap between basic building and advanced voxelmancy to fine-tune your builds.
 
See the video below for a demonstration of how this works. Please keep in mind that the video only shows an early prototype, but we think it’s already promising enough to make you as excited as we are about the possibilities of this tool.
 
 

 

 
VENI, VIDI, VOXIED
I came, I saw, I voxeled 
 
We hope that these voxelmancy changes, along with all of the great new Lua functions added in the Selene update, will inspire and encourage you to make even more amazing things than you already are. 
 
Check out our Tutorials page for even more ideas and tips on using voxels to bring your creativity to life in Dual Universe. 
 
As always, we’d love to hear your comments and answer your questions on the forum. 
 

Honeycomb is the Major game content of DU which pretend to let players build what ever we want
But as it is now, it is tooooooo constrained and limited, buggy, and never looking as we wished, specially in between updates where dev dont know which numbers to tweak for better render results
 
 
The resources needed for making honeycomb: Some honeycombs such as concrete / brick / wood / glass(panels) should require more simple recipes, not requiring mined and refined ores, but raw stone, sand or wood, directly from the planets grounds and trees
Those could be considered as construction material, mostly for static constructs, and their weight should be increased for discouraging players using them on dynamic constructs
 
The honeycomb weight: As for now they are 0.1 times the weight of their relative correspondents on earth
In my opinion the word HONEYCOMB is well chosen, and give this futuristic aspect of a 3D printed honeycomb material
But i think it is still a bit too heavy, since in aerospace, it wouldn't happen to build ships with thicker hull than 5 or 10cm
I also think some honeycombs shouldn't have this weight reduction, or less reduction
For example: concrete * 1 / wood * 0.25 / metals * 0.075
 
The diversity issue: Here is my most hatred part of DU, the numerous amount of different honeycomb colors and finishes
nightmare for industry managers nightmare for players to spawn blueprints, that have dozens of 0.5m3 of different mats filling hundreds of container and inventory slots (that must be a lot of data in back end, but also lot of data for everyone uploads and downloads on front end) All refined material should have 1 and only 1 raw honeycomb with a raw aspect, on which we could later apply the color we want and the shininess we want in build mode
 
Removal of the "voxel replace tool" => replacement by the "voxel paint tool" I dont think anyone using this voxel replacement tool at all, it has its equivalent when copy pasting using the select tool
A paint voxel tool could use a popup window, around the bottom of the screen, same as the scanner does for the ores filters. In which we could select our
desired custom color from a palette the shininess we want from matt to glossy an optional bump map (stripes / screws / holes / galvanized etc...)    
The finish name "galavanized", change back to matt Galavanized is an anti rust coating process for iron, using zinc
From PTS server the "galavanized white iron", is the only correct color and aspect (the texture is pretty nice btw)
So :
galvanized only applies to iron, certainly not to aluminium, copper and others iron can be painted aswell with anti rust paint, but galvanized wont be galvanized is more of a raw finish texture, more than a color or a shininess (which could be added as a bump texture in the paint tool options)  
Textures scale New textures are gorgeous but they arent scaled properly (official and PTS)
Texture edges blending is also necessary
 
 
So Novaquark, if you desire to optimize, reduce lag, reduce loading of containers etc... the diversity issue should be your concern. If you desire to really let players build awesome creation, just unleash the constraints and give us more freedom of choice
We are not paid for testing, and for taking time developing our feedback on the forum after years of testing, so it would be nice to have a better reading of the gold mine for the game development that this forum is (taking notes, and putting them on a big white board is an idea)
After all, WE players are creating the content of the game, but if we dont have at least the few main features of Minecraft, which is gathering wood to make wood, not mining coal to make wood, that aint gonna work
 
Cheers

Honeycomb is the Major game content of DU which pretend to let players build what ever we want
But as it is now, it is tooooooo constrained and limited, buggy, and never looking as we wished, specially in between updates where dev dont know which numbers to tweak for better render results
 
 
The resources needed for making honeycomb: Some honeycombs such as concrete / brick / wood / glass(panels) should require more simple recipes, not requiring mined and refined ores, but raw stone, sand or wood, directly from the planets grounds and trees
Those could be considered as construction material, mostly for static constructs, and their weight should be increased for discouraging players using them on dynamic constructs
 
The honeycomb weight: As for now they are 0.1 times the weight of their relative correspondents on earth
In my opinion the word HONEYCOMB is well chosen, and give this futuristic aspect of a 3D printed honeycomb material
But i think it is still a bit too heavy, since in aerospace, it wouldn't happen to build ships with thicker hull than 5 or 10cm
I also think some honeycombs shouldn't have this weight reduction, or less reduction
For example: concrete * 1 / wood * 0.25 / metals * 0.075
 
The diversity issue: Here is my most hatred part of DU, the numerous amount of different honeycomb colors and finishes
nightmare for industry managers nightmare for players to spawn blueprints, that have dozens of 0.5m3 of different mats filling hundreds of container and inventory slots (that must be a lot of data in back end, but also lot of data for everyone uploads and downloads on front end) All refined material should have 1 and only 1 raw honeycomb with a raw aspect, on which we could later apply the color we want and the shininess we want in build mode
 
Removal of the "voxel replace tool" => replacement by the "voxel paint tool" I dont think anyone using this voxel replacement tool at all, it has its equivalent when copy pasting using the select tool
A paint voxel tool could use a popup window, around the bottom of the screen, same as the scanner does for the ores filters. In which we could select our
desired custom color from a palette the shininess we want from matt to glossy an optional bump map (stripes / screws / holes / galvanized etc...)    
The finish name "galavanized", change back to matt Galavanized is an anti rust coating process for iron, using zinc
From PTS server the "galavanized white iron", is the only correct color and aspect (the texture is pretty nice btw)
So :
galvanized only applies to iron, certainly not to aluminium, copper and others iron can be painted aswell with anti rust paint, but galvanized wont be galvanized is more of a raw finish texture, more than a color or a shininess (which could be added as a bump texture in the paint tool options)  
Textures scale New textures are gorgeous but they arent scaled properly (official and PTS)
Texture edges blending is also necessary
 
 
So Novaquark, if you desire to optimize, reduce lag, reduce loading of containers etc... the diversity issue should be your concern. If you desire to really let players build awesome creation, just unleash the constraints and give us more freedom of choice
We are not paid for testing, and for taking time developing our feedback on the forum after years of testing, so it would be nice to have a better reading of the gold mine for the game development that this forum is (taking notes, and putting them on a big white board is an idea)
After all, WE players are creating the content of the game, but if we dont have at least the few main features of Minecraft, which is gathering wood to make wood, not mining coal to make wood, that aint gonna work
 
Cheers

Honeycomb is the Major game content of DU which pretend to let players build what ever we want
But as it is now, it is tooooooo constrained and limited, buggy, and never looking as we wished, specially in between updates where dev dont know which numbers to tweak for better render results
 
 
The resources needed for making honeycomb: Some honeycombs such as concrete / brick / wood / glass(panels) should require more simple recipes, not requiring mined and refined ores, but raw stone, sand or wood, directly from the planets grounds and trees
Those could be considered as construction material, mostly for static constructs, and their weight should be increased for discouraging players using them on dynamic constructs
 
The honeycomb weight: As for now they are 0.1 times the weight of their relative correspondents on earth
In my opinion the word HONEYCOMB is well chosen, and give this futuristic aspect of a 3D printed honeycomb material
But i think it is still a bit too heavy, since in aerospace, it wouldn't happen to build ships with thicker hull than 5 or 10cm
I also think some honeycombs shouldn't have this weight reduction, or less reduction
For example: concrete * 1 / wood * 0.25 / metals * 0.075
 
The diversity issue: Here is my most hatred part of DU, the numerous amount of different honeycomb colors and finishes
nightmare for industry managers nightmare for players to spawn blueprints, that have dozens of 0.5m3 of different mats filling hundreds of container and inventory slots (that must be a lot of data in back end, but also lot of data for everyone uploads and downloads on front end) All refined material should have 1 and only 1 raw honeycomb with a raw aspect, on which we could later apply the color we want and the shininess we want in build mode
 
Removal of the "voxel replace tool" => replacement by the "voxel paint tool" I dont think anyone using this voxel replacement tool at all, it has its equivalent when copy pasting using the select tool
A paint voxel tool could use a popup window, around the bottom of the screen, same as the scanner does for the ores filters. In which we could select our
desired custom color from a palette the shininess we want from matt to glossy an optional bump map (stripes / screws / holes / galvanized etc...)    
The finish name "galavanized", change back to matt Galavanized is an anti rust coating process for iron, using zinc
From PTS server the "galavanized white iron", is the only correct color and aspect (the texture is pretty nice btw)
So :
galvanized only applies to iron, certainly not to aluminium, copper and others iron can be painted aswell with anti rust paint, but galvanized wont be galvanized is more of a raw finish texture, more than a color or a shininess (which could be added as a bump texture in the paint tool options)  
Textures scale New textures are gorgeous but they arent scaled properly (official and PTS)
Texture edges blending is also necessary
 
 
So Novaquark, if you desire to optimize, reduce lag, reduce loading of containers etc... the diversity issue should be your concern. If you desire to really let players build awesome creation, just unleash the constraints and give us more freedom of choice
We are not paid for testing, and for taking time developing our feedback on the forum after years of testing, so it would be nice to have a better reading of the gold mine for the game development that this forum is (taking notes, and putting them on a big white board is an idea)
After all, WE players are creating the content of the game, but if we dont have at least the few main features of Minecraft, which is gathering wood to make wood, not mining coal to make wood, that aint gonna work
 
Cheers

Sample Scripts (Advanced)
These more advanced scripts demonstrate what can ultimately be achieved with this API. Perhaps they will inspire you a bit!
 
Entropy Like the bouncy ball example, but fancier!
local ballCount = 5000 local speed = 20 local rx, ry = getResolution() --[[ init ]]-------------------------------------------------------------------- if not init then init = true function randF (a, b) return a + (b - a) * math.random() end function randExp () return -math.log(1.0 - math.random()) end balls = {} for i = 1, ballCount do local e = {} e.x = randF(0, rx) e.y = randF(0, ry) e.r = 1 + 1.0 * math.log(1.0 - math.random()) ^ 2.0 e.vx = randF(-1, 1) * randExp() e.vy = randF(-1, 1) * randExp() e.cx = 1.0 * math.random() e.cy = 0.1 * math.random() e.cz = 0.4 * math.random() e.ca = math.random() table.insert(balls, e) end end --[[ simulation ]]-------------------------------------------------------------- local dt = speed * getDeltaTime() for _, v in ipairs(balls) do v.x = v.x + dt * v.vx v.y = v.y + dt * v.vy if v.x < 0 or v.x > rx then v.x = v.x - dt * v.vx v.vx = -v.vx end if v.y < 0 or v.y > ry then v.y = v.y - dt * v.vy v.vy = -v.vy end end --[[ rendering ]]--------------------------------------------------------------- local l = createLayer() -- render balls for _, e in ipairs(balls) do setNextFillColor(l, e.cx, e.cy, e.cz, e.ca) addCircle(l, e.x, e.y, e.r) end -- render title local font = loadFont('Play-Bold', 64) addText(l, font, '{{ E N T R O P Y }}', 32, ry - 32) requestAnimationFrame(1) --------------------------------------------------------------------------------  
 
Radial Menu Practical example of how responsive UI elements could be designed, creates 3 radial menu's using the same function.
Left: Example with transparency on the circle layer to demonstrate layering and the use of math to define the circle stroke.
Top right: Example without transparency, drawn to a different scale.
Bottom right: Example of a collapsible version saving screen real-estate and reducing rending costs while collapsed. (Only a dot is drawn while collapsed)
-- Get screen resolution and center coordinates local resolutionX,resolutionY = getResolution() local centerX,centerY = resolutionX/2, resolutionY/2 -- Draw radial menu layers local triLayer = createLayer() local circleLayer = createLayer() local textLayer = createLayer() -- Define some helpers to convert degrees to radians local d2r = math.pi/180 -- Helper function to get distance of cursor from coordinates function getCursorDistance(x,y) local curX,curY = getCursor() curX = curX - x curY = curY - y return math.sqrt(curX^2+curY^2) end -- Helper function to check if cursor is inside a radial menu section function isCursorInside(radialCenterX,radialCenterY,radiusMin,radiusMax,degMin,degMax) local curX,curY = getCursor() curX = curX - radialCenterX curY = curY - radialCenterY local magnitude = getCursorDistance(radialCenterX,radialCenterY) local deg = math.atan(curY/curX)/d2r if curX < 0 then deg = deg + 180 end if curX > 0 and curY < 0 then deg = deg + 360 end if magnitude <= radiusMax and magnitude >= radiusMin and deg > degMin and deg < degMax then return true end end -- Define function that can draw a radial menu on demand function drawRadialMenu(posX,posY,radius,steps,hide,strokeAndCenterAlpha) -- Define default variables local posX = posX or centerX local posY = posY or centerY local radius = radius or 200 local steps = steps or 15 if hide ~= nil then hide = hide else hide = true end local strokeAndCenterAlpha = strokeAndCenterAlpha or 1 -- minimum of 4 segments steps = math.max(steps,4) -- work out the depth of the triangular facets along the circumferance and use it to determine the outer circle stroke width local aX,aY = radius*math.cos(0) , radius*math.sin(0) local bX,bY = radius*math.cos(((360/steps)*1)*d2r) , radius*math.sin(((360/steps)*1)*d2r) local stroke = math.min(-(radius-math.sqrt(((aX+bX)/2)^2+((aY+bY)/2)^2)),-3) if not hide or (hide and getCursorDistance(posX,posY) < (radius)) then -- Draw triangular segments local alpha = 0.5 for step=1,steps,1 do -- calculate the corners of the triangles on the radius local aX,aY = posX + (radius*math.cos(((360/steps)*(step-1))*d2r)) , posY + (radius*math.sin(((360/steps)*(step-1))*d2r)) local bX,bY = posX + (radius*math.cos(((360/steps)*step)*d2r)) , posY + (radius*math.sin(((360/steps)*step)*d2r)) -- call helper function to determine if cursor is inside the segment and change color if true if isCursorInside(posX,posY,radius/3,radius,((360/steps)*(step-1)),(360/steps)*step) then setNextFillColor(triLayer,1,1,1,1) -- create center number while the cursor is over a selection local font = loadFont('Montserrat', math.floor(radius/4)) setNextFillColor(textLayer, 1, 1, 1, 1) addText(textLayer, font,step, posX-((radius/12)*#tostring(step)), posY+math.floor(radius/12)) else setNextFillColor(triLayer,1,0,0,alpha + 0.5) end -- Draw the triangle based on pre-calculated coordinates and with the color now preset addTriangle(triLayer,posX,posY,aX,aY,bX,bY) -- flip the alpha between 1 and 0 for the next segment alpha = 0.5 - alpha end -- Create the outer stroke which should be a negative value so it overlaps the triangle facets setNextStrokeColor(circleLayer,0.5,0.5,1,strokeAndCenterAlpha) setNextFillColor(circleLayer,0,0,0,0) setNextStrokeWidth(circleLayer,stroke) addCircle(circleLayer,posX,posY,radius) -- Create the inner stroke and fill to create the "hole" in the center at 1/4th of the radius. setNextStrokeColor(circleLayer,0.5,0.5,1,strokeAndCenterAlpha) setNextFillColor(circleLayer,0,0,0,strokeAndCenterAlpha) setNextStrokeWidth(circleLayer,stroke) addCircle(circleLayer,posX,posY,radius/4) else -- Create a transparent dot to indicate its position while its hidden. setNextFillColor(circleLayer,0.5,0.5,1,0.2) addCircle(circleLayer,posX,posY,radius/4) end end -- Draw three examples -- Example 1 (large one on left) with transparency to demonstrate how the circular shape was achieved with the triangles. drawRadialMenu(resolutionX/3,centerY,200,6,false,0.5) -- Example 2 (Top right) Does not hide, shows the result without transparency drawRadialMenu((resolutionX/3)*2,resolutionY/3,100,8,false) -- Example 3 (Bottom right) Remains hidden and un-rendered until the cursor enters its area, reducing render cost by ~120000 while hidden. drawRadialMenu((resolutionX/3)*2,(resolutionY/3)*2,80,36) -- render cost profiler if true then local layer = createLayer() local font = loadFont('Play-Bold', 14) setNextFillColor(layer, 1, 1, 1, 1) addText(layer, font, string.format('render cost : %d / %d', getRenderCost(), getRenderCostMax()), 8, 16) end -- Request a refresh requestAnimationFrame(1)  
 
Text positioning Demonstration example of the various alignment points for text using Font Metrics and Text Align.
local fontName = 'Play' local fontSize = 32 local font = loadFont(fontName, fontSize) local fontDebug = loadFont('FiraMono', 12) local back = createLayer() local layer = createLayer() local rx, ry = getResolution() local ascender, descender = getFontMetrics(font) local text = "??" frame = (frame or 0) + 1 setDefaultFillColor(layer, Shape_Text, 1, 1, 1, 1) setDefaultFillColor(layer, Shape_Circle, 1, 0, 0, 1) function drawTextBox (x, y, alignH, alignV) local w, h, ascent, descent = getTextBounds(font, text) if alignH == AlignH_Left then x = x elseif alignH == AlignH_Center then x = x - w/2 elseif alignH == AlignH_Right then x = x - w end if alignV == AlignV_Ascender then y = y h = ascender - descender elseif alignV == AlignV_Top then y = y elseif alignV == AlignV_Middle then h = ascender - descender y = y - h/2 elseif alignV == AlignV_Baseline then y = y - ascent elseif alignV == AlignV_Bottom then y = y - h elseif alignV == AlignV_Descender then h = ascender - descender y = y - h end setNextFillColor(back, 0.1, 0.5, 1.0, 1.0) setNextStrokeWidth(back, 1) addBox(back, x, y, w, h) end function main () if frame % 2 == 0 then text = "acemnor " else text = "aCjÅkö[]|!r " end -- display debug info about font if true then local infoLines = { string.format(" font : %s", fontName), string.format(" size : %d", fontSize), string.format(" ascender : %d", ascender), string.format("descender : %d", descender), } for i, line in ipairs(infoLines) do setNextTextAlign(layer, AlignH_Left, AlignV_Top) addText(layer, fontDebug, line, 16, 16 + (i - 1) * 12) end end local alignHs = { 'AlignH_Left', 'AlignH_Center', 'AlignH_Right', } local alignVs = { 'AlignV_Ascender', 'AlignV_Top', 'AlignV_Middle', 'AlignV_Baseline', 'AlignV_Bottom', 'AlignV_Descender', } -- draw text boxes with various alignments local sx = 300 local sy = 80 local x0 = rx/2 - sx * (#alignHs-1)/2 local y0 = ry/2 - sy * (#alignVs-1)/2 for y, alignVName in ipairs(alignVs) do for x, alignHName in ipairs(alignHs) do local px = x0 + sx * (x - 1) local py = y0 + sy * (y - 1) local alignV = _ENV[alignVName] local alignH = _ENV[alignHName] drawTextBox(px, py, alignH, alignV) setNextTextAlign(layer, alignH, alignV) addText(layer, font, text, px, py) addCircle(layer, px, py, 3) end end -- draw AlignH labels for x, alignH in ipairs(alignHs) do setNextTextAlign(layer, _ENV[alignH], AlignV_Descender) setNextFillColor(layer, 0.5, 0.5, 0.5, 1) addText(layer, fontDebug, alignH, x0 + (x - 1)*sx, y0 - 16) end -- draw AlignV labels for y, alignV in ipairs(alignVs) do setNextTextAlign(layer, AlignH_Right, _ENV[alignV]) setNextFillColor(layer, 0.5, 0.5, 0.5, 1) addText(layer, fontDebug, alignV, x0 - 16, y0 + (y - 1)*sy) end end if not isFontLoaded(font) then requestAnimationFrame(10) else main() requestAnimationFrame(120) end  

Sorry, but this is just the next iteration of "we heard you"
 
There is nothing substantial in this post, it does not commit to anything and just reiterates how NQ has failed to listen (which is not the same as hearing in case you wonder) to what their community is telling them.
 
That hey seem to think that much changed from Alpha is frankly very funny as they have just continued their attitude and ways from there with little to no change, that they seem to think or try to make the claim they did is probably the most worrying aspect of this post.
 
The proof wil be in the pudding here but based on the many previous attempts by NQ to spin their mistakes and shortfalls by not really taking ownership but pretend they will does not give me much hope for change.. But we'll see

how old is that trello, for that nobody remembers it?
https://trello.com/b/Y6WNMd2S/dual-universe-community-suggestions

NEW UPDATE ON THE PTS!


The Dual Universe Public Test Server (PTS) is online once more! This time, you can take a look at content from the future 0.25 update.
More specifically, what we would like our players to test are the following features:
The new voxel storage tech. We proceeded to large, fundamental changes in how voxels are stored server-side, optimizing and improving player bandwidth usage going forward. To test this, it would greatly help us if players could wreak havoc on planets' soils and dig, dig, DIG as much as possible!  Three new tutorials are available in the "Tutorials" tab of the VR Station: Gunnery tutorial, RDMS tutorial, and Advanced Construction tutorial. Make sure to visit them during your journey!
On a side note, the Screen Unit tech change isn't on the PTS just yet. You'll be able to test that in an upcoming version!
  You can tremendously help Novaquark by playing on the PTS. Not only will you have a chance to see content that’s in development before it’s released on the Live server, but you’ll also be helping to shape DU through sharing your insights and constructive criticism earlier in the development process. By testing on PTS and sharing your feedback, you will directly help improve DU.
  On PTS, you have some perks to help you speed up your progress and have an easier time getting the things you need: 
Dispensers that provide most items for free. A daily allowance of several billion quanta per day. Teleporters at the Market 1 of each major planet, allowing for free teleportation around the universe. For Alioth, the teleporter is located by the dispensers in the Institute District. Three additional teleportation platforms are deployed in space on the edge of the PvP zones Players can respec Talent points at-will.  The Fetch feature with no limit of range or cooldown.
Feedback and bug reports related to PTS should be posted in this designated forum, which we monitor closely as part of our commitment to improve the quality of the game and its performance. 

Please note that PTS is solely for testing purposes and may go offline at any time without prior notice. We are doing our best to keep the PTS online as long as possible, but we cannot guarantee that it won't be taken down if we meet a major issue. 
We’d also like to manage expectations that PTS updates may include feature prototypes and gameplay changes that might not ever come to the Live server. Moreover, there won't be any live Support on the PTS.

Three years and half after pre alpha launch, the best period ever for DU, everything got overcomplicated, heavy and excruciatingly laggy, especially at the introduction of industry 2.O which has changed till now fps, lag and loading times for everyone, but since the developers aren't testing nor playing their own game, very little have been done concerning the content and game mechanics.

Since the beginning JC pretends that he wants to control the visual aspect of the game, but look at the thousands of player made atrocities and piles of elements scattered everywhere
 
For those who never heard about, but there is a french simplistic and satiric cartoon called "Shadoks", where a group of engineers and workers, work hard together to make simple things more complicated, from where we are getting the expression: "why do simple when you can do complicated?"
And this is exactly what is happening here
 
But in real life, and i quote, professionals, engineers, designers, and architects will all agree: "Less is more"
 
So here are my thoughts, after 3 years of hope and life time, on the bad and good decisions taken, and what could be improved at the moment:
 
 
 Building mechanics: Vertices editor should have been a priority long ago, long before that not so useful update on the line tool
The actual given building tools are half of the reason why we see so much trash everywhere, and why most players are giving up, because voxelmancy is a considerable waste of time since ship selling will never be a major part of the market (everyone want to build his own), PVP will destroy it in a matter of seconds, and detailed or undetailed static or dynamic constructs' spaces are dead as hell.
 
Vertices Editor: self explanatory
  Line tool: add triangular and circular shapes, and make one of the corners of the selection the center of rotation (not the center of selection, this doesn't make any sense)
  Paint tool: (omg seriously this one is the biggest joke and laziest decision taken) need to absolutely remove from the game this ridiculous number of different honeycombs, performance wise, and gameplay wise. Every material should have one and only one raw honeycomb, on which we could, using build mode, apply a color we want, a shininess type and or a pattern
That would optimize the game code, our inventories/containers, and our factories (and will fix that uggly .24 update changes)
  Remove the deploy and selection sizes limitations
  Be more consistent in the deploy shapes size increment (1 by 1, not 1 2 3 4 5 6 8 12 16 24 32)  
* by the way change "galvanized" honeycomb name and check the definition of galvanized on wiki: which is a zinc coating process to protect different metals from rusting
 
 Elements: Here is the second half of the reason why we are surrounded by trashes
First, element design is very badly fusing with the voxel building system, specially all the dynamic constructs elements, elements are detailed meshes that don't match with a voxel hull and the voxel default sizes
Even after the best achievable voxelmancy, engines, brakes, hovers, wings, look like stains on our creations, element colors dont match available honeycomb colors, some elements are offsets, some are badly symmetrical
I m not saying that its bad to have detailed mesh elements, but half of them, must be redesigned to be used and integrated "into" a basic voxel shapes, not to be put like a flower pot "on" the voxels, and this concerning all the elements used for designing ships
 
Dynamic elements (engines, brakes, airfoils): those elements can be a single detailed face element, the face that will pop out from our voxels, and other faces must be designed with an easier global shape to work with the voxel grid (tubular, square, rectangle, just as Empyrion or Space engineers do...)
  Decorative elements: make sure they are scaled for the voxel grid and size (the reinforced sliding door is the perfect example of bad design and bad consideration)
  Ability to change elements main color
  Engines: no no no and no to all this different types of engines (safe/maneuver/military/etc...) with different recipes. again its a mess in inventories and markets, same problem as honeycombs, why doing simple when can do complicated?. while the quality (normal/advanced/rare etc...) should remain, all engines should be crafted as a standard factory type, and have an option by right clicking on them to change their mode type, and why not beeing able to change it using lua  
 
Flight mechanics: Overall the flight mechanics are very good, stable and well developed
But, the main issue is bringing back to the dynamic elements issue and the overall aesthetic of the game and players creations
 
Elements power/thrust should be multiplied by a minimum of 5!!!! this would greatly reduce the number of elements needed on each ship, reducing the lag and loading time, but most importantly we would not compromise anymore on the design in order to have "acceptable" flight performances (which will increase the visual quality of players creations)
  Vertical and horizontal cross sections must produce anti drift and high altitude lift, which will reduce the number of wings and stabilizers elements needed, and again will increase everyone performances due to less elements, and allow better ship design
  Fuel consumption to divide by 2 or more, we are tired to mine 2 hours, refine for an other hour, for 20min of flight (nowadays long distances planes can fly at cruise speed 900kmph for about 12 to 14 hours)  
 
LUA Lua is one of the greatest part of the game, allows the best customization possible, but is still way too limited, for no reasons
 
Unlock to unlimited  number of links/slots to a pb/remote/ECU/command chair etc... will reduce the number of scripts running at same time, so will increase performances (what is better? to have 10 scripts, on 10 PB, each one linked to 10 elements? or 1 script on 1 PB linked to 100 elements? do the math!)
  Increase again the recently nerfed CPU usage for custom scripts (they were not producing any client side performances issues, so why decreasing it again?)
  Increase the conf file allowed size, 150k isnt enough
  Make possible to install conf files on programming boards
  Increase Databank sizes
  Fix the rocket engine please for custom scripts, they are broken and deadly, they activate themselves when construct controls are taken
  Add function for camera relative rotation and position
  Ability to save scripts in our nanopack and exchange/sell scripts with DRM protection or not  
 
PVP I think pvp is a very delicate topic, but globally so few people have any interest in pvp at all due it its extrem unbalance
In my opinion there is no goal and no reward in pvp, which makes it boring
So much time and effort put in mining/producing/building a pvp-able ship that it pushes everyone away
 
there should be no safe zone, nowhere!
- heard and read too many stories of players ravaging orgs from the inside, secretly stealing work of dozens, and then venting themselves on streams. there should be no safe                        place in the universe for those people to hide their shameful loot
- cargo ships should be accompanied and escorted by armed fleets, even while mining
  quantas could be physical/stockable/stealable
  claimed territories shouldnt be visible on the map, unless personally discovered surface ore stones, should be mine-able by anyone anytime anywhere (claimed or not. we should be able to get some fast scrap and fuel if we emergency land in middle of a huge claimed territory)
  static and dynamic construct need energy shields element
  containers content should not be destroyed unless the container lost all its lives (otherwise there will be no loot in pvp), they should just be inaccessible
  there should be a way to restore all lives on salvaged elements (repair unit maybe?)  
 
 
 
 
There is so much more to add, but please NQ consider and fix a big part of this first before adding new buggy "content"
At some point there should be a planetary wipe, to leave space for the new planets design (allowing what ever is standing in space to be excluded from the wipe, for players beeing able to save enough to restart quickly)