Mjrlun

It seems very bizarre how we have so many types of doors, yet we don't have gates that are big enough for an XS vessel, but don't cost a fortune to make, and that aren't extremely difficult to find a place to put on a not M to L size ship. What I'm primarily getting at here is that you can make gates using sliding doors, sure, but they don't have a few major functionalities that gates have. First of all, they do not fold up like the normal gates do. Additionally, making a gate with a bunch of doors means that it cannot be tested for airtightness in the future (when that's probably a thing), due to being different elements, at different angles, and therefore most likely having unfixable gaps. Lastly, sliding doors don't really look that good when it comes to something like a hangar door. The aesthetic they give off is not "this is a super heavy duty airlock mechanism", more of a "I am a thing you push out of the way because I'm a door". Separate topic altogether, but folding doors, swinging doors, and of course gate-like compressing doors would be pretty cool too. The mor-doors the merrier. Ahem, but anyways, more gates when?

Is a planet (voxel) reset still under consideration or planning? I do know that Dual Universe currently has a declining community, and that something like this would most likely affect DU much less than if it happened near beta launch. On top of this, I must remark that the planets in DU currently REALLY need attention on not just texture and model updates, but in general features and topography. They are extremely bland in general, and most have not been updated in an *extremely* long time. At least in my opinion, seeing a planet/voxel reset of which would include bigger and more exciting looking planets, especially with new ore distribution and such would be a welcome addition for both PR of the game, as well as the exploration and building aspects as well. Even Teoma at the moment has trees (and grass) underwater...

In this post I'm going to list (in some detail) what I think should be top priority for an update that focuses on a few pillars: intuitiveness and documentation. In these two pillars, this game can make a lot more sense to newer players (thus keeping more on board), while also helping the pre-existing community from becoming discouraged. Other things you must assume, as is for most games. This game should not require 3rd party tools to play, as MOST players do not use any outside tools to play games. Even if this changes in the future, it is still a good idea to take things from the ground up, assuming they do not understand how to play this game. Starting with actual Quality of Life features: Complete overhaul of Maneuver tool to indicate with proper HUD a. Create durability for the Maneuver tool. This durability amount directly correlates with the amount of meters a player can move ANY (dynamic) construct. This is not tied to the construct, but the item itself. b. Increase range capacity from 50, to 150 meters. This is because of making it a unified meter for all ships, while also adding a bit of QoL by allowing players to move their constructs a bit further. c. This durability would recharge at 2m/s* while the durability is not gone, while if it is gone, it recharges at 5m/s*. While the bar is recharging from empty, the tool is not usable until durability is FULL. *Since we're measuring the durability in meters allowed to move distance, using m/s indicates the rate of which durability is recharging per second d. Add a status bar tied to the durability, of which would function similarly to most durability bars (see Minecraft). This would be a visual indicator on the tool itself, like the image given below, which allows the player to understand how these mechanics work in an intuitive way. Allow cores to be swapped out for larger ones Similar to how Mindustry does cores (see gif), allow players to replace the current core on a ship with a larger one (not vice versa). If there is ANY other element in the way of the core, then it would collide, and not be allowed. In addition, the core must entirely envelop the previous core in order to replace it (like Mindustry). Lastly, the previous core is destroyed upon replacement, and all data tied to the previous core is transferred into the new one. Better Item/element descriptions a. This one is purely documentation, but a static table with groups you can choose from a dropdown menu next to it would be much more intuitive and better working than a scroll bar. Examples of groups of these would be "resistances", "basic info" (HP, tier, mass, unit volume), "unit specific info" (fuel consumption, thrust output, just related info for that specific part). I'm sure a dev team could make better groups than I can, but that is the idea. b. Review EACH and EVERY item description, and make sure that it is neither generic, nor is completely forgotten about. For example, there are a LOT of items that just don't have descriptions, or have copy pasted descriptions that don't really tell the player much. This is not a chair? At least it doesn't have a lot of generic text... So a bunch of generic text, with a generic description afterward. What does this element do again? For a lot of functional elements, the game nails the proper description. However, I don't see a reason to have a copy pasted description on EACH tier of EACH engine, because if a player is buying a higher tier engine (than basic), it's quite clear they understand how engines work, because they've played the game enough. In addition, reminding a player each time they look at a decorative element "they do nothing but make your construct look cool, but they do add mass", instead say "this is a decorative element", or something similar, of which shortens descriptions, and makes them more rich in content. In addition, less need for that annoying scroll bar... Increase documentation in, and OUTSIDE the game a. The codex's information, while sorta useful early game, is extremely outdated. There hasn't been a single time in my entire DU playthrough where I've looked in the codex, and genuinely found something that is new, and USEFUL. The sort of things needed to be documented inside the codex are things such as tutorials, how an element works, such as how to use Anti-grav, or warp drives! Uhh... so how does one use this? How do I control the AG unit? ...hello? b. Increase external documentation on the DU wiki. Even if it's community run and made, encouraging, and/or working on the wiki is a MUST. Perhaps encourage users in some way to update the forum. Anything to get proper documentation. In addition, tying in the wiki with the codex (as in, it's edited on the wiki, then the codex syncs to it) would be very beneficial by having both be updated *dynamically*, cutting the work in half. To be the face of knowledge for this game, it seems quite old. As the background suggests, this seems sunsetted. Developers dedicated to fixing smaller issues This isn't really a list, but as a lot of games have, having DEDICATED developers that play the game and from there fix these minor issues and gameplay elements is a good idea. This would be beneficial because you'd only need 1-3 devs total to work on something like this, and they'd be able to do things such as these QoL changes in game, and fixing these minor bugs or inconveniences. In addition, having devs that do this will also increase involvement with the community. This is because these minor changes makes a big difference when playing the game for a long time. In addition, being able to fix minor issues on-the-go means that they won't build up, and instead will be maintained much more efficiency, due to being at a ground level. I hope you guys enjoyed my post, I plan to update it with more ideas in the future as time goes by.

I won't be talking about deleting keys, as I talked about it in the following post, however, keep in mind that I think those improvements should be implemented as well: First I would like some proper documentation on how the keys work, because they work completely unintuitively, in the sense that you cannot consume a key you created, and you cannot use them to transfer your ship to an organization, without first creating a key, and attempting to do so. The game doesn't tell you this. The second feature I would like (as was mentioned in the post above), is the ability to consume your own construct key for yourself, to remove the "unable to interact with tokenized construct" lock out. This is there just in case people would like to experiment with construct keys, you shouldn't penalize someone for an hour just because they wanted to see how to transfer constructs to other people. The last feature is the ability to make a special construct key that on top of giving ownership, also gives DRM ownership to the user of the key. This would be useful if you would like to give a full tradeoff to someone (including the DRM stuff of course). A simple scenario of this would be if you were playing with another person, where they placed down the core, but then you built the ship, but you can't just remove the ship and then replace the ship on a different core, just to have full DRM control over the ship. In addition, the ability to create these special keys should be in the codex along with normal construct keys. P.S. can we increase in game and out of game documentation? The wiki seems abandoned...

In the 0.25.4 PTS update, they made it so we can no longer put construct keys into packages to delete them. Before packages, this was the same. What I see wrong with construct keys not being delete-able is the following: -Construct keys cannot be consumed by the person who made the construct key -Construct keys cannot be deleted once they are expired -Construct keys are not consumable once expired What this means, is that players can create an item that they can never destroy, unless they intentionally force respawn with the key in their inventory (although I haven't tested this, so that might even be false). What I'm asking for here is to allow us to delete expired construct keys, so that clutter in the inventory is not as high, and on top of that, be able to consume the construct key as the creator of the key, in order to get rid of it in case of a misclick, or being unable to give the key to someone else.

I made this post about the 0.24 update a while back when it was about to launch. Considering the Idea Box is quite active, since I can't repost it here, here's the link to the post. Please leave comments on the original post, so that the discussion is centralized, but upvotes here would allow more people to find the original post ❤️

The simple idea is that players can replace a smaller core with a bigger core (but not vice versa) by placing the larger core ontop of the smaller core (directly centered on it). In placing it, it would not be blocked by the smaller core, but only by any other element around around the core. Once placed, the old core would be deleted.

Forget stealth. Instead we have this stupid nebula making any dark object extremely visible at night, or in space.

IDK if it's just me, but I find it quite unnerving that the player size is absurdly tall (exactly 2 meters). Especially for the sake of allowing smaller interiors to not feel so cramped, as well as making the player generally feel more like themselves (but in an alternate universe, AKA immersion), I think it makes more sense for the player to be 6.5-7 blocks tall. While a minor change, I think it would be a welcome addition. If the devs are willing to go further, I think that the players should be able to set their player height (within reason) when making their character (and/or when we edit our avatars as well). Would be a welcome addition on my part.

Tell me... Which of these is Thades, and which is Sinnen? If you can tell me looking purely at the terrain generation of these two images, you deserve a raise. The purpose of this post was to raise awareness for the need for improved planet generation (including a terrain reset), as variety of planets is essential in the appeal and longevity of the game, especially in exploration.

To prefix this, this is primarily a discussion page to talk about various ways to monetize this beloved game called Dual Universe, while weighing pros and cons. Considering many people don't understand why things are done, or perhaps the business people within the company haven't thought of a few of the ideas perhaps to be mentioned in this total thread, here it goes. None of any posts in this thread are considered the whole picture, more as a combination of all the thoughts given, including this initiation post To start, we are going with the backer method from pre-alpha/alpha. This method was to kickstart/crowdfund the game. There were 60, 120, and 180 USD packages, which gave increasing in value rewards in game. Pros: Good for the players, they only have to pay once, and have various ways of supporting if they want to Gives some nice benefits for choosing different packages Cons: Requires constant intake of players to maintain the game, especially the immense server costs and dev pay Might give way to the hated micro transactions Might be considered pay-to-win, even if it is minor The second method is similar to the first method, but with jacked up prices to make each player "support the game for more". Packages for example could be + 20-40 USD. Pros: Supports the devs more Players only have to invest in the game once Gives some nice benefits for choosing better packages. Less likely to create micro transactions (unless the upper management gets greedy that is) Cons: Still requires constant intake of players to maintain the game, especially server costs and dev pay. Might be more considered pay-to-win Costs a LOT Current subscription method, without DACs implemented. (7 USD a month, 21 USD packages) Pros: Keeps development going much longer maintains server costs per player (each player chips in for what data they are changing on the server VERY unlikely to create micro transactions (unless management are extremely greedy) Cons: the HATE for subscriptions No bonuses for pouring in extra money Upkeep that nags at the back of your mind, reminding you to not enjoy Dual Universe, but to pay up so you don't loose access to potentially play the game Becoming the joke of the space sims (bad PR) Current subscription method, WITH DACs implemented. Same subscription model, but when you buy subscription have the choice of redeeming them as in game items which can be traded using in game markets. Pros: You can "unlock" subscription time by GRINDING cash, depending on the demand Helps the person who's selling them get some in game cash Emerging "gameplay" Keeps development going longer because it's still subscription based. Cons: Pay-to-win still a subscription model UPKEEP (as previously mentioned) Still horrible PR, now for the pay-to-win aspect Enforcing the Elite Dangerous mentality "Grind is Gameplay" (not true btw) Hybrid model of DACs and subscriptions, or you can pay expensive package once to get permanent access. Pros: Players can choose to pay a limited time subscription to try out the game, without dropping an OBSCENE amount of money If you want to go subscription method, you can "unlock more subscription time". Potential to increase the income per person monthly for continued development Cons: Confusing business model Still subscription based PR might get confusing, but less negative Still kinda pay-to-win Hybrid model 2.0, but instead with more lenient subscription model. Includes DACs in this scenario, however, the pros and cons of them could be removed if taken out of the equation: Account subscription only ticks down while logged onto the server, encouraging players to make the most of their time spent, while also having a player-determined time bomb on their account. Pros: Each person's subscription lasts longer Only counts down while in game Encourages players to put less strain on the server from logging in Players can use the time they are spending in game extremely effectively, by grinding DACs using in game money. Encourages developers to optimize the heck out of the player data and voxel storage method (more in the cons) Cons: Less effective for dev-income DACs still exist subscription method, while less bad, still exists "Meh" PR Server needing upkeep for storing players' data and constructs, while them not paying for having it on the server That's what I have for now, I do plan to update this now and again depending on if people have new ideas, and/or if I think of something else.

So here's my constructive criticism on the new update. I love it, don't get me wrong, but there's some things that would probably take between 30 minutes to 2 hours for a single dev to complete, and would completely overhaul the feel of the update, and graphics in general (written in the specified feedback format, here we go). The background, yes, the nebula, as well as atmospheric scattering are the main topics that I want to have changed. My opinion on the current background/nebula, is this. It ruins the ambient lighting, by having a persistent, ugly, turquoise tint to the entire night side of the environment. It removes all the depth of any structure or voxel, while also not even being dark, or night time. It's so bad that I'm forced to put an L vertical light above the ship im building just to get some decent lighting on it to not make it look flat, and drawn poorly. In addition, people, as sourced from the video where the nebula released, thought it would be a cool idea for stealth combat with having to make ships dark in some way to be able to not be seen from so far away, while also making headlights useful in space. On top of this, just to mention, the corners of the nebula are soooooooo clearly visible if you spend about 30 seconds looking, which completely ruins immersion further than just having poor lighting. Furthermore, a darker sky would better pronounce the incredibly beautiful atmospheric scattering, and generate some breathtaking screenshots. The second aspect of this, the atmospheric scattering, is probably the more confusing side of this request (not that adding the nebula despite people on the video announcing it saying they didn't like it doesn't make it not confusing why it exists), is that the different planets used to have different atmosphere colors, yes? This is a server-side thing that was "changed" some time in the land of NDA, and thus the devs know when this was. All the different planets used to have cool unique atmospheres, not just "blue blue blue blue blue". The desert planets in the top right of the map had orange atmospheres (Sinnen's not supposed to have an atmosphere, but it has a bright, BLUE one!), as well as Thades having a nice orange atmosphere, and Madis having a nice unique purple acid-y atmosphere. In addition, all of these atmospheres have clouds, which makes 0 sense from a realism standpoint, as they are all white clouds, indicating each planet has sufficient enough water to generate a biosphere (not true, in a long shot). And to wrap this up, they made Sanctuary have the only "unique" atmosphere, which did not need it at all. A bright orange one. Weren't we wanting those for the desert planets? To be frank, the Sanctuary moon should have some alteration of a nitrogen blue atmosphere (similar to Alioth), however, changed in a way to represent its biosphere. Something like a more oxygenated, or less oxygenated, would be a cool addition. For example, if the atmosphere of Sanctuary was made to be a nice green-tinted nitrogen blue, it would probably be as "cool and exotic" as the orange one, without making it look like an apocalypse is around the corner, and also ruining every screenshot in existence that involves nature. IMO, it takes the beauty of the nice, lush landscape, the beauty of the moon, and turns it into something I wish would not exist the way it is at all. To wrap this up in a meaningful concise wants and desires, here's my list in sentence form. Remove the nebula, keep the stars. If you poke around in the files (of course not altering anything), you can see that they are deliberately separate files, as if it was a simple patch at some point that altered it. See images found from public sources where this was a thing. If there are any issues with doing so of course putting in the effort to fix such issues are quite important as well. If you truly want, replace the nebula with some form of darker galaxy background, I don't really care, just not something that ruins the night sky so harshly. Take a note out of Elite Dangerous if you so have to. Find a cool nebula background by messing around in blender, or create a nice galaxy background which would have a similar effect. Should this be the case, however, the ambient lighting should still be dark and black, and still maintain some amount of AO (and shadows preferably, but that's a task). All images here are from earlier versions of the game, publicly found (click on the images) Atmospheric scattering, background, and ambient lighting during night time Shows the background plainly just there against the nice day time atmosphere, in general, very serene! A cinematic cold morning or evening in the early days of DU engine infrastructure Now just pure background and lighting! Now for the atmospheric scatterings. All I request is to make them accurate to the map, and to their descriptions (should they have them, cough sanc cough). On the map, in case you all forgot, Sanctuary used to have an Alioth-style atmosphere. If you prefer to go for a more engaging style, however, I'd highly recommend choosing something similar to what I suggested earlier for Sanctuary, but then apply this creative vision that seems to have been forgotten about on this topic to the other planets, which dearly need some love. Demonstration that even in pre-alpha that this was possible, and just how breathtaking it is with a dark background!