Jump to content

Search the Community

Showing results for tags 'suggestion'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Starting Zone (EN)
    • Rules & Announcements
    • General Discussions
    • Off Topic Discussions
  • Starting Zone (DE)
    • Regeln und Ankündigungen
    • Novark's Registratur
    • Allgemeine Diskussionen
  • Starting Zone (FR)
    • Règles et Annonces
    • Registres du Novark
    • Discussions générales
  • Beta Discussion
    • Beta Updates & Announcements
    • Idea Box
    • Public Test Server Feedback
    • DevBlog Feedback
    • The Gameplay Mechanics Assembly
    • Streamer's Corner
    • The Builder's Corner
    • Innovation Station
  • Organizations
    • Org Updates & Announcements
    • Novark's Registry
  • Fan Art, Fan-Fic & Roleplay
    • Novark Agora
    • Novark Story Time
    • Novark Art Gallery

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location:


Interests


backer_title


Alpha


community_id

  1. I believe that the nebula skybox should be replaced with a realistic, dark and starry skybox, akin to the old one prior to Alpha 3. Here are my arguments, The nebula was originally introduced as an immersive way to increase ambient lighting in Dual Universe, making it easier to see at night. This is mentioned in NQ's Dev Diary on YouTube. However, this was nullified in 0.24 with the reduction of ambient light brightness. This is personal preference however I believe many will agree; the ambient light level does not have to match the skybox's brightness. For example, take this image of Pre-Alpha Thades. Its dark side is heavily illuminated, as I'm sure it would look on the surface as well. You'd be able to see. Compared to current Thades, I think most of us can agree that it still looks far better, and it could be taken down a notch if it's too bright. Additionally, with the introduction of the nebula, the atmospheres were changed to the same blue color we're all used to. I'm guessing this was done as a result of a technical limitation relating to the new skybox. So, think; If I'm right about this, we could have a Thades that looks like this, for example: Current Thades, for comparison: You see where I'm coming from? The way I see it, removing the nebula would provide so much in the way of fidelity, immersion and polish. It wouldn't affect gameplay either. Furthermore, I believe this change would solve many, many of DU's lighting glitches and "rough spots," at the very least making them look far better, and would provide much more polished lighting, both on ground and on a planetary scale. I simply don't see what the nebula adds other than style, but it sacrifices fidelity in a lot of key areas. Unfortunately I don't have any screenshots to back up that claim, so you're gonna have to take my word for it as an Alpha 1 player who knows how lighting used to interact with the old skybox. The nebula may be beautiful to some, but honestly, changing it would add so much in the way of polish — which I believe is far more important and is what this game needs right now. Not to mention, many people were dismayed at the release of this nebula, and I'm taking a wild guess by saying that most players would like this change. I know my friends and I would. Please consider this, Novaquark. Similar post by Mjrlun
  2. I think the title itself explains a lot but the idea is having a second type of Landing Gear elements that have wheels and are more geared towards gravity landing and takeoff. Their main use would be to keep the ship at some height from the ground while still moving forward but without enough lift to keep it flying, which would be useful when taking off or landing with large amounts of cargo, and would require a landing strip to properly land, similar to real planes. In terms of implementation, the retractable part of it could be borrowed from existing landing gears and the physics part could be similar to these of a hover engine, the wheels would not provide any thrust, just maybe a very small braking force, but mainly sustentation/suspension for the ship when they are in contact with the ground, so the ship would still need to brake by itself.
  3. We need folders. under map, the bookmarks section needs folders we can create and move things into Under map, the constructs section we need folders Under RDMS, the tags need folders Under RDMS, the profiles need folders. Would make things look so much more tidy and be easy to find.
  4. is it possible to "apply" your org membership to a transponder, and fellow org members will see a Green ship icon and under the ship name there will be the 3-4 digit tag of that org? that will allow you to filter out an org buddy ship in a herd of other ships. Just some kind of default game identification for friends and allies. At the same time, I would hope that you could declare other orgs ally/hostile and if they run those tags, they appear red instead. would be kinda nice to have instead of me having to run 3rd party lua to actually use the transponder
  5. I'm not sure if the server takes more resources to constantly update all the tunnels as we fly by or what the deal is server side BUT I think that tunnels in the terrain on tiles that are NOT own should 'cave in' after a week or so. And have the OPTION that on my territory that within a certain distance of a construct that no voxels will cave in. (so buildings don't get filled in with dirt) Or no caves ins on claimed territory. So basically Only claimed territories will still keep their tunnels if the player chooses. I fly around looking for ore and there are tunnels EVERYWHERE which is cool... but not very useful. I just think if saving server resources is an issue maybe this might help as hardly anyone is going to go down a tunnel and just dig their own... And as a side note maybe ores can respawn after a YEAR or so... I know that's not planned but as this game grows new players WILL find it hard to get a foot hold because all the easy ore is completely gone. I'm getting a LOT of scans coming up with nothing but tier one ores... now either that is by design or it's all being mined out. If it's really disappearing that fast it will be a problem in the long run... But that's a side issue that can be addressed later.
  6. My idea is landing pads that would be detected by the ship and you would land automatically after pressing a key when you are near of it and there would be different landing pad size for each dynamic core size it would work like in No man's Sky that would prevent landing bugs at market when a ship appears out of the blue and hit your ship because the game doesn't load fast enough even if you have the latest specs rtx 3000 series etc. it would be useful for space station also and would give the opportunity for no landing zone feature to works for example you have to pay a fee to land or example you need an authorization to land! that would add a cool aspect to the game for logistic. ** Landing pad would have a direction so you would not go through objects and would need free space around it and over it and that would require the minimum size of the core limits of your ship.
  7. Heyho Novark Builders, I’ve got a little problem and I cannot find a good answer, so I would like to suggest a little something: This topic is not about core alignment, but about rotating cores. To be more precise, the rotation function where you hold R and Scroll with your mouse-wheel is far to unprecise. As far as I can judge this, equipping a Static Core will show you were you are able to place the core on your plot. This position is not “loose”, which means you can not rotate it by changing the direction your character is looking, but it is simply fixed. And sadly, it is not aligned with any of the plots six sides. Unequipping the Core and reequipping it does also not change the fixed position. Of course, you can rotate the core by holding R and using your mouse-wheel. However, this will rotate the core by a fixed amount of… dunno, 5 degree or so? This means you cannot properly align your building space to your territory’s walls no matter what, as holding R and scrolling rotates the core just by too much of a degree. I get that this might be not a point of concern for most of you out there, but I do think this is an issue that should be talked about. A possible solution and my personal suggestion is the following: The player should be able to rotate the core freely when holding down R and moving the mouse left and right (horizontally, of course!). Edit: Another possible solution would be a feature to snap on the borders of a core to the territorys borders. I have not found a thread with this topic, so if there is one or if you have a solution, please show me the way ^^
  8. • Lighting. Add an option to enable "global" lighting that evenly lights the entire construct area, instead of using the world lighting. • Mirroring. Add a "mirror" tool that lets users add one or more planes to the construct area that mirror elements and voxels placed on one side of the plane. • Copy/Cut & Paste Elements. Allow copying/cutting elements and pasting them. Also allow copying/cutting & pasting voxels and elements simultaneously. • No Clip. Add an option to enable "no clip" while in build mode. • All-axis rotation. Allow the rotation of elements around all axes; a number of elements only allow rotation around one or two axes. • Vertex editing. Add mode that allows moving individual vertices on voxels. Also allow the selection and movement of multiple vertices at once. • Groups. Allow the ability to assign elements and voxels to "groups". A group can then be moved, rotated, copied/cut, deleted, etc. • Blueprints w/o cores. Allow users to create blueprints from voxels and elements they have selected, but do not include the core. They can then paste those to other constructs. • Wireframe option. Add an option when using the link tool to have all voxels displayed as wireframes to make it easier to see connections between elements that go through walls, floors, etc.
  9. Organizing a large industrie is a heavy task. Due to the limitations of container connections the transfere unit helps a lot, but is far away from perfect. It would be nice if we could have multiple items transfered by one transfere unit. This would help automating without touching the container node limits. With this extension we could do the following example: Having a container L as main input for ores. -> transfere unit 1 moves all T1 ores to a T1 container -> transfere unit 2 moves all T2 ores to a T2 container T1 container feeds T1 refinaries T2 container feeds T2 refinaries
  10. Just a suggestion, and I hope that it might be considered for addition into the game at some point. Containers and linking to industry. On the surface a pretty simple thing but once you start upscaling it can grow real complicated, real fast. (at least for my teeny tiny anyhows 😋) Though I guess going into a build with all the stuff needed and a solid plan is the best way to go at it, building a frame structure only, dumping down all the industry where you want, being able to clearly see where all the lines are going etc. But, if your new at it, or enlarging an industry in an already built structure, then you are going to have issues tracing those lines, not because you didn't name all your containers and industry (if you didn't then good luck sorting out that hot mess) but because more often than not you cant see where those links are going, a problem compounded more with multiple floors. Anyhow, to the suggestion....... In containers and industry, under the containers tab, wouldn't it great to be able to select Input / Output links via a dropdown searchable list of all the constructs linkable elements. Even better if we could see how many links are used/available on each one of those elements. And Even Better if we could also see to which elements they are currently (if any) linked to. Please, for the sake of my sanity and mental well being , make this happen 😁 Cheers in advance 🍻
  11. I want to be able to select a voxel construction with the selection tool and save this selection permanently as a blueprint for further use. This way you can construct your individual elements like "a voxel bottle" or "a voxel chair" and place it everywhere you like using the blueprint. Currently you can only save a complete core construction, but not single voxel elements.
  12. Consumable devices that opens small text fields for the player to make and share notes. I would love a full rich-text based editor with maybe even pictures. But a simple text editor to make quick notes like routes through your mining tunnels so my friends (and myself) won't become lost would be awesome.
  13. By using the link element tool in a large factory you loose the overview of all that connections very fast. An improvement could be: If you select an element as smart target all connections with this element are colored, all others are grayed out. Input and output connections should have different colors, so you can recognize the direction of connection faster then watching the nicly animated arrows. I just added a screenshot that you know what i am talking about.
  14. Hello. I'm here to suggest a thing that should have been done from the beginning. Now we have the most inconvenient interface for radar and guns in our constructions. We can get some data from the radar API and can try to create custom widgets and interfaces for this. But all this is completely useless, because we do not have the ability to identify and capture the target and can not shoot without using the standard UI. I understand Novaquark can't allow us to do these things through a script. This would not be fair and it would give an advantage to those who know how to create scripts. The only alternative I could think of was using hotkeys to identify and capture targets and to fire guns. I think this is a very important thing now that we are in beta and the game world is starting to evolve. What do you think about it?
  15. My friend and I have been playing for a about a week now, and today by accident I discovered that CTRL-Double Left Click within the inventory does a select all function in containers/nanopacks. I couldn't find this in any ingame tooltips, we've actually been annoyed thinking this didn't exist and have been manually selecting via CTRL+Left Click 1 by 1 to drag multiple items around. This is mostly a "Newbie Help" item, to add it to the context menu where I see there is room left for more tool-tips. Please see screen capture for my suggestion to add this tool-tip. -Neoki
  16. This post is about the experience of crafting using industry in the early game. I am fully aware that as you build resources these concerns decrease, but .. this still leaves us with a less than ideal early game experience - which is the issue I want to address. So, early game, you're building things in your nanocrafter and you're starting your industry... You build the parts for the Assembly Line S (skipping the XS as it's useless initially), then you build the parts and Assembly Line M, then you build the parts and a Smelter, Refiner, Electronics, Metalwork, 3D Printer, and containers galore. The progression here is fine, the issue is that because you have to use the nanocrafter to produce the parts required (typically into a linked container as input to the assemblies), and because you have to manually alter the recipe each time, you're essentially tied to your base, for long periods of time, doing "nothing". Sure, you could be building the base .. but.. typically you've used all your starting honeycomb and don't want to make more, yet, as it would slow down your industry creation. Sure, you could run off and mine.. but then your nanocrafter queue will put the current output in the wrong place (because you leave the linked container range) and then it will stall (as all the inputs are in the linked container, now out of range). So.. instead, you sit with your thumb up your .. doing "nothing". This is a "not much fun" gameplay loop which I would like to see improved. I think the solution is to add queues to industry units. What I mean by this is that we ought to be able to queue a "make X of Y" request, just as we can in the nanocrafter. I am not suggesting we queue "make infinite" or "maintain X, and Y, and Z" or anything like that. So, industry units can either be processing a queue of make X of Y OR doing one of those other things, not both. So, lets start by listing and attempting to refute the common objections to this: 1) this would make large factories redundant If you can build everything with 1 electronics, why have more? Because one electronics can only do 1 thing at a time. So, if you want to produce something with 5 ingredients, you would have to wait for one electronics to produce all the input, one ingredient at a time, and your "factory" (of 2 units) would be super slow and inefficient. Given this, you still need large factories, especially once you reach the scale where you want to "maintain" a range of input ingredients to keep your factory production constant and efficient. Queues have to be queued manually, so they're not appropriate for a fully automated factory. In short, queues won't change how large factories operate, so they will still exist just as they do today. 2) this would reduce the "value" / "cost" of items in the game, and "ruin" the market. If things are too easy to build, who would buy items from the market. Yes, this will make it easier for new players to build the smallest, cheapest, T1 elements in the game. But, doing so will still take them quite some time (see point #1 above) even if they have a few industry units, so they might prefer to buy these items some of the time. For higher tier items, with more ingredients and longer build times for those ingredients and the item itself.. those players are going to have an ever better reason to buy the items instead of making them. Another way to look at this; even late game players might prefer to simply buy, in bulk, lower tier items. If crafting these is easier for new players, then they may even be selling on the market. This is actually a net positive for the market, even if the price per unit is lower, there will be more items being bought and sold. In short, queues may have an effect on the low end of the market (positive and negative), but very little effect on T2 and above. 3) Any other objections? If you have any, please let me know, keeping in mind the points made in response to objections #1 and #2 above (as I can think of some potential objections which these points refute). This is not just my complaint I am not the only person who has issue with this gameplay loop. I recently watched this video where they express the same concerns about crafting speed and having to sit round doing "nothing".
  17. Hi. When you click a recipe that is in the queue of your crafting window, open the recipe with the queued quantity in the middle window. To allow the user to not have to manually re-enter the amount when they want to look up the item requirements Change the "Missing Ingredients" marker in the queue indicational (Red if missing items, Yellow if it's item requirement is dependent on other queued recipes before it) To provide a clean graphical indication of the queue status and requirements Placing artificial voxel removes dirt voxel within x distance of it. To allow for cleaner builds that move into the dirt. Enable users to see their trade history. To give overview of a player's trades. Even though they can do this manually, it would be easy to see where you bought items and how many at what price Enable users to filter the order lists on market This could be a ticker list, categorized by planets, or perhaps even with a set distance range, perhaps a "Show Local Only" ticker Extend the Harvest tool/Mine tool hud with a contextual infobox To contain the material you are looking at, the refined version of it, and how much of it you have in your inventory Implement the ability to "Favorite" recipies To provide an easy way for users to find often-crafted recipes Allow for an option to take missing dirt from the inventory when flattening the ground. To allow for users to line firt up nicely with built structures
  18. Have a limited amount of items to be placed around the world without the use of a core. Think of lightning/signage in a mine or maybe even cargo boxes. You could limited it to only owned territory (personal and other territory with build rights) to reduce the spamming of these things in public spaces. I am thinking of items like: Signs - snaps to voxels to indicate paths or closed corridors in mines. maybe even decorative once like safety signs. Lights - Can be standing lights or lights snapped to voxels. Can be used to indicate paths or light the dark mining shafts. can also be made with batteries or that you have to link them to a reactor on a static core. Small items like cups - So I can decorate my office. I envision the cargo boxes in 4 sizes mostly because I think the act of loading and unloading cargo would be so much more immersive. Small box - Hand held. Can easily move around while holding. but has only a very small amount of storage capability. Medium box - Roughly 2x2x2 the size of a small box and will limit the player movement. Large box - Needs a vehicle (forklift designs will be booming) to move and comes in different shapes. roughly 3 times larger than a medium box. Extra large box - basically a shipping container.
  19. I noticed that the foliage is in low-poly and there are so much possibilities with Low-poly I don't understand how DU can't get better looking foliage and trees .. Also the ground terrain on Du is a nightmare it's scary it's a nightmare!! It looks like honeycomb or a closeup picture dropped on the floor.
  20. Using the hand to build and edit the terrain is great, but good be improved by a realistic solution. A tool, which could have multiple version, one to build, one to edit the terrain, which could be free for every player, but could break over use. Satisfactory’s tool is a great example.
  21. It would be a tool that let you draw a line around the area you want to fill water with.
  22. Not quite sure if it's implemented or planning to be implemented. After a very lengthy conversation with 1 or 2 discord moderators on "duscussion", I was suggested to come here and make my case. I hope the developers read and see this naturally, as it is intended for them. I understand you have a big game to make, a lot of issues and players to address but please hear me out. From what I hear and see, I'm already beginning to love the idea of your game. All the little things matter, and can make all the difference in the world, especially when it comes to a game. Now, judging by the title you probably already know what I'd like. Stealth. More of a focus on hiding assets on planets, territory units or hex claims whatever they may be from detection other then visually seeing them with the naked eye from a short distance. My intent is to use the games freedom (hopefully) to build underground, while using the cover of a subterranean base and operation to remain hidden from detection or being sighted by potential hostiles. Please make this possible. There should be an option to decide whether you want to broadcast your position or not to other players, I myself, someone who isn't too keen on joining a large faction would like to be able to remain invisible in such a large universe. For example, I don't want a player to be pinged the exact location of that 1 hex I have claimed on a giant planet the second they enter orbit. Please support the players that want to lone-wolf it. Please, this is one of the key steps in doing so. I want other players to have to work for it, make an extremely lengthy and detailed survey of the planet like real life in which would take months to years to find me and my base if they really wanted to. You have to take that into consideration, it's not overpowered and it's not unfair. It's just reality. There's going to be thousands of other players. Why does one or a small group of them hiding matter? Why limit that for them or anyone?? Knowing where everything is at anyone time is a silly thing to have be the case. This is a unique request I'm sure, I just don't want to see the enemy from a million miles away, nor them me. I feel that takes the fun of surprise attacks, stealth or hiding away. The concept of stealth I'm proposing can ALSO be used for space stations, secret asteroid bases in asteroid fields (if you intend on having asteroid fields) as well as naturally underground bases like I originally suggested. If players want to be found, then there let that be their choice. There should be "beacon" objects that ping a title and a symbol of what belongs to what that is fully customization to the players specifications, or perhaps a radio signal with a pre recorded audio voice. Who knows. Thank you, and please reply.
  23. Fuel tanks being exposed is generally a bad thing, and we generally tuck them away from the hazards that would damage them. To allow access there are fuel lines leading into the tanks from the exterior of vehicles. I propose an element that achieves this same function in Dual Universe. It could be linked to a tank (possibly several) to allow for one way fueling to the connected tanks. it wouldn't make the tanks capacities shared in use with other elements, but would allow for them to be internalized in the vehicle protecting them better from outside complications. The logic goes as follows; you can fly a plane with one engine, but not without fuel. Propulsion systems would be completely compromised if fuel tanks are taken out. Internalizing elements is possible (as seen in the tutorial videos) since voxels can be temporarily moved, but having to move them after every few flights seems very inconvenient. Then there is always internalizing most of the tank but having a "window" that exposes part of the tank, but that still has the vulnerabilities associated with an exposed fuel tank.
  24. Hey All, Just wanted to throw in a suggesting to have the ability to throttle the download from the launcher. People who are charged for bandwidth or slow connections might have trouble without this option being available.
  25. It seems like the astronomical side of DU is still in its infancy, or at least from what I can see. So I would like to present a two-sided series of both suggestions and educational posts. Though I will not be going into too much detail. So if there are any other Physicists or Astronomers out there, I'm simplifying for a general audience and possibly have these parameters included into the game. Planet Orbits: Depending on the mass of a star the typical orbits of planets around it have been found to have certain properties. The is an inner and outer limit. Too close and the planet (or rather that section of the proto-planetary disk during formation) will be pulled into the star. Too far and the star will not have enough gravitational pull. Before we proceed, an Astronomical Unit, or AU, is the average distance between the Earth and the Sun, approximately 150 million kilometers or 93 million miles. The inner limit follows this equation: I = 0.1 * M Where I is measured in AU and M is the mass of the star. Similarly, the outer limit can be generalized as: O = 40 * M Though with some caveats on the mass and velocity of individual planets, as particularly fast or less massive planets would have a significantly smaller outer limit. Frost Line: The simplified frost line can be found based on the star's luminosity. F = 4.85 * L^-2 Where L is luminosity and F is measured in AU. Keeping in mind that a planet barren of atmosphere will retain nearly no heat from their star and certain atmosphere compositions will have a greenhouse effect. Stable Orbits: Planets have an almost infinite combination of orbits, but there are some rules of stable orbits when multiple planets are involved. Each further planetary orbit will always be between 1.4 and 2 times the distance of the previous or be unstable and something will somewhere destabilize. This, however, is in relation to the star. IF we are looking at orbits close to the parent star, planets themselves can be no closer than 0.15 AU of each other (generalization, gets a bit more complex). Otherwise, the planets will affect each other and one or more planets will destabilize and go into the sun or settle into a further orbit which may cause a chain reaction of other orbital interactions. Orbital Resonance: Dwarf Planets: Criteria: Orbits a star Roundish in shape Has not cleared its orbital path of debris Not a satellite Terrestrial Planets: Ice Giants: Hot Giants: Moons: Major/Minor: Moons are currently classified by two types, Major and Minor Moons. Major moons are those who have enough mass to collapse into a spherical shape. As mass is not always the same density at certain sizes a minor moon may, in fact, have more volume than a major moon. However, this is a limited range and is extremely rare. This range of overlap resides almost solely in the 200-300 km range. Though theoretically, some really odd and really rare highly dense or the oppositely composed moons could exist. Rocky/Icy: Moons also come in two varieties, predominantly rocky and icy. Why this is has a few theories based on we believe system formation occurs. Moons located within the systems frost line will be predominantly rocky and those outside the frost line will be predominantly rocky. Abundance: Terrestrial planets tend to have very few moons and often none at all. It is not uncommon to capture a few asteroids which reclassify as minor moons, but it is particularly rare to have major moons. Additionally, terrestrial planets closer to a star tend to have fewer moons than those further away. Hill Sphere: The Hill Sphere is the range in which a smaller mass within it will gravitationally bound to the larger mass. This can be calculated by the equation: H (outer): a * (m/M)^(1/3) * 235 Au , m is the smaller mass, and M is the larger mass. The inner limit is the Roche limit, more details on that later, but for now, the equation is: d = R * ( 2 * pM / pm )^ (1/3) Where R is the radius of the major body, pM is the density of the major body, and pm is the radius of the minor body. It must be kept in mind that these are simplified equations for static, or solid moons with an ideal orbit. Moons with fluids or elliptical orbits will have modified equations. Simplified Orbital Period: P = 0.0588 * ( R^3 / (M + m ) )^(1/ 2 ), Where P is in days. Moon Systems -- If you found this interesting comment below and if at least a couple people are interested I will continue with a lot more info. Specifically types of planets and realistic ranges of their properties.
×
×
  • Create New...