NQ-Deckard

Hello Noveans,

It has recently come to our attention that a number of static constructs have been deployed at an altitude above what we previously had defined as the vertical limit of around 1000m.  At this time we are unsure why this limit is not being applied as intended, and we are currently investigating this issue in order to resolve this.

As we are revisiting this limit while it is not currently functioning, we will be exploring our options to implement a more adjustable approach in order to have different limits for different planets. If successful we will also eventually be including this value at a later date in the shipped atlas.lua file, allowing Lua control units to also read this value for each planet and use it to fly above static constructs.

Why are you stifling my dream of building a tower that connects a moon to a planet!?
We also want to be clear about the reason for this limit, it is not here to stifle your dreams of building large towers and structures made of multiple static constructs. It is here, so we can ensure a reasonably safe boundary layer for atmospheric flight by all our players without the concern of encountering a random building in your flightpath while flying at high speeds. Chances are, the build limits will likely be slightly more accommodating than the previous system and allow for slightly more building height in the end, this however remains to be seen.

So what about the existing constructs that are not adhering to this restriction?
Well, as we are unsure why this build limit suddenly deactivated and we are refining it anyway. We will allow these constructs to remain for two weeks beyond the implementation of the new height restriction system. Two weeks after the new restrictions are in place, we will begin removing  or moving any static constructs beyond the defined altitude limit of each planet to ensure they are not inside the boundary layer. Keep an eye on the upcoming change logs for a list of the altitudes for each planet.

I hope this clears up any and all confusion on the topic, and thank you all for reading.
- NQ-Deckard

Hello Noveans,

It has recently come to our attention that a number of static constructs have been deployed at an altitude above what we previously had defined as the vertical limit of around 1000m.  At this time we are unsure why this limit is not being applied as intended, and we are currently investigating this issue in order to resolve this.

As we are revisiting this limit while it is not currently functioning, we will be exploring our options to implement a more adjustable approach in order to have different limits for different planets. If successful we will also eventually be including this value at a later date in the shipped atlas.lua file, allowing Lua control units to also read this value for each planet and use it to fly above static constructs.

Why are you stifling my dream of building a tower that connects a moon to a planet!?
We also want to be clear about the reason for this limit, it is not here to stifle your dreams of building large towers and structures made of multiple static constructs. It is here, so we can ensure a reasonably safe boundary layer for atmospheric flight by all our players without the concern of encountering a random building in your flightpath while flying at high speeds. Chances are, the build limits will likely be slightly more accommodating than the previous system and allow for slightly more building height in the end, this however remains to be seen.

So what about the existing constructs that are not adhering to this restriction?
Well, as we are unsure why this build limit suddenly deactivated and we are refining it anyway. We will allow these constructs to remain for two weeks beyond the implementation of the new height restriction system. Two weeks after the new restrictions are in place, we will begin removing  or moving any static constructs beyond the defined altitude limit of each planet to ensure they are not inside the boundary layer. Keep an eye on the upcoming change logs for a list of the altitudes for each planet.

I hope this clears up any and all confusion on the topic, and thank you all for reading.
- NQ-Deckard

Hello Noveans,

It has recently come to our attention that a number of static constructs have been deployed at an altitude above what we previously had defined as the vertical limit of around 1000m.  At this time we are unsure why this limit is not being applied as intended, and we are currently investigating this issue in order to resolve this.

As we are revisiting this limit while it is not currently functioning, we will be exploring our options to implement a more adjustable approach in order to have different limits for different planets. If successful we will also eventually be including this value at a later date in the shipped atlas.lua file, allowing Lua control units to also read this value for each planet and use it to fly above static constructs.

Why are you stifling my dream of building a tower that connects a moon to a planet!?
We also want to be clear about the reason for this limit, it is not here to stifle your dreams of building large towers and structures made of multiple static constructs. It is here, so we can ensure a reasonably safe boundary layer for atmospheric flight by all our players without the concern of encountering a random building in your flightpath while flying at high speeds. Chances are, the build limits will likely be slightly more accommodating than the previous system and allow for slightly more building height in the end, this however remains to be seen.

So what about the existing constructs that are not adhering to this restriction?
Well, as we are unsure why this build limit suddenly deactivated and we are refining it anyway. We will allow these constructs to remain for two weeks beyond the implementation of the new height restriction system. Two weeks after the new restrictions are in place, we will begin removing  or moving any static constructs beyond the defined altitude limit of each planet to ensure they are not inside the boundary layer. Keep an eye on the upcoming change logs for a list of the altitudes for each planet.

I hope this clears up any and all confusion on the topic, and thank you all for reading.
- NQ-Deckard

Hello Noveans,

It has recently come to our attention that a number of static constructs have been deployed at an altitude above what we previously had defined as the vertical limit of around 1000m.  At this time we are unsure why this limit is not being applied as intended, and we are currently investigating this issue in order to resolve this.

As we are revisiting this limit while it is not currently functioning, we will be exploring our options to implement a more adjustable approach in order to have different limits for different planets. If successful we will also eventually be including this value at a later date in the shipped atlas.lua file, allowing Lua control units to also read this value for each planet and use it to fly above static constructs.

Why are you stifling my dream of building a tower that connects a moon to a planet!?
We also want to be clear about the reason for this limit, it is not here to stifle your dreams of building large towers and structures made of multiple static constructs. It is here, so we can ensure a reasonably safe boundary layer for atmospheric flight by all our players without the concern of encountering a random building in your flightpath while flying at high speeds. Chances are, the build limits will likely be slightly more accommodating than the previous system and allow for slightly more building height in the end, this however remains to be seen.

So what about the existing constructs that are not adhering to this restriction?
Well, as we are unsure why this build limit suddenly deactivated and we are refining it anyway. We will allow these constructs to remain for two weeks beyond the implementation of the new height restriction system. Two weeks after the new restrictions are in place, we will begin removing  or moving any static constructs beyond the defined altitude limit of each planet to ensure they are not inside the boundary layer. Keep an eye on the upcoming change logs for a list of the altitudes for each planet.

I hope this clears up any and all confusion on the topic, and thank you all for reading.
- NQ-Deckard

Hello Noveans,

It has recently come to our attention that a number of static constructs have been deployed at an altitude above what we previously had defined as the vertical limit of around 1000m.  At this time we are unsure why this limit is not being applied as intended, and we are currently investigating this issue in order to resolve this.

As we are revisiting this limit while it is not currently functioning, we will be exploring our options to implement a more adjustable approach in order to have different limits for different planets. If successful we will also eventually be including this value at a later date in the shipped atlas.lua file, allowing Lua control units to also read this value for each planet and use it to fly above static constructs.

Why are you stifling my dream of building a tower that connects a moon to a planet!?
We also want to be clear about the reason for this limit, it is not here to stifle your dreams of building large towers and structures made of multiple static constructs. It is here, so we can ensure a reasonably safe boundary layer for atmospheric flight by all our players without the concern of encountering a random building in your flightpath while flying at high speeds. Chances are, the build limits will likely be slightly more accommodating than the previous system and allow for slightly more building height in the end, this however remains to be seen.

So what about the existing constructs that are not adhering to this restriction?
Well, as we are unsure why this build limit suddenly deactivated and we are refining it anyway. We will allow these constructs to remain for two weeks beyond the implementation of the new height restriction system. Two weeks after the new restrictions are in place, we will begin removing  or moving any static constructs beyond the defined altitude limit of each planet to ensure they are not inside the boundary layer. Keep an eye on the upcoming change logs for a list of the altitudes for each planet.

I hope this clears up any and all confusion on the topic, and thank you all for reading.
- NQ-Deckard

Hello Noveans,

It has recently come to our attention that a number of static constructs have been deployed at an altitude above what we previously had defined as the vertical limit of around 1000m.  At this time we are unsure why this limit is not being applied as intended, and we are currently investigating this issue in order to resolve this.

As we are revisiting this limit while it is not currently functioning, we will be exploring our options to implement a more adjustable approach in order to have different limits for different planets. If successful we will also eventually be including this value at a later date in the shipped atlas.lua file, allowing Lua control units to also read this value for each planet and use it to fly above static constructs.

Why are you stifling my dream of building a tower that connects a moon to a planet!?
We also want to be clear about the reason for this limit, it is not here to stifle your dreams of building large towers and structures made of multiple static constructs. It is here, so we can ensure a reasonably safe boundary layer for atmospheric flight by all our players without the concern of encountering a random building in your flightpath while flying at high speeds. Chances are, the build limits will likely be slightly more accommodating than the previous system and allow for slightly more building height in the end, this however remains to be seen.

So what about the existing constructs that are not adhering to this restriction?
Well, as we are unsure why this build limit suddenly deactivated and we are refining it anyway. We will allow these constructs to remain for two weeks beyond the implementation of the new height restriction system. Two weeks after the new restrictions are in place, we will begin removing  or moving any static constructs beyond the defined altitude limit of each planet to ensure they are not inside the boundary layer. Keep an eye on the upcoming change logs for a list of the altitudes for each planet.

I hope this clears up any and all confusion on the topic, and thank you all for reading.
- NQ-Deckard

Hello Noveans,

It has recently come to our attention that a number of static constructs have been deployed at an altitude above what we previously had defined as the vertical limit of around 1000m.  At this time we are unsure why this limit is not being applied as intended, and we are currently investigating this issue in order to resolve this.

As we are revisiting this limit while it is not currently functioning, we will be exploring our options to implement a more adjustable approach in order to have different limits for different planets. If successful we will also eventually be including this value at a later date in the shipped atlas.lua file, allowing Lua control units to also read this value for each planet and use it to fly above static constructs.

Why are you stifling my dream of building a tower that connects a moon to a planet!?
We also want to be clear about the reason for this limit, it is not here to stifle your dreams of building large towers and structures made of multiple static constructs. It is here, so we can ensure a reasonably safe boundary layer for atmospheric flight by all our players without the concern of encountering a random building in your flightpath while flying at high speeds. Chances are, the build limits will likely be slightly more accommodating than the previous system and allow for slightly more building height in the end, this however remains to be seen.

So what about the existing constructs that are not adhering to this restriction?
Well, as we are unsure why this build limit suddenly deactivated and we are refining it anyway. We will allow these constructs to remain for two weeks beyond the implementation of the new height restriction system. Two weeks after the new restrictions are in place, we will begin removing  or moving any static constructs beyond the defined altitude limit of each planet to ensure they are not inside the boundary layer. Keep an eye on the upcoming change logs for a list of the altitudes for each planet.

I hope this clears up any and all confusion on the topic, and thank you all for reading.
- NQ-Deckard

Hello Noveans,

It has recently come to our attention that a number of static constructs have been deployed at an altitude above what we previously had defined as the vertical limit of around 1000m.  At this time we are unsure why this limit is not being applied as intended, and we are currently investigating this issue in order to resolve this.

As we are revisiting this limit while it is not currently functioning, we will be exploring our options to implement a more adjustable approach in order to have different limits for different planets. If successful we will also eventually be including this value at a later date in the shipped atlas.lua file, allowing Lua control units to also read this value for each planet and use it to fly above static constructs.

Why are you stifling my dream of building a tower that connects a moon to a planet!?
We also want to be clear about the reason for this limit, it is not here to stifle your dreams of building large towers and structures made of multiple static constructs. It is here, so we can ensure a reasonably safe boundary layer for atmospheric flight by all our players without the concern of encountering a random building in your flightpath while flying at high speeds. Chances are, the build limits will likely be slightly more accommodating than the previous system and allow for slightly more building height in the end, this however remains to be seen.

So what about the existing constructs that are not adhering to this restriction?
Well, as we are unsure why this build limit suddenly deactivated and we are refining it anyway. We will allow these constructs to remain for two weeks beyond the implementation of the new height restriction system. Two weeks after the new restrictions are in place, we will begin removing  or moving any static constructs beyond the defined altitude limit of each planet to ensure they are not inside the boundary layer. Keep an eye on the upcoming change logs for a list of the altitudes for each planet.

I hope this clears up any and all confusion on the topic, and thank you all for reading.
- NQ-Deckard

Hello Noveans,
 
We have deployed a number of hot fixes this morning, Dual Universe is now in Version 1.0.2.
The change log can be found here: https://www.dualuniverse.game/launcher/patch/release-102
 
Thank you all for your support!

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

Hello Noveans,
 
We have released hotfix today, DU is now in version 0.29.5 the changes can be found below:
 
Improvements
[UI] Achievement unlocked centered notification is now in front of most panels.
Bug Fixes
Fixed speeder step that failed to deploy (“speeder too far”). Fixed Force respawning during landing that locked the player. Fixed elevators that wouldn’t work underwater.
[UI] Fixed sorting not working on the territory tab in the wallet panel.  
Thank you all for your support!
- Deckard

Hello Noveans,
 
We have released the Athena update today, DU is now in version 0.29.4. The changes can be found below:
 
New Features
Brand new first time user experience (FTUE). Haven, a new sanctuary, has been added near Alioth. It has shuttle connections to the Pioneer Zone on Alioth and to Sanctuary. New players will choose their starting territory on Haven, then land there. A quick onboarding tutorial takes place after landing. New players choose from 10 starting outposts and 4 different speeders, which they deploy during the onboarding tutorial. Space territory control (Space Warfare) New alien space cores have been introduced which are claimable by players but not retrievable or removable. The alien space cores allow players to gather new plasma resources which are used for high-tier industry and manufacturing. Base Shield Generator A new shield generator designed specifically for Space and Alien Cores, these shield generators provide longer-term protection for a space construct and allow for the coordination of defensive actions. Added Lua functions (Most are similar to the Lua API of the Shield Generator for dynamic): [event] absorbed([float] hitpoints, [float] rawHitpoints) : Emitted when the shield absorbed incoming damage. [event] down(): Emitted when the shield hitpoints reached 0 due to damage. [event] restored(): Emitted when the shield hit points were fully restored. [event] enterLockdown(): Emitted when the shield enters lockdown. [event] leaveLockdown(): Emitted when the shield exits the lockdown. [float] getShieldHitpoints(): Returns the current hit points of the shield. [float] getMaxShieldHitpoints(): Returns the maximal hit points of the shield. [table] getResistances(): Returns distribution of resistance pool over resistance types. [0 or 1] setResistances([float] antimatter, [float] electromagnetic, [float] kinetic, [float] thermic) : Distribute the resistance pool according to damage. [float] getResistancesCooldown(): Returns time after which adjusting resistances is possible again. [float] getResistancesMaxCooldown(): Returns maximal cooldown between adjusting resistances. [float] getResistancesPool(): Returns total resistance pool that may be distributed. [float] getResistancesRemaining(): Returns the remaining amount of the resistance pool that can be distributed. [0 or 1] inLockdown(): Returns whether the base shield is currently in lockdown. [float] getLockdownRemaining(): Returns the remaining time of the base shield lockdown. [0 - 23] getLockdownExitTime(): Returns the hour since midnight of the preferred lockdown exit. [0 or 1] setLockdownExitTime([int] hour) : Set hour since midnight for the preferred lockdown exit. [table] getStressRatio(): Returns ratio per damage type of recent weapon impacts after applying resistance. [table] getStressRatioRaw(): Returns ratio per damage type of recent weapon impacts without resistance. [float] getStressHitpoints(): Returns stress, that is the total hit points of recent weapon impacts after applying. [float] getStressHitpointsRaw(): Returns stress, that is the total hit points of recent weapon impacts without resistance. Integrated a brand new 3D system map with new interactions. Overlays and displays for the planets, safezones and constructs on the map. Improved map performance for large amounts of constructs. Construct Speed Revamp Maximum reachable base speed is now based on a construct’s mass. Stasis weapons apply a maximum speed reduction to a construct. Rocket engines apply a maximum speed boost to a construct while firing. Space Market Aegis: a new market in space can now be found and traded on.  The Aegis has a public warp beacon for easy access. The Aegis Market has a 50km interdiction zone surrounding it that blocks space and static construct deployment. Shuttle Landing With the addition of Haven, a new satellite of Alioth, the Shuttle Landing buildings on Alioth and Sanctuary have been revamped to include shuttle services between Alioth, Sanctuary and Haven. Mining Units Lua API A new set of functions have been added to mining units allowing Control Units to gather information from a mining unit such as when it was last calibrated, its percentage, the location of the surface ore that was the result of the last calibration, and more. Added Lua functions : [string] getStatus() : Returns the current status of the mining unit ("STOPPED", "STALLED", "RUNNING"). [float] getRemainingTime() : Returns the time remaining on the drilling process. [int] getActiveOre() : Returns the id of the current selected resource. [table] getOrePools() : Returns the list of resources pool on the territory. Each resource pool object of the list contains ‘id’, ‘available’ and ‘maximum’ fields. [float] getBaseRate() : Returns the base production rate of the mining unit. [float] getEfficiency() : Returns the production efficiency of the mining unit. [float] getAdjacencyBonus() : Returns the territory's production adjacency bonus factor. This value will only be updated when a new batch is started. [float] getCalibrationRate() : Returns the current calibration rate of the mining unit. [float] getOptimalRate() : Returns the optimal calibration rate of the mining unit. [float] getProductionRate() : Returns the production rate of the mining unit. [vec3] getLastExtractionPosition() : Returns the position of the extracted ore during the last calibration in world coordinates. [int] getLastExtractingPlayerId() : Returns the ID of the last player who calibrated the mining unit. [float] getLastExtractionTime() : Returns the time in seconds since the last calibration of the mining unit. [float] getLastExtractedVolume() : Returns the amount of ore extracted during the last calibration. [int] getLastExtractedOre() : Returns the id of the extracted ore during the last calibration. Added Lua events : [event] statusChanged([string] status) : Emitted when the mining unit status is changed. Provide the new status. [event] completed([int] oreId, [float] amount) : Emitted when the mining unit completes a batch. Provide the item ID of the mined ore and the amount mined in the batch. [event] calibrated([int] oreId, [float] amount, [float] rate) : Emitted when the mining unit is calibrated. Provide the item ID of the extracted ore, the amount extracted and the new calibration rate. Added new Lua Item API : [table] system.getItem([int] id) : Return the item table corresponding to the given item ID : [int] id : The ID of the item. [string] name : The name used to define the item. [string] displayName : The name of the item used in the game. [string] locDisplayName : The name of the item used in the game in the language of your game. [string] displayNameWithSize : The name of the item used in the game with the size (XS,S,M,L). [string] locDisplayNameWithSize : The name of the item used in the game with the size (XS,S,M,L) in the language of your game. [string] description : The description of the item in English. [string] locDescription : The description of the item in the language of your game. [string] type : The type of item. [float] unitMass : The unit mass of the item. [float] unitVolume : The unit volume of the item. [int] tier : The tier of the item (1 to 5). [string] size : The size of the item (xs, s, m, l). [string] iconPath : The path of the item's icon in the game files (usable on the screens). New Lua Screen Update Changed screens and signs resolution. Added HDR color support. Added SDF fonts support and improved fonts quality. Added new or changed existing text functions : [int] loadFont([string] fontName,[int] defaultSize) - The font size setting becomes the "default" font size and can be changed during script execution with the setFontSize function. addText([int] layer,[int] font,[string] text,[float] x,[float] y) - Now supports the following properties : fillColor, shadow, strokeColor, strokeWidth. [float] getFontSize([int] font) : Return the currently-set size for the given font. setFontSize([int] font,[int] size) :Set the size at which a font will render. setDefaultTextAlign([int] layer,[int] alignH,[int] alignV) : Set the default text alignment of all subsequent text strings on the given layer. Added layers transforms functions : setLayerOrigin([int] layer,[float] x,[float] y) : Set the transform origin of a layer; layer scaling and rotation are applied relative to this origin. setLayerRotation([int] layer,[float] rotation) : Set a rotation applied to the layer as a whole, relative to the layer's transform origin. setLayerScale([int] layer,[float] sx,[float] sy) : Set a scale factor applied to the layer as a whole, relative to the layer's transform origin. setLayerTranslation([int] layer,[float] tx,[float] ty) : Set a translation applied to the layer as a whole. setLayerClipRect([int] layer,[float] x,[float] y,[float] sx,[float] sy) : Set a clipping rectangle applied to the layer as a whole. Added new shapes and image related functions : addBezier([int] layer,[float] x1,[float] y1,[float] x2,[float] y2,[float] x3,[float] y3) : Add a quadratic bezier curve to the given layer. Supported properties: shadow, strokeColor, strokeWidth. addImageSub([int] layer,[int] image,[float] x,[float] y,[float] sx,[float] sy,[float] subX,[float] subY,[float] subSx,[float] subSy) : Add a sub-region of an image to the given layer. Supported properties: fillColor, rotation. [float],[float] getImageSize([int] image) : Return the width and height of an image. [string] getLocale(): Return the locale in which the game is currently running (“en-EN”, “fr-FR”, “de-DE”). Balance Changes
Talent point gain changes Unqueued talent point gain per second: 0.1>1 Queued talent point multiplier: 15>1.5 This means your talent point gain per minute will go up from 1 to 60 when not training anything. Your training talent point gain will remain at 90. Element Mass changes: Warp Drive: 31000kg > 75000kg Large Gunner Module: 11000kg > 16000kg Medium Gunner Module: 2000kg > 4250kg Extra-Small Adjustor: 22kg > 25kg Small Adjustor: 42kg > 100kg Medium Adjustor: 200kg > 450kg Large Adjustor: 1000kg > 1550kg All Small Shield variations: 3300kg > 5000kg All Medium Shield variations: 17000kg > 30000kg  All Large Shield variations: 92000kg > 125000kg  All medium weapons: x1.5~ (roughly 2850kg > 4275kg) All large weapons: x1.25~ (roughly 15000kg > 19000kg) Shield Generator HP changes: Base values for Extra-Small Shield: 500000 > 450000  Base values for Small Shield: 2000000 > 1750000  Base values for Medium Shield: 7500000 > 5000000  Base values for Large Shield: 20000000 > 10000000 Railgun fittings costs changed XS: 400 > 375 S: 2000 > 1875 M: 10000 > 9375 L: 50000 > 46875 Command seat changes Fittings capacity: 125000 > 175000 Large weapon slots: 0 > 3 Element Mass: 158 > 3500 Atmospheric Radar Ranges changed Max visibility range: 5000m > 10000m Atmospheric Radar S: All identification ranges set to 2000m Atmospheric Radar M: All identification ranges set to 4000m Atmospheric Radar L: All identification ranges set to 8000m Balanced existing space and atmospheric engines variation: Freight: Light, Best Fuel Reduction, Worse T50 Maneuver: Good Fuel Reduction, Good T50 Military: Best thrust, More fuel Consumption Safe: Minor Fuel Reduction, Best T50, Removed thrust penalty Added exotic space and atmospheric engine variations. Added variations up to tier five for Hover Engines and Vertical Boosters The freight variation consumes less fuel but has smaller range The military variation is more powerful but consumes more fuel The maneuver variation has more range but is less powerful Added variations for Item containers The optimized variation is lighter and has more capacity. The gravity-inverse variation reduces the mass of contained materials, but it is heavier when empty, and has reduced max volume. Added variations for Shield Generators The active shield generator variant boasts a reduced venting cooldown and stronger venting regeneration at the cost of adjustable resistances and resistance adjusting cooldown. The variable shield generator variant boasts stronger adjustable resistances and resistance adjusting cooldown at the cost of base shield health. The capacitor shield generator variant boasts a stronger base shield health at the cost of venting cooldown and venting power reductions. Gameplay Changes
[Mining Units] Changed the extraction point to the bottom of mining units. [Mining Units] Changed the scoring in the extraction minigame, so that hotspots now have a "plateau" where the score will be 100%. This makes it easier to get a 100% score in the minigame, without having to target a specific pixel on the hotspot. [Parenting] Allow to force undock any construct you’re aiming at (with proper rights). [Mining tool] Improve tool behavior consistency. [Harvesting tool] Unify tool behavior with mining tool with an auto mode (MMB) and improve consistency. [Elements] Element deactivation due to collisions is slightly more tolerant on existing constructs for backward compatibility. [Lua] getTime() is now deprecated, because it depends on the time zone. You can use instead : [float] getArkTime() : returns the current time since the arrival of the Arkship on September 30th, 2017. [float] getUtcTime(): Return the current time since January 1st, 1970. [float] getUtcOffset(): Return the time offset between local timezone and UTC. Some Aphelia hauling missions are now considered "special" missions. Players will see only a subset of special missions for a given day. A different player may not see the exact same special mission. When taken, special missions have a specific remaining time (likely 24 hours). Special mission packages still block warp drive (this point is unchanged from the current mechanics, but we’re reinforcing it for clarity) [Piloting] Trajectory display mode is no longer available to passengers.
Improvements
[Blueprints] A preview of the constructs honeycomb is now displayed while deploying a blueprint. [Rendering] Improved the water rendering. [Rendering] Improved the look of the terrain. [Rendering] Introduced new skybox background. [Rendering] Improved the far ground voxels rendering. [Rendering] Improved the appearance of volumetric clouds. [Rendering] Introduced new star rendering to improve the skybox visuals. [Rendering] Small performance improvement on the main light of the world. [Rendering] Fixed an issue where screen units could appear all-white and fail to render until relogging. [Rendering] Removed the limit on the maximum number of marks displayed in the world (which was 58). Now the client returns all marks that need to be returned, regardless of the number of marks displayed. [Rendering] Improved the appearance of secondary lighting from the surrounding environment. [Rendering] Fixed glitched preview of Luminescent White Glass. [Server] Improved performance of the mesh generation backend. [UI] Added a filter (and sort) panel for elements listed in maps. Allowing to filter by owner, name, construct type, and/or sort on name/distance/owner. [UI] Various UI polish. [UI] Polished widgetstack UI style. [UI] Improved controls settings UI buttons. [UI] Improved industry batch time precision. [UI] Reactivated inventory background. [UI] Added the current UTC time on the HUD. [UI] Added mining unit type for the notification panel. [UI] Activated more build helper infos for piloting helper. [UI] Move container total items at the bottom of the panel. [UI] Adding specific chat color for Novaquark staff and Community helpers. [UI] Modified a few icons in notification panel for: General, barter, industry and RDMS. [VFX] Improved flashlight VFX. [VFX] Reworked all engine VFX. [VFX] Updated VFX when warping. [VFX] Updated VFX when going at high speed. [VFX] Replaced explosion VFX & SFX from weapons. [VFX] Harvesting ores now do not glow by default. They now only glow when the player equips the harvest tool. [Physics] Conserve momentum when mass is increased before resuming speed. [Voxels] Optimized some voxel operations. [Voxels] Added assignable custom keybindings for Vertex Precision Tool. [Lua] Disabled code dumping provided by string library. [Lua] Lua constants library now returns read-only constants. [Markets] Simplified bots market orders by removing the spread. [Network] Avatar color changes are now replicated in real time over the network. [SFX] Close avatars now emit footstep sounds [SFX] Footstep SFX are now adapted to the current surface being walked on. Escape key no longer closes the game. [GunnerUI] Improve feedback synchronization for firing and weapon impact. [Tools] Added new sounds to many tools. [Codex] Improved search functionality by highlighting the word search in the codex text, and by filtering the navigation menu in order to display main categories which are from the highlighted words. [Market landing pads] Removed lamp posts from the landing pads, added more emissive voxels for better visibility [FTUE] Various Aphelia speech tweaks [FTUE] Added untab step after exiting the map [FTUE] Added step before the outpost screen tutorial to detect if the player has a tool equipped. if yes, Aphelia explains how to unequip the tool [FTUE] Aphelia recommends the Talents mini-tutorial when explaining the outpost objective screen. [FTUE] Outpost objective screen now notes that it is Work In Progress [FTUE] Improved outpost objective screen descriptions to show which mini-tutorials are available and which are not. [Avatar creator] Added music. Detection zone can now be triggered when sitting on a chair, or when using an elevator. Display a notification when trying to disband an organization which has the role of superlegate in another organization. Updated the roadmap. [System map] Drawn distance meter between player & hovered item (if no item is selected).
Bug Fixes
Fixed a precision issue with coordinates. [UI] Interchanged territory and organization icon. [SFX] Fixed sound remaining off after any loading screen. [SFX] Fixed metal cracking sound still playing after a ship crash. [UI] Fixed missing space construct icon on minimap. [UI] Fixed the map selection picker not always displayed. [UI] Sell order notification no longer shows the market name as 'market'. [UI] Fixed button clicking sound played twice on sell/buy button on market UI. [Linked container] Fixed an inconsistent message upon breaking/restoring the container. [Achievement] Wealthy achievement quanta requirement increased from 100 000 to 400 000. [Rendering] Fixed water ship “cutout” glitch. [Rendering] Fixed multiple visual bugs with water. [Rendering] Fixed volumetric fog visibility through clouds. [Rendering] Fixed fuel container highlights not displayed in some cases. [Rendering] Fixed missing screen space shadows (additional shadows for grass). [Rendering] Fixed Alioth water not being rendered when getting close to Sanctuary. [Rendering] Fixed some aliasing issues in the character customization and the periscope views. [Rendering] Fixed screen units not being visible through certain transparent elements such as force fields. [Radars] Fixed construct position incorrectly updated. [Radars] Fixed construct mass incorrectly displayed by Radars. [Lua] Fixed Lua parameters editing fails. [Lua] Fixed implicit activation of ControlUnits on broken constructs. [Lua] Fixed construct mass sometimes incorrect in the api lua when using a programing board. [Lua] Fixed an issue where the Lua screen unit setOutput command could fail under rare circumstances. [Parenting] Fixed avatar not kickable once boarded. [Parenting] Fixed broken force-undocking a child construct from the build helper. [Parenting] Fixed "Undock from" incorrect message, and appearing when not docked. [Parenting] Fixed a bug where docked construct mass would sometimes contribute twice. [Parenting] Prevent docking when maneuvering other player’s constructs on your territory. [Parenting] Added notification error when attempting to manually dock or undock in automatic mode. [Warping] Ship speed is now always 0km/h when reaching destination. [Warping] Fixed negative distance when the warp target was too close. [Settings] Fixed decor display distance setting that was not saved. [Tutorials] Fixed players able to interact with elements in the market tutorials before being asked to. [Tutorials] Fixed market tutorial locking when entering incorrect amounts in the buy and sell portions of the tutorial. Prevent implicit activation of ControlUnits on broken constructs. Fixed an issue where shadows could appear very detached from their casting object. Fixed an issue where light rendering could appear cropped at a certain radius. Display the correct tile owner name inside the requisition popup. Hide requisition context menu if the player is not the owner, legate or super legate of the organization who possess the tile. [Periscope widget] Fixed display if no target is selected. [Marks] Displayed distance matches distances from radar when piloting or in a Gunner Module. Restored notification to the construct owner when the construct is damaged (PVP). Fixed: Display lockdown countdown in the reticle. Editing Lua parameters now works on complex scripts. Context menu on item in linked container while market panel is opened is now consistent with context menu for item in inventory while market is opened. [Radar] Spurious far targets no longer appear. Fix some cases where bookmarks are replaced with the respawn point. [PvP] Fixed a bug where reloading/unloading weapons triggered Combat Lock. Removed sound environment being duplicated when entering a tutorial or a surrogate session. Fixed a bug where you were allowed to tokenize a construct that you are piloting with a remote controller, leaving the construct stuck in remote control. [Linking] Added more notifications when linking or unlinking fails. Fixed some chat messages that were received several times, or weapon shots that were triggered several times. Notification "You died at xxxx Check the last death position bookmark in the map" is no longer added multiple times. Fixed inspecting item inside build helper elements report which close the enhanced mouse mode. Fixed a problem where the player would sometimes get stuck when logging out in a seat. [FTUE] Changed "RMB" for "LMB" when explaining the Outpost Objective screen. Fixed Transfer Unit stay default state. [Planet/system map] Fixed owner sometime not being displayed on first click (part of DU-34818) Fixed territory tooltip for expired territories in the territories list of the map. Don't show the warning/info icon (concerning territory status explanation) on territory not owned by the player or one of his organization). [FTUE tile selection] Fixed owner of an owned territory not being displayed on first click. Fixed a looping calibration sfx not being correctly stopped when existing calibration modal in loading step. Allowed the use of  '-|' in bookmark name & description. [UI] Fixed dropdown being cut in the mission search panel (for destination dropdown). Added a small delay (100ms) before doing a drag start. This reduces risk to unintentionally start (and end) a drag, when quickly selecting multiple items in inventory. Regen crafting queue display on active container switch. Avoiding ingredient list of futur recipes displaying available ingredients that were in the previous container. Removed the final "." in the renamed territory modal title. Fixed a bug where the player could enter build mode during FTUE landing sequence. Fixed a bug where the player could not achieve a tutorial requiring nanocrafter if they had previously performed a search in the item hierarchy. Added confirmation pop-up for back and forward tutorial step keys. Fixed displayed acceleration at low framerate.
Crash Fixes
Fixed rare crash on game shutdown. Fixed rare crash and freeze during loading. Fixed uncommon crash when entering a Gunner seat. Fixed a crash when accepting a barter request twice. [GunnerUI] Fixed occasional crashes when changing cameras.
Known Issues
Space Mining Units and Plasma Collector Lua API will not yet be implemented, but will come in a future minor update. The Objective screens in the Outposts are Work in Progress. Not all tutorials will trigger. The text on the Objective screen indicates which tutorial triggers and which is coming soon. [FTUE] Speeder step sometimes fails to deploy, speeder too far. We are investigating the issue, this issue can be self-resolved by disconnecting and reconnecting to the game. [FTUE] Localization has not been completed for the new tutorial and is currently only available in English.
   
Thank you all for your support!
- Deckard

Hello @EasternGamer!
 
That was quite the read.
 
Although we do already have very similar plans on the drawing board, it is unlikely that this will happen soon as it will likely have to go hand in hand with a larger Lua change for which we simply do not have an ETA at this time. And it's also not something that can be implemented at any point as it involves some major changes that would mean refactoring and "fixing" just about every single Lua script that currently exists in the game.
 
As such, although we agree with the idea and would eventually like to do something along these lines. It is very unlikely it will be before release.

We hope everyone who attended our Fools Defense event held on our PTS on April 1st had fun.
We especially did, and thanks to our fellow Noveans, we had a ‘blast’!
 

 
As some of you might remember in our previous announcement for the Fool’s Defense event, there were some prizes to be had. We are pleased to announce that the winners have been chosen and the Wheel of Foolish Fortune is ready to start spinning! Which prizes will our foolish actions provide those that dare take a spin? Find out on the PTS on Saturday April 9th, 14:00 UTC for all the wheel spinning action.
 
After combing through our logs with a fine tooth comb, we have chosen six participants whose bravery, dedication and foolishness left the server room sizzling. We are now inviting them to prove their luck and talent once again by taking the Wheel for a spin!
 
Walter - For landing the final blow causing the destruction of the defenders station, many developers were harmed in the process. (Yes, we checked the logs thoroughly.) Copperlein - For being so good to us on the PTS, yet destroying Nautilus A’s Core, and breaking our heart. Dronko - For destroying Nautilus B’s Core, and again breaking our heart. (Et tu, Brute?) Wolfram  - For being devs’ best friend by reporting bugs on our forum. Mastuga - For being such a Trooper with the amount of ammo (pew, pew, pew) they used during the event.  Honvik - For forcing so many players to return to the resurrection pod. Skyreaper - For coming back to life so many times we thought they were a cat!   
Winners please present yourself on the PTS on Saturday, April 9th at 14:00 UTC for your chance to spin the Wheel! If you are unable to attend, a Novaquark representative will spin the Wheel in your place. Prizes will be given out shortly after the spinning of the Wheel has concluded. 
 
Please note: All players will need to go through the new FTUE on the PTS in order to participate in this event, please allow yourself enough time to go through it. 
 
Players who wish to join in the fun on the PTS are welcome, teleport over to PVP Platform 2 (::pos{0,0,2729026.2814,-98851321.2156,-1455512.2758}) where you can witness first hand the spoils of war!
 

We hope everyone who attended our Fools Defense event held on our PTS on April 1st had fun.
We especially did, and thanks to our fellow Noveans, we had a ‘blast’!
 

 
As some of you might remember in our previous announcement for the Fool’s Defense event, there were some prizes to be had. We are pleased to announce that the winners have been chosen and the Wheel of Foolish Fortune is ready to start spinning! Which prizes will our foolish actions provide those that dare take a spin? Find out on the PTS on Saturday April 9th, 14:00 UTC for all the wheel spinning action.
 
After combing through our logs with a fine tooth comb, we have chosen six participants whose bravery, dedication and foolishness left the server room sizzling. We are now inviting them to prove their luck and talent once again by taking the Wheel for a spin!
 
Walter - For landing the final blow causing the destruction of the defenders station, many developers were harmed in the process. (Yes, we checked the logs thoroughly.) Copperlein - For being so good to us on the PTS, yet destroying Nautilus A’s Core, and breaking our heart. Dronko - For destroying Nautilus B’s Core, and again breaking our heart. (Et tu, Brute?) Wolfram  - For being devs’ best friend by reporting bugs on our forum. Mastuga - For being such a Trooper with the amount of ammo (pew, pew, pew) they used during the event.  Honvik - For forcing so many players to return to the resurrection pod. Skyreaper - For coming back to life so many times we thought they were a cat!   
Winners please present yourself on the PTS on Saturday, April 9th at 14:00 UTC for your chance to spin the Wheel! If you are unable to attend, a Novaquark representative will spin the Wheel in your place. Prizes will be given out shortly after the spinning of the Wheel has concluded. 
 
Please note: All players will need to go through the new FTUE on the PTS in order to participate in this event, please allow yourself enough time to go through it. 
 
Players who wish to join in the fun on the PTS are welcome, teleport over to PVP Platform 2 (::pos{0,0,2729026.2814,-98851321.2156,-1455512.2758}) where you can witness first hand the spoils of war!