C# Aurora v0.x Suggestions

[Steve Walmsley]

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.

So if I am reading this correctly, small planets wouldn't be much easier to terraform than large ones. The moon has 7.4% of the surface area of Earth and about 17% of the gravity, so it would be 7.4% / 17% = 44% of Earth terraform time.

TBH I think I prefer having a faster terraform time for the small bodies, as most of them lack both atmosphere and water, which will be a significant task, plus they have a smaller capacity. I will play for a while with the updated rate and then make a decision.

[sloanjh (OP)]

So if I am reading this correctly, small planets wouldn't be much easier to terraform than large ones. The moon has 7.4% of the surface area of Earth and about 17% of the gravity, so it would be 7.4% / 17% = 44% of Earth terraform time.

TBH I think I prefer having a faster terraform time for the small bodies, as most of them lack both atmosphere and water, which will be a significant task, plus they have a smaller capacity. I will play for a while with the updated rate and then make a decision.

Correct. 

To give a feel for the change, if we assume constant density then this works out to the time growing like R instead of R^2.  So for the moon, the ratio of radii is 1/4, so the time would be 4x faster (R) instead of 16X faster(R^2), or 25% of Earth time if the densities were the same.  In reality, the moon's density is only 60% of the Earth's ; since G is going to be proportional to density (at constant R) the time should be 0.25/0.6 = 42%, which checks with your number above.  The advantage of the Area/G formula is that you get the right answer without needing to know the density.

John

[SevenOfCarina]

I'm guessing this has been mentioned before, but can we have an option to set the size of the empire's manufacturing sector as a fraction of population at game start? It's probably one of the better ways to actually have a multi-billion population start without resulting in extremely inflated rates of advancement. Although I suppose one can mess wit the manufacturing efficiency sliders ....

On a side note, is there any reason why any increase in the size of the agriculture and environmental sector pulls population only from the manufacturing sector and not the service sector? It should probably result in a proportional decrease in both.

[SevenOfCarina]

In their present iteration, tractor beams, for all their potential, are rather .... underwhelming. You have a single 500 ton module that, attached to a ship, let's you drag around exactly one entity of arbitrary mass, with no room for building space!trains, or for using stuff like drop tanks or external launchers.

For such a staple of science-fiction, it's .... boring, to say the least.

Let's spice it up a bit, shall we?


The Proposal :

Rather than have a single tractor module, as in the present, it might be better to have them function more like a combination of box-launcher, magazine and hangar, with a new line of techs dictating how much stuff you can drag around per ton of of tractor, what you can drag around, and how much of it you can drag around. The existing tractor module is bifurcated into two different components : the External Attachment System, which acts a a kind of cross with a hangar, and the Tractor Module.

The existing tractor module now serves as an attachment point between two ships, or a ship and a station, and masses 5000 tons, with the cost now being 100 duranium and 300 mercassium. It serves pretty much the same function as before.

To complement this, it might be prudent to introduce another kind of ship : the external module.
What is this, you might ask?

The External Module

This is, effectively, a new type of ship, distinct from the existing classifications.

An external module is unmanned, meaning it has zero crew requirements. It does not require a bridge, a commander, or any other such components, indeed, it cannot have them, and it cannot accept crew in any form.  It is rather similar to a station in many aspects : it has no mass restrictions, it can only be built by construction factories, and it has a structural shell instead of armour.  There are three important differences, though :

An external module cannot be issued orders, unless and until it is hooked up to a ship. It cannot move, it cannot use its sensors, and it certainly cannot shoot at anything.

An external module has no limitation on the types of components it can have. Anything and everything from beam weapons to high power military engines are allowed, though it is mostly intended to house the various storage modules and box launchers. It cannot house an EAS, however.

An external module is subject to standard maintenance rules : if it has only commercial components, it gets flagged as commercial and requires no maintenance, but if it has military components, it is subject to military maintenance rules and consumes MSP at the standard rate. However, it counts as having only one-fifth of its tonnage. That is, a 10,000 ton external module takes up 2,000 tons of maintenance capacity at a maintenance facility.

This does pose a dilemma, however : an external module requires maintenance, but cannot maintain itself. Hence, maintenance needs to be provided by an external source, the External Attachment System.

The External Attachment System

The EAS serves as a sort of external hangar, allowing for external modules to be attached to ships, and follows some basic rules :

1. There can only be one EAS per ship, like there can only be one Jump Drive per ship.
2. A ship with an external module will register as a single contact.
3. The added tonnage of all the external modules attached to a ship will result in a proportional decrease in ship speed.
4. Engines on the external modules will add to ship speed.
5. External modules will bloat the size of a ship and increase its sensor contact size.
6. If the external module has shields, they will also protect the ship itself from damage.
7. If a ship equipped with an external module takes fire, the chances of the external module taking the damage instead of the ship itself
    is [(external module structural shell width)/(ship armour width)] per weapon hit. This is re-rolled for each weapon hit.

There are three parameters to be kept in mind for an EAS : EAS size, EAS efficiency, and module count.

EAS module size is very straight-forward, it can range from 1 HS to a maximum of 5 HS, with a series of techs to increase the maximum EAS size to 80 HS. This represents the size of the EAS module itself.

EAS efficiency is similar to Jump Drive Efficiency, and starts at 2, increasing with techs to a maximum of 10.

The EAS capacity determines the total tonnage of all external modules that can be attached to a ship.
EAS capacity = EAS size * EAS efficiency.
For instance,  100 ton EAS ton EAS with efficiency 5 can support 500 tons of external module attached to it.

Module Count determines the number of external modules that can be attached to one EAS. The baseline is 1, though it can be increased through techs till 20 modules per EAS. If you have module count 5, and EAS capacity 2000 tons, you can attach five 400 ton external modules, or two 1000 ton modules, et cetera.

An EAS can be commercial or military.

A military EAS can attach both military and commercial external modules, and is a military component. The cost of a military EAS is one-fortieth of its capacity in duranium and thrice that in mercassium. The cost of a military EAS with capacity 2000 tons would be 50 duranium and 150 mercassium. The military EAS takes care of the maintenance needs of military external modules, drawing MSP from the ships stores.

A commercial EAS can only attach commercial external modules, however, it is twice as large and has ten times the capacity of an equivalent military EAS module, while having the same cost.


That's .... pretty much it.

I understand that this might be a lot of work for Steve to code in, but this allows us to finally have drop tanks, external missile racks, use-and-forget engines, etc., which I think is worth the effort.

Thoughts?

[sloanjh (OP)]

In their present iteration, tractor beams, for all their potential, are rather .... underwhelming. You have a single 500 ton module that, attached to a ship, let's you drag around exactly one entity of arbitrary mass, with no room for building space!trains, or for using stuff like drop tanks or external launchers.

[SNIP]

Thoughts?

To anyone thinking of replying to this:  SevenOfCarina duplicated this post in a separate thread: http://aurora2.pentarch.org/index.php?topic=10286.0 that already has some replies.  Please reply in that thread, both to keep the Suggestions thread uncluttered and to keep the conversation in one place.  Thanks!

John

[Scandinavian]

In the vein of tractor beam revisions, can we get towed vessels to power down their engines if they are not needed for the speed at which they are being towed?

Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).

[Steve Walmsley]

Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).

Engines only consume fuel for the current speed, not their max speed. This is true for both VB6 and C#.

[Jorgen_CAB]

Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).

Engines only consume fuel for the current speed, not their max speed. This is true for both VB6 and C#.

But I think the suggestion was that you could potentially have two different engines on one ship and then the ability to choose if you just want to use one of them or both at the same time. This could be interesting for role-play purposes even if the AI would never use it.

You would fit one engine with a decent fuel to power ratio and one fuel guzzling engine with more power to use only when you really need it.

This is a common way to use engines in real life as well.

[Bremen]

Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).

Engines only consume fuel for the current speed, not their max speed. This is true for both VB6 and C#.

But I think the suggestion was that you could potentially have two different engines on one ship and then the ability to choose if you just want to use one of them or both at the same time. This could be interesting for role-play purposes even if the AI would never use it.

You would fit one engine with a decent fuel to power ratio and one fuel guzzling engine with more power to use only when you really need it.

This is a common way to use engines in real life as well.

This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.

[Steve Walmsley]

This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.

It would be a major change, given how much balance is involved in this area. Fuel consumption has to be matched against fuel production in order to create interesting decisions. If fuel is too plentiful, it is too easy and if fuel is too scarce, it would be frustrating.

If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.

The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.

[Jorgen_CAB]

This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.

It would be a major change, given how much balance is involved in this area. Fuel consumption has to be matched against fuel production in order to create interesting decisions. If fuel is too plentiful, it is too easy and if fuel is too scarce, it would be frustrating.

If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.

The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.

While that  might be interesting I think just allowing to use two engines in one hull would make thing much simpler. You only have to worry about two fuel consumption levels. So, the fuel consumption would be either A or B or A+B. The power output of the the ship would be wither A or B or A+B.
In realistic terms you would only use two options since you would probably never only use the engine with the highest fuel consumption. It might also be easier to teach the AI to use such engine configurations as well. Since it is more of a binary all or nothing thing.

I also understand that such a change would need to look at an overhaul of the availability of fuel.

In the current version of the game you can already use high efficient engines on tractor tugs to haul combat ships long distances. From an industrial point of view it is a viable way to move ships between naval bases since fuel is often a pretty expensive resource. This would mainly make tugging navies around your empire less of a necessary thing to be sort of competitive against other factions in a multi-faction campaign.

[serger]

If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.

The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.

You can set:
1. the only ramscoop cruise engines tech line (max speed limit by power/mass factor and no fuel consumption at all) - usable for both civil and military designs, or, better, civil ones would be cheaper, but bigger and more vulnerable;
and
2. fixed-consumption (as your VB shield generators) military boosters for sprint maneuvres and/or silencers for sneak maneuvres - those would be usable at tactical situations only, and just for military designs.

So there will be no unmanageable range curves, no irritating stuck-w/o-fuel ships any more, and no strange military/civil engines division by some absolutely arbitrary conventional point for all space races of the Universe.

UPD:
http://aurora2.pentarch.org/index.php?topic=10289.msg113138#msg113138 (revised and expanded, not for v0.x for sure)

[Kurt]

This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.

It would be a major change, given how much balance is involved in this area. Fuel consumption has to be matched against fuel production in order to create interesting decisions. If fuel is too plentiful, it is too easy and if fuel is too scarce, it would be frustrating.

If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.

The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.

I kind of like the idea of having a fuel efficiency curve.  To reduce complexity for the programmer (you), you could make it fairly simple, with lower fuel efficiencies at speeds above, say, 80%.  That would give the user a set of decisions to make that he doesn't have now.  Currently, there are only two reasons to go slower than max, either to reduce your thermal profile or to keep your true max speed hidden.  Fuel efficiency would give you another reason to have to consider going slower. 

Although, maybe commercial engines don't have this problem because they are so low powered?

Kurt

[Father Tim]

Just going to say that Drop Tanks could be simulated by having a new "Ordinance" type that adds to fuel reserves of a ship when in its magazines.

Or -- what seems to me a simpler method -- allowing a unit to transfer fuel from any ordnance its carrying into its own tanks.  This would turn Drop Tanks into something designed via the regular Missile Design window, and would simply be a 'Missile' that was entirely fuel tank.

(Sure, this means that in an emergency a full-size spaceship might end up running its engines on what we're picturing as solid-fuel booster rocket cartridges, but that's a problem for the fiction.)

[Barkhorn]

Can't you already do drop tanks with tractor beams and tankers that are nothing more than gigantic fuel tanks?