Author Topic: C# Aurora v0.x Suggestions  (Read 345126 times)

0 Members and 1 Guest are viewing this topic.

Offline Zincat

  • Captain
  • **********
  • Z
  • Posts: 566
  • Thanked: 111 times
Re: C# Aurora v0.x Suggestions
« Reply #1260 on: July 12, 2019, 01:14:11 PM »
On the point of lifepod penalties, could this not be implemented by using a racial trait? We already have various ones so add in a new one that could be called compassion or such, the higher it is then the greater the morale penalties a population suffers from losses such as lifepods. This then easily allows folks to create races of custom opinions and keeps a scalable mechanic in place also.

.. Maybe call it "willingnes to sacrifice"? Honestly I think it would be better to just leave it to roleplay. For example, if I roleplay a honorbound warrior race... it's not a matter of compassion or such. Maybe they think that surviving a lost fight is cowardice. Maybe they think that wasting space for escape pods is stupid and inefficient. I really don't want to reduce something like this to "compassion", there can be a lot of reasons for a race not wanting to save the people in escape pods.

I'd still really just leave it to roleplay. I'm ok with having variable lenght of escape pods duration in designs if people want to.... provided we can also choose to go without escape pods at all.
 
The following users thanked this post: Scandinavian, SpikeTheHobbitMage

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #1261 on: July 13, 2019, 02:55:36 AM »
Count me as another who would like to be able to configure lifepod duration, even down to nothing for those who want that.  A modest cost for increased duration is entirely reasonable and crew returned to a populated colony should at least add their grade points to the pool.

Since we are on that subject, the ability to move survivors and POWs between ships would also be much appreciated.  It would be nice to be able to rescue a 300 seat pod with two 200 seat shuttles and then offload the survivors to the mothership so the shuttles can go get the next one.  Transferring them to another ship or back onto a shuttle for fast transit to another ship/colony would be useful as well.

If Steve allows putting fighter factories on carriers then making on-board survivors available to crew new fighters would be an interesting dynamic, especially if such ships have to provide new crews themselves instead of automagically drawing from the homeworld.
 

Offline Scandinavian

  • Lieutenant
  • *******
  • S
  • Posts: 158
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #1262 on: July 13, 2019, 03:57:05 PM »
While we're on the subject of crews, crew rotation could be an alternative to R&R. At any stop where the crew could R&R, you could instead opt to perform a six-hour action that would muster off your existing crew and take on new crew, at the cost of resetting your vessel performance to the racial training level default (or the minimum, if the vessel class is set to use conscripts). For warships this would normally be counterproductive, but merchant vessels typically do not want to spend two weeks in port while the crew is on shore leave, and don't generally care about the things that crew grade modifies.

On a purely cosmetic note, I think the "use conscript crew" should be changed to "use merchant crew." I have a hard time imagining a modern vessel being entrusted to an impressed crew (outside some neo-Victorian dystopia). Whereas I have no problem at all with imagining orbital miners and fuel refineries being crewed by merchant mariners.
« Last Edit: July 13, 2019, 03:58:56 PM by Scandinavian »
 
The following users thanked this post: SpikeTheHobbitMage, DIT_grue, TMaekler

Offline Kelewan

  • Warrant Officer, Class 2
  • ****
  • K
  • Posts: 72
  • Thanked: 15 times
Re: C# Aurora v0.x Suggestions
« Reply #1263 on: July 15, 2019, 10:36:48 AM »
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.

I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics.  What if my empire is a machine race, and automatically downloads all crew before ship destruction?  What if my empire is a hive mind and sees zero value in rescuing drones?  What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?

The 'penalty' for too-short a time on your life pods is that you don't get your crew back.  If you want a three-day window, or a three-month window, that should be up to your empire to decide.

I am also in favor of configurable life time for escape pods during ship design, but short lived escape pods, or no escape pods at all also have implications regarding capturing POW
and therefor for intelligence gathering.  This could leave the AI  in an big disadvantage. So some other game mechanics  to offset the disadvantage may be required.
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2781
  • Thanked: 1048 times
Re: C# Aurora v0.x Suggestions
« Reply #1264 on: July 15, 2019, 01:17:49 PM »
While we're on the subject of crews, crew rotation could be an alternative to R&R. At any stop where the crew could R&R, you could instead opt to perform a six-hour action that would muster off your existing crew and take on new crew, at the cost of resetting your vessel performance to the racial training level default (or the minimum, if the vessel class is set to use conscripts). For warships this would normally be counterproductive, but merchant vessels typically do not want to spend two weeks in port while the crew is on shore leave, and don't generally care about the things that crew grade modifies.

On a purely cosmetic note, I think the "use conscript crew" should be changed to "use merchant crew." I have a hard time imagining a modern vessel being entrusted to an impressed crew (outside some neo-Victorian dystopia). Whereas I have no problem at all with imagining orbital miners and fuel refineries being crewed by merchant mariners.
I don't think this is much of an issue now that Steve has removed crew morale for commercial vessels. So we can RP crew rotation to be taking place among them easily enough.
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #1265 on: July 15, 2019, 01:41:45 PM »
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.

I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics.  What if my empire is a machine race, and automatically downloads all crew before ship destruction?  What if my empire is a hive mind and sees zero value in rescuing drones?  What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?

The 'penalty' for too-short a time on your life pods is that you don't get your crew back.  If you want a three-day window, or a three-month window, that should be up to your empire to decide.

I am also in favor of configurable life time for escape pods during ship design, but short lived escape pods, or no escape pods at all also have implications regarding capturing POW
and therefor for intelligence gathering.  This could leave the AI  in an big disadvantage. So some other game mechanics  to offset the disadvantage may be required.
If the AI can set its own policy, even just choosing one at random at race creation, that would make it even.  If crew are valuable enough that whether or not to rescue them is a legitimate strategic choice, not just for RP, then that should be enough to keep it balanced and interesting.

I don't think this is much of an issue now that Steve has removed crew morale for commercial vessels. So we can RP crew rotation to be taking place among them easily enough.
So combined with the unlimited fuel glitch my geosurvey ships will now have unlimited endurance?   :D

Seriously, though, I've been using crew morale to keep track of such ships' deployment times.  This means I won't have any way to know when to bring them in for shore leave.

Edit: I just checked and survey ships will still have morale, but other civilian ships won't.  Other small civilian ships would still be affected.
« Last Edit: July 15, 2019, 05:17:44 PM by SpikeTheHobbitMage »
 

Offline TheRowan

  • Chief Petty Officer
  • ***
  • Posts: 48
  • Thanked: 10 times
Re: C# Aurora v0.x Suggestions
« Reply #1266 on: July 16, 2019, 02:48:40 AM »
On the point of lifepod penalties, could this not be implemented by using a racial trait? We already have various ones so add in a new one that could be called compassion or such, the higher it is then the greater the morale penalties a population suffers from losses such as lifepods. This then easily allows folks to create races of custom opinions and keeps a scalable mechanic in place also.

.. Maybe call it "willingnes to sacrifice"? Honestly I think it would be better to just leave it to roleplay. For example, if I roleplay a honorbound warrior race... it's not a matter of compassion or such. Maybe they think that surviving a lost fight is cowardice. Maybe they think that wasting space for escape pods is stupid and inefficient. I really don't want to reduce something like this to "compassion", there can be a lot of reasons for a race not wanting to save the people in escape pods.

I'd still really just leave it to roleplay. I'm ok with having variable lenght of escape pods duration in designs if people want to.... provided we can also choose to go without escape pods at all.

That could be an interesting variable to distinguish NPRs diplomatically too... a race with high compassion could get an opinion boost if you pick up their survivors after battle (even if they're prisoners, at least they're alive) or an opinion penalty if you leave their lifepods to expire. Conversely, the stereotypical honourbound warriors might respect you more for letting their crew die a swift death rather than taking them prisoner.
 
The following users thanked this post: TMaekler

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: C# Aurora v0.x Suggestions
« Reply #1267 on: July 16, 2019, 09:11:52 AM »
That could be an interesting variable to distinguish NPRs diplomatically too... a race with high compassion could get an opinion boost if you pick up their survivors after battle (even if they're prisoners, at least they're alive) or an opinion penalty if you leave their lifepods to expire. Conversely, the stereotypical honourbound warriors might respect you more for letting their crew die a swift death rather than taking them prisoner.


Likewise, the ability to return captured personnel to their empire of origin should be added, and an empire's willingness to do so (or not) and the original empire's opinion of such should also affect diplomacy.  The Happy Individualists of Rygel IV should like me more for returning their captured people, whereas the Hiveworms of Mimicia II should take the opportunity to destroy my units along with their failed drones.
 
The following users thanked this post: TMaekler

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #1268 on: July 16, 2019, 11:29:14 AM »
On the topic of missile defence I have a couple of suggestions:

1) For beam defence, an option during turret design to include a CIWS scale sensor and fire control.  When not linked to a fire control or when linked to a fire control in any PD mode and attacked by an invisible missile, such as during jump blindness, such a turret would act as a regular CIWS.

2) For AMMs, an option to prefer wider incoming volleys before closer ones.  This helps when the enemy is firing more missiles than you can shoot down and you want to thin them as much as possible before your beam PD cleans up.

3) AMM intercept validation.  This doesn't just apply to self defence but also to area defence, which is a harder problem to solve.  Currently AMMs will attempt to shoot down missiles that are too close to their target to catch, wasting the entire volley.  Worse, this weakness can be exploited at range.  If the attacker can match the defender volley-for-volley and can get even a single missile inside that critical band every exchange then the defender's AMM defence will collapse completely with no chance of recovery.  Once anything gets through, everything gets through.  Currently the only mitigation is to disable AMM completely to save your missiles.  The only saving grace is that the NPRs don't exploit it.
 

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: C# Aurora v0.x Suggestions
« Reply #1269 on: July 16, 2019, 11:43:19 AM »
I think (2) and (3) could be collapsed into an AMM PD setting toggle to 'prefer targetting further away salvoes over closer ones' which is the opposite of what Aurora does now.

As someone who almost never uses AMM PD, and when I do only at 1v1, I think many of these problems can be solved -- or at least strongly mitigated -- by fine-tuning the fire control to launcher ratio on AMM ships.

Though most of all, I would like to see point defense ditch the 'salvo' concept and change to an 'all missiles within X radius' system where it wouldn't matter if I'm shooting at 24 missiles from a single BCR or 24 missiles from a dozen bombers.
 
The following users thanked this post: Jorgen_CAB

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #1270 on: July 16, 2019, 02:15:52 PM »
I think (2) and (3) could be collapsed into an AMM PD setting toggle to 'prefer targetting further away salvoes over closer ones' which is the opposite of what Aurora does now.

As someone who almost never uses AMM PD, and when I do only at 1v1, I think many of these problems can be solved -- or at least strongly mitigated -- by fine-tuning the fire control to launcher ratio on AMM ships.

Though most of all, I would like to see point defense ditch the 'salvo' concept and change to an 'all missiles within X radius' system where it wouldn't matter if I'm shooting at 24 missiles from a single BCR or 24 missiles from a dozen bombers.
'Target furthest salvo' would help in most cases, and is in fact what I was initially going to ask for, but it is less efficient than 'target widest salvo'.

I must respectfully disagree.  The defender's fire control to launcher ratio doesn't make any difference, nor does changing the AMM per ASM PD setting.  All the attacker needs is FC and reload rate parity, a small* tube advantage, and enough magazine depth for sustained fire until the defender dies.  While that should generally be the case, the problem is that the numbers are a lot lower than they should be.  Even a single tube advantage becomes total superiority.  How the attacker matches tubes to FC's makes no difference beyond 'every FC has at least one tube', and any mismatch in salvo size between attacker and defender is always in the attacker's favour.  The only possible counters under current rules are: manual PD targeting, putting big enough sensors on AMMs to find incoming ASMs, or outrunning them.  Good luck with that.TM

While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

*The minimum tubes is (defender tubes * defender cth + 1), with the optimum being (defender tubes * defender cth + #FCs), so if the defender's AMMs have 50% cth, only 50%+1 tubes are needed.  Even against 100% cth AMMs the attacker only needs one more tube.
 

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: C# Aurora v0.x Suggestions
« Reply #1271 on: July 16, 2019, 03:43:57 PM »
Are you completely excluding beam PD from this?  Personally, I have never tried to 100% stop incoming missiles with AMMs.  I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers.  (Sometimes I use entire battleships to absorb the leakers.  #:-] )

- - -

If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.

- - -

Quote
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target.  So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.
 
The following users thanked this post: Jorgen_CAB

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2822
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1272 on: July 16, 2019, 03:44:14 PM »
I think (2) and (3) could be collapsed into an AMM PD setting toggle to 'prefer targetting further away salvoes over closer ones' which is the opposite of what Aurora does now.

As someone who almost never uses AMM PD, and when I do only at 1v1, I think many of these problems can be solved -- or at least strongly mitigated -- by fine-tuning the fire control to launcher ratio on AMM ships.

Though most of all, I would like to see point defense ditch the 'salvo' concept and change to an 'all missiles within X radius' system where it wouldn't matter if I'm shooting at 24 missiles from a single BCR or 24 missiles from a dozen bombers.

'Target furthest salvo' would help in most cases, and is in fact what I was initially going to ask for, but it is less efficient than 'target widest salvo'.

I must respectfully disagree.  The defender's fire control to launcher ratio doesn't make any difference, nor does changing the AMM per ASM PD setting.  All the attacker needs is FC and reload rate parity, a small* tube advantage, and enough magazine depth for sustained fire until the defender dies.  While that should generally be the case, the problem is that the numbers are a lot lower than they should be.  Even a single tube advantage becomes total superiority.  How the attacker matches tubes to FC's makes no difference beyond 'every FC has at least one tube', and any mismatch in salvo size between attacker and defender is always in the attacker's favour.  The only possible counters under current rules are: manual PD targeting, putting big enough sensors on AMMs to find incoming ASMs, or outrunning them.  Good luck with that.TM

While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

*The minimum tubes is (defender tubes * defender cth + 1), with the optimum being (defender tubes * defender cth + #FCs), so if the defender's AMMs have 50% cth, only 50%+1 tubes are needed.  Even against 100% cth AMMs the attacker only needs one more tube.

The problem is not Fire-Controls in and of itself, especially not against AMM. If you want to fire say one missile per enemy ASM the problem with Fire-Control usually crop up since you only fire on one salvo so the defender are generally wasting more fire-controls. If a salvo contain say 6 missiles and the defender only have five AMM per fire control you need tow fire-controls to engage that salvo with one missile and waste four missiles in that 5sec turn. Even if there are more missiles incoming, there are no reason that you could not target more missiles from a realistic point of view unless you want to twist and bend the technobabble to fit the narrative.

The thing is way worse for beam fire-controls that can easily be saturated. One problem is that five different missiles fired with the same fire-control create five different salvos as one example.

I don't think that engaging missiles coming in from different direction (in the same 5 sec turn) happen enough in an actual game that it is reasonable to bring up as a reason against engagement of missile fire-control salvos. In that case I would settle for engaging missiles with the same position if that would be a major issue and ignoring the fire-control issue.

Full size missile launcher against an equal tech level opponent is often a waste of resources since beam point defence are too effective (at least until rather late in the game when beam PD become useless, although I never play that late). The only way you can beat beam PD is by saturating the PD by gaming the system (which is possible if you want to). Thus you need reduced sized launchers rather than deep magazines of missiles so you can hopefully overpower the enemies beam PD, this is where AMM become really important.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2822
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1273 on: July 16, 2019, 04:41:20 PM »
Are you completely excluding beam PD from this?  Personally, I have never tried to 100% stop incoming missiles with AMMs.  I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers.  (Sometimes I use entire battleships to absorb the leakers.  #:-] )

- - -

If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.

- - -

Quote
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target.  So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.

I think that you would perhaps like to choose what is the priority and in which order. I would for the most part like to target largest salvo first, furthest out second and closest last.

I would also like to have a minimum salvo size to even shoot AMM in the first place to also be in the game.

In general... wasting AMM to shoot down 100% of incoming anti-ship missiles is usually a wasteful doctrine which pretty much anyone living in that world should recognise quite quickly, especially using low tech AMM which can be very bad at shooting down ASM.
« Last Edit: July 16, 2019, 04:43:38 PM by Jorgen_CAB »
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #1274 on: July 16, 2019, 05:23:34 PM »
Are you completely excluding beam PD from this?  Personally, I have never tried to 100% stop incoming missiles with AMMs.  I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers.  (Sometimes I use entire battleships to absorb the leakers.  #:-] )

- - -

If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.

- - -

Quote
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target.  So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.
The point is that against this exploit you need enough beam defence that missile defence didn't matter anyway.  Once triggered 100% of incoming missiles leak.  While the AI doesn't deliberately exploit it I have lost ships to it, though I didn't understand it at the time.  The AI is defenceless against it and it also negates missile defence in hotseat games since it is simple to exploit.

----

Adding either option should be no harder than the other.  While I consider one better than the other I am in no way against adding both.   :)

----

That supposedly is what missile sensors are for, but good luck mounting those on AMMs before late game in VB or at all in C# due to the new minimum sensor size.

The problem is not Fire-Controls in and of itself, especially not against AMM. If you want to fire say one missile per enemy ASM the problem with Fire-Control usually crop up since you only fire on one salvo so the defender are generally wasting more fire-controls. If a salvo contain say 6 missiles and the defender only have five AMM per fire control you need tow fire-controls to engage that salvo with one missile and waste four missiles in that 5sec turn. Even if there are more missiles incoming, there are no reason that you could not target more missiles from a realistic point of view unless you want to twist and bend the technobabble to fit the narrative.

The thing is way worse for beam fire-controls that can easily be saturated. One problem is that five different missiles fired with the same fire-control create five different salvos as one example.

I don't think that engaging missiles coming in from different direction (in the same 5 sec turn) happen enough in an actual game that it is reasonable to bring up as a reason against engagement of missile fire-control salvos. In that case I would settle for engaging missiles with the same position if that would be a major issue and ignoring the fire-control issue.

Full size missile launcher against an equal tech level opponent is often a waste of resources since beam point defence are too effective (at least until rather late in the game when beam PD become useless, although I never play that late). The only way you can beat beam PD is by saturating the PD by gaming the system (which is possible if you want to). Thus you need reduced sized launchers rather than deep magazines of missiles so you can hopefully overpower the enemies beam PD, this is where AMM become really important.

If the enemy is attacking with more missiles per salvo than my AMM is set up for, I just reassign some tubes.  What saturates missile PD is that it takes more than one outgoing salvo to completely kill an incoming one, so you want more FCs than the enemy has.

I've never tried linking different types of ASM to the same FC since I always standardize my loads so I will need to test that.  Otherwise I've never seen a missile FC create more than one salvo per tick.  As long as they arrive one salvo at a time then one beam FC can keep up with them.

While I misunderstood Father Tim's objection I stand by what I said.

The exploit is that you only need about half as many launchers and a quarter the missiles that you should to defeat AMMs.  Theoretically even a start-game attacker could exploit this against an end-game defender.