Aurora 4x
C# Aurora => C# Mechanics => Topic started by: Steve Walmsley on April 24, 2021, 10:53:06 AM
-
Thread for discussion of changes announced for v2.0.0. Please do not post bug reports or unrelated suggestions in this thread.
-
Can dead/retired commanders be awarded posthumous medals?
-
Can dead/retired commanders be awarded posthumous medals?
In the description it says "They can also be awarded posthumous medals." :)
It's at the end of the second line.
-
I simultaneously look forward to and dread the awesome change that will make me want the next version too much to play the current one :P
-
Can dead/retired commanders be awarded posthumous medals?
In the description it says "They can also be awarded posthumous medals." :)
It's at the end of the second line.
I looked twice and still missed it, thanks.
-
Thank you very much for the dead/retired commanders feature Steve.
-
And now the next generation can have 10-minute retirement! Expend 200 tons of each mineral for glorious cyberification! Rejuvenation guaranteed!!!
Ye olde SpaceBattles would have loved that option...
Thanks, Steve!
-
Awesome! Really looking forward to the changes to retired and dead commanders! I have always wanted to give my commanders medals posthumously. You can imagine being some old Admiral who has been around since the start of your game, has a capital ship class named after them, a veteran of decades of campaigns against spoilers and NPRs alike. Responsible for writing half the tactical training manuals and two thirds of your doctrines. Finally you get some peace and quiet to grow tomatoes back home on Earth, or maybe you bought some land on one of those new colony planets that you helped to set up and protect. Just as you're getting ready for your second harvest, a bunch of uniformed officers show up asking for you to come back because this wormhole opened up and some new threat called Invaders came pouring out, hunting for ships to kill and planets to conquer. Earth needs their best Admiral to take charge once again!
-
Just being able to view dead commanders is a godsend, let alone being able to award them and restore them. I've lost count I've seen a death notice and wanted to look at their bio and personality quirks to include when describing events to others.
-
I agree! I think 1.14 should hit market right away so we could also fix the obfuscation problem with a recompile of the db.
Just a thought!
;D
-
I agree! I think 1.14 should hit market right away so we could also fix the obfuscation problem with a recompile of the db.
Just a thought!
;D
I think Steve should adhere to the 48 hour window and at the end of that window just push whatever fixes 1.14.0 has. That way we don't need to have multiple miniscule DB updates that'll frustrate ppl.
Otherwise I think it is a good idea to push a quick update so that the obfuscation doesn't show too much. Both from player perspective but also from maintaining the effectiveness of the obfuscation.
-
I was planning to test the commander changes in a new campaign before rolling them out - that is why I released v1.13. I've also started adding a new spoiler race based on the comments I made in the 'Pirates' thread, so I don't want to release that half-finished because that could lead to unpredictable bugs. The issues so far in v1.13 are minor. The two obfuscation issues only affect new v1.13 code and the game functioned fine without that for the last year, so I am no rush to push out v1.14 just yet.
-
I was planning to test the commander changes in a new campaign before rolling them out - that is why I released v1.13. I've also started adding a new spoiler race based on the comments I made in the 'Pirates' thread, so I don't want to release that half-finished because that could lead to unpredictable bugs. The issues so far in v1.13 are minor. The two obfuscation issues only affect new v1.13 code and the game functioned fine without that for the last year, so I am no rush to push out v1.14 just yet.
Oh I wasn't aware that there was already half-finished features in so thats fair enough. I had assumed that 1.14 was basically only the changes currently listed.
-
Oh I wasn't aware that there was already half-finished features in so thats fair enough. I had assumed that 1.14 was basically only the changes currently listed.
It's fine - no way you could be aware. I am just taking advantage of my current coding enthusiasm while it lasts :)
-
It is amazing to know that you are working on the race you were talking on the "pirates" thread. Nice feature!!
-
Oh I wasn't aware that there was already half-finished features in so thats fair enough. I had assumed that 1.14 was basically only the changes currently listed.
It's fine - no way you could be aware. I am just taking advantage of my current coding enthusiasm while it lasts :)
I've just read that comment regarding the pirates, I'm assuming that they'll have a toggle that can be switched much like the invaders but otherwise they sound like a really good idea not only from the smaller combat engagements and specialist ship designs (the armed freighter might have a use now) it might generate but also as a justification of the PPV mechanic, which always felt a bit odd to me.
I do wonder if these pirates will have proper ground forces, not to invade entire populated worlds but to take-over automated mining colonies / unguarded sensor outposts. This would also add a ground defense layer to the pirates as now you would want to design outpost garrisons to defend otherwise isolated colonies.
Moreover will they build their own sensor network? Whether that would be buoys or transported installations matters little though based on the comment I suppose that they wont be establishing populated colonies of their own.
-
Each retired or dead commander has a default status of (DNR)
Would it be possible for "Story Character" to have that DNR status off as default?
Also, would retired characters die after some time?
-
I was planning to test the commander changes in a new campaign before rolling them out - that is why I released v1.13. I've also started adding a new spoiler race based on the comments I made in the 'Pirates' thread, so I don't want to release that half-finished because that could lead to unpredictable bugs. The issues so far in v1.13 are minor. The two obfuscation issues only affect new v1.13 code and the game functioned fine without that for the last year, so I am no rush to push out v1.14 just yet.
How advanced will the pirates be? Too much and they become more than the annoyance/distraction they are meant to be but to little and they become an underwhelming threat you have to wonder how they get interdimensional portal tech in the first place.
-
I was planning to test the commander changes in a new campaign before rolling them out - that is why I released v1.13. I've also started adding a new spoiler race based on the comments I made in the 'Pirates' thread, so I don't want to release that half-finished because that could lead to unpredictable bugs. The issues so far in v1.13 are minor. The two obfuscation issues only affect new v1.13 code and the game functioned fine without that for the last year, so I am no rush to push out v1.14 just yet.
How advanced will the pirates be? Too much and they become more than the annoyance/distraction they are meant to be but to little and they become an underwhelming threat you have to wonder how they get interdimensional portal tech in the first place.
They will probably start around precursor level and advance in technology during the game. Unlike precursors they will have an 'off-map' industrial base for research, etc.. They will also 'build' ships (although in a different way to NPRs), rather than just be allocated ships, so you will slow them down by destroying ships and you may see the same ship appear on different raids. I don't want to give too much away though at this stage.
-
The new dead/retired mechanics got me thinking whether it'd be a good idea to implement wounded officers as well who have to rest on a planet for a while before being available for active duty as well as a way to 'call up' retired officers.
In order to make it so you don't need to track the ages of retired officers you might call up, It'd be nice if the game tracked their years of service with the navy rather than their actual ages. This would literally just be a name change, as by default Aurora generates officers starting from O4 and at age 21. 21 is really young to be an O4 but is about the right amount of time you'd expect someone of that ranks to have been in the navy.
Alternatively a racial 'minimum age' setting for RP purposes would be nice.
EDIT: Actually 20 years is still quite a long time in to be just an O4. Typically at that stage you are an O6.
-
In order to make it so you don't need to track the ages of retired officers you might call up, It'd be nice if the game tracked their years of service with the navy rather than their actual ages. This would literally just be a name change, as by default Aurora generates officers starting from O4 and at age 21. 21 is really young to be an O4 but is about the right amount of time you'd expect someone of that ranks to have been in the navy.
Alternatively a racial 'minimum age' setting for RP purposes would be nice.
Yes please.
-
This has been proposed in the past, multiple times, and hopefully, it'll be feasible at some point.
Ideally, we could have male names only, female names only, all names for each type of commander so that for RP purposes we could do every sort of society - maybe women can serve on ships but not on ground forces, or maybe women are scientists only, and so on. Then we should also be able to set the minimum age for service also per type of commander - maybe my species reach maturity at 150 instead of 21. This would also support custom commander systems, like people who have 12+ ranks as they model both officers and non-commissioned officers - as you could then have your navy commanders start as Ensigns at a young age but your administrators start as middle-aged middle-managers.
Even better if we could have entirely separate name themes for different commander types. Maybe my species is actually two different species living in symbiosis but tasks are separated - or maybe my United Earth Alliance draws administrators from Japan while military leaders come from Sweden.
All of this can be RP'd by the player, of course - in my current campaign I only use commander last names since Victorians would not send women into battle but I can't be bothered to change their first names for ten countries - but having them in the game would make things little easier.
-
I'd much rather have different name themes for different species in my empire.
Commanders would be nice, but are a distant 2nd for me.
I'd love a slider to determine the male to female percentage. I think the new XCOM has something like that.
-
I think the new XCOM has something like that.
Wait there's new XCOM?
-
Well, the 2012 XCOM (+XCOM2) is still the "new" XCOM, compared to the old 90s X-COM. For me at least.
-
Regarding the transfer fleet to aliens functionality, the impression I got is the list processed in the order presented. I'd personally suggest moving the weapon fire control a lot higher in the list.
It seems like mis-classifying a battleship that happens to have a survey sensor as a surveyor is a more egregious mistake than mis-classifying an armed surveyor as a battleship, if you get what I am saying.
-
Multiple suggestions
Please register your account so you can post normally and suggestions belong in this thread:
http://aurora2.pentarch.org/index.php?topic=10640.0 (http://aurora2.pentarch.org/index.php?topic=10640.0)
-
Fixed gender roles for specific officer types would let you RP a Vorin empire where the women do all the writing and men do all the fighting.
Although given that many officers and wives are assigned/employed in pairs I'd like the option to have two people assigned per position.
-
I was planning to test the commander changes in a new campaign before rolling them out - that is why I released v1.13. I've also started adding a new spoiler race based on the comments I made in the 'Pirates' thread, so I don't want to release that half-finished because that could lead to unpredictable bugs. The issues so far in v1.13 are minor. The two obfuscation issues only affect new v1.13 code and the game functioned fine without that for the last year, so I am no rush to push out v1.14 just yet.
How advanced will the pirates be? Too much and they become more than the annoyance/distraction they are meant to be but to little and they become an underwhelming threat you have to wonder how they get interdimensional portal tech in the first place.
They will probably start around precursor level and advance in technology during the game. Unlike precursors they will have an 'off-map' industrial base for research, etc.. They will also 'build' ships (although in a different way to NPRs), rather than just be allocated ships, so you will slow them down by destroying ships and you may see the same ship appear on different raids. I don't want to give too much away though at this stage.
I thought about my previous post a little more, and thought of a good lore explanation to explain why these hyper-advanced aliens who were able to setup an entire civilization in a parallel dimension they aren't native to have ships that aren't as advance as you'd think. The ships thy build are made to perform optimally in their parallel dimension and are nerfed draastically when they enter our dimension. Instead of 'teching up' the pirate designs improve simply by them fine-tunning the ships to work better in our dimension.
-
I was planning to test the commander changes in a new campaign before rolling them out - that is why I released v1.13. I've also started adding a new spoiler race based on the comments I made in the 'Pirates' thread, so I don't want to release that half-finished because that could lead to unpredictable bugs. The issues so far in v1.13 are minor. The two obfuscation issues only affect new v1.13 code and the game functioned fine without that for the last year, so I am no rush to push out v1.14 just yet.
How advanced will the pirates be? Too much and they become more than the annoyance/distraction they are meant to be but to little and they become an underwhelming threat you have to wonder how they get interdimensional portal tech in the first place.
They will probably start around precursor level and advance in technology during the game. Unlike precursors they will have an 'off-map' industrial base for research, etc.. They will also 'build' ships (although in a different way to NPRs), rather than just be allocated ships, so you will slow them down by destroying ships and you may see the same ship appear on different raids. I don't want to give too much away though at this stage.
I thought about my previous post a little more, and thought of a good lore explanation to explain why these hyper-advanced aliens who were able to setup an entire civilization in a parallel dimension they aren't native to have ships that aren't as advance as you'd think. The ships thy build are made to perform optimally in their parallel dimension and are nerfed draastically when they enter our dimension. Instead of 'teching up' the pirate designs improve simply by them fine-tunning the ships to work better in our dimension.
My personal take on this (also the combine in half life) is not that they are actually using unmodified equipment, its that they are awkwardly trying to adapt their stuff to the local dimension, and haven't really figured it out all the way yet. So in effect they are partly back to square 1 as far as tech goes, the local dimension is similar to but not identical to their own.
-
Damn, 1.14 has already so many critical fixes listed that Im, again, hesitant to start new game till next patch. Was hoping to have 1.13 going though.
Steve, do you plan to release it soon? Those fixes seems like important.
-
Damn, 1.14 has already so many critical fixes listed that Im, again, hesitant to start new game till next patch. Was hoping to have 1.13 going though.
Steve, do you plan to release it soon? Those fixes seems like important.
There aren't any major bugs that prevent the game being played, so I am in no rush at the moment. I have started work on a new spoiler race so I need to finish that and then run a test campaign, plus I have a few holidays booked.
-
Wouldn't it be possible to just release those fixes alone as 1.13.1 or something? Since they're already coded and stuff. This obfuscation everywhere looks ugly so while not game breaking is rather impactful I'd say.
-
Wouldn't it be possible to just release those fixes alone as 1.13.1 or something? Since they're already coded and stuff. This obfuscation everywhere looks ugly so while not game breaking is rather impactful I'd say.
There is no 1.13.1 as the database is already updated. I don't keep a detailed change log of what was modified for each change or bug fix.
The two obfuscation bugs are in non-essential areas that were only introduced in v1.13, so v1.12 worked fine without them.
-
Damn, 1.14 has already so many critical fixes listed that Im, again, hesitant to start new game till next patch. Was hoping to have 1.13 going though.
Steve, do you plan to release it soon? Those fixes seems like important.
Every patch is essential. One thing I've learned is that if you pass from 1.10 to 1.12 for instance, you have so many changes to assimilate that almost "ruin" the experience. My advice is at least to play 1 small campaign a 1 big campaign per iteration to help yourself with the transition.
So far my biggest campaigns were made on 1.10 and 1.12 and they are totally different experiences because 1.10 was the first stable release after so many bug fixes and qol improvements, also the new NPR designs and threats kept me hooked for a while. 1.12 on the other hand, changed the terraforming and the parasites along with formations, automated exploration, and a new AI mechanic.
-
automated exploration,
Yeah, guess ill just go on with 1.13
But what you mean by automated exploration? wonder if I missed something.
-
automated exploration,
Yeah, guess ill just go on with 1.13
But what you mean by automated exploration? wonder if I missed something.
there are a set of rules and orders that allow you to send ships on permanent exploration tasks without the need of you to micromanaging it if you that kind of person at least. In the beginning, for me, it's not that handy as I usually proceed carefully and I pick my jumps. Later when you are with 100+ systems and you need to look after 30+ jumps at 10 or more systems away from Sol it does really help. I call them exploration eras. Sometimes I just do 1 year or more years of wild exploration while doing other stuff before calling the eagles back in and only then look at the findings.
-
On the tactical map left-hand display panel there is a checkbox called "No child/parent overlaps".
What do?
-
I have a minor issue with the removal of the tokamak, its too cool to remove, could it come back to replace the generic 'magnetic confinement reactor' used for magnetic confinement drives ?
Afterall it is a magnetic confinement reactor itself, and even the previous stellarator is also a magnetic confinement reactor,. It might introduce some confusion to people familiar with previous tech levels though. In fact maybe some of the other generic reactor types could be renamed.
Improved Pressurized water reactor - Pressurized Heavy water Reactor
Improved Nuclear Thermal Engine - Liquid Core Nuclear thermal engine
Improved Pebble bed - Molten Salt Cooled Pebble Bed
Improved Nuclear Pulse Engine - Liquid Metal Core Nuclear Pulse Engine
-
Improved Pressurized water reactor - Pressurized Heavy water Reactor
Pressurized Deuterium Reactor sounds cooler and pretty much means the same thing IIRC
-
Improved Pressurized water reactor - Pressurized Heavy water Reactor
Pressurized Deuterium Reactor sounds cooler and pretty much means the same thing IIRC
Yep. All these were taken from the wiki page for those reactor techs with merely a few minutes of skimming so there could be slightly better terminology, but its better than just 'improved'
-
With the new GU scrapping capability it seems like we're only a couple of automation steps away from being able to implement upgrading of GU formations, which is excellent progress.
-
we're only a couple of automation steps away from...
Said every software development manager ever. :)
-
I agree that tokamak is a rather interesting name and should probably supersede something rather than going away.
-
I am very happy to see Steve add that 100 ton wiggle room for not auto-adding a bridge when you go over 1,000 tons; it's always been a pain in my rear end when designing FACs (I like FACs so I use them a lot.)
Not so thrilled about the crew training change, however. Chucking a fleet into a training admin command was simple, straightforward and easy. Now I'll have to micromanage swapping out commanders for smaller ships without an auxiliary control for an XO? No thanks. And inexperienced fleet fire delay penalties are bad enough to make this matter. Maybe the new fire at will option will mitigate that? Iunno. I might just play with experience penalties turned off, instead. Guess we'll see.
-
I am very happy to see Steve add that 100 ton wiggle room for not auto-adding a bridge when you go over 1,000 tons; it's always been a pain in my rear end when designing FACs (I like FACs so I use them a lot.)
Not so thrilled about the crew training change, however. Chucking a fleet into a training admin command was simple, straightforward and easy. Now I'll have to micromanage swapping out commanders for smaller ships without an auxiliary control for an XO? No thanks. And inexperienced fleet fire delay penalties are bad enough to make this matter. Maybe the new fire at will option will mitigate that? Iunno. I might just play with experience penalties turned off, instead. Guess we'll see.
The crew grade and fleet training rules haven't changed. The only change was changing the crew training bonus from numeric to percentage.
-
The crew grade and fleet training rules haven't changed. The only change was changing the crew training bonus from numeric to percentage.
Oh, thank God. I misread your post. I very much like the admin command approach to training!
-
For v1.14, as soon as a freighter accepts the contract for a given installation, even if it is in a different system to the pickup point, the supply and demand amounts for the start and destination populations are adjusted accordingly. This makes it much easier to see if the contracts are being met, even though the involved ships may still be underway, and eliminates the potential for oversupply.
I think this is already the case...at least, I have observed it to be the case when the freighter is in the same system as the supply site. (I haven't tested for inter-system effects.)
The problem I have observed is that when a freighter finishes loading at the supply site, the Assigned amount on the demand contract decreases by 1.
As a result, if additional supply is available (either currently, or becomes available before this freighter finishes this delivery), another available freighter will be assigned to this same demand unit.
I don't think the Assigned amount on the delivery contract should decrement until the freighter completes the delivery.
-
For v1.14, as soon as a freighter accepts the contract for a given installation, even if it is in a different system to the pickup point, the supply and demand amounts for the start and destination populations are adjusted accordingly. This makes it much easier to see if the contracts are being met, even though the involved ships may still be underway, and eliminates the potential for oversupply.
I think this is already the case...at least, I have observed it to be the case when the freighter is in the same system as the supply site. (I haven't tested for inter-system effects.)
The problem I have observed is that when a freighter finishes loading at the supply site, the Assigned amount on the demand contract decreases by 1.
As a result, if additional supply is available (either currently, or becomes available before this freighter finishes this delivery), another available freighter will be assigned to this same demand unit.
I don't think the Assigned amount on the delivery contract should decrement until the freighter completes the delivery.
The decrement of the demand and supply amounts were handled within the load and unload movement orders. I've deleted that code now. The assignment of contracts also took into account existing orders for both the supply and demand populations. That code is also gone now because as soon as a freighter accepts the contract, the supply and demand amounts at the respective populations are reduced by the capacity of that freighter. The process is now much simpler and therefore less prone to bugs.
-
Adding the "pirates" sounds fun. This makes the planetary protection value actually valuable. They do not have to be strong at all. A gun and some boarding troops would be just fine and would require in system security forces.
I guess I will wait for 1.14 and not play 1.13 ;)
-
Might want to rethink that Kilo. It was several months before we got 1.13.
-
The downside is that a contract might be accepted and then the civilian freighter lost to enemy action. The player would need to adjust the supply and demand in that situation. In v1.14, the cargo on destroyed ships will be listed in the destruction event.
Can you re-add the demand to the destination in case of destruction?
-
I really love the pirate mechanic... seems really thematic and fun. The game really needed a reason for rear area patrol forces to exist and this is a perfect mechanic for that.
-
The downside is that a contract might be accepted and then the civilian freighter lost to enemy action. The player would need to adjust the supply and demand in that situation. In v1.14, the cargo on destroyed ships will be listed in the destruction event.
Can you re-add the demand to the destination in case of destruction?
Yes, I should have thought of that myself. All the information to do that is already available. I'll update the post accordingly.
-
The downside is that a contract might be accepted and then the civilian freighter lost to enemy action. The player would need to adjust the supply and demand in that situation. In v1.14, the cargo on destroyed ships will be listed in the destruction event.
Can you re-add the demand to the destination in case of destruction?
Yes, I should have thought of that myself. All the information to do that is already available. I'll update the post accordingly.
While you are at the civilian contract code... would it be possible to make it so I can put a high demand at some place and the supply on another without the game complaining if there is no physical building to pick up... the ship assigned to the demand should just go there and wait... you could add in that a message appear if a specific time goes and no item appear for them to pick up.
The reason being that sometimes you just want 100 mines to a colony and you don't want to calculate how long it will take another colony to make them and just set up the supply/demand and leave it, it will eventually be fulfilled. And if you do it improperly such as setting the supply of some colony that don't build any mines an even will eventually pop up saying there are no supply available and the supply order will be cancelled.
Or something like it... this would help immensely with automation orders and I would not have to babysit my supply/demand orders so closely.
-
I really love the pirate mechanic... seems really thematic and fun. The game really needed a reason for rear area patrol forces to exist and this is a perfect mechanic for that.
It's a good middle point between none and full sized enemy invasion once they find a hidden JP in your home system.
-
Since pirates are being added as an incentive to protect colonies, will tge unrest from lack of protection be scrapped as redundant?
-
Since pirates are being added as an incentive to protect colonies, will tge unrest from lack of protection be scrapped as redundant?
I think with pirates running around, the colonists are even more likely to be upset if you don't leave any forces to protect them :)
Also, the pirates are optional so would not replace PPV in all games anyway.
-
Cargo Handling Modifier = Number of Cargo Shuttle Bays * Admin Command Bonus * Commander Logistics Bonus * Race Cargo Shuttle Load Modifier
Double checking: are the bonuses for Planetary and Sector governors calculated as part of the Admin Command Bonus?
-
Cargo Handling Modifier = Number of Cargo Shuttle Bays * Admin Command Bonus * Commander Logistics Bonus * Race Cargo Shuttle Load Modifier
Double checking: are the bonuses for Planetary and Sector governors calculated as part of the Admin Command Bonus?
No, its just the admin commanders.
-
Cargo Handling Modifier = Number of Cargo Shuttle Bays * Admin Command Bonus * Commander Logistics Bonus * Race Cargo Shuttle Load Modifier
Double checking: are the bonuses for Planetary and Sector governors calculated as part of the Admin Command Bonus?
No, its just the admin commanders.
Does the Logistics bonus for governors not do anything?
-
Does the Logistics bonus for governors not do anything?
Currently something of an anachronism held over from VB6. It used to be more important when spaceports could stack. I suppose one option would be to multiply the cargo handling modifier by the planetary/sector bonuses if there was a suitable installation on the planet.
-
Does the Logistics bonus for governors not do anything?
Currently something of an anachronism held over from VB6. It used to be more important when spaceports could stack. I suppose one option would be to multiply the cargo handling modifier by the planetary/sector bonuses if there was a suitable installation on the planet.
To be fair: most of the time, logistics bonuses (commanders, admins, or governors) don't provide much value. With careful stacking of bonuses I can cut a few days off of each end of a trip. But trips are usually 100+ days long anyway. Getting a 6% or less bump to throughput rate doesn't really move the needle on my economic growth.
And since a fleet of multiple ships loads at the rate of the slowest ship in the fleet, logistics bonuses on ship commanders matter almost not at all.
But managing logistics-related personnel is still fun for flavor.
It's fun to drop a logistics-expert governor on a fresh colony and imagine them tightly overseeing the unloading of the first wave or two of supply fleets as the colony gets boots on the ground, and then making way for a governor who has more ability to actually produce things.
Why not just make the planet/sector governor bonuses just additional multipliers on the formula? I'd say even regardless of the presence of suitable installations. It's really not something a min/maxer can abuse to much effect.
-
If a civilian freighter is lost to enemy action while carrying an installation, the amount lost will be added back to the demand of the destination population.
What about the case where the freighter is lost before it loads the installation?
-
If a civilian freighter is lost to enemy action while carrying an installation, the amount lost will be added back to the demand of the destination population.
What about the case where the freighter is lost before it loads the installation?
This is a good edge-case since the post implies that what would happen in this case would be:
1 - Freighter assigns itself to the transport -x installation from demand
2 - Freighter is destroyed without cargo +0 of installation is added
This means that the demand would be x lower than what it should be, which results in underfilling in this specific case.
-
If a civilian freighter is lost to enemy action while carrying an installation, the amount lost will be added back to the demand of the destination population.
What about the case where the freighter is lost before it loads the installation?
This is a good edge-case since the post implies that what would happen in this case would be:
1 - Freighter assigns itself to the transport -x installation from demand
2 - Freighter is destroyed without cargo +0 of installation is added
This means that the demand would be x lower than what it should be, which results in underfilling in this specific case.
It also means supply gets lowered and never "replenished" despite not being taken.
-
Have a question about new feature with Minimum [Squadron] Jump Engine Size
(http://aurora2.pentarch.org/index.php?topic=12523.msg151588#msg151588)
All jump drives, regardless of size, can perform a standard transit for any number of ships with the matching engine type.
Am I understand this line correctly, that any (even fighter-size) jump tender with minimal size jump drive will have an ability to open tunnels for any (even million-tonnes) ship, if only she have the same engine type and it will be standard transit?
-
Have a question about new feature with Minimum [Squadron] Jump Engine Size
(http://aurora2.pentarch.org/index.php?topic=12523.msg151588#msg151588)
All jump drives, regardless of size, can perform a standard transit for any number of ships with the matching engine type.
Am I understand this line correctly, that any (even fighter-size) jump tender with minimal size jump drive will have an ability to open tunnels for any (even million-tonnes) ship, if only she have the same engine type and it will be standard transit?
If this was true, it would make JP transit a lot easier and every ship could carry some small emergency jump drive, allowing it to transfer between systems. I have seen AI fleets getting stuck after going through a jump gate of mine into my system without having the ability to go home. This would be kind of nice I guess.
I am pretty sure this is not true though. Why would you ever build a large civilian jump drive in that case? Civilian vessels do not care about jump shock and therefore would carry the smalles jump drive possible at all times. Hell even military vessels could do this. All they needed is a scout checking the other side of the gate.
-
Have a question about new feature with Minimum [Squadron] Jump Engine Size
(http://aurora2.pentarch.org/index.php?topic=12523.msg151588#msg151588)
All jump drives, regardless of size, can perform a standard transit for any number of ships with the matching engine type.
Am I understand this line correctly, that any (even fighter-size) jump tender with minimal size jump drive will have an ability to open tunnels for any (even million-tonnes) ship, if only she have the same engine type and it will be standard transit?
I was referring to the physical size of the jump drive. The max size that can be jumped will still apply. I've updated the text to make this clearer.
-
If a civilian freighter is lost to enemy action while carrying an installation, the amount lost will be added back to the demand of the destination population.
What about the case where the freighter is lost before it loads the installation?
Yes, I knew about this last night but was too tired to add it. So I went to bed wondering if anyone would notice. Of course someone noticed - its Aurora :)
Anyway, its been added now. If a civilian freighter is lost to enemy action before loading an installation, the amount lost will be added back to the supply of the pickup population and to the demand of the destination population.
-
Does the Logistics bonus for governors not do anything?
Currently something of an anachronism held over from VB6. It used to be more important when spaceports could stack. I suppose one option would be to multiply the cargo handling modifier by the planetary/sector bonuses if there was a suitable installation on the planet.
To be fair: most of the time, logistics bonuses (commanders, admins, or governors) don't provide much value. With careful stacking of bonuses I can cut a few days off of each end of a trip. But trips are usually 100+ days long anyway. Getting a 6% or less bump to throughput rate doesn't really move the needle on my economic growth.
And since a fleet of multiple ships loads at the rate of the slowest ship in the fleet, logistics bonuses on ship commanders matter almost not at all.
But managing logistics-related personnel is still fun for flavor.
It's fun to drop a logistics-expert governor on a fresh colony and imagine them tightly overseeing the unloading of the first wave or two of supply fleets as the colony gets boots on the ground, and then making way for a governor who has more ability to actually produce things.
Why not just make the planet/sector governor bonuses just additional multipliers on the formula? I'd say even regardless of the presence of suitable installations. It's really not something a min/maxer can abuse to much effect.
Yes, good idea. I've implemented that for v1.14
http://aurora2.pentarch.org/index.php?topic=12523.msg151607#msg151607
-
I was thinking a bit more of the civilian contract and the supply and demand of installations or components.
Would it be impossible to make it so that if a colony produce any specific installation/component we can tell the colony to automatically add it to the supply of items for civilian contracts.
If we could do this it would really simplify some automation of how you use civilian contracts... I could just tell my colony to automatically offer all Automines to be added to the supply of Automines. Then the civilians will automatically pick them up and move them to wherever you have put a demand for Automines.
This probably would not require a lot of code to be written and it would immensely help with automation of moving installations using the civilians without complicating things or being prone to bugs. Just a simple flag for any production item if it should be automatically added to "supply" or not.
-
I was also thinking about the new pirates and using automatic patrols in your own space.
It would be good if we could have a ship "programmed" to patrol a specific route and then using the automatic "Refuel, Resupply & Overhaul" order and once it has done this it will again continue with its programmed patrol order.
Basically a ship that is on a repeating cycle of order who use the "Resupply, Refuel and Overhaul" order will continue its cycled orders after the overhauls is done. It would require the game to add an automatic order to both return home and back to the last ordered end point and then add the cycled order back to the ship.
We could also require this cycled order to be a saved order or something as well if that makes things simpler.
This would help us set up patrol orders with more "normal" ships... I could still have my patrol ships at 3-6 months as they will regularly overhaul and rest the crew as necessary automatically and then resume their duties. Otherwise I have to build my ships with unnaturally long overhaul and crew times just so I don't get worn out from having to reassign them their patrol orders after each overhaul is done.
Another idea would be an automatic patrol order that you can issue to a ship in a system. The ship will automatically (sort of randomly) patrol between colonies, orbital mining sites, stations or fuel harvesting sites... they could even escort civilian ships randomly as well. Then when they meet their crew time limit they return to port for refuel and overhaul like any other normal ship and then resume their patrol work afterward. You just have to make sure there is an overhaul point in the same system or they will return to a different system and then patrol from there.
-
I was also thinking about the new pirates and using automatic patrols in your own space.
It would be good if we could have a ship "programmed" to patrol a specific route and then using the automatic "Refuel, Resupply & Overhaul" order and once it has done this it will again continue with its programmed patrol order.
Basically a ship that is on a repeating cycle of order who use the "Resupply, Refuel and Overhaul" order will continue its cycled orders after the overhauls is done. It would require the game to add an automatic order to both return home and back to the last ordered end point and then add the cycled order back to the ship.
We could also require this cycled order to be a saved order or something as well if that makes things simpler.
This would help us set up patrol orders with more "normal" ships... I could still have my patrol ships at 3-6 months as they will regularly overhaul and rest the crew as necessary automatically and then resume their duties. Otherwise I have to build my ships with unnaturally long overhaul and crew times just so I don't get worn out from having to reassign them their patrol orders after each overhaul is done.
Another idea would be an automatic patrol order that you can issue to a ship in a system. The ship will automatically (sort of randomly) patrol between colonies, orbital mining sites, stations or fuel harvesting sites... they could even escort civilian ships randomly as well. Then when they meet their crew time limit they return to port for refuel and overhaul like any other normal ship and then resume their patrol work afterward. You just have to make sure there is an overhaul point in the same system or they will return to a different system and then patrol from there.
The only missing step of the automation at present is that you cannot cycle the order when an overhaul is involved, so really this boils down to changing the order rules so that a ship can go into overhaul and resume following orders when it is done, which I think most players would like to have in general. I can't foresee too many problems with allowing this, and it is probably easier than implementing a new "patrol area" standing order.
-
I was also thinking about the new pirates and using automatic patrols in your own space.
It would be good if we could have a ship "programmed" to patrol a specific route and then using the automatic "Refuel, Resupply & Overhaul" order and once it has done this it will again continue with its programmed patrol order.
Basically a ship that is on a repeating cycle of order who use the "Resupply, Refuel and Overhaul" order will continue its cycled orders after the overhauls is done. It would require the game to add an automatic order to both return home and back to the last ordered end point and then add the cycled order back to the ship.
We could also require this cycled order to be a saved order or something as well if that makes things simpler.
This would help us set up patrol orders with more "normal" ships... I could still have my patrol ships at 3-6 months as they will regularly overhaul and rest the crew as necessary automatically and then resume their duties. Otherwise I have to build my ships with unnaturally long overhaul and crew times just so I don't get worn out from having to reassign them their patrol orders after each overhaul is done.
Another idea would be an automatic patrol order that you can issue to a ship in a system. The ship will automatically (sort of randomly) patrol between colonies, orbital mining sites, stations or fuel harvesting sites... they could even escort civilian ships randomly as well. Then when they meet their crew time limit they return to port for refuel and overhaul like any other normal ship and then resume their patrol work afterward. You just have to make sure there is an overhaul point in the same system or they will return to a different system and then patrol from there.
The only missing step of the automation at present is that you cannot cycle the order when an overhaul is involved, so really this boils down to changing the order rules so that a ship can go into overhaul and resume following orders when it is done, which I think most players would like to have in general. I can't foresee too many problems with allowing this, and it is probably easier than implementing a new "patrol area" standing order.
This in combination with speed settings and order delays would allow players to create comprehensive patrol patterns without having to repeatedly check on their patrols. Which for large systems with spread out JPs could become very numerous.
-
Yes I agree... being able to chain overhaul orders in with any regularly cycled order would be really nice.
I still like the idea of setting up a patrol and having the ship go and do "Refuel, Resupply & Overhaul" and then resume their cycled order from their last point. This would make things the most simple for players in general as you don't have to sit and count roughly when a ship need to do overhaul during a cycled order chain.
I do hope we can get some automation in regard to patrol orders... I think we could need them for both parasites and regular ships. A ship that dock with hangar should also be able to automate patrol order in the same way in my opinion. This would make it easier to have patrols stay on station around a carrier without you having to worry when it needs to go back and rest, refuel or whatever... it will just return to patrol when it is done automatically.
** edit **
I missed that Steve already added this mechanic to next version... great news... :)
-
Yes, I can finally do a few run with military only ships without going nuts!
Setting up tanker and freighter cycles was too hard after a while as too much micromanagement. I guess, problem solved!
-
Added Super-Heavy Bombardment ground component.
"I'm about to drop the hammer...
...and dispense some indiscriminate justice!"
-
Alien Artefacts are back 8) Which means more wealth for the shipping lines and more tax income for us!
-
So unlike other trade goods alien artefacts will eventually run out once the ruin in question is fully exploited, correct?
-
So unlike other trade goods alien artefacts will eventually run out once the ruin in question is fully exploited, correct?
Looks like it, so the supply is sustained by finding new worlds with ruins to exploit. As long as the tax income from artifacts is lucrative this is another impetus for exploration and exploitation, so I approve.
-
So unlike other trade goods alien artefacts will eventually run out once the ruin in question is fully exploited, correct?
Yes, correct. At first I was going to have them generated by populations, but it didn't seem reasonable for a small ruin to generate artifacts for decades. I also considered generating a large, one-off amount of artifacts when the ruins were first discovered or surveyed, but there are complications with multiple races on the same planet. Having them as part of the ruin recovery process solves both those problems.
-
So since the only benefit of the alien artifact trade good is taxation off of trade, isn't it basically the same as just unearthing wealth during excavation?
-
So since the only benefit of the alien artifact trade good is taxation off of trade, isn't it basically the same as just unearthing wealth during excavation?
Basically the same, yeah.
Wealth is an instant specific amount.
The trade income will take place over time and the amount will vary by distance shipped.
-
Basically the same, yeah.
Wealth is an instant specific amount.
The trade income will take place over time and the amount will vary by distance shipped.
Would love it if this did something a little different, maybe the artifacts could be spent as a resource type instead and used to build "Museums" which function like Academies except the only produce Scientists and on average produce better ones.
-
So since the only benefit of the alien artifact trade good is taxation off of trade, isn't it basically the same as just unearthing wealth during excavation?
And not very significant amount of wealth.
-
Weren't alien artifacts a thing already? I never actually saw them tho even tho I was exploiting alien ruins which I thought was pretty strange. Where else would they come from?
-
It was broken in VB Aurora 7.1 and it's still broken in all versions of C# Aurora we can play.
There must be only one source - ruins.
-
In regards to the civilian contracts, you say that if a freighter is lost to enemy action, that the supply and, or the demand will be added back to the colony. What happens if the freighter is simply scrapped due to a newer version?
-
In regards to the civilian contracts, you say that if a freighter is lost to enemy action, that the supply and, or the demand will be added back to the colony. What happens if the freighter is simply scrapped due to a newer version?
You know, it never occured to me that civvies would scrap a ship carrying a payload of any kind. If they do (and I don't know if they do), that's kind of a wider issue.
"Hey, when are those colonists scheduled to arrive at Mars?"
"Let me check the records... hm."
-
In regards to the civilian contracts, you say that if a freighter is lost to enemy action, that the supply and, or the demand will be added back to the colony. What happens if the freighter is simply scrapped due to a newer version?
You know, it never occured to me that civvies would scrap a ship carrying a payload of any kind. If they do (and I don't know if they do), that's kind of a wider issue.
"Hey, when are those colonists scheduled to arrive at Mars?"
"Let me check the records... hm."
They will be arriving ballistically in 3 weeks.
-
In regards to the civilian contracts, you say that if a freighter is lost to enemy action, that the supply and, or the demand will be added back to the colony. What happens if the freighter is simply scrapped due to a newer version?
Only empty ships without orders are scrapped.
-
Trade with aliens could be made into another source of alien artifacts now that we have them.
-
Trade with aliens could be made into another source of alien artifacts now that we have them.
I agree this is why I think I will keep using my mod for alien artifacts. But the fact that now they work is good news though.
There is an unanswered question more related to the DB. Is the function RARE working?
Thanks
-
The changes to Collateral Damage are the best thing ever. Thanks Steve :)
-
In regards to scrapping installations, would this apply to Forced Labor camps?
If so, is there any way to add the recovery of the population? Even partial recovery?
I know it could be hard because you need to add restrictions due to the population used originally (but I would tie this to the main race pop scrapping it eventually) and the planet Population Cap (but you could zero out if the cap is reached I guess).
-
not sure if this was asked already but might be cool if one day the genetic tech line would allow us to restore commanders from dead mechanically.
-
On the most recent item added to the changes list on topic of "if you lose a contact type, say thermal, of a ship you are moving to. The game will check if there's another contact type for the same ship, say EM. And follow that."
I'm on my phone and at work so I can't check if there is 1 ingame, and off the top of my head... I can't remember if there is or not.
In the intel menu for contacts, is there a "last known position/speed/vector" in there?
-
Not in the intel menu, which I think just shows the last known system for each contact, but in the tactical map you can go to the Contacts tab and show lost contacts from a specified duration ago, e.g. "Lost Contacts 1 month" will show last known positions for contacts lost within the last month.
-
Being able to set escorts that can follow ships through jump points would be great and I assume much needed for protecting freighters without a mass of micro management
-
Being able to set escorts that can follow ships through jump points would be great and I assume much needed for protecting freighters without a mass of micro management
I've been including the warship(s) in the freighter fleet, but I agree that escorts following through a jump point would be a good idea.
-
I usually just use subfleeting, placing the escorts into a subfleet, however this does not work very well if you have an escort fleet that has it's own subfleet(s) (like for example a ship that carries fighters).
-
In a separate post, http://aurora2.pentarch.org/index.php?topic=12591.msg152859#msg152859 (http://aurora2.pentarch.org/index.php?topic=12591.msg152859#msg152859), Steve has said (in spoilers) something *extremely* important about Raiders that was not documented in any post in the 1.14 thread.
The core of this post is in spoilers.
Raiders start the game with Precursor-level technology. This makes them extraordinarily dangerous, perhaps even unmatchable, for conventional and early-TN empires (unless these have extra-large fleets, preferably designed by a player with abundant starting tech points). This undocumented design decision greatly reduces the sort of starting empires likely to have a successful game, and players will only discover this by losing games to raiders and even invaders that move too fast and kill too quickly to be beaten off. Turtling on your home world (potentially system, if you have a big enough fleet to dissuade attack), possibly for many decades, might be the only option if you are fool enough to check the "Raiders" game start option.
Imagine starting the game with pre-TN tech and checking this box. Imagine starting with game default starting pop and matching installations and ships. Imagine reducing tech gain to 10-25% of normal, as is becoming popular. Imagine not wanting to start the game with a huge fleet, or just figuring you can do some light mining or colonization in Alpha Centauri with level 2-3-4 techs. With raiders that move at something like 6 or perhaps even 10k+ km/s, field great ECM, invade with precursor-level troops, and *can appear in any insufficiently well-defended system at any time*, you might just be sunk.
And imagine what life is going to be like for the NPRs if the "don't appear in NPR-claimed systems" box is not carefully checked! NPRs already have serious problems with resource-acquisition and developing new colonies, which too often cripple them as the game progresses. Therefore, even as the early game might become more difficult for the player, the late game might become a story of curb-stomping one-planet, resource-less, fleet-less NPRs, the Raiders enforcing an effective blockade. Or even - depending on exactly how loot-rich, well-developed Raiders define "insufficiently well-defended colony" - of merely discovering empty homeworlds from which entire NPR races have been carried off as slaves.
I hope this post acts as either
a) a wake-up call for players that will hopefully save many hours of game set-up time, or
b) a call for a more flexible [starting strength] for Raiders that permits weaker starting empires to have challenging, but successful games.
-
I do share some concern that new players will be curb stomped by this new addition due to how the tech difference can mean a single 10k ship that need no MSP can technically kill every single thing an unprepared/unspoiled player have. A simple solution would be to simply leave the option deactivated by default which I suspect will be the case.
I would love for NPR/spoilers to also be constrained by logistics/MSP someday however to avoid the kind of situation where a single ship might entirely cripple an entire empire.
-
I very much like the idea of Raiders and I hope they can be made workable, but I agree that from what we've seen of them so far there are significant issues:
One issue, as pointed out above, is that they are currently extremely strong (at least in the early game -- we know their technology advances over time but not how quickly). Extremely challenging spoilers are nothing new to Aurora, so this in and of itself would not be too bad (although the fact that they can show up anywhere with no warning will have a huge impact on gameplay). But the second issue I see with Raiders is that they cannot be permanently destroyed. There is no long-term goal to work towards, no light at the end of the tunnel, only a long slog as you try to overtake their initial technological advantage while struggling to survive and expand. I think this would be fine if it were only a matter of some small-scale piracy that you have to live with and can't permanently stop; it's really the combination of their difficulty level with the lack of an end goal that I expect will make them uniquely frustrating to play with.
I think the Raiders would be better if they were either strong but with some way of stopping them, or relatively weak (i.e. on roughly the same technological level as the player) while remaining a persistent threat throughout the whole game -- but not both strong and persistent. The first niche is more or less filled by the Invaders already; the second I feel would make a great addition to the game once properly balanced.
Of course I've greatly enjoyed Aurora without Raiders for years and I expect to continue to do so even if I end up turning them off most of the time. :) But I feel that Raiders have a lot of potential if they can be balanced properly.
-
Yeah the last post from Steve's campaign was quite a surprise. I put the rest of the post in spoiler tag:
I was planing some patrol ships with dual-purpose weapons or mix of smaller lasers and gauss cannons, with commercial engines to have endurance to accompany my commercial fleets. But in my current game only my battlecruisers and some heavy cruisers would be able to engage the Raiders and none of my warships have enough speed to catch them (5485km/s for my warships with Magneto-plasma tech).
I roleplay quite a bit and I cannot imagine that I would be able to roleplay the creation of a design that would be able to successfully repel Raider attack from the start of the game. I can imagine to deploy my destroyers or light cruisers to protect important convoys, but they would get slaughtered by single Raider frigate.
We will see how often the Raiders appear in Steve's campaign, maybe they will not be that common, hard to say if I decide to turn them off at the end...
-
From what I understand the corsair is a bit of a glass cannon, insanely well armed but 3 armor. If you can design a missile with 10-16 warhead you'll basically wipe the floor with them.
Idk if they have some sort of missile variant which could cause problems but the fact that they operate in singles kind of makes it easy to overwhelm them with missiles.
I would definitely not want to engage them with beam ships though (maybe reduced 20cm railgun fighters?) which is annoying cuz it's yet another example of beam ships being sub-par to their missile counterparts.
I suppose particle beams/lances would be the beam weapon of choice if you wanted to fight them with beams though.
-
From what I understand the corsair is a bit of a glass cannon, insanely well armed but 3 armor. If you can design a missile with 10-16 warhead you'll basically wipe the floor with them.
Depends on if they field precursor-level AAMs, or decent CIWS, or just a fast-tracking BFC plus turreted railguns. Any of these could wipe out low-tech missile salvos. Can't beam it, might not be able to missile it ... maybe can't do anything but kiss your ass goodbye?
-
There seems to be some concerns about the Raiders :) Here is more information in spoiler tags.
While they can be a local problem, they are limited in number and do not pose an existential threat to an Empire. The Imperium is struggling at the moment, because they are not geared up to fight this particular enemy and the raiders have been lucky enough to find a meaningful target. I am already taking steps to correct the lack of options to combat the Eldar. The Eldar don't have missiles, so you don't need a lot of range. You need high speed and perhaps Agility or ECCM on the missiles. For beams only, you probably need fast attack craft.
I currently have fast-short-ranged missiles, fast attack craft and Electronic warfare in development.
While the Eldar can cause some havoc in a given system, they can't use jump points. If the system isn't critical, you can ignore them and they will get bored and leave. They are raiders and are looking for something to raid. They also aren't looking to fight warships, unless they can assemble a reasonable force, and will generally run away from threats. They may have 1 or possibly 2 larger raiding groups such as the one in Damocles, but they can only be in one place at once, and that includes NPR space. When Raider ships return home, they have to spend at least three months there, so they can't easily jump around all over.
Every Raider ship is tracked, not generated when needed, so if you destroy a ship it is no longer available. New ships are randomly added to their home system over time and then become available for raiding.
Finally, although they are raiding you, you can raid them too. If you take out their support ships they will be less dangerous.
So far, I am reasonably comfortable with them in the campaign. They cause a lot of uncertainty and can be a local problem, but they are not an existential threat like the Swarm
-
Since the raiders are based on the dark eldar, maybe it would help to give them a more stealth/sneaky design? Make the ships slower, maybe even a bit lower tech at least when it comes to engines, but give them reduced thermal engines and cloaking devices?
That's not purely a flavor suggestion - if the ships are lower tech and spend tonnage on cloaking devices and less on engines, then they'd be less of a standup fight threat - one of the concerns I saw was that escorting your freighters doesn't help if they can easily smash aside an escort. Stealthy but weaker ships means they're still a threat to soft targets but less likely to overwhelm your actual military.
It's probably late in the cycle to make major changes, but if Steve wanted to I can't help but think they'd also be a great use for a new weapon I suggested awhile back - a shield/armor penetrating missile that destroys/disables engines in the same way microwaves target electronics. They're supposed to be pirates so this would work towards the idea of disabling and boarding ships while being less likely to vaporize a battlefleet.
The 186 torpedoes all missing also makes me think it might be worth considering a change to how ECM/ECCM works. IIRC, currently if you have a 30% chance to hit, 20% worth of ECM reduces that to a 10% chance; when the ECM % exceeds the base hit chance you get situations like the Imperium is facing. I wonder if wouldn't be better to make it multiplicative, so a 20% reduction to a 30% hit chance would be 30% * (1-.2) = 24%. To make up for the reduction it might be good to increase the effect of each ECM tier to 20% and make them cumulative, so a two tier difference would be (1-.2)^2 = .64, so a 36% reduction.
-
Hmmm, the raiders are cool as an alien faction, but given their advanced tech from the start I worry they can't act as the 'combat tutorial' I thought pirates could double as.
The lack of missiles is certainly a big nerf, but I fear new players will still be overwhelmed due to the tech advantage. I also worry about the raiders being able to advance their tech on top of starting at Precursor-tier.
Could you share with us some Raider designs to analyze?
-
The 186 torpedoes all missing also makes me think it might be worth considering a change to how ECM/ECCM works. IIRC, currently if you have a 30% chance to hit, 20% worth of ECM reduces that to a 10% chance; I wonder if wouldn't be better to make it multiplicative, so a 20% reduction to a 30% hit chance would be 30% * (1-.2) = 24%. To make up for the reduction it might be good to increase the effect of each ECM tier to 20% and make them cumulative, so a two tier difference would be (1-.2)^2 = .64, so a 36% reduction.
I think this is a reasonable change, ECM as it is right now is a bit extreme as a have-it-or-not effect that aggressively pushes a tech lead, which is a bit out of sync with much of the other design aspects of Aurora ship combat. A 20% reduction of all damage received (in the form of causing 20% misses) is still very strong but allows a lower-tech opponent to still stand a chance with numbers or tactics.
The lack of missiles is certainly a big nerf, but I fear new players will still be overwhelmed due to the tech advantage. I also worry about the raiders being able to advance their tech on top of starting at Precursor-tier.
I agree that it seems extreme for new players, the combat power does seem rather high for a NPR not expected to be an existential threat. Precursors and Rakhas are similarly strong tech-wise but are also purely defensive NPRs, while Swarm and Invaders are intended to be very dangerous and most players will know this going in.
Personally I wouldn't consider it a problem for myself as I am fine with enabling or disabling spoilers as the game proceeds, but new players not used to that idea may experience a bit of a shock.
-
I agree that it seems extreme for new players, the combat power does seem rather high for a NPR not expected to be an existential threat. Precursors and Rakhas are similarly strong tech-wise but are also purely defensive NPRs, while Swarm and Invaders are intended to be very dangerous and most players will know this going in.
Personally I wouldn't consider it a problem for myself as I am fine with enabling or disabling spoilers as the game proceeds, but new players not used to that idea may experience a bit of a shock.
I'm less concerned about new players - at most the raiders option could be less disabled by default, like (IIRC) invaders. What I do worry about is that they'll be either be impossible to deal with early on or requiring gaming the AI to do so - note that in the example campaign they only managed to take out a single raider with a small fleet because the AI obliviously wandered into close range of the STO weapons - which would make them a real chore to deal with.
-
It seems that from min/max perspective, smaller ship with commercial engines and lot of box launchers with fast, short ranged missiles would be best counter for Raiders. My current campaign is beam only, so FAC squadron with heavy railgun, transported in escort carrier would be most likely best option to deal with Raiders.
-
I could just remove the ECM advantage, or lower the tech generally. However, as most of the raiders are single ships, I don't want the 'solution' to simply be a basic design with box launchers that guards each colony and escorts every convoy. That isn't adding anything meaningful to the game. They need to present a challenge, or there is no point in having them.
The Raiders don't present an existential threat because of the serious limitations on their numbers and movement. You can present a serious tactical or operational threat due to powerful ships, without being an existential threat to the whole Empire.
-
I like the fact they have high ECM actually because that make them uniquely different from other threats and demand a special consideration from the player. The suggestion to tweak the ECM math a bit makes sense to me too, abrupt cutoff of missile chance to hit with insufficient ECCM and speed is harsh. It should still be very small chance to hit of course with a big tech disadvantage. I really like the suggestion to give them some of that stealth tech that reduce active sensor profile.
If they will truly not engage a superior force despite the fact they could technically wipe them out that does alleviate a bit my concern as they won't do crippling damage, just potentially large economic damage that the empire can recover from.
It should be interesting to have them pop up during a stand off with one of the NPR. Observing the conflict will yield very valuable intel.
-
I could just remove the ECM advantage, or lower the tech generally. However, as most of the raiders are single ships, I don't want the 'solution' to simply be a basic design with box launchers that guards each colony and escorts every convoy. That isn't adding anything meaningful to the game. They need to present a challenge, or there is no point in having them.
The Raiders don't present an existential threat because of the serious limitations on their numbers and movement. You can present a serious tactical or operational threat due to powerful ships, without being an existential threat to the whole Empire.
Broadly I agree, I think the flavor of the new encounter type is unique and poses interesting challenges as the Gothic AAR shows. Turning the raiders into a puzzle which has a known solution is not exciting gameplay as stated.
That said, I think the major concern is not that the raiders do present a threat, but more whether such a threat can be countered effectively early in the game. Mainly I would worry about standard starts at lower populations such as the default 500m, when a reasonable starting tech setup (80k RP) likely struggles to catch the raiders, is outranged by the raiders allowing a fleet to be kited, and would struggle to hit the raiders with even the most accurate possible missiles. As noted it is possible to overcome this, e.g. with well-designed specialized missiles or boosted FACs, but the set of options is limited and I suspect that many players may find these constrained options do not always match the RP setting they wish to play. Which is not necessarily a problem, as the raiders can simply be turned off for that campaign, but I suppose the question is whether so many players will turn them off in favor of their preferred RP leaving relatively few who actually play with the new spoilers? I do wonder if delaying their first appearances depending on the starting population is possible, this might be a reasonable compromise for lower-pop starts.
All this being said, I keep thinking that the comparison to the Swarm is interesting, as they are a very dangerous race but are generally well-liked as game content despite the existential threat and horror stories of campaigns being aborted early on due to a Swarm invading the home system. So while the new raiders seem difficult I am optimistic that they can work out equally well.
-
I like the fact they have high ECM actually because that make them uniquely different from other threats and demand a special consideration from the player. The suggestion to tweak the ECM math a bit makes sense to me too, abrupt cutoff of missile chance to hit with insufficient ECCM and speed is harsh. It should still be very small chance to hit of course with a big tech disadvantage. I really like the suggestion to give them some of that stealth tech that reduce active sensor profile.
If they will truly not engage a superior force despite the fact they could technically wipe them out that does alleviate a bit my concern as they won't do crippling damage, just potentially large economic damage that the empire can recover from.
It should be interesting to have them pop up during a stand off with one of the NPR. Observing the conflict will yield very valuable intel.
In the test campaign a Raider ship attacked a world with around 3x (I think) its tonnage in military ships in orbit, and a sizeable number of STO units on the ground, so it's not like they turn and run at any opposition. It did lose, but really only because the AI allowed itself to be drawn into close range of the STO weapons.
-
I could just remove the ECM advantage, or lower the tech generally. However, as most of the raiders are single ships, I don't want the 'solution' to simply be a basic design with box launchers that guards each colony and escorts every convoy. That isn't adding anything meaningful to the game. They need to present a challenge, or there is no point in having them.
The Raiders don't present an existential threat because of the serious limitations on their numbers and movement. You can present a serious tactical or operational threat due to powerful ships, without being an existential threat to the whole Empire.
Having to conscientiously design, build and deploy dedicated light patrol forces all throughout our empire in order to get good enough coverage to deal with any raiders that pop up is already enough of an addition without making the raiders themselves very strong. The challenge isn't in actually fighting raiders, its in catching them before they can catch your unarmed transports.
The Battle of the Atlantic was 'fought' with largely second-hand ships compared to the Pacific since they didn't expect to fight pitched naval battles there. The challenge for Allied planners was to organize a system where they could efficiently safeguard their commercial vessels. Raiders should force players to think along the same lines; where am I most vulnerable to raids, how can I efficiently respond to them, and what sorts of designs can fill this role without infringing too much on the budget of my proper front-line fleet?
The actual quality of the Raiders doesn't matter as long as they can consistently threaten undefended commercial ships and lone escorts.
-
The 186 torpedoes all missing also makes me think it might be worth considering a change to how ECM/ECCM works. IIRC, currently if you have a 30% chance to hit, 20% worth of ECM reduces that to a 10% chance; when the ECM % exceeds the base hit chance you get situations like the Imperium is facing. I wonder if wouldn't be better to make it multiplicative, so a 20% reduction to a 30% hit chance would be 30% * (1-.2) = 24%. To make up for the reduction it might be good to increase the effect of each ECM tier to 20% and make them cumulative, so a two tier difference would be (1-.2)^2 = .64, so a 36% reduction.
I think the changes to ECM suggested here are good, otherwise I really like the power level that our new spoiler friends are at. Honestly though, if you want to make them less powerful - Tone down raider weapons a bit, and instead make the invaders much more powerful. From my experience the invaders are quite disappointing compared to what they were in VB6.
ECM is just too all or nothing, having ECM 10, even against ECCM 3 seems to give fleets virtual immunity, you can test this out really well on heavily fortified STO worlds like NPR homeworlds, where you can get attacked by 100s of shots every 5s and not have a single one hit over periods of days. ECM should give a major advantage but I don't think the all-or-nothing state its currently in is really good.
-
I could just remove the ECM advantage, or lower the tech generally. However, as most of the raiders are single ships, I don't want the 'solution' to simply be a basic design with box launchers that guards each colony and escorts every convoy. That isn't adding anything meaningful to the game. They need to present a challenge, or there is no point in having them.
The Raiders don't present an existential threat because of the serious limitations on their numbers and movement. You can present a serious tactical or operational threat due to powerful ships, without being an existential threat to the whole Empire.
I think this is a good goal, but after giving it some thought I think the end result is the exact opposite you're going for.
The raiders are very fast - which makes sense because they're raiders. They have high ECM, for the same reason. And they have long range beam weapons and no missiles as the design goal you're going for.
The net result is that even a single ship is a massive threat to entire fleets if they don't have specialized counters (like high accuracy short range missiles or a lot of beam fighters/FACs). You can't count on killing them with beams since they're probably faster (because raiders) and probably outrange you (because of the powerful ECM and tech advantage), so it doesn't matter if you have a dozen beam battleships, a single raider can potentially eventually kill them all by kiting. And a dozen missile battleships can easily be useless as well, as shown by the 0% hit rate in the update. And the raiders won't run out of ammo, since they use beams and not missiles, so you don't even have the prospect of escaping with some of your fleet once they run dry.
So... honestly I think one or more box launcher ships with special anti-raider missiles for each colony and fleet is probably exactly the counter we're likely to see most players use against raiders at low tech levels.
ECM is just too all or nothing, having ECM 10, even against ECCM 3 seems to give fleets virtual immunity, you can test this out really well on heavily fortified STO worlds like NPR homeworlds, where you can get attacked by 100s of shots every 5s and not have a single one hit over periods of days. ECM should give a major advantage but I don't think the all-or-nothing state its currently in is really good.
Honestly ECM 10 vs ECCM 3 probably should be virtual immunity, that's a huge tech difference. My concern is that since it's additive rather than multiplicative even a 1 or 2 tier ECM difference can be the difference between a decent number of hits and 0% hit chance, especially at long range in a game where kiting is already a very dominant tactic.
-
What a weird page! Just lot of black bars ;D
It's good that everyone is using spoiler tags because I for one want to be surprised when 1.14 hits so cheers!
-
What a weird page! Just lot of black bars ;D
It's good that everyone is using spoiler tags because I for one want to be surprised when 1.14 hits so cheers!
To be honest I'm kind of annoyed I read the spoilers. The mechancs are interesting and I love reading it but now I feel spoiled. I hope I forget everything by the time 1.14 drops.
-
I would not change anything. The raiders are fine as they are, the ECM mechanics look like they are immensely fun, and it's a different threat compared to anything else in-game right now.
Making it easier to counter would only make it irrelevant.
It's an OPTIONAL spoiler race. You're not obligated to turn it on. You're not obligated to turn it on immediately.
You can just decide to wait a few years and THEN turn it on, if you prefer.
If I start conventional with reduced research, I don't turn on invaders until I have a couple of tech levels, for example.
And if you have it on from the start and you die? Losing is fun! Since when are we afraid of losing ;D ;D ;D?
-
I would not change anything. The raiders are fine as they are, the ECM mechanics look like they are immensely fun, and it's a different threat compared to anything else in-game right now.
Making it easier to counter would only make it irrelevant.
It's an OPTIONAL spoiler race. You're not obligated to turn it on. You're not obligated to turn it on immediately.
You can just decide to wait a few years and THEN turn it on, if you prefer.
If I start conventional with reduced research, I don't turn on invaders until I have a couple of tech levels, for example.
And if you have it on from the start and you die? Losing is fun! Since when are we afraid of losing ;D ;D ;D?
I don't think the game needs yet another extremely powerful spoiler. If I wanted to fight an NPR with a massive technological advantage I'd turn on the Invaders or Swarm. Raiders had seemed like they could be a different sort of challenge: not very strong but unpredictable and persistent. But it seems Steve has other ideas -- which is fine, it's his game. :)
-
Yeah. Though I've tried to express my opinion, and I do think the ECM change makes sense purely on a balance level, my purpose isn't to try to bully Steve into making the changes I want. I just hoped to provide some perspective and if he decides to go with something else that's fine.
-
Maybe have them with a bit less ECM but use cloaking devices and engine thermal signature reduction technologies as well as ECM? That would considerably drop the ability of fleets to pursue them or engage them at long range with missiles while cutting their ability to duel warships up close.
-
Thermal reduction is a must and I am shocked that it is not already installed on Raider ships after re-checking the Gothic campaign updates. However cloaking devices are very heavy unless using nearly endgame technology, very similar to jump drives in terms of tonnage requirements, so adding cloaks to the Raider ships would require either stripping them of combat ability or giving them very high techs. NPRs also are not very good at skirting sensor range like a player does, so I'm not sure they could actually use the cloaks effectively instead of charging into range of a RES-1 sensor anyways.
-
Thermal reduction is a must and I am shocked that it is not already installed on Raider ships after re-checking the Gothic campaign updates. However cloaking devices are very heavy unless using nearly endgame technology, very similar to jump drives in terms of tonnage requirements, so adding cloaks to the Raider ships would require either stripping them of combat ability or giving them very high techs. NPRs also are not very good at skirting sensor range like a player does, so I'm not sure they could actually use the cloaks effectively instead of charging into range of a RES-1 sensor anyways.
ECM4 isn't a cheap technology itself, the 80k RP investment to get it is equivalent to that of an eff 6/80% cloak. Taking up a sixth of the tonnage is a major impact but at the same time I think it'd be good to chop into a raider's tonnage budget if they're expected to out-tech their opponents in most cases. They don't have missiles anyways so this would be a pretty pure downside in combat for them, the upside would be to make them require more specialized equipment to detect and engage outside of a beam fight.
-
To be honest I don't think ECM should be a problem in and of itself as you just have to invest in ECM/ECCM on your own to lower it's impact.
The main issue I have with NPR beam combat is that they don't care about MSP and can fire indefinitely. The use of MSP is what makes a large low tech fleet have some possibility to survive an NPR beam fleet that have better range and speed.
I think that NPR should suffer the same problem with weapon failures as players so they will eventually not be able to fire anymore unless they go back to base. They don't need to follow normal maintenance rules just not have infinite ammunition.
-
okay i don't think the spoilers are necessary so....
I'm also surprised to hear the raiders don't have any stealth. I'd personally split the tech points invested into ECM with stealth tech with more of an emphasis on stealth. That should be their number 1 technology out of the gate and even come at the expense of offensive weaponry; it'll teach players the importance of good sensor coverage.
Finding and responding to raiders should be the challenge, not necessarily fighting them.
EDIT: I also think there should be more emphasis on boarding and planetary invasion of vulnerable frontier worlds. They're slaving Pirates after all and I think we need more motivation to have proper planetary defenses that aren't just the cheapest infantry possible to suppress unrest.
-
Finding and responding to raiders should be the challenge, not necessarily fighting them.
I think this line summarizes best.
I don't think the ECM of the raiders is the problem here, its just the powerful weaponry given that they're supposed to be attacking lone escorts / hapless commercials. I definitely support the idea of adding more tonnage to the stealth side at the cost of weapons tonnage. Especially since these spoilers were IIRC made not as a combat challenge but more so as a logistics challenge.
-
Guys let's please try to use spoiler tags to talk about the new spoilers, some folks do browse this thread for updates but want to keep the new spoilers a mystery...
Finding and responding to raiders should be the challenge, not necessarily fighting them.
I think this line summarizes best.
I don't think the ECM of the raiders is the problem here, its just the powerful weaponry given that they're supposed to be attacking lone escorts / hapless commercials. I definitely support the idea of adding more tonnage to the stealth side at the cost of weapons tonnage. Especially since these spoilers were IIRC made not as a combat challenge but more so as a logistics challenge.
I think this makes the most sense. Adding cloaking and dropping the weapons load to just 2-4x 15 cm railguns would work very well if the idea is to allow the raiders to be fought off by a respectable force, 15 cm railguns will still make very short work of any commercial or civilian vessel. With tonnage regained from reducing weapons and power cells, and perhaps reducing the BFC size, it's possible to fit a cloak with 8 efficiency, which is very high in terms of techs but very much in keeping with the flavor.
-
okay i don't think the spoilers are necessary so....
They certainly are necessary. I want to know about changes in 1.14 but I do not want to be spoiled about the new spoiler race. I regret reading all about Rakshas before ever encountering them. I've fixed your post to put spoiler tags in place.
-
To be honest I don't think ECM should be a problem in and of itself as you just have to invest in ECM/ECCM on your own to lower it's impact.
The main issue I have with NPR beam combat is that they don't care about MSP and can fire indefinitely. The use of MSP is what makes a large low tech fleet have some possibility to survive an NPR beam fleet that have better range and speed.
I think that NPR should suffer the same problem with weapon failures as players so they will eventually not be able to fire anymore unless they go back to base. They don't need to follow normal maintenance rules just not have infinite ammunition.
I've changed this for v1.14. NPRs now suffer weapon failure and consume MSP to fix it.
-
I've changed this for v1.14. NPRs now suffer weapon failure and consume MSP to fix it.
YES! FINALLY!
We are even at loong last...
Does it apply to all NPRs? Or spoilers are excluded?
-
To be honest I don't think ECM should be a problem in and of itself as you just have to invest in ECM/ECCM on your own to lower it's impact.
The main issue I have with NPR beam combat is that they don't care about MSP and can fire indefinitely. The use of MSP is what makes a large low tech fleet have some possibility to survive an NPR beam fleet that have better range and speed.
I think that NPR should suffer the same problem with weapon failures as players so they will eventually not be able to fire anymore unless they go back to base. They don't need to follow normal maintenance rules just not have infinite ammunition.
I've changed this for v1.14. NPRs now suffer weapon failure and consume MSP to fix it.
What about when "no maintenance" is checked in game settings, they won't have failures then correct?
Also do NPRs properly construct maintenance facilities and ship MSP around to satisfy their new maintenance needs?
-
Presumably the hope is that yes, they do.
I suppose this may turn out to not be the case.
-
The main issue I have with NPR beam combat is that they don't care about MSP and can fire indefinitely. The use of MSP is what makes a large low tech fleet have some possibility to survive an NPR beam fleet that have better range and speed.
In what possible scenario could any beam fleet run out of MSP due to random weapon failures before they have blown your entire fleet into scrap metal? The only situation in which I can see MSP consumption of beam weapons as being significant on the timescale of a deep-space ship-to-ship battle is with beam fighters, since given the tight tonnage constraints it might be tempting to skimp on MSP a little in order to maximize something else. Outside of that, MSP consumption from firing beam weapons just isn't a significant factor in ship to ship combat. The failure rate just isn't that high. And yet I see people talking about it all the time, which utterly baffles me. Are some people designing their ships with a higher ratio of engineering spaces to maint storage than I am? Or are others using, say, system defense FACs more often than I do? Or getting into running battles with missile-heavy NPRs that require hours worth of point-defense fire to defeat?
What am I missing here? I am perpetually confused on this point. :(
-
In what possible scenario could any beam fleet run out of MSP due to random weapon failures before they have blown your entire fleet into scrap metal?
This is literally a major plot point in my AAR, due to what turned out to be insufficient maintenance supplies for particle beam-armed ships engaged in sniper duels.
It is probably also more common in multi-player-race campaigns, as against NPRs the tactics are usually very simple and players usually outtech NPRs quite badly, but with multiple player races the tactics and tech are much more competitive.
Are some people designing their ships with a higher ratio of engineering spaces to maint storage than I am? Or are others using, say, system defense FACs more often than I do? Or getting into running battles with missile-heavy NPRs that require hours worth of point-defense fire to defeat?
A lot of players, including the Man himself, prefer to put only Engineering Spaces on most ships as these reduce the failure rate and thus MSP consumption rather than just providing more MSPs. Maintenance Bays are really only needed for replenishment ships, or to provide extra MSP to repair weapons. However if you choose to rely on Maint Bays instead of Engineering Spaces this is less of a problem since you have more MSP onboard (but a higher failure rate).
Personally for beam ships I will usually put enough Engineering Spaces to get the maintenance/failure values I want, then add MSPs until I feel like I have enough to keep my weapons operational in a long engagement.
Note that point defense fire does not incur a risk of breakdown, for balance reasons I assume.
-
A lot of players, including the Man himself, prefer to put only Engineering Spaces on most ships as these reduce the failure rate and thus MSP consumption rather than just providing more MSPs. Maintenance Bays are really only needed for replenishment ships, or to provide extra MSP to repair weapons. However if you choose to rely on Maint Bays instead of Engineering Spaces this is less of a problem since you have more MSP onboard (but a higher failure rate).
Ah, this makes sense. I usually equip my ships with thermal-reduced engines - which, I'm finding, not only increases the resource cost but also the ongoing maint cost considerably. So with most of my beam warships I find that a mix of engineering spaces and maint storage is needed to provide the optimal ratio of deployment time + low IFR per ton invested. That, and I tend to go for 3 years deployment time and 2 years maint life, so even my particle beam kiting ships tend to do fine for at least a few long engagements.
-
The main issue I have with NPR beam combat is that they don't care about MSP and can fire indefinitely. The use of MSP is what makes a large low tech fleet have some possibility to survive an NPR beam fleet that have better range and speed.
In what possible scenario could any beam fleet run out of MSP due to random weapon failures before they have blown your entire fleet into scrap metal? The only situation in which I can see MSP consumption of beam weapons as being significant on the timescale of a deep-space ship-to-ship battle is with beam fighters, since given the tight tonnage constraints it might be tempting to skimp on MSP a little in order to maximize something else. Outside of that, MSP consumption from firing beam weapons just isn't a significant factor in ship to ship combat. The failure rate just isn't that high. And yet I see people talking about it all the time, which utterly baffles me. Are some people designing their ships with a higher ratio of engineering spaces to maint storage than I am? Or are others using, say, system defense FACs more often than I do? Or getting into running battles with missile-heavy NPRs that require hours worth of point-defense fire to defeat?
What am I missing here? I am perpetually confused on this point. :(
I typically use a mix of engineering spaces and maintenance bays, but I have still on occasion run perilously low on maintenance supplies in battle. It's just a matter of different players balancing their maintenance storage differently I guess. But I think the biggest effect this change will have -- which I'm very much looking forwards to! -- is to prevent NPRs from spending hours slowly bombarding planets into submission, one... shot... at... a... time...
-
I try to have double the MSP of my max repair at least. I'll try to reach that point with just engineering spaces but after a certain point you get drastically diminished returns on IFR and using maintenance storage makes more sense.
-
For regular maintenance failures I think pure engineering spaces makes a lot of sense since the spaces themselves greatly reduce the need for MSP.
For combat failures, I do think storage would generally make a lot of sense since its a lighter weight source of a bunch of supply points to pour into the beams that will keep failing regardless of the amount of engineering spaces you have.
-
I just want to say I am 100 percent pro raider I would love to see them in the game, there isn't much that actually attacks you at the moment. I played campaigns with the whole plan of defending Sol from IG invaders in the past and while it's fun it can be kinda annoying cause they are really strong. Having these precursor style single ships attacking you around your systems sounds like a great improvement over the IG invaders which kinda seem to first send 1 scout, then 3 warships that each have the strength of my entire navy hahaha maybe I should stop the pre-TN starts.
-
Same - I like the idea of requiring dispersed forces to protect colonies and convoys on the frontier from dangerous, but not empire-ending, attacks and raids. It also gives the unrest generated by "insufficient military forces" in a system a logical reason to exist beyond civvie paranoia.
Hopefully sometime in the future we might be able to automate some of the protection tasks like (manually or even automatically) marking a ship design as a convoy escort, and have the civilian lines use a convoy system that attaches the escorts to massed freighter or colony ship runs!
-
The main issue I have with NPR beam combat is that they don't care about MSP and can fire indefinitely. The use of MSP is what makes a large low tech fleet have some possibility to survive an NPR beam fleet that have better range and speed.
In what possible scenario could any beam fleet run out of MSP due to random weapon failures before they have blown your entire fleet into scrap metal?
...
What am I missing here? I am perpetually confused on this point. :(
Imagine getting into a pure beam fight against someone you barely outrange and outrun. With maintenance turned off, this is a guaranteed win so long as you're careful about maintaining the correct range. But with weapon failures on, your opponent can likely weather the storm long enough that you run out of MSP. So if you try to plink him to death, you run out of MSP, he goes back to the shipyard and buffs out the scratches, and it's like the fight never happened. Or you can get closer to do real damage, but also risk taking return fire.
-
I still think hard range limits on beams were a mistake. I think that is a big contributor to the speed+range = automatic win issue. This was also a thing in the dreadnought era, where they realized that being faster and longer ranged was basically all they needed, assuming they could get their crews and admirals to actually correctly prosecute that (ie the old 'speed is our armor' saying with the royal navy, followed of course by their retard admirals closing the distance anyways at jutland and taking a bunch of casualties).
-
I still think hard range limits on beams were a mistake. I think that is a big contributor to the speed+range = automatic win issue. This was also a thing in the dreadnought era, where they realized that being faster and longer ranged was basically all they needed, assuming they could get their crews and admirals to actually correctly prosecute that (ie the old 'speed is our armor' saying with the royal navy, followed of course by their retard admirals closing the distance anyways at jutland and taking a bunch of casualties).
Conceptually I would agree, but in gameplay terms I have difficulty thinking of how else beam weapons would be differentiated without range limits, unless the "soft" range limits were harsh enough that they were not much different from hard limits. Same goes for fire control tech levels if we're honest.
-
I still think hard range limits on beams were a mistake. I think that is a big contributor to the speed+range = automatic win issue. This was also a thing in the dreadnought era, where they realized that being faster and longer ranged was basically all they needed, assuming they could get their crews and admirals to actually correctly prosecute that (ie the old 'speed is our armor' saying with the royal navy, followed of course by their retard admirals closing the distance anyways at jutland and taking a bunch of casualties).
Read some details of Jutland some time.
Beatty probably was moderatly incompetent but no one made the mistakes you suggest. His mistaked were awful signalling which is bad in a scouting force and enouraging bad ammo handling as well as poor gunnery training. British BC force had the worst accuracy, the Battle line and 5th Battle Squadron had better accuracy than the Germans.
Summary 2 BC with the Battlecruiser fleet were lost largely due to poor ammo handling procedures, the Germans had made the same mistakes but blind luck at Dogger Bank ennabled one of their ships to survice a hit which revealed the issue. Invincible may have had the same problem or may just have sufferred from being the 1st BC built and having weak armour. The Germans were really , really lucky had british AP shells been functioning as designed they would have lost at least 3 possibly up to 5 more Battleships and Battlecruisers and sufferred both a strategic and tactical defeat instead of a tactical victory and strategic defeat. The day after Jutland the Grand Fleet had a larger Margin of superiority in operational capital ships than on the day and notably the German commanders were well aware they had escaped being crushed by the skin of their teeth and never dared seek a battle again. Until 1918 when the fleet (snsibly)mutinied rather than die for the honour of the flag
-
I still think hard range limits on beams were a mistake. I think that is a big contributor to the speed+range = automatic win issue. This was also a thing in the dreadnought era, where they realized that being faster and longer ranged was basically all they needed, assuming they could get their crews and admirals to actually correctly prosecute that (ie the old 'speed is our armor' saying with the royal navy, followed of course by their retard admirals closing the distance anyways at jutland and taking a bunch of casualties).
Read some details of Jutland some time.
Beatty probably was moderatly incompetent but no one made the mistakes you suggest. His mistaked were awful signalling which is bad in a scouting force and enouraging bad ammo handling as well as poor gunnery training. British BC force had the worst accuracy, the Battle line and 5th Battle Squadron had better accuracy than the Germans.
Summary 2 BC with the Battlecruiser fleet were lost largely due to poor ammo handling procedures, the Germans had made the same mistakes but blind luck at Dogger Bank ennabled one of their ships to survice a hit which revealed the issue. Invincible may have had the same problem or may just have sufferred from being the 1st BC built and having weak armour. The Germans were really , really lucky had british AP shells been functioning as designed they would have lost at least 3 possibly up to 5 more Battleships and Battlecruisers and sufferred both a strategic and tactical defeat instead of a tactical victory and strategic defeat. The day after Jutland the Grand Fleet had a larger Margin of superiority in operational capital ships than on the day and notably the German commanders were well aware they had escaped being crushed by the skin of their teeth and never dared seek a battle again. Until 1918 when the fleet (snsibly)mutinied rather than die for the honour of the flag
Your reply seems like coping to me, which I think reduces the amount of overall useful information available. Indeed the Germans did not seek further engagement after that battle, they even went on to lose the whole war as everyone knows, don't deflect if you are actually right. The RN closed the distance to the point that the Germans were getting penetrating hits, despite to my memory having generally superior guns that aught to have enabled them to hold the range open and take almost no damage whatsoever. I seem to recall they provided justification for this in their records, it doesn't really matter, ass covering is a universal factor. My personal take is that there wasn't enough damage happening fast enough, and a hunger for glory drove a decision to close the distance in the hopes of getting more hits and more kills.
My original point was mainly that range + speed (and, in fact, relatively limited armor to facilitate more speed) is actually a fairly old theory and isn't some crazy video gamey invention that only exists in aurora, it was actual doctrine for real navies, and in my opinion probably would have generally worked had it been followed more consistently.
-
I still think hard range limits on beams were a mistake. I think that is a big contributor to the speed+range = automatic win issue. This was also a thing in the dreadnought era, where they realized that being faster and longer ranged was basically all they needed, assuming they could get their crews and admirals to actually correctly prosecute that (ie the old 'speed is our armor' saying with the royal navy, followed of course by their retard admirals closing the distance anyways at jutland and taking a bunch of casualties).
Conceptually I would agree, but in gameplay terms I have difficulty thinking of how else beam weapons would be differentiated without range limits, unless the "soft" range limits were harsh enough that they were not much different from hard limits. Same goes for fire control tech levels if we're honest.
I think that there should just be no range limit. For instance, perhaps there could be hit probabilities at different ranges (sortof like how missiles have hit chances expressed vs speed in a nicely formatted list that is easy to understand), and that hit probability falls off with distance on an inverse curve. Improving your equipment improves the curve, but there is no actual 'range', there is just increased hit probability. There would, for instance, be a fixed distance at which your to-hit modifier for distance is 40%, or 5%.
Ships past a certain ridiculous distance probably shouldnt show up in fire control so that you dont fire on them accidentally, but I do think that in general if someone is shooting at you then you should be able to at least try to shoot back and have some non-zero percent chance of hitting.
-
I still think hard range limits on beams were a mistake. I think that is a big contributor to the speed+range = automatic win issue. This was also a thing in the dreadnought era, where they realized that being faster and longer ranged was basically all they needed, assuming they could get their crews and admirals to actually correctly prosecute that (ie the old 'speed is our armor' saying with the royal navy, followed of course by their retard admirals closing the distance anyways at jutland and taking a bunch of casualties).
Read some details of Jutland some time.
Beatty probably was moderatly incompetent but no one made the mistakes you suggest. His mistaked were awful signalling which is bad in a scouting force and enouraging bad ammo handling as well as poor gunnery training. British BC force had the worst accuracy, the Battle line and 5th Battle Squadron had better accuracy than the Germans.
Summary 2 BC with the Battlecruiser fleet were lost largely due to poor ammo handling procedures, the Germans had made the same mistakes but blind luck at Dogger Bank ennabled one of their ships to survice a hit which revealed the issue. Invincible may have had the same problem or may just have sufferred from being the 1st BC built and having weak armour. The Germans were really , really lucky had british AP shells been functioning as designed they would have lost at least 3 possibly up to 5 more Battleships and Battlecruisers and sufferred both a strategic and tactical defeat instead of a tactical victory and strategic defeat. The day after Jutland the Grand Fleet had a larger Margin of superiority in operational capital ships than on the day and notably the German commanders were well aware they had escaped being crushed by the skin of their teeth and never dared seek a battle again. Until 1918 when the fleet (snsibly)mutinied rather than die for the honour of the flag
Your reply seems like coping to me, which I think reduces the amount of overall useful information available. Indeed the Germans did not seek further engagement after that battle, they even went on to lose the whole war as everyone knows, don't deflect if you are actually right. The RN closed the distance to the point that the Germans were getting penetrating hits, despite to my memory having generally superior guns that aught to have enabled them to hold the range open and take almost no damage whatsoever. I seem to recall they provided justification for this in their records, it doesn't really matter, ass covering is a universal factor. My personal take is that there wasn't enough damage happening fast enough, and a hunger for glory drove a decision to close the distance in the hopes of getting more hits and more kills.
My original point was mainly that range + speed (and, in fact, relatively limited armor to facilitate more speed) is actually a fairly old theory and isn't some crazy video gamey invention that only exists in aurora, it was actual doctrine for real navies, and in my opinion probably would have generally worked had it been followed more consistently.
It is worth noting that there is a lot more than just speed and range that goes into a naval battle. Reconnaissance, communications, fire control, rate of fire, gunnery, armo(u)r, and the ever-present bad weather also play key roles, and to my recollection all were present in varying degrees during Jutland. I think it suffices to say that regardless of how one feels about the conduct of battle by the admirals involved (and there is certainly much to harp on), the actual battle was quite complex and a lot more went into it than "closing the distance".
I think that there should just be no range limit. For instance, perhaps there could be hit probabilities at different ranges (sortof like how missiles have hit chances expressed vs speed in a nicely formatted list that is easy to understand), and that hit probability falls off with distance on an inverse curve. Improving your equipment improves the curve, but there is no actual 'range', there is just increased hit probability. There would, for instance, be a fixed distance at which your to-hit modifier for distance is 40%, or 5%.
Ships past a certain ridiculous distance probably shouldnt show up in fire control so that you dont fire on them accidentally, but I do think that in general if someone is shooting at you then you should be able to at least try to shoot back and have some non-zero percent chance of hitting.
This misses my point, which is that having a falloff like this is effectively the same as having hard limits on range. Neglecting BFCs for the sake of discussion, say that instead of a hard limits of 30,000 km my 10cm railguns have 100% accuracy at 30,000 km, 25% at 60,000 km, 6% at 90,000 km, and so on so that by about 135,000 km or so the hit rate is under 1%. Suppose my opponent has 10cm lasers at the same tech level, with 100% accuracy at 90,000 km and, following the same rule, 25% accuracy at 180,000 km. If the laser ships have equal or greater speed to my railgun ships, they can still sit at 180,000 km range or some similar value and enjoy their 25% hit rate while my railguns struggle to score even 1% hits. This is not substantially different from the situation with hard range limits, it's just a bit fuzzier. I actually prefer having hard limits just because it makes the game mechanics clear and straightforward, so I don't see a reason to muddy the mechanics for 99% the same effects.
-
Your reply seems like coping to me, which I think reduces the amount of overall useful information available. Indeed the Germans did not seek further engagement after that battle, they even went on to lose the whole war as everyone knows, don't deflect if you are actually right. The RN closed the distance to the point that the Germans were getting penetrating hits, despite to my memory having generally superior guns that aught to have enabled them to hold the range open and take almost no damage whatsoever. I seem to recall they provided justification for this in their records, it doesn't really matter, ass covering is a universal factor. My personal take is that there wasn't enough damage happening fast enough, and a hunger for glory drove a decision to close the distance in the hopes of getting more hits and more kills.
My original point was mainly that range + speed (and, in fact, relatively limited armor to facilitate more speed) is actually a fairly old theory and isn't some crazy video gamey invention that only exists in aurora, it was actual doctrine for real navies, and in my opinion probably would have generally worked had it been followed more consistently.
It is worth noting that there is a lot more than just speed and range that goes into a naval battle. Reconnaissance, communications, fire control, rate of fire, gunnery, armo(u)r, and the ever-present bad weather also play key roles, and to my recollection all were present in varying degrees during Jutland. I think it suffices to say that regardless of how one feels about the conduct of battle by the admirals involved (and there is certainly much to harp on), the actual battle was quite complex and a lot more went into it than "closing the distance".
I'm not denying any part of that, I am stating the absolute fact that they elected to close the distance. If I recall correctly that decision was deliberate. If someone is inclined to provide contradictory information (or even just deny that without supporting that at all) then feel free. However, waxing poetical about how there are more factors is irrelevant. They had superior range and superior speed, the general doctrine was to hold the range open. They elected not to. Whether that was the correct call or not is presumably a matter on which one might agree to disagree as that seems to be annoying RN fans and my claims that it was a bad call were meant to be an offhanded remark tangential to the real point.
I think that there should just be no range limit. For instance, perhaps there could be hit probabilities at different ranges (sortof like how missiles have hit chances expressed vs speed in a nicely formatted list that is easy to understand), and that hit probability falls off with distance on an inverse curve. Improving your equipment improves the curve, but there is no actual 'range', there is just increased hit probability. There would, for instance, be a fixed distance at which your to-hit modifier for distance is 40%, or 5%.
Ships past a certain ridiculous distance probably shouldnt show up in fire control so that you dont fire on them accidentally, but I do think that in general if someone is shooting at you then you should be able to at least try to shoot back and have some non-zero percent chance of hitting.
This misses my point, which is that having a falloff like this is effectively the same as having hard limits on range. Neglecting BFCs for the sake of discussion, say that instead of a hard limits of 30,000 km my 10cm railguns have 100% accuracy at 30,000 km, 25% at 60,000 km, 6% at 90,000 km, and so on so that by about 135,000 km or so the hit rate is under 1%. Suppose my opponent has 10cm lasers at the same tech level, with 100% accuracy at 90,000 km and, following the same rule, 25% accuracy at 180,000 km. If the laser ships have equal or greater speed to my railgun ships, they can still sit at 180,000 km range or some similar value and enjoy their 25% hit rate while my railguns struggle to score even 1% hits. This is not substantially different from the situation with hard range limits, it's just a bit fuzzier. I actually prefer having hard limits just because it makes the game mechanics clear and straightforward, so I don't see a reason to muddy the mechanics for 99% the same effects.
This is a bad faith argument. There is no reason why range differences between two adjacent tech levels would need to be a factor of three as a result of this suggestion. If you vastly out tech someone, they still in effect will not be able to fire back to any real effect. This is kindof obvious. I mean to say that this would turn a hard range advantage into a softer one, and you would need a much larger advantage in order to effectively turn it back into a hard advantage.
-
I'm not denying any part of that, I am stating the absolute fact that they elected to close the distance. If I recall correctly that decision was deliberate. If someone is inclined to provide contradictory information (or even just deny that without supporting that at all) then feel free. However, waxing poetical about how there are more factors is irrelevant. They had superior range and superior speed, the general doctrine was to hold the range open. They elected not to. Whether that was the correct call or not is presumably a matter on which one might agree to disagree as that seems to be annoying RN fans and my claims that it was a bad call were meant to be an offhanded remark tangential to the real point.
My point was more that there were other factors besides "speed x range" that played into the decision to close the range, which serves as a more general illustration that "speed x range" while a known doctrinal principle is not the sole determinant. For example, the German naval doctrine tended to value heavier armor, which has the effect of reducing the effective range of an enemy due to the mechanics of armor penetration. Admittedly, this is not a mechanic which Aurora really models since armor is basically a form of distributed hit points.
This said I am all in favor of not arguing about Jutland in the checks thread title 1.14 discussion thread. :)
This misses my point, which is that having a falloff like this is effectively the same as having hard limits on range. Neglecting BFCs for the sake of discussion, say that instead of a hard limits of 30,000 km my 10cm railguns have 100% accuracy at 30,000 km, 25% at 60,000 km, 6% at 90,000 km, and so on so that by about 135,000 km or so the hit rate is under 1%. Suppose my opponent has 10cm lasers at the same tech level, with 100% accuracy at 90,000 km and, following the same rule, 25% accuracy at 180,000 km. If the laser ships have equal or greater speed to my railgun ships, they can still sit at 180,000 km range or some similar value and enjoy their 25% hit rate while my railguns struggle to score even 1% hits. This is not substantially different from the situation with hard range limits, it's just a bit fuzzier. I actually prefer having hard limits just because it makes the game mechanics clear and straightforward, so I don't see a reason to muddy the mechanics for 99% the same effects.
This is a bad faith argument.
First, I will thank you to not assign moral judgments to my arguments.
There is no reason why range differences between two adjacent tech levels would need to be a factor of three as a result of this suggestion.
I am literally using the current in-game values for the sake of argument, to compare railguns and lasers at the same tech level. Railguns vs Lasers is a fairly obvious example of a range differential between weapon types, so it is a useful example to discuss the implications of a suggestion.
If you vastly out tech someone, they still in effect will not be able to fire back to any real effect. This is kindof obvious. I mean to say that this would turn a hard range advantage into a softer one, and you would need a much larger advantage in order to effectively turn it back into a hard advantage.
This gets to the base of my argument, though. If the difference in range is large, similar to how it already is in-game, then the effect of removing the range limit and having an accuracy falloff is basically the same with different numbers and some fuzziness.
On the other hand if the range difference is relatively soft then the character of different weapons is lost. If lasers and railguns are both competitive at the same range, then why bother choosing one or the other aside from RP flavor? I don't think either side of the spectrum is desirable , while the hard limits we have in place now I think accomplish what is needed in terms of gameplay and flavor even if the "realism" is not perfect.
-
My point was more that there were other factors besides "speed x range" that played into the decision to close the range, which serves as a more general illustration that "speed x range" while a known doctrinal principle is not the sole determinant. For example, the German naval doctrine tended to value heavier armor, which has the effect of reducing the effective range of an enemy due to the mechanics of armor penetration. Admittedly, this is not a mechanic which Aurora really models since armor is basically a form of distributed hit points.
Shields, however, do work this way in practice. If you can't do enough damage, the shields will just regenerate it away, meaning that plinking away from a distance rarely works very well.
-
what is needed in terms of gameplay and flavor even if the "realism" is not perfect.
Aurora isn't a chess or some card game - we are playing with stars, and distances, and ships, and commanders instead of cells and figures, because it's much easier to believe with some part of our brain, that it's some reality behind the screen. So no point in embracing the word "realism" in quote signs to diminish it's value.
-
Given equal speeds (or a speed advantage to the out-ranging ships), a far greater range gap would be required to make a range difference an absolute advantage. Currently a difference of as much as 1 millimeter is almost insurmountable without heroic efforts. Softening the range values so that the lower tech ships can still at least shoot back and potentially deal some damage is a huge difference from the current situation. As it stands now, as long as you can keep your ships in supply with MSP, you can pretty much slaughter the entire lower tech fleet completely one sidedly, and they cant even attempt to shoot back. Several levels of tech advantage will still result in one side winning without taking any losses or even real damage, but it means that there wont be an immediate massacre as soon as someone rolls out one level of higher tech lasers or whatever.
I admittedly missed your earlier point that you were comparing different weapon systems, rather than different tech levels, but you now seem to be saying that you want the weapons to remain differentiated, which softening ranges would absolutely allow for, while also greatly lessening the immediate slaughter that follows gaining a single tech level, so I am not sure why you even brought that up.
-
I think it's worth to bear in mind also, that AI will not be able to systematically use such "all or nothing" situations with abrupt range gaps - the player can do it regularly, ripping AI's fleets apart with smallest tech or design advantages, but AI cannot do such things, and it's not very challengable and so poor stories.
With "soft range" it will be much simpler for AI to deal against us with big slow fleets, it will be less common to have unbelievably easy no-loss victories, and so I think it will be much better gameplay.
Speaking of weapon differences - I think there are more then enough of differences between them even without abrupt ranges, and now it's more a problem, that some weapons are too rarely usable comparing to others, so softening their differences will do no harm.
-
I'm happy with the current beam mechanics and I definitely don't want longer ranges, because of the issues I have listed many times on the forums. If you are out-ranged and slower (a situation I am facing right now), then you need to avoid deep space combat and find other ways to combat the enemy.
-
I think it's worth to bear in mind also, that AI will not be able to systematically use such "all or nothing" situations with abrupt range gaps - the player can do it regularly, ripping AI's fleets apart with smallest tech or design advantages, but AI cannot do such things, and it's not very challengable and so poor stories.
With "soft range" it will be much simpler for AI to deal against us with big slow fleets, it will be less common to have unbelievably easy no-loss victories, and so I think it will be much better gameplay.
Speaking of weapon differences - I think there are more then enough of differences between them even without abrupt ranges, and now it's more a problem, that some weapons are too rarely usable comparing to others, so softening their differences will do no harm.
If the AI works out it is faster and has longer-ranged weapons, it will use that advantage (and has many times in my games). There is more of a challenge for the AI in avoiding being on the wrong end of that situation, but that is an AI issue rather than a weapon mechanics issue and I will get around to addressing it at some point.
-
Your reply seems like coping to me, which I think reduces the amount of overall useful information available. Indeed the Germans did not seek further engagement after that battle, they even went on to lose the whole war as everyone knows, don't deflect if you are actually right. The RN closed the distance to the point that the Germans were getting penetrating hits, despite to my memory having generally superior guns that aught to have enabled them to hold the range open and take almost no damage whatsoever. I seem to recall they provided justification for this in their records, it doesn't really matter, ass covering is a universal factor. My personal take is that there wasn't enough damage happening fast enough, and a hunger for glory drove a decision to close the distance in the hopes of getting more hits and more kills.
As I say read 2 or 3 decent histories , look at the navigation charts and the viewpoints of all side then have an informed opinion, as I have. Anyway Way , Way of Topic so I will not comment again and apologise for the diversion to everyone else
-
I'm happy with the current beam mechanics and I definitely don't want longer ranges, because of the issues I have listed many times on the forums. If you are out-ranged and slower (a situation I am facing right now), then you need to avoid deep space combat and find other ways to combat the enemy.
I mean, other than using missiles, where it's quite easy to gain the advantage with mass box launchers, there is really not a lot of tactical options for this situation. At least, not one I can see clearly. Hiding on the other side of jump points may seem a good option, but the AI can always jump back before you can fire.
-
I'm happy with the current beam mechanics and I definitely don't want longer ranges, because of the issues I have listed many times on the forums. If you are out-ranged and slower (a situation I am facing right now), then you need to avoid deep space combat and find other ways to combat the enemy.
I mean, other than using missiles, where it's quite easy to gain the advantage with mass box launchers, there is really not a lot of tactical options for this situation. At least, not one I can see clearly. Hiding on the other side of jump points may seem a good option, but the AI can always jump back before you can fire.
I managed to find one in my current campaign when I thought I was in trouble :) It will be in the next update.
-
I have no problem with range and beam combat between player factions as both shields and MSP can give enough benefit to a defender with numerical superiority. Against the AI I think they main problem is they can fire their weapons indefinitely, the AI should not be able to do that.
Another strategy I have employed many times is formations and spreading ships and squadrons out, that make it so even the one with worse range can fire their weapons as it is impossible to keep range from all enemy ships at the same time for anyone. As a ship retreats to recharge shields you have to get into range against those that don't etc... Might seem like a bit of micro bit you can use the escort feature to run formations and easily order them about for good effect.
-
I have no problem with range and beam combat between player factions as both shields and MSP can give enough benefit to a defender with numerical superiority. Against the AI I think they main problem is they can fire their weapons indefinitely, the AI should not be able to do that.
I believe it was already mentioned that was changing this patch.
-
I have no problem with range and beam combat between player factions as both shields and MSP can give enough benefit to a defender with numerical superiority. Against the AI I think they main problem is they can fire their weapons indefinitely, the AI should not be able to do that.
I believe it was already mentioned that was changing this patch.
Ok... if that is the case I missed that and that is a fine change... in that case I find no problem with the beam mechanics as they are as a weaker opponent can fight as long as you don't keep all ships in one place and use shields.
-
You have added the option to scrap installations in 1.14. Any plans to add scrap orbital space stations? :D
-
You have added the option to scrap installations in 1.14. Any plans to add scrap orbital space stations? :D
You can scrap them now in a shipyard.
-
Population: Refuel And Resupply From Colony
I wonder if this might be better as "Refuel, Resupply, and Load Ordnance"? On one hand it seems like this would probably be the most common move order for missile ships, on the other hand I don't know if it is more likely that having this as a default would cause unintended confusion due to e.g. ammunition transports loading ordnance when not desired.
What do others think? I love this change by the way, if this default is left as it is I would have no objections personally.
-
Really loving these QOL changes for 1.14. I have a small suggestion to make 1.14 even more phenomenal for micro than it is now, one of two things:
1.A "home base" for a fleet, where it automatically tracks the range of a fleet from that base using fuel in tankers and consumption of all ships. If a destination is too far, it cancels the order to prevent being stranded, and if it's because fuel is less than max, it goes to refuel before heading off.
2. A check to see if a fleet would trigger a refueling conditional order before it reaches its destination, with a certain margin, where it refuels before going to a destination. To prevent things like fleets traveling 90% to a destination then proceeding to fly back to refuel.
I suppose ranges can be tricky because of movement of celestial bodies but if you just calculate distance using current positions of destination planets and LPs then it should work almost all the time I think, without being too intensive.
-
Population: Refuel And Resupply From Colony
I wonder if this might be better as "Refuel, Resupply, and Load Ordnance"? On one hand it seems like this would probably be the most common move order for missile ships, on the other hand I don't know if it is more likely that having this as a default would cause unintended confusion due to e.g. ammunition transports loading ordnance when not desired.
What do others think? I love this change by the way, if this default is left as it is I would have no objections personally.
I think ammunition is something the player will think much more consciously about than lets say, MSP/fuel. Which is why I think it's better this way.
I'm left wondering what happens when a ship that cannot perform an order encounters a default move order. (No geosurvey and you click on system body or no salvager and you click on wreck)
-
I'm left wondering what happens when a ship that cannot perform an order encounters a default move order. (No geosurvey and you click on system body or no salvager and you click on wreck)
If it is anything like how things work presently, the ship or fleet would move to the target and fire off a message about not being able to do its job, which slightly clutters the event log but functionally works just fine as the fleet has still gotten from A to B.
For me I see this mainly being an "issue" when I send troop transports to a body I haven't yet put a colony on...still, easy fix for me.
-
I'm left wondering what happens when a ship that cannot perform an order encounters a default move order. (No geosurvey and you click on system body or no salvager and you click on wreck)
The default orders are just like any any other order - just activated with a double click instead. The behaviour will be the same in both cases.
I considered having more intelligent default orders that considered the fleet composition, but there are so many edge cases it probably would cause more problems than it solved (plus taking a lot more time to code and debug). I'm in the middle of moving house atm so I don't have much free time.
-
It's funny how used to you become with certain things - I never even considered that raise/lower all button as necessary since doing it ship-by-ship is so routine at this point. QoL!
-
Note this is not the same as turning these spoilers off. Raiders and Swarm will still gain tech in the background and Invaders will use the full time since game start to generate forces when they do eventually invade. This option is simply to delay the encounters until the player empire is larger.
(http://aurora2.pentarch.org/index.php?topic=12523.msg154048#msg154048)
Does that mean that up to 1.13 any dynamic spoiler will start at the same level the moment it's turned on, i.e. by turning them off temporarily you don't only delaying their appearance, but also making them relatively weaker (comparing to your level) at the moment of their appearance?
-
Note this is not the same as turning these spoilers off. Raiders and Swarm will still gain tech in the background and Invaders will use the full time since game start to generate forces when they do eventually invade. This option is simply to delay the encounters until the player empire is larger.
(http://aurora2.pentarch.org/index.php?topic=12523.msg154048#msg154048)
Does that mean that up to 1.13 any dynamic spoiler will start at the same level the moment it's turned on, i.e. by turning them off temporarily you don't only delaying their appearance, but also making them relatively weaker (comparing to your level) at the moment of their appearance?
I believe that the spoiler races already do this (i.e. mark tech/time since game start), and the changelog post simply indicates that this behavior will not be changed by the minimum systems rule. Certainly for Raiders this is the case as they operate from an "off-map" base.
-
When a Swarm is generated, it uses game time as a modifier for tech, so a Swarm generated in year 50 will have the same tech (broadly) regardless of when the Swarm were activated.
Raiders gain tech using the research facilities on their home world. This still happens when they are inactive. However, they gain additional labs over time while active, so late-activated Raiders will have lower tech than Raiders active from the start.
Invaders don't gain tech so time of activation doesn't affect them in this context.
-
Invaders don't gain tech so time of activation doesn't affect them in this context.
Wait what? I thought they did. Honestly given how "low" they start at they really ought to advance.
-
In regards to the "minimum player systems for spoilers" ...what conditions makes a system a player system?
-
In regards to the "minimum player systems for spoilers" ...what conditions makes a system a player system?
It's the total number of systems that a player can see on the galactic map.
-
Could you change it to "Player Known Systems"? As it is, it implies that you can explore as much as you want and only creating colonies affects the number, in which case I'd put it fairly low. But since it's not that but the number of explored systems, I would put it quite a bit higher.
-
In a multiple player faction game, is this the sum total of (unique?) player-known systems by all races, or the greatest from a single race?
-
Could you change it to "Player Known Systems"? As it is, it implies that you can explore as much as you want and only creating colonies affects the number, in which case I'd put it fairly low. But since it's not that but the number of explored systems, I would put it quite a bit higher.
Done.
-
In a multiple player faction game, is this the sum total of (unique?) player-known systems by all races, or the greatest from a single race?
Total for all player races.
-
When a Swarm is generated, it uses game time as a modifier for tech, so a Swarm generated in year 50 will have the same tech (broadly) regardless of when the Swarm were activated.
Raiders gain tech using the research facilities on their home world. This still happens when they are inactive. However, they gain additional labs over time while active, so late-activated Raiders will have lower tech than Raiders active from the start.
Invaders don't gain tech so time of activation doesn't affect them in this context.
I really appreciate this change, especially after losing a few games to the critters early! :)
-
The new changes to system generation are exciting to say the least. Moving the version to 2.0 is an intimidating prospect, I'll venture to say...
I did have one thought regarding the changing colony costs, which is the interaction with civilian shipping. Presently, civilian ships will tote colonists to any colony set as a destination which has some room. They sometimes overfill a bit but generally they get this about right. However with the new planet eccentricity, say I colonize Mars and place some infrastructure while it is closer to the sun, CC=2.11, and the civilians decide to fill it up with colonists. When mars orbits "away" and the CC rises to 2.5ish, those colonists will suddenly be too much for the life support.
So will civilian logic be changed to work on the body maximum CC in this case? Or maybe it already does and I don't know that because I never put colonists on comets?
-
So will civilian logic be changed to work on the body maximum CC in this case? Or maybe it already does and I don't know that because I never put colonists on comets?
I completely agree, this seems super important. Civilians are alreasy inefficient as they are, they need to be able to accomodate somewhat for these changes.
An easy solution might be: have the civilians always use the worst possible coloy cost due to the orbit in order to calculate if there's space on the colony
Aside from that, I'm very excited about these changes. Really great work Steve ;D
-
What would be special about it becoming 2.0 other than nice round number?
-
So will civilian logic be changed to work on the body maximum CC in this case? Or maybe it already does and I don't know that because I never put colonists on comets?
I completely agree, this seems super important. Civilians are alreasy inefficient as they are, they need to be able to accomodate somewhat for these changes.
An easy solution might be: have the civilians always use the worst possible coloy cost due to the orbit in order to calculate if there's space on the colony
Aside from that, I'm very excited about these changes. Really great work Steve ;D
I would be good if we could via the civilian contract menu or somewhere else send a population cap # - i.e. fill until you reach 500m and then don't send anymore - or civilians taking into account the max pop factor when calculating transport (if I want more pop there, then I'll put them there myself). I really like the eccentricity change but having had a few comet colonies get borked, I don't want the micromanagement piece of worrying about my civilians bringing too much population.
-
This is very exciting! It occurs to me that temperature changes due to orbital eccentricity might have interesting interactions with the hydrosphere. For instance, a planet that starts out close to its star with a liquid hydrosphere may have its hydrosphere freeze as it moves away from the star. The increased albedo may mean that the hydrosphere won't necessarily melt again when the planet moves back towards perihelion: it might become stuck in a frozen state. You might also be able to get planets with a runaway greenhouse effect if water condenses back out of the atmosphere more slowly than the planet moves around its orbit. I haven't run the math to see what parameters would be needed for any of this to occur, but if it does it will make living on eccentric planets very interesting!
-
So you can put orbital habitats over the twin planet right?
And can you manually add them in SM mode or at least change the chance of it happening?
And can you have more than one at once or is it just a twin?
-
Eccentric Orbits mechanics - it's splendid! Weeeee!!!
-
Twin planets gets me all excited 8)
But for sure, the eccentric orbits will make for funnier system maps.
-
So I am not completely sure about one thing, can we edit eccentricity of individual planets in SM mode?
-
With the changes coming to system generation, do you have eventual plans to have some sort of barycenter implementation. I'm thinking especially with regards to the new twin planet chance, as technically they would be orbiting eachother around a central point (aka the barycenter), and I suppose that you could also make it a thing for systems binaries etc.
-
Or Trinaries.
That would be fun.
-
So I am not completely sure about one thing, can we edit eccentricity of individual planets in SM mode?
Not yet, but I plan to add before release.
-
Or Trinaries.
That would be fun.
Trinaries already exist - as do systems with four stars. All the non-primary components can have eccentric orbits.
-
An interesting effect here is that eccentric orbits make tidally-locked planets a lot more appealing. Since they have 80% reduced temperature penalties (http://aurora2.pentarch.org/index.php?topic=8495.msg101987#msg101987), tidally-locked colonies should be able to far better handle extreme seasons than their rotating cousins. Presumably some of that infrastructure is used to build static heat collectors/sinks around the terminator.
-
With the changes coming to system generation, do you have eventual plans to have some sort of barycenter implementation. I'm thinking especially with regards to the new twin planet chance, as technically they would be orbiting eachother around a central point (aka the barycenter), and I suppose that you could also make it a thing for systems binaries etc.
No, I don't plan to implement barycenters. They would add a lot of complexity without adding much to gameplay.
-
So if we get the SM command to change eccentricity and use it on planet in your example system for Gas Giant Effects. Will it stay on circular or will it gradually return to its eccentric orbit because of the Jovian planets affecting it?
-
So if we get the SM command to change eccentricity and use it on planet in your example system for Gas Giant Effects. Will it stay on circular or will it gradually return to its eccentric orbit because of the Jovian planets affecting it?
'Gas Giant Effects' is a one-off process during system generation.
-
So if we get the SM command to change eccentricity and use it on planet in your example system for Gas Giant Effects. Will it stay on circular or will it gradually return to its eccentric orbit because of the Jovian planets affecting it?
'Gas Giant Effects' is a one-off process during system generation.
Thank you Steve, these changes are really exciting!
-
With the new orbital changes, what orbit does ʻOumuamua get? Did you go with a really big ellipse or an actual hyperbola?
-
Space geography changes moisten me greatly. Twin planets too! Sounds like terraforming our planets to be just barely within the habitable range may not be enough anymore for them to stay habitable year-round. Finally a reason to put them more firmly in the middle of the livable range other than "somebody might attack them with orbital terraformers and cause damage almost immediately".
Seeing intersecting orbits, we better prepare for a constant trickle of screenshots of colliding planets in the future. Might also be best to tick the "max CC" option by default, because new players who aren't familiar with the mechanic may well be surprised.
-
We live in interesting times!
-
Unlike stars, the orbits of planets may cross due to their eccentricity (like Pluto and Neptune).
I'm pretty sure that the orbits of Pluto and Neptune do not cross.
The closest distance between the two orbits is 2.4 AU. If we could reach out magically and move Pluto and Neptune to any point in their orbits, the closest they could ever get is 2.4 AU. However, this minimum distance can never occur.
Pluto and Neptune have resonant orbits. While Pluto makes two revolutions around the Sun, Neptune makes three; so astronomers say Neptune and Pluto are in a 3:2 resonance. This orbital relationship limits the minimum distance between the two planets. They never get closer than about 16 AU.
Anyway, I love this upcoming orbital update! Great work!
-
Unlike stars, the orbits of planets may cross due to their eccentricity (like Pluto and Neptune).
I'm pretty sure that the orbits of Pluto and Neptune do not cross.
In the real universe, they do not. Within Aurora, because the tactical map for any given system is 2D, they do.
-
I'm pretty sure that the orbits of Pluto and Neptune do not cross.
Pluto moves closer to the Sun than Neptune in part of its orbit, so I was using 'cross' in that sense as Aurora is displayed in 2D. However, that does provide a good real-life example of why crossing orbits in Aurora won't result in collisions, because the bodies involved could be at different inclinations to the plane of the ecliptic.
-
With the new orbital changes, what orbit does ʻOumuamua get? Did you go with a really big ellipse or an actual hyperbola?
At the moment the program only handles eccentricity less than 1, so I deleted it for now until I figure out the answer to that question :)
-
The new changes to system generation are exciting to say the least. Moving the version to 2.0 is an intimidating prospect, I'll venture to say...
I did have one thought regarding the changing colony costs, which is the interaction with civilian shipping. Presently, civilian ships will tote colonists to any colony set as a destination which has some room. They sometimes overfill a bit but generally they get this about right. However with the new planet eccentricity, say I colonize Mars and place some infrastructure while it is closer to the sun, CC=2.11, and the civilians decide to fill it up with colonists. When mars orbits "away" and the CC rises to 2.5ish, those colonists will suddenly be too much for the life support.
So will civilian logic be changed to work on the body maximum CC in this case? Or maybe it already does and I don't know that because I never put colonists on comets?
Civilian colony ships will check population capacity based on the current infrastructure and the max colony cost. Civilian freighters will deliver infrastructure based on the infrastructure requirements of the destination at max colony cost.
-
One other factor is that the available manufacturing population may change during orbits as colonists are required to focus more on environmental concerns. The economics window will therefore show min and max manufacturing populations where there is a difference.
Here is a population with a difference in current and max colony cost.
(http://www.pentarch.org/steve/Screenshots/Eccentric012.PNG)
This population has no difference, so there is no need to display both numbers.
(http://www.pentarch.org/steve/Screenshots/Eccentric014.PNG)
-
Supported Population must be "Current / Min", I think, not "Current / Max".
-
Supported Population must be "Current / Min", I think, not "Current / Max".
Yes, I was thinking population at max colony cost - but you are correct that min is far better.
-
What about variations in carrying capacity? If a planets hydrosphere is at about 100%, you could have relatively large deviations in carrying capacity on small bodies due to temperature changes reducing/increasing hydrosphere slightly. Though I could be exaggerating that since I don't know the numbers.
-
What about variations in carrying capacity? If a planets hydrosphere is at about 100%, you could have relatively large deviations in carrying capacity on small bodies due to temperature changes reducing/increasing hydrosphere slightly. Though I could be exaggerating that since I don't know the numbers.
A temperature change could theoretically turn oceans into water vapour and therefore change the hydro extent to zero. However, if the planet is in that orbit, the liquid oceans would probably not have formed in the first place. Otherwise hydro extent is not affected by temperature beyond the tiny percentage that would turn to vapour if ice sheets became oceans.
I think the vapourising oceans scenario is rare enough to not list it on the economics window for every population.
-
I am generating some systems to test generation and display and noticed something interesting. A superjovian in one system has caused a gas giant with 30 moons to move into an orbit with 0.81 eccentricity. Some of the moons are varying between 4 and 8 colony cost. A colony cost 4 moon is generally a candidate for mining if there are suitable deposits, perhaps with some terraforming, but colony cost 8 is not really practicable even with terraforming (due to the low base temp).
However, in this case you could have a moon that was a mining candidate for part of the parent's orbital period, or was at full production for part of that orbit and moved to limited production when workers shifted to environmental. Also, this particular gas giant has an orbital period of 66 years, so the moon could be a good mining colony for 30-40 years before being abandoned.
It looks like there is potential for many interesting situations and some meaningful new choices.
-
So you can put orbital habitats over the twin planet right?
And can you manually add them in SM mode or at least change the chance of it happening?
And can you have more than one at once or is it just a twin?
-
So you can put orbital habitats over the twin planet right?
And can you manually add them in SM mode or at least change the chance of it happening?
And can you have more than one at once or is it just a twin?
You can put orbital habitats on either of the two bodies, but one is orbiting the other so you have to choose between them. In game mechanics terms, the twin planet is a moon almost as large as the first planet. There are no triple planets.
-
Since system generation is currently being looked at, can we expect the return of nebulas and black holes? With nebulas I wonder if we could have "starless" systems that don't actually contain a star yet but is essentially just a conglomerate of rogue planets.
-
Since system generation is currently being looked at, can we expect the return of nebulas and black holes? With nebulas I wonder if we could have "starless" systems that don't actually contain a star yet but is essentially just a conglomerate of rogue planets.
I left out black holes because the VB6 interpretation was too gamey. In C# mechanics terms, a black hole would just be a system primary with no more ability to suck in ships than any equivalent mass star. I might add them, but it would be for flavour rather than any new mechanics. If I make them really massive, it could be a system with no planets but potentially a lot of jump points (as higher mass primaries tend to generate more jump points) and it would be very hard to survey due to the high point cost for massive stars.
Nebulae have been low priority because I tend to play real stars (and there are no nearby nebulae) and the VB6 nebula mechanics are tricky for the AI to handle correctly. I may still add them, but probably with different mechanics. I doubt they would be starless as the formation of stars and planets is tied together. However, rogue planets is something I have been considering as a add-on to existing generation.
-
Since system generation is currently being looked at, can we expect the return of nebulas and black holes? With nebulas I wonder if we could have "starless" systems that don't actually contain a star yet but is essentially just a conglomerate of rogue planets.
This would be very cool and likely a popular change. I for one do not mind if 1.14/2.0 is delayed to add such a cool feature, as I have plenty to keep me busy in 1.13 1.12 anyways. :)
Since system generation is currently being looked at, can we expect the return of nebulas and black holes? With nebulas I wonder if we could have "starless" systems that don't actually contain a star yet but is essentially just a conglomerate of rogue planets.
I left out black holes because the VB6 interpretation was too gamey. In C# mechanics terms, a black hole would just be a system primary with no more ability to suck in ships than any equivalent mass star. I might add them, but it would be for flavour rather than any new mechanics. If I make them really massive, it could be a system with no planets but potentially a lot of jump points (as higher mass primaries tend to generate more jump points) and it would be very hard to survey due to the high point cost for massive stars.
Nebulae have been low priority because I tend to play real stars (and there are no nearby nebulae) and the VB6 nebula mechanics are tricky for the AI to handle correctly. I may still add them, but probably with different mechanics. I doubt they would be starless as the formation of stars and planets is tied together. However, rogue planets is something I have been considering as a add-on to existing generation.
If the mechanics are different that would not be a problem, the value of nebulae and black holes is flavor more than mechanics I think with mechanical differences serving to make them interesting in a general sense. The specific VB6 mechanics are not IMO essential.
I like this idea of black holes being effectively large, planetless stars. It may not be as tactically interesting as the super-gravity effect but it would add an interesting flavor to the galactic map topography to have a system which is difficult to survey or traverse but has a very large concentration of jump points.
For nebulae it may be worth changing the mechanics to be a drag force that reduces speed by some fraction instead of a hard cap, and allowing missiles subject to the same force. This would still lead to a situation where beams are advantageous, since the slower missiles are vulnerable to beam PD (and AMM efficiency is unaffected), but the NPRs won't be crippled for example if they can't figure out that missiles shouldn't be in a nebula.
-
Whilst you are modifying orbits, could you make displaying the orbit of an object also be visible when zoomed close in? I find it annoying that I lose the display of the orbit to soon when zooming in.
-
Since system generation is currently being looked at, can we expect the return of nebulas and black holes? With nebulas I wonder if we could have "starless" systems that don't actually contain a star yet but is essentially just a conglomerate of rogue planets.
I left out black holes because the VB6 interpretation was too gamey. In C# mechanics terms, a black hole would just be a system primary with no more ability to suck in ships than any equivalent mass star. I might add them, but it would be for flavour rather than any new mechanics. If I make them really massive, it could be a system with no planets but potentially a lot of jump points (as higher mass primaries tend to generate more jump points) and it would be very hard to survey due to the high point cost for massive stars.
Nebulae have been low priority because I tend to play real stars (and there are no nearby nebulae) and the VB6 nebula mechanics are tricky for the AI to handle correctly. I may still add them, but probably with different mechanics. I doubt they would be starless as the formation of stars and planets is tied together. However, rogue planets is something I have been considering as a add-on to existing generation.
The idea of black holes acting as an interstellar junction of sorts IMO is unique enough on it's own. As for nebulae I wasn't necessarily saying that they should be starless systems all the time but just that there might be a tiny chance that they can be starless (because the nebulae might be super young and the star hasn't formed yet).
-
I have suggestions for Nebulas while we are on the subject.
In the game Empire at War, Nebulas on maps reduce or turn off shields and make ships harder to hit while they are inside of them but also harder for ships inside to hit things outside. You could possibly do this by having the nebulas inflict penalties in fleets. Just my suggestion since idk how viable that would be. You could also have it so they reduce sensor signature so you could hide fleets in it if you...wanted to since Stealth ships arent really a thing from what i can tell.
-
From the changes list:
Wide System View
v2.0 has a wide system view option, similar to the wide view for the class window. The only difference is an extension of the system body list to show an extra six columns. The wide version of the window is 1900 pixels vs 1440 for the normal view.
The system view also has several new fields connected to eccentric orbits.
The picture attached to this post shows a column for "Inclination." Does this have a different meaning for 2D orbits that I'm not aware of? Because these are most definitely not the actual inclinations of the planets, and the game doesn't really model inclination as far as I'm aware so it's kind of strange to see it listed. Is this supposed to be the argument of periapsis or something like that? I don't really know orbital mechanics -- anyone who actually does feel free to chime in here.
-
Maybe it is time to make wide view as default for both system and class windows and rename normal view to something like reduced view.
-
Maybe it is time to make wide view as default for both system and class windows and rename normal view to something like reduced view.
If Aurora would save the setting for each window globally for your game that would be great. So anybody can choose his own preference.
-
I think wide is a better default.
-
I think wide is a better default.
I think so too :) but Aurora is designed to work within 1440x900 so non-wide is the default. Its easier for people with large screens to make the windows wide than the reverse. Especially for new players who may not understand what they are seeing. Once clicked the windows will stay wide until you close the game, so its only two clicks per session.
-
The picture attached to this post shows a column for "Inclination." Does this have a different meaning for 2D orbits that I'm not aware of? Because these are most definitely not the actual inclinations of the planets, and the game doesn't really model inclination as far as I'm aware so it's kind of strange to see it listed. Is this supposed to be the argument of periapsis or something like that? I don't really know orbital mechanics -- anyone who actually does feel free to chime in here.
Inclination in 3D space is the angle by which an orbit deviates from the plane of the ecliptic. In Aurora, I am using it to represent the direction in which the orbit stretches away from the star, which is the opposite direction to the argument of perihelion.
It might not be the correct term from an orbital mechanics perspective, but inclination isn't used in 2D space so I borrowed it to use as a simple term for orbital 'stretchiness' :)
-
--- Did we ever get the fighters not unloading colonists bug fixed for 1.14(2.0)? I and someone else reported that they were still broke, but I don't see a fix in the changelog or the v1.1.3 bugs post...
Posting this here for visibility. :)
-
With the new orbit mechanic it would be nice if we could have some automation with the terraforming installation. It could add or remove green gas to try keeping the temperature to acceptable level.
-
Whoa we get seasons now, that's so damn cool.
It would be interesting if a world oscillated between all the hydrosphere freezing and melting, image how chaotic that would be for habitants.
edit: I guess it's not quite season which are based on tilt but similar in practice except planetwide.
-
It would be interesting if a world oscillated between all the hydrosphere freezing and melting, image how chaotic that would be for habitants.
Yes, you should see that happen for planets with the right orbits.
-
I think wide is a better default.
I think so too :) but Aurora is designed to work within 1440x900 so non-wide is the default. Its easier for people with large screens to make the windows wide than the reverse. Especially for new players who may not understand what they are seeing. Once clicked the windows will stay wide until you close the game, so its only two clicks per session.
Well, this is more of a pain than just changing the default, but you might look at inspecting the display resolution to determine the initial wideness setting.
-
I was wondering if it will be possible to limit population to the higher Colony cost with the present infraestructure to avoid accidental genocide.
-
I was wondering if it will be possible to limit population to the higher Colony cost with the present infraestructure to avoid accidental genocide.
Steve confirmed earlier in the thread that the civilians will consider the max colony cost when shipping colonists. Beyond that, as is tradition the onus is on the player. ;)
-
I was wondering if it will be possible to limit population to the higher Colony cost with the present infraestructure to avoid accidental genocide.
Steve confirmed earlier in the thread that the civilians will consider the max colony cost when shipping colonists. Beyond that, as is tradition the onus is on the player. ;)
As far as I can tell, natural population growth ignores the max colony cost. This must be the Aurora equivalent of real-life people building homes on volcanoes, in floodplains, in the path of hurricanes, etc.
-
I was wondering if it will be possible to limit population to the higher Colony cost with the present infraestructure to avoid accidental genocide.
Steve confirmed earlier in the thread that the civilians will consider the max colony cost when shipping colonists. Beyond that, as is tradition the onus is on the player. ;)
As far as I can tell, natural population growth ignores the max colony cost. This must be the Aurora equivalent of real-life people building homes on volcanoes, in floodplains, in the path of hurricanes, etc.
Yes, but this has always been the case. Personally, I just live with it and if the population overexpands slightly and then a few thousand more people die off in the next increment I chalk it up to the cycle of life. This may be harsh and unforgiving of me, but then again that is the nature of colonial life and I do not make the rules.
-
This is going to be a much bigger issue since the cost can fluctuate so much.
-
Steve, can you explain how do we know at which point of colony cost projection, the planet is currently?
Since on the first screen, Mars's current Colony Cost is at 2.05 but the first week of the first period is 2.54 (shouldn't it start from 2.05?). Can you explain in detail how to read it?
-
I was wondering if it will be possible to limit population to the higher Colony cost with the present infraestructure to avoid accidental genocide.
Steve confirmed earlier in the thread that the civilians will consider the max colony cost when shipping colonists. Beyond that, as is tradition the onus is on the player. ;)
As far as I can tell, natural population growth ignores the max colony cost. This must be the Aurora equivalent of real-life people building homes on volcanoes, in floodplains, in the path of hurricanes, etc.
Pop growth will go to zero or less if the amount of infrastructure is insufficient at the current colony cost. However, if there is room to expand the population will keep growing even if that room may vanish later in the orbit.
-
Steve, can you explain how do we know at which point of colony cost projection, the planet is currently?
Since on the first screen, Mars's current Colony Cost is at 2.05 but the first week of the first period is 2.54 (shouldn't it start from 2.05?). Can you explain in detail how to read it?
Its a bug. The colony cost projection wasn't taking the direction eccentricity into consideration. Fixed now.
The new orbital mechanics are a lot more complex, due to the combination of eccentric orbits and direction of eccentricity within an xy coordinates system (which is being translated from polar coordinates in some situations), which means more scope for bugs. I'll be finding and fixing those over the next few weeks.
-
This last wave of changes goes above and beyond, as the best set of non-QoL changes since launch in my opinion. Your performance considerations, selective abstractions, and solid concepts makes me feel the need to congratulate you for making this possible. And while I am at it, thanks to everyone else for being here making this community great
-
The picture attached to this post shows a column for "Inclination." Does this have a different meaning for 2D orbits that I'm not aware of? Because these are most definitely not the actual inclinations of the planets, and the game doesn't really model inclination as far as I'm aware so it's kind of strange to see it listed. Is this supposed to be the argument of periapsis or something like that? I don't really know orbital mechanics -- anyone who actually does feel free to chime in here.
Inclination in 3D space is the angle by which an orbit deviates from the plane of the ecliptic. In Aurora, I am using it to represent the direction in which the orbit stretches away from the star, which is the opposite direction to the argument of perihelion.
It might not be the correct term from an orbital mechanics perspective, but inclination isn't used in 2D space so I borrowed it to use as a simple term for orbital 'stretchiness' :)
Why not just call it the argument of the perhelion then, so that everyone would know what you meant? (Or argument of the periapsis, to be more generic?)
-
The picture attached to this post shows a column for "Inclination." Does this have a different meaning for 2D orbits that I'm not aware of? Because these are most definitely not the actual inclinations of the planets, and the game doesn't really model inclination as far as I'm aware so it's kind of strange to see it listed. Is this supposed to be the argument of periapsis or something like that? I don't really know orbital mechanics -- anyone who actually does feel free to chime in here.
Inclination in 3D space is the angle by which an orbit deviates from the plane of the ecliptic. In Aurora, I am using it to represent the direction in which the orbit stretches away from the star, which is the opposite direction to the argument of perihelion.
It might not be the correct term from an orbital mechanics perspective, but inclination isn't used in 2D space so I borrowed it to use as a simple term for orbital 'stretchiness' :)
Why not just call it the argument of the perhelion then, so that everyone would know what you meant? (Or argument of the periapsis, to be more generic?)
Two reasons:
1) Let's assume for a moment that most people playing Aurora don't know the technical terms for orbital mechanics. In that case, inclination is going to make more sense than 'argument of perihelion' given its use in common English. On the same grid I use diameter for clarity when I should use radius, 'day' instead of sidereal rotation, and reverse Albedo values because it makes the use of Albedo in the game more obvious.
2) The column isn't wide enough :)
-
and reverse Albedo values because it makes the use of Albedo in the game more obvious.
This one has always confused me when I looked up the albedo of any planetary bodies on wikipedia.
-
After giving it some thought and listening to feedback on my current campaign, I have decided to change the design philosophy of Aether Raiders. Rather than being focused on speed and additional ECM, they will have cloaking devices and thermal reduction technology. Speed and ECM will be 'normal' for a race of their general tech level.
The primary reason for the change is that high speed, short-range missiles and/or fast beam fighters are probably the best way to counter high speed / high ECM and I don't want to force players (or myself) to adopt a specific philosophy. The new raiders, which I will test in the same campaign as the new orbital mechanics, will be hard to track down, but no more difficult to destroy than other similar tech level ships. Guarding against them and hunting them down will now be viable with a wider range of design philosophies.
EDIT: Their starting research points are also being reduced from Precursor-level to about 2/3rds Precursor-level.
-
I'm a space nerd and I had never heard of "argument of the perihelion" so using inclination is indeed probably better in that it's more intuitive to understand even if its technically incorrect.
Guarding against them and hunting them down will now be viable with a wider range of design philosophies.
Hooray! It was starting to look like the Raiders were going to only show in a single game where I get my ass kicked and then turned off because there's only one way to deal with them.
-
Yes, I was about to turn them off for the new campaign and then thought that decision through a little more :)
I'm also going to reduce their starting RP a little as they progress quite quickly with no need to consider non-combat techs.
-
and reverse Albedo values because it makes the use of Albedo in the game more obvious.
This one has always confused me when I looked up the albedo of any planetary bodies on wikipedia.
I use the reverse value so the temp formula is obvious, plus most people aren't checking what albedo really means. Even if you do check the Sol system bodies, the albedo I use in the DB won't match because it is rigged to create the right temperatures for the system generation mechanics in Aurora (because in real life temperature is affected by more factors than are considered in Aurora).
-
After giving it some thought and listening to feedback on my current campaign, I have decided to change the design philosophy of Aether Raiders. Rather than being focused on speed and additional ECM, they will have cloaking devices and thermal reduction technology. Speed and ECM will be 'normal' for a race of their general tech level.
The primary reason for the change is that high speed, short-range missiles and/or fast beam fighters are probably the best way to counter high speed / high ECM and I don't want to force players (or myself) to adopt a specific philosophy. The new raiders, which I will test in the same campaign as the new orbital mechanics, will be hard to track down, but no more difficult to destroy than other similar tech level ships. Guarding against them and hunting them down will now be viable with a wider range of design philosophies.
EDIT: Their starting research points are also being reduced from Precursor-level to about 2/3rds Precursor-level.
This is excellent, since Raiders are now probably viable to have along with Precursors and Rakhas as spoilers in a conventional or low-tech TN start - though still as quite a challenge.
-
Why not just call it the argument of the perhelion then, so that everyone would know what you meant? (Or argument of the periapsis, to be more generic?)
Two reasons:
1) Let's assume for a moment that most people playing Aurora don't know the technical terms for orbital mechanics. In that case, inclination is going to make more sense than 'argument of perihelion' given its use in common English. On the same grid I use diameter for clarity when I should use radius, 'day' instead of sidereal rotation, and reverse Albedo values because it makes the use of Albedo in the game more obvious.
Hmm. If I understand you correctly, you are positing the existence of an entire class of people who both play Aurora but also don’t remember the orbital elements from middle–school? That’s crazy talk.
2) The column isn't wide enough :)
Well… I guess columns can be made as wide as they need to be. It’s even easier to do if you use an actual grid view :)
But that column would be a lot wider than the others, which some might find unaesthetic, I suppose. Or you could just label it 𝜔 instead. We have Unicode for a reason.
-
Hmm. If I understand you correctly, you are positing the existence of an entire class of people who both play Aurora but also don’t remember the orbital elements from middle–school? That’s crazy talk.
Orbital mechanics is not middle school, I have a 30 year old physics degree and I did not remember that terminology it is certainly not common knowledge. I probably came across it in A-Level or University Physics or maths but the number of people who take those qualifications is not high and the number who remember all the details after 30 years of not using them is lower. (Or their foreign equivalants)
-
We were taught basic orbital mechanics in my high school.
It was so poorly done i just went and researched it on my own.
Really on Astrophysicists and Sci-Fi writers actually use the terminology to be honest.
Unless you spend a lot of time on Atomic Rockets and read about orbital mechanics for fun like i do.
-
Hmm. If I understand you correctly, you are positing the existence of an entire class of people who both play Aurora but also don’t remember the orbital elements from middle–school? That’s crazy talk.
Orbital mechanics is not middle school, I have a 30 year old physics degree and I did not remember that terminology it is certainly not common knowledge. I probably came across it in A-Level or University Physics or maths but the number of people who take those qualifications is not high and the number who remember all the details after 30 years of not using them is lower. (Or their foreign equivalants)
Yeah, gotta say that I hadn't recalled that term from my OU Cosmology & Planetary Science course last century (did find it when I went and looked up the textbooks tho)
-
I was being somewhat facetious. I do expect the better students to have learned enough that they know why we use the orbital elements instead of just an XYZ position and a momentum in each of the XYZ directions and that they could recreate the orbital elements by combining other bits of knowledge of geometry and physics, but there’s really very little need for the average person to memorize their customary names.
The actual names are a mixed bag. Inclination and eccentricity are ok because they are both words that people use or hear from time to time, with analogous meanings. “Longitude of the ascending node” is wordy but understandable. But “argument of the periapsis” is downright obscure, and “true anomaly” is completely terrible.
I still think that misusing the word “inclination” merely because it is short is a bad idea. Can we come up with any other word or phrase at all, and use that instead? Maybe just call it the “angle of the long axis” or something. Does anyone else have any suggestions?
-
I still think that misusing the word “inclination” merely because it is short is a bad idea. Can we come up with any other word or phrase at all, and use that instead? Maybe just call it the “angle of the long axis” or something. Does anyone else have any suggestions?
How about "orientation"?
-
After giving it some thought and listening to feedback on my current campaign, I have decided to change the design philosophy of Aether Raiders. Rather than being focused on speed and additional ECM, they will have cloaking devices and thermal reduction technology. Speed and ECM will be 'normal' for a race of their general tech level.
The primary reason for the change is that high speed, short-range missiles and/or fast beam fighters are probably the best way to counter high speed / high ECM and I don't want to force players (or myself) to adopt a specific philosophy. The new raiders, which I will test in the same campaign as the new orbital mechanics, will be hard to track down, but no more difficult to destroy than other similar tech level ships. Guarding against them and hunting them down will now be viable with a wider range of design philosophies.
EDIT: Their starting research points are also being reduced from Precursor-level to about 2/3rds Precursor-level.
For what it's worth, I'm glad to hear this. I think the idea of a special enemy that somewhat negated the most common tactics was actually a really cool one, but sadly I think their old form just wasn't a great fit for Aurora mechanics as they stand. Kind of reminds me of why the X-Com devs said they didn't put EXALT assault soldiers in the game - yes, it added new tactics, but it also made their playtesters scream in frustration when an enemy crossed to entire screen to slide into a flank and one shot the player's best soldier with a point blank shotgun.
Cloaked and thermal dampened raiders are going to be interesting since it's not a matter of having enough firepower to stop them, but protecting your more fragile assets.
-
I still think that misusing the word “inclination” merely because it is short is a bad idea. Can we come up with any other word or phrase at all, and use that instead? Maybe just call it the “angle of the long axis” or something. Does anyone else have any suggestions?
How about "orientation"?
That works!
-
I haven't gone through this whole thread but I noticed on your patch / dev notes calling the new version v2.0, so I am guessing its not gonna be called v1.14 anymore cause you added so many new and cool features?
-
I haven't gone through this whole thread but I noticed on your patch / dev notes calling the new version v2.0, so I am guessing its not gonna be called v1.14 anymore cause you added so many new and cool features?
Yes, going to be v2.0 now. I'm not changing the thread title though to avoid confusion over the many posts that talk about v1.14 as the next one.
-
Yes, going to be v2.0 now. I'm not changing the thread title though to avoid confusion over the many posts that talk about v1.14 as the next one.
Maybe "v1.14.0 / v2.0 Changes Discussion Thread"?
-
re: new interrupts - now how am I going to RP my fleets being commanded by complete idiots who sat staring blankly at a wall for 5 days until they suddenly exploded?!?
(it's me, the complete idiot is always me)
-
Good change to NPR generation to ensure that they are not beyond the capability of the player to deal with.
Would be great to see this paired with a parallel change to help keep newly generated NPRs from being so easily outpaced by the players. I've mentioned previously that uncapping the initial number of labs, etc. would be a big help with this as newly generated NPRs are currently limited to 50 initial labs regardless of population.
-
Would it make more sense to calculate the average colony cost for elliptical orbits? It just seems like there's a lot of extra calculations with the new eccentricity system that could lead to a serious performance hit.
-
Would it make more sense to calculate the average colony cost for elliptical orbits? It just seems like there's a lot of extra calculations with the new eccentricity system that could lead to a serious performance hit.
Taking an average would take away some of the fun scenarios that Steve is hoping to get out of this - like planets that are in the perfectly habitable range at one side of their orbit, but end up way out past the Oort cloud at the other end. As it currently is, depending on how long the orbit is and where in its orbit the planet currently is, you might get many (Earth) years worth of use out of the planet before it starts freezing; whereas an average would just cause the planet to be useless.
-
Would it make more sense to calculate the average colony cost for elliptical orbits? It just seems like there's a lot of extra calculations with the new eccentricity system that could lead to a serious performance hit.
Performance doesn't seem to be suffering so far. I've just started a new campaign though, so I will see how it goes once there are a lot of systems in play. Besides, this is an optional change.
As someone else replied, the object of the change is to create interesting scenarios for colonies. I've already found a couple of terrestrial worlds with temperature ranges that are so wide that you cannot terraform them to ideal, but you can bring the colony cost to a fairly low amount. The planet I am currently terraforming has a 64 degree difference. If you terraform to the middle of the human tolerance range (which I am trying to do now), the planet will move between -18C and 46C during its orbit, exceeding human tolerance by 8 degrees at either end of the range, which makes it very interesting from a roleplay/story perspective.
-
If you terraform to the middle of the human tolerance range (which I am trying to do now), the planet will move between -18C and 46C during its orbit, exceeding human tolerance by 8 degrees at either end of the range, which makes it very interesting from a roleplay/story perspective.
Also don't forget that, at some point, Gene Manipulation comes into play. ;)
-
Are populations smart enough to remember to continue to build themselves infrastructure during the good times, knowing that the planet will become inhospitable?
-
Performance doesn't seem to be suffering so far. I've just started a new campaign though, so I will see how it goes once there are a lot of systems in play. Besides, this is an optional change.
I just checked my current campaign. At the moment there are 21 systems with a total of 2876 system bodies, of which 509 have eccentric orbits and 582 more are moons of bodies with eccentric orbits. Those 1091 bodies are being updated during orbital movement as if they were being terraformed. Orbital movement is currently taking 0.01 seconds. I'll keep an eye on it as the number of systems increases.
EDIT: Looks like above was unusual. I checked twice more and it was less than 0.003 seconds each time.
-
Are populations smart enough to remember to continue to build themselves infrastructure during the good times, knowing that the planet will become inhospitable?
Yes, infrastructure is based on max colony cost, not current.
-
Hmm. If I understand you correctly, you are positing the existence of an entire class of people who both play Aurora but also don’t remember the orbital elements from middle–school? That’s crazy talk.
I went to Uni for Physics and studied astronomy, and the reason i know what i do about orbital mechanics is because of Kerbal Space Program...
-
Maybe update the title of the thread , something like V1.14.0 (now V2.0 ) etc thread.
-
Would it make more sense to calculate the average colony cost for elliptical orbits? It just seems like there's a lot of extra calculations with the new eccentricity system that could lead to a serious performance hit.
Performance doesn't seem to be suffering so far. I've just started a new campaign though, so I will see how it goes once there are a lot of systems in play. Besides, this is an optional change.
As someone else replied, the object of the change is to create interesting scenarios for colonies. I've already found a couple of terrestrial worlds with temperature ranges that are so wide that you cannot terraform them to ideal, but you can bring the colony cost to a fairly low amount. The planet I am currently terraforming has a 64 degree difference. If you terraform to the middle of the human tolerance range (which I am trying to do now), the planet will move between -18C and 46C during its orbit, exceeding human tolerance by 8 degrees at either end of the range, which makes it very interesting from a roleplay/story perspective.
I like the new orbital stuff, but do you have any plans for colony management tools for dealing with the temp swings, automated or manual? It seems reasonable that the settlers would be aware of the effects of the eccentric orbit, and have plans to mitigate their effects instead of just dying in droves. Pop caps (to allow for reserve infracture; cap could be set using max CC & available infrastructure, or manually), mass hibernation complexes (stop the entire colony, but allow them to ride it out without mass death), A way to depopulate a planet without abandoning it (to allow for, say, a mining outpost to operate for 30 years, be evaced for a decade or two, then bring workers back once the CC comes back down).
In general, some way to gather excess in times of plenty to guard against times of need, whatever form that takes.
Without some sort of controls, the RP opportunities for this system seem a little slim to me. I have a hard time imagining why people would willing live on a planet that is regularly uninhabitable without some means of preparing for those times (unless you're rolling with a dictatorial government, but that's only one way to play).
These sort of systems could also be the starting point for a disaster/event system, if that strikes your fancy at some point down the line.
-
Without some sort of controls, the RP opportunities for this system seem a little slim to me. I have a hard time imagining why people would willing live on a planet that is regularly uninhabitable without some means of preparing for those times (unless you're rolling with a dictatorial government, but that's only one way to play).
It seems like the underlying "issue" people are bringing up is not that there's no RP opportunities, but rather that the RP opportunities require player attention and (micro?)management. In other words, it looks to me like players are complaining that there is not enough automation to make the RP "worth it" for them.
From what I gather it seems like the RP opportunities, i.e. why Steve likes this new design so much, is because the player does have to pay attention to their colonies instead of just setting them on autopilot and checking every couple years to make sure the civvies haven't depopulated Earth again. The idea is to add gameplay for colony management. So I think to some extent it is maybe not in keeping with this design to expect a lot of automation which would just be turned on by most players and ignored, and where is the fun in that?
Personally I think this all sounds extremely interesting with the variety of different colony sites that can exist. However I do also like to play more slowly than many people so I am sure not everyone will find it to their own taste. Other people who do not appreciate the added management always have the option of only colonizing up to the max CC limit and accepting some inefficiency, or plopping AMs everywhere like we already do anyways.
-
Yeah, nothing forces you to colonize a planet which turns hostile at some point of its orbit. I'm guessing that most planets just vary slightly in their CC if at all. I agree with nuclearslurpee, it seems to me as well that this feature is to add more work for the player in colony management - if they so choose.
-
Without some sort of controls, the RP opportunities for this system seem a little slim to me. I have a hard time imagining why people would willing live on a planet that is regularly uninhabitable without some means of preparing for those times (unless you're rolling with a dictatorial government, but that's only one way to play).
It seems like the underlying "issue" people are bringing up is not that there's no RP opportunities, but rather that the RP opportunities require player attention and (micro?)management. In other words, it looks to me like players are complaining that there is not enough automation to make the RP "worth it" for them.
From what I gather it seems like the RP opportunities, i.e. why Steve likes this new design so much, is because the player does have to pay attention to their colonies instead of just setting them on autopilot and checking every couple years to make sure the civvies haven't depopulated Earth again. The idea is to add gameplay for colony management. So I think to some extent it is maybe not in keeping with this design to expect a lot of automation which would just be turned on by most players and ignored, and where is the fun in that?
I'm not sure automation is what was being asked for. Of the ideas mentioned in the post (pop caps, mass hibernation complexes, and a way to depopulate a planet without abandoning it), two out of three seem like they would be manual tools. I think at present there's just a dearth of colony management options, automated or otherwise. The concern as I see it is that the tools currently in the game (setting a colony as a destination/source of colonists, restricting it to military traffic, etc.) might not be powerful or flexible enough to deal with really difficult planets, and trying to do so might end up more frustrating than challenging. (Personally, I expect to greatly enjoy the new update regardless of whether Steve adds any new colony management options, but I can definitely see where the concern is coming from.)
-
Steve, can you talk a bit about the technical details of your implementation of non–circular orbits? Do you differentiate between circular and non–circular orbits, or are all orbiting bodies advanced using the same code? Do you use a function that only handles ellipses, or did you use the closed–form solution for the general two–body problem (for example, see https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19660027556.pdf)? I’m assuming the former, since you said you hadn’t yet decided how to handle ʻOumuamua.
-
is because the player does have to pay attention to their colonies instead of just setting them on autopilot and checking every couple years to make sure the civvies haven't depopulated Earth again. The idea is to add gameplay for colony management.
. . .
So I think to some extent it is maybe not in keeping with this design to expect a lot of automation which would just be turned on by most players and ignored, and where is the fun in that?
As it stands, we have very limited means of interacting with the colonies along those lines. What I'm asking for in a general sense is a way to interact with the new system. The temp swings will only add micromanagement if we don't have some way of interfacing with them.
Say you decide to set up a mining colony on a body that will be very high CC in 20 years. How is the player supposed to interact with the colony as the CC creeps up over the years, before it spikes to the max value, and slowly comes back down? You can't prepare ahead of time by shipping excess colonists out, because the more you ship out the faster natural growth will refill it. Even when the pop is reduce to 0, there is still somehow natural growth. As it stands, all you can really do is either deal with the "unrest due to overpopulation" messages until everyone dies off, or futilely fight against the pops trying to move into infrastructure that will be needed to keep everyone alive later by sending colony ships continuously at them.
If the extent of automation is checking a box and forgetting about an entire game system, you have a point. But the way you fix that is by making the process of setting up the automation interesting. Look no further than factorio to see how automating the tedium away can be fun in and of itself.
My suggestions weren't completely off-the-cuff:
Pop caps could be a simple as not letting pops grow into more infracture than will be needed at max CC, they could be manually set, or they could be some combo of automatic and manual. This would effectively allow the player to earmark infrastructure as emergency use only.
Mass hibernation complexes would be something you'd need to build, and each one would only hold so many pops. Their travel weight and production costs could be high or low for different balance reasons. They would allow the player to essentially pause the planet, and could have a startup and shutdown time (like industries in VB). This would make the planet useless while hibernating, but would prevent people dying by the millions, and bypasses the issue of trying to fight against the repopulation systems.
A way to depopulate an planet without abandoning it could be as simple as a button that stops colony ships dropping off colonists and stops any natural pop growth (with a hit to unrest or other downside to prevent abuse). This would allow the population to be evacuated en-mass for an indeterminate amount of time without more people growing from rocks or whatever. A second button could even be added, marking the colony as "being evaced", which would allow the civil colony ships to reduce the population to zero (the government might have to pay the civs instead of the reverse for this service).
I'm not picky about the tools we're given to interact with the new system. But we currently don't have any tools I'm aware of to do anything that's not inefficient, micro-intensive, and involves fighting against other game systems.
-
You can't prepare ahead of time by shipping excess colonists out, because the more you ship out the faster natural growth will refill it. Even when the pop is reduce to 0, there is still somehow natural growth. As it stands, all you can really do is either deal with the "unrest due to overpopulation" messages until everyone dies off, or futilely fight against the pops trying to move into infrastructure that will be needed to keep everyone alive later by sending colony ships continuously at them.
I don't want to minimize the rest of your post, but...if there is still "natural growth" when the population is reduced to literally zero, this sounds like a bug. The only "WAI" thing I can think of that would cause "natural" growth at 0 pop would be civilian colony ships delivering colonists because they see empty infrastructure, and this can be prevented by checking a box in the colony window.
The natural pop growth, while annoying, is also only 10% per year at most so fighting natural growth with colony ships should certainly not be futile A colony of 10m pop size or larger can be set as a source of colonists only, which will also mobilize the civilian shipping lines to move people offworld, and a smaller colony can only grow by at most 100,000 people per year which is only a couple of colony shiploads. It is entirely possible provided that one knows where the (admittedly limited) controls we do have available can be found - which in fairness many are unaware of some of these controls.
This being said...
My suggestions weren't completely off-the-cuff:
words
It sounds like the #1 thing needed are pop caps and/or a way to turn off natural population growth (again, this is different from civilian shipping-driven growth). This I think is reasonable particularly as natural growth is the cause of many other problems that are more annoying than fun - for example, trying to use orbital habitats on planets like Venus is a management nightmare because pop growth will exceed the habitat capacity as soon as a small bit of "free" infrastructure is built on the planet surface. Some way to tell the population to stop doing stupid things like this makes sense and will probably offer a lot in terms of making colony management easier with the v2.0 changes as well.
-
Steve has said that colonies will build & demand infra for the maximum CC of the body, not the current one and that civilians will not deliver pop to go over the capacity of the infrastructure present.
So, the only problem is natural pop growth if it's too fast which I doubt. Infra production just by civilians is pretty effective providing sufficient infra to counter natural pop growth unless you have several colonies demanding a lot of infrastructure.
-
I like the new orbital stuff, but do you have any plans for colony management tools for dealing with the temp swings, automated or manual? It seems reasonable that the settlers would be aware of the effects of the eccentric orbit, and have plans to mitigate their effects instead of just dying in droves. Pop caps (to allow for reserve infracture; cap could be set using max CC & available infrastructure, or manually), mass hibernation complexes (stop the entire colony, but allow them to ride it out without mass death), A way to depopulate a planet without abandoning it (to allow for, say, a mining outpost to operate for 30 years, be evaced for a decade or two, then bring workers back once the CC comes back down).
In general, some way to gather excess in times of plenty to guard against times of need, whatever form that takes.
Without some sort of controls, the RP opportunities for this system seem a little slim to me. I have a hard time imagining why people would willing live on a planet that is regularly uninhabitable without some means of preparing for those times (unless you're rolling with a dictatorial government, but that's only one way to play).
These sort of systems could also be the starting point for a disaster/event system, if that strikes your fancy at some point down the line.
Colony infrastructure production, civilian delivery of infrastructure and civilian delivery of colonists are all based on max colony cost, not current, so the problems above should not arise. Pop growth is based on current colony cost, so that could exceed the max supported population, but that is similar in a way to living near volcanos or major fault lines. In any event, pop growth going beyond the maximum future supported population and then dying off a little, has no real difference compared to that growth not happening in the first place. I just thought that the former was more likely to happen than the latter, given past human behaviour.
-
reading the new eccentric orbits, wondering that in a binary star system, would planets on those stars consider solar influx, and hence surface temperature and colony cost, from both stars?
-
> military-restricted jump points
That's going to give us a better tool to work around the inefficient pathfinding for civvies
-
reading the new eccentric orbits, wondering that in a binary star system, would planets on those stars consider solar influx, and hence surface temperature and colony cost, from both stars?
No, they only consider the primary. I have the necessary code to account for all stars in the system, but decided it was too difficult for players to effectively consider those factors. Even with eccentric orbits, there is a pattern that it easy to understand. With one or more additional stars involved, each orbit could be different.
-
> military-restricted jump points
That's going to give us a better tool to work around the inefficient pathfinding for civvies
I currently have a system adjacent to Sol that I can reach more quickly by going through three other systems, hence the sudden need for restricted jump points :)
-
> military-restricted jump points
That's going to give us a better tool to work around the inefficient pathfinding for civvies
I currently have a system adjacent to Sol that I can reach more quickly by going through three other systems, hence the sudden need for restricted jump points :)
Always the greatest motivator for new features! ;D
-
> military-restricted jump points
That's going to give us a better tool to work around the inefficient pathfinding for civvies
I currently have a system adjacent to Sol that I can reach more quickly by going through three other systems, hence the sudden need for restricted jump points :)
Always the greatest motivator for new features! ;D
Yea, it’s nice to see improvements in this area. However, I still would like to see the pathfinder take into account distances rather than just having it go off the number of jumps.
-
Yea, it’s nice to see improvements in this area. However, I still would like to see the pathfinder take into account distances rather than just having it go off the number of jumps.
Isn't that exactly why Steve added this feature? The distance through the three other star systems was shorter than the direct route via the Sol jump point. So distance is what counts. Or did I miss something in his postings?
-
If I understand correctly, Steve added this new feature, to force the ships to take path that have more jumps but less distance. So presumably the normal pathfinding would choose route with less jumps but more distance.
So the feature is only workaround not change to pathfinding. I thought that pathfinding worked with distance but apparently that is not the case.
-
If I understand correctly, Steve added this new feature, to force the ships to take path that have more jumps but less distance. So presumably the normal pathfinding would choose route with less jumps but more distance.
So the feature is only workaround not change to pathfinding. I thought that pathfinding worked with distance but apparently that is not the case.
Looking at his comment, it can be understood in both ways. He either had to restrict the three-jump route because it was shorter and quicker (and maybe went through enemy territory?) - this is how I read his statement, thinking that the auto route will choose the shorter route - or he blocked the one-jump to make the auto route go through the three systems, because it is the shorter route.
-
Pathfinding is based on number of systems. It checks adjacent systems, then the ones adjacent to those, etc., until it finds the destination.
I could base it on actual distance in kilometres, but that would be tricky and hit performance. Instead of checking the small subset of systems required to find a valid path, I would have to check all systems to ensure I found the best option. Its also not entirely correct unless I take into account orbital movement, because if a journey takes a few months then the shortest route right now may not be the correct one. All this is going to add a lot of performance overhead and movement is already the phase the takes the longest.
I think having a basic system that you can influence when you need to is better than a more complex system that slows the game down and isn't needed for the vast majority of the time anyway.
-
Pathfinding is based on number of systems. It checks adjacent systems, then the ones adjacent to those, etc., until it finds the destination.
I could base it on actual distance in kilometres, but that would be tricky and hit performance. Instead of checking the small subset of systems required to find a valid path, I would have to check all systems to ensure I found the best option. Its also not entirely correct unless I take into account orbital movement, because if a journey takes a few months then the shortest route right now may not be the correct one. All this is going to add a lot of performance overhead and movement is already the phase the takes the longest.
I think having a basic system that you can influence when you need to is better than a more complex system that slows the game down and isn't needed for the vast majority of the time anyway.
You could use the current system automatically and have a "recalculate distance" button that the player can manually press if performance over time is a problem. That way everyone is happy.
Also in the latest screenshots in the change list, I assume the new purple jump lanes show the military restricted ones, correct?
Also, late game commander window can take 10 seconds + to open every time, this is because the filter applies itself automatically. I think it'd be a good idea to add a "engage filter" button to let the player choose when to filter their officers - that way the commander menu doesn't take too long to open just to look at officers.
-
Pretty please... while you are working on the Galactic map... can we get the ability to double click a system and have that system open in the main tactical map view?
I have wanted to have that feature for so long and it would make it soo much easier when you have allot of systems.
-
Pathfinding is based on number of systems. It checks adjacent systems, then the ones adjacent to those, etc., until it finds the destination.
I could base it on actual distance in kilometres, but that would be tricky and hit performance. Instead of checking the small subset of systems required to find a valid path, I would have to check all systems to ensure I found the best option.
Yep. As a software engineer myself, this did not escape my attention. :)
Its also not entirely correct unless I take into account orbital movement, because if a journey takes a few months then the shortest route right now may not be the correct one.
Quite true. However, orbits are periodic, and it is quite easy to calculate the minimum and maximum distance a planet can ever be from the jump points in the system. The distance between jump points never changes, so the variation only has to be taken into account for the segments at the beginning and the end of the route. If you find two routes where the ranges overlap, just flip a coin :)
Actually, when I say that it is quite easy, I mean that it is quite easy for circular orbits. I concede that it could be horrible for ellipses; ellipses are generally horrible. I suspect that it is easy (that there is a closed–form solution). If so then it will be a solved problem and probably a quick search will turn it up.
Probably you can take the solution for a circle and correct it using the cosine of the difference between the orientation of the ellipse and the bearing from the jump point to the center of the ellipse, plus an offset from the center of the ellipse to the focus. But I would look it up rather than doing the algebra myself.
All this is going to add a lot of performance overhead and movement is already the phase the takes the longest.
I could be wrong, but does the game actually recalculate these routes every tick or subtick? I suspect that it only calculates them when giving new orders to a fleet, either when the user uses the autorouting to order a ship to go to some other system, or when the AI gives a fleet new orders because it has completed the existing orders. Even with thousands of civilian ships there should only be a few that need new orders in any given tick.
And while it does seem like more work to search the whole graph rather than just a convenient subgraph, A* pathfinding on a graph with thousands of nodes should not be a big performance concern. That’s cheaper than A* pathing in an RTS, where units just have to get from one edge of the map to another. The original Starcraft had a map size of 256*256, meaning it was doing A* on a graph with 65,536 nodes, for example. I don’t recall the frame rate suffering when you gave your units orders…
Also, do you cache these routes at all? If not, then simply caching the fastest route the first time you compute it is easy enough. Invalidation needs to happen sometimes when you explore a jump point (or otherwise discover a new link between systems), but only when discovering a new link to a system you already knew about.
You can also cache the minimum and maximum distances between jump points and planets as well; you would only need to do those cosines once.
I think having a basic system that you can influence when you need to is better than a more complex system that slows the game down and isn't needed for the vast majority of the time anyway.
I don’t disagree with this philosophy.
However, I also believe that if we are clever then we can generally squeeze more work out of a computer than we would at first expect. If we are clever enough, we can have our cake and eat it too. In this specific instance, I think that we should be able to have nicer automatic route planning without slowing the game down.
-
The distance between jump points never changes,
This is actually not true as the travel distance between jump points is influenced by Lagrange Points which are subject to orbital mechanics.
It is also important to note that the performance overhead is not necessarily due to the algorithm (A* or otherwise) but also the calculations involved - especially converting between coordinate systems which involves taking cosines and the like. Floating point calculations tend to become very easily the most time-consuming part of these kinds of simulation or game codes, which is different from the case in enterprise software engineering much of the time. Instead of a "simple" A* which is checking discrete nodes, every "node" in Aurora is accompanied by a distance calculation which is likely to dominate the run time and cause the effect on performance Steve is talking about. This real-valued nature of the problem also means that an approach such as caching min/max values is less feasible.
The other big consideration, which Steve has pointed out, is the lack of a useful termination point. With the simple number-of-systems algorithm it is easy - if you can reach System B from System A in five jumps, and no other five-jump combination does the job, mission accomplished! With real-valued distances it is not so easy, you can get from point A to point B in 20.7 billion km over those five jumps, but you have to keep trying all the six, seven, eight, etc. jump paths in case one is shorter. This will not terminate as neatly, particularly because one has to always consider the possibilities of Lagrange points and strange occurrences with JP network loops and the logic for these "edge cases" must be included in the main algorithm.
This isn't saying that such a problem is unsolvable, or cannot be solved efficiently, but it is certainly a good deal more complex than just "use A*" because of the real-valued nature of distances in Aurora. Ultimately I suspect that this complexity and the amount of work to develop and test a well-optimized algorithm is more than Steve wants to put in, and probably not as interesting to work on when Steve could be adding new spoilers, orbital mechanics, and treaty ports. ;)
Also Steve please let us change the rank ratio for ground force officers, 3:1 is so restrictive, thanks.
-
A more sophisticated tree traversal is probably possible. Instead of effectively counting the number of hops, you track total travel distance and sort off of that. So, whatever the current shortest path currently is, you hop again off of that until you reach the destination (instead of re-generating another set of leaf nodes and hopping off of each of them serially).
It would require finding the current shortest path, rather than just flat iteration when expanding the jump point tree, but it wouldn't necessarily be too bad runtime wise.
Allow me to suggest the following algorithm in pseudocode (assume no particular language):
path_type
list<jump_point> path_array; //this is a list of the path elements so far
double current_distance; //length of this path so far in kms
list<path_type> curr_paths
list<system> touched_systems
touched_systems.append(current_system) //wouldnt want to get tripped up by jump points that lead back to the starting point (although that bug is in theory fixed)
// seed the paths list
foreach jump_point in system:
path_type new_path
new_path.path_array.append(jump_point)
new_path.current_distance = distance_to_jp //calculate distance to current jump point from current position of ship somehow, not sure where that information would exist
curr_paths.append(new_path)
touched_systems.append(jump_point.destination)
// while there are potential paths
while !curr_paths.is_empty():
// search for current shortest path
path_type shortest = curr_paths[0]
foreach path in curr_paths:
if path.current_distance < shortest.current_distance:
shortest = path
//remove current shortest path, add derived paths (if any)
curr_paths.remove(shortest)
jump_point curr_jp = shortest.curr_paths[shortest.curr_paths.length - 1]
foreach jump_point in curr_jp.destination.jump_points: //for jump points in at the end of current path
if jump_point.destination not in touched_systems: //only consider systems that havent already been reached by a shorter path
// make a copy of the shortest path for every possible derived route
path_type new_path = shortest
new_path.path_array.append(jump_point)
new_path.current_distance = shortest.current_distance + [distance between curr_jp and jump_point]
if jump_point.destination == final_destination:
return new_path //we found our solution, return the newly generated path
// capture the new derived path
curr_paths.append(new_path)
return failure //didnt find a path
I made up some types to represent jump points and systems, not knowing how they are represented in the game. It should be possible to recreate this with id numbers or whatever, if there isnt a central system type and there are several different structures indexed on system id instead or something.
This is basically a graph-traversal version of A* pathfinding. Its not very effeceint but its relatively simple. Part of the point here is to underline that you dont need to check all possible systems, you can still do a tree traversal and stop once you find a path.
The basic idea of the algorithm is as follows. Keep track of all possible paths, branch on whatever the current shortest path is, and anything that is a dead end (or leads to an already-explored system) naturally falls out of the list, which is good because any already-explored system inherently is reachable by a shorter path.
I'm not sure how LPs and stuff are currently handled, but you could divide current_distance by the speed of the formation to derive the current time when you are exploring any particular node (for purposes of LP location and such), so there is some provision in this example for dealing with that.
e: actually if there are multiple jump points to the destination in the penultimate system, this doesn't deal with finding the shortest out of those options. its probably worth fiddling with further, but this thing would generally speaking find pretty decent solutions and is very simple
-
Make a graph of JPs (w/o Lagrange ones) with a path lengths between those that are in the same pair of systems. Recalculate those lengths every production cycle.
When you have to find a path - run for minimal number of jumps, continue this cycle with additional 3 iterations (memorizing paths), then calc distances for every path and find the shortest.
To use Lagrange JPs more accurate it's possible to get their positions for estimated time of jump into this system. The same with the last trajectory patch (JP to final target) if it's orbital target.
The task will be much easier without Lagrange JPs, and it's not the only problem with them.
They are inconsistent with overall JP narrative (they are visible and usable before JP theory researched!), they are easy and natural way to abuse AI with massive salvos and so on.
Maybe it worth to consider to replace them with static in-system potential JPs to stabilize, smth like 1/2^n distances between central body and every interstellar JP. Or just exterminate them, because not enough game value for too much problems.
-
Make a graph of JPs (w/o Lagrange ones) with a path lengths between those that are in the same pair of systems. Recalculate those lengths every production cycle.
When you have to find a path - run for minimal number of jumps, continue this cycle with additional 3 iterations (memorizing paths), then calc distances for every path and find the shortest.
To use Lagrange JPs more accurate it's possible to get their positions for estimated time of jump into this system. The same with the last trajectory patch (JP to final target) if it's orbital target.
The task will be much easier without Lagrange JPs, and it's not the only problem with them.
They are inconsistent with overall JP narrative (they are visible and usable before JP theory researched!), they are easy and natural way to abuse AI with massive salvos and so on.
Maybe it worth to consider to replace them with static in-system potential JPs to stabilize, smth like 1/2^n distances between central body and every interstellar JP. Or just exterminate them, because not enough game value for too much problems.
As you mentioned above, to make the above work I would need Lagrange point locations at the point of arrival in-system, not at the point the journey begins. I could use fleet speed to work out the arrival point at the system, then use that time to run orbital movement forward to learn the LP locations. However, I can't pre-store that information as it would be different for each fleet in each system. Also, some fleets (tugs) may change their speed mid-journey so I would need to handle that too, plus other fleets may be spending time loading/unloading or using delay orders rather than moving so that needs to be handled too. 'Load until full' is even worse.
Someone else mentioned not checking a JP chain beyond finding a valid path, but unfortunately a) that isn't necessarily true because leaving the system and re-entering could be a shorter route to the destination than simply heading in-system from the first jump point. Secondly, I would still be checking all the other jump chains to their end, so I don't save much processing time.
Ultimately, it is all the edge cases that make this a lot more intensive that it might seem at first glance. I'm happy that the current system is right 95% of the time and I don't want to spend a lot of effort and processing power trying to get the extra few percent, especially when there are manual interventions available to the player.
-
Make a graph of JPs (w/o Lagrange ones) with a path lengths between those that are in the same pair of systems. Recalculate those lengths every production cycle.
When you have to find a path - run for minimal number of jumps, continue this cycle with additional 3 iterations (memorizing paths), then calc distances for every path and find the shortest.
To use Lagrange JPs more accurate it's possible to get their positions for estimated time of jump into this system. The same with the last trajectory patch (JP to final target) if it's orbital target.
The task will be much easier without Lagrange JPs, and it's not the only problem with them.
They are inconsistent with overall JP narrative (they are visible and usable before JP theory researched!), they are easy and natural way to abuse AI with massive salvos and so on.
Maybe it worth to consider to replace them with static in-system potential JPs to stabilize, smth like 1/2^n distances between central body and every interstellar JP. Or just exterminate them, because not enough game value for too much problems.
As you mentioned above, to make the above work I would need Lagrange point locations at the point of arrival in-system, not at the point the journey begins. I could use fleet speed to work out the arrival point at the system, then use that time to run orbital movement forward to learn the LP locations. However, I can't pre-store that information as it would be different for each fleet in each system. Also, some fleets (tugs) may change their speed mid-journey so I would need to handle that too, plus other fleets may be spending time loading/unloading or using delay orders rather than moving so that needs to be handled too. 'Load until full' is even worse.
Someone else mentioned not checking a JP chain beyond finding a valid path, but unfortunately a) that isn't necessarily true because leaving the system and re-entering could be a shorter route to the destination than simply heading in-system from the first jump point. Secondly, I would still be checking all the other jump chains to their end, so I don't save much processing time.
Ultimately, it is all the edge cases that make this a lot more intensive that it might seem at first glance. I'm happy that the current system is right 95% of the time and I don't want to spend a lot of effort and processing power trying to get the extra few percent, especially when there are manual interventions available to the player.
Having had to code pathing more than once during my life, I 100% agree. Pathing can be incredibly complex to code efficiently, and honestly, most of the time a "sufficiently good" approximation is used. At the end of the day, if it works decently enough, it's often not worth it to double the complexity or more for very marginal gains.
In Aurora, I think what we have is more than good enough, and I don't see why Steve would have to invest a large amount of time and effort, not to mention slowing down the code execution, to have gains in edge cases.
-
Would "improving the AI" be a sufficiently good reason to take a stab at it?
You mentioned that players can manually intervene to improve the situation, but that doesn't help the AI.
-
Would "improving the AI" be a sufficiently good reason to take a stab at it?
You mentioned that players can manually intervene to improve the situation, but that doesn't help the AI.
I don't understand what the seemingly massive problem with pathfinding is. It works just fine from my perspective.
If we're going to improve the AI you'll get much more mileage from trying to make them better at empire building or giving multi-system random NPR generation a try. That's the main problem I see wit the AI. Not their pathfinding.
-
The only way to not lose time on these calculations would be to make them during the player is doing his moves. Don't know how easy it would be to set up a separate thread that does some pre-calculations during the time we work on our moves... though we are slow enough to lose 10% of processing power and not be able to recognize that.
-
As you mentioned above, to make the above work I would need Lagrange point locations at the point of arrival in-system, not at the point the journey begins. I could use fleet speed to work out the arrival point at the system, then use that time to run orbital movement forward to learn the LP locations. However, I can't pre-store that information as it would be different for each fleet in each system. Also, some fleets (tugs) may change their speed mid-journey so I would need to handle that too, plus other fleets may be spending time loading/unloading or using delay orders rather than moving so that needs to be handled too. 'Load until full' is even worse.
It can be done more easily than that. Simply disregard LPs when planning a multi–system route. Then when a fleet starts a route segment, have it consider the LPs to see if they would make a shorter trip than flying direct. This will always be after entering a system, or after loading cargo, or after a delayed order, or releasing a tugged ship, etc. You may still want to allow the player to specify a route going via LPs manually, even though they wouldn’t be included in the plan otherwise.
Of course that still leaves cases where the pathfinder will fail to choose the shortest route. However, it is an improvement because those cases will be rarer and they will involve smaller distances in trip length. And there will be compensating improvements elsewhere.
-
Someone else mentioned not checking a JP chain beyond finding a valid path, but unfortunately a) that isn't necessarily true because leaving the system and re-entering could be a shorter route to the destination than simply heading in-system from the first jump point. Secondly, I would still be checking all the other jump chains to their end, so I don't save much processing time.
The A* pathfinding algorithm is a bit smarter than that; it quickly drops paths that are longer than the shortest known path. In this case you would start with the direct in–system path being the shortest known path, and the pathfinder would stop and return it whenever it had eliminated all of the alternatives. It would begin by considering paths that start by flying to the system JPs. These n additional paths are incomplete, but it can calculate (or rather keep track of) their length so far, which in this case is just the distance between the starting location and the JPs. If any of those distances are larger than the known shortest path, then those routes are simply dropped. The most common scenario will be that all alternative routes are immediately dropped, or that they are dropped after hopping to one more system to consider the JPs there.
Plus remember that you can cache these routes. Ships fly from Earth to Mars all of the time, or from Earth to Aldebaran IX or whatever, and they shouldn’t even be using the pathfinder at all to do so. They should be looking in a table of known routes and finding the shortest route there. If you’re not already doing this, then that may be where the next performance boost comes from.
-
The distance between jump points never changes,
This is actually not true as the travel distance between jump points is influenced by Lagrange Points which are subject to orbital mechanics.
That doesn’t change the distance from one JP to another.
-
The distance between jump points never changes,
This is actually not true as the travel distance between jump points is influenced by Lagrange Points which are subject to orbital mechanics.
That doesn’t change the distance from one JP to another.
The effective travel distance does potentially change thanks to the aforementioned lagrange movement. But if you are simply concerned with the absolute distance between two JPs, that is static. Since we are talking about pathfinding still the former is more important than the latter for our purposes.
-
This pathfinding stuff came up previously:
http://aurora2.pentarch.org/index.php?topic=12211
The last post includes a python script (from me) demonstrating the runtime cost of possible improvements to the pathfinding on notional jump networks. It also shows how to find the shortest path to moving goals (though I didn't implement ships or planets so the demo is only on non-moving goals).
-
Would "improving the AI" be a sufficiently good reason to take a stab at it?
You mentioned that players can manually intervene to improve the situation, but that doesn't help the AI.
I don't understand what the seemingly massive problem with pathfinding is. It works just fine from my perspective.
If we're going to improve the AI you'll get much more mileage from trying to make them better at empire building or giving multi-system random NPR generation a try. That's the main problem I see wit the AI. Not their pathfinding.
The problem is that an AI empire in Steve's current position would be moving ships and resources through a long route of a single jump rather than the shorter multi-system route.
Steve mentioned that a player can intervene to fix the situation with his newly implemented locking of jump points, but I thought there was a small chance that he might look at it from the other perspective.
-
Would "improving the AI" be a sufficiently good reason to take a stab at it?
You mentioned that players can manually intervene to improve the situation, but that doesn't help the AI.
I don't understand what the seemingly massive problem with pathfinding is. It works just fine from my perspective.
If we're going to improve the AI you'll get much more mileage from trying to make them better at empire building or giving multi-system random NPR generation a try. That's the main problem I see wit the AI. Not their pathfinding.
The problem is that an AI empire in Steve's current position would be moving ships and resources through a long route of a single jump rather than the shorter multi-system route.
Steve mentioned that a player can intervene to fix the situation with his newly implemented locking of jump points, but I thought there was a small chance that he might look at it from the other perspective.
I believe Droll's point was more that while there is a legitimate benefit to the NPRs from adding better pathfinding it is a relatively minor improvement because it does not fix the bigger problems that limit the effectiveness of the AI, which includes the inability to effectively expand to multiple systems and build an empire of decent size while maintaining a functional economy. Making an AI shipping lane faster in ~5% of cases, if that, really does little if anything to address those bigger problems.
Basically, the benefit of fixing pathfinding for NPRs is small enough that it would only matter if the question of whether or not to implement a new pathfinding method was borderline. It sounds like it is not as Steve is satisfied with the current system, and honestly if the major goal is to improve the AI his time would be better spent on a dedicated AI improvement project than on a pathfinding upgrade with tangential benefits.
-
The effective travel distance does potentially change thanks to the aforementioned lagrange movement. But if you are simply concerned with the absolute distance between two JPs, that is static. Since we are talking about pathfinding still the former is more important than the latter for our purposes.
You missed my point, or I didn’t explain it effectively.
Pathfinding is a recursive process, where you repeatedly apply simple steps in order to achieve a complex result. In Auora, the simplest possible step is to fly from one JP to another. Instead of doing a square root to calculate that distance every single time the pathfinder considers a JP, we can save time by looking the number up in a pre–built cache. Once that number is known, the pathfinder can check for multi–step paths to reach the same goal, such as going via a pair of LPs, if there are any. Regardless of whether the pathfinder does it, it must first consider the simpler straight–line path, and that’s where the cache is most useful. The existence of LPs does not make the cache invalid or useless. Those straight–line paths are the bedrock on which all fancier paths are built.
-
Of course that still leaves cases where the pathfinder will fail to choose the shortest route.
You missed my point, or I didn’t explain it effectively.
You seem to be aware that what you're proposing doesn't address the cases where stabilized lagrange points cause a different set of systems to have a shorter route than when only direct JP to JP travel is considered. But when it is pointed out to you, your tone is dismissive.
You could have just as easily been explicit in saying that the LP cases would still be unaddressed, but that you still consider your proposal an improvement in that you believe (if I am reading it correctly) there would be fewer edge cases and that it would improve overall performance.
-
Of course that still leaves cases where the pathfinder will fail to choose the shortest route.
You missed my point, or I didn’t explain it effectively.
You seem to be aware that what you're proposing doesn't address the cases where stabilized lagrange points cause a different set of systems to have a shorter route than when only direct JP to JP travel is considered. But when it is pointed out to you, your tone is dismissive.
You could have just as easily been explicit in saying that the LP cases would still be unaddressed, but that you still consider your proposal an improvement in that you believe (if I am reading it correctly) there would be fewer edge cases and that it would improve overall performance.
Yes, the full quote says that explicitly:
Of course that still leaves cases where the pathfinder will fail to choose the shortest route. However, it is an improvement because those cases will be rarer and they will involve smaller distances in trip length. And there will be compensating improvements elsewhere.
I have only debated the statement by Droll:
The effective travel distance does potentially change thanks to the aforementioned lagrange movement. But if you are simply concerned with the absolute distance between two JPs, that is static. Since we are talking about pathfinding still the former is more important than the latter for our purposes.
I did not intend to be dismissive of this, only to state that the pathfinder requires the distances between JPs, whether or not it also considers LPs, and that these can be cached. As I considered the LP step to be self–evident, and as the cache I mentioned didn’t have anything to do with it, I didn’t happen to mention it specifically. My explanation would have been better if I had.
Dealing with LPs correctly is actually much harder than it looks, just as finding the correct path from a JP to a planet is harder than it looks. I’ve posted elsewhere about my own explorations into a pathfinder that finds a very precise solution to the problem, so that fleets never have to play catch–up to planets. Here’s a demo video:
http://db48x.net/Aurora/four%20different%20ways%20of%20plotting%20a%20course%20in%20Aurora-2021-08-07_18.33.48.webm
The code I wrote for this finds not just the correct direction for the fleet to fly, but precisely how long it will take to reach the destination. If properly integrated into the long–distance pathfinder, it would enable the pathfinder to find exact solutions for segments that go to LPs as well as planets, and it would enable that pathfinder to calculate the precise trip length and the fuel required to complete it. It is fully generalizable to nested orbits, elliptical orbits, hyperbolic orbits, etc.
Of course it has drawbacks. My specific implementation is fairly fast, but suffers from numeric stability in some cases. The time it can take is only roughly bounded; it can take over a second to find a solution in those cases. The problem cases are primarily those where the JP is close to the orbit of the destination planet. The demo video cleverly avoids showing of cases where it performs poorly. I consider my implementation to be fairly good for the single week–end of effort put into it, but it clearly needs more research.
By combining this type of in–system solver with a full–featured long–distance pathfinder, the game would have perfect navigation: every fleet could plan its entire route perfectly, and know ahead of time whether it has enough fuel. The AI could benefit greatly from that. So could the player, as a matter of fact!
The downside is that this would be significantly slower than the existing pathfinder, and I’m not as confident that caching would eliminate the problem (because the cache would never have useful information about segments that target a moving destination, and every route has at least one of those.)
However, I have suggested a lesser solution that ignores the difficulties of LPs, as well as the difficulty of the final segment of a long–distance route where the fleet is flying from a JP to a planet. If the pathfinder ignores those, then the pathfinder will never take up excessive CPU time and will generate routes that in practice rarely surprise the player. Today virtually every game encounters situations involving loops in the system graph, where the path finder is very likely to produce the wrong solution. The solution I have suggested solves that common case while leaving the less common cases involving LP shortcuts unsolved. However, it does so in a way that leaves open the possibility of future improvements in that direction.
I think that this solution, plus judicious caching, would be not slow the game down at all, and that we would all enjoy the benefits.
I cannot guarantee that Steve would find it enjoyable to write the code, however. That’s merely a matter of taste.
-
I am quite pleased at the sophistication of this forum, where other game forums argue about unimportant fluff such as game balance or financial costs of overpriced DLCs, around here we argue about only the most technical and intellectual matters such as the efficiency and relative merits of pathfinding approaches. Such erudition is truly praiseworthy. (https://i.imgur.com/Z3wSg01.gif)
Nevertheless as passions do run high over such an important subject, and Steve has already made his position clear, perhaps we ought to cease filling the 1.14/2.0 discussion thread with comments of an admittedly tangential nature?
----
On this note, regarding the only slightly less recent post on NPR starting tech points, I'd like to re-raise the issue of uncapping the research points for high-population races. Currently starting RPs are based on an initial number of labs which are in turn tied to population, but the number of labs is capped to 50 which is equivalent to a 1.25b pop, while NPRs can easily be generated with higher populations. Particularly on high-population games this can lead to NPRs which are very under-researched compared to the player race, a significant disadvantage for the AI which already struggles to present an even slightly credible threat to a well-developed player race. As players we do have recourse to the difficulty modifier setting but this is admittedly a rather clumsy solution to a fairly specific issue.
The listed v2.0 change "will mean that later-game NPRs and Swarm in particular are not overpowered in low research rate games", however I think it is also a worthy endeavor to make this simple change to help NPRs not be underpowered in high-population games as well.
-
Hot damn! I have to start a new conventional campaign in 1.14/2.0 thanks to the new conventional components.
-
Hot damn! I have to start a new conventional campaign in 1.14/2.0 thanks to the new conventional components.
Now instead of having AAR's start with "and then one side found TN tech and conquered everything", we can start them as conventional games with a bit of conventional war, before one side discovers TN tech and conquers everything. I'm excited to do a multi-faction start once 1.4/2.0 comes out
-
I've been plotting a v2.0 conventional-ish start for a while, using a modded DB in any case as I want to explores some design space, but these new additions will make that easier to get off the ground for sure.
-
What unlocks the TN versions, is there a new tech?
-
What unlocks the TN versions, is there a new tech?
Probably just TN Tech, as it is currently. The conventional versions probably don't unlock anything by themselves.
-
What unlocks the TN versions, is there a new tech?
Probably just TN Tech, as it is currently. The conventional versions probably don't unlock anything by themselves.
Yes, that's correct.
-
With the new additions to dominant terrain type, will we see an expansion of troop specialization types?
-
With the new additions to dominant terrain type, will we see an expansion of troop specialization types?
I'll probably change the existing specialization types to cover a wider variety of biomes.
-
I know I argued for a simpler mechanic, but the hydrosphere lagging in both directions is cool. A bit worried about log spam from repeated albedo changes between liquid and solid water, though.
Steve, can you post an updated terrain chart like in this post (http://aurora2.pentarch.org/index.php?topic=8495.msg104912#msg104912)? Maybe update the one in there as well to avoid confusion.
-
With the new changes to hydrosphere... Would it be possible to get a terraforming option for directly adding/removing water instead of bothering with water vapour? I mean, besides it being better micro wise, while for adding water nothing changes, in case of removing water now I'm kinda screwed. Previously to avoid tedium I'd raise temperature above 100 degress, remove some of the vapour and then cool the planet down again. Now with the new changes this is no longer viable because it takes time for water to evaporate, meaning I can't just directly set water level to what I want in one go.
-
With the new changes to hydrosphere... Would it be possible to get a terraforming option for directly adding/removing water instead of bothering with water vapour? I mean, besides it being better micro wise, while for adding water nothing changes, in case of removing water now I'm kinda screwed. Previously to avoid tedium I'd raise temperature above 100 degress, remove some of the vapour and then cool the planet down again. Now with the new changes this is no longer viable because it takes time for water to evaporate, meaning I can't just directly set water level to what I want in one go.
Presently, this is almost possible because there is always a little bit of water vapor in the atmosphere for terraformers to interact with. I say almost because usually the amount is so small that what happens is the terraformers will remove all the atmospheric water in one go and think they have finished the job so will stop working, even though more water vapor is added immediately after this by evaporation from the liquid hydrosphere.
I think this was previously mentioned and Steve might have said he would change how terraforming logic worked to solve this but I don't remember for sure. Either way,. the solution would be to have the atmosphere adjustment to maintain hydrosphere equilibrium done before terraformers check for "job-done" status.
-
Presently, this is almost possible because there is always a little bit of water vapor in the atmosphere for terraformers to interact with.
An extremely bold statement of yours. I'd rate it as "impossible" rather than "almost possible" precisely because of the explanation you gave below. The amount of water vapour present is so low that any terraformation force capable of terraforming before you're done with that save will remove this tiny amounf of vapour very fast, meaning you end up with constant spam of terraforming being "finished" despite lack of any significant progress.
Also the simple option to modify desired hydrosphere level directly has a benefit of you being able to say "I want 50% water" just like right now you can say "I want 0.21 atm oxygen" and be done with it. Even if what you are talking about would work in practice you'd still have to check manually whether you didn't remove too much.
-
I know I argued for a simpler mechanic, but the hydrosphere lagging in both directions is cool. A bit worried about log spam from repeated albedo changes between liquid and solid water, though.
Steve, can you post an updated terrain chart like in this post (http://aurora2.pentarch.org/index.php?topic=8495.msg104912#msg104912)? Maybe update the one in there as well to avoid confusion.
We had same thought. I was already thinking of posting from DB if not available when 2.0 is released.
-
An extremely bold statement of yours. I'd rate it as "impossible" rather than "almost possible" precisely because of the explanation you gave below. The amount of water vapour present is so low that any terraformation force capable of terraforming before you're done with that save will remove this tiny amounf of vapour very fast, meaning you end up with constant spam of terraforming being "finished" despite lack of any significant progress.
By "almost possible" I mean it would be possible if not for this one thing, which makes it impossible at present. It is a different term for the same thing. ;)
Also the simple option to modify desired hydrosphere level directly has a benefit of you being able to say "I want 50% water" just like right now you can say "I want 0.21 atm oxygen" and be done with it. Even if what you are talking about would work in practice you'd still have to check manually whether you didn't remove too much.
This would also work and probably be more intuitive, it should not be too hard for Steve to make the terraforming GUI switch from atm to %hydro for water vapor only, such context-aware switching happens in many other GUIs and even when SM mode is active.
-
I know I argued for a simpler mechanic, but the hydrosphere lagging in both directions is cool. A bit worried about log spam from repeated albedo changes between liquid and solid water, though.
As I understand it, the current change is only for liquid vs gas, which doesn't change albedo AFAIK (though I guess technically it should, clouds are white). I had the same worry.
-
With the new changes to hydrosphere... Would it be possible to get a terraforming option for directly adding/removing water instead of bothering with water vapour? I mean, besides it being better micro wise, while for adding water nothing changes, in case of removing water now I'm kinda screwed. Previously to avoid tedium I'd raise temperature above 100 degress, remove some of the vapour and then cool the planet down again. Now with the new changes this is no longer viable because it takes time for water to evaporate, meaning I can't just directly set water level to what I want in one go.
Adding water vapour and waiting for it to condense was done by design to make terraforming planets without water more of a challenge. The same is true for ocean worlds where you need to remove water.
Heating the planet, adding/removing water vapour and then lowering the temperature to condense all the water at once was an exploit. The 'instant condense/evaporate' when changing between liquid and vapour was intended as a quick fix for situations where that boundary is passed only once during terraforming. Now that eccentric orbits have been added and the boundary may be crossed many times, an update to the water cycle was needed, which had the secondary effect of closing that loophole.
-
Steve, can you post an updated terrain chart like in this post (http://aurora2.pentarch.org/index.php?topic=8495.msg104912#msg104912)? Maybe update the one in there as well to avoid confusion.
See below. The weird 9999 numbers are due to the way the DB sometimes displays floating point numbers, but they are fine on load.
(http://www.pentarch.org/steve/Screenshots/Terrain.PNG)
-
I know I argued for a simpler mechanic, but the hydrosphere lagging in both directions is cool. A bit worried about log spam from repeated albedo changes between liquid and solid water, though.
As I understand it, the current change is only for liquid vs gas, which doesn't change albedo AFAIK (though I guess technically it should, clouds are white). I had the same worry.
Yes, that is correct. No albedo change for liquid to vapour.
-
Will be interesting to see if and how the orbits and environmental considerations will have an effect on Bioengineering/Genome Sequencing if it reappears
-
With the new changes to hydrosphere... Would it be possible to get a terraforming option for directly adding/removing water instead of bothering with water vapour? I mean, besides it being better micro wise, while for adding water nothing changes, in case of removing water now I'm kinda screwed. Previously to avoid tedium I'd raise temperature above 100 degress, remove some of the vapour and then cool the planet down again. Now with the new changes this is no longer viable because it takes time for water to evaporate, meaning I can't just directly set water level to what I want in one go.
Adding water vapour and waiting for it to condense was done by design to make terraforming planets without water more of a challenge. The same is true for ocean worlds where you need to remove water.
Heating the planet, adding/removing water vapour and then lowering the temperature to condense all the water at once was an exploit. The 'instant condense/evaporate' when changing between liquid and vapour was intended as a quick fix for situations where that boundary is passed only once during terraforming. Now that eccentric orbits have been added and the boundary may be crossed many times, an update to the water cycle was needed, which had the secondary effect of closing that loophole.
Well, I hardly see this mechanic as a "challenge" and my solution as an "exploit". IMO much more fitting terms would be "tedious micro" and a "solution to reduce micro". All I want to say here is that it hardly matters, all in all in both cases you have to spend some in-game time to get water to what you want, except:
-you can't "fire and forget" like with other gasses you set once because you know you want 21% oxygen and 1 atm total for a second earth world, you need to constantly watch whether enough water has condensed already and you need to stop adding vapour or not
-in case of removing water, good luck terraforming an ocean world if every few in-game days the game pauses to tell you that "all water vapour has been removed" but very little water disappeared from the planet. Like, you'd be able to run maybe 30 days max without an interrupt and having to give terraforming order once again, repeating it possibly for bazillion times until all the excess water is gone. That was my experience that led me to inventing the heating "exploit"
Thankfully the "exploit" is still possible, just means I'llhave to additionally wait after heating the planet above 100 degrees while constantly checking whether I can start removing vapour, but Steve, please, please consider making hydrosphere adjustment straightforward for the sake of smoother gameplay, make it as slow as you wish, even slower in-game time-wise than it is now to keep whatever challenge you want, but please... 🙏
-
Will be interesting to see if and how the orbits and environmental considerations will have an effect on Bioengineering/Genome Sequencing if it reappears
Yes, I have been thinking about that. In the past, creating a new species wasn't that important because you could terraform your way out of most situations, with the exceptions of high gravity and where you maxed out on greenhouse or anti-greenhouse. Now there is a scenario where it can be impossible to create an ideal world due to the temperate range exceeding that of your primary species. Creating a species with a wider temperature range looks very attractive in that situation. I suspect I will have added that functionality before v2.0 is released.
-
With the new changes to hydrosphere... Would it be possible to get a terraforming option for directly adding/removing water instead of bothering with water vapour? I mean, besides it being better micro wise, while for adding water nothing changes, in case of removing water now I'm kinda screwed. Previously to avoid tedium I'd raise temperature above 100 degress, remove some of the vapour and then cool the planet down again. Now with the new changes this is no longer viable because it takes time for water to evaporate, meaning I can't just directly set water level to what I want in one go.
Adding water vapour and waiting for it to condense was done by design to make terraforming planets without water more of a challenge. The same is true for ocean worlds where you need to remove water.
Heating the planet, adding/removing water vapour and then lowering the temperature to condense all the water at once was an exploit. The 'instant condense/evaporate' when changing between liquid and vapour was intended as a quick fix for situations where that boundary is passed only once during terraforming. Now that eccentric orbits have been added and the boundary may be crossed many times, an update to the water cycle was needed, which had the secondary effect of closing that loophole.
Well, I hardly see this mechanic as a "challenge" and my solution as an "exploit". IMO much more fitting terms would be "tedious micro" and a "solution to reduce micro".
I stopped reading after the first two sentences. Perhaps you should work on your approach to convincing people to listen to you.
-
words
words
I'll admit that stormtrooper come off a bit acerbic, but he is raising a good point that others have mentioned which is that trying to remove hydrosphere with the existing terraforming mechanic is not a fun experience for most players. This is because the atmospheric water vapor especially at higher tech levels is easily removed within a single increment leading to stop-start and notification spam, since the transformation of hydrosphere to new vapor happens after the terraformers check if their job is done. With adding water the same problem actually exists but can be avoided by setting a high atm value for the vapor so it usually doesn't come up.
In addition to the suggested changes above, as another possibility I wonder if allowing players to set the desired atm to -1 would be an acceptable flag to say "remove the selected gas until new orders are given" which also avoids these problems though it is something of a band-aid fix.
Basically, anything to allow removal of water vapor and hydrosphere without the start-stop and notification spam would be much appreciated by many. :)
-
Basically, anything to allow removal of water vapor and hydrosphere without the start-stop and notification spam would be much appreciated by many. :)
Yes, I can understand that frustration. I haven't had to remove water in any of my games or that would have been sorted by now :)
For v2.0, if you are removing water vapour, the process will no longer terminated due to a lack of water vapour in the atmosphere, unless the hydro extent is zero.
-
This is probably not the right place to ask about it, but Steve, do you still plan to eventually in the future have some sort of rudimentary planetary map for placement and movement of ground armies?
-
Basically, anything to allow removal of water vapor and hydrosphere without the start-stop and notification spam would be much appreciated by many. :)
Yes, I can understand that frustration. I haven't had to remove water in any of my games or that would have been sorted by now :)
For v2.0, if you are removing water vapour, the process will no longer terminated due to a lack of water vapour in the atmosphere, unless the hydro extent is zero.
and there was much rejoicing!
-
Basically, anything to allow removal of water vapor and hydrosphere without the start-stop and notification spam would be much appreciated by many. :)
Yes, I can understand that frustration. I haven't had to remove water in any of my games or that would have been sorted by now :)
For v2.0, if you are removing water vapour, the process will no longer terminated due to a lack of water vapour in the atmosphere, unless the hydro extent is zero.
I hate to be a bother by asking on top of this, but is it possible to add other breakpoints at carrying capacity change boundaries? Specifically, if/when I end up with a water world, it would still be convenient to be warned once I reduce the hydrosphere to 75% to maximize the population cap.
-
reading the new eccentric orbits, wondering that in a binary star system, would planets on those stars consider solar influx, and hence surface temperature and colony cost, from both stars?
No, they only consider the primary. I have the necessary code to account for all stars in the system, but decided it was too difficult for players to effectively consider those factors. Even with eccentric orbits, there is a pattern that it easy to understand. With one or more additional stars involved, each orbit could be different.
On basically my second game ever so I still do not know much about Aurora's mechanics. The following my not be a factor in Aurora's system generation mechanics.
That said, IIRC a rule of thumb (i.e. an over-generalization) is that planetary orbits are only stable (long term) if they are 1/10 (or less) or 10x (or more) the stellar separation in a multi-star systems. Thus solar systems can only exist where the stars are very close: a 5 million km star separation allows (P-type) planetary orbits beyond 50 million km to be stable; or the stars are very far apart: a 50 billion km star separation allows (S-type) planetary orbits less than 5 billion km from either star to be stable. Put a star where Jupiter is, and Mercury and Sedna are the only other stable bodies.
In widely separated multi-star systems the heating effects of one star on the planets orbiting the other are minimal in many (most?) cases. In a situation where the planets orbit a central binary however the combined radiation of both stars would dominate.
I did an internet search to make sure I did not imagine that factoid, and the 10% number for S-type orbits seems to be about right; stellar and planetary mass and orbital eccentricity affect the specific number obviously. My eyes glassed over when it came to the 10x for P-Type orbits though, the peer reviewed astronomy journal articles were just too much for my old(ish) brain. The basic story is correct though S-type (satellite/moon like around a single star) are stable close in and unstable further out, P-type (planet orbiting a central binary) are unstable close in and stable further out.
If Aurora generates P-type star systems, the combined heating effects of all the central stars should be factored in.
-
My chemistry-focused brain read "P-type", thought of orbitals instead of planetary orbits, and I am now here to ask Steve to add planets which orbit both stars of a binary system in a figure-8 path because it would be cool as all frell.
-
I was wondering if Steve has considered at some point to split planets into objects which are made of several continents, each having (possibly) a different terrain. Hostiles races would be able to co-exist if not on the same continent, and reversely (somehow) conquering a planet would ask for the invasion of all continents. You could even have completely liquid 'continents', with a kind of blue navy present and defending it (well, that would be version 2 of the implementation perhaps).
I have read my share of books where planetary conquest is made with an initial beachhead, and then you need to push further to different environs.
Edit: OK, I have read all Steve posts since 8 months, with the exception of the new AAR! When is 2.0 coming out, I'm hyped and I think I'm done gorging myself with Rimworld ;D
ps: are the cosmetic components in btw? Please say yes, can't wait to design superfluous infirmaries, brigs and armories.
-
ps: are the cosmetic components in btw? Please say yes, can't wait to design superfluous infirmaries, brigs and armories.
Misc components that have no actual gameplay function can be designed in the current version, yes.
-
ps: are the cosmetic components in btw? Please say yes, can't wait to design superfluous infirmaries, brigs and armories.
Misc components that have no actual gameplay function can be designed in the current version, yes.
They are a bit bugged because you have to instant-research them using SM as they have no research category, but they are available in 1.13.
-
If Aurora generates P-type star systems, the combined heating effects of all the central stars should be factored in.
Sadly, at the moment Aurora does not generate P-type solar systems around binaries. In fact, binary stars don’t orbit barycenters either, which is a necessary precondition.
Even so, I second this suggestion!
-
Sadly, at the moment Aurora does not generate P-type solar systems around binaries.
It does in SM mode ;)
Tatooine demands an update to Aurora's solar system models.
In fact, binary stars don’t orbit barycenters either, which is a necessary precondition.
I intentionally didn't bring that up. Barycentres would likely require a huge computational load for negligible in-game impact. The current fixed central star abstraction is adequate I think (as long as it is the most massive, which I think it currently always is).
-
I intentionally didn't bring that up. Barycentres would likely require a huge computational load for negligible in-game impact. The current fixed central star abstraction is adequate I think (as long as it is the most massive, which I think it currently always is).
Actually the direct computational load is not a problem, at least for binary systems. The only addition is that the primary star would have to be given an orbit, and bodies orbiting it will have the coordinates of that star added to their positions which is relatively minor compared to the sin, cos, etc. required to compute orbital positions in (x,y) coordinates.
The bigger problem is actually mechanical, at least flavor-wise, suddenly jump points in a multiple-star system will make even less sense than they already do as they are not fixed around the system primary anymore.
I guess maybe one solution is to have the barycenter be an invisible "star", i.e., a binary system is modeled as a trinary system with the barycenter 'B' orbiting the primary 'A' and the secondary 'C' orbiting 'B'. However I can see how this would probably get too complicated for trinary and quaternary systems, which poses a second major difficulty.
-
N-Body physics is a real bit*h when you get past n=2... Solving an n=2 body proof took 1 hole page of binder paper in my Quantum Mech. class. n=3 took 9 pages just to set up.
-
N-Body physics is a real bit*h when you get past n=2... Solving an n=2 body proof took 1 hole page of binder paper in my Quantum Mech. class. n=3 took 9 pages just to set up.
Yes, we are lucky that Aurora is only doing nested 2–body approximations! Have you ever seen the Principia mod for Kerbal Space Program? The source code is a great read though:
https://github.com/mockingbirdnest/Principia/
But I still wish we had barycenters, and the ability to set any body as the center of the view. (so that you could zoom in on a planet with a lot of moons and not have the planet vanish off of the screen at the next build cycle).
-
N-Body physics is a real bit*h when you get past n=2... Solving an n=2 body proof took 1 hole page of binder paper in my Quantum Mech. class. n=3 took 9 pages just to set up.
Yes, we are lucky that Aurora is only doing nested 2–body approximations! Have you ever seen the Principia mod for Kerbal Space Program? The source code is a great read though:
https://github.com/mockingbirdnest/Principia/
But I still wish we had barycenters, and the ability to set any body as the center of the view. (so that you could zoom in on a planet with a lot of moons and not have the planet vanish off of the screen at the next build cycle).
I have not see that mod, then again i have not played KSP since Squad sold the game. I'll have to check out that code.
Center of view is probably doable in the code, barycenters would be nice too.
-
I think Max Temperature Factor should be name-changed to Max Colony Cost just to be more clear as to what it is.
-
I think Max Temperature Factor should be name-changed to Max Colony Cost just to be more clear as to what it is.
If a body has say, a temp factor of 1 and a max temp factor of 1.5, then I can think of plenty of situations where this isn't the max cc (and I would want to know this).
-
I think Max Temperature Factor should be name-changed to Max Colony Cost just to be more clear as to what it is.
If a body has say, a temp factor of 1 and a max temp factor of 1.5, then I can think of plenty of situations where this isn't the max cc (and I would want to know this).
Pretty sure I read that max temp factor = max colony cost, so I don't see any reason not to change it to be more clear.
Anyways, the only reason you care about the temp factor in the first place is due to its effect on colony costs.
-
I think Max Temperature Factor should be name-changed to Max Colony Cost just to be more clear as to what it is.
If a body has say, a temp factor of 1 and a max temp factor of 1.5, then I can think of plenty of situations where this isn't the max cc (and I would want to know this).
Pretty sure I read that max temp factor = max colony cost, so I don't see any reason not to change it to be more clear.
Anyways, the only reason you care about the temp factor in the first place is due to its effect on colony costs.
Not strictly true, because if the maximum temperature factor stays under 2.0x you can easily have a higher colony cost due to lack of oxygen, no water, dangerous gas, etc. all of which impose a flat 2.0x CC.
I suspect the confusion was due to linguistic imprecision, in most cases when there is a significant temperature variation due to eccentricity the max temperature cost will probably exceed 2.0x without terraforming. However the two quantities are different and we should not confuse them.
-
I think Max Temperature Factor should be name-changed to Max Colony Cost just to be more clear as to what it is.
If a body has say, a temp factor of 1 and a max temp factor of 1.5, then I can think of plenty of situations where this isn't the max cc (and I would want to know this).
Pretty sure I read that max temp factor = max colony cost, so I don't see any reason not to change it to be more clear.
Anyways, the only reason you care about the temp factor in the first place is due to its effect on colony costs.
Not strictly true, because if the maximum temperature factor stays under 2.0x you can easily have a higher colony cost due to lack of oxygen, no water, dangerous gas, etc. all of which impose a flat 2.0x CC.
I suspect the confusion was due to linguistic imprecision, in most cases when there is a significant temperature variation due to eccentricity the max temperature cost will probably exceed 2.0x without terraforming. However the two quantities are different and we should not confuse them.
I never realized how much circles (or i guess ovals in this case) could hurt my brain...
Anyways, I'd like it if Steve could make Max Colony Cost readily apparent on the planet browser. Its the information I need to know the most as a player.
Also hoping 2.0 will let us use multiple tugs at once that contribute all their engine power to towing instead of having to build what amounts to a giant engine with a tow winch on it. Would be more realistic/flexible. Although I hear it might not be possible on the engine for some reason...
-
Anyways, I'd like it if Steve could make Max Colony Cost readily apparent on the planet browser. Its the information I need to know the most as a player.
If by planet browser, you mean the system view, it already is. There's a checkbox labelled "Show Max Colony Cost" which toggles current cc and max. In the screenshots for v2.0 this checkbox is changed to "Show Max CC / Temp".
This info is also available on the summary tab of the economics window, but in v1.13 it only shows up when this is different than the current cc (that is, on comets), between colony cost and dominant terrain.
-
Looking at the thing about eccentric orbits changing planetary terrain, I was randomly wondering if it is possible to turn planetary terrain to a temperate forest through terraforming?
-
Looking at the thing about eccentric orbits changing planetary terrain, I was randomly wondering if it is possible to turn planetary terrain to a temperate forest through terraforming?
Yes. But only if the range of possible temperatures on the body allows for temperate forest. Basically, if the terrain isn't a base (barren, mountain, rift valley), you can reroll by getting the conditions outside the range of the current terrain. I find temperature by far the easiest to manipulate for this purpose.
Just a note: I'm specifically not getting more detailed here because this is a off-topic for the thread.
-
Will the new fleet overhaul and movement order work with fleet training?
-
The new admin automation is an amazing change and I greatly approve. I wonder if it would be possible to add a similar UI tab for ship classes? For individual ships this would be too much, but it would make it a bit easier to specialize commanders for ship classes or more generally for a commander selection doctrine - such as requiring Tactical skill for point defense ships or Survey skill for survey ships which otherwise would eat a REA/ENG/TAC skilled commander as a "military ship".
Unlike the admin commands tab, the ship tab could use the existing rules by default so that players are not required to mess with these settings for every ship if they do not want the added micro.
-
Question on this error:
Fixed bug that caused 2-stage buoys without targets to self-destruct.
I want to understand how it works now, in version 1. 13.
Let's say I have designed two-stage rockets.
Let's say I fired 10 volleys of these missiles at the enemy.
Let's say the first salvo destroyed one of the targets.
If there are no sensors on my rockets aimed at this target, they disappear anyway.
And if there is?
The mistake is that missiles of the first stage (before separation) disappear even with sensors, if the sensors do not see the enemy, although they SHOULD fly further to the place of the destroyed target, near which they will find a new enemy, and retarget?
Or is it that after the separation, the second stage missiles will be destroyed if they do not see the enemy?
Which missiles are self-destructing, the first stage "booster rockets", or the small second stage rockets?
sorry for my English. .
-
Question on this error:
Fixed bug that caused 2-stage buoys without targets to self-destruct.
I want to understand how it works now, in version 1. 13.
Let's say I have designed two-stage rockets.
Let's say I fired 10 volleys of these missiles at the enemy.
Let's say the first salvo destroyed one of the targets.
If there are no sensors on my rockets aimed at this target, they disappear anyway.
And if there is?
The mistake is that missiles of the first stage (before separation) disappear even with sensors, if the sensors do not see the enemy, although they SHOULD fly further to the place of the destroyed target, near which they will find a new enemy, and retarget?
Or is it that after the separation, the second stage missiles will be destroyed if they do not see the enemy?
Which missiles are self-destructing, the first stage "booster rockets", or the small second stage rockets?
sorry for my English. .
If I understand correctly, it sounds like you are firing the missiles directly at targets, and the first stage is separating into a second stage which has the same target but also sensors to pick up a new target. The first stage does not have sensors to retarget with. In this case, if the first-stage missile no longer has a target it will self-destruct. This may be unintuitive, since it is not the desired behavior, but it makes sense from a mechanical perspective: a first-stage missile needs to release its second stage at a specified distance from the target, and it cannot do so if the target does not exist (wrecks cannot be targeted by weapons). Therefore, it will simply self-destruct like any other non-sensor missile which lacks a target.
The 1.14/2.0 bugfix specifically is referring to two-stage buoys (i.e., mines), in which case the first stage has a sensor to detect a target and then release the second stage at that target.
-
If I understand correctly, it sounds like you are firing the missiles directly at targets, and the first stage is separating into a second stage which has the same target but also sensors to pick up a new target. The first stage does not have sensors to retarget with. In this case, if the first-stage missile no longer has a target it will self-destruct. This may be unintuitive, since it is not the desired behavior, but it makes sense from a mechanical perspective: a first-stage missile needs to release its second stage at a specified distance from the target, and it cannot do so if the target does not exist (wrecks cannot be targeted by weapons). Therefore, it will simply self-destruct like any other non-sensor missile which lacks a target.
The 1. 14/2. 0 bugfix specifically is referring to two-stage buoys (i. e. , mines), in which case the first stage has a sensor to detect a target and then release the second stage at that target.
Does it really work that way?
I read a topic about an attempt to create minefields, and there mines disappeared from a person (i. e. drones, the first stages of a rocket).
Then they mentioned this error in that thread. Logically, this means that the mines disappeared because the first stage (drone) did not see the target.
From this, 2 conclusions can be drawn:
1. Mines or ultra-long-range missiles launched to the desired point are broken.
2. On the first stage (drone) of two-stage missiles, it is necessary to install sensors powerful enough so that they can detect the enemy at a distance at which they will be after the first volleys hit the enemy.
That is, if I fire 20 volleys of missiles with an interval of 60 seconds, the first stage of which moves at a speed of 10 km / s, and the second - 30 km / s, and they are separated at a distance of 1. 5 million km, then:
- at the time of separation, the distance between the first and last salvo will be 12 million km.
And so that, in the event that the first salvo destroys enemy ships, part of the latter does not self-destruct, but over-travels, I need to install sensors on the first-stage missiles that allow me to see the enemy at 12 million km?
Are the sensors on the second, combat stage not needed?
-
I read a topic about an attempt to create minefields, and there mines disappeared from a person (i. e. drones, the first stages of a rocket).
Then they mentioned this error in that thread. Logically, this means that the mines disappeared because the first stage (drone) did not see the target.
Yes, this was the bug which needed to be fixed. A first stage of a two-stage mine has a sensor, so it should be able to sit and wait to acquire a target. The fact that it does not is a bug.
If you have a two-stage missile, and the first stage does not have an active sensor, it should detonate without a target. If it has an active sensor and still detonates then it is being affected by the same bug. It is important to specify the difference between a first stage with and without a sensor.
Are the sensors on the second, combat stage not needed?
I'm not entirely certain since I don't use such designs myself.
-
If you have a two-stage missile, and the first stage does not have an active sensor, it should detonate without a target. If it has an active sensor and still detonates then it is being affected by the same bug. It is important to specify the difference between a first stage with and without a sensor.
If I place sensors powerful enough in the first stage so that they can see the enemy at the distance that these missiles will be located when the first volleys reach the target - will they just find a new target and there will be no problem?
Do I understand the essence of the bug correctly ?: Does the error occur when the first-stage missiles have a sensor, but at the moment of target loss, their sensor still cannot detect the enemy on its own?
At the same time, this bug does not affect the second-stage missiles, combat ones? After separation, they will be targeting the ship the first stage rocket is targeting, and therefore they don't need the sensor, right?
I'm not entirely certain since I don't use such designs myself.
Understood, in any case, thank you very much, we will wait for a narrow specialist in two-stage rockets!)
-
If I place sensors powerful enough in the first stage so that they can see the enemy at the distance that these missiles will be located when the first volleys reach the target - will they just find a new target and there will be no problem?
Do I understand the essence of the bug correctly ?: Does the error occur when the first-stage missiles have a sensor, but at the moment of target loss, their sensor still cannot detect the enemy on its own?
Yes, I believe this is correct if I am reading it correctly.
At the same time, this bug does not affect the second-stage missiles, combat ones? After separation, they will be targeting the ship the first stage rocket is targeting, and therefore they don't need the sensor, right?
I think so, but again someone with more expertise can confirm. My intuition is that the second-stage missiles have the same target as the first-stage, since this is how it should work in the dumb-fire case as the missile inherit targeting orders from their fire controls.
-
Any civilian mining colonies from which you are purchasing minerals are highlighted in light blue. This won't apply if the colony has a population greater than zero, as green text will be used instead.
Could you instead make it so that when purchasing minerals the colony displays "#x CMC [P]" and if you are selling them it displays "#x CMC "?
I'd also like it if it could show normal mines and CMCs at the same time to give a better idea of where my mining is taking place.
-
I think adding option to sort colonies based on population, mining parameters and location(s) would be a good addition.
-
Is it possible to use the new hull designations as the full name of the ship? I feel like this will be much better than the "name 01, name 02..." and would prevent name-list exhaustion related issues. Something that becomes very annoying when you have 200+ system defense frigates.
-
What would happen with new Hull Number feature, when I'll capture a ship of the hull type I already have some ships? Will she keep her original number or recieve new number as if she was recently built by my shipyards?
-
Nice, now i don't have to manually include hull numbers in the ships names when i build them :D
-
What would happen with new Hull Number feature, when I'll capture a ship of the hull type I already have some ships? Will she keep her original number or recieve new number as if she was recently built by my shipyards?
Interesting question. Currently, the original number will be kept unless you change it manually. I guess it would make sense to auto-update it though.
-
I’ll be that guy and ask the question but will we see 2.0 during the holiday season? It is completely 100% cool if not - Lord knows I have plenty of other gaming options piling up and as always with this project, we get it when we get it. But I do have an awesome idea for a new C# game and the new 2.0 features are too attractive for me to invest the setup time in the idea for a 1.13 game. Apologies if question is an annoyance.
-
I’ll be that guy and ask the question but will we see 2.0 during the holiday season? It is completely 100% cool if not - Lord knows I have plenty of other gaming options piling up and as always with this project, we get it when we get it. But I do have an awesome idea for a new C# game and the new 2.0 features are too attractive for me to invest the setup time in the idea for a 1.13 game. Apologies if question is an annoyance.
I don't know. There are still a couple of unresolved bugs I can't track down. One involves the creation of trojan asteroids that appear in a close-packed straight line away from the primary, yet at some point, usually after a few weeks, they fix themselves and work correctly. I'm also going to start a new campaign shortly. The existing one has been fun but not very challenging and I want to test a few new additions. Plus I am playing a few other games at the moment.
My guess would be after Xmas, but I might suddenly get a burst of enthusiasm :)
-
Plus I am playing a few other games at the moment.
Offtopic, but are you giving HighFleet a try? Has a good Aurora feel to it.
-
Plus I am playing a few other games at the moment.
Offtopic, but are you giving HighFleet a try? Has a good Aurora feel to it.
Its on my Steam wishlist but I haven't tried it yet. I've been playing Battlesector and Valheim and I recently fired up Witcher 3, as I never really got into it when it came out. I've also just started Horizon Zero Dawn.
-
With the new option to "collect" minerals in a space station, it would really be nice if we could fully automate mineral transfer by allowing stations to have a mass driver module that can throw mineral packages through stabilised worm holes to a space station or planet in the next system. ;D
-
With the new option to "collect" minerals in a space station, it would really be nice if we could fully automate mineral transfer by allowing stations to have a mass driver module that can throw mineral packages through stabilised worm holes to a space station or planet in the next system. ;D
Or at least from and/or to stations inside a system, so a small jump tramp can be set to transshipment duty (carrying minerals between stations in and out of the JP) without bothering with fuel, changing path lenghths because of orbital motions, restricted points etc.
-
Hull Numbers
v2.0 adds hull numbers for each ship. These are appended to the hull designation for each ship for display and reporting purposes. For example, the sixteenth destroyer built by a race will be designated as DD-16.
This designation is not affected by class. If the last destroyer of the Tribal class is DD-25, the first ship of the subsequent class with the same hull type will be DD-26.
An option on the Miscellaneous sub-tab of the Ship Overview tab on the Naval Organization window allows you to specify a hull number for a ship, as long as that hull number is not already in use. If you specify a number higher than any existing hull number for that hull type, new ships with the same hull type will increment hull numbers from that point onwards.
An option on the 'Ships in Class' tab of the Ship Class window allows you to reset the hull numbers of all ships with the same hull type. This is done in order of original creation.
There is a display flag on the Tactical Map display options to disable the display of hull numbers for a given race. The difference in display is simply DDG-51 Arleigh Burke vs DDG Arleigh Burke. This display flag applies to all uses of the hull number throughout the game - not just on the tactical map.
There is a display flag on the Miscellaneous tab of the Ship Class window that allows you to toggle hull number display for a specific class. For example, you may not want hull numbers for fighters. The hull numbers are still created for this class, but are not displayed if the toggle is off.
Probably should be in the suggestions, but it would be nice if you could set a range for a ship class. I.E., the Constitution class starts with 1700.
-
I just realised this will mean I can have a half a dozen versions of eg freighters and have a nice continuous numbering system for them.
Can we use the hull number as the ship name like the current name+number option?
-
I just realised this will mean I can have a half a dozen versions of eg freighters and have a nice continuous numbering system for them.
Can we use the hull number as the ship name like the current name+number option?
I could probably add something that suppresses the ship name for display purposes, so you only see FT-1, FT-2, etc.
-
Just to clarify, if the first search is unsuccessful and the second search doesn't find an officer with the relevant bonus, does the position stay open?
Will a commander with no relevant bonus be selected due to their political bonus as part of either search?
One other thing, does disabling the political bonus in game settings mean it isn't considered for existing officers, or does it only stop new officers from aquiring the bonus when they spawn graduate?
-
Finally: On-Demand Promotions ;D ;D ;D ;D ;D
-
How does this on-demand promotion system work with admin commands if there are gaps? Let's say the highest rank I can drum up from my fleet is a commodore, but my lowest-rank admin command that's currently vacant wants a vice admiral. Would it simply never be filled until a commodore is promoted (manually, or automatically if some other position were created for them) to rear admiral?
-
How does this on-demand promotion system work with admin commands if there are gaps? Let's say the highest rank I can drum up from my fleet is a commodore, but my lowest-rank admin command that's currently vacant wants a vice admiral. Would it simply never be filled until a commodore is promoted (manually, or automatically if some other position were created for them) to rear admiral?
The situation you're describing can only happen if the player has manually set the lowest-rank admin commands to a rank that is more than one higher than the highest rank ship posts on existing ships.
Which prompts a counter-question: Are you actually worried about this, or are you wondering if this new system is fool-proof?
-
How does this on-demand promotion system work with admin commands if there are gaps? Let's say the highest rank I can drum up from my fleet is a commodore, but my lowest-rank admin command that's currently vacant wants a vice admiral. Would it simply never be filled until a commodore is promoted (manually, or automatically if some other position were created for them) to rear admiral?
The situation you're describing can only happen if the player has manually set the lowest-rank admin commands to a rank that is more than one higher than the highest rank ship posts on existing ships.
Which prompts a counter-question: Are you actually worried about this, or are you wondering if this new system is fool-proof?
Actually worried about it. If I have task groups in my fleet with a minimum admin command rank (going off of the American system here) of rear admiral lower half, but want the fleet above commanded by a vice admiral (so that the task groups would be led by a mix of rear admirals of both sorts), that would pose a problem. While either sort of rear admiral could fit those slots easily, no one would ever be promoted when in those roles unless I explicitly had roles set about for only rear admirals.
I suppose the way to "solve" that is to simply elevate your more important task groups to have a higher minimum and doing some manual promotions, but that specific edge-case might pose a problem if it isn't kept on top of.
-
*snip*
Let's say, for this example, you have somewhere in your ranks Commodore, Rear Adm, Vice Adm, in that order with no other ranks between.
Now lets say you aren't manually assigning minimum ranks to naval admin commands and aren't marking officers as "do not promote."
In this situation, for an admin post to require a Vice Adm, it has to have a direct subordanant post that requires a Rear Adm (whether that is another naval admin, or a post on a ship). If that Vice Adm admin post is open, a Rear Adm who is currently filling a Rear Adm post will get promoted. If there are no Rear Adms anywhere at all, then there is de facto at least one open Rear Adm post for a Commodore to get promoted into, who will then get promoted for the Vice Adm post on the next construction cycle.
For the kind of gaps you're talking about, you would have had to accidentally or intentionally manually set your naval admins to include such a gap, or have had to mark all existing officers of a given rank (such as all your Rear Adms in the example above) as "do not promote." In other words, it is literally a problem you have to micromanage yourself into.
The key thing to remember is that officers don't have to only be promoted to their direct superior's job. In your second post about this, you're describing a Vice Adm in a naval admin post who is directly superior to other naval admins who are either rear upper or rear lower. In this case, a rear upper would get the promotion if that vice post is open (but not necessarilly one of the rear uppers that was in that part of the hierarchy), which would open a rear upper post for a rear lower (likewise, from anywhere in the hierarchy) and so on.
-
Aah, I see. I forgot that promotions could go all over the place in the hierarchy; as long as I have some rear admiral posting, somewhere, everything should be fine. Thank you.
-
As a rule in Aurora, the mechanics are designed to work smoothly if you leave them alone (most of the time), but to never ever prevent the player from digging themselves a hole too deep of their own chosen size and shape. ;)
-
Just to clarify, if the first search is unsuccessful and the second search doesn't find an officer with the relevant bonus, does the position stay open?
Will a commander with no relevant bonus be selected due to their political bonus as part of either search?
One other thing, does disabling the political bonus in game settings mean it isn't considered for existing officers, or does it only stop new officers from aquiring the bonus when they spawn graduate?
Yes, the position stays open. Political bonus only matters if the commander has the primary bonus. Political bonus setting affects commander generation and skill increase. Turning it off doesn't remove existing bonuses.
-
Do I understand the new system correctly when I state that the upper ranks will always be filled (except there is no officer with a fitting bonus)?
If so can it happen that we are going to run out of lower ranks if there are not enough academies?
-
Do I understand the new system correctly when I state that the upper ranks will always be filled (except there is no officer with a fitting bonus)?
If so can it happen that we are going to run out of lower ranks if there are not enough academies?
Yes, that could be the result.
-
If so can it happen that we are going to run out of lower ranks if there are not enough academies?
while true I don't really see this happening very often especially with the changes to the academies and truthfully i'd rather have this issue then the issue we have now where we have way to many lower rank officers for the amount of Senior officers we need especially if you play like i do and model the entire officer core from O1s to O10s
-
If so can it happen that we are going to run out of lower ranks if there are not enough academies?
while true I don't really see this happening very often especially with the changes to the academies and truthfully i'd rather have this issue then the issue we have now where we have way to many lower rank officers for the amount of Senior officers we need especially if you play like i do and model the entire officer core from O1s to O10s
Slightly off topic but how do you model the O-1 to O-6 to fit in a ship class? Considering that a warship with senior co option ticked only allows up to R4 which would be O-4?
-
Slightly off topic but how do you model the O-1 to O-6 to fit in a ship class? Considering that a warship with senior co option ticked only allows up to R4 which would be O-4?
Ill admit it does break down a bit but so does the having LCDR and CDRs command fighters and gun ships, what i use is the junior officers command Civilian ships, small craft and utilize things like the CIC, Aux Control ect to raise the minimum rank required to command, Ground side is much much easier, i know that the game is technically supposed to have your O1s-O3s simulated as generic Crew but the fact that our O4s are 22 years old always rubs me the wrong way, I also consider unassigned O1s to O3s as being Division heads on larger ships when i get to that stage of the game, its not perfect but really no system of officer structures are without giving us massive massive micro to do
-
Ill admit it does break down a bit but so does the having LCDR and CDRs command fighters and gun ships,
This is why I always use a LT rank when I do a carrier-based fleet doctrine.
i know that the game is technically supposed to have your O1s-O3s simulated as generic Crew but the fact that our O4s are 22 years old always rubs me the wrong way,
@Steve plz
-
i know that the game is technically supposed to have your O1s-O3s simulated as generic Crew but the fact that our O4s are 22 years old always rubs me the wrong way,
@Steve plz
It depends on how I handle starting commanders. If I set up a 2:1 starting ratio, then I could assign different ages to higher ranks. If I let it work organically with everyone starting at the bottom rank, then everyone would need to start at a similar age.
-
It depends on how I handle starting commanders. If I set up a 2:1 starting ratio, then I could assign different ages to higher ranks. If I let it work organically with everyone starting at the bottom rank, then everyone would need to start at a similar age.
If the decision lands on higher starting ages, then, since promotions aren't guaranteed, maybe there could be some randomized range to the starting age.
-
I'm wondering if it might be useful to implement a minimum ratio, like you also mentioned here: http://aurora2.pentarch.org/index.php?topic=12847.msg157286#msg157286 (http://aurora2.pentarch.org/index.php?topic=12847.msg157286#msg157286) - simply to ensure there are people to choose from when promoting. Looking at my own current game, there are ranks where I currently have no officers employed. The officers who have jobs are:
R1: 3 out of 4
R2: 0 out of 8
R3: 4 out of 16
R4: 3 out of 32
What happens when all my R2 officers retire? Without a minimum ratio, if there are no jobs, there won't be promotions, which also means I won't get new R1 officers once the R2 officers have retired, since there are no officers to promote. I think I'd prefer to not have to create artificial admin commands to ensure the right number of jobs at all levels. Or perhaps this is just the way to go? Creating admin commands as career pathways for specific skills? I usually have a very simple command structure, so I'm a bit hesistant at the thought of needing a more complex structure simply to create more jobs, but perhaps I'll just have to bit the bullet, if there isn't a minimum ratio.
-
It depends on how I handle starting commanders. If I set up a 2:1 starting ratio, then I could assign different ages to higher ranks. If I let it work organically with everyone starting at the bottom rank, then everyone would need to start at a similar age.
If the starting age was even just shifted up to 30 or 40 it would probably be okay. Really the major issue is that absolutely no army colonel, ship captain, lead scientist, or colony governor should be 21 years old unless we are roleplaying some serious nepotism problems. 30 might be a bit young for some of these jobs but it is a lot better as an approximation.
-
I'm wondering if it might be useful to implement a minimum ratio, like you also mentioned here: http://aurora2.pentarch.org/index.php?topic=12847.msg157286#msg157286 (http://aurora2.pentarch.org/index.php?topic=12847.msg157286#msg157286) - simply to ensure there are people to choose from when promoting. Looking at my own current game, there are ranks where I currently have no officers employed. The officers who have jobs are:
R1: 3 out of 4
R2: 0 out of 8
R3: 4 out of 16
R4: 3 out of 32
What happens when all my R2 officers retire? Without a minimum ratio, if there are no jobs, there won't be promotions, which also means I won't get new R1 officers once the R2 officers have retired, since there are no officers to promote. I think I'd prefer to not have to create artificial admin commands to ensure the right number of jobs at all levels. Or perhaps this is just the way to go? Creating admin commands as career pathways for specific skills? I usually have a very simple command structure, so I'm a bit hesistant at the thought of needing a more complex structure simply to create more jobs, but perhaps I'll just have to bit the bullet, if there isn't a minimum ratio.
I thought about this too. It seems having some baseline of empty promotions is currently off the table, but maybe the function that searches for candidates in the next lower rank can also make another run into the second next lower if it couldn't find anyone (and eventually loop through all lower ranks if necessary), then promoting someone on basis of future promise, but not assigning them yet. They would stay without command, but be lifted up as promising candidates, and perhaps in one year promoted again to then take their role.
This could also ease some worries about never finding qualified higher level candidates, since it would be really rare to have someone run through 3 different types of filters throughout their career and then still have some spare new talents for a 4th specialization position at the top ranks.
On another note, if you really have ranks that do nothing before next, maybe it could just be necessary to delete that rank and compress the hierarchy for you? Well, I do actually understand the need for fluff ranks in a sandbox game, so maybe it is better to find a real solution to this empty-rank problem. After all, in case there are only very few positions for a certain rank, the situation would still occur and run risk of creating a promotion bottlenecks.
-
I'm wondering if it might be useful to implement a minimum ratio, like you also mentioned here: http://aurora2.pentarch.org/index.php?topic=12847.msg157286#msg157286 (http://aurora2.pentarch.org/index.php?topic=12847.msg157286#msg157286) - simply to ensure there are people to choose from when promoting. Looking at my own current game, there are ranks where I currently have no officers employed. The officers who have jobs are:
R1: 3 out of 4
R2: 0 out of 8
R3: 4 out of 16
R4: 3 out of 32
What happens when all my R2 officers retire? Without a minimum ratio, if there are no jobs, there won't be promotions, which also means I won't get new R1 officers once the R2 officers have retired, since there are no officers to promote. I think I'd prefer to not have to create artificial admin commands to ensure the right number of jobs at all levels. Or perhaps this is just the way to go? Creating admin commands as career pathways for specific skills? I usually have a very simple command structure, so I'm a bit hesistant at the thought of needing a more complex structure simply to create more jobs, but perhaps I'll just have to bit the bullet, if there isn't a minimum ratio.
I think you may be overthinking it. If you find you are using a lot of commanders (R3) but no captains (R2), just flag some of your ship classes as 'Senior C.O' and you will have R2 roles available, or just start your admin ranks at R2. If you have no R2 ships or admin commands, then you don't need R1 admin commands anyway.
-
It depends on how I handle starting commanders. If I set up a 2:1 starting ratio, then I could assign different ages to higher ranks. If I let it work organically with everyone starting at the bottom rank, then everyone would need to start at a similar age.
If the starting age was even just shifted up to 30 or 40 it would probably be okay. Really the major issue is that absolutely no army colonel, ship captain, lead scientist, or colony governor should be 21 years old unless we are roleplaying some serious nepotism problems. 30 might be a bit young for some of these jobs but it is a lot better as an approximation.
Yeah, even just taking a look at the US system, if your minimum officer rank in your navy is lieutenant (which would have fully decked-out ships led by commanders, or with senior C.O. captains; this seems ideal to me), that's... graduate officer academy at 22 (4 years), minimum 2 years to promote from ensign, and another 2 years to promote from lieutenant (junior grade). Lieutenant commanders would be another 3 years on top of that, with a total of 9 to 11 years of cumulative service.
So just from that alone (since those are all minimums), having academy graduates start in their late 20's/early 30's seems ideal even if that would be on the young side for the civilian sector.
-
I think you may be overthinking it. If you find you are using a lot of commanders (R3) but no captains (R2), just flag some of your ship classes as 'Senior C.O' and you will have R2 roles available, or just start your admin ranks at R2. If you have no R2 ships or admin commands, then you don't need R1 admin commands anyway.
That is very possible :)
Part of the problem here is also that we currently assign manually, where I look at best skills rather than merely rank. So some of the R1 officers are assigned to admin command where the minimum required rank is R3 or even R4. It would likely look very different if I only assigned best skills within specified rank for the admin command, which is what the new system will do, if we follow the automation without player interference.
-
I think you may be overthinking it. If you find you are using a lot of commanders (R3) but no captains (R2), just flag some of your ship classes as 'Senior C.O' and you will have R2 roles available, or just start your admin ranks at R2. If you have no R2 ships or admin commands, then you don't need R1 admin commands anyway.
That is very possible :)
Part of the problem here is also that we currently assign manually, where I look at best skills rather than merely rank. So some of the R1 officers are assigned to admin command where the minimum required rank is R3 or even R4. It would likely look very different if I only assigned best skills within specified rank for the admin command, which is what the new system will do, if we follow the automation without player interference.
Also note that v2.0 will allow specifying the minimum required rank of an admin command manually, which (with a small bit of one-time micro) avoids the problem that we have presently that the minimum rank for a command might be CDR or CAPT when you want only CDRE, RADM, or higher in an admin command. This way you can make sure that the commands you assign a R1 officer to are actually requiring a R1 which should help matters.
-
Starting Commanders
Even though v2. 0 introduces the concept of promotion on-demand, an Empire will still need an initial officer corps. This will be created used the current method of promotion based on ratios, using 2:1 for naval and 4:1 for ground. Once the game begins, promotion will be on-demand (or manual) only.
Starting commanders will be assigned an age of 21 + Random(5). For each rank they are promoted during the initial race creation their age will be incremented by 2 + Random(5).
I also considered having all officers start at the lowest rank and organically change as ships are built, but that prevents the age modification above and could look very odd. Also, Aurora doesn't actually track age. It tracks career start date vs current date and adds 21 years. Therefore adding 'Age' to starting officers is actually changing their career start date to before the game start date.
Awesome, Thanks Steve I know that this doesn't really change the core of the game at all but it does make me feel better :)
-
Also, Aurora doesn't actually track age. It tracks career start date vs current date and adds 21 years. Therefore adding 'Age' to starting officers is actually changing their career start date to before the game start date.
To satisfy all the people who have strong opinions about this (and I don't count myself among them), could you add a setting which changes the offset for each empire?
You could call it Commander Graduation Age.
-
Starting Commanders
Therefore adding 'Age' to starting officers is actually changing their career start date to before the game start date.
Just wondering: the date library can handle negative years (e.g. starting year 1)?
-
Awesome, Thanks Steve I know that this doesn't really change the core of the game at all but it does make me feel better :)
But it does change the core!
The core of the game always was about creating interesting stories and this is right on the spot when it comes to supporting such ;)
-
Even though v2.0 introduces the concept of promotion on-demand, an Empire will still need an initial officer corps. This will be created used the current method of promotion based on ratios, using 2:1 for naval and 4:1 for ground. Once the game begins, promotion will be on-demand (or manual) only.
I think it would be good to start with no officer corps (it's the dawn of a new era, start with a clean slate, just like ships and ground units). How about instead having a number of "officer points" similar to "build points" and "research points" to kickstart games? That way we can set up the commander naming schemes properly before any are created. It also means we can rename all the ranks without it looking odd in the commanders' history for the first few decades. And it would mean we can immediately promote the right ones, rather than leaving it up to the gods of random. Each such "officer point" allows the creation of one officer of the lowest rank. We can then promote them on demand ourselves. The button could then even be used in SM mode to add more commanders (just like the insta-build-and-add-to-fleet on the ship design misc tab).
What do you think?
-
Starting Commanders
Therefore adding 'Age' to starting officers is actually changing their career start date to before the game start date.
Just wondering: the date library can handle negative years (e.g. starting year 1)?
The data library can't handle it, but I have a try/catch that will default to 1st Jan 0000 if that happens. That will only be an issue though if someone starts a campaign on or shortly after 0 AD.
-
Even though v2.0 introduces the concept of promotion on-demand, an Empire will still need an initial officer corps. This will be created used the current method of promotion based on ratios, using 2:1 for naval and 4:1 for ground. Once the game begins, promotion will be on-demand (or manual) only.
I think it would be good to start with no officer corps (it's the dawn of a new era, start with a clean slate, just like ships and ground units). How about instead having a number of "officer points" similar to "build points" and "research points" to kickstart games? That way we can set up the commander naming schemes properly before any are created. It also means we can rename all the ranks without it looking odd in the commanders' history for the first few decades. And it would mean we can immediately promote the right ones, rather than leaving it up to the gods of random. Each such "officer point" allows the creation of one officer of the lowest rank. We can then promote them on demand ourselves. The button could then even be used in SM mode to add more commanders (just like the insta-build-and-add-to-fleet on the ship design misc ta).
What do you think?
If you want to do this, just use the 'Replace All' option after game start and choose 0 for the number of commanders.
-
Even in a Conventional start, I think most brand new Space Navies would create a starting roster from interested Air, Naval, and Land officers, similar to how Navy and Land officers who were interested in aviation were used to form the first air forces during and after WW1.
There might be a scenario where only graduates of the new Academy are chosen, but I think that would be the minority of scenarios. And you can model this by using SM and smashing the Retire button a lot.
-
Even in a Conventional start, I think most brand new Space Navies would create a starting roster from interested Air, Naval, and Land officers, similar to how Navy and Land officers who were interested in aviation were used to form the first air forces during and after WW1.
There might be a scenario where only graduates of the new Academy are chosen, but I think that would be the minority of scenarios. And you can model this by using SM and smashing the Retire button a lot.
This logic also applied to the initial astronaut training programs - most were military pilots (or had military experience - Neil Armstrong had retired from the Air Force before he was accepted into astronaut training, but he did have the background) before they became astronauts.
-
Even in a Conventional start, I think most brand new Space Navies would create a starting roster from interested Air, Naval, and Land officers, similar to how Navy and Land officers who were interested in aviation were used to form the first air forces during and after WW1.
There might be a scenario where only graduates of the new Academy are chosen, but I think that would be the minority of scenarios. And you can model this by using SM and smashing the Retire button a lot.
This logic also applied to the initial astronaut training programs - most were military pilots (or had military experience - Neil Armstrong had retired from the Air Force before he was accepted into astronaut training, but he did have the background) before they became astronauts.
Neil Armstrong was in the United States Navy, not the Air Force.
-
If so can it happen that we are going to run out of lower ranks if there are not enough academies?
while true I don't really see this happening very often especially with the changes to the academies and truthfully i'd rather have this issue then the issue we have now where we have way to many lower rank officers for the amount of Senior officers we need especially if you play like i do and model the entire officer core from O1s to O10s
Agreed. This new system is way better and problems can be handled easier. It "doesn't really matter" if a lot of your 1.000 fighter planes don't have an officer onboard; but it does if there is a broken link in the upper ranks.
-
--- Maybe the wrong thread to make such a request, but could we get the Super Heavy / Ultra Heavy ground weapons rounded out. Or at least the Ultra-Heavy Anti-Vehicle? It bothers me that they're the only class of vehicle currently without a hard counter... :(
-
--- Maybe the wrong thread to make such a request, but could we get the Super Heavy / Ultra Heavy ground weapons rounded out. Or at least the Ultra-Heavy Anti-Vehicle? It bothers me that they're the only class of vehicle currently without a hard counter... :(
The hard counter to these vehicles are either static or medium tanks armed with Heavy Anti-vehicle weapons... these weapons are enough to knock them out. Depending on technology differences your anti-tank platforms are more efficient at their job than these super heavy or ultra heavy platforms, these platforms have such awful fire-power for their cost they are no really useful for anything but role-play.
If you make them more easy to take out they would just become even more worthless from a game mechanic to build.
-
First off, I'm super excited the officer corps mechanics are being re-worked. Having all starting officers being the same age always made me have to look the other way for RP reasons, so thanks for tweaking all that.
Second off, I'd like to second the proposals that starting age either be drastically shifted upwards or made a variable players can set. It would greatly help with immersion, for those who are more into the personnel side of the roleplay, I think. The crew tooltip always mentioned "enlisted and junior officers" for your total racial crew amount, so I always assumed the new lieutenant commanders were being promoted up from that abstract pool of crew, not graduating straight out of the academy.
I've always wanted to write a utility that generates service histories for your officers prior to attaining the minimum rank aurora tracks (generally lieutenant commander) and now that we have proper tracking of age, it's very tempting to jump on this after 2.0 drops. I dunno how much more you want to go into the officer stuff Steve, but if you want to make that a part of the base game as well that would be interesting ;) (basically just looking at what ships existed before an officer is "created" and generating a short history of service for the officer based on their bonuses. E.g., large tactical bonuses maybe had division officer/ department head roles in weapons, maybe the engineering officers had some section duty in an engine room or something, etc.)
-
First off, I'm super excited the officer corps mechanics are being re-worked. Having all starting officers being the same age always made me have to look the other way for RP reasons, so thanks for tweaking all that.
Second off, I'd like to second the proposals that starting age either be drastically shifted upwards or made a variable players can set. It would greatly help with immersion, for those who are more into the personnel side of the roleplay, I think. The crew tooltip always mentioned "enlisted and junior officers" for your total racial crew amount, so I always assumed the new lieutenant commanders were being promoted up from that abstract pool of crew, not graduating straight out of the academy.
I've always wanted to write a utility that generates service histories for your officers prior to attaining the minimum rank aurora tracks (generally lieutenant commander) and now that we have proper tracking of age, it's very tempting to jump on this after 2.0 drops. I dunno how much more you want to go into the officer stuff Steve, but if you want to make that a part of the base game as well that would be interesting ;) (basically just looking at what ships existed before an officer is "created" and generating a short history of service for the officer based on their bonuses. E.g., large tactical bonuses maybe had division officer/ department head roles in weapons, maybe the engineering officers had some section duty in an engine room or something, etc.)
You means something like the Traveller pre-game career path?
-
I tend to think of academies as not as fresh out of school type of institutions but rather like a war college. It RPs better that way, If you ignore the ages lol...
-
First off, I'm super excited the officer corps mechanics are being re-worked. Having all starting officers being the same age always made me have to look the other way for RP reasons, so thanks for tweaking all that.
Second off, I'd like to second the proposals that starting age either be drastically shifted upwards or made a variable players can set. It would greatly help with immersion, for those who are more into the personnel side of the roleplay, I think. The crew tooltip always mentioned "enlisted and junior officers" for your total racial crew amount, so I always assumed the new lieutenant commanders were being promoted up from that abstract pool of crew, not graduating straight out of the academy.
I've always wanted to write a utility that generates service histories for your officers prior to attaining the minimum rank aurora tracks (generally lieutenant commander) and now that we have proper tracking of age, it's very tempting to jump on this after 2.0 drops. I dunno how much more you want to go into the officer stuff Steve, but if you want to make that a part of the base game as well that would be interesting ;) (basically just looking at what ships existed before an officer is "created" and generating a short history of service for the officer based on their bonuses. E.g., large tactical bonuses maybe had division officer/ department head roles in weapons, maybe the engineering officers had some section duty in an engine room or something, etc.)
You means something like the Traveller pre-game career path?
Hehe, yes, that's a bit of a stretch perhaps but that's the idea. ;D
-
Playing my new game, I've just realized there's a potential problem with the new promotion scheme. I got a very long list of officer promotions and reassignments in the beginning of a new year, and it reminded me of this discussion here.
With Aurora C# we don't have tours of duty, but when officers get promoted they leave their posts and get reassigned to new ones, letting other officers assume their old ones (if you use automated assignments). So there's at least a partial rearrangement of the officers in charge, which eventually allows good junior officers to find good positions.
With the new scheme, there'll be even fewer officers being promoted, and the positions being open for assignment and reassignment may not contemplate all skills. So new officers may not find a position for a long time. AFAIK promotion scores also take into account previous postings, and that may compound the problem. Officers may get stuck in a posting, without the skills or score required for a promotion, and block more qualified officers from climbing the ladder, so to speak.
So I think there'll be a need for tours of duty again. Either that, or the player may use the button "Reassign Naval" to simulate tours of duty. There'll be a need for a similar button for ground officers too. There's already a "Reassign All Colony Governors" for administrators, but it's located in the Governor tab in the Economy window.
Which leads to another problem. With the current scheme, I can set some officers with critical skills with "do not promote" so they won't be promoted (and then reassigned). But the "Reassign Naval" button ignores that and reassigns them all, and that's the reason I almost never use it now.
I suggest changing the checkbox "Do not Promote" to "Do Not Remove", and that the "Reassign" buttons respect that in the new version. It would go a long way towards minimizing this problem.
Additionally, if there was a way to find all those officers with that box ticked, and the Academy commanders too, it would prevent the manually assigned officers from clogging up everything. Maybe a button "Unassign Naval" which would unassign (for later reassignment) all the officers with that box unchecked, could be used for that: it would be much easier to pinpoint the remaining officers with postings in the list, and check whether it's time to replace them with someone else.
-
I suggest changing the checkbox "Do not Promote" to "Do Not Remove", and that the "Reassign" buttons respect that in the new version. It would go a long way towards minimizing this problem.
I think this should be considered necessary, the ability to keep an officer in a specific position is essential for roleplay IMO.
The rest... I do not think it is a big concern. The officer promotions will be driven by continual expansion. As more ships are built more command are opened, and over time a smart player will be expanding the admin command hierarchy as well, both as new capabilities are developed and as branches of the hierarchy are needed in other systems and sectors. It's not too likely for the officer ranks to stagnate completely unless the player just stops expanding entirely, which is rather antithetical to the core gameplay of Aurora - one of those four Xs is "eXpand" after all.
-
So I think there'll be a need for tours of duty again. Either that, or the player may use the button "Reassign Naval" to simulate tours of duty. There'll be a need for a similar button for ground officers too. There's already a "Reassign All Colony Governors" for administrators, but it's located in the Governor tab in the Economy window.
Which leads to another problem. With the current scheme, I can set some officers with critical skills with "do not promote" so they won't be promoted (and then reassigned). But the "Reassign Naval" button ignores that and reassigns them all, and that's the reason I almost never use it now.
I suggest changing the checkbox "Do not Promote" to "Do Not Remove", and that the "Reassign" buttons respect that in the new version. It would go a long way towards minimizing this problem.
I already do this to simulate the ADF practice of MIMO (March In, March Out) which generally results in mass changes in assignment on a three year cycle (usually around the summer holidays in Jan/Feb). One year of the three has around 40% of people changing jobs, the other two are a bit lighter and have 20-30% personnel switching. It was a bit easier in VB with the Tour of Duty mechanic but its still adequate. I do notice though that sometimes the reassignment has the same person back in the same slot several times.
-
So I think there'll be a need for tours of duty again. Either that, or the player may use the button "Reassign Naval" to simulate tours of duty. There'll be a need for a similar button for ground officers too. There's already a "Reassign All Colony Governors" for administrators, but it's located in the Governor tab in the Economy window.
Which leads to another problem. With the current scheme, I can set some officers with critical skills with "do not promote" so they won't be promoted (and then reassigned). But the "Reassign Naval" button ignores that and reassigns them all, and that's the reason I almost never use it now.
I suggest changing the checkbox "Do not Promote" to "Do Not Remove", and that the "Reassign" buttons respect that in the new version. It would go a long way towards minimizing this problem.
I already do this to simulate the ADF practice of MIMO (March In, March Out) which generally results in mass changes in assignment on a three year cycle (usually around the summer holidays in Jan/Feb). One year of the three has around 40% of people changing jobs, the other two are a bit lighter and have 20-30% personnel switching. It was a bit easier in VB with the Tour of Duty mechanic but its still adequate. I do notice though that sometimes the reassignment has the same person back in the same slot several times.
I've just tried "Reassign Naval" in my current game, it's the beginning of a new year so I thought it fit. There aren't yet too many officers and jobs so I could check them manually. Besides the micromanagement, I found that it thought many of my ships were "troop transports", because I'd put small troop transport bays in many ships for RP reasons. So my large terraforming station received a logistical specialist with zero terraforming skill instead of the Story Character/Do Not Promote Commander I've given it. My intelligence ship, with a small PD mount, received a tactical specialist with zero intelligence skill... With this setting, I'm not even sure if they'd acquire the necessary skills if I forgot to check on them...
-
I've just tried "Reassign Naval" in my current game, it's the beginning of a new year so I thought it fit. There aren't yet too many officers and jobs so I could check them manually. Besides the micromanagement, I found that it thought many of my ships were "troop transports", because I'd put small troop transport bays in many ships for RP reasons. So my large terraforming station received a logistical specialist with zero terraforming skill instead of the Story Character/Do Not Promote Commander I've given it. My intelligence ship, with a small PD mount, received a tactical specialist with zero intelligence skill... With this setting, I'm not even sure if they'd acquire the necessary skills if I forgot to check on them...
This probably is not a bug. I had a similar issue with survey ships and raised it with Steve, who told me that what happens is that if there are not enough Survey-skilled commanders, a survey ship can also be considered a generic military ship later in the auto-assignment routine and receive a Training/Reaction/Engineering/Tactical-skilled commander. In your case, you probably have run out of eligible Terraforming commanders (especially if many of them are consumed by more-important postings according to the auto-assign logic), and Logistics-skilled commanders are the very last command positions assigned before the sub-command modules are filled.
Class priorities for super-specialized ships like harvester/miner/former stations can address this by bypassing the usual assignment logic - a commander with those skills will correctly be assigned to those roles instead of being tapped for Fighter Pilot duty or whatever.
-
Wondering if we could get an addition to the new officer promotion system? If I want a specific officer to go through a certain career path (for RP reasons) I have to set him as "do not promote". This however is messy when I want to promote him and have to kick out other officers for him. So how about an extra flag? When "Do not Promote" is enabled I could also enable a new slot: If Position XY is vacant promote this officer to that position". That way I can steer some officers into certain places but do it all through the auto routine and all within the basic logic of the game.
-
This probably is not a bug. I had a similar issue with survey ships and raised it with Steve, who told me that what happens is that if there are not enough Survey-skilled commanders, a survey ship can also be considered a generic military ship later in the auto-assignment routine and receive a Training/Reaction/Engineering/Tactical-skilled commander. In your case, you probably have run out of eligible Terraforming commanders (especially if many of them are consumed by more-important postings according to the auto-assign logic), and Logistics-skilled commanders are the very last command positions assigned before the sub-command modules are filled.
Class priorities for super-specialized ships like harvester/miner/former stations can address this by bypassing the usual assignment logic - a commander with those skills will correctly be assigned to those roles instead of being tapped for Fighter Pilot duty or whatever.
I don't think it's a bug, just a limitation of any algorithm when they try to "read the mind" of the human player. At least in the case of the terraforming station, I only have one. And both the highest qualified terraformers were of the correct rank and unassigned after the algorithm ran... so class priority wouldn't have solved that.
Maybe letting us change what category our ship class belongs to? My station *is* classed as "troop transport". If I could change that to "terraformer" in a pull down menu in the Misc tab, that would probably solve it.
-
Maybe letting us change what category our ship class belongs to? My station *is* classed as "troop transport". If I could change that to "terraformer" in a pull down menu in the Misc tab, that would probably solve it.
Maybe I'm just having a dumb day, but I can't see any rules for auto-assignment/classification of ships.
I can find the ones for Commander Auto-Assignment, which doesn't list troop transport capacity at all.
http://aurora2.pentarch.org/index.php?topic=8495.msg104046#msg104046
Either way I think the algorithm should consider whether the troop transport module is larger or smaller than say 10% of the ship mass.
It could also use the presence or absence of Cargo Shuttle Bays to determine if a ship needs a logistics commander, rather than having it as a final fallback option.
Aside from that, being able to override the category for a ship might be useful.
It might also be useful to be able to pick a specific ship category for a commander, and they are assigned to that category exclusively or as first choice.
Although I suspect what most people desire is a "do not automatically unassign" button.
-
Having the ability to set auto assignment "classes" manually would be nice, I agree. I like to arm my survey ships sometimes for RP (currently doing a star trek run) and the auto assignment likes to put tactical officers on them.
-
--- Could we get a button like in VB6 where you could Research everything up to a certain amount of RP?
-
About the new jump shock change, does it mean AI would no longer jump back and forth a jump point every 5 seconds, causing unwanted 5 sec interrupts?
-
About the new jump shock change, does it mean AI would no longer jump back and forth a jump point every 5 seconds, causing unwanted 5 sec interrupts?
Yes, but unless it's the result of fleeing from an armed opponent, it may result in unwanted 1 minute interrupts. Depends on how the AI handles it, and if it tries to burn away. At the very least it should increase increment lenght
-
I can't believe my scientist house rule of all things made it into an update. :o
-
About the new jump shock change, does it mean AI would no longer jump back and forth a jump point every 5 seconds, causing unwanted 5 sec interrupts?
I am pretty sure, it will change that to 1 minute interrupts with you being able to engage the enemy fleet. There was simply nothing you could do before, as your ships had a reaction time and the enemy fleet would simply disappear. I wasted quite some missiles in these "engagements".
I think the changes to research administration are quite good, as I preferred the slower progression as well. This makes capturing and reverse engineering a lot more viable as well. These are instantaneous and give significant boosts in certain fields. Maybe we could get research points from captured missiles and armor as well. I am pretty sure armor could be reverse engineered in VB6 and cannot be in C#.
-
Limited Research Facilities
A new game-level option called 'Limited Research Facilities' has been added for v2.0.
May be semantics and nitpicking ::) but wouldn't it make more sense to call it Limited Research Administration instead as it's not the Facilities that are limited but rather how many can be administered?
-
Limited Research Facilities
A new game-level option called 'Limited Research Facilities' has been added for v2.0.
May be semantics and nitpicking ::) but wouldn't it make more sense to call it Limited Research Administration instead as it's not the Facilities that are limited but rather how many can be administered?
Yes, that is a good point. I'll make the change.
-
I can't believe my scientist house rule of all things made it into an update. :o
Yes, I thought it was a good idea when I read about it. I've tried the slower research speeds and it seemed too slow, but this seemed like a good way of slowing engine progression while maintaining overall research speed.
-
I've tried playing with the limited research admin house rule, and one thing I noticed is that it tends to discourage research specialization: I typically had many more research facilities than could be used by my best researchers, so I ended up assigning lots of mediocre researchers to work on lower-priority techs. Since I was playing with two player factions, this meant that both factions ended up with more or less the same technologies, which was somewhat boring. Of course I could've just built fewer research facilities... 8) I think I ended up changing the house rule to (admin capacity)/3 with like 50% research speed, or something like that, which allowed the two factions to specialize a bit more.
Anyway, I'm still a fan of the new option. It would be nice if it were a bit more customizable so we could really tune the admin capacity/research speed to our liking, but I'll take what I can get. :)
-
I've tried playing with the limited research admin house rule, and one thing I noticed is that it tends to discourage research specialization: I typically had many more research facilities than could be used by my best researchers, so I ended up assigning lots of mediocre researchers to work on lower-priority techs. Since I was playing with two player factions, this meant that both factions ended up with more or less the same technologies, which was somewhat boring. Of course I could've just built fewer research facilities... 8) I think I ended up changing the house rule to (admin capacity)/3 with like 50% research speed, or something like that, which allowed the two factions to specialize a bit more.
Anyway, I'm still a fan of the new option. It would be nice if it were a bit more customizable so we could really tune the admin capacity/research speed to our liking, but I'll take what I can get. :)
I've had a similar experience in the early game, though once you start generating scientists you start to run up a bigger stable and they gain admin skill so the issue is mitigated a bit. However I am a big fan of Steve's "20% plus 1" implementation as it addresses this exact problem quite neatly.
-
Question is if something is needed lategame to not slow down research of the last techs until forever with so few labs? I don't normally play lategame but maybe a few techs adding one or two labs capability per scientist becoming available very lategame could be a decent solution to this 100% imagined and speculative issue ::).
-
Question is if something is needed lategame to not slow down research of the last techs until forever with so few labs? I don't normally play lategame but maybe a few techs adding one or two labs capability per scientist becoming available very lategame could be a decent solution to this 100% imagined and speculative issue ::).
It is not too different from what we have now, the overall research rate remains the same the only difference is that you are not able to rush techs and will be researching 4-5 times as many techs at any given time. It's true that you aren't able to rush each propulsion tech tier very easily, but once you factor in the corresponding fuel efficiency, engine size, reactor, etc. techs you will be developing in parallel rather than sequentially your overall rate of progress will not be much different. Remember particularly for engines that you can develop the reactor and engine technologies in parallel, as the reactor tech of one tier is the sole prerequisite for the engine tech of that tier and the reactor tech of the next tier.
In the other fields, once you have a large stable of scientists you will maintain persistent research efforts in that field instead of occasionally bum-rushing the next level of laser or something before going back to your regularly scheduled propulsion rushing. Still the same rate of progress, just more evenly instead of in brief spurts which fits well the long-term focus of Aurora.
-
Also there will may be some reduction in overall research speed as the average skill of active scientists may be lower (assuming not enough top tier scientists across all fields to use all available facilities), but it is still likely to still be a high percentage of current speed.
-
It is not too different from what we have now, the overall research rate remains the same the only difference is that you are not able to rush techs and will be researching 4-5 times as many techs at any given time. It's true that you aren't able to rush each propulsion tech tier very easily, but once you factor in the corresponding fuel efficiency, engine size, reactor, etc. techs you will be developing in parallel rather than sequentially your overall rate of progress will not be much different. Remember particularly for engines that you can develop the reactor and engine technologies in parallel, as the reactor tech of one tier is the sole prerequisite for the engine tech of that tier and the reactor tech of the next tier.
In the other fields, once you have a large stable of scientists you will maintain persistent research efforts in that field instead of occasionally bum-rushing the next level of laser or something before going back to your regularly scheduled propulsion rushing. Still the same rate of progress, just more evenly instead of in brief spurts which fits well the long-term focus of Aurora.
There is a cap though when expanding labs for how many parallel projects that are possible to run at the same time before running out of projects, with max labs on all of them.
The main concern is that tech costs range from something like 1000 - 5,000,000 RP (x5000 increase) while Research Rate ranges from 200 - 1500 (x7.5 increase). With lower admin caps you should in theory hit the cap of researching every potential available tech in parallel with maximum number of labs much sooner in your lab expansion, and you should be frustrated much earlier that that by having nothing useful to put labs on.
-
"For v2.0, you can toggle a colony to be ignored for automated refuelling orders."
Hallelujah!
-
There is a cap though when expanding labs for how many parallel projects that are possible to run at the same time before running out of projects, with max labs on all of them.
The main concern is that tech costs range from something like 1000 - 5,000,000 RP (x5000 increase) while Research Rate ranges from 200 - 1500 (x7.5 increase). With lower admin caps you should in theory hit the cap of researching every potential available tech in parallel with maximum number of labs much sooner in your lab expansion, and you should be frustrated much earlier that that by having nothing useful to put labs on.
My assumption is that by the time a player race is concerned about such things, you would have multiple scientists in every field with very good, if not maximum, research and admin skills. Scientist careers are something like 40 years long unless they die in an accident, etc., which is plenty of time to receive a lot of skill-ups and with a robust array of academies you should not have much problem with generating and training new younger scientists to keep up a high quality of replacements in each field. Even if you choose to arbitrarily limit some techs (usually weapons, e.g. beam-only games) there are enough useful techs in the game that you can maintain several dozen more or less ongoing projects particularly if you diversify over time (ECM/ECCM, shields, cloaking, new weapon types, etc.).
As far as the tech cost scaling by ~2x per level, this is by design as it is pretty much expected that the player will hit a "plateau" after the early techs beyond which progress is quite slow and more about incremental advantages and new capabilities. Frankly the game really isn't balanced for playing up to MaxTech as some have found.
-
One comment on the whole "laboratory" system. The trouble with this is it is utterly artificial. Research is not something you can direct like this, and though it will likely upset the munchkins greatly I'd suggest getting rid of the laboratory. I would suggest replacing it with a population based research rate: population*population_factor*(base_racial_research_rate+modifiers)*(multipliers). I would then have the lead scientist in each field's skill be a modifier or a multiplier if that makes it better from a game perspective. I would have the increase research rate be a modifier or a multiplier or a change to the population factor (again based on what makes more game sense). Then I would have different single things you can build on a planet that add a flat bonus. These reflect things like LHD, ITER or other large scale science mega projects. They would add a modifier to a particular line of research, but should be rather expensive to produce.
This could be then further extended by making it possible for a race to be gifted or not so gifted in one field or another. I would also make the population_factor somewhat dependent on the population so you get the most research from a large population but a new colony gives more per population up to a point then it drops down to reflect the fact that the new colony may have interesting new aspects (and this could again be developed so a colony only gives the bonus to one line or more lines of research). Basically a new colony has the potential for inspiring new and exciting developments until well they are all found.
The cost of this should be credits (except the special buildings which clearly could have a mineral cost). For each line of research the player chooses the development queue and they are worked on in that order (just as now).
The research is in all available fields at the same time. There is no real way to do the sorta crazy "we research only this thing" that is done and especially not the dramatic swapping that is done. The government could of course give extra money to one research area and increase its speed but that should cause a drop in the rate of the others. There are only so many students after all and if they are researching propulsion then none are there to do other stuff and the other research slows down.
Ruins could then yield Research points in a field which would be dumped into a current research field or be specific to one type of item and would be available when that was under development. There could also be find "x RPs" which are added to all fields representing finding a science facility.
The lead scientists skill in the field and his administration skill should both modify the number of RPs he produces.
This to me represents "research" more realistically. It is a factor of the number of universities, corporate research groups, and government sponsored laboratories rather than a pool of "laboratories" shuffled around to research x-ray lasers one week and anti-gravity tanks the next.
-
I have always considered that a "laboratory" in Aurora actually represents a large set of research infrastructure including various institutes, user facilities, server farms, universities and other educational institutions, and others all of which might be grouped purely as an administrative unit or might be earmarked to support a flagship facility - ITER, LHC, and so on. All of course highly abstracted, with your "scientist" really being the head of a quite large research division or department. I think this is generally the best way to look at planetary facilities in Aurora, not as single discrete units but rather as reflecting the infrastructure in place to direct the efforts of the employed population towards the goals of your space empire - which can then be shipped around to the desired colonies to direct the efforts of the entire space empire, an important element in a game which has space logistics at its heart I would say.
I will agree that it is quite unrealistic to have labs be hot-swapped at a moment's notice, but frankly it is the same issue we have with construction factories so it is not unique to labs. We could in principle implement some kind of "retooling" mechanic for labs, factories, etc. but while I don't think this would be a "bad" mechanic I do think it is not well-suited for Aurora. It adds simulationism, but not really interesting decisions besides forcing a particular style of gameplay - what I mean by this is that it does force the player to "intelligently" set their industrial or research priorities and only change them slowly, but this doesn't actually add any mechanical depth to the game as the player is only incentivized to make a change when their hand is forced by the game situation. The economic depth of mechanics is not enough that a game of micromanaging the economic balance is really engaging.
IMO the mechanics work best as they are, as far as Aurora works, because the flexibility while it may not be the "most realistic" allows freedom of roleplay while maintaining good balance of gameplay. For those who want a very specific style of play Aurora has always offered great flexibility to create house rules to model whatever we want.
-
One thing I think maybe should be changed is subdividing the current laboratories (10x factory cargo size, 1 mil pop, 2400 construction cost, 200 RP generated) into 10 factory-sized facilities (scaling scientist admin capacity accordingly). Partly out of a desire to avoid having to deal with partial loading of facilities, which Aurora handles... acceptably but not well. And partly out of a desire to make conventional starts more practical (when you can only churn out 1 lab every 3 years you get a strange outcome where you lay the last brick and suddenly your research capacity is increased by 20 %).
Ideally I'd want to turn research point generation into a pool that scientists draw from until her project is fully funded (per her admin cap), then the next scientist in the queue gets to draw, etc. down the priority queue (with the possibility to set a cap on how much a given scientist can draw, e.g. if you want to synchronize certain projects, or want to spread out research for RP reasons). But that is a much more intrusive change than just re-scaling the installation size.
(Also, the same logic could be applied to ground forces formations and even factory construction, giving all non-shipyard planetary production a unified mechanic and interface. Which seems aesthetically pleasing, reasonable and in line with the ambition to unify more game mechanics in this edition.)
-
One thing I think maybe should be changed is subdividing the current laboratories (10x factory cargo size, 1 mil pop, 2400 construction cost, 200 RP generated) into 10 factory-sized facilities (scaling scientist admin capacity accordingly). Partly out of a desire to avoid having to deal with partial loading of facilities, which Aurora handles... acceptably but not well. And partly out of a desire to make conventional starts more practical (when you can only churn out 1 lab every 3 years you get a strange outcome where you lay the last brick and suddenly your research capacity is increased by 20 %).
Ideally I'd want to turn research point generation into a pool that scientists draw from until her project is fully funded (per her admin cap), then the next scientist in the queue gets to draw, etc. down the priority queue (with the possibility to set a cap on how much a given scientist can draw, e.g. if you want to synchronize certain projects, or want to spread out research for RP reasons). But that is a much more intrusive change than just re-scaling the installation size.
(Also, the same logic could be applied to ground forces formations and even factory construction, giving all non-shipyard planetary production a unified mechanic and interface. Which seems aesthetically pleasing, reasonable and in line with the ambition to unify more game mechanics in this edition.)
IIRC Steve was considering switching ground force production to use a similar system to construction/ordinance/fighter factories, though I don't remember if that ever went through.
Honestly, I'd really love for facility size to be standardized as much as possible, if only because then I wouldn't have to keep looking up how many freighters/how much to repeat every time I wanted to move something. Maybe not feasible for spaceports, since those kind of feel like it's supposed to be a big hauling job to make a colony "established", and I get the reasoning involved in refueling stations and forced labor stuff being hard to move. But I'd love it if infra, research facilities, terraforming installations, ground force training, etc all got standardized at 25,000 tons while keeping the same efficiency per ton.
-
IIRC Steve was considering switching ground force production to use a similar system to construction/ordinance/fighter factories, though I don't remember if that ever went through.
I know it has not yet been done, but I sincerely hope Steve chooses to implement this. Although the change to double generation of ground (and naval) officers should help indirectly since the necessary formation sizes for efficient use of commanders will be reduced somewhat, but this isn't really a fix per se.
Honestly, I'd really love for facility size to be standardized as much as possible, if only because then I wouldn't have to keep looking up how many freighters/how much to repeat every time I wanted to move something. Maybe not feasible for spaceports, since those kind of feel like it's supposed to be a big hauling job to make a colony "established", and I get the reasoning involved in refueling stations and forced labor stuff being hard to move. But I'd love it if infra, research facilities, terraforming installations, ground force training, etc all got standardized at 25,000 tons while keeping the same efficiency per ton.
I'd probably not want to see standardization at a single size, flavor-wise it makes sense that different things should be at different sizes, but I do think collapsing the sizes into more comprehensible values would be very helpful. Something like 2,500-tons for infrastructure, 25,000 tons for most production facilities, and 250,000 tons for the large facilities (terraformer, lab, GFTC, etc.) makes sense. This is 10x, 1x, and 0.1x to a cargo hold which is a lot easier to remember but still varied in a sensible way.
-
If a research facility is anyway a whole multiple-location thing with off-site data centers, several laboratory wings and so on, it doesn't really make a lot of sense that it can't be built and shifted piecemeal. I get the argument that there might be economies of scale and a certain minimum size to get started, but that's also true for construction factories and their supply chains.
Infrastructure I would just measure in tons cargo space instead of points - in practice it is always deployed in large enough quantities that the discrete units don't matter, and there's no mechanic that requires us to "allocate" infrastructure point by point.
Keeping the Terraformer at 10 factories load weight makes sense to me, since that makes keeps it comparable to the orbital terraforming module. Spaceports also seem like they should be 10x, both for gameplay and fluff reasons. I could construct an argument either way for the GMC, depending on how you fluff it.
The GFCF is a middle case. It clearly includes all manner of manufacturing and even heavy industry, which it seems to me should operate on the same principles as the construction factories. But it also includes actual training facilities, which have to be large and are generally cumbersome to relocate (it takes a lot of space to do effective training maneuvers, especially once you get to division and corps level deployments - it's expensive too, but it is absolutely essential to maintain a good state of readiness).
-
About facilities sizes. Actually I would prefer the size being displayed somewhere in the game proper. Possibly in fleet order screen where we can see how many facilities it will be able to move.
With that, then we don't need to refer to a picture outside the game and do mental calculations while still allowing differing facility sizes.
-
About facilities sizes. Actually I would prefer the size being displayed somewhere in the game proper. Possibly in fleet order screen where we can see how many facilities it will be able to move.
With that, then we don't need to refer to a picture outside the game and do mental calculations while still allowing differing facility sizes.
This is such a great suggestion. Yes of course all veterans KNOW how big a facility is, and how many cargo spaces we need on our cargos due to that.
But.... having the size displayed in game would be SO helpful for a lot of people.
-
About facilities sizes. Actually I would prefer the size being displayed somewhere in the game proper. Possibly in fleet order screen where we can see how many facilities it will be able to move.
With that, then we don't need to refer to a picture outside the game and do mental calculations while still allowing differing facility sizes.
This is such a great suggestion. Yes of course all veterans KNOW how big a facility is, and how many cargo spaces we need on our cargos due to that.
But.... having the size displayed in game would be SO helpful for a lot of people.
Added for v2.0.
http://aurora2.pentarch.org/index.php?topic=12523.msg158272#msg158272
-
About facilities sizes. Actually I would prefer the size being displayed somewhere in the game proper. Possibly in fleet order screen where we can see how many facilities it will be able to move.
With that, then we don't need to refer to a picture outside the game and do mental calculations while still allowing differing facility sizes.
This is such a great suggestion. Yes of course all veterans KNOW how big a facility is, and how many cargo spaces we need on our cargos due to that.
But.... having the size displayed in game would be SO helpful for a lot of people.
Added for v2.0.
http://aurora2.pentarch.org/index.php?topic=12523.msg158272#msg158272
--- Praise Sobek!
-
I think that foe the new transport information instead of displaying the number of cargo hold needed for installation it should instead tell the size in tonne. It would help with because the game have different number of cargo hold.
-
I think that foe the new transport information instead of displaying the number of cargo hold needed for installation it should instead tell the size in tonne. It would help with because the game have different number of cargo hold.
--- Or use "Standard Cargo Holds" instead. It works ok as presented, IMO, but yeah tonnage would be nice.
-
It would work for my cargo and my freighter but most of my cargo ship are using the small cargo hold.
Mistral class: 5'000 tonnes of cargo capacity (I have 10 of dose) Mostly for inta system (i don't like the mass driver idea so i don't use them)
Mercury class:25'000 tonnes of cargo capacity (I have 2 of dose) Mostly for inter stellar transport mineral. Also carry salvage and some time mine and infrastructure.
Mammoth class: 125'000 tonnes of cargo capacity (I have 6 of dose) To move big stuff lab/spaceport/refuelling station
Class name TBD in concept station with big cargo to be use when my tug are ideling and most of the time it is not the case. The often have years of work waiting to be done.
-
I think representing the tonnage in 'k' would be compact enough to fit into the display window. Factory = 25k, Terraformer = 125k, and so on - much more compact than writing out all the zeroes.
Speaking of Terraformers, while we're changing things can we balance the cost of the installation and the ship module? The ship module is cheaper and otherwise superior in almost every way, really could stand to be tweaked slightly.
-
No Nuclearslurpee you don't touch my mega TF starbases :)
All jokes aside, i could stand a slight tweek with TF installations and ship board platforms, maybe make the ship board 50% more expensive or have a rate penalty ( like ship board are one tech level lower then racial or something for terraforming rate)
-
No Nuclearslurpee you don't touch my mega TF starbases :)
I won't touch them... aims particle lance ;D
-
Steve,
Thanks for the new Squadron features. I tend to make carrier heavy fleets - frankly everything destroyer or above as a hanger deck or boat bay - and I missed the VB6 squadron feature. Question: Can you assign commanders to the Squadrons? Or will they use the most senior ship commander? If commanders are used, what are the auto assignment rules?
Thanks for the new features you have chosen for 2.0. You have addressed damn near all my requests or annoyances of earlier versions and gotten me real excited to take 2.0 for a spin.
-
Steve,
Thanks for the new Squadron features. I tend to make carrier heavy fleets - frankly everything destroyer or above as a hanger deck or boat bay - and I missed the VB6 squadron feature. Question: Can you assign commanders to the Squadrons? Or will they use the most senior ship commander? If commanders are used, what are the auto assignment rules?
Thanks for the new features you have chosen for 2.0. You have addressed damn near all my requests or annoyances of earlier versions and gotten me real excited to take 2.0 for a spin.
They will use the most senior ship commander.
-
Cool - one thing that I typically do with my 'squadrons' to replicate progression is I make a 'CX' version of every fighter class which is the same as the baseline fighter version except I have the 'senior CO' block checked so I can simulate a Squadron Commander. I'll continue that here with this new feature so I can have Lieutenant Commanders commanding my Squadrons rather than Lieutenants (my lowest officer rank).
-
Now I am hoping that Steve will somehow encounter a situation where he wants to provide CAS to ground units so that it also gets improved.
The squadron changes are really nice for the sake of management but also just differentiating sub-fleets from fighter wings at a glance.
One thing I will ask though - How does this interact with a carriers fighter-hoover function when new fighters are being built. Right now we can in the class design give a carrier a default strike group, but will we also be able to go further and create a default squadron configuration? I think that would be a great QOL feature cuz right now it sounds like we need to re-create squadrons for every carrier that is built.
-
It would be useful if individual parasites remembered which squadron they were last part of, and had a "go to task group A, land on your assigned mothership, rejoin the squadron." It would prevent you from having click through a sub-menu navigation to find the correct squadron.
-
Steve,
Thanks for the new Squadron features. I tend to make carrier heavy fleets - frankly everything destroyer or above as a hanger deck or boat bay - and I missed the VB6 squadron feature. Question: Can you assign commanders to the Squadrons? Or will they use the most senior ship commander? If commanders are used, what are the auto assignment rules?
Thanks for the new features you have chosen for 2.0. You have addressed damn near all my requests or annoyances of earlier versions and gotten me real excited to take 2.0 for a spin.
They will use the most senior ship commander.
Shouldn't it be the CAG, if there is one?
-
It would be useful if individual parasites remembered which squadron they were last part of, and had a "go to task group A, land on your assigned mothership, rejoin the squadron." It would prevent you from having click through a sub-menu navigation to find the correct squadron.
Yes, I agree. This occurred me last night after I went to bed :)
I'll add an assigned squadron in the same way as an assigned mothership.
-
Big thanks for adding back a squadron mechanic, even in a reworked form. Will it have an auto random name like in VB6?
-
So uhm.. How tricky would it be to let Fighters to support ground units one Squadron at a time instead of one fighter? ::) Asking for a friend...
-
It would be useful if individual parasites remembered which squadron they were last part of, and had a "go to task group A, land on your assigned mothership, rejoin the squadron." It would prevent you from having click through a sub-menu navigation to find the correct squadron.
Yes, I agree. This occurred me last night after I went to bed :)
I'll add an assigned squadron in the same way as an assigned mothership.
I've updated the original post (and the code) to include the 'assigned squadron':
http://aurora2.pentarch.org/index.php?topic=12523.msg158331#msg158331
-
Thanks Steve, at least getting dusted on the fighter module post has had its effects ;D ;D ;D
I am glad squadrons are back as it will allow managing big fighters groups in a more comprehensive way.
I am really looking forward to 2.0 now and I know we always say it's ready when it's ready but if we were to give a pin, would it be prior to or after Distant Worlds 2?
I guess you are going to put your hands on that too and it may take a good chunk of your time for a few weeks at least...
-
LOVE the new squadron mechanics! Think we can get a way to assign a squadron leader either by adding in a 'flag bridge' for Fighters (basically a fancy radio i'm guessing) or special rules where fighter only fleets can benefit from the skills of their leader?
Perhaps then since Squadron are always assigned to a ship regardless of if they are docked or not, the officer assigned to Primary Flight Control could contribute their skills from the Mothership and act as a proper Commander, Air Group for all the ships attached squadrons.
-
Since a carrier might carry multiple squadrons, CAG aboard the ship is in command of them all. For squadron leaders, the best way is to use that example mentioned before - create a Command version of your fighter that's identical and tick the "Senior CO" box so that instead of R1 it gets a R2 officer commanding it who will then automatically become the squadron commander via being the most senior officer present.
-
Since a carrier might carry multiple squadrons, CAG aboard the ship is in command of them all. For squadron leaders, the best way is to use that example mentioned before - create a Command version of your fighter that's identical and tick the "Senior CO" box so that instead of R1 it gets a R2 officer commanding it who will then automatically become the squadron commander via being the most senior officer present.
But what rank would the CAG be? It'd be weird if the CAG doesn't outrank the squadron leaders.
-
By wet navy traditions, the CAG should be 1 rank lower than the Captain, generally speaking. CVs are also considered to be capital ships and often flagships, although that is partly because the CV has displaced the BB as the ultimate expression of power projection at sea, which is not necessarily true of a space navy in Aurora
-
Since a carrier might carry multiple squadrons, CAG aboard the ship is in command of them all. For squadron leaders, the best way is to use that example mentioned before - create a Command version of your fighter that's identical and tick the "Senior CO" box so that instead of R1 it gets a R2 officer commanding it who will then automatically become the squadron commander via being the most senior officer present.
But what rank would the CAG be? It'd be weird if the CAG doesn't outrank the squadron leaders.
Considering that carriers will probably be your biggest ships so they will be commanded by senior officers, perhaps even flag officers, and fighters are generally piloted by R1 officers, there should be able room between the two for CAG to be higher rank than squadron senior officer. For example, using USN ranks in Aurora:
Fighter pilot - R1 "lieutenant-commander"
Squadron CO - R2 "commander"
CAG aboard a carrier - R3 "captain"
Carrier CO - R4 "rear-admiral (lower half)"
And you could always insert lieutenant as the new R1 and now that we can truly have 1-2 crew fighters, that will make even more sense than before, and thus save all admirals for naval commands.
-
Not laid out explicitly in the actual change post, but I do want to point out that the change to short-deployment crews is actually a small buff to fighter-based races. Given how many fighters a typical carrier fleet needs, reducing the amount of crew needed eases the burden on academies that train crews and allows using a higher academy training level, so crews should be a bit better-trained on average. Given the difficulty of maintaining well-trained fighter crews (lack of Training-skilled commanders + difficulty of refitting fighters to preserve experienced crews) this is a good mechanical change for fighters - in addition to the flavor which many players have wanted.
-
Not laid out explicitly in the actual change post, but I do want to point out that the change to short-deployment crews is actually a small buff to fighter-based races. Given how many fighters a typical carrier fleet needs, reducing the amount of crew needed eases the burden on academies that train crews and allows using a higher academy training level, so crews should be a bit better-trained on average. Given the difficulty of maintaining well-trained fighter crews (lack of Training-skilled commanders + difficulty of refitting fighters to preserve experienced crews) this is a good mechanical change for fighters - in addition to the flavor which many players have wanted.
I did briefly mention it right at the bottom of the post :)
-
I hoped for single crewed fighters for a long time this is very nice. This will also let my hospital ships be less crowded with ejected pilots after a large engagement.
-
I did briefly mention it right at the bottom of the post :)
I should clarify - you did mention the reduced crew requirements for fighter-heavy navies; I am just highlighting the further impact of this in terms of crew training levels, which addresses a long-standing downside of fighter-based fleets. :)
-
@Fighter Crew Changes
Note for the formula - It can be slightly simplified to:
Crew = Round Down ( Crew * ( (Planned Deployment / 3 )^(1/3) ) )Since the calculation isn't done that often, it might not matter I think, but in case it does, this versions otherwise avoids one of the costly fractional exponential calculations, and also aids in oversight to see how the effect works.("actual crew reduction is equal to 'the fraction of Deployment against 3 Months' with the cube root smoothing continuing")
-
By wet navy traditions, the CAG should be 1 rank lower than the Captain, generally speaking. CVs are also considered to be capital ships and often flagships, although that is partly because the CV has displaced the BB as the ultimate expression of power projection at sea, which is not necessarily true of a space navy in Aurora
Akshully, in the US Navy at least the CAG is actually a full Captain and answers to the commander of the Carrier Task Force rather than the Captain of the CV. Kinda weird I know.
On another note, how easy would it be to change the default starting age of officers from 21 to 30? If I start tracking officers when they are Lt. Commanders, it makes more sense for them to be in their 30s rather than early 20s.
It would be great if 'starting age' was something you could edit using the Race screen so every race is different based on how long their lifespans are.
-
May we have an option to not allow an C.O to be assigned to a ship? like a checkbox in ship design or in the ship screen. so we don't have every promising officer assigned to the small craft forces or merchant fleets.
-
May we have an option to not allow an C.O to be assigned to a ship? like a checkbox in ship design or in the ship screen. so we don't have every promising officer assigned to the small craft forces or merchant fleets.
That is already in v2.0.
http://aurora2.pentarch.org/index.php?topic=12523.msg157284#msg157284
-
This is a minor thing, but on the new reduced crew formulas, you use "Personnel" for one formula and "Crew" for the other. Can you change them to be the same, unless there is a difference I'm missing?
Glad to see the small refueling system; I don't use fighters often, but when I do I always have a tanker/fighter/FAC on all the larger carriers.
-
Steve, will officers without a relevant qualification be assigned to roles now? For example, will a terraforming base receive a commander if no free officer has a terraforming bonus, or will it sit empty? And will commanders without a relevant bonus be able to gain that bonus if they're assigned to that role? I know you considered giving everyone a 1% bonus in every field, but I don't know what came of that discussion.
-
Minor suggestion but I think the small refueling system should be renamed to something like "Small Craft Refueling System" or similar, something to make it clearer to new players that this is not just a smaller version of the existing systems but something that can only work with small ships.
(of course it should also have the 1000 ton restriction in the description, but just to be sure)
-
About the new small refuelling system, does the 1000 ton limit apply to the ship hosting it? If I make a 5000 ton ship that sport a small refuelling system, can it refuel other 1000 ton ship? Can it refuels from colonies or refuelling hubs?
-
Oh cool beans! This is also a boost for conventional games because tankers can now be lot smaller!
-
This is a minor thing, but on the new reduced crew formulas, you use "Personnel" for one formula and "Crew" for the other. Can you change them to be the same, unless there is a difference I'm missing?
Glad to see the small refueling system; I don't use fighters often, but when I do I always have a tanker/fighter/FAC on all the larger carriers.
They are different. Personnel is crew + flight crew. Crew is just the ship's crew without anything for the hangars.
-
Minor suggestion but I think the small refueling system should be renamed to something like "Small Craft Refueling System" or similar, something to make it clearer to new players that this is not just a smaller version of the existing systems but something that can only work with small ships.
(of course it should also have the 1000 ton restriction in the description, but just to be sure)
Good idea - I will make the change.
I did include the restriction in the tech description.
-
About the new small refuelling system, does the 1000 ton limit apply to the ship hosting it? If I make a 5000 ton ship that sport a small refuelling system, can it refuel other 1000 ton ship? Can it refuels from colonies or refuelling hubs?
Yes, it does. I've added that to the post.
-
When can we expect to play the new version? :D
-
When can we expect to play the new version? :D
I'm playing it now :)
A few weeks probably, unless life gets in the way again.
-
When can we expect to play the new version? :D
I'm playing it now :)
A few weeks probably, unless life gets in the way again.
Man that would be great but it is looking like the next 30 days are going to be a logjam of gaming for me. Crusader Kings 3 expansion + Total Warhammer 3 + Distant Worlds 2 are all coming out in the next 30 or so days. Doesn't mean I'm not dropping something to tuck into a v2.0 campaign though.
-
All hail our lord and saviour micro QoL changes to fighters XD
-
"If the parasites are attached to one or more squadrons"
Does this mean you can have a ship attached to more then one squadron at a time?
-
"If the parasites are attached to one or more squadrons"
Does this mean you can have a ship attached to more then one squadron at a time?
No, it means if the parasites as a group belong to one or more squadrons. Each parasite can only be in one squadron.
-
When can we expect to play the new version? :D
I'm playing it now :)
A few weeks probably, unless life gets in the way again.
Noooooooo!
That will mean around the same time as Totalwar: Warhammer 3 releases!
Having to pick between the two just won't be fair. :(
-
When can we expect to play the new version? :D
I'm playing it now :)
A few weeks probably, unless life gets in the way again.
Noooooooo!
That will mean around the same time as Totalwar: Warhammer 3 releases!
Having to pick between the two just won't be fair. :(
I'm very bad at forecasting release dates, which is why I tend not to give them, so don't worry about it :)
-
Does the limited research administration option affect NPR research at all?
-
Does the limited research administration option affect NPR research at all?
No. NPR research is implemented so that when they accumulate X research points, they unlock an entire tech tier at once. Personally I dislike this because it makes NPR tech progression weaker than player race progression (as players benefit from every incremental advance as it is developed), but since the mechanic is different it is not affected by the stats of scientists applied to specific projects or fields.
-
Really awesome changes. I submit a small flavor tweak that I think could be nice: perhaps squadrons could track stats like ships do? Kills, distance travelled, medals awarded, etc. To give them more of an identity and a reputation
-
Since Steve is already putting some stuff out there for non conventional start, would it be possible to have conventional geological ground units? It would make it a blast for me to be able to make a conventional start with virtually nothing, low population, low birth rate and 0.3 research rate (Which i think is closer to what it would be in real life, considering that each research lab has a *lot* of scientists in them).
Or at least make it in a way that geological missiles can make this work for them, like it could on earlier versions of the game? (I think that in theory it should work, but i havent had any luck with that so far).
Also, and i know this would be better at the suggestions, but im already here, would it be possible to have a little more macro options? For instance, in v6 we had the option to make training exercises with a button, it would be nice to have the ships actually patrol a system or several systems, based on the decisions the player makes or the route they decide to take? That could be tied up with the idea of planet protection, which now we dont have ships sitting on orbit doing nothing, they are actually patrolling colonies and mining spots gaining some crew grade in the process. (Heck, there is even space to make the risk of the ship taking damage to systems double or being multiplied by something while doing these, so that it requires some rotation and we can RP damage from piracy and etc).
-
Since Steve is already putting some stuff out there for non conventional start, would it be possible to have conventional geological ground units? It would make it a blast for me to be able to make a conventional start with virtually nothing, low population, low birth rate and 0.3 research rate (Which i think is closer to what it would be in real life, considering that each research lab has a *lot* of scientists in them).
Or at least make it in a way that geological missiles can make this work for them, like it could on earlier versions of the game? (I think that in theory it should work, but i havent had any luck with that so far).
Also, and i know this would be better at the suggestions, but im already here, would it be possible to have a little more macro options? For instance, in v6 we had the option to make training exercises with a button, it would be nice to have the ships actually patrol a system or several systems, based on the decisions the player makes or the route they decide to take? That could be tied up with the idea of planet protection, which now we dont have ships sitting on orbit doing nothing, they are actually patrolling colonies and mining spots gaining some crew grade in the process. (Heck, there is even space to make the risk of the ship taking damage to systems double or being multiplied by something while doing these, so that it requires some rotation and we can RP damage from piracy and etc).
I'd like to see conventional geo-survey be ground-team only. Makes sense you'd have to rely on good-ol' boots-on-the-grounds geologic work to prospect research before you unlock the secrets of the magic rocks.
Speaking of ground geo-survey, is it a gamble? I'm pretty sure they can actually find LESS of a resource than previously scanned, reducing the accessibility/maximum amount of a resource. Strange thing is if you just left well enough alone I don't believe you'd lose those resources in the first place; the cosmos are just punishing you for being too nosey.
-
Speaking of ground geo-survey, is it a gamble? I'm pretty sure they can actually find LESS of a resource than previously scanned, reducing the accessibility/maximum amount of a resource. Strange thing is if you just left well enough alone I don't believe you'd lose those resources in the first place; the cosmos are just punishing you for being too nosey.
It will only ever add resources; if the new survey result would be worse it is simply discarded.
-
Will we see an option in the allocation of ingame funds that permit us to set the budget for military academies and thus increase/decrease their annual output of officers as needed?
-
Will we see an option in the allocation of ingame funds that permit us to set the budget for military academies and thus increase/decrease their annual output of officers as needed?
Currently, you can build additional academies if you want more officers and use commandants to affect the types of officers produced.
-
Can you make squadrons a different colour to sub-fleets?
For v2.0, the accommodation formula above remains in place but it will use a minimum value of 3 for planned deployment (for the formula only).
Doesn't this change mean there is minimal benefit to having deployment times lower than 3 months? I've had fighters with deployment times in the region of 0.5 months in the past.
-
Can you make squadrons a different colour to sub-fleets?
Sub-fleets only appear below fleets or other sub-fleets while squadrons only appear below ships. It shouldn't be confusing in practice.
For v2.0, the accommodation formula above remains in place but it will use a minimum value of 3 for planned deployment (for the formula only).
Doesn't this change mean there is minimal benefit to having deployment times lower than 3 months? I've had fighters with deployment times in the region of 0.5 months in the past.
As explained in the rest of the post quoted above, the crew is reduced instead of the deployment time, with the same net effect on accommodation requirements. As this is also rounded down, small ships with minimal deployment times will save space.
http://aurora2.pentarch.org/index.php?topic=12523.msg158366#msg158366
-
For v2.0, the accommodation formula above remains in place but it will use a minimum value of 3 for planned deployment (for the formula only).
Doesn't this change mean there is minimal benefit to having deployment times lower than 3 months? I've had fighters with deployment times in the region of 0.5 months in the past.
As explained in the rest of the post quoted above, the crew is reduced instead of the deployment time, with the same net effect on accommodation requirements. As this is also rounded down, small ships with minimal deployment times will save space.
http://aurora2.pentarch.org/index.php?topic=12523.msg158366#msg158366
I don't understand, as far as I can see the accommodation requirement has a new floor of 3 months, meaning the same tonnage is used for accommodation even if deployment is reduced.
Could you explain how crew and accommodation are related?
-
I don't understand, as far as I can see the accommodation requirement has a new floor of 3 months, meaning the same tonnage is used for accommodation even if deployment is reduced.
Could you explain how crew and accommodation are related?
You'll want to carefully read the next part of his post:
For v2.0, the accommodation formula above remains in place but it will use a minimum value of 3 for planned deployment (for the formula only). In addition, if planned deployment is less than 3 months, the formula below will be applied to the final crew (once all components have been included).
Crew = Round Down ( Crew * ( (Planned Deployment ^ (1/3)) / (3 ^ (1/3)) ) );
This effectively reduces the crew to the point where 3 months deployment would be the same in accommodation terms as the full crew with the original planned deployment. In other words, the accommodation requirement is the same in both cases but now the crew is smaller. As this is rounded down, it will have a slight beneficial effect for ships with small crews and very short deployments. The minimum crew is 1.
Basically, instead of reducing the required accommodation directly, for deployment times below 3 months the actual crew requirement is reduced which reduces the required accommodations indirectly. The effect is roughly the same, but it is a slight buff to small craft due to rounding down and otherwise it is a minor flavor addition only.
-
Speaking of academies, is the bug that causes an officer's homeworld to just be the academy they graduated from gonna be fixed?
-
Steve.... now when you started working on Strike Crafts and managing them... when is the time to start go over the mechanics for ground fighters. As this mechanic simply does not work well. They don't seem to work well with ground forces in general and they are a pain to manage?
If you find some time to change this for the next release would probably be quite appreciated as I don't think many people are using them at present time.
-
Steve.... now when you started working on Strike Crafts and managing them... when is the time to start go over the mechanics for ground fighters. As this mechanic simply does not work well. They don't seem to work well with ground forces in general and they are a pain to manage?
If you find some time to change this for the next release would probably be quite appreciated as I don't think many people are using them at present time.
I know they don't work well. Its unlikely I will fix them for this release, but it is on my radar as a problem.
-
With the Limited Research Administration and slower research speed options allowing for longer tech eras and ship classes remaining relevant for longer I think it would be really nice if there was a way to mothball military ships so they could be used later without consuming as much maintenance supplies. I find this especially useful for scout ships now that geologic sensors are a military item, as often I make a few scouts in the beginning to explore sol, but then when I want to spend a few years developing colonies on the moon or mars before heading out I wind up having to scrap them to prevent wasting a bunch of MSP for years or decades. Having an "Overhaul into Reserve" and "Overhaul out of Reserve" button that slows or halts the maintenance clock on ships would be really neat. Having there being some cost associated with it, like an overhaul, would mean it would only be time and cost effective for long duration pauses, and you would still need some ships on standby using maintance capacity to respond quickly to threats. But the option to have a reserve fleet I think could be tactically interesting and very useful, especially in slower research rate games.
-
... I wind up having to scrap them to prevent wasting a bunch of MSP for years or decades.
And that's the way to go :).
I on other hand would love to see some kind of max life to a ship. So that you are forced to scrap it after let's say deployment x20 or AFR and IFR will increase over time...
The oldest US operational ship is 50 years old...
-
With the Limited Research Administration and slower research speed options allowing for longer tech eras and ship classes remaining relevant for longer I think it would be really nice if there was a way to mothball military ships so they could be used later without consuming as much maintenance supplies. I find this especially useful for scout ships now that geologic sensors are a military item, as often I make a few scouts in the beginning to explore sol, but then when I want to spend a few years developing colonies on the moon or mars before heading out I wind up having to scrap them to prevent wasting a bunch of MSP for years or decades. Having an "Overhaul into Reserve" and "Overhaul out of Reserve" button that slows or halts the maintenance clock on ships would be really neat. Having there being some cost associated with it, like an overhaul, would mean it would only be time and cost effective for long duration pauses, and you would still need some ships on standby using maintance capacity to respond quickly to threats. But the option to have a reserve fleet I think could be tactically interesting and very useful, especially in slower research rate games.
This gets suggested a lot, and every time it comes up the problem is that there's nothing to prevent players from building brand-new ships and immediately putting them into mothballs to save on maintenance costs. Aurora has not historically had a lot of mechanics to counteract this (PPV being an ineffective try, most players cheese it or use ground troops), although the new spoiler race might change that balance.
-
The question then is why don't military organisations do similar things in real life?!?
They actually do this with smaller weapon platforms such as aircraft, tanks and other vehicles, but naval ships it is a bit more rare to do this but it actually happen that they do just that. It is quite rare they build new ships and them mothball them... but I think that the UK intend to do that with their two new carriers and only have one if them operational at any one time for example.
I don't think that mothballing should mean no cost, just lower cost... maybe reduce the cost to 1/4, but the ship will loose experience and fleet training as well over time.
In my opinion that would balance the mechanic well... in my opinion you should still just have the ships you actually need and step up production if there is a major conflict. After a conflict you can mothball ships or even scrap them depending on how large a fleet you expand in said war. In general I think that scraping ships is worth it if you don't intent to use it for the next ten to fifteen years when you factor in upgrades etc you will eventually need to do anyway.
If you are able to mothball ships there is an option to extend the period where you don't scrap ships or maybe you just scrap fewer ships and mothball some of them.
If you just build new ships and then mothball them you can question why you build them in the first place?!?
If there is a Mothball feature there need to be at least some time before they can be operational, like a few months at least.
-
> If there is a Mothball feature there need to be at least some time before they can be operational, like a few months at least.
Yeah, that's why I think them needing an overhaul when entering and exiting would be good, it matches what happens in real reserve fleets and makes removing a ship from reserve time consuming, so you can't just thaw them out the moment they are needed.
-
I know they don't work well. Its unlikely I will fix them for this release, but it is on my radar as a problem.
Biggest issue IMO is the micro in UI with dragging GSF support. Wouldn’t that be fairly staight forward to solve now that you added squadrons?
-
Please register your account so you can post normally, Earthfall10, and we don't have to approve each of your post manually.
They actually do this with smaller weapon platforms such as aircraft, tanks and other vehicles, but naval ships it is a bit more rare to do this but it actually happen that they do just that. It is quite rare they build new ships and them mothball them... but I think that the UK intend to do that with their two new carriers and only have one if them operational at any one time for example.
What the Royal Navy plans to do is to actually one out, "being operational", while the other is being maintained and training and so on. This is actually very ambitious because the USN maintains that to keep a carrier operational, you need two others - one operating at an area, second in transit, third under maintenance. And while it's true that the USN brought back the Iowa class battleships in the 1980s, that really isn't something that navies routinely do. When a ship is taken out of operational use, it is extremely rare for it to come back to service.
The issue that Earthfall10 presented is also bit misleading - the geological survey ships you use to scan Sol should always be scrapped and replaced by either dual-purpose survey cruisers or a newer, modernized, fleet of various survey craft as it's likely that your engine tech is at least a generation better once you leave Sol than what it was when you did the initial survey. Especially if you do a conventional start.
Now, I'm su're we can make a compelling argument for mothball mechanic - I'm pretty sure it's been done in the past multiple times. I'm just not sure how to actually make it so that it's a meaningful choice instead of put all ships into it and then activate as needed.
-
The biggest single cost in a survey ship is the survey sensor(s), so scrapping an old ship and building a new one with the components is the way to go.
Maybe it would help if it showed the value of a scrapped ship more clearly, by listing the scrap value and the value of all the components that get left behind.
I don't know the formula for the value of a scrapped ship (the C# changes log doesn't have any entries and the wiki entry (which covers VB mechanics I assume are still accurate) is rather vague) but if a 600 BP survey ship gets scrapped for 100, but also has 150 BP of components left over then it seems much more worthwhile.
They actually do this with smaller weapon platforms such as aircraft, tanks and other vehicles
My understanding was that these systems were sent straight to units so they could start training with them.
I think that the UK intend to do that with their two new carriers and only have one if them operational at any one time for example.
If you just build new ships and then mothball them you can question why you build them in the first place?!?
Woo global Britain. :P
but the ship will loose experience and fleet training as well over time.
It should reset fleet training and crew grade to 0 because the crew and officers are now working in the private sector (except for the cleaners and 1 person to oil the engines).
It would also add a lot of time to get a ship from mothballed to fully trained.
-
The question then is why don't military organisations do similar things in real life?!?
In very simplified terms, military organizations do not usually build ships straight into mothballs because they need the ships they build to do something, or at least the people in charge think they do. Most national militaries are severely constrained by how much funding they can convince their national governments to give them, which must be justified in terms of "need now" and not "might need in case of major war" - the politicians usually do not appreciate the optics of paying millions of dollars for a shiny new destroyer just to immediately put it in a reserve dock somewhere to be stored up "in case of emergency".
In Aurora, there really are not a lot of demands on a navy besides fighting a wars and carrying out surveys. Currently, PPV is really the only mechanic in place to try and simulate some kind of low-level demand for continual fleet presence, but we do not have needs like anti-piracy patrols, showing the flag, right-of-passage, etc. and in fact even the need for crew training is rather limited since ships will accumulate 100% over time rather than losing skill due to turnover, etc. without dedicated training. Hopefully, the new spoiler race in 2.0 will help to address this but right now the need is not there.
At the same time Aurora also lacks any kind of economic mechanics related to peacetime vs war economy, which means that in times of peace any race is free to build as many ships as they like in anticipation of the next war. In real life, militaries certainly try to do this but they must contend with their governments which have many other things they would like to spend money on. Once a world war starts, suddenly all the governments are much more interested in building planes, tanks, and destroyers.
The reasons why real-world militaries don't build directly to mothballs are there, plentifully, they have just not been translated into Aurora. Without that translation, mothballing will always be an easy way to cheese the maintenance system while building a big navy. This is not a problem unique to Aurora, by the way; Victoria 3 will not have a distinction between active and reserve naval vessels (at least on release), and while many are upset about this I imagine it is for similar reasons to what I've described here and the developers do not want people using reserve mechanics to build up huge fleets in peacetime without some significant cost associated with it.
-
... I wind up having to scrap them to prevent wasting a bunch of MSP for years or decades.
And that's the way to go :).
I on other hand would love to see some kind of max life to a ship. So that you are forced to scrap it after let's say deployment x20 or AFR and IFR will increase over time...
The oldest US operational ship is 50 years old...
I think one way to replicate this is to add a multiplier to refit costs after a certain age - like modifications from 1-30 years is x1, 31-50 is x1.5, 51-75 is x2.0 etc. I don't think I would want to cramp people's playstyle if they wanted to play with 'ancient' ships so I would want to put a hard limit on it. Just make older ships harder to upgrade to the point where it would be cost-prohibitive to do it beyond a certain point vice just building a new modern warship.
-
I know they don't work well. Its unlikely I will fix them for this release, but it is on my radar as a problem.
Biggest issue IMO is the micro in UI with dragging GSF support. Wouldn’t that be fairly staight forward to solve now that you added squadrons?
Also, I totally understand the logic behind FFD and ground support capacity, but given that targeting is essentially random among formations, does having GS dedicated to each unit matter? Could it be abstracted in the way the other GSF fighter missions are. Perhaps do so and keep FFD for non-GSF bombardment ships?
-
Also, I totally understand the logic behind FFD and ground support capacity, but given that targeting is essentially random among formations, does having GS dedicated to each unit matter? Could it be abstracted in the way the other GSF fighter missions are. Perhaps do so and keep FFD for non-GSF bombardment ships?
I believe it does actually matter for breakthrough chances, since a formation providing support to another formation will have the same target as the formation it is supporting. If you have, say, an armored formation with 4x FFD supported by a medium bombardment formation and 24 ground support fighters, any enemy formation targeted by the armor will be attacked three times instead of once, potentially causing sufficient morale loss to allow a breakthrough.
I'm not 100% certain on this since the order of events in ground combat is a bit hazy, but Steve or someone else could confirm or correct this.
That being said, it would significantly reduce micromanagement to just give a fighter wing orders to "Support Ground Formations" in the naval organization window, and have them randomly choose a FFD-equipped formation to support. This preserves the mechanic of assigned fighter support but eliminates some of the micromanagement.
-
Also, I totally understand the logic behind FFD and ground support capacity, but given that targeting is essentially random among formations, does having GS dedicated to each unit matter? Could it be abstracted in the way the other GSF fighter missions are. Perhaps do so and keep FFD for non-GSF bombardment ships?
I believe it does actually matter for breakthrough chances, since a formation providing support to another formation will have the same target as the formation it is supporting. If you have, say, an armored formation with 4x FFD supported by a medium bombardment formation and 24 ground support fighters, any enemy formation targeted by the armor will be attacked three times instead of once, potentially causing sufficient morale loss to allow a breakthrough.
I'm not 100% certain on this since the order of events in ground combat is a bit hazy, but Steve or someone else could confirm or correct this.
That being said, it would significantly reduce micromanagement to just give a fighter wing orders to "Support Ground Formations" in the naval organization window, and have them randomly choose a FFD-equipped formation to support. This preserves the mechanic of assigned fighter support but eliminates some of the micromanagement.
True, I had not though of that. But yes, that solution sounds like a good compromise.
-
With the Limited Research Administration and slower research speed options allowing for longer tech eras and ship classes remaining relevant for longer I think it would be really nice if there was a way to mothball military ships so they could be used later without consuming as much maintenance supplies. I find this especially useful for scout ships now that geologic sensors are a military item, as often I make a few scouts in the beginning to explore sol, but then when I want to spend a few years developing colonies on the moon or mars before heading out I wind up having to scrap them to prevent wasting a bunch of MSP for years or decades. Having an "Overhaul into Reserve" and "Overhaul out of Reserve" button that slows or halts the maintenance clock on ships would be really neat. Having there being some cost associated with it, like an overhaul, would mean it would only be time and cost effective for long duration pauses, and you would still need some ships on standby using maintance capacity to respond quickly to threats. But the option to have a reserve fleet I think could be tactically interesting and very useful, especially in slower research rate games.
This gets suggested a lot, and every time it comes up the problem is that there's nothing to prevent players from building brand-new ships and immediately putting them into mothballs to save on maintenance costs. Aurora has not historically had a lot of mechanics to counteract this (PPV being an ineffective try, most players cheese it or use ground troops), although the new spoiler race might change that balance.
You could make it so mothballed ships need to go through a lengthy 're-activation' process before they can be used.
I'm surprised about the hand-wringing over balance for this issue; mothballing fleets is a feature you are right to expect in a game such as this and compared to the other ways you can cheese the game I don't think its terribly offensive.
-
With the Limited Research Administration and slower research speed options allowing for longer tech eras and ship classes remaining relevant for longer I think it would be really nice if there was a way to mothball military ships so they could be used later without consuming as much maintenance supplies. I find this especially useful for scout ships now that geologic sensors are a military item, as often I make a few scouts in the beginning to explore sol, but then when I want to spend a few years developing colonies on the moon or mars before heading out I wind up having to scrap them to prevent wasting a bunch of MSP for years or decades. Having an "Overhaul into Reserve" and "Overhaul out of Reserve" button that slows or halts the maintenance clock on ships would be really neat. Having there being some cost associated with it, like an overhaul, would mean it would only be time and cost effective for long duration pauses, and you would still need some ships on standby using maintance capacity to respond quickly to threats. But the option to have a reserve fleet I think could be tactically interesting and very useful, especially in slower research rate games.
This gets suggested a lot, and every time it comes up the problem is that there's nothing to prevent players from building brand-new ships and immediately putting them into mothballs to save on maintenance costs. Aurora has not historically had a lot of mechanics to counteract this (PPV being an ineffective try, most players cheese it or use ground troops), although the new spoiler race might change that balance.
You could make it so mothballed ships need to go through a lengthy 're-activation' process before they can be used.
I'm surprised about the hand-wringing over balance for this issue; mothballing fleets is a feature you are right to expect in a game such as this and compared to the other ways you can cheese the game I don't think its terribly offensive.
Seeing as a lot of mothball ships in the real world has parts removed during the mothballing process, a lengthy reactivation time would make sense. Depending on how in depth a system a mothball fleet may be you could also set a level of maintenance to keep the ships in a specific mothball fleet thus changing the reactivation time
-
With the Limited Research Administration and slower research speed options allowing for longer tech eras and ship classes remaining relevant for longer I think it would be really nice if there was a way to mothball military ships so they could be used later without consuming as much maintenance supplies. I find this especially useful for scout ships now that geologic sensors are a military item, as often I make a few scouts in the beginning to explore sol, but then when I want to spend a few years developing colonies on the moon or mars before heading out I wind up having to scrap them to prevent wasting a bunch of MSP for years or decades. Having an "Overhaul into Reserve" and "Overhaul out of Reserve" button that slows or halts the maintenance clock on ships would be really neat. Having there being some cost associated with it, like an overhaul, would mean it would only be time and cost effective for long duration pauses, and you would still need some ships on standby using maintance capacity to respond quickly to threats. But the option to have a reserve fleet I think could be tactically interesting and very useful, especially in slower research rate games.
This gets suggested a lot, and every time it comes up the problem is that there's nothing to prevent players from building brand-new ships and immediately putting them into mothballs to save on maintenance costs. Aurora has not historically had a lot of mechanics to counteract this (PPV being an ineffective try, most players cheese it or use ground troops), although the new spoiler race might change that balance.
You could make it so mothballed ships need to go through a lengthy 're-activation' process before they can be used.
I'm surprised about the hand-wringing over balance for this issue; mothballing fleets is a feature you are right to expect in a game such as this and compared to the other ways you can cheese the game I don't think its terribly offensive.
Seeing as a lot of mothball ships in the real world has parts removed during the mothballing process, a lengthy reactivation time would make sense. Depending on how in depth a system a mothball fleet may be you could also set a level of maintenance to keep the ships in a specific mothball fleet thus changing the reactivation time
A workaround could be to:
- Mothball: Scrap the entire ship for parts (since modules lying around in a warehouse don't wear out)
- Reactivate: Feed the warehoused modules back into the local shipyard to build a "new" ship
-
This is not a problem unique to Aurora, by the way; Victoria 3 will not have a distinction between active and reserve naval vessels (at least on release), and while many are upset about this I imagine it is for similar reasons to what I've described here and the developers do not want people using reserve mechanics to build up huge fleets in peacetime without some significant cost associated with it.
No I believe that is because the Victoria 3 developers are scared of the sea and are on a determined mission to dumb down or abstract away naval warfare from all of their games.
The biggest real world arguments against a mothball/reserve mechanic are that it takes too long to activate the reserves and when you do all you get is an obsolete ship that lacks modern weapons and equipment. When the Royal Navy tried to get some ships from the "Standby Squadron" ready for the Falklands the conflict was over before the ships were out of dock, the USN gave up on it's warship reserve fleets for similar reasons.
If it took, say, 6 months to get a warships out of refit, it started with -10% crew grade and 0 fleet training and you weren't allowed to upgrade or refit the ship while it was in reserve then you'd get something close to the actual experience of a mothballed ship. Though at that point what player would bother doing it, so not a lot of point adding it into the game.
-
The question then is why don't military organisations do similar things in real life?!?
In very simplified terms, military organizations do not usually build ships straight into mothballs because they need the ships they build to do something, or at least the people in charge think they do. Most national militaries are severely constrained by how much funding they can convince their national governments to give them, which must be justified in terms of "need now" and not "might need in case of major war" - the politicians usually do not appreciate the optics of paying millions of dollars for a shiny new destroyer just to immediately put it in a reserve dock somewhere to be stored up "in case of emergency".
In Aurora, there really are not a lot of demands on a navy besides fighting a wars and carrying out surveys. Currently, PPV is really the only mechanic in place to try and simulate some kind of low-level demand for continual fleet presence, but we do not have needs like anti-piracy patrols, showing the flag, right-of-passage, etc. and in fact even the need for crew training is rather limited since ships will accumulate 100% over time rather than losing skill due to turnover, etc. without dedicated training. Hopefully, the new spoiler race in 2.0 will help to address this but right now the need is not there.
At the same time Aurora also lacks any kind of economic mechanics related to peacetime vs war economy, which means that in times of peace any race is free to build as many ships as they like in anticipation of the next war. In real life, militaries certainly try to do this but they must contend with their governments which have many other things they would like to spend money on. Once a world war starts, suddenly all the governments are much more interested in building planes, tanks, and destroyers.
The reasons why real-world militaries don't build directly to mothballs are there, plentifully, they have just not been translated into Aurora. Without that translation, mothballing will always be an easy way to cheese the maintenance system while building a big navy. This is not a problem unique to Aurora, by the way; Victoria 3 will not have a distinction between active and reserve naval vessels (at least on release), and while many are upset about this I imagine it is for similar reasons to what I've described here and the developers do not want people using reserve mechanics to build up huge fleets in peacetime without some significant cost associated with it.
This is something you have to role-play... in my games the civilian government always holds military spending down to a minimum... ;)
As with so many things in Aurora most of the soft stuff needs to be role-played as the game is a pretty big sandbox role-playing game.
-
Well, Pdox shat the bed with the reserve mechanic already in HoI3 so I'm not surprised that they don't want to re-open that can of worms again. IIRC, it's missing from HoI4 too.
But yeah, it basically looks like some players want to be able to have more ships than they can maintain and/or reduce MSP consumption of their fleet in general. Since Steve has repeatedly said that the mineral acquisition part and the fleet logistics management part are important & elementary parts of the game, I don't see him adding a mothball mechanic that would simply let players ignore maintenance - and you can already turn it off if you don't want it all, of course. And I also agree with El Pip that if the cons of mothballing are severe enough so that it isn't a simple MSP circumvention tool, then it probably isn't a viable strategy in Aurora warfare where years of shipbuilding can be lost in few minutes. The sort of desperate delay action from JP to JP while waiting for the Reserve Fleet to get activated and rushed to the front, that we're so familiar from Weber's books, just isn't really viable in Aurora since almost nobody gets empires large enough for that to be possible and there's no NPR that has enough ships and brains to pursue a chase campaign like that either.
Which means that Steve would need to code a complicated mechanic that's only really useful for few RP situations and for PvP campaigns, both of which are pretty rare in my understanding.
I'm surprised about the hand-wringing over balance for this issue; mothballing fleets is a feature you are right to expect in a game such as this and compared to the other ways you can cheese the game I don't think its terribly offensive.
I don't agree that it's a feature that people expect in a game such as this - I can't off the top of my head recall any 4X or grand strategy or space war game where it's possible or at least an integral part of the game. And sure, we are not forced to use such a mechanic but alternatively, you could simulate it by using SM mode to create a dozen massive maintenance stations at Triton and parking your 'mothballed' ships there, and every now and then use SM to add more MSP to them.
-
And that's the way to go :).
I on other hand would love to see some kind of max life to a ship. So that you are forced to scrap it after let's say deployment x20 or AFR and IFR will increase over time...
The oldest US operational ship is 50 years old...
The problem that in Aurora we have some nearly eternal military objects - Precursor ships and bases, as one of the most RP-weighty things, not to mention standard TN components, that from the RP perspective are only comprehended as pre-spoiler's heritage - so for the sake of consistency it's better to have even less obligatory wearout that Aurora have now. I'd like to see more weight on the civilian economy needs (TNM consumption for the industry) instead of just military consumption as a drive for obligatory expansion, just because space is enormously old thing and it's much more natural for me to think, that it's civilization is an unstable, fragile and ephemeral thing, while a spaceship can live thousands of years at least.
-
And that's the way to go :).
I on other hand would love to see some kind of max life to a ship. So that you are forced to scrap it after let's say deployment x20 or AFR and IFR will increase over time...
The oldest US operational ship is 50 years old...
The problem that in Aurora we have some nearly eternal military objects - Precursor ships and bases, as one of the most RP-weighty things, not to mention standard TN components, that from the RP perspective are only comprehended as pre-spoiler's heritage - so for the sake of consistency it's better to have even less obligatory wearout that Aurora have now. I'd like to see more weight on the civilian economy needs (TNM consumption for the industry) instead of just military consumption as a drive for obligatory expansion, just because space is enormously old thing and it's much more natural for me to think, that it's civilization is an unstable, fragile and ephemeral thing, while a spaceship can live thousands of years at least.
I would love more civilian drag on TN resources as well... in fact the civilian sector should be the main reason you need TN resources and not your navy.
I have also several times said that I like for ships to age a bit over time so we can't just keep upgrading them in infinity. Currently you just have to role-play this aspect. But at some point it just should not be economically viable to integrate new technology or the core hull simply have been worn down too much to support new upgrades, especially large parts like engines and jump-drives.
-
And that's the way to go :).
I on other hand would love to see some kind of max life to a ship. So that you are forced to scrap it after let's say deployment x20 or AFR and IFR will increase over time...
The oldest US operational ship is 50 years old...
The problem that in Aurora we have some nearly eternal military objects - Precursor ships and bases, as one of the most RP-weighty things, not to mention standard TN components, that from the RP perspective are only comprehended as pre-spoiler's heritage - so for the sake of consistency it's better to have even less obligatory wearout that Aurora have now. I'd like to see more weight on the civilian economy needs (TNM consumption for the industry) instead of just military consumption as a drive for obligatory expansion, just because space is enormously old thing and it's much more natural for me to think, that it's civilization is an unstable, fragile and ephemeral thing, while a spaceship can live thousands of years at least.
I would love more civilian drag on TN resources as well... in fact the civilian sector should be the main reason you need TN resources and not your navy.
I have also several times said that I like for ships to age a bit over time so we can't just keep upgrading them in infinity. Currently you just have to role-play this aspect. But at some point it just should not be economically viable to integrate new technology or the core hull simply have been worn down too much to support new upgrades, especially large parts like engines and jump-drives.
Yeah I hear you. Once I get the 'formula' for a particular class right the only 'designing' I have to do is linearly upgrading the components with higher tech variants of the same size. Only time there is a shakeup is when shields become viable and start taking up tonnage.
On the other hand, I kinda like the idea of spaceship hulls being so hardy that they can be kept in operation for generations as long as they keep getting upgraded. Gives me a cool 40k vibe.
-
>> I have also several times said that I like for ships to age a bit over time so we can't just keep upgrading them in infinity
There are IRL instances of military hardware being used for decades. Soviet T-55s are still in service today with a surprisingly large number of countries, Ethiopia operated captured Italian tankettes from the 1930s until the 1980s, and the USN still has USS Blue Ridge, which was commissioned in 1970 in active service (real active service, not just nominally listed like the Constitution). Coloumbia operated P-51s until about 1980, and the USAF still has B-52s in service (although a lot of the original airframes are gone now, the H variants still in service were manufactured in the late 50s'/early 60s')
-
But yeah, it basically looks like some players want to be able to have more ships than they can maintain and/or reduce MSP consumption of their fleet in general. Since Steve has repeatedly said that the mineral acquisition part and the fleet logistics management part are important & elementary parts of the game, I don't see him adding a mothball mechanic that would simply let players ignore maintenance - and you can already turn it off if you don't want it all, of course. And I also agree with El Pip that if the cons of mothballing are severe enough so that it isn't a simple MSP circumvention tool, then it probably isn't a viable strategy in Aurora warfare where years of shipbuilding can be lost in few minutes. The sort of desperate delay action from JP to JP while waiting for the Reserve Fleet to get activated and rushed to the front, that we're so familiar from Weber's books, just isn't really viable in Aurora since almost nobody gets empires large enough for that to be possible and there's no NPR that has enough ships and brains to pursue a chase campaign like that either.
Which means that Steve would need to code a complicated mechanic that's only really useful for few RP situations and for PvP campaigns, both of which are pretty rare in my understanding.
I'm surprised about the hand-wringing over balance for this issue; mothballing fleets is a feature you are right to expect in a game such as this and compared to the other ways you can cheese the game I don't think its terribly offensive.
I don't agree that it's a feature that people expect in a game such as this - I can't off the top of my head recall any 4X or grand strategy or space war game where it's possible or at least an integral part of the game. And sure, we are not forced to use such a mechanic but alternatively, you could simulate it by using SM mode to create a dozen massive maintenance stations at Triton and parking your 'mothballed' ships there, and every now and then use SM to add more MSP to them.
I agree a 100% with all this post. Also, Steve has repeatedly noted that resource acquisition is important to him, and mothballing is a way to circumvent a lot of that.
Also.... this discussion really pops up from time to time ;D
-
I agree a 100% with all this post. Also, Steve has repeatedly noted that resource acquisition is important to him, and mothballing is a way to circumvent a lot of that.
Also.... this discussion really pops up from time to time ;D
In general I agree with the reason that you don't want a mechanic that you simply circumvent maintenance costs with.
I do, however, think there could be more stages of readiness of ships with different pros and cons from a game-play perspective. I would not like to see any mechanic that completely remove the cost of maintaining ships, but there are more things you could do which could add some more choices.
There should be a choice between if you want to scrap a ship or put them into long term storage after a long conflict as one example. If you just build new ships and immediately put them into long term storage you might wonder why you build them in the first place. If the cost of bringing them back from long term storage is big enough you must anticipate the ship being in long term storage for a very long time or it will not be worth it. So building a new ship and putting them into storage would not be very wise.
One "fix" for storing new ships could be that a ship in storage have the maintenance clock run up rather fast at first and then slows down to almost stop after a while. So when you bring the ship back you have to spend some considerable time overhauling them. You don't really want a ship with a normal maintenance cycle of around 2.5 years in the field if the ship act as if it has been 5 years in service since the last overhaul.
-
I'm fairly sure it's already been mentioned, but crafting components and/or scrapping ships almost perfectly satisfies the goals put out by the people who want mothballing:
Items in storage have no costs (and never decay).
Building a ship from pre-made components is significantly faster than building from scratch.
About the only problem with it is that it takes up yard slots... but I'm not sure that mothballing shouldn't require that anyway.
-
About the only problem with it is that it takes up yard slots... but I'm not sure that mothballing shouldn't require that anyway.
This is probably the closest thing to actually working mothball mechanics, actually. We already have repair yards, so it would be possible in theory to add a use case where one slip of appropriate size = one mothballed ship in exchange for, say, 25% maintenance cost, requiring an overhaul to reactivate, resetting crew grade, and so on.
By tying this to slipways there is also some population requirement to keep the ships at minimal maintenance, so if the repair yard is not operated at 100% efficiency mothballed ships can suffer maintenance failure the same as ships do currently with insufficient maintenance facilities. Population requirement can also limit overuse of the mechanic since population is an important bottleneck as the game progresses (to the point when mothballing ships is a real possibility).
-
Generally, I am against the idea of mothballing. If mothballing required the use of repair yards / slipways and an investment of resources through either overhauls or some other penalty to ship readiness like crew grade and training, I'd be okay with it.
-
About the only problem with it is that it takes up yard slots... but I'm not sure that mothballing shouldn't require that anyway.
This is probably the closest thing to actually working mothball mechanics, actually. We already have repair yards, so it would be possible in theory to add a use case where one slip of appropriate size = one mothballed ship in exchange for, say, 25% maintenance cost, requiring an overhaul to reactivate, resetting crew grade, and so on.
By tying this to slipways there is also some population requirement to keep the ships at minimal maintenance, so if the repair yard is not operated at 100% efficiency mothballed ships can suffer maintenance failure the same as ships do currently with insufficient maintenance facilities. Population requirement can also limit overuse of the mechanic since population is an important bottleneck as the game progresses (to the point when mothballing ships is a real possibility).
It would actually be a great use case for repair yards during peacetime as otherwise they would be sat there unused. Mothballs take up the space during peace, are refurbished during war to make available extra assets and to clear space for the inevitable return of damaged warships. All the while still being beneficial due to the reduction in maintenance/efficiency of repair yards.
-
I think it would be really nice if there was a way to mothball military ships so they could be used later without consuming as much maintenance supplies.
Absolutely this. At the very top of my feature wishlist is a mothballing system. Even a basic one as described here would be great!
-
Why should it be possible to mothball ships?
Historically it only happens in rare and limited circumstances. During the age of sail it was possible but it went wrong frequently and mothballed ships often sufferred from rot and had to be scrapped.
The US Mothballed ships after WW2 due to massive production resulting in several almost unused ships , most of these then went from Mothball to scrap after wasting money for decades on upkeep. Some were taken out of mothballs for Korea , it was very marginal if the cost of mothballing them was less than the cost of keeping them in service would have been. Some carriers were taken out and rebuilt for service however these improved Essex were very marginal ships and again if the same money had been spent on new hulls it may well have been more cost effective,
Finally the Iowa's were taken out of mothball in the 80's to produce ships of marginal capability with very poor electronics and almost no defense against air attacks you got a platform for Cruise missiles which would have been nearly as effective stuck on the deck of a container ship and some heavy guns you could use to bombard third rate opponents with no air or sea power. And you had paid 40 years of maintenance to get those 'cheap' ships.
The British before Jackie Fisher kept old ironclads in reserve which were utterly worthless against anything semi-modern and this was a form of mothball also a vast waste of money on upkeep and even worse waste of manpower and money if they had ever been ativated. Technically HMS Warrior was a reserve ship in 1900 and her combat value was about that of a gnat, an armed merchant cruiser would have been more capable.
Can anyone name a semi-modern example of mothballing which worked?
-
Can anyone name a semi-modern example of mothballing which worked?
I think you mentioned the sole example, Korea. Off the top of my head HMS Unicorn was decommissioned and put into reserve post-WW2, but reactivated in 1949 for service it the Far East and ended up serving during Korea and doing some shore bombardment inbetween carrier operations. I believe the RCN and RAN did the same with some cruisers and they also worked well enough. Given the largest cost for naval vessels is crew, saving 4-5 years of crew costs was undoubtedly a saving compared to the relatively low cost of putting into reserve and the re-comissioning.
That said I agree that was a pretty niche scenario and generally it does not work. It requires a very long war where lots of 'new' vessels arrive too late, a big financial problem that demands cuts in spending and then a relatively short gap to the next war so nothing is obsolete.
Aurora can do the first and the last, but really lacks the economic model to do the vital middle one. You can of course RP a difference between peace and wartime 'allowable' spending, but at that point you can RP mothballing as well so the problem solves itself.
-
I'm not a big fan of mothballing because, honestly, I feel it adds little and would increase micromanagement. I don't mean to imply that it wouldn't be useful, simply that in a case where no one gets it is essentially equal to everyone having it.
Also these are spaceships, and even in the case of RPed alt-historical settings probably all kinds of advanced in a very hostile environment (and if you think there's nothing in space to wear things down, look up "vacuum cementing".) It seems entirely reasonable to me that you can't just leave them lying around and then come back to fix them up without totally rebuilding them.
-
Rather than wasting time on mothballing, which I feel would be a thing that would barely get used and would work contra to the underlying expansion paradigm that underpins this game, I think tying a ship's age to and increasing cost to refit would be more in line with the game mechanisms. It certainly creates more choices - when do I commit to refitting my venerable fleet of cruisers which have served me well vice building a new line of modern cruisers?
-
Can anyone name a semi-modern example of mothballing which worked?
Just because historical examples have debatable or negative total economic outcome doesn't sound like an argument against adding the feature at all, it sounds like an argument about how the mechanics should be balanced.
While I like the idea of using repair slipways to mothball ships, I expect that if you need to use the shipyard screen to mothball ships then that would cause micromanagement issues. Adding a command for a fleet would probably be better.
-
The main reason for people to want to mothball is to have more firepower ready if an attack occurs. This however is not how a military runs. You have to have ships and crews combat-ready in case an emergency appears - but you have to pay the price for that: Maintenance. Mothballing is however interesting to an upcoming long war campaign, i.e. when two great powers begin to clash, you want to widen your military as much and quickly as you can. Being able to make a number of ships battle-ready within a period of lets say 6 to 9 months could be interesting in such a case.
To make this possible my idea for mothballing would be:
- make it available for 2nd generation tech. I.e. only ships that don't contain the latest generation of jump drives & engines can be mothballed
- a mothballed ship is reduced to 25% of its maintenance points when mothballed and needs to run through a maintenance facility to be made combat-ready (dust it off so to speak)
-
Just because historical examples have debatable or negative total economic outcome doesn't sound like an argument against adding the feature at all, it sounds like an argument about how the mechanics should be balanced.
I disagree with that idea.
Spending development time on adding a feature that very few players will use because it's balanced after historical models such that it's almost never useful/meaningful, would be a big waste of dev time. Much better developing features that would be enjoyable and used by a majority of players instead of a select few.
-
I would respectfully submit that we have strayed very far off topic in this discussion of mothballing... This thread is for discussion of changes implemented in 1.14.0; there is a separate thread for discussion of suggested changes.
-
I may be getting a little confused here on the discussion but from what ive understood, people are requesting mothball to decrease the maintenance cost and etc and still have some form of coherent firepower avaliable. Well, we have those, they are called carriers. You just make a big ass carrier, could be a commercial one, and put your ships in it. They wont get their maintenance clock running nor will use the maintenance and everyone is better for it. You could also just put those ships in a space station around a planet and it will get the same result.
So no need to add a whole pain of mechanics to achieve something that can be done without it. And you can RP that around. The American Navy had scores of ships sitting on dockyards and ports on reserve and etc.
-
nakorkren is correct, extensive discussion of suggestions belongs in the suggestions forum.
You just make a big ass carrier, could be a commercial one, and put your ships in it. They wont get their maintenance clock running nor will use the maintenance and everyone is better for it. You could also just put those ships in a space station around a planet and it will get the same result.
To rebut your point, to stop the maintenance clock you need military hangers, which means the carriers need to be built in a military shipyard. The carriers themselves cost MSP to keep the carrier maintenance clock at 0, if you keep them out of port then they will suffer failures which cost MSP to fix.
Because MSP cost is based on the ship cost, I think you can create carriers which cost less to upkeep than the
-
... I think you can create carriers which cost less to upkeep than the
They got him, the lizardmen got him.
-
nakorkren is correct, extensive discussion of suggestions belongs in the suggestions forum.
You just make a big ass carrier, could be a commercial one, and put your ships in it. They wont get their maintenance clock running nor will use the maintenance and everyone is better for it. You could also just put those ships in a space station around a planet and it will get the same result.
To rebut your point, to stop the maintenance clock you need military hangers, which means the carriers need to be built in a military shipyard. The carriers themselves cost MSP to keep the carrier maintenance clock at 0, if you keep them out of port then they will suffer failures which cost MSP to fix.
Because MSP cost is based on the ship cost, I think you can create carriers which cost less to upkeep than the
... Which leads me back to Space Stations on planets with enough population.
-
I strongly oppose increasing maintenance costs over time. It simply doesn't make any sense from any standpoint and wouldn't add anything to the game, just reduce choices.
-
... I think you can create carriers which cost less to upkeep than the
They got him, the lizardmen got him.
RIP Migi, I know how it is to be hunted for your maintenance hangar secrets. Your arcane knowledge was not meant for the wider world.
-
... I think you can create carriers which cost less to upkeep than the
They got him, the lizardmen got him.
How very Droll. Pun intended
I'm pretty sure the remainder of the sentence was just "ship it contains."
I might try to make a simple proof of concept later.
... Which leads me back to Space Stations on planets with enough population.
A Space Station that you can build on the ground needs the no armour checkbox enabled. They can only have commercial components. Enabling no armour for the design will remove any military components already in the design, and prevent you from adding new ones.
Hanger Decks (and boat bays) are military components. They freeze the deployment clock and the maintenance clock.
Commercial hanger decks are commercial components. They freeze the deployment clock but not the maintenance clock.
Freezing the maintenance clock means you won't pay any MSP for upkeep and it won't count against the maintenance facilities capacity.
-
Will be interesting to see if and how the orbits and environmental considerations will have an effect on Bioengineering/Genome Sequencing if it reappears
Yes, I have been thinking about that. In the past, creating a new species wasn't that important because you could terraform your way out of most situations, with the exceptions of high gravity and where you maxed out on greenhouse or anti-greenhouse. Now there is a scenario where it can be impossible to create an ideal world due to the temperate range exceeding that of your primary species. Creating a species with a wider temperature range looks very attractive in that situation. I suspect I will have added that functionality before v2.0 is released.
Since 2.0's release date seems to be getting narrowed down, is gene modding still on the table for it or might it be skipped for the first release?
Edit:
I've changed this for v1.14. NPRs now suffer weapon failure and consume MSP to fix it.
This isn't listed in the changelog, but it's still part of the update, right?
-
I'd like it if you could set the minimum age, or rather, service time for officers to spawn. An O4 is typically in their mid 30s, not their early 20s.
-
Overhauls and Movement Orders
For v1.14, you can set movement orders that follow overhauls in the order list.
When a fleet is in overhaul, any existing movement orders will be ignored. Once the overhaul is complete, the fleet will begin following the orders. If an overhaul is abandoned, the fleet will begin following the orders but with the penalties for an abandoned overhaul.
When a fleet completes an 'Overhaul' movement order and moves into an overhaul state, any additional orders will remain in the queue, awaiting completion of the overhaul.
If the cycle orders flag is set, the completed 'Overhaul' movement order will be adding to the end of the movement order list. The Repeat option can also be used for order lists that include an 'Overhaul' movement order.
I have a question about this change. Will there be problems if the fleet contains one or more commercial ships? Would it for example be possible to give a tug cycling orders that tell it to 1: move to and start tugging a military base, 2: drag that base to a maintenance place and begin overhaul, 3: after the overhaul is done, bring the base back to its previous guarding location? Or would the overhaul order break, because the fleet contains a non-military ship?
-
Overhauls and Movement Orders
For v1.14, you can set movement orders that follow overhauls in the order list.
When a fleet is in overhaul, any existing movement orders will be ignored. Once the overhaul is complete, the fleet will begin following the orders. If an overhaul is abandoned, the fleet will begin following the orders but with the penalties for an abandoned overhaul.
When a fleet completes an 'Overhaul' movement order and moves into an overhaul state, any additional orders will remain in the queue, awaiting completion of the overhaul.
If the cycle orders flag is set, the completed 'Overhaul' movement order will be adding to the end of the movement order list. The Repeat option can also be used for order lists that include an 'Overhaul' movement order.
I have a question about this change. Will there be problems if the fleet contains one or more commercial ships? Would it for example be possible to give a tug cycling orders that tell it to 1: move to and start tugging a military base, 2: drag that base to a maintenance place and begin overhaul, 3: after the overhaul is done, bring the base back to its previous guarding location? Or would the overhaul order break, because the fleet contains a non-military ship?
I think that would work. The tug would either not overhaul or complete its overhaul immediately, but the fleet wouldn't move until every ship had completed its overhaul.
-
OMG! The changes list for 1.14/2.0 is damned impressive and has me beyond hyped! Can't wait!
-
Changes to 1.14 (2.0?) are looking great. However, the old officer promotion system is personally the one I would prefer to use, instead of the new proposed one.
I enjoy the mechanic of promotion based on promotion score. The political intrigue factor counts into it, all the leader's bonuses count into it, and most importantly my cherished roleplay medals count into it. I enjoy having my most decorated officers progress through the promotion tree. Also, with how the new system apparently only uses one main bonus when looking for officers, it would lead to officers with rarer/secondary skills not being "appreciated". I would want my admirals to be well-rounded, decorated *and* politically competent.
Also, often, especially earlygame, my empire doesn't have nearly enough posts/ships to fill out my officer corps. This, combined with the great increase in the amount of naval commanders we will be getting in the future, will lead to a huge surplus of officers sitting in the lowest rank. The old system automatically allowed people to go up the ranks, and I would have a list of experienced admirals to pick from for my new grand command, instead of having to pick a random captain and promote him all the way up. You can see how this would break the immersion.
Obviously the new mechanics have their benefits, and will be included in the new update. But I wonder if it could be possible to implement the old system alongside it, as an optional game setting? Maybe with the game still using the "search for suitable guy from lower ranks" to find an officer if none are available in the required rank.
-
Personally, I think it is still not a perfect system, but it is overall much better and perfection is really only possible by manual management as every player wants something slightly different.
The big benefit for many players will be the ability to use automatic promotions to manage hundreds or thousands of officers, without being restricted by the arbitrary ratio of ranks. This is IMO a bigger deal for ground forces, but even for naval officers it is tricky to find the right balance of all the different ship types and command modules to maintain full employment of officers. Usually I end up finding difficulty when I try to use the command modules, as I have not enough officers of one rank (say, CDR) to staff all of my escort commands and executive officer positions, and too many excess officers of CAPT or LCDR ranks. Replacing rank ratios with on-demand promotions makes it much easier to build the fleet you want without arbitrary limits on your ability to manage officers.
It's worth noting that you still have promotion score factoring into promotion decisions, albeit mainly as a tiebreaker, and political bonus still plays a big role as it is added to the relevant skill score. If you need a new admiral to control a survey department, for instance, the CDRE with 30 survey score will lose out on promotion in favor of the CDRE with only 20 survey score but also 15 political score. I think it is different than before in a way which is better sometimes and not as good other times, but overall the same flavor is kept while the underlying mechanics are improved. There will still be a natural promotion pace of one rank at a time, so a reasonable career progression occur and you won't see LCDRs jump to VADM just because they are the only officer with a certain skill.
Personally I also see this system will lead to better "appreciation" for rare/secondary skills. Right now for example it can be hard to get a full staff of admirals with economic skills in terraforming, mining, logistics, etc. because these skills are not valued as highly for promotion as the military/combat skills. The new system will ensure that you see officers promoting upwards with these skills if there are jobs for them, so you can have a robust logistical and industrial arm of the admiralty instead of one guy with 15 Mining at a desk in the basement to manage your entire commercial fleet. With the ability to also choose what skill to emphasize for each admin command I think it will work very well in this regard.
-
I don't expect the new system will be perfect, but I hope it will be a substantial improvement over the current system.
I'm slightly disappointed that a political bonus can't cause someone with no relevant skills to get promoted, but anyway. (I think this would be highly realistic, but I'm probably underestimating how frustrating it would be).
Seeing as the old code is written, maybe Steve would add a game setting so players can still use the old system?
-
I actually think it's a better system since the demand for officer of certain level will be met, which empowers the usage of command modules to a higher level.
That said, in the past I tried to compensate by creating more MA and that slowed down my game during the officer update cycle, let's see what happens.
-
The big benefit for many players will be the ability to use automatic promotions to manage hundreds or thousands of officers, without being restricted by the arbitrary ratio of ranks. This is IMO a bigger deal for ground forces, but even for naval officers it is tricky to find the right balance of all the different ship types and command modules to maintain full employment of officers. Usually I end up finding difficulty when I try to use the command modules, as I have not enough officers of one rank (say, CDR) to staff all of my escort commands and executive officer positions, and too many excess officers of CAPT or LCDR ranks. Replacing rank ratios with on-demand promotions makes it much easier to build the fleet you want without arbitrary limits on your ability to manage officers.
Good point. But maybe the ideal solution would then be to have, alongside this new system , an option to use the old system, but with the addition of on-demand promotions. That way officer corps would by default grow in the ratio manner, but would auto-promote to shift into the different ratios of required jobs that the player has for them.
-
I think all these changes are plenty for a new release. Just putting it out there. Would welcome a 1. 14. 0 release.
-
Good point. But maybe the ideal solution would then be to have, alongside this new system , an option to use the old system, but with the addition of on-demand promotions. That way officer corps would by default grow in the ratio manner, but would auto-promote to shift into the different ratios of required jobs that the player has for them.
I think the new system is a far better system when you consider how the ratio method works, I've had a game where I had too little upper level posts (CDRE and above) and too many Captain and below posts.
I could promote officers to fill those Captain ranks posts but this would cause more officers being promoted to flag rank making me having even more flag officers that I dont need, now I got a whole bunch of potentially useful flag officers who could be filling the captain posts but are now over ranked for them.
The on demand system would ensure that if I had 300 captain posts I wouldn't need to fill 150 CDRE posts 75 RADM and so on.
If I had 50 CDRE posts it would only fill those 50 posts
-
--- Haven't militaries been more or less an "Up and Out" type of system since militaries were even a thing? Feudalism and the like notwithstanding of course.
-
Even if so, Aurora isn't really a good game to model that at least in its current form. In the real world, if you promote an officer, you give them a job... even if it is a fairly pointless desk job, they must have something to do for the sake of earning their paycheck, a functional modern military (emphasis!) doesn't promote someone to General just so they can stand around and look pretty. If you look at the US military for instance you will see that pretty much every general/admiral holds a position...but some of these are deputy/vice/assistant positions, and others will hold multiple positions at once. And some of these positions are...well, let's just say that you're not likely to see a mechanical implementation for the Sexual Assault Prevention and Response Office (SAPRO) (https://en.wikipedia.org/wiki/Sexual_Assault_Prevention_Response_(US_military)) in Aurora, while certainly an important office it is decidedly not a "traditional military" command, yet you will find a MAJGEN in charge all the same.
But this is all about the "real world" and here we play Aurora. Mechanically, the main issue is simply that it is frustrating for players when the fixed promotion structure places rigid constraints on how their forces can be structured in order to provide adequate command & control for all ships, formations, etc. In real life militaries can be considerably more flexible than Aurora mechanics allow - you might find a Brigadier in command of a division if there are not enough MAJGENs to go around, or you might see a LTGEN commanding a corps subordinate to another LTGEN commanding an army. Aurora doesn't really play nicely with all of these real-life exceptions to rules, and I can only imagine that trying to program a robust, automatic promotion + assignment system which is as flexible as real life would be a nightmare for Steve. So instead, we have the fairly rigid rules about ranks and assignments, and a flexible on-demand promotion scheme may not be "realistic" but it will make the system work for most players at a mechanics level, and at a roleplay level of course we can do whatever we want as always.
-
--- Haven't militaries been more or less an "Up and Out" type of system since militaries were even a thing? Feudalism and the like notwithstanding of course.
No.
It is at best a late 19th century thing. In the Royal Navy one of the first fully professional armed services compulsory retirement was only introduced in 1870. It contained a provision that no officer who had commanded a ship during the napoleonic war period would be forcibly retired following the victory over USS Chesapeake Provo Wallis commanded HMS Shannon for 6 days , he died in 1892 not long before is 101st birthday as Admiral of the fleet without an active command but technically available to be called back to take a command. Techically he served for 97 years having gone on the books as a child although his first actual service was on board HMS Cleopatra at the age of 13
-
I always kinda headcanon'd that officers without a job were doing shore tours / staff type stuff, especially since staff jobs were removed after VB6. (Consequently, that may be a worthwhile thing to look back into now that we're constrained by only total officers now and nothing else for ranks, otherwise you could stack like 10 tiers over an admin command if you wanted to minmax: staff requirements would provide a cool rp tool while providing an actual coded disincentive)
But yeah the vast majority of officer billets aren't commands or department heads on ships. There's plenty of "off-screen" work for your officer corps in either system, but the current makes much more sense. You're typically only promoted as an officer if there's actual work for you to do and a spot for you to be promoted into (a billet), which is why the old system kinda peeved me.
On this topic some flexibility with ranks not mattering for at least the most immediately superior officer to another in a chain of command (with a max difference of only one rank or so) would be a possible addition that would help with QOL, I think. Billet almost always takes precedence over rank. As an example, a US Navy aircraft carrier has a LOT of people, so department head, a job which is usually an O-3 (Lieutenant) on a smaller ship is actually staffed by an O-6 (Captain). Consequently the CO is also an O-6, but he of course still is the boss of the other 6-7 O-6s assigned underneath him.
-
Staff billets and ± 1 rank positions would be welcomed additions.
Additional something similar to staff positions or system governors for civilian administrators as I tend to end up with a lot of jobless admins.
-
So does the latest ground invasion in the BSG campaign involve CAS? Asking for a friend.
-
So does the latest ground invasion in the BSG campaign involve CAS? Asking for a friend.
;D +1 for a friends friend!
-
Can Steve add a checkbox for ground unit template box that exempts the template from numbering? For dedicated supply stockpile templates and replacement formations.
Checkbox for excluding them from having officer assigned to them as well.
-
Can Steve add a checkbox for ground unit template box that exempts the template from numbering? For dedicated supply stockpile templates and replacement formations.
Not sure why you would need this, since every template has its own numbering series as of 1.13. I.e., supply or replacement formations will not inflate the numbering of "real" formations anymore.
Checkbox for excluding them from having officer assigned to them as well.
Would be nice, currently I work around this by having a really high rank called "NO_OFFICER" or similar.
-
Would be nice, currently I work around this by having a really high rank called "NO_OFFICER" or similar.
Yes, this trick may not work with the new way promotions work.
-
Would be nice, currently I work around this by having a really high rank called "NO_OFFICER" or similar.
Yes, this trick may not work with the new way promotions work.
If I understand how the system works, I think it can still work but you have to have a completely empty rank underneath.
So a rank system like:
N/A NO OFFICER
--- NO COMMAND
FM Field Marshal
GEN General
...
This should 'work' because the auto-promotion system will still only promote an officer by one rank at a time, and an officer can only promote if a suitable post is available. Thus, no officer will ever promote to the NO COMMAND rank, thus no officer will ever be available to promote to the NO OFFICER rank.
However this is still an ugly workaround and not very flexible if you want to add ranks later, so the suggested change is very much preferable.
-
I like the idea of the new repair bays. Do they only work in orbit of a population or can you build deep-space repair facilities?
-
I like the idea of the new repair bays. Do they only work in orbit of a population or can you build deep-space repair facilities?
Only at populations for now, although you can create a 'population' for this purpose on any available chunk of rock.
-
I like the idea of the new repair bays. Do they only work in orbit of a population or can you build deep-space repair facilities?
Only at populations for now, although you can create a 'population' for this purpose on any available chunk of rock.
Would having a population hab on it and making it a space station instead of a ship make it work as a deep-space repair facility?
If so, then it open the gates for a multi-purpose "mobile" base. Similar to how a FOB functions. So, just move them closer to the front lines and the ships can then ressuply, repair and etc.
-
I like the idea of the new repair bays. Do they only work in orbit of a population or can you build deep-space repair facilities?
Only at populations for now, although you can create a 'population' for this purpose on any available chunk of rock.
Would having a population hab on it and making it a space station instead of a ship make it work as a deep-space repair facility?
If so, then it open the gates for a multi-purpose "mobile" base. Similar to how a FOB functions. So, just move them closer to the front lines and the ships can then ressuply, repair and etc.
No, orbital habitats also need a population.
What I am probably going to add at some point is the ability for players to create a 'population' in deep space. This would involve adding a tiny rock with 0.001 pop capacity so I don't need to rewrite all the pop code.
-
What I am probably going to add at some point is the ability for players to create a 'population' in deep space. This would involve adding a tiny rock with 0.001 pop capacity so I don't need to rewrite all the pop code.
Can we call such a rock a hackteroid?
-
Just to clarify Repair ships need resources right? it wasn't too specific in the changes list. So the colony in question does need a store of resources?
-
What would the advantage of repair bays be over commercial damage control plus commercial hangar bays? My hunch from the post is that:
- The former can scrap ships, uses TN resources, and is more resource efficient (shipyard repair vs. damage control rolls).
- The latter doesn't require a population, uses MSP, and is more space efficient (1600t hangar + 300t damage control).
-
What would the advantage of repair bays be over commercial damage control plus commercial hangar bays? My hunch from the post is that:
- The former can scrap ships, uses TN resources, and is more resource efficient (shipyard repair vs. damage control rolls).
- The latter doesn't require a population, uses MSP, and is more space efficient (1600t hangar + 300t damage control).
Armor damage can only be repaired in a shipyard, or now by the new repair bay modules. Using MSP to do repairs is nominally more efficient (about 50% of the resource cost compared to doing repairs, for most components) although for some components that use non-critical resources it may be more economical to use a repair yard instead.
-
Armor damage can only be repaired in a shipyard, or now by the new repair bay modules.
Also military hangar bays with MSP.
-
What's the advantage of repairyards over repair ships? They require workers, but I assume are a lot cheaper to build?
Edit:
Oh, repairyards can be dynamically expanded of course, while the ships are always at the same size unless you redesign them.
It's interesting that this now allows us to make repair space stations, which really are very similar to repairyards in concept, except they play by slightly different rules.
I'm just wondering a little about if not requiring workers is a bit too much of an upside, like how it's rare to see players build terraforming buildings, since terraforming ships are a lot easier to use since they don't require workers.
Hey, Steve, do you see yourself creating a ship component version of shipyards eventually, too, so that you can have ships constructing other ships?
-
As someone whose grandfather served on a repair ship in WW2 and the Korean war, I very much appreciate this repair bay addition.
Will they stack in a fleet or no? after further reading I see how they work, not a bad trade off for mobile repair. Its not like anyone has multiple floating dry docks working on one big ship.
-
maybe I am blind or just ... as I haven't played Aurora a few months waiting for 2.0 but ...
when were "repair yards" added to the game? I couldn't find any hint for them other ion the new chances for 2.0 today.
also for the mobile repair ships:
- which officer bonus applys to them (if any)? (have naval officers "shipbilding bonus"?)
- will the repair ships need resources and MSP?
-
Just to clarify Repair ships need resources right? it wasn't too specific in the changes list. So the colony in question does need a store of resources?
Yes, they need resources.
-
Hey, Steve, do you see yourself creating a ship component version of shipyards eventually, too, so that you can have ships constructing other ships?
Yes, probably. The tricky part was finding a way to avoid rewriting a lot of the shipyard code when shipyards were added to ships. By linking them to a pop while in orbit, the pop thinks it owns the shipyard so all the existing code works. The mobile repair bays are sort of a dry run for mobile shipyards.
-
when were "rapair yards" added to the game? I couldn't find any hint for them other ion the new chances for 2.0 today.
- which officer bonus applys to them (if any)? (have naval officers "shipbilding bonus"?)
Repair yards came in 1.13.
IIRC it's the "Production" bonus that affects this.
-
Armor damage can only be repaired in a shipyard, or now by the new repair bay modules.
Also military hangar bays with MSP.
Is it really only military hangars? I looked at original post from Steve and there is no mention of it being limited to military hangars.
In my last game I had repair ships with commercial hangars and I think that I used them to repair some captured NPR ships.
-
Armor damage can only be repaired in a shipyard, or now by the new repair bay modules.
Also military hangar bays with MSP.
Is it really only military hangars? I looked at original post from Steve and there is no mention of it being limited to military hangars.
In my last game I had repair ships with commercial hangars and I think that I used them to repair some captured NPR ships.
You can repair in a commercial hangar, although that uses MSP rather than minerals. Also a ship in a shipyard (or repair yard) does not require maintenance, while a ship being repaired in a commercial hangar does.
-
Yes, probably. The tricky part was finding a way to avoid rewriting a lot of the shipyard code when shipyards were added to ships. By linking them to a pop while in orbit, the pop thinks it owns the shipyard so all the existing code works. The mobile repair bays are sort of a dry run for mobile shipyards.
This sounds great! The one thing that bothered me was I had to divert my industrial resources to build ship components when it was more useful to build more industries. Hope to see this in 2.1 :)
No need to push for 2.0 ;D
-
Armor damage can only be repaired in a shipyard, or now by the new repair bay modules.
Also military hangar bays with MSP.
Is it really only military hangars? I looked at original post from Steve and there is no mention of it being limited to military hangars.
In my last game I had repair ships with commercial hangars and I think that I used them to repair some captured NPR ships.
You can repair in a commercial hangar, although that uses MSP rather than minerals. Also a ship in a shipyard (or repair yard) does not require maintenance, while a ship being repaired in a commercial hangar does.
Oh I thought parasite repair was just a military hangar thing for some reason.
-
Correct me if I'm wrong but:
Repair bay - 2000 tons size for 1000 tons of repair capability
Commercial hangar - 1600 tons size for 1000 tons of repair capability
I would adjust the size of one or the other so that they match. Then the choice between which one to use would be purely whether you want to spend minerals or maintenance supplies for repairs.
-
Correct me if I'm wrong but:
Repair bay - 2000 tons size for 1000 tons of repair capability
Commercial hangar - 1600 tons size for 1000 tons of repair capability
I would adjust the size of one or the other so that they match. Then the choice between which one to use would be purely whether you want to spend minerals or maintenance supplies for repairs.
Except repair bays need to orbit a colony to work and hangars can repair on the move (and can carry ships).
Should hangars maybe be bigger than repair bays, since hangars are essentially repair bays with added functionality?
-
Correct me if I'm wrong but:
Repair bay - 2000 tons size for 1000 tons of repair capability
Commercial hangar - 1600 tons size for 1000 tons of repair capability
I would adjust the size of one or the other so that they match. Then the choice between which one to use would be purely whether you want to spend minerals or maintenance supplies for repairs.
Adding to this, Commercial Hangars cost only 100 BP (75% of which is Vendarite, usually a very non-critical mineral) while the Repair Bay will cost 120. As it stands right now it seems like the only serious benefit for Repair Bays is the ability to scrap ships (not much more than a niche use, IMO), or to do repairs without MSP which is a questionable benefit at best.
Personally I would suggest to raise the Commercial Hangar size to double that of the military Hangar Bay, either 2000 (round) or 2100 (exact) tons, which would place it in line with the other existing commercial variant components (Magazine C500 and Damage Control) which are double the size of their military equivalents. I'm not sure which direction the costs should be changed in - whether the hangar cost should increase or the repair bay cost decrease.
-
Personally I would suggest to raise the Commercial Hangar size to double that of the military Hangar Bay, either 2000 (round) or 2100 (exact) tons, which would place it in line with the other existing commercial variant components (Magazine C500 and Damage Control) which are double the size of their military equivalents. I'm not sure which direction the costs should be changed in - whether the hangar cost should increase or the repair bay cost decrease.
I would say go other way around. To give it more identity, decrease the size and increase the cost. Lets say 500t for a kt worth of space, with the cost going up 2-3X. It will allow to service ships its size which would be extremely useful for jump drive commercial ships as players, especially in low tech games can't afford to research much larger jump drive for sake of making a repair ship to fix up damaged vessel without jumpgate access.
With incoming raiders, it could be pretty useful in this iteration.
-
I would personally keep the hangar bays the way they are but limit their repair capabilities. If they could not repair vessels of a displacement larger than 1kt, there would be a niche for both.
Another thing that could be looked at is the repair cost. Maybe shipyards should have an edge over hangars when it comes to economy. Does anyone know how expensive the repair of a 100 BP engine is in a shipyard compared to a hangar?
-
I would personally keep the hangar bays the way they are but limit their repair capabilities. If they could not repair vessels of a displacement larger than 1kt, there would be a niche for both.
I suspect this would run afoul of the "no arbitrary size restrictions" rule Steve usually enforces.
Another thing that could be looked at is the repair cost. Maybe shipyards should have an edge over hangars when it comes to economy. Does anyone know how expensive the repair of a 100 BP engine is in a shipyard compared to a hangar?
A 100 BP engine would cost 100 gallicite to repair in a shipyard (plus 100 wealth, usually not the important consideration) or 100 MSP in a hangar (200 if battle damaged, IIRC). 1 MSP costs 0.1 duranium, 0.05 uridium, and 0.1 gallicite (0.25 BP) to produce so usually the MSP repair is much more economical. The chief exception is if the component costs a plentiful resource like tritanium or corbomite, in which case it might make sense to conserve MSPs in order to conserve duranium/uridium/gallicite, but this is admittedly a very niche exception.
-
Another thing that could be looked at is the repair cost. Maybe shipyards should have an edge over hangars when it comes to economy. Does anyone know how expensive the repair of a 100 BP engine is in a shipyard compared to a hangar?
A 100 BP engine would cost 100 gallicite to repair in a shipyard (plus 100 wealth, usually not the important consideration) or 100 MSP in a hangar (200 if battle damaged, IIRC). 1 MSP costs 0.1 duranium, 0.05 uridium, and 0.1 gallicite (0.25 BP) to produce so usually the MSP repair is much more economical. The chief exception is if the component costs a plentiful resource like tritanium or corbomite, in which case it might make sense to conserve MSPs in order to conserve duranium/uridium/gallicite, but this is admittedly a very niche exception.
So, where would this ship take the Material or MSP from to repair such an Engine?
Phoenix class Repair Ship 58,446 tons 1,160 Crew 3,354.2 BP TCS 1,169 TH 1,500 EM 0
1283 km/s Armour 1-134 Shields 0-0 HTK 106 Sensors 6/8/0/0 DCR 1 PPV 0
MSP 35 Max Repair 120 MSP
Captain Control Rating 1 BRG
Intended Deployment Time: 3 months
Repair Capacity: 20000 tons
Commercial Ion Drive (5) Power 1500 Fuel Use 2.48% Signature 300 Explosion 4%
Fuel Capacity 250,000 Litres Range 31.1 billion km (280 days at full power)
Artemis-30NB Navigation Sensor (5) GPS 1920 Range 31.5m km Resolution 120
Themis TH-6 Passive Sensor (5) Sensitivity 6 Detect Sig Strength 1000: 19.4m km
Themis EM-8B Passive Sensor (5) Sensitivity 8 Detect Sig Strength 1000: 22.4m km
I guess we will have to drop the material on the planet.
-
I guess we will have to drop the material on the planet.
That is correct. Per Steve's comments, the Repair Bays still only work at populations (colonies/bodies), you just don't need actual population (number) to work them - same as terraformers, orbital miners, etc.
-
Can a repair ship use minerals that are within the fleet it is in or must the minerals be unloaded planetside?
-
I guess we will have to drop the material on the planet.
That is correct. Per Steve's comments, the Repair Bays still only work at populations (colonies/bodies), you just don't need actual population (number) to work them - same as terraformers, orbital miners, etc.
That's what I thought. We are going to need a filter on the galactic map then, or the ship will still count as shipyard also on the shipyard filter?
Obviously the above is for Steve to answer.
-
I would personally keep the hangar bays the way they are but limit their repair capabilities. If they could not repair vessels of a displacement larger than 1kt, there would be a niche for both.
I suspect this would run afoul of the "no arbitrary size restrictions" rule Steve usually enforces.
Another thing that could be looked at is the repair cost. Maybe shipyards should have an edge over hangars when it comes to economy. Does anyone know how expensive the repair of a 100 BP engine is in a shipyard compared to a hangar?
A 100 BP engine would cost 100 gallicite to repair in a shipyard (plus 100 wealth, usually not the important consideration) or 100 MSP in a hangar (200 if battle damaged, IIRC). 1 MSP costs 0.1 duranium, 0.05 uridium, and 0.1 gallicite (0.25 BP) to produce so usually the MSP repair is much more economical. The chief exception is if the component costs a plentiful resource like tritanium or corbomite, in which case it might make sense to conserve MSPs in order to conserve duranium/uridium/gallicite, but this is admittedly a very niche exception.
Repairing damage on a carrier for 25 to 50% of the cost is something that kills repair yards right now except for role play reasons and I do not think looking into this has any priority right now, as has changing the repair cost of damage at shipyards. So maybe changing hangars in this regards is a fast and simple solution. Even though it might be arbitrary, it is still a thing that today's carriers cannot handle a single craft with a mass equal to that of a typical air group. Introducing such a limit might open up a niche for the repair yards, which does not exist otherwise.
-
--- Or make MSP more costly or repairs more costly in MSP? Designable hangars would be a treat; Max Craft Tonnage, Max Number of Craft, Commercial or Military, Layers of Armor, Deck Crew (for improving re-fuel / re-arm / repair times)
--- Those would be nifty. As it stands the best uses for repair modules is cutting down pop cost and a mobile repair bay (Since Repair Yards aren't quite as mobile as a ship). I'd love to see it take minerals from the ships own cargo as well as Maintenance Modules making MSP to re-fill the ships own stores from minerals in a cargo bay or on a colony. Hell I'd love to see ship-bourne Ordinance and Fighter "factories" with lowered build times versus their planet-side counterparts.
--- Honestly, MSP should be 10x more expensive and Repair Yards should be faster than Modules. This would make a nice stop-gap until a "real" solution is devised.
-
Repairing damage on a carrier for 25 to 50% of the cost is something that kills repair yards right now except for role play reasons and I do not think looking into this has any priority right now, as has changing the repair cost of damage at shipyards. So maybe changing hangars in this regards is a fast and simple solution. Even though it might be arbitrary, it is still a thing that today's carriers cannot handle a single craft with a mass equal to that of a typical air group. Introducing such a limit might open up a niche for the repair yards, which does not exist otherwise.
Im using 24kt parasite battleships for example >.>
The game has no way of seeing what sort of thing I put in my hangars, arbitrary limits are just that, arbitrary.
That's why I asked for change that would allow the shipyard to do something that's hangars just cant do.
They would find their niche in repairing ships too big for hangars.
-
Maybe just change all repairs to MSP as first step, it seems more realistic that forward deployed mobile repair shipyards is not smelting duranium to make new bulkhead but instead is using some prefab MSPs and 3d printing new parts.
Next step would be to change how much MSP is used by repair in hangar/shipyard and possibly how long it takes. Steve could make repair yards faster and cheaper alternative, where hangars would have advantage of repairs on the move and the fact that they serve other purpose as well but would be more expensive/slow.
But it is also possible to just keep it as it is, not everything is balanced in Aurora, some things are simply less effective but we still do it for roleplay and such.
-
Repairs bays are double capacity because shipyards are double capacity when towed. Otherwise, Repair Bays become more useful than Repair Yards.
In terms of the commercial hangar vs repair yard, I agree the balance is probably in favour of commercial hangars vs both yards and bays. However, they were something of a stop-gap solution to allow functioning repair ships until I could find a better solution and are probably over-powered for repair anyway (they can use their capacity for multiple ships for example, which a repair yard or a shipyard cannot).
I will probably remove the repair capability from commercial hangars. Military hangars will remain as they are now so you do have the hangar alternative, but with an added cost for that flexibility.
-
I will probably remove the repair capability from commercial hangars. Military hangars will remain as they are now so you do have the hangar alternative, but with an added cost for that flexibility.
That sounds like a good change to me. If we want to model civilian crews doing emergency repairs on warships, then the repair yard and repair bay in a ship combos work well enough, while military hangars still being able to repair stuff allows the flexibility of both carriers repairing small craft as well as gigantic motherships carrying BB-parasites like some players love to do.
-
hey steve how much crew does each repair bay add?
-
I will probably remove the repair capability from commercial hangars.
When you say remove repair capability, do you mean the ability to use the parent ship DCR and MSP, or just the ability to repair armour that was added in 1.13?
-
--- Honestly, MSP should be 10x more expensive
Yes, officer, this man right here.
I will probably remove the repair capability from commercial hangars. Military hangars will remain as they are now so you do have the hangar alternative, but with an added cost for that flexibility.
This was what I was thinking although I couldn't readily justify it, but I suppose sometimes an arbitrary limit is necessary for balance.
-
I will probably remove the repair capability from commercial hangars. Military hangars will remain as they are now so you do have the hangar alternative, but with an added cost for that flexibility.
This was what I was thinking although I couldn't readily justify it, but I suppose sometimes an arbitrary limit is necessary for balance.
A less arbitrary method would be to limit the repair abilities of commercial hangars to commercial components only. That way you can justify that there is a difference in tooling between military and commercial hangars.
-
That's a pretty good idea too!
-
I will probably remove the repair capability from commercial hangars. Military hangars will remain as they are now so you do have the hangar alternative, but with an added cost for that flexibility.
This was what I was thinking although I couldn't readily justify it, but I suppose sometimes an arbitrary limit is necessary for balance.
A less arbitrary method would be to limit the repair abilities of commercial hangars to commercial components only. That way you can justify that there is a difference in tooling between military and commercial hangars.
Very good idea. For ease of understanding, I think I will make it commercial ships, rather than commercial components, as that is how commercial shipyards work - they can't repair military ships.
-
hey steve how much crew does each repair bay add?
50 crew per bay.
-
The listed change is a good way to do it. Military ships can still make functional use of commercial hangars, but that all-important armor repair is something repair bays will provide. Still offers a lot of flexibility in how to design a deep space base or to provide incremental upgrades over time for such bases.
-
Can we get ships repairing their own armor when inside the commercial hangar if they have MSP to do so?
Also, some sort of fighter damage control to make fighters able to repair themselves.
My current doctrine is to put fighter wings on my freighter ships for self defense, making them completely incapable of repair in hangars would make making repairs on one of few thousands fighter get old fast.
I don't mind compromising fighter's effectiveness so I can put it on a commercial ship, but having to deal with damaged stuff manually would be major pain especially as damage can happen in deep space and fleet has orders for next 5 years I cant drop for repairs of a fighter...
Or, just an order to "repair all damaged ships in fleet" that would queue all damaged ships to undergo repairs in repair yards of a body.
-
Don't send the fleet home, send the fighter home. A small, fast carrier with limited capacity would do
-
Or swap out whole fighter wings at a time.
Admittedly it will get tedious when you get into the scores or hundreds of freighters, but it won't involve individual fighters having to be detached and ferried home.
For that matter, a "transfer all parasites to/from fleet" and "reload standard parasite complement from fleet" would be nice orders to have in general. I see a bunch of use cases for them in reducing the micro associated with using FACs for rear area defense.
-
The changes to the civilian hangar sounds great so far. Will there be changes to military hangars as well now? I was thinking of them as some sort of missile launcher with reusable craft. Missile launchers are purpose build for missiles of a certain size and they improve with tech, which is a thing hangars sadly do not.
What came to my mind was the following:
Players can create hangars for parasites of a certain HS and add refueling tech, MSP transfer tech, ammunition transfer tech and deck armor of their choice. Those military hangars would not carry 1000 tons of parasites like they do now, but they would have bays in them with a certain maximum tonnage capacity. Say 2 500 ton bays as an example. This would allow you to store 2 500 ton craft in it or 2 smaller craft, like 300 ton fighters. You would not be able to bring 3 though.
The total displacement of a flight deck would be something like this:
intended HS * (1.25 + optional refueling + optional rearming + optional maintenance +...) = HS of ONE fighter bay
fighter bays could then be coupled to hangar decks and get efficiency bonuses like shield generators get now. A 1 bay deck would have the full displacement, a 10 bay deck 90% and so on.
The transfer rate of fuel and MSP would have to be scaled with the intended parasite HS to make large parasites viable.
PS: Now you can roast me.
-
PS: Now you can roast me.
(https://media.giphy.com/media/lMUGMp2lImgGA/giphy.gif)
I think the important question is - does this really add anything to the game mechanics, in terms of player engagement or interesting decisions? I don't really see any benefit, "all" this accomplishes is making hangar bays harder and less convenient to use. You can argue this is more "realistic" or "immersive" but I would argue that you can easily roleplay the essence of this mechanic if you like, and the mechanic as it stands currently allows more roleplay freedom while these proposed mechanics limit it - see for example Steve's BSG campaign where he has repurposed survey carriers as light battle carriers in a time of pressing need, not so easy to do when you can only put one 300-ton fighter in a 1000-ton bay.
The only change here I think makes sense for hangars is bumping up the size premium to 25% or 50% instead of the current measly 5%, however this would be a significant nerf to carrier capacity so I don't think it is necessary, it is an easy enough DB edit anyways.
-
The only change here I think makes sense for hangars is bumping up the size premium to 25% or 50% instead of the current measly 5%, however this would be a significant nerf to carrier capacity so I don't think it is necessary, it is an easy enough DB edit anyways.
25% for universal hangars with specialized bays being just the current 5% extra size?
Middle ground, but still just blanket carrier nerf, dunno if its good to keep nerfing them more than once in one patch.
Don't send the fleet home, send the fighter home. A small, fast carrier with limited capacity would do
Each and every one of my freighters have at least 5 fighters some 30+, sending a fast carrier for each mission isn't really an option, is it... The whole purpose is to add cheap security to long and slow journeys of commercial fleets.
Oh, or could also add another function for fighter tag: Can be repaired in any hangar.
Because shipyards arent really made to do that sort of work anyway...
-
Can we get ships repairing their own armor when inside the commercial hangar if they have MSP to do so?
Ships can't repair their own armour anywhere in the game.
Also, some sort of fighter damage control to make fighters able to repair themselves.
Fighters can already repair themselves if they have sufficient MSP
My current doctrine is to put fighter wings on my freighter ships for self defense, making them completely incapable of repair in hangars would make making repairs on one of few thousands fighter get old fast.
I don't mind compromising fighter's effectiveness so I can put it on a commercial ship, but having to deal with damaged stuff manually would be major pain especially as damage can happen in deep space and fleet has orders for next 5 years I cant drop for repairs of a fighter...
Fighters on commercial ships would require long maintenance and deployment times because the commercial hangars don't provide maintenance - that is true in v1.13 too - so if you have already designed fighters with that in mind, they should already have a reasonable self-repair capability.
-
Ships can't repair their own armour anywhere in the game.
Yeah, that's why I asked if they could do repair on themselves there, like a drydock.
Fighters can already repair themselves if they have sufficient MSP
Can they? I had a damaged fighter that should have enough MSP to fix itself orbiting a planet for PPV for maybe 30 years before it was visited by angry NPR.
It was still damaged when I was making stock of my forces in the system before battle. It was being fully maintained and had MSP whole time.
Fighters on commercial ships would require long maintenance and deployment times because the commercial hangars don't provide maintenance - that is true in v1.13 too - so if you have already designed fighters with that in mind, they should already have a reasonable self-repair capability.
They usually get 20 years lifespan, but as stated, while damage to fighters isn't that common, they usually just die, I didn't see one repair itself even if it should have enough to do so three times over. If they can and something is weird on my side, its fine.
-
I believe you have to go to the damage control screen and queue the damaged components (or tell it to auto-queue).
-
Ships can't repair their own armour anywhere in the game.
Yeah, that's why I asked if they could do repair on themselves there, like a drydock.
Fighters can already repair themselves if they have sufficient MSP
Can they? I had a damaged fighter that should have enough MSP to fix itself orbiting a planet for PPV for maybe 30 years before it was visited by angry NPR.
It was still damaged when I was making stock of my forces in the system before battle. It was being fully maintained and had MSP whole time.
Fighters on commercial ships would require long maintenance and deployment times because the commercial hangars don't provide maintenance - that is true in v1.13 too - so if you have already designed fighters with that in mind, they should already have a reasonable self-repair capability.
They usually get 20 years lifespan, but as stated, while damage to fighters isn't that common, they usually just die, I didn't see one repair itself even if it should have enough to do so three times over. If they can and something is weird on my side, its fine.
I'm going to dogpile a bit to also mention (again) that I have had damaged CAS fighters return to a carrier and only have their armor and not any of their damaged internal components be repaired by the mothership.
In my case the fighters would not be able to do any MSP related repairs by themselves (but the CV had MSP) but I was confused as to why I just had damaged fighters sitting in the bay not being repaired.
Perhaps its something to do with HTK 0 components common in fighters idk. I haven't heard of anyone repairing damaged fighter internals inside a carrier yet but idk if its happened in the 12 colonies playthrough.
-
I believe you have to go to the damage control screen and queue the damaged components (or tell it to auto-queue).
In my case the components were on the fighters damage-con queue.
-
Players might refer to fighters as a specialised type, but they are the same as any other ship in mechanics terms and not treated any differently in hangars. The only real difference is that they can be built in fighter factories due to their size.
I've had them repaired in the BSG game, but I had to tell them to repair - it is not automatic.
-
Orbital habitats can be built at, or towed to, the DSP and colonists can be delivered to, or collected from, the DSP. If there is no orbital population capacity, any delivered colonists will die.
Excellent, now we have a way to "accidentally" kill millions of people at once through player ineptitude, this has been lacking ever since mass driver-induced population shrinkage was removed from the game. ;D
Quick question, what happens if we drop off alien prisoners at the DSP? At a body they are just added to a number on the summary screen and otherwise cannot be interacted with. I find the idea of dumping a few hundred POWs at an empty DSP to be left floating in the void rather amusing.
-
Orbital habitats can be built at, or towed to, the DSP and colonists can be delivered to, or collected from, the DSP. If there is no orbital population capacity, any delivered colonists will die.
Excellent, now we have a way to "accidentally" kill millions of people at once through player ineptitude, this has been lacking ever since mass driver-induced population shrinkage was removed from the game. ;D
Quick question, what happens if we drop off alien prisoners at the DSP? At a body they are just added to a number on the summary screen and otherwise cannot be interacted with. I find the idea of dumping a few hundred POWs at an empty DSP to be left floating in the void rather amusing.
Currently, that isn't a valid order for a DSP, although I guess for RP reasons that 'spacing the prisoners' should be an option :)
-
Super excited to see DSPs! I always get that one annoying planetless system that's also a major jump nexus, so it'll be really nice to be able to set up at least a logistics base there.
Any chance we'll see maintenance modules eventually changed to produce MSP as well? That would let the fully replace maintenance facilities at a DSP, but might make them a bit too good. For that matter I'm also curious about the chance of some sort of ordinance/fighter factory module now that DSPs are an option, since I normally set up my logistics bases with those for resupply purposes.
-
Steve since you've said that 2.0 is feature complete you have added 2 features and a balance patch lol
i'm going to need you to stop my wanting can only go so high lol
-
Players might refer to fighters as a specialised type, but they are the same as any other ship in mechanics terms and not treated any differently in hangars. The only real difference is that they can be built in fighter factories due to their size.
I've had them repaired in the BSG game, but I had to tell them to repair - it is not automatic.
Im pretty sure I set it to repair itself, but it was few months back now, so cant say for sure, the fighter got blown up heroically in defensive action. Could be I forgot.
Anyway, with deep space habitats, we need something for colonists to do!
*asks for some orbital module needing pops to work shamelessly*
Zero G labs, manufacturing centres etc!
Could make some components to be impossible to make on planet, needing manufacturing on deep space habitat only to be ferried to shipyards for construction~
Possibilities are endless, and so is hype \o/
-
This is exceptional!
Orbital habitats can be built at, or towed to, the DSP and colonists can be delivered to, or collected from, the DSP. If there is no orbital population capacity, any delivered colonists will die.
Excellent, now we have a way to "accidentally" kill millions of people at once through player ineptitude, this has been lacking ever since mass driver-induced population shrinkage was removed from the game. ;D
Quick question, what happens if we drop off alien prisoners at the DSP? At a body they are just added to a number on the summary screen and otherwise cannot be interacted with. I find the idea of dumping a few hundred POWs at an empty DSP to be left floating in the void rather amusing.
Heh, this was my immediate thought too. Cleansing a planet of xenos very quickly just got as easy as putting a DSP immediately in orbit of the planet and just putting colony ships on loop from the planet to the DSP. Might create space junk though.. ;D
Other question: for a while I've wanted to do a purely nomadic playthrough, with huge ships and travelling hordes of civilian populace, and this change even as it is now makes that extremely tenable. This raises a question, however: what happens when you pull orbital habitats from a DSP? I assume it just rips the pop capacity out of the spot and everyone dies. I imagine it would be quite a hard workaround to get population to somehow be able to transiently move with orbital habitats (moving DSP), but is there an actual issue here? Is it possible to somehow just have a capability of DSPs to have a second towing option that just causes the DSP to move (or split) and follow a TF?
Getting quite into the weeds with this one, but I'd thought I'd ask. The things that are possible in C# Aurora are really pushing the boundaries!
EDIT: A far more sane option might just be to have the ability to "pack up" orbital habs and create massive colony ships, although this also raises huge balance issues.
-
Other question: for a while I've wanted to do a purely nomadic playthrough, with huge ships and travelling hordes of civilian populace, and this change even as it is now makes that extremely tenable. This raises a question, however: what happens when you pull orbital habitats from a DSP? I assume it just rips the pop capacity out of the spot and everyone dies. I imagine it would be quite a hard workaround to get population to somehow be able to transiently move with orbital habitats (moving DSP), but is there an actual issue here? Is it possible to somehow just have a capability of DSPs to have a second towing option that just causes the DSP to move (or split) and follow a TF?
I think it would be feasible to build OrbHab stations with built-in cryo modules and a cargo shuttle bay, and have them load/unload their own colonists when moving between populations.
The requirement for a cargo shuttle bay is perhaps a bit silly, but from a RP perspective what self-respecting nomad race population hub superstation wouldn't have some cargo shuttle hangars?
-
This is exceptional!
Orbital habitats can be built at, or towed to, the DSP and colonists can be delivered to, or collected from, the DSP. If there is no orbital population capacity, any delivered colonists will die.
Excellent, now we have a way to "accidentally" kill millions of people at once through player ineptitude, this has been lacking ever since mass driver-induced population shrinkage was removed from the game. ;D
Quick question, what happens if we drop off alien prisoners at the DSP? At a body they are just added to a number on the summary screen and otherwise cannot be interacted with. I find the idea of dumping a few hundred POWs at an empty DSP to be left floating in the void rather amusing.
Heh, this was my immediate thought too. Cleansing a planet of xenos very quickly just got as easy as putting a DSP immediately in orbit of the planet and just putting colony ships on loop from the planet to the DSP. Might create space junk though.. ;D
Other question: for a while I've wanted to do a purely nomadic playthrough, with huge ships and travelling hordes of civilian populace, and this change even as it is now makes that extremely tenable. This raises a question, however: what happens when you pull orbital habitats from a DSP? I assume it just rips the pop capacity out of the spot and everyone dies. I imagine it would be quite a hard workaround to get population to somehow be able to transiently move with orbital habitats (moving DSP), but is there an actual issue here? Is it possible to somehow just have a capability of DSPs to have a second towing option that just causes the DSP to move (or split) and follow a TF?
Getting quite into the weeds with this one, but I'd thought I'd ask. The things that are possible in C# Aurora are really pushing the boundaries!
EDIT: A far more sane option might just be to have the ability to "pack up" orbital habs and create massive colony ships, although this also raises huge balance issues.
Using the ingame cargo system might work. Colony ships carry their colonists as cargo. So you make it so that any ship that is classified as an OH can also carry colonists as cargo. Not only that you can add a new continuous order to a fleet with OHs called "assign to population at body" and then pick the population on that body you want to assign the OH to. Doing this adds the capacity of that OH to the population and adds the "cargo" of colonists to the actual population of that colony.
The main issue is population growth. When the population grows you would want to add cargo of the appropriate species into the cargo "hold" of the OH. But how do you determine how much of the new population goes into the OH and how many are living on the surface? Agriculture % is already based proportionally between the OH capacity and surface population so maybe a proportional approach would be best.
When you decide to move the OH you can issue another new order "unassign from population" or just cancel the existing assignment order. This would remove the OH capacity from the population as well as subtract population equal to the colonists that are in the cargo bay of the OH.
Also, colonists that are of a different species to the species of the assigned population should not be added to the population, though they will still take up OH space. Alternatively, you forbid an OH from housing multiple species outright, it would be helpful to somehow mark in UI what species an OH is carrying (if any).
Loading and unloading colonists would be a bit different. A colony ship with cargo shuttles should be able to choose to either unload onto the assigned population which puts people at the surface or they can directly unload colonists into the orbital habitats.
The final problem I can think of is population growth when the OH is unassigned/in transit. Either disable population growth or have it be a flat rate based on the species growth and empty capacity (like carrying capacity).
Edit: I will add that "assign OH to population" is a very helpful thing even without the consideration for mobile habitats. In multi-species empires it can be very useful to assign a group of habs to a specific population because you want to have lets say 2m human population of "overseers" in orbit while the 2bn NPR aliens you just conquered toil in labour camps OSHA compliant factories.
Would also be good when population gene-modding gets re-implemented or just any situation that warrants multiple populations on one system body.
-
Other question: for a while I've wanted to do a purely nomadic playthrough, with huge ships and travelling hordes of civilian populace, and this change even as it is now makes that extremely tenable. This raises a question, however: what happens when you pull orbital habitats from a DSP? I assume it just rips the pop capacity out of the spot and everyone dies. I imagine it would be quite a hard workaround to get population to somehow be able to transiently move with orbital habitats (moving DSP), but is there an actual issue here? Is it possible to somehow just have a capability of DSPs to have a second towing option that just causes the DSP to move (or split) and follow a TF?
I think it would be feasible to build OrbHab stations with built-in cryo modules and a cargo shuttle bay, and have them load/unload their own colonists when moving between populations.
The requirement for a cargo shuttle bay is perhaps a bit silly, but from a RP perspective what self-respecting nomad race population hub superstation wouldn't have some cargo shuttle hangars?
Or you could do that.
Though it would be problematic with my 1bn colonist mega stations to have that many cryo-pods. They're big enough as it is.
-
Or you could do that.
Though it would be problematic with my 1bn colonist mega stations to have that many cryo-pods. They're big enough as it is.
Honestly wouldn't be that much larger, only problem is, cost.
RIP there.
-
Cost would be the bigger issue, but if you are playing as a nomad race I would imagine you're SMing a bunch of these superstations at the start of your playthrough and then tugging them across the galaxy for a few centuries, not necessarily looking to stop in Alpha Centauri for a few centuries to build more.
-
Fighters can already repair themselves if they have sufficient MSP
Can they? I had a damaged fighter that should have enough MSP to fix itself orbiting a planet for PPV for maybe 30 years before it was visited by angry NPR.
It was still damaged when I was making stock of my forces in the system before battle. It was being fully maintained and had MSP whole time.
My guess would be that you need a Damage Control Rating of 1 or more to repair. You're unlikely to have a full 50T engineering space on a fighter, so most of the time you need the hanger to provide a bonus to the DCR otherwise the chance of repair is 0.
Regarding the Deep Space Population feature, I note that it uses the same acronym as the game Dyson Sphere Program.
There will be no surface location to place installations, ground forces, fuel, ordnance or MSP.
Without ground forces, how can we deal with unrest?
Due to the lack of a physical location, no ground combat can take place at a DSP, although any ships or stations at the location can be attacked via boarding combat.
If you capture an orbital habitat, what does that do to the portion of the population that depends on it?
Minerals can be delivered to the DSP and collected from it, as it assumed these are stored as free-floating resources.
This feels a little odd, I think the main thing is it feels discordant with the prohibition of storing fuel, ordnance, and MSP. While it seems possible for raw minerals to be kept in blocks floating freely in space, they ought to be in orbit of the star. It also implies that exposure to vacuum or solar radiation doesn't cause the materials to degrade in some way. I'd also be concerned about organization, access, and handling in the absence of any infrastructure.
The current rules make things simple, and that's probably for the best, but if you changed it so that minerals need to be stored on a ship/station with cargo space I think that would be entirely justifiable.
Orbital habitats can be built at, or towed to, the DSP
How can you build a habitat at the DSP if you can't have construction factories and a spaceport at the DSP?
Deep Space Populations do not orbit any stars. They remain in their original position.
Various comments regarding cryo storage for habitats
1 orbital habitat contains 200k people and takes 500kT of space at a cost of 200 BP
20 cryo transports contain 200k people and only takes 50kT of space at a cost of 1000 BP
I'd be more worried about the cost of adding cyro storage to a habitat than the size.
-
Orbital habitats can be built at, or towed to, the DSP
How can you build a habitat at the DSP if you can't have construction factories and a spaceport at the DSP?
You can build them with a shipyard.
You can have shipyards at a DSP.
-
Various comments regarding cryo storage for habitats
1 orbital habitat contains 200k people and takes 500kT of space at a cost of 200 BP
20 cryo transports contain 200k people and only takes 50kT of space at a cost of 1000 BP
I'd be more worried about the cost of adding cyro storage to a habitat than the size.
I see, so the idea could work fairly decently with cryo storage. This raises a question, however, from the "everything is consistent" side of the game's design. What justifies that the cost of enabling mobile habitats is 5 times the capacity of such habitats? Cryo storage is far more compact than orbital hab space so you can argue the cost is the "cryo" part of the design, which keeps everyone happy as a sardine in a sardine can for their journey. For orbital habs we have that cost reduction worked into "we just need a box that holds air and cleans it every now and then". The cryo storage just exists here as a workaround. Sure you can handwave it as something like "for safety purposes in-case something bad happens while moving" but that seems a bit spurious.
More than happy to use the system as is, but I would propose with this change that orbital habitats get a secondary function of being able to store colonists like cargo. Then we fall back into this sort of dichotomy we've been creating lately (e.g., with repair bays and hangars existing simultaneously) where these two similar components have over-lapping roles but are specialized in different ways.
The main problem I can see with this idea is that colonist transport capacity becomes much cheaper to build BP-wise, but you end up paying much more in fuel, and you're tying up mainline industry now instead of shipyards. Enabling orbital habitat colonist storage would create these interesting strategic decisions, imo, while also tying up a large consistency issue I think habitats have had for a while.
-
Well, empty star systems just got content! Babylon class star bases, here we go!
I was initially against allowing OH's to transport colonists but on second thought, the fact that they so much more space does balance them vis-a-vis cryo pods. So you'd want the latter for colony ships so that they don't get too big and slow but you can move Orbital Colonies around with their population intact if you want/need without having to do a complicated unload/reload dance.
-
Currently, that isn't a valid order for a DSP, although I guess for RP reasons that 'spacing the prisoners' should be an option :)
It is always good to "expand" Aurora ;D
-
Well, empty star systems just got content! Babylon class star bases, here we go!
I was initially against allowing OH's to transport colonists but on second thought, the fact that they so much more space does balance them vis-a-vis cryo pods. So you'd want the latter for colony ships so that they don't get too big and slow but you can move Orbital Colonies around with their population intact if you want/need without having to do a complicated unload/reload dance.
At the moment, orbital habitats are treated like infrastructure and are independent of the colonists. When you move them, the population stays behind. Once of the reasons was to avoid creating 'cheap' colony ships, but the massive size is an interesting point. While they might be 'cheaper', they may not be 'better'. I would need to run the numbers.
One option might be to change the mechanics of orbital habitats (maybe they become Ark Modules) so that they act as colony ships rather than infrastructure, but with the added ability to contribute to a planetary population while in orbit. In this case, the colonists would be associated with the ship rather than with the planet.
-
That could very well be a good change. With OH use, the size blows up really quickly so I doubt lot of people would prefer them over cryo pods, especially since you don't usually need dozens and dozens of colony ships.
-
That could very well be a good change. With OH use, the size blows up really quickly so I doubt lot of people would prefer them over cryo pods, especially since you don't usually need dozens and dozens of colony ships.
I've run the numbers using a basic space station with 200,000 capacity. Habs are about 70% cheaper than cryogenics, but 10x larger. On that basis, I don't think habs are a realistic alternative to cryo for pure transportation purposes so allowing them to transport colonists would be fine.
The next question is whether to simply make that change - which would lead to the slightly odd situation of a hab having to unload its colonists at the destination so it could then house them, or make the change above and have the colonists contribute to the population for work purposes, while still being associated with the ship. Even though it is a lot more work from a coding perspective, I think the latter works better and would help a lot with 'nomadic' games.
-
That could very well be a good change. With OH use, the size blows up really quickly so I doubt lot of people would prefer them over cryo pods, especially since you don't usually need dozens and dozens of colony ships.
I've run the numbers using a basic space station with 200,000 capacity. Habs are about 70% cheaper than cryogenics, but 10x larger. On that basis, I don't think habs are a realistic alternative to cryo for pure transportation purposes so allowing them to transport colonists would be fine.
The next question is whether to simply make that change - which would lead to the slightly odd situation of a hab having to unload its colonists at the destination so it could then house them, or make the change above and have the colonists contribute to the population for work purposes, while still being associated with the ship. Even though it is a lot more work from a coding perspective, I think the latter works better and would help a lot with 'nomadic' games.
I'm gonna repost my post on the previous page so I hope that isn't too spammy (for all I know you already read this):
Using the ingame cargo system might work. Colony ships carry their colonists as cargo. So you make it so that any ship that is classified as an OH can also carry colonists as cargo. Not only that you can add a new continuous order to a fleet with OHs called "assign to population at body" and then pick the population on that body you want to assign the OH to. Doing this adds the capacity of that OH to the population and adds the "cargo" of colonists to the actual population of that colony.
The main issue is population growth. When the population grows you would want to add cargo of the appropriate species into the cargo "hold" of the OH. But how do you determine how much of the new population goes into the OH and how many are living on the surface? Agriculture % is already based proportionally between the OH capacity and surface population so maybe a proportional approach would be best.
When you decide to move the OH you can issue another new order "unassign from population" or just cancel the existing assignment order. This would remove the OH capacity from the population as well as subtract population equal to the colonists that are in the cargo bay of the OH.
Also, colonists that are of a different species to the species of the assigned population should not be added to the population, though they will still take up OH space. Alternatively, you forbid an OH from housing multiple species outright, it would be helpful to somehow mark in UI what species an OH is carrying (if any).
Loading and unloading colonists would be a bit different. A colony ship with cargo shuttles should be able to choose to either unload onto the assigned population which puts people at the surface or they can directly unload colonists into the orbital habitats.
The final problem I can think of is population growth when the OH is unassigned/in transit. Either disable population growth or have it be a flat rate based on the species growth and empty capacity (like carrying capacity).
Edit: I will add that "assign OH to population" is a very helpful thing even without the consideration for mobile habitats. In multi-species empires it can be very useful to assign a group of habs to a specific population because you want to have lets say 2m human population of "overseers" in orbit while the 2bn NPR aliens you just conquered toil in labour camps OSHA compliant factories.
Would also be good when population gene-modding gets re-implemented or just any situation that warrants multiple populations on one system body.
-
Do people actually build colony ships past the early game? I always just let civilian shipping do its thing.
-
Do people actually build colony ships past the early game? I always just let civilian shipping do its thing.
I usually scrap all my colony ships once my civilian shipping lines have 3-4 colony ships. The only case where one needs state-owned colony ships is to colonize beyond unstable jump points or unsafe star systems.
Micromanagement can be done by adjusting populations' immigration/emigration settings.
That could very well be a good change. With OH use, the size blows up really quickly so I doubt lot of people would prefer them over cryo pods, especially since you don't usually need dozens and dozens of colony ships.
I've run the numbers using a basic space station with 200,000 capacity. Habs are about 70% cheaper than cryogenics, but 10x larger. On that basis, I don't think habs are a realistic alternative to cryo for pure transportation purposes so allowing them to transport colonists would be fine.
The next question is whether to simply make that change - which would lead to the slightly odd situation of a hab having to unload its colonists at the destination so it could then house them, or make the change above and have the colonists contribute to the population for work purposes, while still being associated with the ship. Even though it is a lot more work from a coding perspective, I think the latter works better and would help a lot with 'nomadic' games.
An interesting side effect of the current "colonist transportation habs" discussion is that doing so would enable the creation of gardener ships (https://www.youtube.com/watch?v=p9KjiqFgo_w) - i.e. fully nomadic ships or fleets that only stop to resupply and to lay down new planetary colonies.
-
Do people actually build colony ships past the early game? I always just let civilian shipping do its thing.
I do, because I don't trust civilians to do exactly what I need them to, when I want them to. If I need ten million people on a planet yesterday, I'm not going to wait for the civvie to finish depopulating Mars or whatever.
Of course this especially applies to establishing colonies outside of the stable jump network which is often a necessity. Actually because of this, I would say at a certain point it starts to make more sense to make (new) colony ships jump-capable as this becomes the major use case.
E: Ninja'd by Steve post, the new Arks change is very neat. Steve, can you confirm that this fixes the long-standing complaint about using OrbHabs at planets like Venus? Prior to 2.0, OrbHab populations at Venus, etc. would build surface infrastructure and experience pop growth beyond the habitat capacity, leading to colonists on the surface which tanked the manufacturing efficiency of the entire colony. It sounds like with the new distinction between orbital and surface populations, this can no longer happen? So if we have 10m colonists in habitats at Venus, they will not overflow to the surface and induce significant penalties to manufacturing efficiency.
-
Do people actually build colony ships past the early game? I always just let civilian shipping do its thing.
E: Ninja'd by Steve post, the new Arks change is very neat. Steve, can you confirm that this fixes the long-standing complaint about using OrbHabs at planets like Venus? Prior to 2.0, OrbHab populations at Venus, etc. would build surface infrastructure and experience pop growth beyond the habitat capacity, leading to colonists on the surface which tanked the manufacturing efficiency of the entire colony. It sounds like with the new distinction between orbital and surface populations, this can no longer happen? So if we have 10m colonists in habitats at Venus, they will not overflow to the surface and induce significant penalties to manufacturing efficiency.
Yes, the pops are entirely separate, so there is no movement of population from the Ark modules to the surface.
-
Yes, the pops are entirely separate, so there is no movement of population from the Ark modules to the surface.
This will reduce fair bit of advantage of habitats tho: pop growth
As most will be filled and no gov bonuses apply, any pop on them is basically dead or in very slow growth
Can be an issue
-
Unfortunately, there's no way around that since Arks will not organically grow and there's no option of overcrowding. You got space for 200,000 colonists, you load 200,000 colonists, now you're stuck with 200,000 colonists forever.
I could see loading Ark with only 90% of its capacity if doing a low-pop start so that it can grow - relatively quickly - that remaining 10% but probably won't bother otherwise.
-
Seems like a fun and flavorful change. The only quibble I can think of is it might be better to have population growth use the greater of the planet's growth or the orbital hab growth when in orbit of a colony (potentially dropping surplus pops down on the planet), so having a bunch of people in orbit doesn't reduce your growth if the planet below has plenty of space. But that's a pretty niche difference, and something you can already deal with by micromanaging the balance of the colony and orbital hab populations if you want.
-
Unfortunately, there's no way around that since Arks will not organically grow and there's no option of overcrowding. You got space for 200,000 colonists, you load 200,000 colonists, now you're stuck with 200,000 colonists forever.
I could see loading Ark with only 90% of its capacity if doing a low-pop start so that it can grow - relatively quickly - that remaining 10% but probably won't bother otherwise.
If the pop growth was less linear, we could have a standing order to drop once a year overflowing population on the ground, it is a ship after all.
So let's say you employ 90% of your pop regularly, and once a year drop *calculated yearly pop growth of whole fleet* on the ground.
-
If I understand it correctly, we are not able to make commercial space station that would have repair capability in orbit of gas giant right? That is something we were able to do with commercial hangars.
-
If I understand it correctly, we are not able to make commercial space station that would have repair capability in orbit of gas giant right? That is something we were able to do with commercial hangars.
That's an interesting question - can you create a DSP in orbit of a gas giant? I'm guessing that would cause some sort of conflict in the programming but it would otherwise make sense.
-
Seems like a fun and flavorful change. The only quibble I can think of is it might be better to have population growth use the greater of the planet's growth or the orbital hab growth when in orbit of a colony (potentially dropping surplus pops down on the planet), so having a bunch of people in orbit doesn't reduce your growth if the planet below has plenty of space. But that's a pretty niche difference, and something you can already deal with by micromanaging the balance of the colony and orbital hab populations if you want.
The orbital and surface populations are now separate so it doesn't really make sense for them to influence each others growth, especially as each is subject to different constraints. In pure mechanics terms, having the orbital population separate actually increases the planetary growth because smaller populations grow faster.
-
If I understand it correctly, we are not able to make commercial space station that would have repair capability in orbit of gas giant right? That is something we were able to do with commercial hangars.
That's an interesting question - can you create a DSP in orbit of a gas giant? I'm guessing that would cause some sort of conflict in the programming but it would otherwise make sense.
DSP are not connected to planets. If you create one in the existing location of a gas giant, it will be left behind when the gas giant continues in its orbit.
-
If I understand it correctly, we are not able to make commercial space station that would have repair capability in orbit of gas giant right? That is something we were able to do with commercial hangars.
That's an interesting question - can you create a DSP in orbit of a gas giant? I'm guessing that would cause some sort of conflict in the programming but it would otherwise make sense.
DSP are not connected to planets. If you create one in the existing location of a gas giant, it will be left behind when the gas giant continues in its orbit.
After some thought on this, I've made a change to how DSP work. When creating a Deep Space Population, if you click on a gas giant or superjovian instead of empty space, the DSP will be created in orbit of the gas giant and will move with the planet. I've updated the original post accordingly.
-
If I understand it correctly, we are not able to make commercial space station that would have repair capability in orbit of gas giant right? That is something we were able to do with commercial hangars.
You can now, as I just modified DSP to allow it.
-
I prefer building orbital habs on site to tugging/putting engines on them, and in 1.13 it's possible to do so on bodies with zero population. While I'm very happy to see the change that separates surface and orbital pops, having some order available to unload or transfer colonists from colony ships to ark modules would be greatly appreciated (even if the option isn't available to civilian lines).
-
If I understand it correctly, we are not able to make commercial space station that would have repair capability in orbit of gas giant right? That is something we were able to do with commercial hangars.
You can with the new Repair Bays since they are commercial modules.
-
You can with the new Repair Bays since they are commercial modules.
These require minerals, which you cannot store at a gas giant (well, now you can with the change to DSPs).
-
You can with the new Repair Bays since they are commercial modules.
These require minerals, which you cannot store at a gas giant (well, now you can with the change to DSPs).
Can't you store them in cargo bays? Although ensuring you have the right quantities could be a pain.
-
Doesn't "Deep Space Colony" sound better than "Deep Space Population", considering that they don't necessarily have any actual population?
I assume it's "population", because there can possibly be multiple populations on one colony?
-
STEVE DID YOU JUST ADD GENERATION SHIPS
-
You can with the new Repair Bays since they are commercial modules.
These require minerals, which you cannot store at a gas giant (well, now you can with the change to DSPs).
Can't you store them in cargo bays? Although ensuring you have the right quantities could be a pain.
Minerals for mobile repair yards need to be at colony site or at DSP. It does not work with cargo bays.
-
The orbital and surface populations are now separate so it doesn't really make sense for them to influence each others growth, especially as each is subject to different constraints. In pure mechanics terms, having the orbital population separate actually increases the planetary growth because smaller populations grow faster.
It increases % of pop being grown slightly, but you do so by reducing total number of pop growing, which doesn't increase the final amount, instead lowers it.
Also, given that all people are commuting to work on the world unless you have a shipyard there, makes sense you wouldn't see strict population control on habitat anyone can choose to leave at any time to move to surface and leave a free space for someone with no children to move into.
At least not neutering pop in them would go a long way to make them useful in regular games instead of heavy RP ones.
-
STEVE DID YOU JUST ADD GENERATION SHIPS
Yes, I think I did :)
-
The orbital and surface populations are now separate so it doesn't really make sense for them to influence each others growth, especially as each is subject to different constraints. In pure mechanics terms, having the orbital population separate actually increases the planetary growth because smaller populations grow faster.
It increases % of pop being grown slightly, but you do so by reducing total number of pop growing, which doesn't increase the final amount, instead lowers it.
Also, given that all people are commuting to work on the world unless you have a shipyard there, makes sense you wouldn't see strict population control on habitat anyone can choose to leave at any time to move to surface and leave a free space for someone with no children to move into.
At least not neutering pop in them would go a long way to make them useful in regular games instead of heavy RP ones.
I'm happy with the new growth model. Based on the chat I read on the Discord, I realised that OH were being used to increase growth rates on habitable worlds, rather than for their intended purpose of allowing population on hostile worlds. Creating that 'exploit' was a side-effect of the growth mechanics, so I consider that fixed now, rather than nerfed.
-
Doesn't "Deep Space Colony" sound better than "Deep Space Population", considering that they don't necessarily have any actual population?
I assume it's "population", because there can possibly be multiple populations on one colony?
Yes, Deep Space Colony is another option, although colony itself suggests colonists. I tend to use colony and population interchangeably, but I'm not completely comfortable with either because , as you mentioned above, they don't necessarily have any actual colonists.
You are correct though that only one population can exist at that location.
-
Is there any chance of NPRs making use of DSPs in some limited way or ark ships (not sure if NPRs were already using habitats or not)?
By the way, it's funny how many new things have been added recently that seem useful for a nomadic-style game, while you're currently playing a non-nomadic BSG game. Will there perhaps be a nomadic sequel of the current game, Steve?
Edit:
Another question. Not sure if it's been answered somewhere, but can you mark a DSP (or a normal colony with orbital population) as "source of colonists" like normal colonies and have civilian transport ships take population from the arks to bring them elsewhere?
-
Is there any chance of NPRs making use of DSPs in some limited way or ark ships (not sure if NPRs were already using habitats or not)?
By the way, it's funny how many new things have been added recently that seem useful for a nomadic-style game, while you're currently playing a non-nomadic BSG game. Will there perhaps be a nomadic sequel of the current game, Steve?
Edit:
Another question. Not sure if it's been answered somewhere, but can you mark a DSP (or a normal colony with orbital population) as "source of colonists" like normal colonies and have civilian transport ships take population from the arks to bring them elsewhere?
I am re-watching the 2004 BSG series again at the moment, so maybe that is the inspiration :)
You can't make DSP as a colony source because you can't load from Ark Modules. At some point, I may add the necessary orders to do so, in which case I would change the civilian situation as well.
-
As the population in Ark modules is awake and functional, there will be some population growth if there is space capacity. This growth will be at an annual rate of 5% x (Space Available / Total Capacity). For example, if an Ark Ship is only carrying 75% of capacity, the annual pop growth will be 1.25%. Available space is likely to be a rare situation, but it could happen after damage and repair, or if an Ark loads a surface population less than its capacity.
Wouldn't it make more sense to also incorporate the species population growth modifier into this calculation?
Also how would an ark handle multiple species being transported, is that even legal?
Finally, how will the game handle the deletion of a DSP, if even possible?
Edit: It would also be nice to be able to manually assign Arks to a specific population, as in a multi-species empire you can end up with worlds with multiple populations.
-
As the population in Ark modules is awake and functional, there will be some population growth if there is space capacity. This growth will be at an annual rate of 5% x (Space Available / Total Capacity). For example, if an Ark Ship is only carrying 75% of capacity, the annual pop growth will be 1.25%. Available space is likely to be a rare situation, but it could happen after damage and repair, or if an Ark loads a surface population less than its capacity.
Wouldn't it make more sense to also incorporate the species population growth modifier into this calculation?
Also how would an ark handle multiple species being transported, is that even legal?
Finally, how will the game handle the deletion of a DSP, if even possible?
Edit: It would also be nice to be able to manually assign Arks to a specific population, as in a multi-species empire you can end up with worlds with multiple populations.
The species growth modifier is included. I didn't mention it in the post. Ark can only carry one species, but multiple Arks at the same colony can have different species.
Deletion of a DSP is just like a normal pop deletion - anything in orbit will remain in deep space, but without pop assignment.
Just tell an Ark to move to a specific pop and it will be assigned to that pop.
-
I can't help it, but the new "Ark module" rules let me think about a (much) smaller POW-module to make POW-camps/ships...
-
Ark Modules have built-in life support and do not need any agricultural/environmental population (as is the case now with orbital habitats). Therefore, the orbital population does not have to be the same species as the surface population and multiple different species can contribute from orbit.
Given that someone needs to run the life support, I think it would make more sense to have a fixed percentage for ag/env workers. Alternatively you could increase the crew requirement for the module. At the moment all 200000 colonists are serviced by 30 crew. Or you could increase the cost to represent automation like automines (although this prompts the question of why this isn't possible with ground population).
If a colony is conquered, the population in the Ark Modules will not be affected, unless the Ark itself surrenders. The Ark will be unassigned from the conquered colony. The same is true for colony transfers
Given Arks populations are separate for the purpose of planetary surrender, are they treated differently for the purpose of system claims?
On the one hand they could be doing valuable work, but on the other hand they can be relatively easily moved.
A few more questions:
Can you have troop modules on Ark Modules to help them if boarded?
How quickly can Ark Modules load population?
-
Can you have troop modules on Ark Modules to help them if boarded?
You can already do this so I don't see why Steve would change it.
-
Just tell an Ark to move to a specific pop and it will be assigned to that pop.
I completely forgot you could do that.
D'oh!
-
Can you have troop modules on Ark Modules to help them if boarded?
You can already do this so I don't see why Steve would change it.
That's cool, so you could also carry the garrison around in the arks. Though I'm guessing NPRs will prefer to nuke Arks instead of invading them outright with boarding pods.
-
Can you have troop modules on Ark Modules to help them if boarded?
You can already do this so I don't see why Steve would change it.
That's cool, so you could also carry the garrison around in the arks. Though I'm guessing NPRs will prefer to nuke Arks instead of invading them outright with boarding pods.
Currently crew get treated as a ground–combat formation during boarding, but what about civilians? What level of militancy is required before everyone is carrying a sidearm all of the time, just in case?
-
What level of militancy is required before everyone is carrying a sidearm all of the time, just in case?
flag0001.jpg
(https://c.tenor.com/vDkdq4-6CSkAAAAM/freedom-america.gif)
-
Can you have troop modules on Ark Modules to help them if boarded?
You can already do this so I don't see why Steve would change it.
That's cool, so you could also carry the garrison around in the arks. Though I'm guessing NPRs will prefer to nuke Arks instead of invading them outright with boarding pods.
Currently crew get treated as a ground–combat formation during boarding, but what about civilians? What level of militancy is required before everyone is carrying a sidearm all of the time, just in case?
Given the size of an Ark, it doesn't seem unreasonable for an all-frills version to include a small garrison of say 1 to 5kT troops.
The new spoilers might make it a necessity.
However Steve seems to want to avoid Arks interacting with the morale system and by extension the ground military. So I thought he might restrict troop presence by blocking troop bays.
I'm not sure if instantly stealing 200k population by capturing a stationary ship with ~30 crew is the sort of thing he intends to be possible, or if he's ok with it to minimise the number of systems which interact with Arks and DSPs.
-
I'm not sure if instantly stealing 200k population by capturing a stationary ship with ~30 crew is the sort of thing he intends to be possible, or if he's ok with it to minimise the number of systems which interact with Arks and DSPs.
Could be interesting with the new spoiler race. But I believe as far as normal NPRs go, they do not use boarding, so this will be issue only in games where player control several races. And I am not even sure if NPRs will use new habitats? I don't think they are programmed to do use habitats in current version.
-
Given the size of an Ark, it doesn't seem unreasonable for an all-frills version to include a small garrison of say 1 to 5kT troops.
The new spoilers might make it a necessity.
However Steve seems to want to avoid Arks interacting with the morale system and by extension the ground military. So I thought he might restrict troop presence by blocking troop bays.
I'm not sure if instantly stealing 200k population by capturing a stationary ship with ~30 crew is the sort of thing he intends to be possible, or if he's ok with it to minimise the number of systems which interact with Arks and DSPs.
Isn't that rather an issue with an Ark having room for 200 000 population only requring a crew of ~30 if that should be the case though? ( Which is fair to assume if it wasn't change from Orbital Habitats ).
I wouldn't have any issues with Ark modules requiring a substantial higher amounts of crew to keep all systems running, which would make them also interact a bit more realistically in boarding automatically.
One crew for every ~7000 inhabitants in the Orbital Hab/Ark seems very... optimistic :)
-
Isn't that rather an issue with an Ark having room for 200 000 population only requring a crew of ~30 if that should be the case though? ( Which is fair to assume if it wasn't change from Orbital Habitats ).
[...]
One crew for every ~7000 inhabitants in the Orbital Hab/Ark seems very... optimistic :)
They might be functioning like those Japanese robot hotels, and have a 2001 Space Odyssey AI overseeing that everyone only ever watches romance novellas.
Very excited about the Ark introduction here. Back when I started in VB6, I used to think and fail at that Orbital Habitats didn't work exactly the way that the Ark Modules seem to be doing soon.(I shipped them to research places, expecting 7m colonists to get to work...)
Too bad my next game planned wanted a setting where this is not center, but maybe I must postpone.
-
Given Arks populations are separate for the purpose of planetary surrender, are they treated differently for the purpose of system claims?
On the one hand they could be doing valuable work, but on the other hand they can be relatively easily moved.
A few more questions:
Can you have troop modules on Ark Modules to help them if boarded?
How quickly can Ark Modules load population?
Ark populations are included in system claims.
Arks are just a module, like cryogenic transports, so all normal ship rules apply. You can add troop bays to the same ship, and loading is done just like loading a colony ship with the same capacity, so it will depend on cargo shuttles bays.
-
I wouldn't have any issues with Ark modules requiring a substantial higher amounts of crew to keep all systems running, which would make them also interact a bit more realistically in boarding automatically.
One crew for every ~7000 inhabitants in the Orbital Hab/Ark seems very... optimistic :)
200k people is a pretty substantial city. They’re going to need to have a government with bureaucrats and police officers and everything, but none of those people actually need to be crew members. In fact, if your habitat is big enough you don’t need any crew at all.
-
Cool addition! Can't wait to do a space bar in the middle of nowhere for my next space pirates campaign. It's really cool that these can also be used to dump off minerals from wreck salvagers in systems with little suitable bodies. Can you use these to disassemble or scrap components from the population menu?
-
They might be functioning like those Japanese robot hotels, and have a 2001 Space Odyssey AI overseeing that everyone only ever watches romance novellas.
If they were Automated by AI why can't AI automate other ship systems to the same degree?
And tbh I think Arks are alot closer to proper living spaces rather than the "Japanese robot hotel" like Cryo Storages of colony ships...
200k people is a pretty substantial city. They’re going to need to have a government with bureaucrats and police officers and everything, but none of those people actually need to be crew members. In fact, if your habitat is big enough you don’t need any crew at all.
That's not the way I see things. The way I see things "crew" in this case would represent anything needed to keep the "ship"or "station" providing enough space for 200 thousand people in running order pretty much indefinately.
Basically if a cargo ship or other functioning station would provide the same physical space + power and life support as such a "ship" would need... How much crew would be needed for that? Alot more than 30 is IMHO!
-
Can you use these to disassemble or scrap components from the population menu?
Almost certainly not, because the population window can only interact with components at the population, which I don't think can include components loaded on ships. The only way this would work is if you can unload the components at a DSP which I don't think is currently what Steve has implemented.
-
Are Deep Space Populations able to be tugged? Can they also be moved in orbit?
-
I like the Arks for the ability to make JP anchorages. I can now "populate" JPs and have an actual base of operations there with all of the associated shenanigans a JP population will bring.
That and solar colonies on empty systems.
-
Are Deep Space Populations able to be tugged? Can they also be moved in orbit?
I would assume no, since they are basically just coordinates in space. It sounds like the only DSPs that can orbit are the ones on gas giants, which are probably more like a normal colony, except on a gas giant.
Edit:
I like the Arks for the ability to make JP anchorages. I can now "populate" JPs and have an actual base of operations there with all of the associated shenanigans a JP population will bring.
I wonder, will it actually be possible to have a DSP be on the exact location of a JP, or would it be impossible to have them on the same spot and the DSP would always end up at least like X meters next to it, depending on the precision of your click?
-
Edit:
I like the Arks for the ability to make JP anchorages. I can now "populate" JPs and have an actual base of operations there with all of the associated shenanigans a JP population will bring.
I wonder, will it actually be possible to have a DSP be on the exact location of a JP, or would it be impossible to have them on the same spot and the DSP would always end up at least like X meters next to it, depending on the precision of your click?
I think you can get exact. You can zoom in so close that the scale shown on the top (right?) corner of the screen will show 0 km as the map scale and place a waypoint on it, and DSPs are just another type of waypoint.
I used this with stars to make what I called "solar hyperspace gates", massive (and expensive) megastructures that I would place right "on top" of a star that I would RP as being able to teleport my fleets between them.
-
But even if you place the DSP directly on the jump point, I assume that the DSP and the jump point will still be two separate things. So for example, you probably wouldn't be able to tell a ship to move to the JP and refuel from the tanker that's stationed on the DSP. You'd have to move to the DSP, refuel, then move to the JP and transit, for example.
What I was wondering was if it's possible to have the DSP be on exactly the same spot as the JP, so that a movement order to the JP would have your ship also be at the DSP. The same way to how it probably will be with DSPs on gas giants.
-
But even if you place the DSP directly on the jump point, I assume that the DSP and the jump point will still be two separate things. So for example, you probably wouldn't be able to tell a ship to move to the JP and refuel from the tanker that's stationed on the DSP. You'd have to move to the DSP, refuel, then move to the JP and transit, for example.
This is really a moot point, since to give the refuel order you'd have to order the fleet to move to the tanker anyways.
-
200k people is a pretty substantial city. They’re going to need to have a government with bureaucrats and police officers and everything, but none of those people actually need to be crew members. In fact, if your habitat is big enough you don’t need any crew at all.
well, in the case of a orbital habitat, "crew" is more like "dedicated maintenance personnel"
-
200k people is a pretty substantial city. They’re going to need to have a government with bureaucrats and police officers and everything, but none of those people actually need to be crew members. In fact, if your habitat is big enough you don’t need any crew at all.
well, in the case of a orbital habitat, "crew" is more like "dedicated maintenance personnel"
There's no support staff from population, because there is a fixed 0% agri/env workers.
An orbital habitat has the population of (pick one you're familiar with:) https://en.wikipedia.org/wiki/List_of_United_States_cities_by_population
It's about the population of Samoa, a bit more than Guam or the Isle of White, roughly twice the population of Reykjavik or the Isle of Mann.
The Isle of Man Constabulary has 200 officers, to say nothing of the coast guard, fire fighters etc.
-
I agree that an ark module's crew requirements should emulate the base 5% agri/env requirement in terms of crew. Even if crew =/= population and also the conscript option allows you to effectively create "new" crew. It would also be a decent approximation of the civilian population fighting back against invaders/boarders.
-
I agree that an ark module's crew requirements should emulate the base 5% agri/env requirement in terms of crew. Even if crew =/= population and also the conscript option allows you to effectively create "new" crew. It would also be a decent approximation of the civilian population fighting back against invaders/boarders.
It's interesting that this is coming up based on a name change, when the rules for the Ark Module are exactly the same as the Orbital Habitat, and they have been around for many years.
-
Lol
-
I would guess that as a relatively niche feature, it was simply not in the focus for most people. Now when it is getting changed, people think more about it and share their opinion on the feature.
-
Are Deep Space Populations able to be tugged? Can they also be moved in orbit?
A Deep Space Population is not an object, it is a place very like a waypoint. Ships can go to the DSP and hang out there. They can be towed to or from a DSP. Any ship that is hanging out at a DSP might have population aboard, living in Ark Modules/Orbital Habitat modules. The most interesting change is that population living in an Ark Module is not left behind when the ship moves or is towed.
So you can tow a ship (or a station) containing population, but you can’t tow the Deep Space Population itself.
-
It's interesting that this is coming up based on a name change, when the rules for the Ark Module are exactly the same as the Orbital Habitat, and they have been around for many years.
Yeah perception is important!
I think it's mainly because an "orbital habitat" is associated with Sci Fi stories like a floating/orbiting city which can be associated with ground populations or infrastructure on a planet, while an "Ark" is more associated with the generation ship stories that are assumed to travel for excessively long times without outside support.
IMO though I felt that orbital habitats were too cheap/easy to put into place before. If you ask me I think it should be more expensive than infrastructure to use orbital habitats/arks for example for the Jovian Moons ( with colony costs of around 6-8 ) but cheaper for Venus.
-
It's interesting that this is coming up based on a name change, when the rules for the Ark Module are exactly the same as the Orbital Habitat, and they have been around for many years.
Besides the other points raised in response, I would note that "well AcKsHuLlY..." the matter was raised due to the potential for an enemy to board an Ark Module and capture the population onboard, which has not previously been the case - if an enemy captured an old OrbHab the population would remain grounded and just die off from a lack of 'infrastructure'. The question was whether those 200,000 or so people might not put up a little bit more of a fight when faced with the possibility of forced relocation to an alien gallicite mine. After this we have had the additional comments from the Realism Brigade™ about crew requirement to operate the facility.
Technically this also applies to the luxury passenger module, but no one actually uses that for transporting colonists so it hasn't really come up before.
IMO though I felt that orbital habitats were too cheap/easy to put into place before. If you ask me I think it should be more expensive than infrastructure to use orbital habitats/arks for example for the Jovian Moons ( with colony costs of around 6-8 ) but cheaper for Venus.
I think it is a good balance point where it is. Currently, OrbHabs match the efficiency of regular infrastructure for a colony cost between 5.0 and 6.0 (http://aurora2.pentarch.org/index.php?topic=8495.msg106761#msg106761), and there's good reasons to consider both options for a range of CCs on either side of that breakpoint. For example, for colonizing Jovian moons OrbHabs/Arks may be nominally cheaper but would require a tug to get into place while infrastructure can be shifted by a robust civilian shipping sector for just a few spacebucks.
This is similar to how the changes to Ark Modules make them cost-effective modes of colonist transport but in practice not always easy to use due to large size, so that more expensive colony ships will likely remain the most time-efficient mode of transport for at least a good portion of the game. In the late game this may change but that is fine as a big part of the tech tree design in Aurora is how different technologies come into their own at different times during the game.
-
I agree that an ark module's crew requirements should emulate the base 5% agri/env requirement in terms of crew. Even if crew =/= population and also the conscript option allows you to effectively create "new" crew. It would also be a decent approximation of the civilian population fighting back against invaders/boarders.
It's interesting that this is coming up based on a name change, when the rules for the Ark Module are exactly the same as the Orbital Habitat, and they have been around for many years.
It's also because thanks to DSPs OH/Arks are also going to act like planets in a way, being able to independently support population so it makes sense that they should behave more consistently in certain regards.
It's something I always found weird because you can currently use OHs to actually reduce the env/agri % of a planet proportionally. I've got worlds with 6bn ppl and 2bn orbitals that have like 3-4% agri because for some reason orbital habitats just make it even easier to live on an already habitable planet.
I just haven't vocalized this before because it wasn't a thing being actively looked at and changed.
-
Very cool! :D
I like the Arks for the ability to make JP anchorages. I can now "populate" JPs and have an actual base of operations there with all of the associated shenanigans a JP population will bring.
That and solar colonies on empty systems.
I love the Deep Space 9 vibes here. Star Trek roleplay stuff also benefits from this. The Galaxy-class literally is a moving city with a large civilian accompaniment, and being able to spice your setting up with things like this and misc components is pretty neat! And roleplay aside, I think there's also a meaningful choice here with orbital habitats now functioning as much cheaper but more logistically challenging colony ships, along with the flexibility they entail. The possibility of mobile fleet bases opens up some pretty serious strategic and operational decisions.
-
Technically this also applies to the luxury passenger module, but no one actually uses that for transporting colonists so it hasn't really come up before.
A-hem, I do use them! Only in my latest game and only for few ships for RP purposes... BUT STILL! 8)
IMO though I felt that orbital habitats were too cheap/easy to put into place before. If you ask me I think it should be more expensive than infrastructure to use orbital habitats/arks for example for the Jovian Moons ( with colony costs of around 6-8 ) but cheaper for Venus.
I think it is a good balance point where it is. Currently, OrbHabs match the efficiency of regular infrastructure for a colony cost between 5.0 and 6.0 (http://aurora2.pentarch.org/index.php?topic=8495.msg106761#msg106761), and there's good reasons to consider both options for a range of CCs on either side of that breakpoint. For example, for colonizing Jovian moons OrbHabs/Arks may be nominally cheaper but would require a tug to get into place while infrastructure can be shifted by a robust civilian shipping sector for just a few spacebucks.
This is similar to how the changes to Ark Modules make them cost-effective modes of colonist transport but in practice not always easy to use due to large size, so that more expensive colony ships will likely remain the most time-efficient mode of transport for at least a good portion of the game. In the late game this may change but that is fine as a big part of the tech tree design in Aurora is how different technologies come into their own at different times during the game.
Yeah, there is no need to touch OH/ARK cost for now, at least.
-
If you wanted to minmax I suppose you would always keep ark modules less than full to benefit from the growth there.
-
If you wanted to minmax I suppose you would always keep ark modules less than full to benefit from the growth there.
Depends on the situation.
If the surface has a low to mid CC, and there is room, sure you could periodically unload from the arks.
If the surface has a high CC (venusian/frozen), it seems to me a better choice to just let the arks be full rather than drop population on the surface and wreck the available workforce.
If the surface isn't habitable (high grav/DSP), the only way to get pop off the ark is to move it somewhere else. If your needs for pop growth justify this, you may have too many arks.
So from my point of view, the more desirable it is to have an orbital population at a colony in the first place, the less desirable it is to unload them.
-
Since we do have generation/ark ships now, could we have survival pods that last longer than 14 days? I always preferred to be able to generate survival pods depending on playstyle / race behaviour. Klingons of course would not add survival pods at all, but the Federation would create one that would last one person for 20 years... . Ok, kidding aside, depending on the level of deep space operations it would be a nice flavour add if we could design survival pods that last for a specified duration of time (and would of course be bigger, depending on how much food etc. you would add to that module. Also if you have a pod designed for 200 survivors and only have 100 it should last double the time... . Also being able to specify how much pod capacity a ship has would become part of the ship design (yes, thinking Titanic here...).
-
Since we do have generation/ark ships now, could we have survival pods that last longer than 14 days? I always preferred to be able to generate survival pods depending on playstyle / race behaviour. Klingons of course would not add survival pods at all, but the Federation would create one that would last one person for 20 years... . Ok, kidding aside, depending on the level of deep space operations it would be a nice flavour add if we could design survival pods that last for a specified duration of time (and would of course be bigger, depending on how much food etc. you would add to that module. Also if you have a pod designed for 200 survivors and only have 100 it should last double the time... . Also being able to specify how much pod capacity a ship has would become part of the ship design (yes, thinking Titanic here...).
I would like that. In the past I have sometimes created 200-250t personalized life pods for larger ships that had emergency cryo pods on them and enough fuel/ low power engines to tow the survivors back to port on their own over very long time.
It would be kind of atmospheric to have survival pod capacity/quality part of the design in some way. Maybe instead of costing tonnage though which is currently well balanced, they could just incur cost on the efficiency of the crew quarter. So to get the current state of 14 lifepods, the crew quarters are just as effective as they are now, but if you want 60 days, maybe they lose 25% capacity or something, and on the other side you might get another +5%(?) by completely omitting them.(perhaps also a crew quality penalty from morale though? but seems too complex)
-
I have a question. Does making a deep space population on a point, asteroid or etc make it viable to have space stations now? Like not having to worry about time on space, maintenance and etc?
-
I have a question. Does making a deep space population on a point, asteroid or etc make it viable to have space stations now? Like not having to worry about time on space, maintenance and etc?
You can't put a DSP on an asteroid. You would just create a normal pop on an asteroid. Space stations work the same at DSP as they do at normal pops.
Space stations are already viable in 1.13. I use them all the time.
-
I have a question. Does making a deep space population on a point, asteroid or etc make it viable to have space stations now? Like not having to worry about time on space, maintenance and etc?
You know you can make (civilian) space stations by checking the "no armor" box, right?
If you mean military space stations, you can use stuff like maintenance and recreational modules.
-
Hull Numbers
v2.0 adds hull numbers for each ship. These are appended to the hull designation for each ship for display and reporting purposes. For example, the sixteenth destroyer built by a race will be designated as DD-16.
This designation is not affected by class. If the last destroyer of the Tribal class is DD-25, the first ship of the subsequent class with the same hull type will be DD-26.
An option on the Miscellaneous sub-tab of the Ship Overview tab on the Naval Organization window allows you to specify a hull number for a ship, as long as that hull number is not already in use. If you specify a number higher than any existing hull number for that hull type, new ships with the same hull type will increment hull numbers from that point onwards.
An option on the 'Ships in Class' tab of the Ship Class window allows you to reset the hull numbers of all ships with the same hull type. This is done in order of original creation.
There is a display flag on the Tactical Map display options to disable the display of hull numbers for a given race. The difference in display is simply DDG-51 Arleigh Burke vs DDG Arleigh Burke. This display flag applies to all uses of the hull number throughout the game - not just on the tactical map.
There is a display flag on the Miscellaneous tab of the Ship Class window that allows you to toggle hull number display for a specific class. For example, you may not want hull numbers for fighters. The hull numbers are still created for this class, but are not displayed if the toggle is off.
Just saw that, thanks Steve!
Though now I have questions: what happens when you refit the ship into a different hull type? Or, say, you redesignate the class into another hull type (something I do with worrying regularity)? Are the corresponding ships renumbered into the new hull type? That's what I would expect.
-
Do I assume correctly, that population in ark modules are not affected by any environmental malus of the planet they are stationed at? So technically I could create an empty colony on a fully radiated body, build industry and production there and populate them with ark ships - without any problems to the population whatsoever?
What happens if I do have population on the planet as well as in orbit and the planet gets bombarded and suffers radiation. Would the planet population be evacuated to the limits of the ark ships or would they stay on the body - and die?
-
Do I assume correctly, that population in ark modules are not affected by any environmental malus of the planet they are stationed at? So technically I could create an empty colony on a fully radiated body, build industry and production there and populate them with ark ships - without any problems to the population whatsoever?
You can literally have ark population live normally in the middle of space using the new deep space colony feature. They are basically the habitats of the current version, so the planet's environment shouldn't affect it.
I dunno about emergency evacuation, but I assume you can probably manually tell your ark ship to load up population, however it sounds like your arks will probably be full most of the time anyway.
-
Do I assume correctly, that population in ark modules are not affected by any environmental malus of the planet they are stationed at? So technically I could create an empty colony on a fully radiated body, build industry and production there and populate them with ark ships - without any problems to the population whatsoever?
You can literally have ark population live normally in the middle of space using the new deep space colony feature. They are basically the habitats of the current version, so the planet's environment shouldn't affect it.
But I thought there were certain penalties. It has been awhile since I've played as I'm waiting for 2.0, but if I recall there were significant penalties to populations that were forced to work on planets with hostile environments. They may live in the orbital habs, but they still need to go down to the surface to work in those factories. This was the draw and incentive to using more expensive automated factories. They don't require worker boots on the ground so the harmful effects of the environment are not associated with the population when using automated industry.
-
But I thought there were certain penalties. It has been awhile since I've played as I'm waiting for 2.0, but if I recall there were significant penalties to populations that were forced to work on planets with hostile environments. They may live in the orbital habs, but they still need to go down to the surface to work in those factories. This was the draw and incentive to using more expensive automated factories. They don't require worker boots on the ground so the harmful effects of the environment are not associated with the population when using automated industry.
There are not programmed-in penalties to OrbHabs in C#. However, what happens in practice is that the population contained by the OrbHabs will (prior to 2.0) function as an extension of the population on the planet surface even if there is not any. Notably, this means they will slowly build infrastructure and experience population growth, and as the population grows is spills out from the OrbHabs to the planet surface where it is affected by the colony cost. This doesn't make OrbHabs unusable but it does degrade their effectiveness and demand a lot of annoying micromanagement to keep the spillover population from growing too large and crippling the colony at a planet like Venus for example. This effect results purely from the population mechanics and the fact that OrbHabs are basically just implemented as special infrastructure prior to 2.0, so I do not think any malus was intended as part of the game design.
With the 2.0 change to Arks this will no longer happen and orbital populations will be fully efficient, making them a viable option for CC>=5.0 or so worlds. Automated mines and other facilities will still have important uses, particularly in the mid to late game when population is a bigger bottleneck than industrial capacity.
-
Depending on playtest, I may also add load/unload colonist orders that have an Ark ship as a target, although I suspect this would be seldom used in practice.
I actually think this would be really great. I haven't used orbital habitats much, but when I did, the goal was usually to get the colony to the point, where they would build their own massive space stations with orbital habitats to enable expansion - both in terms of natural growth and migration. As it is, it probably won't be much trouble to load the colonists from the surface of the planet, but it would be much easier to unload them directly into the Ark modules.
-
--- If I place one of the new Small Craft Re-Fueling Systems on a Tanker alongside a regular Re-Fueling System, will that allow said Tanker to re-fuel small craft AND regular craft at the same time?
-
--- If I place one of the new Small Craft Re-Fueling Systems on a Tanker alongside a regular Re-Fueling System, will that allow said Tanker to re-fuel small craft AND regular craft at the same time?
Not feasible, I think (http://aurora2.pentarch.org/index.php?topic=12523.msg158379#msg158379):
It can only be mounted on ships of 1000 tons or less...
...
Fleets with ships larger than 1000 tons will ignore tankers equipped with the Small Refuelling System.
-
--- If I place one of the new Small Craft Re-Fueling Systems on a Tanker alongside a regular Re-Fueling System, will that allow said Tanker to re-fuel small craft AND regular craft at the same time?
Not feasible, I think (http://aurora2.pentarch.org/index.php?topic=12523.msg158379#msg158379):
It can only be mounted on ships of 1000 tons or less...
...
Fleets with ships larger than 1000 tons will ignore tankers equipped with the Small Refuelling System.
Related to that, if I have *two* regular Refuelling Systems on a single tanker, can it refuel two ships simultaneously? There's no restriction on their number so I'm wondering...
-
--- If I place one of the new Small Craft Re-Fueling Systems on a Tanker alongside a regular Re-Fueling System, will that allow said Tanker to re-fuel small craft AND regular craft at the same time?
Not feasible, I think (http://aurora2.pentarch.org/index.php?topic=12523.msg158379#msg158379):
It can only be mounted on ships of 1000 tons or less...
...
Fleets with ships larger than 1000 tons will ignore tankers equipped with the Small Refuelling System.
Related to that, if I have *two* regular Refuelling Systems on a single tanker, can it refuel two ships simultaneously? There's no restriction on their number so I'm wondering...
http://aurora2.pentarch.org/index.php?topic=8495.msg97525#msg97525
A Refuelling System is 500 tons and has a cost ranging from 10 BP to 100 BP, depending on the tech level. A ship with a Refuelling System can refuel a single ship at once, so will take some time to refuel a whole fleet, although this will improve with higher technology. At the early tech levels, the Refuelling System can only be used if both ships (tanker and target ship) are both stationary. Another new tech line, Underway Replenishment, allow the refuelling to take place while both ships are in the same fleet and underway. Priorities can be set for the refuelling order when multiple ships are involved. The first Underway Replenishment tech allows refuelling at 20% of the normal rate (2500 RP), rising to 100% with the highest tech (40,000 RP).
If you want to refuel several ships at once, you need refueling hub, which is much bigger component.
Spaceports, Refuelling Stations or Refuelling Hubs will always use the highest tech refuelling rate and can refuel an unlimited number of ships simultaneously. However, the ships being refuelled must be stationary.
-
I have a question. Does making a deep space population on a point, asteroid or etc make it viable to have space stations now? Like not having to worry about time on space, maintenance and etc?
You know you can make (civilian) space stations by checking the "no armor" box, right?
If you mean military space stations, you can use stuff like maintenance and recreational modules.
Yeah, i meant military space stations and i've heard something about that it would need population and that the recreational modules wouldnt work, so i got confused.
So lets say i make a military space station and i put a recreational module and a maintenance module, cargo shuttles, etc, would that be able to work indefinitely?
-
So lets say i make a military space station and i put a recreational module and a maintenance module, cargo shuttles, etc, would that be able to work indefinitely?
To clarify, what you want to do is create one or more commercial stations with the desired recreational module, maintenance module, etc. (I suggest keeping each type of station separate so it is easy to build up a deep space base to the desired specifications). You can then deploy military stations, or ships for that matter, which would be maintained by the facilities you have constructed. Keep in mind that maintenance modules require a source of MSP to function so you will need to periodically ship supplies to the base to keep it stocked up.
-
One Second Sub Pulses
Ahem
GOD BE PRAISED!!!
That is all.
-
Small question on 1 second sub-pulses: Will it be possible for the game to interrupt, say due to firing a weapon, on one of the 1 second sub-pulses?
-
Small question on 1 second sub-pulses: Will it be possible for the game to interrupt, say due to firing a weapon, on one of the 1 second sub-pulses?
Sounds like no to me:
A 5 second increment will only be interrupted at the end of the increment, not after one of the sub-pulses.
-
Doy. I need to work on my reading skills, apparently. Good to know!
-
I'd have to run numbers but it sounds like this could also be a useful change in some edge cases involving missile interception? I remember in some early games trying to defend against a certain NPR's missiles with AMMs that were slower than the incoming ASMs, which frequently led the AMMs to be passed by the ASMs without being able to intercept them. Would 1-second pulses reduce the odds of this happening or would there be no real effect?
-
For v2.0, increments of 5 seconds will run with 1-second sub-pulses.
Out here just rewriting the laws of physics.
-
I'd have to run numbers but it sounds like this could also be a useful change in some edge cases involving missile interception? I remember in some early games trying to defend against a certain NPR's missiles with AMMs that were slower than the incoming ASMs, which frequently led the AMMs to be passed by the ASMs without being able to intercept them. Would 1-second pulses reduce the odds of this happening or would there be no real effect?
I believe so - at least there will now be a chance of interception as long as the faster missiles do not by pass the slower missiles entirely in one second. If they are that much faster, then the slower missiles probably have 0% chance to hit anyway.
This will really help with tactically complex fights, that's for sure. Beam slugfests will not really be impacted but weaving in and out of range will be lot smoother!
-
But I thought there were certain penalties. It has been awhile since I've played as I'm waiting for 2.0, but if I recall there were significant penalties to populations that were forced to work on planets with hostile environments. They may live in the orbital habs, but they still need to go down to the surface to work in those factories. This was the draw and incentive to using more expensive automated factories. They don't require worker boots on the ground so the harmful effects of the environment are not associated with the population when using automated industry.
There are not programmed-in penalties to OrbHabs in C#. However, what happens in practice is that the population contained by the OrbHabs will (prior to 2.0) function as an extension of the population on the planet surface even if there is not any. Notably, this means they will slowly build infrastructure and experience population growth, and as the population grows is spills out from the OrbHabs to the planet surface where it is affected by the colony cost. This doesn't make OrbHabs unusable but it does degrade their effectiveness and demand a lot of annoying micromanagement to keep the spillover population from growing too large and crippling the colony at a planet like Venus for example. This effect results purely from the population mechanics and the fact that OrbHabs are basically just implemented as special infrastructure prior to 2.0, so I do not think any malus was intended as part of the game design.
With the 2.0 change to Arks this will no longer happen and orbital populations will be fully efficient, making them a viable option for CC>=5.0 or so worlds. Automated mines and other facilities will still have important uses, particularly in the mid to late game when population is a bigger bottleneck than industrial capacity.
You basically express, what I am a bit worried about - just build enough arks, put them on a high cc colony and be good with it. I don't know if the production costs will be exorbitant if you do so - but better think about this before. It's a nice feature, i.e. I am not against it - but it should come at an adequate amount of costs.
-
You still have to tug them where you want them or alternatively train a lot of CON formations and move them around constructing OH/Arks out of local minerals. That's going to cost fuel and time and effort. I don't doubt that some players will do that to mine high CC planets with good minerals through cheaper manned mines than auto-mines but they will have to pay the cost for that, it's just a different cost!
-
You basically express, what I am a bit worried about - just build enough arks, put them on a high cc colony and be good with it. I don't know if the production costs will be exorbitant if you do so - but better think about this before. It's a nice feature, i.e. I am not against it - but it should come at an adequate amount of costs.
Earlier we did a quick cost analysis, and Arks are only more efficient than infrastructure for a colony cost of 5-6 or more, and there is some flexibility within that range. Since CC5 is the point where infrastructure-based colonization reaches hard caps on manufacturing population this is pretty reasonable.
The bigger concern is that this might make automines less useful, but I doubt this will be the case in practice. In the early game, you will need to research, build, and deploy (i.e., use tugs - more research, building, etc.!) Arks so there will be a window in which automines remain necessary unless you rush Ark tech in advance. In the mid to late game, population is a bigger bottleneck than production so automines remain an important way to expand your mining capacity beyond what your populations can support. Overall I think the various costs and benefits will be fairly well-balanced, at least in the Aurora sense of "balance" as I am sure someone can calculate the theoretically optimized path and that's very nice for them if so.
-
Is it possible that the new 1 second subpulse may make area defense more usable? Shorter ranged weapons tend to not shoot due to missiles flying through in a single increment. I would like to screen my important ships with expendable point defense frigates in forward position.
-
Is it possible that the new 1 second subpulse may make area defense more usable? Shorter ranged weapons tend to not shoot due to missiles flying through in a single increment. I would like to screen my important ships with expendable point defense frigates in forward position.
No, because weapons fire still happens at the 5-second increment, the 1-second sub-pulse is used only to smooth out the movement of fleets during those 5 seconds. If you want to use forward area defense ships, the best tactic remains to use small ships that don't show up on enemy sensors and to equip them with weapons with 5-second ROF and as long of range as you can get - 12cm lasers on FACs are probably ideal for this purpose.
-
Correct me if I am wrong but doesn't that mean it would not really help fighters keep up with ships due to it moving outside range before the fire increment? I expected the ship to try firing its weapon not on cooldown within the subpulse.
-
No, because fleets will move 1/5 as far in a single sub-pulse. An example might help:
Consider a fighter squadron at 10,000 km/s attempting to close with an enemy cruiser at 5,000 km/s. The fighters are armed with 10cm railguns @ 30,000 km range. Suppose the fighters are approaching from the stern of the cruiser and are 35,000 km away, just out of range:
Fig. 1: Situation at the start of a 5-second increment
FTR -----> 35,000 km CA -->
If the fighters and cruiser continue along these trajectories, the fighters will close to 10,000 km range and be able to fire their railguns. If the cruiser has a lower Reaction score than the fighters, that is what will happen.
However, if the cruiser has a higher reaction score, it can evade the fighters. This is because the fighters will try to anticipate the cruiser's movements and move to where it will be, rather than where it is at the start of the increment, thus the fighters will move forwards by 50,000 km in a 5-second pulse, temporarily placing themselves 15,000 km in front of the cruiser.
Fig. 2: Situation partway through a 5-second increment, after the FTR moves but before the CA moves
CA 15,000 km -----> FTR
Due to its superior Reaction score, the cruiser is now able to evade the fighters if it has anticipated this, by moving in the opposite direction (I believe a Follow order with a sufficient minimum distance would do this automatically):
Fig. 3: Situation at the end of a 5-second increment, after the FTR and CA have moved in succession
CA <-- 40,000 km -----> FTR
The cruiser thus remains outside of the fighter maximum weapons range and likely can fire on the fighters with its longer-ranged weapons. This state of affairs would continue indefinitely (or until the FTR are destroyed) unless and until one party to the combat changes their orders, such as the FTR being given a minimum distance criterion or a reduction in speed.
If the minimum sub-pulse is only one second, then this behavior can still happen but the difference in range is only 1/5. The fighters might overshoot the cruiser but by at most 15,000 km which is well within their weapons range.
Now, we can have discussion over whether this 5-second minimum reaction time is "realistic" or not (I think it ultimately is up to the player as every RP setting differs), but in pure gameplay terms it is mostly just an annoyance for the player which requires odd workarounds (closing to point-blank by giving a minimum distance criterion is unintuitive to say the least). With the 1-second subpulse the abstraction of "real-time" combat is maintained even with the necessary concession of discrete time increments to allow computation.
You can see similar behavior in other situations, e.g., in a stern chase while trying to maintain the right sniping range for your own beam weapons to outrange the enemy. In my 1.12 AAR I recount several battles of this sort and maintaining range is always the most challenging aspect. This change to subpulses in 2.0 would make that part of the battle significantly smoother and less annoying.
-
You basically express, what I am a bit worried about - just build enough arks, put them on a high cc colony and be good with it. I don't know if the production costs will be exorbitant if you do so - but better think about this before. It's a nice feature, i.e. I am not against it - but it should come at an adequate amount of costs.
Earlier we did a quick cost analysis, and Arks are only more efficient than infrastructure for a colony cost of 5-6 or more, and there is some flexibility within that range. Since CC5 is the point where infrastructure-based colonization reaches hard caps on manufacturing population this is pretty reasonable.
Ah, good to know, thanks. Yeah, that sounds reasonable. :)
-
Thanks for the explanation nuclearslurpee I think I get it. So the update will make the relative movement of crafts finer but no change to firing logic.
-
With the new squadron feature, is there any chance you might implement the automatic squadron names like in vb?
-
I'm lifting this question from the twelve colonies thread as I think it fits this thread quite well:
Question:
What would happen if a player would try to capture the raider ship by boarding, but before that happen raider ship would transit to their home system. Then the marines take the ship. Can they get back or are they stranded in the raider system?
What interactions could result from this inadvertent intrusion into what should be an inaccessible system?
-
I'm lifting this question from the twelve colonies thread as I think it fits this thread quite well:
Question:
What would happen if a player would try to capture the raider ship by boarding, but before that happen raider ship would transit to their home system. Then the marines take the ship. Can they get back or are they stranded in the raider system?
What interactions could result from this inadvertent intrusion into what should be an inaccessible system?
You probably wouldn't be able to do much without SM there (even with construction equipment, if it even has planets), but unless the system is coded to be impossible to open in system view or instakill any intruders you could have the ship act as a low-thermal spy if you lower engine output and burn away, to give you force asessments before maint failure kills it. Aside from that, not much I can think of.
-
I'm lifting this question from the twelve colonies thread as I think it fits this thread quite well:
Question:
What would happen if a player would try to capture the raider ship by boarding, but before that happen raider ship would transit to their home system. Then the marines take the ship. Can they get back or are they stranded in the raider system?
What interactions could result from this inadvertent intrusion into what should be an inaccessible system?
The Raider home system is just like any other system, except it doesn't have any jump points and you can't link to it via a dormant jump point. If you captured a ship after it returned, you would be in the Raider system and see all the Raider ships currently in that system, but you wouldn't be able to leave. You could attack and cause some havoc, or just monitor traffic in and out if you manage to stay undetected.
-
I'm lifting this question from the twelve colonies thread as I think it fits this thread quite well:
Question:
What would happen if a player would try to capture the raider ship by boarding, but before that happen raider ship would transit to their home system. Then the marines take the ship. Can they get back or are they stranded in the raider system?
What interactions could result from this inadvertent intrusion into what should be an inaccessible system?
The Raider home system is just like any other system, except it doesn't have any jump points and you can't link to it via a dormant jump point. If you captured a ship after it returned, you would be in the Raider system and see all the Raider ships currently in that system, but you wouldn't be able to leave. You could attack and cause some havoc, or just monitor traffic in and out if you manage to stay undetected.
I know that this is not something we should do, but it got me curious. Does it mean you could add jump points to the system with SM mode and link it that way? And then conduct invasion? Would that prevent spawning of new Raiders?
-
I'm lifting this question from the twelve colonies thread as I think it fits this thread quite well:
Question:
What would happen if a player would try to capture the raider ship by boarding, but before that happen raider ship would transit to their home system. Then the marines take the ship. Can they get back or are they stranded in the raider system?
What interactions could result from this inadvertent intrusion into what should be an inaccessible system?
The Raider home system is just like any other system, except it doesn't have any jump points and you can't link to it via a dormant jump point. If you captured a ship after it returned, you would be in the Raider system and see all the Raider ships currently in that system, but you wouldn't be able to leave. You could attack and cause some havoc, or just monitor traffic in and out if you manage to stay undetected.
I know that this is not something we should do, but it got me curious. Does it mean you could add jump points to the system with SM mode and link it that way? And then conduct invasion? Would that prevent spawning of new Raiders?
Theoretically you could invade by creating an SM Link. It wouldn't stop raider production as that is done 'off-map' rather than via shipyards, so I don't have to add exploration, mining, etc. The raiders are simplified in that regard because there isn't expected to be combat in their home system.
-
Maybe that's a cool idea.
Make a mechanic of finding a raider system, wipe them out, and have a few calm years? Then they respawn...
-
Whoa, that's a lot of nice changes!
-
Well, at least ground-based terraforming installations finally getting their side of usefulness...
Water on various worlds also seems nice.
So, good terraforming tweaks.
-
Can the new hostility modifier be a negative number if we want to roleplay as peaceniks?
-
Can the new hostility modifier be a negative number if we want to roleplay as peaceniks?
Yes.
-
Is it possible that racial attributes change over time as a consequence of in game actions? Times of peace and prosperity could make a society more diplomatic and mercantile, while harsher times lead to empires being more militaristic.
-
Understand black holes to be without planets but is there a possibility for asteroids or comets?
-
Is it possible that racial attributes change over time as a consequence of in game actions? Times of peace and prosperity could make a society more diplomatic and mercantile, while harsher times lead to empires being more militaristic.
You can do this yourself by modifying the attributes of your race(s) in response to game events if you want to. I'd rather not see a game mechanic that assumes roleplay here - who's to say that "harsher times" don't make an empire less miltaristic as people don't want to compound their problems with the horrid specter of war, for example?
-
Understand black holes to be without planets but is there a possibility for asteroids or comets?
Or as an addition to the question: Can the possible accompanying stars still have planets, asteroids and the like?
-
Understand black holes to be without planets but is there a possibility for asteroids or comets?
Or as an addition to the question: Can the possible accompanying stars still have planets, asteroids and the like?
Yes, they can. I am considered allowing asteroids around the black hole as well, but haven't decided yet.
-
"ranging in mass from 2.5 solar masses to 10,000 solar masses"
Will the survey location distance scale with black hole mass at the same rate as with solar mass?
Because I find that a system with a very massive star (say, >15) is tantamount to an exploration dead end.
Not because of the survey points required, but because of the distances between survey points.
For a star with mass 17.5, the distance between the inner ring survey locations is ~8.5bkm.
For a star with mass 30, the distance between the inner ring survey locations is ~11bkm.
What kind of distances are we to expect from black holes that can be hundreds of times more massive than these?
And will that be fun? Or will it just be a virtual dead-end system?
-
Just going by wikipedia, there appears to be a black hole in a multiple star system within 1000 ly of us. Would this be added to the known stars list?
https://en.m.wikipedia.org/wiki/V_Puppis
Although apparently here the black hole is not the primary and IDK if that’s possible to handle
-
"ranging in mass from 2.5 solar masses to 10,000 solar masses"
Will the survey location distance scale with black hole mass at the same rate as with solar mass?
Because I find that a system with a very massive star (say, >15) is tantamount to an exploration dead end.
Not because of the survey points required, but because of the distances between survey points.
For a star with mass 17.5, the distance between the inner ring survey locations is ~8.5bkm.
For a star with mass 30, the distance between the inner ring survey locations is ~11bkm.
What kind of distances are we to expect from black holes that can be hundreds of times more massive than these?
And will that be fun? Or will it just be a virtual dead-end system?
It is a valid concern. At the moment, the distance of jump points (and survey locations) is modified by the square root of the primary mass. So a 5 mass star is 2.24x and a 30 mass is 5.48x.
Under the current rules, a 100 mass BH would be 10x and a 1000 mass would be 31x (or about 180 billion kilometres to the outer ring)
This works the other way too, so a 0.5 mass star is 0.71x and a 0.1 mass star is 0.32x.
It would probably be a good idea to reduce this modifier to the cube root, either for all stars or probably just those above one solar mass
Mass / Square Root / Cube Root
5: 2.24 vs 1.71
30: 5.48x vs 3.1x
100: 10 vs 4.64
1000: 31 vs 10
10000: 100 vs 21
I don't have a fundamental objection to some BH being so large they are extremely difficult to survey, because they can still be partially surveyed and still be a source of alien attack. However, I am happy to reduce the impact of the mid-size holes and maybe weight the chances against the really large ones.
-
It would probably be a good idea to reduce this modifier to the cube root, either for all stars or probably just those above one solar mass
Mass / Square Root / Cube Root
5: 2.24 vs 1.71
30: 5.48x vs 3.1x
100: 10 vs 4.64
1000: 31 vs 10
10000: 100 vs 21
If a BH mass is selected from an even distribution from 2.5 to 10000, then changing to cube root still means that ~90% of blackholes will have survey distances greater than what a mass 30 star has now--which is enough to not want to bother with surveying.
It's not really the effort to survey that's the problem, it's that when you find something, it's probably going to be much too far away for any further interaction/exploitation to be desirable. You'll have hundreds of closer systems to explore first.
What if you decouple the survey points multiplier from the distance multiplier, and have the distance multiplier asymptotically approach some maximum?
That way the points required can still get enormous, but the distances to cover aren't so large that the whole enterprise is moot.
-
It would probably be a good idea to reduce this modifier to the cube root, either for all stars or probably just those above one solar mass
Mass / Square Root / Cube Root
5: 2.24 vs 1.71
30: 5.48x vs 3.1x
100: 10 vs 4.64
1000: 31 vs 10
10000: 100 vs 21
If a BH mass is selected from an even distribution from 2.5 to 10000, then changing to cube root still means that ~90% of blackholes will have survey distances greater than what a mass 30 star has now--which is enough to not want to bother with surveying.
It's not really the effort to survey that's the problem, it's that when you find something, it's probably going to be much too far away for any further interaction/exploitation to be desirable. You'll have hundreds of closer systems to explore first.
What if you decouple the survey points multiplier from the distance multiplier, and have the distance multiplier asymptotically approach some maximum?
That way the points required can still get enormous, but the distances to cover aren't so large that the whole enterprise is moot.
Its not an even distribution. Currently the progression is 2.5, 5, 10, 20, 30, 40, 50, 100, 200, 300, 500, 1000, 2000, 3000, 5000, 10000, so about half would be greater than a current 30 mass star.
I've been thinking about having the root factor increase with size, so that it still gets larger but at a decreasing rate. However, maybe the simpler solution is to change to the cube root, but reduce the progression so that only two or three exceed the current 30 mass size.
-
I kind of like the idea that such places are "soft" dead ends - places you turn to only when other avenues of expansion are exhausted, and then you have to pay the price of those distances. Because that makes them truly special circumstances for storytelling purposes. I understand that it's extremely rare for anyone's campaign to go that way but it is still a possibility.
I wouldn't want a BH system to be just a "+5% more difficult to handle but otherwise business as usual" system.
-
"ranging in mass from 2.5 solar masses to 10,000 solar masses"
Will the survey location distance scale with black hole mass at the same rate as with solar mass?
Because I find that a system with a very massive star (say, >15) is tantamount to an exploration dead end.
Not because of the survey points required, but because of the distances between survey points.
For a star with mass 17.5, the distance between the inner ring survey locations is ~8.5bkm.
For a star with mass 30, the distance between the inner ring survey locations is ~11bkm.
What kind of distances are we to expect from black holes that can be hundreds of times more massive than these?
And will that be fun? Or will it just be a virtual dead-end system?
It is a valid concern. At the moment, the distance of jump points (and survey locations) is modified by the square root of the primary mass. So a 5 mass star is 2.24x and a 30 mass is 5.48x.
Under the current rules, a 100 mass BH would be 10x and a 1000 mass would be 31x (or about 180 billion kilometres to the outer ring)
This works the other way too, so a 0.5 mass star is 0.71x and a 0.1 mass star is 0.32x.
It would probably be a good idea to reduce this modifier to the cube root, either for all stars or probably just those above one solar mass
Mass / Square Root / Cube Root
5: 2.24 vs 1.71
30: 5.48x vs 3.1x
100: 10 vs 4.64
1000: 31 vs 10
10000: 100 vs 21
I don't have a fundamental objection to some BH being so large they are extremely difficult to survey, because they can still be partially surveyed and still be a source of alien attack. However, I am happy to reduce the impact of the mid-size holes and maybe weight the chances against the really large ones.
How does this interact with grav survey automation? Will survey ships attempt to survey and run out of fuel or do they have a maximum range like the geo-surveyor order has?
-
I kind of like the idea that such places are "soft" dead ends - places you turn to only when other avenues of expansion are exhausted, and then you have to pay the price of those distances. Because that makes them truly special circumstances for storytelling purposes. I understand that it's extremely rare for anyone's campaign to go that way but it is still a possibility.
I wouldn't want a BH system to be just a "+5% more difficult to handle but otherwise business as usual" system.
I like the idea as well. Love it, actually. But when the distance to cover between survey locations is 10bkm+, it's hardly ever going to be worth exploring the whole system.
It might be worth surveying the nearest three or four to the jump point, but if each location further out adds another 10bkm+, then anything you find is going to be that distant as well.
And at that distance, any new system you connect to is just not going to be worth developing until you've exhausted the possibilities from the hundreds of closer systems you'll find from your routine exploration of normal-mass systems.
-
I kind of like the idea that such places are "soft" dead ends - places you turn to only when other avenues of expansion are exhausted, and then you have to pay the price of those distances. Because that makes them truly special circumstances for storytelling purposes. I understand that it's extremely rare for anyone's campaign to go that way but it is still a possibility.
I wouldn't want a BH system to be just a "+5% more difficult to handle but otherwise business as usual" system.
I've gone for the cube root option (I just posted the update) and I also reduced the range of black hole masses from 1 to 120. That is still going to need a huge effort though, especially in a real stars game where massive stars are rare. The median black hole is 25 solar masses (seven smaller and seven larger), which will have the outer ring of survey locations at 117 AU vs 40 AU for Sol.
-
I don't have a fundamental objection to some BH being so large they are extremely difficult to survey, because they can still be partially surveyed and still be a source of alien attack. However, I am happy to reduce the impact of the mid-size holes and maybe weight the chances against the really large ones.
At least for Real Stars games, I'm not sure that black holes are as likely to be avenues of alien attack as one might imagine. Loops on the system map are already pretty rare for Real Stars, you might explore 100+ systems and only find 2-3 loops, most of which tend to be smaller loops close to Sol. In practice this means that the probability of NPRs stumbling into a rear areas player-controlled system is pretty low, likely even negligible given how much NPRs struggle with fleet logistics to cover such large distances.
Maybe some way to increase the "loopiness" in Real Stars games might make black holes a bit more threatening to players?
-
I don't have a fundamental objection to some BH being so large they are extremely difficult to survey, because they can still be partially surveyed and still be a source of alien attack. However, I am happy to reduce the impact of the mid-size holes and maybe weight the chances against the really large ones.
At least for Real Stars games, I'm not sure that black holes are as likely to be avenues of alien attack as one might imagine. Loops on the system map are already pretty rare for Real Stars, you might explore 100+ systems and only find 2-3 loops, most of which tend to be smaller loops close to Sol. In practice this means that the probability of NPRs stumbling into a rear areas player-controlled system is pretty low, likely even negligible given how much NPRs struggle with fleet logistics to cover such large distances.
Maybe some way to increase the "loopiness" in Real Stars games might make black holes a bit more threatening to players?
Check out the latest posted map from my current campaign for loops. Its actually got worse since this point :) Remember to scroll sideways.
(http://www.pentarch.org/steve/Screenshots/BSG121.PNG)
-
Its actually got worse since this point :)
"Worse"?! ;D ;)
-
Can the new hostility modifier be a negative number if we want to roleplay as peaceniks?
Yes.
According to your change log it doesn't. Default will be zero, and we can input values from 1 to 100. Nothing mentioned about negative numbers possible. Or is the default not zero but 50?!?
-
Can the new hostility modifier be a negative number if we want to roleplay as peaceniks?
Yes.
According to your change log it doesn't. Default will be zero, and we can input values from 1 to 100. Nothing mentioned about negative numbers possible. Or is the default not zero but 50?!?
The default is zero because that means no change when added or subtracted from various attributes. The 1-100 range referred to the attributes post-change, not the number you can enter.
-
Can the new hostility modifier be a negative number if we want to roleplay as peaceniks?
Yes.
According to your change log it doesn't. Default will be zero, and we can input values from 1 to 100. Nothing mentioned about negative numbers possible. Or is the default not zero but 50?!?
The default is zero because that means no change when added or subtracted from various attributes. The 1-100 range referred to the attributes post-change, not the number you can enter.
Ahh, attributes (meaning Xenophobia and Militancy) ranging from 1-100, not the hostility modifier ranging from 1-100. Thank you for clarifying!
-
I guess life got in the way :'(
-
^I feel like feature creep might be an issue here, but so many of them sound really good and useful, so its hard to make any objection. lol
-
Will we be able to see ships in class in design screen again? I miss that feature a lot.
-
Will we be able to see ships in class in design screen again? I miss that feature a lot.
You can see that now on the 'Ships in Class' tab.
-
I did not convey well what I meant. I mean, other ships similar to that class that can be built in the same shipyard.
-
^I feel like feature creep might be an issue here, but so many of them sound really good and useful, so its hard to make any objection. lol
So true. So completely true.
I am almost anticipating 2.0 as much as I was anticipating 1.0.
-
^I feel like feature creep might be an issue here, but so many of them sound really good and useful, so its hard to make any objection. lol
It's would not be wholly inaccurate to say that Aurora is "Feature Creep : The Game", as so much of it is rooted in Starfire, and then developed according to what Steve needed/wanted/thought would be cool to beat up the Chinese with tell stories IN SPAAAAAACE with
-
^I feel like feature creep might be an issue here, but so many of them sound really good and useful, so its hard to make any objection. lol
It's would not be wholly inaccurate to say that Aurora is "Feature Creep : The Game", as so much of it is rooted in Starfire, and then developed according to what Steve needed/wanted/thought would be cool to beat up the Chinese with tell stories IN SPAAAAAACE with
The earliest VB6 versions were basically Starfire with 5HS engines. :P
-
"Minerals can be delivered to the DSP and collected from it, as it assumed these are stored as free-floating resources. They will be displayed as per a normal population."
I was re-reading this. Why can't MSP be stored free-floatingly like the minerals anyway?
I saw someone on the Discord mention that there's no easy way that can be automated to unload MSP to a DSP. Maybe there should be an MSP Hub component that works like the refueling hub, letting ships unload MSP to and resuply from?
-
Hey, Steve, since 2.1 is halving the mineral cost of terraforming installations after 2.0 halved only the BP cost, is the same supposed to be done with repair yards, because their BP cost was also halved in 2.0 or are they fine like this?
-
Now that the long-awaited 2.0 patch is out, should the name of this thread be changed officially to 2.0 to avoid confusing any new comers?
-
Hey, Steve, since 2.1 is halving the mineral cost of terraforming installations after 2.0 halved only the BP cost, is the same supposed to be done with repair yards, because their BP cost was also halved in 2.0 or are they fine like this?
Yes, fixed for v2.1
-
Now that the long-awaited 2.0 patch is out, should the name of this thread be changed officially to 2.0 to avoid confusing any new comers?
Yes, good idea. Done that now.
-
Now that the long-awaited 2.0 patch is out, should the name of this thread be changed officially to 2.0 to avoid confusing any new comers?
Yes, good idea. Done that now.
Are you sure it's done? Thread is still named 1.14.
Edit: The OP post is correctly named but every other reply is still titled 1.14, which if anything is more confusing as the old name is shown on the "recent posts" because of this.
-
Name of the thread should be fixed now...I run an SMF forum of my own and when the subject name of the OP is changed, it will not update until someone replies to the OP, which I just did.
-
I just realised that the initial build cost of repairyards was halved, but the expansion cost (and amount of workers) is still the same as with commercial shipyards. Is that intended?
-
"Commanders of STO formations will receive the same tracking of ship kills as ship commanders, including medal awards."
There are still no Commander skills that actually give STOs a bonus, though, right? Do you plan on changing that, so there's a mechanical reason to give STO formations an HQ?
-
"Commanders of STO formations will receive the same tracking of ship kills as ship commanders, including medal awards."
There are still no Commander skills that actually give STOs a bonus, though, right? Do you plan on changing that, so there's a mechanical reason to give STO formations an HQ?
STO commanders although they never start with it will actually learn the tactical skill that their spacer brethren can get while on duty. So there is actually a reason to have STO HQs beyond just RP.
-
"Commanders of STO formations will receive the same tracking of ship kills as ship commanders, including medal awards."
There are still no Commander skills that actually give STOs a bonus, though, right? Do you plan on changing that, so there's a mechanical reason to give STO formations an HQ?
STO commanders although they never start with it will actually learn the tactical skill that their spacer brethren can get while on duty. So there is actually a reason to have STO HQs beyond just RP.
Wow, really? I've suggested people not to use HQs for their STOs in the past, because I didn't know that.
I think ground commanders should probably just have a chance to start with tactical skill, so that you know they can have it. Otherwise this is a pretty secret mechanic.
-
"Commanders of STO formations will receive the same tracking of ship kills as ship commanders, including medal awards."
There are still no Commander skills that actually give STOs a bonus, though, right? Do you plan on changing that, so there's a mechanical reason to give STO formations an HQ?
STO commanders although they never start with it will actually learn the tactical skill that their spacer brethren can get while on duty. So there is actually a reason to have STO HQs beyond just RP.
Wow, really? I've suggested people not to use HQs for their STOs in the past, because I didn't know that.
I think ground commanders should probably just have a chance to start with tactical skill, so that you know they can have it. Otherwise this is a pretty secret mechanic.
I've added a chance for ground forces officers to have tactical bonuses in v2.1.1
-
I did some digging around here but it seems no matter what I make the environment on a planet I seem to always get a steppe if I get it in the habitable range for humans. I used to get a slight variety but perhaps I am missing something.
-
I've added a chance for ground forces officers to have tactical bonuses in v2.1.1
Is it possible to add Tactical bonus to the sorting list for ground forces officers without some unexpected troubles?
P.S. I have several GF officers with Tactical bonuses in my current 2.0.3 game too.
UPD. 2.1.0 really, not 2.0.3.
-
Avoidance of closed universe: When you reached the number of max systems specified for that particular game and there are still unexplored jump points, are they all going to lead to already explored systems or will the new routine allow the number of max systems to be exceeded?
-
Avoidance of closed universe: When you reached the number of max systems specified for that particular game and there are still unexplored jump points, are they all going to lead to already explored systems or will the new routine allow the number of max systems to be exceeded?
They will lead to existing systems, because the 20 attempts in random stars games won't find any new systems.
-
Avoidance of closed universe: When you reached the number of max systems specified for that particular game and there are still unexplored jump points, are they all going to lead to already explored systems or will the new routine allow the number of max systems to be exceeded?
They will lead to existing systems, because the 20 attempts in random stars games won't find any new systems.
Just because I am curious, why don’t you check for that explicitly rather than trying multiple times to generate a system?
-
Avoidance of closed universe: When you reached the number of max systems specified for that particular game and there are still unexplored jump points, are they all going to lead to already explored systems or will the new routine allow the number of max systems to be exceeded?
They will lead to existing systems, because the 20 attempts in random stars games won't find any new systems.
Just because I am curious, why don’t you check for that explicitly rather than trying multiple times to generate a system?
Because in random stars there is local generation range and chance, so I am trying to maintain the 'rules' of where to link while also trying to find an available system.
-
Couldn't an abandoned civilian ship just generate a wreck?
-
Couldn't an abandoned civilian ship just generate a wreck?
It isn't destroyed - just abandoned. If the player doesn't want to recover it they can destroy it, but at least they have the option.
-
They will lead to existing systems, because the 20 attempts in random stars games won't find any new systems.
Just because I am curious, why don’t you check for that explicitly rather than trying multiple times to generate a system?
Because in random stars there is local generation range and chance, so I am trying to maintain the 'rules' of where to link while also trying to find an available system.
Sure, but it seems like it would be easier just to check if the number of generated systems is >= the max number of systems allowed, and then generate a random existing system id instead of generating a random new or existing system id.
-
Avoidance of closed universe: When you reached the number of max systems specified for that particular game and there are still unexplored jump points, are they all going to lead to already explored systems or will the new routine allow the number of max systems to be exceeded?
They will lead to existing systems, because the 20 attempts in random stars games won't find any new systems.
Am I interpreting correctly that when a jp is explored and the percent chance to be a local system fails, the game will select random system numbers until it selects a number that does not yet have a system (but taking the 20th attempt regardless if it exists or not)?
I always assumed that for a non-local connection the game would just pick a random system number outside of the local range, regardless if that system number already has a system.
-
Couldn't an abandoned civilian ship just generate a wreck?
It isn't destroyed - just abandoned. If the player doesn't want to recover it they can destroy it, but at least they have the option.
It would be best if the player had access to some sort of "auto-abandon" toggle that is unchecked by default. I can predict this getting quite annoying on some games.
-
Couldn't an abandoned civilian ship just generate a wreck?
It isn't destroyed - just abandoned. If the player doesn't want to recover it they can destroy it, but at least they have the option.
It would be best if the player had access to some sort of "auto-abandon" toggle that is unchecked by default. I can predict this getting quite annoying on some games.
I don't think it would happen too often, since Civilian ships being damaged but not destroyed is pretty rare (maybe less so with Raiders but still rare). This only applies if a civilian ship is stranded in space due to some kind of damage, civilians will still scrap ships normally so you won't be accumulating a bunch of extra ships in Earth orbit when the civilians decide they are too old.
-
Couldn't an abandoned civilian ship just generate a wreck?
It isn't destroyed - just abandoned. If the player doesn't want to recover it they can destroy it, but at least they have the option.
It would be best if the player had access to some sort of "auto-abandon" toggle that is unchecked by default. I can predict this getting quite annoying on some games.
How many combat-damaged (but not destroyed) civilian ships have you encountered in your games so far?
-
Couldn't an abandoned civilian ship just generate a wreck?
It isn't destroyed - just abandoned. If the player doesn't want to recover it they can destroy it, but at least they have the option.
It would be best if the player had access to some sort of "auto-abandon" toggle that is unchecked by default. I can predict this getting quite annoying on some games.
How many combat-damaged (but not destroyed) civilian ships have you encountered in your games so far?
I don't play with civilian ships nor have I played with the new spoilers but with the way it seems to be going for people it sounds like they are going to get constantly interrupted but I suppose that your right most of them would probably get outright destroyed.
-
How many combat-damaged (but not destroyed) civilian ships have you encountered in your games so far?
I don't play with civilian ships nor have I played with the new spoilers but with the way it seems to be going for people it sounds like they are going to get constantly interrupted but I suppose that your right most of them would probably get outright destroyed.
In all of the test games I have played since adding the raiders, this situation hasn't happened once. If a civilian ship gets attacked, it dies. This change is to deal with the very rare occurrence where an attacking force is destroyed midway through attacking a civilian ship and they have eliminated that ship's ability to move. Previously, the civilians couldn't handle that so they just left the ship dead in space. If the ship can move, it will now make it home and be repaired. If not, the civilians will hand it over to the player. It is an opportunity to add a little flavour and is likely to happen once every few games.