First of all, need to thank you Steve for that game. many years creating an empire, and living experiences no other game can bring.
i have new game, but old problems :)
as a lot people have, my screen resolution is 1366X768.
is there any way to change it? we need to use the 3rd party programs always recommend people?
thx in advance!
First of all, need to thank you Steve for that game. many years creating an empire, and living experiences no other game can bring.
i have new game, but old problems :)
as a lot people have, my screen resolution is 1366X768.
is there any way to change it? we need to use the 3rd party programs always recommend people?
thx in advance!
According to Steam stats, only about 10% of people have resolutions below 1440x900, so that is why I chose that resolution. I don't plan to add a smaller resolution, but there are lots of options for cheap external monitors or using TV, etc.
When you want quit the game, a window pop up and asking "do you want to save the game"
As one of those with a 1366x768 screen, is there any chance of a "can move the screen around" option? Obviously not now as I am sure bug-squashing takes priority. I can open everything up and so on, but the buttons at the bottom don't even show up. Another monitor isn't really an option at the moment.>move taskbar to the side
An autosave every xx number of days/increments.
Could we maybe get a option to select what interrupts the auto turns?
Turns go so fast that, I could really need to stop the auto turns on more events.
Also could we get the default colors back in the event viewer please? :)
Please add a warning if you try to fit a commercial engined starship with a military jump drive
It will fail to transit, yes
Quote from: dr125 link=topic=10640. msg121322#msg121322 date=1586719373As one of those with a 1366x768 screen, is there any chance of a "can move the screen around" option? Obviously not now as I am sure bug-squashing takes priority. I can open everything up and so on, but the buttons at the bottom don't even show up. Another monitor isn't really an option at the moment.>move taskbar to the side
>move the windows up with the mouse to peek at the buttons
>window scaling in settings? I have heard that might work.
void CheckConditionalOrders(Fleet fleet)
{
CheckFirstConditionalOrder(fleet);
CheckSecondConditionalOrder(fleet);
}
void CheckConditionalOrders(Fleet fleet)
{
CheckFirstConditionalOrder(fleet);
CheckSecondConditionalOrder(fleet);
var current = fleet;
while (current.HasParent())
{
current = current.Parent;
CheckFirstConditionalOrder(current);
CheckSecondConditionalOrder(current);
}
}
It would be great if we could give standing and conditional orders to admin commands, this would allow for easy automation. This change can be implemented by adding the appropriate columns for such orders to the admin commands. Assuming the current code looks something like this:Code: [Select]void CheckConditionalOrders(Fleet fleet)
{
CheckFirstConditionalOrder(fleet);
CheckSecondConditionalOrder(fleet);
}
then changing the code to something like this would work:Code: [Select]void CheckConditionalOrders(Fleet fleet)
{
CheckFirstConditionalOrder(fleet);
CheckSecondConditionalOrder(fleet);
var current = fleet;
while (current.HasParent())
{
current = current.Parent;
CheckFirstConditionalOrder(current);
CheckSecondConditionalOrder(current);
}
}
The while loop would keep going up the command hierarchy and check conditional orders attached to the admin commands. This would allow us to effectively add more than 2 conditional orders to a fleet. It would also simplify setting up conditional orders for, say, survey fleets since the orders can be entered at the admin command level and all that needs to be done to have a fleet operate as a survey fleet is just to attach it to that command.
- When starting on a conventional game I noted that all of my officers and admin started at 20 years old. Seems like there are some serious over achievers in my navy! I've also seen officers retiring at the age of 31 or 32 which also seems pretty slack. Perhaps add five years to the age of a person for each rank they have?
Is it possible to implement dependance between generated officers age and rank?
Now, Aurora generates 20y.o. officers only. It's ok, when they are naval lieughtenants. It's quite strange, when they are lieughtenant commanders and majors (default rank scheme). It's a major disbilieve disaster when they are (pregenerated) higher commanders, research leaders and high-level administrators.
I'l be happy to see the commission ages increase to 23+-1y.o., and a distribution of pregenerated ranks between this age and mean retire age (smth about 75 y.o.) correspondingly to the ranks quantity in this branch.
Can an option be added to copy the design of a ground formation?
I find that I use the same protection detail for my geo/xeno/construction ground forces. Being able to copy one and then just swap out the different vehicles would be quicker.
I just noticed that the stats on ground units do not update with the latest racial weapon and armor levels.
There needs to be some kind of system in place that allows us to "retrofit" ground templates en masse. . .
I just noticed that the stats on ground units do not update with the latest racial weapon and armor levels.
There needs to be some kind of system in place that allows us to "retrofit" ground templates en masse. . .
Refit to upgrade, yes. Free & automatic upgrade, no. Rifles don't just turn into better rifles.
No, it's a terrible idea. Then we'd be right back where we were before, where 90% of the officer corps would retire before the first ship was launched.And what's wrong with it? Starting with aerospace forces, they nearly should retire before the first ship was launched, younger ones will get their places, that's ok.
It would be nice if the events would show up on the map, its little bit hard to keep track about what happens on a notebook without it. And it should not be to hard to implement this.
I might be missing something, but would be cool to see Hierarchy option in Ground Forces Formation Templates.
Basically you can set up for example a "1x INF Corps -> 3x INF Divisions -> 3x INF Battalions" standard hierarchy and can then select a ticbox "include subunits in training" in GU Training which allows you to instead of training an empty Corps trains INF Corps + 3x INF Divisions + 9x INF Battalions and deliver them in the assigned hierarchy into your OOB when finished.
Did not read the whole thread.But I will always have a dedicated tanker harvesting fuel from my harvesting bases and delivering it to my colonies.
Get we get "Design Warnings" for the new dependencies:
Sorium Harvesting without fuel transfer, etc
Did not read the whole thread.
Get we get "Design Warnings" for the new dependencies:
Sorium Harvesting without fuel transfer, etc
Did not read the whole thread.
Get we get "Design Warnings" for the new dependencies:
Sorium Harvesting without fuel transfer, etc
If anything it should be checking the tanker box and not having the new fuel transfer comp.
I might be missing something, but would be cool to see Hierarchy option in Ground Forces Formation Templates.
Basically you can set up for example a "1x INF Corps -> 3x INF Divisions -> 3x INF Battalions" standard hierarchy and can then select a ticbox "include subunits in training" in GU Training which allows you to instead of training an empty Corps trains INF Corps + 3x INF Divisions + 9x INF Battalions and deliver them in the assigned hierarchy into your OOB when finished.
Some sort of delimiter in the ship type droplist between the abbreviation and the type for clarity purposes.
And another separate suggestion, about auto-names for ground units. I think they should be numbered by formation template (or have an option to do so) and not every single ground unit in the race.
(So instead of you building 1st Armor, 2nd Infantry, 3rd Armor, 4th Armor, 5th Artillery it would be 1st Armor, 1st Infantry, 2nd Armor, 3rd Armor, 1st Artillery and so forth.
Oh tiny little thing, maybe I'm dumb and can't find it but somewhere (perhaps the new game screen?) can we have the version number?
I can't remember if I've updated or not! :)
Not entirely sure if this is a bug or missing feature or what.
But there doesn't seem to be a way to see which class designed might be build in same shipyard as each other
There should be some way to avoid opening up multiple instances of a single windows (ex. multiple ground forces windows), and when one clicks the button on the system view top bar, it should bring forward the corresponding window (like in VB6)
Quote from: firsal link=topic=10640. msg122437#msg122437 date=1586870280There should be some way to avoid opening up multiple instances of a single windows (ex. multiple ground forces windows), and when one clicks the button on the system view top bar, it should bring forward the corresponding window (like in VB6)
Yeah, that has been an annoyance when after an hour of clicking I hover over the task bar and see twenty instances of the same window open.
Steve could run a simple side game with only the player empire and no NPR for a few hundred years to get the steady-state officer age distribution. He might need to turn off "up or out", but that should give a good distribution for at-start.No, it's a terrible idea. Then we'd be right back where we were before, where 90% of the officer corps would retire before the first ship was launched.And what's wrong with it? Starting with aerospace forces, they nearly should retire before the first ship was launched, younger ones will get their places, that's ok.
Quote from: Kristover link=topic=10640. msg122439#msg122439 date=1586870370Quote from: firsal link=topic=10640. msg122437#msg122437 date=1586870280There should be some way to avoid opening up multiple instances of a single windows (ex. multiple ground forces windows), and when one clicks the button on the system view top bar, it should bring forward the corresponding window (like in VB6)
Yeah, that has been an annoyance when after an hour of clicking I hover over the task bar and see twenty instances of the same window open.
Or maybe a "close all" Button (except for the Main Game Window of course) OpenTTD does this nicely with the "Delete" Hotkey
Can we get rid of the 30 day turn option, or is that a bridge too far? Now that the game runs so fast, it seems a little excessive.I think the 30-day turn is still useful for conventional starts, but I do agree with getting rid of expansion tasks and renaming "Continual Capacity Expansion" to just "Expand Capacity".
While we're at it, can we remove the fixed shipyard expansion tasks (add 500, 1000, 2000, 5000, 10000 tons)? The new features on the continual capacity expansions make those orders superfluous.
A way to obsolete tech from the class design page.
Races
Race
flag.png
ship.png
station.png
portrait.png
Medals
medal###.png
Names
commanders.txt
ships.txt
Oh tiny little thing, maybe I'm dumb and can't find it but somewhere (perhaps the new game screen?) can we have the version number?
I can't remember if I've updated or not! :)
Is there a way to provide custom ship names and/or ship class names?Does the "Miscellaneous" tab of the system map do what you want? You can add new ship/commander name themes to your database via text files, though there is no way to pass it on to other people than to have them do the same thing in their game.
Would it be possible to select an upper rank bound/range to who can command what class of ship in the design window? I know based on what components you have on a ship (auxiliary command, main engineering, etc) the minimum required racial rank increases, but for an upper bound I could see it being more feasible.
I specifically ask for fighter type ships. I know you had said that the lowest racial rank would be the only eligible command for ships under 1k tons, but I would enjoy it for RP purposes to have a series of ranks that could command fighters and FACs, the first 3 racial ranks or something like that.
Maybe it could be made that Left-Click activates already existing window and Right-Click opens a new instance of that window. Then we could have both!Or perhaps a check box/button that allows multiple instances of a window. So far, the improvement of multiple instances has been a real nuisance. I agree there are times it would be nice to have multiple of the same open at once, as stated before. However, most of the time I would prefer it brings the existing to front if it is already open. At a minimum, the 'close all' windows button to clean up all the open windows except the main one would help a lot.
Can we have the game re-use windows? Every time I click a button for industry or ship design or anything else on the main map it opens a new window, I suddenly had 16 planet overview windows open when I realized this.
It'd also be nice if clicking a tab on a window refreshes the open window. In ship design, anytime I change or create a new hull type I have to close the window and open a new one before it updates the list and it's pretty confusing at times.
Aurora was deliberately switched away from that to enable drag-and-drop between multiple instances of the same window. To switch back would require nearly every window increasing in size to fit a multi-function drag-and-drop space.
Some manner of "permanent capped-output deposit" would be nice, if just to soften the grip of non-newtonian entropy and to allow somewhat more permanent low-intensity mining operations. I can imagine some people would like to keep that entropy factor around though, so i'm wondering what others might feel about it.
A big part of me thinks that such deposits would either have to be represented as mined from the inter-celestial medium as fine dust, (which would make sense for asteroid belt deposits, fluffwise, i suppose), or as sourced from geologically-slow mantle extrusions on volcanically active planets (as it makes sense that it'd be much harder to blow a planet open just to get at it's non-newtonian guts anyway, and the mantle guts could be seen as both incredibly hard to get at at more than a trickle, and very impure).Some manner of "permanent capped-output deposit" would be nice, if just to soften the grip of non-newtonian entropy and to allow somewhat more permanent low-intensity mining operations. I can imagine some people would like to keep that entropy factor around though, so i'm wondering what others might feel about it.
I would also like "permanent capped-output deposits" as you call them. I always liked the idea of heavily colonized home system with lot of small mining outposts in asteroid belts and moons. I did it by SMing low availability deposits in VB6 version, but it would be nice to have it as official feature.
So uh i just made 1 Battalion (kinda doing things proper) with 3 companies with 3 platoons with 3 sections and i think im going to rip my hair out
So . . .
Perhaps add a thing called "standard organisation" or something similar
The idea is that i set up what i just did, or even select what ive done and set it as such so that a the GU screen i can produce everything ive just done, with the organisation already done. Essentially its a formation like the other formations, but instead of consisting of units, it consists of other formations (woah thats a lot of formations! :))
I am currently making the 2nd battalion for my regiment (going to consist of 3 battalions) so i think im going to need another tea . . .
Once the formations are actually built, you can drag-and-drop them between other formations. So you can build a Division HQ that is only a single 750,000 command rating HQ component, and then later assign pre-built Regiments to it.
Would be nice if Governor death would cause auto turns to stop and would be easily differentiated from other officer deaths. After all these are rather important events from game play and RP perspective+1 This would be nice.
What we need is a queue for ground unit construction complexes so I can first design a division and then just queue the whole division to be built instead of having to build it, platoon, by platoon every 5-15 days.
Since we're now building custom formations in a similar manner to how the industry works (instead of shipyards), it would make sense IMHO to change the whole ground production side to be like construction factories, so you don't assign individual projects to each complex. Instead the complexes increase your BP per production cycle and you just queue everything you want.
Once the formations are actually built, you can drag-and-drop them between other formations. So you can build a Division HQ that is only a single 750,000 command rating HQ component, and then later assign pre-built Regiments to it.
Yeah but i mean reproducing the entire group of formations on the ground unit training screen, ie being able to produce actual groups of formations to save time
Though i mightve just been taking forever because i was naming everything like 1st battalion - A company - 1st rifle platoon - infantry section Alpha
Admin commands should auto-assign.
Crew-Served Anti-Personnel on infantry provide 6x the firepower at 2. 4x the cost and 2. 4x the size compared to Personal weapons making them the overall more efficient option. I think it would be a better trade off if they cost 6-8x as much instead making it a trade off between taking the more resource efficient personal weapons or the more space efficient Crew-Served Anti-Personnel. Nerfing the AP of CSAP to 1 less than personal weapons could also be another option for balancing.
When re-training scientists to a new field their research bonus is reduced by 75%. However this lets you generate scientists with bonuses which aren't a multiple of 5, could it be changed so that it rounds (or rounds down) to the nearest 5? Given scientists gain bonuses in steps of 5 it would stop them from being permanently 'the odd one out'.
Alternately, I'd like to see them go to a multiple of 5% the next time they upgrade. Just change the chances accordingly. For example, if a 15% scientist goes to a different field, they'll become a 4% scientist. The next upgrade should bring them to 5%, but because it's 1/5 the size, it should be 5x more likely. (This may be too much work, but if it's practical, it satisfies both my OCD and my desire to prevent obvious loopholes with the rules)
Would be nice if Governor death would cause auto turns to stop and would be easily differentiated from other officer deaths. After all these are rather important events from game play and RP perspective
Admin commands should auto-assign.While I would also like admin commands to auto-assign, I think that a similar notification as suggested above for governors would be a good feature if people are against the idea of it in general.
I'd rather see all scientist bonuses go up 1% at a time -- and probably also more often as a result.
Is there a way to provide custom ship names and/or ship class names?
There're already mechanisms for adding custom flags, racial portraits, and naval leader names; adding the ability to provide custom ship names and ship class names would create the potential for "Race packs" to customize starts.
With a tweak to folder layout, you could allow coherent 'Races' to be created:Code: [Select]Races
Race
flag.png
ship.png
station.png
portrait.png
Medals
medal###.png
Names
commanders.txt
ships.txt
Unpopular opinion: I don't like comets.
Furthermore, I feel like they visually clutter some system, especially Sol.
We have options to hide everything, from gas giants to planets and moons to asteroids, but no option to hide comets, I wish there was one.
Secondly, there is a "min comets per system", but no "max comets per system", altough I think I'd be one of the only ones to use it.
More importantly, after some testing I found out that "all jump points already stabilised" in game options doesn't work if enabled after game start.
I think it should be moved from "options that can be modified at any time" to "options that can be modified at game start"
A standing Orderer for "Explore Unexplored Jump Point" which finds the nearest unexplored jump point and well. . . explores it. . . Would be amazing!
This along with overhauling that refills supplies would allow me to FULLY automate exploration hahaha, I can't see that going badly. . . can you?
The ability to import/export "packs" of medals and awards with their points, descriptions and pictures.
The ability to import/export ground formation templates
A standing Orderer for "Explore Unexplored Jump Point" which finds the nearest unexplored jump point and well. . . explores it. . . Would be amazing!If it would be possible to fully automate exploration, I was wondering if some kind of log message should be given by such exploration vessels for cases when they use over, let’s say, 75% of their fuel to move between exploration goals and refuel / resupply stations.
This along with overhauling that refills supplies would allow me to FULLY automate exploration hahaha, i can't see that going badly. . . can you?
First off great game and thank you for making it available, your amazing!
Secondly my suggestion is a minor one but could we get some sort of dead weight module for ships. Purely so my OCD doesn't get triggered by a ship coming in at 29,994 tons :)
But as a more practical reason it might be helpful to add say 1, 10, 100 & 1000 ton dead weight modules is it would the design of ships with dedicated upgrade slots. This would be much more appealing at least RP wise when say a ship goes in for a sensor upgrade and comes out the refit same tonnage.
Not sure if this was suggested (or possibly can be done but I don't know how) but it'd be nice to be able to select multiple ground units to move under a HQ and multiple ships to move under a fleet.
Can we get an event differentiation between "long term medical problem" and "death"?
Long term medical problems don't bother me. Death is a critical issue that requires a replacement officer, or worse, administrator.
Quote from: Aloriel link=topic=10640. msg124083#msg124083 date=1587058829Can we get an event differentiation between "long term medical problem" and "death"?
Long term medical problems don't bother me. Death is a critical issue that requires a replacement officer, or worse, administrator.
Technically, they are both long term medical issues. Just one is more. . . permanent :D
Okay first off. I played this game a bit long ago and I had someone in discord i knew be like look new version of aurora!. . and the new version looks cool so far, so hats off and kudos.
That aside I have a suggestion. Can there be an option to have a start in the game that's not the sol system for those of us who like to play aliens?
All my attempts to do this with spacemaster mode to kludge it like I used to do it in a way older version have resulted in, not good things.
Future feature request - I was playing Football Manager the another night and I walked away thinking, 'It would be nice if Aurora C# had a periodic autosave'. Given I've had a couple game crashes at inopportune times, I would have liked to have a feature that auto-saved every 6 or 12 months setting dependent.
var ci = new System. Globalization. CultureInfo("en-UK");
System. Globalization. CultureInfo. DefaultThreadCurrentCulture = ci;
System. Globalization. CultureInfo. CurrentUICulture = ci;
as the first few lines of code on app startup. I think it feels pretty odd that fast firing AA and Autocannon weapons are larger than the corresponding Anti-Vehicle weapons, at least when it comes to the tanks/vehicle mounted weapons.
In my fantasy worlds at least I tend to associate Anti-Vehicle and higher penetration with some of the largest and heaviest guns, whatever technology or Sci-Fi setting I may be using as a basis ( although I can see how bombardment weaponry could be of equal size or larger than anti vehicle so that I'm fine with ).
So my suggestion is the AA & Autocannon should be a bit smaller or Anti Vehicle a bit larger in size to feel right ( which might require rebalancing other stats they have )
Make planes part of ground unit design and keep fighters as Orbital elements only with bombardment capability (same as spaceships)
In my opinion autocannons seem useless. I am not sure when you would want them, maybe if you want to make armies of just type of unit instead of combined arms? Still wouldn't be good tho.
We currently have the "Temp[late] as Text" button for ground units, which is nice, but it gives no details on the makeup of the elements. When we post our OOBs on the design forum, it's hard to tell what the "Tank" someone's using is. Can we get some unit info into that text?
A minor thing, it would be nice if MAA units could also provide AA coverage for units under the same parent formation as it's formation. For example, I have an AA battery and 3 tank battalions under one HQ; it would be great if it could cover its fellow subordinate formations. Plus, this isn't much different from having the AA units within the HQ formation; it would still provide AA cover for the same units.
Not sure if mentioned already, probably is, but a stop interrupt when a ship fails to repair something during a maintenance failure would be great.
Love the new AutoMedal system! That being said, I discovered that the conditions are OR instead of AND.maybe if there were an option to choose OR/AND because for some medals like Hero of the Soviet States I give medals for the extremely difficult conditions, so researchers, commanders, administrators can all get it for exceptional service, making it AND would make it impossible for a broad medal like that to be awarded.
Okay, one more. I never can remember which fleet a certain ship is in, so it would be great if the event log would include that information for things like low fuel/MSP warnings. For example, for low fuel, we currently get something like this:
"Benedict Allen has only 17. 1 percent of its maximum fuel (389 072 litres)"
It would be great if it said this instead:
"Benedict Allen in SRV-01 has only 17. 1 percent of its maximum fuel (389 072 litres)"
Quote from: yourITguy link=topic=10640. msg125420#msg125420 date=1587246087Love the new AutoMedal system! That being said, I discovered that the conditions are OR instead of AND.maybe if there were an option to choose OR/AND because for some medals like Hero of the Soviet States I give medals for the extremely difficult conditions, so researchers, commanders, administrators can all get it for exceptional service, making it AND would make it impossible for a broad medal like that to be awarded.
Quote from: yourITguy link=topic=10640. msg125435#msg125435 date=1587247077Okay, one more. I never can remember which fleet a certain ship is in, so it would be great if the event log would include that information for things like low fuel/MSP warnings. For example, for low fuel, we currently get something like this:
"Benedict Allen has only 17. 1 percent of its maximum fuel (389 072 litres)"
It would be great if it said this instead:
"Benedict Allen in SRV-01 has only 17. 1 percent of its maximum fuel (389 072 litres)"
If you double-click the event on the event window it should take you to the individual unit details window, with the Benedict Allen selected.
Let us make divisions in the military so I can create a Peace Keeper division alongside the main Military. All RP.
When running auto turns and you get an interrupt, maybe trigger a game save at that point?
I would like it if we were able to set a standing order for refuel AND resupply at the same time. There's a movement order that does that, so why not a standing order?
Also, I don't know if this isn't done for balance reasons, but perhaps overhauling a ship could also mean refueling and resupplying?
Cheers, and thanks for the awesome game.
The ability to assign 'keep this much' values to delivery orders. I don't want to empty my tankers when they deliver the bounty of fuel harvesting stations to a colony, I want to keep some fuel for the next trip so I don't have to babysit them.Set the minimum fuel for the tankers in the Class Design window (in the Misc tab).
Ion Engine (Tech 4)
Engine Power 125.00 Fuel Use Per Hour 125.00 Litres
Fuel Consumption per Engine Power Hour 1 Litres
Size 10 HS (500 tons) HTK 3
Thermal Signature 125.0 Explosion Chance 10% Max Explosion Size 31
Cost 62.50 Crew 10
Military Engine
Development Cost 625 RP
Materials Required
Gallicite 62.50
Conventional Engine (Tech 1)
Engine Power 10.00 Fuel Use Per Hour 10.00 Litres
Fuel Consumption per Engine Power Hour 1 Litres
Size 10 HS (500 tons) HTK 3
Thermal Signature 10.0 Explosion Chance 10% Max Explosion Size 2
Cost 5.00 Crew 10
Military Engine
Development Cost 50 RP
Materials Required
Gallicite 5.00
Ability to hide selected medals:
Let's say your guy has collected 5 different grades of same research medal for life long science career, you could hide the 4 first lower grade medals and only show the highest one.
Demonius,
many thanks
OK - I was only changing the text colour and not the background colour . I have changed both and it looks as if it does indeed remember the changes.
DavidR
While I have no objections to a 10% default, my super-tankers typically have around a 0.1% reserve limit so expressing it as a percentage is unworkable. Liters is the number that I actually want.The ability to assign 'keep this much' values to delivery orders. I don't want to empty my tankers when they deliver the bounty of fuel harvesting stations to a colony, I want to keep some fuel for the next trip so I don't have to babysit them.Set the minimum fuel for the tankers in the Class Design window (in the Misc tab).
Suggestion: Minimum fuel should be in % and should have a default value of 10%.
Warn if a ship design has engines but no fuel tanks.
Warn if a ship design has Sorium harvesters but no fuel tanks, unless fuel can be directly unloaded to another ship like Salvage Modules can do?
While I have no objections to a 10% default, my super-tankers typically have around a 0.1% reserve limit so expressing it as a percentage is unworkable. Liters is the number that I actually want.
Such an option, or just allowing the user to enter a number with a % sign, is acceptable.Warn if a ship design has engines but no fuel tanks.
Warn if a ship design has Sorium harvesters but no fuel tanks, unless fuel can be directly unloaded to another ship like Salvage Modules can do?
I support those 2 additions.QuoteWhile I have no objections to a 10% default, my super-tankers typically have around a 0.1% reserve limit so expressing it as a percentage is unworkable. Liters is the number that I actually want.
You could have a radio button to change between percent and absolute.
Trying to have a default value in absolute units would be unworkable, but having a default value of 0 litres causes lots of posts in the bugs thread so something needs to be done, like the cargo shuttles needed for unloading.
Minor QoL suggestion:
I absolutely love the prototype feature - it makes designing ships so much more pleasant.
What would make it an even smoother process would be if any prototypes set to be researched would appear in a temporary research category - ie below Power and Propulsion you get Researchable Prototypes, and in that you get duplicate listings for all researchable prototypes. Then once you've settled on a design, you could just go there and quickly allocate labs to them.
Quote from: mike2R link=topic=10640. msg126411#msg126411 date=1587456464Minor QoL suggestion:
I absolutely love the prototype feature - it makes designing ships so much more pleasant.
What would make it an even smoother process would be if any prototypes set to be researched would appear in a temporary research category - ie below Power and Propulsion you get Researchable Prototypes, and in that you get duplicate listings for all researchable prototypes. Then once you've settled on a design, you could just go there and quickly allocate labs to them.
this + maybe a button in the class design window to set for research all prototypes in highlighted design.
This is a balance suggestion. Many of the early ground combat techs that are extremely necessary (construction, geosurvey, and xenoarcheology equipment, etc.) or needed for thematic reasons (fighter pods, etc.) end up arriving later than they should in conventional start games or in TN campaigns with small populations and/or low research rate multipliers. May I suggest lowering the cost on some of these to 2,000 RP from 5,000 RP?
(or have unfortunately-specialized scientists for their desires).You can change that now (best feature ever).
How necessary is xenoarchaeology if you can't get off your home world? (It's possible to start with alien ruins on your homeworld, but only if the SpaceMaster specifically adds them.)
How necessary is geosurvey of you can't get off your home world? (Homeworlds start fully surveyed.)
How necessary is construction equipment if you have no offworld colonies? (And if ground units with construction are more efficient than actual construction factories, that's a big reason to increase the tech cost, not decrease it.)
- - - - -
If things are "arriving later than they should" due to the research priorities the player set, I think that's an indication they set the wrong priorities (or have unfortunately-specialized scientists for their desires).
Sorry with my question, Steve: Will you release a version compatible with 768 vertical high resolution? I have 1366x768 on a notebook screenPer Steve
Thanks!
The required resolution is 1440 x 900.
Hey Steve, is it possible to change the position of the acronym of the ship to be after the name?
Now it is shown:
AMT Ammunition Transport
ANC Anchorage
etc
is it possible to show them in the drop down of the ship design screen in the inverse order?
Ammunition Transport AMT
Anchorage ANC
I say this, because if you write a name in the field to "find" the ship, as the acronym is the first letters and some of them does not match with the name, it is a bit more difficult than as I suggest.
Just a bit of quality of life :D
Thanks!!
Piracy. I know this has been suggested for years, but as far as I remember the reasons against it were more lore based than anything else, so I've tried to think of a mechanic that would fit logically into the game.
Gameplay reasons: Having occasional attacks by low threat enemies in rear areas would give the player a reason to build patrol ships. These would have a different design philosophy than the battle fleet - with range and endurance being more important than raw combat efficiency - and to me anyway, that sounds fun. Obviously you'd want an option to turn the system off in the same way as spoiler enemies for people who don't agree.
Lore: Pirate ships should come from ships "scrapped" by civilian shipping companies. The idea being that a few of these make their way onto the black market, get modified (increase their speed enough to make them useful, and add a few weapons). They then slip through the jump gate network to somewhere to raid civilian shipping lanes, until the player hunts them down.
Mechanic: A percentage of scrapped civilian ships generate a pirate. Probably the system only starts after some set number ships have been scrapped (so its not a super early game thing). When one is generated, a system that a) has a planet with a pop over 25 million and b) is connected to the home world via the jump gate network, gets a pirate generated.
Each pirate in a system has a random chance of spawning any time there is a civilian ship in the system. It appears at some distance from the target ship, and moves to intercept. Once it intercepts it attacks, destroys the ship, salvages it, then flees outsystem. Once it has been undetected on any player sensor for some length of time, it despawns. If the player manages to destroy the ship, the pirate is removed from the game.
The pirate should have enough weaponry to kill a civilian in a reasonable amount if time, and be fast enough to make an interception doable. But you'd want to be able to meet the threat with a small warship with range speced engines - the challenge is meant to be having a ship there at all.
This is a small thing. But I suggest we rename the "Beam Fire Control" to something else like "Weapons Fire Control" or "Turret Fire Control". The reason for this is I am an avid railgun and dont like the beam part. So, Thanks for atleast reading this small thing.
Minerals window:
Please allow sorting by availability before amount, as that is the more important number.
Please add a 'total' column showing the total amount of minerals and their combined availability.
Minerals window:
Please allow sorting by availability before amount, as that is the more important number.
Please add a 'total' column showing the total amount of minerals and their combined availability.
And starting vaule both 0/0 not 0/0.1 pls :D
Since create project just assigns the researcher and labs and those projects can be cancelled with no ill effects I do not see much reason to show "are you sure" confirmation popup.
Since there's nothing being possible lost this confirmation is just one additional click to create a project
In the VB6 event log, when a scientist completed a project and there was another queued up for them, the event log told us so. In C#, this is no longer the case. If possible, it would be nice to have it back.
There could be an indicator of how many officers you have on a given rank. Like say "Lieutenant Commander (28)"
Piracy. I know this has been suggested for years, but as far as I remember the reasons against it were more lore based than anything else, so I've tried to think of a mechanic that would fit logically into the game.
Great idea. . . for after we get a robust civilian economy & commercial shipping. And preferably after, or along with, a way to use CIWS in offensive mode, or otherwise simulated an 'armed merchantman' concept.
Gameplay reasons: Having occasional attacks by low threat enemies in rear areas would give the player a reason to build patrol ships. These would have a different design philosophy than the battle fleet - with range and endurance being more important than raw combat efficiency - and to me anyway, that sounds fun. Obviously you'd want an option to turn the system off in the same way as spoiler enemies for people who don't agree.
Literally the only thing stopping you from building patrol ships and deploying them in your rear areas is you. If it sounds fun, do it. If it sounds not-fun due to current mechanics and/or software limitations, advocate for changing those.
Lore: Pirate ships should come from ships "scrapped" by civilian shipping companies. The idea being that a few of these make their way onto the black market, get modified (increase their speed enough to make them useful, and add a few weapons). They then slip through the jump gate network to somewhere to raid civilian shipping lanes, until the player hunts them down.
No, the lore should be whatever I decide it should be to fit my fiction. The same way I can rename Ion engines to "triple-expansion steam" engines if I so desire.
Not the least because I don't have a jump gate network.
Mechanic: A percentage of scrapped civilian ships generate a pirate. Probably the system only starts after some set number ships have been scrapped (so its not a super early game thing). When one is generated, a system that a) has a planet with a pop over 25 million and b) is connected to the home world via the jump gate network, gets a pirate generated.
What if I want my pirates to be renegade ground troops with boarding shuttles? Historically (and in modern times), the vast majority of pirates have been (are) shore-based in small craft who swarm over passing ships.
Sure, most people probably want an intense, somewhat-close-to-even ship-to-ship fight with a full-up starship, but an hour after Steve releases the 'Pirate Patch' there will be people on these boards posting "Just use a large cruiser with X sensor and Y missile launchers of Z size and A range to exterminate these pests from outside the range they even know you're there."
I apologize; I seem to have drifted off topic. There are many, many ways to do the mechanics (What about ships that can turn on their commercial transponder and prevent you from firing at them? What if they only way to deal with a pirate vessel is to board and capture it?) and that discussion should be left until after we decide what the purpose of adding pirates is, and what we want them to do, and -- for lack of a better term -- where 'the fun' of piracy is.Each pirate in a system has a random chance of spawning any time there is a civilian ship in the system. It appears at some distance from the target ship, and moves to intercept. Once it intercepts it attacks, destroys the ship, salvages it, then flees outsystem. Once it has been undetected on any player sensor for some length of time, it despawns. If the player manages to destroy the ship, the pirate is removed from the game.
I would hate that. I hate the idea of a ship literally disappearing from the game 'until next time' -- it stinks of the worst kind of video game logic. Once a ships exists, it should continue to exist and Aurora should know where it is at all times.
Not the least because if I want to hunt pirates by finding their base, they darn well need to have a location to be found. Pirate ships should not get a pass on fuel or maintenance or ordnance. They should be stealling these things from their victims and running short if I do a good job of risk management.The pirate should have enough weaponry to kill a civilian in a reasonable amount if time, and be fast enough to make an interception doable. But you'd want to be able to meet the threat with a small warship with range speced engines - the challenge is meant to be having a ship there at all.
The pirate should function by exactly the same rules as every other ship in the game. If the humans / Alzairians / robots / Gorrthik of the pirate boat can figure out how to make something a functional starship weapon, my empire's highly-paid and pampered scientists can figure out the same thing with sufficient funding.
I am using a single transaction for each table, so all rows are committed at once.
# create test files, stripping query optimization data.
sqlite3 AuroraDB.db '.dump' | grep -v 'sqlite_stat' | grep -v 'ANALYZE' > dump.prime.txt
# insert DELETE FROM commands.
sed -E 's/CREATE TABLE (IF NOT EXISTS)?([^(]+)\(/DELETE FROM\2;\n\0/' < dump.prime.txt > dump.single.txt
# break into multiple transactions.
sed -E 's/(DELETE FROM|CREATE TABLE)/COMMIT;\nBEGIN IMMEDIATE;\n\0/' < dump.single.txt > dump.multi.txt
# prime temporary database
sqlite3 dump.db < dump.prime.txt
# simulate saving a game under various conditions
sqlite3 dump.db 'PRAGMA journal_mode=delete;'
time sqlite3 dump.db < dump.multi.txt
time sqlite3 dump.db < dump.single.txt
sqlite3 dump.db 'PRAGMA journal_mode=wal;'
time sqlite3 dump.db < dump.multi.txt
time sqlite3 dump.db < dump.single.txt
# clean up
rm dump.*
I would like to suggest a conventional+ start for Players and for player generated NPR's. This start would begin like any other conventional game with a 2 differences.
1. Trans-Newtonian Technology (TNT) is completed.
2. A Legacy Army is generated. This is just like a legacy fleet in RTW or like the troops you started with in VB6, with the option to build it yourself or not.
The early game armor tech is unfortunately useless in my honest opinion. In a conventional game any rational person would take the short time while they wait for TNT to finish to complete the conventional armor techs and then immediately research Duranium armor after TNT is completed so they can make massive weight savings on any new ship they build.
Also, any conventional start requires that you don't have an NPR present in your starting system as you are likely to get creamed if they decided to pick a fight thanks to the new minimum tech requirements for NPR. So, if you want to have a NPR in your starting system you have to start Trans-Newtonian, this means you would never even see those conventional armor techs.
What implementing this would do is actually allow you to use the early game armor tech, and build the "Trans-Newtonian upgrade" to conventional troops that you mentioned and showed everyone in your dev log. How? Because you could have an NPR either on Earth to fight for control of the planet, forcing a scenario where someone has to leave the planet to survive or make a tense but short peace for the new interplanetary empires, or you could have a NPR on the nearby planets to facilitate building a military to protect your borders. What these would do, in short, is allow you to make important early game military and economic decisions that would impact you throughout the mid and even late game.
I would like to suggest a conventional+ start for Players and for player generated NPR's. This start would begin like any other conventional game with a 2 differences.
1. Trans-Newtonian Technology (TNT) is completed.
2. A Legacy Army is generated. This is just like a legacy fleet in RTW or like the troops you started with in VB6, with the option to build it yourself or not.
The early game armor tech is unfortunately useless in my honest opinion. In a conventional game any rational person would take the short time while they wait for TNT to finish to complete the conventional armor techs and then immediately research Duranium armor after TNT is completed so they can make massive weight savings on any new ship they build.
Also, any conventional start requires that you don't have an NPR present in your starting system as you are likely to get creamed if they decided to pick a fight thanks to the new minimum tech requirements for NPR. So, if you want to have a NPR in your starting system you have to start Trans-Newtonian, this means you would never even see those conventional armor techs.
What implementing this would do is actually allow you to use the early game armor tech, and build the "Trans-Newtonian upgrade" to conventional troops that you mentioned and showed everyone in your dev log. How? Because you could have an NPR either on Earth to fight for control of the planet, forcing a scenario where someone has to leave the planet to survive or make a tense but short peace for the new interplanetary empires, or you could have a NPR on the nearby planets to facilitate building a military to protect your borders. What these would do, in short, is allow you to make important early game military and economic decisions that would impact you throughout the mid and even late game.
Well, we specifically asked to have the new levels of armour below duranium added, so I for one would be pretty pissed if they were immediately taken away again.
Given that you can immediately award your empire Trans-Newtonian Tech with SpaceMaster, what's left of your suggestion is 'pre-made ground forces for conventional start games' which is functionally identical to the "ICBM bases" we used to get, so I suspect they are already on the list of "cosmetic and QoL features omitted from v1.0 so it would come out in April instead of August." I look forward to them.
As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.
As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.
Building them yourself would be the "moddability" of conventional forces.
- - - - -
Have you tried creating a fully Trans-Newtonian empire with 0 reaserch points to see if it's closer to what you desire?
Where can you do that?(or have unfortunately-specialized scientists for their desires).You can change that now (best feature ever).
Where can you do that?(or have unfortunately-specialized scientists for their desires).You can change that now (best feature ever).
As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.
Building them yourself would be the "moddability" of conventional forces.
- - - - -
Have you tried creating a fully Trans-Newtonian empire with 0 reaserch points to see if it's closer to what you desire?
As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.
Building them yourself would be the "moddability" of conventional forces.
- - - - -
Have you tried creating a fully Trans-Newtonian empire with 0 reaserch points to see if it's closer to what you desire?
May I also suggest perhaps playing at a lower research speed. Some people much enjoy the slower pace enabling better usage of early tech.
Could we have a way to sell ships and perhaps ground equipment on the civilian market? In real life, nations have often sold off surplus military hardware. Many small commercial vessels even today were originally auxiliary military ships in WW2. I think the reverse should also be possible. Many navies have bought civilian ships to fill auxiliary roles.
I'm not certain if this should go in Suggestions or Development Discussion since it is regarding the database, but there is potential for some improvement that Steve might want to consider.
Saving the 1.8.0 stock game on my machine takes around 30 seconds. During this time the journal file is repeatedly created and destroyed with heavy disk activity. This seems excessive for an 80MB file.
This post explains what is happening.Quote from: Steve Walmsley link=topic=10096.msg116038#msg116038I am using a single transaction for each table, so all rows are committed at once.
In an attempt to simulate this behaviour, I ran some tests using sqlite3's command line utility and the stock 1.8.0 database.
Test script:Code: [Select]# create test files, stripping query optimization data.
sqlite3 AuroraDB.db '.dump' | grep -v 'sqlite_stat' | grep -v 'ANALYZE' > dump.prime.txt
# insert DELETE FROM commands.
sed -E 's/CREATE TABLE (IF NOT EXISTS)?([^(]+)\(/DELETE FROM\2;\n\0/' < dump.prime.txt > dump.single.txt
# break into multiple transactions.
sed -E 's/(DELETE FROM|CREATE TABLE)/COMMIT;\nBEGIN IMMEDIATE;\n\0/' < dump.single.txt > dump.multi.txt
# prime temporary database
sqlite3 dump.db < dump.prime.txt
# simulate saving a game under various conditions
sqlite3 dump.db 'PRAGMA journal_mode=delete;'
time sqlite3 dump.db < dump.multi.txt
time sqlite3 dump.db < dump.single.txt
sqlite3 dump.db 'PRAGMA journal_mode=wal;'
time sqlite3 dump.db < dump.multi.txt
time sqlite3 dump.db < dump.single.txt
# clean up
rm dump.*
Results:
The closest simulation I could produce completed in 25.742 seconds. This test was two transactions per table, one to erase followed by another to fill.
Converting to a single transaction for the entire operation reduced this to 3.489 seconds, more than 7x faster than baseline.
Multiple transactions running WAL mode completed in 8.712 seconds, nearly 3x faster than baseline.
Using both optimizations completed in only 2.876 seconds, nearly 9x faster than baseline.
3-4 seconds per save is fast enough that an auto-save option becomes viable, including save-on-exit.
Further testing (by killing Aurora while it was saving) revealed another issue:
Currently, if a save is interrupted (game or computer crash, power failure, etc), then sqlite can't correctly recover the database on the next start. Some tables will be updated to the new state while others remain in the old state. Because deletes and inserts are separate transactions, whichever table is being written at the time will be left blank*. Using a single transaction per save guarantees that either the new state is completely written out or the old state can be automatically restored when Aurora is next started.
*While testing this I managed to delete every ship in the default game, and another time deleted the event history. I'm not certain what got nuked by the other attempts, only that the database got smaller. When restarted, Aurora reported no errors in any case. Sadly, I never managed to accidentally Sol. :(
Suggestions:
Use a single transaction per save so that auto-saving becomes practical.
-I recommend running all of the DELETEs before running any of the INSERTs to minimize fragmentation.
Auto-save periodically during long execution runs.
Auto-save on exit.
Two minor suggestions:
Set the page size to 4096 for around 10% faster disk performance on modern hardware. This setting is persistent and requires no code changes.
The database could stand to be VACUUMed once in a while. This is equivalent to the old VB "compact database" command.
If anyone is putting together a launcher like VB Aurora had, these last two are low hanging fruit.
Could we have a way to sell ships and perhaps ground equipment on the civilian market? In real life, nations have often sold off surplus military hardware. Many small commercial vessels even today were originally auxiliary military ships in WW2. I think the reverse should also be possible. Many navies have bought civilian ships to fill auxiliary roles.
Delete the ship; SM add the wealth (and, if you feel it appropriate, minerals) you decide was the price.
For Aurora to dictate the price at which this happens, or whether or not there is a buyer, or to limit the frequency at which I can do this is to interfere with my fiction. And I don't even know what that fiction is yet, but I'm pretty sure it's going to vary from game to game.
- - - - -
I would much rather see a way to sell (trade) to the AI. I can already perform trade between two empires I control, but I can't buy up all my neighbour's Corbomite. I can SM add all I want in exchange for my wealth, but the AI-run NPR doesn't lose any.
And how do you SM the price?
And how do you SM the price?
Space Master on, Colony screen, commercial shipping tab or wealth tab or mining tab to see the buttons or stockpiles to which you want to add the "price".
- - - - -
If you mean 'how do I set the price for a particular ship' -- I let my fiction do it for me. Sometimes I even roll dice.
Moving ground forces in a transport ship is annoying. A couple QoL requests - either:
1) Add a "Move including Subordinates" button that allows me to move a whole force structure, not just one division HQ at a time.
I'm not following.
I see SM buttons on the Civilian Economy tab to add/edit numbers of installations.
But I don't see anything similar on the Mining tab or the Wealth tab.
Some suggestions for the civilians shipping orders mechanic.
1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.
Some suggestions for the civilians shipping orders mechanic.
1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.
Again, these largely amount to "remove any remaining need for government-owned shipping" and I, for one, would like to see shipping lines move in other direction -- that of becoming less useful.
That's not very realistic though. Governments mostly do not own cargo ships. They contract out most of their needs.Some suggestions for the civilians shipping orders mechanic.
1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.
Again, these largely amount to "remove any remaining need for government-owned shipping" and I, for one, would like to see shipping lines move in other direction -- that of becoming less useful.
I'm not sure that would be desirable. CMCs will use the Mining bonus of your administrators (planetary and sector), therefore giving you more minerals for less expenditure if you are purchasing them.
But if you are letting the minerals go to the civilian sector. . . if you give the CMC an administrator with no Mining bonus, then you will extend the duration time of the mineral deposits. . . and increase your earnings.
CMCs are also useful for training administrators without creating as many empty colonies on asteroid belts.
That's not very realistic though. Governments mostly do not own cargo ships. They contract out most of their needs.
That's not very realistic though. Governments mostly do not own cargo ships. They contract out most of their needs.
See, that's where you're wrong. In the Hyborean Empire, only governments own cargo ships. In the Hexapod Omnivoracity, the hive mind controls everything. In the JG17i+Violet Connexion, the ships are the citizens and they conduct themselves in an harmonious manner.
In other words, what is "realistic" is determined by the fiction, not the other way around.
Medals
In the medal screen , I only see the facility to show and award ribbons , rather than medals ( as shown in Steve's post of June 23rd 2019 - C# Changes list ) . The screen has changed since this post but could we have the ability to award and show actual medals rather than just ribbons - ribbons don't mean as much as whern seeing a medal.
DavidR
I wish i could sort the research that is beeing done as "per field" - with the same Sorting as in the research drop done.
Reason:
- it would keep better track of how many projects you are currently running in a specific field (and queued as well)
- makes finding the one you are looking for easier to spot
Sincerely
It feels weird when your industry increases its productivity, your speeds allow to travel to the other side of galaxy in matter of months, you ferry around millions of popsicle colonists, yet your lifepods have the same endurance as in conventional era. Maybe there should be some tech line concerning lifepod endurance, starting from 1 day, or as alternative option it could be tied in some way to reactor technology level.I think we had discussed that during development of C# at some point. Some kind of system where you can input "days of supplies for life pods" during ship design (similar to deployment time) would be nice. That way it depends on your philosophy and amound of ship size you want to use for life pods. Heck, you even can make it dependent upon your life pod rescue ships. If you planned for a decentral rescue network and can reach anything within 30 days, make your life pods last 35 days; or if you have one central rescue hub that would need 120 days to the outlying systems, let your life pods last 125 days... . It suddenly becomes a game decision how to play your empire.
My suggestion would be to add terrain types that are less natural but instead effected by industry such as the follow:
Urban: After certain level of population density and or industry the world would be classified as an Urban or "Hive world" and that would effect combat accordingly.
Toxic: Worlds that are habitable but either through nuclear or natural disaster they have had their ecosystem and overall habitability ruined, this could effect logistics as well as how fighting takes place due to low visibility and specialised equipment.
Wasteland: Worlds that through high levels of fighting and damage have had the very landscape itself turned into a wasteland, such as Nuclear weapons firing from orbit or massive amounts of land warfare leading to ecosystem collapse as well as the destruction of the original terrain, this could be implemented based off how much fighting has occurred as well as the type and level of weapons used, this could either effect combat or mainly effect population growth and essentially scare the planet for generation to come.
Planet-Cracked: The next step after the wasteland essentially these types of worlds have either been bombed into submission in such a way that the planet itself has cracked and or that a natural disaster has caused terrible damage and made it uninhabitable, these worlds would be uninhabitable rocks with no atmosphere and reduced amounts of mineral deposits.
Overall I think new terrain types that you can effect through more then just terraforming that allow you to see how wars effect planets and the devastating costs of fighting prolonged drawn out wars with TN tech could be very interesting and enjoyable. So I hope this gets added eventually.
Some suggestions for the civilians shipping orders mechanic.
1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.
Again, these largely amount to "remove any remaining need for government-owned shipping" and I, for one, would like to see shipping lines move in other direction -- that of becoming less useful.
Currently, unless I am going blind which is possible, there doesn't seem to be a way to modify either mineral stockpiles or racial wealth using SM in C#. This isn't so much of an issue in a lot of games, but it's a relatively small thing that adds a lot of utility to multi faction RP heavy games.
I don't mean mineral deposits, I mean the mineral stockpile of an empire. being able to SM mod mineral stocks and wealth makes RP trades between player empires possible.
Speaking of coloured events, it would be great if that could be global rather than per game - set them up, and all subsequent games on that db share the same ones.
Infantry transport module
Currently there is no way to create mechanized/armored infantry units. Mechanized/armored infantry uses armored personnel carriers and infantry fighting vehicles to gain a degree of protection and mobility on the battlefield. Adding armor to infantry does not make a lot of sense since aurora ground combat phases take 8 hours during which infantry would fight dismounted. However, mobility could be implemented through a module that removes the 0. 5 breakthrough modifier from a set number of infantry units per module.
The idea is that they can keep up with the tanks. Obviously not trucks (motorized), maybe APCs (mechanized) but IFVs (armored) are designed to do that. Infantry would dismount when necessary. The breakthroughs are explained here http://aurora2.pentarch.org/index.php?topic=8495.msg109786#msg109786 (Base Ground Combat Rules in C# Aurora Changes List)Quote from: Cedras link=topic=10640. msg129069#msg129069 date=1588163950Infantry transport module
Currently there is no way to create mechanized/armored infantry units. Mechanized/armored infantry uses armored personnel carriers and infantry fighting vehicles to gain a degree of protection and mobility on the battlefield. Adding armor to infantry does not make a lot of sense since aurora ground combat phases take 8 hours during which infantry would fight dismounted. However, mobility could be implemented through a module that removes the 0. 5 breakthrough modifier from a set number of infantry units per module.
Not sure I'm following you here. You can put Vehicles into an Infantry formation. As you stated, the infantry themselves would fight dismounted. And in modern doctrine, those vehicles act as fire support platforms to support the dismounted infantry. Motorized/Mechanized Infantry don't really breakthrough, they just can get from point A to B quicker, but they cannot fight in a battle from point A to point B quicker than regular leg infantry, because of the dismount doctrine which comes from weight of fire advantages of being dismounted. Where do you see/find a "breakthrough modifier" for anything? I've had static units "breakthrough" when their formation is set to Front Line Attack.
I would like to suggest a small quality-of-life improvement:
On the research screen, would it be possible to show the number of current research projects, and the number of queued research projects? Ideally in a format like '20/18'.
This would allow a rapid check to see that all research projects have a queued research project, thus making it unnecessary to constantly count these things if, like me, you can't bear the thought of wasted research points, probably otherwise known as borderline OCD :)
Quote from: Earthrise link=topic=10640. msg129075#msg129075 date=1588165663I would like to suggest a small quality-of-life improvement:
On the research screen, would it be possible to show the number of current research projects, and the number of queued research projects? Ideally in a format like '20/18'.
This would allow a rapid check to see that all research projects have a queued research project, thus making it unnecessary to constantly count these things if, like me, you can't bear the thought of wasted research points, probably otherwise known as borderline OCD :)
Instead of a number, then perhaps a column right next to 'Pause' with a simple 'Yes/No' on whether that particular researcher has a queued project? That way you don't have to go through the list to see which reseacher is lacking a queued project.
My Lunar colony declared independence and currently resides on "Sol A III - Moon 1" >:( I am not renaming the solar system.
Naval Organization window
Fleet tab
Top line of top-right pane has a summary line.
Summary line includes location, current orders, all orders distance, and travel time.
Suggestion: if current order is to stabilize a jump point, show the time remaining on this line.
When declaring independence:
-Have the option to make the race an NPR
-If the population is the only one (of that empire) on the planet, then transfer all Orbital Habitats in orbit of the planet
-Reset political stability to 100% (or have an SM button to manually change it)
-All custom names of stars, planets, moons and populations remain the same. My Lunar colony declared independence and currently resides on "Sol A III - Moon 1" >:( I am not renaming the solar system.
hey everyone,
i wonder if there will be possible ground based missile silos (something like in old Aurora PDC with missile launchers). In my opinion its kinda advantageous on real life to have cheap and immobile, big rockets silos instead of expensive mobile ones (in case of aurora orbital stations/platforms with basically only launchers and magazines). I know there is STU available but so far i was unable to arm those with launchers, so i can imagine this feature is not planned?
Civilian Mining: It really can cripple your economy if you buy minerals from the civilian - and they have so much fun that they increase the numbers of their mining facilities in rapid succession. Some kind of option to limit their numbers would be nice... .An option to ban CMCs like the option to ban CGMs?
Rename either maintenance supplies (MSP) OR missile size points (MSP) to prevent confusion to new players.
. . .
Regardless, it's pretty confusing if you're new and honestly I'm surprised I didn't get confused myself in VB6. Or maybe I did and forgot!
Edit 2: It would also be nice if we could do some things to gas tolerances. I'm creating a race of supped up cyborgs that can live pretty much anywhere and the game allows me to do that. No atmosphere at all? No problem. Temperature of -100C? No problem. Radiation? No problem. Gravity of 0.0001 g? No problem. That 0.01ppm of oxygen constitutes 31% of the atmosphere? Well, we can't live on that! And God forbid there is 0.0001 of fluorine.
Being a little more serious I do realise that this would require a significant amount of work most likely and fortunately thanks to the SM mode I can pretty much simulate this by SMing atmospheres. Even so it does make it difficult to create races that are less human especially since there is no longer an option to breathe methane. Which I would also love to have back by the way.
No, I am generally fine when the civilians do mining. I have blocked some which I want to do myself, but they can do the rest. No worries. I just had the case of having 4 civilian mining stations within like 6 month increasing their numbers from 1 to 3 or 4 - so "suddenly" I had to pay some 2.500 wealth for them. So some kind of: Civilian mining wants to increase their mines from 1 to 2. Allowed (y)es/(n)o would have been nice, so I could have some control over it.
I temporarily switched some of them to "tax civilian mining" - though I could use the minerals. Well, If you have no economy, no minerals are worth anything ;D
I would like a way to add or subtract from total racial wealth.
This is just a minor request, but could the medal criteria be changed from 'destroyed X tons of hostile shipping' to 'destroyed X times own command's tonnage of hostile ships'? It's kind of annoying when Commodore A gets meritorious service medals for slaughtering 10,000 tons of enemy gunboats while in command of a 15,000 ton battleship, but the plucky Commander B who took down a 5,000 ton enemy cruiser while in command of a tiny 1,000 ton destroyer gets absolutely no recognition at all.
The default order caused by double clicking on a JP in Movement Orders should be "Standard Transit", not an error message.
I had the idea for a seed ship (A single ship that's capable of kickstarting a colony). This can be done with various TN buildings, but Conventional Industry would be a perfect cargo-space saver for these things.
To the point then: TN empires should be able to build Conventional Industry.
A mass driver component for space stations only.
This will reduce the amount of micro needed for all the mineral transfers.
Carronade should be renamed to Plasma Carronade (or opposite)
In component design window it is under Plasma Carronade, but in Class Design it is under Carronade. Having same name used everywhere would make it easier to find the component.
Also in research it is 20cm Carronade, not 20cm Plasma Carronade
Using Mass drivers to lob ore around is slow, in part because the speed at which mineral packets move does not appear to depend on Railgun Launch Velocity.
Sector commanders, as expected, increase things like mining and production. I'm not seeing them increase population growth (could have sworn they did so in previous versions).
CMCs are theft anyway -- there's no point in encouraging them.
A mass driver component for space stations only.
This will reduce the amount of micro needed for all the mineral transfers.
When you open the class window, all ship classes trees are open by default. Gets a bit crowded after a while. Maybe having them closed by default or saved which were opened last time, would be a nice QoL, I think ;-)
If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.
That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.
The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.
Math.Floor("Ship BP cost" * 0.25 * "Orbital Standby Maintenance Efficiency Modifier"])
By default the modifier is 1.0, and changes as tech is researched (like fuel efficiency).Math.Floor("Ship BP cost" * "Game Option Standby MSP Rate" * "Orbital Standby Maintenance Efficiency Modifier"])
"Game Option Standby MSP Usage %" would normally be 0.25 (Represented as 25 in the field to fill in. I would not allow values higher than 25.).
If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.
That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.
The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.
A mass driver component for space stations only.Mining stations? Either have the civvies move the driver or include a cargo bay and shuttles and keep it with the station.
This will reduce the amount of micro needed for all the mineral transfers.
Not to mention those systems with only comets in them. If you automate the mineral pickup there, you might end up having a cargo ship chase a comet to the edge of space because the one comet you chose as gathering point is on its way away from the center. A space station with a mass driver would help greatly.It sounds like the solution is to pick a comet which has a small orbit (and preferably angled near the jump point) and use that as a system-wide collection point.
Certainly, government freighters should be a preferred option. But I submit that mass drivers should have more than a marginal reason even to exist in the game. At a minimum, they should maintain the same level of relative effectiveness through the tech progression.Using Mass drivers to lob ore around is slow, in part because the speed at which mineral packets move does not appear to depend on Railgun Launch Velocity.
It is, and it should reamin so to encourage the use of government freighters.
Sector commanders, as expected, increase things like mining and production. I'm not seeing them increase population growth (could have sworn they did so in previous versions).
If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.
That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.
The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.
No, it merely requires one new freighter. One mining colony, one freighter, one route each. Not every mining colony and every freighter all on the same route.
Mule 001 gets the Phobos run, Mule 002 gets the Ceres run, Mule 003 gets the Hailey's Comet run, etc.
Certainly, government freighters should be a preferred option. But I submit that mass drivers should have more than a marginal reason even to exist in the game. At a minimum, they should maintain the same level of relative effectiveness through the tech progression.
Yes, they do have growth modifiers. The report, however, is that the pop growth modifiers of sector governors do not appear to affect population growth in 1.93, and I am confident they did so in the past.
If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.
That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.
The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.
No, it merely requires one new freighter. One mining colony, one freighter, one route each. Not every mining colony and every freighter all on the same route.
Mule 001 gets the Phobos run, Mule 002 gets the Ceres run, Mule 003 gets the Hailey's Comet run, etc.
Assigning one ship per mining colony is a lot of overkill on ship construction, and therefore a lot of wasted fuel, unless you either have massive mining colonies, are using small cargo holds (which is less efficient), or traveling a very, very long way to your mining colonies.
One round trip from a standard cargo hold moves 12.5kt of minerals.
A freighter with a standard cargo hold and three 25% power, size-40 Magneto Plasma engines will make a round trip per year at a range of 11.5Bkm, using 52kL of fuel.
Even if it's a 35Bkm trip to your mining colony, this one ship is moving 4.1kt/year.
That's a lot of output for a mining colony, and will quickly strip most colonies, requiring that I move the mines again (and update the freighter orders again).
And that's at a range of 35Bkm. For a mining colony to keep up with one freighter at 10Bkm, I'd have to pull 43kt/year out of the rock.
Really, I'd just rather plop down a MD and point it at my collection station.
Really, I'd just rather plop down a MD and point it at my collection station.
On the Civilian Economy tab, when a colony is designated as "Source of Colonists", I would like to be able to specify a reserved population amount, such that only population in excess of that amount is considered available for relocation.
This would make it much easier to keep civvies from taking too many colonists and leaving too few workers for my installations.
Right now I have to keep a close eye on it, and switch the status back and forth all the time.
Hi,Automatic promotions can be turned on or off using the game setting "Realistic Commander Promotions".
not sure if it has been posted, but please, please please:
add a button to disable automatic promotions for all officers, so i do not have to do this for 200 individuals one after the other.
thanks and best regards
Civilian Mining Colonies are named after the company. But you loose any reference to on what body they have build that colony. It is shown when they found it, but in any of the tabs you then only can see the name of the colony but nowhere the name of the body. Makes it hard to locate.
Automatic promotions can be turned on or off using the game setting "Realistic Commander Promotions".
Game settings is the third button from the left.
If it isn't working then please post in the bug reports thread.
On the Civilian Economy tab, when a colony is designated as "Source of Colonists", I would like to be able to specify a reserved population amount, such that only population in excess of that amount is considered available for relocation.
This would make it much easier to keep civvies from taking too many colonists and leaving too few workers for my installations.
Right now I have to keep a close eye on it, and switch the status back and forth all the time.
Well, if the amount you want to specify is "25 million" you're in luck. Otherwise, the answer is government colony ships.
Or start blowing up civilians, starving them of funds, tractoring their ships to capture them (if that exploit still exists) or even outright deleting shipping lines.
A more clear distinction between the names of standing orders for geosurvey vs gravsurvey, please. I keep always selecting the wrong set. It's not at all obvious from the current naming witch is witch.
Speaking of standing orders, how about setting a default standing order that gets applied to all ships unless overridden by changing manually? That would save a lot of clicks.
The ability to restrict the ship types civilian shipping lines can build/use.
It is mostly for role-playing purposes; but it would be nice if you can make companies
like ESSO Galactic, Häagen-Dazs Cryo Services or Amazon Cargo that specialize in a specific branch of civilian shipping.
Maybe check-boxes on the "Shipping Line" tab could be implemented without too much work, similar to the check-boxes on the "Repair Report" & "Detailed Fuel Report" tab.
Automatic promotions can be turned on or off using the game setting "Realistic Commander Promotions".
Game settings is the third button from the left.
If it isn't working then please post in the bug reports thread.
AFAIK (I tested it in 1.9.3), "Realistic Commander Promotions" switches only an influence of Political Reliability of Commanders, not an auto-promotion turns as a whole.
It's very strange and counter-intuitive, that Racial (Ground Forces) Weapon Strength depends on "Max Size" (caliber) techs, and fully ignores wavelength / retardation / launch velocity / PB range. Why must infantry weapon depend on max sizes of guns, completely not depending on their "quality"? I think it will be much more consistent to make it on the contrary: both infantry and vechicle weapons can be dependent on "quality" tech lines.
Yes, exactly. And this is the problem. Mass Drivers should not be preferable to government freighters. They should be the choice of last resort, or reserved for cases like the Earth-Luna run where load & unload times for freighters are longer than the transit time from source to destination.I violently disagree with this statement. If you don't want to use mass-drivers in your games, that is your choice, but don't take them from me, especially before sensible hauling orders for government transports are both available and working. We can't even refuel a ship reliably yet, let alone set up a logistics train.
1) The ability to delete prototype components in the class design screen.An option to automatically save on exit.
2) A message to confirm the game has been saved.
There is a separate tick box for Political Reliability; the two should have nothing to do with each other.
It would hardly change anything. Aurora assumes the two things are equal, and since it is already selecting 'the highest of {group}' adding more elements to the group under consideration would only have an effect if your empire, for example, increased wavelength before increasing size.
A better question is why does ground force weapon strength completey ignore gauss cannon tech?
JumpMaster class Gate Builder 84,630 tons 243 Crew 1,606.2 BP TCS 1,693 TH 0 EM 0
1 km/s JR 2-25(C) No Armour Shields 0-0 HTK 37 Sensors 0/0/0/0 DCR 1 PPV 0
MSP 11 Max Repair 1000 MSP
Kaigun-Ch?sa Control Rating 1 BRG
Intended Deployment Time: 3 months
Jump Point Stabilisation: 180 days
JC100K Commercial Jump Drive Max Ship Size 100000 tons Distance 25k km Squadron Size 2
J3000(3-50) Military Jump Drive Max Ship Size 3000 tons Distance 50k km Squadron Size 3
This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as a Space Station for construction purposes
Gord yes! I have long advocated that civilians should build only one type of ship -- for many reasons, including that my luzury cruise passengers would not be susidizing more infernal CMCs.
It would hardly change anything. Aurora assumes the two things are equal, and since it is already selecting 'the highest of {group}' adding more elements to the group under consideration would only have an effect if your empire, for example, increased wavelength before increasing size.
A better question is why does ground force weapon strength completey ignore gauss cannon tech? My empire is in the strange position of having to research a completely foreign weapon to make any progress.
Part of the problem that people seem to be having is that the civilian fleets expand too quickly. Demand limiting would nip that in the bud. I haven't seen mention of it here, so I'm going to repeat a suggestion from the old VB suggestions thread.Quote from: Father Tim link=topic=10640. msg130662#msg130662 date=1588599801Gord yes! I have long advocated that civilians should build only one type of ship -- for many reasons, including that my luzury cruise passengers would not be susidizing more infernal CMCs.
While I don't share Father Tim's seething hatred for the mere idea of private shipping ;D, I do agree that having the various civilian companies specialize would be neat. Having most lines operate only one category of vessel, with a chance of expanding to others as they get more wealthy would be neat.Quote from: Father Tim link=topic=10640. msg130666#msg130666 date=1588600266It would hardly change anything. Aurora assumes the two things are equal, and since it is already selecting 'the highest of {group}' adding more elements to the group under consideration would only have an effect if your empire, for example, increased wavelength before increasing size.
A better question is why does ground force weapon strength completey ignore gauss cannon tech? My empire is in the strange position of having to research a completely foreign weapon to make any progress.
Both of these could be addressed together - make racial ground weapon strength based on the average of your research into one of the weapon categories that are flagged as ground affecting. I'd vote for railguns, gauss, laser and possibly plasma, personally - the first three have three techs that make sense for impacting ground combat, and plasma has two, making it a little cheaper to research up ground weapons. I wouldn't want to have to select which weapon type a unit is using, just use whatever option produces the highest number (though throwing an automatic entry in the stat block of an element when it was built showing what category of weapons it's using could be neat for fluff reasons. )
While this means you won't be as penalized by not researching a specific sub-field, races who invest in all the techs in a type will be better with them than ones who neglect one or more techs, which brings some nice verisimilitude.
I'm sure this has been mentioned before, but my survey FACs and carriers are really missing a "Refuel from Tanker" conditional order.
As an aside, the "Refuel from Colony or Hub" does not count local tankers with Refueling Systems if it should.
Quote from: clew link=topic=10640. msg130956#msg130956 date=1588693216I'm sure this has been mentioned before, but my survey FACs and carriers are really missing a "Refuel from Tanker" conditional order.
As an aside, the "Refuel from Colony or Hub" does not count local tankers with Refueling Systems if it should.
Refueling Hub is different component from Refueling System so Refuel from Colony or Hub should only work for ships with Refueling Hub system that is 100000 tons, not very useful for normal tankers.
I agree that Refuel from Tanker order would be welcome, but there may be problem with the fact that tanker can only refuel 1 ship at a time. So there could be problem when more ships arrive at once and that's why we don't have this command?
Hi fellows, I'm never getting tired of this great game. . .
The range a tug can operate largely depends upon the tonnage it carries. There is no way to determine the range though. Would be nice to have something that makes it visible how much the range is reduced, once you tug something.
The range a tug can operate largely depends upon the tonnage it carries. There is no way to determine the range though. Would be nice to have something that makes it visible how much the range is reduced, once you tug something.
What do you have to multiply the weight of the tug by to get the weight of the towed ship?
Add one to that.
That is your range ratio; divide the tugs unladen range by it and you have your laden range for that tonnage.
For example, my 50kt tugs have a range of 200bkm.
They often tow 250kt mining platforms.
250kt is 50kt times 5.
5 + 1 is 6.
200bkm / 6 is 33.33bkm.
It would be nice if an open galaxy map window updated automatically when time advances. I find I like running from there a lot of the time, but its a minor irritation to have to click refresh to see icons update, or newly discovered systems appear.
It would be nice if an open galaxy map window updated automatically when time advances. I find I like running from there a lot of the time, but its a minor irritation to have to click refresh to see icons update, or newly discovered systems appear.
True, but keep in mind that every auto-refresh of an open window adds a little bit of time to the execution of auto-turns.
Unless Steve can refactor it so that auto-refreshing only happens after auto-turns is interrupted.
Yes, and some place in the fleet display where this "shorter range" is displayed. Maybe even more. At the moment the ship tugs onto something it calculates the distance to the given target until unlinking and sends a log entry: cannot reach destination with current tug load. Fuel too low :-)The range a tug can operate largely depends upon the tonnage it carries. There is no way to determine the range though. Would be nice to have something that makes it visible how much the range is reduced, once you tug something.
What do you have to multiply the weight of the tug by to get the weight of the towed ship?
Add one to that.
That is your range ratio; divide the tugs unladen range by it and you have your laden range for that tonnage.
For example, my 50kt tugs have a range of 200bkm.
They often tow 250kt mining platforms.
250kt is 50kt times 5.
5 + 1 is 6.
200bkm / 6 is 33.33bkm.
Yes, and some place in the fleet display where this "shorter range" is displayed. Maybe even more. At the moment the ship tugs onto something it calculates the distance to the given target until unlinking and sends a log entry: cannot reach destination with current tug load. Fuel too low :-)
True, but keep in mind that every auto-refresh of an open window adds a little bit of time to the execution of auto-turns.
Unless Steve can refactor it so that auto-refreshing only happens after auto-turns is interrupted.
True, but keep in mind that every auto-refresh of an open window adds a little bit of time to the execution of auto-turns.
Unless Steve can refactor it so that auto-refreshing only happens after auto-turns is interrupted.
Now that it's not using VB6 anymore, updating open window contents really shouldn't be that expensive in CPU time, in theory. It's possible that something about how Steve has written the display code under the hood will make it problematic to implement, though with no way to look at the source we can only guess.
It would be really nice to have the option to make things update, maybe with a little warning when you first set the option that it may add a small amount of time to turns?
It would be neat to have some sort of marker in the dropdown list of systems in the mineral search view to indicate which systems contain either normal or populated colonies. It could be either color or a '(C)' after the system's name. That way it will be much easier to quickly find and search those systems which are of interest. Especially since remembering which Luyten I have a colony in can be a bit of a pain.
I'm surprised there isn't -- certainly VB Aurora's mineral report differentiated between bodies with colonies an those without.
- - - - -
Re Luyten:
Turn off Known Stars. One of my three biggest complaints about it is the proliferation of a small handful of names. Fifteen Wolfs and twelve Glieses, etc.
Use a naming theme for systems -- not for 'realism' within your fiction but for information control. Use Roman for everything through the first JP, French for the second JP chain, and Spanish for the third, or something like that. A coherent naming theme tells you where each system is if done right.
Add a pair of settings of species description:
1) Age of commission (AOC).
2) Age of retirement (AOR).
To give player some flexibility for designing fantastic races and/or managing plausibility of human race in their campaigns.
Calculate tour length (time between auto-promotion checks) as AOR - AOC / quantity of ranks.
Separate event type "Commander health" to different ones:And then only if the commander was assigned somewhere. If they were surplus then there is no reason to interrupt.
1) "Commander health" (non-fatal)
and
2) "Commander death"
Because the is no need to react to 1st sub-type, while 2nd sub-type demands players choice of new commander.
I have already proposed it in appropriate tread.Calculate tour length (time between auto-promotion checks) as AOR - AOC / quantity of ranks.
Sounds terrible! This should be a box in which we can specify a number of years (or months) like it was in VB Aurora.
I'd like to see the system numbers on the System window (F9) again.
I have been thinking of doing a campaign where you start with (virtually) nothing but there really isn't any in-game method of doing this. I would like some "rebuilding" civ tech or structure which is highly inefficient. If you have no construction factories I am not aware of how to RP them starting from scratch. I guess you could spawn some Construction Squads but you would need a huge quantity just to build anything.
If ground forces are the only way to do it. It would be nice to have miners, fuel harvesters etc duplicated in troop rolls.
To prevent massive simultaneous auto-promotions, identical ages of commanders, absolutely identical ground formations and ship crews, and so on, implement some randomization in such functions:
Commander creation
Age = MinimalCommissionAge + Random(0..YearLength) + StartingRankAboveMinimal*MinimalTourTime*Min(YearLength*Random(100%..200%),MaxServiceAge)
Commander auto-promotion
PromotoionSuccess = 50% * ProductionPhaseLength / YearLength
Ground Formation Creation
ActualElementsNumber = Ceiling( TemplateElementsNumber * PopStabilityModifier * Random(90%..100%) )
ShipCreation
CrewGrade = BaseCrewGrade * PopStabilityModifier * Random(90%..100%)
P.S.
Can be combined well with Empire/Species player-customizable parameters like EmpireCalendarYearLength, EmpireMinimalTourTime, SpeciesMinimalCommissionAge and SpeciesMaxServiceAge.
(Here's a work-around: fire your entire officer corps at game start, and let your Academies send you new people at nice, semi-randomized rate.)
No. The current system of promoting the most qualified officer when their is a vacancy is better.
The only reason you see "mass simultaneous promotions" is the identical starting dates (and time-in-grade) for the starting officer corps. Fix that and the problem goes away.
No. We already have a sizeable faction of players screaming bloody murder about their combat losses causing a pain of micromanagement to fix. I don't want to deal with them complaining about us forcing even their starting units to suffer the same way.
No. We already have a sizeable faction of players screaming bloody murder about their combat losses causing a pain of micromanagement to fix. I don't want to deal with them complaining about us forcing even their starting units to suffer the same way.
The cause of this pain - is the fact, that new-built formations are ideally fit, and veterans are not.
Make all of them not-ideal, only close to fit - and players will see it as normal state of things (as it is in real life), and it will be micromanagement to deal with very important operations only (as it is in real life, too).
I'm creating a new game as per the Garfunkel Protocol (tm), i.e several NPR races on Sol. Garfunkel emphasises on something, when you create the 2nd and subsequent human races, ** you should not ** use the first human race in the dropdown box, but the one from the first race you created (the only player race) on which you modified the race portrait, so you can identify it as the human race to use in races 2+
And indeed, in races 2+ there are 2 human races to choose from, the first one is not the valid one!!
This is quite the bobby trap shall I say! Perhaps Steve can remove this trap?
The cause of this pain - is the fact, that new-built formations are ideally fit, and veterans are not.
Make all of them not-ideal, only close to fit - and players will see it as normal state of things (as it is in real life), and it will be micromanagement to deal with very important operations only (as it is in real life, too).
Maybe an option to rebuild a formation to template at a training center, much like ships can be repaired at a shipyard? If it can be queued then the micromanagement would be greatly reduced. A default 'rebuild all present units' order would be ideal.The cause of this pain - is the fact, that new-built formations are ideally fit, and veterans are not.
Make all of them not-ideal, only close to fit - and players will see it as normal state of things (as it is in real life), and it will be micromanagement to deal with very important operations only (as it is in real life, too).
The solution to "veteran units end up with ragged TO&E after a campaign is over and people don't like it" is not to make newly built units suddenly start missing pieces! Logistics are the cornerstone of a military, and while you should totally end up cramming together ad-hoc formations in the middle of a campaign, once things are over and you get back to friendly territory, putting your units back in order should not require micromanagement.
Maybe an option to rebuild a formation to template at a training center, much like ships can be repaired at a shipyard? If it can be queued then the micromanagement would be greatly reduced. A default 'rebuild all present units' order would be ideal.
Maybe an option to rebuild a formation to template at a training center, much like ships can be repaired at a shipyard? If it can be queued then the micromanagement would be greatly reduced. A default 'rebuild all present units' order would be ideal.
1 Geo Survey or Grav Survey, Bonus: Survey
2 Protection Values > 0, Bonus: Crew Training
3 Military Vessel, Bonus: Crew Training
4 Construction Ship, Bonus: Production
5 Terraformer, Bonus: Terraforming
6 Harvester, Bonus: Mining
7 Asteroid Miner, Bonus: Mining
8 Salvager, Bonus: Production
9 All Others, Bonus: Logistics
10 None
The ability to delete unused hull types from the list. Alternatively the ability to have selectable hull type themes.
A way to turn prototypes into real tech easily and quickly. Like, this prototype, make it a real tech as I wanna use it and don't wanna fiddle about with options to replicate the damn thing when I have been spending time designing ships and forgot the exact specs. Like, maybe a button in ship design that says something like "Research Prototypes" that turn all the prototypes used in the class into a real design.
In fact, why have prototypes as a separate thing? Why not make all designed tech that have yet to be researched be prototypes automatically? The moment you research them they are not prototypes anymore but real tech, but until then they could work as prototypes do now.
(I post this is in a seperate post, cause I figured it was a separate suggestion and I decided one suggestion per post was best since I do not want it to get it lost to people who skim post, hope that is acceptable. If not then write to me and I will move it all to one post and delete this one)
This is supposed to already exist, however I haven't acutally had success with it the one time I tried to use it.
This is supposed to already exist, however I haven't acutally had success with it the one time I tried to use it.
Okay, thanks, but could you tell me where/how? Tried to find a button like that but I failed so far. But still, I wonder why not make all unresearched tech prototypes? Seems to me that would simplify things, but maybe there is a reason not to that I am unaware of?
A way to turn prototypes into real tech easily and quickly. Like, this prototype, make it a real tech as I wanna use it and don't wanna fiddle about with options to replicate the damn thing when I have been spending time designing ships and forgot the exact specs. Like, maybe a button in ship design that says something like "Research Prototypes" that turn all the prototypes used in the class into a real design.
In fact, why have prototypes as a separate thing? Why not make all designed tech that have yet to be researched be prototypes automatically? The moment you research them they are not prototypes anymore but real tech, but until then they could work as prototypes do now.
It would be kindof nice if prototypes became researchable as soon as you had the tech to do so.They aren't researchable automatically for reasons Migi pointed out above, but being able to mark future tech as researchable so they appear in the research tab as soon as their prerequisites are done would be handy.
It would be kindof nice if prototypes became researchable as soon as you had the tech to do so.They aren't researchable automatically for reasons Migi pointed out above, but being able to mark future tech as researchable so they appear in the research tab as soon as their prerequisites are done would be handy.
Minor quality of life suggestion:
Currently, if you train 9 company formations then train a HQ formation, the suggested name is "10th HQ". It would be nice if the ground unit construction tracked the unit numbers (1st Company, etc) by template rather than globally. I think it would be a relatively simple thing to track, and would make unit construction a smoother experience.
Class Design window
I know some people wanted the abbreviation after the name, but I'd like an option to put back in front. I use the abbreviations as a shorthand to quickly find the entries I want. In that same vein, an option to include the abbreviation in the class list would be helpful for the same reason.
Minor quality of life suggestion:
Currently, if you train 9 company formations then train a HQ formation, the suggested name is "10th HQ". It would be nice if the ground unit construction tracked the unit numbers (1st Company, etc) by template rather than globally. I think it would be a relatively simple thing to track, and would make unit construction a smoother experience.
I object to this. It wouldn't improve my quality of life at all; it would wreck it. I don't want to deal with fifteen different "1st Companies".
To put it bluntly, I think it would be easier for you to rename 10th HQ Co than for me to rename 2nd through 9th.
You wouldn't necessarily have to rename all of them if the numbering is tracked per formation type instead of per unit. Build 10 Companies, and they will be numbered 1st to 10th. Build two HQ Companies and they will be numbered 1st to 2nd. Build 5 Armored Regiments and they will be numbered 1st to 5th. Compare this to the continuous 1st to 17th that we have now. I think that would be a nice feature, but I'm not sure it's worth it.
You might encounter some issues if you start updating or altering existing formations. I don't know how unit and/or formation ID is tracked, but if there is a chance that changing a formation composition (with an updated infantry unit) would also reset the numbering if it's considered a new formation, then the whole exercise becomes much less worthwhile. If it resets just once (or doesn't), when it shouldn't, then there is nothing gained from it.
I would have to rename every single unit after the first. To be clear, the way I want it to work is exactly the way it works now. My fifty-fifth battalion -- whatever 'type' it may be -- I want to be my 55th Battalion.
I would have to rename every single unit after the first. To be clear, the way I want it to work is exactly the way it works now. My fifty-fifth battalion -- whatever 'type' it may be -- I want to be my 55th Battalion.
public string Format(string input, object p)
{
foreach (PropertyDescriptor prop in TypeDescriptor.GetProperties(p))
input = input.Replace("{" + prop.Name + "}", (prop.GetValue(p) ?? "(null)").ToString());
return input;
}
Format("test {first} and {another}", new { first = "something", another = "something else" })
Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.
I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.
Father Tim's system is actually used by many militaries. The logic is that the divisions are really:Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.
I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.
I might regret asking but what do you do with your ships? Do you rename them in order of launch date, regardless of class?
...I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box ...
That was one of the first things I looked at. It fails for two reasons: It is static compiled so it can't handle dynamic format strings, and even if it was dynamic there is no way to limit the scope. Either of these faults by itself would be grounds to reject it outright....I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box ...
Really? I think it does (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated).
fmt = "This {thing} has {attribute} {feature}."
text = fmt.format({'thing':'cat', 'attribute':'grey', 'feature':'fur'})
That was one of the first things I looked at. It fails for two reasons: It is static compiled so it can't handle dynamic format strings, and even if it was dynamic there is no way to limit the scope. Either of these faults by itself would be grounds to reject it outright....I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box ...
Really? I think it does (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated).
FormattableString only takes positional parameters, not named parameters, and requires that all parameters be used. Optional parameters aren't allowed. The first is problematic at best and the second is a showstopper. Think of this as being like environment variable expansion, with Aurora providing a dictionary and the user choosing which entries to include and how to display them.That was one of the first things I looked at. It fails for two reasons: It is static compiled so it can't handle dynamic format strings, and even if it was dynamic there is no way to limit the scope. Either of these faults by itself would be grounds to reject it outright....I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box ...
Really? I think it does (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated).
The FormattableString (https://docs.microsoft.com/en-us/dotnet/api/system.formattablestring?view=netcore-3.1)class allows dynamic format strings.
Do we really need string interpolation instead of composite formatting?
Not sure what you mean about limiting scope.
Father Tim's system is actually used by many militaries. The logic is that the divisions are really:Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.
I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.
I might regret asking but what do you do with your ships? Do you rename them in order of launch date, regardless of class?
1st Division, Arctic
2nd Division, Desert
3rd Division, Arctic
4th Division, HQ
IIRC that system dates back to the Romans.
Point. Different levels should be numbered independently. I was still thinking in terms of the old VB system where you are normally only building brigades. My bad.Father Tim's system is actually used by many militaries. The logic is that the divisions are really:Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.
I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.
I might regret asking but what do you do with your ships? Do you rename them in order of launch date, regardless of class?
1st Division, Arctic
2nd Division, Desert
3rd Division, Arctic
4th Division, HQ
IIRC that system dates back to the Romans.
That might be true for divisions IRL but IRL the sub-units of the divisions don't cause the division numbers to increase.
The way Aurora currently works gives you an orderly numbering of units as long as you don't have units in a hierarchy.
I'd be in favour of more options for unit naming and numbering like ships have.
As an aside, does each level or type of unit have it's own numberline IRL? (I imagine it depends on the country)
New movement order: Execute Order Template
As I am sitting here doing 36 refits of a frigate to a slightly better one, I found myself thinking that we need a refit queue. These refits take maybe 20-25 days. And so, every 20-25 days I have to click on one of the 5 buttons that brings up the colony info, switch to the shipyards tab, switch to refit, select the ship type to refit from, and click refit for each ship till the slipways are full. NB: I do not have a shipyard that has 36 slipways.
That's quite a lot of clicking and adjusting for the same task over and over again. I would much rather that I could queue up the additional refits. This would lock the ships in place, just as if they were in refit.
On a similar note, we should probably have a queue for production of ships as well.
...And so, every 20-25 days I have to click on one of the 5 buttons that brings up the colony info, switch to the shipyards tab...
A nice simple QoL suggestion.An alternative would be to grey-out the speed box when Maximum Speed is enabled as a visual cue to the user that it is enabled.
When entering a fleet speed via the set speed button, would be great if it automatically unset the use max speed checkbox when you apply the new speed, ensuring that you do actually get that speed in the next increment - even when the user forgets the checkbox exists, as I had.
I'd like it to be easier to see what body the Cives have setup a CMC on. Once they change the name. its not easy to tell if its a comet or an asteroid or a moon. A knockon effect from that makes it harder to prioritise administrators.
With left click on any system body you can center the view on that body. However the center point is calculated by screen size, not the size of the window. Would be nice if it would center the view dependent on the size of your window.
I'd like it to be easier to see what body the Cives have setup a CMC on. Once they change the name. its not easy to tell if its a comet or an asteroid or a moon. A knockon effect from that makes it harder to prioritise administrators.
You can click one of the bottom chechboxes to enable system body name next to CMCs.
Please Steve this one would just help so much, please allow either mouse wheel scrolling or scrolling with buttons (anything is better than now) to the galaxy map as it would make life so much easier in the mid-lategame especially for AARs when you are trying to show off the galaxy, for you it tends to be fine cause you have a really big monitor but for others like me it is quite hard.
Please Steve this one would just help so much, please allow either mouse wheel scrolling or scrolling with buttons (anything is better than now) to the galaxy map as it would make life so much easier in the mid-lategame especially for AARs when you are trying to show off the galaxy, for you it tends to be fine cause you have a really big monitor but for others like me it is quite hard.
Does right-click-drag not work on the Galactic map like it does on the Tactical map?
Right-click drag does nothing in either map, so unless you mean left click drag which is just to move around then yes thats in, but that does not allow you to zoom out fully to see the entire map on 1 screen
Yes, sorry. I meant left-click drag to move around. As far as I know, the galactic map is not zoomable in any way. It exists at a fixed number of pixels.Hence his suggestion :).
I would really like a "blast anything that comes through that jump point" order right now - it feels like without it, I'm at an unfair disadvantage to the AI.
I'm camping a JP with a jump gate in both directions (so no jump cool down), and the AI is doing the same (or at least had a fleet there last time I poked through). The AI keeps sticking some ships through the gate, then jumping straight back. Which doesn't give me time to target them - they appear, I set up targeting and give the open fire command, and they vanish without me firing. Since they have been doing this repeatedly with the same ships, if I leave the targeting orders in place, I do get to blast them as soon as they appear if they jump through the ships I have already set up targeting for. But this spams my logs with target not in range reports. And only works the second time they jump through with the same fleet (which they probably shouldn't be doing anyway - if they didn't like what was here the first time they jumped, they probably shouldn't do it again 6 hours later).
If I jump through, I just get blasted - presumably the AI sets up firing in the same tick. I'd really like a way to set my ships to use this logic too.
Or I suppose ideally, have the firing moved ahead of the jumping in the turn order, so I could get a shot at them normally on the turn they jump. But I imagine messing with turn order involves a lot of other changes.
Are they supposed to be able to jump back out the tick after they jump in? That part seems weird.
Decouple the research rate of technology from the research rate of designed systems, and allow them to be set separately.
That way I can play my 20% research rate game without also needing five times as long to research each new engine.
On top of the great new game-wide option, add options to disable/enable civilian shipping/harvesters individually for each player-controlled race.
This is for the "motor home has racked up some mileage"-longlist: One can work around the global option as it is by deleting any new civilian ship in an empire where they don't fit in (or invent a story to make them fit RP-wise), and I think (?) if you delete the first ships immediately before they produce revenue, any new line should be unable to afford new ones, so it shouldn't take much effort. But it would still be nice to simply have a tickbox in the Race Window.QuoteChanges / Additions
Shipping Lines can be deleted
How about an extension to the shipyard system. To me in the actual system I have two choices how to design my shipyards: I can either have one for each class or I can design only a few for fitting sized of my ship classes and retool as needed.
I am suggesting a third option. Since we are talking shipyards here a lot of work is being done in a very modular way. So a component is constructed in some place and then assembled in the main assemble area. Somewhat components come together isn’t that relevant to what ship can be assembled but rather the size that can be assembled.
Adding production lines to a shipyard might be an interesting alternative then. So when you first design a shipyard you tool it for one class. Over time new classes can be added to that shipyard - as long as it would fit the size of the shipyard. But adding instead of retooling is more expensive than retooling. So one would end with a shipyard that maybe has three sliplines of 17.000t but that one can build/scrap/retool eight different ship classes.
I would like a way to group fleets within the same admin command, without needing to create a new sub-command.Or just skip intermediate fleets that don't have any ships in them when working out command bonuses.
This is purely for logical grouping--no mechanical effect.
I simply want an additional level of expand/collapse nodes so I can manage the dozens of freighter fleets in my logistical admin command without sacrificing the optimization of my admin hierarchy (right now I have to create parallel commands at the lowest level, using inferior officers).
Maybe call it a fleet group?
I would like a way to group fleets within the same admin command, without needing to create a new sub-command.Or just skip intermediate fleets that don't have any ships in them when working out command bonuses.
This is purely for logical grouping--no mechanical effect.
I simply want an additional level of expand/collapse nodes so I can manage the dozens of freighter fleets in my logistical admin command without sacrificing the optimization of my admin hierarchy (right now I have to create parallel commands at the lowest level, using inferior officers).
Maybe call it a fleet group?
Sure. If I'm not making sense then I should probably go to bed. Cheers.I would like a way to group fleets within the same admin command, without needing to create a new sub-command.Or just skip intermediate fleets that don't have any ships in them when working out command bonuses.
This is purely for logical grouping--no mechanical effect.
I simply want an additional level of expand/collapse nodes so I can manage the dozens of freighter fleets in my logistical admin command without sacrificing the optimization of my admin hierarchy (right now I have to create parallel commands at the lowest level, using inferior officers).
Maybe call it a fleet group?
Not sure I follow. When you say fleets do you mean admin commands?
I really would need a "follow at" that don't just include the distance but also the vector.
This way I could tell a fleet to follow another fleet at a specific distance and direction. This would be an immense help when setting up patrols, escort or even when attacking an enemy if you want to do it from a specific direction. But mostly it is about setting up patrols, recon and escort missions.
Right now it is a bit fiddly to do so with way-points as it becomes allot of micromanagement to use picket scouts and so forth...
Another problem right now is also that you can't set the speed of ships as that feature don't work so it is very difficult to get picket scouts to follow a fleet unless they have the same speed as the slowest ship in that fleet. This is a big problem right now which make picket scouts very difficult to use.
I really would need a "follow at" that don't just include the distance but also the vector.To set the speed you have to uncheck 'use max speed'.
This way I could tell a fleet to follow another fleet at a specific distance and direction. This would be an immense help when setting up patrols, escort or even when attacking an enemy if you want to do it from a specific direction. But mostly it is about setting up patrols, recon and escort missions.
Right now it is a bit fiddly to do so with way-points as it becomes allot of micromanagement to use picket scouts and so forth...
Another problem right now is also that you can't set the speed of ships as that feature don't work so it is very difficult to get picket scouts to follow a fleet unless they have the same speed as the slowest ship in that fleet. This is a big problem right now which make picket scouts very difficult to use.
To set the speed you have to uncheck 'use max speed'.
Several new modules for ships:There is a maintenance module that handles the 'mobile repair facility' function. I haven't used them yet so I don't know if they make MSP or not.
- A mobile repair facility capable of repairing other ships, provided the repairing ship has raw materials and/or MSP on hand
- A mobile MSP production facility
- A mobile ordnance production facility
Apologies if this has already been suggested or discussed/turned down, but I have always wanted to duplicate the 'fleet auxiliaries' depicted in the Lost Fleet series, and those three capabilities are pretty key to the concept, not to mention that it would make fleet logistics much more forgiving.
yeah sure guys, never wanted to add you more jobs!
i have a computer attached to the TV, so theres no problem to play normally, only wanted to know if im outside with my old laptop. :)
only wanted to know if theres any way to change it easily :)
will destroying Stabilisation Gates be a thing? so you could contain NPRs. Just a thoughtThe switch from describing it as jump gate construction to jump gate stabilization was, if I remember correctly, specifically because Steve does not want it to be possible to undo the connection (outside of SM mode).
There are a lot, and really a lot of names themes in Aurora ...
And some of them might feel silly, or useless. It depends of the player, but I'm sure most of you, if you were to browse the entire list, would say that some lists, you would never use them. And probably you would prefer not having a NPR use them either.
Or perhaps you feel a list is too short so not good to use.
So here is my suggestion. Have a txt file in the Aurora directory, this is the list of excluded lists of names, that the player wants to be ignored by Aurora.
So for example, if I find that 'Ukrainian Birds' is not a list I want to see, for whatever reasons (no offense toward Ukrainian birds ;D ) then I would add the list name in the txt file and Aurora would not show it as a possible list.
That would allow also some 'sanitization' I believe. We just can't have all possible lists submitted by everyone appears in the game, this slow browsing the lists you might be interested in.
Some sort of way to "repair" or "refit" ground unit formations into a formation template.
Minor QoL feature, it would be great if we could have the "Hide Civilian Contact Names" option on the Display window back. It really declutters the system view while still being able to see civilian shipping (and watch the trade convoys pass by)Contacts tab, uncheck 'Civilians'.
I can see some possible use cases to handle mangled/obsolete formations:I think the refit and repair tasks which shipyards do could be a model for this.
An option to swap units with another formation to meet a template. This could also be used to quickly reorganize existing formations in the field.
An option for a training center to replace any missing units in an existing formation. Bonus points if the replacement cohort can be built for a formation that is at another location, to be transported and merged on site.
An option for a training center to refit existing units to a new type.
Minor QoL feature, it would be great if we could have the "Hide Civilian Contact Names" option on the Display window back. It really declutters the system view while still being able to see civilian shipping (and watch the trade convoys pass by)Contacts tab, uncheck 'Civilians'.
It would be nice to be able to create a system in SM mode without passing knowledge of it to the player, and have the ability to delete knowledge of a system from a player. This would allow two player races in different systems to start without any knowledge of each other, even if one of them starts in Sol.
A special message that appears when an Admin Command or a colony/sector loses a leader would be nice. Right now you have to scrutinize every retirement to make sure they weren't assigned to something, and most of the time I can't see it cuz the words don't fit on my skinny secondary monitor.
Of course, being able to set automatic assignments for those jobs would be most ideal.
Also, can we have a way to add officers of lower rank? I want to add ranks of less than Major, like Sergeant and Lance Corporal. It's a pain in the arse right now to do it...You have add-to-the-top-and-rename-all option. That's one-time per company start, so not a catastrophe. Yes, boring, but I do it at every new start. :)
Also, can we have a way to add officers of lower rank? I want to add ranks of less than Major, like Sergeant and Lance Corporal. It's a pain in the arse right now to do it...
Also, can we have a way to add officers of lower rank? I want to add ranks of less than Major, like Sergeant and Lance Corporal. It's a pain in the arse right now to do it...
Not sure if this is what you mean... but in the "Commanders" window you can add additional ranks and rename them. You can model any rank system that you like.
If you need more ground force commanders then make one the leader of your Academies so you get more ground force commanders each year.
I've noticed that the rates of death in my scientists seem to be disproportionately high at the start of a game when using a non TN start. I suspect this is because of the relatively small pool of military officers, administrators and scientists from which to apply random problems to and often results in me having only 5 or 6 scientists left from a reasonably healthy start point by the time I'm ready to start using them. I wonder if the death rates could be adjusted to reflect the age of the relevant person so that naturally your young and upcoming bunch have less chance of ending their careers very early.
That might also tie well with allowing players to set a normal retirement age to better reflect different starting conditions.
Orbital habitat population capacity of a body could be changed to an int64 (or some other higher-capacity datatype) instead of the current int32, limiting current capacities to just over 2b and throwing errors above it.If you are getting errors, post it in the bugs thread, it's more likely to get attention there.
While 2b capacity might not be something that most players would ever be close to reaching on a single body in their games, I've been thinking about doing an orbital-habitat-only game, which this limitation makes infeasible.
Quote from: Siccles link=topic=10640. msg135952#msg135952 date=1591186020Orbital habitat population capacity of a body could be changed to an int64 (or some other higher-capacity datatype) instead of the current int32, limiting current capacities to just over 2b and throwing errors above it.If you are getting errors, post it in the bugs thread, it's more likely to get attention there.
While 2b capacity might not be something that most players would ever be close to reaching on a single body in their games, I've been thinking about doing an orbital-habitat-only game, which this limitation makes infeasible.
It isn't per se a bug though.
We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit. While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve. MSP below this level can only be used by maintenance facilities. This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry. This will also help when dealing with large temporary demands.
You could just RP such a limitation, but I won't object to making it an option. Insufficient planning isn't the only reason to want #3. MSP demand can be quite variable if you use beam fleets and you can't always predict the timing or tempo of a campaign. Front-loading production before a major battle can make all the difference. The problem with overbuilding maintenance facilities isn't just the construction cost of the facilities, but the excess capacity has continuous worker and mineral costs as well.We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit. While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve. MSP below this level can only be used by maintenance facilities. This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry. This will also help when dealing with large temporary demands.
I love 1 and 2, but not 3.
I like that I can't compensate for my insufficient planning by just throwing some factories at the problem for a week or two.
Maybe it's possible to make it configurable per game (at game creation)?
You could just RP such a limitation, but I won't object to making it an option. Insufficient planning isn't the only reason to want #3. MSP demand can be quite variable if you use beam fleets and you can't always predict the timing or tempo of a campaign. Front-loading production before a major battle can make all the difference. The problem with overbuilding maintenance facilities isn't just the construction cost of the facilities, but the excess capacity has continuous worker and mineral costs as well.We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit. While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve. MSP below this level can only be used by maintenance facilities. This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry. This will also help when dealing with large temporary demands.
I love 1 and 2, but not 3.
I like that I can't compensate for my insufficient planning by just throwing some factories at the problem for a week or two.
Maybe it's possible to make it configurable per game (at game creation)?
This brings up another issue: In VB we could turn off entire industries on a colony which would free up the workers for other jobs. This feature is missing in C#.
I don't like the option to just self-impose, because I want the AI to have to play by the same rules.Fair point about the AI.
Fair points about labor issues, and burst demand from beam fleets.
To free up workers, I have resorted to hauling unneeded installations to an unused moon. It's a slow and expensive Off switch, but I find I don't need to use it very often.
You could just RP such a limitation, but I won't object to making it an option. Insufficient planning isn't the only reason to want #3. MSP demand can be quite variable if you use beam fleets and you can't always predict the timing or tempo of a campaign. Front-loading production before a major battle can make all the difference. The problem with overbuilding maintenance facilities isn't just the construction cost of the facilities, but the excess capacity has continuous worker and mineral costs as well.We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit. While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve. MSP below this level can only be used by maintenance facilities. This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry. This will also help when dealing with large temporary demands.
I love 1 and 2, but not 3.
I like that I can't compensate for my insufficient planning by just throwing some factories at the problem for a week or two.
Maybe it's possible to make it configurable per game (at game creation)?
This brings up another issue: In VB we could turn off entire industries on a colony which would free up the workers for other jobs. This feature is missing in C#.
I don't like the option to just self-impose, because I want the AI to have to play by the same rules.
Fair points about labor issues, and burst demand from beam fleets.
To free up workers, I have resorted to hauling unneeded installations to an unused moon. It's a slow and expensive Off switch, but I find I don't need to use it very often.
You can use SM mode to delete unused installations through the civilian economy (the one where you make contracts) menu. This has the obvious problem of making such installations unrecoverable.Installations can be replaced the same way, but deleting them tends to be problematic when you are trying to ship them somewhere else. And if you ever do want them back it means needing to manually keep track of which 'ghost' installations go where.
I just want the ability to spacemaster jump point destinations brought back.
Use FFD to increase rear bombardment's weapon chances to hit, not only air and orbital ones.
For performance reasons, it'd be very welcome to implement limits on civilian ship traffic. Ideally all configurable in the game options.In case you weren't aware, you can turn off civilian vessel generation in the game settings any time after starting.
A few alternatives:Cheers!
- Global civilian vessel cap
- Civilian vessel cap tied to number of colonies
- Civilian vessel cap tied to empire population (best one in my opinion ;))
For performance reasons, it'd be very welcome to implement limits on civilian ship traffic. Ideally all configurable in the game options.In case you weren't aware, you can turn off civilian vessel generation in the game settings any time after starting.
A few alternatives:Cheers!
- Global civilian vessel cap
- Civilian vessel cap tied to number of colonies
- Civilian vessel cap tied to empire population (best one in my opinion ;))
I don't think that ships in transit are the problem, rather it is the idle ships looking for work and not finding it. If so, then the problem is that the civvies build more ships than they need.For performance reasons, it'd be very welcome to implement limits on civilian ship traffic. Ideally all configurable in the game options.In case you weren't aware, you can turn off civilian vessel generation in the game settings any time after starting.
A few alternatives:Cheers!
- Global civilian vessel cap
- Civilian vessel cap tied to number of colonies
- Civilian vessel cap tied to empire population (best one in my opinion ;))
I think people want the civilian economy to scale with their empire without destroying game performance on the long term, which is why a lot of people want to see a more limited approach to civies.
The checkbox you mention is a perfectly valid solution and it should never be removed IMO but it is kind of stop gap.
I personally think that the civilian economy should be abstracted more so that individual ships shouldn't be simulated all the time. Maybe instead use a system similar to how the "detection only in systems where player is" dropdown works and instead dynamically load in civilian freighters only when there are enemy/NPR ships in the same system. That way you only load in like 100 of the total 600 civilian ships during an NPR attack for example
In case you weren't aware, you can turn off civilian vessel generation in the game settings any time after starting.
Frankly the simplest soultion would be:I've been saying that for years. :)
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.
Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.
It is actually trivial to track and shouldn't noticeably affect performance. Give each shipping line a counter for each category of ships it operates (F, C, L). Every time a civilian ship can't find* a job, bump the appropriate counter. Every time a shipping line builds new ships, only consider categories that have low** counters and then reset the counters for that line. If all categories are too high then don't build anything and put the money into dividends instead.Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.
At first glance, yes, but then one realizes the game needs to gauge what constitutes idle in practice, because idle today doesn't mean idle yesterday or tomorrow. If it's something like "inactive for X days", that means putting a timer on every civilian ship out there, which may well not be particularly performance-friendly.
It is actually trivial to track and shouldn't noticeably affect performance. Give each shipping line a counter for each category of ships it operates (F, C, L). Every time a civilian ship can't find* a job, bump the appropriate counter. Every time a shipping line builds new ships, only consider categories that have low** counters and then reset the counters for that line. If all categories are too high then don't build anything and put the money into dividends instead.Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.
At first glance, yes, but then one realizes the game needs to gauge what constitutes idle in practice, because idle today doesn't mean idle yesterday or tomorrow. If it's something like "inactive for X days", that means putting a timer on every civilian ship out there, which may well not be particularly performance-friendly.
*They check every time they finish a job or once every five days while idle.
**One more than the number of production cycles since the last build cycle is probably a good upper limit.
I think it is simply better to use the same mechanic that build ships which is income... make every ship they have cost something to support... if the income stagnate then the cost will outweigh the income and eventually they will have to sell their ships. They might be able to sell them to some other civilian company, even to another faction of there is trade for a cheap price. If no one want's to buy the ship it simply get scraped and the company get a small return on the ships build cost.Such a system would make the shipping lines overbuild until they bankrupted themselves and collapsed. Not only does it do nothing to address the problem at hand (overbuilding ships) it actually manages to be worse than the existing system (introduces catastrophic collapse cycles). The demand limiting mechanisms under discussion aren't arbitrary, but a simplified model of how actual shipping lines manage production.
This would make it so that civilian shipping lines only exist when they are needed and there will be a natural decline if there is little to no work for them to do.
There is no need to use artificial and arbitrary rules for this, the economy can govern itself.
I would even eventually extend this to fuel costs and a more dynamic civilian economy that also need trans-Newtonian materials to thrive well. But that would be the next logical step...
I think it is simply better to use the same mechanic that build ships which is income... make every ship they have cost something to support... if the income stagnate then the cost will outweigh the income and eventually they will have to sell their ships. They might be able to sell them to some other civilian company, even to another faction of there is trade for a cheap price. If no one want's to buy the ship it simply get scraped and the company get a small return on the ships build cost.Such a system would make the shipping lines overbuild until they bankrupted themselves and collapsed. Not only does it do nothing to address the problem at hand (overbuilding ships) it actually manages to be worse than the existing system (introduces catastrophic collapse cycles). The demand limiting mechanisms under discussion aren't arbitrary, but a simplified model of how actual shipping lines manage production.
This would make it so that civilian shipping lines only exist when they are needed and there will be a natural decline if there is little to no work for them to do.
There is no need to use artificial and arbitrary rules for this, the economy can govern itself.
I would even eventually extend this to fuel costs and a more dynamic civilian economy that also need trans-Newtonian materials to thrive well. But that would be the next logical step...
Civilians using TN materials, especially fuel, would not only eliminate the sole advantage to having them but it would make them an active threat. There would be no reason to ever enable them.
The proposed system of running costs, plus selling ships the line cant afford, would work perfeclty fine if there was dampening on both ends of the behavior.Building surplus ships due to surplus income is the problem behaviour that we need to fix. Adding a delay would cause unnecessary production lag during growth periods, especially in the critical early game, while doing nothing to actually limit overbuilding. The only 'dampening factor' that will effectively curb idle civilian ships is to track their idle time. No measurement of supply (income) can ever accomplish that goal because it is measuring the wrong thing, and any valid proxy will always be inferior to direct measurement.
That is to say: if current rate of income isnt meeting current costs (sum of income vs sum of costs for past year for instance), start scrapping ships (less effecient ships first, so for instance older engine tech perhaps), rather than waiting to run out of money first (waiting to run out would cause a catastrophic collapse). Additionally, only purchase new ships if surplus income is sustained for a while (maybe a year? i dunno).
The running cost could be changed to calibrate roughly how many ships they keep on hand.
No... they would not..Even granting that, your proposed system still requires a large idle fleet to create the increased costs needed to curb growth. It will always produce a fixed ratio of working to idle ships, which is what the current system already gives us and is exactly the problem that we need to fix. Simply changing the ratio does not address the problem. Reducing the ratio too far will also cripple small lines in the early game.
1. They first would try to sell it... if that don't work they scrap it and get some wealth back.
2. When a ship is sold/scraped their running cost is lowered and they get some fresh new cash.
This would act to balance their economy and not make it crash, not very hard to make right at all... They would only crash if there is NO jobs at all. In that case there can be some safeguard in place where they are guarantied to keep a few ship that they don't have to pay maintenance for.
It should control their population somewhat if there is a substantial running cost for the ships.That would cause idle colonizers to limit needed freighter production without actually preventing construction of unnecessary ships in the first place.
I don't think that ships in transit are the problem, rather it is the idle ships looking for work and not finding it. If so, then the problem is that the civvies build more ships than they need.
As long as those freighters all belong to the same race so they all share the same job pool, then yes that would help a lot.I don't think that ships in transit are the problem, rather it is the idle ships looking for work and not finding it. If so, then the problem is that the civvies build more ships than they need.
If that's the case, then refactoring the code to avoid redundant checks could go a long way towards solving the problem.
After all, if one small freighter at location X looks for work and does not find any, then the rest of the small freighters at location X don't even need to look.
J-2.5k Ise 1 class Tanker 2,500 tons 46 Crew 133.05 BP TCS 50 TH 50 EM 0
1000 km/s JR 3-50 Armour 1-16 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 1 PPV 0
MSP 33 Max Repair 33 MSP
Intended Deployment Time: 24 months Spare Berths 0
J3000(3-50) Military Jump Drive Max Ship Size 3000 tons Distance 50k km Squadron Size 3
50 EP Commercial Nuclear Pulse Engine (1) Power 50 Fuel Use 1.64% Signature 50 Exp 2%
Fuel Capacity 150,000 Litres Range 658.5 billion km (7621 days at full power)
This design is classed as a Commercial Vessel for maintenance purposes
Taiho class Tanker (P) 5,977 tons 53 Crew 116.3 BP TCS 120 TH 120 EM 0
1003 km/s JR 1-25(C) Armour 1-29 Shields 0-0 HTK 15 Sensors 0/0/0/0 DCR 1 PPV 0
MSP 12 Max Repair 20 MSP
Kaigun-Ch?sa Control Rating 1 BRG
Intended Deployment Time: 3 months
JC6K Commercial Jump Drive Max Ship Size 6000 tons Distance 25k km Squadron Size 1
60HS 120EP 1.07L (1) Power 120 Fuel Use 0.89% Signature 120 Explosion 2%
Fuel Capacity 150,000 Litres Range 505.4 billion km (5832 days at full power)
Refuelling Capability: 50,000 litres per hour Complete Refuel 3 hours
This design is classed as a Commercial Vessel for maintenance purposes
The reduced cost is due to lower fuel tank costs in C# (24 BP savings) and using a commercial jump drive (23 BP). Note that this design also can't jump tend for military engined survey ships like the VB version can. That requires a second ship with a military jump drive.(...)Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.
Allow military jump drives to work with commercial engines again.
(...)Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.
Allow military jump drives to work with commercial engines again.
Frankly, I want both. :)(...)Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.
Allow military jump drives to work with commercial engines again.
I would rather like the idea of having multiple jump engines on the same ship. Then making jump stations becomes fairly possible.
Drive (size/cost) | Eff 4 | Eff 25 |
Smallest Military (1HS/10BP) | 200 | 1250 |
Cheapest Military (7.5HS/10BP) | 1500 | 9400 |
Smallest Commercial (10HS/10BP) | 1500 | 9500 |
Cheapest Commercial (75HS/10BP) | 11,000 | 70500 |
Largest Military (1kHS/63kBP) | 200,000 | 1,250,000 |
Largest Commercial (10kHS/63kBP) | 1,500,000 | 9,375,000 |
(...)Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.
Allow military jump drives to work with commercial engines again.
In addition to this I only think that a certain size of troops only should be able to face of against a maximum enemy size and this should depend on both terrain and colony size. The more developed a planet is the more difficult it should be to overwhelm a garrison force as the infrastructure will prevent it in it self.
A combat width mechanic based on tonnage (affected by stuff like terrain still) would be very interesting, It would also put more emphasis on having a more in-depth OOB since small formations would have an easier time joining/reinforcing the fight.
I also think that a counter to the attacker fortification problem is to use fortification levels below 1.
Consider using orbital drop pods in your transports - this option exists to protect your transports as it allows them to just dump all ground units at once, however you could make it so that every unit that is dropped this way starts at 0.5 fortification due to how disorganized the troops are in the initial landing, you could also have a commander skill for landing which makes these units start at higher fortification.
This does 2 things:
The defender is incentivized to put some of their units on frontline attack as now is the time where the attackers are at their most vulnerable and where most of their casualties will be.
The attacker is incentivized to not immediately charge in and wait for their troops to establish an actual "beachhead", getting their fortification up to at least 1 before pushing on.
This also means that there is an additional emphasis on STO protection. You could make it so that the fortification penalty does not apply when troops are unloaded from the transport bays normally. Ofc this means that the transports have to linger around STO range for much longer and troops might be coming in piece-meal.
So now defenders are encouraged to have more STO units in order to force an attacker to face the fortification penalty or for them weather the STO storm on their transports.
IMO right now planetary landings are just made too easy because of the drop pods, fast, armored/shielded transports almost completely nullify any benefit STOs give to a defense beyond preventing orbital bombardment. The initial landing should be the bloodiest part of the fight for the attacker and right now it isn't any deadlier than the rest of the fight.
Since this is a very defender-centric suggestion I think there should be some form of combat engineer capability for infantry that speeds up the rate of self-fortification which helps the attacker get over the initial drop phase quicker.
As an extension I actually want one of the bugs from the earlier versions of C# to return as a feature.I was going to object to this on the basis of potential exploits, but I can't find any.
The game allowed us to use different types of the same engine archetype - eg. my ships could have 1 HS 15 military engine and 2 HS 6 military engines but would not be able to mix-match commercial and military engines.
I don't think allowing different size engines on the same ship compromises any sort of game balance. Fuel consumption and thermal signature are already calculated per-engine.
I also do not understand why a ship cannot mount different sized shields, the regen rate and capacity are already calculated on a component-wise basis.
HS | HS | EP | L/h | BP | RP |
10 | 10 | 200 | 200 | 100 | 500 |
9 | 11 | 200 | 199.75 | 100 | 1000 |
5 | 15 | 200 | 193.18 | 100 | 1000 |
1 | 19 | 200 | 169.46 | 100 | 1000 |
20 | 200 | 141.42 | 100 | 1000 |
HS*# | EP | L/h | BP | RP | Range | Speed | |
1*24 | 240 | 758.88 | 120 | 50 | 237m km | 5k km/s | These engines are exactly at the 5 BP cost floor, so going smaller has no cost benefit. |
8*3 | 240 | 268.32 | 120 | 400 | 671m km | 5k km/s | |
10*2+4*1 | 240 | 263.25 | 120 | 700 | 684m km | 5k km/s | |
24*1 | 240 | 154.92 | 120 | 1200 | 1162m km | 5k km/s |
HS*# | EP | L/h | BP | RP | Range | Speed |
23*1 | 230 | 727.26 | 115 | 50 | 237m km | 4.79k km/s |
7*3 | 210 | 251.01 | 105 | 350 | 627m km | 4.4k km/s |
7.6*3 | 228 | 261.54 | 114 | 380 | 654m km | 4.75k km/s |
10*2+3*1 | 230 | 254.77 | 115 | 650 | 677m km | 4.79k km/s |
23*1 | 230 | 151.66 | 115 | 1150 | 1137m km | 4.79k km/s |
New fleet command: Follow from directionThis sounds like the old Protect Threat Axis special order from VB. It had options for specifying a protected fleet, follow distance, primary threat, and a bearing offset. Yes, please bring that back.
Another thought about command would be a multi selection type of command structure so the list is not so long and easier to manage and add more command.The movement orders tab can get crowded, and there are quite a few QoL and logistical orders that people have been asking for. Sorting and grouping orders will help going forward. I would make it a single click to expand a heading, and expanding one collapses any other that was open. I've seen this style of control on the web, but I'm totally forgetting the name.
Structure them so you can double click on them and then you get more specific command available so the first list just have the basic command available... this way you can add more command without cluttering the list.
So the list could look something like this...
Move
Logistics
Load
Miscellanous
If you select Move. (double click)
You get a list of...
Move to Location
Follow
Picket
If you click on Logistics.
Refuel from Colony
Resupply from Colony
Refuel and Resupply from Colony
etc...
You could also make this as a selectable choice if you want all command in a list or sorted in categories.
But the reason is to make it easier to implement new commands without having everything in one list making it hard to find the correct order.
Implement small craft Refuelling System, Shuttle Bay, and Ordnance Transfer System components at 1/10 size for 1/5 cost and with 1/20 of the capacity of their full sized counterparts. Please consider fighter scale (1/100 size, 1/25 cost, 1/400 capacity) as well.
This is true, but Steve has asked us not to mod, and I do try to respect that. Cheers.Implement small craft Refuelling System, Shuttle Bay, and Ordnance Transfer System components at 1/10 size for 1/5 cost and with 1/20 of the capacity of their full sized counterparts. Please consider fighter scale (1/100 size, 1/25 cost, 1/400 capacity) as well.
I agree with this.
Sidenote: it seems you can make such components available by adding the appropriate records to a single table in the database. That won't cause civvies, NPRs, or spoilers to use them, but they will be available for your own use.
This is true, but Steve has asked us not to mod, and I do try to respect that. Cheers.Implement small craft Refuelling System, Shuttle Bay, and Ordnance Transfer System components at 1/10 size for 1/5 cost and with 1/20 of the capacity of their full sized counterparts. Please consider fighter scale (1/100 size, 1/25 cost, 1/400 capacity) as well.
I agree with this.
Sidenote: it seems you can make such components available by adding the appropriate records to a single table in the database. That won't cause civvies, NPRs, or spoilers to use them, but they will be available for your own use.
Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .
Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.
Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .
Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.
As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.
Jump point stabilization has significant strategic implications, primarily border control and containing civilian operations. Permanent destabilization would be an asset when moving into an area where an NPR 'helpfully' stabilized every jump point.Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .
Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.
As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.
I don't think permanent de-stabilization is a good idea however I think it would be great to have some sort of "interdiction module" that when used on a jump point will take x amount of time and will distrupt a stabilized point for y amount of time, after which the jump point reverts back to its stabilized state.
To further extend this I think it would be cool to have some sort of advanced interdiction that can (albeit temporarily) completely disrupt a jump point, rendering it unusable by anything. I don't think allowing this to happen permanently is a good idea since you would end up with a bunch of useless isolated systems eventually.
Make Available Workers (~ unemployed) generating some unrest, maybe affected by Determinancy and/or Trade racial stats.While I like this idea, population management is already too micro-managy. The only viable solution would become 'drop troops on it until things settle down'.
(The thing I want is some constant source of economic unrest, not only military and life-support ones.)
Jump point stabilization has significant strategic implications, primarily border control and containing civilian operations. Permanent destabilization would be an asset when moving into an area where an NPR 'helpfully' stabilized every jump point.Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .
Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.
As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.
I don't think permanent de-stabilization is a good idea however I think it would be great to have some sort of "interdiction module" that when used on a jump point will take x amount of time and will distrupt a stabilized point for y amount of time, after which the jump point reverts back to its stabilized state.
To further extend this I think it would be cool to have some sort of advanced interdiction that can (albeit temporarily) completely disrupt a jump point, rendering it unusable by anything. I don't think allowing this to happen permanently is a good idea since you would end up with a bunch of useless isolated systems eventually.
Spamming JP stabilizers is one of the possible AI behaviours that gets chosen at random at NPR creation. My current game has one inside my perimeter because it managed to sneak past my sensor buoys. Unless NPRs don't need to gravsurvey then they also got some of those in undetected as well and I can't find them. :(Jump point stabilization has significant strategic implications, primarily border control and containing civilian operations. Permanent destabilization would be an asset when moving into an area where an NPR 'helpfully' stabilized every jump point.Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .
Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.
As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.
I don't think permanent de-stabilization is a good idea however I think it would be great to have some sort of "interdiction module" that when used on a jump point will take x amount of time and will distrupt a stabilized point for y amount of time, after which the jump point reverts back to its stabilized state.
To further extend this I think it would be cool to have some sort of advanced interdiction that can (albeit temporarily) completely disrupt a jump point, rendering it unusable by anything. I don't think allowing this to happen permanently is a good idea since you would end up with a bunch of useless isolated systems eventually.
I have never encountered a 'helpful' NPR nor have I encountered a jump point stabilized by a NPR. Is this actually a possibility in-game?
I stand by my previous assertion that jump point destabilization would be an interesting game mechanic. ESPECIALLY if NPRs can stabilize jump points.
If demons were invading Earth would you not want the ability the close the demonic warp gate? I certainly would....
I suggest that there be an order along the lines of '80% of maintenance life exceeded', and an ability to queue an order to go find a place to get an overhaul and resupply. It would reduce the burning agony of dealing with survey ships by quite a lot.
I don't think you read my thing, I said 'maintenance life' not MSP quantity. I'd like an order to send them home for overhaul and resupply once they reach a certain percentage of their planned maintenance life. That tends to be a lot closer to the limit of the ship than trying to do it off of MSP, since the MSP thing tends to run out all at once near the end of said maint life.
(...)I second that but with an addition, that the amount of slipways is stored as a decimal. Then you could interrupt expanding a new slipway to retool the shipyard to a new class, and resume the expansion afterwards without loosing progress, similarly how you can do right now with continual capacity expansion.
2) New shipyard activity: "Add Multiple Slipways." Works like "Continual Capacity Upgrade": I give it a target number, and it keeps building slipways until I have that many.
Earth: Move to Location (-1.1 b km via jump LP1-LP2)
Not sure if this has been mentioned before, but I would love to see some kind of help list where you could go to find out information on what the various buildings, components and weapon systems are for, and what they do. This would greatly help new players. For instance, I have been playing this game for a few months now, and there are several weapons systems I have never used, because I simply don't have any idea what they are used for, or how they work, so I have just mainly been sticking to simple weapons such as lasers, railguns. It would just be nice to have some additional information to hand, in game.
I was pretty sure fleets actually accounted for orbital motion when planning out LP use.That is when planning a simple route. Templates, cycled orders, and repeated orders have problems.
Second, when you use the autoroute by system, it currently sorts systems alphabetically. This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list. I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this. So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?
Second, when you use the autoroute by system, it currently sorts systems alphabetically. This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list. I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this. So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?
The problem with renaming systems, including this method and using routing numbers, is that it breaks themes. Every new system will be given the first name in whichever theme you are using.Second, when you use the autoroute by system, it currently sorts systems alphabetically. This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list. I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this. So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?
Definitely this.
As a workaround that does what you're asking, rename them by putting a space in front of their name, they'll be in their own sort at the top of the list. i.e. "Sol" becomes " Sol". All the names with space will be above all the names without. When they get to be too numerous, and you have a couple really important colonies, add another space, al the names with two leading spaces will be above the names with only one leading space.
The problem with renaming systems, including this method and using routing numbers, is that it breaks themes. Every new system will be given the first name in whichever theme you are using.Second, when you use the autoroute by system, it currently sorts systems alphabetically. This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list. I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this. So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?
Definitely this.
As a workaround that does what you're asking, rename them by putting a space in front of their name, they'll be in their own sort at the top of the list. i.e. "Sol" becomes " Sol". All the names with space will be above all the names without. When they get to be too numerous, and you have a couple really important colonies, add another space, al the names with two leading spaces will be above the names with only one leading space.
A nice feature would be if i could set jump point construction ships to automatically stabilize Lagrange points like i could set the to automatically build nearest jump gate.
That would be a lot of Lagrange points, you can stabilize large-ish moons even (in fact its kindof critical for having fast routs out to distant gas giants).Reaching gas giants and secondary stars is why the Lagrange point system exists in the first place. Stabilizing an inner system body helps with that, but otherwise I can't think of any reason to ever stabilize an LP.
I feel like this must have been suggested before, but it would be nice if in the ship design menu, you had the same window as the 'select name' window from the shipyard screen. It would make it a lot easier to figure out what the different name themes have to offer.
Reaching gas giants and secondary stars is why the Lagrange point system exists in the first place. Stabilizing an inner system body helps with that, but otherwise I can't think of any reason to ever stabilize an LP.
I feel like this must have been suggested before, but it would be nice if in the ship design menu, you had the same window as the 'select name' window from the shipyard screen. It would make it a lot easier to figure out what the different name themes have to offer.
Sorry if I miss understanding what you are saying, but the same screen is available. Third button top row.
I feel like this must have been suggested before, but it would be nice if in the ship design menu, you had the same window as the 'select name' window from the shipyard screen. It would make it a lot easier to figure out what the different name themes have to offer.
Sorry if I miss understanding what you are saying, but the same screen is available. Third button top row.
Hmm, I mean with respect to the miscellaneous tab in the ship design window (actually called class design turns out) when you are picking the ship naming theme. I just checked and I cant find what you are referring to so I believe we are talking about different windows entirely.
Reading the latest AAR from Steve and I noticed that he said population growth on Earth is more or less keeping up with evacuation. Humans are pretty idiotic at times but I think maybe if the planet was gonna crash into the sun soon we might not be reproducing like rabbits in the meantime. Maybe add an option to remove or reduce population growth on bodies effected by a disaster?
Designing yet another combat jump-capable fleet I relaized that you are pretty much forced into roughly same sized ship for efficient utilizing of a jump drive potential and having all ships kinda equal size is kinda. . . boring.
So apparently I think there is an easy and rather consistent solution: instead of having Squadron Size as a number of ships, we could have it as a multiplier to tender tonnage with resulting number defining total jumping tonnage. Squadron Size 2 would mean that with a jump tender of tonnage X any number of ships with total tonnage of X can jump as squadron (so total of 2*X), Squadron Size 4 would mean that for tonnage X any number of ships up to totall tonnage 3*X can jump (so total of 4*X). So Squadron Size would define total sqadron tonnage including jump ship.
This way we can have some fancy RP-ish fleets with a jumping supercaptial/supercarrier and a fleet of escorts utilising the jump wormhole created by that supership, which I think would be very nice and more fun than just all 5k/10k/20k/30k ships to keep up with current tender mechanics.
Designing yet another combat jump-capable fleet I relaized that you are pretty much forced into roughly same sized ship for efficient utilizing of a jump drive potential and having all ships kinda equal size is kinda. . . boring.
So apparently I think there is an easy and rather consistent solution: instead of having Squadron Size as a number of ships, we could have it as a multiplier to tender tonnage with resulting number defining total jumping tonnage. Squadron Size 2 would mean that with a jump tender of tonnage X any number of ships with total tonnage of X can jump as squadron (so total of 2*X), Squadron Size 4 would mean that for tonnage X any number of ships up to totall tonnage 3*X can jump (so total of 4*X). So Squadron Size would define total sqadron tonnage including jump ship.
This way we can have some fancy RP-ish fleets with a jumping supercaptial/supercarrier and a fleet of escorts utilising the jump wormhole created by that supership, which I think would be very nice and more fun than just all 5k/10k/20k/30k ships to keep up with current tender mechanics.
I don't get the difference from the system we have in place now. I use 18.000t ship that has the Jump Drive and I can jump any ship from 0t to 18.000t, isn't that the same concept?
Designing yet another combat jump-capable fleet I relaized that you are pretty much forced into roughly same sized ship for efficient utilizing of a jump drive potential and having all ships kinda equal size is kinda. . . boring.
So apparently I think there is an easy and rather consistent solution: instead of having Squadron Size as a number of ships, we could have it as a multiplier to tender tonnage with resulting number defining total jumping tonnage. Squadron Size 2 would mean that with a jump tender of tonnage X any number of ships with total tonnage of X can jump as squadron (so total of 2*X), Squadron Size 4 would mean that for tonnage X any number of ships up to totall tonnage 3*X can jump (so total of 4*X). So Squadron Size would define total sqadron tonnage including jump ship.
This way we can have some fancy RP-ish fleets with a jumping supercaptial/supercarrier and a fleet of escorts utilising the jump wormhole created by that supership, which I think would be very nice and more fun than just all 5k/10k/20k/30k ships to keep up with current tender mechanics.
I don't get the difference from the system we have in place now. I use 18.000t ship that has the Jump Drive and I can jump any ship from 0t to 18.000t, isn't that the same concept?
No, what he is saying that with a squadron size 3, your 18000t jump tender would be able to jump any number of ships as long as the total tonnage of the squadron is under/equal to 54000t (18000t x 3) and no single ship in the squadron is above 18000t.
Right now with the way squadron jumping works, a squadron jump size of 3 means you can support up to 3 ships regardless of overall tonnage. So a 50k ton jump tender would be able to jump at most 3 ships even if they are tiny 2000t corvettes, Whereas with this new system that same tender would be able to jump 75 of those corvettes.
I think this change is inspired since it removes the end game squadron size cap of 12 and places that limit in the hand of the player with how they design their jump tenders.
1) Allow me to designate a current research project as the assignment of any new research labs. That way I don't get an interrupt for idle labs every time I build or import a lab.
New Standing Order. Rescue closest Life pod.
It would save a lot of manual effort if a lot of ships have been blown up and you want to rescue all the survivors
I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.
Expand on the Carried Items screen, currently it shows Ordenance and Cargo, have it include Parasites
This was in VB6 and is not in C# as I presume an oversight, you currently have to do multiplication to actually get the orders you want, this can be extremely annoying and forces me to instead just use civs for this to get precise quantities of stuff.
Would be great, I feel this should of been re added a while ago, thanks for reading steve if you are!
I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.
Added for v1.12
http://aurora2.pentarch.org/index.php?topic=11593.msg138666#msg138666
I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.
Added for v1.12
http://aurora2.pentarch.org/index.php?topic=11593.msg138666#msg138666
Thanks, this is really great... would it also be possible to make it so when a ship finish the overhaul during the conditional order it also try to resupply and refuel before it heads back out or at least a second overhaul conditional order that add those two. Otherwise you still will need to manually make sure that this happens... sure you can clear the order and you will get a notification of it, but this I think would be very appreciative by everyone and probably in your own games as well. ;)
I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.
Added for v1.12
http://aurora2.pentarch.org/index.php?topic=11593.msg138666#msg138666
Thanks, this is really great... would it also be possible to make it so when a ship finish the overhaul during the conditional order it also try to resupply and refuel before it heads back out or at least a second overhaul conditional order that add those two. Otherwise you still will need to manually make sure that this happens... sure you can clear the order and you will get a notification of it, but this I think would be very appreciative by everyone and probably in your own games as well. ;)
So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.
I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful. I personally wholeheartedly approve of this notion and felt the need to post it on the forums. Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain. I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.
In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.
Currently:
10% progress towards improved nuclear thermal
Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.
The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.
We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.
This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.
As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.
The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.
We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.
This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.
As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.
The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.
We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.
This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.
As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.
I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.
So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.
Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.
The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.
We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.
This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.
As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.
I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.
So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.
Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.
I think you could do this with the VB6 escort mechanics, without needing waypoints.
You would just create two empty escort fleets at the desired bearing and distance from the main fleet, and give your sensor craft orders to move back and forth between the two fleets.
In other words, an empty fleet can act just like a waypoint.
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.
The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.
We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.
This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.
As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.
I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.
So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.
Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.
I think you could do this with the VB6 escort mechanics, without needing waypoints.
You would just create two empty escort fleets at the desired bearing and distance from the main fleet, and give your sensor craft orders to move back and forth between the two fleets.
In other words, an empty fleet can act just like a waypoint.
Empty fleets can only move at 1km/s, watpoints also don't clutter the naval OOB, though that is a minor issue at best since there are ways around it.
So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.
I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful. I personally wholeheartedly approve of this notion and felt the need to post it on the forums. Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain. I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.
In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.
Currently:
10% progress towards improved nuclear thermal
Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines
It might sound good from a game-play perspective but not from a more realistic perspective. If a medieval society found a working computer they would never make anything out of it before they progressed through the technology to understand how it works. It is the same principle in the game. You can use the technology but you can't understand how it works unless you have a fundamental understanding of the technologies necessary.
I think it would suffice to say that it would be really nice to have an easy-to-use escort mechanic, without speculating as to how difficult it would be to implement.
Also:So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.
I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful. I personally wholeheartedly approve of this notion and felt the need to post it on the forums. Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain. I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.
In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.
Currently:
10% progress towards improved nuclear thermal
Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines
It might sound good from a game-play perspective but not from a more realistic perspective. If a medieval society found a working computer they would never make anything out of it before they progressed through the technology to understand how it works. It is the same principle in the game. You can use the technology but you can't understand how it works unless you have a fundamental understanding of the technologies necessary.
I don't agree, it seems to me that generally speaking (by default) the vast majority of components you try to disassemble will be within 100 years of whatever tech you have now (if not like 20 to 40 years) rather than centuries upon centuries (computers vs medieval tech level). It would be a reasonable approximation to assume that generally speaking your civilization knows what its looking at when it tries to disassemble a component, and the current mechanic is in my opinion far too harsh in its punishment of disassembling stuff that is more than one tech level past what you currently have.
I would like it if launchers became more space-efficient as their size increases. Larger missiles are not exactly in a good place right now considering how frightfully deadly point-defence is; missile ECM and sensors force a certain minimum size, but there's still a really strong incentive to downsize as far as possible.
Instead of linearly scaling launcher size with missile size, I was thinking :
Launcher Size (HS) = (Missile Size in MSP)^0.8 x (Launcher Size Modifier)
This would mean that a full-size launcher for a 2.5 ton missile would take up 50 tons, for a 10 ton missile it would be 152 tons instead of 200 tons, for a 20 ton missile it would be 264 tons instead of 400 tons, and for a max-sized 250 ton missile it would be 1,990 tons instead of 5,000 tons.
I selected 0.80 as the exponent to avoid max-sized box launchers being smaller than the missiles they hold, but the exact factor is negotiable.
- I agree more with seven of carina, large missiles already have an advantage in range over small missiles. They suffer mostly from throw weight, or rather their lack of it. However, I would think being able to add an additional to hit chance via a communications module would be nice. Better yet, have Thermal Reduction / Cloak work on missiles and bring back armored missiles. I also think armor should add HtK like turret armor does, but also add the % chance to not take damage while being unable to be added in amounts of less than 1 MSP. So no 1.5 or 0.5 MSP of armor.
- The main issue I can see with larger missiles, sans the issue of saturating enemy PD, is the lack of something to do with them. ECM/ECCM isn't very big, and neither are Active or Passive Sensors. Engines automatically use the best fuel consumption, so even range stops being a big deal after a certain level of tech. The other big issue is accuracy, there is no reason to make slow missiles... at all. Slow probes? Yes, but slow missiles? No.
- Seven of Carina's idea has in fact already been implemented by Steve to a point, larger launchers reload much, much faster than before. However, they do not yet scale their tonnage to capacity like Reactors and Shields now do, so big launchers are still ton for ton as efficient as smaller ones. Jorgen_CAB's idea would give big missiles something to do that small missiles can't. Even ECM/ECCM can be mounted comfortably in a Size 6 or 9 missile, while Active Sensors really don't matter much for ASMs.
- Giving the big ones the ability to load up on accuracy gives them more of a reason to exist, as the whole advantage of a biger missile woudl be more room to put stuff. Sol there needs to be stuff to make them better. I am more in favor of an Advanced FCS Module though, which is tied to sensors on the missile itself. Two such FCS Modules in fact, one for Active and one for Passive, with each FCS conferring a bonus based on it's type.
- The Active FCS would confer an accuracy bonus that would work identically to Missile Tracking Speed Bonus, the longer the missile is tracking the target the better the bonus. The Passive FCS would provide the same kind of bonus as the Active FCS, but would scale based on enemy EM/TH output versus the missile's ability to detect said output. So a really hot target would confer a much higher bonus regardless of the passive sensor strength of the missile, while a really good passive sensor suite on the missile would confer a high bonus despite the target being relatively "cold".
- When you combine those ideas with Cloak / Thermal Reduction and add back in armor, suddenly all kinds of new options exist for all the different missile sizes. Want slow, but accurate torpedoes for Commerce Raiding? Use a combination of Passive TH Sensors with Passive FCS and add Armor. Want a speedy shield buster? Big engines, Passive FCS and Passive EM Sensors. Want an ASM to cut through enemy PD? Size 8 with 75% Cloak to appears as a Size 6 and 1 layer of Armor to help deal with Meson / Gauss / Railguns. Want a super accurate mega missile of DOOM? Just cram a crap ton of Active Sensors, Passive Sensors and FCS, add ECM/ECCM, armor and so on and so forth.
- Under that model, missiles get deadlier as they get bigger, but they also get more expensive. Medium sized missiles become more useful, while Cloaked Missiles get more powerful as Cloaking Tech increases. At 50% Cloak, a Size 12 is as hard to see as a Size 6, but would cost more. A slow torpedo would benefit from the Thermal Reduction and the Passive FCS, while everything that is big enough to mount a credible Active Sensor would benefit greatly from an Active FCS. Armor would make big missiles even more viable, as by adding HtK suddenly Railguns and Gauss become less powerful against small salvos, while AMMs will need to be more powerful to compensate.
- Incidentally, Mesons should ignore missile armor's % chance to block incoming damage, and just deal HtK against any missiles they hit. Conversely, AMMs should suffer a flat reduction proportional to the number of layers, and then deal the rest to HtK. So the % chance to ignore damage only involves Non-Meson Beam PD and CIWS. As an aside, Missile Stages should have an option to "Deploy Sub munitions on..." and then two check boxes that read, "Launch" and "Sensor Contact" respectively. This would allow the player to designate something as a mine or a bus w/o the fiddly bits, while a lack of designation in this regard would allow booster stages, armored shells to carry them past Fighter PD, or to create buses for Orbital Bombs
Regarding agility...realistically, a missile's chance to BE HIT should scale with agility. The "issue" with agility is that it makes AMMs more efficient as technology improves (this is not necessarily a bad thing), since attack missiles can only make themselves safer by increasing speed while AMMs can make themselves more lethal via speed, agility (and smaller warheads, to a lesser extent). Making agility help attack missiles avoid AMMs would negate that mismatch.
On the topic of modifying how to-hit chances work, should smaller ships (and missiles, presumably) inherently be harder to hit? Again from a realism perspective, they would be...though if we want to bring realism into Aurora's accuracy mechanics the changes will be...drastic.
Agility based evasion is a bit weird from a missile on missile evasion perspective because it assumes that missiles somehow have the ability to decide to engage in evasive maneuvers. Understand that because of the small detection range of AMMs combined with the relatively large attack range of attack missiles means that missiles will somehow need to evade missile which they don't even know they exist. So such detection would require an onboard missile sensor, passive or active which in turn takes up a large part of the missiles real estate, kind of defeating the point of the exercise.
Mind you this is a realism argument, not a gameplay one. I think from that perspective the missile needs to know that the AMM exists for it to even be able to attempt evasive maneuvers.
Agility based evasion is a bit weird from a missile on missile evasion perspective because it assumes that missiles somehow have the ability to decide to engage in evasive maneuvers. Understand that because of the small detection range of AMMs combined with the relatively large attack range of attack missiles means that missiles will somehow need to evade missile which they don't even know they exist. So such detection would require an onboard missile sensor, passive or active which in turn takes up a large part of the missiles real estate, kind of defeating the point of the exercise.
Mind you this is a realism argument, not a gameplay one. I think from that perspective the missile needs to know that the AMM exists for it to even be able to attempt evasive maneuvers.
You could just say that the missiles flies erraticly to avoid being an easy target. And higher agility allows for better maneuvers/a better threat detection system while still staying on target.
Population Growth Modificator: I was thinking about creating a multi faction start on earth with one dummy "United Nations" which holds just most of the population of earth and then some playable nations holding the rest. It would be nice to be able to lower the pop growth value of this dummy nation.
Point of contention... IIRC the Hellfire can be used for multiple forms of attack, no? Top down or side on IIRC. That would need substantially more guidance than a typical missile. And what of the Maverick? It was TV Guided, and thus would need far less.
I don't think requiring guidance should be a thing simply on account of ships in Aurora already possessing M-FCS in proportion to the range and size of target. A rudimentary sensor and/or telemetry would probably be sufficient for a bare bones guidance under the model of Speed and Agility determining the accuracy. You can flash a lot of information to a relatively small storage device, and so long as the missile knows were it is, where it's been and how to use the information provided to it to get where you want it to be, that's enough.
I think there should be additional guidance systems, namely missile mounted FCS to take advantage of missile mounted sensors. I don't like forcing restrictions on the player, doubly so for restrictions which make no sense IRL and more so when all it does is penalize something. Don't nerf the strong, buff the weak... if the buffs don't balance it out then use nerfs. If that doesn't work... ya don goofed and need to pull the system apart and overhaul it.
Or ya would if balance was an issue. Buff the big missiles, as it stands there isn't much of anything they can do that small / medium sized ones can't do better, cheaper or both.
Most missiles do not communicate, they look at something that is painting the target, or they detect the target completely by their own means. Hence a guidance section usually on the front of the missile.
While true, that mainly has to do with the possibility of directing missiles against alternate targets, rather than enhancing their terminal guidance.
Can we get medal conditions based on ammount of researched projects?
I would love to give those for my best and most dedicated researchers. . .
Quote from: esavier link=topic=10640. msg138889#msg138889 date=1594984025Can we get medal conditions based on ammount of researched projects?
I would love to give those for my best and most dedicated researchers. . .
I am quite sure there are already for 1 and 5 respectively condition number 26 and 27. You can find the list under mechanics and changelist 1. 10
Conditional orders
Condition when deployment time equals x%.
Orders
Refuel and Resupply (This is in the movement orders but not the conditional).
Refuel, Resupply and Overhaul.
It would be really nice if banning a system from 'auto routing' meant that orders like 'refuel from hub(all)' and 'salvage nearest wreck' didnt cause ships to fly into that banned system, particularly when that system is gate camped and is massacring all of my survey ships.
It would be really nice if banning a system from 'auto routing' meant that orders like 'refuel from hub(all)' and 'salvage nearest wreck' didnt cause ships to fly into that banned system, particularly when that system is gate camped and is massacring all of my survey ships.
It feels somehow too quick a growth if one slows down everything else for a longer playtime, and then being overwhelmed by unemployed people do to too quick growth... .
An addition to civilian contracts: I tend to build small fleets of mineral harvesters that roam around to collect TN Minerals from the small planetoids etc. where a mining facility would be a waste of resources. So I was thinking: why not opening that up to the civilians? It should be possible to write out contracts for civilian mineral harvesting. Once a company accepts that they will mine that planet to the last gram of mineral and transport them to the planet where you ordered that contract from.
Automines would lose their "need".
Well not really, civilian orbital mining would be constrained by the orbital mining size tech so larger bodies would still need it.I would definitely want to manage my bigger sources on my own. I mean, those civilians do cost a LOT... lol... ;-)
I guess you could extend the civilian mining operation feature and allow the player to fund civilian mines with immense wealth.
That's already been implemented via Rescue Shuttles. Also, the deliberate allocation of superfluous Spare Berths has been removed from C#, a feature I would sorely like back...
Thus, Ship A and Ship B will seldom if ever have enough spare room to store survivors. Instead, Cryo Berths are used for that purpose. Which kinda sucks... since it would be nice if we could integrated rescued crew, or daresay even commanders, into ships that had suffered casualties.
Also, being able to build out some extra Crew Quarters to stave off Life Support failure on account of battle damaged Crew Quarters would be nice. :)
Byzantium class Pinnace 6'935 tons 79 Crew 1'027.6 BP TCS 139 TH 330 EM 0
4758 km/s Armour 6-32 Shields 0-0 HTK 33 Sensors 32/32/0/0 DCR 4 PPV 0
Maint Life 17.54 Years MSP 8'370 AFR 96% IFR 1.3% 1YR 51 5YR 771 Max Repair 136.125 MSP
Troop Capacity 1'000 tons Boarding Capable Cryogenic Berths 1'000 Cargo Shuttle Multiplier 5
Lieutenant Commander Control Rating 1 BRG
Intended Deployment Time: 96 months Morale Check Required
MD SCAM S0750 E0330 x055-025 TR50 (2) Power 660 Fuel Use 4.58% Signature 165.0 Explosion 5%
Fuel Capacity 150'000 Litres Range 85 billion km (206 days at full power)
ASS-60-32 E4 R0050 S0050 = 0024M (1) GPS 60 Range 24.7m km MCR 2.2m km Resolution 1
ASS-60-32 E4 R5000 S0050 = 0114M (1) GPS 6000 Range 114.7m km Resolution 100
TH-32 E5 S0050 [4/14/44] (1) Sensitivity 32 Detect Sig Strength 1000: 44.7m km
EM-32 E5 S0050 [4/14/44] (1) Sensitivity 32 Detect Sig Strength 1000: 44.7m km
This design is classed as a Military Vessel for maintenance purposes
now having 8 ships of that class in my temporary hospital fleet, i rescued around ~4000 survivors, but those are split between first two ships in the fleet. having them overcrowded while there is still spare space on another ships.Maybe there's already a way to do this and I'm just missing it, but I would love a way to create a research project straight from a prototype.
* there should be possibility to allow player to check what event to pause on
* Ships containing diplomacy module should be exemp from penalties of being in restricted system, (diplomacy module should be able to stay in restricted sysyem)
NPRs deduct 10,000 tons from the tonnage of one Diplomatic Ship (see Part 8) per system for threat purposes if that class type has never fired weapons and the Diplomatic Ship is in a non-Core system. If the NPR only has one system, it is not treated as core for this purpose.
I'm loving the new prototypes feature, but I think it could be even better. I'd like to be able to create research projects for parts I don't have the tech for. Currently, if you make a prototype using tech you don't have, like a twin gauss turret when you haven't researched the gun yet or an engine with fuel use 0.5 when you're only at 0.6, the part has (FP) next to it in the class design window, and the button to make a research project from it is hidden. Even when you finish the necessary techs, that button never reappears.
Follow-up: Let us issue custom conditional orders. We already have order templates, let us hook them up to conditions.I am not entirely sure as now conditional orders have been made for the players and on player request as well, however the main function of the conditional orders were to make AI fleets to work including civilians. I am not sure a custom set of conditional orders would be either possible or anywhere simple to code.
How performance taxing would it be to update all open windows after each turn?
I feel like I'm spending quite a lot of clicks refreshing or closing and opening the same windows all the time.
How performance taxing would it be to update all open windows after each turn?But at least for now, every window can be updated by reselecting your empire in the drop down menu which is probably slightly faster than closing and opening it.
I feel like I'm spending quite a lot of clicks refreshing or closing and opening the same windows all the time.
I think that it would be great if we could turn different sensors types on and off individually on ships. For example there is little to no reason to put large resolution actives on ships as they will reveal your position as soon as you turn them on. Lower resolution scanners on the other hand like 1-10 in resolution is more effective as the type of craft they tries to find usually struggle to have passive good enough to detect them before they are themselves detected by the active sensors so there can be a reason to use them and not large resolution scanners that will guarantee to reveal you long before you detect anything with that active sensor.
In addition to this I might also think it is time for an upgrade to how hangars work too... it simply is too easy to deploy just about anything with hangars and rely on them for just about anything. In my opinion hangars simply is too powerful and basically is more like a modular compartment than an actual hangar. It is too easy to use them as a compartment to hold modular vessels, sensor options, weapons and everything is perfectly interchangeable with any size, type and configurations. We have advances and rather intricate mechanics for fuel, supplies and ordnance but hangar operations and types are quite free, too dynamic and effective.
hangars should simply be a module where you add certain abilities such as max docking size, launch/recovery capability, ability to reload ordnance, maintenance of weapon versus say sensor system. It should be much cheaper and less space requirement to have say two bays that accommodate two 500t survey shuttles or four 300t recovery shuttles or servicing 20 300t missile fighter-bombers that need a whole different types of maintenance, space for quick reloading of ordnance and fuel as well as rapid launch and recovery facilities. There could be a difference between serviceable and storage capacity and the ability to operate offensive fighters. A ship might even have several separate hangar facilities that can do different things.
I don't think this has to be very complex, just that different things should have different costs and take up different amounts of space too accommodate. Launching and recovering crafts should no more complex than it is to refuel or rearm a ship in space.
I think that it would be great if we could turn different sensors types on and off individually on ships. For example there is little to no reason to put large resolution actives on ships as they will reveal your position as soon as you turn them on. Lower resolution scanners on the other hand like 1-10 in resolution is more effective as the type of craft they tries to find usually struggle to have passive good enough to detect them before they are themselves detected by the active sensors so there can be a reason to use them and not large resolution scanners that will guarantee to reveal you long before you detect anything with that active sensor.
In addition to this I might also think it is time for an upgrade to how hangars work too... it simply is too easy to deploy just about anything with hangars and rely on them for just about anything. In my opinion hangars simply is too powerful and basically is more like a modular compartment than an actual hangar. It is too easy to use them as a compartment to hold modular vessels, sensor options, weapons and everything is perfectly interchangeable with any size, type and configurations. We have advances and rather intricate mechanics for fuel, supplies and ordnance but hangar operations and types are quite free, too dynamic and effective.
hangars should simply be a module where you add certain abilities such as max docking size, launch/recovery capability, ability to reload ordnance, maintenance of weapon versus say sensor system. It should be much cheaper and less space requirement to have say two bays that accommodate two 500t survey shuttles or four 300t recovery shuttles or servicing 20 300t missile fighter-bombers that need a whole different types of maintenance, space for quick reloading of ordnance and fuel as well as rapid launch and recovery facilities. There could be a difference between serviceable and storage capacity and the ability to operate offensive fighters. A ship might even have several separate hangar facilities that can do different things.
I don't think this has to be very complex, just that different things should have different costs and take up different amounts of space too accommodate. Launching and recovering crafts should no more complex than it is to refuel or rearm a ship in space.
About the Hangars, I was thinking something too. I think that they should work more like launchers and pods and or have a launcher and a tonnage similar to what you said.
So for instance you would design your Hangar for storage of units and then a launcher/door able to fit only a specific displacement or less.
You will end up with 12000 ton hangar and laucher/door for 1000 ton displacement.
But I think will really be hard...either to code and manage.
Regarding hangars, haven't we had this exact same discussion (or something similar) before? See here (http://aurora2.pentarch.org/index.php?topic=10387.0). IIRC, Steve wasn't too keen on the idea.
Commanders can be assigned as an Academy Commandant on any population with at least one military academy. Any type of commander can be assigned with the following restrictions:Any chance of changing that to a different system, perhaps allowing the top naval rank to command any number of academies?
1) A civilian administrator must have an Admin Rating equal or greater than the number of military academies at the population
2) A scientist must have a Research Administration rating (new bonus for C# which is the max number of labs) at least five times the number of military academies at the population
3) A naval or ground forces officer must have a rank (with 1 being the lowest rank) at least equal to the number of military academies
You can set the color of events by type in the event window.I know. I am talking about the date/timestamp at the beggining of increment log which can't be modified/coloured the same way events can.
You can set the color of events by type in the event window.I know. I am talking about the date/timestamp at the beggining of increment log which can't be modified/coloured the same way events can.
I suppose if you modify the color of all the event types, then the timestamp will be the only one left as the default.I actually tried something similar and while it's still better than nothing, I still often managed to miss a timestamp, due to it being inconspicuous while everything else was visually just screaming for attention. :)
That might suit your purposes for the time being, but I agree that in cases like these (dozens or hundreds of events in a single increment) it would be nice to have a way to quickly jump to the beginning of an increment, or to the previous increment.
Suggestion: On the tactical map, don't keep focus on the system selection dropdown. It's very annoying to pick a system, then scroll thinking you're going to zoom in or out, but it actually scrolls through the system list.
Suggestion: On the tactical map, don't keep focus on the system selection dropdown. It's very annoying to pick a system, then scroll thinking you're going to zoom in or out, but it actually scrolls through the system list.
Right clicking a location on the tactical map displays a selection list of colonies and fleets near the location.
In many cases, the list includes a large number of civilian ships, which makes it difficult to select the fleet I am interested in.
I never actually want to select a civilian ship, but I can imagine that there are occasions when it might be useful (especially if it actually worked correctly--currently, if you select a civilian ship, the Naval Organization window opens but it does not have a fleet selected).
Suggestion:
In the selection list that appears when right clicking a location on the tactical map, don't list civilian ships.
Instead, if civilian ships are present, add a "Civilian ->" item at the top of the list. If that item is clicked, display the list of civilian ships (to the side of the original list).
Suggestion: An option in the Galaxy Map to see the distance in LY between systems, similar to the current in-game distance.
I'm having four tankers of the same type, three ran out of fuel, one hasn't. There's no way for me that I can see to make them equalize/share their fuel.
I'm having four tankers of the same type, three ran out of fuel, one hasn't. There's no way for me that I can see to make them equalize/share their fuel.
I am playing with fighter based operations lately and one of the things I would really like to see at some point in the future is some kind of countermeasure system for light crafts.
The main reason I suggest this is the extreme vulnerability of fighters to AMM. Don't get me wrong, AMM should be a deadly threat to fighters, but at the moment they are basically certain death even in modest quantities. Even missiles designed to kill capital ships are fairly effective at killing fighters which I think is a bit counter intuitive. One can design crafts to stay out of missile/sensor range, and indeed that is kind of the only real build that work against a sizeable force for strike fighters.
The way I would imagine it is basically a personal range only amm that use lightweight ammo. The System itself is a comparable to a mini size 1 launcher. The amount of countermeasure launcher would determine how many evade attempts can be made per salvo increments(probably more than 5sec at start depending on tech level). The system can only be mounted on fighters(500 ton and <) since it rely on maneuverability and sensor overload. Technically it would be cool to separate the countermeasure in chaff/flares and the likes, but I fear this would make it quite a bit of a management hell, not to mention much harder to implement. I would just assume the countermeasure are designed to deal with thermal/grav/EM guidances at the same time.
The countermeasure launch would be automatic when the closest targeting missile get within a certain configurable range. The countermeasure affect all missiles currently targeting the craft within a range defined by tech level(about 200 k I would say at low tech level). At that point a roll is made and the affected missiles have a certain % chance to get misdirected, effectively destroying it. To keep it simple I would use a flat % dependent on tech(50%, 60%, 70% or something to that effect).
I am thinking fighters could carry 5 countermeasure per dedicated storage ton, but that might be too much. Keep in mind the system can launch multiples countermeasure per increment with more than one launcher, making more evade rolls. The countermeasure are replenished with MSP when landed at a carrier(not from on board MSP).
For an example scenario, a fighter is currently targeted by 20 missiles from 4 different waves of 5 each. The closest wave is within the configured 50k countermeasure activation range, causing the fighter to automatically launch a salvo. The second wave is within the 200k max effect range so it will also be affected, but the 3rd and 4th waves are out of range so entirely unaffected. The fighter has 2 launcher with a flat 60% chance to misdirect. So for each of the 10 affected missiles 2 rolls are made and any successful roll will (effectively)destroy the missile. Surviving missiles will then continue on their way or try and hit if they would reach this increment.
So with a squadron equipped with this system, there is now a meaningful choice when a wave of missiles show up on scanner. You can push on into firing range or try and get out of reach. You will still probably lose the squad if you ventured too far but this get you a fighting chance.
I realize that fighters are already strong, but this would exchange firepower for some measure of protection. The "strong" fighter design in the current version never get into missile range anyway, this would make a larger array of fighter roles viable.
Thanks for listening to my TED talk.
I am sure this has been suggested prior, but an autosave feature. Maybe every thirty days, it triggers the save routine.
Second suggestion for beam FC. As standard up to their size and range. From range to 2x range, hit chances are 50%, 2x to 4x range, hit chances are 25%. 4x to 10x, hit chances are 10%. Maybe 10x to weapon max range the hit chances are 1%.
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.
As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.
Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.
This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.
Right now proper PD area defence on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.
As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.
Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.
This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.
Right now proper PD area defence on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).
In 1.12 you will be able to easily deploy escorts, you can easily deploy several small fighter scouts to extend your AMM detection bubble quite far out... then you can definitely design some long range AMM and engage at a much further distance.
Not saying your suggestion is a bad one, just saying it will be allot easier to pull of in 1.12 when that is released.
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.
As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.
Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.
This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.
Right now proper PD area defence on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).
In 1.12 you will be able to easily deploy escorts, you can easily deploy several small fighter scouts to extend your AMM detection bubble quite far out... then you can definitely design some long range AMM and engage at a much further distance.
Not saying your suggestion is a bad one, just saying it will be allot easier to pull of in 1.12 when that is released.
For detection this has always been possible - the issue is not detection its FC target aquisition. Those fighters can see the missiles but they cannot provide terminal guidance with their own MFCs. Normally this is not an issue as MFC ranges are quite high however with AMMs the target lock range for size 6 and smaller missiles can be somewhat restrictive. At least for the purposes of providing area defense with AMMs which is their main appeal.
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.
As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.
Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.
This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.
Right now proper PD area defence on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).
In 1.12 you will be able to easily deploy escorts, you can easily deploy several small fighter scouts to extend your AMM detection bubble quite far out... then you can definitely design some long range AMM and engage at a much further distance.
Not saying your suggestion is a bad one, just saying it will be allot easier to pull of in 1.12 when that is released.
For detection this has always been possible - the issue is not detection its FC target aquisition. Those fighters can see the missiles but they cannot provide terminal guidance with their own MFCs. Normally this is not an issue as MFC ranges are quite high however with AMMs the target lock range for size 6 and smaller missiles can be somewhat restrictive. At least for the purposes of providing area defense with AMMs which is their main appeal.
I understood what you meant... but it is not that difficult to build a bigger fire-control to guide the missiles at distances that is reasonable to engage missiles with AMM without sacrificing too much accuracy of the AMM.
I don't think it is a bad idea either... I just think it might have other unwanted side effects that has nothing to do with AMM.
I am thinking about including a deeper exchange system for technology - not necessarily the tech itself but rather selling or leasing ships, fighters, etc. In our world are some countries who build high tech weaponry and others who don’t. Those usually bye them from the high tech countries. And the low tech countries usually can’t afford the research - which is no hindrance in Aurora at all. The cost for a research facility is quite low. So one starting point for this could be a two step change:
A) building cost for a research center could be a lot higher; maybe also adding a kind of maintenance system for buildings in general... . Which would increase the overall costs to maintain being a high tech country.
B) A new research path that starts with a way lower research output for research facilities - so if you want to become a high tech power, you have to do quite an amount of research first to even get there. Included in this would be a starting option to start as a low tech or high tech nation - latter having already done that process and start on what is the current level of research in Aurora.
So as a low tech country you can choose to bye your ships and fighters, or you can invest into research and become one yourself later. Which gives you more options to specialize your nations industry. You could become a money power house but bad in research - or become a research giant and be dependent upon weapon sales to keep your country going... .
It would be nice if racial weapon and armor bonuses for ground troops were applied when the troops were being constructed instead of being designed. Or for more complexity and fine tuning allow us to re-research ground units so the design is updated with the most recent armor and weapons tech. Having to remake ground forces is a chore and in the early tech levels, you almost dont want to build them because you're going to blow passed the tech level quickly :) Love the game
Suggestion: Damage that propagates. I've been watching a lot of Rule the Waves and Ultimate Admiral: Dreadnoughts content and fire and flooding make damage control much more interesting. Maybe we could have something similar.
Also Jump Engines only ever show their rating in Tons not in HS, regardless of the checkbox about tons.
I know Steve isn't to keen on implementing features that don't add too much gameplay... I was wondering though if we could talk about ideas to get population and planetary management a bit more into the direction of having more details and interaction happening. For example that happiness and political support for what you are doing is interconnected with what you are doing and that is interconnected to the political system you are running your empire with. A democracy for example should make its citizens more unhappy if they start a war (yes, I know, totally unrealistic, but you know... ) etc.
Any ideas welcome that really add gameplay mechanics...
How to implement tho? In a democracy the military is not responsible for civilian happiness or the civilian economy, it's responsible for protecting civilian and state assets, if I was Steve I'd prolly go with implementing a system reversing the economic interaction, have the player piggyback on an NPR. Potentially complex but creating an impetus to flesh out AI/NPR's
How to implement tho? In a democracy the military is not responsible for civilian happiness or the civilian economy, it's responsible for protecting civilian and state assets, if I was Steve I'd prolly go with implementing a system reversing the economic interaction, have the player piggyback on an NPR. Potentially complex but creating an impetus to flesh out AI/NPR's
This obviously is correct... Aurora though is built in such a way that we are suppose to role-play this interaction of civilian and state assets. If you role-play a democratic society then the "state" assets is the part of the economy that you the "player" have access to and can distribute based on role-play of those resources. They don't have to be viewed as "state" owned resources entirely.
I know that allot of people, especially lately as the game have received more attention, play it like just another game that you are suppose to beat or compete with NPRs. Aurora has never really been intended to be that kind of game... it is purely meant to be about building a story and part of that is often to do things that might often not be mathematically optimal. Life rarely are about making the most mathematically optimal choices, that would be a boring life to live.
Anyway... the game are intentionally open so we can use role-play to set these restrictions on whatever empire type we are playing. Therefore any changes that Steve does usually have to be considered in respect to that concept.
How to implement tho? In a democracy the military is not responsible for civilian happiness or the civilian economy, it's responsible for protecting civilian and state assets, if I was Steve I'd prolly go with implementing a system reversing the economic interaction, have the player piggyback on an NPR. Potentially complex but creating an impetus to flesh out AI/NPR's
This obviously is correct... Aurora though is built in such a way that we are suppose to role-play this interaction of civilian and state assets. If you role-play a democratic society then the "state" assets is the part of the economy that you the "player" have access to and can distribute based on role-play of those resources. They don't have to be viewed as "state" owned resources entirely.
I know that allot of people, especially lately as the game have received more attention, play it like just another game that you are suppose to beat or compete with NPRs. Aurora has never really been intended to be that kind of game... it is purely meant to be about building a story and part of that is often to do things that might often not be mathematically optimal. Life rarely are about making the most mathematically optimal choices, that would be a boring life to live.
Anyway... the game are intentionally open so we can use role-play to set these restrictions on whatever empire type we are playing. Therefore any changes that Steve does usually have to be considered in respect to that concept.
Of course, I am there responding to a hypothetical.
Suggestion: Make passive sensor contacts less informative, and thus more realistic. How can I know what class of ship I'm looking at just from how much heat it's radiating? I mean, a long-range tanker running low-power high efficiency engines might have a thermal signature of 200. Meanwhile a tiny fighter running very boosted engines might also have a thermal signature of 200.
Ideally I'd think we'd need an active sensor contact on a ship to tell what class it is. Maybe even that should take time.
I wonder if ground units should have to be equipped with 'suppression' or 'peace-keeping' equipment/training in order to reduce unrest on planets. An army isn't trained to police civilians, you should have to have special police units for that.
I wonder if ground units should have to be equipped with 'suppression' or 'peace-keeping' equipment/training in order to reduce unrest on planets. An army isn't trained to police civilians, you should have to have special police units for that.
I like this idea! And maybe a Miltia Unit too! :D
How about a conditional order that tells the geo/grav ships to survey an unsurveyed system. I`m getting sick of doing this manually.
If there is already a way to do this I`ll feel pretty stupid.
Quote from: Theoatmeal2 link=topic=10640. msg141110#msg141110 date=1601011556How about a conditional order that tells the geo/grav ships to survey an unsurveyed system. I`m getting sick of doing this manually.
If there is already a way to do this I`ll feel pretty stupid.
It depends how your geo/grav ships are designed to operate, the order system allows flexibility.
Don't have the orders to look at so phrasing is off.
Standing, not conditional: Survey next 5 system bodies(geo) & Survey next 3 system locations(grav)
&
'Move to system requiring geosurvey/gravsurvey
with conditionals for fuel/msp/enemies
If you don't see those, check version?
The selection favors single role, long range, jump drive equipped survey craft for hands off.
Couple suggestions to make managing training fleets a bit easier.
First, movement order "Shore Leave". Orders a fleet to a planet to perform shore leave, and temporarily blocks standing orders and training until shore leave is completed. (Naturally manually canceling the shore leave and ordering the fleet
Second. Conditional order and reaction, "Max Deployment Reached", and move to nearest recreational location and shore leave.
Basically these 2 are to make training divisions a little less manual (as one has to very often shift fleets around in commands to give training ships shore leave... and it gets a touch micromanagey after a while)
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation. Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation. Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation. Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.In order to work like I think you want it you would have to break the requirement for HQ's to be in the same location as the ground units in order to provide a bonus.
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation. Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.In order to work like I think you want it you would have to break the requirement for HQ's to be in the same location as the ground units in order to provide a bonus.
And if that's the case, why not have Eisenhower back on earth instead?
What makes you think anywhere is 100's of km away from defenders? I mean sure if you're dropping on some listening post or frontier mining colony, but not if you're dropping on a homeworld. To continue the D-Day analogy, the entire planet will be behind the Atlantic Wall.Earth has 148 million square kilometres of land, a space assault is not landing like the marines at Normandy, it is like the gliders landing in the middle of a French farmers field except you aren't limited to light infantry and light equipment, you have navigation systems so that you don't get lost and your transports are 100% re-usable.
Conversely also probably will have a pretty good idea of where you are landing so they might not have much issue contesting your attempted landing.In the scenario where one side has control over space and the other side has control over ground, it seems to me that the space side can fairly easily target anything moving on the surface or flying in the air. Things which are dug in are harder to pinpoint and destroy.
Make Ground Unit Construction Facilities work more like regular construction facilities. They generate a set number of construction points every year that get invested into ground units. It doesn't make sense that a company takes up as many GUCFs as a brigade.
Suggestion: make it less micro-intensive to load huge formations into troop transports. I am currently trying to load a whole corps into troop transports. The corps has 4 brigades. Each brigade has 3 divisions. Each division has 4 battalions. For each one I have to click "Load Ground Formation", then the formation I want to load, then add move. So that's 3 clicks per formation. And the formation list is too long to fit in the list, so for about 3/4 of them, I have to scroll as well. Worse yet, the formations don't all fit in the order queue, so it's very easy to lose track while I'm doing it. There's also a gameplay problem; I have 14 transports, but I believe they only load one ground formation at a time. My transports can hold 25000 tons, but I think the whole fleet waits while one transport loads one 5000 ton battalion at a time.
I propose two possible solutions.
- 1: Make it like cargo fleets. Fleets of freighters just all fill up somewhat intelligently. Why can't cargo ships do that? When issued to a fleet of mixed size, make them load the big units first, so you don't get a situation where a transport with 25000 ton capability picks up a 1000 ton boarding party that was actually meant for the boarding shuttle, and now it doesn't have room for the 25000 division. Combine this with the ability to shift-click orders to issue them all at once to make it pretty much perfect.
- Include transports in the formation window, and let us move formations with drag and drop, just like moving them from one population to another.
EDIT: I just found the "Load subordinates" checkbox. I'd still like to see transports in the formation window, but it's no biggie.
Make Ground Unit Construction Facilities work more like regular construction facilities. They generate a set number of construction points every year that get invested into ground units. It doesn't make sense that a company takes up as many GUCFs as a brigade.
+1, making ground facilities act like normal industry also means that on the UI they can be placed as a tab in the industrial construction menu. The tech already makes it so that each GUCF contributes a certain amount per cycle much like construction/ordnance/fighter factories. It would make the system much more consistent.
The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.
The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.
You do not fully lose this ability with the normal construction process thanks to you being able to adjust production %. You could potentially be building 100 divisions in parallel with this. Granted with the current system you could potentially go more than that but I don't know how many people go over that.
The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.
You do not fully lose this ability with the normal construction process thanks to you being able to adjust production %. You could potentially be building 100 divisions in parallel with this. Granted with the current system you could potentially go more than that but I don't know how many people go over that.
You kinda do as they all operate at 100% while with your suggestion they do not.
The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.
You do not fully lose this ability with the normal construction process thanks to you being able to adjust production %. You could potentially be building 100 divisions in parallel with this. Granted with the current system you could potentially go more than that but I don't know how many people go over that.
You kinda do as they all operate at 100% while with your suggestion they do not.
You forget that with ground force facilities each unit can be produced at the max rate of 1 facility whereas in the construction menu the industrial capacity is aggregate.
1% of 200 facilities is still going to produce each of those 100 formations at double the rate that 1 facility at 100% will.
Is this the thread to add suggestions that are small enough not to warrant their own post or will it likely not get looked at here?This is the right thread and that is an excellent suggestion.
Either way; it would be great if the diplomacy screen told you what an NPR had last broadcast as the proection status of their system as well as what you have set it to for them. Unless I am missing something obvious I can only see this by searching through the events log. Not huge deal, but would be a small QOL improvement and make the diplomacy screen more dynamic.
Is this the thread to add suggestions that are small enough not to warrant their own post or will it likely not get looked at here?
Either way; it would be great if the diplomacy screen told you what an NPR had last broadcast as the proection status of their system as well as what you have set it to for them. Unless I am missing something obvious I can only see this by searching through the events log. Not huge deal, but would be a small QOL improvement and make the diplomacy screen more dynamic.
Can multiple NPRs of the same race spawn on the same planet? If you were just playing a normal game and exploring the galaxy, would you be able to find the equivalent of insect USA and insect USSR on some swamp planet, orbiting a red dwarf and flying round in space pretending to be from somebodies cold-war-in-space fiction?
If not, that would be really awesome. You could even have more than two factions, you could spawn 4 or 5, with alliances and enemies, so if two factions go to war, others might join in to help friends, or to even out the balance of power to ensure no power bloc wins and becomes too powerful.
Imagine how cool it would be if you were playing a multi faction game on Earth and you run into an NPR with multiple factions. Some Earth factions have similar RP-ed ideologies and want to try team up with certain NPR factions, so other player factions start to panic at this one player faction allying with an NPR and growing too powerful, so they try make alliances or launch a preemptive strike, which brings in some of the previously neutral NPR factions looking for some improvement to their lot on the galactic stage. If the NPR and the player factions all had several colonies that were quite spread out and lots of fleets, it could get quite messy. :)
The galactic map has a checkbox under display that says "security status". I have no idea if this does what you wan't and I've never used it myself but its the closest thing that might work.
Can multiple NPRs of the same race spawn on the same planet? If you were just playing a normal game and exploring the galaxy, would you be able to find the equivalent of insect USA and insect USSR on some swamp planet, orbiting a red dwarf and flying round in space pretending to be from somebodies cold-war-in-space fiction?
If not, that would be really awesome. You could even have more than two factions, you could spawn 4 or 5, with alliances and enemies, so if two factions go to war, others might join in to help friends, or to even out the balance of power to ensure no power bloc wins and becomes too powerful.
Imagine how cool it would be if you were playing a multi faction game on Earth and you run into an NPR with multiple factions. Some Earth factions have similar RP-ed ideologies and want to try team up with certain NPR factions, so other player factions start to panic at this one player faction allying with an NPR and growing too powerful, so they try make alliances or launch a preemptive strike, which brings in some of the previously neutral NPR factions looking for some improvement to their lot on the galactic stage. If the NPR and the player factions all had several colonies that were quite spread out and lots of fleets, it could get quite messy. :)
You can load entire formations by loading "HQ and all subordinate units" which helps a lot.
a order for troop transports load all troops would be nice :)
yes i know but it would be nice to load a xeno and constrution units in one go
The ability to "Mute" certain interrupts, either for a certain amount of turns, game time or RL time. I am currently facing interrupts of: "Enemy forces on [Location] have been defeated but the population refuses to surrender." every production cycle and it is very annoying.
yes i know but it would be nice to load a xeno and constrution units in one go
Organize all your xeno and construction formations under a superior formation then use the checkbox to load all of them.
Just checking I understand correctly. Making formation templates that are just an HQ with enough capacity to cover a set ammount of subordinate formations is standard procedure? I.e. a regiment HQ with capacity 5000 to command 5 small brigades of size 1000. These subordinate formations can still benefit from having their own HQ embedded so they can have a junior commanding officer lower in the order of battle heirarchy?
Just checking I understand correctly. Making formation templates that are just an HQ with enough capacity to cover a set ammount of subordinate formations is standard procedure? I.e. a regiment HQ with capacity 5000 to command 5 small brigades of size 1000. These subordinate formations can still benefit from having their own HQ embedded so they can have a junior commanding officer lower in the order of battle heirarchy?
Exactly, so you have lets say your colonel commanding the regiment itself and then in the HQs inside each brigade you have a major in command. That way your fighting formations in addition to getting the full bonuses of their commanding Majors will get a fraction of the bonuses of their colonel stacked on top of that.
I noticed one of my ground officers was assigned to a unit I did not produce. It appears to actually be a ground unit owned by one of my civilian mining companies. Presumably the unit is stationed on the mining comet as some base security. However, I cannot see or have any access of this unit (as far as I can tell) outside of this indirect confirmation through my officers.
It would be nice if civilian ground units were listed in the formation menu, as civilian ships are.
Auto assign for admin command would be great, as well
I'm going to repeat one of my older suggestions:Seconded.
The ability to create hierarchy templates for ground construction so that if I make a very detailed OOB for a single division I don't have to take the time every time I want to expand my army.
I ask because I like to make my hierarchy go down to company level and it takes a long time to form a divisional hierarchy even if you know what you are doing.
This has probably been suggested in some form earlier but to help alleviate the RSI of weapon assignment:
---
1) In the firecontrol panel, group identical weapon types assigned to the same firecontrol group together under a subheading.
2) Let this group be collapsible so it can be hidden way.
3) Let use use this group as a mass-assign function, by letting anything done to the group be done to the weapons within that group.
---
There are many, many benefits to this:
Got 30 launchers? No problem! Drag the group heading to the firecon, now all 30 are assigned to that firecon. Drag that missile to the group and now all 30 are loaded with that missile!
Got 30 single 10% gauss turrets on that 40kton battleship? Well they're all on your PD firecon with a single drag and drop now!
Got two launchers sitting beneath that stack of 30 other launchers? Collapse that stack and now you can assign the lower ones without needing to open a second fleet screen!
Finally, no more relying on autoassign to assign large numbers of weapons and hoping against hope that it knows what you want amongst all your mixed weapon types, because if it doesn't you're in for a loooong day of drag and dropping...
I'd kindof prefer if ground training just worked like factories and you could have multiple facilities working the same job.
I'd kindof prefer if ground training just worked like factories and you could have multiple facilities working the same job.
Could we please get another conditional order slot, or a "refuel and ressuply" order? There's already a "refuel, resupply and overhaul" order but it doesn't work, being able to refuel/resupply at different moments through either a third slot or a specific conditional order would be so, so very useful.
Could we please get another conditional order slot, or a "refuel and ressuply" order? There's already a "refuel, resupply and overhaul" order but it doesn't work, being able to refuel/resupply at different moments through either a third slot or a specific conditional order would be so, so very useful.
Massive UI work. It is easier to get the error fixed. I have personally found a workaround (although the error still triggers) to keep all ships going without managing them.
I am sure Steve that is playing the game have either fixed it or about to do it.
Could we please get another conditional order slot, or a "refuel and ressuply" order? There's already a "refuel, resupply and overhaul" order but it doesn't work, being able to refuel/resupply at different moments through either a third slot or a specific conditional order would be so, so very useful.
Massive UI work. It is easier to get the error fixed. I have personally found a workaround (although the error still triggers) to keep all ships going without managing them.
I am sure Steve that is playing the game have either fixed it or about to do it.
What workaround?
A small quality of Life point. It would be great if the system tracked which names have been used in any naming convention list such that if you want to use the same naming convention such as RN Destroyers across a range of designs or on subsequent updates to designs then the suggested name recognises this rather than going back to the start of the list.Does it...not already do this?
Similarly if you have ships destroyed making the names available again would be great.
The conditional order Fuel less than 50% (my standard), Refuel Resupply and Overhaul at Colony it doesn't trigger any error, so I just use this in combination with the Deployment exceeded. So ship will overhaul only at deployment exceeded but not refuel running the full process when running out of Fuel.
You'll get the function error but that's all. I am honestly not looking after my exploration at all currently unless something shows up on radar.
Sure sometimes I still like to jump in, be careful etc, but when you have 50 plus ships exploring and surveying you could become tired of the process quite fast.
It would be nice if officers that are not the best qualified for a slot still get put into a slot rather than sitting around picking their orifices, i.e. an officer of sufficient rank, but no skills is left unassigned when there are available slots. He should be put into one.
As an adjunct to that, let the officers get some OJT. If they are in a slot with no skill relative to that job, eventually they will learn something about it. Hopefully.
The conditional order Fuel less than 50% (my standard), Refuel Resupply and Overhaul at Colony it doesn't trigger any error, so I just use this in combination with the Deployment exceeded. So ship will overhaul only at deployment exceeded but not refuel running the full process when running out of Fuel.
You'll get the function error but that's all. I am honestly not looking after my exploration at all currently unless something shows up on radar.
Sure sometimes I still like to jump in, be careful etc, but when you have 50 plus ships exploring and surveying you could become tired of the process quite fast.
Let's see if I understand it correctly, the Refuel, Resupply and Overhaul order works for you if you set it associated with fuel levels? I had set it at Deploymen Exceeded - Refuel, Resupply and Overhaul. But it returns an error and makes my ships not refuel and resupply. Can you get them to both survey automatically, overhal and refuel/resupply that way?
Officers should be able to not only improve their current skills, but develop new ones if placed in a ship that need it. IE. If i dont have any officers with survey, but i assign someone to a DSS ship, they should eventually learn a thing or two about how survey works.Administrators certainly pick up new skills - I thought naval officers also did?
I would love to see a line chart on the Empire Minerals tab of the economy window that depicts your stockpile of the various minerals. With such a line chart, we could see the trend of our mineral production and do something about it before we get to critical levels.
Options for the chart:
Ability to depict stockpile levels of each mineral individually
Ability to display data accrued over the last month, year, 5 years, and 10 years with data points every 5 days, weekly, monthly, and quarterly (respectively), or allow these choices of data points to be adjustable
Ability to choose an individual planet's stockpile to display as well as the entire empire's stockpiles
One additional advantage for this chart is that there is a ton of space on the Empire Minerals tab just begging for a chart. :)
Rationale:
As it stands right now, you only see the stockpile change over the past 5 days. However, you can't see the spikes you might be getting (up or down) that actually create a trend. For example, I could be running a deficit on Corundium, but can't see the 25,000 that a freighter is carrying to Earth and suddenly dumps it. It would appear that I am losing Corundium, but in fact, I am gaining because the freighter has more in it than the losses add up to. The same can happen on a downward trend, where you happen to look just after a mass driver delivery, but you missed the two negative days between that add up to a greater decline than the delivery.
Hm, not sure if someone's asked this before, but how practical would it be to add a aircraft type to the ground forces designs to represent VTOLs and the like?
There is nothing in the game that says what each vehicle category is, just their general weight and size which prohibits how much armour they can carry and what weapons can fit into them. Whether it's rolling on wheels, chugging on tracks, flying on jets, walking on hydraulic legs, or even hovering thanks to anti-gravity plate, is all up to the player and their imagination and the story they are telling.
The ground combat model only understands the concept of the front line, support area and rear area because it supports both a handful of space marines shooting it out on a tiny asteroid as well as fifty million soul strong combined arms army group pulverizing a Super-Earth planet.
Which means that there is no point in determining whether a specific unit walks or swims or flies. All vehicles can achieve breakthrough already - whether that means German tanks driving through the Ardennes forest or American helicopters flying over Vietnamese jungle is mechanically meaningless. There already is a weapon that can reach enemy Rear Area and multiple weapons that can reach Support Area.
Time-wise, it would be much better for Steve to fix planetary support fighters, AAA and STO, as well as give NPR/spoilers the ability to use them.
Of course, if you can come up with a new, novel mechanic that adds to the ground combat model, then, by all means, do write it all down - but adding planes as a ground unit alone is a waste of time. Not to mention that you would have to make all sorts of exceptions to it to explain how helicopters/aeroplanes can operate on airless rocks in space as well as Venusian planets.
Cargo Shuttle Bays
Part of the background in C# Aurora will be that large TN ships function only in space and cannot move any closer to planetary bodies than low orbit. Small craft below a limit of 500 tons, such as fighters and shuttles, are capable of landing on planets. Ship are built in orbit and habitats are assembled in orbit. Only fighters can be built on the ground.
K-Orzel STK wz 1 class Shuttle 499 tons 11 Crew 58.3 BP TCS 10 TH 7 EM 0
722 km/s Armour 1-5 Shields 0-0 HTK 3 Sensors 0/0/0/0 DCR 0 PPV 0
Maint Life 8.65 Years MSP 25 AFR 6% IFR 0.1% 1YR 1 5YR 9 Max Repair 20 MSP
Cryogenic Berths 1 000
Lieutenant Commander Control Rating 1 BRG
Intended Deployment Time: 3 months Morale Check Required
Improved Nuclear Pulse Engine EP7.20 (1) Power 7.2 Fuel Use 19.08% Signature 7.20 Explosion 4%
Fuel Capacity 1 000 Litres Range 1.9 billion km (30 days at full power)
This design is classed as a Fighter for production, combat and planetary interaction
An expanded version of this has already been suggested here: http://aurora2.pentarch.org/index.php?topic=11946.0
The inability of fighters to load/unload is a bug.
Or perhaps a conventional sensor that is, like conventional industry, a combination of all possibilities but way worse - so it'd be like 0.2 EM 0.2 TH 0.2 AS 0.4 Geo in a 50 HS package.This would be nice. However, I suspect it would require more work for Steve to add a new component type and doesn't solve the problem of lacking a MFC.
Alternatively, have conventional versions of all 4 sensors that require only wealth to build.You can actually build thermal and EM sensors without a problem, although EM requires active signals to detect in order to be worth having. I'm fine with grav sensors being TN tech as they're locked behind JP Theory anyways, so Geo sensors are the missing link (along with active + MFC).
I would love to have a game where the first stage of interplanetary exploration (and primitive warfare) is done by fighter-sized vessels.
I think it also would be very, very nice, if all conventional-tech objects will reqire no TN mineral.Presently in a conventional start you can still mine TN minerals, but very slowly due to the limits of conventional industry versus TN Mines. I think keeping the TN material requirements is good to promote a little bit of resource management in terms of not outpacing your slow pace of stockpiling.
I would not change ballance, still would bring much flavour to slow-start campaings.
I noticed that my engineers are busy playing archaeologists while assaulting Precursor positions. I think that it would be better if facility recovery was not possible while hostile forces are on the planet.Perhaps restrict that to only Precursor forces. I can imagine a situation with multiple armies fighting over ruins and having competing archaeologist teams racing to salvage stuff before the enemy.
Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.
I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.
Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.
I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.
Max tractor size would be interesting and could be done in a few different ways. Just having a plain absolute maximum would be kind of limiting and probably slow down the game economy too much, but either making it a multiple of the tug size or allowing multiple tractor modules with additive total tugging capacity. Doing both would be really interesting, i.e. each module lets you tug X% of the tug's mass, but that might be making things overly complicated. Personally I think the mass-per-module makes the most sense, physically a single tractor beam would have an upper limit of tugging capacity regardless of its mount.
Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.
I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.
Max tractor size would be interesting and could be done in a few different ways. Just having a plain absolute maximum would be kind of limiting and probably slow down the game economy too much, but either making it a multiple of the tug size or allowing multiple tractor modules with additive total tugging capacity. Doing both would be really interesting, i.e. each module lets you tug X% of the tug's mass, but that might be making things overly complicated. Personally I think the mass-per-module makes the most sense, physically a single tractor beam would have an upper limit of tugging capacity regardless of its mount.
Makes sense to me. That way, there could be the same kind of design decisions as other modules, like how grav sensors scale up as the tech increases. That would also allow for more and more efficient tugs as tech improves.
I do wonder what happens if you try to tug something above what the tug is rated for. Does it just not work? Are there speed or fuel efficiency penalties?
Sorry about double post, but as this is thoroughly unrelated....
The new reduced size single weapon fire controls could be taken further: make fire controls, in general, have limited number of weapon allocations. Bigger fire controls would allow more weapons to be assigned to them.
The purpose of this is to make giant infrequent missile salvos less effective, since it becomes hard to have enough fire control channels to make it work. It also opens up interesting design space related to sharing fire control channels, much like the rotating guidance schemes used in some of the later Honor Harrington books.
If applied to beam fire controls, it would also create more of a reason to go for layered anti-missile schemes, since you can't manage 100 railguns firing simultaneously anymore. This would help balance out the nerf to missiles, too.
Big, infrequent salvos (box launchers, or just reduced reload rate launchers) are the optimal way to use missiles. That doesn't mean they are the optimal way to play the game, which may be what you are getting at. But currently, if you want to use missiles this is the best route. And as a result, antimissile capabilities need to be balanced around it. This, in turn, makes other approaches untenable. Increasing the expense of huge salvos would allow weakening missile defense capabilities without causing missiles to dominate, in turn allowing other missile approaches to work better.
- I like the idea as applied to Beam FCS, but frankly the big, infrequent salvos thing is already sub-optimal to the point of being near ineffective. Box Launcher spam notwithstanding mind you, but Box Launcher spam is already balanced out by counter-AMM Box Launcher spam, cheap decoy missiles, and by virtue of being a "one shot wonder" as they can't be reloaded mid-battle. The Beam FCS requiring more weight to control more guns is a bit... weird in terms of logic, but since any number of guns can be tacked onto any number of FCS systems to engage any number of missile salvos that might actually create some interesting design decisions, without forcing a meta. It would also serve to increase the role of CIWS as a military system, making it a more attractive option and thus creating even more flavors of design.
- As to 100 railguns... under the C# weapons model you'd probably destroy the damn ship by eating through MSP, so that's not really a great example, but yes having bigger FCS to handle those bajillion guns would be pretty neat. However you already more than one FCS to track more than one (non-missile salvo) target, and you need at least four FCS units if you want to perform offensive beam attacks, Area Defense PD, Final Fire PD and Final Fire PD(Self-Only) at the same time. So it already seems pretty balanced as is, tbh. An erstwhile and good suggestion in any case. :)
Commander auto-assign needs a couple of tweaks to be actually useful.
First: Some degree of allowance needs to be made for commanders to command a ship that they are technically overqualified for. Currently, the auto-assign will only assign a commander to a ship if they are exactly the minimum rank needed to command that ship. This is fine for warships where you have a few different classes and generally can designate one class to have Senior C.O.s as it's the more important one anyways. Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.
Second: It would be helpful if we could assign an alternative commander specialty in the "Miscellaneous" tab of the class design window. For example, if I make a mining platform with a cargo bay to port a mass driver around, the game will treat it as a freighter and assign a Logistics commander instead of a Mining commander
Second one is a minor (heh) detail but the first one is in my opinion much-needed, being the primary reason I hesitate to click "Automated Assignments" even as my empire grows and I have to replace multiple retired or promoted commanders after every increment.
Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.
Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.
Flexible ranks could be nice, but don't forget that you have two new tools now as well. The new command & control modules allow more than one officer per ship, and admin commands provide a bonus to more than one fleet at a time.
Survey officers should start their careers in a Science Department, then be promoted and have a shot at commanding a ship, and then when promoted again they should move into a regional admin command, then get promoted again and take over the whole survey operation for the western spiral arm and so on. Once in an admin command, they provide one quarter of their bonus to every ship in their department. As long as that's four or more ships, then they're using that bonus well. Once promoted again, they provide one sixteenth of their bonus to all the ships two levels down from them. Individually that's not a lot, but if it's spread out over 16 or more ships, then they're contributing just as much as they ever were. Even if you have fewer than 16 ships they'll still be beneficial.
With 16 survey ships you have enough room for four levels of promotions. There will be 16 captains that get promoted and will vie for the chance to run one of the four regional admin commands; you'll give the best four of them the job. Most of the others will retire early, or find jobs in other parts of your navy (since they might have or develop other skills too). The best of the four will end up running the whole survey operation. They could end up running the whole navy on their next promotion, if you decide that they've got enough non-survey skills built up by then.
There is one wrinkle, of course. The standing orders for moving to a system requiring survey do not appear to take into account the location of the admin command to which the ship is assigned. (Not that I've investigated the matter very thoroughly…) As far as I can tell, it just picks the system closest to where the ship is at the time. That will mostly work, but after returning to your capital for overhaul they'll probably end up in a system on the other side of the galaxy, where they won't be getting any bonuses from their admin command. The solution to this is either micromanagement or better logistics: give each region a facility capable of overhauling survey ships. That cuts down on travel times too.
I do something like this already, in fact my survey admin command structure is three layers deep (CDRE-RADM-VADM) assuming I have the officers for it, and I require science officers on all my survey ships (at least for TN start). The problem is just that CDR-CAPT split as I usually prefer to keep Captains (or other 3rd rank) as senior ship commanders and Commodores as the lowest level of admin command both for RP and ease of management.
I do something like this already, in fact my survey admin command structure is three layers deep (CDRE-RADM-VADM) assuming I have the officers for it, and I require science officers on all my survey ships (at least for TN start). The problem is just that CDR-CAPT split as I usually prefer to keep Captains (or other 3rd rank) as senior ship commanders and Commodores as the lowest level of admin command both for RP and ease of management.
I see. I guess you could add Main Engineering to your survey ships too. Then you'd have the three lowest ranks on all of them, and the ship's commander would be a captain.
Queue Name | Pooled resources? | Multiple items? | Future items? | Change order? | Percentage allocation? |
Fleet Orders | yes | yes | yes | no | no |
Industry | yes | yes | yes | yes | yes |
Ordnance | yes | yes | yes | yes | yes |
Fighters | yes | yes | yes | yes | yes |
Shipyard | no | yes | no | no | no |
Research | partial | yes | yes | partial | partial |
Ground Units | no | yes | yes | partial | no |
Civilian Contracts | yes | yes | no | no | no |
Terraforming | yes | no | no | no | no |
A raise all lower all button for shields so that you don't need to go manually ship by ship.
I know there is an order for it, but I think a button will be more intuitive.
A raise all lower all button for shields so that you don't need to go manually ship by ship.
I know there is an order for it, but I think a button will be more intuitive.
A raise all lower all button for shields so that you don't need to go manually ship by ship.
I know there is an order for it, but I think a button will be more intuitive.
Can't you multiselect then use the existing button? I thought that worked.
I have approximately 3 small suggestions:
1) I would like to be able to set a default field position for each template.
When a template is built it is automatically assigned to that position, after that it has no further effect.
There are a lot of rear and support elements that are never going to need to be assigned to any other position, being able to set their position during creation would save quite a bit of micromanagement.
A raise all lower all button for shields so that you don't need to go manually ship by ship.
I know there is an order for it, but I think a button will be more intuitive.
Can't you multiselect then use the existing button? I thought that worked.
As far as I know no such button exists in C#. Though it wouldn't be the first time I missed a UI element
I have approximately 3 small suggestions:
1) I would like to be able to set a default field position for each template.
When a template is built it is automatically assigned to that position, after that it has no further effect.
There are a lot of rear and support elements that are never going to need to be assigned to any other position, being able to set their position during creation would save quite a bit of micromanagement.
Probably too complicated, but it'd be super cool if the game was designed to model all levels of officers, starting from Ensign all the way to Fleet Admiral. The way this would work is that every ship would need certain billets to be filled by default by lower-ranking officer (Department Heads, Co-Pilot on small craft, etc) and then on top of that every part you add to a ship needs a certain amount of officers to work properly (fire controls, engines, hangars, cargo shuttle bays, etc). Frankly, I think the XO and Chief Engineer should present on every ship you build above 1000 tons at the very least.
Currently officers start of as way too young, as the game models them as being mid-level officers (Senior LTs, Commanders) but they all start out at 21. Adding in more opportunities for multiple lower-ranking officers to serve on a ship would be extremely cool from an immersion and storytelling perspective.
Probably too complicated, but it'd be super cool if the game was designed to model all levels of officers, starting from Ensign all the way to Fleet Admiral. The way this would work is that every ship would need certain billets to be filled by default by lower-ranking officer (Department Heads, Co-Pilot on small craft, etc) and then on top of that every part you add to a ship needs a certain amount of officers to work properly (fire controls, engines, hangars, cargo shuttle bays, etc). Frankly, I think the XO and Chief Engineer should present on every ship you build above 1000 tons at the very least.
Currently officers start of as way too young, as the game models them as being mid-level officers (Senior LTs, Commanders) but they all start out at 21. Adding in more opportunities for multiple lower-ranking officers to serve on a ship would be extremely cool from an immersion and storytelling perspective.
Not to be a Debbie Downer, but in addition to adding complication for questionable game benefits I do want to point out that this system would be absolute Hell to use if you play without automatic assignments, or even if you do but also do a lot of manual work because you don't trust the system.
If the problem is that officers are too young, a simpler solution is to either change the default starting age to 30 or 35, or to decouple age from career length entirely and have age be another randomly-generated starting trait. Personally I headcanon that my leaders don't start at age 20/21, rather this is their career length to date and they've been promoted to a senior officer role after a couple decades climbing the ropes.
I don't know why you wouldn't play with automatic assignment tbh. To me the un-optimized nature of it actually contributes to the gameplay and feel of expanding your empire. For your first couple of ships, you can hand select the best guys personally to staff these groundbreaking space ships you are going to use to change humanity forever. As space travel gets more casual and the fleet gets larger however, it naturally becomes more and more difficult to hold leaders accountable and make sure the best guys are getting into positions of responsibility and you have to rely more on the 'system' which is imperfect and subject to bias and nepotism.
Of course, that doesn't stop you from hand selecting a crew for your most important and groundbreaking ships.
I don't know why you wouldn't play with automatic assignment tbh. To me the un-optimized nature of it actually contributes to the gameplay and feel of expanding your empire. For your first couple of ships, you can hand select the best guys personally to staff these groundbreaking space ships you are going to use to change humanity forever. As space travel gets more casual and the fleet gets larger however, it naturally becomes more and more difficult to hold leaders accountable and make sure the best guys are getting into positions of responsibility and you have to rely more on the 'system' which is imperfect and subject to bias and nepotism.
Of course, that doesn't stop you from hand selecting a crew for your most important and groundbreaking ships.
My #1, #2, and #3 issue with the auto-assign is that unless you design your navy precisely to the dictate of the auto-assign algorithm, it will regularly either leave swathes of ships without a commander, or refuse to assign entire ranks to suitable commands, quite often both.
I would love if the auto-assign would reliably keep ships commanded and commanders assigned even if the result was not close to optimal, as you say the RP implications are a perfect fit for the game. I have a lot harder time RPing why half of my frigates lack a commander while half my Captains are sitting around scratching their asses just because my frigates require a "mere" commander and all the cruiser billets are filled. At some point manually filling in all of the holes left by auto-assign becomes tedious enough that one might just be better off doing everything themselves.
Of course, one can design their fleet structure to fit to the auto-assign, but this is a rather limiting view of how the game should be played. There are many systems in the game that impose constraints on the player which can be solved in interesting ways. The auto-assign requires the player to either do exactly as it says, or it just breaks entirely - "interesting" is hardly the word I'd use to describe this.
Anyways, I'm just ranting now and I've already made suggestions in this thread on the topic so I'll let it lie now.
A while ago I made a suggestion to split military academy into multiple buildings - each one only graduating a single type of commander, thereby giving the player more control over what officers they actually want. Either that, or allow the player to determine the ratio between each rank.
I like that idea. Though I would create different academies for each skill instead of saying they belong to the same school. We are talking planets here, it can have more than one school.
Quote from: Borealis4x link=topic=10640. msg143964#msg143964 date=1607047311I like that idea. Though I would create different academies for each skill instead of saying they belong to the same school. We are talking planets here, it can have more than one school.
The reason why I avoided taking my suggestion there is because this would make academy commandants obsolete. If my suggestion were to be implemented it would probably be a good idea to have academy commandant skills have more of an influence on the skill set of the graduates.
Quote from: Droll link=topic=10640. msg143969#msg143969 date=1607050240Quote from: Borealis4x link=topic=10640. msg143964#msg143964 date=1607047311I like that idea. Though I would create different academies for each skill instead of saying they belong to the same school. We are talking planets here, it can have more than one school.
The reason why I avoided taking my suggestion there is because this would make academy commandants obsolete. If my suggestion were to be implemented it would probably be a good idea to have academy commandant skills have more of an influence on the skill set of the graduates.
Might depend on how it's implimented. At the moment we have an academy and every time we build it, it adds one level to the existing for that planet. What could happen is split the academy between the 'officers' so you have one that's pure navy, one pure science, one pure admin and one pure ground, making four commandants initially and have training skill buff the number or quality of graduates (though that would mean every officer type would have that skill).
Maybe if Steve impliments that system, down the line you could have it that each academy also takes the highest one or two skills from the commandant and depending on the level of them and training, you'll have more chance of officers from that planet's x academy having those skills at some level so different worlds would produce officers with different starting skills depending on the commandant's skill set.
Or go a different route, maybe expand things so there's additional buildings you can build linked to the academy ala the ship command modules. Each module building requires a certain type of officer and improves both the number of that type and the likelihood of others with that skill set. It's still one planetary academy so to speak, but the additional 'campuses' both improve the output and allow different skill sets to be taught.
It kind of depends on how complex the programming is and how much manual work players want to deal with.
Would it be possible to add another filter set to the ship design window?
For grouping common types of ship / station designs, that still have distinct name for class and hull.
I tend to design ships and stations that complement each other but have different hull names.
Currently I'm grouping them via hull name.
What I'm proposing is either a third drop-down list or a drag and drop functionality so that my "Combat Logistics" ships which all have different hull names (therefore appearing in different places on the list) could all be displayed together.
Or all my "Carriers" could all be displayed together even though one design is an Escort Carrier, one is an Auxiliary Carrier, and one is a Carrier, and the last is a "Supercarrier" they all have the same basic function (carrying, refuelling and rearming short ranged parasite craft) but all also have different purposes (Auxillary to move undamaged craft to the combat zone as replacements, Escorts to move with other craft, Carriers and Supercarriers to be flagships.
What I'm proposing is either a third drop-down list or a drag and drop functionality so that my "Combat Logistics" ships which all have different hull names (therefore appearing in different places on the list) could all be displayed together.
Or all my "Carriers" could all be displayed together even though one design is an Escort Carrier, one is an Auxiliary Carrier, and one is a Carrier, and the last is a "Supercarrier" they all have the same basic function (carrying, refuelling and rearming short ranged parasite craft) but all also have different purposes (Auxillary to move undamaged craft to the combat zone as replacements, Escorts to move with other craft, Carriers and Supercarriers to be flagships.
Add a station filter so that you don't need to scroll through fleets for refuel, maint, and more.I like this idea, but there are more possibilities:
Can be challenging in busy systems to find what you need.
I currently leave a space before the name so that they always listed on top.Off-Topic: show
Feature Request: Is it possible to add a flag to prevent an officer from being assigned to a particular ship class? I tend to create small commercial sensor platforms on jump points and crank them out with industry - I then load them into a special sensor tender which I then use to drop them. I tend to overproduce academies so officer shortage usually isn't a problem but I rather not have auto-assign wasting Lieutenants on these.
A good "quick fix" for this would be to make newly-created ship classes have a priority of 10 instead of 0, allowing for ultra-low-priority classes like these to exist. That way you should never see a rank-1 officer assigned to one of these when a better XO or freighter posting is open, but excess commanders will still be able to find employment.
Actually I'd like this as a separate feature, both are good.
In addition, 0 = lowest priority now.A good "quick fix" for this would be to make newly-created ship classes have a priority of 10 instead of 0, allowing for ultra-low-priority classes like these to exist. That way you should never see a rank-1 officer assigned to one of these when a better XO or freighter posting is open, but excess commanders will still be able to find employment.
Actually I'd like this as a separate feature, both are good.
In 1.12 the default priority of new classes is set to 10 so this is already in.
A good "quick fix" for this would be to make newly-created ship classes have a priority of 10 instead of 0, allowing for ultra-low-priority classes like these to exist. That way you should never see a rank-1 officer assigned to one of these when a better XO or freighter posting is open, but excess commanders will still be able to find employment.
Actually I'd like this as a separate feature, both are good.
In 1.12 the default priority of new classes is set to 10 so this is already in.
Not sure if any of these have been suggested before, but here's a few potentially useful suggestions.
1) Have an option for a tug fleet to attach to multiple/all ships/stations in another fleet without having to manually select every ship/station you want to have towed (this should probably limit up to either the amount of ships in the tug fleet or the amount of tractor beams in it or the beams' lift capacity). I'd also suggest allowing the tugs to tow station fleets without breaking said fleets since it's a bit annoying to have a batch of stations (especially ones liable to be moved) be put into a fleet, towed to a site and find your fleet has been broken into individual ship units when it reaches its (possibly temporary) destination.
2) I mentioned this partially in my last post on this thread ala allowing sub-fleet components to spread out so recon or survey could run from a single fleet but multiple separated elements, but it could also be useful to allow full fleets to spread across an amount of territory with being split up (particularly if it's something like a group of terraforming/harvesting/mining stations being dragged into position as above) because they're in motion or they're immobile and there's not enough tugs on hand to move everything at once.
3) Allow us to set up 'colony types' along with base rules for them. I know Aurora will take what we put at a 'colony' into account to decide whether it's a mining site, populated colony, archaeological dig, listening post, civilian mining site or 'other' and we can limit whether civilians visit, but it could be useful to allow us some extra control like allowing us to set digs to being excluded from civilian traffic by default so we don't suddenly get civilians dropping colonists there because we unearthed some usable building and forgot to say we don't want civilians involved in the site or tag which asteroids/moons/planets are just for mining over population before we start shipping automines over there.
(1) would be great as long as the limit remains one ship per tug. I'm not sure how much work it would be to code, but something similar exists for squadron jumping so it's certainly possible.
(2) Isn't really needed. You can detach a subfleet from a fleet into its own fleet and then have it rejoin later with the "Rejoin as Subfleet" order. Presently this is necessary since Aurora is coded so that every separate formation on the tactical map is a "fleet" and fleets don't have a hierarchy of fleets under them. However, the one reason I can think of why this would be needed would be if you have a flag bridge and want your ships to keep the bonus from that officer when they split off. Maybe a good way to implement this would be that a flag bridge functions like a naval admin command?
(3) I'm not sure what really needs to be added here. Currently we have the ability to ban civilian traffic from a body, civilian shipping as far as I know will not ship infrastructure and colonists to a colony that doesn't already have such things (e. g. a listening post or xenoarcheology dig), and CMCs as far as I know will not establish themselves on any body that already has a racial colony even if the colony is empty. These functions seem adequate to control civilian behavior pretty reliably as-is.
On point 3, the issue I've found is more for arch digs in that as soon as you have a construction ground unit dig up a working civ building, it turns it from a dig to a hab world at which point, particularly if the building is 'x infrastructure', civilian colony ships jump in and deliver population, which you might not want and might not realise until you check the eco screen. Yes you can tell the civvies not to have anything to do with a colony, but when there's a change due to an event, if you're not checking things when you set a colony, you can wind up having the AI screw you up, particularly if the dig is a high cost planet like Venus, or one you never want colonised even if it's 'viable'. The other thing for automines is more a visual aid. Most colonies we create start as 'other' unless they've got a ruin on site, but auto-mine sites change colour in the fleet orders menu, and shuffle around if you've got 'view by role' on the eco screen, allowing a quick reference for where you're aiming to actually colonise/terraform versus where you just want mines prior to sending anything there, particularly if it's something that might take a while to do because you've got to build things first.
It doesn't even need to be much, just allow us to decide without dropping anything what body has a particular classification of colony and don't auto-change it. Space Empires IV and V allowed you to pick a colony type as a player, so just letting us set and reassign so we keep digs as digs and can see our locales for mines/pops if we have to return to things later and have forgotten what's supposed to be what would help.
The "Military Restricted" flag should do what you want as it basically tells all civilian ships to avoid that body. When you establish a new dig site colony, in the Economics window / Civilian Economy tab there is a checkbox along the top row for "Military Restricted Colony" that per this comment from Steve should cause civilian ships to avoid the body. If that isn't working it is probably a bug and should be reported.Yeah, presuming you remember to do it before a ground force with construction units find something that causes the arch dig to become a settlement or viable for one, as mentioned before.
N. B. you can rename a colony/population separately from the body it is on, so you could establish a colony on Mars for instance and call it "Mars Dig Site" to keep track of what it's for.
Honestly speaking, what tabs are ones you look at for a colony in general? Main economy tab and mining are probably the two I care about for most colonies, the others are pretty much only if there's a population, which if I'm not planning a population but find a ruin, could (and did) result in a populated colony where I don't want one right then, or a place being tagged wrong from the AI.
Maybe a way to do STO missile combat is to treat formations with missile weapons like MFCs in combat as opposed to individual missile STO units. This would allow a player to target their STO weapons like they would with a ship while also creating useful grouping for STO missiles to prevent UI clutter/micro. (literally organizing missiles into batteries via the existing ground OOB system)
Its not without problems though - multiple types of missile launchers in the formation can complicate things (so a formation has an MFC for each missile type it has? Idk if that's a good solution)
- this does nothing for the magazine issues.
The only idea I have for the magazine problem is to just assign and use missiles in the planetary stockpile and maybe create missile STO as a separate component under static type units whose tonnage/reload speed can vary based on magazine feed efficiency technologies - kinda like how the BFC quality of beam STOs is determined through normal BFC tech.
Maybe a way to do STO missile combat is to treat formations with missile weapons like MFCs in combat as opposed to individual missile STO units. This would allow a player to target their STO weapons like they would with a ship while also creating useful grouping for STO missiles to prevent UI clutter/micro. (literally organizing missiles into batteries via the existing ground OOB system)
Its not without problems though - multiple types of missile launchers in the formation can complicate things (so a formation has an MFC for each missile type it has? Idk if that's a good solution)
- this does nothing for the magazine issues.
The only idea I have for the magazine problem is to just assign and use missiles in the planetary stockpile and maybe create missile STO as a separate component under static type units whose tonnage/reload speed can vary based on magazine feed efficiency technologies - kinda like how the BFC quality of beam STOs is determined through normal BFC tech.
Maybe a way to do STO missile combat is to treat formations with missile weapons like MFCs in combat as opposed to individual missile STO units. This would allow a player to target their STO weapons like they would with a ship while also creating useful grouping for STO missiles to prevent UI clutter/micro. (literally organizing missiles into batteries via the existing ground OOB system)
Its not without problems though - multiple types of missile launchers in the formation can complicate things (so a formation has an MFC for each missile type it has? Idk if that's a good solution)
- this does nothing for the magazine issues.
The only idea I have for the magazine problem is to just assign and use missiles in the planetary stockpile and maybe create missile STO as a separate component under static type units whose tonnage/reload speed can vary based on magazine feed efficiency technologies - kinda like how the BFC quality of beam STOs is determined through normal BFC tech.
4 new modules for ground units:
1. Active Sensor
2. Missile Fire Control
3. Missile Launcher
4. Magazine
This actually matches well with the real-world - the notorious Russian S-300 system, for example, has different vehicles for different roles, it's not a single thing handles all because of the size and complexity of the systems. And that's just a Surface-to-Air missile, not a Surface-to-Space missile.
The AS and MFC parts could automatically draw their values from racial tech levels like STO units do, with the addition that player could type in a resolution the way we put in HQ value. Then the launcher module is just a single box of size X as determined by the player and the magazine module is X * Y in tons based on player input.
So an SSM formation would have at least four different units in it. This would be more complex than what STO formations are and of course, I have no idea how the code under the hood works if it's actually impossible to have the hooks to missiles as well as how to handle loadouts without turning the SSM unit/element/formation into a fake-ship at which point it becomes a PDC again which we don't want.
Some level of bespokeness/shipyness is unavoidable with M-STOs...
Some level of bespokeness/shipyness is unavoidable with M-STOs...
Unfortunately, this is why old-style PDCs were removed in the first place.
For Christmas ;) ;D, a super minor request, to help find faster commanders. When you select a ship in the Commander Window, have the commander selected (if you don't always want this behavior, just add a checkbox to enable the option).
Because right now finding the commander of a ship, when you want to switch allocations is rather convoluted.
Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.
this was in the changes discussion but as it turns out I am making a suggestion out of my answer.Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.
I remember I did once played a game humans only+ spoiler races no NPRs and where I have disabled all mineral techs (capped at 10) and every mineral source found would have to be reduced to 0.1 access and increased to 100,000,000 tons.
The point of the test was not to have mineral difficulties, as after a while in Aurora it hardly is because the issue is mere a logistical one, but to face bottlenecks due to a scarcity of minerals directly in the stockpile.
I don't remember if it ended up because I got bored or because there were too many interruptions...it may have been both.
I think, while having the minerals to mine is a great thing, we should have also some sort of limitation in game to avoid piling up minerals to the point that find new better sources are almost useless. Beware, this is mid game problem as when you grow big then you need access to more minerals either because the one left behind have been depleted or it would take simply too long to transport.
I was thinking maybe we could get a sort of stockpile mechanic? I mean a physical one. So let's say that as we have capped pop related to planets, we could have the same on stock. For instance Luna would be able to "stock" 1,000,000 tons of minerals (you can expand through a dedicated structure) while Mars and Earth more as they are bigger. This would impact the asteroids which are small and making collection centers more of a thing. To reflect Aurora Mineral mechanics the cap should go per mineral and not on the total so the 1,000,000 will be divided by the amount of minerals available and not summed up. So if you have 2 minerals on Luna you will have 500,000+500,000 stock otherwise if you have 10 it will be 100,000 each.
As this could create issues with load and pick, considering we already have the wait until full order an unload until empty one could be added?
this was in the changes discussion but as it turns out I am making a suggestion out of my answer.Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.
I remember I did once played a game humans only+ spoiler races no NPRs and where I have disabled all mineral techs (capped at 10) and every mineral source found would have to be reduced to 0.1 access and increased to 100,000,000 tons.
The point of the test was not to have mineral difficulties, as after a while in Aurora it hardly is because the issue is mere a logistical one, but to face bottlenecks due to a scarcity of minerals directly in the stockpile.
I don't remember if it ended up because I got bored or because there were too many interruptions...it may have been both.
I think, while having the minerals to mine is a great thing, we should have also some sort of limitation in game to avoid piling up minerals to the point that find new better sources are almost useless. Beware, this is mid game problem as when you grow big then you need access to more minerals either because the one left behind have been depleted or it would take simply too long to transport.
I was thinking maybe we could get a sort of stockpile mechanic? I mean a physical one. So let's say that as we have capped pop related to planets, we could have the same on stock. For instance Luna would be able to "stock" 1,000,000 tons of minerals (you can expand through a dedicated structure) while Mars and Earth more as they are bigger. This would impact the asteroids which are small and making collection centers more of a thing. To reflect Aurora Mineral mechanics the cap should go per mineral and not on the total so the 1,000,000 will be divided by the amount of minerals available and not summed up. So if you have 2 minerals on Luna you will have 500,000+500,000 stock otherwise if you have 10 it will be 100,000 each.
As this could create issues with load and pick, considering we already have the wait until full order an unload until empty one could be added?
Im not even sure if this is a good idea or not but a communications array/module or whatever you want to call it, that would increase the chance of successful communication between species.
This is an idea that would probably take too much work for Steve and may not be well received, however I just wanted to throw it out there. I have seen many posts about weapons systems that are only useful for roleplaying and similarly if you are really trying to win in the most efficient way you research these techs and build these ships etc.
What if there was a small but significant amount of RNG put into the various techs at the start of every game. The idea being that in one gameplay the lasers might well be the way to go, however the next time with the same exact setup it may be plasma or mesons etc. The player wouldn't know before actually doing the research how effective any one weapon system would be in that particular game requiring one to experiment and find a different path each game.
I think this would be great for roleplaying as well, those who like to assign different preferences to different groups in the multiplayer starts would no longer feel constricted by considerations like well this isn't right because now this group has the weakest weapon system because you wouldn't know beforehand who had what.
I know this would be very difficult as a range would need to be arrived at for each system so that the weapons were not useless on the bottom end and not superpowered on the top end. This would have to be balanced enough however that the value of the systems would change in relation to each other depending on where they were assigned in the range when the game was generated.
Perhaps a check box could be added at game setup for those that preferred the current system as opposed to this proposal.
this was in the changes discussion but as it turns out I am making a suggestion out of my answer.Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.
I remember I did once played a game humans only+ spoiler races no NPRs and where I have disabled all mineral techs (capped at 10) and every mineral source found would have to be reduced to 0.1 access and increased to 100,000,000 tons.
The point of the test was not to have mineral difficulties, as after a while in Aurora it hardly is because the issue is mere a logistical one, but to face bottlenecks due to a scarcity of minerals directly in the stockpile.
I don't remember if it ended up because I got bored or because there were too many interruptions...it may have been both.
I think, while having the minerals to mine is a great thing, we should have also some sort of limitation in game to avoid piling up minerals to the point that find new better sources are almost useless. Beware, this is mid game problem as when you grow big then you need access to more minerals either because the one left behind have been depleted or it would take simply too long to transport.
I was thinking maybe we could get a sort of stockpile mechanic? I mean a physical one. So let's say that as we have capped pop related to planets, we could have the same on stock. For instance Luna would be able to "stock" 1,000,000 tons of minerals (you can expand through a dedicated structure) while Mars and Earth more as they are bigger. This would impact the asteroids which are small and making collection centers more of a thing. To reflect Aurora Mineral mechanics the cap should go per mineral and not on the total so the 1,000,000 will be divided by the amount of minerals available and not summed up. So if you have 2 minerals on Luna you will have 500,000+500,000 stock otherwise if you have 10 it will be 100,000 each.
As this could create issues with load and pick, considering we already have the wait until full order an unload until empty one could be added?
I like this idea, the only caveat I would add is a mechanism to discontinue the mining of a resource once the stockpile for it was full. I have played games with stockpile restrictions before where the resource in the ground continues to diminish every turn due to mining even though there is no place to put what is being mined so it just teleports into an unreachable dimension.
This is an idea that would probably take too much work for Steve and may not be well received, however I just wanted to throw it out there. I have seen many posts about weapons systems that are only useful for roleplaying and similarly if you are really trying to win in the most efficient way you research these techs and build these ships etc.
What if there was a small but significant amount of RNG put into the various techs at the start of every game. The idea being that in one gameplay the lasers might well be the way to go, however the next time with the same exact setup it may be plasma or mesons etc. The player wouldn't know before actually doing the research how effective any one weapon system would be in that particular game requiring one to experiment and find a different path each game.
I think this would be great for roleplaying as well, those who like to assign different preferences to different groups in the multiplayer starts would no longer feel constricted by considerations like well this isn't right because now this group has the weakest weapon system because you wouldn't know beforehand who had what.
I know this would be very difficult as a range would need to be arrived at for each system so that the weapons were not useless on the bottom end and not superpowered on the top end. This would have to be balanced enough however that the value of the systems would change in relation to each other depending on where they were assigned in the range when the game was generated.
Perhaps a check box could be added at game setup for those that preferred the current system as opposed to this proposal.
Without giving the player some sort of indication, what you're suggesting basically amounts to a player getting randomly screwed by their research choices with no way of predicting that this will happen, no way of actually knowing if they're on the optimal path (if I start with lasers and they are 5% stronger than normal, there's no guarantee that I'm not missing a better weapons system at 15% stronger than normal), and the only way to elucidate the mechanic is to dump a massive amount of precious early-game RPs into weapons research, or else pick one and hope you got luckier than the NPRs.
Presently, while some weapons are pretty clearly optimal all of them except maybe plasma have a place in a well-developed doctrine, and even plasma is cheap enough RP-wise that you can slot it into most doctrines as a short-ranged "bomber" weapon if you want to. The thing is that not every weapon or more accurately combination of weapons is suitable as a standalone armament, as really only missiles, lasers, and railguns can be used as standalone fleet armaments as these have both point defense/AMM and anti-ship capabilities. In this sense, the "optimal" play is to pick one of those three weapons systems and use only that weapon to minimize RP investment which maximizes RP available for other things like engines, however going the "RP" route of using additional weapon types is not much worse than this "optimal" route and in fact for the RP invested can give overall stronger ships since other weapon types are more specialized - for example, a laser-based fleet can benefit from Gauss turrets for more effective point defense or HPM secondary weapons to deal with shielded opponents against which the armor penetration of lasers is otherwise mitigated.
Aurora is always going to have a fairly boring "optimal" path, as is the case for nearly any strategy game that revolves around maximizing the efficiency of limited resources...this is why metagaming exists in nearly every game since the dawn of gaming. However, Aurora generally does very well at ensuring that the "optimal" is not too far ahead of various other, more interesting strategies so that players can pursue fun alternatives without being heavily underpowered, and I think this is a better goal from a design perspective than trying to add opaque randomness into the game just to upset or eliminate the meta strategies.
I understand your concerns and that was why I suggested an option at setup to use this or not. However I do believe what you characterize as a player getting randomly screwed is actually how things go IRL. Today I just happened to be browsing through a list of failed aircraft, both civilian and military that were designed and built with high hopes and just didn't work out as planned.
Something that we are all probably familiar with today that speaks to this is all of the vaccines that are under development some of which are now out for use but some of which are failed and no longer being pursued. I don't see this as the player being randomly screwed I just see this as more of a situation that exists where you don't know exactly what the return will be on the research path you choose and you will either live with pushing down a certain line of research even though there may be a better one or more broadly pushing several paths to get a feel for which might be the best way to go this particular time.
If research and development was as cut and dried as we find it in games than every country would field basically the same tanks, planes and ships. This is not the case because real research has a huge degree of uncertainty and results are often not what was anticipated when the project was begun.
This is an idea that would probably take too much work for Steve and may not be well received, however I just wanted to throw it out there. I have seen many posts about weapons systems that are only useful for roleplaying and similarly if you are really trying to win in the most efficient way you research these techs and build these ships etc.
What if there was a small but significant amount of RNG put into the various techs at the start of every game. The idea being that in one gameplay the lasers might well be the way to go, however the next time with the same exact setup it may be plasma or mesons etc. The player wouldn't know before actually doing the research how effective any one weapon system would be in that particular game requiring one to experiment and find a different path each game.
I think this would be great for roleplaying as well, those who like to assign different preferences to different groups in the multiplayer starts would no longer feel constricted by considerations like well this isn't right because now this group has the weakest weapon system because you wouldn't know beforehand who had what.
I know this would be very difficult as a range would need to be arrived at for each system so that the weapons were not useless on the bottom end and not superpowered on the top end. This would have to be balanced enough however that the value of the systems would change in relation to each other depending on where they were assigned in the range when the game was generated.
Perhaps a check box could be added at game setup for those that preferred the current system as opposed to this proposal.
In my opinion it would make allot more sense if each and individual component would have a small random variation of its efficiency for every parameter when researched. If you research a size 10 engine then its fuel efficiency will vary with +/- 10% its power will vary with +/- 10%. If you are no happy with the component you have to spend more research point to perhaps get a better one.
In addition to this you cold then increase research project by allowing more time to be invested to increase the chance for a better more effective component such as if you use two times the RP you are sure to end up with 0-10% more efficiency rather than -10% to 10% variation.
I would understand if this would be problematic for some people as they MUST have ships being exactly the same in some respect which might be problematic with this rules change. If could be optional, but I'm no fan of optional rules.
Personally I would like for research to be a bit less certain of the final result and you simply will have to live with the results.
I also think that it is not super realistic that a size 1 component takes half the time to research from a s size 2 component. I think there should be more of a logarithmic scale to research times of components in most circumstances.
Option to disable CMCs for those planned economy enthusiastsAre they not disabled together with shipping lines?
Option to disable CMCs for those planned economy enthusiastsAre they not disabled together with shipping lines?
That research thing probably deserves a thread of its own where it can be hashed out further as it is a complex topic.
Option to disable CMCs for those planned economy enthusiastsAre they not disabled together with shipping lines?
Nop. I'm playing a no civie game right now and they are building their CMCs regardless.
In my opinion it would make allot more sense if each and individual component would have a small random variation of its efficiency for every parameter when researched. If you research a size 10 engine then its fuel efficiency will vary with +/- 10% its power will vary with +/- 10%. If you are no happy with the component you have to spend more research point to perhaps get a better one.
I also think that it is not super realistic that a size 1 component takes half the time to research from a s size 2 component. I think there should be more of a logarithmic scale to research times of components in most circumstances.
In my opinion it would make allot more sense if each and individual component would have a small random variation of its efficiency for every parameter when researched. If you research a size 10 engine then its fuel efficiency will vary with +/- 10% its power will vary with +/- 10%. If you are no happy with the component you have to spend more research point to perhaps get a better one.
That's an interesting idea, but I fear that it's too readily exploitable. Players of a certain mindset would feel compelled to simply reroll every component they design until they get one that has the +10% bonus.
Perhaps instead, the formulas for component abilities should have an extra modifier that is randomized per-game. This modifier would apply equally to all components that have the same characteristics, so a boring action like rerolling would never help. It would also be predictable, so once you've figured it out you can take it into consideration.
A concrete example might help. Currently, the fuel consumption of an engine is determined by a formula: SQRT(10/Engine Size in HS). What if the formula was SQRT(10/Engine Size in HS) + 0.2 * sin(?*x+?), where ? and ? are random parameters choosen at game start and saved in the database. This would give some engines sizes a small bonus and other engine sizes a small penalty, and you wouldn't know which ahead of time.
I'm still not sure that this would be sufficiently interesting, but it would eliminate the compulsion.
I also think that it is not super realistic that a size 1 component takes half the time to research from a s size 2 component. I think there should be more of a logarithmic scale to research times of components in most circumstances.
This I can get behind. Military HQ research times get really ridiculous really quickly, since the HQ size is the primary factor.
On the other hand, I don't see much of an "exploit" here. Major components like big engines, large weapons, etc. are quite expensive to research so if anything rerolling these becomes a significant game decision. On the other hand rerolling a smaller component I don't think is problematic, after all you can issue a specification for a sensor or fighter engine with X, Y, Z specifications to five different companies and get five different designs to test.
Maybe a reasonable check here is that the +/- 10% (or other value) applies separately to each performance characteristic. So an engine has a separate roll for each of EP, fuel efficiency, power modifier, ... or a laser has separate rolls for power, recharge/ROF, range, ... and in this case you can even for game balance purposes add a constraint that the net randomness averages out to +/- 0% so you get for example two engines that have the same total performance for their tech, but one may be faster and another more fuel-efficient. This makes "better" components a subjective judgment and again rerolling becomes a strategic decision rather than an "optimize nao" button.
Component suggestion: Commercial missile dropper/buoy layer. Basically a component that can deploy missiles only with the Launch Ready Ordnance order. Could be designed with a variable missile size or just fixed at size 25 if you want to be cute about it. Ideally this would have an internal MFC and not require an MFC to be designed and added, similar to how CIWS has an internal BFC.
Main motivation is to make laying sensor buoys easier as right now there's no great solution (putting missile launchers on a survey ship seems to make the commander auto-assign consider it a warship, which is unfortunate). In theory this could also be used to lay minefields except that those are broken presently, otherwise I don't think this would be an immediately broken addition.
The player should be guaranteed to spawn with at least 1 scientist in every field.
The player should be guaranteed to spawn with at least 1 scientist in every field.
We already have the ability to switch a scientist's field for a 75% skill penalty which is reasonably fair (I use my 0% skill scientists for this and then try to train them up, usually I pop a better one in that field first though). This is sufficient IMO, part of the challenge particularly on smaller starts is dealing with a lack in some areas and one of those areas can be scientists.
The player should be guaranteed to spawn with at least 1 scientist in every field.
We already have the ability to switch a scientist's field for a 75% skill penalty which is reasonably fair (I use my 0% skill scientists for this and then try to train them up, usually I pop a better one in that field first though). This is sufficient IMO, part of the challenge particularly on smaller starts is dealing with a lack in some areas and one of those areas can be scientists.
Didn't know you could do that. Thought I still think you should at least start with 1 reasonably skilled scientist in every field.
How about an option to lock trans-newtonian tech behind surveying a ruin on Mars?
It always felt weird to me how cheap the tech that lets you break the basic rules of physics is, so I always waited until I colonized Mars with conventional tech to research it. In my mind, my guys find Precursor ruins there that can be reverse-engineered to understand Trans-Newtonian physics. Its a well-worn trope, but a good one.
Of course, that would necessitate making troop bays Conventional tech.
How about an option to lock trans-newtonian tech behind surveying a ruin on Mars?This would railroad the start of the game in a way fundamentally the opposite of how Steve wants to use Aurora.
It always felt weird to me how cheap the tech that lets you break the basic rules of physics is, so I always waited until I colonized Mars with conventional tech to research it. In my mind, my guys find Precursor ruins there that can be reverse-engineered to understand Trans-Newtonian physics. Its a well-worn trope, but a good one.
Of course, that would necessitate making troop bays Conventional tech.
This would railroad the start of the game in a way fundamentally the opposite of how Steve wants to use Aurora.
Aurora is more of a role-playing tool than a game and that means giving more options and flexibility.
If you want to RP situational limits to certain technologies that is 100% encouraged.
This would railroad the start of the game in a way fundamentally the opposite of how Steve wants to use Aurora.
Aurora is more of a role-playing tool than a game and that means giving more options and flexibility.
If you want to RP situational limits to certain technologies that is 100% encouraged.
I usually headcanon in my TN start games that TN tech was discovered from observations after a massive nuclear event large enough to affect the gravitational field.
There's no need to railroad the game and limit how people RP things.
Something that is sort of a pet peeve of mine albeit a small one is sub-fleet management. I usually build complex sub-fleet structures to my fleet and there is one order that I really miss and that is joining a specific fleet as a sub-fleet and insert it into a specific sub-flee in the tree of sub-fleets. Now I have to join the sub-fleet into the fleet at root level and then manually inject it into the proper place. It works great for parasites into motherships but not that well for other parts of a fleet structure.
I would suggest that the order "Join as sub-fleet" also give a list of Fleet (as in it works now, perhaps call it root) and also a list of all the sub-fleets in that fleet. Now I could join as a fleet and inject mu sub-fleet into any part of the organizational tree directly from my movement order so I don't have to deal with it separately later on.
I really like to use many sub-fleets and have a large and complex organizational structure to my navy.
To add to this aurora also does not handle multi-layer sub-fleet hierarchies very well right now
To add to this aurora also does not handle multi-layer sub-fleet hierarchies very well right now
In what manner do you mean it does not handle well?
To add to this aurora also does not handle multi-layer sub-fleet hierarchies very well right now
In what manner do you mean it does not handle well?
Offhand, two things:
- Aurora doesn't have orders that handle layers of subfleets. Most orders or controls either affect the whole fleet or the lowest subfleet. An example is fire control (the player interface, not the components): if I have two subfleets each with two more subfleets (1-2-4 sub-units at each level), I can give target assignments for the whole fleet or for each lowest-level subfleet, but I cannot give targeting orders for the mid-level subfleets.
- Aurora doesn't handle creation of nested subfleets from the bottom up. Ideally we would be able to select a fleet subunit (ship or subfleet) and create a subfleet containing that subunit. Currently we must create empty subfleets and drag units into them individually which is a bit annoying.
Subfleets work fine, but they could definitely be better integrated mechanically. Personally I'd like to be able to drag a fleet into another fleet (at the same location) and have it join as a subfleet, maybe something like a Ctrl+drag would work. Currently the only way to combine fleets this way is the Join as Sub-Fleet order, which takes 5 seconds (okay in Earth orbit, risky during a combat maneuver) and requires issuing an order (click, scroll, click, scroll...) instead of just doing a neat little drag-and-drop.
Hello everyone.I dont think that watching the AI play would be of massive use, as I believe that an AI race has a few different rules and limitations as a player race
It would be great to have something like a spectator mode, so that you can just watch the computer play multiple races, being able to switch between them and check all the details. Maybe it's not a very important option, but just to see what features the game provides, or what designs the computer will create and so on.
Also, the ability to mass-award officers in a task group or an administrative hierarchy would be nice to make campaign/war medals more feasible.
It would be nice if one could set a home port for a ship or a task group and then just press one button to go home.
Now I have to navigate manually and it takes some time.
It would be nice if one could set a home port for a ship or a task group and then just press one button to go home.
Now I have to navigate manually and it takes some time.
Just select a system using auto-route and it will go home. It's two clicks but close enough.
Nerf the missile neutralization tech line.
At max level I'm making magazines that have a 0.1% chance to explode (and that doesn't even account for chief engineer modifiers). This means that my ammunition storage full of nuclear warheads is somehow less likely to explode than my engine or reactor. There is absolutely no point to use the internal magazine armor for this reason.
I've also noticed that larger magazines have less of a chance to explode, maybe remove that too.
Maybe the best it gets is 60%-75%? It would nerf the short range assault potential of missiles since their parent ships would be powder kegs while also weakening AMM PD.
Regardless I believe that missile storage on combat ships is too safe.
Nerf the missile neutralization tech line.
At max level I'm making magazines that have a 0.1% chance to explode (and that doesn't even account for chief engineer modifiers). This means that my ammunition storage full of nuclear warheads is somehow less likely to explode than my engine or reactor. There is absolutely no point to use the internal magazine armor for this reason.
I've also noticed that larger magazines have less of a chance to explode, maybe remove that too.
Maybe the best it gets is 60%-75%? It would nerf the short range assault potential of missiles since their parent ships would be powder kegs while also weakening AMM PD.
Regardless I believe that missile storage on combat ships is too safe.
- Your at Maximum Tech, of course it's absurd. Even at Maximum Tech magazine armor isn't useless as it increases the HtK of the magazines making them draw more Internal Damage away from engines and reactors and such. They don't need to be nerfed, you just need to play at a lower tech level if you want to be more vulnerable. The game changes drastically at certain tech levels; Ion, Fusion, and Anti-Matter propulsions are the benchmarks most often used, but generally above 40,000 RP is where the game really starts shifting. If your burning through the tech levels, consider reducing your research rate, or using a lower mineral modifier or starting with less pop.
- Also, if we want to be ultra-realistic your stockpile of nuclear weapons should never explode no matter how much you shoot them because nuclear weapons are inert until armed AND detonated... and even then they sometimes fail to denotate properly. If anything, damage to them should render them less explosive, not more. To be short, I disagree, a lot. :)
- But, you still have the choice. You can design magazines with less neutralization tech. ???
Honestly though - even at ion levels assuming you only have the first level, 75% ejection still seems to high to me for entry level.
- But, you still have the choice. You can design magazines with less neutralization tech. ???
The minimum is 75% as I've already said - which I think is too generous/safe
- But, you still have the choice. You can design magazines with less neutralization tech. ???
The minimum is 75% as I've already said - which I think is too generous/safe
- The minimum is 70%, but yeah that does seem rather generous... I recall Steve mentioning that in the changelog though, now that you bring it up. The idea was that explosions would be less frequent, but more devastating. It was, IIRC, an answer to VB6 having far too many explosions overall... like U.S.S. Hood, but instead of a lucky shot to one ship it's your entire fleet and it happens a lot.
- But, you still have the choice. You can design magazines with less neutralization tech. ???
The minimum is 75% as I've already said - which I think is too generous/safe
- The minimum is 70%, but yeah that does seem rather generous... I recall Steve mentioning that in the changelog though, now that you bring it up. The idea was that explosions would be less frequent, but more devastating. It was, IIRC, an answer to VB6 having far too many explosions overall... like U.S.S. Hood, but instead of a lucky shot to one ship it's your entire fleet and it happens a lot.
Was editing the post as you sent this lol. Also you most likely are thinking of the H.M.S Hood, unless there is an American doppleganger im unaware of.
Strictly if you have very high radiation weapons then you might cause a premature ignition on a nuclear warhead. Generally speaking if you detonate a nuclear bomb with any of todays conventional weapons there is no real change of it going off (well, the explosives for the fission bomb might detonate but its unlikely to produce a nuclear explosion), however for instance shooting nukes at nukes might actually get a reaction.
Strictly if you have very high radiation weapons then you might cause a premature ignition on a nuclear warhead. Generally speaking if you detonate a nuclear bomb with any of todays conventional weapons there is no real change of it going off (well, the explosives for the fission bomb might detonate but its unlikely to produce a nuclear explosion), however for instance shooting nukes at nukes might actually get a reaction.
- So, instead of having a higher minimum magazine, we could have enhanced radiation warheads that could potentially damage magazines and intentionally cause said explosions? I'd like that! ;D
Strictly if you have very high radiation weapons then you might cause a premature ignition on a nuclear warhead. Generally speaking if you detonate a nuclear bomb with any of todays conventional weapons there is no real change of it going off (well, the explosives for the fission bomb might detonate but its unlikely to produce a nuclear explosion), however for instance shooting nukes at nukes might actually get a reaction.
- So, instead of having a higher minimum magazine, we could have enhanced radiation warheads that could potentially damage magazines and intentionally cause said explosions? I'd like that! ;D
Custom Water Requirements.
Custom Water Requirements.
What would this entail?
Custom Water Requirements.
What would this entail?
Right now every species needs 20% water. He is suggesting that we be allowed to change this requirement for various species. So one only needs 15% and another wants 30% for example.
Custom Water Requirements.
I was thinking about that the other day. I would love it! Customizable water% is higher on priority IMO but that would be really cool if you could implement it with just a toggle.Custom Water Requirements.
Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.
Would it be possible to add an unlimited number of conditional orders and saving said orders as a standard template to be applied either manually or as default from the ship design menu?
Would it be possible to add an unlimited number of conditional orders and saving said orders as a standard template to be applied either manually or as default from the ship design menu?
I like the idea of standing order templates but I don't think it would make sense to set defaults from the ship design menu. Standing orders apply to fleets, not ships.
Custom Water Requirements.
Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.
Thoughts on this: For now, just RP robots as needing Coolant (like cars). One should be careful when implementing Aquatic and Desert species, since an aquatic race can be completely nonviable if they can only have 2m pop on a planet, and a desert species can be very OP if they can use 100% of the surface just like that. It might require another thread to discuss balance, unless Steve makes an executive decision.Custom Water Requirements.
Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.
That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.
We Robots need no water!
Thoughts on this: For now, just RP robots as needing Coolant (like cars). One should be careful when implementing Aquatic and Desert species, since an aquatic race can be completely nonviable if they can only have 2m pop on a planet, and a desert species can be very OP if they can use 100% of the surface just like that. It might require another thread to discuss balance, unless Steve makes an executive decision.Custom Water Requirements.
Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.
That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.
We Robots need no water!
Thoughts on this: For now, just RP robots as needing Coolant (like cars). One should be careful when implementing Aquatic and Desert species, since an aquatic race can be completely nonviable if they can only have 2m pop on a planet, and a desert species can be very OP if they can use 100% of the surface just like that. It might require another thread to discuss balance, unless Steve makes an executive decision.Custom Water Requirements.
Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.
- That's a very elegant solution! I would add that we should be able to alter the tolerances so that we can have OP races if we want them. :)
That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.
We Robots need no water!
The carrying capacity problem is easily solved for aquatic and desert species - flip it on its head
So for an aquatic species - anything below 75% water reduces their carrying capacity.
For a desert species - anything above their water requirement (let's say 10% for this example) will reduce the effective carrying capacity.
The best part is that you don't even need to have the custom water requirements implemented and use the current ruleset for water (keep it between 10-20% for desert and above 75% for aquatic).
The existence and function of the population density modifier already shows us that aurora in its current form already tracks carrying capacity on a species-wise basis so this isn't too much of an ask (i think).
Thoughts on this: For now, just RP robots as needing Coolant (like cars). One should be careful when implementing Aquatic and Desert species, since an aquatic race can be completely nonviable if they can only have 2m pop on a planet, and a desert species can be very OP if they can use 100% of the surface just like that. It might require another thread to discuss balance, unless Steve makes an executive decision.Custom Water Requirements.
Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.
That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.
We Robots need no water!
The carrying capacity problem is easily solved for aquatic and desert species - flip it on its head
So for an aquatic species - anything below 75% water reduces their carrying capacity.
For a desert species - anything above their water requirement (let's say 10% for this example) will reduce the effective carrying capacity.
The best part is that you don't even need to have the custom water requirements implemented and use the current ruleset for water (keep it between 10-20% for desert and above 75% for aquatic).
The existence and function of the population density modifier already shows us that aurora in its current form already tracks carrying capacity on a species-wise basis so this isn't too much of an ask (i think).
The ability to queue up slipway additions for shipyards. Really annoying when I'm trying to build a FAC shipyard with 10 or so slipways with how fast they build.
I know a lot of people would appreciate Ground Forces automatic name generation to be changed so it only starts counting the number of that specific template used instead of all of them (so you don't get 1st infantry battalion and then 2nd motorized battalion even though its the first mot battalion you built).
I'd go a step further and suggest that the game let us 'lock' in a custom name for the units you are about to train (for example, 'Mars Infantry Battalion) and then automatically apply numbers as you queue up production orders (so you get 1st Mars Infantry Battalion and then 2nd Mars Infantry Battalion and so on) until you unlock or change the custom name.
I know a lot of people would appreciate Ground Forces automatic name generation to be changed so it only starts counting the number of that specific template used instead of all of them (so you don't get 1st infantry battalion and then 2nd motorized battalion even though its the first mot battalion you built).
I'd go a step further and suggest that the game let us 'lock' in a custom name for the units you are about to train (for example, 'Mars Infantry Battalion) and then automatically apply numbers as you queue up production orders (so you get 1st Mars Infantry Battalion and then 2nd Mars Infantry Battalion and so on) until you unlock or change the custom name.
Ordinal Numbers for ground formations will increment on a per-template basis rather than for all ground formations.
The ability to build shipyards to specific specifications right off the bat would be nice.
Obviously a larger shipyard with more slipways would take longer to build an require more resources, but you could make it more efficient in terms of time and resources to build a large shipyard from scratch than modify it over time, the downside being that the larger shipyards won't be available until its complete.
Streamlining shipyard construction is very important for me, as I find myself spending a lot of time just queuing up upgrade orders and its very tedious.
I am using repair ships in my current campaign - based on commercial hangars. They work pretty nicely, but there is unfortunate consequence - repaired ships will suck all fuel from the repair ship if they have damaged fuel tanks. Would it be possible to add checkbox to forbid mothership to refuel parasites?
I am using repair ships in my current campaign - based on commercial hangars. They work pretty nicely, but there is unfortunate consequence - repaired ships will suck all fuel from the repair ship if they have damaged fuel tanks. Would it be possible to add checkbox to forbid mothership to refuel parasites?
Does this not exist already? If you select the mothership on the fleet OOB you should be able to access drop downs that affect resupply behaviour
I am using repair ships in my current campaign - based on commercial hangars. They work pretty nicely, but there is unfortunate consequence - repaired ships will suck all fuel from the repair ship if they have damaged fuel tanks. Would it be possible to add checkbox to forbid mothership to refuel parasites?
Does this not exist already? If you select the mothership on the fleet OOB you should be able to access drop downs that affect resupply behaviour
I have dropdowns for resupply and ordnance, but not fuel. Does the resupply menu affects fuel as well?
don't know, what you can do instead is go to the class design and set a minimum fuel level for the ship
So if you have 1m liters of fuel and you only want it to refuel down to 800k, you set the minimum fuel to 800k and maybe it'll stop refueling parasites
It would be nice to be able to change NPR race/ship/flag pics in-game
It wold be nice if we can order ground troop to execute civilian and have medal for the amount of civilian kill. A lot of people are making game were they play space ####.Could just SM pop away and make a medal for that
- A "Update Unit Class Design" button (in the Ground Forces/Formation Templates tab) that automatically updates the racial armor and weapons of already created unit designs. That way we would avoid having to recreate each and every one of the units and formations every time we achieve a technological advance in armor or weaponry.
The idea of series of units is good as a replacement for units already created, but does not avoid the tedium of having to recreate the designs for all the different types of units in our game. With this suggestion, with just one click we would update our Rifleman PW (Arm. 6-Str. 6) to Rifleman PW (Arm. 8-Str. 8), and so on with each element.
I think the right way will be to create research tasks by "Update Request" button, not update all autonatically without Research Points use.This is an important point as the RP cost for upgrading units must be preserved in such a new system.
Not sure if this was suggested before, but I would like it, if the colour of ship names in the ship list changed according to their damaged status, just like in the fleet tree view. This would allow players to see at a glance whether a ship in the fleet is damaged, without having to open the fleet and all the subfleets.
(https://i.imgur.com/MZurQL7.png)
I've poorly edited in the orange colour for 2 ships, so you can see what it would look like.
I would also like to have zoom on the galaxy map, would also help when the galaxy start to sprawl out.
Showing the actual max travel distance of an active tug would be nice somewhere in the ship info... maybe additionally a log entry which checks when a tug picks up another ship how far it can travel with that load. If the travel distance is larger than how far the tug with the load actually can go until the tug receives the release order, then a log entry should pop up warning you that a tug is going to be stranded in space if nothing is done.
I have another thing that I have been thinking of lately in regard to balance... I think that shipyards that are doing any sort of construction such as expanding the size or adding slipways should get half production capacity if it also are building any ships, or reduced production capacity based on the number of slipways currently under use.
The general issue I have with shipyards is in comparison to ground construction factories, here you have to actually choose if you want to build more factories or something else.
I'm not saying this is a huge issue as you are still dependent on mined resources, but the shipyards are in general terms really effective once you start pumping out terraforming, orbital mining bases in their own dedicated yards. As you can keep building these while expanding the yards to build even more of them.
In order to curtail the snowball effect a bit I would suggest that yards get an efficiency modifier based on how many slipways are in use at the same time, up to 50% if all of them are in use at the same time as it does any sort of upgrade on itself. If you don't want it to be as severe you could make the max penalty like 33% or 25% instead, or you could turn it into a new tech line that start the penalty at even worse like 75% (you loose overall productivity if you multi-task) and then reduce the penalty down to a much smaller one at really high technology.
I have another thing that I have been thinking of lately in regard to balance... I think that shipyards that are doing any sort of construction such as expanding the size or adding slipways should get half production capacity if it also are building any ships, or reduced production capacity based on the number of slipways currently under use.
The general issue I have with shipyards is in comparison to ground construction factories, here you have to actually choose if you want to build more factories or something else.
I'm not saying this is a huge issue as you are still dependent on mined resources, but the shipyards are in general terms really effective once you start pumping out terraforming, orbital mining bases in their own dedicated yards. As you can keep building these while expanding the yards to build even more of them.
In order to curtail the snowball effect a bit I would suggest that yards get an efficiency modifier based on how many slipways are in use at the same time, up to 50% if all of them are in use at the same time as it does any sort of upgrade on itself. If you don't want it to be as severe you could make the max penalty like 33% or 25% instead, or you could turn it into a new tech line that start the penalty at even worse like 75% (you loose overall productivity if you multi-task) and then reduce the penalty down to a much smaller one at really high technology.
I would support even a simpler solution of making shipyards either/or - either they can do an expansion or they can build ships. As this would be quite restrictive currently I'd support coupling this with a significant boost to shipyard operations. To be less restrictive this could be on a per-slipway basis, i.e. a shipyard with two slipways can use one to build a cruiser and one to expand.
Net effect would be to create a decision between building ships and expanding the yard for future classes, while reducing the time it takes to get a fresh new shipyard up to useful capacity which presently is to be frank a bit of an annoyance.
I'll go against both of you for the sake of argument and say that shipyards should use Ground Construction Capacity. I don't think it makes sense that a shipyard would have to cease all operation cuz its building another slipway, but that building capacity should be coming from somewhere. Using GC to build out shipyards would give the player more control over how quickly they want them built and eliminate redundant techs like Shipyard Operations while making the game's systems more interconnected.
Yards are space objects, not ground objects. They are to be build primarily by themselves. I'd like even to see completely different model of their initial construction: by construction spacecraft fleet (made by small craft factories), not by construction factories!
That sounds like the current system with extra steps tho. Construction Factories already make the initial yard, why wouldn't they make produce the expansions as well?Construction Factories already make the initial yard now, in current version. What I proposed - is excluse Construction Factories completely, except of them make Small Craft Factories (now Fighter Factories, but it's not Fighters, especially at the beginning of the game), which could make Construction spacecraft, which could make Shipyards.
That sounds like the current system with extra steps tho. Construction Factories already make the initial yard, why wouldn't they make produce the expansions as well?
Construction Factories already make the initial yard now, in current version. What I proposed - is excluse Construction Factories completely, except of them make Small Craft Factories (now Fighter Factories, but it's not Fighters, especially at the beginning of the game), which could make Construction spacecraft, which could make Shipyards.Though no. I don't like this idea any more. Space crafts are not those who make yards - Borealis4x is right, they are moving it in orbit and mount there only, and this is already abstracted with shuttles. So, current model of initial buildup is good.
I also think you should be able to convert commercial yards to build military ships for a price and some time... they produce 1/12 the size and also a reduce the assembly speed with say a 25% penalty, commercial slipways should be able to be militarized in an emergency.
If the factory part is separate from the assembly there could be some interesting choices to be made. You also should be able to pre build ship components with your shipyard factories so you can store them for quicker assembly later, just as you can do with ground factories. It sometimes make sense to keep components around for strategical purposes.
Redlining Engines-In combat engine boosting with a per tick chance to suffer a breakdown or engine explosion, based on the degree of boosting, and a disproportionately large rise in fuel consumption and a per tick cost in maintenance supplies.
Redlining Engines-In combat engine boosting with a per tick chance to suffer a breakdown or engine explosion, based on the degree of boosting, and a disproportionately large rise in fuel consumption and a per tick cost in maintenance supplies.
Hell no on the malfunctions, I agree that some "afterburner" mechanic should burn more fuel than usual. But the fuel use is already a big enough draw back of boosting engines, they don't need to be anymore explosive than they already are.
Shouldn't techs like Infared Lasers and such effect Racial Weapon Strength instead of Laser Focal Size?
IIRC, last time we had one of those it got super removed (was it called hyperdrive?). My guess is that Steve wants to keep components more fixed.Redlining Engines-In combat engine boosting with a per tick chance to suffer a breakdown or engine explosion, based on the degree of boosting, and a disproportionately large rise in fuel consumption and a per tick cost in maintenance supplies.
Hell no on the malfunctions, I agree that some "afterburner" mechanic should burn more fuel than usual. But the fuel use is already a big enough draw back of boosting engines, they don't need to be anymore explosive than they already are.
IIRC, last time we had one of those it got super removed (was it called hyperdrive?). My guess is that Steve wants to keep components more fixed.
Focal size affects per-shot damageIn the cost of the size, and that is what infantry cannot pay.
Focal size affects per-shot damageIn the cost of the size, and that is what infantry cannot pay.
I mean the smallest laser IIRC is 150 tons and an infantryman in most cases takes 5 tons maybe 6 if you like PWI.
Meanwhile the lowest tech infrared gives infantry weapons that can fire out to 10,000km, which I'm going to assume is not a feasibly usable range for a dude with a laser gun.
For a 12mm focal size infantry "machinegun" compared to 10cm(100mm) focal size space gun if we assume linear progression that results in 1,100 km range, 10% of this is still 110km in case of damage falloff so suffice to say, regardless of what wavelength technology that you have, it won't have any effect on the damage potential of ground weapons.
Maybe you could argue artillery - but indirect fire laser artillery doesn't make sense anyways.
IMO now that I think about it it probably makes more sense to have capacitor tech affect racial weapon tech
Focal size affects per-shot damageIn the cost of the size, and that is what infantry cannot pay.
I mean the smallest laser IIRC is 150 tons and an infantryman in most cases takes 5 tons maybe 6 if you like PWI.
Meanwhile the lowest tech infrared gives infantry weapons that can fire out to 10,000km, which I'm going to assume is not a feasibly usable range for a dude with a laser gun.
For a 12mm focal size infantry "machinegun" compared to 10cm(100mm) focal size space gun if we assume linear progression that results in 1,100 km range, 10% of this is still 110km in case of damage falloff so suffice to say, regardless of what wavelength technology that you have, it won't have any effect on the damage potential of ground weapons. Maybe you could argue artillery - but indirect fire laser artillery doesn't make sense anyways.
On the other hand with focal size you could argue that it also represents the increase in the complexity of laser weapons and not just the raw size that it can be built in. Something which could feasibly benefit a laser armed ground army.
IMO now that I think about it it probably makes more sense to have capacitor tech affect racial weapon tech since it is important for almost every type of energy weapon in the game and allows you more RP flexibility. Only problem is capacitor tech only goes up to 25 but then again rakhas only have 15 racial weapon strength anyways. Capacitors make even more sense in the context of lasers because it usually is the main driving factor when using reduced size lasers - directly attacking the argument that lasers too big for infantry.
It is all just an abstraction... the weapons technology is just the level of technology that you can use with ground troops as the general basis for warfare. It is not like you will put a 10cm laser in the hands of an infantryman, that would just be absurd.
Like ships, STOs can be built from components (weapons) in the stockpile, reducing their production time significantly
Like ships, STOs can be built from components (weapons) in the stockpile, reducing their production time significantly
Now this is something I've wondered but assumed not since there is no 'use components' checkbox for GU (unless I'm blind, happened before). Seems odd for Steve to give us the choice in shipyard construction but not GU? So if I build STO's with my best Lasers that I'm stockpiling for a naval rush build....the GU STO production will scarf them up?
- A crazy, stupid idea... what if we could deploy Buoys and/or Mines from Cargo Holds? Haver it so that Cargo Holds could carry any missile or missile stage w/o an engine and then drop them on their location. No active target allowed, but no MFCS needed or indeed even useable. It *could* be used offensively or defensively... technically, for AMMs with active sensor "cans", or big sensor cans to engage a target with the actives... but that's hardly game changing I'd reckon.
- Maybe have the option to deploy them from magazines? I dunno, perhaps tie it to a cargo shuttle bay. I'd honestly like a minelayer / buoy dropping module...
- A crazy, stupid idea... what if we could deploy Buoys and/or Mines from Cargo Holds? Haver it so that Cargo Holds could carry any missile or missile stage w/o an engine and then drop them on their location. No active target allowed, but no MFCS needed or indeed even useable. It *could* be used offensively or defensively... technically, for AMMs with active sensor "cans", or big sensor cans to engage a target with the actives... but that's hardly game changing I'd reckon.
- Maybe have the option to deploy them from magazines? I dunno, perhaps tie it to a cargo shuttle bay. I'd honestly like a minelayer / buoy dropping module...
Unless you are wanting this to be commercial, it's not significantly different than a magazine+pile of launchers+min size MFC. At that point, why add it?
We already have commercial magazines, though. I could see the use of a commercial "Buoy Deployer" though. It would make minelayers and sensor buoy deployment ships much more economical- A crazy, stupid idea... what if we could deploy Buoys and/or Mines from Cargo Holds? Haver it so that Cargo Holds could carry any missile or missile stage w/o an engine and then drop them on their location. No active target allowed, but no MFCS needed or indeed even useable. It *could* be used offensively or defensively... technically, for AMMs with active sensor "cans", or big sensor cans to engage a target with the actives... but that's hardly game changing I'd reckon.
- Maybe have the option to deploy them from magazines? I dunno, perhaps tie it to a cargo shuttle bay. I'd honestly like a minelayer / buoy dropping module...
Unless you are wanting this to be commercial, it's not significantly different than a magazine+pile of launchers+min size MFC. At that point, why add it?
- I seem to have been unclear, I want this to be commercial. Be able to store Buoys in a Cargo Hold with Missile Size = Cargo Points, to account for the stowage kit. So a 500 Ton Cargo Hold could hold 100 Szie 5 Missiles, or 5 Size 100 missiles or 50 Size 10 Missiles, etc. I only included mines in my suggestions because I felt it'd be a bit dumb to not be able to dump those too.
Not sure if it has been suggested before, but I think a new tech line improving the efficiency for engineering spaces could be interesting. With higher 'engineering efficiency', we should be able to achieve the same maintenance life with less percentage of the ship devoted to the engineering spaces.Can be merged with Maintenance Production Rate (rename on smth like Maintenance Efficiency).
Mining Focus: I would like to see a mining focus for each mineral. I find it odd (and annoying) that the amount of minerals you get out of the soil is solely dependent upon how accessible it is. It would therefore be nice if we could increase or decrease the mining focus for each mineral. Since these factories are very modern and specialized, they should be able to focus on certain minerals.
So how should that work?
Let's say you have the following minerals on a planet:
Duranium 2.344.415t @0,4
Gallicite 455.209t @0,1
Mercassium 12.580t @0,9
Your mines will deplete Mercassium very quickly due to the low amount AND high extraction efficiency. Gallicite and Duranium would be depleted almost at the same time due to the combination of amount and extraction efficiency. But let's say that you do have a Gallicite shortage - how convenient would it be if you could focus the mines on this planet to gallicite for a while?
These focuses should be limited though. Max double the amount should be possible. So with focus added this would look like:
Duranium @0,4 Focus:0,5 =@0,2
Gallicite @0,2 Focus:2,0 =@0,2
Mercassium @0,9 Focus:0,5 = @0,45
You would lose 1/x of the efficiency of all other minerals but gain it for the one you want to focus on. Overall you would lose, but it could be a nice help if you get into a mineral crisis... .
Something that I really would like to have, mostly of RP purposes would be a standing order for patrolling a system. If a fleet is ordered for a patrol order they should more or less randomly move to mining sites, colonies or follow civilian ships in the system. They probably also should randomly set their speed to move relatively slowly as they are not suppose to burn their fuel too much, the idea is they should be out there patrolling.
They should not move to other systems but stay in the system where they are.
unsure if previously mentioned before:
commercial import and export of minerals for colonies via a set of radio buttons/dropdown list on the mining screen just below the CMC tax/purchase option
for import options:
A) do not import minerals
B) Import to reserve levels
C) Import mineral shortfalls [this is already calculated and displayed on the mineral screen as an orange highlight of a mineral]
D) Import everything in system
for export options:
A) do not export minerals
B) export to reserve levels
C) export everything anywhere
D) export to system only
Could lead to possible interempire trading as commercial fleets of friendlies and allies fill mineral movement contracts and the ghost minerals from tax CMC's are sent to friendly empires.
as usually i'm unsure how much of the current trade code would be applicable to such a idea.
It's quite inconsistent now that the most natural type of armoured battle machines (those with mixed weapon, smth like main battle tanks and assault armoured machines), just as the most natural types of battle orders (mixed ones too - infantry with battle machines and mixed weapon types) are rather meaningless against most of decent, nearly-equal-tech enemies, at least during assault or meeting engagement, because with current ground battle model they have no option to select their targets, and so relatively low fire performance of armored battle machines makes them nearly useless in the beginning of battle with it's huge numbers of small targets. Battle machines with this ground battle model have only a niche of baffle pursuit force: elements, that are designed for the finishing blow against enemy's survived armored machines in the end of long, multistage battle.
To give them an ability to contribute in battle from it's beginning and to open a niche of midsized assault machines, I'd suggest to change battle model in two ways:
1. More dividing of front line and battle phase, so that each battle location will be separated from direct fire of units, placed on other locations, and, on the other hand, each battle phase divided to more successive (iterative) subphases.
2. Confined breakthrough rule can be added to these subphases, adding assaulting units an ability to continue an advance, while their opponents are suppressed. Confined breakthrough might be different from full breakthrough in that during subphases there is no ability to change opposing formation or even location, so assaulting subformation is just continue to push with their high-morale units againt opponent in the same location. That will make those units with high armour levels effectively more fire performance and give armors their natural assault role, instead of finishing blow tool in the most intense battles they are now.
Such a mechanic wouldn't be useful for inter-system trade, true, but extremely valuable for planets in other systems. I currently use cheap light traders to try and make all minerals available to system capitals and distribute them via mass drivers from their, but it is a very inexact science with the current tools available.
Since cities are too unreliable, I'd like to put my own ships under the control of a personal shipping company controlled by the civilian AI that always takes our shipping contracts and nothing else. Be a good dumping ground for obsolete freighters I cant convert.
I don't agree with the assessment here. Rather opposite, I think it is good that mixed machines/formations are not appreciably superior to monoform.
I don't agree with the assessment here. Rather opposite, I think it is good that mixed machines/formations are not appreciably superior to monoform.
My point was not that they are not appreciably superior to monoform. My point was that they are obviously inferior to monoform both in the first and the final phases of battle.
You say you want an RP freedom and less micro durinf grounf battles and less penalties with efficiency? Well, what I proposed is serving your declared goal exactly: you'll have much easier way to balance army against averaged opponent, while more scurpulous player will have their complicated toys too.
In what way are they obviously inferior? The only thing I am really aware of is that mixed CAP and AV are more GSP-heavy than using CAP and sending in AV after the enemy infantry are dead, which is admittedly not ideal but a fairly small issue in relative terms.
It's quite inconsistent now that the most natural type of armoured battle machines (those with mixed weapon, smth like main battle tanks and assault armoured machines), just as the most natural types of battle orders (mixed ones too - infantry with battle machines and mixed weapon types) are rather meaningless against most of decent, nearly-equal-tech enemies, at least during assault or meeting engagement, because with current ground battle model they have no option to select their targets, and so relatively low fire performance of armored battle machines makes them nearly useless in the beginning of battle with it's huge numbers of small targets. Battle machines with this ground battle model have only a niche of baffle pursuit force: elements, that are designed for the finishing blow against enemy's survived armored machines in the end of long, multistage battle.
To give them an ability to contribute in battle from it's beginning and to open a niche of midsized assault machines, I'd suggest to change battle model in two ways:
1. More dividing of front line and battle phase, so that each battle location will be separated from direct fire of units, placed on other locations, and, on the other hand, each battle phase divided to more successive (iterative) subphases.
2. Confined breakthrough rule can be added to these subphases, adding assaulting units an ability to continue an advance, while their opponents are suppressed. Confined breakthrough might be different from full breakthrough in that during subphases there is no ability to change opposing formation or even location, so assaulting subformation is just continue to push with their high-morale units againt opponent in the same location. That will make those units with high armour levels effectively more fire performance and give armors their natural assault role, instead of finishing blow tool in the most intense battles they are now.
I don't agree with the assessment here. Rather opposite, I think it is good that mixed machines/formations are not appreciably superior to monoform. This allows players to design units and formations according to whatever RP they wish without having to worry too much about deploying a "suboptimal" configuration.
Further, even if there is no tangible difference between mixed formations and mixed forces of monolithic formations, there is still a clear value in having combined arms in some capacity whether this means at the company/battalion level or by landing one armored division for every two infantry divisions to make an assault.
The topic of random vs selective targeting has been debated as nauseum in many threads by now. I will only say that personally I largely prefer the ground battle system as it is, due to its simplicity and general friendliness to RP over minimaxing. I personally would consider accurate targeting something of a restrictive headache, depending on its implementation, and certainly don't want to deal with a complicated frontage system in my game that was advertised as being about spaceships.
No... the best units in the game are specialised units and you ALWAYS want to keep your heavier guns in reserve until you eliminated most of the lighter enemy units. (medium vehicles with heavy or medium guns is awesome for their cost to fight enemy vehicles this way). This creates a rather boring micro intensive way to conduct battles. If you assault a world you should basically keep your heavy gunned units in orbit so they don't waste shots and thus LOG units against enemy infantry they will not hit anyway and even if they hit them it is not wort it. Once most of the enemy infantry is taken care of by your CAP and HACP equiped heavy vehicles and infantry you retire most of the CAP vehicles and land the vehicles and heavy artillery with the heavy guns to blast all of the heavy enemy stuff upp.
This is the effect of random targeting. The current mechanic only allow RP on the surface due to how the mechanic work.
I NEVER do this in the game as the AI don't do it and when I play multi-faction it certainly is not fun doing it. But... from a pure mechanic purpose this is what you should do!!!
I remember this from the last thread on the subject.
In my mind, the issue here is essentially that mixed formations will run out of supplies faster, which is not optimal but can be managed by bringing more LOG units along, at least in theory. Combat efficiency is not strongly affected as far as I am aware.
On the flip side, if we change the targeting system to be "perfect", for sake of example we'll say every weapon always targets the largest element it has 100% kill chance or as close as possible against, the system becomes much less RP-friendly as now the balance swings completely towards monolithic formations. If an enemy has, say, 50% CAP and 50% MAV weapons by tonnage, with perfect targeting the optimal approach is to send only one kind of unit which renders one of those two weapon types ineffective, either infantry to render the MAV minimally effective or heavy armor to neutralize the CAP. This is then the same issue as we already have except that the determining factor is combat efficiency, not supply efficiency, which I at least would consider a much worse problem to have.
Given that no system can be perfect, and there have been quite contentious discussions about this in the past I think the present system is at least satisfactory, and certainly I do not want to see ground combat become even more micro-intensive nor do I want to always be designing my formations with an eye towards maintaining some optimal ratio of forces to frustrate enemy targeting.
No... it is not just LOG units but this is actually a VERY large saving as heavy wepaons will consume huge amounts of GSP in comparison to CAP or HCAP weapons.
I have actually done testing and the difference can be quite substantial even if you disregard LOG units. Just the fact the the enemy waste all their shots on mostly low value units of yours and you increase the amount of infantry versus tanks and your tanks are less likely to be hit by enemy AT weapon. Once the enemy infantry has been whittled down you add your AT tanks and withdraw the CAP/HCAP tanks and now your heavy weapon have great effect. If the enemy have little or no tanks or heavy vehicles then there is almost no reason to use your heavy weapon units at all.
From a mechanic point of view mixed weapon units is rather bad. You can have mixed formations, that is fine. You can add and remove elements as you see fit during a battle from your formations.
You also can't underestimate the importance of the cost of LOG units... they are neither cheap or small in size... why not bring more small arms fire to kill the enemy infantry faster rather than bring more LOG units. It is a pure math question, that is the problem with random targeting... it becomes mostly relatively easy math.
If the targeting was a bit more unpredictable I think it would add to the the game. This could be attained through some event system. This could be tied with the planets type, terrain or the general colony typed and infrastructure on the colony. This way mixed units and mixed formation could become more important and support RP a bit more.
I think just adding a rule that heavy weapons on units withhold fire if the formation they fire on is too weak could make this much less pronounce and mixed weapon units (and formation) less of a drawback to use. A heavy weapon should only fire under some specific circumstance. This could be both up and down the scale. You could also flag a formation to always fire no matter what as an option.
%Chance to Fire = ( Base_Armour / Base_Penetration ) * ( Base_Hitpoints / Base_Attack )
applied after a target is chosen. Using base, not racial, stats so that a tech-based overmatch doesn't cause units to avoid firing because they would kill the low-tech enemy too hard or something. For example a MAV targeting a basic INF element would only fire 1/16 of the time. This could of course be modified to use an average, square root, etc. to get the desired balance, and random targeting can be retained which avoids the problems of selective targeting and keeps things "unpredictable".Could just have an 80% chance that your vehicle will target an ideally suited target to its weapon (or closest match) instead of being completely random or completely predictable.
This is enlightening. If there is a serious difference in combat performance that's a different matter.
I really like the rule suggestion at the end here since that could be applied asymmetrically. In other words, you could prohibit or at least limit how much heavy weapons fire at small targets while not limiting how much CAP and other light weapons fire at heavy targets, which preserves the role of armor as, well, armor - for the infantry. Something like:
%Chance to Fire = ( Base_Armour / Base_Penetration ) * ( Base_Hitpoints / Base_Attack )
applied after a target is chosen. Using base, not racial, stats so that a tech-based overmatch doesn't cause units to avoid firing because they would kill the low-tech enemy too hard or something. For example a MAV targeting a basic INF element would only fire 1/16 of the time. This could of course be modified to use an average, square root, etc. to get the desired balance, and random targeting can be retained which avoids the problems of selective targeting and keeps things "unpredictable".
What strikes me as clever about this rule is that it "fixes" the targeting problem without reducing the defensive efficiency of mixed formations very much - the heavy weapons conserve ammo by not firing at infantry (very often), but the infantry still "distracts" the heavy weapons from shooting friendly armored units so that mixed formations remain efficient for blunting enemy firepower.
Could just have an 80% chance that your vehicle will target an ideally suited target to its weapon (or closest match) instead of being completely random or completely predictable.
It seems I have failed to provide understandable explanation of what and why I have proposed. Let me try to reformulate it.
Random targetting leads to the effect we discuss here only in combination with an ability to "change lines" during combat. You see masses of enemy infantry and/or light vehicles - you bring your infantry and AP vehicles. You see "naked" armored machines - you bring your AV weapons.
What I proposed - is to effectively take away this ability to change lines. During subphase fights player will have no ability to change front line forces. Iterative fights during long combat phase will bring a necessity to keep every frontline formation mixed, because if your formation will have only AP weapons - it will win first subphases and fail against armored core of enemy formation in the end, and if your formation will have only AV weapons - it'll fail at the beginning. Bring random division of local battle groups - and you'll have much more dispersion of probable results, so lesser temptation of micro-calculating even if you have full knowledge of enemy forces (though this calculation will be available for those, who can do such things, but it will give them lesser advantage per hour of math work, and they'll have no obvious, easy, boring solution from the first glance, that we are obliged to close our eyes at, if we have to play with more interesting formations). This semi-random division of locations and iterations of fights will also bring deeper, however nearly hidden battle stories at the background - we'll know why we must send mixed forces, we'll have no need to close our eyes an envision things that will contradict with game screen. It will be just more RP-ish battle mechanics per se.
I strongly prefer Jorgen's suggestion about a rule which prevents or limits heavy weapons from firing at small targets. This is a simple change that solves most of the existing mechanical issues while preserving player agency and RP ability. No need to overcomplicate things when a simple tweak will solve it.Personally I prefer this too. But Steve obviously doesn't go this way (I don't know why, there must be some reasons), so I proposed to go the way Steve already moved, but to move farther.
I strongly prefer Jorgen's suggestion about a rule which prevents or limits heavy weapons from firing at small targets. This is a simple change that solves most of the existing mechanical issues while preserving player agency and RP ability. No need to overcomplicate things when a simple tweak will solve it.Personally I prefer this too. But Steve obviously doesn't go this way (I don't know why, there must be some reasons), so I proposed to go the way Steve already moved, but to move farther.
Instead of mounting weapon systems to fighters and small craft during design, allow us to add 'hardpoints' which can mount weapons and other systems, such as ECM or refuelling, etc...
Instead of mounting weapon systems to fighters and small craft during design, allow us to add 'hardpoints' which can mount weapons and other systems, such as ECM or refuelling, etc...
If this were implemented in some form it could not be for small crafts only but for all ships. Fighters in Aurora are not the difference between a jet fighter and a naval ship, they are all the same. Steve have been quite thorough during the development of C# to not build exceptions to different rules bit consistent general rules and mechanics.
Not saying it is a bad idea... I would like for ships to have possibility for more modular components as that is realistic.
I also would like to have a system of a bit more restriction when building ships to as to some degree we have a bit too much freedom sometimes which sometimes actually limit our actual choices as there are too many bad ones. I would like some hull integrity value to be applied and different components will require different hull integrity or that components will require more or less space consideration in regards to internal or external positioning. Some components would compete more for the same space others will not etc... this way a "figter" would have more external space than internal than for example a 10kt Destroyer would, for the same reason how armour work... Armour would take both its space from external and from internal, but in actuality that usually mean less space available from external components in relation to its size.
Anyway... more modular components would be nice. Values for hull integrity and weight to satisfy it (based on technology) and a difference of internal and external space for components would make ship design even more interesting in my opinion. More complex... yes... but I think we could handle it.
A simple 'figure of merit' that would vary with ship size would be a surface/volume ratio. If one assumes ships to be spherical (or even ellipsoidal), that ration would be easy to calculate for a given tonnage and would vary pretty smoothly with ship size.
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.
I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.
If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.
I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.
If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.
I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.
Would it be possible to get checkbox for ground units to not show on the list of units when loading ground troops to transports? I have garrison troops on my planet that I have no intention to move and I have to scroll through them to find my assault units.
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.
I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.
If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.
I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.
What about when your ship (or the bad guy) takes internals and the power plant goes? Unless he has gauss or missiles, he's mission killed.
Decline arbitrary tonnage margins between fighters, FACs (w/o bridge) and ships (with bridge), with these changes to ship mechanics:
1. Bridge component reveals an ability to add other command components and makes Crew Quarters 3 times more effective (that are 3 watches, and without command components you cannot relieve watch for commanding personnel, because your Crew Quarters are the only action stations available for them).
2. Add a property "max spacecraft size able to take off" for any planet, dependent on it's mass or gravity. Colony and spacecraft design windows to show these properties accordingly.
3. Fighter Factories becoming Shipbuilding Factories, able to produce space components and build unarmored (yet-to-be-assembled by shuttles) stations and any spacecraft, that can take off this planet.
4. Construction Factories becoming unable to produce spacecraft components and unarmored stations, they are to build surface objects only.
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.
I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.
If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.
I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.
What about when your ship (or the bad guy) takes internals and the power plant goes? Unless he has gauss or missiles, he's mission killed.
If the only purpose of a component is to introduce a weakness, I question the inclusion of that component in the game.
Reactors to me already struggle to make sense since the rest of the ship components are generally considered to be "powered" by the ship's engines. Beam weapons are the only component that apparently needs a separate power source, and that power source is arguably the most boring component in the game when combining the design and "what does it do" elements (as plasma carronades at least shoot at things which is fun).
I'd also be happy with an alternative rework that made all ship systems require reactor power, but I doubt that ever happens.Decline arbitrary tonnage margins between fighters, FACs (w/o bridge) and ships (with bridge), with these changes to ship mechanics:
1. Bridge component reveals an ability to add other command components and makes Crew Quarters 3 times more effective (that are 3 watches, and without command components you cannot relieve watch for commanding personnel, because your Crew Quarters are the only action stations available for them).
2. Add a property "max spacecraft size able to take off" for any planet, dependent on it's mass or gravity. Colony and spacecraft design windows to show these properties accordingly.
3. Fighter Factories becoming Shipbuilding Factories, able to produce space components and build unarmored (yet-to-be-assembled by shuttles) stations and any spacecraft, that can take off this planet.
4. Construction Factories becoming unable to produce spacecraft components and unarmored stations, they are to build surface objects only.
I agree the limits are a bit arbitrary but I dislike these proposals to address them.
(1) if I understand it correctly would not have the desired effect as it represents a nerf to FACs and fighters. I would suggest as an alternative that the definition of a FAC (not fighter) be defined in terms of a maximum crew count which can be commanded without a bridge module, probably with a tech to increase this limit over time as components become more complex. This would be simpler and since the FAC definition does not interact with other game mechanics it is okay to change this.
(2) would add needless complication as now I cannot just design my fighter craft to a given standard, I have to arbitrarily limit tonnage based on which planet(s) I want to build them on. This reduces player flexibility, and also doesn't play neatly with the fact that the game needs a consistent definition of a "fighter" e.g to correctly apply the commander skill for Fighter Combat. As arbitrary as it may seem, having a round tonnage mark for "fighter" definition is good for gameplay and an acceptable abstraction.
(3) and (4) again place restrictions on the player where currently there exists an interesting choice, mainly (4) as currently the choice of what to use construction capacity on is a relevant one in many cases. Why remove decision making from the player? (3) by itself is probably okay as I wouldn't mind making fighter factories more interesting.
I agree that power plants as they are currently aren't very interesting. Making them have uses outside of beam weapons and just power the whole ship in general makes more sense to me.
It allows you to do more things with power plants - they might be made to have their own fuel requirements with boosting decreasing fuel efficiency much like engines
Every ship could also be made to have batteries so that if the generator goes, the ship has some life support left before everything shuts off, now you might want to avoid firing some weapons to ration power.
Each beam weapon benefits from power surplus, some may hit harder, others may shoot more shots and some may be able to fire further by drawing extra power, shields that have extra power may be able to recharge faster than normal.
Hell you could configure a design to "overclock" its life support, using more power but making crew quarters more efficient with an increased chance for maintenance failures for them.
Having power act as a ship-wide resource instead of a beam weapon "reload rate" opens the grounds for a lot of interesting tactical decisions IMO.
(1) if I understand it correctly would not have the desired effect as it represents a nerf to FACs and fighters.
I would suggest as an alternative that the definition of a FAC (not fighter) be defined in terms of a maximum crew count which can be commanded without a bridge module
(2) would add needless complication as now I cannot just design my fighter craft to a given standard, I have to arbitrarily limit tonnage based on which planet(s) I want to build them on.
and also doesn't play neatly with the fact that the game needs a consistent definition of a "fighter" e.g to correctly apply the commander skill for Fighter Combat. As arbitrary as it may seem, having a round tonnage mark for "fighter" definition is good for gameplay and an acceptable abstraction.
(3) and (4) again place restrictions on the player
Suggestion:This is how they worked back in VB6 and I believe how they're supposed to work now, they're just bugged.
1. Make missiles with sensors that are not controlled by a missile fire control pick targets using a weighted selection process like how the "Fire at Will" command for missile fire controls will work in 1.13, except make it so it uses the sensors the missile has, IE if missile has thermal sensors, the weighting is thermal signature/distance, if it has EM sensors then it uses EM signature/distance, etc.
2. Make it so that if a missile is fired at a target and the target is destroyed, the missile will continue heading on its current path, instead of just stopping in space
This way, missiles with sensors won't all hit the same ship in an enemy fleet, and it will actually be possible to use them when chasing an enemy fleet, instead of the sensors only being useful when running from an enemy fleet.
This is how they worked back in VB6 and I believe how they're supposed to work now, they're just bugged.
Have an idea about heavy weapon supply problem.
Suggestion is to make any weapon to do supply roll against it's target armour*HP, not against weapon's own GSP (that will be max GSP instead of constant GSP).
That's not ideal, not as if it will be some sort of anti-personnel shells, that will be able to kill several units of the same element, proportionally to shell power, and targetted specifically at largest units and elements, but this first rule might be much simpler to code.
I'm sure it's been suggested before, but to bring it back to your attention:This could only be an estimate as the distance is never precisely known, because destinations can move.
I would like some kind of visual indicator regarding the fuel needed to fulfill the orders assigned to a fleet. A simple indication in the naval organization> fleet tab (maybe next to the all orders distance and travel time required) that indicates in red if the fleet lacks enough fuel to finish all current orders or yellow if it passes the point of no return.
This would definitely help us better plan routes and avoid stranded fleets out of fuel in the middle of nowhere.
First Suggestion:Mothballed ships were a thing in VB Aurora, but were removed. Searching the VB threads would tell you why. I don't recall and I'm not sure which version it was removed in.
The ability to mothball ships and demobilize ground units.
Mothballed ships would take up 1/100th of its usual maintenance capacity, require no crew or officers, and be drained of all its fuel, munitions, and MSP. It will, however, run down its maintence clock at 1/10th the speed of normal regardless of maintence facilities present.
Demobilized ground units will maintain only a fraction of their strength and cut down on the financial burden of keeping them dramatically. They also do not need officers. Once mobilized however, they require some time to get back up to fighting strength.
First Suggestion:Mothballed ships were a thing in VB Aurora, but were removed. Searching the VB threads would tell you why. I don't recall and I'm not sure which version it was removed in.
The ability to mothball ships and demobilize ground units.
Mothballed ships would take up 1/100th of its usual maintenance capacity, require no crew or officers, and be drained of all its fuel, munitions, and MSP. It will, however, run down its maintence clock at 1/10th the speed of normal regardless of maintence facilities present.
Demobilized ground units will maintain only a fraction of their strength and cut down on the financial burden of keeping them dramatically. They also do not need officers. Once mobilized however, they require some time to get back up to fighting strength.
First Suggestion:Mothballed ships were a thing in VB Aurora, but were removed. Searching the VB threads would tell you why. I don't recall and I'm not sure which version it was removed in.
The ability to mothball ships and demobilize ground units.
Mothballed ships would take up 1/100th of its usual maintenance capacity, require no crew or officers, and be drained of all its fuel, munitions, and MSP. It will, however, run down its maintence clock at 1/10th the speed of normal regardless of maintence facilities present.
Demobilized ground units will maintain only a fraction of their strength and cut down on the financial burden of keeping them dramatically. They also do not need officers. Once mobilized however, they require some time to get back up to fighting strength.
I don't think it ever existed in Aurora - IIRC it was one of the design decisions at the outset. It DID exist in Starfire Assistant tho, and was perceived to cause some difficulties there as players could build ships straight into mothballs, building up huge reserves that could be reactivated very quickly (at about 45% of the cost of a new build), which meant that it was economically beneficial if the unit was not paying maintenance for 5+ turns. There was a bit of a risk in that the unit might be behind the current tech level but I think you could refit while in mothballs which would mitigate that.
I think we need an installation that can increase or decrease surface temperature i.e. orbital mirrors.
I'm trying to make one of Minerva's moons a bit more habitable but I can only raise its temperature by 30 degrees with 5 atm of aestusium.
I think we need an installation that can increase or decrease surface temperature i.e. orbital mirrors.
I'm trying to make one of Minerva's moons a bit more habitable but I can only raise its temperature by 30 degrees with 5 atm of aestusium.
I think we need an installation that can increase or decrease surface temperature i.e. orbital mirrors.
I'm trying to make one of Minerva's moons a bit more habitable but I can only raise its temperature by 30 degrees with 5 atm of aestusium.
I believe the max atmo is 3 for gaining any effect of Greenhouse or Anti-G gasses. Just fyi, you can move the Terraformers on to the next project at that point.
Hi ladies,
what do you think of going full Star Wars and adding planetary shields to the game? They would make a great addition to planetary defense and could help preventing some collateral damage from bombing.
Why oh why is "Salvage nearest wreck" a galaxy-wide standing order?
- Can we bring back the button that let's us Research all techs up to a certain RP cost?Super second
Is there a way to generate two separate "person has died" message? Usually, I ignore when a person dies or leaves his service because I don't need to react to it. But that is of course totally different when a character in an important position dies. Like a sector commander etc. So, is there a way you could separate that somehow into two different kinds of "death" messages so we can color code the one we need to react to?
Can we have planet based shield generators like in Star Wars during the attack on Hoth? It might destroy the balance between ships and STO units though.
Can we have planet based shield generators like in Star Wars during the attack on Hoth? It might destroy the balance between ships and STO units though.
I don't think planetary shields would fit well, as presumably they would take damage from every shot and be destroyed very quickly. STOs and other ground units have as their principal defense from orbital fire a high fortification level that makes them very difficult to hit. The alternative is incredibly strong shields which would definitely make STOs overpowered as things currently stand, they already gain a 25% range bonus over ship weapons.
Obviously not a small change so nothing to take lightly... :)The construction yards have all of that build in. They do the research while they construct the first ship or retool for it.
Obviously not a small change so nothing to take lightly... :)The construction yards have all of that build in. They do the research while they construct the first ship or retool for it.
Well, that is just my in-lore explanation. And research is already jam packed and for my taste a too strong factor in "winning the game"... I don't think we should put more on this factor.
I still think it'd be really handy to have some way to automatically number Hulls in a class, while still having the ship's have Given names. It's just dang useful to know which ships are older and which ships are newer.
Max Population Factor:
Aurora basically simulates only population which is capable of working productively. Children and older people are not modelled. Thinking that through I was wondering of the actual pop max of 12B for Earth isn't too large. Let's say that we actually have around half of the worlds population in the worker age bracket, that would mean that a maxed out earth in Aurora would have 24B people living here.
Whilst maybe possible, having 12B workers seems to me to be too much in terms of the production values Aurora has. How many 10.000 over 10.000 of production factories could earth have?!?
So I was thinking about adding some kind of population factor: Humans for example do have 0.5. So max pop would still be 12B, but only 6B of them would be in the worker age bracket. And so on.
Other races could perhaps have a factor of 0.7 - and thereby be better of with larger populations. Or 0.3 and have to compensate for their lack of production with massive pop growth... .
snip
I'd like to see a similar thing for ships. If I have officers available and captainless ships, it should match them up, even if the ranks might not make sense. I am more upset by seeing an idle admiral and a commanderless corvette than I would be by seeing an admiral commanding a corvette.
My current game is locked into 6 hour increments due to NPRs. I really, really wish that we could have our time increments not be disturbed by their activity. I'm not even talking about when it goes down to 5 seconds because I understand computing battles must be harder on the game, but when nothing's happening, I really wish I could play with 5 day increments again.I proposed a workaround for that earlier. Take a read, and if you want you can quote it and give me feedback.
in the global modifiers, i'd love to be able to modify (specifically increase) gate building time, and i'd love to be able to modify (specifically decrease) jump drive size (and by extension cost)
3 Minor Suggestions:
I) A 5 HS refuel system with 5000 LPH For Fighters and FAC's. Intent is a refuel system useful for small craft but too slow of refuel rate to be of any use on larger ships.
II) Squadron Transit Distance Applies to Departure system in addition to Arrival system. Intent is allow for rapid retreats or raiding parties to evade possible jump pickets.
III) Casemates options for non-turret weapons. Intent is to increase HTK for weapons such as missile launchers, railguns, plasma cannonades, and etc. by armoring them up.
I was thinking about and hoping for a jump point deconstruction module or a weapon of sorts that does the job. It would allow for scorched earth tactics and maybe close a jump point or stabilized intra-system jump point before an enemy fleet can follow.
There are quite a few useful applications for this in defensive warfare against superior empires.
Ha, wasn't the reason for changing from gates to stabilizers so that people would stop asking for a way to destroy them?I was thinking about and hoping for a jump point deconstruction module or a weapon of sorts that does the job. It would allow for scorched earth tactics and maybe close a jump point or stabilized intra-system jump point before an enemy fleet can follow.
There are quite a few useful applications for this in defensive warfare against superior empires.
Since they are no longer physical gates, that is why you cannot destroy them. A destabilizer would be nice :)
Ha, wasn't the reason for changing from gates to stabilizers so that people would stop asking for a way to destroy them?:D
snip
II) is not a simple change, and would need to be balanced by a corresponding change so that smaller ships can jump farther than big ones. Otherwise it becomes trivial to evade JP pickets with even very large fleets - why send a raiding party when you can send the entire invasion?
snip
snip
II) is not a simple change, and would need to be balanced by a corresponding change so that smaller ships can jump farther than big ones. Otherwise it becomes trivial to evade JP pickets with even very large fleets - why send a raiding party when you can send the entire invasion?
snip
It would scatter the entire invasion force around the arrival system jump point in small packets perfect for defeat-in-detail.
For a small group of stealth raiders I would risk it.
A planetary invasion taskforce with specialized Combatants it could be risky on how the ships get scattered and in which directions they get placed..
I was thinking about and hoping for a jump point deconstruction module or a weapon of sorts that does the job. It would allow for scorched earth tactics and maybe close a jump point or stabilized intra-system jump point before an enemy fleet can follow.Yes, let's go "Deep Space Nine" all the way: destabilise the worm hole entirely and collapse it :-)
There are quite a few useful applications for this in defensive warfare against superior empires.
Okay here is the pettiest and most minuscule of requests ever made.....can we get the stars recolored to reflect their true color, i.e yellow, red, orange, blue, white based off their type? It is the smallest of things but I think it would be a cool low impact way to differentiate the systems visually.
Regarding box launchers vs 'regular' launchers, what if 'regular' missile launchers were allowed to build up a salvo of missiles by jettisoning them into space and then allowing the missiles to sit and wait until the full salvo is ready to go?
It may or may not wind up being overpowered, but I would note that it would result in a tradeoff where you would potentially want to build ships that are relatively bad at short ranged combat (if suddenly finding themselves at close range then they cant launch a big salvo quickly) but which are highly specialized into long range combat.
This might also justify a degree of differentiation between box launchers and reloading launchers, if it were said that the reloading launchers are capable of releasing missiles without requiring them to ignite their engines, whereas box launchers due to their generally light weight and simplified construction aren't equipped to be able to do that (the missile needs to leave under its own power).
e: 'regular' in quotes because i think box launchers are currently a lot more common
Realistically you could just build a ship with more surface area
Realistically you could just build a ship with more surface area
And by doing this you will shoot yourself in the foot. You would need significantly more armor and huge parts of the hard points on your vessel would be in locations without line of fire.
Realistically you could just build a ship with more surface area
Realistically you could just build a ship with more surface area
The problem is that from a "realistic" or "practical" perspective it would likely pose very large problems with hull integrity, armour, usage of crew space, engineering, and fitting the engine to allow for the ship to move efficiently. No complex vehicle is that easy to design and I don't believe they actually are in Aurora either.
I'm just saying that ships likely are built in certain shapes for a reason... this is the problem when we get free reign to fit whatever we want with no regards to what is practically actually possible from an engineering perspective.
It makes sense that components can't just be placed anywhere on a ship and box launchers are a pretty good examples of this. Imagine that the ship is a sphere which is the basic shape of the ships and go from there. Not saying that ships in Aurora are spheres... but I presume they have a relatively large interior space for a reason, armour and hull integrity probably being the biggest reasons for this and probably also for making the engines as effective as possible as in Aurora the volume of the ship is the most important factor.
There is no problem with role-play these limits... I do that all the time. But it would give somewhat more balance to ship design in general.
Should probably be able to pay for more armor if I so desire
Should probably be able to pay for more armor if I so desire
Just add more layers?
Should probably be able to pay for more armor if I so desire
Just add more layers?
I think Jorgen was referring to the idea of limited surface area for the ships to try to constrain box launchers, so I was saying I'd be willing to accept paying for more armor in exchange for more surface area.
Okay here is the pettiest and most minuscule of requests ever made.....can we get the stars recolored to reflect their true color, i.e yellow, red, orange, blue, white based off their type? It is the smallest of things but I think it would be a cool low impact way to differentiate the systems visually.
Ha, wasn't the reason for changing from gates to stabilizers so that people would stop asking for a way to destroy them?
Ha, wasn't the reason for changing from gates to stabilizers so that people would stop asking for a way to destroy them?
Yes :)
There was an autoсalculated field in VB Aurora's Class Design window named Power Required - it was very helpful, especially for new players, and for anyone who doesn't have a fun with routine arithmetic.
Will be cool to have it in C# again.
(1) Preferably, remove the Ground Combat Command skill from the game. This has been discussed many times and the general consensus is that is a limiting, unfun mechanic (or it would be, if it worked) which functions uniquely to every other skill in the game which are strictly bonuses.
(1) Preferably, remove the Ground Combat Command skill from the game. This has been discussed many times and the general consensus is that is a limiting, unfun mechanic (or it would be, if it worked) which functions uniquely to every other skill in the game which are strictly bonuses.
Yes, I agree on this. I had forgotten the bonus existed, but you are right that it is a limitation without adding any meaningful decisions. I've removed it for v1.13.
I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.
I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.
This could probably work automatically, similar to naval auto-assign, by simply applying special cases based on the type of the single largest formation element (by total weight). E.g. in a 5,000-ton formation with 3,000 tons of INF+PW and 2,000 tons of LVH+CAP the formation is typed as "infantry".
Suggested bonuses to consider would be:
- If the major element has a STO weapon, no commander should be assigned
- Artillery bonus if the major element has a bombardment weapon
- AA bonus if the major element is an AA weapon
- PRD/SRV/XEN bonus if blah blah blah...
- Manoeuvre bonus if the major element of the formation is a Vehicle type which does not meet one of the above classifications (assuming the formation is tanks, etc.)
- Otherwise no special bonus is preferred and a formation is assumed to be INF or STA and given any remaining commanders
Skills like GC Offense, Defense, Training, Logistics are useful for nearly all formation types and do not need specialization rules. GC occupation can be neglected.
I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.
This could probably work automatically, similar to naval auto-assign, by simply applying special cases based on the type of the single largest formation element (by total weight). E.g. in a 5,000-ton formation with 3,000 tons of INF+PW and 2,000 tons of LVH+CAP the formation is typed as "infantry".
Suggested bonuses to consider would be:
- If the major element has a STO weapon, no commander should be assigned
- Artillery bonus if the major element has a bombardment weapon
- AA bonus if the major element is an AA weapon
- PRD/SRV/XEN bonus if blah blah blah...
- Manoeuvre bonus if the major element of the formation is a Vehicle type which does not meet one of the above classifications (assuming the formation is tanks, etc.)
- Otherwise no special bonus is preferred and a formation is assumed to be INF or STA and given any remaining commanders
Skills like GC Offense, Defense, Training, Logistics are useful for nearly all formation types and do not need specialization rules. GC occupation can be neglected.
Yes... I think that could work pretty well and I'm not sure if this is not already the case or not... but it seem to me most of the time that they are randomly put in charge of formations but I can be wrong.
There also are the Tactical skill which should be applied to STO formations, but this skill seem super rare and it also is not in the sorting list for some reason so perhaps it does not work properly. I think the Tactical skill should be more common for STO formations.
I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.
This could probably work automatically, similar to naval auto-assign, by simply applying special cases based on the type of the single largest formation element (by total weight). E.g. in a 5,000-ton formation with 3,000 tons of INF+PW and 2,000 tons of LVH+CAP the formation is typed as "infantry".
Suggested bonuses to consider would be:
- If the major element has a STO weapon, no commander should be assigned
- Artillery bonus if the major element has a bombardment weapon
- AA bonus if the major element is an AA weapon
- PRD/SRV/XEN bonus if blah blah blah...
- Manoeuvre bonus if the major element of the formation is a Vehicle type which does not meet one of the above classifications (assuming the formation is tanks, etc.)
- Otherwise no special bonus is preferred and a formation is assumed to be INF or STA and given any remaining commanders
Skills like GC Offense, Defense, Training, Logistics are useful for nearly all formation types and do not need specialization rules. GC occupation can be neglected.
Yes... I think that could work pretty well and I'm not sure if this is not already the case or not... but it seem to me most of the time that they are randomly put in charge of formations but I can be wrong.
There also are the Tactical skill which should be applied to STO formations, but this skill seem super rare and it also is not in the sorting list for some reason so perhaps it does not work properly. I think the Tactical skill should be more common for STO formations.
As far as I can tell it is random aside from a check on GC Command which is to be removed. If it's not Steve can feel free to correct me and give us all peace of mind.
I don't think I've ever yet seen the Tactical skill show up on a ground commander even once, though I have heard of it, so I discounted it. Of course if it does exist STOs should receive Tactical commanders with a top priority as they are after all the first line of ground defense for a colony.
I would like to suggest changing the research point (RP) cost for ground force headquarters units be changed to scale with the square root of command size instead of the current (linear?) model.I'd say the game will benefit if all research point costs of components/weapons will be SQRT or even LOG2 from the size.
I would like to suggest changing the research point (RP) cost for ground force headquarters units be changed to scale with the square root of command size instead of the current (linear?) model. I think the current model makes large command units prohibitively difficult to research, field, and upgrade. If scaled with SQRT of command size small HQ units would not be drastically different than they are now but large HQ units would be much less expensive.
I would like to suggest changing the research point (RP) cost for ground force headquarters units be changed to scale with the square root of command size instead of the current (linear?) model.I'd say the game will benefit if all research point costs of components/weapons will be SQRT or even LOG2 from the size.
Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.
This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.
I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.
Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.
This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.
I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.
Personally I do not mind the linear costs in general, though I don't usually play with very slow research speeds so that may color my perceptions. Certainly I would not object to a square-root reformulation although I think logarithmic is more problematic than is worth it.
However, I do think that a few small tweaks to specific component research costs would solve most of the big issues, aside from engines. Jump Drives for example actually scale as size^1.8 which is why large jump drives are so ridiculously expensive, and while they are a critical component I don't think having a prohibitive research cost adds anything to the game as the major opportunity cost is always the lost tonnage aboard any ship which carries one. The other big example is ground unit HQ elements which have horribly outsized research costs compared to every other ground element, this has been discussed numerous times. Simply bringing these components into line with the other components/elements in the game will solve a lot of problems without requiring a wholesale rebalancing of the tech tree - less work for Steve, but still many benefits for all of us I think.
Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.
This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.
I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.
Personally I do not mind the linear costs in general, though I don't usually play with very slow research speeds so that may color my perceptions. Certainly I would not object to a square-root reformulation although I think logarithmic is more problematic than is worth it.
However, I do think that a few small tweaks to specific component research costs would solve most of the big issues, aside from engines. Jump Drives for example actually scale as size^1.8 which is why large jump drives are so ridiculously expensive, and while they are a critical component I don't think having a prohibitive research cost adds anything to the game as the major opportunity cost is always the lost tonnage aboard any ship which carries one. The other big example is ground unit HQ elements which have horribly outsized research costs compared to every other ground element, this has been discussed numerous times. Simply bringing these components into line with the other components/elements in the game will solve a lot of problems without requiring a wholesale rebalancing of the tech tree - less work for Steve, but still many benefits for all of us I think.
Yes... although I think Jump Drives is a good example on a research path that I like as it is not linear for a reason, this work really well.
For engines I generally just think that small engines should be more expensive and really big engines a bit less expensive. Larger engines are not that good for their cost in research most of the time.
For sensors I definitely want really small sensors to be more expensive because small sensors are very effective now and really large sensors are prohibitively expensive for what they are worth, especially in terms of research. An active sensor larger than size five I generally find to be very expensive for what you can do with it.
Sure... I almost always play with 10-20% tech rate so differences in tech cost are quit significant.
Most of what you are talking about could be solved using a RP=SQRT(size) methodology (i.e. small things are relatively expensive and big things are less so). This has the advantage of being simple and not terribly different the the current implementation.
If you wanted to make things REALLY interesting, I would suggest using a variation of RP = e^(size)*(sin(2*pi*size)+size). See here for plot of this function: https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29 (https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29)
This would make successive generations of research proceed in a rather nonlinear fashion, however later generations of research would be dramatically more expensive (and presumably better) than early generations. However successive generations of research would not be linearly 'better' or more expensive than previous generations.
NOTE: You could wrap the aforementioned RP='a bunch of math' thing in a SQRT function also, but that introduces some divide-by-zero singularities. These can be avoided by careful choice of RP values but I didn't want to go off the deep end on that tangent. An interesting variation is RP = sqrt(e^(size))*(sin(2*pi*size)+size)
LOG in particular is difficult because it has a sharp drop to negative infinity near zero
Most of what you are talking about could be solved using a RP=SQRT(size) methodology (i.e. small things are relatively expensive and big things are less so). This has the advantage of being simple and not terribly different the the current implementation.
If you wanted to make things REALLY interesting, I would suggest using a variation of RP = e^(size)*(sin(2*pi*size)+size). See here for plot of this function: https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29 (https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29)
This would make successive generations of research proceed in a rather nonlinear fashion, however later generations of research would be dramatically more expensive (and presumably better) than early generations. However successive generations of research would not be linearly 'better' or more expensive than previous generations.
NOTE: You could wrap the aforementioned RP='a bunch of math' thing in a SQRT function also, but that introduces some divide-by-zero singularities. These can be avoided by careful choice of RP values but I didn't want to go off the deep end on that tangent. An interesting variation is RP = sqrt(e^(size))*(sin(2*pi*size)+size)
I generally don't like the idea of using logs, exponentials, or anything else transcendental to determine RP as a function of size (or another size-like parameter depending on the tech under discussion). From the player-facing side they are just not intuitive or easy to noodle around in your head. Linear of course is very simple. SQRT is a bit more complicated but still simple enough to do head math - if I make an engine 4x as large it will cost 2x the RP, easy enough. With LOG, EXP, etc. there is no easy way to think of it mentally, while simple rational functions can be reasoned with.
From the developer side it is also quite difficult to balance these functions across a very wide range of sizes, tech levels, and so on. LOG in particular is difficult because it has a sharp drop to negative infinity near zero, a fairly small useful region of variation, and then for large arguments it barely changes even for wide differences in size. It is also a problem I think that whatever balance "fit" you use will work only for the existing data set, so to speak - if Steve decided for example to increase maximum engine or sensor size all component research costs would need to be redone. Something like SQRT doesn't really need to be fitted as it behaves the same over the entire range as long as you can't go to zero which is generally true for components.
LOG in particular is difficult because it has a sharp drop to negative infinity near zero
No matter the field, if you think about it hard enough you end up doing calculus.
This pleases me.
With this update being pretty fighter-focused, could we get the crew requirements once again scaled with deployment time as in VB6, so that fighters with deployment times measured in hours don't have like 30 crew members and the associated habitation space requirements?
Is it possible to change the way sensors and fire control systems work for STOs? Right now you can choose between range x4 speed x1 or vice versa. This is pretty restrictive. On top of that you have to use a single weapon beam fire control and cannot develop fire controls for a battery of guns.
These single weapon beam fire control restriction can even lead to situations in which the fire control + sensor is more expensive than it's carronade.
This would - finally - get players what many of us keep trying to do: include formations below the size commanded by a major - squads, platoons, and companies - and do so without gimping their battle effectiveness.
3c. Infantry armor is a really good buy at present (assuming armor tech is at least equal to the opposition's weapon tech). Consider increasing the cost a little bit, or applying a small disadvantage.
5b. The "Avoid Combat" checkbox is always waiting to trip you up. Do not apply it to AA or artillery; they will both hit in all forms of combat much less often. Request: please remove the "Avoid Combat checkbox and always apply it to, and only to, the appropriate unit types.
It'd be really nice to have industrial command & control modules for terraforming and mining ships, call it a "mining control center" or something. As it is, you either leave miner and terraformer commands to junior officers, who have a very high turnover, or have to micromanage by manually promoting officers with high mining & terraforming bonuses.
It'd be really nice to have industrial command & control modules for terraforming and mining ships, call it a "mining control center" or something. As it is, you either leave miner and terraformer commands to junior officers, who have a very high turnover, or have to micromanage by manually promoting officers with high mining & terraforming bonuses.
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.
Even if so, this is I believe a race-specific modifier so it will set the player behind the NPRs which may not be quite what is desired.
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.
Even if so, this is I believe a race-specific modifier so it will set the player behind the NPRs which may not be quite what is desired.
I'm pretty sure there is a global modifier and also a separate racial modifier.
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.
Even if so, this is I believe a race-specific modifier so it will set the player behind the NPRs which may not be quite what is desired.
I'm pretty sure there is a global modifier and also a separate racial modifier.
Nope. Global game settings only have Difficulty, Research, Terraforming, and Survey modifiers. You might be thinking of Construction Cycle Time which is not a difficulty modifier.
Racial settings include Population Density, Population Growth, Research Rate, and Factory Production - only the research rates overlap between both settings groups.
@Jorgen
Missiles are completely OP right now, given that everyone is using reduced-size or even box launchers. Requiring sensors would have a terrible side effect when it comes to AMMs, as these would have to bring a .25 size active sensor on top of the .25 requirement for ECCM. Taken into account that the sensors need a power plant we end up with horribly ineffective AMMs, as more than half of their tonnage is electronics.
Don't get me wrong. It would be a fantastic change for ASMs to be able to fire at enemy ships without having to rely upon active sensors, but Steve would have to rework the electronic warfare or the detection side of combat to make it counterbalance it.
I also would not say that missiles are OP... it is the box-launcher mechanic that is OP and it is on the player if they abuse it until Steve decide to change things. I have already outlined in other threads why using massed box launchers on big ships are unrealistic in the first place. ;)
[quote author=Jorgen_CAB link=topic=10640.msg149258#msg149258 date=1613823736
I also would not say that missiles are OP... it is the box-launcher mechanic that is OP and it is on the player if they abuse it until Steve decide to change things. I have already outlined in other threads why using massed box launchers on big ships are unrealistic in the first place. ;)
[quote author=Jorgen_CAB link=topic=10640.msg149258#msg149258 date=1613823736
I also would not say that missiles are OP... it is the box-launcher mechanic that is OP and it is on the player if they abuse it until Steve decide to change things. I have already outlined in other threads why using massed box launchers on big ships are unrealistic in the first place. ;)
On the last part this isnt completely true as for every weapon activation (thats not for PD) theres a 1% chance of a beam weapon breaking same with a missile launcher, while this wont break the bank it can in certain circumstances such as orbital bombardment where three days of bombing can burn through tens of thousands of MSP
On the last part this isnt completely true as for every weapon activation (thats not for PD) theres a 1% chance of a beam weapon breaking same with a missile launcher, while this wont break the bank it can in certain circumstances such as orbital bombardment where three days of bombing can burn through tens of thousands of MSP
Orbital bombardment isn't really a good example to bring up because you'll only be doing that after the enemy has already lost their navy, at which point it's just a matter of time while you ferry supplies back and forth.
On the other hand with missiles when you run out of ammo that directly affects the outcome of the naval engagement, and in my experience you'll already have tons of MSP on board for your beam combat ships to have decent maintenance anyways so you'll never have trouble killing targets before running out of MSP.
There is also the fact that missile ships also suffer weapons failures on their launchers so they need to have logistics for missiles and MSP whereas beamers only have MSP to contend with.
On the last part this isnt completely true as for every weapon activation (thats not for PD) theres a 1% chance of a beam weapon breaking same with a missile launcher, while this wont break the bank it can in certain circumstances such as orbital bombardment where three days of bombing can burn through tens of thousands of MSP
Orbital bombardment isn't really a good example to bring up because you'll only be doing that after the enemy has already lost their navy, at which point it's just a matter of time while you ferry supplies back and forth.
On the other hand with missiles when you run out of ammo that directly affects the outcome of the naval engagement, and in my experience you'll already have tons of MSP on board for your beam combat ships to have decent maintenance anyways so you'll never have trouble killing targets before running out of MSP.
There is also the fact that missile ships also suffer weapons failures on their launchers so they need to have logistics for missiles and MSP whereas beamers only have MSP to contend with.
Do note that here you are presuming that the enemy will only have one large colony worthy of bombing (that is to say, that they will be obliged to fight to annihilation with their entire navy to prevent it being bombed). That isn't necessarily actually going to be the case.
Do note that here you are presuming that the enemy will only have one large colony worthy of bombing (that is to say, that they will be obliged to fight to annihilation with their entire navy to prevent it being bombed). That isn't necessarily actually going to be the case.
That still means you have won the engagement for that system as a whole and there aren't any reinforcements coming in - it also means that the system is safe for supply ships to enter and resupply as well.
When you play if you simply never abuse the box launcher or reduces sized launchers you will be just fine with game balance. I always make sure ships have a rough "realistic" amount of weapons on them based on their size. The bigger the ship is the less external weapons I put on my ships in relation to their size, this is somewhat realistic and also makes it all quite balanced as well.This is basically true for anything in Aurora. It is not meant to be a game of its own, but rather a tool to tell stories (though we all crave for the game to be as round as it gets ;D)
Do note that here you are presuming that the enemy will only have one large colony worthy of bombing (that is to say, that they will be obliged to fight to annihilation with their entire navy to prevent it being bombed). That isn't necessarily actually going to be the case.
That still means you have won the engagement for that system as a whole and there aren't any reinforcements coming in - it also means that the system is safe for supply ships to enter and resupply as well.
Well no, I'm saying that reinforcements might actually be coming if this isn't their home system we are talking about.
It should be possible to do bombardment generally properly without crippling yourself, but its not necessarily reasonable to suppose that either you cannot at all, or that you could do so at your leisure and take your time with it.
Vertical Envelopment: (Working Title)
- The premises itself is fairly simple and straightforward, have Fighters that are equipped with Troop Transport Bays be able to conduct a special Ground Support Mission that I'm going to refer to as "Vertical Envelopment" from this point on. I'm open to a better name. :) This Ground Support Mission allows any Fighter Sized craft with a Troop Transport Bay to give a random formation an extra breakthrough chance when supported by eligible fighters assigned to said mission. The formations to be supported are chosen at random, with each fighter assigned choosing one until all eligible fighters with this mission are assigned. Formations gain a breakthrough chance increase equivalent to the Troop Transport tonnage of all supporting fighters, divided by the largest unit in the formation then multiplied by the number of eligible fighters assigned. Formations with FFD can have fighters assigned to them to provide support for them as per the usual rules for FFD and Ground Support Fighters.
- The breakthrough chance is applied in it's relative phase, but a fighter assigned to a "Vertical Envelopment" Mission still takes AA fire in the relevant stage. Light AA fire will be taken by the fighter from the formation that was engaged by the formation that the "Vertical Envelopment" support was provided to. Medium AA fire will be taken by the fighter from a formation that was directly supporting the formation that was engaged by the formation that the "Vertical Envelopment" support was provided to. Heavy AA fire will be taken by any fighters taking part in "Vertical Envelopment" Missions regardless of what formations are supported by them, assuming the Heavy AA is in a valid position to fire. A fighter with both a Troop Transport Bay AND at least one Fighter Pod Bay may also fire as if providing CAS during the relevant phase, but will not draw additional AA fire as a result of this.
- If fighters assigned to a "Vertical Envelopment" Mission have a formation loaded into their Troop Transport Bays, instead of the usual bonus they will provide a breakthrough bonus equal to the tonnage of their largest unit multiplied by the number of units. For the purposes of this calculation, LOG and S-LOG do not count for unit tonnage when determining the largest unit tonnage and are not counted towards the number of units multiplier. Formations assigned to fighters that themselves are assigned to a "Vertical Envelopment" Mission are treated as part of the formation that they are supporting for the purposes of ground combat and can take casualties as such. These formations also use supply AND provide supply during that phase as if they were a part of the formation that the fighter they are assigned to is supporting.
- Fighters destroyed during a "Vertical Envelopment" mission will also automatically result in the destruction of any formations that they were carrying. I would not be against some kind of derived percentage of survival with the surviving remnants treated as normal ground combatants from that point on, but I feel it might add too much complexity. Different types of Troop Transport Bays will NOT add any additional benefit over a Standard type, however the Drop Capable bays could allow for an "Orbital Envelopment" mission. The differences between the "Orbital Envelopment" and the "Vertical Envelopment" would be that Fighter Pod Bays would NOT allow a fighter on an "Orbital Envelopment" mission to conduct a CAS mission. Fighters on an "Orbital Envelopment" mission COULD provide Orbital Bombardment in the appropriate phase IF they had a suitable weapon. Fighters on an "Orbital Envelopment" mission would NOT incur AA fire, but WOULD incur fire from enemy STOs. Orbital Bombardment could be toggled by unassigning the B-FCS, or by having a separate set of orders for "Vertical Envelopment w/ CAS" and "Orbital Envelopment w/ Orbital Bombardment".
Steve - can you make "Geo Survey Complete" for ground surveys a time-interrupting event?
I highly suspect that this (or ideas like it) have already been suggested, but *shrug* doesn't hurt to re-hash some things.
Boarding combat - currently, 99% of all boarding combat seems to consist of a squad of highly trained, heavily armored marines against the hapless spacers aboard whatever ship gets boarded.
Thoughts (to be taken individually or mixed and matched):
1. Armory Module - perhaps with size scaling with number of crew. Upgrades typical crew from light weapons and half racial armor to regular weapons and racial armor.
2. Robotic Defender Module - provides X number of defensive troops for the ship. Default with same stats as a normal infantry, with a possible upgrade tree that can lead to heavily armored or heavy weapon variants. Could be RP'd as either actual robotic troops, or as automated boobytraps / hidden turrets in the ship.
3. Ship Security Module - a module that can be filled with X tons of troops, selectable from your currently researched ground combat templates. Set in the ship build menu. Then, when you queue up a new ship to be built, the cost of the troops will be added to the cost of the ship, and when the ship is completed, it will have the troops on board. (Basically, a troop transport bay, but without having to micromanage loading up individual defensive compliments of troops for each ship.)
I highly suspect that this (or ideas like it) have already been suggested, but *shrug* doesn't hurt to re-hash some things.
Boarding combat - currently, 99% of all boarding combat seems to consist of a squad of highly trained, heavily armored marines against the hapless spacers aboard whatever ship gets boarded.
Thoughts (to be taken individually or mixed and matched):
1. Armory Module - perhaps with size scaling with number of crew. Upgrades typical crew from light weapons and half racial armor to regular weapons and racial armor.
2. Robotic Defender Module - provides X number of defensive troops for the ship. Default with same stats as a normal infantry, with a possible upgrade tree that can lead to heavily armored or heavy weapon variants. Could be RP'd as either actual robotic troops, or as automated boobytraps / hidden turrets in the ship.
3. Ship Security Module - a module that can be filled with X tons of troops, selectable from your currently researched ground combat templates. Set in the ship build menu. Then, when you queue up a new ship to be built, the cost of the troops will be added to the cost of the ship, and when the ship is completed, it will have the troops on board. (Basically, a troop transport bay, but without having to micromanage loading up individual defensive compliments of troops for each ship.)
What a ship security module adds is making staffing actual security forces on the ship way easier.
I think the Armory is reasonable if there is a sufficient weight aspect to it. It seems to me like the crew should still be inferior to dedicated troops, just better armed than otherwise.
- I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.
1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.
1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.
3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.
4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.
The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.
1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.
1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.
3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.
4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.
The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
- I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...
Only infantry is used in ship combat, so I don't think that either static nor vehicles will help you much there.
- I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...
Only infantry is used in ship combat, so I don't think that either static nor vehicles will help you much there.
- Don't formations defend their own ship? I thought the infantry-only was with regards to the attacking force only...
- I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...
Only infantry is used in ship combat, so I don't think that either static nor vehicles will help you much there.
- Don't formations defend their own ship? I thought the infantry-only was with regards to the attacking force only...
No it also applies to the defending side.
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.
1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.
1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.
3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.
4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.
The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
In my opinion it would be much better if you changed the UI to better support small ship based security forces and marines. I would like the ground troop screen to be able to filter out troops onboard ships or that you can flag formations as ship security/marine forces so the game understand these are troops assigned to the ship rather than being transported from one place to another.
We should then also be able to see such forces in the ship information screen as more like part of the ship, perhaps even in the ship info screen as if then parasites and missiles are added.
I think this would be better and would fit better in general in my opinion. People on ships should usually be dedicated marines or not.
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.
1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.
1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.
3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.
4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.
The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
In my opinion it would be much better if you changed the UI to better support small ship based security forces and marines. I would like the ground troop screen to be able to filter out troops onboard ships or that you can flag formations as ship security/marine forces so the game understand these are troops assigned to the ship rather than being transported from one place to another.
We should then also be able to see such forces in the ship information screen as more like part of the ship, perhaps even in the ship info screen as if then parasites and missiles are added.
I think this would be better and would fit better in general in my opinion. People on ships should usually be dedicated marines or not.
I second this viewpoint. Besides being probably easier to implement than a whole new armory mechanic, the existing approach of sticking a troop bay and a platoon of marines, security guards, or what have you is I think just better for RP, plus handles all of the caveats Steve mentioned just fine with existing mechanics (leaving #1 and #2 up to player RP - never a bad result - #3 and #4 take care of themselves). Some tweaks to reduce micro are always welcome but adding a new and probably rather opaque mechanic I don't think is worth it.
I would be very much a fan of a "select standard defense squad" for a given ship design, with auto-load function. Not so much to reduce the micro, but also to avoid those: "oops I forgot to load the defense troops" moments
Also having smaller troop transport bays sound nice
I would be very much a fan of a "select standard defense squad" for a given ship design, with auto-load function. Not so much to reduce the micro, but also to avoid those: "oops I forgot to load the defense troops" moments
Also having smaller troop transport bays sound nice
Something like... if you designate a formation as a ship force it shows up in the "Class Design" window in a new tab called troops. You now select formations in the same way like ordnance. You also can just have a ship order to load/unload ship troops to easily load and unload these troops. You also could use this to transfer reinforcements to killed soldiers from any formation on that body designated as "reserved".
This would make it easy to manage small ship troop forces and stay true to the rest of the troop system at the same time.
I would be very much a fan of a "select standard defense squad" for a given ship design, with auto-load function. Not so much to reduce the micro, but also to avoid those: "oops I forgot to load the defense troops" moments
Also having smaller troop transport bays sound nice
Something like... if you designate a formation as a ship force it shows up in the "Class Design" window in a new tab called troops. You now select formations in the same way like ordnance. You also can just have a ship order to load/unload ship troops to easily load and unload these troops. You also could use this to transfer reinforcements to killed soldiers from any formation on that body designated as "reserved".
This would make it easy to manage small ship troop forces and stay true to the rest of the troop system at the same time.
I like all of these ideas. Selecting a formation template during the class design makes a lot of sense, and adding orders for replenishing those troops makes it even better. Add in an order that allows one fleet to draw replacements from another, and I think it completes the set.
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.
1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.
1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.
3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.
4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.
The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.
1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.
1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.
3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.
4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.
The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
I'm quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.
1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training like all seamen and officer do. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics in space. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.
2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.
3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.
However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.
4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.
An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.
1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.
1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.
3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.
4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.
The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
I'm quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.
1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training like all seamen and officer do. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics in space. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.
2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.
3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.
However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.
4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.
An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.
Training level in ground combat is abstracted under morale. Notice that officer with ground force training will slowly increase the morale of their formation over time.
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.
1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.
1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.
3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.
4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.
The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
I'm quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.
1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training like all seamen and officer do. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics in space. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.
2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.
3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.
However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.
4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.
An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.
Training level in ground combat is abstracted under morale. Notice that officer with ground force training will slowly increase the morale of their formation over time.
That doesn't make much sense to me. GI's don't become Delta Force just because their commander changed. Moral should be important sure, but the training level of Ground Units should be something akin to Genetic Modification that greatly enhances their abilities but makes the biggest impact on training time. A solider is more than their equipment.
I quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.
1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics as part of their standard curriculum. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.
2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.
3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.
However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.
4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.
An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.
I would love to see a truly randomly generated world with an intertwining research tree. What I mean by that:
Aurora is meant as a storytelling tool. And as such it works great. It though works only within its confined rules. Some kind of different economy model or what minerals can produce what goods is not in the game. Whilst being nice having those features (being able to define your own minerals and what installations use what resources for production) - the question is: would that be beneficial for the storytelling? I don't think so...
You could just rename Sorium into "Spice" and role play it as only being found on one planet you rename "Arrakis" :-)
But this is still predetermined.It will be great really, but it's very hard to code for Steve.
My point is that with random minerals it is more like exploring the game world every time you start a new game. And it is different every time you play. Sometimes fuel can be gathered from gas giants and sometimes from asteroids.
But this is still predetermined.I fully agree.
My point is that with random minerals it is more like exploring the game world every time you start a new game. And it is different every time you play. Sometimes fuel can be gathered from gas giants and sometimes from asteroids.
Could we have ground units re-supply during the construction phase in addition to during battle? It's kinda weird that a unit that has survived combat can't replenish its internal stores until the start of the next combat.
While we are on the subject of Commanders, I would like to have some additional ground combat commander bonuses that reflect the terrain bonuses that are out there. I was thinking about this the other night when I was playing - I always create a 'Federation Marine Corps' who have boarding and low-gravity fighting capabilities. When I'm fighting wars, these are the guys I usually send after any Low-G colonies the enemy might have. I have also recently created 'Raider Battalions' - Marines with High-G capability. I think it would be great if we had a '<Capability> Modifer' so that certain commanders are adept Jungle, Desert, Low-G, or Mountain Fighters and that the auto-assignment code is biased to place those Commanders into formations with those capabilities. It is a smaller thing but I think it would reward some specialization of formations by having dedicated commanders who are expert in their capabilities.
While we are on the subject of Commanders, I would like to have some additional ground combat commander bonuses that reflect the terrain bonuses that are out there. I was thinking about this the other night when I was playing - I always create a 'Federation Marine Corps' who have boarding and low-gravity fighting capabilities. When I'm fighting wars, these are the guys I usually send after any Low-G colonies the enemy might have. I have also recently created 'Raider Battalions' - Marines with High-G capability. I think it would be great if we had a '<Capability> Modifer' so that certain commanders are adept Jungle, Desert, Low-G, or Mountain Fighters and that the auto-assignment code is biased to place those Commanders into formations with those capabilities. It is a smaller thing but I think it would reward some specialization of formations by having dedicated commanders who are expert in their capabilities.
I also think something like this would be nice to have.
While we are on the subject of Commanders, I would like to have some additional ground combat commander bonuses that reflect the terrain bonuses that are out there. I was thinking about this the other night when I was playing - I always create a 'Federation Marine Corps' who have boarding and low-gravity fighting capabilities. When I'm fighting wars, these are the guys I usually send after any Low-G colonies the enemy might have. I have also recently created 'Raider Battalions' - Marines with High-G capability. I think it would be great if we had a '<Capability> Modifer' so that certain commanders are adept Jungle, Desert, Low-G, or Mountain Fighters and that the auto-assignment code is biased to place those Commanders into formations with those capabilities. It is a smaller thing but I think it would reward some specialization of formations by having dedicated commanders who are expert in their capabilities.
I also think something like this would be nice to have.
It's an interesting concept, but there are a couple of caveats for its inclusion into the game:
- Redundant mechanic. Simply put, we already have capability modifiers so this is really just doubling down on a bonus that already exists.
- Given the variety of terrain and other modifiers we have, there's a serious potential for the listing of commander traits to become quite long and unwieldy.
- There is potential for this to make the choice of assigning a commander basically pointless because for a high-G or extreme temps formation you will always want to assign a high-G or extreme temps commander, rather than choosing from several commanders with different traits depending on the mission the formation will have. The easy way to avoid this is to make the skill so rare that players don't really get to use it. The hard way to do this is a lot of tedious balance testing.
The combination of the first and last points I think make me worry that this mechanic would not really add anything to gameplay in terms of new and interesting decisions, rather just add a bit of RP fluff at the cost of potentially railroading some decisions. That's not a trade I would consider good to make for the design of the game.
A planetary fuel limit that prevents fuel transports to completely empty a planet from fuel. If any other ship refuels at that planet it can freely do so, but any fuel transport should not be able to empty the planet of fuel. If possible the same should apply to any space station that has a refueling hub. Only normal ships should be able to empty that spaceport.
A super nice bonus would be that the user gets a log warning message if a space station or planet is emptied to zero; and/or if a tanker or ship isn't completely refilled so you can check if that fleet is eventually run out of fuel in the future.
Piggyback/alternative: Allow a maximum fuel loading to be specified when a Refuel order is issued. I like to keep my tankers empty unless I'm absolutely swimming in fuel to make sure my planetary stocks can continually refuel my commercial fleets, so if I need to send a tanker off to support a fleet that only needs a third as much fuel as the tanker can carry I don't want to spend an extra month in port loading it up all the way, but other than calculating the loading time and firing a message from an idle ship there's no good way to accomplish this.My issue is with the regular fleets coming by to refuel - directly after I filled a tanker for a mission. It then happens that in the regular fleet halve of the ships get filled and the rest swims along with tanks not refilled. They then can get stranded on their tour - which is annoying. I sure can manually equalize fuel - not nonetheless annoying.
Piggyback/alternative: Allow a maximum fuel loading to be specified when a Refuel order is issued. I like to keep my tankers empty unless I'm absolutely swimming in fuel to make sure my planetary stocks can continually refuel my commercial fleets, so if I need to send a tanker off to support a fleet that only needs a third as much fuel as the tanker can carry I don't want to spend an extra month in port loading it up all the way, but other than calculating the loading time and firing a message from an idle ship there's no good way to accomplish this.My issue is with the regular fleets coming by to refuel - directly after I filled a tanker for a mission. It then happens that in the regular fleet halve of the ships get filled and the rest swims along with tanks not refilled. They then can get stranded on their tour - which is annoying. I sure can manually equalize fuel - not nonetheless annoying.
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.
- Yeah, I was thinking this too, refitting a 100 Ton / 125 Ton ship into a 500 Ton vessel is like turning a little Prius into a friggin' Mac Truck...i would compare it to a camper conversion of a truck or van. or bulking up a cruiser bike for a long trip.
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .
I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.
The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .
I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.
The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.
I think the underlying problem is that it is annoying/time consuming to replace fighters which is why people want refitting to be easier for them, not that refit mechanics are bad for fighters. Some aspects of this will improve when 1.13 hits thanks to the carrier hoover mechanic.
Still, I would propose implementing a replace task for fighter factories. You tell them to replace a certain fighter design in orbit for the target design you selected. Mechanically, what this does is build a new copy of the modern fighter, then scrap an old fighter that is in orbit on the relevant body but not docked at a carrier at the body. This gives a quick and easy way to replace large numbers of outdated fighters.
Some error handling might be wanted to handle cases where the factories are told to replace more fighters than there are available to be replaced.
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .
I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.
The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.
I think the underlying problem is that it is annoying/time consuming to replace fighters which is why people want refitting to be easier for them, not that refit mechanics are bad for fighters. Some aspects of this will improve when 1.13 hits thanks to the carrier hoover mechanic.
Still, I would propose implementing a replace task for fighter factories. You tell them to replace a certain fighter design in orbit for the target design you selected. Mechanically, what this does is build a new copy of the modern fighter, then scrap an old fighter that is in orbit on the relevant body but not docked at a carrier at the body. This gives a quick and easy way to replace large numbers of outdated fighters.
Some error handling might be wanted to handle cases where the factories are told to replace more fighters than there are available to be replaced.
A replace mecahnc seem like a good solution to that particular problem, I would be in favour if this. But I don't like to change the refit mechanic to do it.
The whole point is to solve the problem without touching the refit mechanics. The way the refit system does not favour small ships like fighters makes a lot of thematic sense anyways. It's generally not worth it to overhaul and redo something so small when you can recycle and make a new one cheaper. They didn't start turning F16s into F22s/F35s when they became available for a reason.
IF( (Original.ShipClass / New.ShipClass) < 0.2 ) == TRUE OR IF(New.ShipClass - Original.ShipClass <= 500) == TRUE then REFIT
For refitting the small craft instead creation of an all new function to replace small craft using fighter factories to do so. I'll add a notion, that Aurora tonns are not weight measure, but volume measure - it's a mass of liquid hydrogen, displaced by craft's hull, and there is no such thing in Aurora as above-water part of ship.
So, 20% - is 20% of hull's volume, that's not adding some heavy stuff inside the same hull.
I don't know a difference of volumes between F-16XL and F-16Cs, but I doubt it's much greater than 20%, the same as DC-10's / KDC-10.
And it's the purport of refit: you have to make some changes, but not to redo your hull.
An Aurora fighter is not like a jet fighter either as they are way bigger, more like a small real life Corvette or something.
It does happen on RL designs for heavy/small military aircraft and small boats. I once had the pleasure of crewing an EC-130H that was a former WC-130 and before that spent time as a HC-130 that started it's USAF life as a slick C-130E. all those variants and the added mods in between had significant weight differences between them and greater than 20% of previously modification weight. That isn't even considering some of the franken airframes that make up the KC-135 fleet or B-1 fleet.
The U-2 various Electronic packages makeup over 50~25% of dry weight depending on package and that's a field level swap.
same can be said of ocean workboats, as they often do get refitted drastically when acquired by a different owner or for a new project.
Why create an new mechanic to do something that functionally already exist? An if then statement is a simpler task than creating an entire scrap and replace system.
Why create an new mechanic to do something that functionally already exist? An if then statement is a simpler task than creating an entire scrap and replace system.
If I remember correctly from VB6 Excess crew did return to the pool and it presumably should work or is planned to work the same in C#.An Aurora fighter is not like a jet fighter either as they are way bigger, more like a small real life Corvette or something.
Like refitting an workboat, converting a cruiser to a carrier, making a Razee, or an Huey to Cobra.
But again IRL is irrelevant. If you must find a real-world grounding for this idea it does exist and has and will continue to occur, As I previously mentioned several times before.It does happen on RL designs for heavy/small military aircraft and small boats. I once had the pleasure of crewing an EC-130H that was a former WC-130 and before that spent time as a HC-130 that started it's USAF life as a slick C-130E. all those variants and the added mods in between had significant weight differences between them and greater than 20% of previously modification weight. That isn't even considering some of the franken airframes that make up the KC-135 fleet or B-1 fleet.
The U-2 various Electronic packages makeup over 50~25% of dry weight depending on package and that's a field level swap.
same can be said of ocean workboats, as they often do get refitted drastically when acquired by a different owner or for a new project.
If a grounding IRL you looking for it then that does exist, if a simplicity of operation in terms of game mechanics, how could we justify suggestion of creating a brand new mechanic and associated hooks into other parts of the code.
I also don't see why fighter factories can't refit and scrap fighters as well as build them, that is just odd to me as well. Why do you need shipyards to do that?!?
I also don't see why fighter factories can't refit and scrap fighters as well as build them, that is just odd to me as well. Why do you need shipyards to do that?!?
I think ultimately the reason it is this way is that the factory GUI doesn't have a way to do so. Currently fighters are built from the exact same GUI as all other construction projects (unless built at a shipyard of course), so to add refit ability to fighter factories Steve would have to either fit new elements into that window or rewrite the window to switch GUI elements when fighter construction is selected.
Personally I'd like to see the former as it would be good to apply the same functionality to space stations, in that case not as much for crew training purposes as to be able to upgrade old tech to keep old stations in service since scrapping them is often inconvenient at best.
The system generator gave me a system with 291 Asteroids. They are unfortunately at a distance of 97 to 448bkm to the main star. A bit annoying to have to manually select the asteroids the exploration ship has to go to. Is there any way you can give us a special "go to closest system body" auto command which goes beyond the actual limit of I think 10bkm search radius?
The system generator gave me a system with 291 Asteroids. They are unfortunately at a distance of 97 to 448bkm to the main star. A bit annoying to have to manually select the asteroids the exploration ship has to go to. Is there any way you can give us a special "go to closest system body" auto command which goes beyond the actual limit of I think 10bkm search radius?
Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.
I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to". :P
I would agree but this messes up the automation of surveys, specifically the "go to system requiring geosurvey" standing order will make ships to to the system with the asteroid belt and just idle around there when there are other systems with more useful geosurvey targets. So being able to flag systems as "do not survey" or allowing some way to set up survey orders for them I think is a good idea.
Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.Wanted to start a discussion about it. The 10bkm limit is a leftover from VB6 Aurora - where such gigantic systems weren't possible if I recall correctly; so it wasn't a big issue. Additionally, I don't think C# Aurora will slow down immensely if the search radius would be bigger.
I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to". :P
Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.Wanted to start a discussion about it. The 10bkm limit is a leftover from VB6 Aurora - where such gigantic systems weren't possible if I recall correctly; so it wasn't a big issue. Additionally, I don't think C# Aurora will slow down immensely if the search radius would be bigger.
I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to". :P
My actual survey ship can fly roughly 190bkm - so it could fly back and forth. And I even have a special fuel ship that could accompany it to extend the range :-)
My main issue with that system is simply that there are over 290 of these asteroids. I surely won't fly to the outmost of them (448bkm which is what? Over a lightyear...), but a lot of them are in a belt between 90 and 120 bkm. I had send a ship there to begin investigating. But the space between them often is more than 10bkm... . Maybe Steve can make the search radius depending on the system. If the outmost object is 20bkm out, search in 10bkm radius. But if it is 200bkm why not allowing the search radius to be 20 or 30bkm to keep automation working and reflect the bigger spaces between objects? Or else a new base game parameter. Don't create objects beyond x bkm in system generation... .
Just floating out some ideas... .
Perhaps replace the 10b km limit on auto-survey with two time- and fuel-based triggers?
IF, time needed to reach the next closest unsurveyed body or destination is greater than 180 days,
OR, if fuel is expected to run out before reaching the destination,
THEN, cancel the automatic survey order and state why.
ELSE IF, time needed to reach the next closest unsurveyed body or destination is greater than 60 days,
OR, if fuel remaining at destination is expected to be less than the limit set by the player (or 10% if no limit was specified),
THEN, continue but issue a warning with the expected transit time or fuel remaining.
Seems like that there is no message in the log that indicates that a fleet couldn't be refueled to it's max capacity. A bit annoying realizing this when the 20% warnings begin to pop up whilst the fleet is already underway and way out.
Could you add such a warning message when refueling doesn't fill up? Thanks.
I would like to add that this might be difficult to do for underway replenishment but is a really good idea for stationary refueling, both planetary and tanker based.That is true. Don't need message spam during an underway replenishment ;)
This has probably been suggested in some form but having cargo bays be able to transport formations consisting solely of logistical elements would be a nice little boost to logistics for protracted ground combat, while also making a good deal of thematic sense. (Logistical elements embedded inside formations don't necessarily 'disappear' when they are used. A batallion of men can't eat a truck, no matter how hungry they are! The transports are simply hauling supplies to replenish the ground forces with)
- Can we have an option to make Jump Drives Self-Jump only on purpose? I'd like the option for this since each Jump Drive would be cheaper, and because I'd like to make Jump Carriers that don't really need the squadron jump anyway. Maybe have them be smaller too? Options are always nice to have. :)
- Can we have an option to make Jump Drives Self-Jump only on purpose? I'd like the option for this since each Jump Drive would be cheaper, and because I'd like to make Jump Carriers that don't really need the squadron jump anyway. Maybe have them be smaller too? Options are always nice to have. :)
Self jump-only drives don't have any special cost reduction, so I'm not sure what the point would be as it's not hard to just RP this restriction. Unless you're suggesting reworking how jump drive design works so that self-jump drives are cheaper, which would be a different matter.
That just means they're the same cost as if you selected squadron size 3, the minimum, I take it, not some extra cost reduction beyond that.
Suggestion: I have advocated earlier for the addition or readjustment of conditions for medal awarding (example: Survey 25 Systems, Destroy 50 Missiles, etc). I was looking at the categories today and I think I'm fine with the existing categories but is it possible to add an adjustment that allows us to change the condition through the game UI? Say instead of a condition, 'Discover 3 Habitable Worlds' I could adjust it to 'Discover 2 Habitable Worlds' if I wanted without diving into the DB? I'm not sure this would be hard to add because we already are able to modify the promotion points per medal so it seems that this could be done without a lot of additional work.
- One other suggestion that sprung to mind when thinking about Self-Jump Drives... using Gravitational Survey Sensors to detect ships Jumping in. Perhaps every one point of Gravitational Sensor translating to 1 billion km of detection? Maybe have Science Department enhance it?
Could we have waypoints that are linked to an object like a planet and they keep moving with that object? I don't mean directly on that object but more like a patrol point around that object, i.e. at a certain distance. I would love to set up patrol routes around planets and moons - and those "orbital waypoints" would be a great help with this.
Could we have waypoints that are linked to an object like a planet and they keep moving with that object? I don't mean directly on that object but more like a patrol point around that object, i.e. at a certain distance. I would love to set up patrol routes around planets and moons - and those "orbital waypoints" would be a great help with this.
Piggyback: the ability to tell a fleet to move to or follow a target at a specified distance and heading. I'm sick of having to eyeball a new waypoint placement every time I just want a fleet to move away from a hostile contact on a 45-degree heading instead of directly opposite.
I would like to suggest something regarding scuttling ships and boarding combat.
The goal of a captain in the navy should be to scuttle the ship so that no useful equipment can be captured by the enemy. This means the ship shall not fall into enemy hands as a hole or in parts via salvaging. To achieve that, I would suggest that captains try to blow up their ships by overloading their remaining drives and power plants causing them to explode.
The same thing should be done automatically when an enemy force tries to commandeer the ship. There should be a certain chance that the crew blows up the remaining reactors to destroy their ship and the invading force before they manage to kill off the crew.
What do you guys think about it?
Mass Driver ship module
Wouldn't it be nice if a mining ship fleet also could have an additional ship with a mass driver module that can send mineral packages to a base planet or space station to collect minerals? Or if you could build a mineral collection base close to a jump point, set up a small transfer line to a space station on the other side of the wormhole and continue mineral transport from there?
Choke Point circumvention via temporal wormhole
How about a new type of temporal wormhole generator ship module? With that module, one can create a temporal exit point on an existing jump point connection that is up to 10bkm away from the regular jump point exit. This temporal exit will be open for a few days only and needs at least two years to generate. It also can be archived in the target system once every 20 to 30 years (so no temporal spamming).
Maybe it can be included with a tech line to generate it quicker or keep it open for some days more?
The goal is to archive two things: of course, avoiding jump point slaughter as a key strategic element of surprise in a war situation (but to avoid overuse have it limited as described). And deploying stealth ships without them being detected when coming through the default jump point exit.
Internal Security Control
Cost 100 Size 100 tons Crew 15 HTK 1
Officer: Ground Force Officer
Rank: Major
Skill: Ground Combat Defence
Base Chance to hit 100%
Materials Required: Duranium 20 Corbomite 80
Civil Logistic Liaison
Cost 200 Size 200 tons Crew 30 HTK 2
Officer: Civilian Administrator
Rank: Admin Rating 1
Skill: Logistics
Base Chance to hit 100%
Materials Required: Duranium 40 Corbomite 160
Please change the rank ratio for ground forces to be 4:1 (as I believe it was in VB6).Why not just let us set our own ratios?
The current 3:1 is not feasible for trying to model any modern military formation structure post-WWI era. The change was made for C# along with the 2:1 ratio (was 3:1) for naval officers, however ground forces did not receive the non-command roles as naval officers did, so there is no good reason for the change to 3:1 ratio.
Many people would prefer to see non-command roles added. I agree, but as this would be extra work I would rather have the reversion to 4:1 ratio than no change at all.
Please change the rank ratio for ground forces to be 4:1 (as I believe it was in VB6).Why not just let us set our own ratios?
The current 3:1 is not feasible for trying to model any modern military formation structure post-WWI era. The change was made for C# along with the 2:1 ratio (was 3:1) for naval officers, however ground forces did not receive the non-command roles as naval officers did, so there is no good reason for the change to 3:1 ratio.
Many people would prefer to see non-command roles added. I agree, but as this would be extra work I would rather have the reversion to 4:1 ratio than no change at all.
Horrible no good balance-shattering component number i8182401840 (Does it count as not serious if I would like to see it just think its very very unlikely?)
External Fighter Clamps/Collar
Cost 50 Size 550 Crew 10 HTK 0/1
Base Chance to hit 100%
Materials Required: Duranium 25 Vendarite 75
Capacity 1000tons
-Half-size military hangar bay that acts like a commercial hanger but is as capable as Hangar Deck while half the size and can, obviously be used on military carriers. Double capacity is meant to be balanced by lack of deployment time pause, and possibly not being able to reload missiles and or maintenance supplies if that proves not enough. Thus a carrier that can carry more fighters but is more expensive and even more vulnerable to fire. Though this would allow for more compact carriers as well.
And here are current a hangar components minus commercial hangers
Hangar Deck
Cost 100 Size 1,050 tons Crew 15 HTK 4
Base Chance to hit 100%
Materials Required: Duranium 25 Vendarite 75
Boat Bay - Small
Cost 18 Size 150 tons Crew 3 HTK 0
Base Chance to hit 100%
Materials Required: Vendarite 18
Boat Bay
Cost 30 Size 300 tons Crew 5 HTK 1
Base Chance to hit 100%
Materials Required: Vendarite 30
Thanks knew I forgot some minor detail or another~ ;DHorrible no good balance-shattering component number i8182401840 (Does it count as not serious if I would like to see it just think its very very unlikely?)
External Fighter Clamps/Collar
Cost 50 Size 550 Crew 10 HTK 0/1
Base Chance to hit 100%
Materials Required: Duranium 25 Vendarite 75
Capacity 1000tons
-Half-size military hangar bay that acts like a commercial hanger but is as capable as Hangar Deck while half the size and can, obviously be used on military carriers. Double capacity is meant to be balanced by lack of deployment time pause, and possibly not being able to reload missiles and or maintenance supplies if that proves not enough. Thus a carrier that can carry more fighters but is more expensive and even more vulnerable to fire. Though this would allow for more compact carriers as well.
And here are current a hangar components minus commercial hangers
Hangar Deck
Cost 100 Size 1,050 tons Crew 15 HTK 4
Base Chance to hit 100%
Materials Required: Duranium 25 Vendarite 75
Boat Bay - Small
Cost 18 Size 150 tons Crew 3 HTK 0
Base Chance to hit 100%
Materials Required: Vendarite 18
Boat Bay
Cost 30 Size 300 tons Crew 5 HTK 1
Base Chance to hit 100%
Materials Required: Vendarite 30
Half size isn't going to make much of a difference except maybe in build cost, as the actual size of a carrier is going to have to be scaled up to what it's actually carrying (for purposes of calculating speed, sensor signature, etc.), so you're not saving any tonnage unless the carrier is empty. Unless you're suggesting that a hangar with 550 tons size can carry 1000 tons of fighters and still be considered 550 tons for speed, sensor, etc. purposes, which doesn't make sense.
Given that the existing hangar component essentially "maths out" as 50 tons of component and 1000 tons of fighter space, I'm not sure why not just RP it as an external clamp if you want to. Gripper arms plus refueling and transfer tubes displacing 50 tons seems reasonable to me.
Actually serious(ish) suggestion a thread for Unrealistic Suggestions, a place for people to shove all their "cool and wacky ideas" (me) into a space away from suggestions which might be feasible for a hobby project.
How about a global range factor for missiles?
It would be great if we could change the overall range calculations for missiles to make it fit better with different scenarios. Whilst long range as it is fits quite well for example into an Expanse Universe, it doesn't fit so much for a Battlestar Galactica Universe where beam and missiles are roughly the same (low) range weapons.
You should only be able to change ship commanders when they are in port over a friendly world. I hate it when I send out a hand-picked commander only for him to be promoted in transit and be magically replaced with someone else. Promotion and assignment checks should only occur to unassigned and orbiting officers.
Be really cool if the XO or, failing that, highest rated officer on a ship could take over if the commander is killed.
You should only be able to change ship commanders when they are in port over a friendly world. I hate it when I send out a hand-picked commander only for him to be promoted in transit and be magically replaced with someone else. Promotion and assignment checks should only occur to unassigned and orbiting officers.
This sounds really good in theory (realism, hooray!) but in reality is a huge micromanagement pain. Especially once commanders start being located on different worlds so that every time you want to assign a specific commander you need to figure out which system to send the shuttle to. This would work a lot better if we had some automation for it though.
A refuel until full order. This would be like the fill minerals until full order, except for fuel. This would allow a simple set of orders for working with tankers and harvesters. Refuel until full - Transfer fuel to colony x - Cycle orders. Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.
A refuel until full order. This would be like the fill minerals until full order, except for fuel. This would allow a simple set of orders for working with tankers and harvesters. Refuel until full - Transfer fuel to colony x - Cycle orders. Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.
A refuel until full order. This would be like the fill minerals until full order, except for fuel. This would allow a simple set of orders for working with tankers and harvesters. Refuel until full - Transfer fuel to colony x - Cycle orders. Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.
Eh... in Aurora VB, there was a button to equalize the fleet's fuel. It seems to be gone from Aurora C#, but that functionality could be part of how the order works:A refuel until full order. This would be like the fill minerals until full order, except for fuel. This would allow a simple set of orders for working with tankers and harvesters. Refuel until full - Transfer fuel to colony x - Cycle orders. Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.
The equalize fuel button went away because fuel transfer rules changed massively. What you suggest is of course possible except for the equalizing part. The problem comes from how to make sure that the single tanker refuels equal amounts from each harvester. Because currently the code does not support that as far as I know. It's not just changing one toggle; it would need Steve to rewrite the fuel-refuel code which impacts everything else. That's what I meant when I said that it isn't as easy as we make it sound - apologies if it wasn't clear.Eh... in Aurora VB, there was a button to equalize the fleet's fuel. It seems to be gone from Aurora C#, but that functionality could be part of how the order works:A refuel until full order. This would be like the fill minerals until full order, except for fuel. This would allow a simple set of orders for working with tankers and harvesters. Refuel until full - Transfer fuel to colony x - Cycle orders. Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.
- If tanker is not at harvester fleet, move to harvester fleet.
- Tanker refuels from harvesters, sequentially.
- If tanker is not full, wait a construction cycle and return to step 1.
- Equalize the harvester fleet's fuel.
- (Order complete, proceed with next order.)
Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?
True but I mean a true MSML, ie a launcher that fires off multiple shots per 5 seconds. Some super tech used possibly by invaders of precursors, or discoverable from ruins. Is it possible to make a random chance per completely empty system to generate an lets call it "Ancient Wreck" that has the tech and other advanced ones?Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?
This is kind of possible with 2-stage MIRVs. Empty 1st stage and just set the separation range to the attack range and the missile will split into multiple missiles 5s after launch.
True but I mean a true MSML, ie a launcher that fires off multiple shots per 5 seconds. Some super tech used possibly by invaders of precursors, or discoverable from ruins. Is it possible to make a random chance per completely empty system to generate an lets call it "Ancient Wreck" that has the tech and other advanced ones?Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?
This is kind of possible with 2-stage MIRVs. Empty 1st stage and just set the separation range to the attack range and the missile will split into multiple missiles 5s after launch.
True but I mean a true MSML, ie a launcher that fires off multiple shots per 5 seconds. Some super tech used possibly by invaders of precursors, or discoverable from ruins. Is it possible to make a random chance per completely empty system to generate an lets call it "Ancient Wreck" that has the tech and other advanced ones?Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?
This is kind of possible with 2-stage MIRVs. Empty 1st stage and just set the separation range to the attack range and the missile will split into multiple missiles 5s after launch.
...And another thing! I was puttering along and suddenly two hostile contacts appear in my home system, but for some reason the autoturns don't stop. Fortunately, they didn't seem keen to doing me any harm, but if they were, they would've had literally two months to do so simply because the autoturns kept going. They weren't new contacts in the sense that I hadn't seen them before, but I did lose them before they popped into my system so theoretically I should've gotten interrupted once they reappeared, no?
...there is little to no incremental benefit in dropped troops v just pummelling from above at the moment.
Hey there Steve!!
I would have another small suggestion for the commanders tab. I like to manually assign commanders to the ships, so none of them keep without a command while is in the lower rank. Even if the commander has not a proper skill for the work he will do, I don't think that the Fleet Command would keep commanders looking through the window when there are ships without CO.
I also use automatic assigment, of course, but as said I like to assign from year to year those that are not assigned. Is it possible to add a checkbox in the commander tab to show the "unassigned" commanders? So the list will show only those that need a new ship :)
Thanks.
...there is little to no incremental benefit in dropped troops v just pummelling from above at the moment.
I'm not a ground combat expert, so correct me if I'm wrong: against fortified defenders, isn't it cheaper/faster to drop troops than to bombard from orbit, when you take into account the very low hit chance and the MSP cost of weapon failures?
That said collateral damage in general is rather excessive at the moment so it may get looked at sometime.
That said collateral damage in general is rather excessive at the moment so it may get looked at sometime.
Ground artillery also is quite insane for collateral damage. Its why I prefer long range bombardment over heavy bombardment.
That said collateral damage in general is rather excessive at the moment so it may get looked at sometime.
Ground artillery also is quite insane for collateral damage. Its why I prefer long range bombardment over heavy bombardment.
I've noticed a lot of players will rush to the heavy+ weapons and vehicle types thinking that more powerful == better. Aurora's ground unit system in general is really designed with a "less is more" ideal, as bringing an overkill weapon to a battle is more wasteful than useful, but new players do not always realize this. That might contribute to the collateral damage excess as well.
Hm, not sure if this has been suggested before, but if it's practical I'd like to see some sort of Non-Trans Newtonian ship weapons and sensors. Maybe have them be 50% less effective/efficient that Trans Newtonian weapons and sensors?
My humble suggestion: Make NPR's treat diplomatic ships as harmless. It's getting pretty frustrating that I can never do Diplomacy or even maintain diplomatic contact with a new NPR because they screech at my harmless, unarmed diplomatic station like it's a battleship or something.
My humble suggestion: Make NPR's treat diplomatic ships as harmless. It's getting pretty frustrating that I can never do Diplomacy or even maintain diplomatic contact with a new NPR because they screech at my harmless, unarmed diplomatic station like it's a battleship or something.
Diplo ships in general need to be more obvious. I had an NPR parking their diplo ships on "my" jump points, which I thought were destroyers of some sort due to size and military engines. Since I did not have any diplo ships of my own, at no point did I gain any indication that these were in fact not armed vessels until I, um, accidentally destroyed them much later on.
It would be useful for players if a custom event message (at the least) popped up indicating that a ship is a diplomatic ship...
Can search and destroy fighters and flak suppression be buffed? Currently they are kinda useless, I always wanted to crush a planet's ground forces with fighters but as it currently is, that is impossible to do.Never in human history has airpower crushed ground armies completely or even driven them to surrender. Even the best possible case scenario, the Gulf War of 1991, required the Coalition to drive their ground forces into Kuwait and Irak, and that was a war where one side had complete control of the airspace, could bomb the enemy with total freedom, and had complete intelligence about the enemy's disposition and equipment. Plus both terrain and weather were on the side of the attacker.
Can search and destroy fighters and flak suppression be buffed? Currently they are kinda useless, I always wanted to crush a planet's ground forces with fighters but as it currently is, that is impossible to do.Never in human history has airpower crushed ground armies completely or even driven them to surrender. Even the best possible case scenario, the Gulf War of 1991, required the Coalition to drive their ground forces into Kuwait and Irak, and that was a war where one side had complete control of the airspace, could bomb the enemy with total freedom, and had complete intelligence about the enemy's disposition and equipment. Plus both terrain and weather were on the side of the attacker.
If you don't want to wage a ground war, the only option is to nuke the planet and that's how it should be. It is ludicrous and impossible, regardless of technology, to be able to wipe out armed resistance on a planetary scale.
Not large numbers and it only happened twice and then afterwards got blown out of all proportion, just like the myth of Polish cavalry charging German tanks in 1939. In both cases it were vehicle crews surrendering after seeing their comrades getting blown up. And despite the publicity that the Highway of Death got, that massacre only happened after the advancing Coalition troops had routed the Iraqi troops who then fled in panic.
It would be nice if we could get a formation update button. If you select you're infantry battalion, for example, then click the update button, the engine would look at the unit series, and replace on a one for one basis the units in that batallion with the ones at the top of the unit series. This would save having to replace every element in a formation indivually. Some adjustments may have to be made to the formation, but this is much easier than replacing every element by hand.
I'm referring to the formation template, not an existing formation.
It would be nice if we could get a formation update button. If you select you're infantry battalion, for example, then click the update button, the engine would look at the unit series, and replace on a one for one basis the units in that batallion with the ones at the top of the unit series. This would save having to replace every element in a formation indivually. Some adjustments may have to be made to the formation, but this is much easier than replacing every element by hand.
I'm referring to the formation template, not an existing formation.
- I usually just update them by making a new template and then adding the same number of new units as the old, then hitting "Obsolete" on the old units and deleting the old template for sanity's sake. Not sure if you can delete a template while units still use it, but I'd assume you can... an "Obsolete Template" Button would be nice though. :)
It would be nice if we could get a formation update button. If you select you're infantry battalion, for example, then click the update button, the engine would look at the unit series, and replace on a one for one basis the units in that batallion with the ones at the top of the unit series. This would save having to replace every element in a formation indivually. Some adjustments may have to be made to the formation, but this is much easier than replacing every element by hand.
I'm referring to the formation template, not an existing formation.
Append Template Orders To Current Orders
Right now, using an order template overwrites a fleet's current orders.
I suggest adding a way to append template orders to the end of the current orders list.
Perhaps a checkbox "Append Orders" next to the Create/Delete Template buttons?
If the box is checked, then double-clicking a template appends the orders.
Otherwise, double-clicking replaces the current orders (as it does now).
In the past Steve has been opposed to this because it would potentially create confusing bugs due to order targets not being where expected. However this already occasionally happens and is resolved through a nice event trigger and canceling the order, so I don't think it would be problematic. This would be a very useful addition.
I would love to have a "Rename Fleet" order.Wow, how have I not thought of that before? That's a great idea and it has historical merit too - during WW2 convoys were renamed based on whether they were "going in" or "coming out".
I use fleet names to indicate current assignment, and it would be great if I could, for example, have a freighter fleet rename itself after it unloads.
If ( Current_Atm != Target_Atm ) then // I know about double's wonky equality check, but hear me out
Terraform_change = Terraform_Capacity / Year_length * Cycle_length * other_modifiers.... //Amount of atm change possible on this body this production cycle
If ( Terraform_change > 0 ) then
Difference = Target_Atm - Current_Atm
If ( ABS(Difference) <= Terraform_change ) then //Can target be reached with available change?
Current_Atm = Target_Atm //gives people nice and clean values AND allows that target equality check at the beginning
//Log message here? I know there are several versions of them, but maybe 1 universal "Target has been reached" is enough
else
If ( Difference < 0 ) then //>0 means we need to add gas, <0 means we need to extract gas
Current_Atm -= Terraform_change
If ( Current_Atm < 0 ) then
Current_Atm = 0
else
Current_Atm += Terraform_change
As far as I understand the change has been done to increase the value of logistics technology tree, commander's logistics bonuses, and cargo handling bays (which is stackable but affects only individual ships), but that makes Spaceport inferior to triple station in almost every way. I think Spaceport should still have some positive counterbalance to it's disadvantages. Can't think of anything good for now, unfortunately.
I think it's quite simple, the spaceport is already quite a bit more expensive than its less generalized counterparts. Just make it so that the spaceport doesn't need 1m workers and I think it's in a decent place.It is actually 17% cheaper than stations (3k vs 1.2k x3). But it is not enough to offset population used and 266% more cargo space required for transportation (2000kt vs 250kt x3).
I'm not posting this in the bugs thread, since as far as I can tell from the rules post this is working as intended, but Fire at Will allows you to more or less completely negate jump shock for a well-trained fleet. If you press the Fire at Will button after jumping it seems to overwrite the fire delay from jump shock, and if your fleet is trained then you'll end up with little to no delay. Of course you don't get to choose your targets, and in some cases that's a big downside, but it's usually better than the alternative of not firing at all, and if your fleet outnumbers the enemy then it's often not a huge problem.
This makes taking a jump point generally much easier, but it's especially unbalanced because the AI has a tendency to jump through the jump points when attacked. So you jump through a JP into an enemy fleet, the enemy jumps to escape you, you jump back and chase them -- and now you can use Fire at Will to wipe them out while they recover from the jump shock.
Was Fire at Will intended to negate jump shock, or just reduce the normal fire delays when crews are untrained? The balance issues could be fixed by making the AI use Fire at Will as well to counter the advantage the player has, but that just makes jump shock kind of pointless. I think it would make the most sense to change Fire at Will so that it doesn't affect jump shock.
A new Fire At Will option allow ships to reduce fire delays by half, at the expense of targeting choice. This can be applied to a single fire control, a ship or a fleet.
When the order is given, each fire control is assigned a random target (based on the rules below). Each ship is then assigned a fire delay with a modifier of -50% vs normal. This fire delay will override any existing fire delay (even if the current delay is longer), except if the command is assigned to a specific fire control, rather than ship or fleet, in which case the new fire delay will only override any existing fire delay if the new delay is longer.
I'm not posting this in the bugs thread, since as far as I can tell from the rules post this is working as intended, but Fire at Will allows you to more or less completely negate jump shock for a well-trained fleet. If you press the Fire at Will button after jumping it seems to overwrite the fire delay from jump shock, and if your fleet is trained then you'll end up with little to no delay. Of course you don't get to choose your targets, and in some cases that's a big downside, but it's usually better than the alternative of not firing at all, and if your fleet outnumbers the enemy then it's often not a huge problem.Before Fire at Will existed, combining full training with flag bridge and a good flag officer (lots of reaction) can do the same thing but also select targets.
This makes taking a jump point generally much easier, but it's especially unbalanced because the AI has a tendency to jump through the jump points when attacked. So you jump through a JP into an enemy fleet, the enemy jumps to escape you, you jump back and chase them -- and now you can use Fire at Will to wipe them out while they recover from the jump shock.
Was Fire at Will intended to negate jump shock, or just reduce the normal fire delays when crews are untrained? The balance issues could be fixed by making the AI use Fire at Will as well to counter the advantage the player has, but that just makes jump shock kind of pointless. I think it would make the most sense to change Fire at Will so that it doesn't affect jump shock.
My intuition tells me that PD STOs can be more economical/less economical than orbital PD bases depending largely on planetary terrain. If your planet is a jungle mountain, even if your making massive turret STOs their survivability will be so damn high because of fortification bonuses that enemy fleets will have massive trouble initiating a land invasion or destroying the PD defense shooting down the enemy missiles. On the other hand, orbital bases can't take advantage of the planets terrain, although if the terrain is something like desert there is a good chance orbital bases would be cheaper and overall more cost-effective.
The problem I have with PD STOs is that they are unreasonably expensive, since every single gun has a full-price fire control system which is tuned to anti-missile fire. So you can easily have each gun cost 2000k uridium or something because of the fire control. Big turrets help mitigate this since your quad gauss packs 4x the firepower per FC.
I think there needs to be a new static component called "planetary active sensor" which lets you choose which designed active sensor to use from your racial tech. Likewise when designing standard STOs a checkbox to toggle the inclusion of inbuilt FCs should also be added. I'll crosspost this to the suggestion thread.
Ability to turn off automatic construction of infrastructure on colonies with a colony cost.
On some planetary bodies with low gravity I might want to colonize them using orbital habitats exclusively, but once a population has been established they will automatically start building Low Gravity Infrastructure, which will results in civilians shipping colonists to the surface. This changes the balance between agriculture, service, and manufacturing, which can be a serious detriment on colonies with high Colony Cost.
A temporary solution is to set a cargo ship to perpetually transport the LG Infrastructure away from the planet, and you could probably avoid new colonists by military restricting the planet, but turning off automatic construction of infrastructure is a cleaner solution.
Quote from: smoelf link=topic=10640. msg151565#msg151565 date=1621103281Ability to turn off automatic construction of infrastructure on colonies with a colony cost.
On some planetary bodies with low gravity I might want to colonize them using orbital habitats exclusively, but once a population has been established they will automatically start building Low Gravity Infrastructure, which will results in civilians shipping colonists to the surface. This changes the balance between agriculture, service, and manufacturing, which can be a serious detriment on colonies with high Colony Cost.
A temporary solution is to set a cargo ship to perpetually transport the LG Infrastructure away from the planet, and you could probably avoid new colonists by military restricting the planet, but turning off automatic construction of infrastructure is a cleaner solution.
I'm also in favor of this, but for a different reason: venusian atmo planets.
Just mentioning it because it would be disappointing to see this get implemented for LG's only.
While I don't think this is a bad option (either of them) it is quite simple to avoid this currently. You just assign a small colony ship with a return trip to another colony and match this with the amount of people that is added to the colony over a years time. You can easily then adjust this once every ten years with just speeding up or slowing down that colony ship. But if you time it right you will only have to do this like once every hundred years or so.
The size of the colony ship you need is of course depending on the size of your habitat, but habitats usually are not that big so a single colony ship are usually enough.¨
Now you can also enjoy their production of infrastructure and move it to someplace else more useful.
Maybe add the option for specified types of bodies to have unlimited amounts of minerals. You'd have sperate options for planets, gas giants, dwarfs, moons and asteroids.
I'd always make gas giants have unlimited sorium cuz I'm always paranoid about running out. Its never happened to be fair, but it does give me anxiety. Having unlimited minerals on full planets might also be a good idea for the same reason.
Keep in mind accessibility would still be a thing, so some planets would still be more valuable than others just cuz you can mine at a faster rate. It'd make gameplay more like Stellaris and other more traditional 4X games.
I like how we have our own "house rules".
Mine is if I SM minerals is to set availability to 0. 1 as a penalty
Ability to directly begin upgrading a Ground Unit to a new Template
Right now as ground units become outdated, there's no way to directly re-equip units with the latest tech short of having them take losses that need to be replenished. Would be great if there was a way to upgrade/convert one template to a new one, similar to how ships can be upgraded. Something along the lines of an "Upgrade" order at Ground Force Training Facilities, where the mineral cost is spent to manufacture the replacement equipment, and the time cost to both build it, and train the unit on the new gear. This way unit formations with storied histories can easily be kept on the cutting edge of empire technology and not be lost to obsolescence.
Survey Sites
Trying to track (remember) where I have landed survey teams.
I've just noticed, and am assuming that (body name) * denotes troops on site
Would it be possible to add a %/progress bar next to body names?
+ organise by systems would be helpful to concentrate on 1 system at a time as an alternative to High to Minimal.
Aiming to save ferrying troops from one end of the galaxy to the other.
Bonus: Filter to display completed.
Thank you :)
Like an SAS (or equivalent) recon unit that can also disrupt supplies or improve breakthrough chances.Perhaps a ground team that could interfere with logistics, like loading/unloading ships etc, or gather intel on the planet and its orbit. The player could set how active/passive the team is, the more active, the greater the chance of detection.
have an option to prevent the "Move to System Requiring Gravsurvey/Geosurvey" standing order from moving the fleet outside the range of its admin command
Add manual "auto-assignment" control for ship designs
Currently ship designs get commander auto-assignment based on the components they contain. This leads to various issues, for example if I build an orbital miner and add a cargo space to carry a mass driver - this will not be flagged as an "Orbital Miner" for commander auto-assignment purposes. So you end up micro managing those ships to make sure they have commanders with mining skill.
An option would be to just allow player to override this behavior and manually select ship "role".
Right now I playing around with fighters a lot and there is a problem that I keep noticing.
Fighters die, but before they die they create a new fleet. This results in dozens or hundreds of empty fleets than I have to clean up or quarantine to a special admin command for fighter combat.
I suggest a "Delete Empty Fleets" button that deletes all fleets with no ships in them, are not in any active orders (EG at the time ships are ordered to join that empty), and are not assigned to have ships build into them.
Right now I playing around with fighters a lot and there is a problem that I keep noticing.
Fighters die, but before they die they create a new fleet. This results in dozens or hundreds of empty fleets than I have to clean up or quarantine to a special admin command for fighter combat.
I suggest a "Delete Empty Fleets" button that deletes all fleets with no ships in them, are not in any active orders (EG at the time ships are ordered to join that empty), and are not assigned to have ships build into them.
I support this, but we will need a toggle to protect specific fleets from this behavior so the Shipyard Fleet doesn't mysteriously disappear.
This is what I tried to say in the last sentence, Shipyard Fleet (s) would be protected.Right now I playing around with fighters a lot and there is a problem that I keep noticing.
Fighters die, but before they die they create a new fleet. This results in dozens or hundreds of empty fleets than I have to clean up or quarantine to a special admin command for fighter combat.
I suggest a "Delete Empty Fleets" button that deletes all fleets with no ships in them, are not in any active orders (EG at the time ships are ordered to join that empty), and are not assigned to have ships build into them.
I support this, but we will need a toggle to protect specific fleets from this behavior so the Shipyard Fleet doesn't mysteriously disappear.
A tiny suggestion: add an infrequent check that SM-repairs-all civilian ships.
During a recent incursion into the Sol system that caught me with my main fleet elsewhere, I scrambled whatever I had on hand to defend - including a recently completed batch of ten railgun fighters intended for my new carrier, still on the ways. While they couldn't bring the fight to the enemy, they COULD inhibit their missile attacks, and did so - I used them to escort an unlucky civilian cargo ship and they handily shot down every salvo. Only one leaker got through, punching a hole in the freighter's armor and taking out the cargo bay.
As an experiment I let this ship alone, and sure enough, a few times later, I noticed an error message indicating that the freighter in question had failed to pick up a civilian contract load. So I tracked it down in the civilian ships list and SM repaired its cargo bay.
Civilian ships being damaged but not destroyed is of course rare, the remedy is at hand and it even throws an event message. So this isn't exactly high-priority. By the same token, there seems no good reason not to let damaged civilian ships (at sensibly infrequent intervals) automate pressing the "SM Repair All" button. If this could cause problems elsewhere, it's certainly not worth it, but if the occasional civvie ship with a nonfunctional cargo bay could throw an error in other parts of the civilian contract code, it might be an edge case worth plugging. I wouldn't know, I haven't seen the code. :)
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).
I thought that already happened. If not, that is a bug.
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).
I thought that already happened. If not, that is a bug.
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).
I thought that already happened. If not, that is a bug.
Finally, civilian mining outposts to be able to generate a small amount of pop that can emigrate.
I would like to suggest changing espionage roll table to not include infinite "Race X is in war with *insert known spoiler*" I had 11 reports like that so far from my neighbour. Its about one fourth of all reports I got from them...
I would like to suggest changing espionage roll table to not include infinite "Race X is in war with *insert known spoiler*" I had 11 reports like that so far from my neighbour. Its about one fourth of all reports I got from them...
In general redundant espionage reports get annoying. I've 'discovered' the same enemy sensor entirely too many times...
I would like to suggest changing espionage roll table to not include infinite "Race X is in war with *insert known spoiler*" I had 11 reports like that so far from my neighbour. Its about one fourth of all reports I got from them...
In general redundant espionage reports get annoying. I've 'discovered' the same enemy sensor entirely too many times...
This is almost certainly a bug that should be on the bug thread. There is no reason to rediscover the same component.
In 1.13 carriers will use MSP to repair armor damage sustained by any parasites in its hangars.carriers do this already
Extend this ability to damaged internal components too.
In 1.13 carriers will use MSP to repair armor damage sustained by any parasites in its hangars.carriers do this already
Extend this ability to damaged internal components too.
I was hesitant to put this into the bugs reporting since I don't think it's technically a bug. The Fire At Will fleet setting doesn't retarget a different enemy ship after destroying its initial target. You have to manually select Fire At Will again for it to select a new target. It'd cut some unnecessary micro if it did, especially during large fleet combats.
Anyway, when I assign my junior officer with the best Crew Training skill to be the XO of a warship, the auto-assignment feature inevitably reassigns him to command the next fighter that rolls off the production line, which is a complete waste of his talents.Usually if I'm going to be using a lot of fighters, I tick the box on my large ship designs to bump up the officer ranks by one level so my XOs are e.g. CDRs instead of LCDRs.
Somewhere in the Suggestions thread I posted that it would be good to have the Reaction skill be the preferred skill for warship commanders in the auto-assignment algorithm instead of Crew Training, to reserve the latter skill for XO postings and since Reaction has no corresponding officer module (whereas Crew Training, Engineering, and Tactical do). It would also be really great if Fighter Combat was actually checked by the auto-assignment as I don't think it currently is.
Generally speaking, it would be nice if we somehow could define the rules for the auto selection in some place. Maybe Steve can rework it in a way that the rules are not hard coded but live in the DB and can be changed like rules for medals in a UI screen? It would also open up for individual play and promotion styles for different empires.
On a tangental note, not sure if this is a bug, but it'd be nice if Chief Engineers could gain experience in Engineering. (Or maybe I'm just getting extreme RNG on this point.)
So far my observations are that ENGs can gain Crew Training and Reaction, but not Engineering. (Naval Admins can gain Engineering, so it doesn't seem to be a non-trainable skill.) Which means that with auto assignments, commanders with Engineering get posted to ENG, then eventually gain Crew Training, then get moved to the next CO post on a fighter that opens up.
If this is a bug, I suspect it hasn't come up because I only started noticing the lack of Engineering experience after I stopped using auto assignments.
I wonder if tactical has the same problem.
Generally speaking, it would be nice if we somehow could define the rules for the auto selection in some place. Maybe Steve can rework it in a way that the rules are not hard coded but live in the DB and can be changed like rules for medals in a UI screen? It would also open up for individual play and promotion styles for different empires.
I also would love to see some kind of player-defined rules for auto-assign beyond the current priority system.
Even just a tick box to define a ship design as less important than non-CO command positions would be huge.
2. Could we get some multi-select capability in the task force management screen? IE, ctrl clicking multiple ships in a fleet to drag to another fleet. Or perhaps shift clicking at the top and bottom of a group of ships to multi-select them.
Same goes for Ground Forces. Managing large armies can get extremely click intensive.
1. Per my attachment. On screens showing tasks and a "Completion date". Can't actually tell when techs, ships, ground units, and etc are actually going to be complete due to the date format being so... verbose.
Could you please update it such that the columns on these menus are resizeable. Or, if that proves to be annoying, maybe throw a radio button somewhere to set the date format to something smaller like YYYY/MM/DD/Monday?
Was thinking today that something I would love to see is the ability to assign weapons to fire controls on the ship design screen, similar to how we can assign ordnance and fighter loadouts. This would be a huge timesaver for me! :)
Excellent idea. Just in case you didn't know though:Great reminder, I often forget about that one until way after the fact but it is indeed better than going one by one or fleet by fleet.
If you have at least one instance of a class in active service, you can use "assign all" to copy it's weapon/FC assignments to all other instances of that class which means that often its just a couple clicks before battle to assign everything the way you want it.
I may just not know how to do this, but in case...
When I rescue survivors they seem to go on the first ship in the fleet. Which would be fine if I had no ships with cryo. But, I nearly always have a few ships in a battlefleet with 250, or 1k cryo for RP/rescues. Inevitably the survivors always go on a ship without cryo.
Anyway to a preference could be added for the ships that have cryo?
I may just not know how to do this, but in case...
When I rescue survivors they seem to go on the first ship in the fleet. Which would be fine if I had no ships with cryo. But, I nearly always have a few ships in a battlefleet with 250, or 1k cryo for RP/rescues. Inevitably the survivors always go on a ship without cryo.
Anyway to a preference could be added for the ships that have cryo?
Yeah the game should prioritize cryo capable ships first for picking up survivors.
Updated the rescue code so that the fleet ship that picks up a specific life pod is the first ship in a list ordered by Descending Available Cryogenic Capacity then Descending (Class Crew - Current Survivors)
I have another suggestion/question:
Would it be feasible to have a "Cargo Hold - Fighter", with 250 ton size (or less) in the game?
Considering that a ship has to be 500 tons or smaller in order to interact with a planet (to load cargo, passengers, etc.), do we still need to rely on Cargo Shuttle Bays, or would it be possible to micro-design them ourselves?
I feel like I'm making a mistake with a cryogenic shuttle design, in terms of practicality.
You can get away with not having a cargo shuttle bay, but only if the source and destination colonies both have cargo handling capability themselves. Otherwise it won't work.Guess what? It didn't work.
At any rate, a "microfreighter" like this is extremely impractical anyways - the small engine size means not only is fuel efficiency very poor but it is impossible to make these as a commercial ship, so your "freighters" will eat into your maintenance capacity as military vessels. If you want small freighters you're usually better off with a small commercial design, a single commercial engine is 1,250 tons at minimum so a ship in the 3,000-5,000 ton range can work, or you can build up to 10,000 tons (size of a new commercial yard) with 2-3 engines and more cargo space. Such designs are usually most practical for moving minerals around where mass drivers are not practical, although pretty quickly you'll find a need for more traditional large freighters once you start expanding mining operations appreciably.
You can get away with not having a cargo shuttle bay, but only if the source and destination colonies both have cargo handling capability themselves. Otherwise it won't work.Guess what? It didn't work.
At any rate, a "microfreighter" like this is extremely impractical anyways - the small engine size means not only is fuel efficiency very poor but it is impossible to make these as a commercial ship, so your "freighters" will eat into your maintenance capacity as military vessels. If you want small freighters you're usually better off with a small commercial design, a single commercial engine is 1,250 tons at minimum so a ship in the 3,000-5,000 ton range can work, or you can build up to 10,000 tons (size of a new commercial yard) with 2-3 engines and more cargo space. Such designs are usually most practical for moving minerals around where mass drivers are not practical, although pretty quickly you'll find a need for more traditional large freighters once you start expanding mining operations appreciably.
The less than 500 ton shuttle can't even work as a shuttle - colonists couldn't leave the ships.
We need SPECIALIZED shuttles (The ones in the background of 'Cargo Shuttle Bay', and not the ones you spend oh so long creating in the designs screen)!
Out of the idea of a quick colonist shuttle transport, I get nothing.
Sorry sir, we're not IMPLEMENTED to react with a planet in this way! - imagine hearing this while role-playing as a shuttle transport captain...Well, I suppose I'll add another suggestion then:- actually, there already is 'cargo hold' category, and plenty of others...
In the class design screen, It would be nice to have categories and subcategories of components, like - cargo/colonist/ordnance/fuel handling components - Once you open this category, you can then choose one of these 4, and then choose the specific component you're looking for.
CCOFtT -> Cargo/Colonist/Ordance/Fuel/Troop Transport -> Cargo ->
Also - It would be nice if in the events screen it says that the loading/unloading orders could not be completed due to lack of Cargo Shuttle Bays or planetary installations.
This sounds like a bug. The whole shtick of 500 ton fighter sized craft is that they don't need cargo handling facilities to interact with planets. If your design is considered as a fighter by the game, then you should not need a cargo shuttle bay to land cargo/colonists on a planet. So I feel like this is a bug.
Not sure if this is a bug, my understanding of fighters was that in spite of the lore around them their only special mechanic was being built by planetary facilities. Once they're built they don't have any other special rules aside from benefitting from Fighter Combat skills.
I can't be bothered to dig through the C# mechanics changes thread
I can't be bothered to dig through the C# mechanics changes thread
But I can!
Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.
I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.
I can't be bothered to dig through the C# mechanics changes thread
But I can!
Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.
I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.
This is the post I was thinking of, now that I re-read it, I think you might be right in your interpretation. I recall reading that post and making the assumption that the 500 ton rule was supposed to be all crafts below 500 tons and didn't realize that it was specifically referring to the shuttles that are a part of the cargo shuttle bay component.
Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.
I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.
Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.
I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.
In the 1.12 changes list (http://aurora2.pentarch.org/index.php?topic=11593.0), Steve explicitly states that "Fighter-sized craft do not require cargo shuttles to load / unload colonists or cargo. Due to their size they can land and load/unload directly."
I don't know if it actually works. I made an engineless fighter with cryo transports the other day and it couldn't load/unload without a cargo station but that might be because it was engineless. I didn't test it exhaustively in order to produce a bug report.
In long games, the Leaders window and even the Ship Design window can also bog down.
Some suggestions and observed issues, based on a couple of 1.13 games:Personally, I always disable Star Swarm because - I simply refuse to believe that the open cosmos can be habitable to any sort of living being.
1. The Swarm is too variable in the danger level it poses, and can be far too deadly. What deep-space bugs should not do is a) scout your home planet (>10B km away from any jump point or linked LP point) five years into a game, park 10s of thousands of tons-worth of warships in orbit a few months later, destroy all your shipyards, and start bombarding your helpless early-game homeworld to dust and ruin. Endlessly, because they never run out of supplies.
This is unfair, because:
a) The player, if they set up using ordinary early-TN tech levels (the ones the game offers as defaults), may well not be able to fend off such an attack so early on. "You lose. Regardless of any attempt you might have made at preparedness." is not what a game should tell players. This applies also to the Invaders.
b) Distance should matter to the AIs. If the AI can't be made to understand fuel limits, it should at least respect a travel distance limit.
c) Supplies should matter to the AIs, at least in some sense. They don't have to run out when attacked, but if attacking, they should not be able to fire beam weapons endlessly, especially when bombarding.
d) If it is intended for space bugs to be a mortal threat, or at least if they should attempt to wipe out players if not stopped, then the game should provide some sort of warning that these aren't just ship-killing, wreck-harvesting critters ... the Swarm wages wars of extermination!
I can verify that small crafts still can't unload/load cargo on their own, at least not colonists which is what I tested, I did not try from a cargo hold.
Another issue that still exist is that Troop Transports can unload/load troops on any planet no matter their size without cargo shuttles a well, I'm pretty sure they are not suppose to be able to do that. At least it is a bit weird that they can.
due to my son being born yesterday.
due to my son being born yesterday.
--- Cheers! Currently stuck in a hospital with little to do. Poor guy was a month and a week early... But he's getting better real quick.
--- That's enough Off-Topic in C# Suggestions though. :)
Congratulations!
This raises an interesting point whether or not the policing requirements of a planetary population should increase as the planet becomes more full above a certain threshold. For example, when the space taken is at least 50% the policing requirements start to increase more than usual, with the increase being more extreme as the space used approaches 100%.
I guess I'll repeat my thoughts on this too - if it is going to be implemented, leave a choice whether to use "advanced policing" or not.This raises an interesting point whether or not the policing requirements of a planetary population should increase as the planet becomes more full above a certain threshold. For example, when the space taken is at least 50% the policing requirements start to increase more than usual, with the increase being more extreme as the space used approaches 100%.
Found this in the "What is your biggest empire" - thread and thought, this is worthwhile to think about. We do have unrest due to overpopulation, though it makes sense that once you get close to the maximum (lets say 95%) that people get uneasy and begin rioting which leads to an increase in police needed... . And it would make sense that people will increase violence more if they are in enclosed spaces (i.e. installations) - so the need for a non-zero planet which needs installations should be higher than on a zero world... .
Are there going to be ways to make civilian spawned ground units upgrade-able some way?We can do it now (v1.13).
Or, at least, so when they create new civilian mining colonies with ground units, will there be a way to make them spawn with the new "racial" technologies, rather the the ones, which were created close to the game start (Duranium tech)?
For the ship combat screen Filter targets to armed ships.It will be very possible to have target-rich environment with no info about enemy weapons at any of those targets, so with this filter you can get very counterintuitive result.
For the ship combat screen Filter targets to armed ships.It will be very possible to have target-rich environment with no info about enemy weapons at any of those targets, so with this filter you can get very counterintuitive result.
...My suggested change presents an interesting strategic choice to the player which is between more effective frontline formations at greater logistical expense versus frontline formations with greater non-combatant tonnage for the benefit of cheaper overall logistics and slightly lower transport requirements for LOG elements.
...My suggested change presents an interesting strategic choice to the player which is between more effective frontline formations at greater logistical expense versus frontline formations with greater non-combatant tonnage for the benefit of cheaper overall logistics and slightly lower transport requirements for LOG elements.
Are you saying here that infantry-based logistics would be more efficient with respect to transportation, or am I misreading this? Because that seems backwards: under your proposed change LVH-based logistics provides ~16 GSP/ton while infantry-based logistics only provides 10 GSP/ton.
The last few games I've been playing I do so without jump engines. I just build stabilization ships and only go places that have gates. It slows down exploration, but frees up a lot of space on ships (or frees up a ship type) and it frees up my PP scientists from having to research Jumpy stuff.
Given all that, I was thinking that it would be interesting if gates could be destroyed. Forcing your opponent to use jump engines could be viable. Not sure how the NPRs would decide when a gate should be removed or not and it could be annoying if they snuck into a transit system and destroyed a gate...
I haven't really run into any issues. I just do a standard transit for the entire fleet and that's worked just fine thus far.The last few games I've been playing I do so without jump engines. I just build stabilization ships and only go places that have gates. It slows down exploration, but frees up a lot of space on ships (or frees up a ship type) and it frees up my PP scientists from having to research Jumpy stuff.
Given all that, I was thinking that it would be interesting if gates could be destroyed. Forcing your opponent to use jump engines could be viable. Not sure how the NPRs would decide when a gate should be removed or not and it could be annoying if they snuck into a transit system and destroyed a gate...
I wonder how you handle JP assaults without squadron jump, although you could just use a single/couple specialized jump ships for that.
Currently if there are two ground formations on the same hierarchy level next to each other and both have hq units inside, if you set up one of the formations to support and try to support the other, you won't be able to do it unless the hq inside formation you try to support is the same size or smaller than the hq inside formation you want to provide support with. If the "supported" formation has higher hq size instead, then your drag will end up in making the other formation subordinate of the supposedly supported one instead of setting support correctly.
I'd be grateful for a toggle as to what drag does (ideally a different way than dragging, but at the very least that), so I can consciously decide whether I want to provide support or attach as a subordinate.
I find terraforming strategies to be a bit one-sided:
Terraforming facility is generally considered a worse alternative to the terraforming module mounted on a ship (or a station).
The advantages of terraforming on a ship:
You can get bonus from ship commander,
You don't require population to function.
While the only obvious advantage I can see is:
Facility can be built with a construction factory. Thus, saving you a shipyard.
I suggest to improve ground-based facility to either:
Not require population to function, OR
Work better than a single terraforming module on a ship (like, 5 times more powerful).
Compounding the problem is the cost, a terraforming installation costs 600 BP in a factory while the terraforming module costs somewhat less, I want to say 480? BP but don't have Aurora in front of me right now.Terraforming module:
This is analogous to orbital mining modules vs automines, however in this case OMMs have an obvious limitation in that they can only mine from very small bodies. Thus the balance between OMMs, automines (2x cost, work everywhere) and manned mines (require population) is reasonable and all options have their use. Terraforming modules have no such limitations aside from the initial research investment into the modules themselves as well as tractor beams for the tugs (although you can put engines on a terraforming ship this forces you to use a shipyard to build it).
That being said I am not sure what a good solution would be. Currently shipborne terraforming modules feel like they are in a good place, so I think it is preferable to buff the ground-based installations instead of nerfing the orbital modules. However any buff to the ground installations is difficult to make as we do not want to make early-game terraforming too easy. If nothing else I think bringing the cost of the ground facilities down to be the same as that of the orbital modules is reasonable, as this allows a strategy of using terraformers to employ the first wave of colonists at a new colony to be competitive with the orbital stations economically.
Currently, the shipborne terraforming modules feel likein a good placethey are too good!!!, to the point of making terraforming installations too much of a hassle.
I mean, sure, you can use a freighter that is sooo big, to transport other installations as well, making it a versatile solution (so that you'd need these freighters whether you use terraforming installations or not).
But, still... You'd need infrastructure to transport with it! And even then it sometimes is not enough (some colony costs are so huge, that terraforming installation simply cannot work, no matter how much infrastructure you toss at it - Venus, for example). This population requirement can be bypassed with an orbital habitat... But it will still require a tug, or a separate dockyard to build.
So...
Does anybody even use terraforming installation?
Because I'd rather use a module than an installation. Pretty much, every time.
I guess I can see 1 place where you want taxes even before the planet is terraformed, but... Do they pay taxes?
Different tools for different situations, my friend.
I use TF facilities for Mars and other CC2 planets, as the need for infra is small. TF stations, meanwhile, are used on CC4+ planets. Because they are built by different facilities (CF vs SY), it can be beneficial to utilize both. But especially in early game, when SY space is at premium, it's worth it to have TF facilities even if you eventually phase them out and only use TF stations/ships.
Different tools for different situations, my friend.But you still phase them out... Meaning, they are viable only fairly early, or with specific limitations and role-play reasons...
I use TF facilities for Mars and other CC2 planets, as the need for infra is small. TF stations, meanwhile, are used on CC4+ planets. Because they are built by different facilities (CF vs SY), it can be beneficial to utilize both. But especially in early game, when SY space is at premium, it's worth it to have TF facilities even if you eventually phase them out and only use TF stations/ships.
Yeah, and that's what I also suggested, albeit even further:
To clarify my point: I feel like orbital terraforming modules, by themselves, feel like a good balance. The rate at which they can be built, deployed, and terraform a planet feels reasonable at least in the early to mid game...many players claim terraforming is too fast in the late game but that's a different discussion.
The planetary installations feel decidedly weak by comparison because their cost is greater and their use is more restrictive, but I do not think the answer is to nerf the orbital modules, rather the ground-based facilities need some improvements. Bringing their cost into line with the orbital modules is at least a good first step, or maybe a bit less. Even equal cost at 500 BP I think is fine, but since orbital modules are so much more flexible a slight discount at, say, 480 BP might make more sense.
I can't speak for other players, but I will usually use infrastructure to establish new colonies particularly in frontier systems and place a population of ~10m at a CC2.0 world in a system I want to eventually expand and terraform in. In this case it can make some sense to ship out the ground-based terraforming facilities to give that population something to do, so the population requirement is not always a hindrance especially if the planet itself has relatively poor mining prospects.Considering that in my game Luna and all those worlds near Jupiter (and Titan near Saturn) have no minerals, I suppose a facility may not be entirely without merit...
If I'm playing with a low-pop start and don't have the RPs to research terraforming modules with instant research I'll usually build some installations to get started on terraforming Luna/Mars since I'll colonize those bodies without having any real jobs for the populations to be doing. Once orbital modules and tractor beams are available though there is not much point, though I will still use the facilities I already built as they don't cost any more to operate...I chose to not have any instant research points in my game, and yet still waited for a module... A terraforming station with 10 modules seems like a fairly quick solution.
Yes. All employed workers pay taxes, and terraforming installations are no exception.Which means that an installation has 1 more advantage over a module...
I think the issue is that after the early game, once you have terraforming modules (5000 RP) and tractor beams (5000 RP), plus a few tugs built...there is no economical reason to build the ground-based facilities. The orbital modules are cheaper (500 BP vs 600 BP for the ground-based facilities) and logistically not any more complicated (freighters vs tugs is a wash even neglecting the need for colonists to be shipped around as I assume this will happen anyways).Well, at least we agree on the same problem, though we offer different solutions...
It's reasonable to say that the installations are intended to be the early-game option and the orbital modules for the rest of the game but personally I dislike having a mechanic or feature in the game which is completely useless after a certain point in time.
That said I think only a small adjustment to the build cost is needed, just enough to make ground facilities competitive instead of clearly overpriced and uneconomical.
Well, at least we agree on the same problem, though we offer different solutions...
But, yes, I agree that the cost should be the same, if not less (at least, if the workers still remain on it, can they at least do things, that reduce the facility's cost..?)
Though, if we remove the workers, we also remove the advantage it has over a module...
I think we are taking different approaches to a solution.Yeah...
Your proposals, though I may be misunderstanding, strike me as trying to make the ground facilities and orbital modules basically equal in all situations. For example removing the population requirements (and setting the BP costs equal) means that the only real difference between the two types is whether you use freighters or tugs to move them into place.
Whereas what I prefer is a setup where both types have different uses so one or the other is preferable, for example the orbital modules are more flexible but also slightly costlier, while the ground facilities are a bit cheaper (I suggested 480 BP but you could go even lower if necessary) but require population so they are better for some situations but not all. This leads to a strategy where you want to build mostly the orbital modules but also some ground facilities for the cases where they are a stronger option - which leads to a necessity to assess how many of each you should expect to need and try to build up accordingly.
I find terraforming strategies to be a bit one-sided:
...
I suggest to improve ground-based facility to either:
Not require population to function, OR
Work better than a single terraforming module on a ship (like, 5 times more powerful).
But you still phase them outNo, you skipped over the rest of my post. I wrote that even in the case that they are phased out, they were useful in early game. But they always remain useful and there is no need to phase them out. If your surveyors find a steady stream of planets to terraform, there will never be a situation where you want less terraforming ability.
The only relative advantage is the tax income, but the long-run economic bottleneck is always populationOnly if you do 500M pop default starts. If you do a 7B pop United Earth start, you won't be bottlenecked by population.
If you remove the population requirement from TFIs, then I might actually use them.But then how am I telling a story of maintaining a frontier colony that's desperately trying to terraform their planet?
To be worthwhileI disagree because all you're proposing here is to increase the mathematical formula for achieving maximum effectiveness vs investment while removing options. I don't want Aurora to become yet another 4X game where there's only one true way to play. We already have Paradox and Matrix for that.
Correct me if I'm misunderstanding you but it seems that you're trying to bring BALANCE to Aurora and that's not going to work :P
Even if that's not the case and there's a mathematical most efficient way, it doesn't really matter. Because Aurora is all about options and possibilities - if TF facilities are only useful in early game and then might not be used by few/some/many players after that, doesn't mean that they are wasted. It's 100% fine if something isn't viable/efficient throughout the game - we already have this with weapons. There is no need to make any changes here.
To be worthwhileI disagree because all you're proposing here is to increase the mathematical formula for achieving maximum effectiveness vs investment while removing options. I don't want Aurora to become yet another 4X game where there's only one true way to play. We already have Paradox and Matrix for that.
Correct me if I'm misunderstanding you but it seems that you're trying to bring BALANCE to Aurora and that's not going to work :PProbably, it is what the suggestions forum is for, is it not?
No, you skipped over the rest of my post. I wrote that even in the case that they are phased out, they were useful in early game. But they always remain useful and there is no need to phase them out. If your surveyors find a steady stream of planets to terraform, there will never be a situation where you want less terraforming ability.But You still phase them out...
Even if that's not the case and there's a mathematical most efficient way, it doesn't really matter. Because Aurora is all about options and possibilities - if TF facilities are only useful in early game and then might not be used by few/some/many players after that, doesn't mean that they are wasted. It's 100% fine if something isn't viable/efficient throughout the game - we already have this with weapons. There is no need to make any changes here.I'd like options that have each their own strengths and perhaps niches, not 2 options, one of which is superior in every aspect and other is... Just there.
The only relative advantage is the tax income, but the long-run economic bottleneck is always population
Only if you do 500M pop default starts. If you do a 7B pop United Earth start, you won't be bottlenecked by population.I go with 10B start and still prefer modules.
If you remove the population requirement from TFIs, then I might actually use them.
But then how am I telling a story of maintaining a frontier colony that's desperately trying to terraform their planet?Is the population requirement necessary for Your story?
To be worthwhile
I disagree because all you're proposing here is to increase the mathematical formula for achieving maximum effectiveness vs investment while removing options. I don't want Aurora to become yet another 4X game where there's only one true way to play. We already have Paradox and Matrix for that.What? No, I want actual 2 ways to terraform things, that each have their +'es and -'es. Right now, we have 2 ways to play, with 1 being superior in almost every aspect.
I would like to see more ways to get a weapon lock, including a passive lock.
So it would be possible to create a missile that will lock to the strongest thermal signature or EM emission.
I don't really like that mechanic, it sounds contrived and weird.
I would like to see more ways to get a weapon lock, including a passive lock.
So it would be possible to create a missile that will lock to the strongest thermal signature or EM emission.
This is a great idea in general, passive locks could be such that you can use passives to stealthily fire weapons at the cost of targeting freedom. You'll always lock the strongest EM/TM signature and cannot choose to lock smaller ones at the same location as a larger signature. That way you can choose which enemy fleet to target but not specific ships.
Also great for self-guided missiles, you could make missiles that'll prioritize targeting the big EM signature of actives so that you can eliminate the big scouts.
I don't really like that mechanic, it sounds contrived and weird.
Getting back to the modules versus installations debate about terraformers - There is 1 thing I noticed about modules:
They require crew. 100 per module. Since, I typically design an entire station, with 10 of these modules, I get a crew requirement above 1000...
And it may not be a problem late game, when you have plenty of academies and populations... But it can be early game - building just 4 of such stations depletes your crewmen and junior officers fast. And subsequently, grade goes down...
So there is yet another hidden advantage to the installations - they don't "eat up" your crew...
Regardless, my point still stands - there has to be more advantages to the installations to make them feasible.
An NPR generated when I was playing on 260% difficulty 80 years in.
I get that the size of NPR populations is dependent on the above factors in order to give some sort of challenge.
But what just happened is that the game spawned 30bn aliens on a world that can only accommodate 8bn population (they have 100% population density).
I think what should happen is either:
- Game respects the carrying capacity of the body
- Game creates designs of colossal orbital habitats in such a way that the carrying capacity + orbital capacity is sufficient to house the population.
EDIT: I should also mention this world had dangerous levels of CO2 as well which I had to SM replace with aesthesium.
EDIT: For the problem I pointed out in the edit, the game should, once it's decided that the planet in question will have an NPR, modify the body to actually have 0 cost for whatever alien it's decided to put there.
SJW: Max pop for NPR will now be the capacity of the planet. Also fixed dangerous gas problem.
Forgive me if this is a duplicate; I have about 20 pages of suggestions to catch up on!An NPR generated when I was playing on 260% difficulty 80 years in.
I get that the size of NPR populations is dependent on the above factors in order to give some sort of challenge.
But what just happened is that the game spawned 30bn aliens on a world that can only accommodate 8bn population (they have 100% population density).
I think what should happen is either:
- Game respects the carrying capacity of the body
- Game creates designs of colossal orbital habitats in such a way that the carrying capacity + orbital capacity is sufficient to house the population.
EDIT: I should also mention this world had dangerous levels of CO2 as well which I had to SM replace with aesthesium.
EDIT: For the problem I pointed out in the edit, the game should, once it's decided that the planet in question will have an NPR, modify the body to actually have 0 cost for whatever alien it's decided to put there.
SJW: Max pop for NPR will now be the capacity of the planet. Also fixed dangerous gas problem.
This was a reasonable bug fix, but I suggest that this would be a nice place for future enhancement. If the population would be larger than the planetary capacity, then the game could give the new NPR extra colonies on nearby planets. Find some planets with reasonable colony costs and give them infrastructure and facilities. If they have minerals, move a few mines to them, otherwise financial centers or research labs or something. This should give a new NPR a lot more life.
Got what seemed like a couple hundred errors during system generation jumping into a new JP. Function #2608, #222, #224, #2339 in that order, and then repeating. Over and over.
According to a quick peek in the database, this is anew NPR (not a spoiler race)and they have been generated with the "pre-industrial" flag.Edit: So, I don't know if this is intended or not, but when I approached their planet I discovered that they have two separate empires for the same NPR race on the planet. I'm only detecting STO and ground forces for one of them.
Update on the strike-through text: This system actually spawned with both a 1) Pre-industrial NPR, and 2) Rakhas on the same body. That seems like a bug, although it's an interesting situation with roleplay implications. Also, apparently they're not hostile to each other even after time progresses. I don't think they can detect each other. Maybe this bug created an interesting enough situation not to fix it. (Except for all the error messages I originally got above on system gen)
I don't know, because I never saw the aliens five hops away. My ship was destroyed by unknown, unseen ships and STO weapons.
I neglected to add a thermal sensor to my geo survey ships, and now I pay the price.
However, I started the game with no NPRs, so I don't see how these two races could be the same race. They certainly didn't hop from Cadbury to Mabel without me seeing them. And they couldn't have grown from Mabel to Cadbury: Mabel didn't exist (i.e., I did not discover it) until years and years after Cadbury.
If they are both the same spoiler race, it is odd that one has ships and STO weapons but the other does not.
I am guessing, but I think what happened was as followsI'll add at least one tracking station to Rakhas to prevent that situation (assuming my guess is correct).
- Cadbury population is Rakhas but doesn't have either STO weapons or tracking stations.
- You land in Cadbury but the Rakhas don't detect your ground forces and therefore don't have an alien race record for your race.
- Mabel population is also Rakhas but this one does have STO weapons.
- Mabel population detects your survey ship and destroys it with STO weapons.
- Rakhas now have an alien race record and classes you as hostile
- Rakhas in Cadbury launch an assault because they now know you exist and ground combat doesn't actually need a sensor contact
Except that the crew count is irrelevant because there is a button labelled "conscript" which when checked, makes such stations not take crew from the officer/crew pool. Also for completeness, crew grade does not improve the productivity of modules so gameplay wise there is no reason not to check a terraformer as a conscript ship.
The only crew based argument is the CO officer, but that's also relevant because you just set the officer priority to 0, this means that ground based installations just have the governor bonus advantage, which is more than closed by the cost gap between ground and orbital.
Yeah you don't need navy grade crew for the terraformers so its not the same.Well then...
I've played for a bit, and the weapon I find really lackluster is mesons. This weapon needs a direct buff; this could be addressed through the "Meson Armor Retardation Chance" tech line so that the Meson has much greater chance to penetrate armor. The chance should at least scale with armor rather than being left behind so mesons actually get worse at higher tech levels.
Buff Mesons
please
I've played for a bit, and the weapon I find really lackluster is mesons. This weapon needs a direct buff; this could be addressed through the "Meson Armor Retardation Chance" tech line so that the Meson has much greater chance to penetrate armor. The chance should at least scale with armor rather than being left behind so mesons actually get worse at higher tech levels.
Buff Mesons
please
Honestly all you'd need would be to make it be % chance to ignore armor as opposed to % chance to ignore each layer of armor. Right now at max meson retardation (7% chance to be absorbed per layer), ships of armor level 10+ become virtually immune to mesons.
I think mesons were meant to be an anti-small weapon and not be very powerful against large ships, but they get completely superseded by AMMs in the anti-small role.
Honestly all you'd need would be to make it be % chance to ignore armor as opposed to % chance to ignore each layer of armor. Right now at max meson retardation (7% chance to be absorbed per layer), ships of armor level 10+ become virtually immune to mesons.
I think mesons were meant to be an anti-small weapon and not be very powerful against large ships, but they get completely superseded by AMMs in the anti-small role.
I've played for a bit, and the weapon I find really lackluster is mesons. This weapon needs a direct buff; this could be addressed through the "Meson Armor Retardation Chance" tech line so that the Meson has much greater chance to penetrate armor. The chance should at least scale with armor rather than being left behind so mesons actually get worse at higher tech levels.
Buff Mesons
please
Honestly all you'd need would be to make it be % chance to ignore armor as opposed to % chance to ignore each layer of armor. Right now at max meson retardation (7% chance to be absorbed per layer), ships of armor level 10+ become virtually immune to mesons.
I think mesons were meant to be an anti-small weapon and not be very powerful against large ships, but they get completely superseded by AMMs in the anti-small role.
I actually think the main preciptator of the change was Steve having visions of thousands of STO mesons blasting entire armadas out of the sky. I do agree that the nerf hit them too hard and they no longer have much of a role, though.
The change I'd like to see would actually be for larger mesons to do multiple points of damage and each failed armor penetration roll would reduce the damage by 1. So if you had a heavy meson that did 3 damage, and it failed its 7% (or whatever) chance, it does 1 damage to the armor and the remaining two points continue rolling to penetrate the rest of the armor.
I would love to see a fighter size ship that can operate without a crew, like a drone.
Additionally, perhaps maintenance failures just stay broken.
I don't really agree with those tradeoffs, usually mass automation is not an option you exercise at the last second in a pinch, like 'oh dang im running low on trained crew people i guess ill just quickly engineer automatons that can perform every function a human can as a stopgap measure'. Its frankly usually the opposite of that where its much easier and quicker to find some way to do a job with a human, and then later as the job gets more developed machines start to take over, which is usually much more work.
UPD to the previous:There is a general game option to play without maintenance... or am I missing something?
To take away most boring micro load, this feature have to affect only those ships that are not parked at mainteinance location or inside hangar.
There is a general game option to play without maintenance... or am I missing something?
How do you want to manage the amount of failures? I guess they "just happen" depending of a low random number, independent of any maintenance value?!?There is a general game option to play without maintenance... or am I missing something?
I think it will be better if a player will have an option to turn maintenance off and cricical failures (i.e. my suggestion) on - some players use maint. modules and installations, just do not bother with supply tenders.
How do you want to manage the amount of failures? I guess they "just happen" depending of a low random number, independent of any maintenance value?!?
Randomly getting screwed by unavoidable RNG with no counterplay
Random breakdowns are not really good storytelling either
Frankly I don't think large, multirole ships need help. Smaller specialized ships may give better performance, but they are also easier to target
The counterplay, obviously, if to have spare tugs/docks, tankers and bases. That's more deepness in the sky.
Frankly I'm very surprised that smb thinks like this, because for me it's surprizes that makes game more like a story.
Because now I know that nearly every case my ship was caught by critical failure - it was my failure, my stupidity or carelessness, and just I cannot forget about it, and it's therefore not a story at all.
Frankly I don't think large, multirole ships need help. Smaller specialized ships may give better performance, but they are also easier to target
I think it's obviously the opposite - they are harder to target, especially with missiles.
I dunno if I like the general premise of enforcing redundancy per se though. For instance, if I was allowed to have a small backup thruster on a ship, then that is not nearly as big of a deal, but I am forced to have all engines be the same size, which would effectively be cutting max engine size in half. I am less a fan of that personally.
It would be less frustrating to have temporary failures that don't cost anything to resolve other than time. Can still be catastrophic if the FC farts out at the wrong time or the engines suffer a 30 sec flameout and IMO would still be arbitrary and annoying as opposed to providing a good story to tell.
I will add that movies and shows tend to time 'random' mechanical failures to the beat of the plot and tend to make it into this whole carefully presented dramatic extravaganza that really adds to the narrative. Usually this failure was necessary in order to make something that was otherwise unlikely happen. (i personally usually dont like it very much as a plot device personally but admittedly it can work)
This tends to skew perception of such things, as when they are actually random they are usually just annoying.
If the "counterplay" is "more micromanagement", I cannot say I am in favor of it.
If my ship runs out of MSP or suffers a critical failure due to something I did - poor design, pushing it beyond its operating limits, and so on - then it is my failure, and knowing this is a possibility makes the decisions that lead to those cases interesting. There is a tangible story which has led to this, or which could have led to this. It's not "my failure" if my engine blows up due to a random dice roll.
A good narrative IMO has a meaningful cause and effect which feeds back to the gameplay.
I think usually when we talk about such ships we are talking about sizes >100 HS
I do agree that things are generally balanced as it is.
Some small scope of it, as a tradeoff.I'm not really in favor of this, but okay. Let's try to guess how this would work.
As it is now - most of our bases are just skeletons of the bases, because we really need no harbor tugs and tenders, nor tankers aside of major fleet operations and (not always) deep survey.
With my suggestion implemented - we'll need some stable harbor ship composition, but we'll not need to use it frequently - we'll need just to have it in place or to humble about some losses for the god of Void. And it will be meaningfull choice in most cases: you'll need to choose better places for your bases, balance your support infrastructure, but it will be one-time decision for nearly every base, no boring every year routine as with combat ships overhauls and cargo flows; you'll need constant flow (building) of tugs, tankers and tenders, but it will be a flow of nearly the same classes (maybe with some modernizations from time to time), so no need to retool your shipyards serially (or look at an idle one and make yourself believe forcefully that it's ok to have lazy governors in this scope), when you have done a series of tankers and now you need no such ships for the age, but now you need several tugs, and several years later your yards are idle again, because now you need no tugs any more for ages... That's the micro! That is a dilemma between boring and disbelievable!
So the game will benefit from being more deep and steady.
Look at it in the same light as at commanders'' accidental deaths. There are some small chances that any commander can be killed in accident. Is it adding a micro? Yes, in some small scope. But it's adding a deepness both in your personnel policy and in your story.
Ships are the same.
You have nearly no chance to such random dice roll now, if your design is not skimpy and your orders are just not feckless (aside of combat conditions). You have ZERO chances to this random dice roll with all commercial designs - they are now ideally trouble-free and everlasting, and there is no option to have some balanced variant: your choices are just "have failures and MSP" (and so micro) or "trouble-free and everlasting" (and so disbelieve).But there is a chance, even if a very small one. And that automatically warrants spending yet another batch of minerals to T/MC/S fleets...
So, I think it will be good to have an option to set more balanced rule.
If you have no such desire - don't turn it on.
The same as for new spoilers (those are very much in the same deepness-in-the-sky flavour).
It is so for the short story or the play (theatrical). It is obviously not so for novel-scope story. And Aurora is making novel-scope stories undoubtedly; there is a univerce-scope scenery, not a chamber-scope. Universe is a place, where accidents are inevitable everywhere and they are forming the structure of civilization. My strong preference is to play with more scope, though, again, it have to be optional feature, because, yes, there are players that will prefer lean stories.Ehhh... I dunno. I prefer to see the consequences of my actions, rather than... random encounters..?
I'm talking also about sizes from FACs (that are often somehow decennary-autonomous) to frigate-size deep surveyors (nearly everlasting because why not, isn't it?), missile and PD ships.With how maintenance-inefficient large all-in-1 ships are, it is tempting to turn off maintenance requirements - to satisfy your megalomaniac-ish desires...
But it's not a main point. More important that now we are not paying much for overspecialization (because nearly no chance, that some accident will take down, say, PD half of your squadron and so you're a toast), and therefore we are getting sucked in more-and-more-combat-ships-because-it-is-the-only-efficient-way micromanagement maelstrom, where you'll have nearly the same dilemma: to pretend that it's an accident probability where game-wise there is no (and to make accidents to youself manually, just to have a story coherent), or to play with rules you have and be more and more sucked in late game micro.
The problem, I think, that it's balanced with seemings, not with decision-making dynamics.What?
With new spoilers it can become more apparent.
As it is now - most of our bases are just skeletons of the bases, because we really need no harbor tugs and tenders, nor tankers aside of major fleet operations and (not always) deep survey.
Look at it in the same light as at commanders'' accidental deaths. There are some small chances that any commander can be killed in accident. Is it adding a micro? Yes, in some small scope. But it's adding a deepness both in your personnel policy and in your story.
If you have no such desire - don't turn it on.
It is so for the short story or the play (theatrical). It is obviously not so for novel-scope story. And Aurora is making novel-scope stories undoubtedly;
and therefore we are getting sucked in more-and-more-combat-ships-because-it-is-the-only-efficient-way micromanagement maelstrom,
[...]
The problem, I think, that it's balanced with seemings, not with decision-making dynamics.
Ehhh... I dunno. I prefer to see the consequences of my actions, rather than... random encounters..?
So, what you're essentially asking for, is that commercial ships also suffer maintenance failures? Stations included?
Do the maintenance failures occur when in deep space?
Are they safe when above a 50,000+ colonist-having body? Or do they have to have a maintenance facility? A shipyard?
With the possible locations on where it could happen set, what actually happens?
And about how to fight it... You're basically asking to double if not triple (and +1) our current Tug, Maintenance Carrier and Salvager fleets?
Commander accidental deaths can be disabled with 'story character' setting.
Hey also - would civilian ships also suffer from this?
Ehhh... I dunno. I prefer to see the consequences of my actions, rather than... random encounters..?
But, if this would ever be a thing, can we at least get salvager, maintenance and tractor beam modules technologies as a free starting technology, upon developing trans-newtonian technology?
With your idea of making civilian ships suffer maintenance failures, mechanically game shifts towards numerous designs and numerous different ships.
Or is it that failures are disabled when a ship has a maintenance module?
I do not think adding mechanics expressly to encourage a specific playstyle is a good addition to the game and there are many other things I would personally rather see Steve focusing on, not that my opinion on Steve's time management matters one bit of course.
Or, actually...With your idea of making civilian ships suffer maintenance failures, mechanically game shifts towards numerous designs and numerous different ships.
?Or is it that failures are disabled when a ship has a maintenance module?
If a ship is able to fully maintain herself... well, it's not very often design, but I think it's tolerably to consider them failure-free just to make no exception of general micro-lessening rule.
I personally prefer to see genetic modification tree working, Terraforming installations buffed and ground combat HQs having an option to give bonuses to units on different worlds and ships. :)I do not think adding mechanics expressly to encourage a specific playstyle is a good addition to the game and there are many other things I would personally rather see Steve focusing on, not that my opinion on Steve's time management matters one bit of course.
Well, I don't see how it's only to encourage a specific playstyle (I have made some other explanations about what is this for), but even if it's so - what are you doing by repeatedly expressing a dislike to suggested optional feature?
Again: if this suggestion will face no enthusiasm - it just will not be implemented, and if it will suddenly face some (positive) enthusiasm and will be implemented - those who dislike it just will not turn it on, so you will not suffer in any case.
What is the point of arguing about personal preferences in this case?
Is failure rate % per ship? or a %, divided across all the ships?
1. Measure wall clock time on the turn and if it takes less than, say 0.1 seconds IRL, have the game just delay for a bit if auto turns is enabled
And I'm not sure if I understand what do you mean on "to manage". smeg happens.Sorry, I am from Germany and I think I used our understanding of "Managen" for that word... . So I meant basically what you described. I dislike the idea of it being completely random. You as the player should be able to "manage" the chance of how often the failures can happen by choosing how much you want to invest in such failsafe systems. As you are now able to. The amount of maintenance use can vary greatly depending on your designs. And due to increase in size of the ship these things affect the rest of its function as well... . Wouldn't like to loose that feature.
I dislike the idea of it being completely random. You as the player should be able to "manage" the chance of how often the failures can happen by choosing how much you want to invest in such failsafe systems. As you are now able to. The amount of maintenance use can vary greatly depending on your designs. And due to increase in size of the ship these things affect the rest of its function as well... . Wouldn't like to loose that feature.
That's why my suggestion is not to remove MSP and normal failures as they are now, but to add some small (and optional) probability of "smeg happens", that cannot be removed.I misunderstood your idea as removing the actual system. Hmmm, additionally then... .
I just now noticed that larger planets' and moons' diameters always seem to be nice multiples of 100. This makes generated systems feel a bit less realistic: for example, in my current game there is a gas giant that has three moons each with a diameter of exactly 2,800 km.
Would it be feasible to add some random noise (say, +/- 10%) to bodies' diameters during system creation?
That doesn't really make sense, once the body is survey scanned we should pretty much know down to the millimeter.
I'm fine with rounding personally, seems like a minor inconsistency that Sol doesn't match that.
Group by class in Naval Organization, with a pop up when drag and dropping for how many of that group to move, to minimize fighter micro especially for micro-fighters. Failing that box select and drag and drop if at all possible.
Thought I`m suspecting this isn`t possible for some reason, as due to being so obvious it would be in the game if it was.
A suggestion, that cannot be implemented easily, and I don't think it will face some enthusiasm, yet... you never know.
A thing that is even more disbelievable for me, than a linear laws of cost and so on from the previous my suggestion - is crew needs.
Now we have very strange situation, where nearly barebone freighter (1 standart hold, 1 bay, 4 low-tech commercial engines and 1 large fuel tank) requires 73 of crew members, most of them for engine support. Basic refuelling module requires 20 of crew members alone, so a tanker will eat even more human souls.
Large modern seafaring freighters and tankers usually have crews less then 10 men. The biggest ones - from 10 to 50 men security personnel including. They require no more then several men to support their giant engines.
What are doing those tens of space mariners for every standart commercial engine in Aurora?
It's not just about engines - some other component types are even more strange in this aspect.
So I think it will be great to revise in some future version all crew needs for components to drastically reduce both commercial and military crew needs aside of such components as luxury passenger accommodations, diplomacy modules and so on, that are really personnel-devouring by their inevitable nature.
Well these are deep space vessels so I understand to some extent why the engines need more crew. IMO components like reactors should need more crew and beam weapons should need a lot less crew.
1. Make Build Points / Wealth Cost for all components square rooted from their sizes (the same as Research Points now) instead of linear.
2. Add a modifier to Hit Chance, square rooted from the target size (with x1 point at 1000 tons as a natural watershed between spacecraft and starships).
Allow for ships to power down their engines, to reduce their thermal signature massively at the expense of having access to passive sensors only, no fire control, shields or weapons during this state. Possibly including a time to bring full power back, which could be affected by no. of reactors, engines and engineering skill of captain/officers.
A suggestion, that cannot be implemented easily, and I don't think it will face some enthusiasm, yet... you never know.
My main problem occurs with respect to missile warships/beam warships. I find it really weird how missiles require so much less crew than beam weapons - my 21,600 ton missile cruiser which does not use box launchers and even has it's own self-defense beam weapons (15cm particle lance and gauss PD) still has less crew (525) than my beam focused 13,930 ton light cruiser (533).
1. Make Build Points / Wealth Cost for all components square rooted from their sizes (the same as Research Points now) instead of linear.
Why? The change to component RP made good sense, but I don't understand how this makes sense. If a component is 10x larger, it should also take 10x more material to build, yes? Obviously there are many possible complications to that, but for a simple model linear makes the most sense.
I don't think this makes sense either. Given that beam combat takes place at ranges of 10,000s or 100,000s of km, the size of a ship is a rounding error at most in accuracy calculations. Even something like a Star Wars Star Destroyer or MC Cruiser which is ~1 km in size is a fraction of a fraction of a %CTH compared to the effect of such long range.
Why encourage small ships?
Material - yes, operations time - absolutely no.
Look at real factories and shipyards production stats.
Cross section is cross section even if it's close to rounding error and there is absolutely no rounding error, when an impact is closing.
Just believe if you are not a specialist in relevant field - and you are not, obviously.
(My military training specialization - however second-grade and distant in time - is yet radio- and fire control systems and procedures, AA missile systems including, and I'm very familiar with math, physics, electronics and sensors aside of military training time.)
Material - yes, operations time - absolutely no.
Look at real factories and shipyards production stats.
So in that case, it sounds like a more reasonable approach would be to have build time and cost decoupled?
On the shipyards side however, the build rate is linear with shipyard size as a+bx
I'm not denying the physics of cross section
...
so I have no trouble at all believing that my science-fiction weapons can have the precision to hit ships of different sizes equally well.
While I certainly understand an interest in realism, it is important to ask "realistic compared to what?" as there is a salient difference between "realism" and "believability" or perhaps a better term is self-consistency.
Because for missiles velocity in Aurora is a factor, and ships are now suddenly not from the same universe.
To fix it with component cost mechanics change (regarless of being produced by SYs or factories of any type) - is to fix a problem itself with approximately the same time spent and more consistent model as a result.
Well, you are not denying the physics of cross section in the first string and you are completely and absolutely denying the physics of cross section in the second string.
Because for missiles velocity in Aurora is a factor, and ships are now suddenly not from the same universe.
P.S.
Just for example.
Production time of average modern fighter (smth about 0.02kt) is only about 2 or 3 times shorter then building time of 100kt supercarrier.
Compare to Aurora Build Time for the same scope of sizes.
In general, for most components the cost in minerals scales proportionally with size.
I can understand the concept of cross section perfectly fine, and at the same time believe that the fire controls and weapons in Aurora can have sufficient precision that cross section effects are much less important, even negligible, compared to extreme range, speed, evasion, and so forth which characterizes the Aurora universe.
Anyone who works with beam optics of any sort will tell you that this is utterly impossible
A quick Google search reveals the following:
For a F-35A the required amount of labor is around 40,000 man-hours, as of 2017/2018. Of course this has likely decreased since then but it is a good rough number.
For a Nimitz-class CVN, 40 million man-hours are required, a factor of 1,000x greater.
It seems to be that mechanically, the "issue" is that fighter factories are much more efficient than shipyards because they can operate as an aggregate unit. Something similar to how GFTFs work would probably be more reasonable if the goal is to model real-life production more closely.
words about cross section
That's why my personal lore is that in Aurora combat space is a projective 2-dimensional space with compressed effective distances (i.e. Aether).
I think at this point the best course is to agree to disagree, as it is clear we do not have any disagreements on physics but rather RP considerations, and it is of course useless to argue RP considerations.
That's really very close problem: the same as with fighters vs warships we have a swing between nearly momentary start of production for small formations (so you have to remember to manually delay your production or stockpiles every time, if you want to RP, and if you are not - it will be a mess of forgotten tasks and stopped production), while bigger ones (like STO guns) are disproportionally slow and costly. With linear law for BP it will be nearly impossible to fix this - we'll have to jump from one shoulder of this swing to the opposite inevitably. With slower BP general law (smth like square root) it will be possible to easily fix the second end of this problem in the next iteration - by adding preliminary operations (~building prototypes and production lines as an abstracted, automated, yet tangible background). Thereafter we'll have a combination of not-so-slow build time for small-number large-scale objects and in the same time a slow start for serial mass production. It will be more consistent (one cost law for any production type) and much more player-friendly (united pools of industrial facilities without unnerving too-quick-ending small tasks).
Thus I think probably a better approach would be to rework fighter factories, so that the mechanics are otherwise kept consistent (as presently they work fine in most areas) but fighter build times can be made more believable. Something like for example dedicated production lines, similar to shipyards but with fighter factories, would be interesting. For example such a system could involve a new tab or a new category on the shipyards tab, where the player groups a number of fighter factories together as a production line and assigns a particular class of fighters to be built. This would allow for a retooling mechanic, representing the lead time to convert for new construction, and limit build speeds for single fighter classes while production for a large number of fighters and classes keeps roughly the same balance. As a bonus these lines could also be used to do refits - fighter refits are a much-requested feature so this would be a great bonus.
This amuses me, because on one hand you say there is no possible physics handwaving that could convince you (personally) to ignore cross sections, but you have no problem personally handwaving beam dispersion.
To me this is the opposite, because beam dispersion under present physical understanding has an absolute lower limit (tied to caliber) which guarantees 100x to 1000x divergence - and this is a lower limit! However it is easy to handwave with TN tech and claim this limit is eliminated by TN magic.
P.S.
Just for example.
Production time of average modern fighter (smth about 0.02kt) is only about 2 or 3 times shorter then building time of 100kt supercarrier.
Compare to Aurora Build Time for the same scope of sizes.
In Aurora smaller ships ARE faster to build per population and minerals put into Shipyard construction.
In Aurora smaller ships ARE faster to build per population and minerals put into Shipyard construction.
That IS a part of problem I have tried to explain.
Though already lost a hope to succeed.
I think ground support fighters should be built as ground equipment instead of as space fighters.
It would be less time-consuming by having them baked into a formation to support from the start like artillery is. Having them under the Army's direct command also makes more sense, as would their reduced size. The smallest GSF I could build was still 50-75 tons, and even that seems too large for a bomber/fighter meant to operate in atmosphere.
Only problem then is simulating GSFs operating from space-borne carriers. Perhaps they have to be loaded in to a new type of hangar and then provide air support automatically when its mothership is over a world?
Right now when terraforming bodies and removing gasses, when that gas is completely removed the game automatically sets the active gas to "none" to prevent issues. This is the desired outcome for every gas, except one:
Water vapor.
The problem I have happens with a lot of terraformers and/or small bodies where the terraform speed is too damn high. What this means that in every 5 day increment, all the water vapour gets sucked out of the atmosphere, which sets the active gas to "none", but I still want to drain the swamp which means that advancing the game becomes quite excruciating given how long draining a swamp usually takes.
My suggestion is to make water vapor an exception to the auto-stop terraforming rule so that terraformers can automatically remove the new vapor that is forming after the previous got sucked out.
It may or may not be practical to re-order the calculations like that, if its easily possible thats definitely the right way to go however.Once Steve has the time to redo the terraforming interface, we'll hopefully get a "target atmosphere and water level" window and then just leave the TF stations to do their business.
Would be kindof nice to be able to set a target surface water percentage though. This would also be an exception but in my opinion a logical one.
Suggestion:Add up to that, how about making engineering spaces, maintenance storage, fuel storage, cargo space, cryogenic and ground troop transport components design-able? I much prefer them to be able to design them (from the get-go, Conventional start) rather than research them. Making them design-able during conventional start could also allow us to play some interesting scenarios, set in home system as well.
Variable cargo space/cryo pods/ground troop transport.
Simply cargo space you could design as a component of variable size.
Would be especially useful for boarding pods, rescue fighters and RP. Its cost/HS could be that of whatever cargo space is next down. So, 26kt would have cost of 25kt + whatever extra kt would add rounded up while 200kt would have that of 125kt +75 extra rounded up.
Also. . . I do find it a bit odd with the ground troop transport component - I understand that the simple cargo space component is not really designed to be with full-fledged life support, but, do we really have to have a separate component for troop transport?I always think that the troop transport component also includes training facilities, briefing rooms, small maintenance equipment, even shooting ranges and gyms. So the troops can perform some training and preparations during the voyages.
I always think that the troop transport component also includes training facilities, briefing rooms, small maintenance equipment, even shooting ranges and gyms. So the troops can perform some training and preparations during the voyages.And it is made, so that the troops being transported actually retain their capability to be combat-effective...
Also... I do find it a bit odd with the ground troop transport component - I understand that the simple cargo space component is not really designed to be with full-fledged life support, but, do we really have to have a separate component for troop transport? We already have drop bays and boarding bays...
Instead of completely disabling shipping lines, would it be possible to just impose a cap on them? I would like to have the shipping lines upgrade their ships to be honest.There are caps to them and they definitely do upgrade their ships. What sort of numbers are you seeing currently?
I mean, do we really need so many different types of transport components? Can we simplify it from:
3+ (cryogenic, cargo, troop with boarding and drop) to 2+ (cargo not requiring a life support, cargo requiring life support with boarding and drop)?
Yeah, agreed with Density here. I always make three different transports:
1. Slow and cheap garrison hauler that moves units from Earth to colonies during time of peace.
2. Big and armoured landing juggernaut that drops armoured regiments on enemy planets.
3. Fast and expensive assault shuttle that commits boarding actions.
And I could see situations where I have different varieties of those three as well. Troop transport modules also include life support and training facilities for the troops as Elminster said, so that they maintain their combat capability despite long voyages.
What I would like to see is emergency carry capability:
If a ship and/or fleet has both cargo capability and cryogenic capability, then it can carry ground units with some ratio between the two- this would allow for emergency transportation in early game or crisis situation, where the soldiers are shoved into cryo-pods like colonists are while all their gear is packed away in the cargo holds. The ship/fleet could not commit boarding or drop actions, only unloading that would take 2x the usual amount. That way you would still want to make purpose-built troop transports.Instead of completely disabling shipping lines, would it be possible to just impose a cap on them? I would like to have the shipping lines upgrade their ships to be honest.There are caps to them and they definitely do upgrade their ships. What sort of numbers are you seeing currently?
Suggestion:
Variable cargo space/cryo pods/ground troop transport.
Simply cargo space you could design as a component of variable size.
Would be especially useful for boarding pods, rescue fighters and RP. Its cost/HS could be that of whatever cargo space is next down. So, 26kt would have cost of 25kt + whatever extra kt would add rounded up while 200kt would have that of 125kt +75 extra rounded up.
Ah, right now there are probably around 30+ civ ships in total?Sorry but you're going to have to live with a few more until they start upgrading ships instead of buying new ones. But it won't get to hundreds per shipping line like it used to.
It would be nice to have more control over maintenance production.
In the early game you have to build many maintenance facilities to support your ships. But later you have research to increase the production rate for maintenance. At some point it could be that you may have way more production than usage, which is eating through your minerals (especially Gallicite).
While you could stop production entirely, you can also easily forget about it and be out of maintenance entirely when needed.
I suggest an adjustable percentage value, so you can tune down the production during peace time and crank it up again when needed.
It would be nice to have more control over maintenance production.
In the early game you have to build many maintenance facilities to support your ships. But later you have research to increase the production rate for maintenance. At some point it could be that you may have way more production than usage, which is eating through your minerals (especially Gallicite).
While you could stop production entirely, you can also easily forget about it and be out of maintenance entirely when needed.
I suggest an adjustable percentage value, so you can tune down the production during peace time and crank it up again when needed.
I would like to both second and third this, but cloning technology has not yet been implemented in Aurora so I can only second this.
It would be nice to have more control over maintenance production.
In the early game you have to build many maintenance facilities to support your ships. But later you have research to increase the production rate for maintenance. At some point it could be that you may have way more production than usage, which is eating through your minerals (especially Gallicite).
While you could stop production entirely, you can also easily forget about it and be out of maintenance entirely when needed.
I suggest an adjustable percentage value, so you can tune down the production during peace time and crank it up again when needed.
I would like to both second and third this, but cloning technology has not yet been implemented in Aurora so I can only second this.
I also like this, especially if you do the same for fuel (though admittedly less essential as very few components use raw sorium)
Eventually, the Maintenance and Fuel start-stop buttons should be extended with a Factory one where when you stop, you are shutting down the production as it was in VB6, saving also workers that could be relocated elsewhere then. A cooldown restart would be also appreciated (again as it was already in VB6).
Currently, a number of quantities which scale with starting population at game start have hard limits beyond which they do not scale. The most obvious of these is research points and research labs which are both capped at 200,000 and 50 respectively (corresponding to 1.25b population). Similarly the number of starting officers is capped at, IIRC, 200 (where the default is 150 officers at 500m pop) which tends to be not enough at high populations with a lot of free BPs.This needs to be hard doubleplussed in my opinion. I am sure there are a lot of people who can't take the micro of manning multiple player races and this would be great for them. While I don't want to dismiss the other suggestions I think this needs to be mentioned.
I would suggest that these and any other hard caps are removed and the scaling with population is directly proportional for all populations, possibly with a minimum for very low-pop starts.
While it is trivial for the player to change these quantities at game start, the bigger issue in my mind is the NPR balance. Additionally I think removing particularly the 50 Labs hard cap would help generated NPRs in the later game period remain competitive, as right now it is possible for the player to easily exceed the generated NPR starting tech levels once they have 75 or 100 labs and a few levels of RP boosting tech since new NPRs are still limited to 50 labs on spawning.
[snip]
It may be said already, but starting to feel the need for a Standing Orders Template
Also, the more I think about it and the more I realize that being the same for essentially every race and ship, such templates could be exported, imported and shared through the entire database.
I think I could spare something like 100/200 clicks and repetitions.
There shouldnt be any actual need for a solver to calculate this. Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.
There shouldnt be any actual need for a solver to calculate this. Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.The missile guessed a direction, then plotted what happened. Based on that information, it made a better guess and then repeated until it picked the right course. No complex math and hit every time :)
Some interesting work here. I do have a quick question: does your algorithm account for the fact that planetary/body motion in Aurora takes place only on the construction increments? It seems like that should make an algorithm much easier, since you can basically loop over a limited set of body positions instead of solving a problem in continual dimensional space.
This would require pathfinding to be aware of the time until the next increment, which I don't know if it currently is, but otherwise would be simpler and not require more complex algorithms. I think particularly this may be important as I doubt Steve wants to use other libraries to write his code for him, since Aurora is a coding hobby project as much as a game for him.
There shouldnt be any actual need for a solver to calculate this. Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.
There shouldnt be any actual need for a solver to calculate this. Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.
Funny you should make that post today :)
In Newtonian Aurora, I had a problem of a missile intercepting a ship from a billion kilometres away. Unfortunately, both were accelerating and both were burning fuel, which meant constant changes in mass and therefore rate of acceleration. After tackling the complex math, I hit on a much simpler solution. The missile guessed a direction, then plotted what happened. Based on that information, it made a better guess and then repeated until it picked the right course. No complex math and hit every time :)
I could write some code to calculate the intercept, even with the new eccentric orbits, but it would add processing time. I'm not sure how much without coding it, but movement is the already the largest time-sink. It would also require the necessary enthusiasm from me to solve a problem that isn't really a major issue.
In summary, the reason that ships don't intercept planets is not due to an inability to solve the problem, but rather a question of priority and enthusiasm.
Would it be possible for officers who are on a ship, but who are not the commanders, to add the accomplishments they achieved while on the ship?
For example, a science officer could add stellar objects he discovers with minerals, or new systems he discovers, to his achievement record.
An executive officer, tactical officer, CAG, etc. could add the tons of ships destroyed, ground units destroyed, etc.
In this way, the character's entire career would be recorded.
Thanks Steve!
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .
There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .
There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.
How do you find performances? Also what about failures on ships but especially on fighters? Still acceptable or more "risky"?
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .
There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.
How do you find performances? Also what about failures on ships but especially on fighters? Still acceptable or more "risky"?
Maintenance failure chance is I think also based on the size of increments so it wouldn't overall affect maintenance costs/life for standard ships.
As for fighters, I usually have a fighter maintenance storage onboard, but only if the fuel time of the fighter is longer than 24 hours, if the fighter spends less then a production increment out of a hangar then you don't have to worry about maintenance on it.
Game performance wise, it's the same pretty much, a single 1 day increment is only slightly faster than a single 5 day increment. Only thing to note that doing 5 1 day increments takes longer than doing 1 5 day increment.
Another benefit of 1 day increments are when terraforming really small bodies and/or with lots of terraforming modules/facilities. 1 day increments allow you to avoid situations where you "overterraform" and have to rectify/SM fix the mangled atmosphere.
There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.I wanted to avoid the game performance loss - but it is viable this way, yes.
Another benefit of 1 day increments are when terraforming really small bodies and/or with lots of terraforming modules/facilities. 1 day increments allow you to avoid situations where you "overterraform" and have to rectify/SM fix the mangled atmosphere.I didn't know that. Interesting... . Maybe Steve should take this into consideration and "fix" it.
I'll give it a go then. I am enjoying my current setup with reduced growth for realistic pop, capped mines based on body size, 5% survey, 10% terraforming and DB edited for infrastructures produced only by colonies over 500 million pop. I was about to post some findings about it but the 1 day increment sounds nice addition.Where can you edit that into the DB? Only produce when over 500 mill pop?
Where can you edit that into the DB? Only produce when over 500 mill pop?
I've been using 1-day production cyclen with 1-day increments since Day 1 of C# and it works well for me, I'd definitely suggest switching to it. In fact, it should probably be the default now.
In my current game, I seem not to be able to change the production cycle. Is it possible only at the start?
Also, I'm thinking how to improve the auto-assigment in order to make it much more efficient and avoid ships without CO and officers free of assigment.
The main "limitation" left is that officers with no relevant skills will not be assigned to any role, or if their only relevant skills are for roles that aren't open they will not fill that role.
The main "limitation" left is that officers with no relevant skills will not be assigned to any role, or if their only relevant skills are for roles that aren't open they will not fill that role.
This is what I am talking about. I can't understand that a very expensive organization as the navy will have just one officer, that needed a lot of money to be totally educated, sat in a chair filling sudokus. I guess the navy would assign him/her to any vacancy available.
You are all missing an important point.
For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.
So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)
You are all missing an important point.
For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.
So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)
This is kind of what I was implying. I implicitly assume all of my unassigned officers are at Naval HQ sitting at desks pushing pencils and arguing about particle beams. :P
You are all missing an important point.
For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.
So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)
This is kind of what I was implying. I implicitly assume all of my unassigned officers are at Naval HQ sitting at desks pushing pencils and arguing about particle beams. :P
Are they pushing pencils or stabbing each other with them?
Officer's Mikado (pick-a-stick), whoever moves first has lost. ;DYou are all missing an important point.This is kind of what I was implying. I implicitly assume all of my unassigned officers are at Naval HQ sitting at desks pushing pencils and arguing about particle beams. :P
For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.
So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)
I had some ideas regarding ground forces that might give players more interesting options when designing their troops. They're largely focused on making infantry and other small unit types more useful. (There are a number of other higher-priority balance and QOL improvements that could be made to ground forces, but those have been discussed extensively elsewhere.)
words
Both these additions would give infantry a more useful place on the front lines and allow for more variety and RP opportunities in ground forces design. The first idea is likely easier to implement and balance than the second, but I think they could both probably be made to work.
One idea is a new infantry-only capability called "Infiltration" or "Commando Tactics" or something like that which would double the unit's breakthrough probability (that is, it would negate the 50% reduction in breakthrough probability that infantry have relative to vehicles).
A more extensive addition would be to add new technologies that allow the larger anti-vehicle weapons to be used by smaller unit types, kind of like the compact and small craft ECM/ECCM tech lines. So after researching SHAV, for instance, you would unlock a tech that allows HAV weapons to be used by smaller vehicles and then eventually by infantry. (For the sake of balance I think you'd probably want them to be the same size as the standard weapons, although miniaturizing them for infantry use does make more sense than having infantry somehow dragging around a giant gun.) After all, if the US could deploy tactical nuclear weapons to infantry units in the Cold War, I imagine Trans-Newtonian militaries will find all sorts of new and creative ways of putting massive firepower into the hands of their grunts. :)
It would be nice to have a flag for NO Civilian Mining Colonies.
It would be nice to have a flag for NO Civilian Mining Colonies.
You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?
Not sure if this has been suggested before, but I have an idea for civilian colonist transport. Under the current system civilian colony ships can remove more population from a colony than you want them to or sometimes even completely empty out the closest available "source" colony, which then gets set to a "destination" colony since it is below the 10m minimum for a population source, so the civilian fleet will now continually deliver more colonists there.
My suggestion to fix this is to be able to set a target population that the civilian shipping aims to fulfill. Set the target of e. g. Luna to 50m, the civilian shipping will start by shipping people there until the population reaches 50m, and then as the population grows naturally ship them off to other colonies but never below the target that was set. This target number could even be set to match the current worker requirement of the colony.
Aside from this, a checkbox for "Emergency Evacuation" would be nice. So the civilian sector and government colony ships on "Standing Order"-duty prioritize pulling population.My suggestion to fix this is to be able to set a target population that the civilian shipping aims to fulfill. Set the target of e. g. Luna to 50m, the civilian shipping will start by shipping people there until the population reaches 50m, and then as the population grows naturally ship them off to other colonies but never below the target that was set. This target number could even be set to match the current worker requirement of the colony.Might be nice, i would also be in favor of a check that would stop civilian colony ships from pulling population off a world if it would put the production sector into negative workforce.
It would be nice to have a flag for NO Civilian Mining Colonies.
You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?
Yes. But it would still be nice to have a flag for it to remove the micromanagement involved in doing this.
I think he means no civilian colonies period.
I think he means no civilian colonies period.
It would be nice to have a flag for NO Civilian Mining Colonies.
You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?
Yes. But it would still be nice to have a flag for it to remove the micromanagement involved in doing this.
Wouldn't it be the same amount of micro-managment to check a box saying 'No Civilian Mining Colonies' as it is to press a button saying 'Create Colony'?
Perhaps you don't want it cluttering up the colony screen, but if you are restricting a planet from being used by civilians I assume you intend to use it yourself anyways.
It would be nice to have a flag for NO Civilian Mining Colonies.
You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?
Yes. But it would still be nice to have a flag for it to remove the micromanagement involved in doing this.
Wouldn't it be the same amount of micro-managment to check a box saying 'No Civilian Mining Colonies' as it is to press a button saying 'Create Colony'?
Perhaps you don't want it cluttering up the colony screen, but if you are restricting a planet from being used by civilians I assume you intend to use it yourself anyways.
I can't speak for froggie, but what I want is a global flag on the game settings screen for this. One click, no CMCs. As ArcWolf pointed out, we already have them for civ shipping and civ fuel harvesters.
I can't speak for froggie, but what I want is a global flag on the game settings screen for this. One click, no CMCs. As ArcWolf pointed out, we already have them for civ shipping and civ fuel harvesters.
Specialized and DeSpecialized Industry
Usually my fighter and ammunition factories don't do a lot. They just exist in case they are needed.
I was wondering if it would make sense to allow normal construction factories to produce fighters and ammunition as well - much like prebuilding ship components with them - but of course at a slower production rate than specialised industries.
This would additionally give the option to switch industries to specialised industries as a preparation for war to be able to quickly produce the then needed fighters and ammunition - and later after the war build them back into normal industries. A little bit like it is handled in Hearts of Iron 4 - where you can switch normal industry to war production industry and vice versa.
This could also be used as a political indicator. A country which switches its industry to war production will likely go to war - and can be handled as such. This of course needs to be visible through elint for example.
I'm guessing this has been discussed and rejected before, but if so I haven't seen it.
Would there be a way to have a 'capped' Known Stars game? I like having real-world stars populate the galaxy map but a game with a max of 4,400 stars has a frame-death bullet with its name on it from the start. I'd imagine there are complexities to doing this while pulling from the star catalog.
Aurora is meant to be able to tell stories. Most of our stories are single-player against different kinds of AI. A few attempts have been made to create a multi-player experience and AARs thereof. So I was thinking why so few multi-player ones? Because it is quite a stretch for a game master to manage so many factions and keep the game rolling. What are ways to change this?
If Aurora could export all settings for one race of a game and reimport it into a blank database a single file could be generated for all participants of a multiplayer game. People could import that into their local Aurora and generate all commands and changed they want to do, export these and send them to the game master for re-importing. Sure that involves some programming part on Steves side to not get the live database corrupted. But I think it might be worth it. Who wouldn't want to engage in a fight with another human opponent?
Military or Civilian?
We have a clear distinction between Military and Civilian ships - mostly so that we don't die in micromanaging a bunch of civilian ships. Whilst I generally agree with this, some separations seem to me to be too arbitrary. I was wondering if we could change how maintenance is calculated for engines. At the moment we have a clear distinction: Any engine below size 25 is military, any engine above engine power x0.50 is military. This leads to most of my designs being at the opposite side of these spectrums - very view engines are someplace in the middle.
So how about maintenance below engine power x0.50 stays at zero, then from x0.50 to x1.00 it increases linear and from x1.00 onwards we have the same calculations as we do now. With this linear grade, we could gain the additional option of "fast mid-range transports" that do need maintenance but have superior speed over the non-maintenance transports. Or also some kind of "lower maintenance small military ships". I think adding this option might open up some design options... .
I don't know if doing the same kind of grade with engine size would make sense. But I think it would with engine power factor. All ships from x0.55 upwards stay military, but between x0.55 to x0.95 they have a lower maintenance need... .
This already happens to a degree, because EP modifiers below 1.0x apply as a multiplier to the cost in addition to the usual behavior. So if you have, say, a size-20 ion drive (12.5 EP/HS), at a 1.0x multiplier your engine has 250 EP and 125 BP cost. As a 0.8x multiplier, your engine has 200 EP but rather than the 100 BP you would expect, it is only 80 BP because the cost is additionally multiplied by that 0.8x. Since maintenance cost is tied to BP cost this also affects maintenance requirement.I See and agree that this could go to levels of exploitation. The idea was to have a finer degree between military and civilian - not this abrupt "arbitrary" line at size 25 / engine modifier 0.5x. It would be interesting to see how small maintenance would get if all engines would be military. Is there an option to switch the calculations to all engines being military? I don't think so... well, will take a look into how this all is calculated (oh dear, what am I putting myself into here ;D ::) ).
I See and agree that this could go to levels of exploitation. The idea was to have a finer degree between military and civilian - not this abrupt "arbitrary" line at size 25 / engine modifier 0.5x. It would be interesting to see how small maintenance would get if all engines would be military. Is there an option to switch the calculations to all engines being military? I don't think so... well, will take a look into how this all is calculated (oh dear, what am I putting myself into here ;D ::) ).
My suggestion is that when an NPR is generated mid-game, the game should go through the system and ensure that there is something extra for the NPR to work with. Yes, in a sol start you aren't guaranteed abundance but you are as the player guaranteed to get something on the other bodies of the solar system beyond the poor resources of earth. Especially since NPRs are bad at resource management this might help them be a little more competitive.
An optional auto pause feature that is player definable. For example, once per year I like to check my colonies, fleets, research, production, etc. Other players may want to do it more or less often. Or not at all (thus the optional aspect).
An optional auto pause feature that is player definable. For example, once per year I like to check my colonies, fleets, research, production, etc. Other players may want to do it more or less often. Or not at all (thus the optional aspect).
Until something like this is added I suggest creating a small station around your capital and give it a repeating "send message" order to your capital every 365 days. This will in-effect pause your game once a year.
I personally have it set up to cycle 3 -365 and once 366 day orders to account for leap year some my game "auto-pauses" every Jan 1st.
So, currently an issue I perceive with the game is that it's quite alot of tedious Micromanagement to mine out those asteroids, yet they do contain easily accessible minerals that would be neat to get access to, and that lore wise probably would be lucrative for civilians to go after...
How hard would it be to add some civilian ships that work a bit like sorium harvesters but instead they swoop around our colonized systems and stripmine asteroids for us, so we can just visit a single location and buy all those juicy minerals once they have filled those cargo holds for us with minerals from dozens of asteroids?
So, currently an issue I perceive with the game is that it's quite alot of tedious Micromanagement to mine out those asteroids, yet they do contain easily accessible minerals that would be neat to get access to, and that lore wise probably would be lucrative for civilians to go after...
How hard would it be to add some civilian ships that work a bit like sorium harvesters but instead they swoop around our colonized systems and stripmine asteroids for us, so we can just visit a single location and buy all those juicy minerals once they have filled those cargo holds for us with minerals from dozens of asteroids?
--- I'd add in here the ability for Civilian Shipping Lines to be told to collect from CMCs with the addition that CMCs would build a Cargo Shuttle Station for the purpose of loading / unloading them.
Your basically asking for civilians to get orbital miners in addition to the sorium harvesters they can already get. As long as people can turn it off I have no qualms with this and it would push civies to completeness.
My suggestion is that when an NPR is generated mid-game, the game should go through the system and ensure that there is something extra for the NPR to work with. Yes, in a sol start you aren't guaranteed abundance but you are as the player guaranteed to get something on the other bodies of the solar system beyond the poor resources of earth. Especially since NPRs are bad at resource management this might help them be a little more competitive.
Adding to this, it may be worth giving NPRs a larger starting stockpile of resources (if they don't already, I have not checked) to account for the fact that, especially on higher-population starts, important minerals may be depleted in only 5-10 years and the NPRs often struggle to establish a robust offworld supply of key minerals. This doesn't solve the problem but it does provide a bit more of a buffer for the NPRs to keep their industry and shipbuilding functional while a crunch is resolved.
This was made even worse because the garrison's PD STOs were shooting down 80 of 85 AMMs per 5 secs.
I'm not sure if Steve personally makes lots of use of the wealth screen, but for me I would kinda like it if the wealth button on the map screen was replaced with one to bring up the shipyard screen.No matter what tab I want on the economics window I simply press the research button, it is bright cyan and my mouse gets there without me looking. If we are going to have four buttons to that window, shipyards makes more sense than wealth/trade. Moving the Fleet/Naval Organization window button to follow next would make more sense too; having it in the middle of the various design buttons is an odd choice.
If when a player's mining colony plays out, the name of that colony on the mining tab of the economics screen could be highlighted in red, that would pop right out at the player and make identifying empty mining colonies much easier.
An option that will force commanders on to ships, regardless of skill mismatch. I would prefer for my Junior naval leaders to work as subpar XO's or command freighters than not have a job at all.
This would require also a functionality to replace unqualified officers with new ones when new officers are generated or promoted, otherwise your 125 crew training LCDR may not be able to get an XO job because some nugget with no skills and 45 political rating is loafing on the job instead.
This would require also a functionality to replace unqualified officers with new ones when new officers are generated or promoted, otherwise your 125 crew training LCDR may not be able to get an XO job because some nugget with no skills and 45 political rating is loafing on the job instead.
I'm legitimately okay with not replacing underqualified officers and surely anybody else that clicked that option because like myself they just want bodies in seats.
This would require also a functionality to replace unqualified officers with new ones when new officers are generated or promoted, otherwise your 125 crew training LCDR may not be able to get an XO job because some nugget with no skills and 45 political rating is loafing on the job instead.
I'm legitimately okay with not replacing underqualified officers and surely anybody else that clicked that option because like myself they just want bodies in seats.
also, officers will gain experience where they are stationed, so a "nugget" with no tactical skill serving as a tactical officer after a year may very well have a 5-10% tac skill.
also, officers will gain experience where they are stationed, so a "nugget" with no tactical skill serving as a tactical officer after a year may very well have a 5-10% tac skill.
I have yet to see a serving Chief Engineer or Tactical Officer gain experience in their respective skills (nor have I seen a CO gain Engineering or Tactical). As far as I can tell, those skills are only trained by Naval Admins that use the skill in question, or by academy commandants and unassiged commanders getting random skill training.
Meanwhile, I have a naval officer who picked up Xenoarchaeology while waiting for an XO position, and the top officer of my ground forces learned Diplomacy and Intelligence during his stint running an academy.
A universal tick box for commanders that stops them from being relieved of their current post after promotion. I like to manually assign all my commanders and it's annoying having to put them back in their positions after a promotion.
A universal tick box for commanders that stops them from being relieved of their current post after promotion. I like to manually assign all my commanders and it's annoying having to put them back in their positions after a promotion.
Or at least only promote commanders not current out in 'the field' so they don't teleport back to Earth while in the middle of exploring the far reaches of space.
It's a reasonable assumption (and it's reasonable to hide experience spam in the log). But I didn't say on-the-job training isn't a thing, I specifically called out Engineering and Tactical because I expected it to work in those two cases and I haven't seen it do so.
also, officers will gain experience where they are stationed, so a "nugget" with no tactical skill serving as a tactical officer after a year may very well have a 5-10% tac skill.
I have yet to see a serving Chief Engineer or Tactical Officer gain experience in their respective skills (nor have I seen a CO gain Engineering or Tactical). As far as I can tell, those skills are only trained by Naval Admins that use the skill in question, or by academy commandants and unassiged commanders getting random skill training.
Meanwhile, I have a naval officer who picked up Xenoarchaeology while waiting for an XO position, and the top officer of my ground forces learned Diplomacy and Intelligence during his stint running an academy.
I don't keep track of every officer skill increase, in fact i usually hide them from the event log because it clutters it up, but i've defiantly seen officers serving as COs of Minning/Terraforming stations gain skill in that field while on station. I assume that is true for all officer roles.
The question is, do they need to have that skill or not.I haven't tried it with survey, so I can't verify that specifically (and survey clearly works differently than other skills; +1 vs +5 or 10, and science officers don't seem to get trained in CO skills while other secondary posts do).
It's true and easily verifiable that any officer in a command position will gain relevant skill if they already have it. Thus, captain with survey 5% will have survery 40% after they've commanded a survey vessel long enough. But can you put a captain with no survey skill in the same position and eventually they learn it? This I am unsure of.
It's a reasonable assumption (and it's reasonable to hide experience spam in the log). But I didn't say on-the-job training isn't a thing, I specifically called out Engineering and Tactical because I expected it to work in those two cases and I haven't seen it do so.
Any chance of adding this big chonker in the game? More comets!
https://en.wikipedia.org/wiki/C/2014_UN271_(Bernardinelli-Bernstein) (https://en.wikipedia.org/wiki/C/2014_UN271_(Bernardinelli-Bernstein))
When your empire grows a lot, setting up routes becomes a bit tedious. Especially when the galaxy becomes more like a cross-grid where you can go from one point to another by several routes, not remembering which one is the quickest. I thought to circumvent this by saving a route order template with just the jump points - but that of course doesn't help because you have to save it in the destination system - to which you have no access in the source system.
Is there a way to make this possible?
In general, it would help - though not for jump sequences above 4 systems apart; as well as the blocking can only be used as a general tool. It might be that on a local level of one or two systems apart the jump point needs to be open, but the longer route might be way shorter via another system, and I don't think that "blocking" can differentiate that.When your empire grows a lot, setting up routes becomes a bit tedious. Especially when the galaxy becomes more like a cross-grid where you can go from one point to another by several routes, not remembering which one is the quickest. I thought to circumvent this by saving a route order template with just the jump points - but that of course doesn't help because you have to save it in the destination system - to which you have no access in the source system.
Is there a way to make this possible?
The feature coming in v2.0 to mark certain jump links to be avoided can be used to eliminate the need to remember the efficient route. You should only need to determine the more efficient branch once and then mark the other to be avoided and after that you can forget all about it. It is a manual approach but it should work fine.
--- Internal Armor: In the Class Design Window, I'd like to see a second box for "Internal Armor". This would function just like Turret Armor, adding HtK per layer for each component added to the ship. So a ship with say, 5 Crew Quarters, an Engine and some smattering of other parts would have more HtK with 1 layer of Internal Armor over the exact same ship with 0, and so on and so forth. They would be heavier and more expensive than a ship without of course. :)
--- "Bunker / Transport / Transport - Small" Ground Modules: For Static units only, Bunker modules would be a component that could apply the Static Unit's extra armor to all units either in the same formation as itself or those directly supporting it. It would have a specified tonnage much like an HQ module and would give diminishing returns much like an HQ module if more units than it can handle are added. Transport Modules would work the same way, but would only be for vehicles. Bunker modules would also confer their Hit Mod, that being of a Static unit as well as all other limitations of a Static unit to it's formation and any assigned to directly support it. Transport Modules would confer the Vehicle's armor and Hit Mods as well along with the Armor bonus for breakthroughs to any unit within it's formation. Transport modules would also differ from Bunker modules in that they would need to be directly support a formation to confer their bonus to it if not actually within the formation itself, while Bunkers would need to have formations assigned to directly support them instead. Transport - Small Modules would be smaller than regular Transport Modules, but would only count infantry. All three modules would confer their Terrain / Environment bonuses to units alongside their Hit Mod, Armor and other imitations, but only at half the rate. A new Ground Commander Trait, "Mechanized Operations" or something like that, could increase this... maybe up to like... 75% or something, idk.
--- Missile Batteries: An STO unit that draws from the planet's own stockpiles. Missile Batteries use existing Missile Launchers, much like regular STOs, but any launcher used in them has double the fire rate. Missile Batteries consume ordinance from the planet's stockpiles, using missiles that are specified for them via some new UI element.
~snip snip~
I like all of these, internal armor would have to be incredibly expensive (tonnage and resource-wise) for it to be balanced IMO and also unavailable for stations that use structural shells.
Your bunker/transport idea is interesting because it allows infantry to better play a much larger role in offensives and also allows the player to explicitly define APCs/IFVs that transport troops.
"colonise all mineral rich bodies" and "purge all empty colonies" buttons for using mining ships without developing carpal tunnel.
If possible, "gather minerals from colonies in system" would be nice too, or add it as part of the mining ship routine to gather them before moving on.
FYI: there is already a button to delete all empty colonies. Under the Econ screen -> Summary Screen, at the bottom of the screen there are a few buttons, one is "Rename Pop". The last button on the right is 'Delete empty" Which will do half of what you a looking for.Will it keep colonies that still have minerals on them?
FYI: there is already a button to delete all empty colonies. Under the Econ screen -> Summary Screen, at the bottom of the screen there are a few buttons, one is "Rename Pop". The last button on the right is 'Delete empty" Which will do half of what you a looking for.Will it keep colonies that still have minerals on them?
FYI: there is already a button to delete all empty colonies. Under the Econ screen -> Summary Screen, at the bottom of the screen there are a few buttons, one is "Rename Pop". The last button on the right is 'Delete empty" Which will do half of what you a looking for.Will it keep colonies that still have minerals on them?
I would suggest changing Support unit Defensive calculations from using just Fortification to dynamic system, where it uses Fortification if it supports Units in defence, and to Hit mod if it supports units during attack. It might better reflect combat for role play, as Artillery (Without colossal range, represented in game with Heavy Arty in rear echelons) would have to move with the attacking units, thus leaving the comfort of their entrenched positions. Also it would give more reason to Mechanize your Arty, as now the Hit mod would help them avoid getting hit while Supporting the front line.
Edit. This would be especially Helpful during planetary assaults, where theoretically there is not much time to dig in your arty.
I would suggest changing Support unit Defensive calculations from using just Fortification to dynamic system, where it uses Fortification if it supports Units in defence, and to Hit mod if it supports units during attack. It might better reflect combat for role play, as Artillery (Without colossal range, represented in game with Heavy Arty in rear echelons) would have to move with the attacking units, thus leaving the comfort of their entrenched positions. Also it would give more reason to Mechanize your Arty, as now the Hit mod would help them avoid getting hit while Supporting the front line.
Edit. This would be especially Helpful during planetary assaults, where theoretically there is not much time to dig in your arty.
This would be nice, as currently LVH artillery is strictly inferior to STA artillery. While I do generally subscribe to the philosophy that not every element of the game needs to be equally viable, given the obvious use for modeling real-world military equipment it would be nice if "traditional" SP howitzers were not clearly inferior to their towed counterparts.
For RP purposes and for the "Endgame" feature I would like to have a NULL tech to research forever or a NO research button somewhere like for maintenance and fuel.
This could help with the tedious message and interruption of having no labs assigned to any research.
I know you currently can pause any project and freeze your research and even when everything has been researched you can create a small component and pause the research but still, you'll have to do it for every planet with research labs.
Eventually, if we get the NO research function we also avoid reassigning them once the scientists inevitably die.
For RP purposes and for the "Endgame" feature I would like to have a NULL tech to research forever or a NO research button somewhere like for maintenance and fuel.
This could help with the tedious message and interruption of having no labs assigned to any research.
I know you currently can pause any project and freeze your research and even when everything has been researched you can create a small component and pause the research but still, you'll have to do it for every planet with research labs.
Eventually, if we get the NO research function we also avoid reassigning them once the scientists inevitably die.
alternatively, the option to turn on or off specific interrupts would be nice.
For RP purposes and for the "Endgame" feature I would like to have a NULL tech to research forever or a NO research button somewhere like for maintenance and fuel.
This could help with the tedious message and interruption of having no labs assigned to any research.
I know you currently can pause any project and freeze your research and even when everything has been researched you can create a small component and pause the research but still, you'll have to do it for every planet with research labs.
Eventually, if we get the NO research function we also avoid reassigning them once the scientists inevitably die.
alternatively, the option to turn on or off specific interrupts would be nice.
http://aurora2.pentarch.org/index.php?topic=11780.0 (http://aurora2.pentarch.org/index.php?topic=11780.0)
I did make a tool for this (it says 1.12 but it still works fine).
http://aurora2.pentarch.org/index.php?topic=11780.0 (http://aurora2.pentarch.org/index.php?topic=11780.0)
I did make a tool for this (it says 1.12 but it still works fine).
Nice, i'll give it a try with my next campaign. Still does not mean we can't ask for it to be integrated into the game.
I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle.
As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle.
However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony.
This isn't a huge deal for mobile supply ships as it fits there role. However it currently makes space stations unusable as forward operation bases as far as supply goes. The station can either dole out supplies or receive them but not both. I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix. But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets. Without affecting how mobile supply ships currently function.
Quote from: Velociranga link=topic=10640. msg156697#msg156697 date=1636609674I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle.
As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle.
However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony.
This isn't a huge deal for mobile supply ships as it fits there role. However it currently makes space stations unusable as forward operation bases as far as supply goes. The station can either dole out supplies or receive them but not both. I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix. But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets. Without affecting how mobile supply ships currently function.
It is not ideal, but you can resupply Forward Operating stations from supply ships. Have the supply ship rendezvous with the station, do no merge the fleets. Then give the fleet with the Station the movement order to "Resupply from stationary Supply Ship". It might take a few tries, but it does work. Both Station and Ship are set to "Resupply Own Fleet" incase that makes any difference.
Quote from: ArcWolf link=topic=10640. msg156721#msg156721 date=1636698576Quote from: Velociranga link=topic=10640. msg156697#msg156697 date=1636609674I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle.
As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle.
However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony.
This isn't a huge deal for mobile supply ships as it fits there role. However it currently makes space stations unusable as forward operation bases as far as supply goes. The station can either dole out supplies or receive them but not both. I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix. But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets. Without affecting how mobile supply ships currently function.
It is not ideal, but you can resupply Forward Operating stations from supply ships. Have the supply ship rendezvous with the station, do no merge the fleets. Then give the fleet with the Station the movement order to "Resupply from stationary Supply Ship". It might take a few tries, but it does work. Both Station and Ship are set to "Resupply Own Fleet" incase that makes any difference.
I'll give that a try but I was sure even doing it that way it didn't resupply. I tried a couple of different ways to reduce the micromanagement but trying to get the different fleets orders to line up with travel and resupply time made my head hurt. Either way I feel like we really need a way to initiate the resupply from the supply ship side without joining the fleet you want it to resupply.
Quote from: Velociranga link=topic=10640. msg156804#msg156804 date=1637024194Quote from: ArcWolf link=topic=10640. msg156721#msg156721 date=1636698576Quote from: Velociranga link=topic=10640. msg156697#msg156697 date=1636609674I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle.
As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle.
However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony.
This isn't a huge deal for mobile supply ships as it fits there role. However it currently makes space stations unusable as forward operation bases as far as supply goes. The station can either dole out supplies or receive them but not both. I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix. But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets. Without affecting how mobile supply ships currently function.
It is not ideal, but you can resupply Forward Operating stations from supply ships. Have the supply ship rendezvous with the station, do no merge the fleets. Then give the fleet with the Station the movement order to "Resupply from stationary Supply Ship". It might take a few tries, but it does work. Both Station and Ship are set to "Resupply Own Fleet" incase that makes any difference.
I'll give that a try but I was sure even doing it that way it didn't resupply. I tried a couple of different ways to reduce the micromanagement but trying to get the different fleets orders to line up with travel and resupply time made my head hurt. Either way I feel like we really need a way to initiate the resupply from the supply ship side without joining the fleet you want it to resupply.
What I currently do is move the resupply ship to the space station, then get the space station to resupply from the ship. So it's possible to do but without a transfer supplies option for the resupply ship it can't currently be automated unless I'm missing something.
Is there anyway to fill up fuel and maintenance on a planet to a stockpile like minerals? This would also allow the automation of logistics for these to colonies.
Add a "No Armour" Type in Unit Class Design. Probably should be exclusive for infantry.Hilarious, but...
Reduces unit cost by half of the default cost, thus where for a example a PWL with light infantry armor would cost 0.06 per unit an authentic imperial guard(TM) would cost only 0.03, with of course 0 Armour regardless of Tech Level. Maybe the cost reduction should be even bigger than 50% to make it something that can be seriously considered as a strategic option.
(https://i.ibb.co/KL6tD6Y/Guardsman.jpg)
In addition to becoming standard issue for forces the image above depicts accurately, it also would be choice for genetically engineered berserkers.
Add a "No Armour" Type in Unit Class Design. Probably should be exclusive for infantry.
Reduces unit cost by half of the default cost, thus where for a example a PWL with light infantry armor would cost 0.06 per unit an authentic imperial guard(TM) would cost only 0.03, with of course 0 Armour regardless of Tech Level. Maybe the cost reduction should be even bigger than 50% to make it something that can be seriously considered as a strategic option.
While we are talking about ground combat... I would propose to remove the Logostics module from Infantry or do some mechanic where you must have them and then make vehicle supply modules more efficient than infantry supply units.
Currently there is NO reason to ever use vehicle based supply units as Infantry ones are cheaper. You just use the reserve mechanic to replace the infantry ones when they are consumed or destroyed. They are way more efficient and thus cheap to use than vehicle supply units. I always ban the use of infantry based supply units in my games unless they fit the theme such as a special forces unit meant to operate independently or something.
I think INF+LOG are quite vulnerable in frontline formations, especially when attacking, so 62 log-tons on the rear can be still better of 100 log-tons on the front.
In the spirit of the Additional conventional systems (http://aurora2.pentarch.org/index.php?topic=12523.msg155095#msg155095) change, it might be a good idea to make the Fighter pod techs a bit cheaper than 5000 RP each as well ( maybe 500 or 1000 ) to promote the use of conventional fighters and ground support?
Both from a plausibility standpoint and a gameplay standpoint ( since you have a bit of fighter production capacity as a conventional empire ) it feels strange to me that empires transition to TN tech without air-support typically.
Both from a plausibility standpoint and a gameplay standpoint ( since you have a bit of fighter production capacity as a conventional empire ) it feels strange to me that empires transition to TN tech without air-support typically.
and frankly this makes much more flavor sense since air fighters and space fighters are not going to be designed similarly in most cases anyways.
I honestly think it would be better to get rid of ground support fighters as they currently stand and have them be another ground unit type in the same style as STOs - design a weapon pod, choose it in the unit creation window, and get a ground support fighter with some minimal engine/MFC/sensor tonnage in the same manner as we currently design STOs. Build them into a formation (again, just like STOs) and assign them to support a formation with FFD following the same rules as presently. There could be a new base unit class for these (in which case we could just do away with fighter pods entirely, but I digress) or you could choose from the available vehicle classes to customize HP and armor.
This would reduce the insane micromanagement that currently plagues ground support fighters, make the fighters scale much better with AA weapons (plus, reworking AA damage calculations would allow Steve to fix the stupid issue where LAA is useless until racial weapon strength is 10 or more) ...
Regular fighters can still do orbital fire support in the same way as any other ship for those who want to keep that kind of flavor, although given the micro involved I'm not sure there's more than 2-3 people in the entire playerbase who actually care about it presently.
It would also require specific rules for situations like how to handle if one side only has fighters left and the other side have no AA or fighters left ( so they can't attack them ).
The rest are good points, but to address this one I think it is sufficient to make fighters difficult for regular ground forces to target (e.g. high hit modifier for the base class) so that the primary means of destroying fighters would be AA weapons but ground forces shooting their guns in the air can still do something (as has been done historically).
Alternatively, this may not be a huge issue - if a ground force doesn't bring necessary weapons and then loses as a result, this is a logical consequence of poor preparation. If Steve were to consider such a change this would probably be a decision to be made one way or the other.
...Especially if we envision this new type of ground unit doing all current fighter missions with lots of special rules for targeting and resolution ( Support, CAP, Search & Destroy and Flak Suppression ). It would also require specific rules for situations like how to handle if one side only has fighters left and the other side have no AA or fighters left ( so they can't attack them ).
If we add a new FTR base type with something like 0.01 hit modifier (for example), it would be sufficiently hard to hit that AA weapons would be preferable, but 500,000 militia firing randomly into the air should be able to down 5 fighters before they get brrrrt'd to death.
There would definitely be a lot of complications required to implement this, for example how should fighters interact with formation settings (front line attack/defense, support, etc.)? However if Steve wants to deal with such questions and the programming involved I think it would be a good change for the ground combat system.
why not make those combat missions be the fighters equivalent to rear echelon, support, Front line defence/Attack?
Do we even have mods? I thought we just had a bunch of well-behaved people and then sometimes Erik does techy magicks. :P
Do we even have mods? I thought we just had a bunch of well-behaved people and then sometimes Erik does techy magicks. :PDue to how forum software works, us three "bug mods" are actually "global mods". But it's not like we need to do much aside from occasionally approving a post from a non-registered poster.
Minor quality of life improvement: would it be possible to add a text field on the Mining tab, directly below the Mass Driver Destination drop down, that displays the current (or average, if that's computationally easier) "trip time" for a mineral packet sent to that destination? It would help players avoid setting destinations orbiting other stars, i.e. situations where the minerals you purchased will arrive in a few decades unless you turn off the mass driver and just pick up the minerals with a cargo courier ship.
*cough* Asking for a friend *cough*.
As a small QOL enhancement can we have the ship class abbreviation (CL, TG, FTR) displayed when you go to build ships, stations and fighters?
In the Industry tab, when selecting which Space Station or Fighters to build, it only shows the class name.
Likewise in the Shipyards tab, under the shipyard retooling and the various yard tasks only show the class name.
This would allow a weaker civ to practice piracy (flavor!) as well as potentially impose a sort of blockade of a planet, separating it from its mining colonies without having to fight the garrisons and capture said colonies.
Add a checkbox to prevent officers from teleporting to and from their destinations upon (re)assignment. We have the option to shuttle them around, after all; it'd be nice if it could be forced.
Add a checkbox to prevent officers from teleporting to and from their destinations upon (re)assignment. We have the option to shuttle them around, after all; it'd be nice if it could be forced.I like it better as it is now, since you can actually do the RP part still and assign officers to transfer shuttles if you want to. One of the first big Aurora Let's Plays had that rule, though I forgot the name.
In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?
Question & Suggestion:
In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?
If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.
Question & Suggestion:
In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?
If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.
Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.
I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.
I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.
Question & Suggestion:
In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?
If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.
Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.
I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.
I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.
I'd like infantry to be able to carry the light autocannon and statics to mount all autocannons. Unless there is a reason why they can't at the moment?
Question & Suggestion:
In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?
If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.
Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.
I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.
I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.
I'm not sure I understand. Jorgen. You're not referring to fuel consumption, because it doesn't affect engine cost, right? Is it engine power, then? I've stopped researching lower EP ratings when I noticed the civ lines abusing it... newer ships were *slower* than the earlier ones because they "upgraded" the engines.
Are you saying to mod civ commercial engines to be, say, 0.7 engine power rather than 0.5 where they start? So they're faster but also more expensive? How can I do that with SM? Can I SM edit the civ designs?
You can have infantry with a light anti tank or CAP, why is the light autocannon different? The tonnage indicates there is a whole team operating it, not just a single person.I'd like infantry to be able to carry the light autocannon and statics to mount all autocannons. Unless there is a reason why they can't at the moment?
*casually lifts 20mm Chain Gun* Yeah, what he said.
You can have infantry with a light anti tank or CAP, why is the light autocannon different? The tonnage indicates there is a whole team operating it, not just a single person.
You can have infantry with a light anti tank or CAP, why is the light autocannon different? The tonnage indicates there is a whole team operating it, not just a single person.I'd like infantry to be able to carry the light autocannon and statics to mount all autocannons. Unless there is a reason why they can't at the moment?
*casually lifts 20mm Chain Gun* Yeah, what he said.
we also have Power armour in the game so you could lock the autocannon abhind that as well
Actually not, with the way ground units are implemented in Aurora the choice of components is limited only by the base type and cannot interact with armor. Changing this is theoretically possible but would require considerably complicating the DB entries in a way that would make adding additional armor types as a DB mod basically impossible - in addition to complicating the code and likely introducing bug potential for ground unit creation.
Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.
I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.
I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.
I'm not sure I understand. Jorgen. You're not referring to fuel consumption, because it doesn't affect engine cost, right? Is it engine power, then? I've stopped researching lower EP ratings when I noticed the civ lines abusing it... newer ships were *slower* than the earlier ones because they "upgraded" the engines.
Are you saying to mod civ commercial engines to be, say, 0.7 engine power rather than 0.5 where they start? So they're faster but also more expensive? How can I do that with SM? Can I SM edit the civ designs?
I was talking about engine power yes, not fuel efficiency technology... the engine power effect fuel efficiency though.
So... what I meant was that you use SM to keep your engine power level at a minimum of 0.5, this make civilian ships more expensive but faster, so more efficient. The civilians otherwise use cheaper and slower ships.
This way you reduce the amount of civilian ships your civilians build, ut they also are more efficient as they will be faster.
I then use SM whenever I myself design an engine based on what I researched. I then SM back to 0.5 engine power technology at minimum so the civilians keep using that technology.
[math]
That way instead of current (where colonies have crazy-fast growth rate at first until leveling off), it would be a nice logistic curve: slow to start, fast in the middle, and then smoothing out at the end. Plus this accounts for if the population exceeds the population capacity; at that point the equation becomes negative.
Fair. For what its worth, the growth rate exceeds that of the current mechanic (with that r constant) at about 275 million. You can fudge the constant, of course, if you want it to be a faster or slower growth, and doing so is proportional to when that overlap happens. Take the rate x10, and it exceeds at 27 million; x100, and at 2 million.[math]
That way instead of current (where colonies have crazy-fast growth rate at first until leveling off), it would be a nice logistic curve: slow to start, fast in the middle, and then smoothing out at the end. Plus this accounts for if the population exceeds the population capacity; at that point the equation becomes negative.
It's important to note that this is actually a significant change to the game economy, as right now an important motive for colonization is that smaller populations grow more quickly and population soon becomes a critical resource for a mid-game empire. If you shift the curve to make small colonies grow slowly, the game's economics have to be completely reevaluated. It is one of those cases where making the game "more realistic" might not be good for gameplay. It can certainly work but it would involve a lot of rebalancing work to make sure it works right and doesn't break the core economic mechanics.
I was talking about engine power yes, not fuel efficiency technology... the engine power effect fuel efficiency though.
So... what I meant was that you use SM to keep your engine power level at a minimum of 0.5, this make civilian ships more expensive but faster, so more efficient. The civilians otherwise use cheaper and slower ships.
This way you reduce the amount of civilian ships your civilians build, ut they also are more efficient as they will be faster.
I then use SM whenever I myself design an engine based on what I researched. I then SM back to 0.5 engine power technology at minimum so the civilians keep using that technology.
Ya, that is 1 thing that annoys me about aurora. I understand you need to put a pop cap on a planet, but earth is capable of supporting 10s to 100s of times more population then the cap in game.
Just to give you an idea, We could fit the entire population of the USA and Canada into the state of New York and still have about 20% of the land area of that state left unpopulated if we lived at New York City levels of population density. New Jersey is the most densely populated state in the US (1,200 per sq. Mile). We could fit the entire US population in the state of Texas and still have room at that density. And we could fit the world population in the area of the US (including Hawaii & Alaska) and China leaving the rest of the world 100% devoid of human life.
The biggest use of land is agriculture. Roughly 1.43 mil sq. miles of the US is farm land and that can support roughly 570,000,000 people. But were talking about a game where we can feed 10s of millions if not 100s on a planet with no atmosphere, meaning we would have to have extensive aeroponics and hydroponics infrastructure which would increase the productivity/sq. mile by easily 10x if not more.
so was thinking about something, Population Capacity is defined as the Capacity of a population giving its current Food, Water and other Necessities usage and production, given that humans (and im going to assume other Sapient and industrial creatures) can change the carrying capacity by more efficient farming methods and other environmental things id like to propose the idea of a research that increases the Max population of a planet to represent things like conventional orbital industry, improvements in Farming tech based on the TN mats, and improved energy production also based on the discovery of the TNs,
Kind of a random thought I had earlier today when looking at medals, and some of the conditions - it felt like it would be better if some of the medals could be assigned to the ship instead. Not sure of the work required, but it would be interesting to grant decorations to the ship instead of officers crewing it, or even just the ability to add notes to a ship.
Kind of a random thought I had earlier today when looking at medals, and some of the conditions - it felt like it would be better if some of the medals could be assigned to the ship instead. Not sure of the work required, but it would be interesting to grant decorations to the ship instead of officers crewing it, or even just the ability to add notes to a ship.
On this note, it would also be nice if conditional medals were assigned to all ships in a fleet which accomplished some task, not just the "first ship" in the fleet. Example of this: "Discover N Star Systems" is awarded to only one officer even if a whole fleet jumped into the system to do a survey. This should be awarded not only to commanding officers of all ships but also any sub-commanding officers. Similarly, medals for destroying N tons should be awarded to sub-command officers - which would make the higher conditions more achievable and commander careers as told by medals more interesting.
So, i was thinking about the idea of adding GSFs as a ground element and how that might get set up and this is what i got. 3 different weight classes of fighters.
1) Light fighter: Weighs roughly 20 tons, can only mount light armour (like a light vehicle) and can only mount 1 weapon, either light Auto-Cannon or Light Bombard. Low HP pool.
2) Medium Fighter: Like medium vehicles, can mount light/medium armour. Has 1 or 2 weapon mounts (up for discussion) and can mount light/medium versions of Auto-cannons or Bombard. Weighs about 40 Tons. Medium HP Pool.
3) Heavy fighters (think more along the lines of a B-52 stratofortress): Can mount light-heavy armour, can mount any weight of weapon system. Has 2 weapon mounts. weights about 100 tons. large HP pool.
In addition, a rework of Fire directors would be needed. I was thinking, if the amount of FFD on the front line (and only front line) were equal or greater then a set ratio, lets say 6:1 (fighters:FFD) then the fighters would either get an accuracy bonus during their combat phase OR get a second "Free" attack run during their phase. This phase could take place before or after ground combat (preferably before) but after artillery bombardment phase.
So, i was thinking about the idea of adding GSFs as a ground element and how that might get set up and this is what i got. 3 different weight classes of fighters.
1) Light fighter: Weighs roughly 20 tons, can only mount light armour (like a light vehicle) and can only mount 1 weapon, either light Auto-Cannon or Light Bombard. Low HP pool.
2) Medium Fighter: Like medium vehicles, can mount light/medium armour. Has 1 or 2 weapon mounts (up for discussion) and can mount light/medium versions of Auto-cannons or Bombard. Weighs about 40 Tons. Medium HP Pool.
3) Heavy fighters (think more along the lines of a B-52 stratofortress): Can mount light-heavy armour, can mount any weight of weapon system. Has 2 weapon mounts. weights about 100 tons. large HP pool.
In addition, a rework of Fire directors would be needed. I was thinking, if the amount of FFD on the front line (and only front line) were equal or greater then a set ratio, lets say 6:1 (fighters:FFD) then the fighters would either get an accuracy bonus during their combat phase OR get a second "Free" attack run during their phase. This phase could take place before or after ground combat (preferably before) but after artillery bombardment phase.
So, i was thinking about the idea of adding GSFs as a ground element and how that might get set up and this is what i got. 3 different weight classes of fighters.
1) Light fighter: Weighs roughly 20 tons, can only mount light armour (like a light vehicle) and can only mount 1 weapon, either light Auto-Cannon or Light Bombard. Low HP pool.
2) Medium Fighter: Like medium vehicles, can mount light/medium armour. Has 1 or 2 weapon mounts (up for discussion) and can mount light/medium versions of Auto-cannons or Bombard. Weighs about 40 Tons. Medium HP Pool.
3) Heavy fighters (think more along the lines of a B-52 stratofortress): Can mount light-heavy armour, can mount any weight of weapon system. Has 2 weapon mounts. weights about 100 tons. large HP pool.
In addition, a rework of Fire directors would be needed. I was thinking, if the amount of FFD on the front line (and only front line) were equal or greater then a set ratio, lets say 6:1 (fighters:FFD) then the fighters would either get an accuracy bonus during their combat phase OR get a second "Free" attack run during their phase. This phase could take place before or after ground combat (preferably before) but after artillery bombardment phase.
--- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.
--- I'll elaborate, yeah? The window would allow you to create a "Squadron" comprising of whatever mix of ships you'd want. A textbox would let you specify how many, while a dropdown would let you specify what kind. A button would allow you to add another field for squadrons of mixed types. So if I wanted a "Squadron" of 15 ships, with 12 Bombers, 2 Sensor Spotters and 1 Command Fighter, I'd put 12 in the textbox, use the dropdown to select my Bomber class, then hit the button to add a field. Then I'd put 2 in the new textbox, followed by selecting the Sensor Spotter from the dropdown, then hit the button to add a field one more time. Now I'd put a 1 in that textbox and select the Command Fighter from the dropdown. Then I'd use another textbox to name it, and when I was done naming it I'd hit the button to save it.
--- Additionally, this window would allow me to hit a checkbox that would allow a certain "Squadron" to be automatically deployed as a fleet when built. The Industry Window would get a checkbox or button saying "Toggle Squadrons" for Fighter production somewhere, so the fighter production would list squadrons as a build option under the "Fighters" field instead of the fighter classes themselves. The Squadron window would allow for naming conventions like the Ship Design Window and would furnish a field to manage Fighter-Only Fleets, Fighter-Only Sub-Fleets and further filter to exclude fighters other than Ground Support Fighters, namely those with fighter pod bays versus those without.
--- FFDs could be told to auto-assign fighters or ships, while "Squadrons" of GSFs could have mission types whitelisted or blacklisted with checkbox fields like "No CAP" and such from the Squadron Window. GSFs that are auto-assigned to FFDs will try to distribute themselves evenly and carry out missions that are whitelisted or not blacklisted. Space fighters could have a separate set of conditional orders from the main fleet, allowing them to have priorities for missiles, fighters or just ships within a Minimum / Maximum tonnage range. These priorities would depend on sensor data available. Likewise, for scouts, a conditional order of "Flee from enemy contacts" or for a beam fighter, "Engage at Range" with a field to specify what range in km.
--- I'll flesh this out more later, my baby boy is crying for food and my keyboard is half busted with my wife having borrowed the good one for work. Needless to say, I heartily disagree with GSFs becoming a ground unit and think this solution would be far better for GSFs and regular fighters alike. :)
--- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.
If someone really wants to deal with it just leave the option of assigning them manually, but if you don't they just randomly support as needed. I also believe this would make nearly zero difference from how it works now.
--- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.
The problem is really one of scale, not only micromanagement. To be of any real use GSFs need to be fielded by the hundreds if not thousands, otherwise the impact is too little and the fighters are destroyed in only a few rounds by AA - the NPRs at least field frankly excessive amounts of AA, but even a modest allocation of ~10 AA units per formation means that easily several hundred to thousands of AA guns are present at any significant planetary battle. To effectively counter this requires much more than just several squadrons of GSFs, we really need to start thinking in terms of WWII-esque air wings of ~100 planes each.
So...we have a need for hundreds, even thousands of specialized ships which are only usable for ground combat. At that scale it is completely impractical to populate them with commanders for each ship, so we either just don't do this or we introduce a new mechanic just for GSFs to have commanders on a squadron basis instead. As far as ship design, AFAIK the speed of GSFs has no bearing on combat, so the only things that matter are the weapon and armor (and the latter is very much arguable as others have shown).
So we have a "ship" type which is only usable in ground combat, needs to be built by the hundreds, is too small and numerous or individual commanders, and has no relevant design parameters aside from the weapon and armor. At that point, this perfectly describes a ground unit class. Why not just take the logic to its conclusion, in the process using mechanics which are 90% preexisting to simplify the implementation for Steve?
Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.
--- I don't see the problem here, or rather, why the problem is one of scale rather than balance.
NOW, being able to DESIGN them as ships, but BUILD them as Ground Units, with stats reflective of their class... not too dissimilar to how STOs currently work... THAT I could (begrudgingly) get behind.
Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.
--- I don't see the problem here, or rather, why the problem is one of scale rather than balance.
Considering that ground combat happens at the scale of multi-million ton armies (100,000s to millions of soldiers, depending how you fluff your units), basically world war scales, I don't think its unreasonable to think that fighters should be able to operate on the ~1,000s scale. Beyond that I think I will let others who have used GSFs more than me address the practical reasons in more detail.
That being said...QuoteNOW, being able to DESIGN them as ships, but BUILD them as Ground Units, with stats reflective of their class... not too dissimilar to how STOs currently work... THAT I could (begrudgingly) get behind.
I think this is also fine and my original suggestion was basically this. The problem with GSFs really boils down to needing them to operate in line with ground combat mechanics, not naval combat mechanics (which they currently do) - if we can accomplish this while preserving the flavor of GSFs and allowing unique class designs to flourish that is only a good thing IMO.
This design is classed as a Ground Support Fighter for production, combat and planetary interaction
- This design is classed as a Ground Support Fighter for auto-assignment purposes
Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.
Frankly, they can't even do that now in the current system. My favorite anime growing up was Macross/Robotech. There is no way to recreate that currently. "Fighters" are 2x the size and 4x the crew of the Rocinante from The Expanse.
The most efficient fighter, and only one really worth using is a set of box launchers with an engine.
I would love to have a legit Macross or Battlestar galactica inspired campaign, but the extent i would have to "suspend belief" would just ruin the whole mood of the campaign to the point i'd probably quit it before i've played for an hr.
--- Imagine this in the Class Design Window for a moment. GSFs are already flagged as such for the purposes of combat and planetary interaction, so why not production and auto-assignment as well?I've never seen a ship classed as a GSF before, only as a Fighter. Or are you extrapolating?
(snip)
GSFs are, again, already flagged differently from regular fighters. That's how they avoid provoking STO fire on Ground Missions
--- Imagine this in the Class Design Window for a moment. GSFs are already flagged as such for the purposes of combat and planetary interaction, so why not production and auto-assignment as well?I've never seen a ship classed as a GSF before, only as a Fighter. Or are you extrapolating?
(snip)
GSFs are, again, already flagged differently from regular fighters. That's how they avoid provoking STO fire on Ground Missions
Mechanically the fact that fighters are not targeted by STOs when participating in combat is probably a flag applied to a fleet, or specific ships inside a fleet.
If you apply it to a ship class then you would have an untouchable ground unit killing machine, park it 15k from the planet and just plink away forever (or until it dies from breakdowns).
Personally I don't think ship design and ground unit design mesh very well together, so I think it would be better if things which operate in ground combat should be designed via the ground combat design screen. Trying to interpret a ship design into a ground unit is essentially 'compressing' the information into a very small number of mechanics and I just don't see how you do it both automatically and well.
Personally I don't think ship design and ground unit design mesh very well together, so I think it would be better if things which operate in ground combat should be designed via the ground combat design screen. Trying to interpret a ship design into a ground unit is essentially 'compressing' the information into a very small number of mechanics and I just don't see how you do it both automatically and well.
--- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.
The problem is really one of scale, not only micromanagement. To be of any real use GSFs need to be fielded by the hundreds if not thousands, otherwise the impact is too little and the fighters are destroyed in only a few rounds by AA - the NPRs at least field frankly excessive amounts of AA, but even a modest allocation of ~10 AA units per formation means that easily several hundred to thousands of AA guns are present at any significant planetary battle. To effectively counter this requires much more than just several squadrons of GSFs, we really need to start thinking in terms of WWII-esque air wings of ~100 planes each.
So...we have a need for hundreds, even thousands of specialized ships which are only usable for ground combat. At that scale it is completely impractical to populate them with commanders for each ship, so we either just don't do this or we introduce a new mechanic just for GSFs to have commanders on a squadron basis instead. As far as ship design, AFAIK the speed of GSFs has no bearing on combat, so the only things that matter are the weapon and armor (and the latter is very much arguable as others have shown).
So we have a "ship" type which is only usable in ground combat, needs to be built by the hundreds, is too small and numerous or individual commanders, and has no relevant design parameters aside from the weapon and armor. At that point, this perfectly describes a ground unit class. Why not just take the logic to its conclusion, in the process using mechanics which are 90% preexisting to simplify the implementation for Steve?
Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.
--- I don't see the problem here, or rather, why the problem is one of scale rather than balance. Either AA needs to be nerfed, GSFs needed to be buffed, or both.
Personally I don't think ship design and ground unit design mesh very well together, so I think it would be better if things which operate in ground combat should be designed via the ground combat design screen. Trying to interpret a ship design into a ground unit is essentially 'compressing' the information into a very small number of mechanics and I just don't see how you do it both automatically and well.
I tend to agree. While I do agree with xenoscepter that it would be best to preserve as much of the unique flavor of GSFs as possible, I have a very hard time seeing what in terms of mechanics a unique GSF class accomplishes that merits separating GSFs from ground units and ground combat mechanics. If we are going to create a unique ship class which cannot participate in naval combat or naval operations, while having distinctive HTK, armor, and other mechanical bonuses that make it behave unlike any other class of ship (and would preclude it being usable for anything other ships can do, except for ground combat, for obvious balance reasons)... at that point we have a ground unit that goes in a special hangar. Why not just call it what it is? If we need a special mechanic to allow ground formations composed entirely of GSFs to ride in hangars instead of transport bays that's fine, but there's no reason to call these "ships" if they don't walk like a ship, talk like a ship, quack like a ship...
Look at it from the opposite angle: let's say we have a GSF ground unit type which we can design in a ship-like manner, similar to STOs but a bit more involved so we can really customize our GSFs. Set it up to work with the ground combat mechanics but with special rules for fighters so they are vulnerable to AA but resistant to other ground units. For the full nine yards, add a new troop transport - hangar bay which can only transport GSF units and can deploy them from orbit. Sprinkle some automation on top and voila!
Now, looking at this, what do we gain from making this GSF ground unit a special type of "ship" - which cannot do anything another type of "ship" can except for being stuffed into hangars and siphoning off LCDRs? I can't see any reason why GSFs being a "ship" is beneficial - so why keep it that way just because that's how it already is? Sometimes a change is good.
The only benefit I can think of is that these could be built with fighter factories instead of GFTCs, which is admittedly a fair point. An exception could be made, but ultimately I would prefer that GFTCs be reworked to function like any other planetary industry instead of the silly 1 GFTC = 1 formation at a time restriction.
--- Well, for one we already have them in the ship design window. Why are we throwing that out? I can launch GSFs from outside of orbit, so they are space faring ships. When not on Ground Support Missions, they can be fired on by STOs and ships... like ships. They can attack other GSFs when on CAP, like ship to ship combat. They use a form of missile as a weapon, which uses ship mechanics. All this stuff already exists, why are we gutting it? For what? Why not use it instead of throw it away?
--- What do we lose? Well for one thing, we can't deploy our GSFs from outside of STO range, so now you have to bring the carrier in range or kill of the STOs before you deploy any GSFs. You cannot have a design for an assault ship that can tank and a design, potentially Commerical, which hangs back and deploys fighters. For another, an FFD is only 60 Tons of Ground Unit. You can quite easily stuff several of those into a fighter's Troop Transport Bays AND fit Fighter Pod Bays. They need to be a ship for all of that to work... or perhaps a better way to say it would be, it needs a bigger re-write to NOT need that to work.
--- I could say more, but frankly at this point I'm one trying to argue. I feel like no one is listening and I'm getting hot under the collar. Whether no is listening or is has become irrelevant, I need to go chill.
This the point I'm trying to get at - just because we already have something doesn't mean we should keep it. I am asking - if we did not already have GSFs as a space-faring ship type, what reason would we have to make them so. If there is no good reason (and that's an open question), then there is no reason to keep them this way either - if a better alternative exists, which I believe there does.
So...we have a need for hundreds, even thousands of specialized ships which are only usable for ground combat. At that scale it is completely impractical to populate them with commanders for each ship, so we either just don't do this or we introduce a new mechanic just for GSFs to have commanders on a squadron basis instead. As far as ship design, AFAIK the speed of GSFs has no bearing on combat, so the only things that matter are the weapon and armor (and the latter is very much arguable as others have shown).
So we have a "ship" type which is only usable in ground combat, needs to be built by the hundreds, is too small and numerous for individual commanders, and has no relevant design parameters aside from the weapon and armor. At that point, this perfectly describes a ground unit class. Why not just take the logic to its conclusion, in the process using mechanics which are 90% preexisting to simplify the implementation for Steve?
--- Well, for one we already have them in the ship design window. Why are we throwing that out? I can launch GSFs from outside of orbit, so they are space faring ships. When not on Ground Support Missions, they can be fired on by STOs and ships... like ships. They can attack other GSFs when on CAP, like ship to ship combat. They use a form of missile as a weapon, which uses ship mechanics. All this stuff already exists, why are we gutting it? For what? Why not use it instead of throw it away?
This the point I'm trying to get at - just because we already have something doesn't mean we should keep it. I am asking - if we did not already have GSFs as a space-faring ship type, what reason would we have to make them so. If there is no good reason (and that's an open question), then there is no reason to keep them this way either - if a better alternative exists, which I believe there does.
I think the general consensus is that ground support fighters are OK in terms of balance but is made unusable because of micromanagement issues, they simply take up too much time to deploy in the numbers you generally would need to have them.
I think the general consensus is that ground support fighters are OK in terms of balance but is made unusable because of micromanagement issues, they simply take up too much time to deploy in the numbers you generally would need to have them.
I'm a bit late to the discussion, but just wanted to comment that speed does affect combat. For ground-based AA-fire: "The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier." (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire)). I'm currently preparing to invade the Rahkas with 200 fighters where I have increased the speed from 9.500 to 15.000 and reduced the number of fighter pods from 2 to 1 to see if the survivability outweighs the lower fire power.
I think the general consensus is that ground support fighters are OK in terms of balance but is made unusable because of micromanagement issues, they simply take up too much time to deploy in the numbers you generally would need to have them.
That's... pointlessly averaged, let's say, statement.
Against lowest tech AA (smth like early conventional-start or lowest TN start multifaction game) GSFs are absolutely overpowered in some sense, because lowest AA just cannot pierce anything, and so GSFs are invulnerable.
Against any other opponent they are very vulnerable and quite underpowered at the same time, if you don't use huge ugly fat behemoth "fighters", armoured enough to withstand single average AA hit, at which point they became quite balanced at the cost of both more and more manic micromanagement and disbelieve because of compelled game mechanics abuse.
Yet in average of these extremes they'll be OK balanced, yes.
The tech threshold where fighters become obsolete is the point where enemy AA can reliably do shock damage to a 500t craft. At that level your point about "...armored enough to withstand single average AA hit..." is rendered moot, as shock damage effectively bypasses armor and if not destroy, will render the fighter incapacitated.
I'm a bit late to the discussion, but just wanted to comment that speed does affect combat. For ground-based AA-fire: "The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier." (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire)). I'm currently preparing to invade the Rahkas with 200 fighters where I have increased the speed from 9.500 to 15.000 and reduced the number of fighter pods from 2 to 1 to see if the survivability outweighs the lower fire power.
I recall earlier tests showed the AA tracking and fighter speed interaction isn't properly implemented, right now AA has very high accuracy against fighters AFAIK.
I'm a bit late to the discussion, but just wanted to comment that speed does affect combat. For ground-based AA-fire: "The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier." (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire)). I'm currently preparing to invade the Rahkas with 200 fighters where I have increased the speed from 9.500 to 15.000 and reduced the number of fighter pods from 2 to 1 to see if the survivability outweighs the lower fire power.
I recall earlier tests showed the AA tracking and fighter speed interaction isn't properly implemented, right now AA has very high accuracy against fighters AFAIK.
If that is the case, then I see why excessive AA severely limits the effectiveness of GSF's, but it also means that we don't really have a way of evaluating them properly if they aren't implemented completely yet. At the very least it shows that speed should be a design parameter if a rework is to be done. That would also speak to the above points about armor. If you can't increase survivability by increasing speed, but only through armor, then shock damage at higher tech levels become debilitating.
he problem I have with speed and GSFs is what happens with planets that have atmospheres. You can very easily get GSFs with comparable speed to missiles way beyond the racial tracking which I assume AA will use. How would you model the effect of atmospheric pressure on the top speed / effective evasive ability of GSFs? Would you even gain anything mechanically from modelling that? There isn't really a way to design the aerodynamic profile of fighters, all we know is that they can land/takeoff from planets that may or may not have atmospheres.
And this is completely ignoring the whole issue of air-to-air combat, which has not been a part of the GSF discussions for the obvious reason of NPRs don't use fighters.
he problem I have with speed and GSFs is what happens with planets that have atmospheres. You can very easily get GSFs with comparable speed to missiles way beyond the racial tracking which I assume AA will use. How would you model the effect of atmospheric pressure on the top speed / effective evasive ability of GSFs? Would you even gain anything mechanically from modelling that? There isn't really a way to design the aerodynamic profile of fighters, all we know is that they can land/takeoff from planets that may or may not have atmospheres.
And this is completely ignoring the whole issue of air-to-air combat, which has not been a part of the GSF discussions for the obvious reason of NPRs don't use fighters.
--- GSFs are Trans-Newtonian, they don't fully exist in our reality, so it makes some sense that the laws of aerodynamics as we know them might not fully apply to them or indeed even apply at all.
And this is completely ignoring the whole issue of air-to-air combat, which has not been a part of the GSF discussions for the obvious reason of NPRs don't use fighters.That's a thing I've been thinking about while reading this discussion. If there were air units that were built as ground units, those should be much easier to implement for NPRs than GSF.
Grouping civilian contacts like we can group other contacts. So if you have a bunch of civilian ships sitting on earth it would look like Civilian Freight (x32) instead of listing them all.
Grouping civilian contacts like we can group other contacts. So if you have a bunch of civilian ships sitting on earth it would look like Civilian Freight (x32) instead of listing them all.
would be great to see. One issue is civilian ships almost never form a fleet, so you wind up with 100s of single ship fleets. Having them group up would be nice too.
Also make these support weapons have more impact on morale and not just damage to make them more worth while than they currently are. They probably also should increase the chance of breakthrough happening.
But then again I want ground units to have more combined arms effect in general so combat become a bit more dynamic and interesting. It currently is a bit one dimensional.
Ow, I have forgoten to write down the second half of my suggestion: disadvantageous elements become temporarily non-combat. So, vehicles will hide behind infantry during close combat (if there is any infantry for them to hide behind), while infantry will hide behind vehicles during ranged combat (again, if there is any vehicles for them to hide behind).
Is it possible to add automatic naming for space stations, habitats, mining bases and so on? Right now every station, which is constructed by construction factory is named class name + number. This is quite unfitting for a mighty terraforming base for instance.You should be able to do this by assigning that class a name theme in the Class Design window, under the Miscellaneous tab.
Is it possible to add automatic naming for space stations, habitats, mining bases and so on? Right now every station, which is constructed by construction factory is named class name + number. This is quite unfitting for a mighty terraforming base for instance.You should be able to do this by assigning that class a name theme in the Class Design window, under the Miscellaneous tab.
Then it isn't a suggestion, it needs to be reported as a bug.Is it possible to add automatic naming for space stations, habitats, mining bases and so on? Right now every station, which is constructed by construction factory is named class name + number. This is quite unfitting for a mighty terraforming base for instance.You should be able to do this by assigning that class a name theme in the Class Design window, under the Miscellaneous tab.
Right now this only works for ships built out of shipyards. If you build fighters or stations with planetary industry, they are not named according to the selected naming scheme.
Factory Ratio:
How about a change in Factory Production? As we have it now, there is a "fixed" number of factories doing "general production", other doing "fighter production" and the rest is doing "ammunition production". All have fixed numbers of workers who don't do anything when you don't need new fighters or produce ammunition. So how about reducing the types of factories to one and having a three-split ratio as to how the factories are configured? In times of peace, you lower the % of fighter and ammunition production and in times of war, you need to increase it. This refit should of course cost some minerals, but this way one could manage industry more efficiently.
Factory Ratio:
How about a change in Factory Production? As we have it now, there is a "fixed" number of factories doing "general production", other doing "fighter production" and the rest is doing "ammunition production". All have fixed numbers of workers who don't do anything when you don't need new fighters or produce ammunition. So how about reducing the types of factories to one and having a three-split ratio as to how the factories are configured? In times of peace, you lower the % of fighter and ammunition production and in times of war, you need to increase it. This refit should of course cost some minerals, but this way one could manage industry more efficiently.
Oh and... I'd like conventional industry to be buildable too - though, perhaps this can be circumvented by Data Base editing?
1.) Adding conversion industry tasks similar to with conventional industry between the 3 ( for maybe somewhere around 5-20 cost per factory vs 120 for a new ).
1.) Adding conversion industry tasks similar to with conventional industry between the 3 ( for maybe somewhere around 5-20 cost per factory vs 120 for a new ).
Well this one was surprisingly easy to add through DB edit and appears to work fine when advancing time too...
(https://i.imgur.com/Eatu6k4.png)
( DIM_PlanetaryInstallation and add a row for each conversion )
Facepalms and sighs...
yes, very easy to do, but you have to give them a cost because they have no material requirements. I did 40/40/40 Deranium/neutronium/Corundium to be "fair".
Facepalms and sighs...No... Because if there was no resource cost attached to it you would be able to pay just 20 resources to convert them to full TN Construction Factories worth 120 resources.
Dude, it's CONVENTIONAL INDUSTRY, meaning - made when TNs were not known!
Why should You add a mineral cost to that!?
Although, let me guess - bugs, right? Or the A.I. going nuts with it and building them in infinite numbers?
Ah!
No... Because if there was no resource cost attached to it you would be able to pay just 20 resources to convert them to full TN Construction Factories worth 120 resources.
Ah!
No... Because if there was no resource cost attached to it you would be able to pay just 20 resources to convert them to full TN Construction Factories worth 120 resources.
So in order to make it fair, you could make it, that conversion basically costs the same as a full construction factory.
My goal wasn't really fairness though, my goal was to find a way to make some asteroids and planetoids useful for more than just slow accumulation of population and (low gravity) infrastructure...
As for NPRs building them... they won't?
Suggestion: Allow industry to help with fortification. In VB6 (and maybe still in C#?) construction brigades can be used as factories. Why not the inverse as well?
This would make sense from a removing-special-rules perspective, and from a historical perspective as well; many fortifications were built with civilian or forced labor. The Atlantic Wall, for example, in WW2 was built by slave labor.
Rather than have training occur when you put a fleet under a Training Admin Command, make training a Movement Order similar to how overhaul works. That way you could set a duration for the training, with other orders like refuel/resupply/wait to burn down deployment/actually overhaul since you've used up maintenance life, then set it on Cycle Orders and voila! you've solved the training micromanagement problem.
You could still of course put the fleet in a Training Command, which would be led by someone with high Crew Training, to get that bonus.
I'm almost sure it's been suggested before, but anyway:
In the combat menu, allow dragging a missile onto a fire control and thereby assign it to all launchers under that control.
(Or is there a faster way already and I haven't gotten the memo?)
What about auto-ceasefire for ships landing on a carrier? I just launched a squadron that fired immediately after leaving the hangar bay, because you don't get an auto-5-second-interrupt if the ship has Open Fire orders but no more ammo, and I forgot to order cease fire.
I'm almost sure it's been suggested before, but anyway:
In the combat menu, allow dragging a missile onto a fire control and thereby assign it to all launchers under that control.
(Or is there a faster way already and I haven't gotten the memo?)
Doesn't this already work in exactly this way? I'm fairly certain I just did this last night...
I think it depends on the "assign all" checkbox, or is that only for target assignment?
It would be great to have a "Send demand to surrender" command to have one fleet send to another, with the likelihood of the enemy surrendering being based on relative strength of the two fleets, any other fleets in the area which could intervene in a reasonable timeframe, damage of the ship being asked to surrender, and xenophobia + militancy.
I think it depends on the "assign all" checkbox, or is that only for target assignment?
I think the latter, it definitely doesn't work for PD mode assignment, which gets annoying when I want to turn my AMM cruisers on/off to manage ammo...
We really need a checkbox for "Assign All of Type" - which works with PD assignment and missile loading while we're at it.
I think it depends on the "assign all" checkbox, or is that only for target assignment?
I think the latter, it definitely doesn't work for PD mode assignment, which gets annoying when I want to turn my AMM cruisers on/off to manage ammo...
We really need a checkbox for "Assign All of Type" - which works with PD assignment and missile loading while we're at it.
This reminds me of one thing I'd love to see which I keep forgetting to drop here - add fire control and missile assignment as a template to the ship design screen, similar to the ordnance template. In 99% of situations I will want all builds of a given class to have the same FC assignments and I invariably forget to do the assign all step at some point, especially with fighters, so just stating at the ship design level how I want FCs to be assigned would be an amazing QoL addition.
Yeah even a simple "default" template would work, though for missile ships the ideal might be to have the ability to make multiple templates that you can swap to depending on what missiles you want to be firing.A default is all I was thinking of as a first cut, to keep things simple. Setting FC assignments does feel like something I'd expect to do as part of the design process.
Another suggestion: On the fleet Movement Orders tab, make the orders able to be moved up or down the queue of orders, similar to research/industry.This has been suggested before but Steve always shoots it down because it is really easy to introduce logic errors that will break the orders and/or the game.
I suspect this isn't as easy as it seems, since the orders available depend on what orders precede it, but within a system it would be really helpful. An example use case is you're following a fleet at a fixed range while hammering it with weapons. As their ships blow up, you want to collect the life pods, so right now each time you have to clear the current "follow" order, order pickup of the lifepod, then reorder the follow at a fixed distance.
Suggestion: The Addition of 'Air Forces'
A couple ground forces related suggestions that have been on my mind:Ground Force Admin Commands - just like we have now for Naval Admin Commands, will give things to do for higher level ranks and also allow flexible organizing of units into larger groups(like Armies or Corps) for RP and tracking purposes, without having to build incredibly costly and enormous HQs.
Named GF Construction Factories - just like we have now for shipyards, primarily for RP purposes.
Back to everyone's favorite punching bag... ground combat.
I thought perhaps Heavy Bombard units could ignore (or partly ignore) fortification, with the intent that it would make them particularly useful when assaulting homeworlds which tend to be fully fortified. The game rationale is now you have a reason to bring Heavy Bombard units, the "real-life" rationale is that heavy artillery is one of the main ways you deal with enemy's fortifications.
As a corollary, we could then have fighters ignore (or partly ignore) evasion, making them more effective against vehicles on the attack. This would give defenders some buff to counteract the benefit to attackers of artillery, and again provide a reason to bring them to a fight, and would DEFINITELY jive with real life. Doesn't matter much how fast a ground unit is going, because relative to an aircraft with missiles (or even guns), you're still pretty dang slow.
QoL request... could we get a filter for the Commanders window to only show commanders who are unassigned?I want this so much.
Suggestion: Additional of 'Ministers'
One problem I have in games is that I always wind up with a massive surplus of governors/civilian administrators. I think it would be interesting if we could add in a second layer of administration to each colony and sector governor with the following positions:
Finance Minister: Utilizes Wealth Creation or Logistics
Defense Minister: Shipbuilding or Ground Unit Construction Speed
Industry Minister: Production or Mining
Science Minister: Terraforming and/or Population Control
A governor still remain the most important administrator to have on a colony because he contributes his full value but these other ministers contribute a fraction (25-50% sounds about right) of their bonus to the colony/sector and can be powerful multipliers. They also have the ability to grow their skills - but JUST the skill for the ministry they hold - so that when existing governors die/retire you have qualified and experiences ministers ready to take over.
At the time, when fighters are on ground, the might not even be using MSP and won't be using maintenance facilities, because of that.
At the time, when fighters are on ground, the might not even be using MSP and won't be using maintenance facilities, because of that.
Are you sure about that? When I tested recently fighters seemed to worked just fine using normal maintenance facilities…
You can actually do this to a degree already. When viewing a single ship in the Naval Organization window, you have the option to set a ship-specific loadout on the ordnance tab, which IIRC can be copied to other ships of that class in a fleet as well. It is not quite having multiple profiles that can be swapped around but it is something useful.Really? Never noticed that, i guess i have to check it out.
Additional Internal HTK to Ships/Stations Component ie Bulkheads/Structural Reinforcement
A component to help make more durable ships without having to add armor/shields, the trade-off being since their internal components they don`t block damage to vital components merely give the enemy nonvitals to shoot.
Introduce the option to remove Orbits also to Stars, not only Planes, Moons, and Asteroids.And before anyone misunderstands, Froggiest means orbits of stellar companions as the main star of course never has an orbit.
Reasons here: http://aurora2.pentarch.org/index.php?topic=12886.msg158058#msg158058
I think it would be useful to have class prefix of the ships clases on the Shipyards panel when Retoling Shipyard and all the shipyard tasks (Construction, Refit, Repair, Scrap, Autorefit)
Currently these only show the class name without the prefix, while assigned class does show the prefix.
Hull abbreviation for classes and ships shown in construction options on Shipyard and Industry tabs of Economics window.
At the time, when fighters are on ground, the might not even be using MSP and won't be using maintenance facilities, because of that.
Are you sure about that? When I tested recently fighters seemed to worked just fine using normal maintenance facilities…
Currently fighters work like normal ships when not in a hangar, so they require maint facilities and consume MSP like every other military ship. I think the suggestion would imply that fighters in a hangar would not use MSP at all, which would be more like VB6 but I think a rather poor idea for C# given the design goal of unifying the mechanics instead of adding exceptions.
I don't particularly like the idea of planetside hangars, as it doesn't add anything mechanically (removing MSP consumption would take away something mechanically, if anything) and doesn't really solve the problem as any defensive fighters will just be blown up by an attacking fleet when they do leave the hangars, wither GSFs or space fighters. I would rather see a more elegant solution to the GSF problem such as making GSFs into a ground unit class and unifying those mechanics.
If/when there is a diplomacy update, I would love to see the ability to negotiate conditions for sharing a system. E.g.:
"Let's agree to share this system because we're on good terms, but we won't let anyone else settle here" i.e. claims that do not exclude Friendly aliens
"Let's agree to share access to this system's resources, but no military ships or units allowed" or
"This system will be a buffer between us; no military or civilian use at all by either side" or
"This system can be used as a route to and from other places, but no one is allowed to have a presence in the system for more than 5% of the year"
If/when there is a diplomacy update, I would love to see the ability to negotiate conditions for sharing a system. E.g.:
"Let's agree to share this system because we're on good terms, but we won't let anyone else settle here" i.e. claims that do not exclude Friendly aliens
"Let's agree to share access to this system's resources, but no military ships or units allowed" or
"This system will be a buffer between us; no military or civilian use at all by either side" or
"This system can be used as a route to and from other places, but no one is allowed to have a presence in the system for more than 5% of the year"
"Look, mate: your home system is through this jump point, our home system is through that jump point, neither of us wants next door neighbors, so let's just be cool, yeah?"
The NPRs really, really, really need some concept of a buffer system if the diplomacy mechanics are going to be functional for any kind of realistic RP setting.
How would the buffer work though, would you be allowed to sensor buoy the JPs without too much fuss?
Dynamic Range for Missiles:
I was wondering if it would be possible to add a factor for the flight range calculations of missiles. Something like the factor for research. The idea behind this is to create games which have a more shorter range for missiles like in the Battlestar or Star Wars Universe.
Can you elaborate? I do not see the point. If you want shorter ranged missiles, make shorter ranged missiles.
Not sure if this is a bug or just a suggestion, but when you have a research bonus due to an Ancient Construct, it is reflected on your current research projects, but not on projects in your research queue, even though once those projects transition to being active projects, they do indeed correctly get the bonus applied. It would be helpful if the completion time in years was accurately calculated using the bonus for items in the research queue.
Been playing a bit of Quasar while waiting for 2.0 and it is excellent piece of work. One quality of life feature the developer put in there is a button that restricts whether a particular colony can refuel or not. I think this would be a great idea for C#. I make a lot of use of conditional orders and I hate when an exploration ship with a large fuel tank conditionally returns to the nearest spaceport/hub which has a tiny bit of fuel there for a fighter squadron and drains all the fuel from it when what I really wanted for them to do was to return to my larger central hub with loads of fuel. I would propose a toggle switch on each colony that toggles whether they can be a fuel source or not.
Small QoL request:Change your Long Form Date setting in Windows. Aurora pulls the date setting from Windows so that's the culprit. These are the ones:
Truncate the days and months displayed in all of the subwindows (primarily Fleet, Ship, Research, and Industry screens). Reduce days to 2-3 letters and months to 3 letters, such as:
Thursday, December 20, 2085 ---> (Th/Thu), Dec 20, 2085
I can almost never see the day and year when something is supposed to finish as the column for dates is never wide enough. I'm at 1920x1080 so it shouldn't be a display resolution issue either...
Currently if a ship is boarded it's very easy to deny it to the enemy by abandoning ship once you're sure it's lost. This makes boarding as a mechanic much less fun: you don't get to fight against your own captured ships, and if you also control the faction doing the boarding, you don't get to play with the enemy's ships. Because of this I usually play with the house rule that you can only make one attempt to abandon ship, which has a probability of success weighted by the relative strengths of the attackers and defenders. It would be nice if a mechanic like this were added for the game; for instance, if each boarding combat round there's a chance for a "capture the bridge" event that disables the abandon ship button for that ship until boarders are defeated. This would make for a more interesting choice between abandoning ship early to deny it to the enemy or waiting to see how combat plays out and risking the ship being captured.What if abandoning ship didn't make it self-destruct, but rather just spawned lifepods equal to the remaining crew and set the ship's crew to 0? I mean the button IS abandon ship, not scuttle ship.
Or just don't click the abandon ship button?
(https://abload.de/img/screenshot2022-01-241tcj2h.jpg)Or just don't click the abandon ship button?
I must press the big red button that says DO NOT PRESS
A suggestion to have STOs contribute to planetary protection rating instead of police force.
What if abandoning ship didn't make it self-destruct, but rather just spawned lifepods equal to the remaining crew and set the ship's crew to 0? I mean the button IS abandon ship, not scuttle ship.
Quote from: drakonbane link=topic=10640. msg158258#msg158258 date=1643024105A suggestion to have STOs contribute to planetary protection rating instead of police force.
PPV is calculated system-wide, not per-planet, so this wouldn't work unless the underlying calculation was rewritten.
It is weird that it is called PPV though if actual planetary protection does not contribute, and only ship-type movable assets are considered. An orbital beam base contributes to all planets, but the just-as-movable, freighter dependent STO does not? Shady.A suggestion to have STOs contribute to planetary protection rating instead of police force.
PPV is calculated system-wide, not per-planet, so this wouldn't work unless the underlying calculation was rewritten.
It is weird that it is called PPV though if actual planetary protection does not contribute, and only ship-type movable assets are considered. An orbital beam base contributes to all planets, but the just-as-movable, freighter dependent STO does not? Shady.A suggestion to have STOs contribute to planetary protection rating instead of police force.
PPV is calculated system-wide, not per-planet, so this wouldn't work unless the underlying calculation was rewritten.
I know its been suggested before but some way to retool or upgrade ground units & templates to use new racial weapon and armor techs as they unlock would be awesomeButton to update your existing unit templates to use the latest racial weapon and armour tech while also renaming them with a running number scheme that can be edited by player like prefix and suffix for ships, which the player can then research at their convenience.
I know its been suggested before but some way to retool or upgrade ground units & templates to use new racial weapon and armor techs as they unlock would be awesome[...]
Formations don't need to be automated because we have unit series already.
To go along with the 1. 13 Ordinal numbering (which I love):While this is a good suggestion in general, the fact is that armies have a bewildering array of naming conventions. These include Roman and Arabic numerals and letters, using a comma or a period or nothing, using commander names instead of numbers, and so on. For example:
To be in line with way armies speak either put the number first, or after a comma. eg IV Infantry Division or Infantry Division, IV
Also, I'd like to see a slightly larger change; instead of per template add a template design "class" similar to ship design. Ground unit class can be anything user defined, but anything that shares the same class gets numbered together. Such that if I had three templates "Expeditionary Corps", "Armored Corps", and "Example" all under one class it would create "I Expeditionary Corps", "II Armored Corps", and "III Example", or "1st Expeditionary Corps", "2nd Armored Corps", and "3rd Example".
Similarly if you wanted two formations to have independent numbering sequences you could put them under separate class. Formations "EX1" and "EX2" with classes of "(COM) Company" and "(COM) Marine Company", would create "1st EX1" and "1st EX2" on creation.
Class could also be set to set the default abbreviation and rank for a new template.
I think I've suggested this before, but whatever : make missile warheads increase in efficiency with size, like shields do now. Use this formula instead of the current one:
Warhead Strength = (Warhead Size in MSP) * (Warhead Strength per MSP) * SQRT(Warhead Size in MSP)
I've tested this before (by editing the DB after finalising missile designs), and it seems to work pretty well at making larger missiles more effective and at addressing the AMM spam problem at high tech. An AMM with a levitated-pit implosion warhead would need ~0.4 MSP for the warhead instead of 0.25 MSP, while one with an antimatter warhead would need ~0.14 MSP instead of 0.05 MSP. This penalises warheads that are too small and provides strong advantages to going larger, which should hopefully offset some of the issues with large missiles doing poor damage against strong point-defence.
I think I wouldn't want to make AMM warheads too much larger as this would significantly reduce AMM performance particularly at low tech levels while having minimal impact at higher tech levels. 0.4 MSP versus 0.25 MSP is quite extreme as it would reduce speed and thus, approximately, AMM hit rate by nearly 25%. If we scale it to the MSP required for a 1-damage warhead (which is just 1/tech level), then we can use an expression like (Size*Strength per MSP)^(3/2) which is perhaps not so intuitive for players but makes higher-damage missiles more feasible while preserving AMM capabilities.
A better way to pull back high-tech AMMs would be to reduce the missile agility gain per tech level. Currently it is something quite ridiculous: 20 per MSP, then 32, then 48, then 64... basically the early levels increase very quickly and then agility is inflated for all the tech levels. In my modded DB I have adjusted the early levels to 20, 25, 32, 40, ... in the same pattern as most numerical-valued techs in the game, and agility caps out at 250 per MSP which is not quite enough to create 100% hitrate AMMs at MaxTech without sacrificing ECCM (I think you can reach about 80-85% from a quick calculation; of course you can reach 100% without ECCM, but then ECM makes your AMMs useless). The impact is not too great at lower techs because most of the AMM hit rate comes from the engine techs until you reach the middle tiers anyways, so on balance coupled with the above change to damage it should work fairly well.
Kinetic Missile Warhead:
--- A warhead which requires no MSP, but provides a Strength equal to Missile Size, down to a minimum Strength of 1.
Kinetic Missile Warhead:
--- A warhead which requires no MSP, but provides a Strength equal to Missile Size, down to a minimum Strength of 1.
so a size 2 missile would do 2 damage and a size 6 would do 6?
I mean it's a cool idea, but then it's essentially long range, slow firing beam weapons with limited ammo. Would you keep the missile damage pattern or change it to something like laser damage pattern?
Super minor thing but does anyone else think some of the medal award criterias are a bit optimistic? Specifically the "Discover 100 new systems" and "Discover 1000 system bodies with minerals" conditions. Careers just don't last long enough to achieve those unless you start with a very high tech level and/or make your survey captains story characters and never reassign them.
Kinetic Missile Warhead:
--- A warhead which requires no MSP, but provides a Strength equal to Missile Size, down to a minimum Strength of 1.
On the other hand you'd need something to pad out missile size for this to make sense and be anywhere close to cost-viable. Some sort of field for empty hull in MSP. Otherwise you are forced to put fuel that's not going to get burned at combat ranges.
Suggestion: Industrial command and control modules. Like a mining control center that allows a junior officer to apply their mining bonus, with a similar module for terraforming modules.
Suggestion: Industrial command and control modules. Like a mining control center that allows a junior officer to apply their mining bonus, with a similar module for terraforming modules.
Would love this. The more officer slots we can add the better. I already put a Science module in terraforming platforms for RP purposes.
The difference in cost between adding a new slipway to a fresh shipyard ( doubling capacity ) and building a new shipyard from scratch feels like it doesn't make much sense.Dont forget that a shipyard isnt just the slipways. It includes the storage, logistics, manufacturing/assembly facilities and the trained workers. Expanding an existing shipyard requires less work as fewer new facilities need to be built, and the workforce can be distributed to reduce the training required to staff the facilities
I understand it's a limitation with tooling of all slipways being to the same ship, but it feels like this limitation shouldn't reduce the cost to less than 10% compared to building a fresh new shipyard.
Dont forget that a shipyard isnt just the slipways. It includes the storage, logistics, manufacturing/assembly facilities and the trained workers. Expanding an existing shipyard requires less work as fewer new facilities need to be built, and the workforce can be distributed to reduce the training required to staff the facilities
The balance is not in the relative costs, it is in the fact that a shipyard is built with planetary construction factories, but expanded only by its own innate construction capability which is much slower even if much cheaper.That depends on the situation, you play in a conventional start where you have only 500 BP/year available, then a shipyard is not faster at all, it takes almost 5 years to complete, while adding a slipway can be done in exactly 1 year.
...otherwise if the costs were equal...Did you read the post your responding to?
The balance is not in the relative costs, it is in the fact that a shipyard is built with planetary construction factories, but expanded only by its own innate construction capability which is much slower even if much cheaper.That depends on the situation, you play in a conventional start where you have only 500 BP/year available, then a shipyard is not faster at all, it takes almost 5 years to complete, while adding a slipway can be done in exactly 1 year.
...otherwise if the costs were equal...Did you read the post your responding to?
A conventional start is balanced around converting your starting CI into TN industry before you spend a lot of resources expanding your shipyards, using your initial yards to start your expansion (which is enough to launch a survey ship from the naval yard plus colony/cargo ships from the commercial yard).
but is and should be more expensive so that it is not greatly preferable to adding new slipways to existing yards.
but is and should be more expensive so that it is not greatly preferable to adding new slipways to existing yards.
That they should be more expensive is not something I ever disagreed with. What I disagree with is if they need to be 10 times or more expensive to be balanced?
Would love this. The more officer slots we can add the better. I already put a Science module in terraforming platforms for RP purposes.
A minor suggestion and an expansion of the Misc component Idea
Miscellaneous Ship Officer Stations
You design the components on the Create Research Projects window by:
- Choosing a size (from 1 HS to 10)
- giving the component a name
- Choosing an Officer Type ( Naval, Ground, Admin, Scientist)
- Choosing an Officer Skill That will be the Primary selection Criteria
- For Naval/Ground/Admin only: Rank Required
(Racial Min +0/1/2/3/4)
Cost is equal to size in HS and the mineral requirements are split between 20% Duranium and 80% Corbomite. The HTK is equal to the square root of the size. additional the officer improves the skill required by the ship station up to 1% or 1 per year per HTK of the component. [ballparking some figures]
two example Officer StationsCode: [Select]Internal Security Control
Cost 100 Size 100 tons Crew 15 HTK 1
Officer: Ground Force Officer
Rank: Major
Skill: Ground Combat Defence
Base Chance to hit 100%
Materials Required: Duranium 20 Corbomite 80Code: [Select]Civil Logistic Liaison
Cost 200 Size 200 tons Crew 30 HTK 2
Officer: Civilian Administrator
Rank: Admin Rating 1
Skill: Logistics
Base Chance to hit 100%
Materials Required: Duranium 40 Corbomite 160
thoughts?
Edited: Change Rank Idea with RougeNPS input.
Can we have a hybrid "Know Star Systems" setting? This way we can have earth, proximal centari, etc, but also get pulsars, nebula etc after a set distance in either LY or after a set number of jumps.
Can we have a hybrid "Know Star Systems" setting? This way we can have earth, proximal centari, etc, but also get pulsars, nebula etc after a set distance in either LY or after a set number of jumps.
Sorry to disappoint you, but thus far we don't even have pulsars, nebulae, black holes, etc. in C#, so this would need to come before such a change could be considered.
Can we have a hybrid "Know Star Systems" setting? This way we can have earth, proximal centari, etc, but also get pulsars, nebula etc after a set distance in either LY or after a set number of jumps.
Sorry to disappoint you, but thus far we don't even have pulsars, nebulae, black holes, etc. in C#, so this would need to come before such a change could be considered.
I do have some ideas around new 'star' types, but I plan to release v2.0 before making any more significant changes.
A Quality of life improvement. Templates for setting Mineral reserve amounts for colonies. Or at least a set reserve for all minerals button. Unless I'm missing this already.
CSTC would be a 100-ton component that allows ship to 'clamp' into another ship. As it is using physical connection for tugging instead of TN-based tractor beam, it can only maintain connection if the masses in question are 1000-tons or less and speed is 100 km/sec or less.
A Quality of life improvement. Templates for setting Mineral reserve amounts for colonies. Or at least a set reserve for all minerals button. Unless I'm missing this already.I think you can set a planetary reserve level for each mineral by double-clicking on the number in the reserve column in economics - mining tab. Is that what you are searching for?
Could we have 2 "Move to" items in the movement order list?
1) Move to 0 - always moves to 0 km distance to the target selected
2) Move to distance - this uses the distance in the minimum distance box
thanks
- In the system display tab add a button to allow the highlighted body to have a waypoint added to it. Very helpful when picking through which planets you want to fire a sensor probe towards without then having to go to the map and create the waypoint from thereI like this, but what if there was an option to target bodies directly?
With 1.13 you added miscellaneous components, While i have not use them much, they are great for RP. So can we expand this?
1) Miscellaneous Buildings: Designed like a component, you can chose the size (for transport) the amount of population they use, and how many can be built per planet. This way we can RP things like Planetary Administrations, etc.
2) Miscellaneous Techs: Same premise, you 'design' them like a component, giving it a name, category & RP value and they you can research them.
I know both can be done through a DB edit, however having them available, even if only in SM mode, without having to worry about DB edits would be great.
Oh, and Steve, back before the release of C#, we talked about being able to export/import ground forces, designs and OOBs, for the purpose of creating historically accurate national armies and sharing them with other players. Is that functionality something you could add to 2.0 or is it too complicated? If complete OOBs are not possible, would just unit designs and formation designs be possible to import/export? Would be grand if possible!
Oh, and Steve, back before the release of C#, we talked about being able to export/import ground forces, designs and OOBs, for the purpose of creating historically accurate national armies and sharing them with other players. Is that functionality something you could add to 2.0 or is it too complicated? If complete OOBs are not possible, would just unit designs and formation designs be possible to import/export? Would be grand if possible!
This is something I have been pondering the last few days. I think it is possible, but it would done at the component level and use whatever tech was available, rather than having exact copies.
Oh, and Steve, back before the release of C#, we talked about being able to export/import ground forces, designs and OOBs, for the purpose of creating historically accurate national armies and sharing them with other players. Is that functionality something you could add to 2.0 or is it too complicated? If complete OOBs are not possible, would just unit designs and formation designs be possible to import/export? Would be grand if possible!
This is something I have been pondering the last few days. I think it is possible, but it would done at the component level and use whatever tech was available, rather than having exact copies.
Having new-built units automatically be constructed with the current armor and weapons tech would be a great QOL feature. You could increase the initial research costs for each unit to compensate.
On the mechanics side, I'm very much in favor of converting ground unit training into a system that works more like industrial production, but with minimum training times for specific units (similar to how the build queue works in Hearts of Iron). As it is now, using multiple GFTFs to train a large formation involves breaking down the formation template into individual sub-formations and fiddling with the construction costs until they are about equal, then training them separately and combining at the end. This is tedious and error-prone, and makes IMO only limited sense.
Personally, I don't so much mind having to spend a year standing up an infantry brigade. That seems a little long, but not outside the realm of reasonableness (in our own reality, infantry that is mobilized in less than that time tends to be pretty use-impaired anyway - this is why you can tell a lot about an army's state of readiness from the length of its tours of duty).On the mechanics side, I'm very much in favor of converting ground unit training into a system that works more like industrial production, but with minimum training times for specific units (similar to how the build queue works in Hearts of Iron). As it is now, using multiple GFTFs to train a large formation involves breaking down the formation template into individual sub-formations and fiddling with the construction costs until they are about equal, then training them separately and combining at the end. This is tedious and error-prone, and makes IMO only limited sense.
This has been a frequent request, and Steve has acknowledged the need but not yet developed a solution as far as we know.
I think a large part of the issue is that when Steve developed the ground forces system, he probably had in mind that battalions would be the base formation size (~2,500 to 5,000 tons) as in VB6 (you can see this in the rank themes as well). With this assumption, the ground forces training works without too much trouble as a 5,000-ton infantry battalion can be built in about 5 months at the base training speed tech level, and a similarly-sized armored battalion in 3-4 times that. Once you start developing the training techs these times go down and more expensive units (heavily armored or with added capabilities) can be trained in roughly a year to provide a natural progression of sorts.
The problem has been that the ratio of ground force leaders to number of formations with such small formations is not favorable, and so the equilibrium tends to settle closer to 15,000 to 25,000 tons regiments/brigades as the base size which take multiple years to train. Steve has noticed this, as NPRs tend to use ~15,000 tons as their base formation size, but a change for ground unit construction has not yet come. There is some hope that the doubling of naval and ground commander birth rates in 2.0 can help with this, maybe reducing the needed formation sizes to ~10,000 tons which is more manageable once you research a few levels of the training tech, but it's not going to be a real solution.
But the two years I have to wait for that twelve-gun STO battery I ordered seems a little out of whack with the pace at which my shipyards can crank out the same guns when I wrap them in an engineless papier-mache hull and slap a bridge on them.
Small RP suggestion, in two parts:
- For single-star systems, it would be nice if the star and body names would not include the "-A" in their designations. It's a small thing, but "Epsilon Eridani II" looks neater than "Epsilon Eridani-A II".
- The ability to name stars in a multiple-star system independently. The current behavior is a fine default, but sometimes it makes sense to name each star separately especially for races which start in a binary+ system.
A spaceport is needed to build 'space stations' (the type with no armour).Even better, make it so that once spaceport hits level 5, it becomes space elevator.
To make this more flavourful, can the spaceport be renamed the space elevator?
Thinking about "moveable jump point stabilisers", mostly for RP purposes. The idea is to construct stations that can transfer ships at jump points. Basically manual jump point stabilisers. Depending on their purposes, they can be equipped with RP modules like "Warp Point Communications Relay" (They basically allow ships to communicate with the empire directly through the relay, rather than having to jump to the other system, to deliver messages).
But also functional modules like:
a) Refuel Equipment
b) Maintenance Storage & Facilities
c) Recreation Facilities
etc.
I was wondering if we could get a new module that can act like the jump point stabilisation does, except it is build into a station. Such a ship could move to another jump point, but it would need to stay at a new jump point location for an amount x of days until it can provide the service of stabilising the jump point.
Additionally it would only allow allied ships to pass through, and, it could be destroyed. So new options for war and politics... .
Thinking about "moveable jump point stabilisers", mostly for RP purposes. The idea is to construct stations that can transfer ships at jump points. Basically manual jump point stabilisers. Depending on their purposes, they can be equipped with RP modules like "Warp Point Communications Relay" (They basically allow ships to communicate with the empire directly through the relay, rather than having to jump to the other system, to deliver messages).
But also functional modules like:
a) Refuel Equipment
b) Maintenance Storage & Facilities
c) Recreation Facilities
etc.
I was wondering if we could get a new module that can act like the jump point stabilisation does, except it is build into a station. Such a ship could move to another jump point, but it would need to stay at a new jump point location for an amount x of days until it can provide the service of stabilising the jump point.
Additionally it would only allow allied ships to pass through, and, it could be destroyed. So new options for war and politics... .
Most of what you want here is achieved by putting a jump drive on a station and parking it at the jump point.
I thought that any station with a jump drive is capable to jump ships of its own kind, i.e. if I put a civilian jump drive in the station it could jump any civilian ship to its max jump size. Same with a military jump drive. So my idea would circumvent having two jump stations (one civilian, one military) on each jump point.Thinking about "moveable jump point stabilisers", mostly for RP purposes. The idea is to construct stations that can transfer ships at jump points. Basically manual jump point stabilisers. Depending on their purposes, they can be equipped with RP modules like "Warp Point Communications Relay" (They basically allow ships to communicate with the empire directly through the relay, rather than having to jump to the other system, to deliver messages).
But also functional modules like:
a) Refuel Equipment
b) Maintenance Storage & Facilities
c) Recreation Facilities
etc.
I was wondering if we could get a new module that can act like the jump point stabilisation does, except it is build into a station. Such a ship could move to another jump point, but it would need to stay at a new jump point location for an amount x of days until it can provide the service of stabilising the jump point.
Additionally it would only allow allied ships to pass through, and, it could be destroyed. So new options for war and politics... .
Most of what you want here is achieved by putting a jump drive on a station and parking it at the jump point.
I think the only thing that can't be achieved with this is allowing Civilian traffic through the jump point, since they require a stabilized JP to travel through.
Or did you mean that civilian companies can't use those stations?
I would LOVE to see customizable conditional orders (similar to how we have order templates). This would hugely increase the amount of automation available, but still make it feel like you're engaged in that automation because you have to create your own custom automation, if that makes sense. I understand that fully customizable standing orders is a big ask, as there's a lot of programming and debugging. Would it be possible to just get customization for standing orders that already exist and have numeric values?
Being able to set default standing orders/conditional order on the class design screen. but i'm pretty sure that would be complex to do as it would involve ships having some notion of fleet orders.You could have a button/dropdown that overwrites the fleet's current standing/conditional orders with the s/co from a class within that fleet.
I would really love it if civies could build jump capable ships and not require stabilized jump points for inter-system trade/transport. This combined with a "no stabilization" game setting option would be very interesting to play with for me, although I'm guessing that NPRs would have a harder time managing their fleets and empires under this additional constraint.
I would really love it if civies could build jump capable ships and not require stabilized jump points for inter-system trade/transport. This combined with a "no stabilization" game setting option would be very interesting to play with for me, although I'm guessing that NPRs would have a harder time managing their fleets and empires under this additional constraint.
I would not like this as the current situation allows me to control with 100% accuracy when civilians get access to a system. I know I could use the military restriction button but that is per system-basis. Though I admit that a completely no-stabilized-jump-point game would be interesting.
I thought so too, but I might be misremembering the change that was being added. As a compromise alternative, maybe if we were able to make versions of civilian ships ourselves which they would then use, then this would.be I'm the hands of the player to control. Although it wouldn't change things for NPRs, so less than optimal.I would really love it if civies could build jump capable ships and not require stabilized jump points for inter-system trade/transport. This combined with a "no stabilization" game setting option would be very interesting to play with for me, although I'm guessing that NPRs would have a harder time managing their fleets and empires under this additional constraint.
I would not like this as the current situation allows me to control with 100% accuracy when civilians get access to a system. I know I could use the military restriction button but that is per system-basis. Though I admit that a completely no-stabilized-jump-point game would be interesting.
From the next version you should be able to civilian-restrict individual jump points, no?
Would it be possible to have factory-built fighters and space stations use their classes' ship naming theme instead of the default "$CLASS_NAME $NUMBER"?You can uncheck the "Select Random Name from Theme" which almost does what you want when you use "rename all"
Right now, if I build a few dozen fighters from my fighter factories and wish to give them roleplay names (e.g. Laura (https://en.battlestarwiki.org/Blackbird)), then I have to either:
- Manually name them one-by-one.
- Use the bulk "rename all" tool. However, this also changes the names of existing fighters.
Would it be possible to have factory-built fighters and space stations use their classes' ship naming theme instead of the default "$CLASS_NAME $NUMBER"?
Right now, if I build a few dozen fighters from my fighter factories and wish to give them roleplay names (e.g. Laura (https://en.battlestarwiki.org/Blackbird)), then I have to either:
- Manually name them one-by-one.
- Use the bulk "rename all" tool. However, this also changes the names of existing fighters.
You can uncheck the "Select Random Name from Theme" which almost does what you want when you use "rename all"
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up. I don't think Steve would be interested in letting the player automate such a system outright though.
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up. I don't think Steve would be interested in letting the player automate such a system outright though.
I think what is being requested is a way to have the civilian freighter lines handle this instead of player-built freighters, which wouldn't be unwelcome though maybe since we have mass drivers it is not very necessary?
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up. I don't think Steve would be interested in letting the player automate such a system outright though.
I think what is being requested is a way to have the civilian freighter lines handle this instead of player-built freighters, which wouldn't be unwelcome though maybe since we have mass drivers it is not very necessary?
Mass drivers help but what I want is to have the option of having the civilian sector handle the interstellar transportation of minerals and focus the state transports on moving critical military infrastructure.
So IMO it is pretty necessary though my time on this forum has revealed there are plenty who don't agree.
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up. I don't think Steve would be interested in letting the player automate such a system outright though.
I think what is being requested is a way to have the civilian freighter lines handle this instead of player-built freighters, which wouldn't be unwelcome though maybe since we have mass drivers it is not very necessary?
Mass drivers help but what I want is to have the option of having the civilian sector handle the interstellar transportation of minerals and focus the state transports on moving critical military infrastructure.
So IMO it is pretty necessary though my time on this forum has revealed there are plenty who don't agree.
It is true that mass drivers help with local transport of minerals. Interstellar transport has to done manual (the order has to be set up to be be made kind of automatic). It would be nice to have even though it is fully understandable to not like/want it. In situations where you want to transport minerals from a contested the civilian lines would probably come to its limits, plus the rp aspect of it is respectively important.
I am once again asking for(https://abload.de/img/external-content.duckluj7r.jpg)your financial supportSteve to remove the caps on numbers of starting installations at race creation.
[...]
Please, Steve, the NPRs need the help. Won't someone think of the poor NPRs? :P
I am once again asking foryour financial supportSteve to remove the caps on numbers of starting installations at race creation.
Mainly because I'm really just tired of playing high population/high starting tech games where the NPRs are not any threat because they can only develop up to maybe Ion Drive tech, if that, because they are capped at 50 labs no matter what their starting population is (or for that matter the difficulty level - if I want a difficult game, shouldn't the difficulty level...work?). Frankly I cannot see any reason for a cap on the numbers of any installation which is proportional to population - minimums perhaps, but not caps.
Please, Steve, the NPRs need the help. Won't someone think of the poor NPRs? :P
Would it be possible to have factory-built fighters and space stations use their classes' ship naming theme instead of the default "$CLASS_NAME $NUMBER"?
Right now, if I build a few dozen fighters from my fighter factories and wish to give them roleplay names (e.g. Laura (https://en.battlestarwiki.org/Blackbird)), then I have to either:
- Manually name them one-by-one.
- Use the bulk "rename all" tool. However, this also changes the names of existing fighters.
Allow instant moving a Ground Force Formation from one body to another via drag and drop if SM mode is active:
( Disable this check )
(https://i.postimg.cc/2SjBMv1n/image.png)
Small RP suggestion, in two parts:
- For single-star systems, it would be nice if the star and body names would not include the "-A" in their designations. It's a small thing, but "Epsilon Eridani II" looks neater than "Epsilon Eridani-A II".
- The ability to name stars in a multiple-star system independently. The current behavior is a fine default, but sometimes it makes sense to name each star separately especially for races which start in a binary+ system.
Could you make it so that "hide fleets in orbit" only hides fleets that have no orders?
That way ships which are doing a survey don't disappear while they are in orbit, but busy.
I think you misunderstood my post. I'm talking about the setting in the main window, display tab.Could you make it so that "hide fleets in orbit" only hides fleets that have no orders?
That way ships which are doing a survey don't disappear while they are in orbit, but busy.
'Hide Fleets' only hides fleets with no ships, so they should have no orders anyway.
I think you misunderstood my post. I'm talking about the setting in the main window, display tab.Could you make it so that "hide fleets in orbit" only hides fleets that have no orders?
That way ships which are doing a survey don't disappear while they are in orbit, but busy.
'Hide Fleets' only hides fleets with no ships, so they should have no orders anyway.
At the moment when "hide fleets in orbit" is active, you can see geosurvey ships when they move between bodies, but they disappear when they arrive and start work. This means you can have a system of busy ships but not see any of them, until you change the setting. This causes me to change the setting quite frequently.
I thought the easiest way of resolving this was adding an exception for fleets which have orders.
But having thought a little bit more, it would also affect loading/unloading ships as well, so maybe it would be better as an additional option rather than changing the existing setting.
Please consider changing Formation Templates to be populated with Unit Series, rather than specific Units. That way new formations are always built with the latest and greatest Unit in the series. Right now, if you research a new Unit (e.g. because your armor tech increased) you can't start incorporating them into your Formations (by updating the Formation Template) until you are done building any Formations presently under construction.
A special warning message when a story character dies.
Since gameplay is so much quicker in C# Aurora and since commander health is not differenciated from commander death, I quite often happen to miss when my planetary governors die and leave important positions vacant - until I happen to stumble upon it in the planetary display. . . .
So it would be nice to get a separate warning message for story characters when they die off. That way I can ensure "immediate new elections" :-)
Quote from: TMaekler link=topic=10640. msg132606#msg132606 date=1589268935A special warning message when a story character dies.
Since gameplay is so much quicker in C# Aurora and since commander health is not differenciated from commander death, I quite often happen to miss when my planetary governors die and leave important positions vacant - until I happen to stumble upon it in the planetary display. . . .
So it would be nice to get a separate warning message for story characters when they die off. That way I can ensure "immediate new elections" :-)
Yes please! I would like to see that the auto turns are interrupted when an important character dies and leaves a vacant position. I think this is what checking "Story Character" should do, instead of making them immortal - a bit immersion breaking.
(bonuses might also include reduced cost of production)
removes chance of forgetting to name something
removes chance of forgetting to name something
FYI if you don't know, you can rename a component to have the desired company name if you forget to add it during the design step. No need to ask me how I know this.
This aside, I would at least appreciate the ability to save and re-use company names, as once I have a couple dozen it can be hard to keep them all straight without an external file or Google sheet.
RP suggestion: optional ability to assign parts/tech Company Names to individual scientists and then any equipment that scientist completes research on is automatically given that company name.Id prefer to have the company name saved to a specific component type in the design dropdown ( all engines are named with company name X, all active sensors Y, all launchers Z and so on )
I really like this idea, although imagine it would be complex to implement and would require a rebalancing of all research since we'd essentially be relegating our Scientists to only theoretical work and farming out the application research. I do love the idea of making something like R&D less deterministic and feel like this could create good stories.
I could even see it being fun to extend a bit into ship construction itself, where everytime a ship is built there is a chance for "Quirks" to occur, just small things like 1% more fuel efficient or 'fearsome' which would increase policing points more than usual, etc.
At least in SotS2, it wasn't that individual ships developed quirks, it was the design itself worked better (or sometimes worse) than anticipated. However, being a 4X game, those quirks were a lot more powerful and drew from a fixed list. Less 1% faster and more and more +25% range with ballistic weapons or -10% turn speed and thrust speed.I assume this was added because the devs wanted to make ship design less predictable and harder to converge on a single powerful design. It echoes the semi-randomised tech tree. The problem is that it compounds unpredictability and punishes the player for bad luck.
Now to make the code simple, maybe just let the player decide which ships have these reputations.Then it's a case of "player applies small bonus to ship (or ship class)" which is frankly not an interesting game mechanic.
At least in SotS2, it wasn't that individual ships developed quirks, it was the design itself worked better (or sometimes worse) than anticipated. However, being a 4X game, those quirks were a lot more powerful and drew from a fixed list. Less 1% faster and more and more +25% range with ballistic weapons or -10% turn speed and thrust speed.I assume this was added because the devs wanted to make ship design less predictable and harder to converge on a single powerful design. It echoes the semi-randomised tech tree. The problem is that it compounds unpredictability and punishes the player for bad luck.Now to make the code simple, maybe just let the player decide which ships have these reputations.Then it's a case of "player applies small bonus to ship (or ship class)" which is frankly not an interesting game mechanic.
You could apply it via conditions/milestones like medals, but that's still not very interesting.
In any case balance is still an issue, it's very easy to be too large and overpowering, or too small to be interesting.
None of the proposals acknowledge the existing systems of commander bonuses, crew training and fleet training, so it just becomes an extra thing bolted on top.
I'm not convinced that Aurora has any business trying to be unpredictable via 'quirks'. Most of Aurora is deterministic, you can calculate the exact missile hit chance if you know 3 parameters, the missile speed, MR, and target speed.
Then it's a case of "player applies small bonus to ship (or ship class)" which is frankly not an interesting game mechanic.
You could apply it via conditions/milestones like medals, but that's still not very interesting.
In any case balance is still an issue, it's very easy to be too large and overpowering, or too small to be interesting.
None of the proposals acknowledge the existing systems of commander bonuses, crew training and fleet training, so it just becomes an extra thing bolted on top.
I'm not convinced that Aurora has any business trying to be unpredictable via 'quirks'. Most of Aurora is deterministic, you can calculate the exact missile hit chance if you know 3 parameters, the missile speed, MR, and target speed.
It would be helpful if it were possible to limit the number of the population. Currently, it is possible for a planet that serves as a source of colonists to go down to 0 population. However, if it were possible to specify that a colonist limit of, say, 25 million "must" remain on the colony, then only so many colonists could be transported away until the 25 million was reached. The same applies to the destination of the colonists. It could be specified that, for example, 100 million colonists should be transported to a colony.These would be good options to have. I once accidentally almost emptied Earth thanks to super active civilian shipping.
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.
This would rather defeat the purpose of the unit series tab, since the whole idea is that you can use it to replace your obsolete units with newer ones more easily (though still not super easily). I can't think of any case where I would want to hide obsolete units on the series tab.
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.
This would rather defeat the purpose of the unit series tab, since the whole idea is that you can use it to replace your obsolete units with newer ones more easily (though still not super easily). I can't think of any case where I would want to hide obsolete units on the series tab.
You are on your tenth tank design and would like to hide the p previous 8 designs, just like in the ship designer.
~snip snip~
Reducing the armor accuracy to 0.5t as a minimum grid would instantly absolve this while I think not really taking anything away from design efficiency. On the other hand, maybe personal components could be of down to 0.0001 size, although having 5kg components seems kind of ridiculous.(can I now not only add a kitchen, but also detail it down to the individual coffee machines?)
--- What if instead of this there was just a button on the Class Design or something that let you force the game to round up to the nearest ton? Anything smaller isn't modeled at the Shipyard level so even rounding to a half ton loses you that infinitesimal amount of production. Ergo, rounding up to the nearest full ton let's you have the sparkle finish AND not "waste" production.Whatever solution lets me have my round speed numbers, I will take it.
Rather than set demand and supply, set a target qty in a field next to each installation type on that colony, with a check box to turn that target on or off. If the target is on, and you have more than the target, it is treated as available supply. If you have less, it is treated as demand. If you turn the target off, you have no demand or supply for that type on that colony, regardless of the number filled into the target field.From my point of view, this suggestion would make keeping track of what I expect the civs to move harder. Right now, I can set up supply and demand orders for equal amounts (and if it goes wrong, I know why). If this were implemented, any time the civs are moving things in a way I didn't expect, I'd have to go through all my colonies to see where the target numbers are wrong or if a target is on/off when it's supposed to be the other. I expect the way I would use this system would be to usually have everything off, and only turn specifics on at source and destination colonies in order to replicate the current system.
In addition to requiring less clicks/time to set up supply and demand, it resolves any issues with accidental oversupply as sometimes happens now when multiple ships try to bring in supplies, or you are simultaneously using civ shipping and your own ships to bring installations to a colony.
Wealth bug
I've been running a (relatively) longer campaign and found a ruin and began exploiting it. However I noticed that the wealth didn't seem to reflect the gains from the ruins. It also made me remember that the wealth recovered from scrapped ships and components were strange as well, and that my reported annual wealth gains didn't seem to be fully reflected on my wealth balance. I don't remember ever reading a bug report about it (though I might have missed it). So I started a new game in an unmodded DB to check for it. Mostly default settings (no NPR), added a ruin to Earth, SM-built a Xeno brigade and a number of Construction brigades.
In C# there was a change for the wealth balance to be limited to double annual wealth (http://aurora2.pentarch.org/index.php?topic=8495.msg111163#msg111163). It looks like the ruin is allowing you to go over the limit (which is 37836, according to your annual wealth of 18918), but then being corrected on the next tick.
In C# there was a change for the wealth balance to be limited to double annual wealth (http://aurora2.pentarch.org/index.php?topic=8495.msg111163#msg111163). It looks like the ruin is allowing you to go over the limit (which is 37836, according to your annual wealth of 18918), but then being corrected on the next tick.
Based on this exchange in the bugs thread, can you change wealth rewards from ruins?
I think it would be easiest to remove the wealth reward, and instead have a chance of getting some financial centres.
Alternatively, if wealth is 'full' when the reward is triggered, it runs a check to found or expand a CMC. This represents the wealth being fed back into the civilian economy triggering an expansion in civilian activity.
(I'm not personally enamoured of CMCs, but I thought this was a good way to provide a concrete reward and avoid doing weird things like releasing the wealth over a long period)
4) The planned wealth reserve cap can be removed.
Or just remove the Wealth cap as Steve himself suggested after doing a few other changes down the line?That's certainly an option, although I'm not sure that this situation is a strong argument on its own to change the system.
Rather than set demand and supply, set a target qty in a field next to each installation type on that colony, with a check box to turn that target on or off. If the target is on, and you have more than the target, it is treated as available supply. If you have less, it is treated as demand. If you turn the target off, you have no demand or supply for that type on that colony, regardless of the number filled into the target field.
From my point of view, this suggestion would make keeping track of what I expect the civs to move harder. Right now, I can set up supply and demand orders for equal amounts (and if it goes wrong, I know why). If this were implemented, any time the civs are moving things in a way I didn't expect, I'd have to go through all my colonies to see where the target numbers are wrong or if a target is on/off when it's supposed to be the other. I expect the way I would use this system would be to usually have everything off, and only turn specifics on at source and destination colonies in order to replicate the current system.
It would be nice if Enemy ships can't fire while boarded
Alternately, ships which are captured should become neutral (or untargetable?) and uncontrollable for a short duration. This would represent the time during which the boarders are done fighting and starting to figure out how to fly this alien spaceship, and the fact that the prior owners may not be sure whether the boarders won or their people just lost comms and are still fighting, and hence the ship should not be fired upon.
Alternately-alternately, could ship reaction time/firing time be penalized as a function of ratio of boarders (or boarder firepower) to crew? This would represent the fact that the crew are too busy fighting the boarders to do their normal jobs, including on nearby ships that might otherwise fire at a recently captured neighboring ship.
Any of the ideas above would reduce the incidence of captured ships being blown up a few ticks after capture by their nearest prior friend, which really disincentivizes the use of boarding outside of mopping up after a battle.
Inverse Damage Fall off Weapon
Some kind of weapon system that has an inverted damage curve, ie it does the most damage at Max range and minimal or zero damage at short/point blank range.
an inverted to hit chance.
While not opposed in Principle ....
I'd like to suggest that instead, HQ functionality is split into two parts: As now, the HQ## capability would indicate the size of formation which can be controlled, and would work as presently. However, the ability to control subordinate formations would be based on the number of HQ components included in a superior formation. For example, a corps HQ formation controlling four brigade formations, each of 20k, would require a total of five HQ20 components (one for itself + four for the brigades) instead of a single HQ100 component.
While not opposed in Principle ....
I'd like to suggest that instead, HQ functionality is split into two parts: As now, the HQ## capability would indicate the size of formation which can be controlled, and would work as presently. However, the ability to control subordinate formations would be based on the number of HQ components included in a superior formation. For example, a corps HQ formation controlling four brigade formations, each of 20k, would require a total of five HQ20 components (one for itself + four for the brigades) instead of a single HQ100 component.
Some problems
1) None standard Sub units at a division level I may have larger Planatery defense brigades, with smaller infantry or armoured units and a division may be different selections of sub units depending on the Divisions mission. ( so 120,000 ton Division may have 5 20,000 ton sub units or 1 40,000 and 3 20,000 etc)
2) A corp may have several division and also an allowance for independent regiment brigades assigned at corp level and again these may vary between High level HQ Units (600,000 ton corp has 4 120,000 ton Divisions, 2 20,000 ton brigades and 6 10,000 ton logistics regiments or maybe a 40,000 ton PDC Brigade and 2 10,000 ton logistics regiments)
3)I do occassionally produce 50,000 ton sub units normally Super or Ultra heavy armour units (Titan Legions)
While not opposed in Principle ....
Some problems
1) None standard Sub units at a division level I may have larger Planatery defense brigades, with smaller infantry or armoured units and a division may be different selections of sub units depending on the Divisions mission. ( so 120,000 ton Division may have 5 20,000 ton sub units or 1 40,000 and 3 20,000 etc)
2) A corp may have several division and also an allowance for independent regiment brigades assigned at corp level and again these may vary between High level HQ Units (600,000 ton corp has 4 120,000 ton Divisions, 2 20,000 ton brigades and 6 10,000 ton logistics regiments or maybe a 40,000 ton PDC Brigade and 2 10,000 ton logistics regiments)
3)I do occassionally produce 50,000 ton sub units normally Super or Ultra heavy armour units (Titan Legions)
Or in the Ship Design window, add an option under the Misc tab to toggle the default for Damage Control behavior to be automated or not on a class-wide basis, which when toggled would overwrite any individual ship settings?
It would also be more accurate to modern day militaries - a general commanding a division doesn't worry about the condition of the infantry companies despite them belonging to him, he worries about the regiments or brigades. The commanders of those worry about battalions, and the BN commanders worry about companies and so on. So, it would be best if each level only needs the HQ capacity for itself and its direct subordinates.2) A corp may have several division and also an allowance for independent regiment brigades assigned at corp level and again these may vary between High level HQ Units (600,000 ton corp has 4 120,000 ton Divisions, 2 20,000 ton brigades and 6 10,000 ton logistics regiments or maybe a 40,000 ton PDC Brigade and 2 10,000 ton logistics regiments)
This along with the previous point would probably suggest that a superior formation having only the HQs needed to control direct subordinates is the preferable solution.
It would also be more accurate to modern day militaries - a general commanding a division doesn't worry about the condition of the infantry companies despite them belonging to him, he worries about the regiments or brigades. The commanders of those worry about battalions, and the BN commanders worry about companies and so on. So, it would be best if each level only needs the HQ capacity for itself and its direct subordinates.Yes please, a thousand times this. Not having to wait decade to build a top-level HQ unit, just because I want to have a 4 layer OOB of 25k units would be amazing, and the flexibility to grow the armies more organically while also having more variation within would be fantastic.
And not only is it realistic, it's more intuitive for players when building their armies, plus this way your army can grow organically without having the need to plan multiple levels beforehand.
Though the only problem I have with the current system is the crazy cost (in RP and BP) of high-level HQ's. Somehow the size has never bothered me!
Add an RIO seat that provides similar bonuses as a tactical station, but only for fighters.
I don't plan to scale the modules to ship size or add extra crew. That would add extra complexity and make designing ships more difficult. For small ships, most command and control modules won't be used, and once you get past a certain size of ship, they will probably all be used. I am not trying to create a decision as to whether a battleship should have a CIC or Main Engineering, but rather to create meaningful choices for mid-range ships.
--- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.
Make certain that passive sensors trigger the same interrupts as active sensors.
I'm also unsure what problem this suggestion is trying to solve?
Two problems with this:
--- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.
--- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.
Two problems with this:
1. This makes the definition of a commercial engine murky, confusing, exploitative, and pointless. For example, if I understand this correctly I could make a 200% boost engine and click the "commercial" checkbox to have a 100% boost engine at 2x the size... I've designed a standard military engine that reads as commercial on sensors?? You could avoid such silliness by changing the suggestion to say that any engine with 50% boost is commercial, but in that case all we are doing is removing the size restriction which has already been put in place for a game design reason.
2. This requires making an "exception" in the game rules, when the design thrust of C# has been to reduce or eliminate such exceptions.
It is also worth noting - commercial engines do not get a special bonus to fuel efficiency in C#, whatsoever. The improvement in fuel efficiency for a low EP boost modifier is the same regardless of the engine classification.
I'm also unsure what problem this suggestion is trying to solve? We will always have an arbitrary commercial vs. military designation in Aurora, because the mechanics of it are too essential to the gameplay and frankly necessary to keep the level of logistics micromanagement down to reasonable levels. Given that, having a simple and clear distinction between what does and doesn't count as commercial makes much more sense than having a complicated mechanic just for...what reason?
--- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.
Two problems with this:
1. This makes the definition of a commercial engine murky, confusing, exploitative, and pointless. For example, if I understand this correctly I could make a 200% boost engine and click the "commercial" checkbox to have a 100% boost engine at 2x the size... I've designed a standard military engine that reads as commercial on sensors?? You could avoid such silliness by changing the suggestion to say that any engine with 50% boost is commercial, but in that case all we are doing is removing the size restriction which has already been put in place for a game design reason.
2. This requires making an "exception" in the game rules, when the design thrust of C# has been to reduce or eliminate such exceptions.
It is also worth noting - commercial engines do not get a special bonus to fuel efficiency in C#, whatsoever. The improvement in fuel efficiency for a low EP boost modifier is the same regardless of the engine classification.
I'm also unsure what problem this suggestion is trying to solve? We will always have an arbitrary commercial vs. military designation in Aurora, because the mechanics of it are too essential to the gameplay and frankly necessary to keep the level of logistics micromanagement down to reasonable levels. Given that, having a simple and clear distinction between what does and doesn't count as commercial makes much more sense than having a complicated mechanic just for...what reason?
--- If Commercial Engines get no fuel efficiency bonus above and beyond the typical, then that's fine, but the point is that a Commercial Engine can be used Commercial-y. It is valid for no maintenance designs. The Military Engine with 200% doesn't have this ability, while the commercial engine does, but trades away the power and instead gives that mass over to the ability to be No Maintenance when on a Commercial Design. Using Commercial Engines on a Military Ship thus have no utility anymore, since the No Maintenance is wasted.
--- This streamlines the how and why, since we can assume the how is that whatever is being used to make the Military one go 200% is halved or being used to the effect of making a smaller one at 100%, while using that space saved to add the Magic Doesn't Break Smoke that makes Commercial Engines do their thing. Likewise, the arbitrary engine size and power limit is no longer an arbitrary limit, but a flexible one with a simple toggle that asks the player: "Is this for a Warship or Not?" Another problem it solves is not being able to make tiny Commercial Ships... or even FAC sized ones, to be honest. Currently every Commercial ship MUST exceed 1,250 Tons... before Crew Quarters, Fuel and the lot.
--- What will this be used for? Currently Fighter-sized cryo is bugged since Fighters still can't land on planets to offload colonists... so that's of no use. However, the addition of Small Craft Refueling System means a No Maintenace FAC tanker sees a good benefit from this change. Likewise with Deep Space Populations and the renamed Orbital Habitats... a centralized Colonist supply could be established with Commercial FACs / Fighter scale colonist shuttles refilling the "stock" Tiny FAC sized or smaller scouts receive a good benefit from this, since they would need no maintenance and no additional deployment for their missions, being able to relocate under their own power and hang around forever.
--- Finally, this does not create an exception to the rules at all. Commercial Engines are ALREADY an exception made more exceptional by the arbitrary limits. Jump Drives ALREADY use a toggle to this end, but regular engines don't. Such a toggle streamlines, simplifies and brings regular engines into line with the Jump Engines that they mechanically interact with. This eliminates a special mechanic rather than makes it more complex. A toggle is straightforward, highly visible and not confusing to a new player who wouldn't realize it's 50% or lower AND has to be AT LEAST 1,250 Tons.
--- Hell, while we're at it, why not do the same for sensors? Give it a dropdown to tag it as Commercial, same size, but half the strength... but putting it on a ship doesn't make it military?
~~snippy snippy~~
You could make a commercial engine twice as big as the technology engine size limit.
How would the size change interact with the fuel efficiency from engine size?
Not sure how I feel about large civilian sensors, sure they're less powerful for balance and I assume still expensive to build but having maintenance free mega-radar seems a bit off given how sensitive and delicate sensor equipment is supposed to be.
With engines though I'm kind of onboard with the idea of having a commercial toggle that is equivalent to current power/mass/fuel efficiency ratio to allow for commercial "fighters".
The problem, such as I intuit it, is that commercial ships cannot be small, because commercial engines cannot be small, and commercial ships cannot be relatively fast, because commercial engines have low EP per ton. The latter also limits the pulling power of Tugs.
--- If Commercial Engines get no fuel efficiency bonus above and beyond the typical, then that's fine, but the point is that a Commercial Engine can be used Commercial-y. It is valid for no maintenance designs. The Military Engine with 200% doesn't have this ability, while the commercial engine does, but trades away the power and instead gives that mass over to the ability to be No Maintenance when on a Commercial Design. Using Commercial Engines on a Military Ship thus have no utility anymore, since the No Maintenance is wasted.
--- I failed to communicate this, and I'm sorry for that, but my assumption was the Engine Size tech was still the upper limit for what you could choose as a base. So a 200% Military Engine that was 1,250 tons would indeed become a 100% Commercial Engine of 2,500 Tons. I deemed that mostly irrelevant since it confers no advantage, however with consideration of larger engines being more fuel efficient than smaller per hullsize that might not actually be the case.
--- This streamlines the how and why, since we can assume the how is that whatever is being used to make the Military one go 200% is halved or being used to the effect of making a smaller one at 100%, while using that space saved to add the Magic Doesn't Break Smoke that makes Commercial Engines do their thing. Likewise, the arbitrary engine size and power limit is no longer an arbitrary limit, but a flexible one with a simple toggle that asks the player: "Is this for a Warship or Not?" Another problem it solves is not being able to make tiny Commercial Ships... or even FAC sized ones, to be honest. Currently every Commercial ship MUST exceed 1,250 Tons... before Crew Quarters, Fuel and the lot.
--- Hell, while we're at it, why not do the same for sensors? Give it a dropdown to tag it as Commercial, same size, but half the strength... but putting it on a ship doesn't make it military?
Verisimilitude is always nice. :)
I have a small suggestion that would probably be very useful:
On the left side of the Class Design window, where it lists all your ship designs, put in brackets an "(o)" next to the names of classes that use components that are marked as obsolete.
Alternatively, the names of the ships with obsolete components could be given a colour like red or yellow and when clicking on one of those ships and then on the "class components" tab, the obsolete components could also be highlighted in that colour. That would be nice, too.
ELINT ships tend to be deployed for many years at a time, following an NPR population at a large distance--just close enough for the ELINT sensors to detect the EM signature of the population.Hear hear, this would be very useful!
Sometimes, the EM signature of an NPR population decreases.
When this happens, the ELINT ship can lose contact with the population.
As a result, the ELINT ship is no longer gathering intel, and this can continue for years, since the player is not made aware when this happens.
It would be nice if an ELINT losing contact with an enemy population caused an event log message to appear.
Top of my suggestion list would be edit for orders....
I would also appreciate a "Refresh Lagrange Point Usage" feature that would re-check all the intra-system movement for Lagrange shortcuts.And the ability to put it in as an order too, so you can re-plot course every time you enter a system on a looping order.
Would it be possible for Artillery, when being subjected to Counter-Battery Fire, would use the higher of their two "evasion" stats? So the higher of Hit Mod or Fortification. This I think would make representing a vehicle's ability to "shoot and scoot" over a Static pieces in-ability better represented w/ minimal effort. Since it happens in the Bombardment phase, which I assume is distinct from the regular Attack / Defend phase, this might be simple~ish to execute.
This thread (https://aurora2.pentarch.org/index.php?topic=12977.msg160180) has an interesting conversation regarding Terraforming Installations and their utility compared to the ship-based component. Long story short, Terraforming Installations are wretched as they're a logistical nightmare (5 cargo holds per installation + infrastructure required for the population to run them) as opposed to orbital stations, which can be tugged into place much quicker and easier. The fact they cost more is just insult to injury.
I'd like to propose that the cost of Terraforming Installations be slashed, anywhere from one-half to one-quarter their current value. This would create an actual trade-off for the logistical headache they pose for use anywhere outside of Sol. It'd also be a lore-friendly way to explain how it takes a million people on the planet to do what a crew of hundreds can accomplish in orbit - i.e. automation. And as Jurassic Park taught us, that kind of automation is neither easy, nor cheap. :)
--- How about a type of Countermeasure for GSFs? Or two types, even! One that reduces the accuracy of incoming fire, like an ECM and one that increases a GSFs weighting for the random target allocation? So this way we can use the firs type of countermeasure to make our GSFs more survivable versus ground fire, while the second kind can be used to make "Wild Weasels" either with lots of speed and armor for tanking, or maybe with a powerful countermeasure system of the former type! Or perhaps even some blend of these attributes.
--- How about a type of Countermeasure for GSFs? Or two types, even! One that reduces the accuracy of incoming fire, like an ECM and one that increases a GSFs weighting for the random target allocation? So this way we can use the firs type of countermeasure to make our GSFs more survivable versus ground fire, while the second kind can be used to make "Wild Weasels" either with lots of speed and armor for tanking, or maybe with a powerful countermeasure system of the former type! Or perhaps even some blend of these attributes.
While I'm sure there's some potentially terrible way this breaks the game, I'm in favor of expanding the representation for non-combat ground force capabilities, and this would be a good tool to represent modern-style SIGINT or EWAR stuff.
Top of my suggestion list would be edit for orders.Speaking in general terms: ways to make repeatable command queues easier to handle as well as making templates more versatile - with the goal in mind to minimise the effort to maintain a larger empire, I would be in for that, too. That it is simply too much effort to maintain multiple and larger empires is one of the few aspects that keeps me from diving too deep into this fantastic story telling device.
It would be helpful if the fleet order queue had time estimates for each step in the queue. I assume this data is already being estimated, since there's a total time estimate at the top, and it would be great to know how long each step is going to take even if it's a rough estimate.
Suggest adding the ability to offer civilian shipping lines a bonus (costs the player wealth) to focus on colonizing (moving colonists and infrastructure trade goods) or fulfilling cargo move requests (Demands and Supplies on the Civilian Economy tab). This would enhance the utility of civilian shipping lines, without turning them into a fully player directed set of fleets. It would also give the player a way to subsidize growth of the civilian lines.
I just had a single survey location result in two new unexplored jump gates. After exploring, they led to two different systems, but it got me thinking. It would be cool if some systems had two jump gates between them, to different points in the systems, i.e. system A and system B have two jump gates each that lead between them. This would probably by a very minor amount of impact to the game, but would add flavor/uniqueness and very rarely might reduce the effectiveness of jump gates as a choke point.
I just had a single survey location result in two new unexplored jump gates. After exploring, they led to two different systems, but it got me thinking. It would be cool if some systems had two jump gates between them, to different points in the systems, i.e. system A and system B have two jump gates each that lead between them. This would probably by a very minor amount of impact to the game, but would add flavor/uniqueness and very rarely might reduce the effectiveness of jump gates as a choke point.
I have seen this before, both systems were within the local cluster range (10 IIRC), the first one had only 2 WP initially, but the second one had seven, one of which opened a third WP back in the first system.
.
In my last game i also had two WP connected to each other in the same system, which sometimes allowed for a bit of a short cut, like LPs.
Some Sol System Updates:
1) Ultima Thule is now named 486958 Arrokoth.
2) Currently only Earth and Mars have any water present at game start. We know Enceladus & Europa are "ice Shell" worlds with "planet" spanning sub-surface oceans. Ganymede likewise has a subsurface ocean that is estimated to contain more water then Earth. Ceres is about 30% water by mass.
3) additionally, Pluto, while it's surface is 98% Nitrogen Ice, the crust is water ice and may have a liquid water ocean sub-surface. It also has a nitrogen atmosphere, although that is only .000001 atm.
Hey, allow tankers to move water between worlds. It would be faster than pumping in water vapor and allowing that to condense.Would it be faster?
Ah I didn't meant to transport the equivalent mass of Earth's water, but using tankers when they aren't busy to transport water from Europa, for example, to Mars in early game.Hey, allow tankers to move water between worlds. It would be faster than pumping in water vapor and allowing that to condense.Would it be faster?
Earth's water is estimated at 1E18 metric tons, or basically the same # in cubic meters of volume as a liquid. 1 "ton" of cargo space is really 11 m^3 of volume, yes? So to move an Earth equivalent amount of water, we need 9E16 tons of lift, or 1.8E12 standard cargo holds. It takes, what, 11 days to unload a standard bay with conventional shuttles? We thus require 5.7E10 module-years just to unload, not counting travel OR loading time.
By contrast, it takes 1.775 atm of water vapor to condense 71% coverage. This is 7100 module-years at base tech.
Ah I didn't meant to transport the equivalent mass of Earth's water, but using tankers when they aren't busy to transport water from Europa, for example, to Mars in early game.
You'd end up implementing a feature that could make maybe 0.000001% difference in your terraforming ability.On that note, if we wanted to talk about adding something !fun! that could still impact terraforming, let us attach engines to asteroids/comets and crash them into planets to transfer water ice and other minerals ;D
I think the gist was that the mass of water required is so many orders of magnitude beyond what tankers can realistically move that it doesn't make a lot of sense. You'd end up implementing a feature that could make maybe 0.000001% difference in your terraforming ability.Yeah I guess, I hadn't crunched the numbers at all.
You'd end up implementing a feature that could make maybe 0.000001% difference in your terraforming ability.On that note, if we wanted to talk about adding something !fun! that could still impact terraforming, let us attach engines to asteroids/comets and crash them into planets to transfer water ice and other minerals ;D
For a civilian shipping delivery that starts and ends in the same system, the shipping line pays tax equal to half the single-hop amount.
This is too much.
The typical distance between large populations in a single system is much less than half the typical distance per hop between large populations in separate systems.
It's probably closer to one tenth.
As a result, the number of easy colony locations in your starting system has an outsized impact on your wealth development.
Systems like Sol, which have multiple low-cost, easily terraformable colony prospects, generate so much early wealth via civilian shipping that the player's strategic decisions for the entire game are only very rarely impacted by wealth concerns. The player gets rich fast by developing those home system colonies, and then never has to worry about wealth again.
If you start in a system without easy colony prospects, you don't enjoy this early source of easy wealth, and as a result you actually do have to manage your spending wisely, and devote non-trivial research and production to increasing your tax income.
I suggest dropping the intra-system civ tax to either 10% or 20% of the single-hop rate.
To me this is like saying that if a race starts in a system with JPs 10b km apart they have to put more fuel into their ships than a race starting in a system with JPs 500m km apart - this is true, and it's arguably even unfair, but it's part of the Aurora DNA to have to adapt to such circumstances.
For the 2 you can already do that with fleet formation. You can attach a fleet to another one in system and choose its distance and angle compared to the target fleet, as well as some conditions in which the fleet will go in the specified formation (a threat in the system for example).
Construct all components for ship optioni USED to do that for EVRY ship of EVERY class, then EVERY ship of warship classes, then the FIRST run of every warship class. . . .
Quality of life feature: Add an option under the industry, either in the components selection or preferably as its own separate list that allows you to simply construct all components for a given ship class. This so you don't have to constantly go trough and figure out what components is needed and individually build them.
It's only faster in terms of keellaying-to-deployment. Not in terms of vessels per year per unit of TN capital investment.
It's potentially very useful if you are waiting on a specific new component before laying a bunch of keels for a new class, that you need really urgently. E.g. pre-building the engines for a class that you can't lay keels for because the fire control designs are not ready yet, or pre-building components while you tool up the yards. But in terms of sustained production, you are better off expanding yard capacity than factory capacity.
There is some tradeoff in that factories typically have higher utilization than yards (you can use factories for other things when not in a shipbuilding program), so if you tend to build your ships in spurts with long idle periods for your yards, it can be worth it to take the higher up-front cost of capital to end up with lower levelized cost through higher utilization. But building that kind of models is a thing I insist on getting paid for, so I usually don't break out the spreadsheets and instead just eyeball it.
Which, actually now that I think about it...
... why not let shipyards perform overhauls? That would let us use unused yard slips to free up maintenance facilities, and would certainly be a thing you would do in the real world during a shipbuilding downturn.
Maintenance facilities are taken up by maintaining the ship during overhaul - if you have an idle slip, two 6,000 ton patrol boats, and 15,000 tons of maintenance facilities, then both your non-overhauling patrol boats will start to accrue maintenance clock when you bring in your third patrol boat for overhaul.
It didn't use to work that way in VB6, because maintenance facilities had unlimited capacity subject to a size cap. But in C# maintenance facilities provide tonnage capacity, not berth size.
Honestly, I always try to keep my maintenance facilities numerous enough to support my entire fleet so I can keep them at base when not doing navy business, plus I rotate deployments frequently so the number of ships at home base is fairly constant, so this is never a problem for me. Do other folks frequently outbuild their maintenance capacity?I frequently end up overbuilding my shipyard capacity during my fleet renewal programs, after which they fall into idleness because I don't have the minerals to fully utilize them. If (to take an implementation that would not add to micro) idle naval slipways would add some percentage of their tonnage to maintenance capacity, I could build fewer maintenance facilities. (The same thing happens with commercial yards, but I always imagine them churning out ships for the civilian liners, so that is less of an imposition on suspension of disbelief.)
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.
This ability is already provided by the escort functionality on the Naval Organization window.
1. Please make it possible to edit total empire Wealth using SM. Could place that button on the "Wealth/Trade" screen. When you play multi-faction gamed Wealth can be used as method of payment for many things.
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.
This ability is already provided by the escort functionality on the Naval Organization window.
Sort of. I think OP is asking for an option for having an escort position that moves relative to the anchor fleet, rather than is fixed in position relative to the anchor.
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.
This ability is already provided by the escort functionality on the Naval Organization window.
Sort of. I think OP is asking for an option for having an escort position that moves relative to the anchor fleet, rather than is fixed in position relative to the anchor.
Aren't they the same thing? With formation orders, if the Anchor fleet moves, the escort fleet moves either relative to the Anchor fleet or to maintain position between the Anchor fleet and a chosen target, depending on the orders.
I edited my post above and added an example to clarify.
Some Sol System Updates:
1) Ultima Thule is now named 486958 Arrokoth.
2) Currently only Earth and Mars have any water present at game start. We know Enceladus & Europa are "ice Shell" worlds with "planet" spanning sub-surface oceans. Ganymede likewise has a subsurface ocean that is estimated to contain more water then Earth. Ceres is about 30% water by mass.
3) additionally, Pluto, while it's surface is 98% Nitrogen Ice, the crust is water ice and may have a liquid water ocean sub-surface. It also has a nitrogen atmosphere, although that is only .000001 atm.
I know there are many others that i did not cover, but it would be nice to see the larger Sol systems bodies that are colonization candidates have both hydrosphere and atmospheres that they posses in reality.
It would be helpful if the fleet order queue had time estimates for each step in the queue. I assume this data is already being estimated, since there's a total time estimate at the top, and it would be great to know how long each step is going to take even if it's a rough estimate.
That would be nice, but I don't think that estimates are being calculated for each step.
The total estimate is just the total distance traveled divided by the speed of the fleet.
Time required for non-movement orders (refueling, loading/unloading, etc) is not included in the time estimate, nor is any time added to the estimate for orders that have time delays.
Suggest removing the star system name for moons and planets in the second field of the mineral search.
Currently the first field in the row provides star system name which is then repeated for every planet and moon, squashing out the detail identifying the body so you cannot see the actual number of the moon or whether it already has a colony.
If the redundant repetition of the star system name was removed from default generated names there would be enough room to see the relevant detail, if not then there is enough spare width to make the field a bit bigger too.
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.
This ability is already provided by the escort functionality on the Naval Organization window.
Sort of. I think OP is asking for an option for having an escort position that moves relative to the anchor fleet, rather than is fixed in position relative to the anchor.
Aren't they the same thing? With formation orders, if the Anchor fleet moves, the escort fleet moves either relative to the Anchor fleet or to maintain position between the Anchor fleet and a chosen target, depending on the orders.
Hey Steve.
How difficult would it be to implement a system that would allow a ship component to change ownership? I personally would like to encourage RP between nations (trade exchanges) or to create small nations to simulate companies (and build for other larger nations components) or for multiplayer games (like the one we are playing here (http://aurora2.pentarch.org/index.php?topic=12895.0)).
Thanks!
Hey Steve.
How difficult would it be to implement a system that would allow a ship component to change ownership? I personally would like to encourage RP between nations (trade exchanges) or to create small nations to simulate companies (and build for other larger nations components) or for multiplayer games (like the one we are playing here (http://aurora2.pentarch.org/index.php?topic=12895.0)).
Thanks!
You could do this in the old VB Aurora, I hope Steve will add something similar to C# eventually. I use this all the time in my game. One faction might build a certain component and the export that to other factions. You also should be able to transfer the component technology so other factions can license build those components.
Top of my suggestion list would be edit for orders.
I know it would be harder than it sounds as the orders are contextual, one following on from the context of the preceding order, but I think it might be possible to edit at a pointer in the order stack to insert or remove an order based on the preceding order as context and then remember the rest of the stack and add them back one by one when the edit is done with a context check on each as it is added back using the existing context subroutines. If a context is detectably broken, then the order would go red and if a break occurs during gameplay then you get the same as is currently the case and a message saying ShipX cannot complete order.
Would also be nice (in C#) to be able to add / insert chunks of template based on the preceding order context rather than current context of the ship being ordered, which I recall was different in VB6 so I am sure you know what I mean. Must be practicalities I am not aware of but just thought I would mention it.
Its just giving orders is such a substantial part of the way Aurora plays it strikes me it would be worth adding order queue edit and imagine that Steve would enjoy the result for his own QoL, so just airing the thought since this is the suggestions thread. :)
I have a small suggestion that would probably be very useful:
On the left side of the Class Design window, where it lists all your ship designs, put in brackets an "(o)" next to the names of classes that use components that are marked as obsolete.
Alternatively, the names of the ships with obsolete components could be given a colour like red or yellow and when clicking on one of those ships and then on the "class components" tab, the obsolete components could also be highlighted in that colour. That would be nice, too.
Edit:
Similarly, unlocked class designs should also have either an "(u)" next to their name or have a different colour for their name.
With the upcoming changes to fighter management likely to make fighters much less micro-intensive, I am using fighters in my current 1.13 game to learn the ropes. One thing I've noticed is really tedious is having to manually set each and every fighter to "Automated Damage Control", as they apparently all start with that unchecked.
Would it be possible to make the default for "Automated Damage Control" to be checked? Or in the Ship Design window, add an option under the Misc tab to toggle the default for Damage Control behavior to be automated or not on a class-wide basis, which when toggled would overwrite any individual ship settings? That would allow people to make mass changes with a minimum of tedium, while still permitting granular control by ship if desired.
Construct all components for ship option
Quality of life feature: Add an option under the industry, either in the components selection or preferably as its own separate list that allows you to simply construct all components for a given ship class. This so you don't have to constantly go trough and figure out what components is needed and individually build them.
Hey Steve.
How difficult would it be to implement a system that would allow a ship component to change ownership? I personally would like to encourage RP between nations (trade exchanges) or to create small nations to simulate companies (and build for other larger nations components) or for multiplayer games (like the one we are playing here (http://aurora2.pentarch.org/index.php?topic=12895.0)).
Thanks!
You could do this in the old VB Aurora, I hope Steve will add something similar to C# eventually. I use this all the time in my game. One faction might build a certain component and the export that to other factions. You also should be able to transfer the component technology so other factions can license build those components.
I've added component and ordnance transfers for v2.0.
The component tech itself might be abusable, because you could build the component and then disassemble it.
I've added component and ordnance transfers for v2.0.
The component tech itself might be abusable, because you could build the component and then disassemble it.
Something I suggested somewhere but don't remember where:
Could Fire At Will automatically reassign a new target once it destroys its current target? I'm not the kind of player who likes to micromanage massive battles (especially when hundreds of fighters are involved.) I tend to tick the Fire At Will box and pretend that everything the fleet is doing is the admiral's orders. However, every time a ship on Fire At Will destroys its target, it's out of the fight so to speak because it doesn't re-target, and when there's lots of ships, it's hard to tell who is and isn't firing like they should be.
Also, in a fleet's ship combat screen, could identical components be stacked? I.e., rather than a ship combat screen reading:
Beam Fire Control
Twin Laser Turret
Twin Laser Turret
Twin Laser Turret
Twin Laser Turret
Twin Laser Turret
Twin Laser Turret
It instead reads:
Beam Fire Control
x6 Twin Laser Turret
There could also be option that allows you to assign a specific number to a fire control, kind of like how you can assign a specific number of units from ground formations. This would especially help with missile ships that have to have a massive amount of missiles launchers to be effective.
Something I suggested somewhere but don't remember where:
Could Fire At Will automatically reassign a new target once it destroys its current target? I'm not the kind of player who likes to micromanage massive battles (especially when hundreds of fighters are involved.) I tend to tick the Fire At Will box and pretend that everything the fleet is doing is the admiral's orders. However, every time a ship on Fire At Will destroys its target, it's out of the fight so to speak because it doesn't re-target, and when there's lots of ships, it's hard to tell who is and isn't firing like they should be.
Hell yeah, thanks Steve.I have a small suggestion that would probably be very useful:
On the left side of the Class Design window, where it lists all your ship designs, put in brackets an "(o)" next to the names of classes that use components that are marked as obsolete.
Alternatively, the names of the ships with obsolete components could be given a colour like red or yellow and when clicking on one of those ships and then on the "class components" tab, the obsolete components could also be highlighted in that colour. That would be nice, too.
Edit:
Similarly, unlocked class designs should also have either an "(u)" next to their name or have a different colour for their name.
I've added a change on these lines:
http://aurora2.pentarch.org/index.php?topic=12523.msg160549#msg160549
There is a new checkbox that will highlight classes with obsolete components in orange. This will likely be a large majority of classes in most cases which is why I included the checkbox.
Construct all components for ship optionI've wanted this, too. I may have also suggested it in the past.
Quality of life feature: Add an option under the industry, either in the components selection or preferably as its own separate list that allows you to simply construct all components for a given ship class. This so you don't have to constantly go trough and figure out what components is needed and individually build them.
Completely agreed.I actually wouldn't like a change in behavior of the auto FC assignment in this way, as in most of my large multi-weapon platforms I do want even distribution across FCs so that I can apply the same groupings of firepower to multiple targets at once and reduce target switching. Not to say that my way is "right" or preferable, just that changing this behavior would probably move the cheese for some others.
Additionally, it would generally be preferable if the automatic FC assignment only assigned one type of weapon per FC, since this is the usual way of managing multiple-weapon ships. I keep having to fix auto-assignments where, say, 6 particle beams and 10 railguns are split between 4 fire controls in a 6PB/2PB+2RG/4RG/4RG split when I really want 3PB/3PB/5RG/5RG.
Completely agreed.I actually wouldn't like a change in behavior of the auto FC assignment in this way, as in most of my large multi-weapon platforms I do want even distribution across FCs so that I can apply the same groupings of firepower to multiple targets at once and reduce target switching. Not to say that my way is "right" or preferable, just that changing this behavior would probably move the cheese for some others.
Additionally, it would generally be preferable if the automatic FC assignment only assigned one type of weapon per FC, since this is the usual way of managing multiple-weapon ships. I keep having to fix auto-assignments where, say, 6 particle beams and 10 railguns are split between 4 fire controls in a 6PB/2PB+2RG/4RG/4RG split when I really want 3PB/3PB/5RG/5RG.
Idea - booster.
Component, that is basically an engine, that can be put in addition to normal engines and can be turned off to not affect fuel usage, but is stupidly ineffective, like 3x fuel consumption.
Idea is, this component can be mounted on warships to make them rather fuel efficient when not in combat, but have good speed when in combat.
I know I can do this with tugs or carriers, but it would be great for patrol ships, tat needs some combat power, while being cheap to produce.
To make it even less attractive to put on every warship it could be able to overheat (get destroyed) after some time of constant usage.
For programming simplicity it could be created, that it isn't throttable (I don't know if this is right word. It's used in KSP in this context) i.e. It can either be turned off, or work at 100%. It couldn't be able to be set to other values, like 50%.
Idea - booster.
Component, that is basically an engine, that can be put in addition to normal engines and can be turned off to not affect fuel usage, but is stupidly ineffective, like 3x fuel consumption.
Idea is, this component can be mounted on warships to make them rather fuel efficient when not in combat, but have good speed when in combat.
I know I can do this with tugs or carriers, but it would be great for patrol ships, tat needs some combat power, while being cheap to produce.
To make it even less attractive to put on every warship it could be able to overheat (get destroyed) after some time of constant usage.
For programming simplicity it could be created, that it isn't throttable (I don't know if this is right word. It's used in KSP in this context) i.e. It can either be turned off, or work at 100%. It couldn't be able to be set to other values, like 50%.
It might be too complicated and/or "ship-focused" for Aurora (I think Steve has said he prefers the game to be focused on fleets more than individual ships, though I could very well be incorrect), but I also would like something like this. I would love to see something that resembles the military/commercial engine split in Starfire which I thought made for some interesting strategic/tactical tradeoffs and decision making in ship designs.
Maybe a good approach for the boosters (which could even be added to engine design as another option) would be to apply a similar overboost rule as missile engines, up to double the design EP modifier but with a linear fuel penalty up to 5x in addition to the usual -5/2 power factor for EP modifier.
Sounds good, but the "boosters" EP multiplier should be researchable levels. a flat 5x i think would be too much, but if you start with a 2.5x and research in .25 increments i think it could work quite well.
Sounds good, but the "boosters" EP multiplier should be researchable levels. a flat 5x i think would be too much, but if you start with a 2.5x and research in .25 increments i think it could work quite well.
To clarify, the 5x is in reference to fuel efficiency. The idea is to mirror the missile boost rule, where missiles can have up to 2x the racial tech maximum for EP boosting, but going over the racial tech level incurs an extra penalty which maximizes at 5x. For example, if the racial boost tech level is 2.0x, a missile with 4.0x EP boost will have a 1/5 penalty to fuel efficiency in addition to the usual inefficiency of boosted engines. A missile with 3.0x boost will have a 2/5 extra penalty, and so on.
In this case I would suggest that you could install a boost of up to 2x the baseline engine power, but with the same overboost penalty as missiles already use. The other question is how to balance costs since otherwise this is a tactically superior option to normal boosted engines since fuel use in combat is usually pretty minimal.
Sounds good, but the "boosters" EP multiplier should be researchable levels. a flat 5x i think would be too much, but if you start with a 2.5x and research in .25 increments i think it could work quite well.
To clarify, the 5x is in reference to fuel efficiency. The idea is to mirror the missile boost rule, where missiles can have up to 2x the racial tech maximum for EP boosting, but going over the racial tech level incurs an extra penalty which maximizes at 5x. For example, if the racial boost tech level is 2.0x, a missile with 4.0x EP boost will have a 1/5 penalty to fuel efficiency in addition to the usual inefficiency of boosted engines. A missile with 3.0x boost will have a 2/5 extra penalty, and so on.
In this case I would suggest that you could install a boost of up to 2x the baseline engine power, but with the same overboost penalty as missiles already use. The other question is how to balance costs since otherwise this is a tactically superior option to normal boosted engines since fuel use in combat is usually pretty minimal.
edit: additional thought, if it is possible to add boosters, could we get the agility to use multiple engine designs on one ship? Example would be using a 50HS engine as my "main" engine on capital ships, with 10 or 15 HS engines to tailor the speed that i want.
In order to make civilian ships take a bit less resources I would change how the fuel efficiency technology impact civilian shipping.
In my games I always have my factions stay at 50% minimum efficiency and only lower it with SM when designing ships after investing the research necessary and record each factions actual tech level on an excel sheet or other document.
The thing is that ships are more expensive and they build less but they go way faster so are more efficient. The lower price of the engines is not really good for the game and the ships speed is important for how efficient they are.
I would make some adjustment to how many civilian ships are built and how the fuel efficiency technology impact the civilian fleet. I would have civilian ships always use 50% fuel efficiency engines and instead increase the wealth generation by a small amount for each delivery. I might also increase the cost of the ships by a some amount (for the companies to buy them) to reduce the civilian ships to some degree overall. But they also would earn more money so it will eventually even itself out.
The effect would be less civilians ships but more efficient ones.
I also think that the civilians should build bigger and bigger ships over time, this would also reduce the amount to a certain agree. At least a bit bigger than the largest civilians currently. Some smaller civilians are still good, but bigger ships should also try to find pickups that matches their cargo space and not try to pick up half their cargo space. That would leave the smaller ones to take the contracts that is small or planets with low luxury generation. The bigger ships will generally traffic the routes where there are more cargo to be transported.
As it is, the lower efficiency engines makes the civilian fleet worse and they are able to buy more ships. As they don't actually use fuel there should be some different rule how the efficiency makes civilians ships better. not cheaper and worse. This would to some degree help with game slowdowns later on as well.
It depends on fuel cost. If civilians don't have to pay for fuel, then you're right. But if they have to pay for it, then it can be more problematic.
Another thing I might want to have for performance reasons are able to decide how long log data should be stored in the database. If I want to purge all log data that are older than a year I should. I also would like to have a quick delete button for clearing the log of all combat logs, things like ground combat logs can severely slow the game down if it drags out as it creates a huge amount of data quickly.
Idea - booster.Allowing slow steaming (http://aurora2.pentarch.org/index.php?topic=8107.msg105075#msg105075) seems like a more elegant solution than bolting an SRB onto the engine. To me, at least.
Component, that is basically an engine, that can be put in addition to normal engines and can be turned off to not affect fuel usage, but is stupidly ineffective, like 3x fuel consumption.
Idea is, this component can be mounted on warships to make them rather fuel efficient when not in combat, but have good speed when in combat.
I know I can do this with tugs or carriers, but it would be great for patrol ships, tat needs some combat power, while being cheap to produce.
To make it even less attractive to put on every warship it could be able to overheat (get destroyed) after some time of constant usage.
For programming simplicity it could be created, that it isn't throttable (I don't know if this is right word. It's used in KSP in this context) i.e. It can either be turned off, or work at 100%. It couldn't be able to be set to other values, like 50%.
Also, while speaking of sensors, I would like to have the same thing with active sensors, they should also be able to be turned on individually and not as a whole. It is quite irritating when I must turn on my 100 resolution active if the only thing I want is to use my resolution 1 sensor. The current way this work just means that I rarely put bigger active on ships than resolution 5, everything else are in small scout crafts.
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?
It is in the next update (http://aurora2.pentarch.org/index.php?topic=12523.msg157428#msg157428). :)
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?I'd also like to see a modifier to increase lifespan of officers. Just because we only have a 75-80 year life span doesn't mean that a TN race will too :)
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?I'd also like to see a modifier to increase lifespan of officers. Just because we only have a 75-80 year life span doesn't mean that a TN race will too :)
I like the realistic promotions, but it isn't unusual to see them die or retire before earning many medals when it is used. I know you can manually prevent it on an individual basis, but I would prefer to just give them longer life spans.
Also, perhaps more triggers for medals like assignment to a given task, ie assigned 1st officer, assigned science officer, etc. Basically a ticket punching mechanism to give promotion points to officers that have been used & also increase the number of medals for the more experienced & higher ranking officers.
Rework shields for balance vs armor and better roleplay
Currently: Shield strength scales with the generator size in HS as Size^(3/2). This causes the efficiency of shields per HS relative to armor to increase a lot from one tech level to another, with Epsilon Shields (16k RP) being 40% as efficient as Laminate Composite Armour (20k RP), Theta Shields having 48% relative efficiency, and continuing to increase to a maximum of 75% relative efficiency at high tech levels. In practice, a ship with reasonably thick armor will begin taking internal damage once armor is degraded by about 50%, so a shield which is relatively ~50% as effective as armor is in practice superior against any weapon except mesons, and often is preferable even at lower tech levels against lasers or particle lances which penetrate armor effectively.
On the flip side, small shield generators in the few-HS range are very inefficient to the point of being basically useless. This means that putting shield generators on fighters, FACs, or other smaller ships is usually not practical, despite being a very common fixture in sci-fi settings. While the previous point by itself is okay, since it's fine for newer tech systems to change the combat balance, in my opinion the game mechanics should not limit roleplay in this way.
Suggested change: Rework shields so that regeneration rate scales as Size^(3/2) and generator strength scales linearly with size. This means there is still a tactical advantage to building larger shield generators rather than spamming a lot of small ones, but shield generators of any size will remain viable and shielded fighters or FACs will not be suicide booths like they are now. Shield scaling vs armor will be less extreme as well (i.e. closer to a flat line than a steep sloped curve).
Additionally, to keep shields competitive with armor, the shield strength tech line should be changed to omit the 1.5 and 2.5 values, adding 20 and 25-point values to the end of the tech line. The result would look like this:
Alpha Shields: 1
Beta Shields: 2
Gamma Shields: 3
Delta Shields: 4
Epsilon Shields: 5
Theta Shields: 6
Xi Shields: 8
Omicron Shields: 10
Sigma Shields: 12
Tau Shields: 15
Psi Shields: 20
Omega Shields: 25
For all but the last 3 tech levels the relative efficiency of shields is less than 50% that of armor, so there is an interesting design decision at most tech levels. By the end of the tech line, relative shield efficiency versus armor caps out at 56% which is probably superior to armor but close enough that the choice is not nearly as forced.
Seems like shield capacitor vs shield generator should be separate tech.
Also on the topic of medals can all officers crewing the ship receive the medal when it's an automatic award for meeting a set criteria i.e. new system discovered or ships destroyed.
P.S. Can the Ship also receive medals either automatic awards or manual? would love to see a storied and long lived ship with a big rack of ribbons and citations.
*snip* Small shields are very bad currently, they are not great in linear rates either but at least usable to some degree.
Make player able to buy the output of civilian refinery ships like the civilian mines
If you set tankers to repeat this, you need to go in and modify the order list every time the civvies launch or decommission a harvester. You also don't get warnings when civilian harvesters are nearing capacity.Make player able to buy the output of civilian refinery ships like the civilian mines
I thought we already could do this? Just order tankers to transfer fuel from the civilian harvesters and the wealth is transferred automatically?
You also don't get warnings when civilian harvesters are nearing capacity.
You also don't get warnings when civilian harvesters are nearing capacity.
You actually do get such a warning (at least, I have), but new civ harvs launch with a full tank, and you'll never get a warning for it until you've taken the fuel out of it. I guess because it's never "nearing" capacity--it's already at capacity.
In that vein, it would be grand if all harvesters stopped working when their tanks are full.
Kinetic Weapon Ammo
-To give other weapons similar design depth to missiles Railguns and/or Gauss Cannon, or "just" limiting their ammo to give Energy weapons another advantage. Also giving Railguns more "character"/flavour.
Simple
Railguns and or Gauss Cannons have ammunition similar to missiles but no design is needed, they just require one of three preset gun magazines that provide a fixed amount of ammo.
Complex
Railguns and or Gauss Cannons have special munitions, either preset or designed ala missiles, that grant some kind of bonus to damage, accuracy etc.
Quote from: Warer link=topic=10640. msg160768#msg160768 date=1658784611Kinetic Weapon Ammo
-To give other weapons similar design depth to missiles Railguns and/or Gauss Cannon, or "just" limiting their ammo to give Energy weapons another advantage. Also giving Railguns more "character"/flavour.
Simple
Railguns and or Gauss Cannons have ammunition similar to missiles but no design is needed, they just require one of three preset gun magazines that provide a fixed amount of ammo.
Complex
Railguns and or Gauss Cannons have special munitions, either preset or designed ala missiles, that grant some kind of bonus to damage, accuracy etc.
I like the idea, but that's a lot of micro ;)
I occasionally entertain the idea of reworking armor so that beam weapons ablate armor while kinetic weapons penetrate armor, but this would be a significant rework so I doubt such a thing could ever happen in Aurora.
I looked around the forum but couldn't find anything on this already, so:
Allow hangar decks to be pre-built via industry. Currently can't be, but other comparable ship modules (i.e. not designed like Cryo transport, Diplomacy module, Cargo Shuttle Bay, etc) can be built. Also noticed that the various sizes of cargo bay can't be pre-built either. Wondering if that's intentional, or an oversight?
Would it be possible to give fighters (sub 500 tons) the ability to "land" in the form of significantly reduced signature when at a body? This would open up the ability to "hide" fighters on an asteroid or other body and ambush enemy naval forces, which would be AWESOME flavor-wise.
No idea how that'd work code-wise, and presumably there would need to be some way to toggle it where they can't shoot until they "take off" thereby giving up the signature reduction.
Speaking of wealth changes (as per the 2.0 changes list)...
Would it be possible to get a simple line graph that could show a history of our wealth over the last few years or so?
Similarly, would it be possible to get graphs of our mineral stockpile status on a selected planet? This one would be best served by being able to select the different minerals (or all of them), and the graph scaling to fit the data.
I ask for these because it is often somewhat challenging to see the change of minerals/wealth over time with just numbers.
A checkbox to prevent commander re-assignment for specific commanders
Mostly cause administrators assigned to my academies keeps getting reasigned.
Automatic assignment for Admin commands and ability to choose how its assigned and prioritized like colony administrators
Cause I a tired of micro managing it every time someone gets promoted or something.
A way to designate equal refuel from a designated tanker fleet.I second this. When you got a big fleet, I would rather have then all fueled to 10% than have one at 100% and the rest still empty
I.e battle fleet refueling from one tanker so that the first ships get 100% fuel and the last one only gets the remainder and is still only at 22%
Or tanker goes to refuel from harvesters and the first few have 0% while the last ones still have 90%+
Marvin would be great if I didn't have to save each time for it to update... This is why I suggest these things in Aurora itself. (also, your link doesn't work ;) I found it anyway, but thought you should know)Speaking of wealth changes (as per the 2.0 changes list)...
Would it be possible to get a simple line graph that could show a history of our wealth over the last few years or so?
Similarly, would it be possible to get graphs of our mineral stockpile status on a selected planet? This one would be best served by being able to select the different minerals (or all of them), and the graph scaling to fit the data.
I ask for these because it is often somewhat challenging to see the change of minerals/wealth over time with just numbers.
Allow me to introduce Marvin (http://"http://aurora2.pentarch.org/index.php?topic=12233.0").
Wouldn't it be best if a harvester is only ignored when all fuel tanks in the fleet are full?In that vein, it would be grand if all harvesters stopped working when their tanks are full.
That is already the case. Harvesters with full fuel tanks are ignored during the harvester mining phase.
We have a new suggestions thread for v2.0: http://aurora2.pentarch.org/index.php?topic=13020.0 (http://aurora2.pentarch.org/index.php?topic=13020.0)