ZarTaen

@NQ-Admin Hi, it's important.

Can you put all the alien core in pause (production/lockdown) until PVP was fix? (Radar + Transponder + Anynewbug)

We can't fight in good conditions, we can't have fun or enjoy this content (and it's the only PVP available atm) and with the wipe no decision + all those PVP bugs, we just lost all our motivation.

Do something, don't be passiv, thx.

Noveans, please share your thoughts about Ask Aphelia Episode #2 here.

Hello Noveans,
 
Many thanks to all of you who have been with us from our Kickstarter campaign. We appreciate your support and your patience and would like to update you on the status of the rewards you have been waiting for.

THE PHYSICAL KICKSTARTER REWARDS
 
Production on the Dual Universe figurines and the Collector Box is complete. However, there are two challenges in shipping them:
 
First, due to the COVID-19 Pandemic, the price of shipping has risen significantly. It has reached a point where sending the rewards would cost as much as producing them. We had hoped that these price rises would only be temporary, but we now know that they won’t decrease in the short to medium future. We’ve therefore taken the decision to absorb the increased cost and to move forward with shipping the physical rewards. The second challenge has come from our partner responsible for handling the shipping of the physical rewards. They’ve recently informed us that they won’t be able to complete the task. We are therefore searching for a new partner to take receipt of the physical rewards and to start shipping them to you as quickly as possible.     THE VIRTUAL KICKSTARTER REWARDS
 
Both the Kickstarter Founder Packs and the Supporter Packs will be released throughout the milestones of 2022 in Dual Universe. We’ll give you more concrete details on exactly when you can expect each part of those rewards packages to be released in the months ahead.

Your support and patience mean a lot to all of us at Novaquark, and the delivery of your Kickstarter rewards is one of our priorities. We thank you again for your support and will update you with more information as quickly as we can. 
 

Thank you for raising these questions. The important one from my point of view is "Why we don't have a combat free timer after we win a defence?". This machnik would make an attacker think twice before attacking. It would also be nice to double both the shield HP and the time for the attacker.

Earlier was probably not a good time, but now the last big patch has been placed, and it is minor patches before release then now is the ti e for controller and joystick input.
It’s a flight game, so really needed for some of us which aren’t very dexterous on the keyboard. 
 

Yes, that's a long-time wish. Similar suggestions were posted months ago. 🙂
 
 
The ideal level of weathering would be similar to what can be seen and experienced in "Ark Survival Evolved", as I can compare directly.

It's not much, and since there are no survival mechanics, it's unlikely to have much game mechanic impact.... BUT it would bring a lot of immersion into the game.

 

Our new system map overhaul gives powerful new tools to players in visualizing the Helios system. You can read about this new Athena update feature below!

OVERVIEW
 
Players can now see and navigate around the entire system map laid out to scale in three dimensions.  

 
Setting a Warp Point will no longer replace your current destination. Players may now set a destination waypoint separately to a warp-specific waypoint.  
Space resources such as the Alien Core Units are accessible through the map.   
We’ve added a better organized menu that opens quicker and has a more useful filter system in the top-left menu, allowing players to filter items on the map by name, owner, or construct type.  

 
Players can see coordinates displayed in real time as they move the target around the map, allowing for precise copying of coordinates, position input and bookmark creation.  
THE CONTROLS
 
You can freely move around the map, rotate it by holding left click, pan around horizontally by holding left + right click and pan vertically by holding right click. You can zoom by scrolling your mouse wheel. You can also reset your view back to default with a button in the top menu.  
You can toggle display settings using the associated button in the top panel, such as the target plane or the safe zones. This will let you choose the amount of elements visible on the map at all times.  

 
You can select any item with left click, select and move to any item with double-left click, and select, move to and reorient the camera with middle click.  
You will also see an exact distance indicator between your avatar and any location (or your current selection and any location, if there is one), by mousing over them. Distances can also be quickly gauged using the grid size indicator at the top.  
Players may set destinations, warp points, open planet maps and more from the menu on the top-right of the map when selected. These actions are also served through contextual menus displayed on bodies in the map.  
----------------------------------------

As always, we’d like to hear from you. How do you like the new map? Will it have an impact on your game? Please let us know here.
 

Intro
With the recent dev-blogs, I feel like there's been a change in attitude with Lua. Before, we basically never got changes to it or the changes were very minimal/incomplete. (*cough* character orientation *cough*)
But, now that we're adding a bunch of functions to Lua, so much so that it's starting to get cluttered with really long function names, I think a general structure change should occur. A perfect example is camera data.

Structure Change
The core unit, control unit and system basically are filled to the brim with functions that don't really related to them, especially system.
 
So, here I go with what I believe should happen:
The creation of a "Construct" default slot. (No links required)
The creation of a "Player" default slot. (No links required)
The creation of a "Database" default slot. (No links required)
The creation of a "Elements" default slot. (No links required)

Construct Slot (moved to)
This slot will handle everything to do with the construct, and only the construct. As the first dev-blog has shown, a fair number of things are irrelevant of the core, thus it doesn't quite make sense that we should still access the core for them.

For example, world orientation of the construct is irrelevant to the core, and even ordinary orientation is irrelevant to the core since it is based off the orientation unit, a gyro or core.
However, data which is more core-related remains, like direct calculations/measurements that you would imagine the core making (velocity, acceleration etc.).
 
Player Slot (moved to)
This slot will handle everything to do with the master player, the player who has executed the control unit. As you can guess, a fair number of functions are placed on the unit because of this. But, it sort of makes little sense beyond the fact that the player activated, not to mention to access any player related info, they want to prefix every function with MasterPlayer, a perfect example of how absurdly long it is getting is unit.getMasterPlayerWorldForward(), now tack on camera to it... unit.getMasterPlayerCameraWorldForward(). You get the point.
 
Database Slot (moved to)
This will consolidate any thing that essentially accesses a database, static or otherwise, for instance getting the player name, position, etc. It will be similar to the Lua version in our files, but be entirely made of native code, instead of Lua. This should help with Database.lua's semi-redundancy and inefficiency, aside from code length contraction.
 
Elements Slot (moved to)
This will consolidate any general element function that is normally accessed by the core. This will remove the need to basically prefix stuff with getElementDATAById(uid)
Instead, you will simple say getDATAById(uid) or getDATA(uid)
 
Keys
Bad Name* (Italics, suffixed by one or more light yellow asterisks, name requires a change for consistency reasons)  ? Dev Blog Addition (Bold, prefixed by "New" emoji) moved to (Colour coded, moved to another slot) Suggested Addition (Bold, green)
Core
getData() getConstructMass() getConstructIMass() getConstructCrossSection() getMaxKinematicsParametersAlongAxis(taglist,crefaxis) getConstructWorldPos() getConstructId()  ? getConstructName()  ? getOrientationUnitId() getWorldAirFrictionAngularAcceleration() getWorldAirFrictionAcceleration() spawnNumberSticker(nb, x, y, z, orientation) spawnArrowSticker(x, y, z, orientation) deleteSticker(index) moveSticker(index, x, y, z) rotateSticker(index, angle_x, angle_y, angle_z) getElementIdList() getElementNameById(uid) getElementTypeById(uid) getElementHitPointsById(uid) getElementMaxHitPointsById(uid) getElementMassById(uid) getElementPositionById(uid) ? getElementForwardById(uid) ? getElementUpById(uid) ? getElementRightById(uid) getElementIndustryStatus(uid)* getElementTagsById(uid) getSchematicInfo(schematicId) getAltitude()  ? getCurrentPlanetId() g()** getWorldGravity()*** getWorldVertical()**** getAngularVelocity() getWorldAngularVelocity() getAngularAcceleration() getWorldAngularAcceleraton() getVelocity() getWorldVelocity()  ? getAbsoluteVelocity()  ? getWorldAbsoluteVelocity()***** getWorldAcceleration() getConstructWorldOrientationForward() getConstructWorldOrientationRight() getConstructWorldOrientationUp() getConstructOrientationForward() getConstructOrientationRight() getConstructOrientationUp() getPvPTimer() getPlayersOnBoard()****** getDockedConstructs()******* isPlayerBoarded(pid) isConstructDocked(pid) forceDeboard(pid) forceUndock(cid) getBoardedPlayerMass(pid) getDockedConstructMass(cid) getParent() getCloseParents() getClosestParents()  ? getParentPosition()  ? getParentWorldPosition()  ? getParentForward()  ? getParentUp()  ? getParentRight()  ? getParentWorldForward()  ? getParentWorldUp()  ? getParentWorldRight() dock(pid) undock() setDockingMode(mode) getDockingMode() getCoreStress() getMaxCoreStress() getCoreStressRatio() All Events *getElementIndustryStatus() -> getElementIndustryStatusById()
**g() -> getLocalConstructGravityIntensity()
***getWorldGravity() -> getConstructWorldGravity()
****getWorldVertical() -> getWorldGravity()
*****getWorldAbsoluteVelocity() -> getAbsoluteWorldVelocity()  (Swapping the Absolute Prefix with the World prefix sounds better and is probably more consistent)
******getBoardedPlayerIds()
*******getDockedConstructIds()
 
System
getActionKeyName(actionName) showScreen(bool) setScreen(content) createWidgetPanel(label) destroyWidgetPanel(panelId) createWidget(panelId, type) destroyWidget(widgetId) createData(dataJson) destroyData(dataId) updateData(dataId, dataJson) addDataToWidget(dataId, widgetId) removeDataFromWidget(dataId, widgetId) getMouseWheel() getMouseDeltaX() getMouseDeltaY() getMousePosX() getMousePosY() getThrottleInputFromMouseWheel() getControlDeviceForwardInput()* getControlDeviceYawInput() getControlDeviceRightLeftInput()** lockView(state) isViewLocked() freeze(bool) isFrozen() getTime() getActionUpdateDeltaTime() getPlayerName(pid) getPlayerWorldPos(pid)   ? getOrganizationName(oid)   ? getOrganizationTag(oid) getWaypointFromPlayerPos() setWaypoint(waypointStr) getScreenHeight() getScreenWidth() getFov() print(msg) logInfo(msg) logWarning(msg) logError(msg) All Events *getControlDeviceForwardInput ->getControlDevicePitchInput
**getControlDeviceRightLeftInput ->getControlDeviceRollInput
 
ControlUnit
exit() setTimer(timerTagId, period) stopTimer(timerTagId) getAtmosphereDensity() getClosestPlanetInfluence() ? getMasterPlayerPosition() ? getMasterPlayerWorldPosition() ? getMasterPlayerWorldForward() ? getMasterPlayerWorldUp() ? getMasterPlayerWorldRight() ? getMasterPlayerForward() ? getMasterPlayerUp() ? getMasterPlayerRight() getMasterPlayerId() getMasterPlayerMass() getMasterPlayerParent() ? getMasterPlayerOrgIds() setEngineCommand(...) setEngineThrust(taglist, thrust) setAxisCommandValue(axis, commandValue) getAxisCommandValue(axis) setupAxisCommandProperties(axis, commandType, targetSpeedRanges) setupControlMasterModeProperties(controlMasterModeId, displayName) getControlMasterModeId() cancelCurrentControlMasterMode() isAnyLandingGearExtended() extendLandingGears() retractLandingGears() isMouseControlActivated() isMouseDirectControlActivated() isMouseVirtualJoystickActivated() isAnyHeadlightSwitchedOn() switchOnHeadlights() switchOffHeadlights() isRemoteControlled() activateGroundEngineAltitudeStabilization(targetAltitude)* getSurfaceEngineAltitudeStabilization()* deactivateGroundEngineAltitudeStabilization()* computeGroundEngineAltitudeStabilizationCapabilities()* getThrottle() setSignalIn(plug, state) getSignalIn(plug) All Events *I got no idea what to replace those with, but the names are just weird, what's a surface engine, ground engine? Function name is super long.
 
Construct
getWorldOrientationForward() getWorldOrientationRight() getWorldOrientationUp() getOrientationForward() getOrientationRight() getOrientationUp()  getWorldPos() getId() ? getName() ? getOrientationUnitId() getMass() getIMass() getCrossSection() getLocalGravityIntensity()  
Elements
 getIdList() getNameById(uid) getTypeById(uid) getHitPointsById(uid) getMaxHitPointsById(uid) getMassById(uid) getPositionById(uid) ? getForwardById(uid) ? getUpById(uid) ? getRightById(uid) getIndustryStatusById(uid) getTagsById(uid) getElementById(uid)  
Player
getId() getMass() getParent() ? getOrgIds() lockView(state) isViewLocked() freeze(bool) isFrozen() getFov() getHorizontalFov(bool) getVerticalFov(bool) getHeadlampState() setHeadlampState(bool) isSeated() getSeatId() getCameraView() getCameraWorldForward() getCameraWorldUp() getCameraWorldRight() getCameraWorldPos() getCameraLocalForward() getCameraLocalUp() getCameraLocalRight() getCameraLocalPos() ? getBodyPosition() ? getBodyWorldPosition() ? getBodyWorldForward() ? getBodyWorldUp() ? getBodyWorldRight() ? getBodyForward() ? getBodyUp() ? getBodyRight()  
Database
 getPlayerName(pid) getPlayerWorldPos(pid) ? getOrganizationName(oid) ? getOrganizationTag(oid) getSchematicInfo(schematicId) getPlayerById(pid) getMasterPlayer() getOrganization(oid) getConstruct(cid)  
 
 
Camera Data Explanation
The camera data is pretty straight forward. I made an code example and explanation before this mess, I'll just paste that here lol.
 
local player = player --> A tab which virtually represents the "player", it holds player related events and functions. local isSeated = player.isSeated() --> Returns true or false if the player is seated or not. local seatId = player.getSeatId() --> Returns the player seat ID if seated, otherwise nil. local headlampState = player.getHeadlampState() --> Returns the boolean of the avatar headlamp, on or off. player.setHeadlampState(not headlampState) --> Inverts the headlamp state. local camView = player.getCameraView() --> Returns 0 for first-person, 1 for third-person and 2 for fixed third-person. -- Consideration to have is that you can get into third person while using the normal avatar using an emoji. -- Why it is useful is so you can change the HUD you intend on using depending on if you're in those seperate views and if you should listen to mouse input for UI, etc. local camWorldUp = player.getCameraWorldUp() --> Returns the camera up vector in world coodinates. local camWorldForward = player.getCameraWorldForward() --> Returns the camera forward vector in world coodinates. local camWorldRight = player.getCameraWorldRight() --> Returns the camera right vector in world coodinates. local camLocalUp = player.getCameraLocalUp() --> Returns the camera up vector in local coodinates, relative to the build grid. local camLocalForward = player.getCameraLocalForward() --> Returns the camera forward vector in local coodinates, relative to the build grid. local camLocalRight = player.getCameraLocalRight() --> Returns the camera right vector in local coodinates, relative to the build grid. local camLocalPos = player.getCameraLocalPos() --> Returns the camera position in local coordinates relative to the build-grid (construct) center. local camWorldPos = player.getCameraWorldPos() --> Returns the camera position in world coordiantes. --<! Optionally, you could add a relative world position function which is relative to the construct center, but in world coordinates. Though, I feel it would be very niche !>-- --- Lastly, local camHFov = player.getCameraHorizontalFov(true/false) --> Returns the horizontal fov with a boolean parameter to determine if it is returned as a radian or degree format. local camVFov = player.getCameraVerticalFov(true/false) --> Returns the vertical fov with a boolean parameter to determine if it is returned as a radian or degree format.  
 
Final Structure (No Formatting, mainly for glancing to see roughly the impact)
 
Core
getData() getMaxKinematicsParametersAlongAxis(taglist,crefaxis) getWorldAirFrictionAngularAcceleration() getWorldAirFrictionAcceleration() spawnNumberSticker(nb, x, y, z, orientation) spawnArrowSticker(x, y, z, orientation) deleteSticker(index) moveSticker(index, x, y, z) rotateSticker(index, angle_x, angle_y, angle_z) getAltitude()  getCurrentPlanetId() getConstructWorldGravity() getWorldGravity() getAngularVelocity() getWorldAngularVelocity() getAngularAcceleration() getWorldAngularAcceleraton() getVelocity() getWorldVelocity()  getAbsoluteVelocity() getAbsoluteWorldVelocity() getWorldAcceleration() getPvPTimer() getBoardedPlayerIds() getDockedConstructIds() isPlayerBoarded(pid) isConstructDocked(pid) forceDeboard(pid) forceUndock(cid) getBoardedPlayerMass(pid) getDockedConstructMass(cid) getParent() getCloseParents() getClosestParents() getParentPosition() getParentWorldPosition() getParentForward() getParentUp() getParentRight() getParentWorldForward() getParentWorldUp() getParentWorldRight() dock(pid) undock() setDockingMode(mode) getDockingMode() getCoreStress() getMaxCoreStress() getCoreStressRatio() All Events  
System
getActionKeyName(actionName) showScreen(bool) setScreen(content) createWidgetPanel(label) destroyWidgetPanel(panelId) createWidget(panelId, type) destroyWidget(widgetId) createData(dataJson) destroyData(dataId) updateData(dataId, dataJson) addDataToWidget(dataId, widgetId) removeDataFromWidget(dataId, widgetId) getMouseWheel() getMouseDeltaX() getMouseDeltaY() getMousePosX() getMousePosY() getThrottleInputFromMouseWheel() getControlDevicePitchInput() getControlDeviceYawInput() getControlDeviceRollInput() getTime() getActionUpdateDeltaTime() getWaypointFromPlayerPos() setWaypoint(waypointStr) getScreenHeight() getScreenWidth() print(msg) logInfo(msg) logWarning(msg) logError(msg) All Events  
ControlUnit
exit() setTimer(timerTagId, period) stopTimer(timerTagId) getAtmosphereDensity() getClosestPlanetInfluence() setEngineCommand(...) setEngineThrust(taglist, thrust) setAxisCommandValue(axis, commandValue) getAxisCommandValue(axis) setupAxisCommandProperties(axis, commandType, targetSpeedRanges) setupControlMasterModeProperties(controlMasterModeId, displayName) getControlMasterModeId() cancelCurrentControlMasterMode() isAnyLandingGearExtended() extendLandingGears() retractLandingGears() isMouseControlActivated() isMouseDirectControlActivated() isMouseVirtualJoystickActivated() isAnyHeadlightSwitchedOn() switchOnHeadlights() switchOffHeadlights() isRemoteControlled() activateGroundEngineAltitudeStabilization(targetAltitude) getSurfaceEngineAltitudeStabilization() deactivateGroundEngineAltitudeStabilization() computeGroundEngineAltitudeStabilizationCapabilities() getThrottle() setSignalIn(plug, state) getSignalIn(plug) All Events  
Construct
getWorldOrientationForward() getWorldOrientationRight() getWorldOrientationUp() getOrientationForward() getOrientationRight() getOrientationUp() getWorldPos() getId() getName() getOrientationUnitId() getMass() getIMass() getCrossSection() getLocalGravityIntensity()  
Elements
 getIdList() getNameById(uid) getTypeById(uid) getHitPointsById(uid) getMaxHitPointsById(uid) getMassById(uid) getPositionById(uid) getForwardById(uid) getUpById(uid) getRightById(uid) getIndustryStatusById(uid) getTagsById(uid) getElementById(uid)  
Player
getId() getMass() getParent() getOrgIds() lockView(state) isViewLocked() freeze(bool) isFrozen() getHorizontalFov(bool) getVerticalFov(bool) getHeadlampState() setHeadlampState(bool) isSeated() getSeatId() getCameraView() getCameraWorldForward() getCameraWorldUp() getCameraWorldRight() getCameraWorldPos() getCameraLocalForward() getCameraLocalUp() getCameraLocalRight() getCameraLocalPos() getBodyPosition() getBodyWorldPosition() getBodyWorldForward() getBodyWorldUp() getBodyWorldRight() getBodyForward() getBodyUp() getBodyRight()  
Database
getPlayerName(pid) getPlayerWorldPos(pid) getOrganizationName(oid) getOrganizationTag(oid) getSchematicInfo(schematicId) getPlayerById(pid) getMasterPlayer() getOrganization(oid) getConstruct(cid)  
 
 
Ending Notes
It has taken me literally the entire day doing this, and even then I feel like I've missed a lot because I was literally looking at the entirety of Lua.
I was planning on explaining all the changes and stuff, but my head is about to explode from doing this the entire day so not gonna. Lol.

Tbh, if they implemented even a single one of these slots, I would be happy. I don't expect most of it to change.
I would also, personally, like if these changes came out gradually, if any. I think if camera angles are added though, we must at least get the player slot, or similar global variable because of how long the variable names will end up getting.
 
Obligatory @NQ-Ligo and @NQ-Deckard, I wish you find this helpful, even if you don't add even 1% of it xD

Oh, and oops. Kinda broke the "one idea" rule... it's kinda a super idea though. Hope whoever od

We would like to thank each and every one of you who has taken the time to visit our Public Test Server (PTS) and that tried our new Athena update. A special thanks to those who were able to attend our Fools Defense PvP event on April 1st, we hope you enjoyed it!
 
We recognize a good number of players were unable to attend the PTS event due to other engagements. As with any test, we had to make sure that our development teams were able to actively monitor and be present as the event took place. Thanks to your participation though, we have been able to identify some areas in need of improvements or adjustments - and thanks to your feedback, we will be working on improving them.
 
In addition, we are excited to announce that we will be bringing the PTS up for a couple of additional days, before heading into the next portion of our PTS test for Athena.
 
ATHENA ON PTS - SCHEDULE
 
- Wednesday 6th April 13:00 UTC to Friday 8th 09:00 UTC
We have finished adding more of the late stage game items, such as the schematics for the new Relic Plasma Harvester and Space Mining Unit, along with the variants of elements that have been introduced. We have also applied some fixes for added performance and stability for players to test out.
 
- Friday 8th April 11:00 UTC to Monday 11st April 09:00 UTC
Moving into the second part of our planned PTS testing for Athena, we’ll be focusing on the First Time User Experience (FTUE) beginner introduction guide. More information on this will be released very soon, so keep your eyes open for the upcoming devblog with all the details!
In order to fully test the new FTUE, the PTS will be completely reset on Friday, April 8th (hence the two hours maintenance between the two sessions). Please note that said maintenance might be a bit longer. But once it is done, everyone that connects to the PTS will be able to experience the new FTUE in detail. Of course, there will still be dispenser towers providing many in-game items for free, so players are able to continue to test other features that they are interested in as well.
 
Regarding the FTUE itself, brace yourselves for an upcoming devblog on this topic! The FTUE devblog will be available by the end of this week, so keep on the lookout for it. There will be many details to help you get ready for the FTUE PTS session!

As always, we would like to remind players that this is a Public Test Server and as such, many unforeseen issues can arise; this can include performance and stability issues. In the event that issues do arise, we will do our best to remedy them as soon as possible.
 
Get out to the PTS and test when the time comes! We look forward to reading your feedback for our Athena update in our Forum thread here.
 

If all L cored ships where L sized, If all M core ships where M sized, if all S core ships where S sized.  I would agree.  But you can get a medium core ship that weighs 10KT, and you can get a Large core ship that weighs 1KT.  
 
Core size does not reflect ship size.  And this is something I said from day 1 when they added shields to PTS. Shield HP should be a multiple of voxel HP. 
 
Restricting L shields to L core only would be bad for the game. 

Hello Noveans,
 
We have released the Panacea update today, DU is now in version 0.28.0. The changes can be found below:
 
New Features
Vertex Precision Tool This is a new tool that will enhance the precise manipulation of the shapes of voxels by allowing a player to move the individual vertices. Home  sets the cursor to the currently-selected vertices position. End  resets the cursor to the last applied position. Alt + Home  sets the cursor to the centered 0, 0, 0 coordinates. X  toggles the grid display. Ctrl + Scroll  adjusts the grid size. The Arrow keys and Page Up/Down are used to move the cursor. The grid is not displayed for the smallest two grid sizes. Space wrecks Players will now be able to find randomly-spawned shipwrecks in space throughout Helios. There are five tiers of rarity, with lower-tier wrecks with low-value contents spawning at a higher frequency. The highest-tier wrecks will be harder to find; those who discover and harvest them will be rewarded with high-value materials and elements. Inactive Asset Requisitioning (IAR) This new system offers salvaging opportunities for active players. Inactive Assets When the subscription for an account is canceled and becomes inactive, a 90-day countdown timer begins on all the constructs owned by that account. Once those 90 days have passed, the construct is then abandoned. This also applies to constructs belonging to organizations, based on when the account of the last remaining legate becomes inactive after unsubscribing. These abandoned constructs can be claimed by any player or organization, just like any other abandoned construct. Constructs that have been abandoned for more than 30 days will be removed automatically. On Aphelia Territories Regardless of account activity, constructs parked on Aphelia territories will become subject to abandonment if not piloted for seven days. Constructs on Aphelia territories will be automatically removed if left in an abandoned state for longer than 48 hours. On Sanctuary Your constructs are safe on your territory. Aphelia territory rules still apply on Sanctuary Aphelia territories. Changes to organization construct ownership (construct slots) A new organization construct system has been introduced. The limit of constructs that can be owned  by an organization is now based on the lowest of two parameters: The organization’s legate with the highest level in the Organization Construct Management talents. The organization's slot count, which is assigned to the organization by players from a player’s available pool. Each player now has 10 base construct slots they can assign to any organization of their choosing. Added a new Organization Construct Slot Optimization talent increasing a player’s available organization construct slot count by three per level. Added a new Advanced Organization Construct Slot Optimization talent increasing a player’s available organization construct slot count by five per level. Added a new Improved Organization Construct Slot Optimization talent increasing a player’s available organization construct slot count by 10 per level. Base personal construct slot count increased from two to 10. Bonus from Core Unit Upgrades talent increased from two to three constructs per level. Bonus from Advanced Core Unit Upgrades talent increased from one to five constructs per level. Introduced new Improved Core Unit Upgrades talent for 10 constructs per level. Legate Organization Construct Management talents no longer grant direct construct capacity to the organization but provide a maximum limit on construct count in the organization. Talent points previously invested in these talents have received a one-time reset and are free to be spent once more. Organization Construct Management talent now increases the organization's maximum construct count by 25 per level. Organization Construct Management Specialization talent now increases the organization's maximum construct count by 75 per level. Advanced Organization Construct Management talent now increases the organization's maximum construct count by 225 per level. New UI for organizations allowing for insight into their construct slot availability and usage count as well as visibility on abandoned construct and slot allocation given by individual players to the organization. In a future update, organizations with constructs in excess of their capacity will receive an in-game warning during a bi-weekly construct check. If the organization doesn’t rectify the construct slot excess, random constructs belonging to that organization will be marked as  abandoned from the organization until the available slots and constructs are reconciled. Introduced new JSON export to clipboard buttons in the Organization Construct UI. RDMS UI polish The RDMS UI has undergone a pass for improvements and polish to bring them more inline with other interfaces. Dropdown elements are now removed from the dropdown when added to the list of selected elements.  Talent UI polish The Talent UI has undergone a pass for improvements and polish to bring them more inline with other interfaces. Added Talent search field. Added the option to hide completed talents. Collapse All and Expand All buttons added. Clear Queue button added. Camera Lua API Added Lua Camera API, under System: [event] system.cameraChanged([int] mode): Emitted when the player changes the camera mode. [number] system.getCameraHorizontalFov(): Return the current value of the player's horizontal field of view. [number] system.getCameraVerticalFov(): Return the current value of the player's vertical field of view. [int] system.getCameraMode(): Returns the active camera mode. [bool] system.isFirstPerson(): Checks if the active camera is in first person view. [vec3] system.getCameraPos(): Returns the position of the camera in construct local coordinates. [vec3] system.getCameraWorldPos(): Returns the position of the camera in world coordinates. [vec3] system.getCameraWorldForward(): Returns the forward direction vector of the active camera in world coordinates. [vec3] system.getCameraWorldRight(): Returns the right direction vector of the active camera in world coordinates. [vec3] system.getCameraWorldUp(): Returns the up direction vector of the active camera in world coordinates. [vec3] system.getCameraForward(): Returns the forward direction vector of the active camera in construct local coordinates. [vec3] system.getCameraRight(): Returns the right direction vector of the active camera in construct local coordinates. [vec3] system.getCameraUp(): Returns the up direction vector of the active camera in construct local coordinates. Added Lua Camera API, under Unit: [bool] unit.isMasterPlayerSeated(): Checks if the player currently running the control unit is seated. [int] getMasterPlayerSeatId(): Returns the UID of the seat on which the player currently running the control unit is sitting. Deprecated system.getFov() function to be renamed by getCameraHorizontalFov().  
Balancing
Abandoned construct core units can now only be replaced with new core units and can no longer be repaired with scrap. Base personal construct availability has been increased to 10. New organization construct slot has been added at a base level of 10.  
Talents
Existing talent changes: Bonus from Core Unit Upgrades talent increased from two to three constructs per level. Bonus from Advanced Core Unit Upgrades talent increased from one to five constructs per level. Organization Construct Management talent now increases the organization's maximum construct count by 25 per level. Organization Construct Management Specialization talent now increases the organization's maximum construct count by 75 per level. Advanced Organization Construct Management talent now increases the organization's maximum construct count by 225 per level. New talents added: Added new Surface Harvester talent group Added new Surface Harvesting Efficiency talent, decreasing surface harvesting time by 10% per level. Added new Improved Surface Harvesting Efficiency talent, decreasing surface harvesting time by 5% per level. Added new Surface Harvesting Optimization talent, increasing surface harvest output by 5% per level. Added new Improved Surface Harvesting Optimization talent, increasing surface harvest output by 3% per level. Added new Improved Core Unit Upgrades talent for 10 personal constructs per level. Added a new Organization Construct Slot Optimization talent increasing a players available organization construct slot count by three per level. Added a new Advanced Organization Construct Slot Optimization talent increasing a players available organization construct slot count by five per level. Added a new Improved Organization Construct Slot Optimization talent increasing a players available organization construct slot count by 10 per level.  
Improvements
Upon death, items in packages in inventory that should be preserved are now placed  in the inventory. [UI] Polished RDMS interface. [UI] Polished FTUE objectives. [UI] Hide basic controls reminder when empty. [UI] Added a basic controls reminder entry for the link tools Hold Ctrl input. [UI] Added error notifications for the Planet Smoothing tool. [UI] Cursor now displays "Asteroid" when looking at an asteroid. [UI] Added a notification when the Refuelling tool runs out of available fuel. [UI] Added a notification when the use of the Flattener tool is forbidden. [UI] Add Search inputs in the dropdown of marketplaces in the Market panel. [UI] Removed the switch button in the Market panel to switch between buy and sell orders. [UI] Added a better error message when dropping a non-munition into an ammunition container. [UI] Add Search inputs in the dropdown of the RDMS panel for tags, policies, and actors when there are more than 10. [SFX] Updated sound effects for harvesting tools. [Gameplay] Improved detection zone precision. [Gameplay] When you lock on a player, their position is now visible on the map. [Territory Scanner] Territory Scanner state is now persistent across all players and logging out. [Achievement] Added space between quanta amount and quanta symbol in achievement descriptions. [Talent UI] Added Search input to search talent and talent group by name or description. [Talent UI] Improved visual feedback on the Talent queue. [Talent UI] Added the auto-scroll when dragging a talent in from the Talent queue. [Talent UI] Modified talent level selection when there are few levels currently in the Training queue. [Talent UI] Selecting the Home button unselects the current selected talent and meta group. Added a setting to skip most of the transitions in calibration mini-game. (Checkbox bottom left on Pre-calibration page.) Calibration mini-game speed increased. (Faster probe move speed, faster action placement confirmation.) Allow industry units to run on inactive territories. Added "clear channel" & "copy channel content to clipboard" on chat channel context menu. [Lua] Completely removed following client log writing functions from Lua. logInfo() logWarning() logError() [Lua] Added sound Lua API, under System: playSound(filePath) : Play a sound file from your sound user folder. Only one sound can be played at a time. The audio files can be added to your user folder in “My Documents/NQ/DualUniverse/audio/” stopSound(): Stop the currently playing sound. Enabled mining unit laser sound impact again. In addition to unclaimed items, players can now use claimed items from the player account. Deploying construct (blueprint or core) and consuming a territory key for an organization is now gated by RDMS. (Standard members will no longer be able to deploy core/blueprint in the name of an organization without appropriate RDMS rights.) Renamed "Organization Wallet" preset tag to "Organization" tag. Added "Deploy or claim organization constructs" RDMS right for org. Description of the right: "Allows someone from the organization to deploy a construct or use a construct token in its name. (Policies including this right must use the 'Organization' tag).” [RDMS] Default sort by name when selecting a different registry. [RDMS] Removed element from the dropdown when it's added to the list during the update of an actor or a policy.  
Bug Fixes
[UI] Fixed missing avatar icon on friend list. [UI] Tooltips are now adapted to the limits of the screen. [UI] Fixed arrow position on some contextual menus. [UI] Fixed Ctrl+F9 hiding loading screens and menus. [UI] Fixed weapon reload dropdown in the gunner seat. [UI] Fixed missing notification when activating an ECU on a static core. [UI] Fixed long actor names preventing the removal of actors in the RDMS panel. [UI] Fixed the menu lists that have pagination sort by page instead of by list. [UI] Fixed links that were not always hidden when hovering out of an element. [UI] Fixed the fuel time remaining value in the piloting widgets, with a maximum of 24 hours. [UI] Fixed the pagination reset in the RDMS panel when a new tag or policy is created. [UI] Removed unnecessary fields (volume and mass) from the item inspector on construction tokens. [Voxels] Fixed an issue with the grid at LOD superior to 0. [Tools] Fixed links that could appear backward. [Tools] Fixed z-fighting on bidirectional links with the Link tool. [Tools] Line tool is now immediately red when used without material. [Gameplay] Fixed mining units that could be unexpectedly blocked. [Gameplay] Fixed moving multiple items at the same time in the ammo container refusing ammo. [Gameplay] Characters can no longer be stuck in a chair of a tokenized construct. [Lua] Fixed a consistency issue between getMasterPlayerWorldPosition() and getPlayerWorldPosition() which did not return the same position. They now return the position of the player's feet. [Tuto] Players are prevented from piloting a ship before being instructed to. [Tuto] Fixed RDMS tutorial highlight player navigation button. [Tuto] Market Tutorial: Fixed the teleporter allowing the player to complete the tutorial without completing objectives. [Settings] Fixed mouse sensitivity parameter in the settings panel. [Settings] Fixed error log message when sorting an empty table in the RDMS panel. [Rendering] Fixed volumetric clouds on OpenGL [Rendering] Fixed a rare issue where volumetric clouds could appear bright red. [Rendering] Fixed corrupt voxels on planets while terraforming in some locations. [Performance] Reduced framerate stuttering due to visual effect loading. Fixed a bug when creating a mission where visibility dropdown was not reset correctly. Fixed unclear error when creating a hauling mission with a destination container that could not contain the package. [Talent] Fixed meta groups icon position broken after the resize of the screen. [Talent] Level tooltip is updated when a talent level is updated. Fixed soft lock when closing “Edit” or “Create” market order. Fixed Talent group’s data tree collapsing after selection of a talent. Fixed radar widget hovering over detected construct buttons. Fixed a bug where opening the Crafting panel didn't collapse the recipe’s data tree. [RDMS] Fixed sorting of tables with pagination for actors, policies, rights, and tags. [PVP] Fixed radar scan results close to a safe zone border. Quantity of buy/sell market regular order is now displayed properly in the Wallet log. Fixed mining unit animation not launching on relogging. Fixed invalid “Small Market” displayed in market interface, existing market orders that were placed on the invalid “Small Market” have been moved to Alioth District 1 Market. Fixed bogus notifications about constructs on territories owned by someone else where the constructs didn't exist anymore.  
Exploit Fixes
Fixed an exploit with markets and sandboxed tutorials.  
Crash Fixes
Fixed a crash with the graphics option "Highlight frontiers on the map" when viewing Alioth Moon 1 or 4 on the map.  
Known Issues
It is not possible to control the volume of Lua sounds with Lua. This requires more work at the moment.  
Thank you all for your support!
- Deckard

So much noise..
 
In the end, NQ will tweak the number a bit and most of the tears will dry.. This was unavoidable and needed. Sucks for those who took advantage of what is clearly a broken part of the game and I get the frustration, but it needed to be done.

I can only hope NQ has enough of a spine to weather this storm of noise. They'll come out stronger and more prepared for launch on the other side, something quite a few seem to not understand.


But at the same time, they will just make the same mistakes again when it comes to the eventual power management. Communication is their Achilles heel.

Its a step. I dont know where yet, but a step. From what I gather, this will greatly push advantage to players with alts again though by making it all that bit more necessary if you want to have many cores. Im not particularly against it, but I would have loved a system based on active player effort instead.

Its a step. I dont know where yet, but a step. From what I gather, this will greatly push advantage to players with alts again though by making it all that bit more necessary if you want to have many cores. Im not particularly against it, but I would have loved a system based on active player effort instead.

Its a step. I dont know where yet, but a step. From what I gather, this will greatly push advantage to players with alts again though by making it all that bit more necessary if you want to have many cores. Im not particularly against it, but I would have loved a system based on active player effort instead.

Its a step. I dont know where yet, but a step. From what I gather, this will greatly push advantage to players with alts again though by making it all that bit more necessary if you want to have many cores. Im not particularly against it, but I would have loved a system based on active player effort instead.

Its a step. I dont know where yet, but a step. From what I gather, this will greatly push advantage to players with alts again though by making it all that bit more necessary if you want to have many cores. Im not particularly against it, but I would have loved a system based on active player effort instead.

I really really love this, it is basically everything I wished for. Gonna be a bit confusing calculating exact angles at first with some of the stepping, but I think we are gonna be fine.

I really really love this, it is basically everything I wished for. Gonna be a bit confusing calculating exact angles at first with some of the stepping, but I think we are gonna be fine.

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

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

Greeting Noveans. Let us know what you think about our latest devblog, Precision in Building!

This is gonna be a long one. Skip to the end for tl;dr.
 
Introduction
Territory Warfare in Dual Universe has to happen at some point. Cool, I'm here to talk about everything but the act of warfaring over territory. One of the "complaints" that some players mentioned is the lack of reason for war once Territory Warfare would arrive. This is what I am trying to address here with my idea.
 
Territory Claim vs Tile Ownership
First of all, I suggest splitting tile ownership from territory claims. I legitimately think this is a necessity. Not only are planets and moons too big to actually own it all, but having to own the tiles directly, taxes and all, would greatly inhibit the aspect of waging war. Reality does not have a cost associated with claiming some plot of land as territory (other than conflicts over it), so it should not be for DU either.
 
This means that some lonely industrialist could own a tile that changes territory claim ownership, and possibly would not notice a difference. However. this does not mean the nation should not be able to take ownership either. My suggestion is as followed:
A Nation owns territory claim A Nation can seize tiles, but not own them directly A Nation can decide a new owner for a tile This could be limited in some ways or carry a cost for the nation An approach like this would allow for vastly different ideologies between nations and a result of loyalty or indifference for actual tile owners. It would also foster possible ways to "force" loyalty by asking for assistance when trying to take over territory, or "else".

"But what would a territory be for then?" Tiles have taxes, right? Those might as well go to the occupying nation. Whether this happens fully, or partially can be up for debate. Yes, unowned tiles are not mentioned, see next chapter.
 
Reasons to have Territory
With territory claims and tile ownership split, what is the point of claiming unowned tiles?
For this I suggest a couple of things.
 
1. A nation should be allowed to assign tiles as nation specific safezone, based on a value related to territory claim, holding time and possibly other metrics.
Such a safezone should be restricted to non-border tiles only and have a limited number The nation should be able to assign who this safezone applies to Assigning a safezone should have a cooldown or carry a substantial cost This must be transparent to every player playing the game, by looking it up on the map
2. Nations should have a set of policies that can be chosen and improved.
Policies could be inspired by strategy games Imagine stuff like "Robust Building" which could increase health of all items produced in the nation, at a slightly higher resource cost Should not be free of course
3. The strategic aspect of creating a bridge to an enemy nation.
A nation shouldn't be able to attack another nation unless tiles are adjacent As a solution to planet wide warfare: footholds A foothold would be a tile or group of tiles by a nation away from the big national blob "capital" that is held for long enough. This would allow srategic invasion preparation of nations across planets but also take time and preparation Adjacency rules apply to footholds as well and they can be "destroyed" After some conditions are met, the "capital" tile could movbe to a sufficiently big foothold, at a price of cost/time or both  
Not a Nation for Everyone
So, lets assume a nation has a big territory, and some policies should not apply to the whole nation. There are reasons why one would want to subdivide a nation into zones.
A zone could be named and be an arbitrary shape based on tiles inside the territory A policy can apply to a zone or nation wide. Zone specific policies would overwrite nation wide policies. Implementing a policy has to cost time/currency/asset for every implementation of the nation. So while zones allow policy specialisation per region, the policy cost to make it worthwhile compounds per policy implemented across the nation Only one policy ber zone  
"Okay, this might be neat if its given more thought, but what about membership?"
This is where opinions might vary a lot. I legitimately think that an organisation must not be a member of a nation. Yes, you read that right.
A nation has citizens and organisations are not. Sure, there might be a Madistani organisation that happens to have 100% Madistani citizens, but the members voluntarily chose to be Madistani at some point and were not forced to be by the organisation.
Additionally, it should not be possible to change nations at will.
Once you join a nation, you can forfeit citizenship, but then youre bound to have no citizenship for a while. Another nation might accept you earlier, but only as refugee/immigrant, which doesn't give voting rights  
The Govern(mental)
This is where a lot of leg work would have to be done to make the implementation by NQ a smart one. As we already know, organisations themselves are fairly restrictive when it comes to roles and hierarchies. This is an absolute no-go for a nation and possible government structures. My hope/dream would be a diagramm based "coding" of voting processes and government structures. This is no easy feat and would have to allow for democracy of various kinds, monarchy, dictatorships, and everything inbetween. Some of it should be malleable, but only when the conditions, as defined by the nation founding, are met. (This almost sounds like duties of the RDMS...).
 
For example, let us take direct democracy with a minimum amount of representatives. It should be possible to assign enough representatives, for example per active zone, x amount per active zone, etc. However, every citizen has a vote when it comes to deciding matters, policies etc. Representatives would not be able to execute them unless the condition is fulfilled: enough people voted for it. They might however be able to suggest what is being voted on and are being voted on come election time. The election process would also have to be definable. Ultimately, the purpose of such a system is to do the enforcement of the government as it is supposed to be.
 
Of course, this is only my proposal and we could also go into metagaming and simply do it the way we handle organisations outside the game. But this removes some of the fun and participation as well as transparency for citizens and ultimately leaves enforcement to nobody.
 
Planetary Domination
So a nation managed to dominate the planet:
Do we want this to be legitimized by the game? What should this look like? Planetary taxes? Planetary policies? Interplanetary warfare? Intersystem warfare? Intergalactic warfare? At this point we reach a point of strategy that can probably wait a while until more important stuff is implemented.
 
TLDR:
Introduce Nations as separate thing from organisations Split tile ownership and territory claim Nations should be able to claim territory without needing to touch tile ownership, but they should be able to if they want Allow creation of nation specific safezone that is configurable for who it affects (other nations, players without nationality, etc.). Border tiles would not be eligible. Policies assigned and improved by the nation Zoning of the territory for several policies and possibly other stuff (names for example, geography, etc) Territory should *usually* be connected together. However, a foothold system is necessary. Think colonisation, but near the enemy territory as possible forward base, or otherwise. One capital per nation. Losing a capital is *bad* Organisations cannot be citizens. Only players can be citizens and organisations can have members of various nations. Nation membership isnt decided willy nilly, it needs a proper membership procedure with immigration/refuge. Yes, this would become an ingame racism simulator. System of the government should be "codable": customizable enough to allow everything conceivable. From dictatorship to direct democracy, we should have it all. I think these need to be discussed and clear before we talk how war is waged.  
 
 
This is by far not everything and I am sure I forgot something I already discussed before on the discord.

I really hope there will be a good solution for data export.
Several projects in the community depend on that.
 
We in our org built in months of work a whole own economy system.
Members can store their ores in our ore deposit, they get "HC" (our own currency) in exchange, and can use these HC in the fully automated shopping center to buy nearly any item for a cheap and steady price (what is important especially for new players). Our players can transfer their HC to other members, or can use them to order something from our industry department (if its not in the shopping center, or a really large order). This system works well and is a great addition and an advanced community creation. (If you are interested, check this video: Hyperion Warehouse and HC-System it's German and not 100% up to date, but you can understand most of the content just with the visuals)
 
And there are many more complex systems like this from other orgs and players, that rely on sync with external databases, because the DBs in the game are too small to handle this.
 
All of these advanced scripted community creations would be lost if there is no proper and easy way to export the data anymore.
If we are restricted to just the ingame DBs, this will kill massive creativity in scripting because of the limitations.

This is my first post on the forums, so forgive me if my formatting is off or I posted in the wrong place. TL;DR Included but please read the post.
 
Hi All,
 
Over the past year, I have mainly been a builder and creator. For the longest time, this has been my only source of income and as so, I have plenty of experience with the DU building system. I had a few ideas on the Quality of Life improvements for building in Dual Universe that would make everyone's life just that little bit easier, and so I want to post them here to be discussed. For every idea, I will outline what it is and why it is needed. Building is the best part of DU and it should not be forgotten about. Please feel free to discuss and reply!
 

Selection Zones - Suggestion 1
We all know that the size of the zone we can select is limited by size. While this is annoying most of the time, I'm fairly sure it is there as a technical limitation of the build mode. However, some improvements are warranted (mainly to voxel selection/placement tools):

What:
- Do not let us select a larger area than is possible. I have spent many a time trying to find the maximum selection size or over estimated the max selection size when building, making the entire selection area red with the only fix being to re-select the area again.

- If possible, increase the size of the selection area.
 
Why:
- This saves us time and effort, as, if I wanted to select the largest area possible, I could just click to a corner and the system will automatically select the most volume that it can. I will no longer see a "selection size area is too large" message, saving me time in finding the max selection size. This can also be a toggle if people find it necessary

- Convenience and makes building mirrored areas on L/M cores much easier.
 
 
Mirroring - Suggestion 2
The pain of having to perfectly line up elements on the other side by remembering / writing down element positions or copy/pasting voxels in little bits on an L or M core is all too known. I propose we are given two things: 

What:
- A mirror mode or a mirror tool, that would place the selected element on the other axis facing the same way. Could also group elements together, so that when one moves, the other mirrors this movement along an axis.
 
- A mirror axis (or multiple) that automatically places any voxels onto the other side (if you've ever played Space Engineers you know what I'm talking about). 

Why:
- Speed up the process of placing elements and thereby speed up the process of building by removing the need to memorize locations of elements. 
 
- Incredibly increase the speed of building mirrored constructs or large sizes, as the largest time waste is copy-pasting bits of an M or L core around from one side to the other every time one side is updated. 
 

Painting - Suggestion 3
Replacing voxels in order to change the look or material type of a ship's armor has always been a pain. For one, it wipes out complex patterns unless it is done perfectly and is, at least in my opinion, the biggest obstacle to the ability of individual creators to release multiple paint schemes of ships larger than an M core at an efficient rate. To remove the pain in re-painting a ship, I propose the following:

What:
- Allow me to replace certain types of voxel with another type of voxel with a single right-click option. I see this working as follows: Select an Area > Right click > Replace Voxel> Select Voxel X (to be replaced) > Select Voxel Y (to replace with). There most likely are other  more efficient ways of doing this but this is the most basic I could see.

- Could limit the suggestion above only to the same materials, aka can only replace steel with steel or aluminium with aluminium.
 
Why:
- I, and many others, have spent hours replacing complex patterns on our ships just to end up not liking the new  colour scheme and starting again. Not only that, when voxels are replaced currently, it creates a multitude of voxel errors and wipes any complex patterns that are then a pain to replicate. This change would allow for much quicker colour scheme changes and make it convenient to change colour.

- This change would be kept to keep actual armoring work (say for a pvp ship in a changing meta) as a time-consuming thing that is rewarded with gains in PvP.


Destroying/Removing Voxels - Suggestion 4
Just yesterday, I have spent around 30 minutes trying to find 0.14 cubic meters of luminescent glass on my ships which were invisible. I had to select a max size voxel cube and alt-paste it around until I got the last bits of the glass. This is an area that could be improved as nobody should have to spend hours finding one micro voxel in their construct in order to get back the core. I propose the following straight-forward solution:

What:
- Allow the option to remove the last big of voxels from a construct with a simple right click. For example, if the core has less than say 5m^3 (value could be changed or different with core size) of voxels left, one could right click the core in build mode Right Click > Remove Remaining Voxels. This would only work if the voxel volume is low to keep the work associated with actually disassembling a ship.

- Add the ability to change the last little bits of a voxel to another type, say I have a ship made from Voxel X, Y and Z, but Z is only 0.1m^3 and I can't for the life of me find where it is. I should be able to just right click the core and remove/replace it with another voxel.

Why:
- This saves innumerable hours for everyone in the game, as I can guarantee I'm not the only one who spent hours trying to find tiny voxels on an L core only to give up and abandon something worth half a million quanta. This change should have been available from the start.

- This change allows builders to clean up their blueprints and not make someone get 15 types of voxels just because there's 0.1m^3 of each in an L core blueprint.


Copy Paste Changes - Suggestion 5
Copy-Pasting was improved so much when the ability to change paste priority was introduced by pressing SHIFT when pasting. The change I'm proposing is minor, but still important when one is working with low quantities of voxels. Currently, if you need to paste , say, 10 cubic meters of a voxel but they are spread over a large area, you will need up to 300 cubic meters of voxel to paste it anywhere, because the system calculated the area of the selection and not the actual amount of voxels in the area.

What:
- Change the calculation of copy-paste voxel amounts so you need the exact amount of voxels that you are pasting instead of the entire selection area. 

Why:
- Allows builders to work with less amounts of honeycomb and makes life easier. Also helps when working with expensive honeycomb or limited supply, as you can use it to a more efficient degree.
 

Element Blocking - Suggestion 6
I have seen many times my elements were being blocked. Through scrolling through the element list I could see how much they were blocked, but it was time consuming. However, I could only guess as to what exactly was blocking them. Would be nice if you could tell what is doing the blocking.

What:
- Highlight the elements that are blocking the element in question or highlight the area that the voxels that block said element occupy.

- Allow to mouse over the element to tell how much it is being blocked by instead of scrolling through a menu at the top of build mode.

Why:
- Allows builders to quickly tell why their creations are being blocked instead of guessing and constantly changing voxels to fix a problem they can never know the true cause of.

- QOL change that exists for saving time when building.


DRM Change- Suggestion 7
What:
- Please enable DRM protection on constructs by default. Why is this even turned off in the first place?

Why:
- Allows new builders and experienced ones not to lose ownership of their constructs and scripts because of a simple oversight.
 
 
Element Talents - Suggestion 8
I, like many players, have wondered what exact talents are currently affecting my elements. The only workaround as of right now is doing the annoying math to sort-of get the right value. Currently, there is no way to tell what element has what exact talents affecting it as you can in the industry view.

What:
- Allow the option to either mouse over an element with a tool and see all the talents affecting it and their rank, or, Right Click Element> Show Effective Talents on Element

- Ability to remove all talents from an Element via right click or the ability to remove all talents from ALL elements.

Why:
- Allows ship builders or industry builders to quickly tell if their elements could use boosting with higher level place-down talents or if they are maximized. Also allows to see if all elements have the same talents, although this is not so much of a problem with the apply all talents button that we have now.

- Allows shipbuilders to gauge the performance of their ships as someone who does not have any piloting skills and build for those people. Currently, you need an alt or be in VR to do this.

 
CSS View - Suggestion 9
The CCS is a big part of building a PVP ship. Perhaps not in the current Meta that we have know, but in case it gets buffed it will be very important. I propose the following:

What:
- Ability to see the CCS value of a ship in the build mode when building a ship.

Why:
- This change will allow ship builders to gauge the performance of their ships without having to rely on Excel or other external tools.
 

Element Preview - Suggestion 10
Elements conduct the vast majority of voxel sizing and other dimensions. Most creators work either around or with elements that are in their builds. It would be great if we could see the size/outline of an element without actually having it.

What:
- Ability to select any element in game and place it in the construct as a "hologram". This hologram would only show the size of the element, so that a creator can plan ahead and work with elements they may not have (for example, L AGG). 

Why:
- This allows creators to plan ahead and construct their voxels around elements that they may not have at the exact moment, saving time and effort on everyone's part.


Blueprint Preview - Suggestion 11
Blueprint deployment is one of the many things my customers encounter and find problematic for many reasons. For once, static blueprints can be placed in the wrong orientation and once placed cannot be moved. Additionally, the same situation can be applied to dynamic blueprints when using them as statues or ornaments. 

What:
- Blueprints should not be displayed as a transparent cube right before deployment but as an approximate hologram of the final structure/ship. Even if the extra calculations on the client-side will take time, this should still be prioritised.

Why:
- This will allow players to properly foresee the structure and alignment of the blueprint that they are placing and not have to spend 20 minutes of their time dismantling the structure if they place it in the wrong orientation without knowing (and then flying back to buy another, losing precious quanta and time). This feature will make creating cities and bases with precision made from other people's creations a lot easier for everyone.


Blueprint Alignment- Suggestion 12
Stacking static blueprints together has always been painful for everyone. Having to fight the curvature of the earth and even the fact that the blueprint outline is not the same size as the outline of the core building area has been a significant barrier to many players' ability to build cities and bases in an orderly fashion. Personally, I wish this feature would be around now so I can continue work on the MTI City Project for my organization.

What:
- Aligning blueprints together with other deployed cores should be made easier. There should be options to align it in the centre of the core its being placed on and align it either with the orientation of the or the curvature of the planet at the place.
- Additional tools to align blueprints and be able to see the build area around the new blueprint before it is placed.
- Ability to use a blueprint on an EXISTING empty core to place the elements and voxels around it automatically while retaining the DRM rights of the BP creator. (alternative but easier-to-implement option)

Why:
- This change will allow the precise building of blueprints onto other cores and their alignment that much easier for every player in the game, not only those building cities. This results in cleaner looks of bases and more orderly placement of cores.


Core Alignment- Suggestion 13
Every organization and practically every player has encountered the pain of aligning multiple static or space cores in a fashion that allows for grid structures, be it for bases, airports, cities or space stations. Currently the process involves moving a lot of cores around with CTRL+Arrow and then building voxels to the edges of the cores. Note that such a process doesn't even guarantee similar alignment of cores in terms of their direction (for static cores)

What:
- Ability to align cores next to each other automatically or only through several clicks. Either by right clicking on a static core and selecting "Attach Static Core" or another method.
- Ability to select core alignment and ensure it is in the same direction to allow building of core grids much easier.

Why:
- This will allow players to properly place static/space core grids and not have to spend 20 minutes of their time re-aligning the core if they place it in the wrong orientation without knowing. This feature will make creating cities and bases easier due to the simplified way of aligning core grids (and save lots of time)


And that's it! Please reply to this post if you like the changes and if you think they should or should not be added to the game. Lets hope NQ sees this and implements some of the ideas (please just implement them all and save us all so much pain). I personally think these changes will make the life of many people so much easier and will encourage more people to enjoy the building aspect of this game - the strongest aspect of it as of right now.

Stay safe out there,
Koriandah.

TL;DR:
- Bigger / more manageable selection zones
- Mirror tools like axis mirroring and element mirroring
- Painting tools to easily replace voxels and keep their complex shapes
- Tools to easily remove the last pesky micro voxels from construct
- Copy paste required voxel quantity optimization
- Element blocking info, what is blocking said elements and how much
- DRM enabled by default
- Show talents on elements, ability to remove all talents
- CCS View
- Element Preview
- Blueprint Preview
- Blueprint Alignment
- Core Alignment