C# Aurora v0.x Suggestions

[sloanjh (OP)]

Was going to put this in the changes discussion, but I think it goes here better.  Suggestion:

Allow prototypes to be researched.

If you do this, then you can probably get away with eliminating the old "un-researched design" components.  Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag.  This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.

John

Nothing automagical about that. Clearly, the design bureau has some clue about the specifications and expected results of the component design, so they put some place holders in the design and when the components were completed integrated them properly after some refinement.

The magic part was intended to refer to the player experience created by the underlying code, i.e. the player doesn't need to do anything to change it from a prototype to an active design - the class just magically changes itself.  That being said, it isn't all that stunning and I mainly used the word because I like to say "automagic" and this gave me a fig leaf of an excuse

John

[sloanjh (OP)]

Was going to put this in the changes discussion, but I think it goes here better.  Suggestion:

Allow prototypes to be researched.

If you do this, then you can probably get away with eliminating the old "un-researched design" components.  Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag.  This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.

John

I've implemented this suggestion:

http://aurora2.pentarch.org/index.php?topic=8495.msg119347#msg119347

Cool!  Hadn't thought of the case where the prototype depended on un-researched tech.  As you point out in the comment it sounds like the process for bringing class designs that depend on un-researched components into production is a lot smoother now.

John

[Jorgen_CAB]

Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.

About a month ago Steve changed PD to target the largest salvo first.

I got the impression that was for beam weapon final fire only but if it is all PD fire-controls then that is great. But I still would like to have a minimum distance as well as that would help allot for AMM engagement where you also have a strong beam PD present.

[amram]

Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.

About a month ago Steve changed PD to target the largest salvo first.

I got the impression that was for beam weapon final fire only but if it is all PD fire-controls then that is great. But I still would like to have a minimum distance as well as that would help allot for AMM engagement where you also have a strong beam PD present.

As well as layered anti missile missiles - I can micro which launchers get to target what and have both in use, or i can load one until they are close enough then load the other across the board to mitigate micro at cost of combat efficiency.

If I can set a minimum range on weapons or firecontrols, I can prevent the longer ranged AMM from wasting shots on targets the shorter ranged amm should be taking, or either from wasting shots better left to the guns.

For reference, these are the sort of two tier AMM I tend to use when I decide on AMM defences (7.1 numbers, for c#, nearly identical results can be had except for significantly shorter reach, 0.44mkm and 3.63mkm range, respectively):

Code: [Select]

Viper S1 AMM
Missile Size: 1 MSP  (0.05 HS)     Warhead: 1    Armour: 0     Manoeuvre Rating: 41
Speed: 49000 km/s    Engine Endurance: 1 minutes   Range: 1.9m km
Cost Per Missile: 1.482
Chance to Hit: 1k km/s 2009%   3k km/s 656%   5k km/s 401.8%   10k km/s 200.9%
Materials Required:    0.25x Tritanium   1.232x Gallicite   Fuel x33.25

Code: [Select]

Taipan S1 AMM
Missile Size: 1 MSP  (0.05 HS)     Warhead: 1    Armour: 0     Manoeuvre Rating: 38
Speed: 42200 km/s    Engine Endurance: 6 minutes   Range: 14.6m km
Cost Per Missile: 1.338
Chance to Hit: 1k km/s 1603.6%   3k km/s 532%   5k km/s 320.7%   10k km/s 160.4%
Materials Required:    0.25x Tritanium   1.088x Gallicite   Fuel x283.25
Ideally, I would have Taipans restricted from engaging inside of 2mkm, and let the Vipers tackle anything between 2mkm and PD area defence range.  As it stands, one must micro the missile FC's to prevent not firing when one should or firing when one should not.

Having that minimum engagement range would go a long way towards mitigating player intervention in achieving the same result, since you could simply set a minimum large enough to keep the two missiles from overlapping at all, so each works to its own strength when needed to do so.

[Father Tim]

If not already added, how about having Training slowly decrease over time as "crew rotate out, get rusty, or die?" However, recent battles will slow down this descent for quite a while, until it again returns back to normal.

If you scroll back a few pages, you can see a couple-dozen-post argument on this very topic.

[Father Tim]

A QoL improvement:

Can the 'Summary' tab of the Colony (F2) window {this one: http://www.pentarch.org/steve/Screenshots/Crusade/Space1889_01.PNG} section "Manufacturing Worker Breakdown" auto-sort itself to descending order by number of workers (with "Available Workers" still at the end though)?

[Steve Walmsley]

A QoL improvement:

Can the 'Summary' tab of the Colony (F2) window {this one: http://www.pentarch.org/steve/Screenshots/Crusade/Space1889_01.PNG} section "Manufacturing Worker Breakdown" auto-sort itself to descending order by number of workers (with "Available Workers" still at the end though)?

Done.

[Father Tim]

Thanks!

[L0ckAndL0ad]

Allow refit of electronics on any appropriate shipyard

Crusade AAR made me thinking about updating older ships vs building new ones. In my own game in VB6 Aurora, when I create new generations of ships and retool shipyards, I loose the ability to make small upgrades on my older generation vessels (which is not realistic). To be able to keep the old ships updated with newer FCS and sensors, you need to either have to make costly refit to them to get them to a new generation standards and replace their engines and armor along the way (which is unrealistic and super inefficient), or have as many separate shipyards (that will be idle and PITA to deal with) that were tooled for this particular design that you still use.

So, I propose allowing refit of electronic modules (sensors and fire controls) on any appropriate (type and size) shipyard.

Optional: Allow other small changes to be done the same way, regardless of what design the shipyard is tooled for.  Similar to how USN refitted its old 21 knot Standard type battleships in WW2 with new 5 inch DPs. BB-45 - USS Colorado, for example, was built on the East Coast in 1921, but was under refit at West Coast in 1942 where it received new 5/38 DPs.

[Steve Walmsley]

Allow refit of electronics on any appropriate shipyard

Crusade AAR made me thinking about updating older ships vs building new ones. In my own game in VB6 Aurora, when I create new generations of ships and retool shipyards, I loose the ability to make small upgrades on my older generation vessels (which is not realistic). To be able to keep the old ships updated with newer FCS and sensors, you need to either have to make costly refit to them to get them to a new generation standards and replace their engines and armor along the way (which is unrealistic and super inefficient), or have as many separate shipyards (that will be idle and PITA to deal with) that were tooled for this particular design that you still use.

So, I propose allowing refit of electronic modules (sensors and fire controls) on any appropriate (type and size) shipyard.

Optional: Allow other small changes to be done the same way, regardless of what design the shipyard is tooled for.  Similar to how USN refitted its old 21 knot Standard type battleships in WW2 with new 5 inch DPs. BB-45 - USS Colorado, for example, was built on the East Coast in 1921, but was under refit at West Coast in 1942 where it received new 5/38 DPs.

Even in that case, I doubt the battleships could just drop by any shipyard at any time and have the guns fitted. There would need to be some scheduling and preparation work.

[Hazard]

You'd also need a slipway that's large enough to fit the ship and a shipyard that can handle the components.

When you order a capital ship in for work on the electronics you aren't pulling chips from the motherboard and slotting in new chips, you are moving hundreds if not thousands of tons of sensitive equipment in and out of the armour layer, consisting of sensor panels, mechanical gears to adjust the panels, large amounts of computation equipment to process the data the sensors gather and kilometers and kilometers of cabling along with adjustments to the ship's power distribution system to deal with the different demands of the new electronics.

[TMaekler]

As an example, here is Fleet Auto-Route
http://aurora2.pentarch.org/index.php?topic=8495.msg106871;topicseen#msg106871

Will this auto route feature also in the "repeat order list"? Would be nice if a transport would recalculate the (always changing) shortest route due to Lagrange points etc.

[BAGrimm]

Had a thought while playing around with missile designs in my most recent campaign attempt.  As an RP-tool, Enhanced Radiation warheads are useful.  And while I have yet to personally unleash them against an actual population, I assume that they can be useful under the correct circumstances for planetary attack.  However, outside of this, they seem to be fairly useless.  What I propose is as follows: What if they were turned into a tactical choice in ship to ship encounters by giving them an effect on, say, shields/electronics/crew/component malfunctions? I haven't really thought out a concrete set of possible/useful rules for them, but I found the idea intriguing.  Obviously not expecting anything to come from this in the initial C# release, as it is coming much too Soon^TM, but maybe as a later inclusion, to play off of possible general enhancements to Electronic Warfare?

[vorpal+5]

You'd also need a slipway that's large enough to fit the ship and a shipyard that can handle the components.

When you order a capital ship in for work on the electronics you aren't pulling chips from the motherboard and slotting in new chips, you are moving hundreds if not thousands of tons of sensitive equipment in and out of the armour layer, consisting of sensor panels, mechanical gears to adjust the panels, large amounts of computation equipment to process the data the sensors gather and kilometers and kilometers of cabling along with adjustments to the ship's power distribution system to deal with the different demands of the new electronics.

Makes sense too. Now from a gaming perspective, would it be possible to give some leeway to ship retrofit if the difference is only 5% between the 2 ships? I doubt that in WW2 if you had a very large slipway, you needed to retool it for months just to change the radar of a carrier, right? in fact, except because of size, slipways, were they really specialized down to a precise class of ship?

[SultanPepper]

Hi all, long time lurker, first time poster (haha).  Been reading through a lot of this, but not all, so apologies if it's been discussed.  Any chance for a 'disable missile tech' option at campaign start? I love me some Star Wars, and would love for NPR's to play by the same rules - beam weapons only.  Maybe have such an option also boost beam ranges and whatnot to keep the game smooth.  Possible/thoguhts?

Amazing game, Steve.  I've been (im)patiently awaiting C# version for a while haha.