KwarkM

Honeycomb is the Major game content of DU which pretend to let players build what ever we want
But as it is now, it is tooooooo constrained and limited, buggy, and never looking as we wished, specially in between updates where dev dont know which numbers to tweak for better render results
 
 
The resources needed for making honeycomb: Some honeycombs such as concrete / brick / wood / glass(panels) should require more simple recipes, not requiring mined and refined ores, but raw stone, sand or wood, directly from the planets grounds and trees
Those could be considered as construction material, mostly for static constructs, and their weight should be increased for discouraging players using them on dynamic constructs
 
The honeycomb weight: As for now they are 0.1 times the weight of their relative correspondents on earth
In my opinion the word HONEYCOMB is well chosen, and give this futuristic aspect of a 3D printed honeycomb material
But i think it is still a bit too heavy, since in aerospace, it wouldn't happen to build ships with thicker hull than 5 or 10cm
I also think some honeycombs shouldn't have this weight reduction, or less reduction
For example: concrete * 1 / wood * 0.25 / metals * 0.075
 
The diversity issue: Here is my most hatred part of DU, the numerous amount of different honeycomb colors and finishes
nightmare for industry managers nightmare for players to spawn blueprints, that have dozens of 0.5m3 of different mats filling hundreds of container and inventory slots (that must be a lot of data in back end, but also lot of data for everyone uploads and downloads on front end) All refined material should have 1 and only 1 raw honeycomb with a raw aspect, on which we could later apply the color we want and the shininess we want in build mode
 
Removal of the "voxel replace tool" => replacement by the "voxel paint tool" I dont think anyone using this voxel replacement tool at all, it has its equivalent when copy pasting using the select tool
A paint voxel tool could use a popup window, around the bottom of the screen, same as the scanner does for the ores filters. In which we could select our
desired custom color from a palette the shininess we want from matt to glossy an optional bump map (stripes / screws / holes / galvanized etc...)    
The finish name "galavanized", change back to matt Galavanized is an anti rust coating process for iron, using zinc
From PTS server the "galavanized white iron", is the only correct color and aspect (the texture is pretty nice btw)
So :
galvanized only applies to iron, certainly not to aluminium, copper and others iron can be painted aswell with anti rust paint, but galvanized wont be galvanized is more of a raw finish texture, more than a color or a shininess (which could be added as a bump texture in the paint tool options)  
Textures scale New textures are gorgeous but they arent scaled properly (official and PTS)
Texture edges blending is also necessary
 
 
So Novaquark, if you desire to optimize, reduce lag, reduce loading of containers etc... the diversity issue should be your concern. If you desire to really let players build awesome creation, just unleash the constraints and give us more freedom of choice
We are not paid for testing, and for taking time developing our feedback on the forum after years of testing, so it would be nice to have a better reading of the gold mine for the game development that this forum is (taking notes, and putting them on a big white board is an idea)
After all, WE players are creating the content of the game, but if we dont have at least the few main features of Minecraft, which is gathering wood to make wood, not mining coal to make wood, that aint gonna work
 
Cheers

you could try adding a rectangle in the background by adding
<rect fill="white" height="3000" width="3000"/> between the translate and the first path.
since i'm not very good with svg too there might be better way but this worked for me

C:\Users\[User Name]\Documents\NQ\DualUniverse\holograms
IIRC

About
This is a short script that prints base max thrust of linked engines. It can serve as an example, and may also be used to detect which engines do not have a technician buff applied to them.
 
Set-up
Place a programming board. Link up to 10 engines to the programming board. In the Lua editor (right-click, "Advanced", "Edit Lua code") create a unit start() event handler with this code: -- detect linked engines local engines = {} for key, value in pairs(unit) do if type(value) == "table" and type(value.export) == "table" then -- `value` is an element and `key` is the slot name if value.getThrust and value.getMaxThrust then -- `value` is an engine engines[#engines + 1] = value end end end -- get engine names local engineNames = {} for _, engine in ipairs(engines) do -- engine name is available in its widget data -- for other elements `core.getElementNameById` would have to be used instead local dataJson = engine.getData() local data = json.decode(dataJson) engineNames[engine] = data.name or "???" end -- sort engines by name table.sort(engines, function (engine1, engine2) return engineNames[engine1] < engineNames[engine2] end) -- print engines and their base max thrust system.print("Linked engines: " .. #engines) for _, engine in ipairs(engines) do local name = engineNames[engine] local maxThrustBase = engine.getMaxThrustBase() system.print(string.format("%s: %.0f N", name, maxThrustBase)) end unit.exit()  
Click "Apply" in the Lua editor, exit build mode and activate the programming board. You should see base max thrust printed in the Lua chat tab.  
Change log
2020-09-13. Posted the first version (tested in r0.21.5).

the scaling is wrong in your STL file. this is how big the model is without modifying it after loading: 2.54x1.39x1.35 mm. ( can be scaled up manually though)


It would be really nice if you could share some more OBJ or STL files for ships. maybe for things like in-game contest winning designs? Or even better allow us to export OBJ models of our own ships.-

Knowing more about how the game mechanics are turning out I think this can all be done with an augmentation to TCUs.
 
Why not have a TCU be a player bound incorporeal object. This would be their one and only TCU. Once put down it can claim adjacent tiles overtime either through UI or with a smaller TCU extender item (that can only be placed adjacent to TCUs). Each additional tile would get exponentially harder to claim and maintain. This TCU's territory could be committed to an org or the player. The main TCU can be destroyed but after a cool down period it can be placed on an unclaimed territory. 
 
I think this encourages orgs to control zones rather than a patchwork of individual tiles. It allows for more territory (zone) based game mechanics. Also, this would allow individuals to have atleast one TCU that they will have throughout therir entire DU career. Just throwing it out there.

Did you receive a email yet? Emails need a little longer now and then. Also make sure to use your email as login-name.
 
Try emailing support@dualthegame.com for help otherwise.

Great to hear that.
 
Have good time. Thanks for all the community work you did!

You should delete this Post and open a new one in the NDA Forums.

This is actually really important, so you may already have a plan for it, but if not, it is an important thing to consider.
 
after the game has been running for years the terrain will be chewed up with tunnels and ditches, and buildings abandoned no longer used will scatter the landscape.
It happens in every game like this that is a persistent world, and it is easy to handled, but rarely is handled other then with server resets, that  always get someone upset.
 
Also since worlds are algo generated, the size of the change file on top of the generated terrain will continue to grow to 'difficult to layer over' algo generation sizes.
 
All that has to happen is for each change to the environment to have a durability, and stamp of last time it was maintained.
For tree squares, and ditch squares it is easy, any 'changed terrain' next to algo terrain(unchanged) begins to change back.  Different for each type, sand faster then soil, soil faster then rock.  And trees grow back.  All you have to do is look at the time stamp of the change voxel that shows its date of change or last maintenance, and if it is next to a unchanged square and every x amount of time move its durability.  As durability goes down, land gets smoothed, when it reaches 0 durability the change to that voxel is removed.  The removal happens from unchanged territory towards changed territory, so it is like the original land organically grows back over time (and is realistic actually)
 
This means that if a person digs a tunnel, 1 voxel wide, it will go away say in 2 days, unless they add to the voxel a 'support item'  (made from wood and/or rock/cement, giving reason for those items.)
so if someone is tunneling to get dirt, or to get to some location they won't return to, they don't care about keeping it open, and they don't spend the time to reinforce tunnel, and it closes, if they have it as an entrance to a base, they must put up timber or masonary walls to support a tunnel, and easy crafting item, but some extra work.  This is so you don't have ditches everywhere, if they put a frame in the ditch it stays open, and actually looks nicer with a texture that covers walls, then the ditch or tunnel wont shrink in as fast because it won't be sand time, or soil regeneration time, it will be frame supported sand regeneration time.
 
It is really easy to do, simply remove changes, if they reach durability 0, and paint them with different texture if they at 75 50 or 25. 
 
The time scale to revert back is design decision, but it will keep the terrain looking good, and keep weird stacks of sand from littering the landscape.
 
Also any player made structure should require a maintenance bot machine that uses fuel, and can be connected to fuel tanks.  The base bot would be a unit that covers some area dimensions.  A tunnel version would also exist that would be put in an alcove.   (animation would be optional)  Device would report areas it keeps up to date, and fuel cost based on number of items in the area.
As long as a player wants to provide fuel, the repair bot keeps his base from deteriorating, but if he doesn't fuel it, pieces start to deteriorate, when they reach 0 they disappear.
that gives both a resource sink, and makes it so that players that move on to other locations on other planets don't leave hundreds of buildings unused across the landscape,
and if they want to use some building they have to at least supply it with fuel, a low cost but basically gives player the decision to keep or let decay a building.
 
It really solves the clutter that will have to happen when thousands of players for years are digging up terrain, or if some group decides to cut down every tree in some area or dig up every beach.
 
without this mechanism, one days game play of a beach digger can remove the landscape beauty for years, and that is not balanced, and is why you see many games reset there servers.  This method puts the reset into a simple algo that is checked a few times a day, and changes the terrain automatically simply by running through the changed terrain file and modifing a value, or removing the changed terrain making the voxel have its original algo determined look.
 
Change removal would be put on a que, and would only occur when no players are within a certain distance, there is no rush, it is not time critical, and could even be a simple worker thread, since if it reverts an hour late because someone around there thats fine, but if it is that close, the walls would show it with cracks and discoloration, and same with sand or soil walls in tunnel, the texture at 25% would have large cracks in it.  The mechanism to remove a change is to both remove the previous item from the 'change file for an area' and the notification to be a 'change' order that is also removed, as an add of a new change object that does exactly that, so it removes it from client, when downloaded, and is not added in next time server updates the area for client.   That should make sense.
 
The selection of the texture based on durability would be client side.
 
This should make sense, and it really is much benefit for a little added mechanism.
 
Just thought I would share the idea after seeing so many persistent MMOs with large areas that looked great for three months that were ridiculous when they needed to continue to build a client base going into 6 months and a year since release.   If you add change to terrain, there has to be a slow change back mechanism, and persistent MMOs been missing that part for years.
 
 

As the name implies, Dual Universe Sleepers is a temporary initiative: it will cease, or at least change, when we awake, i.e. according to NQ's current lore, at Release.

I'll keep making daily notes for my own use but will then switch to my "real" original project: collecting and recording knowledge and history through an ingame library with ingame readable "books" (programming boards with screens and buttons, most probably), open to public use in a safe area.
 
Details are still in the works but there will be books, as many of them as possible, from different writers and in several languages.

The latest State of Affairs is out for your reading by our own Kurock
 
It sums up Dual Universe from July 2019 through January 2020, remember to Comment and Share it!
 
https://www.outpostzebra.com/dual-universe-state-of-affairs-alpha-2/

An idea that I would think would be great fun is to copy from Eve is the Decorations system.  It is a completely for-fun system whereas an Organization can bestow a medal of commendation to a player for whatever reason.  Medals are designed by the Org leaders with a name, design and description.  These commendations would show up on a player's information screen somehow, and could be removed by the player if they choose to.  These medals could be given by Legates of an Org for any reason they could come up with, with ideas like:
 
Org participation and/or Contribution Reaching a milestone (PvP kills, Constructs Produced, Hauling Jobs completed) Taking part in a major battle/event Making a huge mistake and laughing about it (crashing a huge spaceship, setting RDMS wrong and stuff getting stolen) Leaving the Org on good terms