Average Mineral Accessibility, Amount and Likelihood during game setup, maybe even a toggle that all planets should have ~some~ minerals.
More options for setting up minerals on planets manually, basically a button to specify that the planet should have a large amount high accessibility low amount or the reverse of which mineral.
Steve, add an order to refuel another fleet "while this fleet is moving".Ships can already refuel while moving. Its under the "underway replenishment tech", which starts at 20% of normal rate and goes up from there. You just have to have the tanker join the fleet, and set it to refill ships in the fleet
Realistically speaking, I do not see the reason why while a ship is moving (or has run out of fuel but it is still moving at 1km/s) cannot be refuel. After all, in real world fighter and ships get refueled while moving, so why not in sci-fy Aurora?
If you think there's a reason why you do not want do that, maybe we can think of an extra module to add to tankers or maybe a chance that the refuel operation fails and there's an explosion with random damage in one of the two ships (I imagine this operation would be risky and complicated).
Steve, add an order to refuel another fleet "while this fleet is moving".Ships can already refuel while moving. Its under the "underway replenishment tech", which starts at 20% of normal rate and goes up from there. You just have to have the tanker join the fleet, and set it to refill ships in the fleet
Realistically speaking, I do not see the reason why while a ship is moving (or has run out of fuel but it is still moving at 1km/s) cannot be refuel. After all, in real world fighter and ships get refueled while moving, so why not in sci-fy Aurora?
If you think there's a reason why you do not want do that, maybe we can think of an extra module to add to tankers or maybe a chance that the refuel operation fails and there's an explosion with random damage in one of the two ships (I imagine this operation would be risky and complicated).
Ships can already refuel while moving. Its under the "underway replenishment tech", which starts at 20% of normal rate and goes up from there. You just have to have the tanker join the fleet, and set it to refill ships in the fleet
I know that, I wanted avoid the joining fleet order, because than you have to detach the tanker again.
Steve, add an order to refuel another fleet "while this fleet is moving".Ships can already refuel while moving. Its under the "underway replenishment tech", which starts at 20% of normal rate and goes up from there. You just have to have the tanker join the fleet, and set it to refill ships in the fleet
Realistically speaking, I do not see the reason why while a ship is moving (or has run out of fuel but it is still moving at 1km/s) cannot be refuel. After all, in real world fighter and ships get refueled while moving, so why not in sci-fy Aurora?
If you think there's a reason why you do not want do that, maybe we can think of an extra module to add to tankers or maybe a chance that the refuel operation fails and there's an explosion with random damage in one of the two ships (I imagine this operation would be risky and complicated).
I know that, I wanted avoid the joining fleet order, because than you have to detach the tanker again.
More auxiliary command stations, to provide more positions for officers, and allow officers to have more extensive career histories:
Much like how the existing command stations such as "Science Department", "Engineering" etc function, where the officer assigned gives their full bonus, and the ship captain a half bonus to a function.
Things like:
Terraforming Control, for coordinating the terraforming modules of the ship - officer position would be "Planetologist", uses the "Terraforming" bonus of the officer.
Xenolinguistics Department, for dealing with aliens - officer would be "Xenolinguist", uses the "Communications" bonus
Astrophysics Department, for jump stabilisation ships - officer would be "Astrophysicist", using the "Production" bonus
Information Warfare Centre, for ELINT ships - officer would be "Information Warfare Officer", using the "Intelligence" bonus
Astrogeology Department, for orbital mining ships - officer would be "Astrogeologist", using the "Mining" bonus
True enough, however it'd allow for more story opportunities. Having the ship commander separate from the ship's primary function, has potential for story set-ups, whereas the single-officer ship has less. Especially when you factor in the "political reliability" option for promotions.Quote from: Louella link=topic=13404. msg167314#msg167314 date=1703022631More auxiliary command stations, to. . . allow officers to have more extensive career histories:This has been discussed many times in the past. The main reason cited not to do this is that it doesn't create interesting decisions in most cases.
Suggestion:
Release 2.5.0 before Christmas, so we have the most stable version to play with for the rest of the year. ;D
Suggestion:
Release 2.5.0 before Christmas, so we have the most stable version to play with for the rest of the year. ;D
Unironically this because it's a crying shame that ATG on missiles is bugged and I want to play with the new toys.
Would it be possible to import/export admin command setup?
Would it be possible to copy/paste auto assignment settings between different admin commands?
Right now it takes a lot of time to set it up every time you start a new campaign or create new admin structures/fleets.
Creating 20+ different admin commands and then setting their automatic assignment preferences and priorities is a lot of clicking.
Would be great qol change to make it easier to set up.
BTW, isn't it time for a new Full Installation Version?
I mean... 1.13.0 to 2.5.0 seems to be an adequate jump, don't you think? ;-)
Suggestion:
Release 2.5.0 before Christmas, so we have the most stable version to play with for the rest of the year. ;D
Unironically this because it's a crying shame that ATG on missiles is bugged and I want to play with the new toys.
I will release v2.5.0 before Christmas. As this is a DB release, I am just giving it a couple more days to see if anything else turns up.
Suggestion:
Release 2.5.0 before Christmas, so we have the most stable version to play with for the rest of the year. ;D
Unironically this because it's a crying shame that ATG on missiles is bugged and I want to play with the new toys.
I will release v2.5.0 before Christmas. As this is a DB release, I am just giving it a couple more days to see if anything else turns up.
This actually works for me. I set up a new campaign, but have been struggling to get it off the ground. It took me longer than it should have to realize that this was because I wasn't really interested in the setup, and couldn't get into it. I had already decided to start over, and the new update works for me.
Thanks Steve!
Suggestion:
Release 2.5.0 before Christmas, so we have the most stable version to play with for the rest of the year. ;D
Unironically this because it's a crying shame that ATG on missiles is bugged and I want to play with the new toys.
I will release v2.5.0 before Christmas. As this is a DB release, I am just giving it a couple more days to see if anything else turns up.
This actually works for me. I set up a new campaign, but have been struggling to get it off the ground. It took me longer than it should have to realize that this was because I wasn't really interested in the setup, and couldn't get into it. I had already decided to start over, and the new update works for me.
Thanks Steve!
On those lines, it can be useful to complete setup and then save a copy of the database before incrementing time. If the campaign doesn't get off to a good start, you can go back to that database at any time, open up the System View and use Regen Min and Regen JP to effectively create a new Sol system, giving you a new start. The NPRs will be the same though.
Suggestion for a fighter-sized cargo hold, either 100-ton or 250-tons would be great. Now that fighters can land on all bodies again, they can perform all missions that actual ships can except for transporting facilities and minerals, meaning that it is impossible to run a fighter-only game. Having a fighter-sized cargo hold would rectify that.I'd also like to bring up an old suggestion to remove the size requirement for commercial engines. As it stand now with the new 50t cargo shuttle, the smallest commercial transport you can make is over 2000t; 500t cargo hold, 50t shuttle, 50t bridge, 50t engineering space, 1250t engine, and fuel/armor/sensors to flavor and tech limitations. You can make it smaller but it will require maintenance which would be pretty annoying for something that's meant to transport small amounts of minerals or infrastructure within a system.
Alternately, could we have a design feature in the missile design section called "ballast" that does nothing but add mass/size, and costs nothing, to make matching missile speeds easier?
Would it be possible to import/export admin command setup?
Would it be possible to copy/paste auto assignment settings between different admin commands?
Right now it takes a lot of time to set it up every time you start a new campaign or create new admin structures/fleets.
Creating 20+ different admin commands and then setting their automatic assignment preferences and priorities is a lot of clicking.
Would be great qol change to make it easier to set up.
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Happy to implement if you can supply the logic :)
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Happy to implement if you can supply the logic :)
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Happy to implement if you can supply the logic :)
Maybe it can be done semi-automated. I was thinking of the TikZ module in LaTeX to create mind maps. Start with a starting system like Sol in the center and create each system around it with the first directly north and every following one 360/x degrees further clockwise with x being the number of explored JPs. You do the same for the next set of JPs that originate from the daughter systems with the single difference that the parent system is the new starting point from which systems get placed.
The connections between later generations of stars have to be significantly shorter than those for earlier generations, but they have to be long compared to the star system symbols. This way you can ensure that there will never be an overlap between systems.
You can use zoom on the star map after all and you have no size limitations like you have on paper.
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Happy to implement if you can supply the logic :)
You could check out the code for one of the algorithms listed here: https://graphviz.org/docs/layouts/
Assuming you can't just use this library as-is, I totally understand not wanting to spend your time digging through their code and reimplementing it -- I'm sure you have more interesting things to work on. But at the very least improving the grid snapping algorithm (currently it often doesn't snap to the nearest grid point, it might be rounding down?) and letting people adjust parameters like the minimum grid spacing and default placement distance would I think go a long way towards making the inevitable map rearrangements less painful.
This is one of those situations in which humans are generally better than computers, especially as each player will have his own view on an acceptable layout.
I add fighters to numerous civilain fleets as I stick a commercial hanger on most commercial ships and then a pair of fighters so a convoy stands a chance of killing a raider
Reintroduction of Staff Officers for admin commands
Reintroduction of Staff Officers for admin commands
Was this ever a thing?
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Happy to implement if you can supply the logic :)
Maybe it can be done semi-automated. I was thinking of the TikZ module in LaTeX to create mind maps. Start with a starting system like Sol in the center and create each system around it with the first directly north and every following one 360/x degrees further clockwise with x being the number of explored JPs. You do the same for the next set of JPs that originate from the daughter systems with the single difference that the parent system is the new starting point from which systems get placed.
The connections between later generations of stars have to be significantly shorter than those for earlier generations, but they have to be long compared to the star system symbols. This way you can ensure that there will never be an overlap between systems.
You can use zoom on the star map after all and you have no size limitations like you have on paper.
The above solution might work for the first 3-4 connections, assuming no loops, but when you get to 10+ jump chains and hundreds of systems, you quickly run out of space. How do you handle situations where there are not enough surrounding 'locations' for the systems (mainly due to the presence of other nearby un-connected systems) and how do you handle loops, especially nested loops?
The star map doesn't zoom BTW
Loops are the biggest issue I can see and they should be prevented at all costs.
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Happy to implement if you can supply the logic :)
Loops ... should be prevented at all costs.I'm sorry but that is complete nonsense. Yes, loops make mapping more difficult but they are often a storytelling spice that brings extra flavour to a campaign.
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Happy to implement if you can supply the logic :)
There seems to be a very nice package, that is unfortunately in javascript, called d3 force that looks like it could do something pretty neat using a force-directed graph technique.
Demo (with some really nice drag functionality):
https://observablehq.com/@d3/force-directed-graph/2?intent=fork
Source:
https://github.com/d3/d3-force
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
I think that it is important to aim for _simple_ improvements rather than complex ones. Automatic placement could be improved, but even a complex implementation will never be perfect. So the simple improvement that we really need is just better interactivity when dragging systems around on the map. Just making the snap–to–grid functionality less fiddly would go a long way by greatly reducing user frustration. It might even cause some user satisfaction!
Currently, when you drag a system to a new spot on the map there is no feedback about where it will actually snap to. This causes frequent misses, along with repeated attempts to move the system just far enough to put it where we want it to go. Just rendering a “ghost” in the spot where the system will end up and updating it as we move the mouse around would improve usability by a huge margin, and it would be far simpler to implement than any automatic placement system.
Even just changing the rounding so that systems snap in a more intuitive way would be a huge improvement, and probably won’t require changing but a couple of lines of code.
I think that it is important to aim for _simple_ improvements rather than complex ones. Automatic placement could be improved, but even a complex implementation will never be perfect. So the simple improvement that we really need is just better interactivity when dragging systems around on the map. Just making the snap–to–grid functionality less fiddly would go a long way by greatly reducing user frustration. It might even cause some user satisfaction!
Currently, when you drag a system to a new spot on the map there is no feedback about where it will actually snap to. This causes frequent misses, along with repeated attempts to move the system just far enough to put it where we want it to go. Just rendering a “ghost” in the spot where the system will end up and updating it as we move the mouse around would improve usability by a huge margin, and it would be far simpler to implement than any automatic placement system.
Even just changing the rounding so that systems snap in a more intuitive way would be a huge improvement, and probably won’t require changing but a couple of lines of code.
I have advocated before for changes in the snapping parameters under the hood. Currently, the galactic map spaces systems 140px apart with default placement and the snap-to-grid function snaps systems to increments of 20px. This means that there are seven 'increments' of snap positions between default system placements which is silly and not at all conducive to any way of organizing the systems besides a square grid - sometimes I would like to do a hexagonal arrangement and this is not feasible.
So my suggestions would be:
- Change the default snap increment to a neater fraction of 140px - 70px is probably not flexible enough but 35px should be fine.
- Snap-to-grid should round to the nearest increment mark, currently it seems to prefer rounding up rather than down which is frustrating to work with.
For a EXE-only patch we can keep the default 140px spacing as it looks fine as-is and this would preserve compatibility with 2.5.0 maps, but we could change to a friendlier value like 144px or 160px in a DB release which breaks saves anyways.
Move to jump point (Time Delay 365 days)
Trigger Nearby Fleets
Wait for Trigger
Refuel and Resupply at Planet
Overhaul at PlanetThe other fleet would be the same, you would just have it start at Wait for Trigger.Even just changing the rounding so that systems snap in a more intuitive way would be a huge improvement, and probably won’t require changing but a couple of lines of code.
I have advocated before for changes in the snapping parameters under the hood. Currently, the galactic map spaces systems 140px apart with default placement and the snap-to-grid function snaps systems to increments of 20px. This means that there are seven 'increments' of snap positions between default system placements which is silly and not at all conducive to any way of organizing the systems besides a square grid - sometimes I would like to do a hexagonal arrangement and this is not feasible.
So my suggestions would be:
- Change the default snap increment to a neater fraction of 140px - 70px is probably not flexible enough but 35px should be fine.
- Snap-to-grid should round to the nearest increment mark, currently it seems to prefer rounding up rather than down which is frustrating to work with.
Hexagonal arrangements are not impossible, even if they are not easy to achieve:
I split facility construction 50/50 so the system doesn't get clogged by big orders, but this does mean I have to change the %used by construction every time I open the window, either by typing it or selecting an existing work order. I'd very much appreciate the ability to set a default construction % for new construction tasks to use.
QOL Suggestion:That would be a useful "minor change."
Show the ages of scientists as part of the information given when choosing someone to head a project.
May not be relevant to everyone but I've been playing a slower paced game (40% research speed, with Limited Research Admin) and I've run into the problem whereby I'll start the research and then a couple of months later the scientist retires as they reach their mid 60s. Having their age listed when choosing from the list would make it a lot easier to avoid that, whilst also giving players a better idea of when it would be a good idea to switch to a less experienced scientist to train them up.
QOL request...Just use the continuous expansion function to expand it to the proper size. Adding a few hundred tons of capacity would only take like a month, probably
Could the shipyard size limitation be changed to be a modifier on efficiency, rather than a hard limit? E.g. if you want to build a ship that is 20,103 tons, and your shipyard capacity is only 20,000, you'd get a multiplier on your build rate of something like (20,000/20,103)^2. That way you don't have to fuss with adding 103 tons of capacity every time your ship design comes in slightly over, but there's still an incentive to build your shipyards big enough?
Presumably it would only apply in cases when the shipyard is too small, and multiplier would be capped at max of 1.0 (i.e. for when the shipyard is bigger than needed).
is there no conditional order for "cargo hold full" ?
automatic salvaging just salvages untill full and keeps going
-- So, off the cuff idea for Meson Cannons.
Currently, Meson Cannons larger than 30cm are strictly and progressively worse, since they fire slower and have no damage scaling, thus rendering the range increase worthless.
What if it was altered so that larger Meson Cannons had a higher effective rate of fire by making them more energy efficient per shot as they got bigger?
So unlike Railguns and Gauss Cannons, which fire multiple shots per increment and thus have multiple chances to hit as a result, Meson Cannons would instead fire more often by requiring less capacitors per shot as their caliber increased.
So I'm thinking every three caliber techs or so, a Meson Cannon would gain one extra shot, but without needing more capacitors to do it. So 10cm to 15cm Meson Cannons would have one shot as they currently do. 20cm to 30cm Meson Cannons would have twice as many shots, 35cm to 45cm would have thrice as many, and so on and so forth with each new threshold adding one shot.
Incidentally, High-powered Microwaves have this issue as well, whereby the lack of damage scaling means that HPMs over 30cm are just outright worse.
Also incidentally, this change could be applied to HPMs to make calibers over 30cm no longer useless while still preserving their "Secondary Weapon" flavor.
It probably always was like this but not as apparent as Jump Capability was not locked in place... But now it seems silly that the components for more advanced Jump Drives are cheaper to research and build because they are smaller.More advanced tech means more can be done with less materials. I think it's fine. Cloaking devices are the same way.
Efficiency 6 for 3000t ship costing me 50 BP and 500 RP (380t JD size)
Efficiency 4 for 3000t ship costing me 75 BP and 612 RP (570t JD size)
More advanced tech means more can be done with less materials. I think it's fine. Cloaking devices are the same way.Yes, It seems like Cloaking devices are the same way when I test them.
A QOL suggestion since this issue seems to have come up many times in my reading, the ability to organize fighters ordered to provide ground support into some sort of unit that can then be assigned to provide support to some formation directly, rather than having to go by each individual fighter.
Also: Can you make it display the date better in the shipyard production and scientist menus? Usually you can only see that it was produced on friday 12th. . . , which isn't very helpful.
Can you make it that it displays the age of the scientist in the research menu? Will make it easier to pick young healthy ones after they start dying off.
Also: Can you make it display the date better in the shipyard production and scientist menus? Usually you can only see that it was produced on friday 12th. . . , which isn't very helpful. There are probably other places with this same problem but I can't remember off the top of my head.
Attached Pic is all suggestions visualized
I'd still like to have some highlighting in the Commanders window for "Story Characters" to make them easier to find when you have thousands of commanders. That window already supports colored status text for commander health, so the code infrastructure is there. I think the color that is used for CMCs you're buying from would work nicely, but I would be happy with anything.
I attempt to use this feature in all of my games to track individuals with notable achievements throughout their careers and I don't always remember to write their names down in my personal notes.
Also! I don't think there is anywhere that shows your total number of academy crew graduates (not officers) that you have stored up. They show how much you get per year, but not the total stored. I think this used to be showed in the academy/teams tab.
wtf. . . if been suffering for so long bros. . .Bro...
Also! I don't think there is anywhere that shows your total number of academy crew graduates (not officers) that you have stored up. They show how much you get per year, but not the total stored. I think this used to be showed in the academy/teams tab.
I wish a ship with a Hub could at least work exactly the same as a ship with a Refuelling/Transfer System. Optimum would be it works as a Hub, even when underway (with appropriate tech).
Re-read what he wrote, that's the number of crew and junior officers that you get per-year, not how many are in the pool total.wtf. . . if been suffering for so long bros. . .Bro...
Also! I don't think there is anywhere that shows your total number of academy crew graduates (not officers) that you have stored up. They show how much you get per year, but not the total stored. I think this used to be showed in the academy/teams tab.
(https://i.imgur.com/qM6SV4J.png)
Re-read what he wrote, that's the number of crew and junior officers that you get per-year, not how many are in the pool total.
If that's true and there's no hidden pool then it doesn't seem to have any bearing on gameplay whatsoever, the value that's shown in my campaign is 1717, and it will let me construct anything, ships with 2,000 crew, many ships with 1,000 crew, etc.Re-read what he wrote, that's the number of crew and junior officers that you get per-year, not how many are in the pool total.
Fun fact: No. This is actually the total number of crew you have available at any one time.
I realize this is confusing because the number changes when you change the crew training level (1-5), but this is how it works. Presumably this admittedly confusing implementation was easier for Steve than trying to keep track of different numbers of crews with different training levels if you changed the training level.
If that's true and there's no hidden pool then it doesn't seem to have any bearing on gameplay whatsoever, the value that's shown in my campaign is 1717, and it will let me construct anything, ships with 2,000 crew, many ships with 1,000 crew, etc.Re-read what he wrote, that's the number of crew and junior officers that you get per-year, not how many are in the pool total.
Fun fact: No. This is actually the total number of crew you have available at any one time.
I realize this is confusing because the number changes when you change the crew training level (1-5), but this is how it works. Presumably this admittedly confusing implementation was easier for Steve than trying to keep track of different numbers of crews with different training levels if you changed the training level.
This has been the way crew grade worked since before I started playing VB6 Aurora, back when the big change was that jump gates did not need components anymore and commercial shipyards started at 10,000 tons instead of 1,000 tons like military. We had Gunboat engines and Fighter engines as special cases to use in addition to Missile engines and actual Ship engines.
and as Nuclearslurpee said, once you run out, your ship's crew grade will start as negative instead of a positive number.
If that does not happen, then you've encountered a bug.
This has been the way crew grade worked since before I started playing VB6 Aurora, back when the big change was that jump gates did not need components anymore and commercial shipyards started at 10,000 tons instead of 1,000 tons like military. We had Gunboat engines and Fighter engines as special cases to use in addition to Missile engines and actual Ship engines. You have a lump sum of crew and junior officers and it grows based on how many academies in total you have. Increase your training level and the pool goes down, decrease your training level and the pool goes up. Use the Conscript tickbox for ships that will never see combat to save trained crew for your military ships and as Nuclearslurpee said, once you run out, your ship's crew grade will start as negative instead of a positive number.Does the pool replenish over time?
If that does not happen, then you've encountered a bug.
Right now there is a "salvage nearest wreck" command but no way to automatically empty the ships when they are near full.
If possible some conditional orders of >50% >75% >90% Cargo would be nice and "unload cargo at nearest colony" and "unload cargo at capital" would be nice if possible?
I get into many fights with 10's of ships and manually salvaging is a bit of a pain.
Being able to make smaller salvaging fleets that are automated with commercial hangers and defences would really speed up the game.
Ships that are scrapped send their crews back to the pool and building more academies increases the speed at which the pool grows.This has been the way crew grade worked since before I started playing VB6 Aurora, back when the big change was that jump gates did not need components anymore and commercial shipyards started at 10,000 tons instead of 1,000 tons like military. We had Gunboat engines and Fighter engines as special cases to use in addition to Missile engines and actual Ship engines. You have a lump sum of crew and junior officers and it grows based on how many academies in total you have. Increase your training level and the pool goes down, decrease your training level and the pool goes up. Use the Conscript tickbox for ships that will never see combat to save trained crew for your military ships and as Nuclearslurpee said, once you run out, your ship's crew grade will start as negative instead of a positive number.Does the pool replenish over time?
If that does not happen, then you've encountered a bug.
Could we get an autosave function? Default it to, say, once a year?
Asking as someone whose computer decided to reboot overnight to install an update and lost about an in-game decade of progress.
along with this making asteroids far more common in systems (as would be realistic) would promote many more people to use astoid mining ships which are far more vulnerable than their planetside counterparts.
Personally i would like to see 10x-100x more asteroids since as far as i know it doesn't impact performance anymore, maybe even 1000x more asteroids to make automated mining operations much more worth their time and risk.
I have found systems with lots of asteroids before. They aren't common, but are pretty good when they do exist.along with this making asteroids far more common in systems (as would be realistic) would promote many more people to use astoid mining ships which are far more vulnerable than their planetside counterparts.
Personally i would like to see 10x-100x more asteroids since as far as i know it doesn't impact performance anymore, maybe even 1000x more asteroids to make automated mining operations much more worth their time and risk.
Seconded. I noticed this when setting up a bunch of habitable systems for player races, the number of asteroids in Sol is rather anomalous in Aurora and I'm not sure it should be. Although I can see why having large asteroid belts be a bit rare is good for gameplay in making asteroid mining systems valuable finds, this value could be preserved by toying around with the mineral generation rate for asteroids if needed.
It is honestly not uncommon in my known stars game for systems to have asteroid belts with lots of asteroids. In some cases systems have even had multiple asteroid belts usually a system belt and a gas giant belt.
So I'm not convinced that there is a systematic problem with asteroid generation.
Could we get an autosave function? Default it to, say, once a year?I'm sorry dude but you know you can press the save button yourself? I can understand leaving your PC on for the night but at least manually save Aurora before going to bed. Windows does not force an update when you're actively using the PC afterall. Having said that, an auto-save on 1 January of each year is a good idea.
Asking as someone whose computer decided to reboot overnight to install an update and lost about an in-game decade of progress.
I'm sorry dude but you know you can press the save button yourself? I can understand leaving your PC on for the night but at least manually save Aurora before going to bed. Windows does not force an update when you're actively using the PC afterall. Having said that, an auto-save on 1 January of each year is a good idea.Oh, it's totally my fault - I forgot to hit the save button before I went to sleep for the night. I even thought to myself the next day "you know, it's been a while since I last saved - I should probably do that," right before I flipped the screen on.
I'd like to suggest some method of over-riding the game's automatic class designations on player designed ship or station classes. This would obviously need some limitations, such as not being able to change commercial, military or station designations (and probably some others I haven't thought of at the moment). The default works well enough in almost all cases but occasionally gets in the player's way.
For example, I just designed a mobile asteroid mining ship intended to be nearly self-sufficient. It has cargo holds to drop a mass driver then move it when necessary and, crucially, troop transport capability to carry then drop STO's on whatever rock it parks above, in case any unfriendly pests come to bother it.
But when I add the troop transports, it changes the design to a Troop Transport for auto-assignment purposes, due to Troop Transport Bays having precedence over mining modules when determining class type. This is a bit frustrating, as the entire purpose of this ship is to mine so I'd prefer commanders with the relevant bonuses. The ability to manually set design types when necessary would obviate this irritation.
Dropping off life pod survivors is somewhat tedious, especially because you have to have the survivors on board in order to be able to give the unload order, requiring two interrupts.
Therefore I suggest that you add the option to space the survivors. This would not solve the two-interrupt problem, but it would be vastly more satisfying.
In the ship history listing, it would be neat to list what shipyard constructed a given ship.
In the ship history listing, it would be neat to list what shipyard constructed a given ship.
It looks like it does to me -- are you looking at a ship that was Instant Built at game start or with SM mode? Those just say "Constructed".
QOL Suggestion:
Show the ages of scientists as part of the information given when choosing someone to head a project.
May not be relevant to everyone but I've been playing a slower paced game (40% research speed, with Limited Research Admin) and I've run into the problem whereby I'll start the research and then a couple of months later the scientist retires as they reach their mid 60s. Having their age listed when choosing from the list would make it a lot easier to avoid that, whilst also giving players a better idea of when it would be a good idea to switch to a less experienced scientist to train them up.
Add a new type of intelligence gain: Hull Classification. This should be pretty common, and would provide the hull classes of multiple known NPR hulls for the relevant NPR. This way, you can build up information on what each class is, without needing to hope for getting the full design specifications or needing to attack/board NPR ships.
I've found that despite sitting ELINT ships in range of NPR homeworlds for years, I basically only get intelligence on a handful of designs, most of which are either outdated or not deployed. An intelligence gain option like this would let me figure out which ships are tankers, freighters, etc, in a much more practical time-span
In my "war of the worlds" game I have destroyed...
16 ships of 30kt
12 ships of 20kt
4 ships of 10kt
2 ships of 10kt
without being able to gain intel on what the hull classifications might be, despite many of the battles involving cruisers carrying ELINT modules, engaging at beam ranges.
I know the class name, and partial information on sensors, engines, weapons etc. from salvage.
But not the hull classifications.
now that I think about it, the only ships that I have hull classifications for, are ones that I have boarded, or saw being launched due to having sensor coverage of Mars at the time of their launch.
Everything else is XX unknown hull classification. I'm using "real ship/class names".
Is it because I have not translated the Martian language ? (they're extremely xenophobic and refuse to communicate)
In my "war of the worlds" game I have destroyed...
16 ships of 30kt
12 ships of 20kt
4 ships of 10kt
2 ships of 10kt
without being able to gain intel on what the hull classifications might be, despite many of the battles involving cruisers carrying ELINT modules, engaging at beam ranges.
I know the class name, and partial information on sensors, engines, weapons etc. from salvage.
But not the hull classifications.
now that I think about it, the only ships that I have hull classifications for, are ones that I have boarded, or saw being launched due to having sensor coverage of Mars at the time of their launch.
Everything else is XX unknown hull classification. I'm using "real ship/class names".
Is it because I have not translated the Martian language ? (they're extremely xenophobic and refuse to communicate)
In my "war of the worlds" game I have destroyed...
16 ships of 30kt
12 ships of 20kt
4 ships of 10kt
2 ships of 10kt
without being able to gain intel on what the hull classifications might be, despite many of the battles involving cruisers carrying ELINT modules, engaging at beam ranges.
I know the class name, and partial information on sensors, engines, weapons etc. from salvage.
But not the hull classifications.
now that I think about it, the only ships that I have hull classifications for, are ones that I have boarded, or saw being launched due to having sensor coverage of Mars at the time of their launch.
Everything else is XX unknown hull classification. I'm using "real ship/class names".
Is it because I have not translated the Martian language ? (they're extremely xenophobic and refuse to communicate)
You can just set a hull classification? I don't see why the inherent classification is any more useful than one you give it?
You can just set a hull classification? I don't see why the inherent classification is any more useful than one you give it?
Well, assuming that their hull classification isn't misinformation on their part. Y'know, German tank problem and whatnot. Just use misleading hull classifications and fool your foes!
That and the fact that hull classification isn't followed in a general way anyway. Is a destroyer a destroyer based on size, or purpose? Who knows?
I think the general sense in the thread right now is that (1) such intelligence should not be "free" when using the Real Class Names checkbox (and inconsistently so at that) and that (2) being able to gather such intelligence by ELINT would be a cool feature.
Can I meet an adversary 100 kton ship in my space? Yes.
Can they call it as battleship? battle cruiser? heavy cruiser? cruiser? escort cruiser? carrier? freighter? giant freighter? or what ever other way? Yes.
Is this classification meaningful respect the role this ship can have in the fleet? Frankly, no. IMO, its systems, weapons, armour, shields, etc. are much more meaningful, maybe together with the knowledge whether it is a military (M) or a civilian (C) ship.
If my sensors warn me about this large ship, I can be really suspicious it can be very dangerous, even if I don't know whether it is M or C (I can think a cargo loading troops and deploying them where I am unarmed).
So, IMHO, a ship classification can be a very secondary information.
Also for 2.5 there only seems to be a bug report thread...
After having created a few custom NPRs, I notice that those I check to have both missiles and a beam weapon rarely ever use the beam weapon, even in large fleets, and even on beam defence bases (which seem to be PD only). I've observed what seems to be NPRs taking fights at relative tonnage parity despite being entirely out of ammunition and lacking any offensive option. I know it might just be a roll of the dice, but it would be nice to see a more even split between the distribution of beams and missiles in NPR fleets.All or nothing is rather favored with offensive missiles. Your ability to win battles with them is heavily dependent on your volley volume. Trading more missile launchers for offensive beams, either on a ship or in a fleet, is risking your ability to win with missiles to buy the ability to also lose with beams...
In my "war of the worlds" game I have destroyed...
16 ships of 30kt
12 ships of 20kt
4 ships of 10kt
2 ships of 10kt
without being able to gain intel on what the hull classifications might be, despite many of the battles involving cruisers carrying ELINT modules, engaging at beam ranges.
I know the class name, and partial information on sensors, engines, weapons etc. from salvage.
But not the hull classifications.
now that I think about it, the only ships that I have hull classifications for, are ones that I have boarded, or saw being launched due to having sensor coverage of Mars at the time of their launch.
Everything else is XX unknown hull classification. I'm using "real ship/class names".
Is it because I have not translated the Martian language ? (they're extremely xenophobic and refuse to communicate)
You can just set a hull classification? I don't see why the inherent classification is any more useful than one you give it?
It isn't necessarily, but on the other hand, detecting "15x XX Unknown" might prompt a different response than detecting "15x DDG Absolute Carnage". Might want to bring escorts for that second one.
You can literally set the 2nd one yourself? There is no need for the game to do that for you?
Your response is nonsensical?
Unless you want the game to give you all of the information you need about a ship you have never seen before without having ever fought it? which would be REALLY weird.
This just isn't true? you can get ALL of the information relevant to the capabilities of a ship without any elint?Thats not what they are saying at all.
You can get speed, sensors, weapon ranges, ECCM, ECM shields, armour etc.
There is simply no need for the game to give you the class of the ship?
You don't NEED to know what class it is, it doesn't actually give you any new information. I have successfully classified more than 2/3 of my current NPRs ships just by evaluating what they do and their capabilities before destroying or being shot at by them.
Once a ship has shot at you then you should be able to classify it with almost a 100% accuracy?
So basically what you are asking for is the game to spoon feed you information you couldn't be bothered to look up / determine yourself OR you want more information on enemy ships without any extra effort, which just makes the game even easier to counter AI designs, which the game sorely does NOT need.
This just isn't true? you can get ALL of the information relevant to the capabilities of a ship without any elint?
You can get speed, sensors, weapon ranges, ECCM, ECM shields, armour etc.
Once a ship has shot at you then you should be able to classify it with almost a 100% accuracy?
So basically what you are asking for is the game to spoon feed you information you couldn't be bothered to look up / determine yourself OR you want more information on enemy ships without any extra effort, which just makes the game even easier to counter AI designs, which the game sorely does NOT need.
This just isn't true? you can get ALL of the information relevant to the capabilities of a ship without any elint?Thats not what they are saying at all.
You can get speed, sensors, weapon ranges, ECCM, ECM shields, armour etc.
There is simply no need for the game to give you the class of the ship?
You don't NEED to know what class it is, it doesn't actually give you any new information. I have successfully classified more than 2/3 of my current NPRs ships just by evaluating what they do and their capabilities before destroying or being shot at by them.
Once a ship has shot at you then you should be able to classify it with almost a 100% accuracy?
So basically what you are asking for is the game to spoon feed you information you couldn't be bothered to look up / determine yourself OR you want more information on enemy ships without any extra effort, which just makes the game even easier to counter AI designs, which the game sorely does NOT need.
The whole point is that 99% of the time ELINT is useless for finding out any information about enemy ships, because you get maybe 1 ship class report every few years. What we want is a way to more quickly figure out very general information about NPR ships without having to be at war with them.
from an in-character perspective, this would represent your ELINT ships listening to comms chatter to figure out what ships are what (IE this intercepted message says this ship is loading colonists, it must be a colony ship), or having analysts look at photos to figure out what ships do (IE This ship has 20 openings, based on the size of those opening it must be an AMM ship)
You don't see any real world navy waiting until they are at war to figure out what the enemy ships do.
The proposal originally and the entire argument is about the ability to determine a ships class using ELINT, because of the way the game works that just instantly gives you the entire capability of the ship bar weapon range and exact sensor ranges.
Presently, new construction is preferable to refit as you get none of the minerals used in the replaced components back (unless I'm mistaken). That's all well and good, but it means that ships with long histories are lost if you're short of minerals and can't afford the inefficiency. I'd like to suggest that components replaced in refit be either given back to you as in the case of scrapping or automatically scrapped for minerals.
Presently, new construction is preferable to refit as you get none of the minerals used in the replaced components back (unless I'm mistaken). That's all well and good, but it means that ships with long histories are lost if you're short of minerals and can't afford the inefficiency. I'd like to suggest that components replaced in refit be either given back to you as in the case of scrapping or automatically scrapped for minerals.
There is a reason that this is not done, which is that it would yield in many cases a net gain of minerals relative to new construction.
An illustrative example: Suppose I want to do a simple engine refit for a ship, where I have 3x NGC engines of 300 EP each (150 BP each, total 450 BP) and I want to do a simple engine upgrade to 3x ion engines of 375 EP each (187.5 BP each, total 562.5 BP) In this case the refit cost is 562.5 x 1.20 = 675 BP, which will be all gallicite since we are doing only the engines. If we could recover the old engines, we could then scrap them for 30% of their minerals or 135 gallicite. This would mean the net refit cost was 540, which is less than the cost of the engines. This is not desirable and defeats the point of the 1.20x refit penalty mechanic.
Refitting should not be preferable to new construction for economic reasons (this is why we currently have the 1.20x penalty). Refitting is used for other purposes: most commonly, it is used to keep highly-trained crews while upgrading the ships. Another important use is that upgrading ships can make more sense than new construction when you lack the capability to maintain, crew, or assign commanders to large numbers of new ships. There can be others, including some edge cases when you want to upgrade ships without spending certain minerals on specific components.
Refitting not being preferable to new construction for economic reasons seems like a bizarre priority to me. You might as well not have refitting if it's going to be at a loss.Presently, new construction is preferable to refit as you get none of the minerals used in the replaced components back (unless I'm mistaken). That's all well and good, but it means that ships with long histories are lost if you're short of minerals and can't afford the inefficiency. I'd like to suggest that components replaced in refit be either given back to you as in the case of scrapping or automatically scrapped for minerals.
There is a reason that this is not done, which is that it would yield in many cases a net gain of minerals relative to new construction.
An illustrative example: Suppose I want to do a simple engine refit for a ship, where I have 3x NGC engines of 300 EP each (150 BP each, total 450 BP) and I want to do a simple engine upgrade to 3x ion engines of 375 EP each (187.5 BP each, total 562.5 BP) In this case the refit cost is 562.5 x 1.20 = 675 BP, which will be all gallicite since we are doing only the engines. If we could recover the old engines, we could then scrap them for 30% of their minerals or 135 gallicite. This would mean the net refit cost was 540, which is less than the cost of the engines. This is not desirable and defeats the point of the 1.20x refit penalty mechanic.
Refitting should not be preferable to new construction for economic reasons (this is why we currently have the 1.20x penalty). Refitting is used for other purposes: most commonly, it is used to keep highly-trained crews while upgrading the ships. Another important use is that upgrading ships can make more sense than new construction when you lack the capability to maintain, crew, or assign commanders to large numbers of new ships. There can be others, including some edge cases when you want to upgrade ships without spending certain minerals on specific components.
Refitting not being preferable to new construction for economic reasons seems like a bizarre priority to me.
You might as well not have refitting if it's going to be at a loss.
Refitting not being preferable to new construction for economic reasons seems like a bizarre priority to me.
I...don't see how? Intuitively, it costs more to open up a ship, rip out a component, install a new one, and close the ship back up than it does to install the same new component while building a ship from scratch. I'm not one of the guys with a hard-on for realism but this seems logical to me.
Yes, but building the entire rest of the new ship is a rather large penalty on that side of the scale. It should be more expensive in some respect to obtain your final ship by building a different design and refitting, sure. But if a refit is plausible at all, it shouldn't be more expensive to do the refit than to scrap the starter ship and build the new ship.Refitting not being preferable to new construction for economic reasons seems like a bizarre priority to me.
I...don't see how? Intuitively, it costs more to open up a ship, rip out a component, install a new one, and close the ship back up than it does to install the same new component while building a ship from scratch. I'm not one of the guys with a hard-on for realism but this seems logical to me.
- Keeping highly trained crews: Okay, but only because the system doesn't allow us to do things like transfer a trained crew to a new hull.QuoteYou might as well not have refitting if it's going to be at a loss.
I've given several reasons why refitting is valuable even if it is relatively more costly. Needless to say, I don't agree with this statement.
Okay, I think I see where your point is. I'm thinking more about the relatively partial refits which can still be significant but come out to substantially less than the cost of building a new ship. Although I think it should be extremely rare to have a refit that costs significantly more than the cost of new construction since you will have carry-over from components that don't upgrade - engineering, fuel tanks, maintenance bays, crew quarters, etc., so even a total refit should be a very similar cost, at worst, to new construction.The original concern was with the mineral dis-economy of (reportedly) not recovering the removed components in any form on a refit, as opposed to scrapping giving you back the components to re-use or break down.
It would be nice to have some way to shift a highly-trained crew over, though.
Honestly the main thing that currently makes me prefer refits over scrap and build new, is service history. I want to see those tonnage destroyed numbers go up higher.This reminds me that it would be good if you could award and then transfer across Battle Honours (including the tonnage destroyed numbers) to ships with the same name.
Maybe the idea here is that you should go ahead and delete the previous one when you train the replacement, but I tend to have at least a couple older generations of troops around as garrison units so it would be nice to at least have the option to retain the current numbering.
I love using STOs in Aurora but managing them can get tedious. Building large STO formations of clustered weapons to minimize entries in the STO targeting list is expensive with long build times, but building multiple smaller, cheaper STO formations means a lot more manual clicking when setting up defense doctrines and during combat situations.I'm 99% sure that you can build smaller STO formations, then merge them together into larger formations afterwards (I've done this with regular troops, so I don't see why STOs would operate differently.) There'll still be some clicking involved to move the STO units, then deleting the (now empty) formations; but it should be a lot less annoying than having to duplicate firing orders to multiple STOs.
-Officers rescued from life pods are not automatically unloaded when the Unload Survivors order completes at a population. My suggestion is that the Unload Survivors order also unloads any unassigned officers that are onboard a ship. Alternatively, an "Unload Unassigned Officers" order be available to ships that have unassigned officers onboard.
-Officers rescued from life pods are not automatically unloaded when the Unload Survivors order completes at a population. My suggestion is that the Unload Survivors order also unloads any unassigned officers that are onboard a ship. Alternatively, an "Unload Unassigned Officers" order be available to ships that have unassigned officers onboard.
I think you can use the "drop off commander" order to unload any rescued officers, but you are presented with a list of all ship commanders in the fleet, which can be a lot. Perhaps some highlighting of unassigned officers would be in order, if that would be simpler to implement than dropping off unassigned officers.
-Officers rescued from life pods are not automatically unloaded when the Unload Survivors order completes at a population. My suggestion is that the Unload Survivors order also unloads any unassigned officers that are onboard a ship. Alternatively, an "Unload Unassigned Officers" order be available to ships that have unassigned officers onboard.
I think you can use the "drop off commander" order to unload any rescued officers, but you are presented with a list of all ship commanders in the fleet, which can be a lot. Perhaps some highlighting of unassigned officers would be in order, if that would be simpler to implement than dropping off unassigned officers.
Yes, this is my issue with the Drop Off Commander order. If Drop off commander highlighted unassigned officers, that would be fine too in my opinion.
As far as ground combat goes, I'd just like aircraft to be moved from individually built tiny spaceships to just being a different type of ground unit.Would an auto-allocate for air support maybe mitigate the problem without changing the architecture?
The benefits of the tiny spaceship approach do not in any way offset the massive increase in micromanagement needed to effectively use them over regular forces.
As far as ground combat goes, I'd just like aircraft to be moved from individually built tiny spaceships to just being a different type of ground unit.Would an auto-allocate for air support maybe mitigate the problem without changing the architecture?
The benefits of the tiny spaceship approach do not in any way offset the massive increase in micromanagement needed to effectively use them over regular forces.
any chance you can increase the amount of static defenses (machine-gun bunkers?) the ai builds?Agreed, any more variety for AI ground force builds would be good.
if you ever do plan on taking another go at ground-forces balance, I have idea for an entire new feature. The problem I'm thinking to solve, is that machine-guns are too much better than personal weapons.I disagree. They are more lethal, for sure, but there is a cost to be paid for that in increased tonnage and increased GSP use. That cost is IMHO about right currently.
I'm trying to think how to change the balance, such that personal weapons become the primary infantry weapon, with machine-guns performing a supporting role.You sound like French generals in WW1 and the interwar period. In reality, the machine gun in its various iterations has arguably been the primary infantry weapon since late-WW1 and most certainly so from WW2. The Germans built their infantry squads around the MG-34/42 and the riflemen were there just to support it. Eventually everyone else copied them to some extent. Yes, the introduction of assault rifles, ie automatic rifles shooting an intermediate cartridge that were affordable enough to equip every infantry soldier, seemed to change things but I would not go so far as to claim that the rifle is the primary weapon and the MG is the supporting weapon. This is an illusion conjured by the recent Anglo-American experiences. In other words, Afghanistan and Iraq massively distorted the understanding of war in both the US and in Britain. Yes, MGs were largely support weapons when 99% of combat is patrol and search missions in counter-insurgency operations among civilian populations. If you look at Ukraine, you'll see that the MG is the king of the battlefield, with artillery and drones coming up close seconds. There the assault rifle is just a support weapon, used only if other, more effective, weapons are not available.
The second problem I wanted to solve, is artillery. Basically, front line being the shield, and backline being the cannon is the most fun dynamic way for things to be,I disagree. Obviously the most fun and dynamic way for things to be is to have Godzilla and King Kong fight each other, with the 50-foot-tall woman as a surprise entrant to make it a 3-way fight. ;D I'm exaggerating for comedic effect but you really shouldn't make such blanket claims. They are just silly.
if you ever do plan on taking another go at ground-forces balance, I have idea for an entire new feature. The problem I'm thinking to solve, is that machine-guns are too much better than personal weapons.I disagree. They are more lethal, for sure, but there is a cost to be paid for that in increased tonnage and increased GSP use. That cost is IMHO about right currently.
So no, I don't think that the current ground combat mechanics need to be changed to solve a problem that does not really exist, especially by promoting ideas that are unrealistic and promote rock-scissors-paper gameplay where you have to have X and Y and Z, while running the risk of distilling all the flavour out of it.
As far as ground combat goes, I'd just like aircraft to be moved from individually built tiny spaceships to just being a different type of ground unit.
The benefits of the tiny spaceship approach do not in any way offset the massive increase in micromanagement needed to effectively use them over regular forces.
And equally as importantly, it is important to recognize that the current ground combat system, due to its relative simplicity, does an excellent job of supporting roleplay. While it may not be "realistic", a player may create a WH40K Imperial Guard regiment, a BattleTech 'Mech regiment, or a WWI-era infantry regiment, and all of these forces will perform reasonably well on the battlefield.
Yes, I will redo the 'air' component of ground combat at some point, probably by introducing a new ground unit type to represent helicopters / attack aircraft / fighter etc.And now you have given me a reason to wait until starting the campaign that I want to do, since that sounds fantastic and I would not want to play without it.
Yes, I will redo the 'air' component of ground combat at some point, probably by introducing a new ground unit type to represent helicopters / attack aircraft / fighter etc.
We used to have nebulae, which did some of your suggestions (shields disabled and reduced speed... possibly reduced sensors?). I honestly don't recall them terribly fondly - being slow is annoying, and since (at least in the last version) they replaced empty systems, there was no reason to be in them. So you ended up just hoping that you didn't get any long realspace connections in a nebula, since it would slow your entire empire down if one ended up in the middle of your main corridors.
In the Class Design window, would be great to see Maintenance needed when a specific component fails.
Would it be possible to add a fleet's Minimum current range stat in the overview tab? We can see total range of all orders and total fuel, but not if the ships have enough fuel to complete the orders.
Probably ignore any refueling effects for simplicity.
If a fleet level stat isn't practical, it would be nice if it could be displayed in the ship list next to % of remaining fuel.
A "Commercial Hanger" or "Commercial Boat Bay" that can only be used to carry commercial vessels and doesn't make the mothership automatically a military ship (the way current hangers do). This would let us put small commercial sensor posts inside hangers on Jump Point Stabilization ships and drop them as they stabilize jump points, leave them near gas giants you suspect your enemies may stop by for fuel harvesting, leave them above prime colonizable worlds you don't have time/reach to claim yet, etc.
Would it be possible to add a fleet's Minimum current range stat in the overview tab? We can see total range of all orders and total fuel, but not if the ships have enough fuel to complete the orders.
Probably ignore any refueling effects for simplicity.
If a fleet level stat isn't practical, it would be nice if it could be displayed in the ship list next to % of remaining fuel.
There already is a range stat for ships.
Naval Orginization Menu - If two fleets are in the same place, let us drag a ship directly from one fleet to another without the extra step of detaching.
Option to start with a default medal setup and event log color scheme as part of the base game. I played for a week before learning about the Medals aspect of this game. I played another two weeks before learning I could download a file from the forums of fully defined conditions with beautiful medals. Include this in the base game, let people have the option to use the default, but still let them edit it to their preferences if they like.
Alternately, offer an option to have the minimum rank selection increase to meet increased demands. Do we *really* need to be bothered every time these people aren't high enough rank?
Towing asteroids into orbit around a different body.
When queueing up installations for construction, show workers required for the installation in the panel that shows mineral costs. Just add it right under "Corundium 20" or whatever.
An in-game library of ship class designs using either the most basic, or currently researched, tech. For instance, if you select Freighter for the class label, have a button to import a basic Freighter design from the library. Not all classes would need examples in the library, but those that do could be highlighted in the drop down to let the player know an example exists. This could even open the door to people sharing their own libraries of ships that they share.
Oh man, I thought that was how it worked already. I didn’t realize my fleets were slowly draining their MSP. Panic
Suggestion - New "No Maintenance Cost" Game RuleOr, alternatively, perhaps have it be paid with wealth instead? In the beginning where wealth is scarce, it might be an issue, but then again, maintenance is low at those times, and you can probably compensate the wealth costs by shutting MSP production off more frequently.
Currently in the game setup rules we have "No Maintenance Required", which disables all ship breakdowns, failures, overhauls, and ongoing MSP maintenance costs. I personally would enjoy a less severe version of this where ships still suffer maintenance breakdowns when away from a maintenance base and require overhauls, but there is no annual MSP consumption for ships at a maintenance base. This would allow for building larger standing fleets and make it less costly to keep obsolete ships, while still having the logistics challenge of building forward fleet bases and maintaining pickets.
Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large
Oh man, I thought that was how it worked already. I didn’t realize my fleets were slowly draining their MSP. Panic
They’re not. They consume MSP from the colony they orbit first, if it has any. The maintenance facilities there are constantly building new MSP, provided they have the right minerals.
If you don't already know, you can see how much MSP a fleet is using in the summary above the ship list ("Annual MSP ###") to help you figure out how much you need. Non-commercial ships use 1/4 their cost in MSP per year, and MSP cost 0.25 minerals each, so after 16 years you have paid the ship cost again in maintenance. If you have keep an old ship around for ~30 years, you might as well have scrapped it to get some of its cost back and built two higher-tech ships instead.Oh man, I thought that was how it worked already. I didn’t realize my fleets were slowly draining their MSP. Panic
They’re not. They consume MSP from the colony they orbit first, if it has any. The maintenance facilities there are constantly building new MSP, provided they have the right minerals.
You misunderstood, I thought it was free so I have been setting up my frontier maintenance colonies without any extra MSP or minerals to make it. The fleets are have been maintained on their own supplies for a good while now. So now I gotta scramble to resupply them and figure out how to keep them supplied.
Or, alternatively, perhaps have it be paid with wealth instead? In the beginning where wealth is scarce, it might be an issue, but then again, maintenance is low at those times, and you can probably compensate the wealth costs by shutting MSP production off more frequently.I like this idea quite a bit - maybe we could call the option "Wealth-Based Maintenance" to make it more clearly different from "No Maintenance Required".
Later, wealth often overflows due to having many no-producer colonies, so this would be a nice way to integrate it back more and be useful.
While I'm thinking on ruins, could we get back the chance of uncovering Precursor Robots that were an infrequent spicy treat when snooping around fallen alien cities in VB6?I never liked that feature personally. It basically just makes ruin recovery take longer, because you have to spend the time to send extra troops.
While I'm thinking on ruins, could we get back the chance of uncovering Precursor Robots that were an infrequent spicy treat when snooping around fallen alien cities in VB6?I never liked that feature personally. It basically just makes ruin recovery take longer, because you have to spend the time to send extra troops.
While I'm thinking on ruins, could we get back the chance of uncovering Precursor Robots that were an infrequent spicy treat when snooping around fallen alien cities in VB6?I never liked that feature personally. It basically just makes ruin recovery take longer, because you have to spend the time to send extra troops.
Worse, the "spicy treat" had a tendency to blow up your loot as collateral damage, which meant that the way to recover loot safely was to have a freighter on station constantly moving installations from the ruin site to some other dumping ground colony, which was annoying and immersion-breaking, let's be honest here.
While I think random spiciness is best for roleplaying reasons; perhaps as a nod to gameplay, if a ruin is chosen as "spicy", it would be the very first thing your construction teams unearth? That way the other ruins haven't been generated yet, so there's no worry about them being destroyed.While I'm thinking on ruins, could we get back the chance of uncovering Precursor Robots that were an infrequent spicy treat when snooping around fallen alien cities in VB6?I never liked that feature personally. It basically just makes ruin recovery take longer, because you have to spend the time to send extra troops.
Worse, the "spicy treat" had a tendency to blow up your loot as collateral damage, which meant that the way to recover loot safely was to have a freighter on station constantly moving installations from the ruin site to some other dumping ground colony, which was annoying and immersion-breaking, let's be honest here.
Famously, blue emu's campaign at Wolf 294
While I think random spiciness is best for roleplaying reasons; perhaps as a nod to gameplay, if a ruin is chosen as "spicy", it would be the very first thing your construction teams unearth? That way the other ruins haven't been generated yet, so there's no worry about them being destroyed.
This would actually make a lot of sense and work pretty well...That's fair - so far in my games I've seen defended planets and I've seen planets with ruins, but ne'er the two together. It makes sense that defended planets would/should be guarding something valuable.
...however, we basically already have this since planets with ruins "usually" have ground units defending them. So really the only difference would be if they are already there defending or pop out in a surprise attack. I don't think having both at the same time works very well, practically.
Oh man, I thought that was how it worked already. I didn’t realize my fleets were slowly draining their MSP. Panic
They’re not. They consume MSP from the colony they orbit first, if it has any. The maintenance facilities there are constantly building new MSP, provided they have the right minerals.
You misunderstood, I thought it was free so I have been setting up my frontier maintenance colonies without any extra MSP or minerals to make it. The fleets are have been maintained on their own supplies for a good while now. So now I gotta scramble to resupply them and figure out how to keep them supplied.
Or, alternatively, perhaps have it be paid with wealth instead? In the beginning where wealth is scarce, it might be an issue, but then again, maintenance is low at those times, and you can probably compensate the wealth costs by shutting MSP production off more frequently.I like this idea quite a bit - maybe we could call the option "Wealth-Based Maintenance" to make it more clearly different from "No Maintenance Required".
Later, wealth often overflows due to having many no-producer colonies, so this would be a nice way to integrate it back more and be useful.
The possibility in the class design window to get an extra tab "ship combat" the same as in the naval org. view to check how the disposition of the armament looks like before putting the ship in production.One step further.
- Ability to mark a character to be Retain in advance, before he/she would go to retire.
- On Map, the ability to mark a few systems at once and move them (with Ctrl.)
...
The story character flag will prevent commander retirement...
Is this the suggestions thread for current builds? I'm hoping so.They aren't added because using them would be a no-brainer. Every cargo vessel would have them, there's no decision making involved. You get the admin bonus if you set up your admin structure right and you get the ship commander's bonus on top. It's the same reason why there isn't a terraforming leadership module or Sorium harvesting leadership module.
My suggestion is a Quartermaster's, Cargomaster's, NESCO's or Intendant's (pick your noun) Command & Control module for ships, equivalent to Aux. Control, that adds the Logistics bonus of an officer to the ship.
Surprised that's missing, actually, since that's usually a pretty big deal IRL. Pork chops (supply officers) are two-three steps from God on a ship depending on its class.
They aren't added because using them would be a no-brainer. Every cargo vessel would have them, there's no decision making involved. You get the admin bonus if you set up your admin structure right and you get the ship commander's bonus on top. It's the same reason why there isn't a terraforming leadership module or Sorium harvesting leadership module.
Quote from: Garfunkel link=topic=13404. msg168728#msg168728 date=1708304235They aren't added because using them would be a no-brainer. Every cargo vessel would have them, there's no decision making involved. You get the admin bonus if you set up your admin structure right and you get the ship commander's bonus on top. It's the same reason why there isn't a terraforming leadership module or Sorium harvesting leadership module.
Seems like this is an unpopular idea, considering all the thanks you're getting for shooting me down :-[, but I feel compelled to disagree regardless. First, so what if every cargo ship has one? Let it happen.
Every cargo ship (probably) has shuttle bays too, does that mean they're a nonsense concept?
Same for CIC bridges on combat ships; that tactical bonus is an absolute no-brainer, on any ship larger than an FAC for 3 HS. Are those too much, as well? After all, you get a pretty good Tactical bonus from setting up your Admin structure correctly there, too, if you emphasize the trait. Why even have that, if that's an issue?
Second, if it's really a problem to have a named Cargo officer on every Naval cargo ship, instead of just implied. . . then instead of dismissing the notion completely, let it be large or expensive enough of a module to have a tradeoff. If it's, say, the size of a cargo shuttle bay, until you already have 4 shuttles, adding one or two more gives more than 25% logistics; you'd need a bunch of really good logistics officers to justify trading a shuttle bay for one in smaller ships. That way, only your heavy freighters built out of extremely large shipyards merit the office. Or same/same for large missile boats, stations, etc. - those may have a cargo officer, but your family-owned small freighter doesn't have the dime for such fancy things.
That said, I think there are a couple slots where there is room for meaningful decisions.
The Diplomacy module, to make a ship a diplomatic one, is 500t, and means the ship requires a Captain, rather than Cmdr or Lt.Cmdr.
With this required rank increase, there's a possibility I feel, to appoint a xenolinguist to the diplomatic ship, to provide a bonus to diplomatic effectiveness and/or efforts at translation.
So a diplomatic ship would have two officers - the Captain (using their Diplomacy bonus), and the Xenolinguist (using their Communications? bonus [I'm not entirely sure what the Communications bonus actually does])
There might even be a case to have a dedicated Ambassador, (using their diplomacy bonus), with an even larger "Embassy" module. (10x the size of the DIP module maybe).
Since pure diplomatic ships are fairly small (even my jump-capable ones are only 5000t), then there's a bit more of a decision on whether or not to include modules that would increase their size.
The ELINT module is another one where I think there might be a meaningful decision to be made.
One of the ships that I was using in my game, was a cruiser which had an ELINT module on it. It wasn't the ships main role, it was a frontline warship that also happened to be capable of gathering ELINT.
Now then, with ELINT modules coming in at 500t, then... another module with an intelligence analyst officer might be a meaningful decision to make.
It'd be a straightforward decision to put one of those on a dedicated intelligence gathering ship, which would carry multiple ELINT modules anyway.
But on ships like my cruisers... do I want to spend a couple hundred tons to make it slightly better at ELINT whilst still being a standard combatant ship ? Do I want to use that tonnage on another CIWS instead ?
Quote from: Louella link=topic=13404. msg168759#msg168759 date=1708458447That said, I think there are a couple slots where there is room for meaningful decisions.
The Diplomacy module, to make a ship a diplomatic one, is 500t, and means the ship requires a Captain, rather than Cmdr or Lt. Cmdr.
With this required rank increase, there's a possibility I feel, to appoint a xenolinguist to the diplomatic ship, to provide a bonus to diplomatic effectiveness and/or efforts at translation.
So a diplomatic ship would have two officers - the Captain (using their Diplomacy bonus), and the Xenolinguist (using their Communications? bonus [I'm not entirely sure what the Communications bonus actually does])
There might even be a case to have a dedicated Ambassador, (using their diplomacy bonus), with an even larger "Embassy" module. (10x the size of the DIP module maybe).
Since pure diplomatic ships are fairly small (even my jump-capable ones are only 5000t), then there's a bit more of a decision on whether or not to include modules that would increase their size.
The ELINT module is another one where I think there might be a meaningful decision to be made.
One of the ships that I was using in my game, was a cruiser which had an ELINT module on it. It wasn't the ships main role, it was a frontline warship that also happened to be capable of gathering ELINT.
Now then, with ELINT modules coming in at 500t, then. . . another module with an intelligence analyst officer might be a meaningful decision to make.
It'd be a straightforward decision to put one of those on a dedicated intelligence gathering ship, which would carry multiple ELINT modules anyway.
But on ships like my cruisers. . . do I want to spend a couple hundred tons to make it slightly better at ELINT whilst still being a standard combatant ship ? Do I want to use that tonnage on another CIWS instead ?
I think having a general-purpose "Communications/Intelligence Officer" station which gives bonuses to Communications and Intelligence skills would be really great, as these skills are not currently really handled anywhere in the auto-assignment system which means they tend to go unused unless you manually assign officers.
I think having a general-purpose "Communications/Intelligence Officer" station which gives bonuses to Communications and Intelligence skills would be really great, as these skills are not currently really handled anywhere in the auto-assignment system which means they tend to go unused unless you manually assign officers.
I'm not sure what the "Communications" skill even does. Old wiki pages suggest that it helps with fleet-wide orders.
But if it's really too overpowered, there are answers for that besides "nah, it's a no-brainer. "Ah sorry friend, I did not mean to claim that your proposal is stupid or that you are stupid. I meant it as a "no-brainer design decision", as in, it's not a decision at all because as nuclearslurpee explained, it would always be added. In which case it might as well be automatic like the Bridge is.
And if you have too many officers, try running fighters and carriers, you'll run out of officers quick :P
One way to solve this issue would be by separating civilian and military commanders. I mean, generally it isn't the military officers running oil drilling platforms or mining excavations or planning logistics networks, though of course many veterans end up employed by companies in these fields. I'd love to have separate military and civilian admin systems and leaders - for example most players end up with a massive surplus of administrators unless you really go hard on creating little mining colonies everywhere. I'd love to have them run industrial and logistics admin commands - 'State owned corporations' - in addition to being governors of colonies and sectors. This would also help with the lack of leadership position between a colony and a sector, which has been asked quite a few times.
If there were separate civilian leaders/managers/specialists, it would make sense to have industrial leadership modules to add to commercial ships and the decision there would be whether you have invested enough in the leadership pipeline so that you have sufficient numbers of trained specialists to fill out all these roles, or whether you run 'poor leadership' ships & stations. Granted, somewhat minor decision but at least one that would require long-term planning.
The ability to SM create NPR minor races, right now it seems like when creating a new race through the system screen, the moment I tick NPR, the option for neutral race gets blocked. Interestingly trying to just create a neutral race results in all of the installations and stockpiles all default to 0.Neutral and minor are two different things.
The ability to SM create NPR minor races, right now it seems like when creating a new race through the system screen, the moment I tick NPR, the option for neutral race gets blocked. Interestingly trying to just create a neutral race results in all of the installations and stockpiles all default to 0.Neutral and minor are two different things.
Neutral race is a completely passive population, usually on the same body as the actual player race. It exists to simulate non-aligned countries in multi-faction game and allows all active factions to utilize that population to simulate immigration to bring in extra colonists as needed. Neutral race has no AI code, cannot have any installations and will never do anything except grow its population.
Minor race is an alien race that is created when a player race enters a system, just like a normal NPR and it will grow and expand like a normal NPR, but it will never leave its home system. It exists to create an option between a full-blown NPR and a low-tech/conventional 'NPR' which will not do research or build industry - this last option exists to simulate low-tech alien populations that can be civilized through the power of superior firepower.
Just a quick suggestion: Could there be logic implemented for civilian movement of colonists, similar to civilian installation movements? ie, could the UI on the Civilian/Flags tab include a target population, for supply or demand, after which the population is set to stable?
Just had my civilians completely drain one of my mining colonies of settlers. Kind of frustrating when I still want people there, just not as many as I had.
Thank you!
Hope you are enjoying the travel life, Steve!
As a possible alternative to one of my earlier suggestions (being able to sort the minerals window by total accessibility), I would also be amenable to the ability to export/copy the text in that window.
I can more-or-less brute-force that functionality by OCR'ing screenshots of the window, but that's obviously not ideal.
Just a quick suggestion: Could there be logic implemented for civilian movement of colonists, similar to civilian installation movements? ie, could the UI on the Civilian/Flags tab include a target population, for supply or demand, after which the population is set to stable?
Just had my civilians completely drain one of my mining colonies of settlers. Kind of frustrating when I still want people there, just not as many as I had.
Thank you!
Hope you are enjoying the travel life, Steve!
I think what you want is already implemented.
In the economics window, under the civilian/flags tab, at the top there are 3 radio buttons.
Stable or destination should prevent civilians from taking colonists (although I expect it will not change currently assigned orders).
When a colony is created, it is set as a destination. I think there is a population level (probably 10 million) where the setting is automatically changed from a destination to source, it sounds like that changeover affected your colony.
Just a quick suggestion: Could there be logic implemented for civilian movement of colonists, similar to civilian installation movements? ie, could the UI on the Civilian/Flags tab include a target population, for supply or demand, after which the population is set to stable?
Just had my civilians completely drain one of my mining colonies of settlers. Kind of frustrating when I still want people there, just not as many as I had.
Thank you!
Hope you are enjoying the travel life, Steve!
I think what you want is already implemented.
In the economics window, under the civilian/flags tab, at the top there are 3 radio buttons.
Stable or destination should prevent civilians from taking colonists (although I expect it will not change currently assigned orders).
When a colony is created, it is set as a destination. I think there is a population level (probably 10 million) where the setting is automatically changed from a destination to source, it sounds like that changeover affected your colony.
Well aware of this functionality. The problem is when I want to bring the population up from 50 M to 60 M, for example. Or if I want 10 M colonists picked up, but no more. Right now, I can have a full blown industrial colony have all 50 M population set to "Source", wanting to move the extra 5 M pop that's there, and the whole 50 M pop will be resettled very quickly when there are too many civvies. It would be awesome to have something a little more granular than what is already available.
In case anyone was curious: this works, but actually getting the text into something that Excel can work with was rather a pain - nearly as much as the OCR route, although without the worries of incorrect characters (and with the bonus of getting an entire system in one shot, rather than 42 planets at a time).As a possible alternative to one of my earlier suggestions (being able to sort the minerals window by total accessibility), I would also be amenable to the ability to export/copy the text in that window.
I can more-or-less brute-force that functionality by OCR'ing screenshots of the window, but that's obviously not ideal.
On a system by system level, you can get the mineral deposits in text form.
In the main window, in the left hand box, there is a tab called "Min Text", which has the body, mineral, and accessibility for the present system.
You can copy and paste the contents into a text file or spreadsheet.
Ability to delete prototypes tech (P) from Ship Design Window.
Ability to delete prototypes tech (P) from Ship Design Window.
You can either set them to be obsolete or if you create a research project for them you can then delete them from the research tab.
Ability to delete prototypes tech (P) from Ship Design Window.
You can either set them to be obsolete or if you create a research project for them you can then delete them from the research tab.
That is the reason behind the suggestion.
I'm sure this one has been brought up a few times by now -
We need a way to search and locate Systems on the Galactic map. I have 150 systems, it can sometimes take a while to track down a system by name alone. Often I have to take several passes at the galaxy to find one system. Maybe also interface with the Mineral Survey Window and snap to a system on double click.
I'm sure this one has been brought up a few times by now -
We need a way to search and locate Systems on the Galactic map. I have 150 systems, it can sometimes take a while to track down a system by name alone. Often I have to take several passes at the galaxy to find one system. Maybe also interface with the Mineral Survey Window and snap to a system on double click.
361 systems and climbing reporting in; I'll echo this suggestion but also add my own: bringing back zooming in/out on the galaxy map (it existed for VB6) would be amazing.
I'm sure this one has been brought up a few times by now -
We need a way to search and locate Systems on the Galactic map. I have 150 systems, it can sometimes take a while to track down a system by name alone. Often I have to take several passes at the galaxy to find one system. Maybe also interface with the Mineral Survey Window and snap to a system on double click.
361 systems and climbing reporting in; I'll echo this suggestion but also add my own: bringing back zooming in/out on the galaxy map (it existed for VB6) would be amazing.
This would also be worthwhile for the "Autoroute" checkbox on the ship movement screen. It would be nice to be able to just type the name of the system I want the fleet to go to.
More importantly, adding a suggestion: autoroute currently selects the shortest route by jumps instead of the shortest route by distance and travel time; this results in some hilariously bad autoroutes. I have a black hole in my main pipeline that if I manually add two extra jumps to enter the black hole via a different jump point I can shave dozens of billions of kilometers (6-8 weeks at 5,000km/s) off the distance and travel time. Exhibit A:
My basic suggestion is to have equal levels fall in the middle of effectiveness. Say, give jammers a +1 to effective level, so an even ECM vs ECCM shows 80% of normal performance. It's an edge to ECM, but not an overwhelming one. For decoys, instead of capping effectiveness if ECM has an edge, why not let it keep having a bigger edge? Or if that's too much, change the benchmark for full performance from equal levels to a level or two of ECM overmatch. So maybe if you're shooting 5 ECM decoys vs 5 ECCM, each decoy looks like size 3 instead of size 5.
Yeah, that would work fine. If ECCM is actually about twice as expensive as ECM, then it's reasonable to assume that you'll generally have a 1-level advantage in ECM, and the problem goes away, at least for jammers. I'd still like something else to be done with decoys, because 5 v 5 and 10 v 0 looking the same is kind of absurd.My basic suggestion is to have equal levels fall in the middle of effectiveness. Say, give jammers a +1 to effective level, so an even ECM vs ECCM shows 80% of normal performance. It's an edge to ECM, but not an overwhelming one. For decoys, instead of capping effectiveness if ECM has an edge, why not let it keep having a bigger edge? Or if that's too much, change the benchmark for full performance from equal levels to a level or two of ECM overmatch. So maybe if you're shooting 5 ECM decoys vs 5 ECCM, each decoy looks like size 3 instead of size 5.
I do generally agree that the ECM/ECCM calculations could use a bit more nuance. I also think how to achieve that nuance is trickier than it seems. One simple change could be to leverage research costs to generate a "pseudo-balance" in ECM vs ECCM at the strategic level.
That's exactly what I thought! We need 1 ton and 0.1 ton misc components! I actually prefer using them to achieve a rounded weight instead of having a fuel capacity of 213,000 liters ;DSorry dude but Steve has shot these sort of suggestions down multiple times in the past. Sure, they work wonders for the experienced user who is very careful but for everyone else, they are a major source of faulty bug reports and frustration because the player messed something up. And Steve does not want to have to code bajillion layers of security-code to prevent players from doing stupid smeg.
New suggestion:
Do not clear current orders when adding a new Template order batch. This would allow for "modular building" of orders. Say Template 1 is to load 1000 of each mineral on Earth, while Template 2 is to unload all on Ceres, then Mars. Template 1 could then be used for different locations afterward.
And ideally, it would be nice if most orders could include an option to "perform task at current location". Instead of "Load minerals on Earth", it would be "Load minerals at current location", and voilà, Template orders would be significantly more versatile.
The research requires 4000 RP.
The Hangar Deck component has 4x the capacity of the Boat Bay, and has 4x the size, 4x the cost, 4x the crew, and 4x the HTK.
In other words, a Hangar Deck is almost entirely equivalent to 4 Boat Bays.
The only difference is using 4 components at 1 HTK each vs 1 component at 4 HTK.
I guess the latter could provide a terribly slight, terribly situational advantage.
But it hardly seems worth the effort to research.
Suggestion: Improve Hangar Decks relative to Boat Bays to justify the 4k RP cost.The research requires 4000 RP.
The Hangar Deck component has 4x the capacity of the Boat Bay, and has 4x the size, 4x the cost, 4x the crew, and 4x the HTK.
In other words, a Hangar Deck is almost entirely equivalent to 4 Boat Bays.
The only difference is using 4 components at 1 HTK each vs 1 component at 4 HTK.
I guess the latter could provide a terribly slight, terribly situational advantage.
But it hardly seems worth the effort to research.
Simple idea: reduce Hangar Deck crew requirement from 12 to 9.
Reducing cryogenic transport modules capacity by a factor of ten (or some other number) would be an interesting option to slow down expansion, it always feels a little silly just how quickly you can move nearly arbitrary amounts of people to me.
To be fair it's more from a preference point of view than a mechanical one, from a mechanics point of view colonization/population transport mechanics in this game are perfectly fine. I personally just find how quickly you can shift hundreds of millions and then billions of people and think it would interesting if settling the stars was a long drown out process over the course of centuries instead of TN tech get's discovered tomorrow and before I even retire Earth is ghost town type timeline you see in the game.Reducing cryogenic transport modules capacity by a factor of ten (or some other number) would be an interesting option to slow down expansion, it always feels a little silly just how quickly you can move nearly arbitrary amounts of people to me.
Interesting.
Do you mean you can do this quickly from the game start, or do you mean that eventually you can move large amounts quickly?
It takes me decades of constant shipbuilding and shipyard expansion from the start to grow my colony ship fleet enough to merely keep up with the rate of pop growth on the HW.
Maybe after fifty years I have enough pop-moving capacity to really spread the population evenly among the HW and other major colonies.
Is that quickly? It seems a long time to me.
Reducing cryogenic transport modules capacity by a factor of ten (or some other number) would be an interesting option to slow down expansion, it always feels a little silly just how quickly you can move nearly arbitrary amounts of people to me.
Request for a new fleet order: Begin Overhaul and Join FleetYou can already do this. Give the order for overhaul and add "join fleet" after it.
I often give ships orders to return to a planet and begin overhaul, and as soon as they arrive and I receive the interrupt event, I manually drag them to a holding fleet.
It would be great if I could do this with a single order and avoid all the extra interrupts and manual fiddling.
Request for a new fleet order: Begin Overhaul and Join FleetYou can already do this. Give the order for overhaul and add "join fleet" after it.
I often give ships orders to return to a planet and begin overhaul, and as soon as they arrive and I receive the interrupt event, I manually drag them to a holding fleet.
It would be great if I could do this with a single order and avoid all the extra interrupts and manual fiddling.
It seems that civilian ships will load colonists from colonies marked as sources even if there are no destinations available. This isn't a big deal normally, but it's somewhat annoying in empires with multiple species: colony ships will fill up with one species, and if they don't have a valid destination they won't be able to carry colonists of a different species. I think it would be better for civilian colony ships to only pick up colonists once they have a valid destination, like civilian freighters.
Yes, I will redo the 'air' component of ground combat at some point, probably by introducing a new ground unit type to represent helicopters / attack aircraft / fighter etc.A bit late to the party but since you've recently started back up posting AAR's after starting your nomadic life I figured now may be a good time to start throwing ideas at you. While there have been many many suggestions for an aircraft unit type, not many actually go in depth on how to actually implement them besides broad strokes "GSF but less micro and mo' better", which is an alright start but we could definitely go deeper. The main topics to discuss is what separates an Air vehicle from a ground vehicle in terms of design and how they interact with ground units, Anti-Air, and each other in regards to the ground combat phase.
| Base Unit | Size | HP | Slots | To Hit Mod | Max Fort | Armor | Available Components |
| Ultra-Light Air Vehicle | 72 | 1.0-1.5 | 1 | 0.05 | 1.0 | Unarmored (1.5x) | CAP, HCAP, LAC, MBL, LAV, LAA, LAG, FFD, LOG |
| Light Air Vehicle | 120 | 1.5-2.5 | 2 | 0.1 | 1.0 | Unarmored (1.5x) | CAP, HCAP, LAC, MAC, MBL, LAV, MAV, LAA, MAA, LAG, MAG, FFD, LOG? |
| Medium Air Vehicle | 240 | 2-4 | 3 | 0.15 | 1.0 | Unarmored (1.5x), Armored (2.0-2.5x) | CAP, HCAP, LAC, MAC, HAC, MBL, HB, LAV, MAV, HAV, LAA, MAA, HAA, LAG, MAG, HAG, FFD, LOG? |
| Heavy Air Vehicle | 360 | 3-5 | 4 | 0.2 | 1.0 | Unarmored (1.5x), Armored (2.0-2.5x) | CAP, HCAP, LAC, MAC, HAC, MBL, HB, SHB, LAV, MAV, HAV, SHAV, LAA, MAA, HAA, LAG, MAG, HAG, SHAG, FFD, LOG? |
| Component Name | Abbreviation | Size | Penetration | Damage | Shots |
| Light Air-to-Ground | LAG | 20 | 2-3 | 2-3 | 3-4 |
| Medium Air-to-Ground | MAG | 40 | 4-6 | 4-6 | 2 |
| Heavy Air-to-Ground | HAG | 80 | 8 | 8 | 1-2 |
| Super-Heavy Air-to-Ground | SHAG | 120 | 10 | 10 | 1 |
words
I believe aircraft should be able to equip CAP, Auto Cannon, and Anti-Air weapons as they are now (might need tweaking to AA weapon parameters), AA components obviously being for use against hostile air units, while CAP and AC would be a sort of dual purpose weapon targeting both air and ground units. For attacking ground targets I am split between giving aircraft access to Anti-Vehicle and Bombardment weapons, or giving them a new Air-to-Ground component that blends the 2 together, again I'll detail out the +/- further in the Air Combat Phase.Note that GSFs currently have access to LAC, LB, and LAA-like components as fighter pod loadouts, so there's not really a reason to preclude aircraft from using bombardment components.
Moving on though, non-combat equipment, FFD is a must. It is only the the first and foremost job of aircraft to be a scout/reconnaissance force and to direct friendly fires, from the first scout aircraft of the 1910s, to modern unmanned drones.Note that FFD only works in a frontline formation, AFAIK, so recon aircraft are limited to organic assets in frontline formations unless we change that mechanic - which we could, but I'd prefer to keep things simple and keep the impact on existing ground unit mechanics minimal.
we could also implement a new feature where if an intermediate formation is destroyed, it would cut off the supply chain from higher units to lower ones,This functionality already exists in the game if you use LVH logistics. However, this conflicts with INF logistics managed through the replacements/unit series mechanic, which is population-based and does not depend on the order of battle. I don't think it is worth reworking this mechanic and making it much less convenient in the general case to support this specific case - destruction of headquarters already has enough benefits to be worthwhile, I think.
Air Unit Base Types
Base Unit
Ultra-Light Air Vehicle
Light Air Vehicle
Medium Air Vehicle
Heavy Air Vehicle
Lastly, the first true special rules for aircraft is how they truly do not benefit from the terrain and can not physically dig in fortify their position, because well, there is no dirt in the sky.
Now for the nitty gritty of how Air-to-Air, Air-to-Ground, and Ground-to-Air combat works. I think it best to implement semi-separate Air Combat phases that precede the Direct combat, Support Fire, Ground AA, and Resupply phases already in place.
Second, they can resupply any unit globally, rather than just internal of a specific unit and its parent formations.
#1 What the hell should the 3/4 letter acronym be!?!?
The other big thing being in order to make aircraft somewhat viable and interesting in my eyes is that we have to give them very specific rule exceptions which kinda breaks Steve's design philosphy for Aurora C#,
Thank you, probably could merit its own individual suggestion thread, but I already had open as just a reply when I first started about ~60 hours ago. And don't worry I got pretty thick skin and after my last effort post forever ago try to reel back on my own abrasiveness. You do bring up some good and valid points, and I think we are both trying to think of the best and most simple ways to do this. I'd say my suggestion is focused more on using existing ground vehicle mechanics with some minor/major tweaks to replicate GSF mechanics, whereas you are trying to mesh GSF mechanics into ground combat. Ultimately its up to Steve to decide which way he wants to gowords
This is quite an effortful post and deserves far more credit than I can give it. As it happens, I shall have to suffice with a simple reply.
I'll not wade too deeply into the mechanics here, and keep my comments to a relatively high level. In short: I like the ideas, but I think it is rather too complex for the fidelity and mechanics of Aurora's ground combat as it currently stands, and I'd prefer to keep that simplicity where possible. Furthermore, I think we can accomplish a lot of this by simply repurposing the existing ground support fighter (GSF) mechanics in terms of targeting, combat, etc. so that we are adding a minimum of new mechanics and rules to the system.
A couple of mechanics notes:
Yep, I had a lot of the Changelog mechanics posts open for reference while typing everything out. The problem with the bombardment pod is that it is treated as always long range/heavy bombardment, ignoring the mechanics of the short range bombardment weapons, which if we give aircraft access to those will it require extra tuning and coding? ALso GSF also don't have a direct AV equivalent so do you not allow aircraft to equip them and will the range properties of them need to get changed up? Its why I'm partial to creating a new AG component thats a blend of both, but I don't know the code well enough to say which would be easier to adapt and why I listed both options.Quotemy wordsNote that GSFs currently have access to LAC, LB, and LAA-like components as fighter pod loadouts, so there's not really a reason to preclude aircraft from using bombardment components.
I shoulda/coulda/woulda clarified, though this was assumed. It is Forward Fire Direction after all, not Backward Fire Direction.Quotemy wordsNote that FFD only works in a frontline formation, AFAIK, so recon aircraft are limited to organic assets in frontline formations unless we change that mechanic - which we could, but I'd prefer to keep things simple and keep the impact on existing ground unit mechanics minimal.
Good catch, the replacements strategy was only half way in my mind thinking. Again, in my post in the bonus suggestions, I do have a slight disagreement with how resupply works with units being "consumed". It may be a future effort post topic for a revamp of the system to actually track its supply usage which is already done in some form with combat units tracking their 10 combat cycles before needing resupply.Quotemy wordsThis functionality already exists in the game if you use LVH logistics. However, this conflicts with INF logistics managed through the replacements/unit series mechanic, which is population-based and does not depend on the order of battle. I don't think it is worth reworking this mechanic and making it much less convenient in the general case to support this specific case - destruction of headquarters already has enough benefits to be worthwhile, I think.
----
As far as my more general thoughts:I'm not opposed to the idea of flight being a capability, I think what you suggest would be far more convoluted to implement as currently all capabilities only affect the To-Hit and Hit Chances when fighting in different terrain/environment (and boarding allowing a new "environment" which is kinda iffy as it only works for offense since all ground units work defensively on board). Adding new mechanics for size/GSP/HP multipliers I would think would be significantly more code intensive rather than adding new Base Unit Types. There's plenty of space in the Ground Unit Design window for 4 more.Quotemy words
I think this is too complicated. We currently have a grand total of seven ground unit types, adding several more just for aircraft seems rather awkward. I would also suggest that it is unnecessary, and an easier approach would be to simply model air units as a capability which can be applied to any vehicle type, conferring (say) 2x size, 2x GSP, 0.5x HP, and 0.5x armor multipliers in exchange for using the air combat mechanics instead of normal ground combat mechanics. I would prefer this approach as it keeps the ground units UI simple while allowing for a lot of roleplay freedom - for example, having an armor multiplier means I could use a VEH base type and choose between light armor for 'normal' warplanes and medium armor for my A-10 Warthog equivalents. On the other hand, designing a UHV with flight capability to model a massive hovering skybase sort of aircraft is very fitting for some settings.
Using the existing unit types as the basis also means the question of weaponry is cleared up as well, and personally I see no reason to add weapon restrictions and restrict roleplay - heavier weapons are generally more specialized anyways, so I doubt we're opening up some silly exploit involving UHV aircraft with 4x SHAV or something.
Valid points, I could concede on my suggestion for the permanent hidden aircraft capability reducing the terrain factor rather than negating it outright. And while I understand the want to have aircraft protected in hangars able to be fortified, again in headcannons, you may also have to worry about your actual runways being damaged and not all your aircraft being stowed away at the same time. I think its a good trade off with aircraft essentially being glass cannons for all intents and purposesQuotemy words
Partially agreed on fortification, disagreed on terrain. I think aircraft should be able to benefit from terrain, it may not be the most "realistic" but I think a lot of headcanons imagine, say, aircraft sweeping around mountain peaks or skimming forests to fly beneath enemy radar before popping up to fire a torpedo down the exhaust port... or something more realistic. :P Again, no need to restrict it here.
As far as fortification goes, I would say it can still apply when aircraft are the target of normal ground unit fire - representing them being caught at base in a hangar, surely an airbase can be fortified to some degree? Of course, fortification should not apply when facing AA fire during the AA fire phase.
Like I said above, I had those open for referencing. I do feel like you are kinda repeating what I was proposing though. I probably should have added some more examples in my post. Currently as stands for GSF, they can be assigned to Provide Ground Support to units with fire support as bombardment does, Search and Destroy which just gives them open range on all ground units (though I'm not clear in the wording of the rule saying they can target any formation regardless of position if it factors in positional weighting), or Flak Suppression to directly target ground AA. All of these can be replicated just with the current positional, support, and FFD functions already in place for ground forces. Search and Destroy is the easiest, its just aircraft set to Frontline Attack. Ground support is also simple with setting an air formation to support. Flak suppression is a little tricky, while there are no current mechanics for GU to target specific elements, it can be pretty simply be represented by air units supporting another air unit. If the front-line aircraft are targeted (preferably those equipped with FFD) by surface to Air ordnance, then the supporting unit can engage the attacking units in the same manner as Counter Battery fire mechanics. We also have another function that GSF's lack to simulate Escort Fighters, aircraft with AA weapons supporting air units with AV/B/AG weapons and "counter battering" enemy aircraft targeted your bombers.Quotemy words
As mentioned, I would simply take the ground support fighter rules (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Air_to_Ground_Combat) (including the following ground-based AA fire rules (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire)) and paste them onto the new Flight capability. Since those rules are already written out in sufficient detail for discussion purposes, I won't rehash them here.
One simplification here is that, since we can't set orders for ground units in the UI, I would probably use existing mechanics for bombardment and AA targeting to make this work. In short, aircraft formations can be assigned to support frontline formations or left unassigned. In most cases, regardless of assignment they have the same targeting options as HB units (aside from eliminating the target size reduction for support/rear formations, as you stated). The exception would be AA components which fire as AA weapons following the targeting rules for HAA.
This does mean the bombardment components are a tad lackluster since they won't have any special ability making up for their inflated sizes, but I think that's fine as not every component needs to be equally useful in every situation.
I did state that Air logistics should be resolved last vs internal and parent supply draw. Though like you had mentioned above, the replacement unit tactic does kinda negate the benefit of aircraft logistics being able to resupply any formation regardless of hierarchy. Once again, the consumption of whole units as supplies is a bit of a bore.Quotemy words
I would actually prefer to keep the same rules, as this makes it easier to control the flow of supplies. I suppose an alternative would be to have airborne supply distributed last in the resupply order, which would ensure it ends up where it is needed while maintaining the special flavor, but I'm not sure if that mechanic would see a lot of use in practice. Resupply is already a big enough cost that I don't see airborne supply being very cost-effective - and Aurora doesn't really model the kinds of tactical situations where airborne supply is most useful (e.g., formations aren't getting surrounded and cut off tactically, Aurora simply does not model this).
That would be acceptable if flight was a capability trait, though not a fan of it for base unit types.Quote#1 What the hell should the 3/4 letter acronym be!?!?
I'd settle for an '(A)' following the unit base class abbreviation, e.g., "LVH(A)" or "VEH(A)". Should be easy enough to pick out of a lineup.
I do feel like we are both are trying to reach the same goal just from different starting points. We both want to make a dagger, one of us is elongating a knife while the other is shortening a sword. And agreed, GSF's are just a bit too clunky for my taste (which is almost universally agreed on), and while the concept of trans-atmospheric fighters is appealing, I don't think there is a really good way to bridge the very different gameplay mechanics of Naval Combat and Ground Combat. Its best to just let fighters operate under the already existing orbital bombardment mechanics.QuoteThe other big thing being in order to make aircraft somewhat viable and interesting in my eyes is that we have to give them very specific rule exceptions which kinda breaks Steve's design philosphy for Aurora C#,
This is another major reason why I prefer to work within the existing mechanics as much as possible by treating flight as another capability and repurposing the existing GSF rules. We could keep GSFs as they are but I personally see no reason to, space-to-ground fighters can use regular weapons and rules like everybody else IMHO.
----
Again, great post, and I hope this doesn't come across as being overly critical, my goal is really more to look at how we can best mesh new air units with the existing mechanics without upsetting the bucket too much and still get a satisfying flight mechanic that promotes strategic decisions and roleplay openness in equal measure.
I think this is too complicated. We currently have a grand total of seven ground unit types, adding several more just for aircraft seems rather awkward. I would also suggest that it is unnecessary, and an easier approach would be to simply model air units as a capability which can be applied to any vehicle type, conferring (say) 2x size, 2x GSP, 0.5x HP, and 0.5x armor multipliers in exchange for using the air combat mechanics instead of normal ground combat mechanics. I would prefer this approach as it keeps the ground units UI simple while allowing for a lot of roleplay freedom - for example, having an armor multiplier means I could use a VEH base type and choose between light armor for 'normal' warplanes and medium armor for my A-10 Warthog equivalents. On the other hand, designing a UHV with flight capability to model a massive hovering skybase sort of aircraft is very fitting for some settings.
Using the existing unit types as the basis also means the question of weaponry is cleared up as well, and personally I see no reason to add weapon restrictions and restrict roleplay - heavier weapons are generally more specialized anyways, so I doubt we're opening up some silly exploit involving UHV aircraft with 4x SHAV or something.
I'm not opposed to the idea of flight being a capability, I think what you suggest would be far more convoluted to implement as currently all capabilities only affect the To-Hit and Hit Chances when fighting in different terrain/environment (and boarding allowing a new "environment" which is kinda iffy as it only works for offense since all ground units work defensively on board). Adding new mechanics for size/GSP/HP multipliers I would think would be significantly more code intensive rather than adding new Base Unit Types. There's plenty of space in the Ground Unit Design window for 4 more.
Partially agreed on fortification, disagreed on terrain. I think aircraft should be able to benefit from terrain, it may not be the most "realistic" but I think a lot of headcanons imagine, say, aircraft sweeping around mountain peaks or skimming forests to fly beneath enemy radar before popping up to fire a torpedo down the exhaust port... or something more realistic. :P Again, no need to restrict it here.
As far as fortification goes, I would say it can still apply when aircraft are the target of normal ground unit fire - representing them being caught at base in a hangar, surely an airbase can be fortified to some degree? Of course, fortification should not apply when facing AA fire during the AA fire phase.
Valid points, I could concede on my suggestion for the permanent hidden aircraft capability reducing the terrain factor rather than negating it outright. And while I understand the want to have aircraft protected in hangars able to be fortified, again in headcannons, you may also have to worry about your actual runways being damaged and not all your aircraft being stowed away at the same time. I think its a good trade off with aircraft essentially being glass cannons for all intents and purposes
In the Environment tab, together with the Annual Terraform capacity, I would like to read the number of the Terraforming Istallations active on (or near) a body.