Davian_Thadd

So what is stopping orgs from asking their members to set the org with full rights on such a tile and place it where the org asks in exchange for .. whetever possible incentive or just as a pre-requisite to join.
 

The Dual Universe Demeter update is fast-approaching. In addition to the geometry reset and the introduction of mining units, Territory Upkeep will also be part of the package. 
 
Territory upkeep presents two benefits from a design standpoint: it should help prevent infinite land grabbing by introducing a constant financial constraint to massive land owners as well as provide a resource sink to help keep the economy in check. 
 
We looked at different options to bring some form of balance in the control of territories. For example, the current setup for organizations, that allows infinite nested organizations, ruled out a progressive tax system, as nested organizations with one territory each can be created to only benefit from the lowest tax level. 

OFFLINE, ONLINE AND TAXES
For now, the cost of claiming a territory will be at a fixed price of 500,000 quanta. After the Demeter deployment, the territory will be free from taxes for three days, which is the equivalent of having a tax break for the first week. 
 

 
Accessing the Territory interface through the Wallet menu will show you a list of your territories and their stored funds. Here is where you will add quanta to the balance for any of your territories. Taxes will automatically be withdrawn from this balance at a rate of 1,000,000 quanta per week. Each territory can hold up to 13 weeks of quanta.
 
Territories with unpaid taxes will go offline. Once funds have been added, you will be able to activate the territory once again and it will come back online, allowing mining and industry processes to be restarted. If the territory was online before the tax was successfully withdrawn, industry and mining will simply continue to run.
 
In the event that the territory successfully pays its tax, and the balance is reduced below the point that the next taxation cycle will have insufficient funds, a notification will be sent to the owner or the legates of the organization that owns the territory.
 
If the territory does not have enough quanta to cover the week, the territory will go offline and cease all mining and industry operations and a reminder notification will be sent to the territory owner or legates of the organization that owns the territory. During this period, the affected territory will not contribute to the adjacency bonus of the mining units.
 
If a territory remains offline for two consecutive tax cycles (two weeks in total), the ownership to the territory is lost and it becomes abandoned, unless that territory is flagged as a headquarters from the territory interface.

HEADQUARTERS
Each player will be able to assign five territories as their headquarters. These territories do not lose ownership when offline and remain in the players' ownership even if taxes are unpaid for longer than the two week grace period. This feature is only available to player-owned, not organization-owned, territories. We will monitor how this develops; in the future, these territories may be subject to the loss of their headquarters state if the account in question is unsubscribed; however this will not be the case in Demeter. 

TERRITORY EXCHANGE
To allow for the transfer of territory ownership to another player or organization, a territory can now be tokenized. By simply right-clicking on the territory unit, a token can be generated similar to the way constructs can be tokenized. Once tokenized, the territory will be frozen, preventing the deployment of new static constructs and terraforming operations. Mining and industry units placed on the territory will continue working as intended so long as the upkeep taxes are paid. 
 

 
The token itself will contain information about the territory and the static constructs deployed on it. Although it can be used to take ownership of that territory, this does not grant ownership of the static constructs on it. The quanta balance of that territory will transfer with the territory to the new owner.
 

 
If the token expires, it disappears and the territory will be unfrozen and remain in the token creator's ownership.

REQUISITIONING CONSTRUCTS
While territories can be lost by remaining offline due to unpaid taxes or they can be traded to other entities, static constructs may still be present on those territories.
 
The new owner of a territory can requisition any static construct present on his territory. Requisitioning will start a two-week window where the new territory owner must allow access to the static construct for the former owner and where the former owner of the static construct is able to remove that static construct by dismantling and removing it from the territory. If the static construct is still present after two weeks, its ownership will automatically be transferred to the new owner of the territory. Constructs on abandoned territories that haven’t been claimed by a new owner can’t be requisitioned though. 

STARTING WITH DEMETER…
We understand that players will need some time to adjust to the new Territory Upkeep system. In order to allow time to prepare, the first tax payments will be subtracted from the territories two weeks after the Demeter release date. Once the update is live, we will announce the exact date and time the first tax cycle will begin. 
 
CAVEATS AND COMMENTS
As with most new systems, many things are subject to change, including UI, naming conventions, tax rates, etc. Your feedback has already made a difference as the system was being developed, and we’ll continue to look at our players’ input to see what further adjustments need to be made. Share your thoughts in this forum thread. 
 

This feature is only available to player-owned, not organization-owned

It written in the text you quoted ?
Anyway, I personally approve that 5 is too much, I propose to reduce to 3 tiles, but one per planet could a thing too ? And may be limit it to SZ.

This feature is only available to player-owned, not organization-owned

It written in the text you quoted ?
Anyway, I personally approve that 5 is too much, I propose to reduce to 3 tiles, but one per planet could a thing too ? And may be limit it to SZ.

Dear Noveans,
 
Earlier this year, we announced that JC was transitioning to a new role as a board member and board advisor and that Nicolas Granatino, a long-standing backer of Novaquark via Andurance Venture, had been appointed chairman of the board. 
 
We’re happy to share with you today that Nouredine Abboud has joined the company as CEO of Novaquark. Nouredine has more than 15 years of experience in the industry and brings a wealth of knowledge and expertise with an impressive catalog of work that includes Ubisoft’s Ghost Recon games. 
 
As CEO, his primary focus is on the business side of things, so you probably won’t see him participating on the forums much. As we reach the final stretch leading to the launch of the game, the team already in place will continue to work on improving Dual Universe with NQ-Kyrios continuing his work as creative director.
 
We can’t wait to share with you the exciting things that are cooking for the game and for the company in 2022. Stay tuned!

Welcome thread is here if you'd like to say hello to Nouredine. 
 

Hi all!

Let me try to reply you  

Multiple Lua API versions
This may seem simple from an external point of view, but it is not. Indeed, we don't necessarily have the resources to rework the whole Lua API at the moment and maintain multiple versions, even if we would like to rework it completely, there are more priorities at the moment.
Anyway, be sure I've passed this point on to the rest of the team  . 


Next Devblog
Thanks for your feedback! On this point I will be cruel I think, and will let you wait for the publication of part 2  . Sorry 


Suggestions
To make sure I understand your point, when you say "add a Lua scripter for players to have custom GUIs", do you mean provide Lua libraries for GUIs that could be used by scripters to make GUIs more easily on screens? I can say that we have already discussed this, be sure that we will check your feedback and take it into account if we see that this could be a thing for players.
What do you mean by a Lua API for the map?
And if we consider the API to send/receive messages to the programming board, we have senders and receivers for that. Or maybe I missed your point.
 

Lua projection function
Could be considered, we've passed this point on to the rest of the team. Can't promise anything.
 
 
Function naming and consistency
In fact, that's exactly why we kept the return of the relative speed with core.getVelocity() and core.getWorldVelocity(), with that, your flight systems will still allow you to land on moving parent constructs. Whereas providing the absolute speed would have prevented you from doing so. With this choice, a ship parenting to a parent construct will have its speed set to relative, and can then stop on the parent by setting its speed to 0 relative to it. This is exactly what you have in game now.
 
In addition, we did not want to have too long functions. So we chose to use core.getAbsoluteVelocity() and core.getWorldAbsoluteVelocity() functions to give you the absolute speed.
All these choices have been made to allow compatibility with existing systems and not to make the API too heavy.
 
 


Anyway all, we try to done some work to provide you Lua API for all new features we added and we try to improve it on the time, listen your feedbacks to fix issues, and provide you more libs that could be interesting for you. I hope I have answered your questions and that you will like these changes.

We have been adding a lot of features to the Lua API following the additions of shields and core combat stress in addition to the docking and boarding changes. We have taken a lot of your feedback and suggestions into consideration and have made a few changes to improve some of the consistency and implementation of Lua.

These changes are minor; we can't rework the whole Lua API without breaking most of your scripts. 

With this in mind and to finalize the implementation of the Lua API associated with docking and future changes to other mechanics, we have decided to adjust a few parts that may be major for Lua creators, both for the addition of new features and the improvement and consistency of the API as a whole.

In this first part of a three-part devblog, we’ll cover the recent Lua changes and additions, including some related to docking and the deprecation of quaternions. 
 
You can read up on the other parts here: Part 2 & Part 3
 
CHANGES AND ADDITIONS
First, we have decided to rework the way the repositories associated with constructs and elements are managed.

Previously, some functions returning position or orientation information referred to the center or even a corner of the construct, others to the position of the core unit in the construct.

Going forward we have standardized everything. Once these changes go live, all functions will be based on the reference frame of the construct whose origin is the center of the build zone. Further, in order to guarantee the functionality of the flight systems and to safeguard the gyro unit, we have integrated in a clearer way of representing orientation.

An orientation unit is an element that is used to define the orientation of your construct. There are two orientation units in the game, the core unit and the gyro unit. As a construct cannot exist without a unique core unit, the core unit is always the default orientation unit. By pressing F on a gyro unit, you can switch to using the gyro unit as the current orientation unit.

You can see that the marker and arrow displayed when you enter the build mode will indicate the orientation given by the active orientation unit. 
You can activate a gyro unit by pressing F on it and so use its orientation.
 
See examples below:


For these changes, we have added:
<int> core.getOrientationUnitId() : Returns the UID of the currently active orientation unit (the core unit or the gyro unit). We have also modified the following functions:
<vec3> core.getConstructOrientationForward() : Returns the forward direction vector of the active orientation unit in construct local coordinates. <vec3> core.getConstructOrientationUp() : Returns the up direction vector of the active orientation unit in construct local coordinates. <vec3> core.getConstructOrientationRight() : Returns the right direction vector of the active orientation unit in construct local coordinates. <vec3> core.getConstructWorldOrientationForward() : Returns the forward direction vector of the active orientation unit in world coordinates. <vec3> core.getConstructWorldOrientationUp() : Returns the up direction vector of the active orientation unit in world coordinates. <vec3> core.getConstructWorldOrientationRight() : Returns the right direction vector of the active orientation unit in world coordinates. <vec3> core.getConstructWorldPos() : Returns the position of the center of the construct in world coordinates (instead of orientation units position).
  REMOVAL OF QUATERNIONS
 
Quaternions are the quotient of two directed lines in a three-dimensional space or the quotient of two vectors.  In looking at how players were using Lua and reading their feedback, , we realized that very few players were familiar with this mathematical notion of representing rotation. 
 
Therefore, we decided to deprecate quaternions from the Lua API and instead expose the direction vectors of objects.
 

 
While this leads to the addition and change of some functions, deprecated functions will remain backwards compatible and will display a deprecated message in the Lua console.
 
<quat> core.getElementRotationById(<int> uid) : DEPRECATED <vec3> core.getElementPositionById(<int> uid) : Returns the position of the element, identified by its UID in construct local coordinates (instead of the construct corner). <vec3> unit.getMasterPlayerRelativePosition() : DEPRECATED <quat> unit.getMasterPlayerRelativeOrientation() : DEPRECATED And we have added the following functions:
<vec3> core.getElementForwardById(<int> uid) : Returns the forward direction vector of the element identified by its UID in construct local coordinates. <vec3> core.getElementUpById(<int> uid) : Returns the up direction vector of the element identified by its UID in construct local coordinates. <vec3> core.getElementRightById(<int> uid) : Returns the right direction vector of the element identified by its UID in construct local coordinates. <vec3> unit.getMasterPlayerPosition() : Returns the position of the player currently running the control unit in construct local coordinates (relative to the construct center instead of the control unit). <vec3> unit.getMasterPlayerWorldPosition() : Returns the position of the player currently running the control unit in world coordinates. <vec3> unit.getMasterPlayerForward() : Returns the forward direction vector of the player currently running the control unit in construct local coordinates. <vec3> unit.getMasterPlayerUp() : Returns the up direction vector of the player currently running the control unit in construct local coordinates. <vec3> unit.getMasterPlayerRight() : Returns the right direction vector of the player currently running the control unit in construct local coordinates. <vec3> unit.getMasterPlayerWorldForward() : Returns the forward direction vector of the player currently running the control unit in world coordinates. <vec3> unit.getMasterPlayerWorldUp() : Returns the up direction vector of the player currently running the control unit in world coordinates. <vec3> unit.getMasterPlayerWorldRight() : Returns the right direction vector of the player currently running the control unit in world coordinates.  
DOCKING-RELATED LUA API ADDITIONS

With the new docking mechanic, we wanted to empower players to manage the parent-child relationship between constructs. 

Some of the additions were added in  the Ares (0.26.12) update;  however, we still had more changes and additions planned and these will be included with the Lua changes release

We have added and modified the following functions:
<vec3> core.getVelocity(): Returns the construct's linear velocity, relative to its parent, in construct local coordinates. <vec3> core.getWorldVelocity(): Returns the construct's linear velocity, relative to its parent, in world coordinates. <vec3> core.getAbsoluteVelocity(): Returns the construct's absolute linear velocity in construct local coordinates. <vec3> core.getWorldAbsoluteVelocity(): Returns the construct's absolute linear velocity in world coordinates. <vec3> core.getParentPosition(): Returns the position of the construct's parent when docked in construct local coordinates. <vec3> core.getParentWorldPosition(): Returns the position of the construct's parent when docked in world coordinates. <vec3> core.getParentForward(): Returns the construct's parent forward direction vector in construct local coordinates. <vec3> core.getParentUp(): Returns the construct's parent up direction vector in construct local coordinates. <vec3> core.getParentRight(): Returns the construct's parent right direction vector in construct local coordinates. <vec3> core.getParentWorldForward(): Returns the construct's parent forward direction vector in world coordinates. <vec3> core.getParentWorldUp(): Returns the construct's parent up direction vector in world coordinates. <vec3> core.getParentWorldRight(): Returns the construct's parent right direction vector in world coordinates.  
Questions? Comments? 

We’re sure some of the Lua-enthusiasts in our community will have questions and comments about this blog. Post them here so our resident Lua expert, Ligo, can discuss them with you.
 
Watch for Part 2 next week. It’s got great information about radar changes, the library database, an in-game atlas, and an event handling system. 
 

If you checked today PTS release change log, they fixed it. And if you read the older PTS change logs, they fixed multiple exploits  

Anyway, I like this PTS release ! So much Lua ?

This is the follow-up to Tuesday’s devblog, Inside Ares, Part One. Here we’ll go over the improvements and changes to warp sequences as well as docking and boarding. Even if you read the previous devblog about docking and boarding, you should give this a look; we’ve been finessing the original plans to make them even better. 
 
WARP IMPROVEMENTS
Based on player feedback, we’re turning the knobs down a bit on warp drive. The ability to cancel a warp at any time made it more powerful and flexible than originally intended. To curb that, warp speed has been divided by 4. Although it may seem like we’re overcorrecting, in effect it’s not as drastic as it sounds. Travel will take a little longer at the new rate; expect trips to be closer to the minute mark rather than 15 seconds. This will take it from “blindingly fast” to “still pretty damn fast”. 

The cooldown has been adjusted to 150 seconds (2.5 minutes). This will require more judicious use of warping as you weigh the convenience of using it against having it available in case of needing to bug out quickly if you unexpectedly encounter threats. 

Probably the most impactful change is that auto-align strength during the warp sequence has been reduced to 20%. This change will correct a situation where the warp alignment was way too powerful for larger ships. Keep in mind you can still align manually before warping and skip this step. We hope this will keep pilots more engaged and thinking about the warping process either by passive aligning to an extract point or actively aligning before warping.

We’re also adding spool-up time. Spooling is a post-align state in which your warp drive is spooling after aligning. This is intended to curb the purely reactionary defensive use of warp drives. Going into a PvP zone is a risk, and the risk vs. reward needs to reflect the weight of those situations. If you’re paying attention, hitting warp could get you out of most dangerous situations in a flash and we felt that this was a little too strong. Initially, the spool-up time will be set to 15 seconds.

Last but not least, weapon fire taken during the initialization sequence - be it starting the warp, alignment, or spooling sequences - will cancel the action. (Note: Hits taken once the ship enters warp after the spooling process will not cancel the warp and the ship will continue to warp.) This is a behavior players have requested and we've also intended to implement for a while. Although we don’t want to shift the risk-vs-reward ratio too far the other way, we believe this is a good change.

DOCKING AND BOARDING REVAMP
Since we published the Docking and Boarding Revamp devblog, we have continued to iterate on the design to make it even better. Before explaining the incoming changes, here’s a quick recap of what we previously announced.
 
The owner of a construct or ship is considered the “parent”. As a parent, you will now have more control of, and more information about, your current docking and boarding situation. On the information side, you will always see your current avatar/ship boarding/docking status. You are free to (un)dock/(un)board while in the immediate proximity of any construct to which you have RDMS rights. To get ''in'’ the construct, you will need to be docked/boarded to that construct or you will be repulsed.
 
A new widget will display your construct parenting information. This will also be available in the control unit data in Lua. We’re also adding a build helper window that lists parented masses (player or construct) to the inspected construct. This will allow you to evict any unwelcome guests. 
 
Thanks to your feedback, we’ve revisited our plans and made some additional adjustments based on your input. The introduction of two alternative docking modes to complement the existing default “manual” mode. 
To change your docking mode preference, you will need to reset it in the context menu action on the targeted new parent construct or by using the new shortcut to switch active docking to the closest docking candidate. 
 
The "Automatic'’ mode will automatically dock you to the closest ship for which you have docking rights. ''Automatic (owner)'' will do the same if the ship is owned by the same entity as the pilot.   
The docking widget is changing to display these changes.  

 
New Lua functions will give you more flexibility to create docking rules for your constructs. 
 
Players also told us that having to use a context menu while maneuvering the construct felt awkward. To address this, we’re making changes to the reticle that will give more fluidity by allowing you to see the best docking candidate of the maneuvered constructs, using the same shortcut (Alt-T) so that you can switch docking of the maneuvered construct without using a context menu.
 
COMING SOON
Production to transition Ares from PTS to Live is well underway. It bears repeating that players, especially those who enjoy PvP, should spend a little time on the test server to see the impact these changes will have on their personal gameplay. 
 
We’d love to hear your feedback about Ares. Join the conversation in this thread. 
 

We recently announced that an additional update, Ares, was added to our public roadmap. Many of the features and changes for Ares will be available on our public test server (PTS), when it is updated and back online tomorrow, September 15th, at 10.00 UTC. (See the roadmap here.)
 
In that announcement, we promised a devblog that would talk about the big-ticket items we plan to deliver with Ares: the new Core Combat Stress victory condition, more functionality for shields, and PVP-related fixes. (Inside Ares, Part Two will cover warp improvements as well as boarding and docking changes. Watch for it on Thursday.) 
 
Without further ado, let’s dive in! 

CORE COMBAT STRESS 
In a nutshell, core combat stress represents a core's ability to keep functioning under prolonged weapons fire. A core unit that takes too much stress will be destroyed and will be considered a PvP destruction.
 
Core combat stress will be used as a second loss condition on constructs during PvP, working in tandem with generic core unit destruction. It does not matter which one happens first, only that one happens eventually. This will allow us to support larger fights and ensure that everyone's weapons are doing damage, even if it is only against core stress.
 
Stress will be accumulated as the construct takes non-shield weapons hits, taking the form of a gauge that starts at 0% and goes up to 100%. Non-shield hits on a construct will make the gauge go up. The core stress gauge is affected by a weapon's raw damage and is unaffected by the resistances of the element or material the attack hit.
 
Example: A weapon hit does 1,000 thermic damage. It hits an element with 50% thermic resistance doing 500 damage to the element; however, the core stress gauge will count 1,000 damage for that hit.
 
When the core stress gauge hits 100%, the core unit will be destroyed and will be considered a PvP destruction (as if it was destroyed by a weapons hit) and everything that implies.
 
The value of the stress gauge will be defined by the following:
The base of the core stress gauge value will be the health sum of honeycomb materials on your construct. The quality of the material used will provide multipliers to the value. Higher honeycomb tiers will provide better multipliers. The type of material used will provide a different multiplier, with products having a better multiplier than pure materials.   
Finally, the stress gauge will gain health linearly with honeycomb until a cap, at which point additional honeycomb will have diminishing returns.

SHIELDS v2
The fundamentals for shields were unveiled in this devblog and made their initial debut with the Apollo update in August. The time has come to increase their potency and value with some new features. 
 
Shields v2 brings adjustable resistances and venting. 
 
Adjustable resistances Shields have a base resistance value of 10/10/10/10 with an additional resistance pool of 60% that players can assign in 5% increments to any of the four resistances. (Examples: 10/10/10/70 or 25/25/25/25) Once players have locked in their resistance selections, those choices will be active and cannot be changed until the cooldown time of 60 seconds has expired, at which time the resistances will remain as set unless they are recalibrated. Shields UI will display which resistances are taking the most damage on the shield, allowing pilots to make an informed decision regarding the settings. Venting Pilots may vent their shields at any point, the exception being when the venting cooldown is active. Cooldown duration varies per size, with smaller shield variants having lower cooldowns. Venting shields will do two things: Turn off the shields, bearing in mind that they can’t be active during venting.  Begin shield regeneration of a certain percentage per second.  Venting may be deactivated at any time. Deactivation will occur automatically when shields have reached maximum capacity.   
We highly encourage pilots to explore the use of shields and venting while it’s available on PTS. Since there’s a bit of a learning curve involved, the test environment is the perfect place to experiment freely without any real cost to your ship on the Live server. 
 
PVP FIXES
We’re closing the loop on some “unintended” uses of these game mechanics. 
Speed Resume deactivated on construct death: When a core is destroyed, that construct will be incapable of benefitting from speed resume in any way. This will avoid and fix various exploits in regards to “ghost-riding” destroyed ships into safe zones. Offline player deaths on construct death: Offline players on constructs will now be killed on core destruction. This will avoid logging off characters that can then log back in, repair the core unit, and attempt to flee.   
Originally, the plans also included a change that would cause ownership loss on core unit crash destruction. Thanks to our intrepid PTS players who tried it out and promptly let us know the problems such a change could cause, we pulled it from the Ares update. (Read the related post from the Game Design team’s NQ-Entropy.) 
 
This is exactly why we have a test server and why we value those who do reconnaissance there before the updates are released on the Live server. We offer sincere thanks to the players who took the time to give us candid, constructive feedback. 
 
SEE YA THURSDAY
Inside Ares, Part Two will be published on Thursday. While you’re waiting, why not head over to the forum and share your thoughts about Part One? 
 

Questions or comments about the Market-Cleanup announcement? Post them here. 

Update 10-20-21 - REMINDER: These rules are still in effect and are now extended to mission hubs. 

In an effort to improve the experience of visiting some of our most popular markets, we will be implementing a new set of rules for constructs left at markets. Enforcement of these rules will begin on the 3rd of September at 6pm UTC. (That’s one week from the date of this notification.)
 
We want to encourage a free and open game environment for all to enjoy. It’s in the spirit of that goal that these measures are being put into place.
 
Only ships are allowed on the market landing platform. Constructs must be parked outside the green perimeter line surrounding the main market building and the access ramp to the market. One container construct per entity (player or organization) will be allowed for the purpose of storage below the landing pads. Shop constructs, advertisements, and dispensers are not permitted at any markets. These should be placed on your own tiles or at districts instead. We would like to remind you that you now have the ability to place a “Welcome Visitors” marker on your territory.  Under no circumstances may player constructs intersect with the Aphelia constructs. Constructs at the Aphelia markets must be parked either on the landing platform or the ground around the Aphelia markets. Airspace within 2km of the market building must remain clear. XL screens and screen arrays are not permitted within 2km of the market building Constructs that violate these rules may be hidden, removed, or abandoned without warning. Novaquark reserves the right to move, hide, or delete constructs at its discretion, for example if they are designed to circumvent these rules or if they impact marketplace performance or usability.  
To safeguard the performance of everyone visiting these locations, we strongly encourage players to adapt any screens and advertisements to use Lua based Render Script instead of SVG/HTML even if that is in the form of uploading an image of your SVG and then loading that into the Render Script.

Join the conversation here.
 

Currently it is not possible using the new LUA screen functions to rotate text. As a result, is it is not possible to have a screen in portrait orientation with text.
 
The only way to add text using the new functions is
addText(layer, font, text, x, y)  
But the documentation states that this function does not support rotation
Screenshot: https://imgur.com/a/GHxK0w8
Documentation: 
 
 
Text rotation is essential, I won't be able to convert my existing content over without it. Can this be added a priority?
 
Thanks
 

When a ship with an active shield is being shot, will the resistance of the element/voxel matter that would be hit, or the resistance of the shield, or both?

Can you use multiple shields?

Can you already allow the building (release schematics) of the items and then "enable" them with the patch? That way people can already make, trade and build with the shields and are ready when they are released. Otherwise, given the Honeycomb HP nerf, people will have to wait until they get a shield before they can continue their normal gameplay.

Okay, PvPers, this one’s for you! 
 
As foretold in The Future of Dual Universe Part 3: Finding the Fun and the recently-published 2021 roadmap, we’re adding some new toys to your arsenal and making some of the existing toys even better. 
 
These changes will come over time and in waves. Here’s what you can expect in the first pass as part of the Apollo (0.26) update, now available on our public test server. 

New PvP element: Shield generators
Shield generators serve as the first layer of protection for dynamic constructs during combat. Shields will absorb damage until depleted, at which point they will stay depleted until the end of combat as defined by the combat timer. Future plans will bring shields into play for space core units, but for now, they will only be available on dynamic constructs. 
 
These elements come in sizes XS through L with different shield strengths respective to their size and are not restricted to core sizes.
 
This is the V1 technical phase of introducing shields, making sure that the foundation is solid before more bells and whistles are added.

Honeycomb Health Points
Adjustments to honeycomb HP--rebalanced and significantly reduced--have been done in the context of the implementation of shields and the weapons rebalance. With these changes, we should see a general reduction in fight duration with a faster time to construct destruction (TTCD).
 
Specifically, gold has been brought back in line. While still technically the highest HP honeycomb, it will now come at a serious mass cost compared to other options. This should open new options in honeycomb selection when building ships and reduce the feeling of “gold or nothing” players may currently sometimes feel.

Weapons adjustments
We found that the disparity between the smallest and largest weapons DPS was too great. This made it difficult to justify using anything other than L weapons. While L weapons previously did roughly eight times more damage than XS weapons, they will now only do just under three times more damage than their smallest cousins. 
 
Revised damage per second:
XS weapons: On average, extra small weaponry will do 2.5 to 3 times more DPS. S weapons: On average, small weaponry will do 1.75 to 2 times more DPS. M weapons: On average, medium weaponry will do 1.5 times more DPS. L weapons: On average, large weaponry will do about the same DPS.  
In regards to DPS, larger weapons of the same type will take more time to cycle, allowing larger weapons to keep hitting hard per round, at the cost of rate of fire.
 
Lastly, adjustments have been made on various other parameters, such as reload times and weapon capacity, to help balance overall damage output, and how it feels to use.
 
We hope this brings more diversity to the offensive options you have when building ships and allowing more space for smaller ships and weapons.
 
Cones
Weapon cones’ optimal and falloff values have been augmented by about three times (with the exception of missiles). This change was based on feedback from the community who said that weapon cones felt too limiting and restricted flexibility when designing ships. 
 
We hope this allows more options when placing different weapon types, having more weapons that approach similar levels of flexibility to missiles with weapons like lasers and cannons having a much wider range of operation. Railguns will remain relatively limited as a heavy sniping platform but will still enjoy more cone than before.
 
Tracking
Tracking on weapons is the ability to reliably track and hit targets. Weapons with improved tracking will generally have better chances of hitting targets, especially smaller and faster ones.
 
There was always an intention that smaller ships should be able to evade damage from larger guns. In practice, this was not the case as L-based ships easily dispatched smaller constructs at various ranges. 
 
To help correct this, tracking has been significantly decreased across the board by about half on every weapon. These initial adjustments will help, but likely not suffice in helping smaller ships survive combat engagements. We will continue to look at other options for further iteration in future updates and already have plans on the subject.
 
As a parting comment on weapon balance, please note that this is more of a global rebalance to address macro issues we had across the board to set a healthier base. Expect more specific adjustments to come later for specific weapon changing and balancing as more PVP-focused releases are done in the future. 
 
Opinions Wanted
As noted above, and in nearly all of our communications, player feedback is always welcomed and encouraged. Particularly as these changes are on PTS where you can experience them first-hand, your opinions go a long way in helping us make needed adjustments before Apollo (0.26) debuts on the live server. Please take a moment to share your thoughts in this thread.
 

We invited you to ask questions about 0.25 and 0.26 for a Q&A, and you did not disappoint! Here are the responses to some of the most commonly asked questions. 
 
The community also expressed curiosity about issues related to schematics and voxels. Those are both important topics that we think would be better served in separate, focused discussions. We’ll hit those for you soon. 
 
Big thanks to everyone who submitted questions. Let’s keep the conversation going! 
 
1. Will the PTS receive a newer image when the next iteration comes through?
Our most important consideration is to ensure better, smoother releases. (Can we agree that Hermes went pretty well?) Unfortunately, that means that migration to PTS is not on the priority list. Migrating the database from the live environment to the PTS requires a lot of work from our DevOps and Production teams, among others. These resources are scarce in the company, and, as usual, it’s about choices. 
 
We’d like to remind you, though, that playing on PTS comes with a lot of perks, such as dispensers with infinite resources, the ability to change skills at-will, millions of quanta, etc. 
 
2. Are there going to be any changes to nerf the ability to use multiple alts with the hauling missions?
We don’t currently have plans for that. We consider the cost of moving a package being the movement of the mass. You still need a bigger ship to move a larger amount of cargo. That said, we will consider the question of alts carefully for future mission types.

3. Will you be adding a way to identify which packages belong to which mission?
This is a great suggestion! We definitely see how it would bring quality of life for mission-takers out there. It seems quite doable although it’s unlikely we can include it with Apollo (0.26) since that’s already underway internally and should come to the PTS soon; however, we’re in the process of discussing how we can add it to a future release.
 
4. Are org changes coming with 0.26?
Following feedback from the community and discussions with some of the major org leaders, we announced this week that the org changes have been postponed. While we still need to address issues caused by nested organizations, we also want to make sure that we approach the changes in a collaborative manner with the players. With more options to consider and more conversations needed, it’s highly unlikely that these changes will come with the next major version, Apollo (0.26).

5. Will you please elaborate on what you mean by "PvP balance changes"? Will you be improving combat with smaller cores/stopping cube designs, etc., or just adding shields?
We’ll share more details as the Apollo release date gets closer. To give you a little sneak peek now, we can say that overall it will feature weapons changes (including cosmetics), PvP-related bug fixes, the introduction of shields, and quite a few changes to the overall balancing of PvP. We would like to manage expectations by stating that this will be the first wave of changes and that we will have more heavy PvP-focused releases in the future.
 
6. Is passive mining coming before asteroid mining?
Planet/passive mining is planned for the release after Apollo, codenamed Demeter. With Apollo, we are focusing on the introduction of asteroid hunting and mining gameplay. We’ll communicate more about it once Apollo is out of the way, but rest assured that these changes to mining are not too far in the future.
 
7. Do we get to have mining elements for ships?
With Apollo, we will introduce one new element called the DSat scanner, which will be used to hunt down asteroids and discover their location. Mining itself will work as it currently does on planets though. More info on Apollo features coming soon. 

8. Will asteroid mechanics still put a huge red arrow over your head by broadcasting the position through the universe, removing any need for PvPers to put effort into finding those who go out and find asteroids?
To clarify, some asteroids will be in the PvP zone and some won’t. Asteroids in the PvP zone will have higher chances of including higher-tier ore and, as such, will be more valuable. But asteroids in safe zones should be worth your while, too. 
 
There will be a countdown between the time an asteroid is discovered by a player and the moment when its location is broadcast to other players. (Currently, the gap is four hours but this may change once we get feedback from players.) It shouldn’t be enough to completely deplete an asteroid of all its ore, but it should be enough to mine all the good stuff first. Once the location is publicized, it’s up to you if you want to stick around to finish mining the asteroid or move away before the pirates show up. 
 
We think this will provide interesting collaboration mechanics (mining while others protect the miners, for example) and, yes, additional PvP opportunities. We don’t think it will become an easy targeting system for pirates, though, as there’s no guarantee miners will still be on site by the time they arrive after learning of an asteroid location. 
 
9. Will the asteroid system use the current land mining system, 400m manual scanner and hand-operated vein or will it be blocks of pure ore?
Yes, asteroid mining will use mechanics similar to the current on-planet mining gameplay. Think of them as mini-planets with valuable ores.
 

The three-part devblog series we published in April, “The Future of Dual Universe”, addressed the cost of doing business and our plans for the ramp-up to launch. We took the first steps in delivering on those changes in May with the incremental 0.25 updates, adding more gameplay content and improving both performance and visuals.
 
Our 0.25 updates brought players:  
Voxel compression  Constructs LOD  Hauling Missions The Job Forum The first of a series of Challenges The integration of PopcornFX for visual effects And, of course, many bug fixes and additional improvements  
If you haven’t had time yet to check out these changes, we released some videos showcasing them. Watch this video for a closer look and missions and challenges and this first look at the new visual effects. 
 
About the latter, It was fun to watch the real-time reactions from our Twitch streamer community as they saw the changes for the first time. 
 
Now that 0.25 is wrapped up, development is underway for our next big milestone. Codenamed Apollo, the update centers around the first phase of a major mining revamp. The addition of asteroids will provide rare and precious ore, which in turn will create opportunities for conflict as the hunters become the hunted. To that end, PVP will receive a first wave of balancing changes and the introduction of shields. Keep an eye out for devblogs on these topics! 
 
In the meanwhile, we’d like to invite you to post your follow-up questions about the changes we introduced in 0.25 in this thread. In turn, we’ll take the best questions for an upcoming Q&A. Your insights and constructive feedback go a long way not only in helping us identify any lingering issues that should be addressed but are also helpful in how we can make things better in future updates. 
 

We’re making some changes to the way organizations work. 
 
Currently, organizations can cascade within themselves thus making it possible to create a near-infinite multitude of sub-organizations. This poses a problem from both a design and cost perspective as it removes any form of scaling limit to the amount of constructs and organization that can be in the game. It also leaves the door open for various ways to circumvent limitations needed for balancing. 
 
These changes will address these issues as well as clear up a number of anomalies that are affecting some existing organizations. They will be included in the 0.26 update, which gives you more than a month to reorganize as needed. 
 
New regulations for organizations will be:
Each organization must have a player as its super legate. An account can only be the super legate of one organization. Nested organizations will still be possible but will require a player as super legate of that organization, and that player cannot also be the super legate of the parent organization.
  To ensure a smooth transition and have things set up the way you prefer, we encourage you to restructure your org(s) accordingly. Organizations that have not been updated will undergo an automated modification process. This will be done in a prioritized order as described below. 
 
For players that are the super legate of multiple organizations:
One organization will be selected as the player’s primary organization according to the following parameters: The number of players in the organization. The number of constructs in the organization. The age of the organization. The player will become a designated legate for any other orgs to which they belong.
  To address situations where an organization is nested within another so that there is no player designated as super legate, these are the solutions we’ll pursue: 
The legate with the most seniority that is not already a super legate of an organization and has connected over the past month at the time of the change is promoted to super legate. If no legates exist, the oldest member that is not already a super legate of an organization and has played within the past month at the time of the change is promoted to super legate. The oldest legate that is not already a super legate of an organization is promoted to super legate. The oldest member that is not already a super legate of an organization is promoted to super legate. If none of the above apply, the organization will be disbanded.
  Constructs and territories for any properly structured organizations or organizations that are assigned a new super legate will be unaffected and remain in ownership of that organization. The constructs and territories of disbanded orgs will be reassigned to the first former super legate in the chain of organization parenting. Any other construct will be abandoned, and territories will be unclaimed.

 

Damn you people are whiny.
 
This change is awesome.  Docking is simplified, not made harder - much better than the maneuver tool jankiness.  Though floating 'docked' ships may look a bit odd.  
The only form of 'boarding' DU has today is where you take an alt and logout on someone's ship when they're not online.  Which part of that is fun?  It is very nice that NQ has finally cleared that up, so people like Markee aren't constantly being harassed, and until we have AvA there's no downsides.  We may see some changes once AvA is in, who knows

Globaly, I like the idea !

The docking and boarding rights use is logical.
The build helper addition is good to be able to monitor it.

Anyway ... the docking procedure become more "complex", more steps. A thing that could be not appreciated. Could be may be improved later with a right management with Lua, to be able to implement board system asking docking request and autorize by Lua ...etc

The boarding system ... humm.. on one side, it's good to control who is in your construct. And think about expositions with the "deactivated" status is good.
Just certainly consider to reauthorize entering of players in active constructs when we will have to ways to defend, with the AvA.

Currently, considering there is no ways to act against a players, I'm for !


Good addition ! ?

I think this makes sense now. Boarding parties aren't feasible without AvA and the speeds and rubberbanding involved in combat, will probably need a whole new boarding game mechanic to get around that

Really like this devblog.  Repulsing ships that try to ram you in pvp will be nice.  As people build "kinetic impactors" to try to intercept a larger construct where the aim is to get the larger construct to collide with the kinetic impactor destroying the target.  The other thing in PVP it is common for people to logoff chars on rival pvp ships so they can easily track locations.  Furthermore people taking this step further by carrying as much weight in nanopacks to weigh down a target construct to reduce its performance.  Very cool I really like this thumbs up NQ.

Space can be lonely, and, if some adages are to be believed, no one can hear you scream out there. You may want to bring along some friends, maybe not so much for the screaming but for sharing fuel and good times. That’s where docking and boarding comes in. 
 
Previously referred to with the blanket term “parenting”, breaking them off as boarding and docking clarifies what they are and what they do. Just as the name implies, boarding allows passengers to come aboard your ship. Docking makes it possible to have ships connected to other ships, even when both are moving. This boarding/docking relationship basically has the same functionality and behaviour as before but with the added benefit of rights management.
 
In its original design, boarding or docking a construct was not consensual. Neither the player who owned the construct being boarded/docked nor the player whose construct was being attached to another could decline. They may not have even been aware it had happened in some cases, it simply occurred due to their proximity. 
 
This was a problem for a few reasons, most notably that it opened the door for bugs and exploits. In addition to negating those, revisiting the feature also gives us the opportunity to make it more intuitive and purposeful. 
 
ASSIGNING RIGHTS
Owners can use the Rights & Duties Management System (RDMS) to assign Right to Board or Right to Dock to their constructs that will let others board or dock, or to forbid such requests. 
 
Dynamic constructs have the ability to move, as opposed to static constructs - like buildings - that are immobile. With the necessary rights, avatars will be able to board dynamic constructs, and smaller dynamic constructs (let’s call them shuttles) will be able to dock with bigger ones (aka carriers). When boarded or docked, the player or the shuttle moves with the carrier, and their mass is added to the carrier’s physics. 
 
A player or a shuttle will need to be near the carrier in order to board or dock, it can’t be done from a distance. The distance is commiserate with the size of the target vessel, the minimum distance being 32m and 128m being the maximum. 
 
BOARDING
Players are able to board any inactive dynamic construct. This makes it possible for them to tour constructs on display in a marketplace or the like. The construct will go into the “active” state when the owner or someone else with piloting rights jumps into the driver’s seat, and unauthorized passengers will be automatically ejected.
 
If a player enters a dynamic construct with the proper rights or when the construct is inactive, they will become boarded and can move freely around the construct. 
 
The UI display may look something like this: 

This is a sample of the UI that is still in progress 
 
If the construct is active and the player attempting to board does not have the necessary right to board, they will be repulsed. The effect is similar to hitting an impassable barrier with no damage taken. The UI display may look something like this:

 
DOCKING
Once shuttle pilots with the necessary rights are within range, they can manually dock to a carrier. This is done through a contextual menu that is accessed via right-click. The shuttle will then be invisibly tethered to the exterior of the carrier. 

 
Without that clearance, the shuttle will be repulsed.

 
Authorized shuttle pilots will receive an opt-in confirmation to signal when they are within docking range. 

 
The “Docking” widget in the piloting UI informs the pilot of the shuttle when they are in docking range through this small open chain link icon.
 

This is a sample of the UI report to show a shuttle’s docking status.
 
PARENTING ADVICE
The owner of the carrier is considered the parent, and those who are granted boarding or docking rights are children.   
Just as real-world moms and dads, construct owners can give their “kids” the old heave-ho when it’s time for them to leave the nest and fly solo. This is done in a Build Helper’s submenu where all boarded players and docked shuttles are listed.
 

 
Buh-bye! Boarded avatars can be ejected at any time directly through the carrier’s Build Helper interface. 
 
This results in ejected players suddenly finding themselves adrift, possibly in deep space. Here, they have two options. Jetpack to a safe place. Depending on the distance, this could take quite a while; however, it’s safe (they can’t be attacked) and they will arrive with the inventory in their nanopack. The second option, suicide, will get them on terra firma faster, but they will lose whatever they were carrying. Probably a good idea to stay on the good side of the carrier captain to avoid being in this predicament. 
 

 
With a few simple clicks, the carrier pilot can easily de-dock shuttles, too. 
 

 
TAKE IT FOR A SPIN
These changes will be featured in an upcoming release on the public test server (PTS). We highly encourage our community to explore it when it’s available, then let us know what you think about the ease of use and convenience. Until then, feel free to join the discussion on our forums.
 

Despite our recent efforts to expand and clear out Market 6, we are still getting reports about performance and clutter. We want to assure our players that we understand your frustration and are still working to find better permanent solutions. 
 
Meanwhile, we will be addressing clutter across Alioth this weekend. Our plan is as follows:
Dynamic constructs that have not had direct interaction with their owner over a set duration (currently 30 days*) will be hidden.  Constructs at the market that violate our rules,  Code of Conduct and EULA will be removed.
If your construct is hidden, you can unhide (recover) it by using the Fetch tool. To do this, right-click on it in the Construct list on your Map screen. Any constructs that you own, whether visible or hidden, will appear on this list.
 
Fetch functionality now works for organization-owned constructs as well. For hidden constructs that belong to your organization, your legates can retrieve them via that same functionality. 
 
Our customer support team is at the ready if you still need assistance recovering your constructs. Simply ping our Live Support staff in the in-game help chat with “@GM” or file a ticket on our support page and we will dispatch help right away!
 
Please note that this is intended only as a temporary measure to aid performance and improve your experience when visiting these areas. 
 
We look forward to seeing the results from these changes over the weekend.
 
May your frames be plenty.
 
 
*Duration may change based on our findings 

THE FUTURE OF DU
We’ve seen a lot of positive feedback following the release of our devblog series on the future of DU. We’re  thankful to our community for the great feedback and encouragement. We’ve collected what seem to be the most burning questions following the publication of the blogs and wanted to do a follow-up to address them the best we can. Not all questions have an answer at this point, and we’ll try to fill in the gaps as we’re able in future communications. 
 
Are you going to launch the game in 2021? 
Realistically speaking, we have too much to do with the time that’s left  this year to get to a state where we feel the game is ready for launch. Our current plan is “at some point in 2022”, and we’re targeting mid-year. That projection is tentative, depending largely on our progress and  the feedback we get from our community, so please don’t hold this as a commitment. It could be sooner, it could be a bit later. The state of the game will dictate the date.
 
Why is the game not working on Shadow (cloud gaming platform) and do you plan to support it?
We believe cloud gaming platforms are a great way to enjoy DU if you want to play the game but don’t meet the proper PC specs or want to benefit from the latest hardware improvements without investing in upgrades for your gaming rig; however, we need to clarify that we are not yet officially supporting cloud gaming platforms, including Shadow. Our releases are not tested on these platforms or Windows emulations on Mac and Linux, and we can’t guarantee compatibility at this point. The game is still in beta, and we are focusing our efforts on native Windows PC support.
 
We plan to officially support these platforms at some point, and would like to ensure that when we do we are able to offer ongoing compatibility with adequate testing and collaboration with the platform holders to make a long-term commitment. 
 
We recently started working with a cloud gaming platform in an official manner, and we are hopeful to announce our official support of that platform soon. In the meantime, compatibility with cloud gaming platforms can’t be guaranteed. We log bugs and look at potential quick wins, but we can’t commit to a timeframe for fixing them. Please also note that there is a waiting list of one year to have access to one of the machines of Shadow, which makes debugging all the more difficult.
 
Will there be an updated roadmap?
At the moment, there is no plan to release an official roadmap with dates. We tried to explain why in the three devblogs. We’re changing many things in the way we develop DU, and it’s hard right now to have a clear idea of our future velocity. We don’t want to give you dates that we might not hold. We think it’s more important to have the freedom to adapt to your feedback rather than trying to hit the dates on a public roadmap. We hope you will see this as a sign that things are changing for the better and that we’re being more realistic in our approach.
 
Why don’t we have more frequent releases?
Dual Universe is an extremely complex game to develop. Many of the systems we have already in place are interdependent, and changing or adding a feature has ripple effects on other features and systems both in terms of code and in terms of feature design. For example, RDMS has to be carefully considered in many things we do, as does  the role of organizations in the introduction of new features, etc. Most of the tech we use is custom and not off-the-shelf. It’s one of the secret sauces of the game, and it also makes features much more difficult to work on because we develop the tech AND the features at the same time.
 
Now, with the introduction of the PTS, we hope to make more frequent releases, including releases of prototypes, such as the Lua technology for screen units. How frequently will depend on what goes in these releases and how much work needs to be done after we receive feedback from the PTS. We estimate that you can expect three to four additional major releases in 2021, and smaller releases in-between, but that’s only a ballpark estimate for now.
 
What’s going on with long-standing beta bugs? Are you going to fix them?
Yes we will fix them as quickly as possible although we aren’t able to pinpoint an exact date. Some bugs are easier to squash than others, and some even require a rework of an entire complete backend system to resolve. These processes need to be scheduled accordingly, also taking into account that we want to avoid reworking the same thing multiple times if we suspect that the development of an upcoming feature will force us to rework the same system again. The more critical the bug, the higher the priority. When we’re focused on fixing bugs,  that means we’re not working on the plan we presented to you, so it’s a balancing act. We wish we could give you a list of bugs and a timeframe for each one, but that would be highly unrealistic. These bugs are not being forgotten, that’s the best we can tell you right now.
 
Can we expect a more frequent communication from Novaquark?
We’d love to, just understand that the frequency of our communications really depends on the cadence of the game releases. The way it works is that as soon as the content of a new release is established (at least a content draft), we sit down and make a plan for how and when we’re going to talk about these features/this content. Often we have to wait until a feature is stable enough in terms of game design and/or coding to be able to talk about it or show it, as a feature can evolve a lot along the development process and the unfolding of our sprints. We simply want to ensure that the information we give you isn't misleading, as early communication means the end result may differ significantly once development is complete and the feature is released.
So between releases, there is indeed a communication gap. 
 
There are different general topics we could discuss between releases, but they wouldn’t really bring anything concrete to the table and that communication could be seen as shallow and vague. It’s actually an interesting topic we’d like to explore with you: what is it exactly that you expect in terms of communication? How can we balance having meaningful content to present with what seems to be the need of our players to see ongoing communication? Based on reactions we’ve seen in the past, we  believe that communicating simply for the sake of it when we have nothing really new to talk about is never well-received.
 
What about PvE? Are you planning to add PvE features to make the game more varied?
Our current focus is on enabling emergent content between players. PvE is not one of our priorities at the moment. This doesn’t mean that it won’t ever come to the game, but it is not going to be added before the official release of the game. That said, one could potentially consider the challenges that we’re currently working on as some form of PvE, though not in the sense that you’ll be shooting NPCs or wildlife.
 
Will we see a return of NQ employee Interviews and AMAs?
We would love to do things like livestreams and AMAs again when the time is right. We feel like these formats are better suited when there is a clearly defined topic to focus the discussion, such as a major release for instance. It is duly noted that these interactions with the community are appreciated, and we will include them whenever possible.
 
You mentioned the changes in the industry gameplay, but it wasn’t clear if schematics will stay or go?
The honest answer is that we don’t know yet. When we introduced schematics, it was a major disturbance in the forc… in the economy of the game.  We don’t want to rush into more changes after that, especially given that players invested a lot of hard-earned quanta in buying them. Removing schematics is ONE of the options we’re looking at, as well as changing their prices or adding more recipes. Reverting to the way it was before the introduction of schematics is also on the table. We know we want to do something with the current state of the industry to add back some of the fun that was taken away with 0.23, but how exactly we’ll do it is yet to be decided.  
 
Is there going to be a wipe?
We see that the debate on the topic has been pretty hot in the community for a while, and it’s about the same at Novaquark. We’re uncertain if the changes we are planning to introduce will require a wipe or not, and we’ve started (intense) internal discussions on the topic. Our priority is to try to preserve the time and effort that our players have put in the game since the beta started. Once we’ve got a better idea of how much the changes we discussed in the third  “Future of DU” devblog will impact the game’s economy, we’ll make a decision. If there is a wipe (and it’s a big IF), it may be a partial one only affecting certain aspects of the universe. Our  priority will be to mitigate the impact for long-time players.

Join us in our feedback thread here!