C# Suggestions

[Iestwyn]

Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.

I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.

Max tractor size would be interesting and could be done in a few different ways. Just having a plain absolute maximum would be kind of limiting and probably slow down the game economy too much, but either making it a multiple of the tug size or allowing multiple tractor modules with additive total tugging capacity. Doing both would be really interesting, i.e. each module lets you tug X% of the tug's mass, but that might be making things overly complicated. Personally I think the mass-per-module makes the most sense, physically a single tractor beam would have an upper limit of tugging capacity regardless of its mount.

Makes sense to me. That way, there could be the same kind of design decisions as other modules, like how grav sensors scale up as the tech increases. That would also allow for more and more efficient tugs as tech improves.

I do wonder what happens if you try to tug something above what the tug is rated for. Does it just not work? Are there speed or fuel efficiency penalties?

[TheTalkingMeowth]

Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.

I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.

Max tractor size would be interesting and could be done in a few different ways. Just having a plain absolute maximum would be kind of limiting and probably slow down the game economy too much, but either making it a multiple of the tug size or allowing multiple tractor modules with additive total tugging capacity. Doing both would be really interesting, i.e. each module lets you tug X% of the tug's mass, but that might be making things overly complicated. Personally I think the mass-per-module makes the most sense, physically a single tractor beam would have an upper limit of tugging capacity regardless of its mount.

Makes sense to me. That way, there could be the same kind of design decisions as other modules, like how grav sensors scale up as the tech increases. That would also allow for more and more efficient tugs as tech improves.

I do wonder what happens if you try to tug something above what the tug is rated for. Does it just not work? Are there speed or fuel efficiency penalties?

The most interesting mechanically would be to have tractors have an engine power (which is speed*mass) transfer rating. Like, a 1000 EP tractor would allow hauling a 100 ton (2 hull spaces) target at 10,000 km/s, or 1000 tons at 1000 km/s. Then have tech that scales the efficiency of tractor beams, and let us design different size tractors. Finally, let tractor beams work both directions; the tugged ship can also have the tractor.

The point of this would be to allow using multiple tugs on a single target to speed it up, or to let a single super tug haul multiple things. It would also make tiny tractor beams reasonable. I want to make the self-tractoring missile pods from Honor Harrington! But currently, with fixed, 500 ton tractors that have to be on the ship providing the engines, this is thoroughly impractical.

Mathematically, working out the acceptable speed for a tug network would end up being a linear program. There are very very fast algorithms for this!

[TheTalkingMeowth]

Sorry about double post, but as this is thoroughly unrelated....

The new reduced size single weapon fire controls could be taken further: make fire controls, in general, have limited number of weapon allocations. Bigger fire controls would allow more weapons to be assigned to them.

The purpose of this is to make giant infrequent missile salvos less effective, since it becomes hard to have enough fire control channels to make it work. It also opens up interesting design space related to sharing fire control channels, much like the rotating guidance schemes used in some of the later Honor Harrington books.

If applied to beam fire controls, it would also create more of a reason to go for layered anti-missile schemes, since you can't manage 100 railguns firing simultaneously anymore. This would help balance out the nerf to missiles, too.

[xenoscepter]

http://aurora2.pentarch.org/index.php?topic=12088.msg143483#msg143483
^I'm gonna put this here as it is more of a Suggestion than a helpful contribution to the 1.13.0 Changes Discussion. The Off Topic contains the reply itself, just incase a duplicate proves useful. The above is a link to the original.

Off-Topic: show

- Well, the return of reduced size FCS already makes Beam fighters wayyyy more practical than they were before. Like, quite significantly so.

 - With that having been said; for Plasma Carronades I'd like to see them have an option to consume fuel as ammo. Perhaps a kind of alternative shield that was stronger and/or smaller, but consumed fuel as well to go with it. In Homeworld and Homeworld 2, the Plasma Bombs were fluffed as using a portion of the starship's fuel as ammo, which keeps with the idea and logic of what plasma actually is, that being a state of matter. I don't really expect Steve to put all that work into them though, as much as I'd like to see such a change it really doesn't jive to well with Aurora's flavor, IMO.

 - An alternative for the Carronades would simply to be adding in the reduced size and giving them an "Extended Minimum" analogous to the Laser's Spinal Mounts. The Extended Minimum would have two levels, with the first reducing damage drop off for a corresponding increase in weight, say halving the drop off in exchange for a mass increase equal to +1 calibre. AKA, like how Spinal Mounts increase the laser's weight. The second tier would add +2 calibres of mass for a removal of damage drop off. This would mean that you could combine the two upgrades to make an expensive 15cm Plasma Carronade that had no drop off and weighed the roughly the same mass, but had drastically increased recharge needs.

 - For the HPMs, I'd really just like the option to turret 'em, tbh. I think they'd make nice Anti-Fighter / Anti-FAC guns. I'd also like to see the damage of HPMs, well "damage", but you know what I mean... I'd like to see that increase with calibre. Likewise for Mesons, I'd like to see bigger Meson Guns do more damage. So a 12cm HPM would do 4 damage to shields and a 15cm would do 5 damage to them, but both would still only roll once for E-DAC, while the 20cm would do 6 Damage to shields and roll twice on the E-DAC. Basically have the bigger HPMs increase the shield damage while making the number of rolls on the E-DAC be equal to half the shield damage rounded down.

 - Mesons could do something similar, in that they fire a bigger "shot". So a 12cm Meson fires a 2-point "shot", a 15cm Meson fires a 3-point "shot" and so on and so forth. Thus the Meson Retardation Tech would become more useful as you went up in size, with each failed roll removing 1 point of strength from the "shot" until it finally fizzled. The size, power requirements, costs and so on would keep smaller guns useful for fighters, turrets and such, while the FCS needed to make use of the better range would help keep the mid-sized guns relevant for some time as well. These factors would also curb the usefulness of truly monstrous guns, like 30cm+ ones, as their FCS and Power Requirements would hamstring their damage output via accuracy, RoF, and required technological & material investment.

 - Thus under these changes Plasma Carronades would become a more robust and interesting weapon system to invest in, without losing their low-cost / low-tech niche. HPMs would become shield-buster / ion cannon-esque weapons, and with the option to turret would double as Anti-Fighter / Anti-FAC against beam-centric foes. Mesons would a lot more useful to research as a main weapon option, since the big ones would give better performance against ships while the turreted small ones remain a viable Anti-Missile / Anti-FAC, with the ones in the 12~15cm range would double as Anti-Fighter weapons. These would make Mesons into an actually threatening weapon, without reverting them to the overpowered monstrosities that they were. Add back them Armored Missiles and suddenly they become very, very attractive options indeed.

[xenoscepter]

Sorry about double post, but as this is thoroughly unrelated....

The new reduced size single weapon fire controls could be taken further: make fire controls, in general, have limited number of weapon allocations. Bigger fire controls would allow more weapons to be assigned to them.

The purpose of this is to make giant infrequent missile salvos less effective, since it becomes hard to have enough fire control channels to make it work. It also opens up interesting design space related to sharing fire control channels, much like the rotating guidance schemes used in some of the later Honor Harrington books.

If applied to beam fire controls, it would also create more of a reason to go for layered anti-missile schemes, since you can't manage 100 railguns firing simultaneously anymore. This would help balance out the nerf to missiles, too.

 - I like the idea as applied to Beam FCS, but frankly the big, infrequent salvos thing is already sub-optimal to the point of being near ineffective. Box Launcher spam notwithstanding mind you, but Box Launcher spam is already balanced out by counter-AMM Box Launcher spam, cheap decoy missiles, and by virtue of being a "one shot wonder" as they can't be reloaded mid-battle. The Beam FCS requiring more weight to control more guns is a bit... weird in terms of logic, but since any number of guns can be tacked onto any number of FCS systems to engage any number of missile salvos that might actually create some interesting design decisions, without forcing a meta. It would also serve to increase the role of CIWS as a military system, making it a more attractive option and thus creating even more flavors of design.

 - As to 100 railguns... under the C# weapons model you'd probably destroy the damn ship by eating through MSP, so that's not really a great example, but yes having bigger FCS to handle those bajillion guns would be pretty neat. However you already more than one FCS to track more than one (non-missile salvo) target, and you need at least four FCS units if you want to perform offensive beam attacks, Area Defense PD, Final Fire PD and Final Fire PD(Self-Only) at the same time. So it already seems pretty balanced as is, tbh. An erstwhile and good suggestion in any case.

[vorpal+5]

Scientist history: Would be nice to have their completed projects there!

[TheTalkingMeowth]

 - I like the idea as applied to Beam FCS, but frankly the big, infrequent salvos thing is already sub-optimal to the point of being near ineffective. Box Launcher spam notwithstanding mind you, but Box Launcher spam is already balanced out by counter-AMM Box Launcher spam, cheap decoy missiles, and by virtue of being a "one shot wonder" as they can't be reloaded mid-battle. The Beam FCS requiring more weight to control more guns is a bit... weird in terms of logic, but since any number of guns can be tacked onto any number of FCS systems to engage any number of missile salvos that might actually create some interesting design decisions, without forcing a meta. It would also serve to increase the role of CIWS as a military system, making it a more attractive option and thus creating even more flavors of design.

Big, infrequent salvos (box launchers, or just reduced reload rate launchers) are the optimal way to use missiles. That doesn't mean they are the optimal way to play the game, which may be what you are getting at. But currently, if you want to use missiles this is the best route. And as a result, antimissile capabilities need to be balanced around it. This, in turn, makes other approaches untenable. Increasing the expense of huge salvos would allow weakening missile defense capabilities without causing missiles to dominate, in turn allowing other missile approaches to work better.

- As to 100 railguns... under the C# weapons model you'd probably destroy the damn ship by eating through MSP, so that's not really a great example, but yes having bigger FCS to handle those bajillion guns would be pretty neat. However you already more than one FCS to track more than one (non-missile salvo) target, and you need at least four FCS units if you want to perform offensive beam attacks, Area Defense PD, Final Fire PD and Final Fire PD(Self-Only) at the same time. So it already seems pretty balanced as is, tbh. An erstwhile and good suggestion in any case.

Currently, very little tech is required to put up a nigh-impenetrable wall of 10cm railgun PD. However, this relies on large quantities of such guns, since each shot is really inaccurate. If the mass (and thus, cost) of fire controls to support your PD scaled with the number of guns, that would make mass railguns weaker without affecting stuff like turreted PD or AMMs as much (since they use fewer numbers of higher accuracy weapons, and thus need less fire control).

Basically, the whole point of scaling fire control size with # of weapons is to force players to spread shots out temporally. If we can't handle 500 missiles in one tick, we need to use strategies relying on 300 missiles every other tick. If we can't manage 1000 final defense shots when the missiles arrive, we need to thin them out with AMMs, then longer ranged PD fire.

As to flavoring why beam fire controls scale with # of weapons controlled...well, it never really sat right with me that non-turreted weapons were truly hull mounted (how can they all engage a single target? Isn't the ship in the way?). So the fire control mass allocation could include some limited traverse capabilities for all the weapons assigned to it. Or something.

[nuclearslurpee]

Commander auto-assign needs a couple of tweaks to be actually useful.

First: Some degree of allowance needs to be made for commanders to command a ship that they are technically overqualified for. Currently, the auto-assign will only assign a commander to a ship if they are exactly the minimum rank needed to command that ship. This is fine for warships where you have a few different classes and generally can designate one class to have Senior C.O.s as it's the more important one anyways. Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.

Second: It would be helpful if we could assign an alternative commander specialty in the "Miscellaneous" tab of the class design window. For example, if I make a mining platform with a cargo bay to port a mass driver around, the game will treat it as a freighter and assign a Logistics commander instead of a Mining commander

Second one is a minor (heh) detail but the first one is in my opinion much-needed, being the primary reason I hesitate to click "Automated Assignments" even as my empire grows and I have to replace multiple retired or promoted commanders after every increment.

[Froggiest1982]

Commander auto-assign needs a couple of tweaks to be actually useful.

First: Some degree of allowance needs to be made for commanders to command a ship that they are technically overqualified for. Currently, the auto-assign will only assign a commander to a ship if they are exactly the minimum rank needed to command that ship. This is fine for warships where you have a few different classes and generally can designate one class to have Senior C.O.s as it's the more important one anyways. Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.

Second: It would be helpful if we could assign an alternative commander specialty in the "Miscellaneous" tab of the class design window. For example, if I make a mining platform with a cargo bay to port a mass driver around, the game will treat it as a freighter and assign a Logistics commander instead of a Mining commander

Second one is a minor (heh) detail but the first one is in my opinion much-needed, being the primary reason I hesitate to click "Automated Assignments" even as my empire grows and I have to replace multiple retired or promoted commanders after every increment.

I just dont understand 2 things:

1-Why we got rid of the minimum rank selection for ships in VB6.

2-Why the rank selection have been instead moved to the ground units and it is not even flexible!

During development I was very happy with the changes. When I saw suddenly the ground units I was skeptikal. After almost a year I am afraid I was right.

The ground unit changes are welcome and when they work they really add a nice extra layer. The problem is that they most likely going to break your game.

I am now more into DB managing editing though as it can help fixing these minor issues when you face them.

However, I think it focused Steve's mind on a less important part of the game leaving the the core a bit unfinished.

If you think we just got formations back and yet they still different and there was no much need to change it. Some solutions like escorts are awesome, but do I miss the feature of 1 unique survey fleet moving together, arriving in the system, split and survey? God yes! Or maybe there is and I could not make it work.

Mines, still not working and not even investigated.
Fighter Squadrons.
Galaxy map with no zoom.

These are just some of the things I miss.

Regardless the above I love C#, I support Steve and all I can do is keep playing and waiting faithfully for more things to be added. I like the change is doing on Fighters for instance from 1.13 on as I think they will allow for interesting RP games.

EDIT: I know the release was rushed to get Aurora out, just trying to understand how some things got prioritized over others. Obviously, without having no idea how the game is made I still want this to be read in a constructive way and without having any malicious intentions. Hence the last part.

[db48x]

Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.

Flexible ranks could be nice, but don't forget that you have two new tools now as well. The new command & control modules allow more than one officer per ship, and admin commands provide a bonus to more than one fleet at a time.

Survey officers should start their careers in a Science Department, then be promoted and have a shot at commanding a ship, and then when promoted again they should move into a regional admin command, then get promoted again and take over the whole survey operation for the western spiral arm and so on. Once in an admin command, they provide one quarter of their bonus to every ship in their department. As long as that's four or more ships, then they're using that bonus well. Once promoted again, they provide one sixteenth of their bonus to all the ships two levels down from them. Individually that's not a lot, but if it's spread out over 16 or more ships, then they're contributing just as much as they ever were. Even if you have fewer than 16 ships they'll still be beneficial.

With 16 survey ships you have enough room for four levels of promotions. There will be 16 captains that get promoted and will vie for the chance to run one of the four regional admin commands; you'll give the best four of them the job. Most of the others will retire early, or find jobs in other parts of your navy (since they might have or develop other skills too). The best of the four will end up running the whole survey operation. They could end up running the whole navy on their next promotion, if you decide that they've got enough non-survey skills built up by then.

There is one wrinkle, of course. The standing orders for moving to a system requiring survey do not appear to take into account the location of the admin command to which the ship is assigned. (Not that I've investigated the matter very thoroughly…) As far as I can tell, it just picks the system closest to where the ship is at the time. That will mostly work, but after returning to your capital for overhaul they'll probably end up in a system on the other side of the galaxy, where they won't be getting any bonuses from their admin command. The solution to this is either micromanagement or better logistics: give each region a facility capable of overhauling survey ships. That cuts down on travel times too.

[Kristover]

Couple of suggestions involving medals:

1. Could you add a condition for governors, sector governors, and academy commandants?  I realize it is minor and really for flavor but given that I'm one of those guys that LOVES the medals process, I wouldn't mind having some ability to auto-recognize those who get these posts. 

2.  Similar to systems, could you standardize a 1, 10, 25, 100 gradation for discovery of minerals and jump-points?  What I find is with auto-assignment, no commander is every going to get close to 1000 minerals discovery and almost none will ever get 100 minerals (I think I only had one reach 100 and that was one game I forgot to click auto assign commanders).  On the contrary, finding 3 JP for a single ship commander happens all of the time when I send a single long endurance ship to survey a system and thus doesn't feel like much of an accomplishment.  I think the 1, 10, 25, 100 level would be a better standard.

[nuclearslurpee]

Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.

Flexible ranks could be nice, but don't forget that you have two new tools now as well. The new command & control modules allow more than one officer per ship, and admin commands provide a bonus to more than one fleet at a time.

Survey officers should start their careers in a Science Department, then be promoted and have a shot at commanding a ship, and then when promoted again they should move into a regional admin command, then get promoted again and take over the whole survey operation for the western spiral arm and so on. Once in an admin command, they provide one quarter of their bonus to every ship in their department. As long as that's four or more ships, then they're using that bonus well. Once promoted again, they provide one sixteenth of their bonus to all the ships two levels down from them. Individually that's not a lot, but if it's spread out over 16 or more ships, then they're contributing just as much as they ever were. Even if you have fewer than 16 ships they'll still be beneficial.

With 16 survey ships you have enough room for four levels of promotions. There will be 16 captains that get promoted and will vie for the chance to run one of the four regional admin commands; you'll give the best four of them the job. Most of the others will retire early, or find jobs in other parts of your navy (since they might have or develop other skills too). The best of the four will end up running the whole survey operation. They could end up running the whole navy on their next promotion, if you decide that they've got enough non-survey skills built up by then.

I do something like this already, in fact my survey admin command structure is three layers deep (CDRE-RADM-VADM) assuming I have the officers for it, and I require science officers on all my survey ships (at least for TN start). The problem is just that CDR-CAPT split as I usually prefer to keep Captains (or other 3rd rank) as senior ship commanders and Commodores as the lowest level of admin command both for RP and ease of management.

Don't get me wrong, I certainly appreciate and make use of the new rank features in C# but I prefer those features as tools available to be used how I like, rather than as a constraint saying "you must play in this way" which the auto-assign very much feels like due to how it handles ranks. The feature as it stands to me feels more like a puzzle to be solved, i.e. how to design a fleet structure so that the auto-assign "works", rather than a helpful feature to reduce tedious micro-management.

Of course, manual assignment always works as long as you don't mind occasional RSI. 

There is one wrinkle, of course. The standing orders for moving to a system requiring survey do not appear to take into account the location of the admin command to which the ship is assigned. (Not that I've investigated the matter very thoroughly…) As far as I can tell, it just picks the system closest to where the ship is at the time. That will mostly work, but after returning to your capital for overhaul they'll probably end up in a system on the other side of the galaxy, where they won't be getting any bonuses from their admin command. The solution to this is either micromanagement or better logistics: give each region a facility capable of overhauling survey ships. That cuts down on travel times too.

I usually use the system map to manage this using the labels feature to track which system each ship is assigned to and plan out my surveying accordingly. Even with double-digit survey ships each one only needs new orders every couple of years so the micromanagement is minimal to accomplish balanced or directed exploration missions.

[swarm_sadist]

Reserving installations.

Currently, I am building Mass Drivers at an Industrial Planet, and shipping them out to the neighbouring Mining Worlds in the system. I want to keep 1 Mass Driver on the industrial planet, but going back and forth to set the supply manually is rather tedious.

I suggest:
1) Allowing you to set reserve levels for planets in the "Civilian Economy" tab, in the left-hand field. This could look like Mass Driver 3(1), with double clicking bringing up a field to change the reserve number. Your civilian cargo ships won't touch these.

2) Disable the alert for no supply, allowing you to have supply requests for non-existent installations. (I think this has been suggested already)

3) Have some installations have defaults, well, by default. Spaceport (1), Mass Driver (1), Naval Headquarters (1, mostly because you might get some weird errors if the HQ disappears)

4) Perhaps a floating default based on use. Ground Force Complex being used, Infrastructure supporting population, Research Labs in use, etc.

[db48x]

I do something like this already, in fact my survey admin command structure is three layers deep (CDRE-RADM-VADM) assuming I have the officers for it, and I require science officers on all my survey ships (at least for TN start). The problem is just that CDR-CAPT split as I usually prefer to keep Captains (or other 3rd rank) as senior ship commanders and Commodores as the lowest level of admin command both for RP and ease of management.

I see. I guess you could add Main Engineering to your survey ships too. Then you'd have the three lowest ranks on all of them, and the ship's commander would be a captain.

[nuclearslurpee]

I do something like this already, in fact my survey admin command structure is three layers deep (CDRE-RADM-VADM) assuming I have the officers for it, and I require science officers on all my survey ships (at least for TN start). The problem is just that CDR-CAPT split as I usually prefer to keep Captains (or other 3rd rank) as senior ship commanders and Commodores as the lowest level of admin command both for RP and ease of management.

I see. I guess you could add Main Engineering to your survey ships too. Then you'd have the three lowest ranks on all of them, and the ship's commander would be a captain.

That's certainly not the worst idea, though the Main Engineering isn't a Survey position so one rank of survey-skilled commanders missed out regardless, but that's probably fine as the LCDR rank is more of a training rank really.

That being said, I'd still appreciate at least the option for a more flexible auto-assignment. I use survey ships as the most vexing example personally, but this also applies to e.g. various industrial-type ship commands where I'd rather have my 50 Logistics/Mining commanders stay in command of a logistics or mining ship instead of promoting into command of a frigate or something. Plenty of other small examples, and as always there's ways to work with the system, but more flexibility and options is not a bad thing here is my main point.