Ambaire

Title

NQ probably think... who knows what they think, they never tell us, but they probably think that they are saving congestion on the game chat and forums by porting anything intensive to a 3rd party program.
 
It's a horrible idea.   People new to DU, but not MMos think that it will be like an ordinary, normal website that will have a dedicated support forum and in game chat channels.
 
When they don't find it they, understandably, litter up the support channel and all forum channels looking for help.
 
I've seen requests for help in the middle of unrelated topics, in the Recruitment channel and probably other places.
 
When the forum responds with "go to a support area not found in the game or forums or go to Discord", well that's a proportion right there of already frustrated players asking for a refund.
 
It's not like the help on the Discord channel is exactly zippy either, so the plan isn't even doing anything but porting a badly communicated delays to Discord and STILL having a clogged up forum.
 
Mini rant over.  Tl;dr  NQ needs Support to go to normal channels even if it means hiring another sub server and is just further evidence  of NQ's woeful communication strategy.

Yeah. This other thread is a great example.
Since the launcher / game login screen has no server status info or useful error messages, you get posts like the following:
and my reply
e. go to try to log in right now and

Any newbie would be like.. uhhh... what?
 
Nope, no problem on the player's end. Just another thing that makes me wonder WTF they actually tested in the Alpha.

It means the servers are down. They took them down roughly an hour ago to do database maintenance which the ingame message said would last ~2 hours.
 
Why the players have to inform other players of this.. lol.

OR.. :shock: :horror: Maybe put that server status thing in the Launcher? What a novel idea!

OR.. :shock: :horror: Maybe put that server status thing in the Launcher? What a novel idea!

I have seen no talk of planetary resource regeneration, yet.
 
To take a quick look at some other games with similar gameplay elements:
Space Engineers has infinite asteroids, and its planet deposits are far richer than Dual Universe's. 
Eve Online's asteroids respawn every day.
Empyrion has meteorites that fall on a planet if all deposits of a type are mined.
No Man's Sky has basically infinite resources even on a single planet.
Factorio has a basically infinite map with resource deposits getting larger and larger as one gets further from the center.
Oxygen Not Included allows rockets to be launched to planets to retrieve resources.
Surviving Mars has the Mohole wonder which gives basically infinite resources once constructed.
 
What mechanisms will be in place for this in Dual Universe? I am especially concerned about this as some resources can only safely be obtained from relatively small moons, and once those moons are mined out entirely (I see this as inevitable considering the territory scanner mechanic and how many people are in the larger organizations), there will be no easy way for new players to obtain them without needing to resort to market trade. Even venturing further, the resources are limited.

Skill injectors were the worst thing that ever happened with EvE. It will be a big disappointment if they appear in DU. 
This mechanics allows to create skill point farms with actually dead characters just to resell sp.  
Why not to sell skill points directly from ingame store then, along with premium ships and modules.

While this feedback may not be applicable to all users, I've found the initial progression as a solo player to be excruciatingly slow.  I chose a tile on a mountain (550 altitude), and as far as I can tell there are no veins that I can detect above or below ground yet.  This means I have to mine rocks, which sucks but it's not the end of the world. I shouldn't have to hollow out a mountain randomly to find Iron.
 
Factorio is one of my all time favorites.  It's very similar and it's mastered the long slope of progression in a way that even the daunting ceiling is fun to work towards.  You build a bus of ore > ingots > composites and then you add to it all the sub components needed.  It lets you focus on resource identification and always optimizing and redesigning - always feeling like progress is being made.
 
In DU, the same feeling is not captured.  Initial experience is a harsh grind, not because of quantity of things to make - but the inability to establish unoptimized systems early on. Moving away from a bottleneck (nanocrafter) is important.  Some reasons why this experience occurs.
 
Impossibly to produce in parallel.  There should be XS versions of all assemblers and refineries.  Without these, we can't even begin a multi-threaded factory. Assembler M requires too much production and establishing even 4 refineries for the basic ores takes much too long. There's no small factory to produce screws,pipes,etc.  I would expect there to be at least an assembler XS for these.  Players will need a surplus of these. Industry units as prerequisites are time sinks.  They don't do anything except gate the machines that produce. The only refinery is M and the path is too long.  This early into the game, I shouldn't be weighing the path of spending 400K on overpriced refineries in Sanctuary to establish a production line. Inventory management is a pain, because all production stops in order to make containers of a notable size. Why again are core units size restrictions a thing?  Shouldn't scale be limited by resources and not artificial bounds? Beginning static unit is XS but first assembler is M.  Assembler M completely out-scopes to size of unit XS volume.  Beginners shouldn't be building dense cubes of components to eek out production.  Adding more XS cores would help to not feel confined, but for some reason there's a limit of 1.   Core upgrades are non-existant.  I shouldn't have to repackage an entire factory to upgrade. Action items shouldn't take up inventory.  These should be moved or hotbar adjusted.   Sort inventory by type or volume would be helpful  
Hopefully stuff like this will improve, as new players might look at this and skip the game, assuming the later game is much more grindy.

Yes this is ridiculous. Choose material -> choose pattern -> choose color. Why does everything in DU have to be purposefully unintuitive?

Hi folks,
I was looking to set up some simple scripts this evening to streamline my refining process however the scripting api around containers and industry units seem quite limited. I thought I'd post here to see if I am missing something obvious.
 
1: it seems you cannot query the contents of a container, other than just getting the raw mass? I would like to check if I had a particular volume of item in a container ie: bauxite >= 50l. Is there a way to do this?
2: it also seems I am unable to set a recipe on an industry unit via scripting, is this correct?
 
What I am trying to achieve is to check how much of each raw ore I have in a container, and then set my refinery to refine the correct ore based on the container contents. Anyone got any ideas? I am comfortable with scripting, it just seems the api does not support it. Is this right?

As the title says, blueprints are 100% broken currently. I have nearly 2 dozen of them, ones from alpha, and ones I made today. None of them work. They either say I'm missing items in my inventory that "I HAVE IN MY INVENTORY" hence the green cube. Or when placed the blueprint is ONLY the modules are placed, and all honeycomb materials vanish into the ether, removed from my inventory but never placed, leaving me with a giant ball of floating modules.

As I have been playing this game for the past week, I have been wondering about the internal mechanics of the server engine. Obviously without the code I can't know what is going on , but I can guess.
 
1.  There are numerous microservices in a distributed environment.
2. While load is light, these work just fine, very efficiently.
3. When load is heavy, the queues get very deep and cause deadlocks between different microservices
4.  Users start cancelling requests with other actions
5.  The old actions are clogging up the queues, more incomplete actions pile up between the microservices as users get frustrated and repeat actions quickly.
6. Everything grinds to a halt until a bunch of people are forced to lose connections or the servers are reset.
 
 
My suggestions:
1.  Have a max queue depth of no longer than 10 millisecond's worth of data. Deeper queues are NOT better.
2. consider using parallel queues, if one gets stuck for too long, just kill the whole thing and proceed with the unstuck one.
3. Use backpressure to notify fillers of the queue to wait. It is easier to cancel actions if portions of it haven't been submitted to other microservices yet.
4. Consider using tags to quickly remove cancelled requests from heavily used queues.
 
Anyways, I hope NQ can solve this as I love the game and want to see it thrive.
 

Try using the scanner to estimate where the ores are and you won't need the detector at all.
 
The trick I use is that I only move in 6 possible directions when searching for ore:
Cardinal: 0, Angle 0
Cardinal 180, Angle 0
Cardinal 90, Angle 45
Cardinal 90, Angle -45
Cardinal 270, Angle 45
Cardinal 270, Angle -45

Do we really need to have all the different honeycombs, divided by different textures?  Having to keep so many different kinds of honeycombs on hand in order to give our creations different colors & textures is kind of a PITA.
I DO enjoy the varied statistics of the different honeycomb materials. (pure & products)  Would it not be easier on both the players and the servers if we limited the honeycomb down to one block based on it's material, and offer the players a "paint & texture tool" instead?
 
Thank you

I only started playing 4 days ago, but I've found dozens of ore deposits and never really had to excessively search for any of them.

Dig east/west until closest point of approach
Dig north/south until closest again
Note distance, move that distance in a cardinal direction and dig a 45 degree tunnel back up/down. Should be right on target.

Hi Noveans, 
 
Dual Universe is now in Beta 1 r0.21.4 version. Please read carefully about the idle constructs auto-compacting activation.
 
Bug Fixes
Fixed an inventory exploit when force respawning from the login screen Fixed elements that could be raycasted through a force field Improvements
Client/server voxel communication optimization Idle constructs auto-compacting activation: To improve performances around cluttered points of interests (Districts, Markets, Ship-Shops...), we're about to compact and give back in player's inventory any construct matching the following criteria: Based on an XS Core Unit without any container with one fuel tank tops without any weapon with a maximum of three atmospheric engines with no space engine in a radius of 1 kilometer around any point of interest having a mass up to 20 tons after 3 consecutive hours during which the Constructs have remained in "idle" (not used) state.  
This special “compacted Blueprint” allows you to deploy your construct again for free and the fuel in its fuel tank will also be restored as well.
 
If you don't find a Construct of yours where you have parked it a moment ago, this may be because of this so please check first your in-game notifications and your character inventory before panicking and contacting the Customer Support.
 
Cheers, 
Nomad

My largest concern about this game is the opportunities that griefers will have. I hate pvp, doesn't matter what game it is, FPS, RTS, MMO doesn't matter. I detest the concept on a fundamental level. I plan on building ships, I already have designs for required dozens of players to use efficiently. I also want to build space stations and shipyards. I have absolutely zero interest in participating in any combat, all i want to do is build.  I like the idea of "arena zones" that are specifically for combat. Otherwise players like myself will be griefed endlessly by the more disreputable members of the community. Sanctuary zones need to be more common and easier to make use of.

Over the years I've found that the only way to please everyone in a game with a complex crafting system and economy is to implement Google Sheets into the game client.

Hello Novaquark,
 
I apologise for the pompous sounding post I'm writing, I'm not normally so self-obsessed, but I feel the need to get this across as it's a CRUCIAL QoL thing for DU industry people.
 
In my job (I am a planner for electronics manufacturing, a simple low echelon MRP monkey) we work with the obvious concept of demand. DU is no different. We create works orders  (DU "item in queue") for end products that in turn generate demand for sub-assemblies, which in turn generate demand for further sub-assemblies all the way down to a base material that doesn't need to be manufactured. So we have a list of works orders all generating demand for the item provided by the next level down the chain.
 
So far, so obvious. What the production screens in DU fail to do, however, is demonstrate the total amount of demand, currently generated by all loaded works orders in the production queue, for any given sub-assembly or material. E.G., If I have multiple queued works orders that all demand varying quantities of Basic Pipe, I don't know what my total demand for Basic Pipe is without doing a lot of messing about, flicking between screens and doing arithmetic. It isn't immediately obvious how many Basic Pipes I need to make. 
 
So, what we need to see is, when we click on a material in those production screens (and ye Gods, the "Ingredients" in the list on the Assembly Lines need to be clickable), somewhere on the screen should be a short list of the jobs, with quantities, that are both generating demand for Basic Pipe or whatever material you are looking at, AND what Basic Pipe production orders we have on as well.
 
This takes the simple format of a bank statement (I'm sure jobs in the queue have a unique job number that you can display):
 
Basic Pipe
Total Stock: 24
Job  No.      +/-       Qty       Running Total
12345            -          13               11
13345            -           6                  5
12211            +          4                  9
16611            -          14                -5
16520            +          8                  3
 
This table, nested somewhere on the Basic Pipe production order creation screen, demonstrates to me immediately that I must either move job 16520 and place it before job 16611 in the queue, or create another job for at least 5 units and place it before job 16611 in the queue, or face a stoppage.
 
As a job is completed, it disappears from the list and the "Total Stock" field is updated with its new quantity.
 
In current implementation, this information is not shown.
 
This only leaves the question of what/where Basic Pipe works orders should be included on the list? I would probably go with works orders that are on machines/nanocrafter that have inputs that come from the same container. So if I'm looking at a Basic Pipe works order creation screen for a machine that outputs to Box A, all machines that also output Basic Pipe to Box A, and all machines with orders in their queue that demand Basic Pipe and that pull from Box A should be on the list, displaying their demand/output.
 
If we are going to have numerous sub-assemblies using various production cells, this sort of information summarised this way is absolutely crucial. Without it, we're lost in a sea of demand that we cannot easily describe and translate into works orders. Please, for the love of God, implement .
 
I don't know if this forum has an upvoting system, but if you're a DU industrialist, please upvote and bump, you'll thank me.
 
 
 
 

Please add honeycomb material colors that match the slightly off-brand colors that the majority of our components use. You give us basic colors like "Red" "Grey" "Brown" but nothing in-between, even though all the components are designed with colors that do not match any we currently have available.
 

 
Adding colors similar or derived from the base colors of the components would diversify the appearance of ships significantly. Thanks for reading!

Please consider moving the tutorials away from the bustling markets and into a fully singleplayer environment. All of the optional tutorials already put you into a load-gated area, so a loading screen to send you to a singleplayer experience wouldn't feel any different from if it were connected to the shard.
 
Additionally, albeit more controversially, I believe DU needs a singleplayer ship editor. I understand the concerns, DU clearly wants everyone in one universe, but I think for ship building we should make an (optional) exception. Allowing dedicated ship builders to use a singleplayer editor would reduce much of the server strain caused by having to constantly update and validate thousands of constructs real-time. Players would still have the option to make their constructs in the single shard and cooperatively with other players. The only thing adding an editor would do is provide a less server resource intensive outlet for ship designers to work privately. This doesn't have to be a black or white solution either, DU could adjust the editor's features to include only what they think should be included.
 
In summary, I believe reducing the cost of operating servers (thus potentially reducing the cost of the game, increasing potential players!!) should take priority over forcing every single person everywhere into the single shard, even when what they are doing has no impact on immediate state of the universe. Reduces the server strain and operational costs, improving stability, bringing more players to the universe, balancing out those that are temporarily in a singleplayer experience.
 
Thanks for reading.

If You mean instant craft, then the answer is big NO, because it will ruin the industrial part of gameplay. I know that words like cheap and expensive are relative, but $7 for a month - give me a break. I see that NQ are making everything they could to give us best possible product at this stage of development (frequent updates with observed improvements in gameplay /in my case/) and things like loading times aren't bad (maybe your hardware is reason that You feel it differently), ofc they are not ideal but this will be sorted out sooner or later. Be patient.

So the idea is simple. Add a runway to the market hubs.
 
Why?
1. Easier to land then on a parking lot littered with a combination of ships, players, player ads, a large ad sign, random constructs, dark spots, light poles, other ships trying to land, and a tower that doesn't like you near it to boot.
2. I am sure I am not alone that some ships are built more as a jets and less as a hover crafts so landing gets dicey at the market hubs
3. A runway could also provide a format for players to have a role in directing traffic and such 
4. Oh yea...It would be pretty cool addition to the game
5. There is ample space...why not?
 
Now i have no idea how you would deal with people clogging up the runways but ....I'm just the idea man here. 

It would be useful if construct owners could permit specific players to build only in specified zones of a construct via RDMS. This would be especially useful in, say, an apartment complex, where you could allow a resident to edit and furnish their apartment and not any other part of the complex. Construct owners wouldn't have to find workarounds like splitting it up with multiple core units, for example.