I would love a second pass on the ground combat mechanics, especially an overview of air combat is certainly needed.
The one other thing I would like is some sort of combat width system so you can't engage with ALL of your forces against a much smaller force.
Create (or allow stabilization of) LaGrange points for secondary stars in a system. They are created for super-jovians automatically so should logically be created for dwarf stars as well.
Both flag bridge and sector governors are still not part of the automatic assignment system. Can we please get these added into it? :)
Unfortunately, this isn't the case. Flag bridge adds a new position called flag officer. It remains unassigned even when there are plenty of unassigned people in the rank. Senior CO is what you are thinking of, which makes everything +1 rank.Both flag bridge and sector governors are still not part of the automatic assignment system. Can we please get these added into it? :)
I thought Flag bridges were included since all they do is increase the command level of the ship
Unfortunately, this isn't the case. Flag bridge adds a new position called flag officer. It remains unassigned even when there are plenty of unassigned people in the rank. Senior CO is what you are thinking of, which makes everything +1 rank.Both flag bridge and sector governors are still not part of the automatic assignment system. Can we please get these added into it? :)
I thought Flag bridges were included since all they do is increase the command level of the ship
I don't know if it is possible, since i think units are just "deleted" when they are killed, though it might be possible to add an extra "saving throw" if they are killed and if they pass that they are kept around.
1. Triage Technology: Each level increases the amount of casualties returned to their units after battle and increases the chances of officers and crew escaping from ships alive. Also reduces the chances of officers being killed in accidents.
2. Healthcare Technology: Increases the lifespan of your leaders and reduces the chances they develop health issues.
3. Medical Technology: Increases the population growth rate.
More Complex Additions
4. Viral Agents: An alternative to using missiles or beam weapons to clear out an enemy planet. Viral Agents are launched from specialized bomb-bays requiring the ship to be in orbit of the target, causing no damage on their own but introducing a viral agent that will slowly (relative to bombardment) clear out the planet population and garrison without damaging the planet or infrastructure. Viral Agents are designed in the component designer and each agent needs to be custom made for each species you encounter, with the option to do so presenting after you conduct an autopsy. Using viral agents have a serious effect on you relations with any empires in contact with you or the target. Viral Agents would have two components; Viral Agent Potency, and Viral Agent Target (both researched in Biology).
5. More options to upgrade infantry genetic enchantments. It could be split into three different upgrades; Health, Stamina, and Reflexes. Health increases health, much like the existing enchantments do now. Stamina increases the shots they can take per turn (they don't have to rest as often). Reflexes increases the damage done per shot to reflect better accuracy.
I would love a note pad function linked the system currently open in the system view, so I can leave notes about what I am doing in that system. I have no idea how much of an ask this would be though.
I would love a second pass on the ground combat mechanics, especially an overview of air combat is certainly needed.
Seconded.QuoteThe one other thing I would like is some sort of combat width system so you can't engage with ALL of your forces against a much smaller force.
I think a "combat width" system would have some problems, frankly a much smaller force should be surrounded and annihilated not allowed to hole up and take out the enemy peacemeal. It would create a metagame where heavy armor (either vehicle or IFN power armor) is dominant against anything lighter - if a formation of 12-armor tanks is limited to only fight up to 3x its size you can see the problem readily.
What I would like to see, though, is that formations which fire at each other have a good chance to (1) continue firing at each other in successive rounds and (2) fire back at each other defensively. This would not have a significant mechanical effect (at least on average, there would probably be a lot more variance though), but would be great for writing combat narratives if, say, the 153rd Regiment attacks an enemy tank formation at dawn and continues ambushing them throughout the day instead of randomly shooting at an enemy infantry platoon in the next increment.Create (or allow stabilization of) LaGrange points for secondary stars in a system. They are created for super-jovians automatically so should logically be created for dwarf stars as well.
I'm not sure this would have a lot of use, as the LPs in Aurora do not save any distance traveled to a distant body due to the 60-degree offset. LPs are most useful for traveling between the planetary systems of different components and sometime shortening the distance between JPs when the LPs line up fortuitously.
I think a "combat width" system would have some problems, frankly a much smaller force should be surrounded and annihilated not allowed to hole up and take out the enemy peacemeal. It would create a metagame where heavy armor (either vehicle or IFN power armor) is dominant against anything lighter - if a formation of 12-armor tanks is limited to only fight up to 3x its size you can see the problem readily.
I don't agree that it needs to be a problem, first of all it would be more realistic... it certainly is not realistic that 100.000 soldiers can engage 1000 at the same time. It just would mean that defending can delay a bit more... but it would also be combined with the concept of defending the colony or the entire planet.
There would be a slight advantage to high quality troops and technology, but I would not call that an issue... just a change from how it is now. You also could tailor your shock forces, artillery would probably be more important as it would be granted special powers, such count for less size on their attacks etc... air combat (especially if fixed) would also have a bigger impact.
I think a "combat width" system would have some problems, frankly a much smaller force should be surrounded and annihilated not allowed to hole up and take out the enemy peacemeal. It would create a metagame where heavy armor (either vehicle or IFN power armor) is dominant against anything lighter - if a formation of 12-armor tanks is limited to only fight up to 3x its size you can see the problem readily.
I don't agree that it needs to be a problem, first of all it would be more realistic... it certainly is not realistic that 100.000 soldiers can engage 1000 at the same time. It just would mean that defending can delay a bit more... but it would also be combined with the concept of defending the colony or the entire planet.
While maybe not realistic, I don't think making the 100,000 vs 1,000 matchup more fair is terribly important for good gameplay. It reminds me, for example, of playing multiplayer in old RTSs like Age of Empires where your opponent would hide his last villager in a map corner and force you to spend 30 minutes hunting him down to win the game. At some point, mechanically it makes sense to allow a bit of unrealism for the sake of wrapping up the battle.QuoteThere would be a slight advantage to high quality troops and technology, but I would not call that an issue... just a change from how it is now. You also could tailor your shock forces, artillery would probably be more important as it would be granted special powers, such count for less size on their attacks etc... air combat (especially if fixed) would also have a bigger impact.
The advantage would be more than slight. With unit costs being balanced as they are now, a 12-armor UHV formation which costs 12x as much as 1-armor infantry is expected to be roughly equivalent to 12 of those infantry formations of the same size, assuming some reasonable distribution of weapon types of course. So if the combat width is, for sake of example, 3x the targeted formation size, only three of those 1-armor infantry formations can engage the 12-armor UHV formation at once. While one might think at first glance that, okay fine, so we send 12 infantry regiments and they just take longer to fight to mutual destruction, but in fact due to the way combat works the UHV will be able to sit and tank the fire of far more than 12 infantry regiments with this mechanic (if you expect the first 3 INF regiments to do 25% damage to the UHV, in fact they will do more like 6% before being wiped out due to square law scaling of combat power with numbers). Therefore, you create a system by game mechanics alone which incentivizes heavy armor and/or HP upgrades as the exclusive optimal point by a huge degree.
While the current ground combat is imperfect and has a fairly obvious metagame (CAP spam), this is not enforced by the mechanics, rather by a combination of NPR army design being infantry-heavy and the values in the DB which are readily tweaked even if finding a good rebalance is not straightforward. I think this is strongly preferable to a state where the game mechanics force an optimal strategy.
It's always tricky to discuss "balance" in Aurora, but I think most can agree that we do not demand perfect metagame balance but simply that many options are viable and even if some are stronger than others on average there are interesting gameplay decisions to be made. Often the tactically-optimal solution is not the best in grand strategic terms for example. The implications of a size-based stacking width system would violate this concept of balance, IMO - and it is not so easy to find a better basis for stacking width, for example a cost basis heavily penalizes special forces types of units, which are IMO already a bit less than optimal on average and so are not in need of such a harsh nerf. Similarly, what factor should the combat width be? If we say, okay, let's avoid the armor problem by making it 12x size, then 120,000 soldiers can assault 10,000 with no hindrance, so have we really made any change to the game on a practical level?
snip
snip
I think we must agree to disagree, the points have been presented and as always the decision rests with Steve. I think it is clear we play the same game very differently and that influences our respective ideas here. :)
Though I will say... I do not think it is bad if ground combat is mathematically predictable. For roleplay it might not be every player's ideal, enamored as we are with the idea of a small group of holdouts outlasting the siege until the cavalry arrives. However, strategically it is good to have a predictable outcome to decisions made t an extent, so that the player is rewarded for making decisions and the balance hangs on the decisions of both factions leading to the moment rather than balanced on mechanical edge cases. At the strategic scale ground combat is a game of numbers and technology with some influence of reasonable capability choices, frankly the mechanics are not tactical and I think that is fitting for Aurora.
Defending anything with anything really armoured is a waste of resources from a pure math perspective.
Currently you can turn on/off display of planets, asteroids, moons, etc as well as their names and orbits on the tactical screen, but not comets/comet names for some reason. I would like to be able to declutter the display of Sol, which has a ton of comets.
Can we get Commander Health notifications separated into two different notifications?
1) Medical problems
2) Deaths
Medical problems that don't inspire retirement or cause death are not as critical as ones that do. I need to know when my officers have left my service, not so much when they're feeling poorly.
Can we get Commander Health notifications separated into two different notifications?
1) Medical problems
2) Deaths
Medical problems that don't inspire retirement or cause death are not as critical as ones that do. I need to know when my officers have left my service, not so much when they're feeling poorly.
This! Even better would be to make retirements separate between "Was filling a role and retired" vs "Was on the roster but not currently assigned", because as stated above I only really care if it left a role open.
On a related note, would it be possible to have a monthly and an annual summary of vacant positions? That way you could suppress the monthly if you don't care to review it that often. And you could safely suppress all of the medical and death messages, since you would find out fairly soon (within a month or a year) that the position was open, or sooner if they were actively researching something, since you'd get an Open Labs message.
Defending anything with anything really armoured is a waste of resources from a pure math perspective.
I'm very curious how this is true from a pure math perspective. I do agree that armor is modestly less than optimal, but not on mathematical grounds as far as I know.
Cost of armored units scales linearly with armor, but the effectiveness of that armor scales quadratically until overmatch occurs. This works out on a theoretical basis to a perfect balance, because the effectiveness of numerical advantage is also quadratic, but the number of units one can field scales inversely with the cost - armor efficiency goes up as cost^2, numerical efficiency drops as 1/cost^2, and it all cancels out. The disadvantage of armor occurs on a practical basis due to overmatch mechanics (both for armored and unarmored units), but at this point you get into decision-based effects which cannot really be modeled - if the enemy fields more LAV/MAV, infantry are preferable, but too much infantry and the enemy is free to field CAP spam which is countered by armor. The true optimum is not mathematically trivial.
I will readily concede that none of this is relevant against NPRs, but against NPRs a wet mop is as good as a battle tank.Currently you can turn on/off display of planets, asteroids, moons, etc as well as their names and orbits on the tactical screen, but not comets/comet names for some reason. I would like to be able to declutter the display of Sol, which has a ton of comets.
Yes please.
I've asked for improvements to loading of ground units onto ships before, but I think I came up with a better way to manage it that would have prevented the half hour I just spent mindlessly clicking through 200 boarding shuttles to load 200 marine units to go defend against raider ships.
Allow ship classes to specify a template for military unit contained, and then add a command to "Load a Ground Unit per template" (as opposed to the current "Load Ground Unit" which forces you to pick which ground unit you want. That way troops would be handled much like ordinance and fighters are in the class design window, could even be under the ordinance tab and just update the title to "Loadout" or something like that.
Please please please! I really want boarding shuttles (and boarding combat in general) to be a viable strategy, and I think tactically it is, but right now it's a huge tedious slog due to micro.
In the Naval Organization window, the Logistics Report tab must be refreshed by hand, to show an updated situation.
Is it the intended behaviour?
SJW: Working as intended. If every tab of every open window was continually updated, it would slow the game down considerably.
The ability to award medals to ships, or edit their history tab. I really like to build up history of my ships particularly which battles they were a part of. But I can only award medals to officers of those ships, not the vessel it self. I can't edit its history to include some information about it either (If one can do it, please tell me how, I don't see any edit button to do so)
The ability to award medals to ships, or edit their history tab. I really like to build up history of my ships particularly which battles they were a part of. But I can only award medals to officers of those ships, not the vessel it self. I can't edit its history to include some information about it either (If one can do it, please tell me how, I don't see any edit button to do so)
Instead of medals they should be called service stars. I believe the USN does this for their ships.
The ability to award medals to ships, or edit their history tab. I really like to build up history of my ships particularly which battles they were a part of. But I can only award medals to officers of those ships, not the vessel it self. I can't edit its history to include some information about it either (If one can do it, please tell me how, I don't see any edit button to do so)
If there's a fuel hub stationed at a DSP, it would be nice if the "refuel from/transfer fuel to Hub" actions were listed at the DSP, so that you don't have to specifically target the fleet the hub is contained in.
The ship would move to the DSP, then upon arrival look for a hub that is stationed there.If there's a fuel hub stationed at a DSP, it would be nice if the "refuel from/transfer fuel to Hub" actions were listed at the DSP, so that you don't have to specifically target the fleet the hub is contained in.
What do you suggest happens if there are multiple hubs in different fleets at that location? One might be temporarily station or passing by, as rare a case that might be.
The ability to award medals to ships, or edit their history tab. I really like to build up history of my ships particularly which battles they were a part of. But I can only award medals to officers of those ships, not the vessel it self. I can't edit its history to include some information about it either (If one can do it, please tell me how, I don't see any edit button to do so)
I like the idea, but what would happen mechanically? The medals currently go to the officer's promotion score. Ships don't have that. What would you propose it do?
Mines.Mines already exist, and iirc are no longer bugged. Make a two-stage missile with one or more sensors and no engine as a first stage, and one or more missiles as a second stage.
- Mines as a variant of a missile whose engine is dormant at the start.
- Mines. Just like missiles with Active sensors but will act when an enemy ship is detected (like 10k km at start and 500k at top tech).
- Minelayer module (or the ability of a missile launcher during design, more effective than a missile launcher).
- Minesweeper module (the module that can sweep enemy or friendly mines or probes if its neutralization range is greater than mine detection range).
- Mines that can be launched as a two-stage missile or as a mine.
Mines.Mines already exist, and iirc are no longer bugged. Make a two-stage missile with one or more sensors and no engine as a first stage, and one or more missiles as a second stage.
- Mines as a variant of a missile whose engine is dormant at the start.
- Mines. Just like missiles with Active sensors but will act when an enemy ship is detected (like 10k km at start and 500k at top tech).
- Minelayer module (or the ability of a missile launcher during design, more effective than a missile launcher).
- Minesweeper module (the module that can sweep enemy or friendly mines or probes if its neutralization range is greater than mine detection range).
- Mines that can be launched as a two-stage missile or as a mine.
Currently commanders are DNR (Do Not Retain) by default when they retire/die. While keeping them all would probably bloat the DB unnecessarily, what about having DNR disabled when they have certain medals, configurable from the medals screen?
Technically, you CAN attack their home system, sorta. If you board a vessel of theirs that then retreats and is captured in that system, you are free to do whatever you like there. Good luck...Steve also stated that their system doesn't really serve a practical purpose in terms of production or having a functional colony at all if I remember correctly. Even if you somehow managed to glass their planet, the ships are spawned in via script, so what Zeebie fears might be correct: There is likely an infinite and regular number of them. (and killing will only stall them)
The fact that this is the first non-npr threat that can research doesn't lie well with me either through this. They are the only ones you can never shut down, and they will always improve? It really does sound quite bothersome, which is a shame, because otherwise I like their idea.
Now, if there were more instances of this race that could spawn, kind of how remnants could be considered their own local faction in each system they are in, that I would welcome. A new raider clan once in a while to keep the game interesting, that sounds nice to me.
The same invincible and improving threat all the time however seems to take away control from the player, which is not good for sandbox. I will test how I can edit them in database to see if they can be 'defeated' there after some time. If that doesn't work, I would probably deactivate them pending further player reports.
Spoiler for Rahkas rant:
The problem I have with stuff like Rakhas for example spawning an instance for every planet is that after a while you can get clutter in the intel screen of all these dead races. It also is a bit redundant and unnecessary for the Rakhas to have an instance per planet as due to their nature they will never interact with other Rakhas and have very simple and uniform foreign policy regarding NPRs and player races.
But I digress
Spoiler for my Raider rework:
I actually really support the idea of there being a % chance for a system that you first explore to be declared a raider system where they have a colony and basic infrastructure. You could then add a special raider-only component to their ships that allows them to partially circumvent the JP network by allowing them spool up this component and enter anywhere on the outskirts of any system connected to their current system through JPs. This component would probably have a decently sizeable cooldown so it can't be spammed and not be mutually exclusive with the existing jump drives, allowing the raiders to also use JPs like everyone else, maybe as a desperate escape attempt.
This means that you can predict where the pirates will appear/travel through based on where their system(s) are but not completely be able to stop them through JP blockades. Giving the player the choice either escort everything, or build surveillance on problem frontier systems to spot entering pirates and remove them before they move deeper into your territory, allowing you to maybe not escort absolutely all civilian traffic in the core of your empire.
Under this rework, you would be able to have multiple Raider systems each emanating an aura of piracy around them from different directions, with the colony in the raider system (would be cool if they were the new DSPs so that even otherwise empty systems are candidates) producing a set amount of resources (+ whatever is looted) and with certain shipyard capacity producing new problems until dealt with. It might be a good idea to give the raiders strong static defenses for their colonies/defensive fleets so that the player needs to assemble some force to remove them, possibly different colony sizes for the raiders too for varying severity.
I might repost this to the suggestions thread if it finds popularity here but I really do think these new Raiders would fit the "no exceptions" philosophy of C# much better than "there is a magic system you can never legitimately access".
Suggestion: Add a separate tech line to upgrade ground unit racial attack.
Rationale: Currently, GU racial attack is improved by the "caliber" tech for Lasers, Railguns, Plasma, and Particle Beams. This means that if a race wants to use missiles, Gauss, HPM, or Mesons as their main weapon(s), their ground units will be basically screwed unless they invest into one of the former four weapon types. This can be worked around most easily by developing plasma weapons, but it seems silly to force a race to do this if it is not within the player's roleplay canon for that race, and it adds an extra RP burden at the start of the game if the player wants to stay within the allocated starting RP. Basically, the current mechanics effectively are a nerf to missiles and mesons, neither of which needs the extra hurting in the current state of Aurora.
Additionally, this mechanism can upset GU balance if the player chooses to research very cheap Plasma weapons to boost GU attack, as the low RP cost means that GU racial attack can easily reach ~50% greater than racial armor, which tends to upset the ground combat balance in a way that minimizes the value of armor and reduces interesting decision-making as a result - ground combat is intrinsically balanced around the expectation that racial attack and armor are usually equal at a given nominal tech level. I don't think it is good for interesting gameplay decisions to be flattened if the player decides they want plasma guns for their ships - note that plasma is just fine for ships and doesn't need to be a special bonus for ground forces to be useful or viable.
Finally, while this isn't really a rationale for a gameplay change, I will observe that for DB modders it is not possible to change the ship armor techs without affecting the ground unit balance. Pulling GU attack into its own tech line would allow a DB modder to rebalance GU attack if they decide to change the ship armor techs.
I'm reposting this from it's own thread as I think it might be interesting to at least think about:Technically, you CAN attack their home system, sorta. If you board a vessel of theirs that then retreats and is captured in that system, you are free to do whatever you like there. Good luck...Steve also stated that their system doesn't really serve a practical purpose in terms of production or having a functional colony at all if I remember correctly. Even if you somehow managed to glass their planet, the ships are spawned in via script, so what Zeebie fears might be correct: There is likely an infinite and regular number of them. (and killing will only stall them)
The fact that this is the first non-npr threat that can research doesn't lie well with me either through this. They are the only ones you can never shut down, and they will always improve? It really does sound quite bothersome, which is a shame, because otherwise I like their idea.
Now, if there were more instances of this race that could spawn, kind of how remnants could be considered their own local faction in each system they are in, that I would welcome. A new raider clan once in a while to keep the game interesting, that sounds nice to me.
The same invincible and improving threat all the time however seems to take away control from the player, which is not good for sandbox. I will test how I can edit them in database to see if they can be 'defeated' there after some time. If that doesn't work, I would probably deactivate them pending further player reports.
Spoiler for Rahkas rant:
The problem I have with stuff like Rakhas for example spawning an instance for every planet is that after a while you can get clutter in the intel screen of all these dead races. It also is a bit redundant and unnecessary for the Rakhas to have an instance per planet as due to their nature they will never interact with other Rakhas and have very simple and uniform foreign policy regarding NPRs and player races.
But I digress
Spoiler for my Raider rework:
I actually really support the idea of there being a % chance for a system that you first explore to be declared a raider system where they have a colony and basic infrastructure. You could then add a special raider-only component to their ships that allows them to partially circumvent the JP network by allowing them spool up this component and enter anywhere on the outskirts of any system connected to their current system through JPs. This component would probably have a decently sizeable cooldown so it can't be spammed and not be mutually exclusive with the existing jump drives, allowing the raiders to also use JPs like everyone else, maybe as a desperate escape attempt.
This means that you can predict where the pirates will appear/travel through based on where their system(s) are but not completely be able to stop them through JP blockades. Giving the player the choice either escort everything, or build surveillance on problem frontier systems to spot entering pirates and remove them before they move deeper into your territory, allowing you to maybe not escort absolutely all civilian traffic in the core of your empire.
Under this rework, you would be able to have multiple Raider systems each emanating an aura of piracy around them from different directions, with the colony in the raider system (would be cool if they were the new DSPs so that even otherwise empty systems are candidates) producing a set amount of resources (+ whatever is looted) and with certain shipyard capacity producing new problems until dealt with. It might be a good idea to give the raiders strong static defenses for their colonies/defensive fleets so that the player needs to assemble some force to remove them, possibly different colony sizes for the raiders too for varying severity.
I might repost this to the suggestions thread if it finds popularity here but I really do think these new Raiders would fit the "no exceptions" philosophy of C# much better than "there is a magic system you can never legitimately access".
One other addition that Vandermeer points out is the idea of potentially having Raiders spawn in an as yet undiscovered system. This could be done by having a setting for raider generation % per system and when it procs. The game picks a free JP and generates a path of undiscovered systems that is lets say 2-5 jumps away. Forcing the player to spend time actually finding the hideout. It also generates a use-case for those stars and planets that are 100s of billions of KM away, as thanks to their unique travelling the raiders could have those as their pirate havens. Especially if you combine this with their colonies being DSPs.
I just learned at https://www.reddit.com/r/aurora/comments/wtmx2r/enemy_ground_units_just_appearing_on_my_colony/ (please correct if its wrong) that [REDACTED].
I just learned at https://www.reddit.com/r/aurora/comments/wtmx2r/enemy_ground_units_just_appearing_on_my_colony/ (please correct if its wrong) that [REDACTED].
What the frell.
I haven't had the time to play 2.0+ yet but if this holds out I won't have any inclination to play with Raiders on. It sounds like we need a few more patches to iron out the wrinkles before I would feel comfortable starting any long-term campaign with Raiders active, which is a big shame.
I just learned at https://www.reddit.com/r/aurora/comments/wtmx2r/enemy_ground_units_just_appearing_on_my_colony/ (please correct if its wrong) that [REDACTED].
What the frell.
I haven't had the time to play 2.0+ yet but if this holds out I won't have any inclination to play with Raiders on. It sounds like we need a few more patches to iron out the wrinkles before I would feel comfortable starting any long-term campaign with Raiders active, which is a big shame.
Yeah space pirates and raiders attacking ships, stations and planets is one thing. Raiders teleporting onto your planets just sounds grindy and annoying.
Perhaps the space raiders and teleporting planet raiders could be seperate options?
Steve explained on Discord that his comment about the webways was not understood correctly by some of us and they are not in fact teleporting to the planet but always use ships to drop troops.
Minor QoL suggestion: On the ship design screen, I'd like the obsolete component button to rather be a delete component button, when the selected component is a prototype. This would stop the obsolete component lists getting spammed with tons of unused prototypes made when refining ship designs, and make it easier to find actual obsolete components (I tend to mark components obsolete when I research improved prerequisites for them, but then occasionally want to get a ship out quickly without researching an upgraded component).
I just learned at https://www.reddit.com/r/aurora/comments/wtmx2r/enemy_ground_units_just_appearing_on_my_colony/ (please correct if its wrong) that [REDACTED].
What the frell.
I haven't had the time to play 2.0+ yet but if this holds out I won't have any inclination to play with Raiders on. It sounds like we need a few more patches to iron out the wrinkles before I would feel comfortable starting any long-term campaign with Raiders active, which is a big shame.
Yeah space pirates and raiders attacking ships, stations and planets is one thing. Raiders teleporting onto your planets just sounds grindy and annoying.
Perhaps the space raiders and teleporting planet raiders could be seperate options?
Steve explained on Discord that his comment about the webways was not understood correctly by some of us and they are not in fact teleporting to the planet but always use ships to drop troops.
I just learned at https://www.reddit.com/r/aurora/comments/wtmx2r/enemy_ground_units_just_appearing_on_my_colony/ (please correct if its wrong) that [REDACTED].
What the frell.
I haven't had the time to play 2.0+ yet but if this holds out I won't have any inclination to play with Raiders on. It sounds like we need a few more patches to iron out the wrinkles before I would feel comfortable starting any long-term campaign with Raiders active, which is a big shame.
Yeah space pirates and raiders attacking ships, stations and planets is one thing. Raiders teleporting onto your planets just sounds grindy and annoying.
Perhaps the space raiders and teleporting planet raiders could be seperate options?
Steve explained on Discord that his comment about the webways was not understood correctly by some of us and they are not in fact teleporting to the planet but always use ships to drop troops.
It doesn't matter if the ships are directly appearing on top of the planet, from the post I linked it sounded like there was adequate sensor coverage over the victim colony and yet no ships were spotted and the troops appeared out of nowhere anyways.
Like, they shouldn't be appearing literally on top of you, that would be a bug
I just learned at https://www.reddit.com/r/aurora/comments/wtmx2r/enemy_ground_units_just_appearing_on_my_colony/ (please correct if its wrong) that [REDACTED].
What the frell.
I haven't had the time to play 2.0+ yet but if this holds out I won't have any inclination to play with Raiders on. It sounds like we need a few more patches to iron out the wrinkles before I would feel comfortable starting any long-term campaign with Raiders active, which is a big shame.
Yeah space pirates and raiders attacking ships, stations and planets is one thing. Raiders teleporting onto your planets just sounds grindy and annoying.
Perhaps the space raiders and teleporting planet raiders could be seperate options?
Steve explained on Discord that his comment about the webways was not understood correctly by some of us and they are not in fact teleporting to the planet but always use ships to drop troops.
It doesn't matter if the ships are directly appearing on top of the planet, from the post I linked it sounded like there was adequate sensor coverage over the victim colony and yet no ships were spotted and the troops appeared out of nowhere anyways.
Like, they shouldn't be appearing literally on top of you, that would be a bug
I just had it happen to me. An Error messege, and few 8h turns later They just apeared. 72k vs my 5k. R.I.P.
Currently, I have so many fleets in a single NAC that some fleets in the middle of the list can't be dragged to another NAC, because no other NAC is visible in the pane at the same time as these fleets. The workaround for that is rather tedious: create a new empty fleet, move it to the same location (which often requires creating new waypoint), and give my existing fleet an order to merge with the new fleet.
Would like to suggest a minor qol enhancement for the [Auto Assign FC] button.
Would be nice if it did the whole fleet/subfleet if you have the fleet or sub-fleet element selected.
Currently you have to auto assign FC for every ship individually. Unless I am missing something?
Would like to suggest a minor qol enhancement for the [Auto Assign FC] button.
Would be nice if it did the whole fleet/subfleet if you have the fleet or sub-fleet element selected.
Currently you have to auto assign FC for every ship individually. Unless I am missing something?
You can assign to whole class after you set up one ship of that class. Or for same ships in same fleet. There is Assign All button and Assign Fleet button.
Repeating an old suggestion.Second this one. It also fits into role-play more, if you can design different life-pods for each race. Surely the United Federation of Planets has life pods which will be capable of traveling half the Galaxy, but the Klingon Empire as surely will not have such luxury for those who failed in battle.
There should be lifepod endurance tech. As game progresses reactors and other stuff gets better, but survivors still get those sad 15 days regardless of tech.
Would be nice to see whether the hydrosphere is solid, liquid, or gas, on the Economics > Environment tab
1.
In the Naval Organization window, for the civilian sites/installations, is it possible to show the name of the body (comet, asteroid, etc.) where each one is?
Now, to know this, you have to go to the System Generation and Display window and search for the object you need.
If you need to move a fleet to a civilian location, these are some unnecessary mouse clicks, in my opinion.
2.
In the System window, in the table of all the system's bodies, which is the title of the second column?
Quote from: paolot on Today at 12:53:51 AM
1.
In the Naval Organization window, for the civilian sites/installations, is it possible to show the name of the body (comet, asteroid, etc.) where each one is?
Now, to know this, you have to go to the System Generation and Display window and search for the object you need.
If you need to move a fleet to a civilian location, these are some unnecessary mouse clicks, in my opinion.
You can see this information in the Economics window using he "System Body" checkbox at the bottom-left, perhaps this would be more helpful if not what you are asking.
Would be nice to see whether the hydrosphere is solid, liquid, or gas, on the Economics > Environment tab
Doesn't the Gas list append "(F)" to any gas that is currently frozen?
So if you see "Water Vapour (F)", the hydrosphere is solid.
If you don't see the (F), then the hydrosphere is a liquid/gas combination as expected.
Research tab:
Option "Matching Scientists only" preselected
QuoteQuote from: paolot on Today at 12:53:51 AM
1.
In the Naval Organization window, for the civilian sites/installations, is it possible to show the name of the body (comet, asteroid, etc.) where each one is?
Now, to know this, you have to go to the System Generation and Display window and search for the object you need.
If you need to move a fleet to a civilian location, these are some unnecessary mouse clicks, in my opinion.
You can see this information in the Economics window using he "System Body" checkbox at the bottom-left, perhaps this would be more helpful if not what you are asking.
Thank you, nuclearslurpee.
But I would like to have the information in the Naval Organization window too, to direct a fleet to the body of a civilian site without exiting this window.
Can you not just give an order to the fleet to go to that civilian site, just like going to any other colony?
Can you not just give an order to the fleet to go to that civilian site, just like going to any other colony?
I would like to send a fleet to a comet, that I didn't see as a possible destination in the Movement Orders list (Naval Organization window).
So, through the System window, I found a commercial installation was built there.
But, in the Movement Orders list of bodies, the name of the comet is not written next the name of the commercial installation. If it were written, I could send the fleet directly there, without searching for it in the System (or Economics) window, and saving some mouse clicks.
Maybe reduce the "eldar" pirate spawn rate? or logic of spawn?
I've murdered dozens of them but they keep coming into Sol and slowing my game down (because I have to hunt them down). They come every 15-30 days - 4-5 ships that I slaughter and repeat.
I guess they are trying to salvage their own wrecks. . . Maybe make them not spawn in same location after they have been wiped several times?
They are not a threat at all just slowing me down :(
Sure, but that would be a different game. Because then the point isn't ship-to-ship combat in an empire setting game but an empire management game with detailed but automated combat.
Maybe reduce the "eldar" pirate spawn rate? or logic of spawn?
I've murdered dozens of them but they keep coming into Sol and slowing my game down (because I have to hunt them down). They come every 15-30 days - 4-5 ships that I slaughter and repeat.
I guess they are trying to salvage their own wrecks. . . Maybe make them not spawn in same location after they have been wiped several times?
They are not a threat at all just slowing me down :(
Maybe reduce the "eldar" pirate spawn rate? or logic of spawn?
I've murdered dozens of them but they keep coming into Sol and slowing my game down (because I have to hunt them down). They come every 15-30 days - 4-5 ships that I slaughter and repeat.
I guess they are trying to salvage their own wrecks. . . Maybe make them not spawn in same location after they have been wiped several times?
They are not a threat at all just slowing me down :(
Make the "Order Delay" field accept the DDD:HH:MM:SS format.
So for 1 year you dont have to input "31536000" but instead can use "365:00:00:00".
You know, it would really be nice if the Format Template window had an Upgrade Elements button that examined each element in the selected template and checked to see if there is a better element type in the same series that it could replace it with. On finding one, it would replace the element with an equivalent mass of the new element type.
That would save a lot of clicking when we get a new racial armor or weapon strength level.
Yea, maybe. Makes getting the formation to the right size more difficult, since not every element in the series is necessarily the same size.
Integrate the Naval Admin Command and Fleet Commander systems.
I feel that the fleet commander system is a bit underdeveloped, and at the same time we now have a great system of naval admin commands with automatic assignments and the promotion on demand system.
Why not merge the two into a unified Naval Command system? Any fleet or subfleet that has at least one ship containing flag quarters, becomes a naval command and can have a commander assigned, manually or automatically, in the same way that naval admin commands work at present. That commander provides bonuses in the same way that a naval admin command does. If a commander is assigned, they pick from the available flag ships and are physically present on one of them. If the fleet or subfleet no longer has a ship with flag quarters subordinate to it, the naval command is dissolved, with any subordinate commands reparenting to the next level up.
As well as bringing the automated assignment system to fleet commanders, this would give the possibility of a hierarchical fleet command using subfleets for those that want it (squadron commanders under division commanders under the fleet admiral). But in a way that only provides the same bonuses you can get at the moment out of nested admin commands, so people who don't want to bother with that aren't penalised.
Filter out 0-bonus officers for the 1st bonus selected, to make the window usable with 1000s of officers.
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:Thank you for coming to my TED Talk.
- 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.
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:Thank you for coming to my TED Talk.
- 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.
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.
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:
I'd love a conditional order for 'Full cargo'. This would be useful for salvagers. As far as I know, if the cargo space is full, the salvager can still continue salvaging but the extra salvage is lost, since there is no place to put it. This requires a bit of micromanagement to avoid ejecting the salvage into outer space once the cargo is full. With a 'Cargo space full' conditional order, you could set it to 'Unload all installations at colony (A)' and not worry more about it.I'm not sure exactly how salvaging works, but won't your salvager end up with for example only a 90% full cargo hold, then salvage another wreck and have most of the contents be wasted, because they didn't fit into the rest of the space? Possibly never actually reaching 100% full and then never stopping?
EDIT: Could possibly be an 'Unload everything' or 'Unload all minerals and ship components', since the game distinguishes between installations, minerals, and ship components for unloading purposes and the last two seems more common when salvaging.
There needs to be some kind of prevention that stops salvagers from salvaging something that can't fit into their cargo hold.
Either the salvager should know beforehand that the wreck salvage can't fit into its hold or after salvaging the rest of the loot that doesn't fit should just be dropped in space at that location.
Pre-amble: Many people who use ground forces often have a stockpile/reserve formation which they draw replacements from, however it is not only used for that it is also used to manually move elements around and create entirely new formations but as of 2.1.1 it is not possible to create a completely new formation with existing elements and so you have to build new "empty" formations for this purpose.
Suggestion: Make it so when you drag an element out of its formation and onto the body it is apart of or ship etc that it gives you the option to create a new formation with that element or elements inside.
Pre-amble: Many people who use ground forces often have a stockpile/reserve formation which they draw replacements from, however it is not only used for that it is also used to manually move elements around and create entirely new formations but as of 2.1.1 it is not possible to create a completely new formation with existing elements and so you have to build new "empty" formations for this purpose.
Suggestion: Make it so when you drag an element out of its formation and onto the body it is apart of or ship etc that it gives you the option to create a new formation with that element or elements inside.
Seconded as this would be a brilliantly simple UI fix for a common problem.
It would be great if the Default Movement Action that's issued when double clicking on a location could account for the capabilities of the ship. I'm specifically thinking of only issuing Geo/Grav Survey orders in the case where the fleet has the relevant sensor, and just doing a Move To order otherwise.
When exploring, I normally use a dedicated scout craft to enter a new system first, and then bravely fly around its planets to see if it bumps in to anyone. Every now and again I find one stuck forever trying to survey a planet because I forgot, and just double-click ordered it to survey :)
On this subject, I'd also suggest making the Default Movement Action when clicking on a population Refuel, Resupply And Load Ordinance From Colony, rather than just Refuel And Resupply From Colony). That could be issued to all fleets, since those without ordinance capacity treat the two orders the same.
Depending on playtest, I may also add load/unload colonist orders that have an Ark ship as a target, although I suspect this would be seldom used in practice. Ark Modules will more likely load colonists once and then retain them indefinitely (with the exception being an orbital colony that builds its own Ark ships).http://aurora2.pentarch.org/index.php?topic=12523.msg159464#msg159464
Pre-Amble: In the current ground force system players must create individual formations and then bring them under one another to create a hierarchy for actual duty in combat, this can become heavily tedious as players must individually drag formations under headquarter formations and this is especially so when you consider larger hierarchies, this is why I believe we can solve this relatively simply through the introduction of the ability to save and construct entire hierarchies from the ground force construction window.
Suggestion: The way I see this being implemented is through a system of "hierarchal" formation templates, what I mean by this is that in the formation templates window of ground forces you would be able to grab formations and bring them under other formations within that window assuming they follow the normal rules of course, this would create a hierarchal formation and would be designated with (H), a simple +- tab could also be implemented to hide these subservient formations like currently implemented in order of battle.
Once formations are brought into this hierarchy you can then begin construction, the new system of ground force construction will begin constructing the hierarchy either 1 at a time from top down or all at once equally and once built it will then automatically be put into order of battle in that exact same hierarchy.
Feasibility: I am unsure how much you will be able to adjust or make this work but I believe simply copying the hierarchies from order of battle with some modification should make things easier, the difficulties being getting construction to work with it and automatically creating hierarchies on completion
Feature suggestion: in the ground unit formation editor, add a button to update a formation template with the newest units for unit series within the template
IE:
I have a unit series with soldier mk1 and the newer soldier mk2 unit designs
Instead of having to manually replace the "soldier mk1" units within my formation templates, I just press "update template series" or whatever, and it would swap to soldier mk2.
To be clear, I am not talking about already built formations, just their templates
Oops I missed that.Feature suggestion: in the ground unit formation editor, add a button to update a formation template with the newest units for unit series within the template
IE:
I have a unit series with soldier mk1 and the newer soldier mk2 unit designs
Instead of having to manually replace the "soldier mk1" units within my formation templates, I just press "update template series" or whatever, and it would swap to soldier mk2.
To be clear, I am not talking about already built formations, just their templates
I've already added something very similar
http://aurora2.pentarch.org/index.php?topic=13090.msg162229#msg162229
This uses copy, rather than replace, because otherwise it would affect units already under construction.
SJW: You can already flag systems for mineral search by using the Mineral Search Flag on the Galactic Map
Maybe the Conscript checkbox should be ticked by default for commercial designs and space stations. It could toggle off automatically when the ship flips to a military design.Oh yeah, I definitely want this. I keep forgetting to check that box and as far as I know there's no point in not having it checked for commercials.
I'm again tinkering with Orbital Mining, and it is a pain in the A... urora Game. ::)I agree that some rework of orbital mining to make it more automated would be nice.
I'm not listing all what is needed right now. Suffice to say that it is micro-management at the finest, without help from Events.
So here is my suggestion to make OM feasible (maybe at least some of it is doable):
1. Change Standing Order "Move to Asteroid Mineral Source" to "Mine at OM Mineral Source" and don't remove it when destination is reached (similar to Science Vessels).
2. Add Condition "Cargo Hold more than 90% full" and add Action "Unload Cargo at Colony (with Pop)".
3. Don't request to make all OM-Eligible bodies a colony.
3a. Let the civil mining companies check, if there is an Orbital Mining Module present before establishing a CMC.
or
3b. Let the Mining Module make the body a colony and delete the colony when all minerals are mined.
or
3c. Add a button to "System Generation and Display" with "Create all OM Colonies". And another one for "Delete empty OM Colonies".
That way you can nearly fully automate the OM, similar to the fully automated colonization.
I'm again tinkering with Orbital Mining, and it is a pain in the A... urora Game. ::)Playing with both Orbital Mining and Fuel Tankers moving fuel from Sodium Harvesters, I've come to want a set to conditional orders that basically let me say:
I'm not listing all what is needed right now. Suffice to say that it is micro-management at the finest, without help from Events.
So here is my suggestion to make OM feasible (maybe at least some of it is doable):
1. Change Standing Order "Move to Asteroid Mineral Source" to "Mine at OM Mineral Source" and don't remove it when destination is reached (similar to Science Vessels).
2. Add Condition "Cargo Hold more than 90% full" and add Action "Unload Cargo at Colony (with Pop)".
3. Don't request to make all OM-Eligible bodies a colony.
3a. Let the civil mining companies check, if there is an Orbital Mining Module present before establishing a CMC.
or
3b. Let the Mining Module make the body a colony and delete the colony when all minerals are mined.
or
3c. Add a button to "System Generation and Display" with "Create all OM Colonies". And another one for "Delete empty OM Colonies".
That way you can nearly fully automate the OM, similar to the fully automated colonization.
Quote from: Elminster link=topic=13020. msg162352#msg162352 date=1663236773I'm again tinkering with Orbital Mining, and it is a pain in the A. . . urora Game. ::)Playing with both Orbital Mining and Fuel Tankers moving fuel from Sodium Harvesters, I've come to want a set to conditional orders that basically let me say:
I'm not listing all what is needed right now. Suffice to say that it is micro-management at the finest, without help from Events.
So here is my suggestion to make OM feasible (maybe at least some of it is doable):
1. Change Standing Order "Move to Asteroid Mineral Source" to "Mine at OM Mineral Source" and don't remove it when destination is reached (similar to Science Vessels).
2. Add Condition "Cargo Hold more than 90% full" and add Action "Unload Cargo at Colony (with Pop)".
3. Don't request to make all OM-Eligible bodies a colony.
3a. Let the civil mining companies check, if there is an Orbital Mining Module present before establishing a CMC.
or
3b. Let the Mining Module make the body a colony and delete the colony when all minerals are mined.
or
3c. Add a button to "System Generation and Display" with "Create all OM Colonies". And another one for "Delete empty OM Colonies".
That way you can nearly fully automate the OM, similar to the fully automated colonization.
1. Do a thing (load ore, mine, refuel from harvester)
2. When full, go to specified place and unload
3. Goto 1
I know I can set up timed orders now. That's what I do with the fuel tankers. I set some interval to wait between loading fuel and offloading. But what I'd really like to do is basically just say "wait until full", drop off cargo, go back and do it all over again without having to try to calculate how long it will take to get a full load and prevent a lot of back and forth.
Maybe what this needs is a checkbox on the orders screen for things like refuel and load minerals that says "keep doing this until full".
Perhaps there is a way to do this already. I'm still pretty new at this game.
Or Maybe th
With new spoilers creating multiple engagements at a time in different systems. It is sometimes hard to remember which fleets are in Openfire. Causing slowdowns.
Can an indicator be added to the fleet list to highlight ships or fleets that are in an open fire state? similar to ships going red and orange showing damage.
maybe a small yellow light beside the ship's name.
Quote from: Ush213 link=topic=13020. msg162381#msg162381 date=1663317339With new spoilers creating multiple engagements at a time in different systems. It is sometimes hard to remember which fleets are in Openfire. Causing slowdowns.
Can an indicator be added to the fleet list to highlight ships or fleets that are in an open fire state? similar to ships going red and orange showing damage.
maybe a small yellow light beside the ship's name.
I have recently discovered that there is a "Cease Fire All Ships" button in the miscellaneous tab. That is hugely helpful in those instances.
I just noticed that wrecks can't be tractored.Pretty sure it's because most wrecks are supposed to be more of a debris field from blowing up rather than a nicely Swiss cheesed albeit 1 or 2 piece ship that sinks in the ocean. You can't really tow all the bits and bobs floating around so you scrap it on site and store it in your cargo hold.
Is there a reason for it?
Can we get the ability to tractor wrecks?
First Suggestion: Make a "Bugs Discussion" thread, so you can separate Bugs and Discussions. :-)You can make new threads in the Bugs sub-forum for discussion about them. No need for a specific thread. Then, once there is consensus that it's a bug, the thread creator can post in the actual Bugs thread.
I want to preface this post with a couple things. I play on a 27" 1440p monitor (ROG SWIFT PG279Q), I sit about a meter from my screen. I deal with text on a daily basis (I'm a software developer) and I'm looking at a screen most of the day.
I regularly get headaches from looking at Aurora's UI only because of how small it is at 1440p. Combine this with contrast between text and colours on the UI I have to regularly strain my eyes to make out some text which causes the aforementioned headaches. I have tried increasing the scaling on my monitor to 125% which makes most of the UI readable, but all the text becomes extremely blurry, to the point where it also causes headaches trying to make out different characters.
I understand that Aurora has a very complicated UI where it would involve a lot of work to ensure the UI is scalable to different resolutions, specifically, since Aurora is configured to be played on 1080p, it would scale up by 50% when being played on 1440p. I understand that scaling down to fit on smaller screens isn't feasible due to how many UI elements Aurora has, but surely scaling upwards shouldn't require rearranging of UI elements?. As I was digging around for a solution, the closest I got is changing Aurora.exe -> Properties -> Compatibility -> Change High DPI Settings -> High DPI scaling override -> System (enhanced). This ensures that the text is crystal clear when playing on 125% Windows scaling. However, some interface elements are cut off which makes this solution not usable. If it weren't for this, I could play with this setting and not have to endure headaches.
Interestingly, this issue only exists on a handful of window; most windows are fine, I've included screenshots of the problematic windows.
I've I'd take a guess, I'd say that most, if not all, windows have a maximum window size. Due to the increase in font size, some scaling elements on the UI are pushing other elements that are anchored to said element out of the bounds of the window, and due to the window being limited in size, it can't scale to fit it's contents. Either making sure Aurora is DPI aware by uniformly increasing the scale of it's windows (WinForms should have an API to do this out of the box with very little effort needed, though I could be wrong, happy to provide my findings on this), or unlocking the maximum size of windows are two fixes that come to mind (keep in mind that I'm in no way saying that either of these solutions require little work).
I want to clarify that this is a minor accessibility issue but I hope that this could get some attention, surely I'm not the only one using a screen with a higher resolution.
I want to preface this post with a couple things. I play on a 27" 1440p monitor (ROG SWIFT PG279Q), I sit about a meter from my screen. I deal with text on a daily basis (I'm a software developer) and I'm looking at a screen most of the day.
I regularly get headaches from looking at Aurora's UI only because of how small it is at 1440p. Combine this with contrast between text and colours on the UI I have to regularly strain my eyes to make out some text which causes the aforementioned headaches. I have tried increasing the scaling on my monitor to 125% which makes most of the UI readable, but all the text becomes extremely blurry, to the point where it also causes headaches trying to make out different characters.
I understand that Aurora has a very complicated UI where it would involve a lot of work to ensure the UI is scalable to different resolutions, specifically, since Aurora is configured to be played on 1080p, it would scale up by 50% when being played on 1440p. I understand that scaling down to fit on smaller screens isn't feasible due to how many UI elements Aurora has, but surely scaling upwards shouldn't require rearranging of UI elements?. As I was digging around for a solution, the closest I got is changing Aurora.exe -> Properties -> Compatibility -> Change High DPI Settings -> High DPI scaling override -> Application. This ensures that the text is crystal clear when playing on 125% Windows scaling. However, some interface elements are cut off which makes this solution not usable. If it weren't for this, I could play with this setting and not have to endure headaches.
Interestingly, this issue only exists on a handful of window; most windows are fine, I've included screenshots of the problematic windows.
I've I'd take a guess, I'd say that most, if not all, windows have a maximum window size. Due to the increase in font size, some scaling elements on the UI are pushing other elements that are anchored to said element out of the bounds of the window, and due to the window being limited in size, it can't scale to fit it's contents. Either making sure Aurora is DPI aware by uniformly increasing the scale of it's windows (WinForms should have an API to do this out of the box with very little effort needed, though I could be wrong, happy to provide my findings on this), or unlocking the maximum size of windows are two fixes that come to mind (keep in mind that I'm in no way saying that either of these solutions require little work).
I want to clarify that this is a minor accessibility issue but I hope that this could get some attention, surely I'm not the only one using a screen with a higher resolution.
With the current automated medal awards, only the CO of a ship gets credit for any kills or achievements. This makes sense but it does mean that lower-level officers XO, TO, etc, never get any awards until they reach command rank.
It would be neat and make sense for some kinds of awards to go to all the officers. For example, in my current campaign, I have a "Royal Unit Citation for Gallantry" which is awarded for destroying a hostile ship. I've also got a unit citation for the first ship through a jump point and things like that. Maybe there could be a configuration option in the Medals window similar to the one in the manual "Award Medal" screen allowing us to select multiple recipients for certain awards? I realize this is complicated by the fact that achievements are tracked on individual commanders and maybe it isn't worth the effort. I just think it would be neat.
<snip>
It would also be cool to make it job specific. It makes sense for the tactical officer to get kill credits and for the science officer to get survey related credits while the chief engineer gets damage related credits.
You could have the CAG get the kill credits of the strike group, idk what you'd do for the XO.
When giving the order to "Refuel and Resupply" at a colony, can we please get an automatic unloading of Survivors?Any interaction with a colony seems like it ought to do this.
I had several occasions, where I rescued personnel, but forgot about them. Then years later the fleet moved to fight, and I get the message, that the life support is not enough, because they still had the survivors onboard.
Maybe it's time for another Theme import/update round?
Your last one seems to be more than 2 years ago.
Ofcourse this has nothing to do with the fact that I have submitted/corrected two of the Themes. ;D
Alternatively/Additionally, can we get a counter in the names of the Themes, so wew can easily see how much entries they have?
In light of the recent changes to Particle Beams I was looking at weapons and noticed something odd about Carronades. Some calibers of Carronades are one hull size smaller than the equivalent laser and that makes them output marginally more damage per HS at the meager 10k range they're useful. Other Carronade calibers are exactly the same size as the equivalent laser, which means they do the exact same damage per HS. This is a bit weird because it makes some calibers more useable than others. I think Carronades should do a bit more damage than lasers at 10k (they're already giving up armor penetration and range) so normalizing this to make all Carronades 1HS smaller than lasers would at least make them all equally viable.
Current game sizes of carronades and lasers.
C-HS L-HS
80cm 25 26
70cm 22 23
60cm 19 19
50cm 16 16
40cm 12 13
35cm 11 11
30cm 9 10
25cm 8 8
20cm 6 6
15cm 4 5
I might suggest going a step farther and making all Carronades significantly smaller, while keeping the current power requirements. Any size decrease gives them a point-blank edge over the same laser. Decreasing all carronade sizes by 1/4th or even more compared to the equivalent laser would give them a huge damage boost at point-blank range, while keeping them below the equivalent lasers and railguns after about 20k. Running up on one would be worse than getting a face full of gauss cannons, but the counter play is just to stay out of range.
Carronade technology is around half as expensive so you can advance up their technology tree MUCH faster, usually about two sometimes three technology levels higher then the equivalent other weapon systems. Carronades also effect ground troop weapon strength if not having two or three levels better ground troop weapons strength is a huge advantage I don't know what is.
As Carronades is far cheaper and fire much less often they also consume way less MSP in prolonged combat engagements and also is cheaper in general to fit into your ships which can be important in many regards.
I think that Carronades is in a very good place at the moment and serves a very interesting role...
Wouldn't the 96 damage from the carronade generate 3x as much shock damage vs the 36 damage laser, i.e. 18 vs 6 since shock damage goes up linearly above about 36 damage after you reach the 100% chance of doing shock damage? If so, that could that be significantly more helpful than additional DPS, at least against a heavily armored ship. The whole point of combat is to scramble the inside of the egg, not poke holes in the shell.
60 cm C8 Plasma Carronade (1) Range 192,000km TS: 3,000 km/s Power 96-8 RM 10,000 km ROF 60 96 48 32 24 19 16 13 12 10 9
35 cm C8 X-Ray Laser (1) Range 192,000km TS: 3,000 km/s Power 32-8 RM 70,000 km ROF 20 32 32 32 32 32 32 32 27 24 22
Beyond 30k the laser does more damage, fires three times as fast and is 58% the size of the Carronade. It's debatable whether the Carronade wins even at 10k as both a 96 damage PC and a 32-damage laser penetrate 9 layers of armor, the laser will fire 3 times for every Carronade shot, and you can fit a lot more of them in the same space.
Making Carronades smaller won't make them much more useful at long ranges but it would make them more competitive against equal tech lasers in their supposed niche.
EDIT: At very low-tech levels the ability to research very large carronades so cheaply does make them more competitive at range see:
30 cm C3 Plasma Carronade (1) Range 192,000km TS: 3,000 km/s Power 24-3 RM 10,000 km ROF 40 24 12 8 6 4 4 3 3 2 2
15 cm C3 Near Ultraviolet Laser (1) Range 180,000km TS: 3,000 km/s Power 6-3 RM 30,000 km ROF 10 6 6 6 4 3 3 2 2 2 1
At this level, the carronade's damage actually falls off slower than the laser because of the comparatively low laser range tech. Still, the laser is 55% the size, fires four times as fast, doing the same damage over time even at 10k and both weapons have 4 armor penetration at point blank range. I suppose the carronades do quite a bit more shock damage though. I don't know how to evaluate that.
EDIT2 TLDR: I don't actually think early Carronades should be able to out range lasers at the same tech level or be usable to game the ground combat system or only be viable as low-tech weapons. I'd like to see them rebalanced to be viable in their niche for the whole game without conveying early game advantages. Making them smaller alone won't accomplish this, it would probably require some kind of very very expensive range boosting tech to make them more useful in the midgame while reducing their range early.
Carronade technology is around half as expensive so you can advance up their technology tree MUCH faster, usually about two sometimes three technology levels higher then the equivalent other weapon systems. Carronades also effect ground troop weapon strength if not having two or three levels better ground troop weapons strength is a huge advantage I don't know what is.
Yeah, but I'd argue that's a bad thing. The ground combat system wasn't designed for being able to artificially inflate your attack so far above armor at a given tech level and doing so is basically mandatory against another player. It's only so cheap in an effort to balance it against other ship weapons. It might as well be renamed to Ground Attack Strength and moved into the Ground Combat section.
I consider this a large enough exploit that I bump the RP cost of carronades up by 50% in my DBs. Since ground combat effectiveness scales to the fourth power of the tech level (roughly), it is really ridiculous. I have considered putting it back to 2x as in VB6 but I know it was changed for a reason - but then again, VB6 had a separate ground forces attack tech line, so maybe back to 2x is a good idea. Jorgen is certainly correct that the carronade as it is constitutes a quite strong and respectable choice of weapon - especially since it only has one tech instead of 2-3, so a carronade caliber that costs 30k RP to develop is the same net research cost as most weapons' 15k RP level since you have to develop 2-3 of those 15k techs.
When setting Themes for Star Systems, please add a checkbox for random picks.
Similar to ship names.
When setting Themes for Star Systems, please add a checkbox for random picks.
Similar to ship names.
I'd like to suggest eliminating stand-alone ECM and ECCM modules, and making them another drop down box when designing missile fire controls and beam fire controls, increasing mineral and wealth cost of the resulting fire control. Those are the two components which the ship's ECM and ECCM rating impact anyway, so it wouldn't necessarily change the mechanic. It would just eliminate the need to dedicate volume to a separate module, which I don't see a gameplay reason for doing. As it stands now, it doesn't make sense for ECM/ECCM tech to be so large you can't really fit it into fighters but also small enough you can put it on missiles, which seems inconsistent.
I'd like to suggest eliminating stand-alone ECM and ECCM modules, and making them another drop down box when designing missile fire controls and beam fire controls, increasing mineral and wealth cost of the resulting fire control. Those are the two components which the ship's ECM and ECCM rating impact anyway, so it wouldn't necessarily change the mechanic. It would just eliminate the need to dedicate volume to a separate module, which I don't see a gameplay reason for doing. As it stands now, it doesn't make sense for ECM/ECCM tech to be so large you can't really fit it into fighters but also small enough you can put it on missiles, which seems inconsistent.
Partially agree. For ECCM this makes perfect sense, ideally with a premium +HS to the fire control in question, however ECM as a module affects the entire ship, not its individual fire controls. ECM should remain a separate component, however I do think it would be nice to have it be designable in some manner like shields or cloaking modules, with an adjustable size corresponding in some way to efficiency. It should retain the current non-stacking effect (although stacking modules for redundancy is fine) so that it is not optimal to spam 0.1-HS ECM on your 69,420-ton battleships.
Army units that have weapons to heavy to be used for police specialization units should not count towards police strength, but instead give a small amount of protection, allowing you to pick between a small fleet or a relatively big army but one that perhaps doesn't need as much maintenance for your protection.
I'd like to suggest eliminating stand-alone ECM and ECCM modules, and making them another drop down box when designing missile fire controls and beam fire controls, increasing mineral and wealth cost of the resulting fire control. Those are the two components which the ship's ECM and ECCM rating impact anyway, so it wouldn't necessarily change the mechanic. It would just eliminate the need to dedicate volume to a separate module, which I don't see a gameplay reason for doing. As it stands now, it doesn't make sense for ECM/ECCM tech to be so large you can't really fit it into fighters but also small enough you can put it on missiles, which seems inconsistent.
Partially agree. For ECCM this makes perfect sense, ideally with a premium +HS to the fire control in question, however ECM as a module affects the entire ship, not its individual fire controls. ECM should remain a separate component, however I do think it would be nice to have it be designable in some manner like shields or cloaking modules, with an adjustable size corresponding in some way to efficiency. It should retain the current non-stacking effect (although stacking modules for redundancy is fine) so that it is not optimal to spam 0.1-HS ECM on your 69,420-ton battleships.
Having ECM rating scale with ship size would be excellent, makes it harder to have massive battleships that can avoid every attack while also giving big aid to fighters/FACs. Would allow Steve to remove the special small-craft modules and just use ship ECM + FC Electronic warfare module. Honestly, instead of placing an ECM/ECCM component, there should be an additional design option in FC creation for Electronic Warfare on the MFC and BFC design windows. That way the only additional component is the module you mount for ships, reduces clutter a little.
I don't know if this exists already but I couldn't figure it out:
Allow us to move multiple systems on the galactic map at once. Probably by pressing shift then clicking multiple systems, then dragging them. That would make it much easier to adjust large parts of the map to make space for new things near the center.
I don't know if this exists already but I couldn't figure it out:
Allow us to move multiple systems on the galactic map at once. Probably by pressing shift then clicking multiple systems, then dragging them. That would make it much easier to adjust large parts of the map to make space for new things near the center.
You can do this. You can shift-click to box select a group of systems, and also ctrl-click to select additional systems. You can then mass-position them by holding down the mouse button on empty space (doing it on a system moves just that one, even with multiple selected). To unselect the group afterwards, you need to click on a system.
Formation Level Capabilities, rather than Element Level CapabilitiesBut why? And what would happen if a unit/element is moved from formation A to formation B? Will it lose formation A capabilities?
Reduced Missile Radiation Research LineYou can do that already via orbital bombardment from space ships and having FFD units on the ground. Having "clean" missiles that you can shoot safely from outside STO range means that they would basically lose their effectiveness completely. Currently players have to choose between bringing their ships into harm's way if they want to take the planet intact, or just glassing it into an irradiated hellhole.
We can research enhanced missile radiation if we want to glass planets, but what if we could research reduced missile radiation for tactical ballistic missiles for use in assisting ground forces without ruining the planet?
Formation Level Capabilities, rather than Element Level CapabilitiesBut why? And what would happen if a unit/element is moved from formation A to formation B? Will it lose formation A capabilities?
Reduced Missile Radiation Research LineYou can do that already via orbital bombardment from space ships and having FFD units on the ground. Having "clean" missiles that you can shoot safely from outside STO range means that they would basically lose their effectiveness completely. Currently players have to choose between bringing their ships into harm's way if they want to take the planet intact, or just glassing it into an irradiated hellhole.
We can research enhanced missile radiation if we want to glass planets, but what if we could research reduced missile radiation for tactical ballistic missiles for use in assisting ground forces without ruining the planet?
--- I had an idea for designable hangars, thought I'd share it here. So instead of what we have now, you know, with the various modules we'd have bespoke modules which we designed, not unlike engines or the like. Unlike the modules we have, Hangars would be a "one type only" much like engines or jump drives are. You can have as many of the same type as you want, but you cannot mix different types.
--- You would choose size from a drop down, not unlike Jump Drives, and that would determine Capacity. You would have a dropdown for Refueling, Repair (DCR in effect), and Reload. These three would have a 1.0x multiplier to start, and increasing that would increase size and cost.
--- These new bespoke Hangars would come in one of two types, Commercial and Military, chosen from a drop down like Jump Drives. These would follow the existing rules as is with regards to ship types. All Hangars would provide Maintenance and Deployment Freeze / Reduction as they already do with respect to type of hangar.
--- Optionally, Commercial Hangars could be cheaper per Capacity than Military. Likewise, Hangars could have the option to build in armor. It might also be useful to allow Refuel / Repair / Reload multipliers of less than 1.0x all the way down to zero, but having no size reduction only cost reduction. Unless something else would have been increased, in which case the aize would decrease but never fall a certain threshold of Capacity plus... Something else. I haven't mathed that one out yet.
--- Additionally a new feature/ mechanic could be a sort of Shield Boost; basically a system which would give a shielded fighter some shield strength on launch, allowing cheap very low recharge shields to be useful on Fighters by mitigating the recharge on the initial launch. Likewise, shield boost could allow shields to be overclocked, but induce a launch delay while the shields charged up.
--- Gameplay wise I think this could add several things, verisimilitude chief among them. For role play, the player could have specialized hangar types and thus greater variety and character for their designs. Mechanically, this allows more investment in dedicated Fleet Carriers while Escort Carriers could conceivably be smaller and / or cheaper. Beam Based carriers could specialize in Refuel / Repair, but drop reload to 0 to make themselves cheaper and smaller. Missile Based Carriers could go heavy into Reload to increase effectiveness at a cost.
--- I had an idea for designable hangars, thought I'd share it here. So instead of what we have now, you know, with the various modules we'd have bespoke modules which we designed, not unlike engines or the like. Unlike the modules we have, Hangars would be a "one type only" much like engines or jump drives are. You can have as many of the same type as you want, but you cannot mix different types.
--- You would choose size from a drop down, not unlike Jump Drives, and that would determine Capacity. You would have a dropdown for Refueling, Repair (DCR in effect), and Reload. These three would have a 1.0x multiplier to start, and increasing that would increase size and cost.
--- These new bespoke Hangars would come in one of two types, Commercial and Military, chosen from a drop down like Jump Drives. These would follow the existing rules as is with regards to ship types. All Hangars would provide Maintenance and Deployment Freeze / Reduction as they already do with respect to type of hangar.
--- Optionally, Commercial Hangars could be cheaper per Capacity than Military. Likewise, Hangars could have the option to build in armor. It might also be useful to allow Refuel / Repair / Reload multipliers of less than 1.0x all the way down to zero, but having no size reduction only cost reduction. Unless something else would have been increased, in which case the aize would decrease but never fall a certain threshold of Capacity plus... Something else. I haven't mathed that one out yet.
--- Additionally a new feature/ mechanic could be a sort of Shield Boost; basically a system which would give a shielded fighter some shield strength on launch, allowing cheap very low recharge shields to be useful on Fighters by mitigating the recharge on the initial launch. Likewise, shield boost could allow shields to be overclocked, but induce a launch delay while the shields charged up.
--- Gameplay wise I think this could add several things, verisimilitude chief among them. For role play, the player could have specialized hangar types and thus greater variety and character for their designs. Mechanically, this allows more investment in dedicated Fleet Carriers while Escort Carriers could conceivably be smaller and / or cheaper. Beam Based carriers could specialize in Refuel / Repair, but drop reload to 0 to make themselves cheaper and smaller. Missile Based Carriers could go heavy into Reload to increase effectiveness at a cost.
Another option could be maximum ship size, though I think many would prefer the maximum of this tech to be quite high as it can kill the "jump carrier" design that I know some people like using. A compromise would be to have a potentially quite expensive "uncapped" option which allows you to dock whatever but in the case of a combat carrier you could cap it to like 500 tons so that only fighters can dock or 1000 tons if you want FACs.
Make Artillery ignore the target's fortification bonus but have an extra malus vs units with evasion. This would make artillery more useful in assaulting dug-in defenders without making it overpowered, and make light vehicles more useful as a counterbalance vs artillery-heavy forces.
Update the existing breakthrough mechanism (where attacker who achieves breakthrough get a 2nd attack round) to be based on the relative size and and maneuver of sum of front-line attackers vs front line defenders, and have the 2nd attack be weighted to be more likely to be against support or rear echelon units. It's possible this is how it already works (at least how the 2nd attack is targeted), but I haven't been able to find enough documentation to confirm/deny. This would make actual formation size less critical in determining breakthrough (so people can make formations whatever size their OOB heart desires) and give both assaulting and defending forces a reason to keep some units on attack and some on defense, lest you open yourself up to massive breakthroughs. You could also give the defenders some partial credit (0.25?) for their own front line attackers since they should at least help screen from the enemy attackers.
Add a new mechanism called "Rout", where the attacking unit gets a 2nd attack round against the same target, and make it based on relative size of attacking unit vs defending unit and the moral of the defending unit
--- You would choose size from a drop down, not unlike Jump Drives, and that would determine Capacity. You would have a dropdown for Refueling, Repair (DCR in effect), and Reload. These three would have a 1.0x multiplier to start, and increasing that would increase size and cost.
--- Additionally a new feature/ mechanic could be a sort of Shield Boost; basically a system which would give a shielded fighter some shield strength on launch, allowing cheap very low recharge shields to be useful on Fighters by mitigating the recharge on the initial launch. Likewise, shield boost could allow shields to be overclocked, but induce a launch delay while the shields charged up.
Right now I think that hangars can hold way too much tonnage for its size too... fighter crafts and hangar crafts in general is very powerful in a fleets arsenal. They add quite a multiplicative force to a fleet that is hard to counter with your own fighters or small crafts around.
Artillery is literally the defenders best friend. Even moving columns are relatively easy to hit, whereas dug in or fortified defender is relatively safe against artillery bombardment. This was true in WW1 and is still true today even with all the fancy precision munitions. The game should not have mechanics that fly completely against how things work in real life.
Artillery is literally the defenders best friend. Even moving columns are relatively easy to hit, whereas dug in or fortified defender is relatively safe against artillery bombardment. This was true in WW1 and is still true today even with all the fancy precision munitions. The game should not have mechanics that fly completely against how things work in real life.
I might not agree with moderns precision guided munition. They sort of make static fortification pretty pointless if you have total air dominance... that means you have the means to localize and destroy anything you want where you want, when you want... this we saw for example in Desert Storm. Enemy major fortifications was run over as if they were hardly there... it is only when the sides are roughly equal or lack proper air dominance and/or have lack of precision guided munition that fortification is really strong.
Precision munitions still aren't better than your fire direction. Even with undisputed air control, undirected indirect fire is mostly a way to punctuate press releases with explosions, not really a useful tool to attrition enemy formations. Target discrimination from the air is, so far at least, an art form that eludes the ken of human air forces. That *might* change with cheap, low-flying, high camera resolution, high data bandwidth drones. But it hasn't yet. (And probably won't, because people are going to learn how to shoot down drones too, eventually.)
Vehicles are more vulnerable than infantry and static positions, because they can neither hide nor dig in as well. But even vehicle casualties to undirected bombardment have proven lackluster and overhyped in a lot of historical conflicts where the defenders' archives have been opened to researchers. Turns out people who like launching undirected indirect bombardments often replicate their bad target identification in memoirs and after action reports, leading to exaggerated claims of effectiveness (and undercounted collateral damage). And for various institutional reasons the claims made by air forces about their operations tend to be given more air time and credence than the claims made by their victims.
Undirected indirect fire is really useful for blowing up oil and gas infrastructure. But oil and gas infra is, ah, temperamental at the best of times, and will blow up without much provocation.
In related notes, artillery (and orbital bombardment and CAS, both of which are really just expensive artillery) should probably have an efficiency bonus when used in an infantry support or counterbattery roles and an efficiency malus when not used in a combined arms role with infantry.
That was air power, not artillery. Desert Storm is also an outlier - the world's largest and most advanced air force, with allies too, could pound the defender for a month in impunity in the most favourable terrain possible. USA could not replicate its success even in Kosovo just few years later. But I do agree that complete air dominance combined with PGMs can get really effective in neutralizing your opponent.Artillery is literally the defenders best friend. Even moving columns are relatively easy to hit, whereas dug in or fortified defender is relatively safe against artillery bombardment. This was true in WW1 and is still true today even with all the fancy precision munitions. The game should not have mechanics that fly completely against how things work in real life.
I might not agree with moderns precision guided munition. They sort of make static fortification pretty pointless if you have total air dominance... that means you have the means to localize and destroy anything you want where you want, when you want... this we saw for example in Desert Storm. Enemy major fortifications was run over as if they were hardly there... it is only when the sides are roughly equal or lack proper air dominance and/or have lack of precision guided munition that fortification is really strong.
That was air power, not artillery. Desert Storm is also an outlier - the world's largest and most advanced air force, with allies too, could pound the defender for a month in impunity in the most favourable terrain possible. USA could not replicate its success even in Kosovo just few years later. But I do agree that complete air dominance combined with PGMs can get really effective in neutralizing your opponent.Artillery is literally the defenders best friend. Even moving columns are relatively easy to hit, whereas dug in or fortified defender is relatively safe against artillery bombardment. This was true in WW1 and is still true today even with all the fancy precision munitions. The game should not have mechanics that fly completely against how things work in real life.
I might not agree with moderns precision guided munition. They sort of make static fortification pretty pointless if you have total air dominance... that means you have the means to localize and destroy anything you want where you want, when you want... this we saw for example in Desert Storm. Enemy major fortifications was run over as if they were hardly there... it is only when the sides are roughly equal or lack proper air dominance and/or have lack of precision guided munition that fortification is really strong.
However, artillery isn't there yet and probably never will. And anyway, this was as a response to the earlier poster.
Why are very small jump engines restricted to standard transit only? I'd like to be able to create small jump scouts that can fit a good number on a carrier, but even with fairly advanced jump tech I have to put aside ~500 tons for a jump drive capable of squadron transit. The part I like most about Aurora's ship design is the complete freedom it provides when it comes to doctrine, but this just puts a foot down on what I'd like to do.
Separately, I would also like a "load ground unit and all subordinates" order for ships so I can easily load an entire army without havign to load each unit in the OOB separately.This already exists.
Raiders are a great early game enemy but become a micromanagement hassle by the mid game. A sunsetting mechanic for them would be nice. Yes you can just turn them off after a while, but that feels less thematic.
I'd love to see a sunsetting mechanic, something like:
- A tech that can be researched which can stop raiders spawning
- Research and build a device that stops spawns in a system
- Having all the jump points stabilized would prevent spawning in that system by stabilizing the ether
- A certain amount of PPV in a system would lock that system down
- Research a jump drive that can jump to their home base and destroying it would stop the spawns
- Spawn of some sort of "boss" fleet after a set amount of time/exploration that when defeated would stop the spawns
Anyways, that is my 2 cents. .
Raiders are a great early game enemy but become a micromanagement hassle by the mid game. A sunsetting mechanic for them would be nice. Yes you can just turn them off after a while, but that feels less thematic.
I'd love to see a sunsetting mechanic, something like:
- A tech that can be researched which can stop raiders spawning
- Research and build a device that stops spawns in a system
- Having all the jump points stabilized would prevent spawning in that system by stabilizing the ether
- A certain amount of PPV in a system would lock that system down
- Research a jump drive that can jump to their home base and destroying it would stop the spawns
- Spawn of some sort of "boss" fleet after a set amount of time/exploration that when defeated would stop the spawns
Anyways, that is my 2 cents. .
Would an interesting alternative be that the Raiders attack less frequently, but in greater force, as the game advances? That way as an empire grows, the micromanagement load from Raiders would not grow so much, and they would hopefully remain challenging enough to fend off that they remain fun to play against.
Raiders are a great early game enemy but become a micromanagement hassle by the mid game. A sunsetting mechanic for them would be nice. Yes you can just turn them off after a while, but that feels less thematic.
I'd love to see a sunsetting mechanic, something like:
- A tech that can be researched which can stop raiders spawning
- Research and build a device that stops spawns in a system
- Having all the jump points stabilized would prevent spawning in that system by stabilizing the ether
- A certain amount of PPV in a system would lock that system down
- Research a jump drive that can jump to their home base and destroying it would stop the spawns
- Spawn of some sort of "boss" fleet after a set amount of time/exploration that when defeated would stop the spawns
Anyways, that is my 2 cents. .
Would an interesting alternative be that the Raiders attack less frequently, but in greater force, as the game advances? That way as an empire grows, the micromanagement load from Raiders would not grow so much, and they would hopefully remain challenging enough to fend off that they remain fun to play against.
Personally I'd much prefer something like that, if a solution is needed (my own game has seemed very light on Raiders after the early game, to the point where I've unticked Raiders attack NPRs in the hope I might get a bit more of their attention). But I definitely want to have the need to guard rear areas throughout the game - thats the whole point of enabling them for a game IMO.
I do think their weapon choice may not be the best - fighting raiders just means being able to intercept with a single ship that can make 5000kms plus, and has a beam weapon range of at least about 190,000km. I'd prefer a design where they get to land some hits if you come at them with beams, so a big fleet would be a different level of threat - right now the only difference between fighting a single destroyer and a fleet is the amount of patience needed to slowly plink away at them.
Trying to terraform a small asteroid for use with LG infrastructure, my single terraform station was rated as being able to supply 76 atmospheres worth in a year. So in a single 5 day production period it was vastly overdoing the atmosphere then when I tried to fix the overpressure it was vastly undershooting.Unfortunately, there is no easy solution for this because we do not want turn resolution to be slowed down by the game triple-checking every terraforming operation being done by every race. Instead, try making your production delay shorter - turn it down from 5 days to 1 day, for example, that should help. If it doesn't, then build a smaller TF station specifically to handle smallish asteroids.
Can you make it so that if a terraform gas overshoots its level that you assume the engineers turned off the machines early, and so you get the amount you set as a limit?
Or after getting the overshoot use the SM settings to set the atmosphere to the lower level you needTrying to terraform a small asteroid for use with LG infrastructure, my single terraform station was rated as being able to supply 76 atmospheres worth in a year. So in a single 5 day production period it was vastly overdoing the atmosphere then when I tried to fix the overpressure it was vastly undershooting.Unfortunately, there is no easy solution for this because we do not want turn resolution to be slowed down by the game triple-checking every terraforming operation being done by every race. Instead, try making your production delay shorter - turn it down from 5 days to 1 day, for example, that should help. If it doesn't, then build a smaller TF station specifically to handle smallish asteroids.
Can you make it so that if a terraform gas overshoots its level that you assume the engineers turned off the machines early, and so you get the amount you set as a limit?
Or after getting the overshoot use the SM settings to set the atmosphere to the lower level you need
Trying to terraform a small asteroid for use with LG infrastructure, my single terraform station was rated as being able to supply 76 atmospheres worth in a year. So in a single 5 day production period it was vastly overdoing the atmosphere then when I tried to fix the overpressure it was vastly undershooting.Unfortunately, there is no easy solution for this because we do not want turn resolution to be slowed down by the game triple-checking every terraforming operation being done by every race. Instead, try making your production delay shorter - turn it down from 5 days to 1 day, for example, that should help. If it doesn't, then build a smaller TF station specifically to handle smallish asteroids.
Can you make it so that if a terraform gas overshoots its level that you assume the engineers turned off the machines early, and so you get the amount you set as a limit?
If the current layout of the code supports this change with relatively little issue, I would like to propose a low to moderate chance of worlds that would otherwise be tidally-locked spawning as worlds that, instead, enter a stable 3:2 spin-orbit resonance with their host star. Mercury is a real-life example of such a planet; the motion of the sun in the sky of Mercury is as affected as much as Mercury's orbit around the Sun as it is Mercury's own rotation. (http://"https://commons.wikimedia.org/wiki/File:Orbital_resonance_of_Mercury.gif") Cribbing from the notes from my in-progress sci-fi novel, around your average cool red dwarf with the very close-in habitable zone this can result in orbits where the local solar day lasts two years, and the local year is only 96 hours long - with a modestly dense atmosphere this would result in pretty good heat conduction all across the planet as well as something approximating a diurnal cycle.
Given the nature of Real Stars games, I feel this might make things a little more interesting. Aside from large terrestrial moons around close-orbiting Jovian planets, (which are regrettably but likely realistically rare) good colony candidates in Real Stars games can be few and far between if you roll snake-eyes on Alpha Centauri.
This has been suggested in the past, and Steve has indicated that he is aware of this but doesn't think it would have enough of a game impact as whether a planet is fully locked or in 3:2 resonance, it will still be mostly uninhabitable in most cases. To model habitable planets with 3:2 resonance would be rather more involved of a planetary dynamics simulation than I think Aurora is suited for.
I would however not mind seeing some refinement of the colonization mechanics for these bodies, since in principle the light or dark side of a locked planet should still be colonizable at a similar cost to any other body at that temperature. However that would again probably be more complex than is really necessary in Aurora, especially now that OrbHabs, pardon me, Ark Modules are now viable as an alternative to infrastructure.
>> Sure... you can end up with a transport sitting there indefinitely as it tries to pick up something that will never be built
How about adding a cut off condition/s? "75% load OR 180 days have passed "?
Infantry Battalion
Transport Size: 4,997 tons
Build Cost: 120.2 BP
4x Infantry - Supply Team
1x Infantry - Headquarters Squad
24x Infantry - Machine Gun Team
24x Infantry - Anti-Tank Team
24x Infantry - Bombard Team
16x Infantry - Anti-Air Team
2x Infantry - Forward Fire Director
24x Infantry - Sniper
420x Infantry - Rifleman
12x M12 StrikerInfantry Battalion
Transport Size: 4,997 tons
Build Cost: 120.2 BP
4x Infantry - Supply Team (INF, LIA, LOG)
1x Infantry - Headquarters Squad (INF, LIA, HQ - 5k)
24x Infantry - Machine Gun Team (INF, LIA, CAP)
24x Infantry - Anti-Tank Team (INF, LIA, LAV)
24x Infantry - Bombard Team (INF, LIA, LB)
16x Infantry - Anti-Air Team (INF, LIA, LAA)
2x Infantry - Forward Fire Director (INF, LIA, FFD)
24x Infantry - Sniper (INF, LIA, PWI)
420x Infantry - Rifleman (INF, LIA, PW)
12x M12 Striker (VEH, LVA, MAC/CAP)Is there a reason that a shipyard with 6 slipways takes much longer to upgrade itself (using continual capacity) than one with a single slipway?
Sure you are adding more capacity, but you also are using more capacity.
I'm strongly against balancing all weapons to the point where it doesn't really matter which one you use and all are equally good. That's fine for competitive PvP games but doesn't fit single player games, and definitely doesn't fit the character of Aurora. This like trying to make Gauss work as a primary weapon.
I swear the hostility in the forum is getting out of hand
Edit: And for the record, there's probably less than ten people that know the ins and outs of Aurora better than @nuclearslurpee
Have you seen how drastically their damage drops off,
to use them you HAVE to be faster than the enemy, you HAVE to be able to survive the entire distance closing from whatever your max range is to under about 20000km,
and then when you do deploy your "alpha strike" youre still failing to out DPS nearly any other weapon in the game.
also if you think Carronade range is good youre insane.
Also i dont know how youd justify them being used as point defence.
I really fail to understand how you can even pretend Plasma is an effective niche weapon, and honestly it makes me suspect that you dont actually understand how their range scales or something.
And god forbid you need to close the range over distance.
Please, if you disagree give me a detailed answer as to how Plasma is a viable weapon in any circumstance and dont just quote the same "its good for ground units and thats about it" stuff at me,
Also, they don't need to be the best or the most viable. Aurora is a game designed to drive story telling. Theyre great as a RP friendly weapon if nothing else. Not every option is the best option.
I'm strongly against balancing all weapons to the point where it doesn't really matter which one you use and all are equally good. That's fine for competitive PvP games but doesn't fit single player games, and definitely doesn't fit the character of Aurora. This like trying to make Gauss work as a primary weapon.
I swear the hostility in the forum is getting out of hand
Edit: And for the record, there's probably less than ten people that know the ins and outs of Aurora better than @nuclearslurpee
A baseline squadron jump (50k) with starter drives neutralize the emergency plasma weapons role (60k range) unless the opposition has terrible luck.
Blacklight and the others who have written before, makes a reasonable argument that inside the "The ship weapon box" Plasma is objectively terrible at any role outside of luck based encounters or RP Encounters niche. It's heavy, can't be turreted, slow to fire, and terrible damage falloff. It has the flaws of every other Energy weapon type.
I interpreted no hostility from any writer here, I do see friction from differences of opinions and that usually leads to better outcomes from exchanges of thoughts and compromise.
Nobody is infallible and everyone is entitled to their own assessment.
I mean, bluntly, this is largely accurate: in a purely tactical view, plasma is almost always the worst beam weapon as long as no one has invited Mesons to the party - provided that we are ignoring the research and build costs of the different weapons being compared. In practice, given that these costs are actually very low, carronades have many strategic benefits that make them a viable choice in a wide range of cases. I think it is okay if the cheapest weapon to develop and deploy also has the most flaws, that seems pretty fair to me honestly.
One case I like to use plasma for is as a secondary beam weapon for carrier escorts. I can put a couple of decent-caliber carronades on my DEs or CLEs, which allows me to use them to destroy vulnerable targets when I don't want to waste missile ordnance, and using the Gauss turrets which are the primary payload of the DE/CLE class would consume significantly more MSP to do the job (due to the 2% failure rate on weapon firing outside of final fire situations). It is a relatively minor benefit, I admit, but saving ordnance and MSP makes the fleet logistics for a long campaign that much less demanding.
Except it would have all the same problems as a ship with plasma carronades - it must be faster than the opponent and protected strongly enough to survive crossing the enemy's field of fire since their beam weapons will outrange your gauss even easier than they outrange plasma.I'm strongly against balancing all weapons to the point where it doesn't really matter which one you use and all are equally good. That's fine for competitive PvP games but doesn't fit single player games, and definitely doesn't fit the character of Aurora. This like trying to make Gauss work as a primary weapon.
A ship solely equipped with Gauss turrets will likely have an excellent to acceptable chance at accomplishing it's primary mission in pretty much all standard combat conditions. A ship equipped with plasma has a middling to low chance of accomplishing any mission objective in the best of combat conditions. A baseline squadron jump (50k) with starter drives neutralize the emergency plasma weapons role (60k range) unless the opposition has terrible luck.
How big of a destroyer escort if you're using one of the heaviest weapons for secondary batteries? We're not planning the same fleets but that's the beauty of Aurora many ways to play and enjoy yet...
we're still having this conversation about limiting somebody else because it makes subject sense to some to have an objectively known to be worst use of tonnage in combat range of opposing forces.
Plasma may we suggest a few ideas to make this actually useful in a standard tactical use case besides being a rocket-powered deathtrap for crews. You're a prolific author of ideas on this forum, think of it as a thought exercise. Maybe damage falloff, maybe rate of fire, damage pattern, weight or something else?
Railguns recently had a buff, particle as well. There's still two underperforming energy weapons -
meson (I only use as a Small fast craft killer ) which was one of the best weapons of VB6.
Anyway, I can split these posts off into their own thread if folks want to continue discussing the pros and cons of plasma carronades as otherwise it'll clutter up the Suggestion thread too much.
Also, it would be nice if Orbital Miners could have the minerals deposited into their cargo holds instead of the asteroid/system body. It would improve logistics and RP, as we can send a fleet of Orbital Miners and have them come back and forth when their cargo holds are full. So actually having tiny cargo holds on them starts making sense. Especially since a mining operation is a complex thing. It involves a lot of logistics, equipment and etc, so its a bit weird that they would just leave the minerals dumped on the asteroid instead of using small drop ships to bring it back.
I'm strongly against balancing all weapons to the point where it doesn't really matter which one you use and all are equally good. That's fine for competitive PvP games but doesn't fit single player games, and definitely doesn't fit the character of Aurora. This like trying to make Gauss work as a primary weapon.
Yes, there are requirements that have to be met to get the most out of the weapon. A lot of these conditions, for what it's worth, also apply to railguns, and nobody has called for a buff to railguns around here in quite some time.
I would not change most of these things as I think they work consistently with the rest of the game mechanics, damage falloff for instance works exactly as it does for other beam weapons.
Anyway, I can split these posts off into their own thread if folks want to continue discussing the pros and cons of plasma carronades as otherwise it'll clutter up the Suggestion thread too much.
Ground Force Suggestion - New ground forces tech lines.
- Ground Unit Weapon Strength - increase empire weapon strength
- Ground Unit Armor Strength - increase empire armor strength
- [...]
Regarding Plasma Carronades:
This is a Suggestion Thread not a Dissuasion Thread, yes?
[words]
That out of the way, my next step was i just want 1 change. Remove the dramatic damage drop off and make it linear like every other weapon in the game.
What do you mean damage fall off works exactly the same as it does for other beam weapons.
Also didnt reduced shot railguns get nerfed in the recent update? or am i misremembering.
Some potential suggestions for fleets, if they're viable.
- Have a Standing Order to allow transports your transports to respond to Civilian Orders (Supply/Demand Facilities)
- Allow fleets to interact with other fleets without merging (tankers can refuel, tugs can tractor ships/stations, etc as their own fleet)
- Clarifiy the Unload Colonists/Passengers standing orders for the potential target (lowest pop colony, etc)
- Add a variant of the Move to System Requiring Grav Survey for systems that aren't fully Geo surveyed. Preferably have both prioritise systems that are already partially completed over untouched ones
- Have a setting that allows Standing Orders to interrupt manually set orders without wiping the list and allow ships to continue with manual orders after clearing a standing order (generally the conditionals are the interrupters)
- Add a Civilian Supply/Demand for the minerals and allow both Shipping Companies and player built civilian ships to respond. You can potentially add colonists to that if you want to have a colony grow a certain amount before switching to stable after reaching the point you can switch off colonist transfers, which might be a useful way of prioritising colonies for growth
Ground Force Suggestion - New ground forces tech lines.
- Ground Unit Weapon Strength - increase empire weapon strength
- Ground Unit Armor Strength - increase empire armor strength
- Ground Unit Countermeasures - (To-hit modifier) decrease ground unit classes chance to be hit, possible a tech line per unit class or a standard % increase for all unit types
- Ground Unit Toughness - (Hit Points) increase ground unit classes hit points, possible a tech line per unit class or a standard % increase for all units types
- Ground Unit Entrenchment - (Fortification) increase ground unit max fortification level, possible a tech line per unit class or a standard % increase for all unit types
- Ground Unit Armament Munitions Improvement - (Supply Use) decrease ground unit weapons supply use, possible a tech line per weapon class or a standard % decrease for all types
- Ground Unit Armament Penetration Improvement - (Penetration) increase ground unit weapons penetration, possible a tech line per unit class or a standard % increase for all types
- Ground Unit Armament Rate of Fire Improvement - (Shots) increase ground unit weapons shots, possible a tech line per unit class or a standard % increase for all types
- Ground Unit Capability Training- decrease cost modifier for additional ground unit capabilities
I would probably just keep it to these two lines, for a couple of reasons: (1) it is easier to balance since it is just relocating some existing "techs" into a more sensible place, and (2) with too many techs the GC category can become oversized relative to its importance in the game mechanics. This plus the build rate tech gives 3 techs which can scale into the late game, which is on par with the typical research load to maintain a single major ship system type.
We could probably add more (2-3 more lines I think would be fine) but I'm not sure which new tech lines would be the least likely to throw the ground combat balance out the window by accident. Some kind of ECM/ECCM analogue would be great whenever Steve figures out the planned rework for ship-based EW, but in the current state it would be too much of an I-win button I think, given how polarizing the ship-based modules already are.
Breaking off from that to the plasma carronades discussion. My personal suggestion is that there should be a 10cm and 12cm versions, with the 10cm starting at 6-9 dmg and scaling from there, keeping the short range bar a few scattered upgrades. The reason being it's plasma, super high temperature gas that's on the edge of fission/fusion that's being shoved into a magnetic bottle and tossed at other ships. It's probably harder to contain that, especially away from the firing ship, than keep a beam of light from an overpowered torch/flashlight focused or maintain the momentum of a bunch of solid slugs.
What could happen is it's made into the 'anti armour' weapon. Close range, but even on the lowest size, it'll melt a wide 2-3 deep hole through armour. It's not as useful vs shields, and possibly there's a defence tech to counter some of the damage (probably shield to have it mirror mesons), but the concept is that while you're running a risk having to rush in much closer than normal, if you manage it, you can rapidly cripple or kill other ships as even a few volleys can burn large holes in hulls and the components under them.
QuoteRegarding Plasma Carronades:
For a size reduction tech line, I would suggest a line that looks like:The astute observer will note that the size and recharge multipliers are the same as the reduced-size missile launcher options, and the suggested RP costs are the same as for Gauss weapon ROF. I chose this progression as simply doubling the tech cost at each point made it a bit too accessible early on. The given progression is still better than what we currently have for reduced-size lasers (which IMO we should just remove from the game I think as no one uses it and it is not a well-balanced pair of techs) for the RP investment, which fits into the general purpose of the plasma line. The last, optional tech level would require recharging in a hangar bay or at a maintenance facility, just like box launchers for missiles - and as such you don't need a capacitor for the weapon.
- Size 0.75x, recharge time 2x, tech cost 1,500 RP
- Size 0.6x, recharge time 5x, tech cost 5,000 RP
- Size 0.4x, recharge time 20x, tech cost 15,000 RP
- Size 0.3x, recharge time 100x, tech cost 45,000 RP
- (Optional) Size 0.15x, recharge time N/A, tech cost 135,000 RP
My goal here is that at each tech point, a carronade of caliber with comparable RP cost can be reduced and loaded into a fighter to enable the fun, but probably suboptimal, "plasma bomber" class to be used at most stages of the game where fighters are viable. If the recharge time works the same as it currently does for the laser tech, the capacitor requirement will be minimal which will help balance the ~200 ton size compared to 150 tons for the 10cm railgun fighters. My major balance concern is that this enables putting a large number of carronades onto a ship and building up a massive alpha strike, but given the costs I've imposed, the hideous vulnerability of such a ship if it fails to destroy the entire enemy fleet in the first volley of fire, and the general challenge in using plasma as a main offensive weapon, I think it will not prove to be too great of an exploit.
I would not readily go into the larger sizes, because that crosses over with the spinal lasers and I think it is better to keep the roles of each weapon type distinct from one another as much as possible.
Add a variant of the Move to System Requiring Grav Survey for systems that aren't fully Geo surveyed. Preferably have both prioritise systems that are already partially completed over untouched ones
Have a setting that allows Standing Orders to interrupt manually set orders without wiping the list and allow ships to continue with manual orders after clearing a standing order (generally the conditionals are the interrupters)
More choice is better, yes?
Balance in a game with DM options is not exactly the highest of priorities imo.
Overall I think our understanding of Aurora is fundamental different, To me It's a Story Generator like Starfire, D&D, Dwarf Fortress, Or Rule the Waves.
We already have a Move to System Requiring Geosurvey order, although a priority option for partially-completed surveys could be useful.
This would be very useful in some cases, such as not interrupting a survey in progress when deployment time ticks over.
- I would absolutely love this options
- In the next update some of what you purposed has been added, check out the changelog and see if that is what you were thinking about
- Like adding more variants of the unload standing order? may you clarify this.
- That's interesting/may be useful and possible a mirror one to go Geo Survey fully Grav surveyed systems?
- Idk if that is feasible with how the order system is built. Perhaps it could do the conditional order and return to the location is was prior but you might run into a loop for something like refuel at 50% as the ship was already at the end of it's operating range. this one is a technical toughy on initial glance.
- this is one i've previously suggested and would love to have available. Simple movement of minerals and colonist movement.
I would even go farther allow movement of ship components, Missiles, and Ground Unit by Series (Only from formations that are listed as replacements and placed in a formation on the receiving colony named {Colonyname_Replacement_Pool} to allow for easier replenishment of Ground Unit Formations
That's an interesting take on the concept. If I may further suggest your line of reasoning:
- 2 weapon sizes to choose from
- only tech improvement line is for raw damage. Increases damage, power needed, and resource cost But does not increase tonnage.
- Weapon Gradient 2 or 4
It's a simple tweak and may be worth exploring in detail.
Not exactly what I was thinking. More along the lines of Plasma Carronades start at the same size as other direct fire weapons (mostly so fighters/bombers can rack a second one in), however they're more powerful on direct damage and shorter ranged, or at least they've got a shorter effective range, maybe a slower refire rate as well. This results in them having a larger size selection, potentially ending up larger than anything bar a max-tech spinal weapon of any other type and maybe their own spinals are even larger.
The big thing is their damage dispersal. I don't recall what the set up for each weapon is currently, but I know missile warheads need to be a square number for their damage dealt to pen an additional armour layer. I think lasers have a deep but tight penetration, meaning each hit can potentially kill internals, but it's like sticking a needle into a foam ball. What I'm thinking for plasma is that they're a splash anti-armour. Minimum of two layers penetration on their lowest damage
So we now have the Load Colonist, unload colonists options for Colony Ships, which is an excellent addition if you play without Civvies.
As the commands shall be there, I assume it is relatively easy for the following to be implemented:
Freighters command to fulfil Civilian Contracts (Automated)
Freighters to be able trading Trade Goods (Automated)
While I like for some plays to use civilians, I prefer to "Run" my own, especially now that through automated Admin assignments you can pretty much have officers be the CEO of the companies.
I would like to request a new ship component - Political Office, obviously staffed with a Political Officer, producing no benefits and having a token 5-10 ton mass cost. The officer would be selected for Political Reliability, and the entire thing would be mostly for roleplay
I think it should have no benefits, but should inflict a penalty to crew morale. No one likes having an official narc on the ship after allPenalty to morale but an increase to reaction time/fleet training because the political officer will ensure that the crew follow orders quickly, or else.
Just use the current customs components and create a Political office of size 10 tons, thats what the feature is for adding things you want with no game effectsthanks, that actually gets me halfway there! Now if only we could add an officer post to those components, and specify the primary officer skill for appointment
A minor suggestion and an expansion of the Misc component Idea
Miscellaneous Ship Officer Stations
You design the components on the Create Research Projects window by:
Choosing a size (from 1 HS to 10)
giving the component a name
Choosing an Officer Type ( Naval, Ground, Admin, Scientist)
Choosing an Officer Skill That will be the Primary selection Criteria
For Naval/Ground/Admin only: Rank Required(Racial Min +0/1/2/3/4)
- Cost is equal to size in HS and the mineral requirements are split between 20% Duranium and 80% Corbomite.
- The HTK is equal to the square root of the size.
- Additional the officer improves the skill required by the ship station up to 1% or 1 per year per HTK of the component. [ballparking some figures]
2 examples of additional officer stationsCode: [Select]Internal Security Control
Cost 100 Size 100 tons Crew 15 HTK 1
Officer: Ground Force Officer
Rank: Major
Skill: Ground Combat Defence
Base Chance to hit 100%
Materials Required: Duranium 20 Corbomite 80Code: [Select]Civil Logistic Liaison
Cost 200 Size 200 tons Crew 30 HTK 2
Officer: Civilian Administrator
Rank: Admin Rating 1
Skill: Logistics
Base Chance to hit 100%
Materials Required: Duranium 40 Corbomite 160
thoughts?
Edited: Change Rank Idea with RougeNPS input.
Funny enough I've suggested something similar back in February & April of last year.
hxxp: aurora2. pentarch. org/index. php?topic=10640. msg158509#msg158509QuoteA minor suggestion and an expansion of the Misc component Idea
Miscellaneous Ship Officer Stations
You design the components on the Create Research Projects window by:
Choosing a size (from 1 HS to 10)
giving the component a name
Choosing an Officer Type ( Naval, Ground, Admin, Scientist)
Choosing an Officer Skill That will be the Primary selection Criteria
For Naval/Ground/Admin only: Rank Required(Racial Min +0/1/2/3/4)
- Cost is equal to size in HS and the mineral requirements are split between 20% Duranium and 80% Corbomite.
- The HTK is equal to the square root of the size.
- Additional the officer improves the skill required by the ship station up to 1% or 1 per year per HTK of the component. [ballparking some figures]
2 examples of additional officer stationsCode: [Select]Internal Security Control
Cost 100 Size 100 tons Crew 15 HTK 1
Officer: Ground Force Officer
Rank: Major
Skill: Ground Combat Defence
Base Chance to hit 100%
Materials Required: Duranium 20 Corbomite 80Code: [Select]Civil Logistic Liaison
Cost 200 Size 200 tons Crew 30 HTK 2
Officer: Civilian Administrator
Rank: Admin Rating 1
Skill: Logistics
Base Chance to hit 100%
Materials Required: Duranium 40 Corbomite 160
thoughts?
Edited: Change Rank Idea with RougeNPS input.
yes, this is excellent
can i perhaps add it to my db?
If we are willing to accept no actual bonus (or malus), it would be neat if Steve exposed a variable to the Misc. Component creation allowing officer assignment based on X skill. This would probably mean some extra work under the hood (exposing Misc. Components at the officers window, adding Misc. Components to the auto-assignment logic) but it would satisfy a lot of roleplay needs without upsetting game balance in any way (as gaining benefits would make Misc. Component-stacking a meta exploit).
If somebody is willing to build a training station filled with Additional Officer Stations to increase officer stats on a yearly basis why not allow?
The consensus of suggestions I'm reading here is in favor of no benefit to the vessel itself but rather improving the specified selection skill of the assigned officer.
Thoughts on that?
4. I would get a lot of use out of a way to push a tech to the top of the research queue without cancelling and reapplying the whole backlog.
11. It can take around a decade to produce 10 kilotons of static, beam-armed STO ground forces. Even when the beam components are sitting around in the planetary stockpile. Maybe there are balance reasons for STO production not to draw from the planetary stockpile - but I feel like it currently takes too long to produce STO units.
Maybe to balance things, have some sort of penalty for multiple scientists so you can't go crazy. Maybe only the best scientist gets the specialization bonus and everyone else uses their base bonuses.
Drones (no crew), with an associated tech that can incise their size.
It is a very flavorful idea, but the concept has come up many times and the general sense is that Steve does not want to remove the need to man ships with a crew as a resource that is managed and balanced by current mechanics. Adding robotic/drone crews basically bypasses several mechanics which isn't really a design pattern that works well for Aurora.
Drones (no crew), with an associated tech that can incise their size.
Sadly, more than 10 messages like this one exist:It is a very flavorful idea, but the concept has come up many times and the general sense is that Steve does not want to remove the need to man ships with a crew as a resource that is managed and balanced by current mechanics. Adding robotic/drone crews basically bypasses several mechanics which isn't really a design pattern that works well for Aurora.
While I would love the inclusion, I don't think it's going to happen.
Detaching a fleet to retain the Standing orders.In VB Aurora we used to be able to copy conditional orders by simply starting all survey parasites as one fleet, setting orders there, and then hit a "split fleet" button which would turn them into individual ships, but retain all conditional orders.
In this way, we could just set up the first GEO or GRV ship and then just split without multiple clicks. It can be used also in many other instances.
Detaching a fleet to retain the Standing orders.In VB Aurora we used to be able to copy conditional orders by simply starting all survey parasites as one fleet, setting orders there, and then hit a "split fleet" button which would turn them into individual ships, but retain all conditional orders.
In this way, we could just set up the first GEO or GRV ship and then just split without multiple clicks. It can be used also in many other instances.
So bringing back either split fleet would solve this problem the same way as copying conditionals from the mothership would, and make survey carriers viable once more.
Ahh, so it is an order now, good to know.In VB Aurora we used to be able to copy conditional orders by simply starting all survey parasites as one fleet, setting orders there, and then hit a "split fleet" button which would turn them into individual ships, but retain all conditional orders.
So bringing back either split fleet would solve this problem the same way as copying conditionals from the mothership would, and make survey carriers viable once more.
It still possible to do so by using the Divide Fleet into Single Ships order, The fleet will split into individual ship fleets and retain the conditional and standing orders.
That's how I set up my Survey ships and Auto Colony Ships.
Ahh, so it is an order now, good to know.
Old VB was also able to copy orders down from the lead ship of the parasites to the rest, so re-docking survey ships was just as easy as spreading them. There is already a "land on assigned mothership" conditional order, but it is lacking a trigger of the kind "no standing orders left to do" to make it work here. If that could come however, it would be an even superior solution to the VB setting, since it would run completely without clicks.
We already have warheadless missiles that are capable of doing everything we would want drones to do and are often times RP'd as such. The only problem with them is they are not recoverable. Would it be oh so terrible to have drones be built using the current missile designer, but controlled like a ship. Possibly with a new Drone bay module that works pretty much like a magazine/hangar hybrid. Maybe as a balancing feature have a new FC tech line called Drone Director that limits how far away the drones can be operated from their mothership
Regarding #11, you can work around this by splitting your STO formation into smaller batteries and building them separately, then combining them once all are built. Not ideal but helps with the build time problem. Really the long-term solution should be changing ground forces training to be the same as every other factory type, you get the same total BP either way so it is not a huge change IMO.
2. When a troop transport is loading troops from a planet with lots of different types, the list is very cluttered, and the "2nd Surveyor Team" comes below the "21st" through "29th Archaeology Team". The list presentation in "GU / Stockpile" is a lot better to navigate, because the unit's short designation is prefixed.
3. Not sure if you consider it cheating, but maybe an indicator for whether or not I should "Disassemble" a looted alien part. Perhaps an indicator for parts which I've already disassembled and learned nothing.
15. Currently the ordering of the "History" tab of a task group shows the earliest dates first, and I have to scroll down to the newest dates. Because my main usage of this tab is a reminder of what these ships are up to, it would save clicks if this ordering was reversed so the most recent dates are on top.
This change is already in v2.2.
http://aurora2.pentarch.org/index.php?topic=13090.msg162293#msg162293
--- What if we just allowed Troop Transports to have specific loadout templates? We could set them from the Fleet Organization tab and have a "Load to Template" order. Trying to choose a formation that exceeds troop transport tonnage will throw up a dialogue box telling the player "Error: Formation Size cannot exceed Transport Capacity!"Already exists for 2.2
New tech:Jump point creation
field of study:
- time limit (after which the jump point will collapse)
- distance in LY (how far can JP can reach)
Optional:
- ship size that can pass through
- energy demand (power plant size)
Reinforcement Building or feature on existing recruitment building.
I'm not sure if its possible to implement with the current ground force mechanics or even with the 2. 2 changes
But could there be a new building or feature in the ground units building to slowly reinforce existing ground units stationed on the planet with the building.
The current reinforcing mechanics would stay in place and be crucial in reinforcing front line positions fast.
But more for peacetime or light spoiler engagements. The ability to have a building set to reinforce at a trickle speed to bring armies back up to full strength over time would be a nice QOL improvement.
Multiple buildings speed up the process but have diminishing returns. This would allow for the creation of recruitment worlds where dedicated reinforcement armies go back to resupply and be ready for the next large scale fast reinforcements, this would save having to rebuild new reinforcement armies each time.
It could be that the reinforcement building is "loaded" with a new (2. 2) organization or template and in the background has every unit already built in a sort of ghost reinforcement unplayable army. this way when you land your real army on the planet the two armies react the same way as they do now just at a much slower rate.
Population of a body could also be a factor in reinforcement speed.
Quote from: Ush213 link=topic=13020. msg163697#msg163697 date=1674132276Reinforcement Building or feature on existing recruitment building.
I'm not sure if its possible to implement with the current ground force mechanics or even with the 2. 2 changes
But could there be a new building or feature in the ground units building to slowly reinforce existing ground units stationed on the planet with the building.
The current reinforcing mechanics would stay in place and be crucial in reinforcing front line positions fast.
But more for peacetime or light spoiler engagements. The ability to have a building set to reinforce at a trickle speed to bring armies back up to full strength over time would be a nice QOL improvement.
Multiple buildings speed up the process but have diminishing returns. This would allow for the creation of recruitment worlds where dedicated reinforcement armies go back to resupply and be ready for the next large scale fast reinforcements, this would save having to rebuild new reinforcement armies each time.
It could be that the reinforcement building is "loaded" with a new (2. 2) organization or template and in the background has every unit already built in a sort of ghost reinforcement unplayable army. this way when you land your real army on the planet the two armies react the same way as they do now just at a much slower rate.
Population of a body could also be a factor in reinforcement speed.
Why not use the Ground Force complexes for this. . . we just need to be able dedicate a certain percentage of its capacity to replenish troops on the planet. For planets with no population there could be automated ground force complexes just like auto mines who is much more expensive to build just like auto mines.
1) I would love to see a Research module, so we can have proper science stations that can take advantage of dormant constructs on Venusian-type planets. Scientist should be on board such a station to perform studies.
2) Government structure like Naval organization.
If you look at the two screenshots, these are successive in the process of adding water vapour to Proxima Centauri II. You can see the Hydrographic Extent increases from 5.51 to 6.56.
Min Max thermal range changes from (-11.136 <> 54.498, which is a range of 65.634) to (-9.256 <> 56.849 range 66.105). So the range has increased not decreased and the temperature factor has gone from zero to 0.123 though it fluctuates quite a bit.
If you look at the two screenshots, these are successive in the process of adding water vapour to Proxima Centauri II. You can see the Hydrographic Extent increases from 5.51 to 6.56.
Min Max thermal range changes from (-11.136 <> 54.498, which is a range of 65.634) to (-9.256 <> 56.849 range 66.105). So the range has increased not decreased and the temperature factor has gone from zero to 0.123 though it fluctuates quite a bit.
You need to let all that water vapor condense down to equilibrium, which will take ages from 0.5 atm. The increased range you're seeing is simply because you increased atmospheric pressure with water vapor which increased the body's greenhouse effect.
Maybe, just maybe the design and construction of the tech could be improved. meaning, i launch a ship and within 30days something has broke, jump engines, drive engines, all manner of things.
Would scotty put up with that? would kirk? ships should not break less than a month out of the SY.
Just sayin'
More engineering spaces? i can put more than one in a ship?
Ships connected to FFD units are so ineffective so as to be actually comical.
A ship that can fire every ~5-20 seconds, which could wipe out the entire ground force in an hour or so if we didn't care about collateral damage, fires once in an 8-hour window. Then its durasteel and energy-shield penetrating, WDM-scale firepower can apparently 'miss' by not being able to handle fortification level. A light vehicle can dodge the blast while being actively target-painted by the FFD unit.
Also this target painter unit is 1.25 the tonnage of a heavy anti-vehicle cannon, and it takes the same logistical burden to sync it with a ship as it does to direct an entire support-artillery battalion (it's a bit of a pain to manually assign ships to FFD-equipped formations). As it is, it's hardly worth the effort to set it up.
It would probably be good if we could get some kind of modeling of space-based weaponry acting with some kind of 'AOE' - in the sense that a single shot from a spinal-mounted railgun is probably going to leave a half-mile wide crater, and a laser will actively turn the atmosphere to plasma in a significant radius of the targeted soldier.
To model this we might see any of these from FFD'd ship fire:
- the number of shots multiplied by some factor. Perhaps dependent on a quadratic function based on HS - 1 HS (small gun) weapon = 1 impact, but 4HS weapon (big gun) = 16 impacts
- fire as many rounds as their ROF allows in ~120-600 seconds. Perhaps a variable number dependent on some measure of the intensity of the engagement
- these shots might ignore entrenchment, and/or miss chance entirely. What's a target painter good for otherwise?
Change so cargo modules don't have weight until there actually hauling cargo. Meaning empty cargo vessels are faster when empty. Also the inclusion of a dump cargo button.
With raiders now a common joy to encounter. I was thinking about other sci fi shows were the captain has to drop cargo to be able increase speed to attempt an escape. This would be a cool feature now when your cargo haulers detect a raider you can dump cargo and make a run for the nearest jump point.
maybe the cargo also become salvageable as to attract the raiders to it thus giving you a better chance to save the ship.
Change so cargo modules don't have weight until there actually hauling cargo. Meaning empty cargo vessels are faster when empty. Also the inclusion of a dump cargo button.
With raiders now a common joy to encounter. I was thinking about other sci fi shows were the captain has to drop cargo to be able increase speed to attempt an escape. This would be a cool feature now when your cargo haulers detect a raider you can dump cargo and make a run for the nearest jump point.
maybe the cargo also become salvageable as to attract the raiders to it thus giving you a better chance to save the ship.
You know about tractor beams and cargo barges, right?
Ya i know i did a whole playthrough as a space trucker. It was great but there is higher element of micro with that playstyle. plus it got messy when i had to attach and detach for various empire operational reasons. This time around i went back to straight cargo ships and fuel haulers for a simpler life. well as simple as Aurora will allow. ha
I think this change to cargo would be good for QOL reasons to because an empty hauler going on a run will get there faster thus meaning faster moving of resources.
It would be great to have some kind of DB cleaning tool (for player and NPR), like fleet history and so on.Agreed!
Hit% = base_hit% + 10 * (ECM - ECCM)This has a lot of problems, mostly when low base hit% is involved such as for reduced-size Gauss cannons or point defense scenarios, where even 1-2 levels of ECM have an outsize impact of completely negating fire.Hit% = base_hit% / (1 + ECM - ECCM)(with appropriate bounding of ECM - ECCM). This means that ECM will never render a low-accuracy weapon useless, and makes electronic warfare investment most important for near-peer conflicts (i.e., pushing ECM research against an opponent when you already outmatch their ECCM capabilities handily will provide minimal benefits, rather than providing an unbeatable advantage as currently).Hit% = C * base_hit% / (C + ECM - ECCM)is preferable where C could be 2 or 3, etc. This means the effect of a single level of ECM is only a 33% or 25% (respectively) reduction in effective hit rate. We could also start throwing powers and roots around but I prefer to keep things simple if possible.Variable ship (or fleet speeds) Perhaps 1% and then 10% increments to simplify.
With a view to scaling thermal output to ship speed.
Adds an element of stealth.
My bad. Thanks Steve :)
Does the thermal output scale to the speed?
With all the improvements coming to missiles in the next version, could we also get missile series? So that one doesn't have to destroy all ammo or tediously make partial reloads?
With all the upcoming changes to missiles, it would be nice to get passive missiles and MFCs. This would give fleets another stealth option. At the moment, you have to either give your position away when you intend to launch or bring a fighter with an active sensor, Both things give away your intention minutes to hours before your missiles strike.
Additionally, I was thinking about alternative missile fuels. What we have right now is a regular liquid fuel engine only. What might be an interesting addition is solid and hybrid rocket motors. They do have a significantly worse fuel efficiency, aka Engine power hours per fuel mass, but they are easier to manufacture and store. In terms of Aurora that could be translated into a tradeoff between range & speed vs build cost and resource requirements for the engines. Hybrid motors would require less Gallicite and fuel and solids would require none at all, but they would burn maybe Tritanium.
The game probably should emulate real world fire controls more accurately in general... which means that each fire control have capacity of how many missiles they can control and how many targets they can track. This would also be needed if we could guide missiles to targets without having an active lock on them. You also would need the missile itself to have either an active or passive ability to lock onto and track target in the terminal phase.
Missiles should gain accuracy bonuses from having passive and or active abilities as well as the new module for accuracy bonus.
Missiles should be able to be fired at a passively identified object... if an object somehow is lost the missile should just continue on the same path and able to require anything it detect on the way, not just stop dead in it's track. If the object is required it should then be able to require the target or even change to a new target while in flight if the missile have that ability.
There are allot of things you could do with missile combat to make it a bit more realistic.
I would also not mind if ships would need to be data linked with each other and there was limitations on the distance for sensor fusion to occur between ships, but this might be beyond what Aurora could do for complexity reasons. But it would open up more interesting uses for electronic warfare etc which are highly effective in real life.
[...]I agree with these changes. It could potentially fit well with the rework of cloaking systems that Steve has mentioned. An add-on part for your missiles that allows them to track thermal signatures would potentially allow for a stealth ship that can sneak up on its targets using nothing but sensitive passives, fire a volley of missiles, then fade back into the black.
Missiles should be able to be fired at a passively identified object... if an object somehow is lost the missile should just continue on the same path and able to require anything it detect on the way, not just stop dead in it's track. If the object is required it should then be able to require the target or even change to a new target while in flight if the missile have that ability.
[...]
Ya i know i did a whole playthrough as a space trucker. It was great but there is higher element of micro with that playstyle. plus it got messy when i had to attach and detach for various empire operational reasons. This time around i went back to straight cargo ships and fuel haulers for a simpler life. well as simple as Aurora will allow. ha
I think this change to cargo would be good for QOL reasons to because an empty hauler going on a run will get there faster thus meaning faster moving of resources.
Sweet as, just checking you knew about that option.
I wonder where your suggestion would end though: Should tankers get faster with less fuel in the tanks? Other ships as well? Could carriers ditch their small craft to lighten up and go faster? Missiles in magazines? etc.
Hello steve gonna keep this suggestion short it is right what it says on the tin, so I was doing my standing orders for my survey ships recently and i released what a pain it is to go into each one and do the exact same set of orders for 7 different fleets, what if we took the assign fleet option in the ship combat UI for fire controls and applied it to standing orders, put it in that window and hit "assign system" or assign All and it would copy paste those orders to all ships of the same class within the same system or across the galaxy. this would reduce RSI and be a QOL improvement id imagine is somewhat easy to introduce since the concept and idea as well as implementation exists elsewhere.
thanks :)
It would also be nice if "Assign All" (for fire controls and standing orders) applied to all future ships of that class as well, but that would be more work so one thing at a time is good. :)
Hello steve gonna keep this suggestion short it is right what it says on the tin, so I was doing my standing orders for my survey ships recently and i released what a pain it is to go into each one and do the exact same set of orders for 7 different fleets, what if we took the assign fleet option in the ship combat UI for fire controls and applied it to standing orders, put it in that window and hit "assign system" or assign All and it would copy paste those orders to all ships of the same class within the same system or across the galaxy. this would reduce RSI and be a QOL improvement id imagine is somewhat easy to introduce since the concept and idea as well as implementation exists elsewhere.
thanks :)
~Snip~
Standing orders are assigned at the fleet level, rather than the ship level, so it wouldn't work simply for ship classes. It could potentially be done for fleets that only contain that ship class.
One thing I don't much like about beam combat is that the optimal tactics are to focus down one ship after another. ..But those things only make sense because of technological constraints at the time. Modern naval ships, well actually already in WW2, did not have those constraints. Radar was used to both track ships and shots. And then of course airplanes and missiles changed naval combat completely. Similarly, if you go back about a century from WW1-era battlewagon slugfests, you'll see that navies tried their best to focus fire on a single enemy ship and fired at multiple targets only if they were unable to 'cross the T' of the enemy fleet.
One thing I don't much like about beam combat is that the optimal tactics are to focus down one ship after another. ..But those things only make sense because of technological constraints at the time. Modern naval ships, well actually already in WW2, did not have those constraints. Radar was used to both track ships and shots. And then of course airplanes and missiles changed naval combat completely. Similarly, if you go back about a century from WW1-era battlewagon slugfests, you'll see that navies tried their best to focus fire on a single enemy ship and fired at multiple targets only if they were unable to 'cross the T' of the enemy fleet.
That being said, I personally think that engaging a target to throw off the accuracy of the target's shots is a pretty good and quasi-realistic idea to add some further consideration to beam combat. Probably focusing targets will still be a major thing, but you will at least want to 'pay the bills' so to say on keeping a target sufficiently heavily engaged as to degrade its ability to shoot accurately. Personally I think this should only really effect direct fire weapons. There would also need to be some feedback on whether more firepower needs to be allocated (it should probably be more for bigger targets), otherwise it wont be particularly fun because there will be no clear way to know what effect you are having.
Agreed, I'm personally not a fan of adding unfun extra micro. Less micro is better than more micro in 80% of cases.That being said, I personally think that engaging a target to throw off the accuracy of the target's shots is a pretty good and quasi-realistic idea to add some further consideration to beam combat. Probably focusing targets will still be a major thing, but you will at least want to 'pay the bills' so to say on keeping a target sufficiently heavily engaged as to degrade its ability to shoot accurately. Personally I think this should only really effect direct fire weapons. There would also need to be some feedback on whether more firepower needs to be allocated (it should probably be more for bigger targets), otherwise it wont be particularly fun because there will be no clear way to know what effect you are having.
To me, this sounds like a bunch of extra micromanagement. Having to set up your fire controls to allocate shots against every ship in the enemy fleet to degrade their targeting is tedious already, then having to adjust after every increment until you find the right sweet spot. Meanwhile the enemy is doing the same (assuming the NPR is capable of this... if not they are screwed!), so the net result is that the battles take much longer which means many more turns of clicking through 5-second increments and fiddling with BFC assignments. No thank you.
IMO, there is such a thing as having so much tactical detail that it drags the whole game down, even if it is in the name of "realism". I think Jorgen has given the better approach, if you want the tactical micro then manipulating engagement ranges with split formations is a better approach and carries the added risk of being vulnerable to a surprising missile attack against an isolated subformation, which I think with the 2.2 changes is a very present risk.
2) 'Softening up' Most hits on Battleships partiularly at fairly long range do not penetrate the Citadel and so are not a risk to sinking the ship but lots of critical parts of the ship particularly Fire Control systems cannot be armoured. So ships fire control degrades as they take hits , an unengaged ship will still have fully effective fire control when it reaches decisive range. To make this a factor in Aurora it would be necessary to change the armour model so that some ship systems are easy to take out with light hits at long range, worse at any range an Aurora ship does not degrade its fighting or maneuver ability until armour is breached and cumulative hits on armour shorten the time to breach it whereas it does not matter how many 8 inch shells hit a dreadnought they are never going to breach its armour.
Doesn't Aurora already make the distinction between components protected/not protected by armor? Specifically I recall that turrets do not benefit from the armor belt, hence why they have an armor option to add HTK and make them more resilient. Or am I imagining things?I'm pretty sure all components are protected by the armor belt (aside from shock damage, microwaves, and mesons, ofc). Turret armor only adds HTK for when the component starts taking damage.
The issue is that, as you said, you can only put one missile at a time inside, so using a variety of munition sizes in a bomber for example is actively detrimental to its performance, and the more useful thing to do is to create an entirely new bomber design with a different size of launcher, so in essence each craft will generally be specialized for one type of missile only.
~snip snip~
A small amount of damage reduction either through a tech or gained by having some number of armor layers or shields would balance against NPR AMM spam.
I like playing beam only and AMM spam was always an issue, but the new PD and Missile changes look to make it less fun.
Hey Steve, is there any chance NPR carriers will make a return with the changes to NPR fleets etc? it would be really awesome to see them make use of carriers once more. And honestly having NPR's surprising you with large fleets of missile fighters or beam fighters etc would be really fun. Especially with a missile revamp making their missiles more interesting.
So what if we had a fighter specific Troop Transport Bay? It would be more efficient than Standard ones,
but could only be mounted on, and loaded / offloaded by, fighter craft.
Maybe someone with more free time could trawl through the Bugs thread and double-check whether Steve has fixed that bug for 2.2
I think an important thing to add to the next update would be to finish implementing the auto-assign feature for all the positions that still need it. I believe these are only Sector Admins and Academy Commandants. Automating Academy Commandants so you always have the right kind of leader in charge is especially important imo, since thats a major way you can control your recruitment.
I'd also like to add options to Ground Unit HQs similar to Command Modules which would both incentivize you to tailor command units more based on what they are leading (currently I see no reason not to make them heavily armored static units) and to give more jobs to your officers that aren't just command positions.
For example, you add a Supply Command to your HQ and you then create a slot for a Supply Officer that can add their Logistics bonus to reduce consumption on Supply to the unit. These positions are for officers 2 ranks below the HQ Commander and adding any of them will also create an Executive Officer slot for an officer 1 rank below the HQ commander.
I'd even go so far as to expand this system into Admin Commands as well. It'd give your officers many more opportunities and as a result much richer service histories.
Maybe someone with more free time could trawl through the Bugs thread and double-check whether Steve has fixed that bug for 2.2
Maybe someone with more free time could trawl through the Bugs thread and double-check whether Steve has fixed that bug for 2.2I see no response from Steve on the most recent post about it (http://aurora2.pentarch.org/index.php?topic=13078.msg164064#msg164064).
E: Looks like the last couple posts on the same topic have not been addressed by Steve. Candidly, I wonder if maybe he doesn't care to address it for whatever reason - certainly fighter-size colony ships are not terribly practical anyways so maybe he considers it a very low priority.
Maybe someone with more free time could trawl through the Bugs thread and double-check whether Steve has fixed that bug for 2.2
--- I am that person, I have, multiple times. Two releases have seen Steve attempt to fix the bug, yet it persists. AFAIK, 2.2 has no such fix, and nothing of the sort is mentioned in the fix log.
I'd also like to add options to Ground Unit HQs similar to Command Modules which would both incentivize you to tailor command units more based on what they are leading (currently I see no reason not to make them heavily armored static units) and to give more jobs to your officers that aren't just command positions.
For example, you add a Supply Command to your HQ and you then create a slot for a Supply Officer that can add their Logistics bonus to reduce consumption on Supply to the unit. These positions are for officers 2 ranks below the HQ Commander and adding any of them will also create an Executive Officer slot for an officer 1 rank below the HQ commander.
I'd even go so far as to expand this system into Admin Commands as well. It'd give your officers many more opportunities and as a result much richer service histories.
I'd love to have an admin command structure. After the first 3-4 levels of actual combat units there's very little that having a formation in the field with HQ100,000,000 can actually contribute in combat - plus it would be nice to have unified system or even sector commands for the army.
For the command modules... I would love the roleplay aspect, but in practice as it currently stands these would be pretty much useless for me as I usually can build more formations than my commanders could control, so I would not have the officers to spare except maybe for the highest-level HQs (and then I would prefer an admin command structure anyways).
I always kinda headcanon'd that officers without a job were doing shore tours / staff type stuff, especially since staff jobs were removed after VB6. (Consequently, that may be a worthwhile thing to look back into now that we're constrained by only total officers now and nothing else for ranks, otherwise you could stack like 10 tiers over an admin command if you wanted to minmax: staff requirements would provide a cool rp tool while providing an actual coded disincentive)
~Snip~
~snip~
In that vein, maybe it would be very interesting to allow for hybrid missile launchers (or maybe just box launchers? Designing a reload system that would accept such a wide variety of sizes would be hellish IRL), that could allow for several different sizes of missiles to be put in a launcher, as long as the total missile size would be below the launcher size.
~snip~
Would like to suggest System Governors as a layer between colony and Sector.
...40k ground forces theory crafting...Bonus Generic Hit Chance Capability for Ground Forces
Tangentially, does anyone know of actual numeric examples of Astartes kill rates/ratios? I know that it'd likely vary wildly between authors, but still, real numbers would be nice. My goal here is to be able to percieve a solid, meaningful difference between a 250kt battlegroup and a 250kt battlegroup plus a few ~2kt companies of Astartes, but maybe my initial assumption about Astarte potency is simply out of sync with the fiction. Per my original post, in ideal circumstances, an 8kt group of my Astartes would provide an equivalent of ~128kt generic troops. Does this feel sufficient to most people? I go back and forth. Mostly, I just want to do tests...
Ground Force Suggestion - New ground forces tech lines.~Snip~
- Ground Unit Weapon Strength - increase empire weapon strength
- Ground Unit Armor Strength - increase empire armor strength
- Ground Unit Countermeasures - (To-hit modifier) decrease ground unit classes chance to be hit, possible a tech line per unit class or a standard % increase for all unit types
- Ground Unit Toughness - (Hit Points) increase ground unit classes hit points, possible a tech line per unit class or a standard % increase for all units types
- Ground Unit Entrenchment - (Fortification) increase ground unit max fortification level, possible a tech line per unit class or a standard % increase for all unit types
- Ground Unit Armament Munitions Improvement - (Supply Use) decrease ground unit weapons supply use, possible a tech line per weapon class or a standard % decrease for all types
- Ground Unit Armament Penetration Improvement - (Penetration) increase ground unit weapons penetration, possible a tech line per unit class or a standard % increase for all types
- Ground Unit Armament Rate of Fire Improvement - (Shots) increase ground unit weapons shots, possible a tech line per unit class or a standard % increase for all types
- Ground Unit Capability Training- decrease cost modifier for additional ground unit capabilities
When you design a missile launcher there could be a "hybrid" option that is 10% larger then normal. That means you can load several missiles of the same type in one launcher and launch them separately as if in their own launcher. This way you could make a size 8 launcher and having launching 8x size 1 or 2x size 4 missiles if you want to.
I think it would be an interesting option to have.
Its honestly pretty standard for nato box launchers to support quad or octuple stacking by default. They are not MIRV they just put multiple missiles into the box in a 'bus' that holds the missiles and handles firing them individually. So there is space inefficiency but they aren't constrained to 1 missile per tube or 'all at once'.
~Snip~
My suggested mechanic to have something similar to this for Aurora is to have smaller missiles may be assigned to the larger launchers as suggested by GrandNord.
- A Multi-packed Missile launcher utilize firing mode options (similar to the PD mode options) such as X missile per launch or launch all loaded missiles (with the default option being launch all loaded missiles).
- A loaded launcher with missiles remaining rate of fire could be every 5 seconds or perhaps the racial ROF for whatever size missile is packed inside divided by 2 rounded up to the nearest 5 seconds.
- Reloading multi-Pack Missile launcher is based on launcher size and perhaps with a extra delay of 1 second per missile rounded to the nearest 5 seconds.
New component: atmospheric thrusters.
Gives ship equivalent of 1 cargo shuttle, designed as hyperdrive, based on total size of the craft, remaining tiny for fighter sized crafts, but quickly scaling up after.
Fixes fighter transport ships, removes arbitrary limit.
Quick and dirty way to implement: just make it size 0, 1 or 5t module researched at beginning that gives 1 cargo shuttle but throws error if above 500t or 2 in design.
Would be nice to have fighter sized cargo bays to go with it.
1-2hs
New component: atmospheric thrusters.
Gives ship equivalent of 1 cargo shuttle, designed as hyperdrive, based on total size of the craft, remaining tiny for fighter sized crafts, but quickly scaling up after.
Fixes fighter transport ships, removes arbitrary limit.
Quick and dirty way to implement: just make it size 0, 1 or 5t module researched at beginning that gives 1 cargo shuttle but throws error if above 500t or 2 in design.
Would be nice to have fighter sized cargo bays to go with it.
1-2hs
Fighters already can land on planets and fly in the atmosphere of planets. That is also why you can build fighters with fighter factories on the surface of planets.
I'm not 100% sure that you need to change armour effectiveness, you need to consider the extraordinary amount of research you need to get those levels of shields. You can't just look at "level" of shield technology and compare as it they are equal just because they have the same cost individually. You MUST research armour technology regardless and almost all the time armour will be one or two levels above shields for the better part of most games.
Am I the only one who likes when the optimal strategy changes with technology, instead of staying flat and choices essentially being flavor for sake of 'all options being equally viable'. It seems like the only retort to that is 'well with these changes its still slightly different its merely much more similar now'.
Seems like a flat buff doesn't really have any of the nuance you claim it does.
Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen. The big drop down box. After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at
Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen. The big drop down box. After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at
That would be useful. What I normally do is rename important systems to have a space at the front, which sorts them at the top of the list (and generally give Sol two spaces to put it right at the top).
Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen. The big drop down box. After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at
That would be useful. What I normally do is rename important systems to have a space at the front, which sorts them at the top of the list (and generally give Sol two spaces to put it right at the top).
Another option is to have a System naming convention that organizes the list somewhat. I generally do [Number of jumps from Sol][Letter of first jump in branch]-[System Name], so it goes 0-Sol, or 1A-Alpha Centauri, or 1B-Barnard's Star, or 2A-Proxima Centauri for a system down the Alpha Centauri line. That way, all the close stuff is at the top, all the far stuff is at the bottom, branches are grouped together, and systems you haven't gotten around to taking a look at and renaming are at the very bottom. That being said, it would be nice to have populated systems highlighted in green or something, especially since I don't always want to use my naming convention.
Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen. The big drop down box. After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at
That would be useful. What I normally do is rename important systems to have a space at the front, which sorts them at the top of the list (and generally give Sol two spaces to put it right at the top).
Another option is to have a System naming convention that organizes the list somewhat. I generally do [Number of jumps from Sol][Letter of first jump in branch]-[System Name], so it goes 0-Sol, or 1A-Alpha Centauri, or 1B-Barnard's Star, or 2A-Proxima Centauri for a system down the Alpha Centauri line. That way, all the close stuff is at the top, all the far stuff is at the bottom, branches are grouped together, and systems you haven't gotten around to taking a look at and renaming are at the very bottom. That being said, it would be nice to have populated systems highlighted in green or something, especially since I don't always want to use my naming convention.
I do something very similar to this and even a bit further. I use some form of coordinate system so I know where a system is (roughly) on the galaxy map and then systems are sorted in the lost appropriately.
I base it on my sectors and the have a coordinate system going from there based on if the planet is up, down, left or right from the sector seat system.
This also makes each system very easy to find on the Galaxy map and makes everything easier to find in general. Adding a space or more before systems also sort important system to the top of the list which helps.
I was thinking lately about a possible active stealth system.
The idea is to make ship system, that allows ship to completely disappear from sensors (not only active) for some time. During that time cloaked ship cannot engage enemies (eg. no detection, no boarding and no shooting). It could also have a timer (eg. Game would force this ship to decloak after some time), some recharge time (which might use powerplants from the ship, making it less effective in combat for some time) and/or giving the ship jumpshock after exiting.
It would make JP assault and commerce raiding more viable.
This idea is actually quite common in different games, so I wouldn't be surprised if someone already suggested it, but I'm to lazy to read all pages of this thread.
Maybe they don't need to be undetected.
We already have a way to get into an unfriendly system through a lightly defended jump point: Squadron jumping through and then peeling off like a bat out of Hell. (Maybe we should have a "move directly away from target" command, so we can set up to move away in the same direction as the squadron jump offset immediately.) The trick to raiding is getting back out again without getting got, because you have to move all the way up to the jump point to exit the system.
But what if you didn't? What if you could squadron jump with an offset from the outbound JP as well? If the JP has a deep, layered defense then it won't help, of course, but... that's probably fine. It means the defenders have to be separated out to a range where they are not in easy beam support range of each other.
To further help the raiders get out, you could imagine a "jump homing beacon" ship component; a military component that you put on a ship that sits on the destination jump point, and which multiplies the outbound offset limit by 1 + [multiplier]*MAX(1, [component size]/[size of jumping vessel]).
So if you have a 5 thousand ton raider with a jump drive capable of 250 thousand km squadron jump offset, then it would squadron jump in the normal way, run away from the jump point picket, murder some merchant shipping, and come back toward the jump point. If you now have a jump tender sitting on the home side of the jump point with a 5000 ton multiplier 3 jump beacon, the raider could evacuate from a JP offset of 1 million km. With a 2500 ton beacon sitting on the other side, it'd have to get to within 500 thousand km, and with no return beacon, it would have to get to 250 thousand km.
It won't help your raiders if the jump point picket has some missile ships with a fifty million km range and sensor coverage and enough weight of fire to just swat your raider out of the sky sitting 25 million m away from the JP. But in that case the defender has made a strategic decision to expend part of the resources available for the JP picket to protect against raiders rather than build a brick wall for your battle fleet to beat itself silly against when it tries to force the JP in force. Which still is a way for your raider doctrine to impose costs on the JP defense doctrine of the other side.
--- Some random ideas I had:
--- Regarding missile changes, the removal of missile agility ruffled quite a few feathers it seems, but I've given it a lot of thought and I think... after playtesting, that an avenue to reinstate it, IF NEEDED, could be as such:
--- Missile Agility is rebranded to Missile Guidance. It has the same tech line as agility. Mechanically, the rebranded agility scales up with the missile, and the tech line, rather than giving more agility per msp dedicated to it, governs the agility cap. So bigger missiles would have more innate agility, but not more than the cap. Meanwhile, smaller missiles would need to add msp into guidance, and would still end up being capped by the tech. So, basically, if Missile Guidance Cap, the replacement for Missile Agility per MSP, was 16, a missile could never have more than 16 regardless of size or MSP invested, and bigger missiles would have more agility to start with, thus needing less MSP to get the same agility.
[...]
--- Regarding beam ships:
--- It struck me that a form of "Capacitor Bank" might be a helpful thing for diversify beam ship designs. Basically, this component would derive it's efficiency from the Capacitor tech. It would then incur a power requirement, like a beam weapon would, and would charge like a beam weapon too. The capacitor would discharge as part of the beam weapon firing phase, just like a beam weapon would, however, it would distribute it's available energy evenly across all beam weapons that are firing. This would work more or less identically to how power plants distribute their power, following the same priorities. The caveat is that these aren't power plants, but capacitors, and so count as extra capacitors for the purposes of weapon RoF.
--- So for example, a weapon has 25 capacitors, and a RoF of 10s. A single capacitor bank of 25 would give it a 5s RoF instead. Another example, Three weapons with 10 capacitor and a 20s RoF with a single 15 capacitor bank would instead have a 15s RoF each. I'll do an effort post later, in it's own thread. Questions or thoughts are welcome in the meanwhile.
[...]
--- Regarding beam ships:
--- It struck me that a form of "Capacitor Bank" might be a helpful thing for diversify beam ship designs. Basically, this component would derive it's efficiency from the Capacitor tech. It would then incur a power requirement, like a beam weapon would, and would charge like a beam weapon too. The capacitor would discharge as part of the beam weapon firing phase, just like a beam weapon would, however, it would distribute it's available energy evenly across all beam weapons that are firing. This would work more or less identically to how power plants distribute their power, following the same priorities. The caveat is that these aren't power plants, but capacitors, and so count as extra capacitors for the purposes of weapon RoF.
--- So for example, a weapon has 25 capacitors, and a RoF of 10s. A single capacitor bank of 25 would give it a 5s RoF instead. Another example, Three weapons with 10 capacitor and a 20s RoF with a single 15 capacitor bank would instead have a 15s RoF each. I'll do an effort post later, in it's own thread. Questions or thoughts are welcome in the meanwhile.
I do not understand it completely. Are we talking of some sort of ready rack for munitions/energy, that allows for a limited rate of fire increase to levels otherwise unobtainable by current technology levels?
One small thing - i would love for the old "transport bay isnt drop pod bay" distinction to return...
I miss making dedicated drop ships for Marine/Assault forces and big transports that just serve purely as transports.
Yes, the bays have sort of all blurred into one situation going on. The only advantage to drop bays is instant drop, which is only really necessary when a planet is defended. Which usually isn't the case, because you won't invade until you have control of space.
An option to suppress retirement and death notifications for unassigned personnel.
It's fine that the fleet hangs around in space waiting for a new pickup - it'll typically be near a jump point where shipping will presumably enter the system at some point.
- If an escorted fleet no longer meets these criteria, the Escorting fleet will cease escorting and seek a new target - if none is found, the Escort fleet should probably return to a population in-system instead of waiting around in empty space, if available (or a jump point? Or maybe waiting around in empty space is okay in practice?).
I would like to request that a new standing order be added named "Escort convoy" or similar.
The idea of this is to automate assigning escort ships or squadrons to commercial and/or civilian traffic in systems. In particular, I think this would help to eliminate some of the more tedious gameplay related to a certain recently-added spoiler race, which pushes the game in a direction where the options are micromanagement or suffering significant losses, which I don't think is very healthy and is likely to make said spoiler race unpopular with many players.
A fleet with the Escort standing order will, if not presently escorting anything, look for an active fleet of commercial or civilian ships in the system. If an appropriate target fleet is found, the Escorting fleet will execute a Follow order targeted on that fleet until it either leaves the system or is no longer active.
An "active fleet" of commercial or civilian ships meets the following criteria:These criteria prevent an Escort fleet from "escorting" idle ships in orbit and fuel harvesters (which are presumably nearly permanently positioned and should have a dedicated guard force, if any), but will allow escorting of a stabilization ship in addition to more traditional commercial or civilian shipping traffic.
- No military ships in the fleet (to avoid escorting a fleet which already has an escort, presumably).
- Must have an active order (to avoid escorting a fleet which is just sitting idle in planetary orbit).
- If an escorted fleet no longer meets these criteria, the Escorting fleet will cease escorting and seek a new target - if none is found, the Escort fleet should probably return to a population in-system instead of waiting around in empty space, if available (or a jump point? Or maybe waiting around in empty space is okay in practice?).
- If an escorted fleet leaves the system via jump point, the Escorting fleet does not follow them and seeks a new target.
It may be helpful to also add a conditional order, such that if a fleet has no Escort target they can return to a designated position - population, jump point, refuel hub, etc.
I like the idea in principle, but there are some additional complexities. If there are different fleets available to escort, how does the escort determine which one to follow? Largest by tonnage, largest by number of ships, total cost, distance, some combination of the above or perhaps only potential fleets within a certain distance. Maybe the fleet that it could escort for the greatest time.
How do those criteria change if two or more escorts are available - should Escort B become available after Escort A and Escort A is still heading toward a fleet closer to Escort B, does Escort B take over and Escort A looks for a new assignment (to prevent escorts far apart ending up moving to fleets close to the other one due to timing). Probably a few other considerations once I think through it.
Also, those criteria probably change if there is a hostile ship present, plus the escort would have to ignore ships that would leave the system before it could join them, which means checking that for every fleet.
If there is no convoy system for civilians, then there is no point in creating an escort system.
If there is no convoy system for civilians, then there is no point in creating an escort system.
Using the above as a suggestion, maybe a simpler option is the creation of Convoy Waypoints (CW). This is currently thinking out loud, not a final draft.
- A CW would have a destination of either a population or a jump point in the same system, a required tonnage of commercial shipping and a required tonnage of escorts. Perhaps also there could be an acceptable speed range so that new ships don't get slowed down too much by obsolete ones.
- Any qualifying commercial shipping with the same destination for their current order will instead move to the nearest qualifying CW, if that CW is closer than their destination.
- Any military fleets without orders that are flagged as an escort fleet will move to the nearest CW that requires additional escort tonnage (taking account of any ships en route).
- Once everything is assembled, the escorts get formed into a new fleet with a speed equal to the slowest of the commercial ships, flagged as an active convoy escort fleet and given the destination specified by the waypoint.
- The commercial fleets are flagged as being escorted.
- An 'escorted fleet' will ignore its current orders and follow the associated escorts.
- Once the escort fleet reaches its destination, all the associated 'escorted fleets' are unflagged. As they are at their destination, they will return to following their normal orders.
- This allows escorts to move back and forth within each system, probably between pairs of Convoy Waypoints, while the commercial ships are handed off to escorts in the next system if required
- It also means that commercial ships with different final destinations can share the same escorts for parts of their journey
- If the escorts are removed mid-journey (perhaps to engage raiders), the commercial shipping will go back to step 2.
- Conditional Orders would be checked before checking escorts for moving to waypoints to ensure they don't run out of fuel/MSP
If there is no convoy system for civilians, then there is no point in creating an escort system.
Using the above as a suggestion, maybe a simpler option is the creation of Convoy Waypoints (CW). This is currently thinking out loud, not a final draft.
- A CW would have a destination of either a population or a jump point in the same system, a required tonnage of commercial shipping and a required tonnage of escorts. Perhaps also there could be an acceptable speed range so that new ships don't get slowed down too much by obsolete ones.
- Any qualifying commercial shipping with the same destination for their current order will instead move to the nearest qualifying CW, if that CW is closer than their destination.
- Any military fleets without orders that are flagged as an escort fleet will move to the nearest CW that requires additional escort tonnage (taking account of any ships en route).
- Once everything is assembled, the escorts get formed into a new fleet with a speed equal to the slowest of the commercial ships, flagged as an active convoy escort fleet and given the destination specified by the waypoint.
- The commercial fleets are flagged as being escorted.
- An 'escorted fleet' will ignore its current orders and follow the associated escorts.
- Once the escort fleet reaches its destination, all the associated 'escorted fleets' are unflagged. As they are at their destination, they will return to following their normal orders.
- This allows escorts to move back and forth within each system, probably between pairs of Convoy Waypoints, while the commercial ships are handed off to escorts in the next system if required
- It also means that commercial ships with different final destinations can share the same escorts for parts of their journey
- If the escorts are removed mid-journey (perhaps to engage raiders), the commercial shipping will go back to step 2.
- Conditional Orders would be checked before checking escorts for moving to waypoints to ensure they don't run out of fuel/MSP
Just to be clear, does "commercial shipping" here include both state commercial and civilian commercial or just the latter?
Once the mechanics are implemented, state commercial fleets could be flagged to act the same way very easily.
Once the mechanics are implemented, state commercial fleets could be flagged to act the same way very easily.
Love the proposal here, it's a bit more complex than what I originally suggested but a lot more robust and good for roleplay. ;D
Really like this idea to let commercial fleets piggyback on some of the civilian AI and features, that would be a big automation help. One thought: a tweak to the current contract system would be nice so that if the supply at a planet is set to a value greater than the amount currently available on that planet, the civilian AI/system doesn't stall and spam "Fleet was unable to pick up installation" messages - either picking a different contract or ignoring it until it can be filled. This would be particularly helpful in the early game (and especially if player commercial ships can use the same features), for example when moving infra + colonists to a colony in Sol the rate of transport usually exceeds how fast Earth can build infrastructure, requiring manual control of that process.
You mentioned contracts and reminded me how amazing being able to set mineral contracts would be, especially being able to just set a "fill to reserve" contract to maintain reserve levels for populations.
Dice roll research, been listening to a lot of Perun lately, instead of Research Labs giving a fixed amount of RP every five day increment they instead roll for that value to reflect the difficulties real life development programs can run into, potentially even having a chance to suffer a loss of progress.
Also a line in the research tab that shows how much each project costs in terms of wealth.
Dice roll research, been listening to a lot of Perun lately, instead of Research Labs giving a fixed amount of RP every five day increment they instead roll for that value to reflect the difficulties real life development programs can run into, potentially even having a chance to suffer a loss of progress.
--- I do kind of like this idea, however RNG is seldom fun as a mechanic. I think this would be better if the RNG decayed over time. So while projects might hit big setbacks early on, maybe even hit several and hit them often, as time went on the setbacks would be fewer and lesser in scope. However, the chance should never decay to zero and the magnitude never fully decay either.
Idle thought on prototypes
A New Standing Order for "fuel less than 60%" would solve A LOT of headache for me personally.Really? That sounds strange - 50% fuel order has almost always worked for me. And the list is already so long. Hopefully Steve could instead code a "fuel at X%" and a box where you could input the exact percentage. Anyway, you could probably solve your problem by changing how you explore or by bringing tankers and/or fuel depots closer.
Ships set to refuel after reaching 50% fuel will almost never make it home when traveling in a straight line, it's really annoying having to micromanage my exploration ships so much with this issue.
Fuel less than 60%, maybe also 70% would really help with this. I can't imagine this is a difficult change to implement.
A New Standing Order for "fuel less than 60%" would solve A LOT of headache for me personally.Really? That sounds strange - 50% fuel order has almost always worked for me. And the list is already so long. Hopefully Steve could instead code a "fuel at X%" and a box where you could input the exact percentage. Anyway, you could probably solve your problem by changing how you explore or by bringing tankers and/or fuel depots closer.
Ships set to refuel after reaching 50% fuel will almost never make it home when traveling in a straight line, it's really annoying having to micromanage my exploration ships so much with this issue.
Fuel less than 60%, maybe also 70% would really help with this. I can't imagine this is a difficult change to implement.
The stranded explorer happened to me exactly once. What I think has happened in that case is that the ship had finished exploring a body, decided that it would have enough fuel and picked another exploration target that was way out, surveyed it and burned too much fuel on the way to that destination to make it back unassisted.
Generally it is not a problem, as the ships do some sort of random walk and the trip home is way shorter than the course they traveled towards the last destination. But whenever you do surveys 5 jumps away out from your nearest base and the systems along the way happen to be extremely large, things can go wrong.
A New Standing Order for "fuel less than 60%" would solve A LOT of headache for me personally.Really? That sounds strange - 50% fuel order has almost always worked for me. And the list is already so long. Hopefully Steve could instead code a "fuel at X%" and a box where you could input the exact percentage. Anyway, you could probably solve your problem by changing how you explore or by bringing tankers and/or fuel depots closer.
Ships set to refuel after reaching 50% fuel will almost never make it home when traveling in a straight line, it's really annoying having to micromanage my exploration ships so much with this issue.
Fuel less than 60%, maybe also 70% would really help with this. I can't imagine this is a difficult change to implement.
A New Standing Order for "fuel less than 60%" would solve A LOT of headache for me personally.Really? That sounds strange - 50% fuel order has almost always worked for me. And the list is already so long. Hopefully Steve could instead code a "fuel at X%" and a box where you could input the exact percentage. Anyway, you could probably solve your problem by changing how you explore or by bringing tankers and/or fuel depots closer.
Ships set to refuel after reaching 50% fuel will almost never make it home when traveling in a straight line, it's really annoying having to micromanage my exploration ships so much with this issue.
Fuel less than 60%, maybe also 70% would really help with this. I can't imagine this is a difficult change to implement.
I'm honestly unclear how this is possible in normal survey operations. Maybe if you arrive in the target system with just over half your fuel remaining, and due to one or multiple freak accidents of orbital mechanics the distance home might be a bit longer - but that seems really inefficient, if you are reaching a survey target system with only half your fuel you need a closer base of operations or more fuel/more efficient engines in the ship design.
it's 10 systems awayThere's your problem then. That is a really significant distance.
i can't change how i exploreYes, you can and you should because even if Steve agrees with you and adds your requested feature, it will not happen until 2.2 comes out and that is months away still. Meaning that you would have to suffer with this problem you have created for yourself for a long time. There is no way that your explored systems are devoid of minerals so just stop exploring further until your industry can catch up. When you start having problems keeping your survey ships/fleets going - fuel, maintenance and deployment time wise - it's a sign that it's time to simmer down the exploration and instead focus on exploiting the systems you have already surveyed.
Yes, you can and you should
"I'm honestly unclear how this is possible in normal survey operations" my bet is you only explore when absolutely necessary and you've finished turtling,
Yes, you can and you should
Except your only solution is to stop? There is no reason to stop? having to micro 1 trip in 10 to explore more systems isn't a big deal?
I can't afford to expand and change the way i explore significantly and there is no reason to stop?
Your solutions are terrible and you are arguing on pure opinion? the exploration of new systems takes up a good 1% of my mineral use, finding more valuable systems to exploit is well worth that tiny effort and little bit of micro.
"I'm honestly unclear how this is possible in normal survey operations" my bet is you only explore when absolutely necessary and you've finished turtling,
LMAOYes, you can and you should
Except your only solution is to stop? There is no reason to stop? having to micro 1 trip in 10 to explore more systems isn't a big deal?
I can't afford to expand and change the way i explore significantly and there is no reason to stop?
Your solutions are terrible and you are arguing on pure opinion? the exploration of new systems takes up a good 1% of my mineral use, finding more valuable systems to exploit is well worth that tiny effort and little bit of micro.
I'd like to politely request a slight toning-down of the aggressive rhetoric here.
Hi,
Please, everyone, let me know if I'm wrong here but:
ISTR that when a fuel% conditional order is potentially triggered, there is a check that there is a fuel source (of the type specified in the conditional order) within a certain limit (I think it might be 3 or 5 jumps). If there is no suitable fuel source within that limit then the conditional order is not triggered and the ship continues with its normal orders (and the game will not notify you because the conditional order was not triggered). If my memory is correct then adding a 60% or 70% conditional order would still not trigger in your current situation and would not help you.
I would love to see your ship design for a survey ship that can make 10 jumps and still have over 60% of its fuel left, not to mention being expected to survey at least half of any system it finds.
Andy
--- This isn't the SerBeardian discord Josh, we're civil here. I too will ask you to simmer down.
--- This isn't the SerBeardian discord Josh, we're civil here. I too will ask you to simmer down.
I've said nothing bad meanwhile being berated with essentially "get gud" or "play differently" to a simple suggestion to reduce micromanagement?
Me simmer down?
The one argument to what i've said is basically about my tone when replying to someone with status, you can't just say i'm doing something wrong because you don't like that i disagree with you?
If you have arguments as to why we shouldn't have a "if <60% fuel" option in the menu, then i'm all ears! but more repeating of the same 2 solutions is just mind-numbing.
If you have arguments as to why we shouldn't have a "if <60% fuel" option in the menu, then i'm all ears! but more repeating of the same 2 solutions is just mind-numbing.
I think the main "argument", which has maybe not been stated clearly, is that most folks are having a hard time imagining how "if <50% fuel" is not sufficient, which means the argument is that it's simply not necessary. Specifically:
- It's not clear how a survey ship can arrive in a system with significantly more than 50% of fuel remaining (i.e., enough to do meaningful survey work), survey until under 50%, and then not have enough to get back to base if the fuel requirement to get home is significantly less than 50%. In this case, a <50% trigger is adequate.
- It's not clear how, if a survey ship is arriving in a system with marginally more than 50% of fuel remaining, any meaningful survey work can be done. In this case, a <60% trigger (for instance) seems very pointless as it doesn't really seem to enable any useful gameplay. Although "useful gameplay" is of course subjective.
It would probably help if you could show some kind of example to visualize where these cases occur. It sounds from your posts like you're running into case (b), which is what confuses people as it doesn't seem like a lot of useful survey work could be done with such marginal amounts of fuel, but we might be misunderstanding.
In any case, it's worth noting that just because a change is (or should be, or sounds) easy, or the UI seems to have open space, doesn't make a strong argument for Steve to implement it. If Steve made every change that was "easy" and requested by someone, the game would be incredibly cluttered and user-unfriendly (well, more user-unfriendly...). So even though it does look like there is some blank space in the UI, the suggestion still requires careful consideration, and if there is not a consensus that a suggestion is necessary or useful for many or most players, it is unlikely that Steve will implement it (although not impossible, Steve does after all make his own decisions!).
I was thinking maybe there could be something like static ground units that could provide maintenance, refueling and rearming for crafts smaller than 1000 or 500tons. Like that you could more easily make fighter bases than can be done now, and they would be ground side, so a lot more resilient than a station to attacks.While I agree that this might be an interesting option, it flies against Steve's goal of getting rid of as many "special rules" as possible with C# Aurora. The need to protect your facilities is also a good gameplay problem for the player to solve.
One added benefit would be an increase in the use of this kind of smaller patrol ships or corvettes for PPV or patrol, especially in less populated or unpopulated systems. Currently small patrol crafts are really only a flavor choice and other than RP there is no real reason to make them over bigger, 6000-10000 ships for this kind of role in term of effectiveness against actual enemies. It would be nice to have them easier and more practical to use for some jobs where you can sacrifice some combat power.There already exists a good reason to use smaller ships over larger ones and it is specifically maintenance. Since a maintenance facility/station can only service a limited tonnage, it can be better to have two small patrol craft rather than one large ship, especially if the ships patrol independently. Let's say your corvette is 2000 tons and your cruiser is 6000 tons. If you use the latter for system PPV and spoiler patrol, then you need to have maintenance capability in the system for 6000 tons as nothing less suffices. But if you use three corvettes instead, you only need to build up a capacity for 2000 tons while also having thrice the sensor coverage. And in case of an enemy excursion, you can bring the corvettes together to fight as a fleet.
There already exists a good reason to use smaller ships over larger ones and it is specifically maintenance. Since a maintenance facility/station can only service a limited tonnage, it can be better to have two small patrol craft rather than one large ship, especially if the ships patrol independently. Let's say your corvette is 2000 tons and your cruiser is 6000 tons. If you use the latter for system PPV and spoiler patrol, then you need to have maintenance capability in the system for 6000 tons as nothing less suffices. But if you use three corvettes instead, you only need to build up a capacity for 2000 tons while also having thrice the sensor coverage. And in case of an enemy excursion, you can bring the corvettes together to fight as a fleet.Small note, but since C# v1.0 maintenance doesn't work as a limit like that: it adds up the tonnage of all present ships, so three 2,000 ton ships require the same facilities as one 6,000 ton ship. Of course, in this case having a 2,000 ton ship still lowers your minimum requirement for stationing something in the system, while still giving you flexibility to expand it later.
But if bringing 6000-ton maintenance capacity to this system is trivial for my empire, then I'll do that and I do not want a hardcoded rule to hinder me. Maybe my Galactic Empire uses 6000-ton patrol boats.
One thing about fighters is that you can't really easily make forward fighter bases without having to bring either vulnerable stations somewhere for maintenance, refueling and rearming, or ground facility with hundreds of thousands of workers, which isn't exactly feasible for an outpost or forward base, especially near or in enemy territory.
This makes sense for ships, as you need extensive facilities, dockyards and a lot of personnel to maintain them, but for fighters (and maybe FACs?) more limited teams of mechanics should be able to maintain and service them, no?
I was thinking maybe there could be something like static ground units that could provide maintenance, refueling and rearming for crafts smaller than 1000 or 500tons. Like that you could more easily make fighter bases than can be done now, and they would be ground side, so a lot more resilient than a station to attacks.
ie having your survey ships use the "Move to System requiring Gravsurvey" standing order.
One thing about fighters is that you can't really easily make forward fighter bases without having to bring either vulnerable stations somewhere for maintenance, refueling and rearming, or ground facility with hundreds of thousands of workers, which isn't exactly feasible for an outpost or forward base, especially near or in enemy territory.
This makes sense for ships, as you need extensive facilities, dockyards and a lot of personnel to maintain them, but for fighters (and maybe FACs?) more limited teams of mechanics should be able to maintain and service them, no?
I was thinking maybe there could be something like static ground units that could provide maintenance, refueling and rearming for crafts smaller than 1000 or 500tons. Like that you could more easily make fighter bases than can be done now, and they would be ground side, so a lot more resilient than a station to attacks.
Edit : Maybe that should also apply to crafts that are a little bigger too? 2000-3000 tons maybe? Someone correct me if I'm wrong, I don't know much about this, but I'd expect you don't need a huge amount of facilities to maintain small patrol boats.
One added benefit would be an increase in the use of this kind of smaller patrol ships or corvettes for PPV or patrol, especially in less populated or unpopulated systems. Currently small patrol crafts are really only a flavor choice and other than RP there is no real reason to make them over bigger, 6000-10000 ships for this kind of role in term of effectiveness against actual enemies. It would be nice to have them easier and more practical to use for some jobs where you can sacrifice some combat power.
I've read the 60% fuel range topic. I don't plan to add this. The coding is trivial, but I don't want to spend the rest of my life explaining why that condition isn't a typo.
I've read the 60% fuel range topic. I don't plan to add this. The coding is trivial, but I don't want to spend the rest of my life explaining why that condition isn't a typo.
What about Garfunkel's "fuel at x%" option? That would allow people to do the weird settings without you having to answer questions, and it also reduces the clutter in the standing orders window.
What about Garfunkel's "fuel at x%" option? That would allow people to do the weird settings without you having to answer questions, and it also reduces the clutter in the standing orders window.
That's less trivial, due to the extra UI work, and also would seem odd as the only option with a text entry. However, that could be done as part of a more significant overhaul of standing/conditional orders.
Probably the best solution is to have standing order templates, which of course means significantly more work for Steve.
(if (< current-fuel (* 0.3 max-fuel))
(refuel-and-resupply-at (find-nearest-facility 'fuel-transfer))
(if (< maintenance-clock 0.0)
(refuel-resupply-and-overhaul-at (find-nearest-facility 'maintenance))
(let ((targets (take 5 (find-nearest-bodies 'unsurveyed))))
(if (empty? targets)
(travel-to-system (find-nearest-system 'unsurveyed))
(survey-bodies targets)))))
--- As someone who cannot code, does not want to learn it, and hates doing it. I dislike this proposal intensely.
What about Garfunkel's "fuel at x%" option? That would allow people to do the weird settings without you having to answer questions, and it also reduces the clutter in the standing orders window.
That's less trivial, due to the extra UI work, and also would seem odd as the only option with a text entry. However, that could be done as part of a more significant overhaul of standing/conditional orders.
Also worth noting that, without other related changes, it would probably be less popular than anticipated if you have to enter a value every time you set the standing order. Clicking through the same orders for all survey ships, for example, is annoying enough as it is, never mind if we throw some typing on top of it.
Probably the best solution is to have standing order templates, which of course means significantly more work for Steve.
I thought of a way that the "Any% fuel" concept could be included without messing with the UI: have the condition be "Fuel below reserve level". We already have an entry in the ship design window to set the fuel reserve, which is usually only used for tankers and occasionally fuel harvesters. It shouldn't be any problem to add a condition which checks the current fuel against the reserve, we can leave the current X%-based conditions since they are easy to use, and I think it's a lot easier to justify the slot in the conditions list than adding more X% levels.
The only catch is that we need some UI element to let us modify the reserve level on a per-ship basis. Currently, the "Miscellaneous" tab in the "Ship Overview" tab in the Naval Organization window allows customizing the refuel and resupply priority for single ships (which are normally class-based settings), so I don't think it would be an issue to add a line here to expose the fuel reserve level on a per-ship basis.
Overall, it is still some work for Steve but I think this would be a comparatively elegant solution without adding a weird exception to the conditionals or adding completely new UI elements.
Very, very minor request: Please bump the starting age for commanders up to 31.
The 2.0 change to have varied starting ages was great mechanically, but I'm still tired of seeing commanders, colonels, presidents and lead scientists in their early 20s. Especially the last one, not every setting has to be a Marvel movie after all.
Like how you can crtl+click to select multiple systems to move them all on the star map, allow the same to select multiple weapons on a ship, to then move them all to an FC in one go. If that is easy to implement, also allow shift+click to click on a starting and an ending weapon and select all inbetween.
My missile ships have a lot of tubes and often I want to fire a fraction of them. Maybe firing 10/40 now and for the other 30 wait to see if the enemy moves or if there are more somewhere. Maybe the enemy is weaker and only 5 shots are sufficient today. Or I need to divide my fire over exactly 2 targets but my weapons are currently divided over 3 FCs. Because of that I often move them around but this is currently cumbersome.
Not sure if anyone has already suggested this, could we have a reserve level at colonies for fuel and MSP? this would allow automating to reserve levels for forward colony bases. Prevents the scenario where you have to suddenly work out where all of Earth's fuel went and why it is 30b Km away :)
Not sure if anyone has already suggested this, could we have a reserve level at colonies for fuel and MSP? this would allow automating to reserve levels for forward colony bases. Prevents the scenario where you have to suddenly work out where all of Earth's fuel went and why it is 30b Km away :)
I encountered the same issue, and while waiting for an implementation, I found a simple workaround.
Basically, I create a flow from Earth to a pickup base in orbit through a simple loop of orders and tankers/supply ships. This way, I can set the minimum amount of fuel and MSP to be stored in orbit, creating an emergency vault in case things go out of hand. Please note that I use SM to expand and create such orbital structure, and as I use it as a fix for a game issue, I don't consider it a cheat.
However, the downside is that it could still be vulnerable and potentially blown away. To enhance its protection, you can consider turning it into a ship and adding some armor layers, which would create an extra interesting strategic challenge in ensuring its safety.
It's worth noting that now I have moved a bit away from this and I try to tweak the routes to ensure they never exceed my annual production. It becomes challenging when you add another main HUB to Earth, and distributing nodes while keeping all systems operational becomes a fun and engaging aspect of the game for some.
Not sure if anyone has already suggested this, could we have a reserve level at colonies for fuel and MSP? this would allow automating to reserve levels for forward colony bases. Prevents the scenario where you have to suddenly work out where all of Earth's fuel went and why it is 30b Km away :)
I encountered the same issue, and while waiting for an implementation, I found a simple workaround.
Basically, I create a flow from Earth to a pickup base in orbit through a simple loop of orders and tankers/supply ships. This way, I can set the minimum amount of fuel and MSP to be stored in orbit, creating an emergency vault in case things go out of hand. Please note that I use SM to expand and create such orbital structure, and as I use it as a fix for a game issue, I don't consider it a cheat.
However, the downside is that it could still be vulnerable and potentially blown away. To enhance its protection, you can consider turning it into a ship and adding some armor layers, which would create an extra interesting strategic challenge in ensuring its safety.
It's worth noting that now I have moved a bit away from this and I try to tweak the routes to ensure they never exceed my annual production. It becomes challenging when you add another main HUB to Earth, and distributing nodes while keeping all systems operational becomes a fun and engaging aspect of the game for some.
I guess this is also more viable once the fix goes in to orders to transfer fuel/supplies to the structures so I can automate the resupply process. Still would have to wait till 2.2 though. How do you currently setup your orders with the structure? I originally went for structures because the capacity was fixed but the issues I had with automating it was annoying :)
Very, very minor request: Please bump the starting age for commanders up to 31.
The 2.0 change to have varied starting ages was great mechanically, but I'm still tired of seeing commanders, colonels, presidents and lead scientists in their early 20s. Especially the last one, not every setting has to be a Marvel movie after all.
Add a toggle to each colony, similar to the one for what civilian colonist ships do, for what to do with minerals on a planet. Options: Import, nothing, export. Freighters should then try to pick up minerals once there is a full hold of minerals on a colony.
Since this is much easier than manually setting up this sort of thing, perhaps have it require something on the colony, eg. a cargo shuttle station.
A few changes to decrease the amount of changes of dominant terrain that planets have.
My current race homeworld has a pretty high eccentricity (0.3, periapsis of 164m, apoapsis of 298m) and I get this set of updates over a 1.6 year long year:Off-Topic: show
So I was trying to think of some rules to decrease this chance. Here are some ideas:
- Hydro > 95%: Always Archipelago (change all other terrains to have 95% as the max hydro) (potentially break it up based on ox% and/or temperature and/or tectonic into XX Archipelago)
- If you have the option for one of the new, larger temperature variance, biomes, take it (this prevents flip-flopping between eg. Desert and Cold Desert, and issue I've had in a previous game)
- If a terrain is viable for less than 10% of the time at the peri- or apoapsis of the orbit, don't change to it (to prevent a planet from going Barren each closest approach for a short time)
I would propose a diffrent solution. A planet dominant terrain can be calculated once a year, taking into account an average of that year. (for example one sample every 30 days) This way you both solve the constant change of terrain on some planets, and make terraformation (both natural and artificial) a slower, more "accurate" process.This is a good suggestion. There does need to be some care taken for what moment and period to do this with. If you do it once per terran year, then it could still have changing results for a planet with an orbital period of 1.5 years: you could have a different result when you get the top 1 year of it vs. the bottom 1 year. If you instead do it once per local year, then inner planets are much more responsive to terraforming. Perhaps do it once per terran year, but keep a log of 30 day intervals for the larger of a terran year or the orbital period?
When creating a race, an option to create a completely new rank structure, i.e. Custom Ranks. And then you get to fill in the blanks.
Playing today I was comparing stats for laser vs one shot railgun and wondering why anyone would bother building lasers apart from the possibility of putting them on turrets.
I read that railgun charge time would not decrease with shot count in 2.2 which if I understand correctly will make them slower firing than lasers but still smaller if shot count is low enough.
Hi All,
I don't know if this has been mentioned before (I couldn't see it, apologies if i've missed it) but it's something I'd love to see added.
It'd be great to have the ability to expend ships as targets in order to test out new weapons systems, especially in the early game before you encounter NPR's.
It'd add some great RP for me as I find I don't always know how well weapons function until i provoke a fight with an NPR, not to mention the RP of fleet manouvers/exercises.
I thought this could be achieved by either changing the abandon ship function to a self destruct option and adding a seperate abandon ship where the crew evacuate but the ship remains intact though non-operational.
Or alternatively, a new option added in ship designer to create a ship with 0 crew but cannot move or use non-automated systems (such as potentially CIWS). This could even allow the designing of custom target hulls.
It was just an idea for adding something a bit interesting but hopefully not an enormous amount of work. I'm sure it's much harder than it sounds but thought i'd share the idea!
Quote from: Skip121 link=topic=13020. msg165816#msg165816 date=1694783712Hi All,
I don't know if this has been mentioned before (I couldn't see it, apologies if i've missed it) but it's something I'd love to see added.
It'd be great to have the ability to expend ships as targets in order to test out new weapons systems, especially in the early game before you encounter NPR's.
It'd add some great RP for me as I find I don't always know how well weapons function until i provoke a fight with an NPR, not to mention the RP of fleet manouvers/exercises.
I thought this could be achieved by either changing the abandon ship function to a self destruct option and adding a seperate abandon ship where the crew evacuate but the ship remains intact though non-operational.
Or alternatively, a new option added in ship designer to create a ship with 0 crew but cannot move or use non-automated systems (such as potentially CIWS). This could even allow the designing of custom target hulls.
It was just an idea for adding something a bit interesting but hopefully not an enormous amount of work. I'm sure it's much harder than it sounds but thought i'd share the idea!
Totally quote this idea, I know It can be done via SM, but having It embedded directly as option in the game would be great under all points of view.
Just an option to create at shipyards any ship as a target test with 0 crew in order to test missiles and beam weapon, eventually the ship can be tug away in the space before the test.
Exactly! Using SM mode to do it feels a bit sub-optimal if there's any possible way of embedding the function as a feature.
I play manual commander assignment.
In the commander assignment interface, there is a checkbox for available ships, which cuts the list to ships without commanders.
Would be nice if there was similar for the list of commanders, i.e. a checkbox which cuts the list of commanders to unassigned only.
When using limited research administration can we get an increase in game start scientists. I love the way it slows everything down however I keep running into the issue that there simply are not enough scientists to utilize all the research labs, especially in higher population game starts. Current work around is simple to just SM in some more but an automatic scaling factor would be nice
When using the Limited Research Administration option, the chance of military academies generating scientists will be increased from 4% to 5% (and from 8% to 10% if the Academy Commandant is a scientist).
Is there not already scaling for the starting number?
Is there not already scaling for the starting number?
It should scale the same, since your starting commanders are generated based on the same rules AFAIK.
When using limited research administration can we get an increase in game start scientists. I love the way it slows everything down however I keep running into the issue that there simply are not enough scientists to utilize all the research labs, especially in higher population game starts. Current work around is simple to just SM in some more but an automatic scaling factor would be niceStarting scientists should scale based on number of starting Academies.
I got confused by that too, what he means is can he have an additional scaling factor if the limited research box is ticked (the one where it limits how many labs a scientist can control).
It doesn't scale properly with high population conventional starts.
Some examples all Jan 1st new game starts with the only changes being population, conventional empire, and limited administration
My point is that starting scientists (commanders) do scale... but it's scaling based on starting Military Academies.
So the root cause problem here is that number of starting Military Academies don't scale well with population (in either conventional or normal starts).
Even with insane populations it only goes to 2 starting Military Academies for normal and 1 for conventional.
Workaround is to put in more Military Academies manually during setup.
Would it be possible to mark some colonies as "No governor required"? Even if you have just a single DST on a colony it is listed as requiring a level 1 civilian administrator. I never put governors on my listening posts, which means that they often clutter the population view in the commander window, thus making it harder to figure out if any proper colonies are lacking a governor.DST colonies are the punishment posts.. :)
Maybe a checkmark to prevent assigning a governor and setting the required administrator level to 0?
Would it be possible to mark some colonies as "No governor required"? Even if you have just a single DST on a colony it is listed as requiring a level 1 civilian administrator. I never put governors on my listening posts, which means that they often clutter the population view in the commander window, thus making it harder to figure out if any proper colonies are lacking a governor.
Maybe a checkmark to prevent assigning a governor and setting the required administrator level to 0?
Is there a way to automatically rename all bodies in a system according to a naming theme, all at once? I can't figure out exactly what the buttons Rename Body All and Rename Sys All do, but they seem to just rename either the single body or the system, and you have to type in a new name. I've been renaming the bodies in major systems manually, but it's getting to be too much as my rate of expansion increases.
Maximum speed limiter for Auto-turns.
With the smaller increment length selected the turns go extremely fast (atleast in early game). Also the turn-rate of auto-turns depends on your computing power.
I wish there would be a check box where one could limit the minimum time between turns to some value (100ms? 200ms? 500ms? 1sec?) so it would not be so hyper fast and would run at even, predictable pace.
In my current campaign, I have been using scout fighters on my survey ships to check planets for any hostile aliens before risking my valuable survey ships. I have noticed that when the survey ship recovers the fighter, if the fighter has very low fuel the conditional refueling order is triggered and the survey ship (which can easily refuel the fighter and has lots of fuel left) will turn for home to refuel.
Suggestion: Conditional orders such as "Fuel less than X%" should not include parasites in hangars when evaluating the condition.
It works, but also leads to certain drawbacks like the colony having the conquered political status, the need for a policing force, and potential unintended tech transfers.
Hi All,
I don't know if this has been mentioned before (I couldn't see it, apologies if i've missed it) but it's something I'd love to see added.
It'd be great to have the ability to expend ships as targets in order to test out new weapons systems, especially in the early game before you encounter NPR's.
It'd add some great RP for me as I find I don't always know how well weapons function until i provoke a fight with an NPR, not to mention the RP of fleet manouvers/exercises.
I thought this could be achieved by either changing the abandon ship function to a self destruct option and adding a seperate abandon ship where the crew evacuate but the ship remains intact though non-operational.
Or alternatively, a new option added in ship designer to create a ship with 0 crew but cannot move or use non-automated systems (such as potentially CIWS). This could even allow the designing of custom target hulls.
It was just an idea for adding something a bit interesting but hopefully not an enormous amount of work. I'm sure it's much harder than it sounds but thought i'd share the idea!
When I'm playing the game it feels like some of the stuff I enjoy especially with ground combat units unlocks a bit "too late" or cost a bit too much RP to be able to play around with in primitive or conventional starts until your already in the "mid game" or exploration phase. And for no real logical or good reason that I can think of at least.
For example stories where you just manage to get to space proper and find alien ruins on Mars you need to first put 5000rp into both Construction Equipment and Xenoarcheology Equipment before you can even design ground units to start exploring them.
Another thing I think feel odd is the boarding combat stuff (5000 RP for Boarding Combat Capability + 4000 RP for Troop Transport Bay + 6000 RP for Boarding Bays = 15k RP).
Not to mention the fighter weapons (3 x 5000RP) that have lots of potential for early game fun if they were balanced properly so they actually have a decent chance to hit ground forces / to damage, and so that AA is not super binary like nothing... nothing... nothing... all ground support fighters slaughtered.
Then we also have the Salvage Module (5000RP). Do I really need the same amount of research as developing jump drive theory in order to know how to dismantle an enemy faction space station I destroyed in orbit of Earth?
The only logical reason I can think of limiting these to later in the game is to not overload new players with too much information/stuff right away, but let's be honest here... Auroroa 4x was never designed to be friend to new players to begin with ::)
Looks like Steve is on a roll this week.
I made that suggestion some time ago, but I never got an answer to it (http://aurora2.pentarch.org/index.php?topic=13150.0), so I'll try my chances one more time.
We've all seen military ships just stay in place while exchanging beam fire with planetary defense. Or your beam fighters stay in place while attacking stationary enemy ship and taking hits. This makes beam combat sketchy. You would make waypoints so your ships would keep moving to evade enemy shots. it's especially problematic with fighter swarms.
I'm suggesting to make ships participating in combat to be treated as if they are going at full speed, regardless of them moving or standing in place.
Does anyone actually use Training naval admins? I feel like it is too much micromanagement so most people avoid it, but maybe people do use it and we just don't talk about it much?
Suggestion: Change Training Admin Command to give 0.25 Crew Training and 0.25 Fleet Training, and eliminate the training behavior for fleets under this type of command.
This would eliminate micromanagement and make Training commands worth using, plus it would create some jobs for my admirals with Crew Training and no other useful skills. If we still want to have access to the current mechanic (or better, the old VB6 mechanic?) it could be re-implemented as an order or standing order.
Does anyone actually use Training naval admins? I feel like it is too much micromanagement so most people avoid it, but maybe people do use it and we just don't talk about it much?
Suggestion: Change Training Admin Command to give 0.25 Crew Training and 0.25 Fleet Training, and eliminate the training behavior for fleets under this type of command.
This would eliminate micromanagement and make Training commands worth using, plus it would create some jobs for my admirals with Crew Training and no other useful skills. If we still want to have access to the current mechanic (or better, the old VB6 mechanic?) it could be re-implemented as an order or standing order.
I use them religiously. Getting rotated through the training and overhaul fleets before being released for active duty is part of my ship production pipeline. I think it makes sense for there to be a major advantage to having well trained crews, but for that to take a little bit of admin to arrange.
This is fair. My thing is more, I want to have a job for my admirals with Crew Training and very little else + a more thematically appropriate command type for reserve/training fleets, but I hate the micro and resource use of the current training mechanics. So my idea is to have the Training HQ give a passive bonus, and then have the current training mechanic as an order type that gives x2 boost or similar to the training rate in exchange for the micro + resource usage.
While Steve is apparently working on the refit costs section I thought Id bring up adding a time to refit section to that screen. Personally I usually don't particularly care about the cost to refit something, I mostly care about the time it'd take. Building a brand new ship can take a long time, especially if you dont have components built for it. Refitting something to get a ship with similar capabilities can be quicker than building a new ship. Unless it's not which I'd like to know. If some thing costs a lot to refit but takes less time than building the class from scratch I'd strongly consider doing the refit to save time. So it's a useful metric and having it shown on the screen would be awesome. Thanks!
Yes, I agree that the more fun parts of ground forces are currently limited by high research costs. I think I already knew that without consciously registering it :)
I'll take a look at those costs.
That said after giving it some reflection I probably would have left some of the Superheavy techs untouched, and I was pretty fine with the Powered Infantry Armour (especially Heavy) being expensive as I see it as more or less Mecha/Spacemarines stuff in RP which IMO makes sense unlocking later.
I also missed suggesting that HQs design costs do become a bit silly if you want to make large primitive military OOBs (like spending 20-40% of wealth on ground forces) where you end up needing 1000-2000 RP research unlocks for the HQs even without extra armor for them.
The terrain modifiers still make the units with them a lot more expensive, so you can't put many on a unit . You have to build the units for the planet so your offensive units can't really use them as the time taken to build an offensive army means you really need to have been building it before the target is available. They can be nice on defensive units as you know the terrain , or small units made to knock over outposts on minor planets
Though I do agree that the infantry armor didn't really need a cost reduction, I already used that one regularly. However I am enjoying the cheaper research costs for the terrain capabilities as I never used them before but now they are so accessible, why not? ;D
want to make large primitive military OOBs (like spending 20-40% of wealth on ground forces) where you end up needing 1000-2000 RP research unlocks for the HQs even without extra armor for them.
Though I do agree that the infantry armor didn't really need a cost reduction, I already used that one regularly. However I am enjoying the cheaper research costs for the terrain capabilities as I never used them before but now they are so accessible, why not? ;DThe terrain modifiers still make the units with them a lot more expensive, so you can't put many on a unit . You have to build the units for the planet so your offensive units can't really use them as the time taken to build an offensive army means you really need to have been building it before the target is available. They can be nice on defensive units as you know the terrain , or small units made to knock over outposts on minor planets
That said after giving it some reflection I probably would have left some of the Superheavy techs untouched, and I was pretty fine with the Powered Infantry Armour (especially Heavy) being expensive as I see it as more or less Mecha/Spacemarines stuff in RP which IMO makes sense unlocking later.
As long as boarding capability is locked behind the first level of Powered Infantry Armour, then I think it should be very accessible, but I would be fine with later tiers being more expensive.Oh it is??!!! I never actually noticed that because I always get the Powered Infantry Armour as my first tech in Ground Combat :o
Words of wisdom
Also, it would be nice to be able to import/export the naval admin command hierarchy, since this is also another big game setup step.
Not sure to report this as a bug or a feature request. According to this post: http://aurora2.pentarch.org/index.php?topic=8495.msg104912#msg104912, "Ground units of species with certain types of home world may gain capabilities for free". I have not done the testing to see if this is implemented behind the scenes, but in a recently created game with a player race that has a home world of the desert mountain type, when creating ground units I still need to research and pay to apply the desert and mountain capability on ground forces.
If it is implemented behind the scenes, then it can be easy enough to remember if you only have one race, but it becomes more complicated if you conquer and integrate a different race with, say, a jungle home world and start building ground forces with them to mix into the main army.
If this is already implemented, I would like to suggest an interface update to reflect if a particular ground unit already has a terrain specialty, and if it is not, then perhaps a check could be made to award the relevant techs for free and allow free updates with the relevant terrain specialties.
Steve, in the class design window, the engine storages are not in size order and that is counter-intuitive when you have select different storages to fit the tonnage.
It is actually standard-large-very large-ultra large and then small-tiny-fighter-minimal. Can you make instead from the bigger to the smaller?
EDIT: Same goes for maintenance storage bays
Oh, and while we're at this, I'd once again like to request that missile warheads use square-root scaling like power plants currently do. The math behind decoys right now means that larger missiles can only break through missile defences at similar rates as smaller missiles by having smaller warheads relative to their size. And missile warheads are anaemic as is!
Something like warhead strength = ((warhead size in MSP)/0.25)^0.5 * (warhead size in MSP) * (warhead strength per MSP)?
Oh, and while we're at this, I'd once again like to request that missile warheads use square-root scaling like power plants currently do. The math behind decoys right now means that larger missiles can only break through missile defences at similar rates as smaller missiles by having smaller warheads relative to their size. And missile warheads are anaemic as is!
Something like warhead strength = ((warhead size in MSP)/0.25)^0.5 * (warhead size in MSP) * (warhead strength per MSP)?
I think there's something to this. I've noticed the same thing when trying to design size 10 or 12 ASMs. By the time I add enough penaids to offset the smaller volley size due to the larger missiles, the average damage per MSP tends to go down.
Reinforcement Building or feature on existing recruitment ground force building.
I posted this months ago but with all the activity i'm going to chance my arm again.
Could there be a new building or feature in the ground force units building to slowly reinforce existing ground units stationed on the planet with the building.
The current reinforcing mechanics would stay in place and be crucial in reinforcing front line positions fast.
But more for peacetime or light spoiler engagements. The ability to have a building set to reinforce at a trickle speed to bring armies back up to full strength over time would be a nice QOL improvement.
Multiple buildings speed up the process but have diminishing returns. This would allow for the creation of recruitment worlds where dedicated reinforcement armies go back to resupply and be ready for the next large scale fast reinforcements, this would save having to rebuild new reinforcement armies each time.
It could be that the reinforcement building is "loaded" with a new (2. 2) organization or template and in the background has every unit already built in a sort of ghost reinforcement unplayable army. this way when you land your real army on the planet the two armies react the same way as they do now just at a much slower rate.
Population of a body could also be a factor in reinforcement speed.
One thing to keep in mind is that even if larger missiles have lower damage per MSP due to mounting penaids, etc. the idea is that they will still deliver more damage per salvo due to all those penaids making it harder to kill them. Whether this idea works in practice is something we need to figure out with a lot of playtesting since all of these new missile options are new and not yet well understood.
I do like the idea in concept, just think we need to get more data as a playerbase before we start making more changes to missiles. :)
One thing to keep in mind is that even if larger missiles have lower damage per MSP due to mounting penaids, etc. the idea is that they will still deliver more damage per salvo due to all those penaids making it harder to kill them. Whether this idea works in practice is something we need to figure out with a lot of playtesting since all of these new missile options are new and not yet well understood.
I do like the idea in concept, just think we need to get more data as a playerbase before we start making more changes to missiles. :)
They don't. This can be checked mathematically. Consider a 4.0 MSP missile with 1.5 MSP of payload (so ECCM, one decoy, and 0.75 MSP of warhead) that needs four AMMs or gauss shots to kill. To maintain the same penetration rate (i.e., the same fraction of salvos make it through defences), an 8.0 MSP missile should need twice as many AMMs or gauss shots to kill. Because of how decoys scale, this needs an additional three decoys.
But an 8.0 MSP missile will only have 3.25 MSP of payload (after accounting for increased engine size efficiency), so adding three more decoys will imply 1.0 MSP of warhead, which is ~50% less warhead per MSP of missile compared to the 4.0 MSP missile. If you choose to add only two extra decoys to conserve warhead size per MSP, a smaller fraction of the salvo will penetrate defences, leading to lower total damage. And this isn't even accounting for multiple warheads, which are brutal towards additional decoys.
Hello,
I would like to suggest the features 'Auto-Construct', 'Auto-repair' 'Auto-scrap' '
Currently we have auto refit, however if we were to extend the auto nature to scrapping, constructing and repairing it would greatly reduce clicks needed for say creating a large scale fleet of FAC or any other vessel that you want to construct, it would also allow you to set auto repair and have your entire fleet be repaired over time with no additional clicks required!.
I submit this suggestion because my arms hurt and so do my wrists, also because its relatively atleast from my view easy to implement as auto-refit has already been implemented and it uses the same window and interface.
Also, with the ground unit terrain type table by Nuclearslurpee in mind (link is http://aurora2.pentarch.org/index.php?topic=13369.msg166544#msg166544), I propose new terrain type specializations.
Amphibious, applies to; Archipelago, Jungle, Rainforest and Swamp.
Forest, applies to; any Forest/Forested terrain, Taiga and Sub-Tropical Terrains, and is infantry only.
and Flatlands, applies to; Arid, Barren, Chapparal, Cold Desert, Cold Steppe, Desert, Grassland, Hot Desert, Ice Fields, Savannah, Steppe, Subarctic and Tundra.
Hello,
I would like to suggest the features 'Auto-Construct', 'Auto-repair' 'Auto-scrap' '
Currently we have auto refit, however if we were to extend the auto nature to scrapping, constructing and repairing it would greatly reduce clicks needed for say creating a large scale fleet of FAC or any other vessel that you want to construct, it would also allow you to set auto repair and have your entire fleet be repaired over time with no additional clicks required!.
I submit this suggestion because my arms hurt and so do my wrists, also because its relatively atleast from my view easy to implement as auto-refit has already been implemented and it uses the same window and interface.
I would love to be able to queue up a number of ships for a shipyard and just have the shipyard start construction as slips become available. Doesn't even need to be an endless feature, preferably not actually, I just want to be able to queue up a dozen frigates to expand my navy and not have to think about how many of the number I've planned I've got now one has rolled out of dock.
Also, with the ground unit terrain type table by Nuclearslurpee in mind (link is http://aurora2.pentarch.org/index.php?topic=13369.msg166544#msg166544), I propose new terrain type specializations.
Amphibious, applies to; Archipelago, Jungle, Rainforest and Swamp.
Forest, applies to; any Forest/Forested terrain, Taiga and Sub-Tropical Terrains, and is infantry only.
and Flatlands, applies to; Arid, Barren, Chapparal, Cold Desert, Cold Steppe, Desert, Grassland, Hot Desert, Ice Fields, Savannah, Steppe, Subarctic and Tundra.
Add a tech series for "Maximum Sorium Harvesting Diameter", similar to the current "Maximum Orbital Mining Diameter" techs.
Obtaining fuel from gas giants is far too easy right now, and it's basically impossible to run them dry since they spawn with millions of tons of sorium. This would reduce the fraction of gas giants that are exploitable in the early game, and spur redevelopment in the mid game as higher-quality sorium reserves within your territory become exploitable.
Add a tech series for "Maximum Sorium Harvesting Diameter", similar to the current "Maximum Orbital Mining Diameter" techs.
Obtaining fuel from gas giants is far too easy right now, and it's basically impossible to run them dry since they spawn with millions of tons of sorium. This would reduce the fraction of gas giants that are exploitable in the early game, and spur redevelopment in the mid game as higher-quality sorium reserves within your territory become exploitable.
I'm not a fan. I already find it a bit tricky to find a sorium-bearing gas giant that is in the right place with sufficiently high accessibility, especially with Raiders as this adds a requirement that the gas giant be in a system which can support a defensive force.
Perhaps an alternative would be to reduce the amount of sorium so that it is possible to run these gas giants dry in a reasonable time frame?
Add a tech series for "Maximum Sorium Harvesting Diameter", similar to the current "Maximum Orbital Mining Diameter" techs.
Obtaining fuel from gas giants is far too easy right now, and it's basically impossible to run them dry since they spawn with millions of tons of sorium. This would reduce the fraction of gas giants that are exploitable in the early game, and spur redevelopment in the mid game as higher-quality sorium reserves within your territory become exploitable.
I'm not a fan. I already find it a bit tricky to find a sorium-bearing gas giant that is in the right place with sufficiently high accessibility, especially with Raiders as this adds a requirement that the gas giant be in a system which can support a defensive force.
Perhaps an alternative would be to reduce the amount of sorium so that it is possible to run these gas giants dry in a reasonable time frame?
Suggestion: The "Copy Class" button in the Class Design window should provide a pop-up dialog asking the user for the name of the new class.
I can virtually guarantee that no one plans to use "Class Name - Copy" as the actual class name, so why not eliminate an extra button click?
Suggestion: The "Copy Class" button in the Class Design window should provide a pop-up dialog asking the user for the name of the new class.
I can virtually guarantee that no one plans to use "Class Name - Copy" as the actual class name, so why not eliminate an extra button click?
I'd rather not, a lot of the time I don't know what name I'll give the new class and come up with it while I design/make modifications to the copy class. This would make that process quite irritating as I'd just give it a placeholder name anyways.
I suggest a simple terraforming display info on the environmental tab, which says "terraforming devices present (yes) or (not)".
This is because when you have multiple populated colonies across the universe or inside a system and you want terraform many (albeit not all of them) it is hard to remember in which body you have already moved terraforming devices so you have to always switching between tabs to recall that.
From long professional experience and sufferring importing data files never ever use CSV with a , seperator someone will always break it | seperated usually works although I have encountered a mistyped pipe in someones name breaking an import in the past
People screw up JSON and XML files all the time too! I have had national database updates broken because someone found a clever way to put invalid data into their JSON file which broke the process, not a deliberate thing just the way data entry works. Or because the XML/JSON was badly specified and then could not be altered as it was legally mandated in the broken format. I suggested pipe seperated as it is CSV with a different seperator and one which is harder to break. Loading JSON files can also be fairly slow depending on the data volume so for live access to data systems Database are the standard for a reason, none of the organisations I work for or talk too have any plans to abandon databases for storage and operation, we get data submission via JSON and similar but that is transferring between organisations with seperate databases
I suggested CSV simply because it is used elsewhere in Aurora so Steve, I presume, is already comfortable working with the format. I agree it is not a very good format but it is easy. For my money, Aurora would benefit from moving away from a DB model and using JSON files or some other relatively robust, readable format to store all the game data, but obviously I don't expect Steve to do all that work while the current system works perfectly fine for our needs. :)
When attacked by missiles and no hits were scored, I still received a report of the damage per hit. That seems like intel I shouldn't get, considering no warhead detonation contacts occur.
If the missiles explode, there should be warhead detonation contacts, shouldn't there? But you only get those for the missiles that actually make contact. (At least for regular missiles, I haven't seen laser missiles yet.)When attacked by missiles and no hits were scored, I still received a report of the damage per hit. That seems like intel I shouldn't get, considering no warhead detonation contacts occur.
I think the idea is that if the missiles explode, you can get readings of how big the boom was even if they don't actually hit anything.
This is recalling a previous suggestion here (http://aurora2.pentarch.org/index.php?topic=13020.msg161588;topicseen#msg161588), but I think it is relevant with the changes to missile combat making missiles more of a featured system.
Suggestion: Make ground unit racial attack dependent on a dedicated tech line and independent of weapons tech lines.
Alternative: In addition to current techs, make ground unit attack also improve based on missile warhead, meson caliber, and optionally Gauss ROF and/or HPM caliber technologies.
Rationale: The main reason for this suggestion, which I gave in the linked post as well, is that currently ground unit attack only improves if you research certain weapon techs - specifically, only lasers, railguns, plasma, and particle beams will affect ground unit attack. This is a notable nerf to any race which wants to use missiles, mesons, Gauss, and HPM as it forces these races to research the former types of weapons even if they might not want to. Why should a race that uses missiles + Gauss be penalized for that choice or else forced to research a weapon type that may not match their roleplay philosophy?
I consider this particularly timely in light of the recent improvements to missile combat, if we want missiles to be more widely used and viable it does not make sense to nerf missiles on the strategic level (especially since missiles are already strategically the most difficult weapon type, research and logistics-wise) by having this negative side-effect for ground units. Furthermore, the distinction is arbitrary and makes no sense - many ground unit weapons can be modeled as missiles (ATGMs, SAMs, MLRSs, strategic bombardment weapons, etc.) so why should missile warhead tech not improve missile-based ground weapons. One might make the argument that spaceborne missiles are nuclear weapons and that tech should not affect ground force weapons, to such people I ask who are you to judge me for my choice of wartime atrocities? :)
I would prefer making ground unit attack dependent on a dedicated tech line, because it: (1) is more transparent to the player IMO, (2) gives ground combat researchers something to do at higher tech levels, and (3) makes the balance of ground unit attack/armor accessible to DB modders. However, if it would be easier or preferred by Steve/the playerbase I would be fine with seeing missile and meson tech lines able to contribute to ground forces. Gauss and HPM could also contribute but I can see sensible lore-based reasons why they might not so I list them as optional.
That sounds overcomplicated to me to be honest.This is recalling a previous suggestion here (http://aurora2.pentarch.org/index.php?topic=13020.msg161588;topicseen#msg161588), but I think it is relevant with the changes to missile combat making missiles more of a featured system.
Suggestion: Make ground unit racial attack dependent on a dedicated tech line and independent of weapons tech lines.
Alternative: In addition to current techs, make ground unit attack also improve based on missile warhead, meson caliber, and optionally Gauss ROF and/or HPM caliber technologies.
Rationale: The main reason for this suggestion, which I gave in the linked post as well, is that currently ground unit attack only improves if you research certain weapon techs - specifically, only lasers, railguns, plasma, and particle beams will affect ground unit attack. This is a notable nerf to any race which wants to use missiles, mesons, Gauss, and HPM as it forces these races to research the former types of weapons even if they might not want to. Why should a race that uses missiles + Gauss be penalized for that choice or else forced to research a weapon type that may not match their roleplay philosophy?
I consider this particularly timely in light of the recent improvements to missile combat, if we want missiles to be more widely used and viable it does not make sense to nerf missiles on the strategic level (especially since missiles are already strategically the most difficult weapon type, research and logistics-wise) by having this negative side-effect for ground units. Furthermore, the distinction is arbitrary and makes no sense - many ground unit weapons can be modeled as missiles (ATGMs, SAMs, MLRSs, strategic bombardment weapons, etc.) so why should missile warhead tech not improve missile-based ground weapons. One might make the argument that spaceborne missiles are nuclear weapons and that tech should not affect ground force weapons, to such people I ask who are you to judge me for my choice of wartime atrocities? :)
I would prefer making ground unit attack dependent on a dedicated tech line, because it: (1) is more transparent to the player IMO, (2) gives ground combat researchers something to do at higher tech levels, and (3) makes the balance of ground unit attack/armor accessible to DB modders. However, if it would be easier or preferred by Steve/the playerbase I would be fine with seeing missile and meson tech lines able to contribute to ground forces. Gauss and HPM could also contribute but I can see sensible lore-based reasons why they might not so I list them as optional.
I think this proposal got some legs, and I will incorporate it into my overall thinking to explore the possibility of a comprehensive overhaul of the ground unit research tree. The recent revision of ground units has brought to light potential limitations in the existing system as while we updated the ground units the tech tree is still anchored to the past IMHO.
In VB6, due to the composition of the ground units, there was a justified need to link several units to the research table. While I'll delve into this later, it was understandable but may not make much sense, especially when considering the need to research construction module to construct an engineer unit.
Considering that we already possess knowledge of engineering, it seems redundant to have to research it again simply to build a unit. With the new update system, you have the option to either design a new unit after discovering it and continually updating it, or you can auto-research all units by SM (System Manager) the relevant research and then progress. This aligns with my current approach, as I find it puzzling that we lack prior knowledge of these things, while I understand the needs of having to research a blueprint.
In conclusion, I would appreciate a system of "Upgrades," similar to the one proposed by nuclear, that enhances existing specialization rather than adhering to the current model. Ideally, we could have immediate access to all "military" units (I will still be open to researching construction and other elements for gameplay reasons).
Ideally, after selecting a unit, the unit composition could be presented as a series of panels, akin to the specialization ones, where you can decide on factors like Armor (S, M, L, XL), weapon base (kinetic, laser, etc.), and so on.
For instance, you could have a Medium Infantry with Forest terrain specialization, equipped with missiles as its primary weapon. How they use the missiles? Well we have already the CAP, AT, AV, and more, so that won't be a problem. Eventually, to extend this concept, you could also permit the inclusion of extra modules (similar to vehicle design) in all designs, further enhancing customization.
Naturally, researching the corresponding technologies would also contribute to the unit's differentiation, making ground units even more intriguing as we encounter similar dilemmas faced when designing ships.
Alternative: In addition to current techs, make ground unit attack also improve based on missile warhead, meson caliber, and optionally Gauss ROF and/or HPM caliber technologies.I'm sure this has been brought up before but I still can't understand why ground force attack is based on the weapon size techs rather than the weapon "range" techs. Sample size 1 - Earth history - suggests that the effectiveness of ground forces weapons throughout a long period of technological advancement is defined mostly by muzzle velocity and resultant range rather than maximum size. Modern militaries today use small arms which fire projectiles a fraction of the size of historical projectiles at speeds an order of magnitude higher than historical projectiles, which is wholly independent of the maximum theoretical projectile size.
Right now, especially at high tech for tracking and range making modern PD STO weapons is incredibly waste full as Aurora deems it necessary that my STO Gauss Cannons NEED to fire out to 1,750,000 (btw that's the 25% range bonus at max tech making projectiles FTL - bug?) resulting in some wasteful STO costs.
There is also supposed to be a change in 2.2 that will reduce the BFC range multiplier for non-PD STOs if the BFC range is significantly greater than the weapon range, which would apply if you are using 10cm railguns as PD for instance.I've seen that in action.
Right now, especially at high tech for tracking and range making modern PD STO weapons is incredibly waste full as Aurora deems it necessary that my STO Gauss Cannons NEED to fire out to 1,750,000 (btw that's the 25% range bonus at max tech making projectiles FTL - bug?) resulting in some wasteful STO costs.
This is a bug and should not be happening. STOs with the PD weapon fire controls should use the 1x range multiplier, not 4x - which, with STO bonus range should only extend out to 437,500 km. I will admit that this is still a bit wasteful since you probably would be fine with a shorter range (this gives you 97.7% base accuracy at 10,000 km for final fire PD, where a range of 100,000 km would give you 90% accuracy and save some uridium).
There is also supposed to be a change in 2.2 that will reduce the BFC range multiplier for non-PD STOs if the BFC range is significantly greater than the weapon range, which would apply if you are using 10cm railguns as PD for instance.
So based on the above I think it would make more sense to slim it down as:
- Have progressive GC techs for armor, HP, damage, and penetration. Just four tech lines, this is plenty to keep ~2 GC scientists busy at about the same workload as EW or DS scientists.
- I don't like the idea of a ROF tech line. Remember that ground combat in Aurora is inherently operational, not tactical, so ROF does not represent how fast you fire your weapon but rather the relative weights of fire between different weapon types over the course of an 8-hour engagement period.
- We don't need dedicated tech lines for specific component types, It is too much added research complication and actually adding these would make it more difficult to add new component types in the future if Steve wanted to.
Regarding the bonus suggestion, I think this is adding more granularity than makes sense for Aurora. If you need an alternative way to handle heavier personal weapons, we have a component type for that called PWI (although I think PWI should be buffed a bit in stats to be more distinct from PW, currently it is not very useful).I wouldn't be overly opposed to this, even in my post I did mention giving PWI a small buff. I'd be content for trading my PAV/PB/PAA for a Heavy PW that was 6-8T/4-5AP/4-6DMG. However, I still prefer my Personal Support Weapons for the thematics of CAP/HCAP/LAV/LB/LAA can be moved around by infantry, mounted on vehicles, or emplaced in fixed positions, but PAV/PB/PAA fill the same roles less effectively but more compactly. And I think you may have glazed over my examples for PSW's, its not Javelin vs TOW and 60mm vs 81MM mortars, its RPG-7 vs TOW, M320 Grenade Launcher vs 60/81MM mortars. My examples are almost exclusively single user operated, but yes TO&E will usually have an assistant/ammo bearer, but that's not the same as an average mortar team of 3-5 guys and you'd never see them mounted on a vehicle or fixed emplacement.
I was actively thinking about the possible "over"complexity of my suggestion, but I think its warranted to provide better roleplay diversity in the same way we can choose between all the various beam weapons and missile design (which I think got a little too over complicated for my tastes).
And the great thing about aurora is that even with super in-depth mechanics, you can smooth brain it and make it work. Dont want to replicate the entire US Marine corps down to the fireteam level, no worries, make tank, make infantry, produce a bunch in a 50kton formation, and if 1 doesnt work, send 10. Or in regards to missile design, you can ignore it entirely and just make beam only warships.
While I only provided a tactical/RP argument for the RoF tech, it does have a massive operational/strategic capacity in that buffing the number of shots (which I did not suggest should consume more GSP) reduces the number of required 8-hour ground combat cycles to resolve a battle. The AP/ARM and HP/DMG balance have a smaller effect on the actual length of combat as opposed to RoF.
I'm not too sure about this argument as realistically what other components could we add besides slight modifications like my PSW suggestion. Unless Steve wants to implement choice between weapon types like lasers and railguns and missiles for ground units, I think its kinda moot.
I'd be content for trading my PAV/PB/PAA for a Heavy PW that was 6-8T/4-5AP/4-6DMG.
And I think you may have glazed over my examples for PSW's, its not Javelin vs TOW and 60mm vs 81MM mortars, its RPG-7 vs TOW, M320 Grenade Launcher vs 60/81MM mortars. My examples are almost exclusively single user operated, but yes TO&E will usually have an assistant/ammo bearer, but that's not the same as an average mortar team of 3-5 guys and you'd never see them mounted on a vehicle or fixed emplacement.
When building an organisation, right now the game will simply create all tasks at 100% power individually, building formations one by one. It would be nice the game tried to balance the GU construction output. Though I realise that is easier set than done (maybe balance sub-organisation by sub-organisation instead of the whole thing?).
Failing that, unlike construction, ordnance and fighter factories, the player cannot right now modify the % of GU construction capacity used, would be nice if we could - it would make my above suggestion less important.
When building an organisation, right now the game will simply create all tasks at 100% power individually, building formations one by one. It would be nice the game tried to balance the GU construction output. Though I realise that is easier set than done (maybe balance sub-organisation by sub-organisation instead of the whole thing?).
Failing that, unlike construction, ordnance and fighter factories, the player cannot right now modify the % of GU construction capacity used, would be nice if we could - it would make my above suggestion less important.
I think this may be forced by the current implementation of organizations, since there can be a problem if the component formations are built out of order. By setting them to 100% it is easier to ensure that everything is built in the right order as long as the player doesn't screw it up on purpose.
When building an organisation, right now the game will simply create all tasks at 100% power individually, building formations one by one. It would be nice the game tried to balance the GU construction output. Though I realise that is easier set than done (maybe balance sub-organisation by sub-organisation instead of the whole thing?).
Failing that, unlike construction, ordnance and fighter factories, the player cannot right now modify the % of GU construction capacity used, would be nice if we could - it would make my above suggestion less important.
I think this may be forced by the current implementation of organizations, since there can be a problem if the component formations are built out of order. By setting them to 100% it is easier to ensure that everything is built in the right order as long as the player doesn't screw it up on purpose.
Yeah I guess. The easy way to do it would be do condense an organisation build order into a single construction task and then spawn the required formations and structure when the task is complete.
But then you lose some the granularity of the construction system. Though if you are building things through the organisation tab maybe one doesn't care?
When building an organisation, right now the game will simply create all tasks at 100% power individually, building formations one by one. It would be nice the game tried to balance the GU construction output. Though I realise that is easier set than done (maybe balance sub-organisation by sub-organisation instead of the whole thing?).
Failing that, unlike construction, ordnance and fighter factories, the player cannot right now modify the % of GU construction capacity used, would be nice if we could - it would make my above suggestion less important.
I think this may be forced by the current implementation of organizations, since there can be a problem if the component formations are built out of order. By setting them to 100% it is easier to ensure that everything is built in the right order as long as the player doesn't screw it up on purpose.
Yeah I guess. The easy way to do it would be do condense an organisation build order into a single construction task and then spawn the required formations and structure when the task is complete.
But then you lose some the granularity of the construction system. Though if you are building things through the organisation tab maybe one doesn't care?
I personally wish it worked the other way around, and build the lowest level of units first. It shouldn't matter too often, but in a time-sensitive scenario I'd rather have the infantry regiments in the field before the super-expensive non-combat corps HQ, you know, just in case...