Author Topic: C# Aurora Changes Discussion  (Read 271967 times)

0 Members and 2 Guests are viewing this topic.

Offline Alsadius

  • Lieutenant
  • *******
  • Posts: 176
  • Thanked: 79 times
Re: C# Aurora Changes Discussion
« Reply #2595 on: February 11, 2020, 04:00:57 PM »
Quote
The Add Lagrange button adds a Lagrange point to the currently selected body, even if it would not normally qualify for one.

Is there a Remove Lagrange button as well? Or would you need to delete the body and try again?

Edit: I see this was addressed in a subsequent post. Thanks.
« Last Edit: February 12, 2020, 08:24:57 AM by Alsadius »
 

Offline Titanian

  • Sub-Lieutenant
  • ******
  • T
  • Posts: 105
  • Thanked: 20 times
Re: C# Aurora Changes Discussion
« Reply #2596 on: February 12, 2020, 06:34:54 AM »
Maybe an option to remove a whole ring of asteroids could be added? Removing all of those 500 asteroids you just accidentally created might be quite the chore otherwise ;). Would also help with the times where large amounts of them are created so far away from the star they won't matter anyway.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 9949
  • Thanked: 10024 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes Discussion
« Reply #2597 on: February 12, 2020, 07:15:05 AM »
Maybe an option to remove a whole ring of asteroids could be added? Removing all of those 500 asteroids you just accidentally created might be quite the chore otherwise ;). Would also help with the times where large amounts of them are created so far away from the star they won't matter anyway.

As things stand, I could add an option to remove all Trojan asteroids for a specific body or all asteroids for a specific star, but not an 'asteroid belt'. Once the asteroids are added there is no association between them. Until now, that wasn't an issue :) 

The other option is to create some form of asteroid belt identifier, which shouldn't be too difficult.

EDIT: Asteroids now have a belt identifier, so I will be able to delete an asteroid belt.
« Last Edit: February 12, 2020, 07:27:02 AM by Steve Walmsley »
 
The following users thanked this post: DIT_grue, TMaekler, Titanian, DEEPenergy, Alsadius, Tikigod, BigBacon

Offline Tikigod

  • Lieutenant
  • *******
  • Posts: 155
  • Thanked: 42 times
Re: C# Aurora Changes Discussion
« Reply #2598 on: February 12, 2020, 05:42:43 PM »
EDIT: Asteroids now have a belt identifier, so I will be able to delete an asteroid belt.

Awesome!  ;D ;D
The popular stereotype of the researcher is that of a skeptic and a pessimist.  Nothing could be further from the truth! Scientists must be optimists at heart, in order to block out the incessant chorus of those who say "It cannot be done. "

- Academician Prokhor Zakharov, University Commencement
 

Iranon

  • Guest
Re: C# Aurora Changes Discussion
« Reply #2599 on: February 22, 2020, 04:40:57 PM »
Reading through the change list, I played around with a few paper designs and made a few calculations. Overall impression: The new ruleset seems less robust in some ways. I mentioned some of the points earlier, sorry for the repetition...

For point defence weapons, which will be firing many many shots at low hit rates, cost-effectiveness will be hugely important: weapon cost is directly proportional to "ammunition expenditure". This mostly kills long-ranged weapons for area defence, except as a last resort.
Area defence with small weapons remains useful for very fast interceptors that can keep pace with enemy missiles, assuming that's still achievable.
Despite the reduction of Gauss research costs and the increased efficiency of turret gear, bottom-of-the-barrel railguns may be preferable to anything else as point defence because of breakdown costs.

Similar considerations apply to long-ranged beam combat, because we also have low hit rates here. Shooting near the limit of (balanced-research) particle beam range would be harder on the firing ship than on the target. Highest priority would be anything that improves relative hit rate - fire control range and E(C)CM rather than the weapons themselves, probably being shield-heavy (allows suffering no real damage at closer range, saving wear and tear on the guns). If we can control the range without very stressed and fuel-hungry engines, we may favour slow-firing weapons - with most lines, 5 C1 weapons will incur 1/5 of the costs per shot than 1 C5 weapon.
Encouraging holding fire when hit chances are low is a nice concept, but problematic in Aurora because of the very low beam ranges. Beam fring rates are comparable to 20th century wet navy ships, but the difference between extreme and modest range against a retreating target can be closed in seconds rather than hours. Long-range shots with most lines are penalised in terms of damage as well as accuracy, further shortening effective range if there's any meaningful cost to firing a weapon.

Changes to missile launchers strongly favours something that was first among equals anyway: Box launchers in parasites (possibly engineless or otherwise bare-bones) to get around reloading limits.
Somewhat-reduced launchers become bulkier, full-sized ones suffer most from weapon malfunctions, directly-mounted box launchers are now dangerous (and another RP sink to only mitigate the risk somewhat).

New sensor model overwhelmingly favours small ships when it comes to mutual detection range. This pretty much solves missile-vs-missile combat from the get go, if that remains relevant at all (lack of salvo restriction makes lots and lots of cheap flak even more viable. We also lose point blank missile fire - imo, that was a good desperation measure that was more likely to breathe life into an otherwise one-sided situation than to be a balance problem, and also gave CIWS some validity).

Changes to fuel logistics strongly encourage ruthlessly optimising designs for fuel efficiency, which imo was already very attractive (tonnage efficiency suffers, but not cost efficiency). Now we have a bunch of techs lines soaking up RP and some logistics concerns that we can simply evade at design time, without any major concessions.
Likewise, getting propulsion design slightly wrong will be even more costly.

Changes to maintenance, especially the way MSPs are handled, seems to encourage ignoring the system. Plentiful engineering, scrap or abandon/salvage at end of life. Used to be a viable niche choice, now it seems more efficient than playing by the system.
Also not helpful: New components encourage large ships, and as I understand it the equipment failure system still gives up when faced with large ships carrying many cheap components. This is especially relevant combined with large low-tech weapons being less affected by weapon failure.

I'm excited about ground combat, AI changes, varied NPR design themes, more fleshed-out diplomacy, performance and other quality-of-life improvements...
but many basics pertaining to ship design, one of the core strengths of the game, seem less open-ended despite added complexity, and more prone to "one right way" rather than a wide range of reasonable trade-offs with different soft counters. Furthermore, the favoured one often seems unintuitive.
 
The following users thanked this post: iceball3, lordcirth, Jovus, BigBacon

Offline Ektor

  • Sub-Lieutenant
  • ******
  • E
  • Posts: 126
  • Thanked: 83 times
Re: C# Aurora Changes Discussion
« Reply #2600 on: February 24, 2020, 06:47:34 PM »
I just want to express how grateful I am for the new ability to add Commander themes.  I have a couple of conlangs and I'd love to use them as a base for my Aurora Empires.
 
The following users thanked this post: QuakeIV, Alsadius, BigBacon

Online Jorgen_CAB

  • Vice Admiral
  • **********
  • J
  • Posts: 1682
  • Thanked: 230 times
Re: C# Aurora Changes Discussion
« Reply #2601 on: February 24, 2020, 08:15:11 PM »
Reading through the change list, I played around with a few paper designs and made a few calculations. Overall impression: The new ruleset seems less robust in some ways. I mentioned some of the points earlier, sorry for the repetition...

For point defence weapons, which will be firing many many shots at low hit rates, cost-effectiveness will be hugely important: weapon cost is directly proportional to "ammunition expenditure". This mostly kills long-ranged weapons for area defence, except as a last resort.
Area defence with small weapons remains useful for very fast interceptors that can keep pace with enemy missiles, assuming that's still achievable.
Despite the reduction of Gauss research costs and the increased efficiency of turret gear, bottom-of-the-barrel railguns may be preferable to anything else as point defence because of breakdown costs.

Similar considerations apply to long-ranged beam combat, because we also have low hit rates here. Shooting near the limit of (balanced-research) particle beam range would be harder on the firing ship than on the target. Highest priority would be anything that improves relative hit rate - fire control range and E(C)CM rather than the weapons themselves, probably being shield-heavy (allows suffering no real damage at closer range, saving wear and tear on the guns). If we can control the range without very stressed and fuel-hungry engines, we may favour slow-firing weapons - with most lines, 5 C1 weapons will incur 1/5 of the costs per shot than 1 C5 weapon.
Encouraging holding fire when hit chances are low is a nice concept, but problematic in Aurora because of the very low beam ranges. Beam fring rates are comparable to 20th century wet navy ships, but the difference between extreme and modest range against a retreating target can be closed in seconds rather than hours. Long-range shots with most lines are penalised in terms of damage as well as accuracy, further shortening effective range if there's any meaningful cost to firing a weapon.

Changes to missile launchers strongly favours something that was first among equals anyway: Box launchers in parasites (possibly engineless or otherwise bare-bones) to get around reloading limits.
Somewhat-reduced launchers become bulkier, full-sized ones suffer most from weapon malfunctions, directly-mounted box launchers are now dangerous (and another RP sink to only mitigate the risk somewhat).

New sensor model overwhelmingly favours small ships when it comes to mutual detection range. This pretty much solves missile-vs-missile combat from the get go, if that remains relevant at all (lack of salvo restriction makes lots and lots of cheap flak even more viable. We also lose point blank missile fire - imo, that was a good desperation measure that was more likely to breathe life into an otherwise one-sided situation than to be a balance problem, and also gave CIWS some validity).

Changes to fuel logistics strongly encourage ruthlessly optimising designs for fuel efficiency, which imo was already very attractive (tonnage efficiency suffers, but not cost efficiency). Now we have a bunch of techs lines soaking up RP and some logistics concerns that we can simply evade at design time, without any major concessions.
Likewise, getting propulsion design slightly wrong will be even more costly.

Changes to maintenance, especially the way MSPs are handled, seems to encourage ignoring the system. Plentiful engineering, scrap or abandon/salvage at end of life. Used to be a viable niche choice, now it seems more efficient than playing by the system.
Also not helpful: New components encourage large ships, and as I understand it the equipment failure system still gives up when faced with large ships carrying many cheap components. This is especially relevant combined with large low-tech weapons being less affected by weapon failure.

I'm excited about ground combat, AI changes, varied NPR design themes, more fleshed-out diplomacy, performance and other quality-of-life improvements...
but many basics pertaining to ship design, one of the core strengths of the game, seem less open-ended despite added complexity, and more prone to "one right way" rather than a wide range of reasonable trade-offs with different soft counters. Furthermore, the favoured one often seems unintuitive.

A few points you might not have considered...

Low tech rail-guns already are extremely useful in VB6 and perhaps even more so because of the maintenance system. A planet with say a 5000t maintenance facility could have unlimited numbers of super cheap PD satellites and ships also could carry them although you still need to pay the engine cost, but they are still effective. As the failure now are 1% I don't see this to be overly prohibited in most situation even if you go with slightly higher quality.
To be honest I don't think that the failure rate will change how battles are fought at all and how you build the ships and with which weapons... it will change your logistics as all ships will need some logistics to maintain them for long operations even more than before. To be honest I don't think that you will ever empty a ships full MSP stores in a combat unless you are very unlucky or you have very highly specialised ships with extremely small MSP storage. I would say it is a mechanic that actually give a small incentive towards more balanced designs in general as you would then have way more MSP on the ship for each weapon.

Adding allot of engineering to ships to crank up the maintenance cycle is not going to be economically that feasible more than before, it will still take a considerable amount of space on the ship you could use for other stuff. Ships really have very limited space to work with once you consider engines, fuel, crew space and engineering. In most cases you are lucky if a ship get more than 50% actual mission tonnage on them which needs to be divided into armour, shields, weapons and sensors.

Box launchers in hangars is not also really the problem either... it is that hangars is a very simplistic mechanic and need role-playing to compensate for it. Attaching a 2000t box launching platform in a 2000t hangar is a misuse of the system in my opinion and you should simply not do it. The intent of box launchers is not to mass use them on regular ships and like so many other mechanics in Aurora you don't have to abuse them, there are many ways to break the system if you really try.
I think a more elaborate hangar mechanic would make more sense than changing how box launchers work as I think they seem fine in general. This is simply something you will have to role-play in the mean time.

I do agree that particle beams really need some love... they are utterly crap... especially with the failure rate mechanic in place. They need some overhaul to become interesting.

In my opinion the new C# give incentives to both large and small ships which really is interesting. Many things point towards small ships being more effective such as sensors as one example, you then have efficiency of component that makes larger ships far more value for your money. The new maintenance system certainly favour larger ships as a small ships takes up proportionally the same cost in facilities now.

Extremely fuel efficient engines obviously usually means larger or more engine to tonnage ratio (if you want the same speeds)... which then leads to that you need more maintenance facilities wherever you want to station ships. Fuel efficiency have always been an issue so that is not new.

Missile combat have always been about being able to overload the enemy point defence and that will not change. Even if PD have been made somewhat more effective then beam PD still struggle to engage really large salvos. Regular launchers have always been bad and extremely inefficient against a similar technological strong opponent who has a well rounded PD shield around their fleets and planets. Weapons failure rate will hardly make a difference in any ONE engagements, I think that will be rare. Having to buy less fire-controls is nice but not as terrible as one might think in the end as it also solves gamey ways to combat the fire-control mechanic.
I would not be against a better salvo mechanic and I do hope that Steve will eventually come around and do a re-haul of how it works. A one that fire-controls actually controls targets, missiles and tracking data and they do have a limit to their capacity. Perhaps together with an even more and interesting electronic combat mechanic.
But as is I don't think it will be worse than before... I think it will be better now as you don't have to abuse certain things which before was difficult as you unintentionally had to due to the salvo mechanic.
 

Offline QuakeIV

  • Registered
  • Captain
  • **********
  • Posts: 486
  • Thanked: 79 times
Re: C# Aurora Changes Discussion
« Reply #2602 on: February 25, 2020, 12:57:58 AM »
A planet with say a 5000t maintenance facility could have unlimited numbers of super cheap PD satellites and ships also could carry them although you still need to pay the engine cost, but they are still effective.

I feel the need to point out thats no longer how maintenance works (and rightfully so if you ask me).
 

Online Jorgen_CAB

  • Vice Admiral
  • **********
  • J
  • Posts: 1682
  • Thanked: 230 times
Re: C# Aurora Changes Discussion
« Reply #2603 on: February 25, 2020, 01:30:12 AM »
A planet with say a 5000t maintenance facility could have unlimited numbers of super cheap PD satellites and ships also could carry them although you still need to pay the engine cost, but they are still effective.

I feel the need to point out thats no longer how maintenance works (and rightfully so if you ask me).

Yes... the new maintenance system will favour quality over quantity allot more now than before. If you have a fleet of 100.000t you need to build that wherever you like to station it. So you might need to build up several places with that tonnage not just in one place, unless you have a really small empire and all your fleets will be stationed more or less in your capital. In any way... you are more likely to need more maintenance facilities in general now if you want some flexibility in where you can station your fleets. You can still maintain ships even if you over stack but that means that the maintenance clock just runs much slower and that might be something you are willing to accept now sometimes.

As your maintenance facilities are based on a set number of tonnage it will be more important than ever to make sure you get as much out of every ship stationed there as possible, especially when you consider that maintenance also often will cost you population unless you build them in space where they are more vulnerable to enemies and more expensive.
 

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 627
  • Thanked: 62 times
Re: C# Aurora Changes Discussion
« Reply #2604 on: February 25, 2020, 06:20:25 AM »
And if you over stack enough you can't even run a ship building program, because the shipyards will be busy overhauling lest everything explode. Or explodes even while you are overhauling everything because there's just too much. I agree it's a good change though.
 

Online Jorgen_CAB

  • Vice Admiral
  • **********
  • J
  • Posts: 1682
  • Thanked: 230 times
Re: C# Aurora Changes Discussion
« Reply #2605 on: February 25, 2020, 08:02:17 AM »
But we don't need the shipyards for the Overhaul... or was this changed in C#?

It is interesting though what happens if you Overhaul a ship at a site that is over-stacked, I will look though the change list and see if Steve mentioned that.
« Last Edit: February 25, 2020, 08:05:54 AM by Jorgen_CAB »
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 9949
  • Thanked: 10024 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes Discussion
« Reply #2606 on: February 25, 2020, 08:40:04 AM »
But we don't need the shipyards for the Overhaul... or was this changed in C#?

It is interesting though what happens if you Overhaul a ship at a site that is over-stacked, I will look though the change list and see if Steve mentioned that.

The overhaul goes more slowly. If you are double-stacked, the overhaul takes twice as long.

 

Online Jorgen_CAB

  • Vice Admiral
  • **********
  • J
  • Posts: 1682
  • Thanked: 230 times
Re: C# Aurora Changes Discussion
« Reply #2607 on: February 25, 2020, 10:46:09 AM »
An interesting question for you Steve... have you ever considered to extend the failure system or something like it to all components. I mean it is one thing for the maintenance cycle to advance slowly if a ship is sitting in space doing nothing. But a ship that is actively moving and using active sensors, shields and all that stuff should wear out allot faster...  I mean you sort of symbolise that when ship are training.

At some time you might do a maintenance system based on components but still have it impact the whole ships maintenance as a whole to avoid micromanagement. With that you would run up the maintenance of ships the more they are in active use which seem quite relevant. Whenever a component is in active use there would be a small chance of a failure... for engines it could be a logarithmic scale on the speed used (perhaps more lenient in the AI though) which would then make it more economical to run the ship at a lower speed unless you need the speed. You also could have technologies and options for reliability on your engines as well for example.

It does not have to be as complex... just something that impact your decisions on how active your ships are and a design choice if you want the ship to be more or less active during its career. A patrol ship would sacrifice some tonnage for more reliable systems as they will be active allot more while a missile boat don't need it as they only will be active if there is a need for them. The same for your fleet... if you mainly intend the fleet to be defending your space you can sacrifice some reliability but if you intend your ships to go on long voyages you will need to design them with more reliable systems.

It kind of work like this even now... but I generally think that it often is a bit too easy to get really long maintenance cycles on ships. It would also be interesting of there are real trade off in the way you actually can use the ships in terms of your economy and strategic use of them.
 

Offline Garfunkel

  • Registered
  • Vice Admiral
  • **********
  • Posts: 1786
  • Thanked: 442 times
Re: C# Aurora Changes Discussion
« Reply #2608 on: February 25, 2020, 11:57:40 AM »
Iranon, I agree that area defence with large beam weapons is now even more useless but going from 1% usability into 0.5% usability is not that big of a difference. Area defence beams were always a gimmick that barely worked at all. Adding the failure rate on top doesn't really change the picture, in my opinion.

OTOH, for planets/moons/asteroids/comets it actually becomes more valid because AFAIK ground units with STO/CIWS capability do not have a failure rate, they just consume supplies, and you don't need maintenance facilities to take care of them either. So if you were using PDCs on airless moons with long-range lasers/particle beams as area defence, that's still possible.

Quote
Encouraging holding fire when hit chances are low is a nice concept, but problematic in Aurora because of the very low beam ranges. Beam fring rates are comparable to 20th century wet navy ships, but the difference between extreme and modest range against a retreating target can be closed in seconds rather than hours. Long-range shots with most lines are penalised in terms of damage as well as accuracy, further shortening effective range if there's any meaningful cost to firing a weapon.
This I do not understand. You cannot make a blanket statement like that since you don't define engines. Yeah, closing speed could be seconds. It could be hours too if one side is running away and the other side is gaining only very slowly. Maybe it'll be 20 minutes, which gives quite a number of opportunities for long-range sniping.

Long-range sniping-kiting has always been iffy and this doesn't change in C# and I'm not sure why you seem to be so worried about it. Is it a dominant/favourite playstyle of yours?

As for missile launchers, you're somewhat mistaken. Because even a 5-sec AMM launcher is not going to be firing for hours AND because it is so small, will only consume very small amounts of MSP. I can't see that becoming an issue to the point where players would abandon full-size launchers in favour of box launchers. Bigger launchers are not going to be firing every 5-seconds and the slower they fire, the fewer chances there are for failure. Reduced-size launchers are not significantly bulkier than before - 0.75 remains the same, 0.5 becomes 0.6, 0.33 becomes 0.4 and 0.25 becomes 0.3 - so we would have to crunch some numbers to see how much of a difference it makes on a ship with 20 launchers or 50 launchers. Furthermore, the changes to missiles (more fuel required, no armour, ECM/ECCM) make it so that to me it seems that bigger missiles fired on a slower pace is better than smaller missiles fired more often. With the caveat that an overwhelming alpha strike reigns supreme and always will.

To me, it seems that while the sensor changes favour small ships, the engine/shield/powerplant changes favour large ships. So perhaps large Battlestars equipped with sensor-drones and box launcher-drones will be mechanically the superior option but unless the AI ruthlessly exploits that particular approach with no alternatives, something that I doubt Steve would program, it won't be a problem any more than any of the current exploit-y options.

There are so many changes in C# that I think it's impossible to accurately predict the metagame at this stage since none of us are smart enough to foresee all synergies or surprising possibilities stemming from A interacting with K interacting with Z.

 

Online Jorgen_CAB

  • Vice Admiral
  • **********
  • J
  • Posts: 1682
  • Thanked: 230 times
Re: C# Aurora Changes Discussion
« Reply #2609 on: February 25, 2020, 09:30:12 PM »
The one thing that "might" make area fire beam weapons somewhat useful in the new version is if long range missiles tend to be rather slower now. That actually could make area fire weapons more useful despite the MSP cost for failures.
 

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72