WarrenOne

Because a crosshair on your ass as soon as you touch an asteroid is nowhere close to 'risk vs reward'.
That mechanic was purely designed to cater gankers with quick nobrainer prey..and it's good and healthy for the game that this crap will be gone soon.
 
Wan't to gank or controll all pvp space resources?..work for it..

How many times do we have to ask for the purple plastic and steel variants? This was a mistake left uncorrected for 2 years now.

How many times do we have to ask for the purple plastic and steel variants? This was a mistake left uncorrected for 2 years now.

How many times do we have to ask for the purple plastic and steel variants? This was a mistake left uncorrected for 2 years now.

How many times do we have to ask for the purple plastic and steel variants? This was a mistake left uncorrected for 2 years now.

Obviously in recent posts and releases, the game is focusing on preparing the game for release. There are many additions that could definitely be added or changes to correct after release, there are some that I believe NQ should absolutely not do after a release as without them, the release is likely to fail. The first on the list is to redefine the pillars of the game as there are new features that really changed how to even talk about them in the game. I believe the easiest way to categorize the players is in the following sections: Mining/Harvesting, Building, Fighting, Transport/Missions, Scripting, Industry, and Admin/Management. Below are the absolute necessities for each before release.
 
Mining/Harvesting
 
As is, the system is alright. However, I recently saw a suggestion that may be way more appealing to the community over passive mining and the change would have to be made before release as it would be too game-changing to be made post-release. The idea of passive mining has lead to massive acquisition of ores that honestly seemed too easy. The reason people mined by digging so much even though it was monotonous is that there was a reward right away for the grind. The current mini game seems very boring since there's no real reward in front of you minus the little bit of surface ore. What could be a good system is have a mining unit bring the ore to the surface (either the surface rocks or what would be nice is just the surface ore we used to have when a node was above ground so no tunnels) and have each 'calibration' yield a few thousand liters and then go into a cooldown period. No passive mining but rather you use the mining unit to gather a large amount. This brings some of the active effort back to acquiring resources instead of clicking a few buttons and then waiting. Whatever the rebalancing or change may be to make planetary mining better, it has to be final before release
 
Building
 
Blueprints: If we're going to have a wipe (I'm not getting into that argument here) then for the blueprints to be put down, we need a way for structures to snap to an existing structure on the ground. I don't know why we don't already have this as there are many multi-core structures that people cant share because you cant align blueprints with each other. If this is not added before a wipe, say goodbye to a good amount of the content creators. Also a recommendation: add this feature soon and reemphasize that blueprints will stay even with a wipe. There seems to have been a lack of awareness of this.
 
Energy Management: If you're going to add this, add it before release or else it will restructure everything people already built. Don't do this after a release and then screw up how people began building the officially released version of the universe. Also my personal opinion is this system should apply to ships to encourage specialization like a real ship would have to (energy to operate weapons is a thing), apply to anti-gravity generators (this is basic physics that something like that should consume SOME type of energy), and apply to industry machines (seriously we should have to use energy to run machines this is a basic concept).
 
Element Destruction: we need this back once the game is stable. People keep taking sides on this over one very easily detachable issue: loss of ownership. People saying how bad the element destruction was and how it should never be done again said it because people lost their entire ship on game glitches. Just remove that part. Elements should have lives and then be able to be broken down into some of the parts based on the amount of lives maybe. The problem was the core destruction from environmental damage should not have caused you to lose your ship permanently. I don't understand why it would be so difficult to separate PVP from PVE damage to a core in it's ability to lose ownership. I get it would take some time to code for the conditionals but if the core's single life is destroyed from PVE damage, it should be replaceable instead of dropping ownership on PVE damage. If it really is that impossible, then just allow for PVE element lives on all the other elements like the wings and adjustors. Maybe the number of lives may need adjustment on them and maybe different numbers on different elements, but I see no reason to not put back in wing replacement mechanics after being broken over ten times. Maybe things like large engines would have more lives since its a more durable element than say an extra small wing. It could be an equation based on element mass that determines how many times it can be repaired. Now an outstanding bonus that might have to wait if it's reasonable to implement is to either repair "damaged" elements with scrap, but "broken" elements or maybe just ones with no lives would require some of its parts to restore like consuming pipes to restore an engine. That would be amazing for game balancing with industry and finally give use to parts instead of just the final product.
 
Core Sizes: Recently we heard about how XL cores could cause some issues with people just having too much data in a single area. I think this actually highlights a small flaw in the current core limit system. The idea is to limit the amount of data a single player/organization can be taking up. As it stands now, if someone has 100 construct slots available, it doesn't matter if they are 100 XS constructs or 100 L constructs. This seems to defeat the purpose since 100 L constructs is 512 times the amount of data as 100 XS constructs. This means 100 L constructs has the space of 51,200 XS constructs. I suggest to better handle the needed data limits, switch to a system of construct points of either "XS=1, S=2, M=3, L=4, XL=5" or "XS=1, S=8, M=64, L=512, XL=4096" and then have construct point limits. This would allow better balancing for XL cores and the current core sizes.
 
Purple Honeycomb. This is personal. The fact that I still cant build with purple plastics or purple polished/galvanized steel disappoints me every time I log on.
 
Fighting
 
Balancing can always be adjusted after release. Weapon nerfs/buffs happen all the time to healthy games. What absolutely needs to be decided (even if not implemented) before release is territory warfare. Implementing it can happen after release if really necessary, but players have to know where they should plan to build. The safe zone was obviously created for that reason. If there are plans to add planetary warfare on say Lacobus, players need to know that before building their lives on Lacobus at release. A simple statement saying "the safe zones around planets outside the main safe zone (Alioth-Madis-Thades) will not remain long term" would prevent players from quitting when they learn their home base will no longer be safe even after release. 
 
Transport/Missions
 
Missions: We just need more variations that were talked about long ago. We really need the bounty system before release as this would be many players' reason for playing. Maybe even a taxi service as part of it too. There have been other ideas floated in those discussion threads but we definitely need more types of missions to keep players playing at release. Also for the love of Aphelia we need to be able to use parcels with RDMS and not have to be a Legate of an organization to ship a package. I should be able to send a "letter" to my friend without owning my friend's house. 
 
Warp: We need to ability to add public warp beacons to our list in our map menu. This is the only way for player/organization constructs in space to form when the game is released. We can't require a player to waste an organization slot just to be able to visit an organization's space construct with a warp beacon. Also please give us the ability to block the "stop warp" function. With the original Lua API we could remove the "alt+j" key's ability to stop warp but for obvious PVP exploit reasons that may be an issue to control the "stop warp" function. There must be someway we can remove a player's ability to drop out of warp in PVP space on our ships if we so choose. "Trust your player" is not a good enough mechanic. We should have control over their ability to do that since we would be able to block a person's use of systems in the real world without just "trusting them to not hit that button." 
 
Scripting
 
Additions can be made post-release, but what we need beforehand is a way to sell scripts for people to put on their own constructs. For example, if I made a shield control system/interface, I can't sell it to someone to put on their ship without them being able to copy and paste it for free afterwards. The only way to keep it protected is to sell them a whole ship with the interface installed with DRM enabled for the entire construct. They can't put it on their own already existing ship with protection enabled on just my script. Just add DRM flagging in the actual element of a programming board when putting it into an inventory and trading it. It's already in blueprints. 
 
Industry
 
Fix "balancing" mistake that was made. Obviously the idea of an endless amount of machines making screws was something that needed to be fixed, but the wrong side was adjusted. The "idea" (schematic) of making a screw is very easy and simple. In the real world, the hard part is acquiring a machine that can actually make the screws. In this example, it should be the metalwork industry unit that is the bottleneck point, not the specific screw. Having a machine to make screws should be difficult, but not to then simply reprogram the machine to make a frame instead or another added cost for a second machine you already have to be able to make screws. I'm open to how this would be implemented. My idea is have the  machines cost more to make and then have your character "learn" to make screws. This could be through talents, a separate passive learning que, or some sort of mini game for each tier of each part/element. This could even apply to the current familiar schematic system only you buy one schematic that stays in the avatar's memory bank to start a machine with that schematic loaded. Then once your character learns how to make uncommon screws, they can make it in any machine since they have the knowledge. 
 
Admin/Management
 
We need in game and external communication. It really doesn't seem too hard to implement since systems already exist for hundreds of other server based programs not just games. We need a way to leave a message for someone in game. Some sort of mailbox to send a message to a player that's not online the exact second we are. Also a system where an email can be sent to someone with in game notifications such as when something is under attack or a construct of theirs is about to be abandoned. I can already see how many players would hold back from playing or building out in space and taking risks because someone would have to be online 24/7 to monitor if their space station is under attack. Could be a simple menu under the organization/person for "notifications" where you can see a list of constructs and check boxes of what you want notifications for on the individual constructs: one for when targeted (meaning it's been discovered), one for when attacked, one for when destroyed, and one for when abandoned by IAR or parking/construct number limits. Players have quit this game before due to lack of info on what's going on with their stuff in game and there needs to be a solution before release.
 
Things that can wait until after release because they wouldn't turn players away:
 
More Lua screen functions
More Lua APIs
Skin stores?
More star systems/planets
In-game events like earlier
Pets
Potential farming/food for buffs
New voxel textures
XL cores existence (see building for new limit system though)
L and XL elements that don't already exist (ie engines/wings)
Construct deconstruction/packing
Player market pods
Playing sounds through lua
Holograms?
Visual FX

Honestly I'm still waiting for the relevant Lua for my field in this game: Industry. We've been having issues since the very beginning of Beta with figuring out the amount of product certain batches create. An example is basic pipes. With no talents, 10 pipes are created per batch. Not counting the productivity talent, the efficiency talent actually changes it at a certain point so that instead of making 10 pipes quicker, it actually jumps up to just making 20 pipes in the same amount of time to account for efficiency. Smaller elements like buttons also see this effect with efficiency talents where it will go from making say 2 buttons per batch to 4 which screws up the required input material.
 
TLDR: We need a Lua function that queries what the machine is making and how much is needed/outputting in a single batch.

Honestly I'm still waiting for the relevant Lua for my field in this game: Industry. We've been having issues since the very beginning of Beta with figuring out the amount of product certain batches create. An example is basic pipes. With no talents, 10 pipes are created per batch. Not counting the productivity talent, the efficiency talent actually changes it at a certain point so that instead of making 10 pipes quicker, it actually jumps up to just making 20 pipes in the same amount of time to account for efficiency. Smaller elements like buttons also see this effect with efficiency talents where it will go from making say 2 buttons per batch to 4 which screws up the required input material.
 
TLDR: We need a Lua function that queries what the machine is making and how much is needed/outputting in a single batch.

Honestly I'm still waiting for the relevant Lua for my field in this game: Industry. We've been having issues since the very beginning of Beta with figuring out the amount of product certain batches create. An example is basic pipes. With no talents, 10 pipes are created per batch. Not counting the productivity talent, the efficiency talent actually changes it at a certain point so that instead of making 10 pipes quicker, it actually jumps up to just making 20 pipes in the same amount of time to account for efficiency. Smaller elements like buttons also see this effect with efficiency talents where it will go from making say 2 buttons per batch to 4 which screws up the required input material.
 
TLDR: We need a Lua function that queries what the machine is making and how much is needed/outputting in a single batch.

For those of you who were in stream last night. This is a good middle ground of what they wanted and what we wanted. I think this post coming so soon after the fact is amazing. Thank you for the quick response NQ

Wallet feeling a little light lately? Get ready to remedy that when the Panacea update hits, bringing with it two lucrative, quanta-producing possibilities: space wrecks and inactive asset requisitioning (IAR).
 
SPACE WRECKS
 

You’re going about your business, flying through space from one market to another or heading out to join some friends when your radar unexpectedly reveals something. Curious, you move closer to investigate and find wreckage. There’s no indication of who left it behind or why. Finders keepers, right? It’s yours now. And you’ve got some choices to make.
 
DECISIONS, DECISIONS
Will you: 
salvage the ship for materials and elements? tokenize and sell the whole ship? sell the information about where the wreck is located? create a mission to get someone else to salvage it? The decision is all up to you.
 
RADAR AND RARITY
No special equipment is needed to locate these space wrecks, your standard radar is enough to detect them.
They will spawn randomly 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
 
This system is being introduced to address one of the chief complaints we’ve heard from Noveans, namely abandoned constructs cluttering up the universe, especially in public markets.
 
The purpose of IAR is to:
create salvaging opportunities for players around the game world. ensure cleanliness and performance around markets and other Aphelia zone hot spots. clean up older, unowned constructs.  
In other words, IAR has the potential to create a less cluttered environment for everyone and a fatter wallet for you.
 
ABANDONED CONSTRUCTS DEFINED
Players with a subscription, even if they have not logged in for a while, are in no danger of having their constructs flagged as “abandoned”, with the exception of constructs parked in Aphelia territory as noted below.
 
In effect, constructs belonging to unsubscribed users and not on their owners’ sanctuary zones will eventually lose their ownership, putting them in an abandoned state and making them vulnerable to be salvaged by other players. Likewise, constructs owned by an organization will lose their ownership when the org’s last remaining legate ends their subscription.
 
During the unsubscribe process, players will be reminded that their constructs will be in danger of becoming abandoned. When the constructs lose ownership, a blueprint will be placed in the owner’s inventory should they choose to return to Helios at a later date.
 
TIME’S TICKING 
When an account becomes inactive due to a canceled subscription, a countdown will begin on all constructs belonging to that account. After a period of time, those constructs will lose their ownership and other players will be able to salvage or capture them.
 
Then, all unowned constructs will have a countdown timer and it will count down from the moment it is unowned, regardless of why they are unowned (PvP destruction, IAR, abandonment, etc.) At the end of this timer, the construct will simply be removed from the game world.
 
The ‘ownership’ timer for unsubscribed players’ constructs is three months (90 days/2160 hours). The timer is the same for organization-owned constructs and begins when the last active legate of the owning organization’s subscription expires.
 
Each time a construct is unclaimed, whether due to an owner’s inactive game account or if abandoned via PvP, a one-month countdown to decay is set and is visible to everyone. If no one salvages the construct, it will be permanently removed from the game.
 
As with most newly introduced systems, this is subject to change in the future depending on the metrics we see as time passes.
 
SPECIAL RULES FOR MARKETS 
A modified version of IAR will be used on Aphelia territories, including all market zones.
Regardless of whether or not the owner is an active subscriber, all constructs on Aphelia territories are subject to IAR. As soon as a player exits their construct in Aphelia territory, a 168-hour (seven-day) abandonment countdown will begin for that construct. This is considerably shorter than the default IAR timer. Once that countdown reaches 0, the construct will lose its ownership. A new countdown timer of 48-hours (two days) before deletion will start ticking.
 
HAPPY HUNTING
 
Will you be among the happy scavengers scouring the skyways and byways for wrecked ships and abandoned constructs? Join the conversation about this devblog here.

Mining units are one of the key features that will be introduced in the upcoming Demeter update. What are they? How do they work? How will they impact the gameplay of Dual Universe? Read on for the answers to those questions and learn more about these handy-dandy little ore vacuums. 
 
HOW DO MINING UNITS WORK?
Let’s start with the basics. 
 
Mining units are new elements that you can deploy on your static constructs on the surface of planets. They need to be linked to an output container and, once started, they will autonomously dispense ore at regular intervals into this container without the need for you to be connected to the game. 
 
There is one mining unit for each tier and they are large elements. Each tier of mining unit is able to mine ores of the same tier. In addition to these five large mining units, there is also a small one for tier 1 only. This special small mining unit is intended for beginners.
 
Let’s have a look at these beautiful beasts in action.
 

A minimalist mining building with an active mining unit and its best friend, the container
 
These mining units work only if the mining ray you see in the screenshot above is not obstructed and can reach the ground. The mining ray has a maximum range of 50m.
 
Once the mining unit is deployed, linked to an output container, and in range of the ground, you can select what ore it will mine and start the machine. Once calibrated (more on that below), It will then mine regularly and deliver a batch of ore in the output container every hour. To further automate the process, the output container can be designated as the entry point of an industry line. (Note: If the container is full; the mining unit will no longer collect ore, so you’ll need to empty the output containers from time to time or have them feed directly into an industry line.)
 
There are two primary considerations when deploying mining units. First, you need to make sure the territory where they are deployed actually holds enough ore underground and the units will need to be calibrated before they will begin collecting ore.

TERRITORY POOLS
Various types and tiers of ore are dispersed with limited availability across Dual Universe. You won’t find them all grouped together in a particular place. 
 
To represent that, each territory in the game can provide up to a certain volume of ore each hour. That’s what we call the ‘ore pool’. A territory scan can show the kinds of ore present on a territory tile and their yield rates in liters per hour.
 

This territory is capable of providing a variety of tier 1 ore
 
The image above illustrates the territory-based maximum rate for each ore on this territory. Since there’s a maximum yield per hour, adding more and more mining units becomes useless past a certain point. Each active mining unit “consumes” a part of these available resources. These territory pools represent mining rates, not a total volume of available ore. For example, if a territory has a pool of 100 l/h of a given ore and each mining unit is capable of extracting 50 l/h, then you need two mining units to maximize your extraction capacity, and any additional mining unit beyond two won't give you more yield.
 
Unlike the previous ‘manual mining’ system, the new ore pools are infinite. You will always be able to mine these ores at this rate for as long as you have a calibrated mining unit running here.
 
These territory ore pools are varied and different. On a planetary basis, this new repartition should match more or less the previous allotment for manual underground mining. There are a few changes, but basically a planet that used to contain some tier 3 ore will still contain some tile-wise though, the issuance is very different between low and high tier ores, even from territory tile to territory tile. Typically, you should find tier 1 ore in abundance on nearly every territory tile in the system, but tier 5 ores are only on a few small spots on the most distant planets.

ACTIVE TERRITORIES
For mining units to work, the territory must be active. That simply means that the territory tax for it must be paid. That’s right, if you want the shiny rocks, you gotta pay your taxes. You can learn more about territory upkeep in an upcoming devlog. 

MINING RIGHTS
If you share your territory tile with your friends or organization, you might want to keep the precious underground ores for yourself or, conversely, allow only specific people the ability to operate mining units on your territories. For this purpose, we’re adding the Mining Unit Right. Without this, mining units belonging to other players are unable to access the ore pool and cannot mine on your territories. 

ADJACENCY BONUS
Mining units are social. They like to be around friends. That’s why if you own several active territories near each other, the mining units working on them get an ‘adjacency bonus’ to yield a greater amount of ore beyond the ore pool in each batch. Note that the territories must be owned by the same entity. If you find a great tile with precious ore under it, it might be worth it to own and maintain a few adjacent territories.

EXTRACTING AND CALIBRATION
As explained above, mining units are fully autonomous, doing their appointed duties regardless of where you are and what you’re doing, including when you’re offline having real-world adventures (which you should be enjoying from time to time). The reality is just a bit more complex as mining units need to be calibrated to work efficiently.
 
Each mining unit has a ‘calibration score’ and slowly loses calibration over time if kept unchecked. When the calibration score is below 100%, the mining unit will produce less ore; at 0%, it won’t produce anything at all. To remedy that, it must be calibrated.
 
To calibrate, you will need to enter a specific interface where you will manually probe the territory in search of underground ore. This is ‘extracting’.
 

Manually extracting ore and calibrating the mining unit
 
In this extracting session, you will use several tools to probe the territory tile, but you will need to keep a look at the probe battery at the same time. The goal is to find the optimal point with the best ore density that you’ll select at the end of the process. Depending on the quality of the location, this will have two effects:
It will increase the calibration score so that the mining unit can continue to do its job. It will also extract a few ore rocks in the process and those will pop to the surface of the tile at the selected location. These may be harvested manually at your convenience; they don’t expire.   
Calibration is not unlimited. Each player generates calibration charges at the rate of one charge every few hours. You can use your charges on the mining units owned by other players or organizations as long as you have the rights needed to access them.
 
Finally, a single mining unit cannot be extracted twice in a row. There’s a 24-hour cooldown period before calibrating it again. The upside is that mining units will not lose calibration for two days after being calibrated.

MINING UNIT TALENTS
Since mining units are a big new thing for Dual Universe, they come with a variety of new talents to complement their use.
 
You will have talents that improve the:
mining unit efficiency, on element deploy base mining rate, on element deploy speed at which your character will regenerate calibration charges  maximum mining charges your character can hold amount of ore extracted when calibrating  
GETTING TO THE CORE OF TERRAFORMING
One change we do want to make you all aware of comes as part of the terraforming changes where previously a number of players had dug down to the center of certain planets or moons. Each planet or moon will now have an impenetrable core at the center that forms about 80% of the planet's radius with a minimum digable depth of 5 km below its “sea” level.
 

 
As such, some constructs may be located below this line after the incoming terrain changes. In these cases, we will raise those constructs up to the relevant planet’s surface. (See this article about preparing for the geometry reset for directions on how to request assistance.) 

A CHANGE OF HEART, THE REMOVAL OF SCAN RESULTS
We received a considerable amount of feedback from players who were opposed to keeping old scan results relevant. And following some internal discussions on the topic, we feel that it is indeed in the best interest of the game to provide a clean slate when it comes to mining data to prevent the hottest of hotspots from being immediately taken. As such, we will be clearing all scan results from the game when Demeter goes live. 
 
We realise that this will inconvenience some of the players who have large amounts of scan data; however, we do believe it is the right thing to do.

DO YOU ‘DIG’ THE MINING CHANGES?
Mining units are a significant departure in how mining is done in Dual Universe. The old underground mining system is gone, replaced by mining units and asteroid mining. We hope that you will appreciate the new feature, from territory management and optimization to the extracting sessions. We really think that the new state of mining in DU is more sustainable and hope you’ll agree. Share your feedback here. 
 

I usually am not very active on the forums, but I decided I wanted to help combat some of the "hate" people have been spreading about this update and I'll do it in multiple sections to make it easier. I'll also bring some things up that have been put on the back burner, but I believe should be addressed sooner rather than when they become a major issue again.

TAXES
 
Opinion: 1 million quanta in this game is not nearly as much as most people think. If you log in for 7 days, you just paid for your territory tax for a single tile on top of the free one on sanctuary. You do not have to do a single thing other than log in then back out to earn the money for a territory of your choosing. This being said, NQ can easily change the rate after implementing the system and seeing what does happening instead of everyone guessing what might happen. Arguing about the rate before it is even implemented is not useful since everything will remain an "if." 
 
Territory Loss
 
Opinion: The game NEEDS this. We have way too many tiles claimed and too many obtrusive constructs owned by players who left the game. This is making the game feel abandoned in some areas instead of simply "unexplored" or "potentially useful" in those areas. These abandoned cities and towers and outposts are discouraging clutter and need to go. We also do need the system to continue purging abandoned materials from land. For the health and enjoyment for the active players and to attract new ones, we need this system. 
 
Suggestion: I'm not sure of the capabilities of linking in-game information to external registered accounts, but I believe we are seeing more and more need for a external connection to certain information. This territory loss mechanic is the largest need so far. We really do need a way by email to receive a notification of an abandoned tile construct being marked for excavation by another player. If someone is taking a break from the game but still has their active subscription and maybe ran out of tax funds, they shouldn't have to log in continuously to make sure their constructs aren't marked for excavation. A simple email notification from an in-game connection to it would go miles for relieving players of their worries and would be less deterring for players to branch out. I'll address another crucial need for this system under Player Communication.
 
Brakes
 
Opinion: To those complaining about new obstruction: I'm sorry, but move on. The obstruction arrows and indicators have been on the elements since the beginning of Beta. You should have known better and cannot act surprised that they are fixing what has clearly been a bug for ages. 
 
Question: Are we going to see the intended animation for the air brakes at some point?
Question: Will the obstruction areas be changed for the air brakes? Currently the area is towards the front of the model, but wouldn't they logically open upwards and it not matter what's in front of them so long as they can open?
 
Mining
 
Opinion: I'm on board with all the changes honestly. I will not miss digging holes being the most profitable source of income. Also thank you for increasing asteroids in the safe zone because the current 12-ish was definitely NOT enough. I get it low risk is low reward, but we're just talking wanting some tier 1 and 2 ore. My only complaint with the mining changes is some of the tier 2 ore scarcity is a little too extreme. Out of over 50 tiles on Alioth absolutely zero of them had any tier 2 or 3. I get it for the tier 3+ maybe this scarcity will make the game more interesting. However, the bare necessity of this game is fuel, specifically space fuel. How are people supposed to play the game if you can only make space fuel to start exploring on less than 2% of the tiles. This is too extreme. As for a scan wipe, I don't personally care. It's better to not wipe and see how it goes and maybe wipe and regenerate the ore pools later than to wipe it and then realize you shouldn't have.
 
Suggestion: We need more tier 2 ore in the ore pools. New players can't play this game if they have to scan 100 tiles to start making fuel to start playing the rest of the game. Sure they could theoretically buy space fuel, but that's not going to be affordable for new players if there's, again, less than 2% of tiles ever capable of producing it on the entire main planet.
 
Suggestion: Keep the majority of asteroids spawning on the weekend if that's the route you think is best, but maybe make some spawn during the week (unannounced). You could potentially try and use the ratio of online players. Example: if you have 70 players online Friday-Sunday and 30 online Monday-Thursday then 70% of the weekly asteroids spawn on the weekend and 30% spawn during the week. 
 
Mining Units
 
Opinion: The current production method is rather ridiculous that you're required to have tier 3 ore to be able to mine tier 3 ore. You mention it's a "chicken and egg" situation, but this is a game where you (Devs) can change what turns into a chicken. 
 
Suggestion: Just make the mining units function as the industry units do that works fairly well. Basic mining units can mine basic and uncommon ore to make the next one up. Uncommon mining units can mine basic, uncommon, and advanced ore to make the next unit up. Seems to make sense to me since you've already implemented this system with industry and it works pretty well in my opinion.
 
Subscription Price Increase
 
Opinion: Fine by me. I was afraid you were about to start charging up to $15 a month which would be absurd. $9.99 USD for a single month and if you buy a year it's still only $6.99 USD? As a few friends of mine constantly repeat and is still true: if you sacrifice two *insert popular coffee brand name here* drinks per month you just got 30 days access to a fully customizable sci-fi server world.
 
Now onto some older business that has, in my opinion, gotten pushed to the back of discussions
 
Warp Drives
 
Opinion: Love the speed reduction in making it feel like a real journey again instead of it being 5 seconds and you're at the farthest place you can get in this world. You could probably slow it down even more and I'd be okay with it even at 1,000,000 km/h instead of 2,500,000 km/h. My only sadness is with the still removed Lua functionality. 
 
Suggestion: After all the balances and adjustments to prevent PVP exploitation, and maybe one or two more to prevent unfair auto-warp, can we please get warp drive control back through Lua? What might help is if there is a way to prevent warp activation through Lua just in the PVP zone to stop the auto-warp on radar contact. There are so many projects I had to throw in a box and pack away for later because we don't have warp drive control anymore. The biggest problem I have with the system right now is there's NO way to block people from dropping out of warp on a ship they have access to. Would be real nice to un-bind alt+j from stopping warp at the very least so we can remove users ability to forcibly bring a ship into PVP space that we coded to not allow users to do. . If we could have full Lua control back that would be even better to make cool warp control scripts for more immersion. 
 
Question: Are we getting Lua control back someday?
 
Industry in General
 
Opinion: Please for the love of Novea fix these talent applications. I have some seriously cool projects I'm working on for industry display and control, but this guessing game of which talents are currently being applied to the schematics and how are they affecting the schematics and which version am I looking at is insanity. Sometimes efficiency skills reduce time, but sometimes it increases its production output and then also requires more material at a certain unknown threshold. Some talents are applying when looking at a schematic in the machine and some won't show their affect until you already started it and who knows which ones did what. 
 
Suggestion: Please just add a way for us to query a schematic's adjusted time, input, and output before and after talents and/or show us in the schematic info panel inside the industry unit what is happening from which talents. If you feel extra nice it would be great to have a blog/forum post somewhere as to how in the world they are supposed to be calculated to be able to figure out what materials we'll need for what without having to build the entire factory and start the machines first. 
 
Markets
 
Opinion: API when? With all these changes coming to ore acquisition which will help stabilize markets with static ore influx rates, we could really use something to get market data in game instead of all these semi-allowed "market log file readers" floating around. 
 
Suggestion: Lua API for highest buy/sell order, lowest buy/sell order, and average buy/sell order values and amounts for target item please. Would be even cooler if you added a planet ID parameter where if left blank it will query the entire market but if specified it will only query the data from the specified planetary body's markets. 
 
DRM Flag System
 
Opinion: Love it. I just want more control over it. Right now there is no way to sell someone a protected script. The only way to do so is to put the script on a new construct, DRM protect it, and sell the entire construct. There's no way currently to sell someone a protected script to add to an existing construct. If you think there's a work around through trading/tokenization/flag activation/deactivation/trading, there isn't trust me. I've tried every method and the buyer can always open and edit/take the script.
 
Suggestion: Please add a way to DRM a programming board with the Lua script on it. They have "dynamic properties" so is it difficult to add a DRM to one of those dynamic properties to communicate with the DRM flags when placed down after trading? 
 
Element Destruction
 
Opinion: The ownership loss on core destruction was obviously a terrible idea especially in the game's current state. Great for PVP and makes sense, but terrible for flying around the safe zone on planets. I don't fully understand why cores are no longer destroyed on ground collision anymore since they were previously before that PTS version and didn't result in the loss of your ship. Also what happened to recyclers actually recycling? I digress. I have some suggestions on how to bring all this back in a healthy way.
 
Suggestion: Before addressing the core lives and ownership loss, maybe just throw in element lives on the other stuff first. It would help the economy a lot to make people replace their wings after crashing so many times. 3 lives is definitely a little too harsh given the current game state. Maybe start off with 10 until it's more stable from all the client crashes. That may seem like too many lives to some, but we have infinite right now for collisions in the safe zone so 10 is better. 
 
Suggestion: Allow recyclers to break elements back down into parts based on lives. if an element requires 20 screw and has 9/10 lives left, allow it to be broken down for 18 of the 20 original screws. If an element takes a single large reinforced frame, then if its missing a life, the frame is damaged so you don.t get the 1 item back. Basically if the percent of lives left multiplied by the number of parts is less than 1, you don't get any of that part back because all of them are damaged. 
 
Suggestion: For core destruction, first of all, maybe there's a way to introduce another "type" of damage? So you have thermal damage/resistance, electromagnetic, and others. Maybe add another type call "structural" damage/resistance. This is so that the PVP damage and environmental damage are separately controllable by you guys (Devs). A core unit could have a much higher structural resistance so that core loss is more likely in PVP rather than accidentally crashing into a rock. A laser should be able to do much more damage to a core than a lump of snow. Secondly, maybe put a timer for ownership loss in the safe zone? This might be harder to implement since it would need to have different mechanics in the safe zone vs PVP zone, but it would be logical. If you blow the core on your ship, you already get a waypoint to where you died so add a 24 or 48 hours timer to it when it blows in the safe zone so you can decide if its worth going back for and can without losing everything.
 
Player Communications
 
Opinion: We really need a way to leave messages for players and/or be notified of communications outside the game. 
 
Suggestion: As I mentioned earlier in Territory Loss we really need some connection between in-game and out-of-game. Would be nice to get an email when someone wants to reach out to you in game or simply when you get a friend request. Would also be super useful if we had an inbox to send/check messages with for when you need to talk to someone who isn't online. Discord just isn't good enough since there's no guarantee they have the same name on Discord as the person you're trying to reach out to in game.
 
Energy Management
 
Question: Is this still a future thing?
 
Suggestion: This should be a thing.
 
Shoutout to @NQ-Deckard for being the Lua master who probably has all the answers and good luck reading all this Deckard/Pann
Keep going with the video Q&As I love these and it's why I decided to be involved on the forums again. You might need a whole other video just from my questions/suggestion in this one post!

I usually am not very active on the forums, but I decided I wanted to help combat some of the "hate" people have been spreading about this update and I'll do it in multiple sections to make it easier. I'll also bring some things up that have been put on the back burner, but I believe should be addressed sooner rather than when they become a major issue again.

TAXES
 
Opinion: 1 million quanta in this game is not nearly as much as most people think. If you log in for 7 days, you just paid for your territory tax for a single tile on top of the free one on sanctuary. You do not have to do a single thing other than log in then back out to earn the money for a territory of your choosing. This being said, NQ can easily change the rate after implementing the system and seeing what does happening instead of everyone guessing what might happen. Arguing about the rate before it is even implemented is not useful since everything will remain an "if." 
 
Territory Loss
 
Opinion: The game NEEDS this. We have way too many tiles claimed and too many obtrusive constructs owned by players who left the game. This is making the game feel abandoned in some areas instead of simply "unexplored" or "potentially useful" in those areas. These abandoned cities and towers and outposts are discouraging clutter and need to go. We also do need the system to continue purging abandoned materials from land. For the health and enjoyment for the active players and to attract new ones, we need this system. 
 
Suggestion: I'm not sure of the capabilities of linking in-game information to external registered accounts, but I believe we are seeing more and more need for a external connection to certain information. This territory loss mechanic is the largest need so far. We really do need a way by email to receive a notification of an abandoned tile construct being marked for excavation by another player. If someone is taking a break from the game but still has their active subscription and maybe ran out of tax funds, they shouldn't have to log in continuously to make sure their constructs aren't marked for excavation. A simple email notification from an in-game connection to it would go miles for relieving players of their worries and would be less deterring for players to branch out. I'll address another crucial need for this system under Player Communication.
 
Brakes
 
Opinion: To those complaining about new obstruction: I'm sorry, but move on. The obstruction arrows and indicators have been on the elements since the beginning of Beta. You should have known better and cannot act surprised that they are fixing what has clearly been a bug for ages. 
 
Question: Are we going to see the intended animation for the air brakes at some point?
Question: Will the obstruction areas be changed for the air brakes? Currently the area is towards the front of the model, but wouldn't they logically open upwards and it not matter what's in front of them so long as they can open?
 
Mining
 
Opinion: I'm on board with all the changes honestly. I will not miss digging holes being the most profitable source of income. Also thank you for increasing asteroids in the safe zone because the current 12-ish was definitely NOT enough. I get it low risk is low reward, but we're just talking wanting some tier 1 and 2 ore. My only complaint with the mining changes is some of the tier 2 ore scarcity is a little too extreme. Out of over 50 tiles on Alioth absolutely zero of them had any tier 2 or 3. I get it for the tier 3+ maybe this scarcity will make the game more interesting. However, the bare necessity of this game is fuel, specifically space fuel. How are people supposed to play the game if you can only make space fuel to start exploring on less than 2% of the tiles. This is too extreme. As for a scan wipe, I don't personally care. It's better to not wipe and see how it goes and maybe wipe and regenerate the ore pools later than to wipe it and then realize you shouldn't have.
 
Suggestion: We need more tier 2 ore in the ore pools. New players can't play this game if they have to scan 100 tiles to start making fuel to start playing the rest of the game. Sure they could theoretically buy space fuel, but that's not going to be affordable for new players if there's, again, less than 2% of tiles ever capable of producing it on the entire main planet.
 
Suggestion: Keep the majority of asteroids spawning on the weekend if that's the route you think is best, but maybe make some spawn during the week (unannounced). You could potentially try and use the ratio of online players. Example: if you have 70 players online Friday-Sunday and 30 online Monday-Thursday then 70% of the weekly asteroids spawn on the weekend and 30% spawn during the week. 
 
Mining Units
 
Opinion: The current production method is rather ridiculous that you're required to have tier 3 ore to be able to mine tier 3 ore. You mention it's a "chicken and egg" situation, but this is a game where you (Devs) can change what turns into a chicken. 
 
Suggestion: Just make the mining units function as the industry units do that works fairly well. Basic mining units can mine basic and uncommon ore to make the next one up. Uncommon mining units can mine basic, uncommon, and advanced ore to make the next unit up. Seems to make sense to me since you've already implemented this system with industry and it works pretty well in my opinion.
 
Subscription Price Increase
 
Opinion: Fine by me. I was afraid you were about to start charging up to $15 a month which would be absurd. $9.99 USD for a single month and if you buy a year it's still only $6.99 USD? As a few friends of mine constantly repeat and is still true: if you sacrifice two *insert popular coffee brand name here* drinks per month you just got 30 days access to a fully customizable sci-fi server world.
 
Now onto some older business that has, in my opinion, gotten pushed to the back of discussions
 
Warp Drives
 
Opinion: Love the speed reduction in making it feel like a real journey again instead of it being 5 seconds and you're at the farthest place you can get in this world. You could probably slow it down even more and I'd be okay with it even at 1,000,000 km/h instead of 2,500,000 km/h. My only sadness is with the still removed Lua functionality. 
 
Suggestion: After all the balances and adjustments to prevent PVP exploitation, and maybe one or two more to prevent unfair auto-warp, can we please get warp drive control back through Lua? What might help is if there is a way to prevent warp activation through Lua just in the PVP zone to stop the auto-warp on radar contact. There are so many projects I had to throw in a box and pack away for later because we don't have warp drive control anymore. The biggest problem I have with the system right now is there's NO way to block people from dropping out of warp on a ship they have access to. Would be real nice to un-bind alt+j from stopping warp at the very least so we can remove users ability to forcibly bring a ship into PVP space that we coded to not allow users to do. . If we could have full Lua control back that would be even better to make cool warp control scripts for more immersion. 
 
Question: Are we getting Lua control back someday?
 
Industry in General
 
Opinion: Please for the love of Novea fix these talent applications. I have some seriously cool projects I'm working on for industry display and control, but this guessing game of which talents are currently being applied to the schematics and how are they affecting the schematics and which version am I looking at is insanity. Sometimes efficiency skills reduce time, but sometimes it increases its production output and then also requires more material at a certain unknown threshold. Some talents are applying when looking at a schematic in the machine and some won't show their affect until you already started it and who knows which ones did what. 
 
Suggestion: Please just add a way for us to query a schematic's adjusted time, input, and output before and after talents and/or show us in the schematic info panel inside the industry unit what is happening from which talents. If you feel extra nice it would be great to have a blog/forum post somewhere as to how in the world they are supposed to be calculated to be able to figure out what materials we'll need for what without having to build the entire factory and start the machines first. 
 
Markets
 
Opinion: API when? With all these changes coming to ore acquisition which will help stabilize markets with static ore influx rates, we could really use something to get market data in game instead of all these semi-allowed "market log file readers" floating around. 
 
Suggestion: Lua API for highest buy/sell order, lowest buy/sell order, and average buy/sell order values and amounts for target item please. Would be even cooler if you added a planet ID parameter where if left blank it will query the entire market but if specified it will only query the data from the specified planetary body's markets. 
 
DRM Flag System
 
Opinion: Love it. I just want more control over it. Right now there is no way to sell someone a protected script. The only way to do so is to put the script on a new construct, DRM protect it, and sell the entire construct. There's no way currently to sell someone a protected script to add to an existing construct. If you think there's a work around through trading/tokenization/flag activation/deactivation/trading, there isn't trust me. I've tried every method and the buyer can always open and edit/take the script.
 
Suggestion: Please add a way to DRM a programming board with the Lua script on it. They have "dynamic properties" so is it difficult to add a DRM to one of those dynamic properties to communicate with the DRM flags when placed down after trading? 
 
Element Destruction
 
Opinion: The ownership loss on core destruction was obviously a terrible idea especially in the game's current state. Great for PVP and makes sense, but terrible for flying around the safe zone on planets. I don't fully understand why cores are no longer destroyed on ground collision anymore since they were previously before that PTS version and didn't result in the loss of your ship. Also what happened to recyclers actually recycling? I digress. I have some suggestions on how to bring all this back in a healthy way.
 
Suggestion: Before addressing the core lives and ownership loss, maybe just throw in element lives on the other stuff first. It would help the economy a lot to make people replace their wings after crashing so many times. 3 lives is definitely a little too harsh given the current game state. Maybe start off with 10 until it's more stable from all the client crashes. That may seem like too many lives to some, but we have infinite right now for collisions in the safe zone so 10 is better. 
 
Suggestion: Allow recyclers to break elements back down into parts based on lives. if an element requires 20 screw and has 9/10 lives left, allow it to be broken down for 18 of the 20 original screws. If an element takes a single large reinforced frame, then if its missing a life, the frame is damaged so you don.t get the 1 item back. Basically if the percent of lives left multiplied by the number of parts is less than 1, you don't get any of that part back because all of them are damaged. 
 
Suggestion: For core destruction, first of all, maybe there's a way to introduce another "type" of damage? So you have thermal damage/resistance, electromagnetic, and others. Maybe add another type call "structural" damage/resistance. This is so that the PVP damage and environmental damage are separately controllable by you guys (Devs). A core unit could have a much higher structural resistance so that core loss is more likely in PVP rather than accidentally crashing into a rock. A laser should be able to do much more damage to a core than a lump of snow. Secondly, maybe put a timer for ownership loss in the safe zone? This might be harder to implement since it would need to have different mechanics in the safe zone vs PVP zone, but it would be logical. If you blow the core on your ship, you already get a waypoint to where you died so add a 24 or 48 hours timer to it when it blows in the safe zone so you can decide if its worth going back for and can without losing everything.
 
Player Communications
 
Opinion: We really need a way to leave messages for players and/or be notified of communications outside the game. 
 
Suggestion: As I mentioned earlier in Territory Loss we really need some connection between in-game and out-of-game. Would be nice to get an email when someone wants to reach out to you in game or simply when you get a friend request. Would also be super useful if we had an inbox to send/check messages with for when you need to talk to someone who isn't online. Discord just isn't good enough since there's no guarantee they have the same name on Discord as the person you're trying to reach out to in game.
 
Energy Management
 
Question: Is this still a future thing?
 
Suggestion: This should be a thing.
 
Shoutout to @NQ-Deckard for being the Lua master who probably has all the answers and good luck reading all this Deckard/Pann
Keep going with the video Q&As I love these and it's why I decided to be involved on the forums again. You might need a whole other video just from my questions/suggestion in this one post!

Hi Noveans,
Thanks for the warm welcome! Since I've joined I've been amazed by the incredible job the Novaquark team is doing, working hard on delivering the dream of Dual Universe. I’m also very impressed by how you, our community, have been supporting the DU project from day one. Let's all keep moving forward together!
Cheers,
Nouredine

Voxels make up almost everything you see in the world of Dual Universe. Currently, most creations are made using the basic tools we provide with standard shapes such as cubes, spheres, cylinders, wedges, and tetrahedrons. 
 
More intricate designs can be achieved through the art of ‘voxelmancy’ where players customize the shapes of voxels using a variety of methods and techniques based on how voxels react to each other when placed. This very advanced technique allows voxelmancers to place each corner of a voxel exactly where they want it. To do that, they use what is called a ‘voxel reactor’.
 

 
Voxel reactors, as amazingly useful as they are, have three major drawbacks:
They are time consuming to use. They are not very intuitive for beginners. They are laid out in a checkered pattern in all three dimensions.  
The last item on that list poses some technical problems. 

VOXEL COMPLEXITY
When we are effectively applying a checkered pattern of voxels of different colors or even air, it creates a relatively large amount of small surfaces. This doesn’t really pose a problem for a single reactor, but can be a performance burden for some voxel libraries that consist of thousands of reactors.
 
With more and more detailed constructs of complex design being built, it’s become problematic for the ‘mesh service’ system that generates the shapes that you see when not in build mode. On a few rare occasions, highly-detailed constructs may not render at all or their honeycomb will disappear. 
 
To prevent this from happening, we will gradually implement a limitation to the complexity that can be created in a single chunk of voxels. It will start with a simple complexity gauge in Demeter:
With the launch of Demeter, you will start by seeing a new feedback gauge while building which highlights the region you’re actively working on and will appear as a bar in the HUD that indicates the complexity level of that region as a percentage.  In a future update (exact update number still to be discussed), we will introduce the eagerly-awaited vertex precision tool (Known to many of you as the fabled vertex editor) as a way to ensure that the limitation to voxel reactors doesn’t hinder players’ ability to create amazing constructs in the game. (More on that below.) In a subsequent future (and yet undefined) update, we will enforce the complexity value limit to be 100% for any new voxel operations. As such, old constructs and blueprints will not be altered by this but may become unalterable if they are above the limit in a region. Rest assured that if you have an existing construct that’s above the limitation, you will still be able to use it as is.  
With all that out of the way, let’s get to the fun part!

THE VERTEX PRECISION TOOL
There is currently a bit of a gap between learning how to build using the basic tools and more advanced voxelmancy techniques, something we’ve wanted to address for a long time. The introduction of the vertex precision tool in a future update will allow you to take any vertex (a corner of a voxel) and move it to a new location on any of its three axes inside the vertex's moveable area at different resolutions. This will provide an intuitive way that fills that crucial gap between basic building and advanced voxelmancy to fine-tune your builds.
 
See the video below for a demonstration of how this works. Please keep in mind that the video only shows an early prototype, but we think it’s already promising enough to make you as excited as we are about the possibilities of this tool.
 
 

 

 
VENI, VIDI, VOXIED
I came, I saw, I voxeled 
 
We hope that these voxelmancy changes, along with all of the great new Lua functions added in the Selene update, will inspire and encourage you to make even more amazing things than you already are. 
 
Check out our Tutorials page for even more ideas and tips on using voxels to bring your creativity to life in Dual Universe. 
 
As always, we’d love to hear your comments and answer your questions on the forum. 
 

offtopic:
 
NQ, keeping in touch / doing an Inside Star Cit... / DU video series is a good step in the proper direction.
 
Also the frequency of client / game updates is getting better.
 
Keep up the improved work.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Dual Universe: Ares (0.26.12) has launched! 
 
Earlier this month, we announced that the Ares update had been added to the Dual Universe public roadmap. Less than a month later, we’re pleased to announce that players can now enjoy all that Ares has to offer, from brand-new features to a long list of improvements. 
 
In many ways, Ares is a complementary companion to the Apollo (0.26) update. Released in August, Apollo introduced the first wave of PVP-centric assets, balancing, and features, such as Shields v1. 
 
Watch this video for a short (yet visually stunning!) overview of key features from both Apollo and Ares. 
 
 
Turning our attention back to Ares, here’s a topline view of the key facets of Ares, our fifth major update so far this year.  
 
New PvP-focused features
 
 
Core combat stress - In conjunction with core unit destruction, core combat stress gives weapons another way for all that delicious firepower to bring down the opposing construct. Depending on which side of the battle you’re on, this can be viewed as an additional victory or loss condition. (Hopefully victory. We believe in you!) Shields v2 - Shields were introduced in the Apollo update to amp up PvP gameplay. In Ares, shields acquired adjustable resistance and venting, giving them more depth, taking them from a purely passive accessory to a prized load-out that can have a big impact on the outcome of dust-ups.   
For a closer look at core combat stress and Shields v2, along with important information about ways we’ve closed the gate on some problem-causing PvP-related exploits, read Inside Ares, Part 1. 

Improvements to existing features 
 
Warp drive improvements -  Taking player feedback into account, we’ve made some adjustments to warp drives that will encourage pilots to employ a higher level of strategy. We’ve reduced warp speed, increased the cool-down time, added spooling, and several other tweaks and recalibrations, all of which should factor in for more excitement. Docking and boarding revamp - It’s yours and you should have control over who has access to it. The docking and boarding revamp makes nonconsensual boarding a thing of the past.   
Details about these changes can be found in our latest devblog, Inside Ares, Part 2. 
 
Full patch notes can be viewed here. 
 
Production is underway for our next update, Demeter, which will focus primarily on mining with the introduction of automated mining units and a revamp for territory management. As always, we’ll pave the way with devblogs and other Demeter-related content. 
 
In the meantime, we invite you to pose questions about the Apollo and Ares updates in this thread on our forum. We’ll answer what we can in an upcoming, postmortem-ish Q&A. 
 

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

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

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

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

Join the conversation here.
 

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

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

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

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

ALL ABOUT ASTEROIDS 
Ahh, those crunchy little rock nuggets, filled with fabulous sweet surprises. *nom nom nom* Okay, so they aren’t so little, and they probably aren’t all that delicious, but those sweet surprises are very, very real. Some say they smell like quanta.
 
Let’s take a look at asteroids, one of the key features coming in Apollo (0.26), now available on the public test server. What are they? What’s in them? How do you find them? How will they impact the gameplay of Dual Universe?
 
WHAT ASTEROIDS ARE, WHAT THEY HOLD
Asteroids are small, temporary celestial bodies. You will be able to track, discover, and mine them. They respawn in dispersed batches weekly, and asteroids in each batch will initially spawn over the first 24 hours.  
 
The addition of asteroids will bring some spicy elements to gameplay as they provide a real incentive for PvP other than mere pirating (not that there’s anything wrong with that if that’s your thing). Another upside is that locating and mining asteroids, along with transporting their bounty, will encourage cooperation and interaction between different groups of players. One can never have too many friends, right? 
 

 
At the end of the life cycle of these asteroids, they will be despawned, to make way for a new batch to spawn. For testing purposes, this is set to one week but is subject to change based on community feedback. 
 
And, last but not least, it’s always good to have another way to acquire resources. Asteroids are also more resource-rich than your average mining territory. The ore they contain is of varying tiers, depending on the area in which they are discovered. Higher tier ore will be found in the more dangerous PvP zones. The greater the risk, the higher the reward. 
 
HOW TO FIND THEM
Although it is technically possible to discover an asteroid as you’re roaming around in space, it’s more likely that you’ll need some mechanical assistance. 
 
Say hello to the deep space asteroid tracker (DSAT). It serves two general purposes: to display all existing asteroids in the system, regardless of their state, and to track undiscovered asteroids. Once an asteroid is discovered, you’ll use the DSAT to set a series of waypoints to it. 
 

 
The DSAT display panel shows: 
Rumored: Asteroids that exist but have not been discovered. Discovered: Asteroids that have been successfully discovered. Broadcast: The shared location of discovered asteroids.  Discovered countdown timer: The length of time remaining before broadcasting the location of a discovered asteroid. Scan: Click to begin scanning for an asteroid’s location.   

 
Information about the specific asteroid being scanned is displayed in the box above. The Rarity field shows the type of ore you will find there, ranging from Basic, Uncommon, Advanced, Rare and Exotic. 
 
From there, you can select an asteroid to track. The DSAT will ask you to scan several information points in the target area in order to zero in on the final location of the asteroid. These information points are unique for each player; sharing them won’t enable anyone else to speed through the scanning process. Once you have reached and scanned all the information points, the location of the asteroid will be revealed.
 
When someone touches down on the asteroid, the time starts ticking. In four hours, the location will be revealed in the Broadcast section of the DSAT display, visible to anyone with a DSAT unit.  
 
(Important note: The four-hour time limit is subject to change based on testing results and player feedback.) 
 
DIG IN
Good news for the lone wolves of the world: Single-player asteroid-hunting is completely feasible. It is about picking the right amount of risk and having a well-designed ship for dig-and-run action. A major perk of being the first to discover and begin mining an asteroid is that you’re pretty much guaranteed to pull out a few nodes of higher-tier-ore from the get-go. A tier-3 asteroid might contain a couple of tier-5 veins.
 
How long it will take to fully deplete all of the asteroid’s resources depends on a wide range of variables. How large is the crew? How good are they at working together? What equipment are they using? A well-oiled machine of a team with top-line equipment has the potential to complete the task before the four-hour broadcast timer dings. (Potential being the operative word there.) 
 
A more likely scenario is that you’ll have competition. Being the first to successfully locate the asteroid doesn’t give you exclusive rights to it. Anyone else can scan and locate it, too, or stumble upon it out of sheer luck. 
 
SWITCHING THINGS UP 
Although the basic mining gameplay and mechanics are in place, a big change for miners is that asteroids have extremely low gravity and no atmosphere to speak of, giving you the option to mine and dig entirely in jetpack mode if you so choose. 
 
Another significant departure is that with asteroids having the potential to spawn in PvP zones, this will also be the first time players can mine and fight in the same general area.
 
CHOICES
With plenty of options related to asteroids, you’ve got some important choices to make. 
Is your sole business to find asteroids and sell the location information to others before they are publicly broadcasted? Will you stick to the safe zones and leave the dangerous resource gathering to others? Do you use the Job Forum to hire help to mine and transport ore? Will you scour the skies looking for miners to loot?   These are simply a few possibilities. There are countless more, and endless stories of victory and defeat waiting to be told. 
 
What will your asteroid glory story be? Share it in the forums. 
 

Sample Scripts (Control Unit Interaction)
These scripts show some simple examples of Control Units interacting with screen units.
 
Light Control (Screen to Programming Board) This example demonstrates clickable buttons on a screen unit, that set the screens output to a value, the programming board reads that value and then clears it and toggles lights based on that data. (See the top section for the programming board code)
--[[---------------------------------------------------------------------------- -- Add the following section to a programming boards System.Update() -- Link the screen unit and three lights to the programming board -- Name the slots in the programming board respectively: screen, light0, light1, light2 local handlers = {} handlers['Light 0'] = function() light0.toggle() end handlers['Light 1'] = function() light1.toggle() end handlers['Light 2'] = function() light2.toggle() end local output = screen.getScriptOutput() if #output > 0 then screen.clearScriptOutput() if handlers[output] then handlers[output]() end end --]]---------------------------------------------------------------------------- -- Screen render script below -------------------------------------------------------------------------------- font = loadFont('Play-Bold', 32) rx, ry = getResolution() cx, cy = getCursor() layer = createLayer() click = getCursorPressed() -------------------------------------------------------------------------------- if not Button then local mt = {} mt.__index = mt function Button (text, x, y) return setmetatable({ text = text, x = x, y = y, }, mt) end function mt:draw () local sx, sy = self:getSize() local x0 = self.x - sx/2 local y0 = self.y - sy/2 local x1 = x0 + sx local y1 = y0 + sy local r, g, b = 0.3, 0.7, 1.0 if cx >= x0 and cx <= x1 and cy >= y0 and cy <= y1 then r, g, b = 1.0, 0.0, 0.4 if click then setOutput(self.text) end end setNextShadow(layer, 64, r, g, b, 0.3) setNextFillColor(layer, 0.1, 0.1, 0.1, 1) setNextStrokeColor(layer, r, g, b, 1) setNextStrokeWidth(layer, 2) addBoxRounded(layer, self.x - sx/2, self.y - sy/2, sx, sy, 4) setNextFillColor(layer, 1, 1, 1, 1) setNextTextAlign(layer, AlignH_Center, AlignV_Middle) addText(layer, font, self.text, self.x, self.y) end function mt:getSize () local sx, sy = getTextBounds(font, self.text) return sx + 32, sy + 16 end function mt:setPos (x, y) self.x, self.y = x, y end end function drawFree (elems) for i, v in ipairs(elems) do v:draw() end end function drawListV (elems, x, y) for i, v in ipairs(elems) do local sx, sy = v:getSize() v:setPos(x, y) v:draw() y = y + sy + 4 end end function drawUsage () local font = loadFont('FiraMono', 16) setNextTextAlign(layer, AlignH_Center, AlignV_Top) addText(layer, font, "Activate board to enable buttons!", rx/2, ry - 32) end function drawCursor () if cx < 0 then return end addLine(layer, cx - 12, cy - 12, cx + 12, cy + 12) addLine(layer, cx + 12, cy - 12, cx - 12, cy + 12) end -------------------------------------------------------------------------------- local buttons = { Button('Light 0', 128, 90), Button('Light 1', 128, 290), Button('Light 2', 128, 490), } drawFree(buttons) drawUsage() drawCursor() requestAnimationFrame(5)  

 
 
Light Control (Screen to Programming Board) This allows you to create and use toggle buttons for boolean values, the examples flip not only their own state, but also the horizontally neighbouring toggle.
--[[---------------------------------------------------------------------------- -- Add to programming board's unit.start() and connect it to this screen. local messages = { "Hi, I am a message!", "Yes hello this is Lua Screen.", "We love Pops the Hamster!", "WARNING: No warnings found.", "I am a screen unit.", "Are you enjoying this?", "Pending Screen Operations", "Lua Screen Units o/", "It is NOT NQ-Node\'s fault.", "Knock knock...", "Who's there?", "Ran out of Knock knock jokes.", "It is all NQ-Deckard\'s fault." } local message = messages[math.random(1, #messages)] local params = { message = message, testNumber = 1.337, testStr = 'hello I am a string', testTable = {x = 1, y = 0, k = {1, 2, 3, 4}}, } screen.setScriptInput(json.encode(params)) unit.exit() --]]---------------------------------------------------------------------------- -- Screen render script below -------------------------------------------------------------------------------- local json = require('dkjson') local params = json.decode(getInput()) or {} message = params.message or '[ no message ]' fontSize = params.fontSize or 64 color = params.color or {r=1.0,g=0,b=0.3} -------------------------------------------------------------------------------- local font = loadFont('Play-Bold', fontSize) local rx, ry = getResolution() local layer = createLayer() local cx, cy = getCursor() local sx, sy = getTextBounds(font, message) setDefaultStrokeColor(layer, Shape_Line, 1, 1, 1, 0.5) setNextShadow(layer, 64, color.r, color.g, color.b, 0.4) setNextFillColor(layer, color.r, color.g, color.b, 1.0) addBoxRounded(layer, (rx-sx-16)/2, (ry-sy-16)/2, sx+16, sy+16, 8) setNextFillColor(layer, 0, 0, 0, 1) setNextTextAlign(layer, AlignH_Center, AlignV_Middle) addText(layer, font, message, rx/2,ry/2) -------------------------------------------------------------------------------- local fontCache = {} function getFont (font, size) local k = font .. '_' .. tostring(size) if not fontCache[k] then fontCache[k] = loadFont(font, size) end return fontCache[k] end function drawUsage () local font = getFont('FiraMono', 16) setNextTextAlign(layer, AlignH_Center, AlignV_Top) addText(layer, font, "Activate for an exciting new message!", rx/2, ry - 32) end function drawCursor () if cx < 0 then return end if getCursorDown() then setDefaultShadow(layer, Shape_Line, 32, color.r, color.g, color.b, 0.5) end addLine(layer, cx - 12, cy - 12, cx + 12, cy + 12) addLine(layer, cx + 12, cy - 12, cx - 12, cy + 12) end function prettyStr (x) if type(x) == 'table' then local elems = {} for k, v in pairs(x) do table.insert(elems, string.format('%s = %s', prettyStr(k), prettyStr(v))) end return string.format('{%s}', table.concat(elems, ', ')) else return tostring(x) end end function drawParams () local font = getFont('RobotoMono', 11) setNextTextAlign(layer, AlignH_Left, AlignV_Bottom) addText(layer, font, "Script Parameters", 16, 16) local y = 32 for k, v in pairs(params) do setNextTextAlign(layer, AlignH_Left, AlignV_Bottom) addText(layer, font, k .. ' = ' .. prettyStr(v), 24, y) y = y + 12 end end -------------------------------------------------------------------------------- drawUsage() drawCursor() drawParams() requestAnimationFrame(1)  

Earlier this year, we presented our plans for the future of Dual Universe, following player feedback from the beta. Along with these plans, we had an internal roadmap, which we thought needed further refinement before being able to share it publicly, as we want to be able to give our community a reliable view of our plans. We now feel that this time has come, so here is the roadmap for the remainder of 2021. 
 
A few important things to note: 
This is a work in progress.  Dates may shift.  Features may be added or removed.  
Please also note that there is more further down the line, past 2021. We just want to be realistic about content and timings and start with delivering what we think is important for 2021. We hope to be working with you, our community, to deliver fun and interesting new features and improvements, thanks to our “new” release process, which includes the PTS, and to your ongoing feedback.
 
Which features on the roadmap are you most excited about?