Mjrlun

Hello Noveans!

We’re thrilled to introduce our newest, most innovative feature yet: Boxels!

For years, we’ve marveled at the boundless creative expression of our community using our voxel tech, from the reactor days of voxelmancy, to the VPT and beyond. Our players have built epic worlds, intricate machines, warships, factories, and flying insectoids. But, alas, even as we’ve enjoyed the countless masterpieces crafted, we couldn’t help but notice that something was wrong.

Our voxel technology, while enabling creative freedom, was paradoxically restricting the true artistic potential of our players. With a near-infinite number of possibilities, it was simply too daunting for players to express themselves properly. The number of choices was overwhelming, leaving players adrift in indecision while building in-game. That’s why we decided to think outside the voxel and give you: BOXELS!

We're upgrading our voxel building technology to Boxels, a set cubic shape for enhanced building in Dual Universe.
 

 

 


Here’s what our producer, NQ-Deckard has to say on Boxels:

“With DU's existing voxel systems, you have the freedom of moving any vertex of a voxel on a 3-dimensional 253-point grid; we do this in such a way to store a single 3D coordinate into 3 bytes of variable data.

But with our new Boxel technology, we've gone the extra mile to achieve higher levels of cubeness. As the Boxels are always just cubes, and nothing more than cubes, we decided to go above and beyond traditional precision for the never-changing corners of each Boxel by dedicating 4, 64bit, double precision floats to every single corner of every single Boxel. (The fourth one allows us to proudly say we are now the first 4D game!)

If you suffer the effects of high gas prices, don't worry, we've got you covered. Instead of using gas to heat your house, with Boxels, your CPU and Memory will now provide most of the heating your home requires.”

Boxels are your inner artist’s ticket to liberation from the oppressive chains of choice. No longer will you need to worry about crafting the perfect shape because our team of geometricians has created it for you! You’re guaranteed (but not actually guaranteed) to find the Boxel to meet your building needs.

With Boxels, you can confidently build knowing that our extensive (but not extensive) shapes library will ensure you’ll never feel overwhelmed by choice again!

We can’t wait to see your Boxel-based masterpieces in Helios. Stay tuned for more updates on our groundbreaking and innovative Boxel technology. Remember: When it comes to creative freedom, sometimes more is less!

Happy Boxel-ing, Noveans.

Yours Cubically,
The Novaquark Team
 

Will NQ unlock EAC for usage with Wine on Linux? I doubt the launcher will work, but it would be awesome to see this compatibility enabled. If this would require testing to ensure quality on Linux (regardless of decision), that information would be also appreciated.

Dear Noveans, 
 
We have made some changes today on the forum. Here are the most noticeable changes to make our communication more straightforward with the Community and help the new players: 
 
We separated Forum Rules and Announcements forum sections. There will soon be more threads in the Forum rules section to clarify some topics like Forum Warnings policy and a few other things. Players will now have the opportunity to reply and give their feedback directly in the Announcements forum section. This will prevent doubling the number of threads each time there is a need for feedback to an announcement. Warning: many announcements threads will be unpinned very soon, so don't be surprised if an old announcement thread will NOT appear at the top of the list in this forum section. Remaining pining threads will be either about recent announcements or old important announcements that are still worthy of being pinned. A full New Player Landing Zone, divided in 4 forum sections (Help forum section, FAQ forum section, Gameplay Tutorials and New player introductions. A few new forum sections in the General Category, dedicated to specific themes. The Gameplay Mechanics Assembly forum section will be closed soon. In the future, please use the new forum sections for specific topics. The "Idea Box" forum section will be closed soon as well: we thank you for all your input and ideas you have shared with us. However, right now, we already have a (very) long list of things that we want to add to the game. It doesn’t make much sense to ask for more suggestions and keep this section open for now, as we won’t be able to allocate much time for new ideas in the near future and may give the feeling that the team doesn’t listen to the Community. So we prefer to close it at the moment, and reopen it later when the developer team will have some bandwidth to take into consideration new ideas. You’re still more than welcome to share your feedback and suggestions on what to improve among the already existing features in the game in the thread dedicated to specific features! The opening of a PvP forum section. Please be aware that it’s an experimental section, so the rules about it may change quickly if needed and please try not to abuse the already more flexible rules for this section. French forum sections have been merged into one for the time being, due to limited activity. We might redevelop a few sections in the future, depending of the needs German forum sections have been merged into one for the time being, due to limited activity. We might redevelop a few sections in the future, depending of the needs Many Beta and Alpha sections have been archived, when they were not really active for at least a few months.
We hope you’ll enjoy this new layout! 
If you have any questions or comments about these changes, if you think there is a bug about some forum access or posting rights, please let us know!
 
The Novaquark Community Team.
 

Hello Noveans,

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

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

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

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

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

Greetings Noveans,
 
As many of you may have noticed, there have been no Market Bot buy orders available recently. We wanted to give you an update about this topic. 
 
The Market bots were initially designed to help kickstart the Helios economy for the launch of Dual Universe. It gave all Noveans a chance at earning more quanta at the beginning, in order to jumpstart the global in-game economy.
 
We have been closely watching the amount of quanta obtained selling to the Market Bots and we have determined that Market Bots are no longer needed and this ability has now been turned off, which means that players will no longer be able to sell to Market Bots.
 
A note from NQ-Entropy:
 
Just to establish some background, before Market Bots started running out, the T1 ore buy orders were the first quanta faucet in the game economy, with missions coming in second. Another point of note is that since the start of the game the total amount of quanta in the game has never stopped climbing. It was honestly a scary level of inflation for the early state of the game.

One of the reasons we had mentioned when we did the release wipe is that the economy was in trouble and the state and health of the economy is something we are paying especially close attention to after wipe. While we didn't communicate on this, and perhaps we should have, is that we knew we needed bot buy orders on launch, but we were unsure as to if and when we were going to refresh them. We know that there was some confusion about this and we do sincerely apologize for any miscommunication. However, it has become apparent that keeping bot orders refreshed would not be a good thing for the economy, and ultimately the game at large.

So let's talk about the game itself, there's a couple of things I want to mention. The realities of a game with a pseudo-economy and a real market is that we are in a basic version of supply and demand. If the supply for a resource is too high, the cost will fall. Unfortunately, it was too idealistic to think that everyone could free-farm a T1 ore territory cluster and make guaranteed (and quite high) profit. On average ore buy orders were seeding 3 to 4 times as much quanta as was being sinked by territory taxes.

The second thing I’d like to mention is that for most players there is no requirement for your territories to always be online. HQ territories still allow you to build and run industries. The only thing onlining a territory does is activate mining units and if it is unprofitable to do so, you may choose to offline/HQ your territories.

Territories and mining units were never meant as a means to print infinite money, sustainably, with no risk and limited effort. The tradeoff you are making when activating a territory and running mining units is paying tax for access to resources. What you do with those resources, and what is possible with those resources is up to you, and to an extent, the state of the game and its economy. It may be that it's a good time to make a profit on the market, but it may also be that you just need extra resources for honeycomb, scrap, or materials to run industries and make items you need.

If it is the case that the supply exceeds the demand, and as a result of that, prices sink, then it may be that the best solution for you is simply to go buy those cheap ressources at the market and take advantage of the surplus of resources. The more people do this, then demand should rise, and so will the cost, until we find some sort of equilibrium.
 
Adding another thing: Ultimately one of the main things that matter in all of this is fundamentally balancing our supply versus our demand. When it comes to T1 ore, the barrier to entry is incredibly low, even a starter character can have a basic mining unit setup over a couple territories in a few days. The question is, how many people as a rough percentage of the player-base are needed to supply the game with the resources that all players require? We fundamentally don't expect all players to need or want to gather resources, that's why markets exist. The real question is if that number is too high and too low. The issue that we are seeing now I believe is that while bots were still active, mining units were a good form of income for everyone, because the prices were artificially pumped up. That will not be the case anymore and we will have to find some form of equilibrium between people willing to farm resources and people who ultimately would prefer to buy them at a competitive price. For those staying in the MU field, as with any competitive endeavor, it will come down to organization, talents and preparation to stay competitive if you truly wish to make good profit selling ore from MU.
 
The counter-balance is that if resources were ever too expensive and demand was higher than supply, either due to some sort of market interdiction, or other similar phenomenon, anyone is free to pay for a couple territories to start flowing resources into the economy to rebalance the supply and demand or to acquire resources at a “cheaper” price. 

It could be that it requires too few people to supply the game with the resources it needs, and in that case, we have levers we can ultimately use to change the balancing of the game and make the demand higher, such as making crafting more resource demanding, or introducing more element sinks.

Finally, a note on buy and sell orders. We understand that without infinite buy orders the market feels less fluid. This is the reality of the size of our economy at this point in time. People will have to get more used to utilizing buy and sell orders as opposed to instant buy and sell. Don't get tricked by players putting up low buy orders, put up a sell order at a fair price and people will buy it. Make no mistake, people out there need ore, and are willing to pay for it.

We understand many of you enjoyed using the Market Bot orders, but ultimately this amount of quanta flowing into the economy could not last. We will be continuing to monitor the in-game economy very closely.

Hello, Noveans!
 
Update 1.1 has a release date!
 
If you’ve not seen this post yet, this update will bring Grid Snapping, Element Recycling, new talents, Steam achievements, and more to the game, as well as adding crowdfunding rewards such as pets, titles, skins, and emotes!
 

 
Our hotfixes have addressed many of the issues encountered since launch. We continue to improve the gameplay experience and are excited to build on Dual Universe with new features and systems, as NQ Kyrios had outlined before launch.

After careful consideration and seeing the outpouring from the community, we have decided to remove our building. Make no mistake as this isn't HexTek conceding to those of you who have harassed, stalked and even threatened us. For our organization, we would rather put our efforts into enjoying the game and playing how we feel. We made sure that we were not breaking any of the rules set out by the developers however this seems to have been taken out of context and assumptions have been made about our build. Our organization would rather play and enjoy the game and not be chased out of every platform because of who we are. We do not appreciate the threats to our lives, the constant harassment, and the slandering. We certainly never had any intention to grief or cause undue hardship to anyone playing the game. 
 
We would like to apologize to the NQ Staff who spent countless time dealing with this outpouring and helping to clarify the rules. We see no reason to have NQ's time spent on this rather than future development and possible content.
 
Thank you,
 
-Hextek

Greetings Noveans,

We are aware that some players are experiencing an issue with missing Sanctuary Territory Units (STUs) and other backer rewards.

We wanted to let everyone know that the team is working as quickly as we can to address these issues and we are working to resolve them as soon as possible.  We will update everyone when a resolution is in place.

Thanks to everyone for creating a support ticket about their missing STUs and alerting us of this issue. Unfortunately at this time, we cannot distribute STUs on an individual account basis. 

We apologize for any inconvenience that this might be causing and we want to thank you for your continued support as we work to resolve this issue. 

We hope you’re as excited as we are by the launch of Dual Universe. If you have any questions on the talent points boost, let us know below 👇

Who needs fireworks when you can just let a few shots off at some cores. Totally not exploitable.

Having a different explosion for the core is cool an all, but the explosions not doing any damage made it all look silly, and nobody is going to see any of those explosions unless you add a kill-cam to let the previous occupants of the now dead ship watch it blow before they respawn.
 
As for seeing explosions from battle-fields you aren't on, that would get annoying really fast once someone decided to just dump a bunch of cores and start popping them.

Maybe with such a huge core breach and explosion all elements should be destroyed. Only makes sense.

The core explosion is cute and all, but I feel you guys should make the effect so large that it can be seen from far, far away - up to 2su. It would be cool if you could see someone's core explode after you kill them in pvp. As it is, no one is going to see that effect - not the aggressor, and of course not the person who got destroyed.
 
If NQ wants to really improve the visuals of a battle, you guys need to render all weapon effects for everyone on the battlefield. It would make things so much cooler and interactive if we could see crisscrossing lasers and railguns everywhere.
 
I'm looking forward to the SSGI/SSAO. Ship interiors have long been too dark, even with many lights placed. Hopefully it works as advertised in those infographics. It didn't seem to do much on the PTS.

I made a whole post during the PTS if y'all havent seen it already

 

I made a whole post during the PTS if y'all havent seen it already

 

The Dual Universe roadmap has been expanded with the Panacea update, which is currently in production and brings with it a plethora of new features, tools, and improvements that will be particularly interesting for builders, scavengers, and Lua aficionados.
 
WHAT’S IN IT
 
A follow-up to the changes introduced in the Selene and Demeter updates, the Vertex Precision Tool will provide a powerful, intuitive way to fine-tune your builds. Particularly for those who are new to voxelmancy, this tool will be invaluable. Watch this video to get a taste of what it can do.
 
The introduction of shipwrecks in space will open a variety of lucrative opportunities for players who seek them out. Sell them as-is, salvage them for parts, create missions for other players to bring you the ship or its parts, or simply fetch a handsome price by selling the location information.
 
Other new features and improvements include: 
Camera Lua API: get access to information about the in-game camera Talents UI improvements: a more efficient way to view Talents RDMS UI polish: a cleaner interface for the management of RDMS  
To reduce clutter and keep Alioth beautiful, we are implementing inactive constructs requisitioning, an automated system for the abandonment of constructs owned by unsubscribed players and organizations to aid in keeping overcrowded public market areas clear.
Organization construct ownership (construct slots): a new way of assigning available construct limits to organizations. Disabling element stacking or overlapping: the final step in preventing the element stacking exploit.  
WHAT’S IN A NAME
 
Choosing the name for this update, Panacea, the goddess of remedy, is a reference to our renewed dedication to taking player feedback into greater consideration.
 
In reflecting on the aftermath of the Demeter release, we recognized that we fell short in this area. We read your feedback but did not make the adjustments we could and should have. We pledge to be better about working hand-in-hand with the community by implementing a plan to increase two-way communication and making some important tweaks and balancing to the game that will address some of the pain points as much as we’re able.
 
As a first step, beginning January 12th, we will postpone the next territory upkeep pay period for two weeks. This will allow the Design team time to revisit the tax rate, which many community members said was too steep. The purpose and functions of the upkeep system go beyond limiting “landgrabbing” and are more complex than they may appear on the surface. Many factors and interdependencies need to be taken into consideration.
 
WHAT’S NEXT
 
A series of devblogs will be published soon to reveal more information about the Panacea update. Additionally, we will be sharing a new roadmap soon. We hope that you’ll like what you see, and we encourage you to share your constructive feedback about our ideas as you read each article. 
Let’s chat! 

I really like this idea

What I like about the research table proposal is it gives more than just the research - like the emergent gameplay of sharing knowledge and schematics that you discuss. What I like the most however is the material sink that would go into the schematics, and the scarcity created by them, which should help regulate the economy in a more organic way than carnival tokens (quanta).

I actually agree about more realism to flying etc. But now is not the right time to add any more limitations to the game.
 
This game is already tedious at best, with players being forced to do mindless tasks all day long.
So before anything else, NQ has to add actual game play and ways to make income that does not suck the soul out of players.
 
And it is only after that we can start talking about potentially slowing down some stuff to balancing out the game.

Look up "Thaumcraft 4 research" and "Thaumonomicon" for reference.

Tech tree examples ^
 
 
In Thaumcraft you have a 'tech tree' and in this you can unlock various recipes for items (eg. schematics in DU). In this tech tree it gives a relatively defined path, however, sometimes the triggers to research steps are not clear. The user must unlock precursor items and precursor research point types, or trigger certain events to progress to the next step on the tree. However, the best part about this tree is when you click on an element on the tree there is usually a detailed description of the item (not just the item's tool tip description).
 
There is also a research table where you can scan various blocks (elements, voxels, honeycomb, and terrain decor in DU's case) for these research points of various types (ex. Terra, Lux, Aqua, etc.), which you can use in the research table to make patterns in a puzzle to unlock the recipe of an item. In DU's case this would translate to getting a schematic in return. Now, this could replace the need to sell schematics by bots, because the required stuff to make these researches could be engineered to only found after exploration (and prospecting). 
 

Left: List of various research point variants that the user can use for the research puzzle.
Right: The research puzzle itself, the pre-existing "nodes" must all be connected to each other in some way complete the puzzle.

These research points in Thaumcraft can be combined, and all but the most elemental are a form of 'recipe tree', where they are made by, or make other research point types. These research points connect in the puzzle to other research points that they either are made of 1 tier down, or make 1 tier up.
 
To scan there'd probably be talents related to it, as well as a tool to scan the various objects. Items could be further investigated by actually putting  them into the table. All items/objects should be scannable (to return some research points).
 
 
 
How to replicate a schematic once you "unlock" it at this table? The best way to enrich the replication of schematics is to add a new layer of depth to item scanning. Once you unlock certain parts of the tech tree, it should be possible to re-scan various elements (without telling the player what changed, after all, it's research). The player could then re-play the puzzle mini-game to attain more schematics. This should naturally create a limit on the amount of schematics possible by an individual, due to this budgeting.
 
Lastly, the research table "puzzle", unlike Thaumcraft, is fundamentally random to some extent. The player will always be presented with the same "research stems" in the puzzle, however, their positions are entirely random, unlike the original, making the replay-ability much higher.

I agree. Simply having a button to enable/disable it at will would be a nice feature.

Dear NQ,
 

 
You see this little thing? It's always there, taking up UI space. I'd love it if you guys added some way to hide this. It could be an option in the settings menu or moved into the context menu when you right click a construct (like with right-clicking to see player names).
 
In addition, the information it shows you while looking at a planet I feel is redundant and unnecessary:
 

 
The planet name and whether the territory is claimed can be observed through the map. As for the voxel material, there's already a key for that: H! While it's quicker to view it this way, I think it simply doesn't need to be, considering the value of the information you're actually gathering.
 
Just a small QoL thing that, for me personally, I'd love immensely. Never liked this label since the day it was added.

Player jetpacks vs. hover vessels
 
The sense of scale in this game has always been weird to me. When I started out back before having any talents, the world felt very big, and very mysterious. In this, a sense of immersion was there, not knowing what was over the hill in front of me, while also taking a long time to get there. This, of course, is no longer there in much manner.
 
Currently, the idea of a hover vessel is entirely overshadowed by a player's two feet (and a jetpack sprint), for literally any purpose other than short-distance lugging of some resources early game. Especially with a maxed out jetpack-sprint talent, you move at 81km/h, which is literally faster than a hovercraft that's trying to stay safe.
 
Additionally, players can jump extremely high with the use of a jetpack, with an oversimplified "refresh" method. Side note, but a better method is how Empyrion Galactic Survival does jetpacks. Google it

Due to these very simple, but highly underbalanced features, the sense of scale, immersion, and a need for hovercrafts is broken (as mentioned before). Therefore, buildings and ships feel much smaller, planets feel much smaller, to the point where even a kilometer feels much smaller (a KM in the real world takes a while, even in a car!). 
 
To fix this issue, of player movement being comparable to a hover craft, I suggest 2 major changes. First, remove the double tap sprint* (in this, of course reimburse the players that have it upgraded). It's quite confusing to have 2 different sprints, and on top, one that is objectively better than the other for literally all purposes but immersion. Removing this alone makes need for a ship of some form a lot more valuable (including slowing progression in a sense). My second suggestion regarding player jetpacks is to simply make the jetpacks very similar to Empyrion.
 
*Double tap sprint would just enable the normal sprint instead.
 
Mobility Part 2: Electric Boogaloo
Let's talk engineering and aerodynamics!

The second part of this post I wanted to direct attention to the engineering side of the game. There's 2 major problems within the game's progression and ship construction, of which stem from 1 major issue: calculations for proper center of lift, lift itself, are not very advanced.
 
The first of the two reasons for needing this is that hovercrafts, the most simple form of ship design, as well as normal omni-directional thrust space ships are almost extinct, due to literally being able to slap some wings on them and call it good.
 
While of course the major downsides of a change such as this would be scrapping a lot of designs that rely on wings to function, I see a lot more major upsides for at least me personally (and I'm sure others will agree with me).
 
First, ships that want to use aerodynamics (and wings) will have to prioritize proper shape, to optimize the amount of lift (and where the lift is located), will need to go through more rigorous engineering, and give more meaning to each ship crafted.
 
Due to this, planes will be a specific market, of which space ships (without wings), and hover crafts will once again have a purpose due to being more simple to engineer. Additionally, anti-gravity will be even more valuable to larger vessels, due to air-space maneuvers being much more difficult, and requiring more skilled piloting to do normally.
 
Continuing on, a better marketing image for the game, as well as an interest from the space ship engineering side of the community, would most likely arise from this. Due to the changes in how well crafted ships have to be, each ship will have a higher chance of looking more believable, and help with both marketing of the game (in luring people interested in aerospace engineering), and of course immersion. 
 
Lastly, major changes to ship progression within the game. This is because it would make each ship's thought toward the engineering side more pronounced, will make the progress slower, and for a lot of people more interesting and fun. Making your first proper plane will be an accomplishment, and if done right very rewarding (achievement tree for this stuff maybe?).
 
On a side note, similar problems that this change would highlight would be the flight model, which doesn't work very well for omni-directional thrusters, due to not having automatic dampening against gravity (see most other space piloting games, one of the best examples would be the flight model of Elite Dangerous for this matter imo).
 
What I would like to see specifically change to how wings and aerodynamics works is very similar to how Kerbal Space Program (and actual aero physics work). Firstly, surface area for not only drag purposes, but also rotational purposes would be appreciated.
 
The way this would work, is that you have pre-baked model wings to work with (of which are literally just props), but additionally have "ailerons", or a more simple name "control surfaces", of which are controlled using yaw/pitch/roll depending on how they are set, and help control your vessel.
 
While of course on their own, these mechanics don't really make sense in the current model, as aerodynamics don't exist (past drag), adding proper use for the cross sections of ships, as well as the aforementioned player-built wings, and pre-baked control surfaces, of which depending on how they are animated (extended, retracted, inverted extended) will apply to the cross section differently, would have 1 major effect. Due to the sudden change in the "air current" on one side compared to the other in terms of center of mass, and the surfaces seen (such as a control surface extended), would rotate the craft accordingly.
 
Going "too fast", and turning suddenly would create a sudden increase in lots of drag, of which of course would in turn rotate the ship, as well as not only (potentially) damage elements (due to drag and high G forces), but also decelerate the ship, causing it to fall, and also cause the player to lose control of the vessel, if they are not skilled enough. High stakes KSP, OUCH!
 
The final change that this would make is changes to air brakes, to become directional. First, I must preface this as "only if omni-directional thrust flight model is fixed". If it is not, this feature will make the game too difficult to actually brake properly not in a plane.
Since by themselves, air brakes only increase the amount of surface area of the plane, proper placement would be necessary to make them functional. The proper mechanic here would be more that they extend and retract, and the drag mechanic does the rest. Of course, their "goodness" is still given in a different quantity (surface area when extended) as a stat.
 
When piloting a plane, a player will have to use a combination of both braking properly to not decelerate too much to drop out of the sky, while also using drag of the wings to "skip in the air" (pull up, dive, repeat), to both glide with efficiency, as well as land.
Good piloting will of course be required with this feature. Did I mention that already?
 
The final change I'd make is indirect with the topic of aerodynamics, but more simply to do with space brakes. Since air brakes require more knowledge to use, a similar amount of thought should be put forward to make space brakes omni-directional, and apply thrust only where they are facing, of course the angled ones would also provide braking force to those directions as well.
 
Conclusion
While of course this post is 2 pronged, the first being the player jetpacks, the second being construct engineering, I felt that the topics combined in a way that they merited being in the same post. I hope that you enjoyed reading the post, as much as you hopefully want these feature changes in the game.

Now, before I start, I made a mention of this at the end of my post called "Quality of Life and beyond", however, to NQ directly: If able, I highly recommend employing 1 or more (coding) developers to permanently play test the game, and to fix any various bugs, and/or quality of life features thought up, because that would allow for better polish within the game for everyone, while also taking the least amount of time from the base development team. Additionally, just having some sort of board to post various small quality of life features internally from devs to devs, in case anyone has suggestions on such features and bug fixes, would also be highly productive.
 
UI changes
 
In build mode, the game doesn't really tell the player much about what elements are destroyed. It just says either "there are no elements damaged", or "there is at least 1 element damaged". The funny part about this, is there's literally LUA scripting that can detect damaged elements, and those specific elements (and their names) can be put on a screen, to tell the player what needs repairing. Of course, while this is great for LUA scripting, it is important to realize that the game cannot rely primarily on community made tools (unless you think Elite Dangerous is a perfectly designed game), and such, my suggestion is as follows:
 
Under the construct tab in the build helper, put a list of all damaged elements (if there is any). When they are double-clicked, highlight them (through everything) with a unique color that is distinct from the repairing tool's highlights (such as orange). This would persist when you get out of build mode, and would time out after a minute. Should the player start to repair the element damaged, it will persist till the element is fully repaired.
 
 
Another reference to my Quality of Life and beyond post, but better layout, and more dense information for item descriptions is sorely needed. Of course, you can find that post here. To build this, as well as upon other ideas under "Better Item/element descriptions", having better ways to judge element sizes without actually having to buy that element would be a great addition, for blueprinting, and visualizing ship builds. This of course can use pre-existing assets, with not too much effort (I hope?).

This feature would require its own tool most likely, named the "blueprint tool". Similar to the "element" tool, it allows players to place elements, but in this case, very differently. On the right side, where the selection for elements for placement occurs, a button above all of the elements in the list (named the "selection menu"), when opened will create an inventory-like menu which will house any and all elements that exist within the game (assuming polish exists), excludes elements that the player cannot access naturally. It would have a search function similar to a container menu, as well as filtering functions, and so on. The list would be alphabetical, to make it easier to find elements manually as well. Lastly, the right-click function would not work on any of the elements inside the menu, as well as any form of moving the elements around. All of their information (just like a container window) will appear on the right side of the inventory panel.
 
When it comes to actually using these items, it functions very similarly to the element placement tool. Firstly, you select elements the same way you select them with the element tool, however, of course only using the "element selection", menu, or (hypothetically), dragging elements into the bar as well from the player's inventory. When placing the element (with the same criteria as normal), instead of the actual element placing, a hologram-highlight would appear, in either light blue, or yellow. This hologram would only appear in build mode, and the player cannot collide with it either. Lastly, it of course would not be right clickable, and would be ignored with right-click. Lastly, alt-clicking the element with either the element tool, OR, the blueprint tool in hand would remove the hologram.
 
In markets, simple changes such as improvements to how linked containers interact with the market container UI, as well as simple changes such as removing the "instant buy" and "instant sell" buttons when there is no stock, as well as creating more search filters, such as "has stock at X market", or "tier X", etc. would also be great. Additionally, improvements to how items can be selected and moved (select multiple, and drag), as well as being able to select multiple items, and then click "move to inventory" and have all items move, instead of just that slot.
 
Finally, for the search function itself in all uses and forms, a better algorithm to include the sub-strings that match, not only just the search input string, would be greatly appreciated to find items that you don't know the precise name of, especially considering just how inconsistent the naming scheme is. In this, also having tags associated with item types, such as "Thruster" for all engines, or "alloy" to search for all alloys, etc. would make searching a lot easier and quicker.
 
Ship piloting improvements
 
Moving on to the default UI (and controlling) for construct controllers (cockpits, really), major improvements to both the UI, and functionality, would be a great idea. Of course, DU prides itself on community-made tools, and scripts, however, a development team should not sacrifice good quality of life for that "quirk". Additionally, a feature change would also allow the developers to clean up the LUA functions themselves, which is also a good thing.
 
 
To the first suggestion, major changes to the way that omni-directional thrust works would be a great idea for ships that use this feature. At the moment, the movement is very lack-luster, with literally just hover function included to make the ship float against gravity, and literally the rest is the same compared to normal throttle-design. There is no auto-dampening, such as many other games, and there is no "tap w to move forward slightly", like games such as Empyrion, and Space Engineers, which, while having more basic flight models, can be credited for it being very intuitive and smooth. The current version of this is nothing like this, and has a mish-mash of that feature, in every direction but forward and backward, but for those directions, uses throttle for acceleration. This of course ruins the primary perk of omni-directional thrust, which is the fine tuned aspect of piloting. Additionally, smaller features like having keybinds for specific throttle amounts would also be great to see.
 
To change both of these issues, I suggest the following. First, for auto-dampeners, have a button that auto-toggles between 3 different modes (identical to Empyrion, btw). No dampening, gravity-dampening, and full dampening. These different modes are self explanatory, just observe the mechanics in those games.
For the actual movement changes, to counteract the issue of not having a throttle slider, having a key bind once again that locks the current state of acceleration from the thrusters would be the solution here. To clarify acceleration, I mean what the thrusters are currently doing/outputting. changing any movement manually would cancel this, as well as pressing the button again. 
 
If you wanted to get more fancy with these two features, to make them not clash, having a distinction between what the dampeners are doing, compared to what the player has inputted would be my solution to this. The auto-dampeners would work separately to the thruster-lock, and in this would allow the ship to still stay airborne without constant adjustment.
 
 
Moving onto the UI itself (assuming that the features above have indicators within the UI), decluttering the different UI boxes to be more clean, and take up less of the screen would be preferable. Currently, when attaching a weapon of some form to a flight seat, the amount of UI that it introduces clutters the screen so bad, that in my experience makes it nearly unusable for piloting. I do not have a suggestion really to fix this, however, the issue is still persistent, and bugs me greatly. 

Secondly, there is literally a scroll bar for a cockpit that uses mouse wheel for the throttle. Due to this, the information hidden by this is lost due to this issue. 

 
Additionally, some tiny improvements to fuel tanks within the piloting UI, adding a number to indicate the fraction of fuel compared to the total would be helpful for fuel usage calculations on the fly. An example as simple as this would suffice in my opinion.

 
Tank relays/Tank hubs
I'm sure this feature has been suggested basically everywhere, but the amount of flexibility this feature would provide for ship designs makes it a great suggestion for this post. My take on this is as follows. Similar to a container hub, it connects tanks. While this is cool and all, there are 3 different types of tanks in the game, of which are not compatible. In this, my suggestion to solve this is to color code a tank hub (change its coloration of the texture itself) when it connects to a type of tank. Light-blue for Nitron, yellow for Kergon, and white for Xeron. While a type is active, when attempting to connect a tank of different type to it, an error message will appear, stating that different tank types cannot connect to a tank hub at once. Lastly, when there are no connections to the tank hub, it reverts to the original state (and texture).
 
Gameplay Balance
 
While at this rate you could probably claim I'm sponsored by Empyrion Galactic Survival or something, I just really like the game. In this, a lot of survival-oriented features in that game I find quite compatible and important for this game to exhibit in some manner as well. Starting with the biggest issue in my opinion, ore distribution and the tech tree.
 
Currently, limestone and malachite are only present on the same body on Alioth, where they are used to craft tier 2 components. This issue with this is the following: You cannot craft tier 2 components without a static core, and therefore by extension a territory unit, which that territory unit requires tier 2 components. Due to this, it is physically IMPOSSIBLE to start from scratch on any celestial body in the star system in almost any manner, therefore breaking a core gameplay pillar (in my opinion) of any progression-based game, something Empyrion (for example) does incredibly well. In that game, you can get to the end game in almost any situation from scratch (no matter if it's extremely difficult), due to the nature of the progression. 
 
To fix this major issue, excluding of course the need for Malachite and Limestone to exist on all celestial bodies (in my opinion), allowing territory units to be crafted using tier 1 components, AND in a nanocrafter I see as a necessity for this game. Of course, it would have to be highly expensive in that regard, and additionally take a long time to craft (example being 6-12 hours).
 
 
Switching to a similar topic, brought up in the previous feature mention, a change of ore distribution and planet revamp is sorely in need. While of course a planet revamp is not a quality of life feature that is simple to answer (and solve), the ore distribution, which of course requires a planet revamp, is highly important to the current progression of the game. Without good level design, a game will most likely suffer for that issue. I do plan on making a post about the planet revamp though, so ill link it here when it happens. Anyways.

Take this situation: Currently, you can get stranded on a moon. These moons do not exhibit atmosphere, and a lot of them do not contain tier 2 ore either. Due to this issue, it is physically impossible to progress without a market, and to even move a ship starting with no fuel. Because of this chicken and egg issue, the player physically cannot get off of a celestial body without any tier 2's, due to space engines (and technically rocket engines) being impossible to fuel without them, and being required to move in space properly.
 
Funnily enough, the player can craft space engines (and tanks) in their nanocrafter, but of course cannot fuel them, making that feature quite questionable.
 
 
Lastly, any major changes to progression can be linked here. This post is about player movement, as well as ship diversity, engineering, and piloting.
 
 
This post will be updated over time, and in that, any major changes will have a call-back post which will link back to this page. Thanks for reading!

Now, before I start, I made a mention of this at the end of my post called "Quality of Life and beyond", however, to NQ directly: If able, I highly recommend employing 1 or more (coding) developers to permanently play test the game, and to fix any various bugs, and/or quality of life features thought up, because that would allow for better polish within the game for everyone, while also taking the least amount of time from the base development team. Additionally, just having some sort of board to post various small quality of life features internally from devs to devs, in case anyone has suggestions on such features and bug fixes, would also be highly productive.
 
UI changes
 
In build mode, the game doesn't really tell the player much about what elements are destroyed. It just says either "there are no elements damaged", or "there is at least 1 element damaged". The funny part about this, is there's literally LUA scripting that can detect damaged elements, and those specific elements (and their names) can be put on a screen, to tell the player what needs repairing. Of course, while this is great for LUA scripting, it is important to realize that the game cannot rely primarily on community made tools (unless you think Elite Dangerous is a perfectly designed game), and such, my suggestion is as follows:
 
Under the construct tab in the build helper, put a list of all damaged elements (if there is any). When they are double-clicked, highlight them (through everything) with a unique color that is distinct from the repairing tool's highlights (such as orange). This would persist when you get out of build mode, and would time out after a minute. Should the player start to repair the element damaged, it will persist till the element is fully repaired.
 
 
Another reference to my Quality of Life and beyond post, but better layout, and more dense information for item descriptions is sorely needed. Of course, you can find that post here. To build this, as well as upon other ideas under "Better Item/element descriptions", having better ways to judge element sizes without actually having to buy that element would be a great addition, for blueprinting, and visualizing ship builds. This of course can use pre-existing assets, with not too much effort (I hope?).

This feature would require its own tool most likely, named the "blueprint tool". Similar to the "element" tool, it allows players to place elements, but in this case, very differently. On the right side, where the selection for elements for placement occurs, a button above all of the elements in the list (named the "selection menu"), when opened will create an inventory-like menu which will house any and all elements that exist within the game (assuming polish exists), excludes elements that the player cannot access naturally. It would have a search function similar to a container menu, as well as filtering functions, and so on. The list would be alphabetical, to make it easier to find elements manually as well. Lastly, the right-click function would not work on any of the elements inside the menu, as well as any form of moving the elements around. All of their information (just like a container window) will appear on the right side of the inventory panel.
 
When it comes to actually using these items, it functions very similarly to the element placement tool. Firstly, you select elements the same way you select them with the element tool, however, of course only using the "element selection", menu, or (hypothetically), dragging elements into the bar as well from the player's inventory. When placing the element (with the same criteria as normal), instead of the actual element placing, a hologram-highlight would appear, in either light blue, or yellow. This hologram would only appear in build mode, and the player cannot collide with it either. Lastly, it of course would not be right clickable, and would be ignored with right-click. Lastly, alt-clicking the element with either the element tool, OR, the blueprint tool in hand would remove the hologram.
 
In markets, simple changes such as improvements to how linked containers interact with the market container UI, as well as simple changes such as removing the "instant buy" and "instant sell" buttons when there is no stock, as well as creating more search filters, such as "has stock at X market", or "tier X", etc. would also be great. Additionally, improvements to how items can be selected and moved (select multiple, and drag), as well as being able to select multiple items, and then click "move to inventory" and have all items move, instead of just that slot.
 
Finally, for the search function itself in all uses and forms, a better algorithm to include the sub-strings that match, not only just the search input string, would be greatly appreciated to find items that you don't know the precise name of, especially considering just how inconsistent the naming scheme is. In this, also having tags associated with item types, such as "Thruster" for all engines, or "alloy" to search for all alloys, etc. would make searching a lot easier and quicker.
 
Ship piloting improvements
 
Moving on to the default UI (and controlling) for construct controllers (cockpits, really), major improvements to both the UI, and functionality, would be a great idea. Of course, DU prides itself on community-made tools, and scripts, however, a development team should not sacrifice good quality of life for that "quirk". Additionally, a feature change would also allow the developers to clean up the LUA functions themselves, which is also a good thing.
 
 
To the first suggestion, major changes to the way that omni-directional thrust works would be a great idea for ships that use this feature. At the moment, the movement is very lack-luster, with literally just hover function included to make the ship float against gravity, and literally the rest is the same compared to normal throttle-design. There is no auto-dampening, such as many other games, and there is no "tap w to move forward slightly", like games such as Empyrion, and Space Engineers, which, while having more basic flight models, can be credited for it being very intuitive and smooth. The current version of this is nothing like this, and has a mish-mash of that feature, in every direction but forward and backward, but for those directions, uses throttle for acceleration. This of course ruins the primary perk of omni-directional thrust, which is the fine tuned aspect of piloting. Additionally, smaller features like having keybinds for specific throttle amounts would also be great to see.
 
To change both of these issues, I suggest the following. First, for auto-dampeners, have a button that auto-toggles between 3 different modes (identical to Empyrion, btw). No dampening, gravity-dampening, and full dampening. These different modes are self explanatory, just observe the mechanics in those games.
For the actual movement changes, to counteract the issue of not having a throttle slider, having a key bind once again that locks the current state of acceleration from the thrusters would be the solution here. To clarify acceleration, I mean what the thrusters are currently doing/outputting. changing any movement manually would cancel this, as well as pressing the button again. 
 
If you wanted to get more fancy with these two features, to make them not clash, having a distinction between what the dampeners are doing, compared to what the player has inputted would be my solution to this. The auto-dampeners would work separately to the thruster-lock, and in this would allow the ship to still stay airborne without constant adjustment.
 
 
Moving onto the UI itself (assuming that the features above have indicators within the UI), decluttering the different UI boxes to be more clean, and take up less of the screen would be preferable. Currently, when attaching a weapon of some form to a flight seat, the amount of UI that it introduces clutters the screen so bad, that in my experience makes it nearly unusable for piloting. I do not have a suggestion really to fix this, however, the issue is still persistent, and bugs me greatly. 

Secondly, there is literally a scroll bar for a cockpit that uses mouse wheel for the throttle. Due to this, the information hidden by this is lost due to this issue. 

 
Additionally, some tiny improvements to fuel tanks within the piloting UI, adding a number to indicate the fraction of fuel compared to the total would be helpful for fuel usage calculations on the fly. An example as simple as this would suffice in my opinion.

 
Tank relays/Tank hubs
I'm sure this feature has been suggested basically everywhere, but the amount of flexibility this feature would provide for ship designs makes it a great suggestion for this post. My take on this is as follows. Similar to a container hub, it connects tanks. While this is cool and all, there are 3 different types of tanks in the game, of which are not compatible. In this, my suggestion to solve this is to color code a tank hub (change its coloration of the texture itself) when it connects to a type of tank. Light-blue for Nitron, yellow for Kergon, and white for Xeron. While a type is active, when attempting to connect a tank of different type to it, an error message will appear, stating that different tank types cannot connect to a tank hub at once. Lastly, when there are no connections to the tank hub, it reverts to the original state (and texture).
 
Gameplay Balance
 
While at this rate you could probably claim I'm sponsored by Empyrion Galactic Survival or something, I just really like the game. In this, a lot of survival-oriented features in that game I find quite compatible and important for this game to exhibit in some manner as well. Starting with the biggest issue in my opinion, ore distribution and the tech tree.
 
Currently, limestone and malachite are only present on the same body on Alioth, where they are used to craft tier 2 components. This issue with this is the following: You cannot craft tier 2 components without a static core, and therefore by extension a territory unit, which that territory unit requires tier 2 components. Due to this, it is physically IMPOSSIBLE to start from scratch on any celestial body in the star system in almost any manner, therefore breaking a core gameplay pillar (in my opinion) of any progression-based game, something Empyrion (for example) does incredibly well. In that game, you can get to the end game in almost any situation from scratch (no matter if it's extremely difficult), due to the nature of the progression. 
 
To fix this major issue, excluding of course the need for Malachite and Limestone to exist on all celestial bodies (in my opinion), allowing territory units to be crafted using tier 1 components, AND in a nanocrafter I see as a necessity for this game. Of course, it would have to be highly expensive in that regard, and additionally take a long time to craft (example being 6-12 hours).
 
 
Switching to a similar topic, brought up in the previous feature mention, a change of ore distribution and planet revamp is sorely in need. While of course a planet revamp is not a quality of life feature that is simple to answer (and solve), the ore distribution, which of course requires a planet revamp, is highly important to the current progression of the game. Without good level design, a game will most likely suffer for that issue. I do plan on making a post about the planet revamp though, so ill link it here when it happens. Anyways.

Take this situation: Currently, you can get stranded on a moon. These moons do not exhibit atmosphere, and a lot of them do not contain tier 2 ore either. Due to this issue, it is physically impossible to progress without a market, and to even move a ship starting with no fuel. Because of this chicken and egg issue, the player physically cannot get off of a celestial body without any tier 2's, due to space engines (and technically rocket engines) being impossible to fuel without them, and being required to move in space properly.
 
Funnily enough, the player can craft space engines (and tanks) in their nanocrafter, but of course cannot fuel them, making that feature quite questionable.
 
 
Lastly, any major changes to progression can be linked here. This post is about player movement, as well as ship diversity, engineering, and piloting.
 
 
This post will be updated over time, and in that, any major changes will have a call-back post which will link back to this page. Thanks for reading!

Now, before I start, I made a mention of this at the end of my post called "Quality of Life and beyond", however, to NQ directly: If able, I highly recommend employing 1 or more (coding) developers to permanently play test the game, and to fix any various bugs, and/or quality of life features thought up, because that would allow for better polish within the game for everyone, while also taking the least amount of time from the base development team. Additionally, just having some sort of board to post various small quality of life features internally from devs to devs, in case anyone has suggestions on such features and bug fixes, would also be highly productive.
 
UI changes
 
In build mode, the game doesn't really tell the player much about what elements are destroyed. It just says either "there are no elements damaged", or "there is at least 1 element damaged". The funny part about this, is there's literally LUA scripting that can detect damaged elements, and those specific elements (and their names) can be put on a screen, to tell the player what needs repairing. Of course, while this is great for LUA scripting, it is important to realize that the game cannot rely primarily on community made tools (unless you think Elite Dangerous is a perfectly designed game), and such, my suggestion is as follows:
 
Under the construct tab in the build helper, put a list of all damaged elements (if there is any). When they are double-clicked, highlight them (through everything) with a unique color that is distinct from the repairing tool's highlights (such as orange). This would persist when you get out of build mode, and would time out after a minute. Should the player start to repair the element damaged, it will persist till the element is fully repaired.
 
 
Another reference to my Quality of Life and beyond post, but better layout, and more dense information for item descriptions is sorely needed. Of course, you can find that post here. To build this, as well as upon other ideas under "Better Item/element descriptions", having better ways to judge element sizes without actually having to buy that element would be a great addition, for blueprinting, and visualizing ship builds. This of course can use pre-existing assets, with not too much effort (I hope?).

This feature would require its own tool most likely, named the "blueprint tool". Similar to the "element" tool, it allows players to place elements, but in this case, very differently. On the right side, where the selection for elements for placement occurs, a button above all of the elements in the list (named the "selection menu"), when opened will create an inventory-like menu which will house any and all elements that exist within the game (assuming polish exists), excludes elements that the player cannot access naturally. It would have a search function similar to a container menu, as well as filtering functions, and so on. The list would be alphabetical, to make it easier to find elements manually as well. Lastly, the right-click function would not work on any of the elements inside the menu, as well as any form of moving the elements around. All of their information (just like a container window) will appear on the right side of the inventory panel.
 
When it comes to actually using these items, it functions very similarly to the element placement tool. Firstly, you select elements the same way you select them with the element tool, however, of course only using the "element selection", menu, or (hypothetically), dragging elements into the bar as well from the player's inventory. When placing the element (with the same criteria as normal), instead of the actual element placing, a hologram-highlight would appear, in either light blue, or yellow. This hologram would only appear in build mode, and the player cannot collide with it either. Lastly, it of course would not be right clickable, and would be ignored with right-click. Lastly, alt-clicking the element with either the element tool, OR, the blueprint tool in hand would remove the hologram.
 
In markets, simple changes such as improvements to how linked containers interact with the market container UI, as well as simple changes such as removing the "instant buy" and "instant sell" buttons when there is no stock, as well as creating more search filters, such as "has stock at X market", or "tier X", etc. would also be great. Additionally, improvements to how items can be selected and moved (select multiple, and drag), as well as being able to select multiple items, and then click "move to inventory" and have all items move, instead of just that slot.
 
Finally, for the search function itself in all uses and forms, a better algorithm to include the sub-strings that match, not only just the search input string, would be greatly appreciated to find items that you don't know the precise name of, especially considering just how inconsistent the naming scheme is. In this, also having tags associated with item types, such as "Thruster" for all engines, or "alloy" to search for all alloys, etc. would make searching a lot easier and quicker.
 
Ship piloting improvements
 
Moving on to the default UI (and controlling) for construct controllers (cockpits, really), major improvements to both the UI, and functionality, would be a great idea. Of course, DU prides itself on community-made tools, and scripts, however, a development team should not sacrifice good quality of life for that "quirk". Additionally, a feature change would also allow the developers to clean up the LUA functions themselves, which is also a good thing.
 
 
To the first suggestion, major changes to the way that omni-directional thrust works would be a great idea for ships that use this feature. At the moment, the movement is very lack-luster, with literally just hover function included to make the ship float against gravity, and literally the rest is the same compared to normal throttle-design. There is no auto-dampening, such as many other games, and there is no "tap w to move forward slightly", like games such as Empyrion, and Space Engineers, which, while having more basic flight models, can be credited for it being very intuitive and smooth. The current version of this is nothing like this, and has a mish-mash of that feature, in every direction but forward and backward, but for those directions, uses throttle for acceleration. This of course ruins the primary perk of omni-directional thrust, which is the fine tuned aspect of piloting. Additionally, smaller features like having keybinds for specific throttle amounts would also be great to see.
 
To change both of these issues, I suggest the following. First, for auto-dampeners, have a button that auto-toggles between 3 different modes (identical to Empyrion, btw). No dampening, gravity-dampening, and full dampening. These different modes are self explanatory, just observe the mechanics in those games.
For the actual movement changes, to counteract the issue of not having a throttle slider, having a key bind once again that locks the current state of acceleration from the thrusters would be the solution here. To clarify acceleration, I mean what the thrusters are currently doing/outputting. changing any movement manually would cancel this, as well as pressing the button again. 
 
If you wanted to get more fancy with these two features, to make them not clash, having a distinction between what the dampeners are doing, compared to what the player has inputted would be my solution to this. The auto-dampeners would work separately to the thruster-lock, and in this would allow the ship to still stay airborne without constant adjustment.
 
 
Moving onto the UI itself (assuming that the features above have indicators within the UI), decluttering the different UI boxes to be more clean, and take up less of the screen would be preferable. Currently, when attaching a weapon of some form to a flight seat, the amount of UI that it introduces clutters the screen so bad, that in my experience makes it nearly unusable for piloting. I do not have a suggestion really to fix this, however, the issue is still persistent, and bugs me greatly. 

Secondly, there is literally a scroll bar for a cockpit that uses mouse wheel for the throttle. Due to this, the information hidden by this is lost due to this issue. 

 
Additionally, some tiny improvements to fuel tanks within the piloting UI, adding a number to indicate the fraction of fuel compared to the total would be helpful for fuel usage calculations on the fly. An example as simple as this would suffice in my opinion.

 
Tank relays/Tank hubs
I'm sure this feature has been suggested basically everywhere, but the amount of flexibility this feature would provide for ship designs makes it a great suggestion for this post. My take on this is as follows. Similar to a container hub, it connects tanks. While this is cool and all, there are 3 different types of tanks in the game, of which are not compatible. In this, my suggestion to solve this is to color code a tank hub (change its coloration of the texture itself) when it connects to a type of tank. Light-blue for Nitron, yellow for Kergon, and white for Xeron. While a type is active, when attempting to connect a tank of different type to it, an error message will appear, stating that different tank types cannot connect to a tank hub at once. Lastly, when there are no connections to the tank hub, it reverts to the original state (and texture).
 
Gameplay Balance
 
While at this rate you could probably claim I'm sponsored by Empyrion Galactic Survival or something, I just really like the game. In this, a lot of survival-oriented features in that game I find quite compatible and important for this game to exhibit in some manner as well. Starting with the biggest issue in my opinion, ore distribution and the tech tree.
 
Currently, limestone and malachite are only present on the same body on Alioth, where they are used to craft tier 2 components. This issue with this is the following: You cannot craft tier 2 components without a static core, and therefore by extension a territory unit, which that territory unit requires tier 2 components. Due to this, it is physically IMPOSSIBLE to start from scratch on any celestial body in the star system in almost any manner, therefore breaking a core gameplay pillar (in my opinion) of any progression-based game, something Empyrion (for example) does incredibly well. In that game, you can get to the end game in almost any situation from scratch (no matter if it's extremely difficult), due to the nature of the progression. 
 
To fix this major issue, excluding of course the need for Malachite and Limestone to exist on all celestial bodies (in my opinion), allowing territory units to be crafted using tier 1 components, AND in a nanocrafter I see as a necessity for this game. Of course, it would have to be highly expensive in that regard, and additionally take a long time to craft (example being 6-12 hours).
 
 
Switching to a similar topic, brought up in the previous feature mention, a change of ore distribution and planet revamp is sorely in need. While of course a planet revamp is not a quality of life feature that is simple to answer (and solve), the ore distribution, which of course requires a planet revamp, is highly important to the current progression of the game. Without good level design, a game will most likely suffer for that issue. I do plan on making a post about the planet revamp though, so ill link it here when it happens. Anyways.

Take this situation: Currently, you can get stranded on a moon. These moons do not exhibit atmosphere, and a lot of them do not contain tier 2 ore either. Due to this issue, it is physically impossible to progress without a market, and to even move a ship starting with no fuel. Because of this chicken and egg issue, the player physically cannot get off of a celestial body without any tier 2's, due to space engines (and technically rocket engines) being impossible to fuel without them, and being required to move in space properly.
 
Funnily enough, the player can craft space engines (and tanks) in their nanocrafter, but of course cannot fuel them, making that feature quite questionable.
 
 
Lastly, any major changes to progression can be linked here. This post is about player movement, as well as ship diversity, engineering, and piloting.
 
 
This post will be updated over time, and in that, any major changes will have a call-back post which will link back to this page. Thanks for reading!