C# Aurora v0.x Suggestions

[Barkhorn]

The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.

As stated above, the components to build a fighter must weigh at least as much as the fighter.

Incorrect.  Aurora ships are measured by displacement, not by mass.  A "500 ton fighter" is 500 tons because it displaces 500 "tons" of Luminiferous AEther.

Whether the Trans-Newtonian Elements are all there is to an Aurora unit, or if it also includes conventional materials (and if so, how much) is left to the individual player's fiction.

None of which is an argument for or against a space-based module for small craft (and/or munitions) production.  I remember when gate constructors needed five standard-cargo-hold-sized components to build a jump gate, and the myriad problems that caused due to failed delivery, interrupted production, and disappearing components.  About the only JGCSs that functioned reliably were those built with five internal cargo holds and which 'reloaded' their jump gate components at a proper colony after each build.

Would "portable" small craft and/or munitions production be fun?  Probably.  People seemed to like the Machine Shops in Starfire.  Would they add signifcant gameplay decisions?  Maybe.  If they were 100% as efficient as a ground installation at production -- especially if they could manufacture while moving -- they'd be overpowered, even though they'd require significant organizational overhead in terms of delivering (or holding) raw materials.  I'm pretty sure you'd want significant cargo hold capacity on each such unit.

I think such units should be limited to manufacturing out of their own, on-board cargo holds, requiring significant cargo-handling operations to feed.  I don't want to drown the idea in micromanagement, but having just instituted a series a rule changes to fix 'instant reload' and 'instant fuel transfers' and such, it seems a foolish gap to allow full-on production out of an adjacent cargo freighter.

For ships in real life, displacement equals weight.  The water a ship displaces weighs as much as the ship.  I don't see any reason for this to not be true in Aurora.

[Father Tim]

For ships in real life, displacement equals weight.  The water a ship displaces weighs as much as the ship.  I don't see any reason for this to not be true in Aurora.

Sometimes -- but for ships in real life, displacement doesn't (always) equal displacement.  There's light displacement and full load displacement and standard displacement and Washington displacement and effective displacement and (calculated) waterline displacement . . .

Not to mention net weight or gross weight or deadweight or any of the myriad other means of measuring ships.

Back in the very beginning, Aurora did everything in hull spaces.  But we clamoured for for a more 'realistic' measurement system.  Aurora's armour calculation assumes a perfectly spherical ship, and its engine power-to-speed formula assumes cargo holds (and hangars, and fuel tanks, etc.) impart the same 'drag' on a ship whether full, empty, or somewhere in between.

So units (ships, small craft, ordnance) are technically designed and built in Hull Spaces and then assigned a calculated value for theoretical displacement of Luminiferous AEther. . . listed in 'tons' for convenience sake, but still just as much as violation of the laws of physics as TNEs themselves.

[Desdinova]

The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.

As stated above, the components to build a fighter must weigh at least as much as the fighter.

Incorrect.  Aurora ships are measured by displacement, not by mass.  A "500 ton fighter" is 500 tons because it displaces 500 "tons" of Luminiferous AEther.

Whether the Trans-Newtonian Elements are all there is to an Aurora unit, or if it also includes conventional materials (and if so, how much) is left to the individual player's fiction.

None of which is an argument for or against a space-based module for small craft (and/or munitions) production.  I remember when gate constructors needed five standard-cargo-hold-sized components to build a jump gate, and the myriad problems that caused due to failed delivery, interrupted production, and disappearing components.  About the only JGCSs that functioned reliably were those built with five internal cargo holds and which 'reloaded' their jump gate components at a proper colony after each build.

Would "portable" small craft and/or munitions production be fun?  Probably.  People seemed to like the Machine Shops in Starfire.  Would they add signifcant gameplay decisions?  Maybe.  If they were 100% as efficient as a ground installation at production -- especially if they could manufacture while moving -- they'd be overpowered, even though they'd require significant organizational overhead in terms of delivering (or holding) raw materials.  I'm pretty sure you'd want significant cargo hold capacity on each such unit.

I think such units should be limited to manufacturing out of their own, on-board cargo holds, requiring significant cargo-handling operations to feed.  I don't want to drown the idea in micromanagement, but having just instituted a series a rule changes to fix 'instant reload' and 'instant fuel transfers' and such, it seems a foolish gap to allow full-on production out of an adjacent cargo freighter.

For ships in real life, displacement equals weight.  The water a ship displaces weighs as much as the ship.  I don't see any reason for this to not be true in Aurora.

The weight of water displaced by a ship is equal to the ship's mass because the water exerts a buoyant force on the ship. A ship in the aether wouldn't experience this force. It would "displace" an equal volume, not mass of aether. Whether aether has mass at all I don't think is defined.

[Rabid_Cog]

After reviewing the actual numbers, it seems the numbers are closer than I first thought.
1 mineral weighs (displaces) 2 tons. The example geosurvey ship in the wiki is 550 tons and 151 BP. 151 BP = 151 minerals total needed for construction. That is raw weight of 302 tons and therefore not unreasonable that the resultant ship displaces 550 tons in the Aetherium.

[papent]

What would we be building fighters out of? TN minerals is an option, but would require either a new, smaller cargo hold or keeping a freighter with the fleet.
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons. The logical conclusion is therefore, that while we only consider the TN minerals in the cost of ship construction, the remaining ship mass is taken up by conventional metals that are abstracted away. On a planet that abstraction works, but on a starship? Where do those metals come from?
Alternatively, it can be built out of "fighter parts", a new maintenance parts-like object. These would have to be built on planet and shipped, same as a fighter. At which point, what is the real gain? Slightly increased storage efficiency at best since you need space to store the parts and space for the assembly module, and all that space could have been devoted to having a larger fighter complement ready to fly.

The real problem that I can see, however, is that if it becomes viable to construct/assemble fighters in space... why would it not be viable to construct/assemble missiles in space? And that is a far greater logistical change than building fighters in space.

maybe a  Fighter Assembler Module. provided that you have within the Taskgroup
A) all the major components (prefabricated at a construction facility) of the wanted fighter design
B) MSP equal to max repair of the fighter design
C) hanger space for the fighter to dock after completion
you give the Taskgroup an order to 'Assembly Fighter' then select the design to assembly and the taskgroup starts on the task with 12 hours of task time = 1 BP per Fighter Assembler Module? adjust for taste.

EDIT: for crew members, I was thinking taking from the Rescued survivors (if any) then grabbing from cryogenics/passengers then from the Assembling Ship crew.

[Scandinavian]

One thing to keep in mind is that making something into a ship module is equivalent to creating an automated version with zero workforce requirement. For fuel refining and orbital mining modules there are particular restrictions on the bodies they can target, but you see it clearly with the terraforming and maintenance modules and VB6 construction brigades. Creating automated fighter factories may or may not be desired behavior.

[JacenHan]

On that note, maybe terraforming installations should be cheaper/smaller/require less population? I think if ship-based fighter or ordnance factories are implemented, they should be less capable in some way, probably BP/cost, than the ground-based alternative.

[Father Tim]

One thing to keep in mind is that making something into a ship module is equivalent to creating an automated version with zero workforce requirement. For fuel refining and orbital mining modules there are particular restrictions on the bodies they can target, but you see it clearly with the terraforming and maintenance modules and VB6 construction brigades. Creating automated fighter factories may or may not be desired behavior.

This is, indeed, why I gave up on building terraforming installations 13 years ago and went exclusively with ship-based modules.  In the earliest days of Aurora my empires were desperately worker-starved, and I relied heavily on automated mines, sorium harvesters, asteroid mining modules, and the like.  Mostly because back then I squeezed out every last Research Facility I could.

[QuakeIV]

Terraforming small worlds seems like it would be too easy.

Consider the following:  If there is 20% of the gravity, then the air will weigh 80% less and you will need 5x as much air in order to build up a certain level of pressure on the planet (assuming you dont go full gas giant and add enough air to significantly change the gravity of the planet).

This would make terraforming tiny worlds more realistic, in that it should probably be an exceedingly difficult thing to do.

So, divide the terraforming time by the surface gravity.  10 years / 20% surface gravity (0.2) = 50 years.


e: Fiddling with the math, assuming constant planet density the divide-by-surface-gravity balancing approach would result in a very nearly flat rate terraforming cost.  Minding that in reality smaller planets are generally much lower density than larger planets which would probably cause them to spike massively in terraforming cost because lower density = higher radius = lower surface gravity = longer terraforming time if the suggestion is implemented.

graph (x axis is mass, y axis is terraforming time): https://www.desmos.com/calculator/hepyghpcyh



Additionally, it might be fun if you needed to keep some number of terraformers on the planet in order to keep it terraformed.  This would raise the cost in that you can't really re-use infrastructure for that purpose.  I don't have a specific idea of how to balance that one.

[Hazard]

Note that low surface gravity planets, especially if they are already small, are unlikely to hold too strongly onto their atmospheres. Partially because they don't have a magnetosphere to prevent solar flares and such from carrying off chunks of the atmosphere, and partially because the upper reaches of the atmosphere might reach escape velocity if the atmosphere is tall enough and the gravity low enough.

There's a reason Luna sized planetoids lack anything but the most tenuous atmospheres.

[TMaekler]

Shipyards should probably remain planet locked, but a fighter factory module could be an interesting way of adding deep space production capabilities.

I would perhaps think the other way. Make shipyards be able to function next to a deep space station which provides TN materials and workforce for it to perform shipbuilding. Thinking of "Deep Space Black Ops construction sites" ;-)

[JustAnotherDude]

Perhaps a tech that limit the size of the shipyard? There's potential there. But a big problem would be balancing it so that population isn't made completely irrelevant. Shipyards are, at least in my games, the largest section of workforce a lot of the time. Perhaps the ability to  house population on stations and keeping the pop requirements.

[Desdinova]

Perhaps a tech that limit the size of the shipyard? There's potential there. But a big problem would be balancing it so that population isn't made completely irrelevant. Shipyards are, at least in my games, the largest section of workforce a lot of the time. Perhaps the ability to  house population on stations and keeping the pop requirements.

A lot of people enjoy making huge "Battlestar" type fleets, though. This would arbitrarily make that impossible.

[sloanjh (OP)]

Terraforming small worlds seems like it would be too easy.

Consider the following:  If there is 20% of the gravity, then the air will weigh 80% less and you will need 5x as much air in order to build up a certain level of pressure on the planet (assuming you dont go full gas giant and add enough air to significantly change the gravity of the planet).

This would make terraforming tiny worlds more realistic, in that it should probably be an exceedingly difficult thing to do.

So, divide the terraforming time by the surface gravity.  10 years / 20% surface gravity (0.2) = 50 years.


e: Fiddling with the math, assuming constant planet density the divide-by-surface-gravity balancing approach would result in a very nearly flat rate terraforming cost.  Minding that in reality smaller planets are generally much lower density than larger planets which would probably cause them to spike massively in terraforming cost because lower density = higher radius = lower surface gravity = longer terraforming time if the suggestion is implemented.

graph (x axis is mass, y axis is terraforming time): https://www.desmos.com/calculator/hepyghpcyh



Additionally, it might be fun if you needed to keep some number of terraformers on the planet in order to keep it terraformed.  This would raise the cost in that you can't really re-use infrastructure for that purpose.  I don't have a specific idea of how to balance that one.

We've been here before:

3 is OK, but your formula is off.  While the required atmosphere mass will scale with the surface area, it will be inversely proportional to the surface gravity of the planet.  On a lower-gravity world, you need more stuff above you to get a given pressure.  The surface gravity is proportional to both density and radius, so if each terraformer produces a constant mass of atmosphere, you'll see the yearly atmosphere production proportional to density and inversely proportional to radius. 
The gory math behind this can be found at http://aurora2.pentarch.org/index.php?topic=8107.msg91559#msg91559

The referenced link has a lot of the back and forth.

The short version:  Assuming constant density, a lot of the other observables of a body are dependent on the radius.  Putting all those in, the time should go like R ~ Mass^(1/3), BUT in terms of Aurora this is easier to think about as Area/surface gravity.  In addition (as I just realized) if you think in terms of Area/surface gravity the density should drop out (because these are the direct observables that determine the total mass of air required to create the desired pressure) so you don't need the constant density assumption.   

So I'm hoping that your plot is simply Y = constant*X^(1/3) - if you expressed it in terms of radius rather than mass you'd get linear behavior.  The other thing in the thread that's important is that there's a selection effect for ~1 G planets - we won't want to terraform a 10G planet, so the surface gravity bit should be fairly (within an order of magnitude or two) uniform across interesting planets.

Don't remember what Steve coded up though - didn't see anything down-thread when I reviewed the references.

John

[QuakeIV]

Holy smokes, I was around for that but have no memory of witnessing that conversation.  Fricken 2016, it doesn't feel like its been that long since the C# version started being a thing.

Regardless, it seems like it might be a good thing to add at this point, since terraforming is currently getting attention from steve.