Wallfacer

I've given this some thought too.  In space, the most efficient design is what maximized space since there is no air to deal with.  So boxy and ugly will be more efficient.  I fear space in this game will eventually look like it was overrun by the borg.  

Logic

I heard that clouds will be handled in the cloud.  Pretty sure that means the Amazon, so expect rain.

I heard that clouds will be handled in the cloud.  Pretty sure that means the Amazon, so expect rain.

I heard that clouds will be handled in the cloud.  Pretty sure that means the Amazon, so expect rain.

I heard that clouds will be handled in the cloud.  Pretty sure that means the Amazon, so expect rain.

I heard that clouds will be handled in the cloud.  Pretty sure that means the Amazon, so expect rain.

I heard that clouds will be handled in the cloud.  Pretty sure that means the Amazon, so expect rain.

That's quite simply because that's what the "general public" wants !
 
The general public is not interested in EVE or DU, but they'll eagerly read the shocking news that $500K worth of "assets" were destroyed in a video game !

As an idle passenger?  I can see transport.
 
I guess I can see large multi-crew ships working well as war/transport ships as people will always want to explore/mine varying worlds and would like a safe way to and from outposts.

You're no fun.

I've given this some thought too.  In space, the most efficient design is what maximized space since there is no air to deal with.  So boxy and ugly will be more efficient.  I fear space in this game will eventually look like it was overrun by the borg.  

I would hope that the players login position would be fixed to the construct when you log off so that you login into the same position within the construct.
 
NQ has hinted that FTL could still take days, weeks, or months to reach other systems and so the player would need to be able to logoff in transit and be able to log back into the construct later in the flight (or upon arrival).
 
I'm excited about the potential pirating, stowaway strategies this could create.  For example, I am hoping I can send a character to into a neutral or enemy construct when it is unguarded and log off if I know that ship is going to fly to another system (or mining camp).  Later, I hope to login with this character still in the ship at its new location (or with the cargo hold full of stuff I can now steal).  Of course that would always be a risky strategy.  

The LUA scripting Devblog goes into this.
 
The "Control Unit" is the interface between the game client and your computer hardware.  It is what is used by your scripts to access different types of input methods, such as keyboards and mice.  There's been no confirmation of analog inputs.
 
So what you're suggesting is exactly what I've proposed.

Star Wars Battle Pod style anyone?

Better yet, let players write code through LUA to use whatever hardware they like.
 
I could imagine players designing their own physical controls and marketing them.

We've got to be careful with assumptions about server load, a change that will double the number of calculations per-shot could turn a battle that causes a bit of lag into a battle that brings the server to it's knees.
 
Since the server won't be actually tracking projectiles, the only weapons I see time to reach target mattering here is missiles and torpedoes, since they would be slow enough for countermeasures. Rather than making it as complex as the server needing to decide on time to reach target, I might propose the following.
 
non-missile/torpedo weapons - no time to reach target, all calculations made at start, distance between shooter and target affects accuracy.
 
missile/torpedo weapons - Delay based on distance between shooter and target, no calculations made at start, all calculations made on impact (if hit).
 
As far as non-missile and torpedo countermeasures and reactions, it might be fair to assume you would deploy said countermeasures after the first impact or impacts, and the countermeasure would take effect on subsequent impacts.
 
The bulkier the combat system is, the longer it will take to be added, and the more strain large space battles will cause. Eve Online suffers tremendous strain when it has large space battles, and it's combat mechanics are less complex than the ones you are suggesting, and will probably still be less complex than a very very simple system because of voxel destruction and deformation (which should be pretty taxing).

To further explain, my understanding is that once a shot is locked and fired an algorithm will calculate what damage is done.  So if there is a shot the system will calculate things such as weapon fired, structure hit, distances, and result in specific damage from zero to the maximum damage depending on the luck of roll (somewhat random chosen value within the range).  Once the shot is fired; it's just math.  
 
How I see this working, ideally, is that a firing ships client sends a string through the server that a shot has been locked and fired.  The string could include the location of the firing ship, the weapon used, and the location of the target.  This string can pass through the server to the targeted ship's client which will initially calculate when that shot will reach the target ship based on the weapon used and locations of the ships.  The target client then waits the required time to impact and at the time of impact makes the final damage calculation taking into account the end location of the target ship and whether any defensive elements were used (like flares or interception laser or projectiles).  It's all just math.
 
So nothing "in-game" on the server side actually affects the shot.  This also shouldn't effect server load too much since the server only sends the shot string one time between the clients.  It really only adds extra load to the target ship client since it now has to make two separate calculations (when will the shot hit?... then how much damage?).  I suppose an extra string may be required by the server registering weapon and defense numbers to complete the final calculation if there is a concern that players will hack their client and change the values of weapons and defenses.
 
Then again, I don't really know where the combat calculations are made.  Maybe they have to be done completely server side because of connection issues?

You really can't compare the DU economy (or government) with the real world economy, they have different goals.  The real world economy involves real people and the goal should be to most efficiently allocate resources justly among those people.
 
DU is a different story; the end goal of the economy should be to create the most enjoyable time for all players (regardless of how much time they can devote).  It's a game.  The point is to be a game.
 
The only way to balance gameplay to allow new players to join is if they are able to gather resources at a fairly comparable rate to all veteran players.  Otherwise, the game will shrivel and die because new players will not be able to compete; they would be at the mercy of the players who control the resource gathering.  
 
While it is very true that the DU economy will be very inefficient; the goal isn't efficiency; the goal is balanced gameplay.  Futhermore, an efficient economy that allows maximum resource gathering would eventually allow organizations to build a nearly limitless fleet of ships and cities.
 
I would like to see a distant expansion allow some mining elements to give a slight advantage at resource mining; but this should not be in the game initially.  Also, elements shouldn't allow a player to mine when the character is loggen in but inactive.

It appears that they are releasing player customization in the official release, but holding off on construct v. construct until a later patch or first expansion.
 
I am happy construct v. construct isn't a first day feature since I think it will help players make initial developments without construct weaponization.  My only disappointment in no construct v. construct initially is that it seems like we likely also won't see it in the beta also.  Who knows though, since it looks like they will want to add it soon after, we might get some beta construct weapons prior to the initial release.

I would hope this would be the case, that constructs can crash and be destroyed, but that still presents a game play issue.  Players could crash big blobs of whatever on enemy bases and bury them even if it doesn't hurt the building.  Of course, crashed ships could simply be destroyed and disappear.  But again that would create a "burned earth" incentive to crash your own ship to prevent being pirated.
 
I'm curious to see how this is going to work.

It appears that they are releasing player customization in the official release, but holding off on construct v. construct until a later patch or first expansion.
 
I am happy construct v. construct isn't a first day feature since I think it will help players make initial developments without construct weaponization.  My only disappointment in no construct v. construct initially is that it seems like we likely also won't see it in the beta also.  Who knows though, since it looks like they will want to add it soon after, we might get some beta construct weapons prior to the initial release.

Thoughts on how stealth elements should be implemented in this game.  Often they are not done well.
 
My thought is that if a construct is allowed to be entirely stealthed, it should take a while to charge up weapons before it can begin firing.
 
Ideally, stealth would only apply to radar and sensors, but not visuals.  

Thoughts?

I would hope that there would be levels in sensor detection and stealth elements.  For example, a low level stealth element can hide you from low level sensors, but not higher level sensor elements.
 
I like the idea of being forced to use color as visual camo as opposed to active visual camo.
 
My biggest concern from looking at the pre-alpha build is that anyone in visual range will automatically be displayed on other user's HUD.  If I build a relatively "hidden" base on a mountain, I don't want my icon to pop up on someone's HUD a mile away when I look outside.
 
As long as there are options to keep my ship and person from showing an icon on other player's HUD's; I can live it.

As far as visual stealth goes, camouflage paint will be the most basic type.  Spaceships in deep space could be painted black, for example, and tanks meant for desert fighting could be tan and brown.  We'd eventually be able to make active camouflage that checks the terrain you're on and changes color to match, and the quality of the camo will depend on the quality of the scripts (and possibly the quality of the computer the script is running on, how many scripts are running, etc.)  There's also just hiding underwater or underground.  Giving how easy it is to dig in this game, I expect subterranian warfare would be an especially effective tactic. 
 
For electronic stealth, it's dependent on the method being used to sense targets.  
 
Active sensors like radar and sonar send out a pulse and can tell you the size, range and direction of a target based on how that pulse gets reflected back.  Materials, coatings and even the angles at which the waves impact the target determine the detection range and accuracy of these sensors.  Countermeasures such as chaff (aluminum foil strips) can confuse or dampen these signals.  If you are using radar or sonar, you yourself are easily detected.
 
Passive sensors include infrared sensors, radio direction finders and hydrophones.  You look for electromagnetic spectrum and audio emissions of targets.  That's why your fleet maintains radio silence.  These sensors make no emissions so are excellent for remote, hidden observation posts and/or for use on stealthy vehicles.  They can be mitigated by low heat and quiet drive systems (which would generally be lower performance) and shielding of electronic components (which adds weight) as well as noise and light discipline (don't use flashlights at night, don't use your voice chat when you're waiting in ambush.)