Murmandamus

They can DU DU however they want to DU, DU. You know?
 
Kinda like my original post in here... They win by however they want to play the game and however they define their winning as. Just as I DU DU and you'll DU DU.

Okay!

Yeah, great grapics, but the gameplay sucks.

"Winning" is an arbitrary line in the sand.
 
DU is a sandbox.
 

Build a bonsai... win DU

I don't think you've actually seen proper cash grab games yet....
 
 

lol

I voted for option 1, but I think the org page should display 2 values. We should all be able to see an orgs total numbers and their paid account numbers.
 
Their overall rank can consist of their ghost and real accounts together still.

There seems to still be some misunderstanding about my stance on PVP combat as well as continuing confusion on the purpose of this thread. You may read all about my stance on PVP combat and ask question here: 
TLDR? Then you don't really want to know so STFU.
 
Further discussion of that topic in this thread will be reported as off topic and  trolling.

Please don't take this the wrong way, but how you guys have set up your pledging is super confusing.  When I go to see if I want to pay to play your game and pay for the  $60 Contributor pack I first off notice that there is no such indication that you have to subscribe up front, which to me is dishonest,  only after searching around did I find that I would also have to pay for a subscription.  Also if I did buy the game for $60 and I did not know that after I paid for the game I would now also have to continue to pay a subscription I would be very upset especially how the subscription information is hidden away. 
 
The next thing that I would like to say and ask, is if I were to buy the game I see that I would receive 3 Dual Access Coupons with each coupon equals 30 days of free gameplay.  So what does that mean?  is that 30 calendar days, or 30 days (30 x 24 = 720 hours)  of time I spend in the game? So if I login and play for 4 hours do I still have 716 hours left until I need to use my next  Dual Access Coupon? 
 
Also it says that I can use in game currency to buy more  Dual Access Coupons.  Does that mean I can grind and work in the game to pay for a new Dual Access Coupon without ever having to spend any more real money on this game, or does that mean I use real money to buy in game money to then buy more Dual Access Coupons?
 
And finally the last confusing thing,  is if I buy the game now it says  "The game Server may only be available during specified testing periods. The dates & times of upcoming server tests can be seen at the top of the DU homepage or on the server status page ."  I than clicked on the the server status page  link and it said that the access start date for Alpha 2   is on  November 28, 2019 - 14:00 UTC (which is tomorrow)  through  December 02, 2019 - 14:00 UTC  for only  96:00 hours, and if I  Pledge now I can get access now even though it says it starts on November 28, 2019 - 14:00 UTC (which is tomorrow).  Also does this mean that if I pledge now I only get to play for 96:00 hours, or does it mean I have only 96:00 hours to sign up until I can not get access to play until the next window of opportunity to pledge and start playing the game?
 
Please help me understand these questions.
 
Thank you.
                       

(Update: November 12th, 2019: detailing the content that will be released before the end of the year)

Dear Community, 
 
We heard your feedback regarding our communication that wasn't as regular during the past months than it was before, in addition of a few miscommunication incidents. That's why we decided to plan several events to catch up and address that topic before the end of the year:
 
For those who have questions (or concerns) about Dual Universe or Novaquark, we've just opened a dedicated thread here (as many questions may be related to subjects under NDA, and we can't check beforehand, we had to put the forum thread in a section under NDA. If you're not a backer and you have questions on topics that aren't under NDA, feel free to contact NQ-Nomad and/or NQ-Nyzaltar by private message on the forum, and they wil transmit them to the team). No question is taboo. Although we can't promise to give a clear and detailed answer for each question, we will try our best to reply as much as we can.
  Here is the content related to communication we plan to release before the end of the year:
- a video presenting the updated roadmap.
- a Dev Diary video showing the recent progress on the game development
- a PodCast where we will try to answer the most pressing matters (based on the questions posted in the dedicated thread).
- an AMA event where we will try to answer to the remaining questions.
- a Kickstarter update.
  We can't give specific dates for all of this content yet, but all will be released before the end of the year.
 
Best Regards,
The Novaquark Team.

If they REALLY preferred playing grouped, they would CHOOSE grouped play, lol
 
None of the "convenience" features you listed prevent group play...

You are all missing the most important thing that differentiate solo vs group play.
 
Group play equate group drama.
Solo play equate solo drama; wait what?
 
I've played MMO's since UO/Mankind, the only thing I can say is, group play when more than a few always end up in drama. Do I want drama? No, I'm here to enjoy myself not to manage adult babies and their egos.

I so choose solo play, with a few friends here and there.

I know that "predefined sounds" is on the "Considered" list on Trello: https://trello.com/c/HVdTjEsH/51-functional-scriptable-speakers-able-to-play-predefined-sounds 
 
While I think that would be cool, I think it would be cooler if we had access to a synth sound module through LUA to build and sequence our own custom sounds. 
 
Writing sound synthesis by hand isn't unheard of in LUA, for example:
 
 
 
And even more, here are some tracks composed entirely with LUA:
https://soundcloud.com/luehi/systemf  https://soundcloud.com/luehi/luacid1 https://soundcloud.com/luehi/early https://soundcloud.com/luehi/selfkitchen https://soundcloud.com/luehi/luaessay5 https://soundcloud.com/luehi/movk  
I think that giving us the flexibility to define our own sounds with such an approach would be incredibly more valuable than choosing from a list of predefined sounds. 
 
In case anyone is wondering, yes I am suggesting this because I want a night club in DU.

Hey guys! NQ-Wave here, and today we’re going to talk about the changes we’ve made regarding ship and character movement that are upcoming in Alpha 2 of Dual Universe.
 
In Dual Universe, players will be flying all kinds of constructs; from small hovercrafts roaming the ground to huge spaceships floating in space, from atmospheric planes to ambivalent atmo/spacecrafts. These very different configurations mean experiencing very different sensations. As you already know, we’ve always wanted to take a more realistic approach to how we handle space travel, especially with a ship’s inertia within a dragless void. 
 
We were quite happy with how ships translated differently in atmosphere and space, but we hoped to add an improved sensation of weightlessness. And now it’s done! Now when trying to manoeuver a ship while in the atmosphere, you should experience the true dragless feeling of space and the effects of air upon a ship’s hull. Even if you only have a few adjustors, you’ll still be able to rotate your gigantic battlecruiser if you give it (a lot of) time, whereas, in the atmosphere, drag will keep you immobile.
 
Also, in the sad event of a collision between your ship and whatever hazardous object floating about in space, you’ll really feel something! But we’ll let you try it for yourselves! (Though we don’t really suggest it.)
 
There is something else we want to tell you about moving around in this scary, nearly empty void. Let’s say you’re enjoying your nice space travel, gliding frictionless at a few tens of thousands of km/h. Suddenly, you realize that you don’t have enough fuel for deceleration, and maybe because of a small lack of planning, your fuel tank is inaccessible from inside the hull! Don’t blame yourself, that happens to everyone eventually. If you want to decelerate, you’ll need to refill! You have two options here. You could just ignore this small problem and pray before going down in a fiery blaze upon the surface of your destination planet.

3, 2, 1, 0 G!
 
But since crashing on a foreign planet is probably a player’s last resort, let’s approach this differently!  We bet that you wished your Nanosuit would enable you to make an extravehicular trip to reach this fuel tank. Well, now that’s totally possible!
As of Alpha 2, your Nanosuit contains a jetpack that allows players to glide around in space! To try it, you just need to be far enough from any planet. Keep in mind that this jetpack is not powerful enough to compensate for high gravity. Once you open the airlock of your ship, just jump into the great unknown! 

Once you begin floating in space, you’ll hear the familiar, yet reassuring sound of your jetpack. To control it, you can use the WASD keys to move horizontally. The Space Bar and C key will give you vertical movement. And since there is no gravity to hold you down, you can roll your character with A and E keys.
 
Due to the physics of empty space, only the acceleration is controllable. When removing your hands from the keyboard, your character will continue to glide along at a constant speed! But maybe you’d prefer to better stabilize for precise control. That’s why we’ve added a brake in your Nanosuit which you can use to nullify your speed. Just press CTRL to activate it!
Of course, because of how physics work, you’ll be able to manoeuver around an immobile space station as well as around your small fighter traveling full speed in space. And we’ve even heard that you can use this jetpack to jump from one construct to another when they are doing a fly-by. But here again, maybe that’s not the best idea for your survival. We can’t say we didn’t warn you! Now, get out there and enjoy your extravehicular activities!
 
Enough about space! Let’s put our feet back on solid ground for a minute. There is other stuff to talk about.

I’m Like A Bird!
 
When you’re on the surface of a planet that is lucky enough to have an atmosphere, you’re used to moving your ship through use of ailerons, using air to provide lift and sustain your ship in altitude. Ailerons are very useful both for lift and drift compensation. You were also used to stabilizers; elements that enable you especially to compensate drift.

We’ve now unified the behavior of those elements. You’ll now find them in the ‘Airfoil’ category, and be able to choose between ailerons, stabilizers, but also traditional fully functional wings. These elements work in similar ways and can be used for lift and drift compensation. The controller of your ship will automatically use them for one of these goals depending on their orientation.
 
These elements have different characteristics, however. Ailerons do not produce a lot of drag, but can stall easily. You must make sure that the angle between your aileron and your current speed is not too large or you’ll stall and won’t get any lift! And crash — probably. On the other hand, stabilizers are very forgiving in regard to stalling and can be very useful to compensate drift during a sharp turn, but they induce a lot of drag. Finally, wings offer a tradeoff between drag and stalling. We’re sure that you’ll find the Airfoil element that best fits your purpose.
 
Speaking of piloting, we’ve also made some wanted changes in this area. First of all, we decided to have varying behaviors of ship control depending upon the situation. In the past, hovercraft planes and spaceships used to be controlled in a similar way, and we wanted to change that to better adapt controls for the type of ship you are building. When piloting a hovercraft, you don’t care as much about your roll than when piloting a spaceship, for instance.

Some Va-Lua-ble Insights
 
As you may already know, the behavior of a dynamic construct is controlled by its Lua configuration. When you create a dynamic construct and place a control unit on it, the Lua configuration of that control unit is automatically done for you. You don’t need to tweak a single thing! This is the autoconfiguration of your ship, and the behavior is chosen depending upon the element you use as a cockpit. A hovercraft seat will use a ‘hovercraft’ autoconfig scheme, whereas a fighter cockpit or a commander seat will use the ‘airplane cockpit’ autoconfig scheme. You can also manually choose the autoconfiguration you want to apply to your control unit by right-clicking on the element and choosing ‘Run default autoconfigure’.
 
At its core, Dual Universe is about customization. As we previously mentioned in our last DevBlog, we’ve made several improvements regarding Lua in general, and made it possible to change select behaviors without requiring code. You can do that by right-clicking on the cockpit of your ship, and choosing ‘Actions for this element’ > ‘Edit Lua parameters’. This opens a window where you can change the control parameters of your ship. Once you have autoconfigured your ship, you can use this panel to choose the rotation speed, for example.

Through this same panel, you can also change major behaviors of the airplane cockpit control scheme. (Try changing the autoStabilizeRoll and rollInducedYaw parameters to experiment advanced control!)
One last word, if you want to dive a little bit more into the arcane of piloting configuration, don’t hesitate to try and modify the new autoconfigure scripts of your constructs. We made significant strides to give you easier access to your ship’s control and allow for easier experimentation. Try it out! Just right-click on a control unit and choose ‘Actions for this element’ > ‘Edit Lua script’. Hint: A lot can be done in the system -> flush event.

Don’t be afraid of giving something new and creative a whirl! You can safely try all sorts of things here without being a total code nerd. And if by mistake you break something and your ship becomes uncontrollable, just re-run the autoconfigure, and your construct will be good as new.

That’s all for today! We hope you’ll have fun playing with this new way to pilot ships in Dual Universe, and the new jetpack. As always, don’t hesitate to give us your feedback regarding these new changes, and thanks a lot for your support.
 
Best,
NQ-Wave

Hi Noveans!
 
I’m Maxime Ferrieu aka NQ-Giantsmoy, Lead Audio at Novaquark Paris. You may already know me as the music composer for Dual Universe, but today, I’d like to tell you more about something we haven’t showcased yet, and that we think is really important: the sound design! Working at Novaquark, I’m not only responsible for the music, but basically everything you hear in the game, especially what we are going to discuss today: ambient sound!
 
Before going further, I want to stress right away that we will dive deep into the rabbit hole and this will be rather technical. 
 
Ambient sound is critical to building an immersive soundscape, and in Dual Universe, this raises quite a number of challenges. The emergent / player-edited world leaves us completely unaware of what a player’s environment will look like at any given time or location. In a traditionally designed game world, ambient sound switching is generally done via trigger volumes. The player enters the trigger volume, we fade out the current ambient sound and then fade in a new one. Job’s done. Simple. But this standard method is inapplicable for DU because players can terraform and design their own geometry. 
 
A second solution would be to rely upon the underlying biomes that the player is currently in. But again, what if those players completely wipe all of the trees in a forest biome? Without a forest, will the ambient sound of one be sensible or relevant? Again, the creative freedom given to the players forces us to take an alternative approach to this problem.
 
After a period of trial and error, we decided on a nested detection approach. It may sound complicated, but it’s actually very simple! The graphic below shows how the ambient system is currently implemented in the game:
 


The idea here is to ask questions about the player’s environment to the game engine, which will tell the ambient sound system which sounds to appropriately render in real-time. We are using Wwise, by the good folks at Audiokinetic, to manage the audio in Dual Universe. It’s a diverse and powerful tool that allows us to create complex sound behaviors very easily in addition to receiving real-time parameters from the game engine to modulate sound properties. And that’s perfect for our scenario.
 
The first question we ask is: Is the player underwater? If so, we play an underwater ambiance and filter the current above water ambient. Simple, yet effective. 
Things get more interesting when above water. We have to detect if we are in or out, and as I mentioned before, there is no way to rely on trigger volumes for this task. To determine this, we went for a raycast approach. Every frame, a ray is launched in a random direction and tells us if it collided with geometry or not. The ratio of rays that collides gives us an approximation of what we call the ‘Indoor Factor’. In the game, you are now hearing a blend of indoor and outdoor ambience based upon this value, which is cool, but we can go further than this.

For the indoor ambience, we can also check if it’s a soil voxel, construct voxel, or element. With the same type of operation, we can determine a ratio of cave/construct ambience and render a blend of sound that appropriately suits the situation. We can also calculate the average of the rays' lengths before they collide using simple math. This gives us an approximation of the volumetric size of the interior to apply reverberation to accordingly, which plays a big part of the indoor ambience as a whole.
 
For outdoors, we conduct a simple asset detection around the player. We place a base wind layer and on top of that, we ask the game engine how many tree assets are in a given radius around the player. How many small vegetation assets? With those values, we can easily render deserts/prairies/forests and everything in between. The main challenge here is that the detection must be tightly coded due to it being CPU intensive, and I think we reached a solid compromise in the latest releases. We keep working on improving, though. We stated this multiple times in the past, we’re still in Alpha and actively developing the game. Optimization is still work in progress!
 
In addition to the previous, we also detect atmospheric density. This allows us to change the base wind sound if we are at sea level or at various altitudes transitioning into space.
 
The version we are shipping for Alpha 2 on July 11th is the first iteration of the environment sound system. It provides us a solid technical ground to build upon when adding extra layers of detail in the future. This means adding branches to the tree diagram shown above with weather variations, temperature, and hygrometry (which helps us to determine biomes more precisely), and things such as unseen wildlife (no ETA for this to be implemented yet). Basically, everything we can think of to give the player a richly-detailed, immersive, and interactive ambient sound.
 
We will show you examples of this sound system in the upcoming Dev Diary video, so stay tuned!
Hope you guys enjoyed this article and I’m looking forward to interacting with you in the game!  Enjoy Alpha 2!
 
Maxime FERRIEU / (NQ-Giantsmoy)
Audio Lead - Novaquark Paris

Hi guys, 
 
Following up the release of the third Alpha 2 DevBlog about Lua, we wanted to develop things further for the most curious, dedicated and skilled among you. The API has changed so you guys will have to redo a certain amount of stuff. This being said, you'll find below some documentation that will allow you to do pretty neat stuff so knock yourselves out!
 
Thanks to NQ-Arlequin for his help and for writing this! 
 
How does it work
 
All ControlUnits (Cockpits, HovercraftSeats and ProgramingBoards) can display information on the screen when activated by the current player. CockpitUnits and PilotingSeats have predefined behavior that should suit most players. However advanced players can edit the ControlUnit LUA script to adapt the display to their needs.
There are different levels of customization possible:
 
 
Intermediate Difficulty: Show/hide the default widget of an element linked to the Control Unit. Advanced Difficulty: Mixing those widgets in custom panels. (New in Alpha 2) Expert Difficulty: Create custom widgets from your own data or existing elements data. (New in Alpha 2) Expert Difficulty: Create your own HTML code to display custom content on your screen. (Modified in Alpha 2)  
 
Default behavior
 
Cockpit view

 
Hovercraft Seat

 
Programing Board

 
Hovercraft Seat and Programming Board widgets do stack:

 
 
Adding/removing element widgets in Lua
 
API:
slot.show() slot.hide()  
Default Cockpit LUA Script

 
 
We can instead only show the Core Unit widget, and hide the Control Unit widget (shown by default):
core.show() unit.hide()
 

 
 
NEW - Reorganizing Element widgets within panels in Lua
 
API:
system.createWidgetPanel(title) → panelId system.destroyWidgetPanel(panelId) system.createWidget(panelId, type) → widgetId system.destroyWidget(widgetId) system.addDataToWidget(dataId, widgetId) system.removeDataFromWidget(dataId, widgetId) slot.getDataId() → dataId slot.getWidgetType() → type  
Instead of having all the fuel container widgets in different panels, I can create my own panel and add all fuel widgets to this panel:
fuelPanel = system.createWidgetPanel("Fuel Tanks") for i=1,container_size do widget = system.createWidget(fuelPanel, container[i].getWidgetType()) system.addDataToWidget(container[i].getDataId(), widget) end
 

 
 
NEW - Creating custom widgets in Lua
 
API:
system.createData(json) → dataId system.destroyData(dataId) system.updateData(dataId, json) slot.getData() → json  
You can finally write your own custom data, and display them using predefined custom widget types. 4 exist for now: text, title, value, and gauge.
 panel = system.createWidgetPanel("Panel")     -- Display “Hello World” widgetText = system.createWidget(panel, "text") dataText = system.createData('{"text": "Hello World"}') system.addDataToWidget(dataText, widgetText) -- Display a title “Title” widgetTitle = system.createWidget(panel, "title") dataTitle = system.createData('{"text": "Title"}') system.addDataToWidget(dataTitle, widgetTitle) -- Display a gauge filled at 60% widgetGauge = system.createWidget(panel, "gauge") dataGauge = system.createData('{"percentage": 60}') system.addDataToWidget(dataGauge, widgetGauge) -- Display “Weight  80 kg” widgetValue = system.createWidget(panel, "value") dataValue = system.createData('{"label": "Weight", "value": "80", "unit": "kg"}') system.addDataToWidget(dataValue, widgetValue)
 

 
You can now combine all those methods to create your own customized panels.
 
 
CHANGED- Customize screen using html code.
 
API:
system.setScreen(htmlContent) system.showScreen(1/0) You can write your own html code to change the appearance of the control unit screen. It will be displayed below the widgets, so if you want full control: you can hide all widgets.
 
html = '<div class="monitor_left window">' html = html .. '<div class="center window">monitor_left</div>' html = html .. '</div>' html = html .. '<div class="monitor_right" style="background-color: red;">' html = html .. '<div class="center window">monitor_right</div>' html = html .. '</div>' system.setScreen(html) system.showScreen(1)
 

 
Predefined style classes
 

 
class=”monitor_left”         defines the area of the left monitor.
class=”monitor_right”        defines the area of the right monitor.
 

 
class=”grid”         stacks all its child elements on an invisible wrapping vertical grid.
class=”center”        positions an element centered to its parent. Can be the viewport.
 

 
class=”window”        applies the Dual Universe background and border.
 
Well, that's it for this time! We hope you'll enjoy the info here to surprise us
 
Cheers,
Nomad

It sounds like you want to abuse the playerbase A LOT in every point I see you make. So how about you get to be the abused in this game, because everyone plays the same game after all (you could end up being outsmarted by someone smarter than you or has way more experience in this game than you). And if you ever played Space Engineers survival online you would know that backstabbing was the biggest bitch you ever had to deal with in gaming. It has to be fun/fair for people on both sides of the community you know what im saying? Take another look at what you just posted, it's complete bullshit and in no way relevant with making a good game, it's only about yourself and what motivates you to play games and code. lol

Disclaimer: All ideas are based on the publicly available info, not under NDA.

Hello, so one of my biggest concerns with the voxel building tools so far, is the lack of support for curved shapes. I really think it would be sad to see an amazing game like this, filled with only Minecraft Box spaceships. Because curved shapes are so impossible to make. So here are a few basic additions I think could really improve on the current voxel building system. I know, more advanced voxel editing are planned like being able to edit control points, and a Voxel Element Library for more complex shapes. But, there are other, more simple things I think that can be done to get curved shapes into the game sooner rather then later. So, the basic idea is to make curved voxel shapes easily available so players would be encouraged to build none box shaped ships and constructs. I did some artwork to help illustrate my ideas. Please feel free to discuss and give feedback on this thread in the comments. Ok, So lets dive right into it.
 
 
These pictures are examples of designs that can be made with these shapes.

 

 

 

 

 

 

 
 
Starting Primitives
So, there are several shapes to begin with when using the voxel deploy tool. Here are some important primitives I suggest should be added as voxel brush shapes. Those shapes are Oblate Sphere, Prolate Sphere, Cone, Torus, Elbow Joint.

Why these shapes?
The reason I chose these shapes is because they are nearly impossible to make with with the current tools. An even with advanced editing options, they would still be difficult to get right. So it seems like a no-brainer to have these shapes as starting primitives for the voxel brush. It would make it much easier to start creating curved shaped constructs, and encourage more creative designs.
 
This picture is of the voxel shapes I think should be added to the voxel brush tool.

 
 
Voxel Shape Options
So the next thing is an a expansion on the voxel shapes, by adding parameters before/after the shapes is deployed. For example, having an option like size, and diameter of the TORUS shape before/after you deploy it, or option to set how extreme the elongation is on the SPHERE or CONE before/after you deploy it, and even maybe set the angle of the Elbow joint. So, the way I imagine it would work is, when you select a starting primitive shape, shortcuts like arrow keys, numbers keys are used to set the value of the shape options, then you can deploy it as normal. Also, having an option box that would stay on screen as long as you're using that shape could work too, so that you can continue to change options and deploy new shapes.

This pictures give an example of what changing the options would look like on each shape.
          
 
 
Bevel, Fillet, sharpen edge tool
So, we currently have a tool that allows builder to smooth edges, but to expand on that idea, I think we should also have the option to Bevel, Fillet, or sharpen edges as needs. The issue is that most times the smooth tool does not give the desired result, or maybe you only want to bevel an edge but not smooth it, or maybe you want some edges with a fillet and some edges sharpen. I imagine it working exactly like the current smooth edge tool, except you would be able to Bevel an edge, Fillet an edge, or Sharpen an edge.
 
 
This pictures below illustrates how the tool would effect the edge. This is the current smooth tool.
           
 
 
Additional Ideas
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
Scale Axes
I think this is a simple, but vary important option that needs to be available. Basically we have the option to scale the size of voxel primitives, but we should also have the option to scale voxel primitives on a specific axis (X, Y, Z). This I think would definitely add greater control to create the desired shapes, as well as enhance the freedom of creativity.
 
Hollow Primitives
So, this thought came to me last minute, but I think its something that shouldn't be overlooked. The ability to start with hollow voxel primitives. Either a voxel brush option to deploy hollow voxels, or solid, and set the wall thickness, or have hollow voxel shapes as a standard starting shape to choose from. I know that there is an option to cut out voxels using primitives shapes, but the main issue is that cutting out voxels gives a very ugly looking result, most times the edges don't look right at all, or you need a hard edge but the cut out has a rounded edge with a messy texture. Also, hollow primitive shapes would improve the speed, and ease of use when building constructs. Especially when working with curved shapes. Trying to hollow out a curved shape would be a nightmare, so starting with a hollow shape would be great.
 
Voxel Elements
So my last suggestion is in regard to Voxel Elements. Novaquark mention in this DevBlog that will have a Library of detail, or complex voxel shapes that players could use in their constructs. They mentioned a spiral staircase as an example. Well, here are a few shapes that I think should be included in that database of Voxel Elements.

Pictures of suggested Voxel Elements to add to the Voxel Library.

 

I know that a voxel point cloud editing system is in development, list on trello Here. That will really open up lots of possibilities for builders. But, in addition to that, having a variety of voxel brush shapes to start with is still needed to give builders alternative options, because sometimes doing things one way just may not work out how you need it to, so having other ways to create shapes is a big help.
 
I think that covers the general ideas I had. My overall goal is to see more spaceships and constructs that aren't just limited to boxed shapes, and enable creative builders to really unleash their imagination. An I feel adding additional shapes to the Voxel Brush tool would be a good way to accomplish that goal. Please feel free to give feedback in the comments.

Thanks for reading, see you in the next thread.
 
 

(this DevBlog has been posted on the website on April 30th, 2019)

Hey guys!
NQ-Entropy here today with NQ-Wave. 
 
We’ve been working on a significant overhaul of the game’s balancing and we’re going to do our best to explain the big changes we’ve been working on. The main subjects today are the major rebalance of inventory and container capacity, material transportation, crafting recipes, and almost every single step between mining and crafting. Saddle up.
 
Our starting point was the dialogue we had with the community about the issues with containers. We heard everything you guys said, from smaller containers not being useful and crafting times on larger containers being too long. This wasn’t lost on us; we also agreed that it was a little ridiculous at how weak certain containers were as opposed to the Nanoformer inventory, which held a staggering 64m3, the equivalent of a large container, or 64 extra-small containers. There was an issue.
 
What happened in the following weeks was us going down a massive rabbit-hole where we started pulling different strings and unearthing a lot of inconsistencies in our global balancing on almost every level. We decided that we wanted to start over on solid and healthy ground, and make sure that we knew what we were doing, how, and why. We are now at the finish line of the first major pass, and we’re ready to talk to you about it.
 
One of the initial issues excavated from the wreckage of our investigation was the difficulty of transporting materials while in atmosphere. As it turns out, in a realistic physically based system, it's really hard to transport hundreds of cubic meters or potentially tens of thousands of tons in materials. Who saw that one coming? It was a learning experience to see some of you try and transport raw material, only to end up with about 20 large hover engines to lift a couple of containers, which amounted to no material at all.
 
So this is where we began. No matter what happened next, we needed to drastically reduce the amount of weight that a player would have to reasonably move around; even in the context of large transports. As previously mentioned, the main culprit was our overly common use of cubic meters, which artificially drew upwards the volume and weight of everything we did. We globally changed our main volumic unit from m3 to liters. We now had finer control over volumes and had a more human-level metric to base our foundations on. Your inventories will now have a capacity of 4,000 liters; goodbye cubic meter, it was nice knowing you.
 
Having said that, we mostly liked the ratios we had in place for how fast players filled their inventories when mining and made sure to adjust everything so that it remained similar to how mining was done previously.
 
Continuing up the chain, we reached crafting recipes. We were also generally happy with the feedback we received for the crafting mechanic, but our first recipes were more for functional testing than any sort of real balance. Now was the perfect opportunity to take a look at it in more detail.
We want you guys to discover this without too much of a heads up, but there's a couple of cliff-notes we can mention here:
Global rebalance of item volume and weight across the board. Conservation of mass during crafting across materials, parts, and elements during crafting (some exceptions apply). Rebalancing of all ancillary materials recipes (honeycomb, fuel, products and scraps).
  The end result of this is fairly significant, and we’re not quite sure we fully grasp all of the implications at this point. What we are confident in is that we have all of the tools in hand to effectively make adjustments and deal with any issues that arise; something that we couldn't quite say to the same degree before. 
 
In terms of clearer changes:
 
Parts are generally more coherent in weight and volume with less outliers. Smaller parts will generally take up more space in your base inventory while larger ones will take less. You can still expect large parts to take up significant space, but not multiple base inventories worth.
  Elements operate in the same ballpark of weight and volume as before, but we have less outliers. Smaller elements are not so small and larger elements are not so huge. 
  Generally speaking, honeycomb materials will require more ore to make. The amount of honeycomb material you could acquire previously was a little too high and we wanted to rein that in a little. We don't want you to feel constantly limited by honeycomb material, but we also don't want to make acquiring large quantities of honeycombed materials trivial. It's worth noting that we fixed a bug which changed honeycomb mass; honeycombed material will likely be overall heavier than before.
  Fuel cost and weight have been drastically augmented, but as counterbalance, we reduced both fuel consumption for engines and fuel tank capacity. Hopefully, this ensures that fuel is more difficult to acquire and weighs more, but you will need a lot less of it for similar performance. The end result is that you’ll be able to fly for longer while retaining a similar overall cost per distance traveled as before.
  In regards to scraps, the first thing we did was add scraps for all ore. You can now craft equivalent level scrap from level one to four using any ore that you’d like. Secondly, we had previously done a quick fix adjustment on scrap repair, making it less painful to repair your elements. The new scrap recipes will allow you to make more scrap for less raw ore than previously, hopefully addressing said pain points of having to mine for ages just to repair a single element. It should now be more efficient to repair an element with scrap than to craft that element from scratch.
  Finally, containers. Containers haven't changed at all. Not one bit. An extra large container is still 128m3 of volume. But in a world of liters, 128 cubic meters comes out to just about 128,000 liters of capacity. That’s roughly 32 times the size of your basic inventory, and frankly, that's a hell of a lot of storage.
  Additionally, there’s been a significant revamp of the information displayed in the inventories information panel. We won't go into too much detail here as we hope the new information should be easily understood and explain itself well enough.
 
This was a huge undertaking and we’re confident that we’re going in the right direction, but we expect there to be issues. We’re looking forward to you guys testing everything out, hearing your feedback, and hopefully providing answers.
 
NQ-Entropy and NQ-Wave

Hi guys, 
 
The idea of making a podcast has been circling in our heads for some time. We wanted to reach out to our community in a new and captivating way, and today you can discover the end result.
 
We're very excited to bring you some behind the scenes material and invite you to join us while we discuss what's new in DU. If the community's response is positive, we may make a series out of it.
 
You can listen to this first episode below on YouTube:
 
 
It's also available on SoundCloud:
 

 
Happy listening! We'd love to hear your feedback!
 
Cheers,
Nomad

Hi guys, 
 
On March, 6th, we organized a special stress-test with thousands of simulated players. Our objective was to showcase our unique server technology and test it under live conditions! Dozens of human Alpha players were invited and participated as well, as witnesses of the event. You can discover the details on the news here. 
 
Don't hesitate to comment below!
 
Cheers,
The Novaquark Team

Dear community,
 
We’re expanding! Novaquark opens a new studio in Montreal to accelerate the development of Dual Universe!
With the hiring of Stéphane D’Astous as General Manager and 50 positions open, if you think you have the skills required (and/or know people who have them), don't hesitate to apply to join the first true Metaverse!
 

 
You can find the complete news here.
You can find the job opportunities on this page of the official website.
 
Best Regards,
The Novaquark Team.