Davian_Thadd

Hello Noveans,

The upcoming 0.24 Update includes a plethora of enhancements to elevate the look and playability of Dual Universe. Today, we’re going to take a closer look at two of these: biomes improvements and new voxel features.
 
BIOMES IMPROVEMENTS

In this first phase of a significant, ongoing graphics update, we are improving the biomes of our planets to make them more visually diversified. Combining Speedtree, a procedural generation software, with the Quixel Megascans assets library for the textures and meshes, we now have many new tree models!
 
The Quixel Megascans library also provided many new rock models, which our artist team has then reworked.
 
Moreover, to achieve maximum realism, our ground textures now utilize scans of authentic terrestrial soils. In addition, we have improved the rendering to increase the textures’ visual quality and performances even further.
 

 

Rendered models from our Engine Editor.


These new rock assets will replace all the previous ones and add variety to the environments.
 

 

We have a new night lighting! To offer a better visual by nighttime, the tree models have been calibrated in order to fit the new night lighting.
 

 

All tree and rock assets are placed in the game world using procedural generation spawning.
 

These scans ground textures are the materials from Quixel Megascans used to replace previous ground textures.
 
NEW VOXEL FEATURES

One of the most compelling aspects of Dual Universe is its fully editable world. Through the art of manipulating voxel structures known as voxelmancy, the possibilities for channeling your creativity are endless. Our goal is to provide the players with as many tools as possible to edit voxel shapes, and we want these tools to be user-friendly and efficient.
 
 
The suite of voxel tool shapes is now even sweeter with the addition of the cone shape. Using it is similar to making cylinders. Use the mousewheel to increase the size of the base, and drag up or down to increase or decrease the height.
 
 
The new line tool allows you to select an area using any of the available voxel shapes and then hit the Alt key to delete them. Hopefully, you will now find it less tedious to remove voxels than with the previous system!
 
SHARE YOUR THOUGHTS

Are you looking forward to being surrounded by the luscious new sights and textures of the graphics update? How will the new voxel tools compliment your constructs? Let us know in this discussion thread. ?
 
 

Dear Noveans,
 
With the opening of the Public Test Server (PTS) available to all DU players come a few guidelines, if you want to give some feedback.
We wanted - for a long time - to give the opportunity to anyone among you to give your opinion on features before they hit the Live Server.
However, as the time window to give feedback on new features deployed on the PTS will be usually limited, it's important to get structured feedback to be taken into account by the Devs, in order to make possible changes before deploying the said features on the Live Server. Note: having a new or modified feature deployed on the PTS doesn't necessarily mean that the same will be deployed on the Live Server. Community feedback may change the Dev Team course of action.
 
In order to facilitate the follow-up of your feedback by the Dev Team, it's really important to talk about one topic/feature per forum thread.
Additionally it's highly advised to follow the template below when giving feedback on a specific topic/feature deployed on the PTS:
 
Naming clearly the feature / game mechanics involved. Your feedback on the deployed feature (what you like / what you don't like about it (in this case, please give an explanation why you don't like it)). What kind of improvement you would see for such feature.  
If your feedback is about a bug report, please follow this template:
 
Subject: [BUG] <Issue name here> Current Version Number: <Can be seen when closing the client> Impact: <Game breaking / Crash / Corruption / Item/Data loss / Inconvenience / Cosmetic> Summary: <Short outline of the issue> Description: <Description of the issue> Reproduction: <Steps taken to make this bug happen>  
Reminder: there will be no official support for the PTS.
This means you can report bugs you found/experienced on the PTS (preferably in this forum section).
It's encouraged to report bugs found on the PTS, to make sure they won't be replicated once the involved feature will be deployed on the Live Server.
However, do not send tickets to the Customer Support to fix issues you encountered on the PTS.
Why no support? The reason is quite simple: in their experimental state, things may be broken.
The Novaquark Team prefer to allocate 100% of the Customer Support resources to the Live Server, where the "real game" happens.
 
We hope you'll understand our stance on the matter.
 
Best Regards,
The Novaquark Team.
 

Hey Noveans,

Joining an organization in Dual Universe has many advantages, especially when it comes to pooling and sharing resources. The introduction of org wallets in the upcoming 0.24 update will add a convenient way to transfer money to and from organizations, just as players have been requesting.
 
But wallets aren’t limited to organizations alone. Many of these features will be useful to individual players as well. This should be welcome news to everyone who will be raking in the quanta via the new Mission system.
 
Let’s take a closer look at all the wonderful things wallets can do.
 
WALLETS 101

Each organization now has a wallet.
 
There are two new rights related to organization wallet management in the Right and Duty Management System (RDMS):
 
Consult wallet: Gives the right to members to simply know the current balance of the organization. Edit wallet: Gives the right to do all the wallet operations available to the organization wallet. It includes buying, selling (and paying taxes by doing so), browsing the log and transferring money (see below).

            Giving the right to edit the wallet of Wave Corp to another player.
 
HOW IT WORKS

Any player with the “edit from wallet” right of an organization can:
Sell unclaimed items or items claimed by the organization in the name of the org. Once sold, the money goes to the organization wallets. Buy items in the name of the organization. When doing so, the wallet of the org is used instead of the wallet of the player. Also, the item is then automatically claimed by the org when purchased. Edit and/or delete orders owned by the organization. NOTE: Going to the “My Orders” panel of the market UI, allows the player to see their own orders as well as the orders of all organizations for which they have the appropriate rights.
  Payable dispensers owned by organizations will use the organization wallet, instead of the Superlegate wallet.

TRANSFERING QUANTA

All players can give any amount of quanta to any other player or organization. Players with the necessary wallet rights of an organization can also transfer money from the organization wallet to any other entity. Transfers are tracked in the wallet logs of both the sender and the recipient.
 
There are a few rules regarding quanta transfer, mainly intended to protect players from griefing through spamming the recipient’s wallet log :
A transfer requires a minimum amount of 1,000 quanta. There is a cooldown period of 10 minutes between two transactions with both the same sender and the same recipient.

            Transfering money to the organization Wave Corp.
 
THE WALLET LOG

Managing an organization and giving the right for wallet operations to several players requires basic management functions. That is why we are adding the wallet log.
All entities (players and organizations) have access to a wallet log that reflects all transactions related to their wallets.
 
Each entry contains the date of the operation, the type of operation (such as money transfer, market transaction, various fees, etc.), and additional information, such as the name of the player who completed the operation, for instance.

            
            The wallet log.
 
SHARE YOUR THOUGHTS!

What do you think of the plans so far? Is this a good starting point or are there additional functions you think wallets will need? We look forward to reading your feedback in this forum thread. ?
 

Like it ! We need know a DRM system for Lua libraries. 
We need to be able to install a lib on library slots of controlers, which could be protected by a DRM.

Allowing us to sell or give technologies protected, and useable to create custom sytems / APIs ...etc based on created technologies.

For example, to install games on existing construct, or install a navigation system on existing construct, or install technologies with API made by the reator to interact with it ...etc


I'm really waiting for  it ! But it's a good first step ! 

The customisation of various HUDs in ships or industry monitoring tools could be a collection of scripts from multiple authors so that player would want to install several scripts what they can currently do but not anymore with the current RDM system.
For Lua it would be interesting to allow player to buy Lua BluePrints that can be added to controllers like schematics to industry units.
 

Hello Noveans,
 
With release 0.23, we have introduced a long-due system to protect and manage the intellectual property rights of construct creators. This is not just a variant of the existing . Rights and Duties Management System (RDMS), which is mainly in the hands of the owner of a construct. Instead, the Digital Rights Management (DRM) system is in the hands of the creator of a construct, who might be another entity than the current owner. Let’s have a look at how it works.
 
Creators and DRM flags

When a construct is created from scratch, that is, when someone deploys a core unit, whoever deploys this core unit becomes the construct creator. This can be an organization, if the deployment is done in the name of the organization. This notion is crucial because when interacting with a construct being the creator will give you certain privileges. 
 
Note that if the creator is an organization, any legate of this organization will be considered as the creator. It’s a great way to share “creatorship” between several players and be more resilient about people not being in the game for whatever reason.
 
There are four things you might want to protect as a creator when somebody else is going to buy/use one of your constructs (with the caveat that we may add more things in the future if needed):
 
The creation of blueprints The copying of voxel structures out of the construct The edition of Lua code in Control Units The edition of HTML content in Screen Units  
However, we wanted the creator to be able to select which protection to activate or not, to give them more control, and also to allow to make a distinction between Control Units/Screen Units that might have been added after the purchase of the original construct (and which should, obviously, not be subject to any protection). So, we needed flags on elements to be able to say yes/no regarding each of the above protection abilities. That’s the purpose of  the DRM (which is a commonly used acronym for copyright protection of digital assets in the real world).
 
The DRM flag for blueprint and voxel copy protection is held by the Core Unit. Otherwise, each Control Unit and Screen Unit has its own flag.
From there, the rule for accessibility of any of the above four actions is defined by: 1. Is the player performing the action the creator? If yes, authorization is granted, if no: 2. Is the DRM flag of the corresponding element activated? If yes, authorization is NOT granted, otherwise it is.
 
Note: Historical constructs, created before the introduction of the notion of creator signature in construct (roughly around April 2020), do not have a creator. In this case, we chose to disable DRM entirely. Since there is no easy way to guess who was the creator (we can’t easily trace back the history of a construct, originating from several blueprints, etc.), we will leave it at that.

Blueprint creation and DRM management
 
How do you set the DRM flags? It is done automatically for you when you create a blueprint of the construct. By default, all DRM flags are set to “activated” on the Core Unit, all Screen Units, and all Control Units;  however, you have  a relatively hidden (because relatively dangerous) right-click menu option in “Construct/Advanced/Create Core Blueprint without right protection” that allows you to create a Core Blueprint that has no DRM flag activated, which means no protection at all. We will see below in the “use cases” section that this is not quite as useless as it sounds.
 

 
It is important to understand that the flag configuration is held by the Core Blueprint. Any construct that will be spawned from blueprints originating from the Core Blueprint will inherit the flag configuration: either all activated or all deactivated.
 
Once a construct has been created with such a blueprint (or even on the original construct if need be), the creator can still individually unflag any of the flagged elements (with the right-click menu “Advanced/Release DRM Protection”). Unflagging the Core Unit will release the DRM protection for blueprinting and voxel copying. It does not mean that anyone can now blueprint the construct, since now the owner (who is not necessarily the creator here) can use the usual RDMS restrictions on blueprint creation to define who can use this ability. In the same way, a DRM-free Control Unit is still subject to the RDMS as for who is allowed to edit the Lua inside it. But again, this is now a consideration for the owner, who is managing the RDMS, rather than the creator.
 

 
Once unflagged, a Core/Control/Screen Unit cannot be re-flagged by the creator. So, be careful when using this, it cannot be reversed.
 
Now, if the owner of a DRM protected construct decides to customize the construct and add some Control Units or Screen Units, these elements will be deployed without the DRM flag activated. In effect, it means that the owner will be free to edit them, as expected. There will be two types of Control/Screen Units in this construct then: those coming from the original DRM-protected blueprint, with their flag activated and therefore not editable, and those coming from the owner’s personal additions with no flag activated and full edition rights.

Use cases

Let’s be practical here and see some patterns of usage that we believe will be quite frequent.
 
1) The ship designer: This player/org typically intends for their constructs to be sold and fully protected. A Core Blueprint will be created with full DRM activation, and constructs made from the Blueprint originating from this Core Blueprint will be ready for sale and fully DRM-protected.


 
2) The org internal ships: Those ships are meant to be used by org members and should be created in the name of the org. A special blueprint without DRM would be issued to create ships for the org’s internal use. RDMS would play its role in managing internal org rights as usual.


 
3) Voxel library designer: By definition, selling or simply sharing a voxel library construct would imply the creation of a blueprint without DRM, otherwise the voxel copying will not be possible.

4) Special customer deal for a ship designer: It could be that the designer of a ship accepts to unlock some aspect of the DRM for a given customer. In this case, the creator will have to access the sold construct and operate on it to deactivate the flags wherever needed.

Still to Come
 
We are still missing some important features to fully cover the DRM mechanism. In particular:
 
We need to improve the way to find out who is the creator of a construct and provide an easy way to contact them. (You can currently find this info in the “Construct Information” tab of the Build Helper, but it should be easier to find.) We need a way for a creator to be able to transfer their “creatorship” to another player/org. We may need a way to separate DRM protection for blueprint and for voxel copy. We may need a way to allow the creator to activate the DRM flag, not only to deactivate it. (This means the construct should remember what was an original Control/Screen Units in the list of elements of the construct.)  
This will come in future updates. Until then, we hope you will enjoy this new addition to the game mechanics related to constructs and that, in particular, ship sellers will now be able to mass-produce and sell their creations without fear!

Want to discuss this? Visit the thread linked below! ?
 
 

I agree that this will clearly not please everyone ^^ '

However, it is important to remember that this is not a game in creative mode, solo / co-op with a lifespan of 50 hours.
Currently, far too many things are simple, and the complexity is .... no it's not the right word .... accessibility, that's better ^^ '
The accessibility is too high, everyone can do everything so easily, no need for other players directly or in direct, little cooperative effort ... etc
In short, people find it hard to see the game as an MMO whose goal is to build a new civilization at the moment, and an infinite one to take, manage, create its role in this world.
 
Anyway, why am I saying that ??! Well because without wanting to criticize, even if I know that a lot of people will fall on me ... well the players want everything to be simple, accessible ... etc to play quietly in their corner and do everything so easily . And that goes through the elements, the industry, the management of the damages ... etc
 
 
 
Anyway, after this intro, basically, I'm clearly positive about adding a final destruction! It is clearly a necessity! (and contrary to what we hear, many games have definitive destruction, because it is a need to have an economy that runs, even on management games ... etc. everything is CONSUMED it comes back to the same) .
 
BUT ! I am not necessarily in favor of this system of life, even if I REMIND IT, IT IS A FIRST ITERATION, THEREFORE TEMPORARY and INTENDED to change.
 
This is why I am much more in favor:
 1 single life for all the elements (a destroyed element should not logically reshape by wonder)  much more HP for the elements  a degree of performance directly linked to the HP of the element ( fuel consumption, t50, thrust, tracking speed ...etc) What's the idea, before I get spit on me ^^ ', the idea is to make the complete destruction less frequent, but still impactful. Some examples to explain:
 In PVP, we could have a lot less elements destroyed but a lot of damaged. This will keep value to recover in combat, while allowing to weaken a target.  For ship crashes, well some elements yes would be completely destroyed, and IT MAKES LOGIC if you spit yourself out, but a good part would be damaged, even sometimes close to destruction.  This will avoid having second-hand pieces lying around for nothing because they have X lives on Y ... etc  
Obviously, the idea will greatly benefit from a recycling system to create the scraps, from destroyed elements, since the DESTROYED elements SHOULD NOT DISAPPEAR BY MAGIC ^^ '
 
 
 
There you go, now you can spit on me because I have circumscribed the players who want everything simple and easy and without fuss ^^ '

I agree that this will clearly not please everyone ^^ '

However, it is important to remember that this is not a game in creative mode, solo / co-op with a lifespan of 50 hours.
Currently, far too many things are simple, and the complexity is .... no it's not the right word .... accessibility, that's better ^^ '
The accessibility is too high, everyone can do everything so easily, no need for other players directly or in direct, little cooperative effort ... etc
In short, people find it hard to see the game as an MMO whose goal is to build a new civilization at the moment, and an infinite one to take, manage, create its role in this world.
 
Anyway, why am I saying that ??! Well because without wanting to criticize, even if I know that a lot of people will fall on me ... well the players want everything to be simple, accessible ... etc to play quietly in their corner and do everything so easily . And that goes through the elements, the industry, the management of the damages ... etc
 
 
 
Anyway, after this intro, basically, I'm clearly positive about adding a final destruction! It is clearly a necessity! (and contrary to what we hear, many games have definitive destruction, because it is a need to have an economy that runs, even on management games ... etc. everything is CONSUMED it comes back to the same) .
 
BUT ! I am not necessarily in favor of this system of life, even if I REMIND IT, IT IS A FIRST ITERATION, THEREFORE TEMPORARY and INTENDED to change.
 
This is why I am much more in favor:
 1 single life for all the elements (a destroyed element should not logically reshape by wonder)  much more HP for the elements  a degree of performance directly linked to the HP of the element ( fuel consumption, t50, thrust, tracking speed ...etc) What's the idea, before I get spit on me ^^ ', the idea is to make the complete destruction less frequent, but still impactful. Some examples to explain:
 In PVP, we could have a lot less elements destroyed but a lot of damaged. This will keep value to recover in combat, while allowing to weaken a target.  For ship crashes, well some elements yes would be completely destroyed, and IT MAKES LOGIC if you spit yourself out, but a good part would be damaged, even sometimes close to destruction.  This will avoid having second-hand pieces lying around for nothing because they have X lives on Y ... etc  
Obviously, the idea will greatly benefit from a recycling system to create the scraps, from destroyed elements, since the DESTROYED elements SHOULD NOT DISAPPEAR BY MAGIC ^^ '
 
 
 
There you go, now you can spit on me because I have circumscribed the players who want everything simple and easy and without fuss ^^ '

Good day, Noveans!
 
Much of the allure of Dual Universe is the ability to be the captain of your own destiny as you pilot the ship of your dreams. Piloting your ship requires skill and a strategic use of the tools available.
 
The Maneuver Tool is an important part of that toolbox. In its current state, however, it wasn’t working quite the way we planned. As we approach the launch of the 0.23 update, we wanted to talk about changes we’ll be making to the Maneuver Tool as well as changes to issues around what happens when you’re disconnected from the game (intentionally or not) when actively flying your ship.
 
The Maneuver Tool is for maneuvers

The Maneuver Tool was originally introduced to offer a simple way to get your ship out of a small hole or to flip it over when it landed upside down. It also provided a handy way to lift your ship off the ground a bit so you could work on it from below.
 
But as is often the case when designing video games, the cunning imaginations of players found unexpected ways to use the tools that were not intended by the designers, some of which are detrimental to gameplay and could cause issues in the not-so-distant future. Let’s take a closer look at some of the issues caused by the “creative” use of the Maneuver Tool and the upcoming changes we’ll be implementing in the imminent 0.23 update to correct them.
 
Cooperative play is all about collaboration and players helping other players. That’s great, and we don’t want to discourage players from doing that, but how it’s done is important. The Maneuver Tool was not intended as a way to move a ship “by hand” over kilometers or to create a ladder of two ships used as intermediary steps to reach space. These uses went clearly beyond the original intent of the tool.
 
To address this, we’re introducing some limitations in line with the purpose of the tool: 
 
A ship will not be able to move more than 50m in total between accumulated uses of the tool. The distance between the start and end points is added at each run of the tool. The moved distance is reset after three minutes to ensure that players aren’t stuck forever. It is, of course, a per-construct limitation.  Unless the player was in contact with a planet ground or a static/space construct, a ship will no longer freeze in the air during the use of the Maneuver Tool. This will make it possible to lift it up to work under it, but no higher than that.
No more instant stopping of ships upon disconnection

Everyone has “the need for speed”, the desire to get from Point A to Point B in the shortest time possible. So you pull that throttle back, amp up the power and blast off. The danger is that if you don’t carefully monitor your speed, you’ll smash full-force into a planet, your ship will blow up, and you’ll find yourself either returned to your bind point or resurrection node. Ouch!
 
A common workaround for this has been to disconnect from the game just before impact. Upon reconnection, your speed would be reset to zero, and thus you could approach with a safe speed. Although it’s convenient, that’s not how it’s supposed to work.

With the upcoming change, upon reconnecting, as soon as you get in range of the construct, the speed and rotation will be restored to whatever they were when travel was interrupted. The benefits to this change are twofold. First, it will close the aforementioned loophole. Second, it will prevent you from expending twice the amount of fuel to reaccelerate a ship at maximum speed if you had been disconnected for whatever reason.
 
Further, if you disconnect while another player is in range, the server already assigns the task of handling the physical properties of your ship to that nearby player. This means that your ship will continue to move in this situation. On a large ship with many people on board, disconnecting will no longer have the effect of freezing your ship because there will always be other players nearby to continue the simulation of your ship’s movement.
 
We will also add the option to have the Emergency Control Unit (ECU) activated in that case, so that an emergency “braking” can take place if the ship capacity allows it.
 
Keep Doing What You’re Doing
 
We tip our hats to the ingenuity of our Beta testing community. The way you use the tools and mechanics we toss into the sandbox gives us lots of food for thought, showing us the changes we need to make to make the game we all want to play. We encourage you to maneuver your way to the discussion thread to tell us what you think about the adjustments we’re bringing to DU! ❤️ 

Combat changes as expected, good first step.
 
Replacing destroyed element instead of repair is not really new, just back
Allowing buffs to remain when replacing an element seems unbalanced and reduces the impact of the change.
 
The T2-T5 industry idea is something which I expect will not catch on as long as replacing a T1 element boosted with L5 talents is not showing a very significant increase in performance on it's own. I expect this will not be the case and we will see NQ nerf T1 elements/talents to push towards higher tier elements but then again, that will hardly, if at all, affect the players in the safe zones.
 
 
How will container destruction work in relation to hubs?
What if the hub is intact but all containers destroyed?
Frankly, if a destroyed container is replaced in a hub configuration, should that not lead to loss of inventory?
If a hub is intact but containers destroyed, should that not mean all inventory is lost?

Regarding this announcement: 
this particular scenario:
and this future feature:

Will the floating container stay forever?
Will a player "killed" by force-respawn leave a floating container?
 
Depending on this, players will probably build castle moats as trap holes around their bases/tiles. What if everybody does that around the districts?
If beeing traped is an approved scenario for demanding NQ's help, should setting up such traps be forbidden by the rules?
Is it bad to play this card?

 
note: this is also valid for trap constructs with closing doors and detectors for example, should it be considered as griefing?

Dear Noveans, it's time for another DevBlog!
 
Dual Universe is a vast game. Its gameplay has layers, and we keep adding depth to them as often as possible (though not nearly as frequently as we would like to!). As developers, we love to dive into these depths. Moreover, we want to make sure everybody understands why we design features the way we do. DevBlogs are perfect to address these topics, so here we are!
 
Today, we will tackle two major features which shall be released in an upcoming patch: Construct Intellectual Property Protection and Blueprints Duplication. Without further ado, let's jump right into it.

CONSTRUCT INTELLECTUAL PROPERTY PROTECTION
 
The objective of this feature is quite simple: allow a player to protect their creations when they distribute them in game (whether it is by selling them or trading them). We want to make sure that no unauthorized player will access the intellectual property content of a construct they did not create themselves. In particular, we want to protect:
 
The possibility to create a Blueprint of the construct The possibility to copy voxels from the construct to another construct (however, intra construct copies are still allowed) The access to Lua scripts from Control Units The access to HTML content from Screen Units  
This is how it works: each construct has a creator. A creator can be either the player or the Organization who deployed the original Core Unit. We can call this initial construct the “Master Construct”. When an Organization is the creator, any legate will be considered to be the creator.

When making a copy of a Master Construct via a Blueprint, a set of Digital Rights Management (DRM) protection flags are set automatically, both on the construct as a whole AND individually on each of the Control Units and Screen Units in the Blueprint. The newly created construct can have a new owner, different from its creator, but it remembers who was its creator. When trying to access Lua or Html content, the DRM flag of the corresponding Element (i.e. a Control Unit or a Screen Unit) will be checked to determine if the new owner is allowed to do this action. The creator is always allowed to do that. 
 
Similarly, when trying to make a Blueprint or to copy voxels, the DRM flag of the whole construct is checked. By default, since the original Blueprint sets all the flags to “not allowed”, a new owner will have no rights to do these actions.

If you deploy a new Control Unit, or a new Screen Unit on your construct that is DRM protected, they will be deployed without the DRM flag activated; therefore, you will be allowed to modify these Elements in particular. 
 
Moreover, the creator of the construct can also decide to come and remove the DRM protection of the whole construct (by right-clicking on the Core Unit), or of one particular Control Unit/Screen Unit if he wants to (warning: this action is not reversible). Make sure, however, to check if the DRM flag for voxels is global or not. If it is, and you add a beautiful sculpture to the construct, you will not be able to copy-paste it out of the construct. You should rather make your own Master Construct for this kind of action.
 
BLUEPRINT DUPLICATION

The Blueprint duplication will let players create copies of Blueprints, which in turns other players will use to generate a limited quantity of constructs.
To understand this feature better, allow us to make the distinction between Core Blueprints and regular Blueprints.
 
Core Blueprints
When the creator of a construct, or any player owning the right to create a Blueprint from a construct generates a Blueprint from said construct, this is a Core Blueprint.

Its creation is free. It can be used as the simple construct-save it used to be. But more importantly, this is what you’ll use to generate Regular Blueprints.

It is stored in the player inventory and behaves as a regular information item. A Core Blueprint is never lost on death. However, a player can generate a core Blueprint only if he is the creator of a construct or if the DRM flag of the construct has been lifted.

All ancient Blueprints (as in, Blueprints from before the Blueprint Duplication patch) will be converted into Core Blueprints.
 
Regular Blueprints

By right-clicking on a Core blueprint, a player can choose to generate a regular Blueprint, or just “Blueprint” for short. A regular Blueprint, is in reality a one-run Blueprint, and is always the result of a duplication of a Core Blueprint.

It is a standard information item, and because it is a one-run Blueprint, it can only be used once and disappears on use.

Once created, regular Blueprints are delivered at once in the player’s inventory as soon as he validates the duplication. Regular Blueprints are weight-less and volume-less.
 
We hope this DevBlog gives you better visibility and understanding of what’s coming next in Dual Universe. Don’t hesitate to tell us what you would like to see next!
 
See you very soon in Dual Universe

 
Want to discuss this announcement? Click HERE. ?

 

Good afternoon, everybody!!

If you (and/or your Org-mates) are a fan of Lua and you've used it to breathe life into a creation you're dying to show off... now's your chance.  

For a chance to be featured in our Lua Museum (ooooh, ahhhh!), please submit your builds using the handy dandy form we've put together. 

? Click HERE to access the form! ?

Thank you for taking the time to check this out, and happy building!! We can't wait to review your submissions.

~ NQ-Naunet

For those not in-the-know, Lua is a lightweight, high-level, multi-paradigm programming language designed primarily for embedded use in applications. This video contains more information about the ways in which you can use it in DU!

Our website and all linked features will be under maintenance on Monday starting at 9am UTC and lasting until approximately 1pm UTC. During this time access to the website, account tools, forums, etc, will be unavailable for use. 

Come join the community in our Discord channels! 


 

Greetings Noveans,

This is your newest Community Manager, NQ-Naunet, reporting for duty! ?

It’s no secret to all of you that Dual Universe has undergone some changes in recent months; the launch of Beta, an increase in fan-made content appearing across our social channels (bye, bye NDA), and new NQ staff members popping up all over the community... just to name a few! Exciting things are on the horizon for all of us, and we couldn’t be happier about it.
 
The first big mission I propose we tackle together, should you choose to accept it, involves this space right here - the forums. In the interest of keeping things tidier, more useful and fun for everyone, we’ve been thinking about giving this place a bit of a makeover.
 
If that piques your interest, read on to see what we’ve got planned so far. We propose:
 
Cleaning up some older, less relevant pinned posts and limiting future pinned posts to ~5 per topic. Archiving older, pre-Beta material. Creating a dedicated Beta category! Adding an “Innovation Station” space for creators to show off what they’ve been building in-game. Changing the look and feel of the forums with a brand new theme. Implementing an “Organization of the Month” series to highlight some of the amazing things all of you are getting up to together.
What we’d like from you is your feedback, as it’s important to us that this place continues to be made for you, by you. Please let us know:
 
Which topics/threads you feel should be preserved! (Tutorials, lore, etc.) What sorts of categories you might like to see! Any theme/styling suggestions you may have. Anything else you think we should know about the forums/our proposal.
  I’m really looking forward to hearing your thoughts and getting to know all of you a little better. Together, I think we can whip this place into the best shape it’s ever been in! ?

~ NQ Naunet, over and out.
 

As there is nothing new to be covered in the plan, I've skipped ahead to show
the scratch board's content after building layer 3 and layer 4 (a second
arc formed by voxel "plates"). The green quarter circle is layer
2 (plus handles). The red arc is of radius 3.5, and the yellow
arc is of radius 5. The quarter cone is seen in blue, and was
formed by first copy pasting layer 4, then layer 3, and then layer 2.
Finally, in red is the full cone formed by rotating the quarter cone 90
degrees and pasting 3 times.

OUTDATED. NOT UPDATED SINCE v0.23.0
 
This is the result of running the globals dumping script in-game on constructs that had various elements attached to them.
 
Some exposed functions were called with pcall. The first value indicates whether the call was successful, the second is the actual function return value. All functions that return a vector return it as a table, not as a vec3 structure. Usually such functions will be called like this: local worldGravity = vec3(core.getWorldGravity()). Boolean values are returned as a number 0 or 1, and not as true or false.
 
Element events are not listed here, as they cannot be detected by the dump.lua script. See the codex in-game (press F1) or outside the game (C:\ProgramData\Dual Universe\Game\documentation\web_codex.html) for event and function descriptions and other information.
 
Anti-Gravity Generator
r0.21.0
 
Control unit
r0.23.0
Programming board exposes fewer functions compared to cockpit and seat. The control unit has references to linked elements, which are also available as local variables in each event handler. Event handlers defined in the script editor also get placed inside it. Here the control unit is a hovercraft seat that has 2 linked fuel tanks, a radar and a core.

Core
r0.23.0
Static cores have fewer functions compared to dynamic cores.
 
Databank
r0.21.2
 
Elements with a state
r0.21.2
Detection areas, laser detectors and manual buttons expose the same functions. Their state is accessed using getState().
 
Elements with a toggle-able state
 r0.21.2
Force fields, ship doors, landing gears and manual switches expose the same functions. The state is accessed using getState() and can be changed by activate(), deactivate() or toggle().

Emitter
r0.23.0
 
Engine
r0.21.0
Space engines, atmospheric engines, ailerons, air-brakes, retro-engines and adjustors expose the same functions. Usually engines are controlled through unit.setEngineCommand and do not require linking to the control unit.
 
 Fuel container
 r0.23.0
 
Gyro
 r0.21.2
 
Industry
r0.23.0
 
Item container
 r0.23.0
 
Library
r0.21.2
 
Light
r0.23.0
 
PVP radar (atmospheric and space)
r0.22.0

Radar
not available to craft or buy; for atmosphere and space radars see PVP radar instead
 
Receiver
r0.23.0

Screen
r0.21.2
 
System
r0.23.0
 
Telemeter
r0.21.2
 
Warp Drive
r0.23.0
 
Weapon
r0.21.0

You have all our support ! It's comprehensive  And thanks for the topic to explain the situation !

You have all our support ! It's comprehensive  And thanks for the topic to explain the situation !

You have all our support ! It's comprehensive  And thanks for the topic to explain the situation !

These things happen, we are all here because we love what you have made.
Thanks for the heads up, looking forward to seeing the new website!

Dear Noveans,
 
When we set out to launch our beta this summer, we also envisioned a series of major changes and improvements outside of the game. A major one was the complete redesign of the game’s website, as well as the migration to a brand new tech stack for the site’s front and back ends. We were also planning to launch several programs, such as a Content Creator program and a Recruit-a-Friend program, which relied on a new, versatile code system. That code system is also being used to grant our backers the beta invitations which are part of their Kickstarter or Alpha packs.
 
Unfortunately, things don’t always go as planned, as you’ve been witnessing over the past few days (2020 strikes again...). We had to revert part of our tech migration, and postpone the move to a new authentication platform, among other things in our backend. So for the past few weeks we have been struggling to try and reconcile the new site and the code system with our legacy backend. This task has honestly been way more difficult than we had imagined. 
 
We already missed the boat when it came down to allowing you to invite your friends a week earlier, and we’ve come to announce more delays, sadly. As we approach the launch of the beta, we have to be realistic about what we’ll be able to deliver, as we had to make tough choices:

We will launch the new Dual Universe website tomorrow; it will have the most essential content and features, with some visual and quality of life improvements missing. We’ll add more content after beta.
 
The Content Creator program will be ready, using the above code system (see potential limitation below). You should be able to get the invitations included in your beta packs on day 1, though the system may not be as easy to use as we wanted. Making sure you have these codes ready is one of our top priorities (see potential limitations below). You should be able to go to the website and upload images for publishing in Dual Universe, which will go through an internal review process to ensure that they follow the game’s Code of Conduct.  
The Recruit-a-Friend program didn’t make the cut… and that sucks. We worked hard on it and we were really excited about it. The in-game content is ready, but the entitlement system isn’t. Unfortunately, we couldn’t work on all the entitlements in the limited time that we had these past few weeks.

There is a potential limitation with the code system, for both content creators and beta keys: in the next few days the codes may not be redeemable with existing accounts - only with new ones (like for the load test). We are trying to lift that limitation as soon as possible, as we know it’s not ideal. 
 
So what’s next? All these new systems, the new website, and these new programs will be constantly improved in the days and weeks to come. Our priority will be to lift the code limitation and to launch the Recruit-a-Friend program as soon as possible. We don’t want to give you a date that we may not be able to hold, but know that we are doing everything we can to make it as early as possible. 
 
Finally let’s tackle the question of “Why did we announce the Recruit-a-Friend program if it wasn’t going to be ready?” Well, that’s the point; we really thought it was going to be ready, just as when we announced the ability to invite your friends a week prior to beta. It’s disappointing, for you and for us. But we believe these programs are worth it, so we want to make them right.
 
We hope you’ll bear with us, and that you’ll be able to enjoy the Dual Universe beta in the meantime.
 
Sincerely,
The Novaquark Team
 
*Note: we unfortunately won’t be able to retrofit any recruitment that you may do between now and the official launch of the program. Recruitment will only count from the day of the launch of the program, when we can track who’s recruiting who properly.

Fresh inverview with @ZarTaen from Hyperion, shipbuilding, science, experiments, organizational things and good news, that some good news, that your boots, clothing and hover-cycles in reletive safety ?
 
https://dupress.wixsite.com/newmeroviachronicle/post/zartaen-hyperion
 
 

So! New one, with @Elias Villd, about himself, his unsual org, game potential and lot of interesting talk on Lua (casualy incluing automated killer ships).
 
https://dupress.wixsite.com/newmeroviachronicle/post/elias-villd-novalys
 
It was possible with super-patient help of @KurockNotabi! Thanks! 
 
And we, to compensate little bit of of slacking, doing 2 more. Stay tuned!

This Thursday at 11 am EST / 3 PM UTC we’ll be holding our second Twitch live-stream Q&A, with JC returning and answering more questions from the community regarding the recently released Alpha version 3.1. In particular, there will be an emphasis on the use of warp drives and surrogates in Dual Universe, so be sure to join the stream, grab a snack, and ask any questions you may have. Preceding the live Q&A will be an exclusive first look at the latest Dev Diary, featuring lots of cool new features coming to Dual Universe, including...well, you’ll just have to join us live this Thursday!  
 
Join here:  https://www.twitch.tv/dualuniverse