Mjrlun

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.

To me it seems like the tactical hud is a placeholder markup gone rogue. Good to know though that they're aiming for something elite quality 🤔

Do these boosts stack? For example (as an alpha player), if I buy sub over 13 months (as an example), but also have the Contributor Pack, do I just get Exotic, or do I also get Rare? Does this apply universally, so if I had paid 6 months in sub, and was a Contributor, would I get Rare twice?

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

[Redacted, wrong forum section]

[Redacted, wrong forum section]

Where I'm coming from is that you can slow down a game regardless of its completeness as long as you make it enjoyable. Especially when you consider all the artificial ways they are trying to slow down progression - instead create a bunch of organic pockets (that are enjoyable in their own right), focus on those, combine them, and continue.

I would like to mention that DU was not originally designed for players to move at such speeds, especially in the context of hover vessels. You are intended to make early game hover vessels to get stuff done - there's a lot that needs fleshing out on this front. From the perspective of literal distance, it makes little sense that the player can move as fast as a vehicle in a universe so small anyways. The issues with these hover engines as you mention are the trees. That should be a challenge. Why? The scale of the game matters intensely with how players spread out, how fast the player progresses, and also, if done right, it should be about the journey. Not the destination. The wings as well need to be more limited as well (the way people use them at the moment is atrocious), especially how people take any hover vessel and smack wings onto it and fly. Travel should be more nuanced on planet surfaces, and right now we have none of it.

Well the point isnt to necessarily be about trading. It seems a lot of DU players miss this point. Game loops should try to maintain separate in their progression and mechanics such that you don't have to directly rely on the external loop - schematics are the worst example of this, as industry relies on the market game loop for multiple reasons. What it boils down to is that quanta are essentially the ore/manufactured parts you traded in so you can buy other things, however, it doesnt make sense that you can't just use them directly to make actual things, and progress. Markets need a use beyond "we're forcing you to use them because we said so", and moreso "I can't be bothered to make this", or "It's more economically efficient to let others craft this than me".

In the post I mention that the first time the schematic is "researched" you get it from the puzzle, while later you'd most likely get it from inputting resources that have resource aspects corresponding to what made the schematic. It could be balanced such that making the schematic the first time costs less than the recurring creations afterward, such that it is a proper research sink. Also its pretty silly to be scarred from Empyrion's skill tree because it is a survival/progression game, and all games that are not literal sandboxes need this type of structure to properly build their ideas. You should not think of a game's progression about "how quickly can I get from point a to point b", and instead think "how can I enjoy the journey as much as possible from point a to point b." A game designer needs to focus on the latter to make their game actually interesting.

If you read the post, no you really cant look up specific schematics online past the research point "nodes" that is the only constant in that schematic. The specific arrangement of these nodes can be randomized such that its not terribly helpful to google search.

After upgrading my talents on the run jetpack, I honestly regret doing so. The already quite small planets that comprise DU feel much smaller when you're traveling at higher speeds. Additionally the game gives no reason to walk - let alone just run normally. Due to this, I highly doubt many people have just taken a moment to walk through their planetary environment to appreciate the detail put into it in the recent updates. This compounds with the grand scale of many construction projects that appear to just be upscaled due to the speed of the character sprint. The scale of the whole game world is shattered when the character by itself can move so fast. This comes with a few proposals: Remove the ground-jetpack (the super-sprint). It's a main culprit of this immersion breaking, and also competes entirely with the idea of hover vessels, which are supposed to take up the 50-200KM/h range of motion. Add a stamina bar of some sort, with a maximum sprint time of 10-20 seconds, and a recharge time that takes 1.5x the capacity (in seconds) of that bar. Additionally, when the bar runs out, add some realism with exhaustion. You have to wait for the bar to recharge half way to sprint again, and it takes double the capacity of the bar to get to that point. Grant the character controller more polish, to make the movement, sound triggers, and camera bobbing more natural. Players can still float when they walk off certain surfaces. Perhaps even employ someone in particular to focus on this kind of polish (see here). Give more reasons for hover vessels, such that we can enjoy the finer details of the planetary surfaces. Good example of this would be to increase the weight capacity of hover vessels, but decrease the max height allowed. Distinguish hover vessels from typical ships and "planes" in some way. I make a similar post to this one where I discuss this in more detail here. Thanks for your time.

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).

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.

Is there still a possibility for the main star system to be replaced with the new planet tech? It's a shame it hasn't happened yet, and I can 100% confirm it'd be a major PR boost for the game if done properly.

This is going to be in a list style format. No poll this time (too many suggestions, just leave comments ) Add "full throttle" key bind. Literally inverse of "stop engines" key bind, but in cruise control just acts like tapping the up-throttle button once. Tank hubs. Like container hubs, but for only 1 tank type a piece. Consider altering the ore distribution to better fit this game loop flaw (forum post). Essentially allow at least 1 tier 2 to exist on all planets/moons. Consider making territory units craftable in nanocrafter using tier 1 components, albeit extremely slowly (see referenced post). Consider changes to the atmospheric scattering shader It's been a long while, and I'm sure if y'all have planet tech cooking, the atmospheric scattering definitely is being worked on. Frankly though, it's pretty easy to make a good atmospheric shader, especially in an engine that gives a lot of tools for you. Make changes so that the trace chemicals in each atmosphere give a transition effect before the atmosphere fades night atmosphere is not 100% transparent (a proportion based on the atmosphere's thickness Change atmospheric colors of ALL planets to match the planet atmospheres on the MAP (or some other interpretation). Now that I have your attention (here's a word from our sponsor, Raid Shadow Legends!), here's some changes I would like to see in future releases. Total planet reset to accommodate new planet tech. The forum post attached, assuming you also read referenced other posts, would fill my argument. It's the last step in improving all the planets after literally everything else has changed. Just do it sometime soon, the team has already found, or is going to find ways to make the transition as easy as possible. Ex. "Magic BPs" It's beta phase 1, when's phase 2? I'm tired of small planets with bad detailing that all embarrass all of us when we attempt to show the game to friends. Exploration needs good destinations. This game has almost none. Schematics. Ties in with the previous ore distribution, but to compare to another game... In Empyrion Galactic Survival, you can start from the ground up (nothing on the player), and make your way to end game, without ever needing to interact with any other player. It is balanced to be like this. A game like DU should promote this as well for a few reasons: Polish, showing the game's designers are good at making the core loops Whenever there's frontier societies, we cannot rely on the rest of society. Especially when you think about the "player made markets", why would bots suddenly be selling these schematics there (giving free cash to the establisher)? The element of progression, which when made well, can be engrossing and well worth the effort, and rewarding (player retention). In Demeter I'm quite pleased with the clear well thought out ideas of the mining loops, I'm confident the team is beyond competent to take upon the challenge of this. Physics (player and construct) While hard KSP-style (proper Newtonian) physics I don't imagine 100% for this game, many changes should be made to uphold realism and balance for the game. To quote a reddit comment I made on the DU subreddit... Thanks for reading, hope you are swayed by my arguments. See y'all!

The point of a progression system is to not rely on the markets. This game has a horrible pattern of solely relying on others to get stuff done, rather than letting players create the solutions themselves. This is especially noticeable in the world of Schematics. You cannot craft them, however, you can get them only by trading in ore to some bots (if you're thinking about a tech tree, where you are the only person, which is the whole point of a tech tree). What I'm saying with territories (and I explicitly mentioned this in the original post,) is that you cannot craft them without a territory unit in the first place, therefore making the progression system incomplete, and seemingly forgotten about.

IMO this wouldn't really fix everything, because the planets are way too small for an MMO sized world, and aesthetically are bad at best. A major change, while frightening, would be much better for everyone in the long run. Especially because, we're currently in a beta, expect change, people!

You're forgetting: not all moons have capabilities to craft kergon. And certainly not all planets have the ability to make kergon, because you need a territory unit to make anything tier 2's, which in itself requires t2's to craft. This game's progression makes little sense, from the perspective of actual progression and crafting

I've seen it before on surrogate (you can see it quite easily if you do too), but i dont have pictures xP

kergon fuel is uncraftable without tier 2's? how would you move your ship without kergon through space xD Rocket engines require tier 3's as well xD

Like I said, the issue with this is the game's progression. You physically cannot get off of celestial bodies without tier 2's, and not all of them have them.

I talked specifically about planet atmospheres (and skybox) in this post, as well as a similar post that my friend made focusing on the nebula found here. These detail issues that link into this particular issue, and are very important, however, I am not mentioning them in this post. Now why do I bring up these 3 posts? Well, they link very heavily into the topic at hand. Planet tech, and planet revamp. Starting with the game's progression and longevity itself, the current planets do not link very well (if at all) with the progression within the game. To put it succinctly, this section of text describes it perfectly: In this issue, the game's progression directly clashes with the way these planets were designed. Not to mention the longevity of the planets. On the regard of longevity, the simplest way to explain it would be the post about planet tech, their appearance, and their atmospheres, but also including their size. If you were to compare the Alioth system to the rest of the planets, you'd notice something highly disturbing. Alioth is double the radius of all other planets (and a lot of them are over double smaller), Sanctuary moon is also bigger than every planet excluding Alioth, and even Alioth's moons are the same size as Madis! 30km radius, 60km diameter. For an MMO of the scale that Dual Universe wants to have, planets this small is comparable to Space Engineers, a game designed for either small scale multiplayer, and singleplayer messing around. Many of the moons of the planets have been completely mined out of anything but tier 1's (pre-demeter), and planets such as Madis are extremely full of players, and we were only about a year into the public beta. To solve this major issue, I suggest the planets' sizes to be increased significantly. The moons themselves should be around as big as Sanctuary is currently (80km diameter), and all the planets should be of course much bigger, a maximum size in my opinion would be upwards of 600KM, but most likely closer to 400KM diameters. This is of course to increase the longevity of the planets and their habitation, and to make the sense of scale within the game much more apparent. Onto the tech itself, while I'm sure that the developers working on planet tech already have made major improvements to the planets, a sneak peak found in this video (over a year ago, now), it is highly apparent if you look closely at many of the planets that they were not made with intent of being permanent, let alone even looking pretty on the surface. Just look at Alioth, for example, it is quite clear that it is literally just an upscaled version of whatever it was when it was smaller like the rest of the planets, not even scaling the terrain's biomes and noise along with it to counteract this issue, which is an amateur mistake, especially for something as permanent as it seems to be currently. Not to mention, this post (can you tell the difference), which clearly shows that both Thades, and Sinnen uses the exact same planet generator, and if you look at Madis, also appears to use a very similar generator (but with different colors), of which shows just how lazy they were thrown together. Very little variety in terrain shapes. We move onto the other planets, Teoma seems to be one of the higher effort ones, having both grass, and trees, but once again is betrayed by the laziness of not even doing a height filter properly, and in that, Teoma literally had UNDERWATER TREES (pre-Demeter), which is honestly confusing and I don't know why they did not pick up on this. Additionally, although it looks very pretty, Teoma also has what seems to be a translation slider for its terrain compared to Alioth, and in that, they just translated all terrain filters for voxel types down by like 500 meters to a KM, and terrain up by about 100-250 meters, achieving a planet covered by mountains, and with no proper bodies of water (which to my current knowledge is by no means realistic). I could keep bashing each one of the planets and their features, but I think at this point you get the idea. These planets don't seem to be permanent, and seem to be amateur-ish at best. With how the process of a planet revamp would work, I must clear up a few major misnomers. Firstly, assuming it's not an actual wipe, all of your constructs will be turned into magic BP's (compactified constructs) and put into players' inventories. Of course, the items within the player's inventories will also remain, and thus no actual information except for the planets themselves will be altered, or lost. This of course does mean, however, that multi-core builds will be a pain to set up once again, however, I'm sure NQ is smart enough to find solutions to that issue as before. I hope that you enjoyed this post to some degree, and also are willing to undergo a planet revamp. I doubt it will be the easiest change, however, it is vital to the game's success, not only for the player base, but for the company, and continuation of the game's development as a whole.

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!

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.