C# Suggestions

[nuclearslurpee]

Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.

This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.

I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.

Personally I do not mind the linear costs in general, though I don't usually play with very slow research speeds so that may color my perceptions. Certainly I would not object to a square-root reformulation although I think logarithmic is more problematic than is worth it.

However, I do think that a few small tweaks to specific component research costs would solve most of the big issues, aside from engines. Jump Drives for example actually scale as size^1.8 which is why large jump drives are so ridiculously expensive, and while they are a critical component I don't think having a prohibitive research cost adds anything to the game as the major opportunity cost is always the lost tonnage aboard any ship which carries one. The other big example is ground unit HQ elements which have horribly outsized research costs compared to every other ground element, this has been discussed numerous times. Simply bringing these components into line with the other components/elements in the game will solve a lot of problems without requiring a wholesale rebalancing of the tech tree - less work for Steve, but still many benefits for all of us I think.

[Jorgen_CAB]

Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.

This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.

I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.

Personally I do not mind the linear costs in general, though I don't usually play with very slow research speeds so that may color my perceptions. Certainly I would not object to a square-root reformulation although I think logarithmic is more problematic than is worth it.

However, I do think that a few small tweaks to specific component research costs would solve most of the big issues, aside from engines. Jump Drives for example actually scale as size^1.8 which is why large jump drives are so ridiculously expensive, and while they are a critical component I don't think having a prohibitive research cost adds anything to the game as the major opportunity cost is always the lost tonnage aboard any ship which carries one. The other big example is ground unit HQ elements which have horribly outsized research costs compared to every other ground element, this has been discussed numerous times. Simply bringing these components into line with the other components/elements in the game will solve a lot of problems without requiring a wholesale rebalancing of the tech tree - less work for Steve, but still many benefits for all of us I think.

Yes... although I think Jump Drives is a good example on a research path that I like as it is not linear for a reason, this work really well.

For engines I generally just think that small engines should be more expensive and really big engines a bit less expensive. Larger engines are not that good for their cost in research most of the time.

For sensors I definitely want really small sensors to be more expensive because small sensors are very effective now and really large sensors are prohibitively expensive for what they are worth, especially in terms of research. An active sensor larger than size five I generally find to be very expensive for what you can do with it.

Sure... I almost always play with 10-20% tech rate so differences in tech cost are quit significant.

[liveware]

Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.

This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.

I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.

Personally I do not mind the linear costs in general, though I don't usually play with very slow research speeds so that may color my perceptions. Certainly I would not object to a square-root reformulation although I think logarithmic is more problematic than is worth it.

However, I do think that a few small tweaks to specific component research costs would solve most of the big issues, aside from engines. Jump Drives for example actually scale as size^1.8 which is why large jump drives are so ridiculously expensive, and while they are a critical component I don't think having a prohibitive research cost adds anything to the game as the major opportunity cost is always the lost tonnage aboard any ship which carries one. The other big example is ground unit HQ elements which have horribly outsized research costs compared to every other ground element, this has been discussed numerous times. Simply bringing these components into line with the other components/elements in the game will solve a lot of problems without requiring a wholesale rebalancing of the tech tree - less work for Steve, but still many benefits for all of us I think.

Yes... although I think Jump Drives is a good example on a research path that I like as it is not linear for a reason, this work really well.

For engines I generally just think that small engines should be more expensive and really big engines a bit less expensive. Larger engines are not that good for their cost in research most of the time.

For sensors I definitely want really small sensors to be more expensive because small sensors are very effective now and really large sensors are prohibitively expensive for what they are worth, especially in terms of research. An active sensor larger than size five I generally find to be very expensive for what you can do with it.

Sure... I almost always play with 10-20% tech rate so differences in tech cost are quit significant.

Most of what you are talking about could be solved using a RP=SQRT(size) methodology (i.e. small things are relatively expensive and big things are less so). This has the advantage of being simple and not terribly different the the current implementation.

If you wanted to make things REALLY interesting, I would suggest using a variation of RP = e^(size)*(sin(2*pi*size)+size). See here for plot of this function: https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29

This would make successive generations of research proceed in a rather nonlinear fashion, however later generations of research would be dramatically more expensive (and presumably better) than early generations. However successive generations of research would not be linearly 'better' or more expensive than previous generations.

NOTE: You could wrap the aforementioned RP='a bunch of math' thing in a SQRT function also, but that introduces some divide-by-zero singularities. These can be avoided by careful choice of RP values but I didn't want to go off the deep end on that tangent. An interesting variation is RP = sqrt(e^(size))*(sin(2*pi*size)+size)

[nuclearslurpee]

Most of what you are talking about could be solved using a RP=SQRT(size) methodology (i.e. small things are relatively expensive and big things are less so). This has the advantage of being simple and not terribly different the the current implementation.

If you wanted to make things REALLY interesting, I would suggest using a variation of RP = e^(size)*(sin(2*pi*size)+size). See here for plot of this function: https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29

This would make successive generations of research proceed in a rather nonlinear fashion, however later generations of research would be dramatically more expensive (and presumably better) than early generations. However successive generations of research would not be linearly 'better' or more expensive than previous generations.

NOTE: You could wrap the aforementioned RP='a bunch of math' thing in a SQRT function also, but that introduces some divide-by-zero singularities. These can be avoided by careful choice of RP values but I didn't want to go off the deep end on that tangent. An interesting variation is RP = sqrt(e^(size))*(sin(2*pi*size)+size)

I generally don't like the idea of using logs, exponentials, or anything else transcendental to determine RP as a function of size (or another size-like parameter depending on the tech under discussion). From the player-facing side they are just not intuitive or easy to noodle around in your head. Linear of course is very simple. SQRT is a bit more complicated but still simple enough to do head math - if I make an engine 4x as large it will cost 2x the RP, easy enough. With LOG, EXP, etc. there is no easy way to think of it mentally, while simple rational functions can be reasoned with.

From the developer side it is also quite difficult to balance these functions across a very wide range of sizes, tech levels, and so on. LOG in particular is difficult because it has a sharp drop to negative infinity near zero, a fairly small useful region of variation, and then for large arguments it barely changes even for wide differences in size. It is also a problem I think that whatever balance "fit" you use will work only for the existing data set, so to speak - if Steve decided for example to increase maximum engine or sensor size all component research costs would need to be redone. Something like SQRT doesn't really need to be fitted as it behaves the same over the entire range as long as you can't go to zero which is generally true for components.

[TheTalkingMeowth]

LOG in particular is difficult because it has a sharp drop to negative infinity near zero

No matter the field, if you think about it hard enough you end up doing calculus.

This pleases me.

[liveware]

Most of what you are talking about could be solved using a RP=SQRT(size) methodology (i.e. small things are relatively expensive and big things are less so). This has the advantage of being simple and not terribly different the the current implementation.

If you wanted to make things REALLY interesting, I would suggest using a variation of RP = e^(size)*(sin(2*pi*size)+size). See here for plot of this function: https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29

This would make successive generations of research proceed in a rather nonlinear fashion, however later generations of research would be dramatically more expensive (and presumably better) than early generations. However successive generations of research would not be linearly 'better' or more expensive than previous generations.

NOTE: You could wrap the aforementioned RP='a bunch of math' thing in a SQRT function also, but that introduces some divide-by-zero singularities. These can be avoided by careful choice of RP values but I didn't want to go off the deep end on that tangent. An interesting variation is RP = sqrt(e^(size))*(sin(2*pi*size)+size)

I generally don't like the idea of using logs, exponentials, or anything else transcendental to determine RP as a function of size (or another size-like parameter depending on the tech under discussion). From the player-facing side they are just not intuitive or easy to noodle around in your head. Linear of course is very simple. SQRT is a bit more complicated but still simple enough to do head math - if I make an engine 4x as large it will cost 2x the RP, easy enough. With LOG, EXP, etc. there is no easy way to think of it mentally, while simple rational functions can be reasoned with.

From the developer side it is also quite difficult to balance these functions across a very wide range of sizes, tech levels, and so on. LOG in particular is difficult because it has a sharp drop to negative infinity near zero, a fairly small useful region of variation, and then for large arguments it barely changes even for wide differences in size. It is also a problem I think that whatever balance "fit" you use will work only for the existing data set, so to speak - if Steve decided for example to increase maximum engine or sensor size all component research costs would need to be redone. Something like SQRT doesn't really need to be fitted as it behaves the same over the entire range as long as you can't go to zero which is generally true for components.

Maybe I went a little overboard. RP=SQRT(size) is good enough for me.

[liveware]

LOG in particular is difficult because it has a sharp drop to negative infinity near zero

No matter the field, if you think about it hard enough you end up doing calculus.

This pleases me.

But this would be better :-)

[Desdinova]

With this update being pretty fighter-focused, could we get the crew requirements once again scaled with deployment time as in VB6, so that fighters with deployment times measured in hours don't have like 30 crew members and the associated habitation space requirements?

[Steve Walmsley]

With this update being pretty fighter-focused, could we get the crew requirements once again scaled with deployment time as in VB6, so that fighters with deployment times measured in hours don't have like 30 crew members and the associated habitation space requirements?

It is already scaled with deployment time.

Accommodation = Personnel * (Planned Deployment ^ (1/3));

[kilo]

Is it possible to change the way sensors and fire control systems work for STOs? Right now you can choose between range x4 speed x1 or vice versa. This is pretty restrictive. On top of that you have to use a single weapon beam fire control and cannot develop fire controls for a battery of guns.
These single weapon beam fire control restriction can even lead to situations in which the fire control + sensor is more expensive than it's carronade.

[nuclearslurpee]

Is it possible to change the way sensors and fire control systems work for STOs? Right now you can choose between range x4 speed x1 or vice versa. This is pretty restrictive. On top of that you have to use a single weapon beam fire control and cannot develop fire controls for a battery of guns.

I would suggest that the restricted nature is a balance concern as much as anything. STOs are already quite strong due to their +25% range boost and benefitting from fortification level. The current restrictive STO fire controls allow you to build either a long-range anti-ship weapon which is limited by racial tracking speed (probably reducing accuracy by 25% to 50% depending on your tech and the enemy fleet speed), or a short-range PD weapon. Both have limitations which helps keep STOs from completely outclassing orbital platforms for example.

These single weapon beam fire control restriction can even lead to situations in which the fire control + sensor is more expensive than it's carronade.

Carronades are supposed to be quite cheap so this isn't necessarily a problem. Same applies for e.g. 10cm railguns although those make quite poor STOs due to lack of turret.

[Polestar]

I'm loving the changes in 1.13 for ground formations, some of the juiciest bits in what's going to be an especially heavy-hitting Aurora update. In fact, they are so juicy as to give me hope that a few other issues might be considered sooner rather than later.

1. As of fairly recently, ground commanders didn't apply any bonuses to any subordinate formations. [ed: to make it clear, this is not a bug report, merely one of an unimplemented feature] So there's never been much point - aside from role-play - to building a 250k HQ, whether the research cost be 5k or 1.5k, because such a large HQ provides only (expensive) automatic supply distribution and mouse-click reduction. More than anything else, I hope that 1.13 lets us field ground formation hierarchies that actually provide bonuses.

2. Large HQs continue to be extremely expensive to build. Even when fully hierarchical commander bonuses are implemented, we'll still face the problem that, in order to actually field a formation hierarchy, we have to pay for HQs at every level of command, and we still have to up-armor or duplicate HQs, at every level, in order to avoid losing commanders in battle. Once bonuses from superior commanders are implemented, we will also have to avoid breaking the chain of command at any level and thus lose those bonuses. This gets pricey, fast. So, request to either make HQs (especially large ones) a lot less expensive to build, or make them much less like to be targeted and destroyed in battle, or both.

A more radical suggestion would be to remove the HQ type altogether and have the assigned officer, plus (in higher-level formations) a number of generic officers taken from the national pool to serve as staff, provide both the command span and the command bonuses. If the formation type is too small to be commanded by an officer of the lowest rank modeled by the game (by default, a major), and an officer has not been directly assigned anyway, then the simplest thing to do is to just check to see if that formation is in a hierarchy, find the lowest-ranking officer in direct line of command, and apply that officer's full bonuses, treating that officer as though they were also in direct command of each subordinate formation.

This would - finally - get players what many of us keep trying to do: include formations below the size commanded by a major - squads, platoons, and companies - and do so without gimping their battle effectiveness.


3. Aurora 1.13 is going to make some great game balance changes, and so perhaps a few more might be added to those considered:
3a. Several players have requested that heavy weapons get better at targeting suitable opponents. I heartily second these requests for both logical and game balance reasons.
3b. Heavy A isn't only more flexible than light AA, it is also considerably more cost-effective. It kills more fighters per unit cost and unit size. I propose that it should instead be somewhat less cost-effective, and light AA be especially cost-effective for defending a particular formation from air attack.
3c. Infantry armor is a really good buy at present (assuming armor tech is at least equal to the opposition's weapon tech). Consider increasing the cost a little bit, or applying a small disadvantage.

4. Turning to quality of life issues, I'm very glad that managing large numbers of similar formations (of a given template) is to get easier in 1.13. Another change I'd love to see is the ability to set a default field position for each formation template.

5. Finally, turning to the "gotchas" that the current ground formation system sets up for unwary players, I'll make a plea to consider these:
5a. Artillery only fires if the formation it is in is set to support another formation [I think this is still true - apologies if not]. Artillery should fire in any case, or at least it should be clearly indicated that, unless the player does something, it will not fire.
5b. The "Avoid Combat" checkbox is always waiting to trip you up. Do not apply it to AA or artillery; they will both hit in all forms of combat much less often. Request: please remove the "Avoid Combat checkbox and always apply it to, and only to, the appropriate unit types.
5c. Morale bonuses disappear on the next build phase if the formation's commander lacks sufficient Training bonuses. This plays very poorly with automated assignments! Request: please either change the name of this bonus, or have unit morale decrease far more slowly. If the second option is decided on, then I would recommend reducing the power of this bonus by roughly half, because at present it is - as long as the commanding officer is not replaced - considerably more powerful than either Offense or Defence (as it affects both chance to hit and chance to be hit).


Many thanks, Steve, for your continuous improvement of your masterwork. With every version of Aurora 4X and Aurora C#, your ability to recreate Warhammer 40K and other cosmos has becomes more and more impressive, and I've been glad to ride along!

[Desdinova]

It'd be really nice to have industrial command & control modules for terraforming and mining ships, call it a "mining control center" or something. As it is, you either leave miner and terraformer commands to junior officers, who have a very high turnover, or have to micromanage by manually promoting officers with high mining & terraforming bonuses.

[nuclearslurpee]

This would - finally - get players what many of us keep trying to do: include formations below the size commanded by a major - squads, platoons, and companies - and do so without gimping their battle effectiveness.

I love 95% of this comment, but I do want to point out that this suggested change will not really make sub-company size formations much more viable. The major limits on formation size are those due to micromanagement (nothing to be done, sadly, unless we get the feature to build hierarchies which I doubt) and breakthrough mechanics - very small formations simply break too easily allowing a larger opposing formation extra chances to deal bonus damage.

3c. Infantry armor is a really good buy at present (assuming armor tech is at least equal to the opposition's weapon tech). Consider increasing the cost a little bit, or applying a small disadvantage.

Power armor is quite good but I'm not sure it needs any nerf. The advantages of light armored units (LVH/STA) are plentiful enough compared to infantry - more HP than even gene modded infantry, ability to mount medium-size weapons, and better exploitation/breakthrough chance to name a few. Later in the game INF with full armor and HP mods is more tonnage-efficient in many cases but also much more expensive per ton due to the cost multiplier of HP mods, so I think the balance is still there.

5b. The "Avoid Combat" checkbox is always waiting to trip you up. Do not apply it to AA or artillery; they will both hit in all forms of combat much less often. Request: please remove the "Avoid Combat checkbox and always apply it to, and only to, the appropriate unit types.

I suspect this is done manually mainly as there's not always a clear answer as to what type an element "should" be. For example a command tank with HQ+AV could be set to avoid combat to keep the HQ alive, or not to bring another gun to bear. However I think a useful compromise would be if the checkbox is only available if an element would contain a non-combat weapon (HQ, LOG, FFD, etc.) as this avoids confusion for units with artillery, AA, etc.

It'd be really nice to have industrial command & control modules for terraforming and mining ships, call it a "mining control center" or something. As it is, you either leave miner and terraformer commands to junior officers, who have a very high turnover, or have to micromanage by manually promoting officers with high mining & terraforming bonuses.

Would this work like the command modules for ships already in the game? If so I don't think this solves the problem, since commander turnover will still happen and the only change is to what position a commander is assigned.

[liveware]

It'd be really nice to have industrial command & control modules for terraforming and mining ships, call it a "mining control center" or something. As it is, you either leave miner and terraformer commands to junior officers, who have a very high turnover, or have to micromanage by manually promoting officers with high mining & terraforming bonuses.

What I do is stick mining/terraforming platforms in a separate industrial admin command. You don't get the auto-assign niceness but keeping admin commands stocked with good commanders isn't a huge burden really. I also usually build a huge number of mining/terraforming platforms (if I build them at all) in which case having a junior officer on each on is usually not practical.

For example I would set up an admin command like "Venus Orbital Terraforming Complex" and would then assign something like 25 terraforming space stations to it. The admin command gets a commander, but the space stations usually don't because there are too many for my academies to keep up with. I prioritize keeping my military ships fully staffed with commanders so if the commercial sector falls by the wayside I don't worry too much about it.