Velenka

I seriously doubt they are not adding CvsC to the game. The question, I hope, is when. Hit the stretch goal, maybe alpha. Miss it, probably later, sometime in Beta.

I seriously doubt they are not adding CvsC to the game. The question, I hope, is when. Hit the stretch goal, maybe alpha. Miss it, probably later, sometime in Beta.

I agree there should be explosives of some type or another. How powerful they should be will be a very crucial balancing element in a game like this. I don't think we can determine that this early in the development cycle.
 
Structures would have to be easy to defend with shields, turrets etc. to allow for big explosives without upsetting the balance. This is also closely related to the question of how much damage you should be able to do in foreign-owned territory, if there's some magical protection against damage, if you can even damage stuff in foreign territory at all without fighting some kind of red tape á la war-declarations or "hacking", and so on.
 
Personally I think I'd favour a system where there's little protection or automated defenses, but explosives are rather puny for balance (do a lot of damage and destroy voxels, but have a very small explosion radius). Simply because this would be less punishing for builders. Hey, those guys took over your base, but at least it's mostly intact and they can appreciate your designer skills. I imagine this would be less upsetting than seeing it all reduced to craters.

Here i outlined some basic ways to define actual detection.
 
 
 
 
i like the idea of just needing the object ID to identify a located target in the computer system, but it also seems slightly limited in what the player can do with software to locate/identify/track targets.
 
maybe replace it with a more generic "point/vector" primitive to which characteristics can be added by the player?
 
the primitive would contain an origin, a direction and optionally a distance.
so its denoting "somewhere in that direction" or "exactly there".
 
those primitives can be handed over to other systems (like turrets) and the game engine handles all necessary coordinate transformations.
(cause thats a pain)
 
the primitives would be reusable for other purposes other than detection as well, for example for general navigation and communication of directions.
(hell, the direction vector could directly be utilised for target designation by the player "the first ship that intersects with my pointing vector", a raycast)
 
 
so, now to actual gameplay and not programming details.
 
a passive sensor cant determine the distance to an object on its own. it either needs a reference emission strength (it receives x watts/m² object radiates y watts so the distance has to be r away x=y/r²) or a second passive measurement which has to be some distance away to cross the vectors and to determine the distance that way.
active sensors provide their own reference emissions and thus can pinpoint targets on their own, but they are very visible over great distances (the square of their detecion range assuming identical ships)
 
again the vector math should be done by the game engine
   
the vector headings shouldnt be perfectly precise but have some imprecision in their heading.
so one sensor might have an angular resolution of 0.5° which gives good enough data at short ranges but isnt suitable for long range fire
and another sensor might have an angular resolution of 0.025° which is suited for much longer range pinpointing but the sensor also has balance defined drawbacks.
this would enable confusion plays with multiple ships flying close to each other. appearing like a bigger target or a different target than whats searched for.
 
 
player programming skill should come from choosing which vectors to analyse more closely and which vectors to "cross" to determine pinpoint coordinates.
the rate at which vectors can be compared could be game mechanics limited ( x comparisons/second per DPU) so that good programmers would have an edge in terms of target detection by smart choice of the vectors to analyse and cross for coordinates.
 
so one could run target identification by brute force and a large amount of DPUs or by smart checking and using the resources they have optimally.
with a way to have DPUs communicate even across constructs (linky) would encourage having specialised sensor and processing ships, which weave their com nets through the fleet and supply the less sensor focused ships with targetting data.
 
so for large battles dedicated C4 ships would be highly useful to keep all the targetting data organised, precise and distributed to the combat ships.
 
 
 
this also opens the gates for player made countermeasures.
 
have an emitter randomly switch on and off to confuse the distance assesments of active sensors.
 
throw out flares to confuse passive sensors.
 
randomly toggle emitters distributed over the surface of you ship to obfuscate your position and velocity vector.
 
 
 
 
edit: 
after posting i noticed a small gap in my explanations:
 
sensors on their own dont provide pinpoint coordinates, the player has to process data in DPU's to get pinpoint data.
the sensors directly only provide directions and emission strengths

I'm pretty sure that somewhere NQ said there's not going to be nukes. (not sure where, sorry) Other kinds of explosives, maybe. I would like to see some kind of infiltrator planting C4 in an enemy's base, that sounds neat. But it would have to be difficult, and the C4 can't be too powerful or else the balance gets skewed.

I don't see why this is a question. Obviously the answer should be yes. I like the argument OP gives under "No." I definitely should not lose my ship and supplies just because my game crashed while I was out exploring. A simple way to deal with constructs occupying the same space as the logged off character is to just move the character until there's no issue. Using something like bounding spheres, the player could be safely placed outside the construct, instead of being trapped inside. There won't be an issue with your constructs since they don't disappear.

The game won't be able to tell which areas are pressurized and where people could breathe because that would just be too computationally intensive for a voxel-based MMO to handle. So the game wouldn't be able to tell when its safe to remove the helmet.
 
I guess it would still be possible to allow customized faces that are visible behind the visor, but really, all things considered it makes sense to focus entirely on customizable clothing and armour.

I'd prefer to see crashed arkships as ruins only. Maybe with some schematics or something inside. But without any chance of powering it up and turning it into a safezone. It would be a construct just like any other. Still very rare and very valuable in a sentimental way.

A contract system might not work so well for rather vague deals, i.e. a privateer. A privateer might get hired to "harass" another corporation. It would be impossible for a computer to say when that was accomplished.
 
I would suggest that verification be a third party system. Whenever a trade or deal is made, all the information about the deal is contained in a parcel of information called a "trade packet." With a trade packet you get a unique ID generated. Call it the trade ID. NQ would be the third party responsible for storing the packet and the ID.
 
The two players making the trade get tagged behind the scenes with the trade ID. Anyone with the trade ID tag can look up the trade packet from NQ. Using this, it would be then possible to independently verify details of a trade. You could tag your boss and say "Yes I did deliver, look here." The boss could then use an in-game lookup function to look at the trade packet. Using a system like this would enable you to verify, but not enforce contracts.

Pretty sure NQ is aiming for a more physically based system, like Cornflakes says.
 
If you want your ship to go faster, add more engines.
 
If you want more protection, add more shield units.
 
If you want to deal more damage, add more weapons.
 
Then you add in power generators as needed. Seems pretty simple to me.

IMO this should all be controllable with RDMS:
 
For the constructs themselves:
Right to generate blueprint from construct
Right to add to a construct (voxels, elements, paint)
Right to remove from a construct
If the repairing mechanic is different from add/removing (which I hope it is, since you could repair without being able to add/remove), Right to repair
Right to trade
Right to use/interact

For the blueprints:
Right to switch between reuseable and one time use BP
Right to use manually
Right to use in a factory unit
Right to trade
If BPs are/can be contained in a physical thing, right to overwrite physical thing with another construct BP
If BPs are/can be contained in a physical thing, right to copy to another physical thing with rights identical to first BP
Rights should transfer in a specific way from blueprint to construct built from the blueprint. Either inherited from the original construct, or owner specifies rights at time of blueprinting. Owner would only be able to grant rights which he has.
 
This probably won't be an exhaustive list, but that's the general idea. Every action which can be taken with the BPs or BPing a construct should be associated with a right which is manageable by the RDMS.
 

IMO this should all be controllable with RDMS:
 
For the constructs themselves:
Right to generate blueprint from construct
Right to add to a construct (voxels, elements, paint)
Right to remove from a construct
If the repairing mechanic is different from add/removing (which I hope it is, since you could repair without being able to add/remove), Right to repair
Right to trade
Right to use/interact

For the blueprints:
Right to switch between reuseable and one time use BP
Right to use manually
Right to use in a factory unit
Right to trade
If BPs are/can be contained in a physical thing, right to overwrite physical thing with another construct BP
If BPs are/can be contained in a physical thing, right to copy to another physical thing with rights identical to first BP
Rights should transfer in a specific way from blueprint to construct built from the blueprint. Either inherited from the original construct, or owner specifies rights at time of blueprinting. Owner would only be able to grant rights which he has.
 
This probably won't be an exhaustive list, but that's the general idea. Every action which can be taken with the BPs or BPing a construct should be associated with a right which is manageable by the RDMS.
 

A good idea would be to put every player through the same sequence the main character from the short story written for DU went through. in the story, the main character woke from his cryosleep and spoke with the AI controlling the ship. Once able, he left the cryotube and explored a little. After a while, the AI spoke to him again and he was placed into a few 'training exercises'  inside the Virtual Reality zone the Devs mentioned to us. Inside the zone, we will be free to test out builds without the risk of crashing and losing materials as a result. I believe this would be the best place for the tutorial.

planets are 100km diameter right know, they want to make them bigger in the future. It's fine as it is, actually i'd like them to be smaller for a simple reason=social interactions. If the world is too large, people wouldn't meet. Like NMS.

I really think that people just don't comprehend the huge scale that are planets. There is no need to worry about completely mining out an entire planet any time soon. But after a time, maybe it will be possible to mine out an entire planet. I doubt it though, since it would also require lots of time and effort from many players involved. Unless literally half of the planet is a factory, I also don't see endeavors of this scale being useful.
 
And it could be that the ore distribution is not continuous, but spotty. Ore deposits would only be a small fraction of the entire planet anyway, everything else being useless dirt. No worries there.And like Sekmeth says, devs might want limited resources as a driving force for exploration.
 
Though I could see the arkship area being regenerative since there's new players and it's one of (and possibly the only) the safe zones.

Any kind of maintenance would, of course be automated. As long as the construct has power then it should not need anything else other than to repair damage caused by combat. 
 
The degradation timer would not start until after the power systems fail due to no fuel. Now if someone were to happen by the construct "hack" the core unit and transfer ownership to them then restore power then the timer would "reset" and any maintenance from there would continue as before. The only repairs that may be needed would be those that caused severe "hitpoint" loss lets say over the period of a year. 

Reality check.
 
Using our one REAL measure (Earth):
 
Surface area: 501,000,000 km2
 
Dry bits (usuable "territory"): 139,870,000 km2 or about 29.2% of the total surface area.
 
Arable land - example only - obviously mining is different): About 55,948,000 km2 or about 10 of the total surface area...
 
And then to refine it further (for instance) when it comes to human settlement, historically something like 80% of all human settlement was within walking distance of salt.
 
Key takeaway - there is a crap ton of "territory" to be had in a setting like DU - you may consider this "infinite". But only (if modelled right) a very small percentage of that territory will be usable in some way and thus matters - Sovereign Territory therefore is really actually "finite" and always will be.
 
Sovereign Territory isn't about how much km2 you control - it's about WHAT is in the territory you control, or what controlling that territory strategically gives you access to or control over.

I vote no. Seems a bit too complex for far to little payoff. Most of the problems like, ships accelerating too fast and turn speed can be handled by the engine and thruster mechanics and fuel consumption. I do not think this problem will need an additional system of injuring the player or ship.
 
Not to mention with all the technologies that seem to be available in the game, nano compressing weight and items, artificial gravity and whatever other crazy technologies in the game this seems like a problem that could be easily solved.
 
If this was a flight sim style game. A game that was 99% about building a ship and flying it with an ultra realistic feel to it, I would be all for it. In dual universe with all the other things to do in the game and the combat not really about dog fighting or ultra realistic flight. I just don't see the pick up in spending time on a system like this.

I really think that people just don't comprehend the huge scale that are planets. There is no need to worry about completely mining out an entire planet any time soon. But after a time, maybe it will be possible to mine out an entire planet. I doubt it though, since it would also require lots of time and effort from many players involved. Unless literally half of the planet is a factory, I also don't see endeavors of this scale being useful.
 
And it could be that the ore distribution is not continuous, but spotty. Ore deposits would only be a small fraction of the entire planet anyway, everything else being useless dirt. No worries there.And like Sekmeth says, devs might want limited resources as a driving force for exploration.
 
Though I could see the arkship area being regenerative since there's new players and it's one of (and possibly the only) the safe zones.

I see no reason to designate different hull types, because it would only serve to reduce variety in ship design, rather than letting the best designs rise to the top of the markets. 
 
Though I could definitely see blueprints for frames or modular ship parts becoming popular on the markets, because they could speed up the construction process while still allowing for personal customization. 

You should read this
Most of what you describe should be possible with the RDMS and Territory Units. It would be up to the players to decide how to organize themselves and how to organize territories.

You should read this
Most of what you describe should be possible with the RDMS and Territory Units. It would be up to the players to decide how to organize themselves and how to organize territories.

You should read this
Most of what you describe should be possible with the RDMS and Territory Units. It would be up to the players to decide how to organize themselves and how to organize territories.

I agree with this and your previous statement about exposing the script in any way leading to theft of the intellectual property. It's probably for the best. But I would say that coding should be capable of interfacing with the RDMS. You can allow others to look at it or not. Allow others to edit, or not. Depending on how DPUs and the code interface is developed, it may be possible to limit the number of copies created or sold, too.

i'd personally limit the range of any repair tools to very short ranges, like a few meters.
 
combined with some system that remembers the undamaged state of a given construct (or just plain blueprint access) it would strongly encourage shipyards (with repair arms) and small repair vehicles that crawl surfaces.
 
neither variant would make it "too cheap" or particularily useful in combat.
 
and would make repair yards and fleet tenders an asset to be protected.
with all the repair equipment and production capacity at hand.