Yoarii

Not an actual bug, but some general feedback. The time it takes to repair a ship seems based on core size with a time of 3h for an M-core. That seems very steep. I get it, it is not a replacement for the repair tool, but still. imho the time it takes to repair should be based on the amount of damage that it needs to repair, not a fixed time.
 
Also, are repair talents taken into consideration when using the maintenance unit to repair a ship?

Not an actual bug, but some general feedback. The time it takes to repair a ship seems based on core size with a time of 3h for an M-core. That seems very steep. I get it, it is not a replacement for the repair tool, but still. imho the time it takes to repair should be based on the amount of damage that it needs to repair, not a fixed time.
 
Also, are repair talents taken into consideration when using the maintenance unit to repair a ship?

Not an actual bug, but some general feedback. The time it takes to repair a ship seems based on core size with a time of 3h for an M-core. That seems very steep. I get it, it is not a replacement for the repair tool, but still. imho the time it takes to repair should be based on the amount of damage that it needs to repair, not a fixed time.
 
Also, are repair talents taken into consideration when using the maintenance unit to repair a ship?

When logging out and back in, the MtU is no longer showing what it is repairing.

When logging out and back in, the MtU is no longer showing what it is repairing.

Not an actual bug, but some general feedback. The time it takes to repair a ship seems based on core size with a time of 3h for an M-core. That seems very steep. I get it, it is not a replacement for the repair tool, but still. imho the time it takes to repair should be based on the amount of damage that it needs to repair, not a fixed time.
 
Also, are repair talents taken into consideration when using the maintenance unit to repair a ship?

Not an actual bug, but some general feedback. The time it takes to repair a ship seems based on core size with a time of 3h for an M-core. That seems very steep. I get it, it is not a replacement for the repair tool, but still. imho the time it takes to repair should be based on the amount of damage that it needs to repair, not a fixed time.
 
Also, are repair talents taken into consideration when using the maintenance unit to repair a ship?

Subject: Dynamic properties can't be removed from databank dismantled by the maintenance unit. Not confirmed if this is a general issue and not directly related to the MtU. Version: 1.3.0-PTS Impact: Element not stackable with others/unable to clear contents
 
 

Subject: Very short render distance Current Version Number: 1.3.0 PTS Impact: Visual Summary: The maintenance unit only renders when closer than ~44m

Up until now snapshots haven't really mattered unless your ship was getting shot at.  But it sounds like they are going to matter more now.  Could we get a bit more info on snapshots?
 
I know that i can take a manual snapshot from the context menu in build mode.  And i think a new snapshot is taken every time you leave build mode.  But i also get a message saying that the snapshot failed sometimes.
 
If i enter build mode on my ship, while it has damaged elements, will they be saved in the snapshot and no longer be able to be repaired by the maintenance unit?
 
Maybe i'm misunderstanding something, but that doesn't sound ideal.
 
 

There are so many “simple” quality of life fixes like this the NQ should be loooking at to pad their release notes with. Low hanging fruit, if you will. 
 
Many of these are elementary interface tweaks, that theoretically could be done by a Junior dev. 
 
but even before that, there’s an argument for bringing the entire interface into the 21st century since it currently appears to be html 4 and css 2 based judging by just how static everything is. 
 
 

Put in a support ticket with info to where you want it moved. We had ours moved in beta, maybe they still do such things.

im with Yoarii on this one. I think the HQ were merely places to put your stuff without taxes are without worry of them becoming unclaimed. I don’t remember specifically hearing that they would be a permanent repository. 
 
Sanctuary, however was supposed to be the place you could put all your stuff and it would never disappear. 
 
is that still the case?

Were they though? I can't remember ever seeing NQ saying that straight up. Only permanently safe place were supposed to be Sanctuary/Haven.
 

Were they though? I can't remember ever seeing NQ saying that straight up. Only permanently safe place were supposed to be Sanctuary/Haven.
 

Services? Oh, should we read that as Dispenser APIs are coming? And reversed dispensers? ❤️
 

Oh, what a teaser! I'm guessing detached camera with pathing. That'd be nice for the streamers, if not so useful for the general population.

I can confirm that there is still some development going on on the Lua feature.  Don't worry, there are many things planned that have already been exposed to the Lua community; it just may take some time or wait for the integration of other features (like for example the known issue of remainingSchematics that will be solved with the integration of another feature soon).

But no no, I'm still here and still working on extending the possibilities of Lua especially for content creation.  

Randomly generated missions. Different for each player and rerolled at random intervals, if not able to be rerolled by the player.
Missions will have random starting and ending spots, and random volume/weight to move. Payout is calculated by distance and weight.
It would be possible to (wait to) reroll missions until enough were similar across a series of alts and still game the system as it is now, but it would be significantly more laborious, especially if there were a lot more pick-up/drop-off points.
On that note, let players create pick-up/drop-off points for NPC missions, an element they can place on their base. Generating traffic between player tiles should be a top priority if "community" is a gameplay aspect to be emphasized. To prevent exploits, like players placing these far out of reach, let us have some context-menu option to operate the element from a distance (maybe "get package" from an "active missions" tab, so you don't have to be physically interacting with it and players can't be trolls)
Other possibilities:
Missions should be granted by a mission hub, another unique interactive element, instead of taken from an F- menu. This would mostly be cosmetic, but this element can also be one that players build and can set up to be public, like a DSAT, again generating traffic between player-made cities.

Not just the devs. The entire staff should be playing. That way, the people writing the public patch notes can, from personal experience, highlight things that are important to the player about how new developments impact play, just for starters.

It's no secret NQ isn't that popular among most of the core player base. There's a few stragglers who will back NQ no matter how hard they kill the player base and how many bad changes are made but the lack and loss of players since beta and release is notable and a problem NQ needs to recognise. 

With that being said, I'm not here to criticize NQ on what they've done wrong. If they're not already aware of this they should be so I wont pound this in here.  

Now I want to make this clear. I love this game and its potential. It is 100% possible to Love DU and dislike NQ. The DU idea is where the love sits. The lack of NQ's understanding the game and their lack of understanding of the players is where the problem is in my eyes. 

Lets take a look at a game thats gone through a similar dev structure and situation as DU:

 FacePunch Studios was a indy dev team ( literally a modder who went pro) that had its roots from Garry who designed "Garry's Mod" and later on "RUST". When Rust first started out it was just a tech demo within Garry's Mod. It progressed to what is now known as "Legacy Rust" which was a rough copy of what RUST is today and was built on a limited Game engine. The game was extremly popular and actually eventually out played its Engines capabilities. Garry having built his success off Garry's Mod had a very solid understanding on how his community and there for player base was extremely important in his success. He realized very early on they were the reason he was where he was. Without getting too indepth on how RUST was developed it always had one major rule structure and it went something like this:

**Players First** ---> Money Second ---> Outside Investment Last. 

With this rule in mind, Garry and FacePunch knew that Legacy Rust couldn't be upgraded to fulfill what the players wanted. But they saw the opportunity and potential the game had.. The extremly hard decision was made to scrap Legacy Rust and design a new Rust from the ground up, Engine and all. This was HARD WORK, a HUGE RISK, but... it was what was best for what the players wanted and the games vision. 

Now with that history lesson complete. I'm not saying DU needs a new game engine or a redesign. What I'm getting at here is DU sits in a very similar situation business wise and in game development. Where NQ has failed and FacePunch thrived can be narrowed down to the way the two dev teams listen to their players as well as the fact that FacePunch devs were required to play Rust a certain number of hours per day to ensure they understood the game mechanics they were designing. 

With over 4000+ hours in Beta and nearly a 1000+ hours in release, having stuck around through the disastrous 0.23 update and the later mining and territory updates that all saw a mass loss of players.. Its very clear to me after having been through FacePunches success from that Tech Demo in Garry's mod all the way to where RUST sits today. NQ could learn a lot about community and how to properly make big changes to DU through RUST and FacePunch's success. 

Please, NQ if you're reading this. Take a quick look at https://www.rustafied.com/ and scroll through the games past few years of development and the early days. EVERY game change and update has been very accurately documented via Rustifieds awesome update news posts. 

Take note on the changes, how they came about and how often the player base was consulted and accommodated. I understand these two games play very differently. But the core idea stands that they both require a somewhat accommodated and happy player base to succeed. 

With all due respect. You have failed on this part NQ. The current player base and market situation speaks for itself. First things first. Require your devs to play the game. Set a required hour per week and pay them to use it. Second, from now on. Consider what changes you make and the effect they'll have on your games "FUN" game loops. 


~Sarrah ~ (8900 hours in Rust, 5300 hours in DU) 

Yes, we definitely need a visual separation between element lives and regular dynamic properties as well as the proposed inventory stacking based on lives left.

Yes, we definitely need a visual separation between element lives and regular dynamic properties as well as the proposed inventory stacking based on lives left.

Lets assume we are talking only about Basic Space Engine L.  This applies to all but I want to make it simple.
 
I have these items below....
 
30x Basic Space Engine L - New
30x Basic Space Engine L - 2 of 3 lives remaining
30x Basic Space Engine L - 1 of 3 lives remaining
 
I now have 61 slots in a container taken up.  
 
Can we please get the ability to stack parts with equal lives remaining and instead just have 3 slots taken up?   This has an effect on being able to use dispensers as well since I would have to reset the dispenser for each individual element as opposed to using 3 separate dispenser to dispense a part with equal amount of life left.

This thread isn't about clipping elements in to each other like people used to before NQ stopped that, its about un-cluttering the inventory screen with damaged elements, and allowing them to be connected in a long-term useful manner to dispensers.
 
This seems a very reasonable request, though I might also ask for some kind if indicator in the corner of the element's inventory icon so that we can see how many lives elements from a given stack have remaining.