C# Aurora v0.x Suggestions

[Desdinova]

In the other thread, people are talking about trading ship components between player races.

I know that the planned diplomacy system is a long ways off, but I'd like to suggest:

Making it possible to trade technologies between NPRs. Currently, you can set it so newly discovered technologies can be shared between friendly/allied NPRs, but it'd be nice to have an option to trade previously discovered technologies with allies or exchange knowledge with neutral races.

Making it possible to trade ship components directly, or to grant a "production license" allowing a race to build components they wouldn't normally have access to.

I'd also like to suggest making it possible to steal component technologies through espionage. This is currently possible with missiles, but not other components. If a race has the prerequisite technology to build it, it should be possible to steal the plans for a component.

[JustAnotherDude]

C# has had a bunch of QoL changes that makes certain things a lot easier, but I think a big on is allowing conditional orders to use order presets (i.e go to planet X, moon Y and asteroid Z, transit to system A and refuel at station B) and also, as you considered earlier in the changes list, adding ship level conditional orders. This would let you, say, bring fuel from your homeworld to FoB once it reaches a certain level automatically. One can already have the ship making the trip 24/7 but this would give it some extra finesse and flexibility.

[MasonMac]

Importing/exporting ships. They can only be added if the required technology was researched by that player or the player is in sm mode. There are a lot of designs I like in the design bureau but it's a bit inconvenient having to figure out what technology was used for it.

[tobijon]

Importing/exporting ships. They can only be added if the required technology was researched by that player or the player is in sm mode. There are a lot of designs I like in the design bureau but it's a bit inconvenient having to figure out what technology was used for it.

that's a bit of a problem considering the research of components, I don't see a viable way to solve that.

[MasonMac]

What I'd imagine is that the data is stored has the components with the technology required and the attributes to it (size/fuel eff.) which the program can parse into a usable ship. Then the ship "class" will just contain all the references to the components and how many of them are in the ship. Though before any of this is parsed, there are checks to make sure that the technology has been researched already by comparing the Empire tech and a list of the minimum technology required to design that ship. What I'm thinking is likely an inefficient form of data storage but it's possible to do.

[xenoscepter]

 - How about adding a checkbox that allows the player to determine whether a drive is a Military Engine or a Commercial Engine? Perhaps with a third option for an Intermediate Engine, an option which which might be selected by NOT checking any of the other two? The Military Drives would be heavier than the other two, while having more HTK per tonnage; whilst the Commercial versions would produce better fuel economy than the other two, but suffer from having fewer HTK per tonnage than them. Meanwhile the Intermediate Drives would have balanced stats which served as the baseline. Only Military engines would require Maintenance by default, while Intermediate and Commercial Drives would only require Maintenance if the ship had Military Components.

 - I think that would be a cool idea! It would make things more robust in the balance department, making single engine ships more useful. I think Reactors could benefit from something like this as well; with Military Reactors having more HTK per ton, but also weighing more; while Commercial Reactors create more output than the Military and Intermediate ones, but suffer from less HTK per ton than them. Again, intermediate versions would be a baseline; middle of the road variety. I also think between the Military, Commercial, and Intermediate versions, there should be a difference in the cost to build them. Likewise to this, I'd like to see a "Civil Defense" style of weapons, which would enable Civilian designs to have weapons while being classed as commercial ships, but at the cost of the "Civil" grade weapons being of poor quality. It could even potentially pave the way for export models of weapons and ships.

 - If you were to make Armored Engines and Armored Reactors a thing, then it would become even more robust, allowing the player the ability to trade weight for HTK, overall reducing speed to increase survival rates. This would give players a reason to make single engine ships, as one big engine with armor will be significantly lighter than two big engines without. Coupled to the fuel requirements of larger engines and increased HTK of Military engines, this could make single engine designs quite useful. Likewise, the options are further increased when considering the cost / weight ratio of Intermediate Engines / Reactors with similar or greater Armoring; while the greater cost efficiency and fuel economy of large Commercial Engines might make a heavily armored version desirable for fast and tough ships.

 - Less of a suggestion and more of a request. Can we please mount more than one type of engine on a ship? I understand if it's difficult to program or something, but I just figured I'd ask.

 - EDIT: Also, can we have an option for single man fighters? Perhaps a "Fixed Crew" option which would impose a degraded performance penalty to someone trying to fire, maneuver etc. Maybe dedicated "Fighter" versions of weapons which are much smaller, lighter and cheaper... but can only be mounted on Fighters? Perhaps a dedicated Fighter Training installation to counter the degraded performance, but only for Fighters? Maybe a Fast-Attack Craft class (500-1000 tons) which benefits from that installation? However it needs to work, I really just want to have the ability to control the crew requirements of my Fighters, single man crew, two-man Pilot / Gunner configs, three man Pilot / Gunner / Sensors setup, or even Turret Gunners for big bomber / interdiction craft. That's all. The above are just some suggestions as to how I think such a feature might end up looking like.

 - ANOTHER EDIT: Regarding dedicated "Fighter" components, maybe additional Flight Crew needs for stuff like Lasers, since maintenance is a thing. Or special Fighter Hangars that allocate berths and tonnage to the needed support crews and their equipment. Possibly a component that provides dedicated fuel capacity to Fighter class craft, or one that provides Magazine Capacity for up X number of Fighter ships with Class 1-3 missiles, etc.?

[Garfunkel]

That change to engines would mean that Steve would have to rework the engines and their scaling completely, for no good reason.

It is entirely possible to create 1-man fighters already. As for the other fighter stuff, Steve has stated that he wants to move away from special rules as much as possible - this is the reason why PDCs were scrapped in C# and why engines and sensors are now uniform across all sizes and purposes. If you want to create a 1-pilot or 2-pilot fighters, have them with minimal deployment time and using either box launchers or reduced size gauss cannons, and just the fire control with no other sensors.

[BlueWinds]

In VB6 Aurora, I always end up turning off Inexperienced Fleet Penalties for one reason - when a ship is processing new orders, it comes to a dead stop, which is often fatal in the case of dangerous battles.

Would it be possible to have ships continue moving to their previous destinations while processing new orders (or perhaps continue their previous orders entirely, possibly including continuing to shoot)? It seems more realistic - a ship in a firefight (the only time I really care about reaction time) isn't about to just cut its engines and turn into a sitting duck while the officers confer! (and how were the green gunners disciplined enough to cease fire the moment the 'message from command' light blinked?)

[MasonMac]

Option to get get rid of the hull prefix on the name of individual ships? (i.e. gsv, gev).

[Father Tim]

Option to get get rid of the hull prefix on the name of individual ships? (i.e. gsv, gev).

This can be easily worked around by adding a new 'blank' class type, with a three-character abbreviation of three spaces.

[amram]

Since its time for AI combat programming, there are two aspects of AI targeting that can serve both player and AI equally well, the first is an improvement to missile PD, the second is an improvement to offensive missile fire.

For missile PD

• Can we get two additional settings for Point Defence Modes? 
  
  Specifically minimum salvo count per increment, and a minimum salvo size.
  
  Right now, if I setup a missile defence with say,  (1v1 PD Mode 1270), then I literally spend one missile per inbound, even if there is just one inbound, and I have dozens of gauss turrets.  I waste missiles, lose fights I should have won.
  
  I could choose not to use the system at all, and manually fire on large/excess salvos so that the gauss defences can handle what remains.  This is incredibly tedious and not fun, but effective and I survive larger/longer attacks.
  
  Could we just take the tedium almost entirely out and allow specifying how many salvos must be incoming before the FC cares, or how many missiles must be in any given salvo?
  
  If I had gauss turrets that reliably stop 9+ per salvo, and enough turrets to engage 8 salvos per increment, then I really only need missiles for salvos larger than 9, or more numerous than 8 for any given increment.
  
  Its not OP, because nothing stops me from stacking an ungodly amount of gauss and running a single stack formation - I get missile immunity with no ammunition expenditure at all.  Game the system with a very enticing civilian hull with an absurd amount of CIWS perhaps.
  
  It just enables a more hands off approach to missile defence, letting the ships defend themselves with an efficiency closer to if you were fully hands on, minus the tedium.
  

  It does nothing the the player is not already capable of, saves the player a tedious task if they so choose, and would improve the AI's combat effectiveness as well as the player's by more efficiently spending their limited AMM stocks, letting gunnery take up some of the workload automatically.
  
  

For offensive use:

• FAC/Fighter swarms can be a pain to deal with as a player, just because its so micro intensive.  Select ship, select firecontrol, clear used/reloading/unwanted weapons, select weapons to use for next firing, set target, repeat for 100+ targets.
  
  We already have engagement range for PD fire, so that field can run double duty.  If the missiles per inbound were changed to a manual entry field, it could serve double duty easily as well.  That leaves min TCS as a new field for offensive weapons usage.
  
  The purpose is to leave target selection, and weapon rotation to the AI, with some simple constraints to limit stupidity, and leave the player to the more important aspects of the battle.  Pick an FC, set its weapons per engagement value, set its minimum target TCS, and leave the AI to handle target selection, and weapon rotation from there, micro free.
  
  Have one firecontrol and three particle beams that comfortably one-shot fighters with a 15 second reload?  You won't have to manually stagger their fire yourself, just set the FC to one weapon, give it all three weapons, and set it free.
  
  Don't want a weapon to engage small ships because its overkill? Don't use the auto targeting for that FC, or don't assign the weapon to an FC with auto targeting enabled, or or boost the min TCS of that FC to exclude those small ships.
  
  With it, capital weapons auto target capital sized targets and ignore fighters/FACs, and unconstrained FC's target whatever is closest, including those fighters/FACs.  You just design the ships, build them, bring them, decide which FC gets which weapons, what the terms for usage are, and leave the rest to the AI so you can focus more on overall strategy/tactics, and less on individual ship handling.
  

Miscellaneous QoL

• Would be great to be able to assign a class' default FC assignments while designing it, so that every ship leaves the yard with those settings already done.
• Would be great to be able to assign a class' default standing orders while designing it, so that every ship leaves the yard with those settings already done.
  have the ship default to those orders whenever split off as its own taskgroup.  So you set orders for a survey craft, its built, joins the shipyard group, takes those orders, gets split off by itself, takes the class orders by default.
  
  Think survey fighters launched from a carrier automatically resuming their class default survey orders without having to merge them into a task group together, assign the orders to that group, then split them all up.
• a shoreleave task/order.  Like follow distance, or order delay, it'd be great if I could dictate that a ship take shore leave, for n days, as a means getting ships to take their shoreleave when default orders would move them out again, or to silence geosurvey ships that nag you about not having any work to do when you have no work to give them at that moment.  They'll return to work when it expires and remind you they have nothing to do when that time comes.
  
  If zero, order stands until taskgroup is fully rested, if non zero, order stands until time expires.

A thought on how to organise a feature such as the salvo size/quantity engagement.

By all means, feel no obligation to so much as read the remainder of this post, much less consider it, just trying to save you some brainstorming if it has any merit.

• some Assumptions:
  • I assume salvo's exist as an entity, which holds references to the missiles that it is composed of, and both a target taskgroup and previously written target taskgroup.
  • I assume that salvo's will be saved under a sorted dictionary, with increments to arrival as key, and the value of any given key is a list of incoming salvos that arrive during that increment.
  • I assume the sorted dictionary will only contain keys with live missiles.  Any key which is emptied of incoming salvos should be removed from the dictionary.
  • I assume taskgroups exist as an entity, and contain references to the ships contained within.
  • I assume ship's exist as an entity, and contain a reference to their current task group.
  
  Give responsibility for maintaining that list to the salvo objects.  They have all the information needed.  On missile target update, set previous target taskgroup=target taskgroup, target taskgroup = current target's taskgroup(obtain via target parent task group reference).  On mossile movement, it estimates arrival(dirt simple (distance/(speed*5)) is plenty for this), and updates its target's taskgroup's dictionary of incoming salvos.  It gets there via getting the taskgroup of its target, target.taskGroup.vampires perhaps?  If this is not the same taskgroup as its previously written target task group(target split from group), use that reference to remove itself from the previous taskgroup.  On kill/detonation, use the references to remove itself and keep the dict clean.
  
  On each combat/defence increment, while it has an idle FC with idle launchers, each ship goes through each key in the dict, pulls the list(or whatever other convenient structure is used) of salvos that arrive in that key/increment, in order of soonest to most distant in time by virtue of sorted dict.
  
  If any salvo exceeds the salvo size setting, fire on it to bring it below that value.  If total salvo's exceeds the salvo quantity setting, fire on the smallest salvo to eliminate it. 
  
  
  It will not waste effort trying to figure out what missiles are arriving together, because each key contains exactly that, and each missile puts itself where it belongs as part of its movement update, utilising the target object reference saved in the salvo to save future effort in looking up their target.
  
  It will not waste time in querying missiles that are not a threat to it at that moment
  
  
  For area defence of other taskgroups, one need only obtain a list of task groups which are in range, and run through their dictionaries to see what danger they are in, and if you can assist.  Having the intercept time handy, one can easily decide which engagements are pointless to attempt, and which engagements can be meaningfully useful in.  Perhaps a priority TaskGroup menu field would be valuable in such case for missile pd, allowing setting the ship to defend another taskgroup entirely before seeing to its own defence by using that taskgroup's vampire dictionary before its own taskgroup's dict.
  

[chrislocke2000]

A few other thoughts on the AMM piece:

- I often find myself with groups of AMM ships where one two have fully expended all of their ammo whilst others in the fleet have full mags which I assume is due to some ships always selected as firing first. This isn't much of an issue in VB6 because of instant ordnance transfer but I can see it becoming a real bug in C#. If the firing order could just be switched to whichever ship has the fullest magazines I think that would go a long way to help.

- On wasted AMMs I think I have mentioned before that having a minimum engagement range for AMMs as well as the current maximum would again help with using layered missile and PD fire.

[amram]

Noticed a flaw in how I laid out my concept above.  I didn't adequately consider salvos with no target set.  As described above, your ships wouldn't shoot on passively guided missiles that were sent to a waypoint that will let them see and target you themselves, until such time as they actually target you.  Possibly a valid approach, but liable to get you killed and opens an AI exploit.

Perhaps have missiles with no target register with every task group they could reach with some weighting for their approach angle, and unregister themselves as time goes by and they no longer have the range to reach that task group, or once they go live and pick a target.

The target ships wouldn't shoot on absurdly distant salvos, they can't even detect them probably, and FC/AMM ranges limit their firing, it adds cost, but minor, and ships which can engage, will engage missiles that have no targets set yet.

A few other thoughts on the AMM piece:

- I often find myself with groups of AMM ships where one two have fully expended all of their ammo whilst others in the fleet have full mags which I assume is due to some ships always selected as firing first. This isn't much of an issue in VB6 because of instant ordnance transfer but I can see it becoming a real bug in C#. If the firing order could just be switched to whichever ship has the fullest magazines I think that would go a long way to help.

- On wasted AMMs I think I have mentioned before that having a minimum engagement range for AMMs as well as the current maximum would again help with using layered missile and PD fire.

A round robin engagement pattern would smooth that out considerably, with the assumption that ships not ready to fire are skipped over by those who are.  You'd still run dry in one ship before others, potentially much earlier if their designs aren't well suited to equal expenditure/endurance, but at least it wouldn't be one empty and others full, they'd all be depleted, and if they were the same class, very nearly all depleted together.

I didn't try to sort out the order in which the FC's were evaluated as able/ready to fire above.  If each ship that can engage in missile PD is kept in a queue, then you iterate over the queue, and move any ship which opens fire to the rear, even if its just one FC or many that fired, you could spread the workload across every ship with a capable FC before ever having a ship shoot a second time.

A minimum engagement range would also be very nice, and it would play well with both of my above suggestions, offensive and defensive AI control of weaponry.

I stuck to just the bare minimum I saw to be useful, but the complete set of criteria I'd love to have shared for both PD and offensive firecontrol: Min range, max range, min TCS, max TCS, weapons per engagement.  For PD specific FC, the salvo size and quantity settings to effectively attempt a defence against saturation attacks, as well as a priority, changing the round robin firing queue to a priority queue.

You could then limit AMM fire in ASM roles to anti fighter work for example, or prevent your 200 damage ship killers from being spent on fighters, and can layer your defence so long range and short range AMM is a thing the AI FC respects.

With the priority queue, every ship with a defensive missile might not engage, because a high priority FC might be busy as hell keeping the fleet safe, but those low priority FC's will step in if the high priority FC is ever so busy that there is work left over.

Think modern fleet defense.  If you have 16 missiles, and a single FC channel, you could certainly engage a lone inbound, but if there is a ship with an even better missile than you carry, and/or with much deeper magazines, and more FC channels, and its in a position to offer a better defense than you, they should shoot, not you. You should save your limited defence for when it really matters, saturation attacks.   FC Priorities let the player affect the queue in this way, by causing an 'important' FC to keep cutting in near the front of the line instead of moving to the rear every time it engages, while still spreading the work equally across FC's with equal priorities.

[Garfunkel]

How would one ship know that it has more missiles left than another ship? Do the ship computers talk to each other automatically or does it require the crew to communicate such decisions? Could networked combat groups be a new research tech and ship module? And what if I want one ship to empty its magazines first, so that it can be detached and sent back for resupply, instead of all AMM escorts running dry at the same time?

[Father Tim]

And what if I want one ship to empty its magazines first, so that it can be detached and sent back for resupply, instead of all AMM escorts running dry at the same time?

Then I think you're stuck transferring munitions after the battle.  Amram's 'priority queue' might deliver what you want; otherwise you'll probably need to handle it manually.