Suggestions Thread for v2.0

[Elminster]

Make the "Events" checkbox on the main screen display tab checked by default.

The only time I don't check this is when I forget about it, until I wonder why there are no events shown. 

[Elminster]

Out of a given occasion...

on the "Industry" tab, move the "Cancel" button to the far right. 

[serger]

Filter out 0-bonus officers for the 1st bonus selected, to make the window usable with 1000s of officers.

[Droll]

Filter out 0-bonus officers for the 1st bonus selected, to make the window usable with 1000s of officers.

I've also suggested multiple times to change the default filtering to set the minimum rank to the highest rank and the maximum rank to the lowest rank so that by default the filter just doesn't run and take a whole minute just so I can assign CAP Noname Johnson to my new warship. This should be an incredibly simple change.

It's not like the default filtering is very helpful anyways - literally just sorts all the naval officers by crew training when most of the time I don't want that anyways.

[nuclearslurpee]

A quick check reveals that while I've noted this imbalance in several places, I've never made a suggestion thread post about it, so here goes:

Change the large logistics module (50-ton) to be LVH only (no INF) and give 1000 GSP instead of 500.

Rationale:

• There is currently no reason for INF to use the large LOG module instead of the small LOG-S module, as the latter means you have 5x as many units and therefore suffer a smaller loss of supplies when a logistics unit is killed. Therefore, nothing is lost by prohibiting INF from using the large LOG module.
• Currently, LVH logistics are almost strictly inferior to INF logistics, due to the mandatory 2 armor on a LVH unit. A LVH+LOG costs 2.48 BP per 500 GSP, while five INF+LOG-S cost 1.00 BP per 500 GSP. Given the cost to supply a ground force of multi-million tons over weeks to months of sustained ground combat, which is necessary for planetary invasions of home worlds and other heavily garrisoned planets, this cost difference is not sustainable.
• The advantage of LVH+LOG used to be automatic resupply of subordinate formations. However, since 1.12 and the Unit Series + Replacements mechanics, this is no longer necessary. A cursory element of INF+LOG-S in any combat formation enables resupply via unit replacement from a LOG-S supply dump formation in the rear echelon. Therefore, there is no longer a good justification for the excess cost of the LVH+LOG unit.
• Experience shows that the small loss rate of front-line INF+LOG-S units does not make up for this cost differential.
• With the proposed change, LVH+LOG will still be only about 80% as cost-efficient, due to the LVH tonnage overhead, but will be ~40% more tonnage-efficient as a means to deliver GSP. This ensures that both unit types have a suitable niche for different use cases - usually, build cost is the dominant strategic factor for ground forces, while tonnage is a critical tactical factor, e.g., when mounting an invasion with limited transport capacity.

Thank you for coming to my TED Talk.

SJW: Thanks for the analysis. Added to v2.2.

[ranger044]

A quick check reveals that while I've noted this imbalance in several places, I've never made a suggestion thread post about it, so here goes:

Change the large logistics module (50-ton) to be LVH only (no INF) and give 1000 GSP instead of 500.

Rationale:

• There is currently no reason for INF to use the large LOG module instead of the small LOG-S module, as the latter means you have 5x as many units and therefore suffer a smaller loss of supplies when a logistics unit is killed. Therefore, nothing is lost by prohibiting INF from using the large LOG module.
• Currently, LVH logistics are almost strictly inferior to INF logistics, due to the mandatory 2 armor on a LVH unit. A LVH+LOG costs 2.48 BP per 500 GSP, while five INF+LOG-S cost 1.00 BP per 500 GSP. Given the cost to supply a ground force of multi-million tons over weeks to months of sustained ground combat, which is necessary for planetary invasions of home worlds and other heavily garrisoned planets, this cost difference is not sustainable.
• The advantage of LVH+LOG used to be automatic resupply of subordinate formations. However, since 1.12 and the Unit Series + Replacements mechanics, this is no longer necessary. A cursory element of INF+LOG-S in any combat formation enables resupply via unit replacement from a LOG-S supply dump formation in the rear echelon. Therefore, there is no longer a good justification for the excess cost of the LVH+LOG unit.
• Experience shows that the small loss rate of front-line INF+LOG-S units does not make up for this cost differential.
• With the proposed change, LVH+LOG will still be only about 80% as cost-efficient, due to the LVH tonnage overhead, but will be ~40% more tonnage-efficient as a means to deliver GSP. This ensures that both unit types have a suitable niche for different use cases - usually, build cost is the dominant strategic factor for ground forces, while tonnage is a critical tactical factor, e.g., when mounting an invasion with limited transport capacity.

Thank you for coming to my TED Talk.

I would second this, currently the only reason I ever use LVH+LOG is for flavor. I like my "convoy" units to be, you know, a convoy of trucks. But my bigger and more planned out games always use INF+LOG-S and have for some time.

[Pedroig]

A quick check reveals that while I've noted this imbalance in several places, I've never made a suggestion thread post about it, so here goes:

Change the large logistics module (50-ton) to be LVH only (no INF) and give 1000 GSP instead of 500.

Rationale:

• There is currently no reason for INF to use the large LOG module instead of the small LOG-S module, as the latter means you have 5x as many units and therefore suffer a smaller loss of supplies when a logistics unit is killed. Therefore, nothing is lost by prohibiting INF from using the large LOG module.
• Currently, LVH logistics are almost strictly inferior to INF logistics, due to the mandatory 2 armor on a LVH unit. A LVH+LOG costs 2.48 BP per 500 GSP, while five INF+LOG-S cost 1.00 BP per 500 GSP. Given the cost to supply a ground force of multi-million tons over weeks to months of sustained ground combat, which is necessary for planetary invasions of home worlds and other heavily garrisoned planets, this cost difference is not sustainable.
• The advantage of LVH+LOG used to be automatic resupply of subordinate formations. However, since 1.12 and the Unit Series + Replacements mechanics, this is no longer necessary. A cursory element of INF+LOG-S in any combat formation enables resupply via unit replacement from a LOG-S supply dump formation in the rear echelon. Therefore, there is no longer a good justification for the excess cost of the LVH+LOG unit.
• Experience shows that the small loss rate of front-line INF+LOG-S units does not make up for this cost differential.
• With the proposed change, LVH+LOG will still be only about 80% as cost-efficient, due to the LVH tonnage overhead, but will be ~40% more tonnage-efficient as a means to deliver GSP. This ensures that both unit types have a suitable niche for different use cases - usually, build cost is the dominant strategic factor for ground forces, while tonnage is a critical tactical factor, e.g., when mounting an invasion with limited transport capacity.

Thank you for coming to my TED Talk.

I would second this, currently the only reason I ever use LVH+LOG is for flavor. I like my "convoy" units to be, you know, a convoy of trucks. But my bigger and more planned out games always use INF+LOG-S and have for some time.

Thirded!

I only use LVH+LOS for RP reasons to "keep up" with Armoured/Mechanized units and for Corps/Army Logisitics.  Mechanically, INF+LOG-S is superior in every way to LVH+LOG.

[Ush213]

Can a reserve limit for pops on colonies be added in.  Similar to minerals.  This way when colonies are set to source the civs won’t take more then the reserve.  I think it should stop the civs emptying colonies when players forget to remove source. 

[Foxxonius Augustus]

I would really appreciate an option to decrease the number of significant figures in hull sizes. I can't tell you the number of times I have been frustrated when designing a ship because my ship is 0.0009 hull size over a nice round number. I looked it up 0.0009 HS is about 100 kilos. It's like, just ditch the snack fridge and the spare toaster! If a ship is 0.1 or even 0.01 HS over a shipyard capacity or hanger space then fair enough, it's too big but 0.001 or 0.0001? Nah, that shouldn't even matter to a 500 ton fighter craft, let alone a 50,000 ton warship.

[nakorkren]

Since cargo bays and fuel tanks have Very Large versions which reduce the cost to build big ships of those types, would it be possible to get an equivalent "Very Large" cryogenics module, ark module, and troop transport module?

SJW: I've added larger versions of troop transport bays, troop transport drop bays and cryogenic transport modules. The Ark is already 500,000 tons, so it doesn't really need a 'large' version.

[Kinnas]

I'm finding that unless I manually manage the military appointments, there tend to be far too many low ranked people compared to the higher ranks.    With that in mind, I've got a couple of suggestions:

1.    Allow us to set the preferred ratio of officers per rank, with promotions and demotions occurring automatically according to promotion score (and respecting the 'do not promote' setting for either promotion or demotion') Perhaps setting a band that the numbers can fall within to limit promotion/demotion spam.  (I. e.  say you set a higher rank at 20%-30% of the lower rank, only promote someone if less than 20%, and only demote someone if >30%)

2.    Introduce a  brevet rank feature, have a setting for each rank for the preferred promotion score, and where there is a shortfall of higher ranked officers but no-one with sufficient promotion score for the next rank, give the most eligible person a temporary brevet rank until someone more qualified emerges.    (And obviously, any demotions required to meet the required rank populations should come first from brevet holders.   )

[nuclearslurpee]

I'm finding that unless I manually manage the military appointments, there tend to be far too many low ranked people compared to the higher ranks.    With that in mind, I've got a couple of suggestions:

This is because the promotion system was changed to an on-demand system in 2.0, due to the numerous challenges of a fixed rank ratio system. If you want more promotions to higher ranks, you need to create more higher-rank positions to be filled. Otherwise, there will not be automatic promotions if there is no job for the person being promoted to fill.

If you have too many low-ranked officers, you can either create higher-rank commands to encourage promotions (you can use the "Senior C.O." checkbox in ship design to help diversify your ranks) or use command modules (AUX, ENG, CIC, etc.) to give your low-rank officers more things to do.

Note that once you get to the flag officer ranks (CDRE/R4, RADM/R5 or so) this means you will have to create more admin commands at the appropriate level. Depending on your rank structures, this may mean having a finer-grained command structure or having "superfluous" commands for roleplay. One idea is to have NAV admin commands which prioritize Crew Training, Reaction, Engineering, or Tactical differently rather than just a general-purpose NAV command at each level. You can also play around with the range of the admin commands, e.g., you might have several SRV commands located in different systems to provide bonuses in several areas of operations.

[gpt3]

Would it be possible for Raiders to have some equivalent of jump shock?

I currently have a game where there is a wreck right next to a portal; I'm stuck in ~30 second intervals because the looters warp in, see my waiting battle fleet, and then immediately warp out.

[TMaekler]

When the game changes the orders of a fleet due to a primary or secondary condition fulfilled it ignores any already set order and wipes them clean.

I would love to have an option that does not clear the order list but adds the conditional order to the stack. At least if there is no cycle order present. With cycling orders, it might always be best to completely kill them. But with a list of orders, I would love to have the option to choose.

At least what the game should do is to check if there is already an order present of the same kind. I sometimes add a command to refuel and resupply if something breaks on a ship and the supply goes very low, but not below the limit I have set in the conditions. But during the flight back something else may break that puts the ship below the condition - and that overwrites my refuel and resupply command with just a resupply command. If there would be a check if a similar command is already present, would be awesome.

SJW: Movement Orders is a very complex area. There are 115 different order types, dozens of different pre-requisites attached to orders and many, many different situations in terms of prior orders and context. This is why orders are cleared in several different situations and you can't just edit orders or add orders in the middle. There would be a huge amount of work (and bugs) involved to try to deal with every possible situation.

[mike2R]

A minor irritation I run into is setting up order templates that involve tractoring newly built space stations.  When you tractor the last ship out of a fleet with Tractor Any Ship in Fleet, the fleet is disbanded.  The next space station built recreates the fleet, but it is a new fleet as far as any order template is concerned.  This means I can't simply create an order template for tractoring new fuel harvester stations or terraformer stations out to where I want them, and have to manually issue the orders each time.

The fleet disbanding behaviour seems desirable in most situations, but not when the fleet is the one that you build into.  I suggest changing this behaviour in the specific case where the fleet is in orbit of a population, and that population has the fleet selected as the target of space station builds in the Industrial panel (whether or not a space station is actually being built).  In this case, have the fleet remain, even if empty.

SJW: Added for v2.2: http://aurora2.pentarch.org/index.php?topic=13090.msg162184#msg162184