Oxyorum

To be honest, until the game goes live, it doesn't matter. I can't wait for the organizational implementation in game. 

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

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 May 2nd, 2019)
 
Hey guys!
This is NQ-Entropy coming at you today with a new DevBlog about what we’re calling Barter, or to be more precise—direct-player trading.
 
Now Markets aren't going anywhere, and we expect the majority of transactions to be done there. But often in the depths of the wilderness, you may not have direct access to a Market and might need the helping hand of a stranger to obtain an extra part or element.
 
That being said, let's talk about our new Barter system. The Barter system is going to allow players to directly trade items and Quanta between one another in the game world. You’ll be able to do this by approaching another player, opening the drop-down menu by right-clicking on the player, and selecting “Barter”.
 
The player receiving an attempt to barter will be notified with a prompt asking him to confirm or deny it, which he can do by using the “y” or “n” keys. Should that player be AFK or totally ignore you, the request will automatically timeout after 30 seconds. If a player is in a position or location where a Barter isn’t possible, the issuer will be notified.


 

 
If a player initiates a Barter and another accepts, a brand new interface will pop up; welcome to your Barter screen.
 
The Barter interface is split into four key areas. Starting from the top left, you will see your Bartering partner’s name and basket, with all items or Quanta they may put up for trade. In the top right is your domain, where you can see your personal basket and what items or Quanta you’ve decided to offer. Keep in mind that these screens are updated in real-time, and both parties will see baskets revise as you add or remove items or modify Quanta.
 
 

 

 
In the bottom right, you’ll find your inventory which will work exactly as you would expect. You’ll be able to use all of your standard inventory filters and search functionality to find the items you want to Barter. 
 
In order to move items from your inventory to your basket and vice versa, there are several methods:
Drag and Drop: You can click, hold, and drag items. Double Click: Double-clicking on any item will move it to the other location. Contextual Menu: You can right-click on any item and select to move it manually from the drop-down menu.  
The Shift key will still work the same way it always has when moving items that are stacked, allowing you to split stacks of items appropriately.
 
You will notice two buttons next to your respective baskets. This is how you and your partner will confirm that you are satisfied with the current Barter and are ready to proceed with the exchange—however, there are a couple of important things to note.
 
At a basic level, both partners have individual confirmation buttons to designate that they are ready to proceed with the trade. Once both parties agree and have confirmed, the exchange will go through instantly. 
 
At any point during this confirmation, should either player change anything in their basket  (remove an item, add an item, change quanta, etc.) all activated confirmations will be deselected. For example, if I am Bartering an engine for 100 Quanta and I confirm this exchange, my partner may decide to change 100 Quanta to 50, which will automatically deselect my initial offer.
 
The exchange will proceed only when both parties have confirmed the exchange. Speaking in game terms, if I am Bartering an engine for 100 Quanta and confirm this exchange, and neither basket is modified, once my partner activates their confirmation, the trade will instantly complete. 
 
Lastly in the bottom left, you will see your chat. You can use it normally to access your other chat channels, but initiating a Barter will automatically prompt an additional chat window between both players to discuss trading terms. Once the Barter is complete or if the Barter is canceled, this window will automatically close. 
 
In the event that you are unable to receive items due to volume considerations, your confirmation button will turn red to indicate this. If your button turns red on a confirmation attempt, that means that you do not have adequate inventory space to accept new items.
 
Barter will work with the linked container in a limited fashion. When entering a Barter, you will only be able to trade using one inventory source at a time; either your main character inventory or your linked container. This will be defined by your linked container option in the inventory. Should the inventory you are Bartering from becoming too full, you will have the option to transfer items from your current inventory to a secondary one. 
 
At this time, you will not be able to trade dynamic objects such as Territory Scanner results and Blueprints, but this is something we’re striving to accomplish in the future. 
 
Thanks for your support, guys!
As always, feel free to drop any feedback you have to share with us in this forum thread
 
NQ-Entropy
 

I guess they want us to actually put thought into how much fuel we are going to need for things, rather than just running around with full tanks at every occasion.
We will probably have to calculate how much fuel we can bring with us based on how much mass we are moving on our ships. Also, keep into account that they are increasing fuel efficiency, so as to ensure that fuel consumption per distance traveled stays the same after the changes.
 
Only thing I want clarification on is this:
 

(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

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.
 

Welcome to Dual Universe!
happy to have you with us

Hello, MisterDoge.
Welcome to Dual Universe.

Welcome to Dual Universe!
glad you could join us, we are accepting of even the most virtual of beings

Core units already have standard sizes, as is shown by some of the earlier videos. There is no need to "standardize" them.
As for standards in general, I am positive that there will be use of them when the game is released. Standardized landing dock sizes, standard road sizes and standard rules for flight in cities are some of the possibilities. Standards can be helpful for travel between cities/jurisdictions as well as trade between players.
 
 
I do not believe that the game's architecture would allow for merging of constructs (grids) together in the way you are describing.
I am pretty sure that we will be able to delegate work to other organizations, but not for modules.
In practice, an organization will be able to use RDMS in order to allow other organizations to work on their buildings/ships, bringing their expertise and compensating them for their work.

I agree with @ShioriStein. RDMS can be used to sort this out. You can assign special roles/rags for each residence, and only the tenant of said residence would be able to affect the residence itself. This way, you would only need one static core for the entire building while still providing access to the people who pay to live there (and JC already confirmed that there will be the ability to charge people monthly or weekly with RDMS).

This is an excellent idea. I would think, however, that if RDMS is going to be as extensive as we are being lead to believe, we could probably have the organization for the building, and have those who manage the building as the only actual members (all legates probably). Then, they can give roles to tenants and whoever else they want. This is all assuming that orgs can give temporary roles to people that are not members of the organization.

A skeleton to attach cores is not very practical. In my opinion, its redundant because any one of those cores could manage the whole building most likely.
 
Why not have one core for the entire building, along with the rooms made with voxels and RDMS control for each room? I don't think that cores will have a limit to the amount of voxels/elements attached to them.

My understanding is that all of the kickstarter backer specific rewards (lifetime sub, etc.) will not be returning. The only packages that you can buy at this time are the supporter packages available on the website now. If you really want to support the game, you can buy all of the supporter packs instead of one. Hoping someone for Novaquark can give you a more official answer.

My understanding is that all of the kickstarter backer specific rewards (lifetime sub, etc.) will not be returning. The only packages that you can buy at this time are the supporter packages available on the website now. If you really want to support the game, you can buy all of the supporter packs instead of one. Hoping someone for Novaquark can give you a more official answer.

Hi everyone!
 
Here is the dedicated thread to discuss about the June DevBlog that has been posted today on our website here.
Let us know what you think of the upcoming changes!
 
Best Regards,
Nyzaltar.