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

0 Members and 1 Guest are viewing this topic.

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #465 on: August 25, 2018, 09:28:03 PM »
I'd point out a lot of the lack of flexibility on legacy aircraft such as the f-14 and a-10 is due to exceedingly old electronics and non standardized connectors, issues which are both not nearly as much of an issue on newer platforms using newer missiles.

In general, the harrier was a good aircraft because it could do the job of a multirole fighter while constrained to the tiny deck of a british aircraft carrier, perhaps a better example of a multirole that isn't under such constraints would be the f-15 strike eagle or most of the newer f-16 variants (or for that matter the f-18 superhornet) all of which can carry a fairly wide variety of munitions with a good degree of flexibility, while also being hugely dangerous air-to-air threats capable of supersonic flight.  With respect to the growler refit, thats true that a carrier cant do that, but you can put generic electronic warfare pods onto fighters just fine, they just arent as good as a dedicated EW bird such as the growler (which has quite a lot done to it other than simply bolting a couple EW pods on).  In general the navy tends towards growlers covering formations of fighters because that is more effective for them, but that doesn't actually stop them from getting very minor f-18 modifications that would let them all carry less powerful EW devices if they were so inclined.

Here is an f-16 carrying an electronic warfare pod on its belly:


Yes I would agree that in general missile launchers are more specialized than aurora makes them out to be, but in a lot of the earlier magazine based ships that got brought up by mentioning the oliver hazard perry, there was absolutely no consideration for standardization and flexibility for those ships.  The perry class was practically one of the first production missile destroyers ever made.  The current missile destroyer and cruiser family in the USN all have complete flexibility in how they load their box launchers.  Yes it takes time to re-arm a particular cell, but the time it takes isn't particularly influenced by what kind of cell you are loading.  I don't see any particular reason why magazines couldn't also be standardized to some degree in the future, if anyone ever felt inclined to go back to using those.

With respect to the assumed modular mass ratio of 2% or whatever, an f-16 loaded with fuel weighs 12000kg, and can carry up to 7700kg of additional payload for a total of 19700kg.  7700/19700 = circa 40% of the final mass, which is quite a lot.

Finally, with respect to lasers, thats a good point about wiring.  It would be a huge stretch to say that you could run the huge amount of wiring needed to direct reactor power to generic mounting points with any reasonable degree of effeciency or flexibility.  I'll concede the laser point as kindof ridiculous on that basis.

e:  I also don't particularly mind the concept of fitting different weapons or targeting/EW/sensor pods costing MSP and such for instance.  I also think it would be reasonable to say that fighter box launchers or hardpoints or what have you should have their full carrying capacity included in the base fighter mass, so that you aren't getting to move components outside of the armor to save on armor weight.  As far as I know part of why everything has to have at least one armor layer is so that it has the robust structure required to pull hard maneuvers.  Obviously that should apply to hardpoints as well, which would have to be quite reinforced I would think.  And then the hardpoints have the downside of the payloads existing outside of the armor regardless.
« Last Edit: August 25, 2018, 09:37:53 PM by QuakeIV »
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2788
  • Thanked: 1051 times
Re: C# Aurora v0.x Suggestions
« Reply #466 on: August 25, 2018, 09:37:35 PM »
The 2% thing was just a left over from an earlier comparison. It really is meaningless - the point was to show the size/mass difference between a Harrier gun pod IRL and an Aurora laser.

I agree that more modern planes are designed with modality in mind, but that's a result of 50+ years of development. Same with the EW warfare pods - the planes had their computer systems upgraded so that they could actually take advantage of the pods. That's the thing, all of this modularity and multi-use is the result of decades of design work, and all the components involved were purpose-built to be modular and multi-use. If we can replicate that process in Aurora, then I'm 100% for it. But if we can't, then it's just another method for the human player to curb stomp the NPR.
 
The following users thanked this post: Scandinavian

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #467 on: August 25, 2018, 09:41:03 PM »
I mean, only if the NPR is unable to make use of this stuff.  Mind you, I agree that conventional AIs have so far done horribly in environments with lots of options that have complicated implications.  I'm also not really sure why a tech curve would help the NPRs against this, it seems like that would only delay the inevitable if they are bad at it regardless.

Also, I'd note that these modularity concepts would most likely apply to trans-newtonian stuff as well (having implicitly been developed prior to the TN tech), though I agree they would probably require a fair bit of additional technology to deal with all the new trans-newtonian physics factors.  I don't necessarily think its a good idea to add those techs since I don't see what that complexity would bring to the table.
« Last Edit: August 25, 2018, 09:46:39 PM by QuakeIV »
 

Offline amram

  • Lieutenant
  • *******
  • a
  • Posts: 154
  • Thanked: 79 times
Re: C# Aurora v0.x Suggestions
« Reply #468 on: August 26, 2018, 12:06:18 AM »
Agreed on modularity being a feature of the future.   Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.

I'd note that even today's latest and greatest can't field everything though, F-35's currently have no HARM capability, starting with the point that the missile won't fit its internal bay - given the objective of stealth and the penalties of carrying externally, its not wired to even try.  AIM-120's have external mounting capabilities though, no reason to hobble it in lower threat environments.   Even as modular as they are, weaponry included, the ever present issue of aerodynamic and torsional stresses, wiring/connectivity and internal software/awareness of the munitions envelop remain a thing, though we certainly do try harder to keep it an option.   Fortunately for the concept, this is the sort of detail aurora abstracts away entirely, absolving us of needing to dwell on it, once sure we don't consider it too large a hurdle.

I also agree that it may be difficult to balance well, and especially the AI using it effectively.   Though an AI effectively abusing this could have very capable carriers.   An entire fighter wing that can launch with the right armament to best make you suffer, and then be completely different for its next engagement?

I would contend it should not be possible to internally mount a complete weapon system, and still be able to later swap it out like a munition - once inside the armor, that's that.   Something mounted outside the main hull may be open to a little more variability, but you lose the advantages full integration would have allowed.   This tradeoff would naturally be in one of two forms for gameplay reasons, either a loss of performance for same mass, or a growth in mass for same performance.   Given the intent to mount these on fighters, the loss of performance for same mass seems the better candidate.   So for the same mass, you get a somewhat inferior, but more flexible weapon system.

In the interests in achieving reasonable fire control range, the fire control should not be in the mount, it should be hosted by the parent craft.

Now, on to energy supply.   Under the assumption that modular mounting of lasers or particle weapons is a thing, should the power be in its own pod, part of the external mount, or mounted in the parent craft?  I'm partial to requiring they be internally mounted, and suffer a penalty to delivery efficiency, perhaps a simple percentage loss of power at the mount, requiring a larger generator for same system, or the more explosive flavour for similar/same size.

This leaves you deficient compared to a dedicated system in a couple ways.   One, the weapon system will not have the advantage of armor - not that fighters have much anyways.   Two, it will lack the performance of a dedicated system.    Three, even when not mounted, you have mass spent on the no unnecessary power generators.  Four, the expense of design and construction should be larger, its one thing to integrate the weapon, its another to run it from a mounting, the design considerations change.

In an all up fight, the fighter with permanent mounts should perform better and cost less - it sacrificed flexibility to get those advantages.   There are many efficiencies you can leverage when you can optimise for a specific system rather than generalising.

There is one serious caveat to this line of thought, and QuakeIV already mentioned it.   If it is reasonable to mount a weapons system, why would it not be reasonable to do something less challenging: mount active or passive sensors, ECM, or ECCM?  What about even simpler things like fuel tanks?  Could fighters end up serving as emergency tugs dragging out a podded tractor beam?

Personally, I think its much harder to justify the can of worms for full weapon systems, much less difficult for subdivided box launchers.
 

Offline Scandinavian

  • Lieutenant
  • *******
  • S
  • Posts: 158
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #469 on: August 26, 2018, 01:49:36 AM »
Agreed on modularity being a feature of the future.   Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.
This is peacetime logic.

Once you start taking double digit casualty rates in each engagement, you need to start counting the cost of replacing attrition. Any capability you're using less often than your attrition rate is on average better off being split off to a dedicated specialist platform. And you will see double digit attrition rates if you ever go up against someone who can shoot back: Since the early 1940s the ability of a weapon platform to inflict damage has grown much faster than the ability to equip the same platform to endure damage, and there is no sign that this trend will break any time soon.

For wars against people who can't shoot back - colonial punitive expeditions and counterinsurgency warfare - you don't need multirole platforms either, because you don't need most of the roles they provide. Bringing next-generation air superiority capabilities to a counterinsurgency is like bringing a thousand dollar golf club to a back-alley brawl. I'm sure it's a very nice golf club, and in a pinch you could hit a guy over the head with it, but you're better off bringing a ten dollar knife and a lack of sportsmanship.

(Also, the supposed savings from multirole platforms tend not to be realized, but that is mostly a matter of political dysfunctions in the armaments procurement bureaucracies of the countries that have that design doctrine. And Aurora does not model the political economy of the military-industrial complex.)
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #470 on: August 26, 2018, 02:25:25 AM »
I think you are saying that multirole capability is wasted if the expected statistical outcome for the vehicle is to be destroyed before it can use every capability.  Therefore, leave out the unused capabilities and just send specialist units to perform their one mission and then die.  I will try to argue mathetically, which is probably a mistake given how late in the night it is for me.

I don't fully agree that this applies to multirole vehicles when for any given mission they are able to leave the useless parts of their multimission capability behind.  Yes they are somewhat less capable at each role, but for instance you don't need to bring your expensive multispectral targeting system on an air to air mission, nor do you need to bring every possible needed EW capability at the same time.  You can just leave the un-needed bits in storage, and then they are still there and useful to go do their thing even after loss of vehicle.

This allows for siginificant economy of force in that you can for instance potentially send quite a lot more air to air capability up against the enemy than they can respond with (all other things being equal), since they have specialized vehicles of which only a fraction can engage with your own vehicles.  So, unless the cost to produce some arbitrary x air to air capability in multirole vehicles plus the weighted average of their mission equipment (weighted by the optimal balance of equipment) is nearly as expensive as the weighted average cost of every possible specialized vehicle (weighted by the optimal balance of equipment) then the multirole would generally come out on top because you could exert more force in any given role with the resources at hand.

e: There is less total multirole capability, but the total in any specific environment is higher.

This is ignoring the economy of scale amram mentioend in his logistics argument, wherein you could have significant economy of scale by mass producing a lot of the same thing.  Though, I think that working out would be dependent on the common multirole vehicle being the majority of the cost or something like that.

He may also have just been pointing out that there is the logistical upshot of always having the right equipment in the right place at the right time (though this would only be fully true if you could afford to have a full complement of gear to go with every vehicle), rather than having a bunch of ground attackers and SEAD somewhere where you need air to air for instance.
« Last Edit: August 26, 2018, 02:44:31 AM by QuakeIV »
 

Offline Scandinavian

  • Lieutenant
  • *******
  • S
  • Posts: 158
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #471 on: August 26, 2018, 03:35:59 AM »
You're assuming that the integration overhead of the platform itself is negligible, which is not true.

You're further only looking at initial strike capabilities, not the economics of sustained attrition. The cost of sustaining a particular amount of battle-winning ability in a given theater over the course of a long conflict against a capable enemy is heavily tilted toward the cost of replacing expended equipment, not the cost of maintaining the readiness of unused equipment.

If maintaining readiness in peacetime is already straining your logistics train, then your doctrine doesn't matter because your tail will break the moment you actually have to fight a serious shooting war. This is one of the five 'C's - the big five reasons even large, well-funded militaries fall on their face when they stumble into a war after a long period of peace: Coups, Counterinsurgency, Conscripts, Corrupt procurement, and Civilian logistics.
 

Offline Person012345

  • Captain
  • **********
  • Posts: 539
  • Thanked: 29 times
Re: C# Aurora v0.x Suggestions
« Reply #472 on: August 26, 2018, 04:23:35 AM »
Agreed on modularity being a feature of the future.   Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.
This is peacetime logic.
No, logistics is an immensely important part of warfare and is often the make-or-break factor in real life war. Having equipment that can do the job, albeit less well, is always preferable to not having the equipment to do the job at all. Having for example one type of multirole plane doesn't just mean that you have the equipment though, even if more can't be delivered. It also means that you only need to produce replacement components, fuel, mechanics and everything else that goes along with operating a plane, for that single type of plane and that they are compatible with every plane there. This immensely simplifies the production chain and allows you to ramp up production faster, and simplifies the logistics of delivering these things where they need to go.

Better equipment wins battles, better logistics wins wars.Obviously there's wiggle room here, with sufficient logistics and sufficiently advanced equipment the equipment will be more likely to win enough battles to sway it, but history has pushed us in a general direction.
« Last Edit: August 26, 2018, 04:25:15 AM by Person012345 »
 

Offline amram

  • Lieutenant
  • *******
  • a
  • Posts: 154
  • Thanked: 79 times
Re: C# Aurora v0.x Suggestions
« Reply #473 on: August 26, 2018, 05:43:36 AM »
Quote from: Person012345 link=topic=9841. msg109535#msg109535 date=1535275415
Quote from: Scandinavian link=topic=9841. msg109532#msg109532 date=1535266176
Quote from: amram link=topic=9841. msg109531#msg109531 date=1535259978
Agreed on modularity being a feature of the future.    Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.
This is peacetime logic.
No, logistics is an immensely important part of warfare and is often the make-or-break factor in real life war. 

. . . snip. . .

Better equipment wins battles, better logistics wins wars. . . .

Bingo.   If you field more models of equipment, with a force structure that is equivalent in performance to an adversary which meets you in quantity and quality through a single model, they hold a significant advantage.

Take air combat.   two forces.   One has 30 fighters and 30 attack planes.   The other has 60 multirole.   The fighters are superior and will maintain a 3v2 kill ratio.  After the initial combat, they lost their 30 fighters, you lost 45 multirole.   Your 15 remaining multirole easily murder the attack aircraft and now only you have aircraft.

Another approach, assume the 30 fighters can fire first, pk 0. 7 per shot, the multiroles pk 0. 3 per shot.   The 60 multirole will win with 15 survivors.   Even 30 fighters and 45 multirole, with 0. 6 and 0. 45 pk, the multirole win with 4 survivors.

Multirole flexibility allows sudden swings in your total force in a given role, instead of only 30 aircraft on CAP, you can have 45-60.   Quantity is a quality all its own.

It simplifies your logistics allowing the entire force structure to utilise any given supply, improves supply delivery since how much of what devolves to as many of one thing as fits.   Its better to have 4 spare engines for all your craft than none for the model that needs one now.   Ditto for ammunition, in some cases even fuel.

Production benefits as well, less competition for limited resources means the quantity of the stock will be increased.   Distribution, warehousing, acquisition, everything benefits.

Aurora multirole fighters could make for a very powerful airwing provided the selected armaments are on point.
 

Offline Scandinavian

  • Lieutenant
  • *******
  • S
  • Posts: 158
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #474 on: August 26, 2018, 06:39:57 AM »
If you field more models of equipment, with a force structure that is equivalent in performance to an adversary which meets you in quantity and quality through a single model, they hold a significant advantage.
If you use two models and his single model is three times as expensive in manufacturing time and supply chain complexity, he will have to outspend you by fifty per cent just to have parity in quantity and quality.

Standardization works when the cost of standardization is lower than the cost of redundancy. Agreeing on only using two or three ammunition calibers is very nearly costless (though notice that even here the cost of standardizing on a single caliber was deemed excessive - while squad-support rifles can assault rifles use interchangeable munitions, you still have different, non-interchangeable munitions between squad support and full machine guns and marksman's rifles).

Agreeing to use only one airframe instead of three, on the other hand, raises unit cost by a factor of ten or twenty (compare the F-35 to a fleet of mixed F-16/A10/Predator drones), and then the economics don't work.

Quote
Take air combat.   two forces.   One has 30 fighters and 30 attack planes.   The other has 60 multirole.
That will never be the force structure of the two opposing sides in your hypothetical. The side that uses dedicated planes will always field a force more heavily weighed toward air superiority on day one, because once one side has established air superiority it is very hard to take it back, while flying CAS can clearly wait a few days for reinforcements to be brought up from rear echelons (if it could not, you would not be able to fly all of your fleet in the air superiority configuration during your alpha strike). At a 3:2 kill rate, they only need a 45:15 split to wipe out your whole force on the first day, at which point you will never recover the attrition game (assuming equivalent total production capabilities, and that they produce air superiority planes at a 3:1 rate to ground attack), and they are free to fly CAS with impunity.

And assuming equivalent budget instead of equivalent numbers, you're even worse off, because your multiroles are individually more expensive than his dedicated planes.

(Of course in reality, the defending side would have surface to air missiles, and the force mix in the air would not matter, because all aircraft on the attacking side would be blasted out of the sky on the first day.)

Quote
Production benefits as well, less competition for limited resources means the quantity of the stock will be increased.   Distribution, warehousing, acquisition, everything benefits.
Yes, I've also read Lockheed's advertising copy.

Let me know if you find an airforce anywhere in the world that has ever been able to cut their budget without losing readiness after buying Lockheed. Because that would be a first.
 

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: C# Aurora v0.x Suggestions
« Reply #475 on: August 26, 2018, 09:05:16 AM »
Hey gang, can we please take this to another thread?  Steve is pretty conversant with modern military technology, and the suggestion (and objection) has been made. 

Please remember that Steve uses the Suggestions thread as a filing cabinet/issue database, so forcing him to scroll through a lot of back and forth when he reviews the thread six months from now to find unique suggestions is not doing him a favor.

Thanks,
John
« Last Edit: August 26, 2018, 09:10:58 AM by sloanjh »
 
The following users thanked this post: Scandinavian, Jovus, King-Salomon

Offline Jovus

  • Lt. Commander
  • ********
  • J
  • Posts: 220
  • Thanked: 81 times
Re: C# Aurora v0.x Suggestions
« Reply #476 on: August 26, 2018, 09:45:37 AM »
Thinking about it last night, I came up with what I think is the single most important change for C# that I haven't seen discussed anywhere else.

In C#, the bitmask that occasionally changes officer sex to YES!! should be retained. Furthermore, the miniscule chance should be multiplied by some coefficient of deployment time, so that officers on long deployments are more likely to display it. Furthermore, there should be another coefficient multiplier based on crew morale, so that officers on deployments so long that the shipboard amenities are running low are even more likely to display it.

This seems to me to be a critical issue, without which we simply can't consider C# complete.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #477 on: August 26, 2018, 06:04:54 PM »
Not sure how this forum works with regards to the difficulty of thread splitting, would you be willing to split off the debate of that particular suggestion into its own thread?

starts here: http://aurora2.pentarch.org/index.php?topic=9841.msg109413#msg109413
 

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: C# Aurora v0.x Suggestions
« Reply #478 on: August 26, 2018, 09:17:04 PM »
Not sure how this forum works with regards to the difficulty of thread splitting, would you be willing to split off the debate of that particular suggestion into its own thread?

starts here: http://aurora2.pentarch.org/index.php?topic=9841.msg109413#msg109413

I know how to split out a thread, except it involves going back through the posts and deciding one by one whether they get pulled into the now topic (which is why I didn't do it earlier - I just didn't have the energy).  I don't know how to move posts back and forth between two threads though.  Since you've already made a branch (thank you!!) I'm just going to leave it alone.

Thanks,
John
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #479 on: August 27, 2018, 12:55:55 AM »
Some ideas on event update messages:

I'd like getting an event update when I, lets say have 5 MDs on a planet (which has a send to target set) and the mineral production of that planet goes over or under the sending capacity (in this case 20.001-25.000t per year). If it gets below 20.000t, I would like to get a message stating that I have unused MDs on a planet, or if it goes above 25.000t, it should read: cannot send all produced minerals via MDs on planet XY.


I usually set up mineral transports for transportation through jump points. Every now and then I check if the transport still can carry all collected minerals of the starting planet and either increase the number of transports or increase the traveling speed of them. So a message like "could not pick up all stored minerals on a planet" would make my life a little easier doing that... .