Aurora 4x
C# Aurora => C# Mechanics => Topic started by: Steve Walmsley on January 26, 2024, 07:34:41 AM
-
Thread for discussion of changes announced for v2.6.0. Please do not post bug reports or unrelated suggestions in this thread.
-
So it looks like you're working to solve the problem of binaries way the hell out in the middle of nowhere, potentially with no easy way to access (and just all-round gigantic systems in general.)
I like that you've made it an option - I've always designed my ships with a surfeit of range (each generation of engines has a "Miserly" variant, which takes the biggest engine I can design and matches it with the lowest power% - for ships that don't need to move quickly, and which I don't want to have to refuel often.) Things like my stabilization ships can travel hundreds of billions of km between refuels. So, for me, as long as there's something that can hold a stabilization point on the other end, I'm willing and able to send a ship over there and wait however long it takes to form a bridge.
That said, I can be annoyed as anyone when the number of surveyed objects in a system remains stubbornly under 100%, and little chunks of rock that are in the far outreaches of a system are the number one cause of such things. This looks like it will greatly help with that.
Edit: Okay, I change my answer - I just came across a trinary star system where the third star (which has a full solar system, along with some juicy-looking planets) is 720 billion km away. That's too far.
-
Regarding the LaGrange rule, perchance apply that to planets as well? I've had a few cases where far-out gas giants had an LP and that made them interesting.
-
Regarding the LaGrange rule, perchance apply that to planets as well? I've had a few cases where far-out gas giants had an LP and that made them interesting.
Having an LP doesn't do that much to make a gas giant in a huge orbit accessible, since the point is at a distance from the body that appears to relate to the orbital circumference.
Though it can be very helpful for catching some trojan asteroids.
-
Does the Limited Planet Distance option means that some real star systems could be missing the companion stars? I think from close stars Epsilon Indi and 40 Eridani could be affected for example.
SJW: Yes.
-
Regarding the LaGrange rule, perchance apply that to planets as well? I've had a few cases where far-out gas giants had an LP and that made them interesting.
Having an LP doesn't do that much to make a gas giant in a huge orbit accessible, since the point is at a distance from the body that appears to relate to the orbital circumference.
Though it can be very helpful for catching some trojan asteroids.
If we could put a DSP at Lagrange Points particularly at L1 then it would make a gas giant that is far out more accessible
-
Regarding the LaGrange rule, perchance apply that to planets as well? I've had a few cases where far-out gas giants had an LP and that made them interesting.
Having an LP doesn't do that much to make a gas giant in a huge orbit accessible, since the point is at a distance from the body that appears to relate to the orbital circumference.
Though it can be very helpful for catching some trojan asteroids.
Oh yeah good point, would need to be a moon. I could swear it happened once.
-
The new shipping changes look good. It makes good sense to have only a certain amount of pop available for transportation.
Do the existing source, destination, stable buttons remain?
Is the emigration pressure percentage shown anywhere in the UI? I think it needs to, otherwise people will wonder why the civs don't ship anything to their new 10%+ colony.
-
The new shipping changes look good. It makes good sense to have only a certain amount of pop available for transportation.
Do the existing source, destination, stable buttons remain?
Is the emigration pressure percentage shown anywhere in the UI? I think it needs to, otherwise people will wonder why the civs don't ship anything to their new 10%+ colony.
Yes, source, etc. is the same.
Pressure is shown on the population summary in the first column after infrastructure.
-
Since reading the post of the new "Colonization Pressure" mechanic, I was puzzled if the actual "Colonization Pressure" words would clearly reflect what was going on. So I have turned to my friend Chat GPT using the full changelog from Steve, asking the same question. Here is the answer:
Instead of "Colonization Pressure," you could consider using the term "Migration Incentive" or simply "Migration Pressure." These alternatives reflect the concept of individuals being incentivized or pressured to migrate to certain colonies based on various factors such as infrastructure, security, and population capacity.
However, I was still unsure, since if I understood properly, what is going on is that the higher this number is, the higher number of people will be unhappy at their colony and be willing to pay to relocate to another world with perhaps higher desirability. When highlighting this, and after several other conversations, we agreed on the following:
"Relocation Rating"
I think the Relocation might still be better than Colonization. Eventually we could keep pressure and go for the following:
"Relocation Pressure"
-
I like the idea of "Colonization Pressure", but I think there is a factor missing.
Aurora does consider the security and environmental effects, but not being able to find a work and
to earn a living has been a major factor for migration around to world.
I would therefore suggest that either:
- a high unemployment rate increases the colonization pressure, or
- the number of unemployed workers could increase the maximum number of colonists
-
Population that is in excess of required manufacturing personnel numbers is generally considered to be gainfully employed, just not in trans-newtonian industries relevant to the game.
-
Yes, exactly that. You don't have two billion unemployed on Earth at the start of a conventional start.
-
Population that is in excess of required manufacturing personnel numbers is generally considered to be gainfully employed, just not in trans-newtonian industries relevant to the game.
Correct, but it could still be relevant to include some smaller pressure from this factor both for gameplay reasons and for flavor/immersion reasons.
For immersion:
It's not mutually exclusive with the idea that this population is available to be more gainfully employed (earning higher salary/status) if they were moved into a prioritized trans-newtonian industry career instead where such opportunities exists on other colonies.
For gameplay:
It's handy to have colony shipping prioritize colonies with surplus workers without having to micromanage this yourself by turning stable on and off again in the larger empires having to monitor the surplus workers.
-
So glad this is not a problem anymore https://aurora2.pentarch.org/index.php?topic=11545.msg166635#msg166635
Thanks Steve!
-
I know this is sort of a lend them a hand, lose the entire arm situation I'm causing here, but it would be nice if the tactical view option (esp. the "Open Tactical Map" one) somehow was differentiated visually. Even simply forcing Open Tactical Map to be always on the top of the list would be very nice. I can see it getting buried in systems with a lot of fleets.
The above was mentioned and remedied in the suggestions thread.
-
For immersion:
It's not mutually exclusive with the idea that this population is available to be more gainfully employed (earning higher salary/status) if they were moved into a prioritized trans-newtonian industry career instead where such opportunities exists on other colonies.
For gameplay:
It's handy to have colony shipping prioritize colonies with surplus workers without having to micromanage this yourself by turning stable on and off again in the larger empires having to monitor the surplus workers.
The pressure bump shouldn't be huge (maybe 2% of available/"unemployment" workers?), but would do a lot to help shipping lines pull colonists from where I would want them pulled without micromanagement.
Additionally I'd propose giving some priority to target planets where there is a worker shortage. This would again ease micromanagement and makes sense from an immersion standpoint - colonists would be more likely to go to worlds where jobs were waiting for them, even if the world is less desireable (re: higher colony costs). Any colonists en route should be subtracted from the shortage for this calculation.
-
New Colonists
Each construction phase, more colonists will become available at the rate of:
(Length of Construction Phase / Year) * Population * Colonization Pressure
For example, if colonization pressure was 5% and the population was 100m, then a 5-day construction phase would generate (5 / 365) * 100m * 5% = 68,493 colonists. A population of 1 billion with 2% pressure would generate 274,000 colonists every construction phase.
The max number of available colonists at any time will be equal to the annual amount generated. This 'production' of colonists has a side effect of breaking up the shipping line colony ships so they all don't move everywhere together. As shipping line colony ships load colonists they will be deducted from the available colonists total.
Should new colonist production be scaled by the species and/or governor population growth modifier? Given sufficient civilian transport capacity, every core world will eventually drift towards an equilibrium point where emigration is balanced by reproduction. In principle this is fine, but in practice the actual equilibria can vary surprisingly wildly based on local growth rates.
For example, let's consider Earth: homeworld, 12b capacity, colonization pressure 2%. In order to be at its equilibrium point, Earth will need a population with a 2% growth rate. I tried manually playing around with Earth's population in Spacemaster and got the below results:
| Species Growth Modifier | Equilibrium (millions) |
| 2.0 | 5100 |
| 1.5 | 3400 |
| 1.25 | 1950 |
| 1.0 | 1000 |
| 0.8 | 510 |
| 0.667 | 300 |
| 0.5 | 125 |
-
Love the new change to alert if MSP or fuel drops below a certain amount.
Do you think you can also have same if it exceed a certain amount?
This will help with the following:
Random forgetting with multiple colonies to switch off a production for any reason
Logistic (once x amount is reached send a tanker/replenishment ship to move)
-
Love the new change to alert if MSP or fuel drops below a certain amount.
Do you think you can also have same if it exceed a certain amount?
This will help with the following:
Random forgetting with multiple colonies to switch off a production for any reason
Logistic (once x amount is reached send a tanker/replenishment ship to move)
Why not go a step further and allow colonies to automatically start and shut down maintenance production if they recieve the maximum and minimum values so you can mosly just forget about it and automate this production on planets.
-
The galactic system search would be amazing to have on the movement screen when using autoroute.
Honeslty even a filter that lets me only show systems colonised by my race would be a godsend.
-
I am very happy to see the new autoroute changes making it into 2.6.0. The pain of having to scroll down to find Sol every time is finally over.
-
I am very happy to see the new autoroute changes making it into 2.6.0. The pain of having to scroll down to find Sol every time is finally over.
Seconded.
It would be neat to have some functionality to specify a specific system as "very important" independent of these factors. This would allow marking systems in which I want to conduct military operations, for instance, to make shuffling fleets back and forth easier. E.g., spoiler race systems where I am unlikely to establish a colonial presence before clearing out.
-
Personally, I was always adding a space before the name of each system out of my interest. Sometimes even 2 or 3, so that I could have them in my preferred hierarchy.
;D
Glad we have a bit of a solution in that space now.
-
It would be neat to have some functionality to specify a specific system as "very important" independent of these factors. This would allow marking systems in which I want to conduct military operations, for instance, to make shuffling fleets back and forth easier. E.g., spoiler race systems where I am unlikely to establish a colonial presence before clearing out.
Perhaps a different (red?) Color for systems flagged as controlled by a hostile faction on the Galaxy map?
Another neat QOL feature would be if systems in need of Xenoarcheology, Ground Survey, Ruin excavation or systems containing a Research bonus could be highlighted somehow. Not sure if there would be a good way to show normal Grav or Geo survey/unexplored JPs too. It risks getting a bit too cluttered if there is too much info ::)
-
Steve, the 2.6 seems chunky, May We have a date when It is going to be released? Honestly, I would like to start a new long campaign with the new stuff.
Thank you :)
-
Steve, the 2.6 seems chunky, May We have a date when It is going to be released? Honestly, I would like to start a new long campaign with the new stuff.
Thank you :)
I believe the answer to this question is *always* "It'll be released when it is ready". The joke is that it'll be delayed one month per time that someone asks.
-
Steve, the 2.6 seems chunky, May We have a date when It is going to be released? Honestly, I would like to start a new long campaign with the new stuff.
Thank you :)
I believe the answer to this question is *always* "It'll be released when it is ready". The joke is that it'll be delayed one month per time that someone asks.
That's what I was afraid of :D
-
Steve, the 2.6 seems chunky, May We have a date when It is going to be released? Honestly, I would like to start a new long campaign with the new stuff.
Thank you :)
I believe the answer to this question is *always* "It'll be released when it is ready". The joke is that it'll be delayed one month per time that someone asks.
That's what I was afraid of :D
I'm tempted to ask several times now to push back the release long enough to give me time to finish my AAR campaign. :P
-
Steve, the 2.6 seems chunky, May We have a date when It is going to be released? Honestly, I would like to start a new long campaign with the new stuff.
Thank you :)
It's going to be a while. We are spending this year (from mid-March anyway) travelling in a motorhome around the UK, and maybe Europe too. Everything done since March is on my laptop and I prefer to handle new releases on my desktop. At the moment, we only plan to return home (to the Isle of Man) in December, so it could be next year for v2.6. It's possible I could decide to do the release on my laptop, but don't count on it :)
Here is a quick shot of Remy - our Motorhome - earlier this year in Invercoe, Scotland (all motorhomes have to be given names - its a rule).
(http://www.pentarch.org/steve/Screenshots/Remy002.png)
-
Steve, the 2.6 seems chunky, May We have a date when It is going to be released? Honestly, I would like to start a new long campaign with the new stuff.
Thank you :)
It's going to be a while. We are spending this year (from mid-March anyway) travelling in a motorhome around the UK, and maybe Europe too. Everything done since March is on my laptop and I prefer to handle new releases on my desktop. At the moment, we only plan to return home (to the Isle of Man) in December, so it could be next year for v2.6. It's possible I could decide to do the release on my laptop, but don't count on it :)
Here is a quick shot of Remy - our Motorhome - earlier this year in Invercoe, Scotland (all motorhomes have to be given names - its a rule).
(http://www.pentarch.org/steve/Screenshots/Remy002.png)
Thank you, at least We know it is not behind the corner and We can play in peace ;)
-
Fixed a bug that prevented laser torpedoes from detonating at the correct range.
Does that mean that laser warheads are not worth using in 2.5.1?
-
Fixed a bug that prevented laser torpedoes from detonating at the correct range.
Does that mean that laser warheads are not worth using in 2.5.1?
They keep closing past their detonation point during the increment when they detonate. So they work to some degree, but not as intended.
-
Finally a way to do prisoner transfers! Make a colony on an empty rock, drop prisoners there, at the end of the war, transfer the colony to your former enemy. Live long and prosper!
-
Question: are the minerals, fuel and MSP stockpiled at the colony transferred to the new race?
-
Question: are the minerals, fuel and MSP stockpiled at the colony transferred to the new race?
Yes, they are part of the population.
-
Perfect. Now all that I need to simulate civil wars is the ability to move officers between empires, but I think that can just be handled through DB edits.
-
Will other POW mechanics be expanded on ? I'd like to be able to repatriate them, or to transfer POWs to conquered worlds of the same species, and stuff like that.
-
Perfect. Now all that I need to simulate civil wars is the ability to move officers between empires, but I think that can just be handled through DB edits.
DB Edit is probably the best option. I could add a Transfer Officer button, but doing it one at a time would take a while. A better option would be some form of mass transfer at the fleet or admin command level, like awarding medals, but that is a larger piece of work.
-
Is a new colony created or an existing colony must be created first from the target race?
If a colony with a population is on the same planet, will the population be added to the existing?
And finally, if the population is a different species, will it be addedd to the pool and subjected to the existing species rules for colony transport and such?
-
Is a new colony created or an existing colony must be created first from the target race?
If a colony with a population is on the same planet, will the population be added to the existing?
And finally, if the population is a different species, will it be addedd to the pool and subjected to the existing species rules for colony transport and such?
The colony is moved to the other race. Nothing is created. It won't be added to an existing colony, as amalgamation is more complex. I might add it in the future though. The receiving race gains a new species, if they don't have it already.
-
Very neat, we could take this one step further and have population unrest trigger this mechanic and create a rebel population. Maybe also a chance to spawn rebel troops or "capture" ships and ground forces in orbit and on the surface
-
Very neat, we could take this one step further and have population unrest trigger this mechanic and create a rebel population. Maybe also a chance to spawn rebel troops or "capture" ships and ground forces in orbit and on the surface
I think all of that already exists. It's always been possible to release a colony as an empire; there was just no way to move a population from one empire to another.
-
Looks amazing so far Steve thanks a lot!
Could you please clarify the below? (Or if anyone else get's it please also feel free to help me out!)
- Species characteristics, such as growth rate, research rate, etc. are passed on when used as a base species for a new species design.
-
Looks amazing so far Steve thanks a lot!
Could you please clarify the below? (Or if anyone else get's it please also feel free to help me out!)
- Species characteristics, such as growth rate, research rate, etc. are passed on when used as a base species for a new species design.
Looks like it's about these modifiers found on the middle in the leftmost column here:
https://aurora2.pentarch.org/index.php?topic=11136.0
(https://rainydaygaming.com/posts/2020/04/aurora-random-system/customrace.png)
-
Looks amazing so far Steve thanks a lot!
Could you please clarify the below? (Or if anyone else get's it please also feel free to help me out!)
- Species characteristics, such as growth rate, research rate, etc. are passed on when used as a base species for a new species design.
In v2.6, the new species copies the growth, density, research and production modifiers, but not in v2.5.1.
http://aurora2.pentarch.org/index.php?topic=13463.0
-
Considering the new fire control options, wouldn't it be possible to have it operating similarly to turrets, where you input a specific tracking speed and the game does the math for you? That would be better than seeing a frakkton of 0.01 increments.
-
Considering the new fire control options, wouldn't it be possible to have it operating similarly to turrets, where you input a specific tracking speed and the game does the math for you? That would be better than seeing a frakkton of 0.01 increments.
I'd argue instead of that, it would be easier to program a pair of boxes that just accept a number between 0.01 and 4.00 for the range/speed modifiers. Which is effectively what's already being done, but would save a lot of scrolling, and needing to code in a bunch of checks for "Did the user enter a range that's too high for their tech... they can only do 480,000km with a max range BFC but they've entered 1,800,000km".
-
Considering the new fire control options, wouldn't it be possible to have it operating similarly to turrets, where you input a specific tracking speed and the game does the math for you? That would be better than seeing a frakkton of 0.01 increments.
I'd argue instead of that, it would be easier to program a pair of boxes that just accept a number between 0.01 and 4.00 for the range/speed modifiers. Which is effectively what's already being done, but would save a lot of scrolling, and needing to code in a bunch of checks for "Did the user enter a range that's too high for their tech... they can only do 480,000km with a max range BFC but they've entered 1,800,000km".
The x1 and x4 (the most common) are already 1st and 2nd in the list, which will cover most of the time. The rest are no different than many other options for different component types.
I have considering re-doing the Create Project screen entirely to allow players to enter values, but that is a much larger change. The dropdowns contain information tagged to each item that is passed directly to the design functions. If I take the values from boxes, I then have to change the design function parameters, which then means updating all the automated design code to use the new parameter types.
I already did that in this case, modifying the beam fire control design function to accept decimals from the dropdowns instead of TechSystem objects. That led to adding new database fields so I could store those choices, because I needed to record them for the ship component code in the class design templates. This is because race-designed components are tagged with the tech systems used to create then, which no longer exist in this case. I also had to change the way NPRs designed ships, to use decimal values instead of tech systems. Because there is a lot of code in Aurora, it is often a lot more complex than simply changing the UI, plus all the changes also lead to increased chances of bugs.
Ultimately, it comes down to the amount of improvement in QoL vs the amount of effort required to achieve it. In this case, I finally found the lack of granularity annoying enough to justify the effort to change it :)
-
Steve, wouldn't it be possible to hide the dropdown list, and add a box, to input the needed value, that instructs the dropdown to select the value to use in the rest of the program?
So the design part should not be modified, and there could be an easier way to input the data.
The box should anyway limit the maximum and minimum values, and the decimal digits to two (or any other number that's considered right).
-
Steve, wouldn't it be possible to hide the dropdown list, and add a box, to input the needed value, that instructs the dropdown to select the value to use in the rest of the program?
So the design part should not be modified, and there could be an easier way to input the data.
The box should anyway limit the maximum and minimum values, and the decimal digits to two (or any other number that's considered right).
Theoretically possible, but extremely hacky. Future Steve trying to debug something a couple of years from now would not be very happy with current Steve :)
-
Steve, wouldn't it be possible to hide the dropdown list, and add a box, to input the needed value, that instructs the dropdown to select the value to use in the rest of the program?
So the design part should not be modified, and there could be an easier way to input the data.
The box should anyway limit the maximum and minimum values, and the decimal digits to two (or any other number that's considered right).
Theoretically possible, but extremely hacky. Future Steve trying to debug something a couple of years from now would not be very happy with current Steve :)
A question I just had, based on your observations of Auroras code quality. How happy is current Steve with past Steve? ;D
-
Steve, wouldn't it be possible to hide the dropdown list, and add a box, to input the needed value, that instructs the dropdown to select the value to use in the rest of the program?
So the design part should not be modified, and there could be an easier way to input the data.
The box should anyway limit the maximum and minimum values, and the decimal digits to two (or any other number that's considered right).
Theoretically possible, but extremely hacky. Future Steve trying to debug something a couple of years from now would not be very happy with current Steve :)
A question I just had, based on your observations of Auroras code quality. How happy is current Steve with past Steve? ;D
Fairly happy. I went into the C# rewrite with a lot of lessons learned from VB, so readability and ease of updating was a major factor, even above the most efficient possible code. I comment a lot, so its not too bad understanding what past Steve was trying to do, and use very descriptive names for functions and objects. That is especially important in complex areas, such as the AI code. In general, when I need to make changes, I don't have to spend much time trying to understand what is already happening. Where I usually get into trouble is some kind of knock-on effect of the change that I hadn't considered.
-
The "Say Thanks" button isn't strong enough, THANK YOU SO MUCH for making the maximum geological search radios customizable!! In my current game I've been working with several systems concurrently with widely dispersed asteroid belts where geo surveyors had to constantly be micro managed. This change is a huge quality of life improvement.
Is there a similar max set for the "Move to system requiring grav/geo survey" standing orders? I've noticed in my current ~80 year game, ships with that standing over who are starting from my home system only go a few jumps before getting stuck of a cycle of going back and forth through the same jump point.
-
The "Say Thanks" button isn't strong enough, THANK YOU SO MUCH for making the maximum geological search radios customizable!! In my current game I've been working with several systems concurrently with widely dispersed asteroid belts where geo surveyors had to constantly be micro managed. This change is a huge quality of life improvement.
Is there a similar max set for the "Move to system requiring grav/geo survey" standing orders? I've noticed in my current ~80 year game, ships with that standing over who are starting from my home system only go a few jumps before getting stuck of a cycle of going back and forth through the same jump point.
There is no restriction so that sounds like a bug.
-
Is there a similar max set for the "Move to system requiring grav/geo survey" standing orders? I've noticed in my current ~80 year game, ships with that standing over who are starting from my home system only go a few jumps before getting stuck of a cycle of going back and forth through the same jump point.
Ive seen some other odd or inefficient things with this standing order as well.
Mainly that survey ships tend to clump together and all end up in one or two systems after running all ships on it 5-10 years...
Would it be hard to tweak the logic to prioritize systems without any other survey ships in them or with queued orders to go there?
-
Like the new map screenshot button ;D
Taking a look at the generated image - would it be possible to get the game time included in the information - say below or above the Known Systems count? Or even in the title - beside "Galactic Map"?
-
It would be lovely if we got alternate view mode for galactic map. Basically make systems just dots with names, flags at most for extra information, shrink everything to fit much more on screen.
Navigating large maps is pain...
-
Steve, while working on the map would you consider adding a toggle to display the alignment grid.
Currently its a guessing game if i've aligned up the systems with each other.
-
The screenshot feature is amazing; also it would be really nice to be able to see my race's flag on systems that I have claimed in the galaxy map.
-
The screenshot feature is amazing; also it would be really nice to be able to see my race's flag on systems that I have claimed in the galaxy map.
Any system without a flag is effectively your system. If I included all the viewing race flags as well, so that all systems had flags, it would be crowded.
-
The screenshot feature is amazing; also it would be really nice to be able to see my race's flag on systems that I have claimed in the galaxy map.
Any system without a flag is effectively your system. If I included all the viewing race flags as well, so that all systems had flags, it would be crowded.
Yes, but it does seem useful to be able to see on the map which systems you have specifically claimed (via Protection Status), rather than which systems are effectively yours.
-
Really thank you, Steve!
Fantastic addictions both the screenshots printing and the flags! :o
I would like I can play my current match using all the new features you are introducing! ;D
-
It seems like having the "Attempt Boarding Action" not appear for Swarm contacts could make it trivially easy to identify a contact as Swarm? Just select a boarding ship on the other side of the galaxy and see if you can ask it to board, unless I misunderstand the change. Probably most experienced players who would know to do this are already able to identify spoiler races pretty quick anyway, but it still sounds overly exploitable to me.
-
It seems like having the "Attempt Boarding Action" not appear for Swarm contacts could make it trivially easy to identify a contact as Swarm? Just select a boarding ship on the other side of the galaxy and see if you can ask it to board, unless I misunderstand the change. Probably most experienced players who would know to do this are already able to identify spoiler races pretty quick anyway, but it still sounds overly exploitable to me.
You can already tell if something is Swarm by looking at the picture on the intel window. I have considered removing the image until comms are established or bodies/survivors recovered ( although you cant establish comms with some races and they don't leave life pods, so you would never see them).
I could do it by having the attempt fail so you lose the first boarding party.
I could also add a 'biological' tag to the contact information for active sensors, as that is probably something that should be known anyway, and that means you know Swarm anyway. I was thinking of adding other 'biologicals' anyway, so that might be the best option.
-
--- Perhaps instead of removing the boarding option outright, have it so that they attack and damage the armor of the ship. Not efficient at all, nor even really effective, BUT!
--- It would sidestep the mentioned exploit while also neatly providing a little flavor for those crazier sorts of roleplay.
-
I still think the coolest way to handle swarm boarding is to make boarders fight the ship itself, dealing exclusively collateral interal damage and receiving damage from the ship's internal acid in return, making it a suicide mission either way. However, this would probably be difficult to implement, and having boarders continously damage the ship's armor would make boarding an extremely overpowered opening tactic, since even the largest hives would get stripped and become extremely vulnerable after a few hours of 1 minute hell. That is, unless swarms still have regenerating armor and it would regenerate faster than the boarders can damage it which means the armor damage is for flavor purposes only (and perpetual 1 minute hell!).
Making them unboardable is a good compromise, making boarding auto-fail is better. As far as identifying the swarm goes, their picture, tech and behaviour are not exactly conspicious, so any player aware enough to attempt boarding during a first contact would probably know what he's up against regardless.
-
More biological spoilers? Are we getting space whales? Awesome! ;D
And agreed with the change. Boarding swarm always struck me as a silly thing.
-
More biological spoilers? Are we getting space whales? Awesome! ;D
Maybe some space fish, so Steve's future NATO vs Soviet campaign will finally have spy trawlers. :)
-
More biological spoilers? Are we getting space whales? Awesome! ;D
Actually, that is exactly what I was considering :)
Creatures that contain valuable resources, but can be dangerous if provoked. Perhaps others that live in the atmospheres of gas giants. Plus maybe some SFB 'monster' type options.
-
If it is not possible to board Swarm ships anymore, will there be any way to acquire their technology?
-
If it is not possible to board Swarm ships anymore, will there be any way to acquire their technology?
No, the only way was boarding and because it was very easy to board them, acquiring their tech was too easy. Maybe at some point in the future, I will add organic ships as a technology option.
-
If it is not possible to board Swarm ships anymore, will there be any way to acquire their technology?
No, the only way was boarding and because it was very easy to board them, acquiring their tech was too easy. Maybe at some point in the future, I will add organic ships as a technology option.
One interesting way to add that back could be to have some swarm colony with pop on asteroids you can assault with ground forces and capture
Edit: For technology options not the whole ship needs to be organic, some components could be organic with unique attributes, like:
- Organic Armour -> regenerating over days.
- Organic Powered weapon version -> integrated without need for separate powerplants.
- Organic Fuel Generator -> Maybe relying on solar power and asteroid sorium if it can be balanced?
- Organic Salvager -> Slower to salvage, extracts no components but alot more minerals of ship wrecks.
-
I have read the new update about alien components, so, the conversion is only possible if the tech matches the one I have?
What happen if the alien componen is of higher tech than the one I possess? Can I still create a single ship with that component? I liked the possibility to create few ships (depending how many components I have) made with superior alien devices.
-
You can still create a single ship with that component.
-
The treeview nodes for Naval Admin Commands retain their expanded or closed status on save.
Does this mean that it will remember status only when you save the game? Will the status still reset when you toggle on/off the "Show Elements" option or other options?
Also, can we please also have this for the Ground OOB window? That was actually the tree I was hoping to have the change made to, although I realize now that I didn't make that clear in the suggestion thread.
-
Reading the change about alien missiles has me wondering; realistically, shouldn't missiles be limited to being launched from specific launcher designs? I mean, you can't put an M1 bazooka rocket in a 60mm mortar and expect it to work, even though the M1 rocket will fit. It seems like you should have to design rockets to match launchers in a similar way to how we can tool shipyards to build multiple similar classes; different missile classes can only be launched from the same launcher if they're really similar.
-
Reading the change about alien missiles has me wondering; realistically, shouldn't missiles be limited to being launched from specific launcher designs? I mean, you can't put an M1 bazooka rocket in a 60mm mortar and expect it to work, even though the M1 rocket will fit. It seems like you should have to design rockets to match launchers in a similar way to how we can tool shipyards to build multiple similar classes; different missile classes can only be launched from the same launcher if they're really similar.
That just sounds like way too much of a headache to me.
-
Reading the change about alien missiles has me wondering; realistically, shouldn't missiles be limited to being launched from specific launcher designs? I mean, you can't put an M1 bazooka rocket in a 60mm mortar and expect it to work, even though the M1 rocket will fit. It seems like you should have to design rockets to match launchers in a similar way to how we can tool shipyards to build multiple similar classes; different missile classes can only be launched from the same launcher if they're really similar.
Launcher size is the only limiting factor in Aurora, i.e. the launcher must be large enough. Yes, in the real world launchers are typically designed to launch a specific missile, or in rare cases a small set of missiles. Would adding that restriction add interesting gameplay choices, or just more work?
-
Maybe at some point in the future, I will add organic ships as a technology option.
That'd certainly be something to add to the biology/genetics science division, heh.
-
Would adding that restriction add interesting gameplay choices, or just more work?
Both. I think it would be an interesting choice of having to recondition missiles to your missile launchers at an ordinance factory. It would add a little more micro to the game for, in my opinion, a proportionate amount of interesting gameplay. Now, when you consider the fact that it would have to be built into the industry tab with some type of popup most likely and it isn't exactly the easiest implementation then I don't think it would really be worth looking into.
-
Will the "Add replacement crew" command be an option between ships? Or maybe an equivalent "Transfer prize crew"? Otherwise you have no way to add a prize crew, unless perhaps the boarding crew counts toward the manning requirement?
-
Will the "Add replacement crew" command be an option between ships? Or maybe an equivalent "Transfer prize crew"? Otherwise you have no way to add a prize crew, unless perhaps the boarding crew counts toward the manning requirement?
No that won't be available, as it would invalidate the need for the 1m pop. The 'prize crew' is effectively free, but only counts as 1 effective crewman.
-
No that won't be available, as it would invalidate the need for the 1m pop. The 'prize crew' is effectively free, but only counts as 1 effective crewman.
I'm not assuming we'd create prize crew out of thin air, I was envisioning that we'd transfer X of our crew from our original ship(s) to the captured ship, reducing the remaining crew on the giving ship(s), the way prize crews are/were sourced in real life. That doesn't obviate the need for a 1M pop colony to replace the missing crew, it's now just on two ships instead of one. With a largish fleet each ship gives up say 20 crew and now you have a decent prize crew for the captured frigate, etc etc.
Maybe more trouble than it's worth I guess.
-
No that won't be available, as it would invalidate the need for the 1m pop. The 'prize crew' is effectively free, but only counts as 1 effective crewman.
I'm not assuming we'd create prize crew out of thin air, I was envisioning that we'd transfer X of our crew from our original ship(s) to the captured ship, reducing the remaining crew on the giving ship(s), the way prize crews are/were sourced in real life. That doesn't obviate the need for a 1M pop colony to replace the missing crew, it's now just on two ships instead of one. With a largish fleet each ship gives up say 20 crew and now you have a decent prize crew for the captured frigate, etc etc.
Maybe more trouble than it's worth I guess.
It a gameplay issue, rather than a mechanics issue. I am trying to simulate the fact you can't just capture an alien ship and immediately get it functional by transferring a crew on board. It has been like that until now in Aurora - as it was immediately fully crewed - but I am trying to make it more challenging to put captured ships into service. The mechanics assume you put some crew aboard (effectively for free), but they are just about capable of eventually getting the ship to a colony where it can be properly examined, which is why the captured ship behaves as 'effectively' uncrewed until that happens.
-
No that won't be available, as it would invalidate the need for the 1m pop. The 'prize crew' is effectively free, but only counts as 1 effective crewman.
I'm not assuming we'd create prize crew out of thin air, I was envisioning that we'd transfer X of our crew from our original ship(s) to the captured ship, reducing the remaining crew on the giving ship(s), the way prize crews are/were sourced in real life. That doesn't obviate the need for a 1M pop colony to replace the missing crew, it's now just on two ships instead of one. With a largish fleet each ship gives up say 20 crew and now you have a decent prize crew for the captured frigate, etc etc.
Maybe more trouble than it's worth I guess.
It a gameplay issue, rather than a mechanics issue. I am trying to simulate the fact you can't just capture an alien ship and immediately get it functional by transferring a crew on board. It has been like that until now in Aurora - as it was immediately fully crewed - but I am trying to make it more challenging to put captured ships into service. The mechanics assume you put some crew aboard (effectively for free), but they are just about capable of eventually getting the ship to a colony where it can be properly examined, which is why the captured ship behaves as 'effectively' uncrewed until that happens.
Won't this just lead to captured ships just falling apart before you have the ability to tug or transfer them to a suitable colony?
-
It a gameplay issue, rather than a mechanics issue. I am trying to simulate the fact you can't just capture an alien ship and immediately get it functional by transferring a crew on board. It has been like that until now in Aurora - as it was immediately fully crewed - but I am trying to make it more challenging to put captured ships into service. The mechanics assume you put some crew aboard (effectively for free), but they are just about capable of eventually getting the ship to a colony where it can be properly examined, which is why the captured ship behaves as 'effectively' uncrewed until that happens.
Won't this just lead to captured ships just falling apart before you have the ability to tug or transfer them to a suitable colony?
No, because the penalty is to deployment time, not the maintenance clock.
-
With regards to players building shield ships that are just for ramming, perhaps make it such that shields have zero protection against ramming, or that they take 10x damage from a ram? This would keep players from exploiting it much. Any ship that rams and survives needs to return to a shipyard to get armor repairs.
-
With regards to players building shield ships that are just for ramming, perhaps make it such that shields have zero protection against ramming, or that they take 10x damage from a ram? This would keep players from exploiting it much. Any ship that rams and survives needs to return to a shipyard to get armor repairs.
I considered exactly that - with some accompanying technobabble about how shields aren't designed to stop physical objects. Then I realised that railgun rounds are effectively physical, so that leads to 'shields are designed to cope with large physical objects'. At that point someone will want to know 'how large', and then we end up in debate about how big you need a railgun round to be to defeat shields :)
Maybe I can do both - some form of large shield-damaging weapon and ramming rules that negate shields to some degree, but I need to think about it for a while.
-
I considered exactly that - with some
accompanying technobabble about how shields aren't designed to stop physical objects. Then I realised that railgun rounds are effectively physical, so that leads to 'shields are designed to cope with large physical objects'. At that point someone will want to know 'how large', and then we end up in debate about how big you need a railgun round to be to defeat shields :)
Maybe I can do both - some form of large shield-damaging weapon and ramming rules that negate shields to some degree, but I need to think about it for a while.
It could also have to do with the speed of the object as well. Shields might operate based on kinetic energy and disperse the kinetic energy from missiles and railguns while a ship itself doesn't travel fast enough to engage the dispersion of the kinetic energy (or maybe they do but with the mass of the ship it isn't torn apart. It could also be a ratio of kinetic energy to mass with anything being able to do damage without the shield engaging would have to be such a large mass that it is basically a ship already.
-
I considered exactly that - with some
accompanying technobabble about how shields aren't designed to stop physical objects. Then I realised that railgun rounds are effectively physical, so that leads to 'shields are designed to cope with large physical objects'. At that point someone will want to know 'how large', and then we end up in debate about how big you need a railgun round to be to defeat shields :)
Maybe I can do both - some form of large shield-damaging weapon and ramming rules that negate shields to some degree, but I need to think about it for a while.
It could also have to do with the speed of the object as well. Shields might operate based on kinetic energy and disperse the kinetic energy from missiles and railguns while a ship itself doesn't travel fast enough to engage the dispersion of the kinetic energy (or maybe they do but with the mass of the ship it isn't torn apart. It could also be a ratio of kinetic energy to mass with anything being able to do damage without the shield engaging would have to be such a large mass that it is basically a ship already.
The slow blade penetrates the shield, except the slow blade is still traveling at thousands of kilometers per second...
I would argue strongly against spending time rewriting the lore around how shields work, especially with missiles in the new patch becoming able to out-mass most fighters, just because of this ramming conundrum. Writing shields out of the ramming equation would make NPR ramming unreasonably dangerous against a shield-heavy player anyway. Taking 200 damage should you ever slip up and taking 200 armor/component damage should you ever slip up are entirely different things.
I propose making ramming unavailable to the player, at least until a viable system of restrictions and consequences can be designed. It definitely shouldn't be available to undamaged player ships, and I have been thinking about how planetary unrest could be influenced by losses in battle, especially such catastrophic ones as ramming (a fleet is wiped out in a crushing defeat, all nearby systems and Earth where it was built and crewed experience riots!), but such a system would be very complex to think through and implement. Not to mention that making ramming unavailable to the player would cement our place as the sole power of justice and reason in the galaxy full of vile, suicidal xenos ;D
-
If or when you want to make ramming available to players.
You could make it rely on crew training, morale, officer traits, etc.
And probably provide a toggle "Allow ramming" (or similar) on the combat overview of a ship, when the rules would determine that a ship is willing to ram.
A Fleet can than have a command "Ram target fleet".
Ships that have ramming disabled would split of (or the other way around)
The ramming ships (fleet) would randomly choose targets in the target fleet.
Or if you want to make it more complex, provide ramming strategies on the combat overview.
Ram closest, ram biggest, smallest, fastest, slowest, etc.
Just a thought. :-)
Version 2.6 is shaping up nicely.
Any other changes or improvements you have in mind for this version?
-
Perhaps ramming should do shock damage in addition to (or instead of, if needed for balance reasons) normal damage. Then it doesn't matter how heavily shielded the ship is, significant internal damage is still going to happen and a dedicated ramming vessel cannot be built to be survivable, preventing this cheese strategy.
-
While it could be an interesting addition, I am against player-controlled ships executing ramming orders without specific instructions to do so.
If I may suggest, a mechanism that has worked well in other titles is to have "special orders"—in this case, ramming—appear as an option only if predetermined circumstances are met. This is similar to how refuelling orders are only available if the tanker checkbox is enabled. The difference here is that this option could be hidden or perhaps shown only if the SM setting is on. I believe this was the implied mechanism already, anyway.
If I were to speculate on what these conditions could be, the commander would definitely need to be brave or aggressive, avoiding traits that are cautious or cowardly. I agree that the training level should be above a certain threshold to prevent panic and mutiny. Additionally, the ship should have suffered some damage at least.
On the other hand, drawing inspiration from the original Battlestar Galactica series and real WWII scenarios, I wouldn't mind the idea of some fighters being used as kamikaze. This could include a mechanism that allows the fighter to explode and cause damage, perhaps through a "Kamikaze Module" that can be added to the fighter and researched to increase damage up to a threshold that prevents it from being OP. This could be somewhat similar to how mesons work, bypassing all ship armour and shields—or perhaps just shields—with the difference being that the fighter's armour and the targeted ship's armour could play a role in the damage calculation.
-
It would mean storing a bit of extra data for each ship, but if you don't want to change how ramming interacts with shields you could make a rule that ships will only ram if they've lost x% of their (internal?) hit points in y time. This would mean a ship won't ram until it's defences have already been breached, and you can't make a dedicated ramming ship and leave it damaged. Maybe make it count over the current and last production increment so you don't need to track when each bit of damage happened but can just update the numbers every five days or so.
-
It seems to me if the big fear with player-controlled ramming is players building dedicated ramming ships, the key is to just make it suicidal. That way, while the player -can- make dedicated ramming ships, it's just no good. With this in mind, my idea is to make ramming cause a ton of shock damage to internal components. A real ship will have most of it's tonnage in internal components, so it will be less likely to die from it. Whereas a big ball of armor with engines has hardly any internal components, so shock damage will quickly kill it. So at best, your ram ship will kill one enemy ship, and that will be it. Yes, your ram ships will be cheap, but the giant shipyards needed to make dozens of ram ships won't be.
I'd also make shields work against ramming based on the amount of armor the ram has. I'm thinking of it kinda like how microwaves work irl. Small things often don't get heated at all; fruit flies for instance survive in a microwave totally unharmed, whereas larger insects die. Well what if ship-scale shields work somewhat similarly? Railgun shells and big balls of armor are dense enough that the shield interacts with them. But normal ships are actually mostly hollow, so just like the fruit flies being smaller than the wavelength of the microwave and surviving, normal ships are unaffected by "hitting" shields. So there's no fear about ram ships mounting 1000-strength shields.
-
There's no need to ensure that there are no exploits with ramming. If a player wants to build dedicated ramming ships then that's on them. Steve just has to make sure that the mechanics are such that ramming is not an obviously superior tactic as that's the point where lot of players would struggle. Kinda like how the DPS at first for single shot rail guns was so crazy good that it basically forced everyone to use them, not doing so being so inefficient.
But I don't mind ramming staying an AI option only.
-
While it could be an interesting addition, I am against player-controlled ships executing ramming orders without specific instructions to do so.
If I may suggest, a mechanism that has worked well in other titles is to have "special orders"—in this case, ramming—appear as an option only if predetermined circumstances are met. This is similar to how refuelling orders are only available if the tanker checkbox is enabled. The difference here is that this option could be hidden or perhaps shown only if the SM setting is on. I believe this was the implied mechanism already, anyway.
If I were to speculate on what these conditions could be, the commander would definitely need to be brave or aggressive, avoiding traits that are cautious or cowardly. I agree that the training level should be above a certain threshold to prevent panic and mutiny. Additionally, the ship should have suffered some damage at least.
On the other hand, drawing inspiration from the original Battlestar Galactica series and real WWII scenarios, I wouldn't mind the idea of some fighters being used as kamikaze. This could include a mechanism that allows the fighter to explode and cause damage, perhaps through a "Kamikaze Module" that can be added to the fighter and researched to increase damage up to a threshold that prevents it from being OP. This could be somewhat similar to how mesons work, bypassing all ship armour and shields—or perhaps just shields—with the difference being that the fighter's armour and the targeted ship's armour could play a role in the damage calculation.
I am also not really a fan of control being taken away and prefer the idea of the option becoming available after certain conditions are met (Or an SM button to force it to be available in addition.)
You could have one of the conditions be tied to the number of crew who have died in the system or overall against this enemy compared to the number of enemy ships destroyed or damaged. If the crew and CO believes there is no choice and are very well trained and disciplined, they'll have the option show up. Probably combine that with requirements for the ship to be damaged and other things. This ramming thing is an interesting idea for sure.
-
A good game is the one where both sides have the same options available, so I am for both AI and human player to have the ram option, We just need to make sure there are the right balances so we do not exploit this.
-
A thought occurred to me. And a question.
Shields in Aurora are designed to keep things OUT.
How would shields in Aurora react to being forced to keep things IN?
So by extension, perhaps on possible way to balance player ramming, is to make shields significantly LESS effective at preventing ramming damage caused by the player ramming into something?
A nice lore/fluffy reason would be, "Shields systems in Aurora work by projecting a shield around the ship, and while they work great at keeping things OUT, the projects aren't designed to keep things IN. Thus, a player ramming will find their shields much less useful in protecting them from the kind of damage such ramming would incur."
-
How is boarding affected by shields?
If shield is supposed to just stop things than it is no different from armor. If the shield is supposed to disintegrate anything that touches it than it would not take damage from impacts, but be depleted based on for example a mass of object that contacted it. But all weapons we shout at shields deal damage equal to that weapons power. Missiles deal damage equal to it's warhead strength instead of being deleted out of existence.
But with ramming we have to massive objects colliding with each other. Is shield a 100% rigid dome around a ship? If so, all kinetic energy would be transferred in to rammed ship. Shield is just extension of armor. However if shield is flexible and can bend under pressure, than that shield could absorb a fraction or all energy from impact.
-
Steve, please, in the formula for the "percentage chance of ‘processing’ a given officer", the Number of Naval Headquarters does it include the levels of each of them, or not?
I mean, a level 3 NH, does it count as 3 or as 1?
-
Steve, please, in the formula for the "percentage chance of ‘processing’ a given officer", the Number of Naval Headquarters does it include the levels of each of them, or not?
I mean, a level 3 NH, does it count as 3 or as 1?
Good question - I hadn't thought of it in those terms. Currently it is set up as the physical number of naval headquarters, rather than the level for command purposes. Perhaps I should be using the level instead. I'll think it about it overnight.
-
I think that if a race/power/empire is conquered by the player, then all prisoners of that race/power/empire should be automatically released and added as population to a suitable colony where their species already exist. If no such colony exists, then assume player is committing genocide and the prisoners are disposed of.
That way I can RP a nice overlord race and not have to execute POWs, just wait until war is won.
-
Steve, please, in the formula for the "percentage chance of ‘processing’ a given officer", the Number of Naval Headquarters does it include the levels of each of them, or not?
I mean, a level 3 NH, does it count as 3 or as 1?
Good question - I hadn't thought of it in those terms. Currently it is set up as the physical number of naval headquarters, rather than the level for command purposes. Perhaps I should be using the level instead. I'll think it about it overnight.
I think it make more sense to use the actual number of NHQ, since the logical reason for the levels is to model their range/reach which is a more exponential number in turns of systems covered by each additional jump while the needs of processing PoWs can be assumed to scale more linearly with empire size growth.
-
I think that if a race/power/empire is conquered by the player, then all prisoners of that race/power/empire should be automatically released and added as population to a suitable colony where their species already exist. If no such colony exists, then assume player is committing genocide and the prisoners are disposed of.
That way I can RP a nice overlord race and not have to execute POWs, just wait until war is won.
I think it would be difficult to even notice such an interaction. Meaningful population numbers are orders of magnitude larger than those of crew/prisoners. You'd get 0.01m, the smallest displayed pop, from hundreds of thousands of tons worth of military ships.
-
Steve, please, in the formula for the "percentage chance of ‘processing’ a given officer", the Number of Naval Headquarters does it include the levels of each of them, or not?
I mean, a level 3 NH, does it count as 3 or as 1?
Good question - I hadn't thought of it in those terms. Currently it is set up as the physical number of naval headquarters, rather than the level for command purposes. Perhaps I should be using the level instead. I'll think it about it overnight.
I think it make more sense to use the actual number of NHQ, since the logical reason for the levels is to model their range/reach which is a more exponential number in turns of systems covered by each additional jump while the needs of processing PoWs can be assumed to scale more linearly with empire size growth.
Yes, agree. I am going to leave it as it is.
-
Am I correct in reading that the new Transfer Prisoners and Unload Prisoners orders allow us to move prisoners around the empire. Like can we dump any prisoners on a random body to group them and then bring a transport in to collect them? Which in my mind creates the need for a Prisoner Transport class of ship. :)
If so great. With the way my playstyle is it wouldnt suit to have my warships having to double back to unload their captives at my Naval academy worlds.
-
Love this new, fleshed-out prisoner of war system! Although, the more I think about it, the more I feel that there should also be at least some mechanism in the background for adopting prisoners into your civilization who have been with you for a very long time (as long as you opt into that kind of thing in principle, of course). A small but constant chance of defection for crew that has truly gone native and passed all background checks. I guess I don't want to let people rot in prison for decades with not even a theoretical way out if I'm dealing with an empire that has absolutely no interest in diplomacy at all, but is at the same time too strong to easily conquer.
-
Hooray for better NPRs! ;D ;D ;D
One thing I'm not clear on from the description: do these settings apply to only the NPRs generated at game start, or also those NPRs generated during the gameplay?
-
Hooray for better NPRs! ;D ;D ;D
One thing I'm not clear on from the description: do these settings apply to only the NPRs generated at game start, or also those NPRs generated during the gameplay?
This is only for starting NPRs, although I will probably add something similar to the manual NPR generation too.
Any NPRs created as a result of exploring will be 'normal' single system NPRs. They are generated when a suitable planet is created as a result of system generation (when you or another NPRs explores a JP) and they pass the random chance text. They only exist because their home world was just created. Even if I ran the multi-system process at that point, it wouldn't make sense because they would have already explored the system you entered from and you would have met them sooner. Plus every time you would find their home world first.
The only way to really generate multi-system NPR post-start would be to generate them randomly as the game progressed. Either stand-alone in systems no one found yet, or via a tiny chance for each new system being the edge of their Empire, which would entail generating them standalone and then connecting an 'outer-ring' jump point to the system you just explored - which would be odd in Known Stars games as it would likely be an abnormal jump distance.
The better option is generating several multiple-system NPRs at game start, probably further out than normal, so you can meet them more naturally.
-
Even if I ran the multi-system process at that point, it wouldn't make sense because they would have already explored the system you entered from and you would have met them sooner. Plus every time you would find their home world first.
The only way to really generate multi-system NPR post-start would be to generate them randomly as the game progressed. Either stand-alone in systems no one found yet, or via a tiny chance for each new system being the edge of their Empire, which would entail generating them standalone and then connecting an 'outer-ring' jump point to the system you just explored - which would be odd in Known Stars games as it would likely be an abnormal jump distance.
The better option is generating several multiple-system NPRs at game start, probably further out than normal, so you can meet them more naturally.
To be fair there are some situations where it could make sense. For example:
1.) A multi system NPR that just has not explored the JP you arrived to their home system through yet (although logically it would not be a vast empire at that point)
2.) A multi system NPR where the encountered system is not their home system but lets say a secondary colony on a habitable world.
-
Terrific, Steve! :D :D :D
Really thank you!
How many developed NPR empires would be present? just one, ore more?
Will this number depend on the generated NPRs at the game start (let's say, for example: 3 generated --> 1 is large, or 4 gen --> 1 large)?
Or an even more "extreme" hypothesis: chosing larger numbers of generated NPRs, we could face differently large empires: 1 NPR (or even more) generated using the new method, 1 or 2 halving the chosen parameters, 2 or 3 dividing the param by 3 or 4, etc.
So, we can span from some minor races to 1 or more large empires.
Silly suggestion... can we start calling this version 3.0, no more 2.6? ;D
-
Terrific, Steve! :D :D :D
Really thank you!
How many developed NPR empires would be present? just one, ore more?
Will this number depend on the generated NPRs at the game start (let's say, for example: 3 generated --> 1 is large, or 4 gen --> 1 large)?
Or an even more "extreme" hypothesis: chosing larger numbers of generated NPRs, we could face differently large empires: 1 NPR (or even more) generated using the new method, 1 or 2 halving the chosen parameters, 2 or 3 dividing the param by 3 or 4, etc.
So, we can span from some minor races to 1 or more large empires.
Silly suggestion... can we start calling this version 3.0, no more 2.6? ;D
All the NPRs generated at game still will use the same parameters. So if you set base to 2, random to 4 and had eight NPRs, then all eight would be multi-system and would have explored between 3 and 6 transits out. The more variation you want in NPR empire size, the more you weight the result to random rather than base.
For my next campaign, I am considering running a conventional Earth against 6-8 multiple system NPRs with the game research speed set to 25% research speed, to see how long I can last :)
-
Any NPRs created as a result of exploring will be 'normal' single system NPRs. They are generated when a suitable planet is created as a result of system generation (when you or another NPRs explores a JP) and they pass the random chance text. They only exist because their home world was just created. Even if I ran the multi-system process at that point, it wouldn't make sense because they would have already explored the system you entered from and you would have met them sooner. Plus every time you would find their home world first.
The only way to really generate multi-system NPR post-start would be to generate them randomly as the game progressed. Either stand-alone in systems no one found yet, or via a tiny chance for each new system being the edge of their Empire, which would entail generating them standalone and then connecting an 'outer-ring' jump point to the system you just explored - which would be odd in Known Stars games as it would likely be an abnormal jump distance.
I would imagine that, in principle (to say nothing of in practice), it could work well enough with a tweak to the order of events: generate the system, and and if it contains a new NPR then run the new multi-system NPR code, and only then connect the jump point to one of those outlying systems and place the player's fleet at that point instead of in the original system. I think even for known stars games this should be okay as there is some variance in how distant the connections are anyways.
That said, the ability to manually generate new multi-system NPRs would also be great. My main thing really is that I don't want to generate so many starting NPRs to slow the game down at the start, but after a few races have been wiped out it's nice to have some more to keep the game running.
-
...
All the NPRs generated at game still will use the same parameters. So if you set base to 2, random to 4 and had eight NPRs, then all eight would be multi-system and would have explored between 3 and 6 transits out. The more variation you want in NPR empire size, the more you weight the result to random rather than base.
For my next campaign, I am considering running a conventional Earth against 6-8 multiple system NPRs with the game research speed set to 25% research speed, to see how long I can last :)
Thank you!
Much better than my hypothesis, as we can face a random preset force in each NPR we meet.
-
Thanks, Steve!
I asked about pre-developed NPRs quite a while ago, and I’m glad it’s finally happening! This has been one of the main reasons I would often create and control random alien factions myself.
It feels like I’ll finally be able to enjoy a long solo campaign once 2.6 drops—or maybe after one or two exterminators' patches.
-
I hope this will also work with the customize NPRs feature, particularly if and when Steve makes it possible to do this in the middle of the game!
-
Multi-System Starting NPRs
*Halo Theme starts playing*
-
Any NPRs created as a result of exploring will be 'normal' single system NPRs. They are generated when a suitable planet is created as a result of system generation (when you or another NPRs explores a JP) and they pass the random chance text. They only exist because their home world was just created. Even if I ran the multi-system process at that point, it wouldn't make sense because they would have already explored the system you entered from and you would have met them sooner. Plus every time you would find their home world first.
The only way to really generate multi-system NPR post-start would be to generate them randomly as the game progressed. Either stand-alone in systems no one found yet, or via a tiny chance for each new system being the edge of their Empire, which would entail generating them standalone and then connecting an 'outer-ring' jump point to the system you just explored - which would be odd in Known Stars games as it would likely be an abnormal jump distance.
The better option is generating several multiple-system NPRs at game start, probably further out than normal, so you can meet them more naturally.
You don't need to specify a chance for a newly explored system to be an edge system to trigger multi-system NPR generation.
You could trigger in-game NPR generation the same way you do now, when a suitable planet is present in a newly explored and randomly generated system, and the random chance succeeds.
(Because, as you say, you can at that point generate a full multisystem NPR and link this jump point to an edge system instead of the home system.)
So the overall prevalence of in-game NPRs won't change. They'll just start living and breathing well before you reach their home system, and you won't even be aware when you trigger the creation of one. You'll just see another normal system.
-
Any NPRs created as a result of exploring will be 'normal' single system NPRs. They are generated when a suitable planet is created as a result of system generation (when you or another NPRs explores a JP) and they pass the random chance text. They only exist because their home world was just created. Even if I ran the multi-system process at that point, it wouldn't make sense because they would have already explored the system you entered from and you would have met them sooner. Plus every time you would find their home world first.
The only way to really generate multi-system NPR post-start would be to generate them randomly as the game progressed. Either stand-alone in systems no one found yet, or via a tiny chance for each new system being the edge of their Empire, which would entail generating them standalone and then connecting an 'outer-ring' jump point to the system you just explored - which would be odd in Known Stars games as it would likely be an abnormal jump distance.
The better option is generating several multiple-system NPRs at game start, probably further out than normal, so you can meet them more naturally.
You don't need to specify a chance for a newly explored system to be an edge system to trigger multi-system NPR generation.
You could trigger in-game NPR generation the same way you do now, when a suitable planet is present in a newly explored and randomly generated system, and the random chance succeeds.
(Because, as you say, you can at that point generate a full multisystem NPR and link this jump point to an edge system instead of the home system.)
So the overall prevalence of in-game NPRs won't change. They'll just start living and breathing well before you reach their home system, and you won't even be aware when you trigger the creation of one. You'll just see another normal system.
Yes, that's an interesting idea. The potential downside is that in known space games, its likely the system from which the exploration is launched is a lot closer to the new home world in real space than the edge system to which the link is redirected, which might have some odd results for future connections - like any jump point explorations from existing systems close to the newly generated area (in JP terms) are more likely to connect to the centre of that area (as its closer in real space). Although only about 1 in 15 systems link to existing so it may not be very noticeable.
-
...The potential downside is that in known space games, its likely the system from which the exploration is launched is a lot closer to the new home world in real space than the edge system to which the link is redirected, which might have some odd results for future connections - like any jump point explorations from existing systems close to the newly generated area (in JP terms) are more likely to connect to the centre of that area (as its closer in real space). Although only about 1 in 15 systems link to existing so it may not be very noticeable.
Probably unlikely to be noticed, as you say.
But even if you decide that generating multisystem NPRs after game start is only feasible in non-real-stars games--still, there would be much rejoicing.
Songs are written about such things.
-
Yes, that's an interesting idea. The potential downside is that in known space games, its likely the system from which the exploration is launched is a lot closer to the new home world in real space than the edge system to which the link is redirected, which might have some odd results for future connections - like any jump point explorations from existing systems close to the newly generated area (in JP terms) are more likely to connect to the centre of that area (as its closer in real space). Although only about 1 in 15 systems link to existing so it may not be very noticeable.
Given that most players don't exactly have a star map of the Milky Way embedded in memory, I suspect in most cases it would not be noticeable at all. ;)
-
One other potential issue with in-game creation occurred to me. With the at-start creation, there are no aliens generated in the NPR territory. There can be ruins and ancient constructs, but without precursors. The starting NPR will setup research colonies if there are constructs.
I would use the same principle for in-game creation, because having precursor systems (for example) between the home world and a major colony wouldn't make sense.
However, this opens up potentially large ruins without precursors for the player to exploit, although there would probably be some NPR defenders. I'm not sure this is necessarily a problem, but it would be different than a standard game.
-
Yes, that's an interesting idea. The potential downside is that in known space games, its likely the system from which the exploration is launched is a lot closer to the new home world in real space than the edge system to which the link is redirected, which might have some odd results for future connections - like any jump point explorations from existing systems close to the newly generated area (in JP terms) are more likely to connect to the centre of that area (as its closer in real space). Although only about 1 in 15 systems link to existing so it may not be very noticeable.
Given that most players don't exactly have a star map of the Milky Way embedded in memory, I suspect in most cases it would not be noticeable at all. ;)
No, its not that. If you discover a new NPR with a radius of 6 transits, you end up connecting to a rim system. Any other jump points you explore from the initial system (or one nearby but not in NPR space) have a much greater chance of connecting to the NPR home system, or one of the core systems, rather than another edge system. That's on a per-system basis, so given there will be a lot more edge systems than core system it might not be an issue.
-
One other potential issue with in-game creation occurred to me. With the at-start creation, there are no aliens generated in the NPR territory. There can be ruins and ancient constructs, but without precursors. The starting NPR will setup research colonies if there are constructs.
I would use the same principle for in-game creation, because having precursor systems (for example) between the home world and a major colony wouldn't make sense.
However, this opens up potentially large ruins without precursors for the player to exploit, although there would probably be some NPR defenders. I'm not sure this is necessarily a problem, but it would be different than a standard game.
As long as the NPR has appropriate xeno and survey ground units on-site, I would expect them to exploit most of those ruins before the player can survey to that area, especially if the ruins are on the "far side" of the generated jump network. That leaves a potentially vulnerable construct, but that's not much different from the situation with existing NPR empires anyways except that it might be better-defended if anything.
-
Man I love the idea of having this for explored NPRs... (Not that having it for starting NPRs isn't great on its own :) )
I don't think it needs to be perfectly balanced if this would take a bunch of extra work. Just having the option available, even with a few oddities, would be amazing!
I sometimes like playing with no starting NPRs and NPR exploration chance at 0. Then turn up the exploration chance once I've built up an established multi-system empire. Great if I feel like more of a sprawling space opera game. Being able to set it up so that the NPRs that got generated later on were big established empires would be absolutely incredible...
-
Could you use the same mechanic as a Player race game start option as well? Give us an option to start at an early-mid game empire level without having to spend hours spacemastering a similar setup.
Also, I think one way you could get non-game start NPR empires to work is that when a new race is generated and designated as an empire, that race explores all jumppoints in that system and then randomly picks ONE! that is not the JP the discovering race entered through, to then back explore. It continues to explore only one jump point back in a chain length based on the empire radius, until it discovers another suitable homeworld and from there it will spiderweb back out using the regular empire generator. A few caveats: (1) If no suitable world is found within the jump chain once it reaches its limit, one will be generated (2) If a JP leads to an already known system of any race, it stops exploring beyond the exit JP (3) If the initial chain ends up being a dead end before reaching its max length, it can go back one system and explore another JP
-
Could you use the same mechanic as a Player race game start option as well? Give us an option to start at an early-mid game empire level without having to spend hours spacemastering a similar setup.
Also, I think one way you could get non-game start NPR empires to work is that when a new race is generated and designated as an empire, that race explores all jumppoints in that system and then randomly picks ONE! that is not the JP the discovering race entered through, to then back explore. It continues to explore only one jump point back in a chain length based on the empire radius, until it discovers another suitable homeworld and from there it will spiderweb back out using the regular empire generator. A few caveats: (1) If no suitable world is found within the jump chain once it reaches its limit, one will be generated (2) If a JP leads to an already known system of any race, it stops exploring beyond the exit JP (3) If the initial chain ends up being a dead end before reaching its max length, it can go back one system and explore another JP
This kind of process occurred to me as well, when you described the issues with creating multi-system empires in Real Stars games. You could keep the system that you rolled the NPR generation in as a non-homeworld and take a 'pathfinding' approach with system generation to find the homeworld, then generate the empire from there as normal. In this case, there is no reason why you wouldn't be able to run into a new NPR in a Starless Nexus, even, so instead of NPR having a, say 25% chance of generating for each habitable world you find, you would instead have a 0.5% of generating one for each SYSTEM you find.
If the system fails to find a habitable world in the X jumps you specify, you can either abort the NPR generation process, pretend it never happened, or delete everything and try again. Or some combined method where you do, say, 5 retries and if none succeed, cancel it, delete the generated systems and skip NPR generation.
-
Could you use the same mechanic as a Player race game start option as well? Give us an option to start at an early-mid game empire level without having to spend hours spacemastering a similar setup.
Also, I think one way you could get non-game start NPR empires to work is that when a new race is generated and designated as an empire, that race explores all jumppoints in that system and then randomly picks ONE! that is not the JP the discovering race entered through, to then back explore. It continues to explore only one jump point back in a chain length based on the empire radius, until it discovers another suitable homeworld and from there it will spiderweb back out using the regular empire generator. A few caveats: (1) If no suitable world is found within the jump chain once it reaches its limit, one will be generated (2) If a JP leads to an already known system of any race, it stops exploring beyond the exit JP (3) If the initial chain ends up being a dead end before reaching its max length, it can go back one system and explore another JP
The problem with trying to generate a new similar home world is that a species is based on its home world environment, so finding another exact match is very unlikely.
If I do go down this route, I will use Skoormit's suggestion, as that is very straightforward. Essentially, once a home world is discovered, break the link from the 'exploring' system, generate the Empire, and then link the exploring system to a system on the edge of the NPR Empire. For known systems, I would probably order them in real space distance and then link one of the closest ones.
-
I've added multi-system NPRs post-start. This does lead to a slight problem, which is a likely pause for a few seconds while a multi-system NPR is generated. That pause between transit and arrival can effectively warn a player than an NPR has been created. Therefore I was wondering whether to add random pauses to some system generations, to make it less obvious when something is actually happening. Or would this just be annoying?
-
I feel random pauses could become annoying if long turn calculations (in mid- and end-game phases) will disappear.
Otherwise, no, they could be acceptable.
Please, an explanation and a question about post-start multi-system NPR.
Requested explanation: If we want large multisystem empire(s) at start, we set non zero values for at least one of NPR Base Explored Transits, NPR Random Explored Transits and NPR Max Start Systems parameters.
But this new addiction will also cause generation of post-start multi-system NPRs. So, I understand that we will never again meet single system NPRs, apart minor races: is it correct?
Question: how many systems will each post-start NPR control/know?
-
I feel random pauses could become annoying if long turn calculations (in mid- and end-game phases) will disappear.
Otherwise, no, they could be acceptable.
Please, an explanation and a question about post-start multi-system NPR.
Requested explanation: If we want large multisystem empire(s) at start, we set non zero values for at least one of NPR Base Explored Transits, NPR Random Explored Transits and NPR Max Start Systems parameters.
But this new addiction will also cause generation of post-start multi-system NPRs. So, I understand that we will never again meet single system NPRs, apart minor races: is it correct?
Question: how many systems will each post-start NPR control/know?
If you set all the parameters to zero, you will have single-system NPRs. If you set either the Base Explored or Random Explored to a positive number, you will have multi-system NPRs. The Minor Race option is checked first during race generation, so if you set that parameter, you will still have minor races with one system in a game with otherwise multi-system NPRs.
You can change the parameters at any time, so you could generate multi-system NPRs at start and then just set everything to zero.
If you want some small NPRs and some large, leave the Base at zero and only use Random.
The number of systems per NPR will depend on a combination of the parameter settings and the systems generation. For example, if you set Base to 5 and Random to zero, an NPR will do five rounds of outward jump point exploration. It might only have a few systems. It might find a hundred or more. The Max Systems option is for you to control that upper number if desired.
-
Thank you, Steve.
I can't wait to test these new mechanics!
-
I've added multi-system NPRs post-start. This does lead to a slight problem, which is a likely pause for a few seconds while a multi-system NPR is generated. That pause between transit and arrival can effectively warn a player than an NPR has been created. Therefore I was wondering whether to add random pauses to some system generations, to make it less obvious when something is actually happening. Or would this just be annoying?
In the existing 2.5.1 game I already experience a pause of sufficient length during transit of an unexplored jump point to warn me of a newly generated NPR when that occurs; as such, from my perspective, a pause of a few seconds to generate a multi-system NPR changes nothing.
That said, I would personally be in favor of a slight pause each time a new system is explored by the player. As long as the pause is no more than a few seconds it shouldn't be terribly disruptive while providing a greater air of mystery and the potential for truly unexpected encounters. Otherwise we have perfect knowledge that down that road lies a potential danger, making the ultimate encounter anti-climactic.
It's hard to tell how it'll 'feel' unless or until it's implemented, and if it feels too irritating during your own play testing or the feedback given by other players upon release it could be easily removed or altered.
-
Agree with Ragnarsson with the pause, couple of seconds more, randomly generated toward some system generation is nothing, definitely better that knowing for sure that I have a NPR ahead which would eliminate all the flavour of exploration and mystery.
-
I am strongly against implementing mandatory pauses, even if they are random. We already have a God like awareness of the game, adding something like that would just be annoying. I know I never time the system generation so I wouldn't know either way.
-
I've added multi-system NPRs post-start. This does lead to a slight problem, which is a likely pause for a few seconds while a multi-system NPR is generated. That pause between transit and arrival can effectively warn a player than an NPR has been created. Therefore I was wondering whether to add random pauses to some system generations, to make it less obvious when something is actually happening. Or would this just be annoying?
Once the NPR home system is generated but before the rest of calculations occur, would it be possble to generate an additional buffer system between the system from which the exploration took place and the system(s) that will become the rim of NPR territory, then reveal that system to the player while "caching" the NPR home system? The delay would be barely noticeable then, and all the other calculations concerning NPR territory, colony and fleet generation can then occur afterwards during the next construction cycle, when some delay is to be expected (at least when DB gets large enough), and a jump point linking the buffer system to the NPR's frontier will be created.
For further subversion of expectations it could also be delayed to happen randomly during one of the next several construction cycles, or maybe during one of the next several JP explorations which might happen anywhere else in the galaxy. If the buffer system happens to get a full gravitational survey by then, the jump point to NPR territory can be generated as dormant, further adding to the element of surprise.
Wouldn't it be horrifying if Swarm could be generated in a similar way?
-
Ooof, no mandatory pauses please! My personal Aurora experience is usually a very curated one, where I often generate and regenerate new systems until I have something that looks narratively interesting - I do care more about that than about being properly surprised. If there turns out to be widespread desire for such a feature, maybe add it via a checkbox at world creation so that everyone can be happy?
-
I've added multi-system NPRs post-start. This does lead to a slight problem, which is a likely pause for a few seconds while a multi-system NPR is generated. That pause between transit and arrival can effectively warn a player than an NPR has been created. Therefore I was wondering whether to add random pauses to some system generations, to make it less obvious when something is actually happening. Or would this just be annoying?
You could pre-create them.
On game load, or whenever the associated game settings change, go ahead and create the next NPR and all of its systems.
Just don't give the systems any IDs yet, and don't link to any existing system (obviously).
When an NPR is "discovered" during system gen, use this "green room" NPR.
That's probably the easy bit. The hard bit is making another "green room" NPR after you use the first one, without causing noticeable slowdown.
You could probably just tack something on to the end of con cycle processing:
If the "green room" NPR does not have all systems generated, create the next system for it. (But just one system per con cycle.)
Most of the time, of course, the next NPR is fully created and ready to go, so this extra bit doesn't fire.
When it does fire, creating a single system per con cycle will probably not cause a noticeable increase in processing time.
-
I've added multi-system NPRs post-start. This does lead to a slight problem, which is a likely pause for a few seconds while a multi-system NPR is generated. That pause between transit and arrival can effectively warn a player than an NPR has been created. Therefore I was wondering whether to add random pauses to some system generations, to make it less obvious when something is actually happening. Or would this just be annoying?
You could pre-create them.
On game load, or whenever the associated game settings change, go ahead and create the next NPR and all of its systems.
Just don't give the systems any IDs yet, and don't link to any existing system (obviously).
When an NPR is "discovered" during system gen, use this "green room" NPR.
That's probably the easy bit. The hard bit is making another "green room" NPR after you use the first one, without causing noticeable slowdown.
You could probably just tack something on to the end of con cycle processing:
If the "green room" NPR does not have all systems generated, create the next system for it. (But just one system per con cycle.)
Most of the time, of course, the next NPR is fully created and ready to go, so this extra bit doesn't fire.
When it does fire, creating a single system per con cycle will probably not cause a noticeable increase in processing time.
That won't work for Known Systems. What might be possible is to create a 'frozen NPR' that doesn't do anything until you enter one of its systems and then it wakes up. Either way, that would be a LOT of work to find every place where a race should do nothing instead of something.
I may just add the random pauses as an option then people can choose to use them or not.
-
I've added multi-system NPRs post-start. This does lead to a slight problem, which is a likely pause for a few seconds while a multi-system NPR is generated. That pause between transit and arrival can effectively warn a player than an NPR has been created. Therefore I was wondering whether to add random pauses to some system generations, to make it less obvious when something is actually happening. Or would this just be annoying?
You could pre-create them.
On game load, or whenever the associated game settings change, go ahead and create the next NPR and all of its systems.
Just don't give the systems any IDs yet, and don't link to any existing system (obviously).
When an NPR is "discovered" during system gen, use this "green room" NPR.
That's probably the easy bit. The hard bit is making another "green room" NPR after you use the first one, without causing noticeable slowdown.
You could probably just tack something on to the end of con cycle processing:
If the "green room" NPR does not have all systems generated, create the next system for it. (But just one system per con cycle.)
Most of the time, of course, the next NPR is fully created and ready to go, so this extra bit doesn't fire.
When it does fire, creating a single system per con cycle will probably not cause a noticeable increase in processing time.
That won't work for Known Systems. What might be possible is to create a 'frozen NPR' that doesn't do anything until you enter one of its systems and then it wakes up. Either way, that would be a LOT of work to find every place where a race should do nothing instead of something.
I may just add the random pauses as an option then people can choose to use them or not.
I already got those pauses as my pc is not that grat atm, and so far have not impacted my gameplay even if I knew "something was going on".
-
...would be a LOT of work to find every place where a race should do nothing instead of something.
Just firing from the hip: can you create an NPR_Frozen object that has all the properties of an NPR (or perhaps just the subset of properties necessary so that the processing time incurred upon "discovery" is not noticeable), but that is not kept in the list of live NPRs that the game processes each increment?
(I don't think you even need to store such an object in the database--it does not need to persist through a game close->reopen cycle, since you will make a new one on game load.)
But I'm not pushing for this at all. Just throwing it at the wall in case it sticks. A game option to add camouflage pauses is a very good solution as well.
-
Okay I can not wait for 2.6 the NPR changes sound amazing!!
-
...would be a LOT of work to find every place where a race should do nothing instead of something.
Just firing from the hip: can you create an NPR_Frozen object that has all the properties of an NPR (or perhaps just the subset of properties necessary so that the processing time incurred upon "discovery" is not noticeable), but that is not kept in the list of live NPRs that the game processes each increment?
(I don't think you even need to store such an object in the database--it does not need to persist through a game close->reopen cycle, since you will make a new one on game load.)
But I'm not pushing for this at all. Just throwing it at the wall in case it sticks. A game option to add camouflage pauses is a very good solution as well.
An NPR covers many different database tables, all of which expect a corresponding RaceID, so its not really an option.
-
One idea I had for dealing with pausing tipping players off about NPR generation would be to change when it occurs. What if the system discovery and mid-game NPR gen worked like this:
1. A ship enters a new system, System A, for the first time.
2. All jump points in System A are decided, though not shown to that race until they're found via surveys or someone else transiting them. Play continues normally.
3. In the background during normal play, the systems on the far side of each of System A's jump points are genned, including any necessary NPR creation.
There's no need to worry about someone jumping across a jump point with nothing ready on the far side because there is plenty of time to gen everything while the player surveys System A. You could easily spread the system and NPR genning out over many increments and no player will ever notice.
-
One idea I had for dealing with pausing tipping players off about NPR generation would be to change when it occurs. What if the system discovery and mid-game NPR gen worked like this:
1. A ship enters a new system, System A, for the first time.
2. All jump points in System A are decided, though not shown to that race until they're found via surveys or someone else transiting them. Play continues normally.
3. In the background during normal play, the systems on the far side of each of System A's jump points are genned, including any necessary NPR creation.
There's no need to worry about someone jumping across a jump point with nothing ready on the far side because there is plenty of time to gen everything while the player surveys System A. You could easily spread the system and NPR genning out over many increments and no player will ever notice.
Deferring to the construction increment might work, although you do have some weird edge cases where players are SM-exploring systems in batches that could cause problems.
That said, I'm in the camp that doesn't care much if there's a noticeable pause. I hardly notice these things anyways.
-
I'm starting a test campaign with eight multi-system NPRs, using a conventional start with 25% research speed and limited research admin. I suspect I might get into difficulty at some point :)
-
If this was a java project I'd probably just make a way to save and load a pre generated NPR from Json, either as a file on disk or as a blob in a table. Using a copy of the db classes as a starting point for the json model, some mappers to translate back and forth..
-
I am so excited to see ramming is going to be a thing! Hopefully it gets implemented for players in a fun way, making Triremes in space would be amazing and maybe Steve would revive his Romans go to space AAR
-
The new NPR features look incredible and I am starving to play it :P, but I think We will need time to understand well how they work, for example, is It possible to have a game where multistar NPR and single star NPR are created or have the same random chance to appear during the course of the game?
Or, do these options require a previous setup from us during the game settings?
-
Will the total starting population of a multi-system NPR be scaled the same way that NPR starting populations are currently scaled?
Or will the homeworld be the same population as currently calculated, and any non-homeworld population is just extra for being multi-system?
-
I am really liking this new multi-system NPR. Will an existing NPR in a game have a chance to spawn a multi-system NPR as well or will that be only for the players?
-
I am really liking this new multi-system NPR. Will an existing NPR in a game have a chance to spawn a multi-system NPR as well or will that be only for the players?
Any spawned NPR will follow the multi-system rules, regardless of whether it is triggered by a player or an NPR.
-
Will the total starting population of a multi-system NPR be scaled the same way that NPR starting populations are currently scaled?
Or will the homeworld be the same population as currently calculated, and any non-homeworld population is just extra for being multi-system?
The NPR home world will be generated normally and then the check will be done for multi-system vs single system. If it is multi-system, the populations and mining colonies in the additional systems will be scaled by the home world population. These will be in addition to the originally-generated home world population.
-
The new NPR features look incredible and I am starving to play it :P, but I think We will need time to understand well how they work, for example, is It possible to have a game where multistar NPR and single star NPR are created or have the same random chance to appear during the course of the game?
Or, do these options require a previous setup from us during the game settings?
Post-start, they will follow whatever parameters are set in the game details window. Minor races will always be single-system. Normal NPRs will use the base + random. If you want multi-system but with a wide variety, set the base to 0, with the random positive and have a minor race percentage above zero. So if you have 50% minor, base 0 and random 5, some NPR will be single system, some will be multi-system but only with 1 or 2 radius and some will be 5 radius. At start, you can have both single-system and multi-system by using the Customise NPRs option.
-
I've run about twenty years of a campaign with eight multi-system NPRs, using 3 + 3 for the base / random.
There are 575 systems in the game, with 10 discovered by my conventional player race. About 80% of those are starting systems, with the rest discovered post-start.
There are 110 bodies with populations above 0.1m, 84 colonies with at least one automated mine and 276 with at least one civilian mining complex.
There are over 6000 ships in 2000 fleets. About 60% of the fleets are civilian. I added extra shipping lines to multi-system NPR (1 for every 2 transits), but I think I might remove that and just start them with a single line.
I also noticed a LOT more civilian mining colonies, because the NPRs often start with several systems above 10m pop so it is easier for them to spawn. I think that is fine, as it definitely creates the impression of a more developed Empire.
One minor error popped up, which I fixed. Otherwise, the run was error-free. At this point, I am going to setup a more serious campaign with a TN player race. Maybe Babylon 5, or maybe Enterprise era of Star Trek, both of which lend themselves to single-system player vs developed alien empires.
-
I've run about twenty years of a campaign with eight multi-system NPRs, using 3 + 3 for the base / random.
Steve, sorry: is your player race a multi-system one too?
Is it possible to set some starting parameter so the game can create a multi-system race for the player (if the player likes this option)?
About the other data in your game: I imagine that you have checked the DB, is it right?
Thank you really again and again for your dedication to this creation!!
-
I've run about twenty years of a campaign with eight multi-system NPRs, using 3 + 3 for the base / random.
Steve, sorry: is your player race a multi-system one too?
Is it possible to set some starting parameter so the game can create a multi-system race for the player (if the player likes this option)?
About the other data in your game: I imagine that you have checked the DB, is it right?
Thank you really again and again for your dedication to this creation!!
The player race is single system. Creating your multi-system Empire is straightforward. Just use the explore JP option on the System View.
Yes, the data I gave came from the DB.
-
There are over 6000 ships in 2000 fleets. About 60% of the fleets are civilian. I added extra shipping lines to multi-system NPR (1 for every 2 transits), but I think I might remove that and just start them with a single line.
Holy moly!!! How is the performance with that much stuff in the galaxy?
-
There are over 6000 ships in 2000 fleets. About 60% of the fleets are civilian. I added extra shipping lines to multi-system NPR (1 for every 2 transits), but I think I might remove that and just start them with a single line.
Holy moly!!! How is the performance with that much stuff in the galaxy?
I started to notice it after about 15 years. By 20 years it was maybe 5 seconds for each 1 day increment. That's one reason I am going to remove the extra starting shipping lines.
-
NPR Fighters and Carriers
Thank you, Steve!
Just one word: a gorgeous addiction!!
I really think this is Aurora 3.0. :) :) :)
-
NPRs and Precursors may sometimes deploy carriers and fighters.
Which are the condictions that can trigger the deployment?
-
NPRs and Precursors may sometimes deploy carriers and fighters.
Which are the condictions that can trigger the deployment?
Wait a moment, I missed this update, do NPR and precursor now deploy carriers and fighters?
EDIt: sorry I saw this right now, amazinggggggg!!!
-
Wow, NPR carriers... That's definitely a Christmas present if I ever saw one, haha.
Does "fighter" in this case include FACs or is it only the 500 ton parasite crafts?
-
Wow, NPR carriers... That's definitely a Christmas present if I ever saw one, haha.
Does "fighter" in this case include FACs or is it only the 500 ton parasite crafts?
There are already NPR FACs in the game. This addition is for 500-tons or less fighters, plus the carriers to transport them.
-
Honestly with how things are progressing, once ground support craft are revamped, I think the game will reach a state of something close to perfection.
-
NPR carriers, finally! Certainly something to look forward to. But will NPRs be able to exploit the tactical advantage that parasites offer? I found their approach to combat to be very one-dimensional, literally speaking. Missile fighters are a perfect sneak attack weapon, but it's no good if they will only attack in a straight line from the carriers' direction, because the player will know where the carriers are right away. Will NPR fighters actually respect their fuel range, unlike the rest of their ships? (I've boarded more 0% fuel ships than I could count).
There are already NPR FACs in the game. This addition is for 500-tons or less fighters, plus the carriers to transport them.
I assume this question was in regards to parasite FACs, as NPR FACs in the game behave the same as normal warships.
-
There are already NPR FACs in the game. This addition is for 500-tons or less fighters, plus the carriers to transport them.
I guess I worded it incorrectly. I meant to ask whether the FACs would use the carriers as motherships and operate from them the same way fighters will.
-
For v2.6, NPRs and Precursors may sometimes deploy carriers and fighters. These can be both missile and energy-armed, with carrier designs appropriate for the type of fighter.
Will the fighters be all-purpose ? or is it intended to have a mix of "fighters" and "bombers", to engage enemy fighters, bombers, and larger ships ?
Will NPRs and Precursors use ground-support fighters/other aircraft, so that there is a reason to include AA ground units ?
This is pretty exciting news.
Forget the Battle of the Coral Sea, now we can have the Battle of the Coral Nebula !
-
Fighters will launch only within their operational range and will follow the normal NPR rules regarding refuelling - heading home once fuel is low. There will be both energy and missile fighters. No ground support for now, but I will revamp that mechanics at some point anyway. Theoretically FACs (or larger ships) could now use carriers, if I created an operational group that was setup that way. The AI is coded on strike groups, rather than a particular size.
-
Fighters! Rejoice! Hurrah!
Also - will there be a checkbox in the Customize NPR screen to toggle fighter use for custom empires?
-
Fighters! Rejoice! Hurrah!
Also - will there be a checkbox in the Customize NPR screen to toggle fighter use for custom empires?
There isn't right now, but that makes sense to add.
-
Fighters will launch only within their operational range and will follow the normal NPR rules regarding refuelling - heading home once fuel is low. There will be both energy and missile fighters. No ground support for now, but I will revamp that mechanics at some point anyway. Theoretically FACs (or larger ships) could now use carriers, if I created an operational group that was setup that way. The AI is coded on strike groups, rather than a particular size.
Will the AI also use beam fighters (when using Rail or Gauss) in fleet Point Defense role?
-
Fighters will launch only within their operational range and will follow the normal NPR rules regarding refuelling - heading home once fuel is low. There will be both energy and missile fighters. No ground support for now, but I will revamp that mechanics at some point anyway. Theoretically FACs (or larger ships) could now use carriers, if I created an operational group that was setup that way. The AI is coded on strike groups, rather than a particular size.
Will the AI also use beam fighters (when using Rail or Gauss) in fleet Point Defense role?
That is my intention, although I'll need to see how it works out in practice.
-
Boy god they've discovered Fighter craft!
Seriously amazing work Steve!
-
The AI is coded on strike groups, rather than a particular size.
So some AI doctrines might use their carriers offensively, whereas others might use their carriers defensively ?
so like, one NPR might use carriers to have their fighter groups defending the fleet against missiles and enemy FACs & fighters, whereas a different NPR might have their fighter groups as their main attack method against enemy fleets ?
-
The AI is coded on strike groups, rather than a particular size.
So some AI doctrines might use their carriers offensively, whereas others might use their carriers defensively ?
so like, one NPR might use carriers to have their fighter groups defending the fleet against missiles and enemy FACs & fighters, whereas a different NPR might have their fighter groups as their main attack method against enemy fleets ?
Missile fighters are an offensive weapon. Beam fighters can be used offensively or defensively, depending on the situation. That is a lot easier for humans to determine than AI, but I will try to add something on those lines.
Fighters are not going to be perfect on release. Based on my own testing and player feedback, I will slowly improve their AI over time.
-
Missile fighters are an offensive weapon. Beam fighters can be used offensively or defensively, depending on the situation. That is a lot easier for humans to determine than AI, but I will try to add something on those lines.
Fighters are not going to be perfect on release. Based on my own testing and player feedback, I will slowly improve their AI over time.
It would be cool at some point to have some different levels of risk and aggressiveness of the AI. A good IRL example would be the war in the Pacific where Japan and USA deployed similar assets (like CV fighters) in very different ways and had very different approaches to manage risk on all levels from ship design, strategy down to squad tactics (which Im sure your well aware off based on your latest in depth Japanese Navy inspired AAR).
The prime example would be US Carrier generally using like 50-75% of their planes in a potentially defensive way (CAP/Scouting/Escort) while Japanese Carriers would be more like 25% defensive and 0-5% scouting to maximize Offense and Strikes.
-
Glad to see fighters coming back ;D They could be quite deadly in VB Aurora and it's always fun when the AI manages to turn things around on you.
-
Hi Steve, Is one of the three options for the carrier checkbox something that is mandatory to check when creating a new game or Can we leave all of them unchecked and the game will provide a standard carrier options for the NPR? (with a mix/random carrier/battleship composition)
-
Will NPR's use hangars on ships that aren't really carriers? Like a hangar on a battleship for carrying a couple scouts? What about for boarding parties?
-
The IA can use civil ship for carrier? ( For me to send small and fast ship in other area is the best cost if you not need a fast carrier)
-
Will NPR's use hangars on ships that aren't really carriers? Like a hangar on a battleship for carrying a couple scouts? What about for boarding parties?
Currently, there are no other NPR designs with hangars. If I add some, I will make the necessary adjustments.
-
Hi Steve, Is one of the three options for the carrier checkbox something that is mandatory to check when creating a new game or Can we leave all of them unchecked and the game will provide a standard carrier options for the NPR? (with a mix/random carrier/battleship composition)
After thinking about this question, I've gone back and changed the checkboxes to dropdowns. Each one has options for Random, Yes and No. Random will just follow the normal random generation option, or you can select the outcome using the Yes/No options.
-
Yessss! Nice to see the B5 related name lists! Hybrid carriers make perfect sense for B5 too... Are we going to see you do a B5 run Steve?
-
Yessss! Nice to see the B5 related name lists! Hybrid carriers make perfect sense for B5 too... Are we going to see you do a B5 run Steve?
Yes, that is the plan. A B5 run to test multi-system starts and carriers.
-
I'm seeing some character encoding issues in the B5 Shadows name theme - things like: Oblivion’s Flame
-
I'm seeing some character encoding issues in the B5 Shadows name theme - things like: Oblivion’s Flame
They aren't in the original file, or the game. Looks like some problem with displaying apostrophes when I place them within url tags.
-
I'm seeing some character encoding issues in the B5 Shadows name theme - things like: Oblivion’s Flame
They aren't in the original file, or the game. Looks like some problem with displaying apostrophes when I place them within url tags.
This seems to happen with a few other name themes as well, though I don't have a specific example on hand.
-
I'm seeing some character encoding issues in the B5 Shadows name theme - things like: Oblivion’s Flame
They aren't in the original file, or the game. Looks like some problem with displaying apostrophes when I place them within url tags.
That makes sense - googling for the string ’ indicates, via a helpful person on stack overflow, that this is what you get when you try and interpret the ’ (RIGHT SINGLE QUOTATION MARK - U+2019) in CP-1252 instead of UTF-8.
Unless the forum preview is lying to me, the one I used in the paragraph above is working ok. I'll try uploading one in an attached file. Edit: seems to work.
-
Wooo! Multi kiloton battleriders here we go!
-
Wait. Just want to make sure the Larger Parasites change will allow for 5kton ship to now show up as a parasite. A massive literal Fleet carrier with 300Ktons of hangar bay would allow 10Kton ships to be parasites?
-
Wait. Just want to make sure the Larger Parasites change will allow for 5kton ship to now show up as a parasite. A massive literal Fleet carrier with 300Ktons of hangar bay would allow 10Kton ships to be parasites?
it should allow 100Kton ships as parasites, even one 300Kton ship.
-
Wait. Just want to make sure the Larger Parasites change will allow for 5kton ship to now show up as a parasite. A massive literal Fleet carrier with 300Ktons of hangar bay would allow 10Kton ships to be parasites?
Yes, that's correct.
-
Steve, can We expect the new update by Christmas? :)
-
Steve, can We expect the new update by Christmas? :)
Probably not. We are back on the island in a couple of days after nine months travelling, but we've rented a cottage for three months and our furniture (and my desktop) is still in storage. I'll be looking for a new day job during that time, as I have only been working part-time remote on our travels. Depending on how that goes, we will decide whether to stay on the island, relocate if required for a new job, or spend another year travelling. In cases 1 and 2, I am back on the desktop.
I could do a release on my laptop, but I would need to get the obfuscation working from scratch and I prefer not to mess with it when I have it setup correctly on my desktop. Also, I really need to run a short test campaign for fighters and multi-system NPRs before release.
So very unlikely for Xmas, fairly unlikely (but possible) before March.
-
Nice, waiting for the cool update!
IMMORTAL LORD - I got an idea today about officers and characters, just wanna share it. I really like to get attached to characters so it would be nice to have some of them not dying for age at all (but still dying in battle). So, I was thinking: is it possible to introduce a sort of biological research technology that makes immortal officers, or extend dead age? Let's say not all of them: Just 1-3 per year (depending on technology level researched). In this way we may have some immortal lords, or long live officers, to bring with us in the campaign ;D What do you think?
Edit: I'm not sure about "story character" flag option, it should retain the character in "retired" list and avoid accident or health illness, but still dying for age. I'm not sure about that..
-
IMMORTAL LORD - I got an idea today about officers and characters, just wanna share it. I really like to get attached to characters so it would be nice to have some of them not dying for age at all (but still dying in battle). So, I was thinking: is it possible to introduce a sort of biological research technology that makes immortal officers, or extend dead age? Let's say not all of them: Just 1-3 per year (depending on technology level researched). In this way we may have some immortal lords, or long live officers, to bring with us in the campaign ;D What do you think?
Why not just flag them as story characters so they won't retire or die from accidents?
-
Yes, i do it, but still they die for old age. Don't they? ???
-
Hello. With regards to the larger parasites... Could we see NPRs that utilize larger parasites instead of (or alongside) fighters, with the carrier update?
-
Yes, i do it, but still they die for old age. Don't they? ???
Just need some Frankenstein tech or Zombie tech ;-)
-
The proposed change for Precursors, to have them emerge years afterwards, sounds intriguing.
Would there be a possibility for Xenology or engineer units to discover dormant ground forces or ships, and be able to exploit them in some way ?
Certainly, on bigger ruins, I've found plenty of ship components, possibly enough of the right types to build complete warships. (i.e. fire controls, reactors, beam weapons, engines, jump engines, shield generators, sensors)
-
The proposed change for Precursors, to have them emerge years afterwards, sounds intriguing.
Would there be a possibility for Xenology or engineer units to discover dormant ground forces or ships, and be able to exploit them in some way ?
Certainly, on bigger ruins, I've found plenty of ship components, possibly enough of the right types to build complete warships. (i.e. fire controls, reactors, beam weapons, engines, jump engines, shield generators, sensors)
It's an option, rather than a change. You can still choose to use the original Precursor mechanics.
You won't be able to detect the Precursor ships. The ruins themselves are the indication that something might emerge later. This is on the lines of Necron tomb worlds in WH40k.
-
Really like the Enhance Precursors, but I almost feel they're mechanically different enough to be a fifth spoiler race instead of just an alternative version of the precursors? Call them Ancients maybe? Sleepers?
You could make it so if both options are active there's a 50-50 chance of ruin being trad-precursors or neo-precursors.
-
The change to Precursors makes them much more dangerous and ominous, but also more mechanically distinct from Rakhas which right now are basically Precursors without ships or ruins to loot.
Notably, with Enhanced Precursors on the Rakhas will be the only spoiler that immediately shoots your survey ship out of orbit (unless you discover a system and leave it alone for many years).
-
With the Enhanced Precursors: if I add a ruin in Sol System per GM (or any other race starting system), is there also a chance for an Emergence?
maybe it would be a good idea to make Sol System an exception so that there can no Emergence in Sol System/starting system?
-
Could have that be an option that can ge turned off or on too.
-
With the Enhanced Precursors: if I add a ruin in Sol System per GM (or any other race starting system), is there also a chance for an Emergence?
maybe it would be a good idea to make Sol System an exception so that there can no Emergence in Sol System/starting system?
Manually created ruins don't generate precursors.
-
Additional swarms potentially spawning in unsurveyed systems, how utterly terrifying. I love it! Will new swarms have the same strength as a normal swarm spawn though? Feels like potentially getting several full-strength swarms in a year might be a bit much, but maybe that's the point.
Will the swarms be allied to each other and assist each other, or be neutral, or fight each other? I feel like that's very important.
Also, should the invasion really be a once-per-playthrough thing? Feels like long playthroughs would benefit from additional ones being possible, perhaps with a long cooldown since the last invasion was dealt with and with a large minimum distance to simulate a different tendril of the Swarm entering a different region of space?
-
With the Enhanced Precursors: if I add a ruin in Sol System per GM (or any other race starting system), is there also a chance for an Emergence?
maybe it would be a good idea to make Sol System an exception so that there can no Emergence in Sol System/starting system?
Manually created ruins don't generate precursors.
I don't know if this is still possible, but back in the VB6 days I had a ruin spawn on Mars, not through SM. Can that happen now? If it can, could that ruin spawn Precursors?
-
With the Enhanced Precursors: if I add a ruin in Sol System per GM (or any other race starting system), is there also a chance for an Emergence?
maybe it would be a good idea to make Sol System an exception so that there can no Emergence in Sol System/starting system?
Manually created ruins don't generate precursors.
I don't know if this is still possible, but back in the VB6 days I had a ruin spawn on Mars, not through SM. Can that happen now? If it can, could that ruin spawn Precursors?
Ruins can still spawn in Sol but don't generate precursors either.
-
The enhanced precursors and swarm are interesting. They'll definitely contribute to wanting to spread out your forces instead of keep your battlefleet in Sol, which I'm always in favor of. But it's really hard to picture how challenging they might be without a playtest, which I look forward to.
-
Just to clarify something, with the ground forces capability and training cost...
What happens with empires of multiple species ? Does it just use the local population species to check the criteria ?
Is having a colony where the workforce is housed in orbital stations, then the only way to have a training facility for "Extreme Gravity" ?
-
Every time I see Steve make changes to anything ground forces-related, I get hopeful.
-
Just to clarify something, with the ground forces capability and training cost...
What happens with empires of multiple species ? Does it just use the local population species to check the criteria ?
Is having a colony where the workforce is housed in orbital stations, then the only way to have a training facility for "Extreme Gravity" ?
It uses population species. High gravity would need orbital stations. Low gravity will be fine for normal populations, assuming you can get sufficient population on to a small body.
-
Hmmm, so what happen with the cost if the terrain of a planet changes due to eccentric orbits mid construction of a ground unit? ::)
Edit: Never mind it's determined at construction start... I just can't read
Well it still opens up interesting scenarios where you can train several different ground units with discount if you find the right planet orbit..
-
Added a Non-Combat button to the Formation Templates tab of the Ground Forces window. This allows you to toggle the non-combat status of each Ground Unit Class.
That is such a wonderful small QOL change. I can't even count the amount of times I have forgotten to add the Non-Combat modifier and have had to rebuilt the unit and research again (usually through SM, but still..)
-
Added non-interrupt event for each ground unit unloaded.
Will this impact the Unload All Ground Units order in any way? Dropships currently have no advantage outside of opposed landings which are rarely the best choice since defeating the enemy STO is almost always more economical. If normal troop transports could only unload GUs in batches (with Front Line Defense units being unloaded first, I suppose) then a slowly disembarking force could suffer a few rounds of serious damage before it's fully assembled, and dropships would suddenly become a viable choice for establishing beachheads or even conducting entire invasions without their GUs ever fighting at a disadvantage.
-
Happy to finally see a new entry in the changelog, but I have to confess this is the first change that I personally don't agree with. Low gravity infrastructure always felt like an interesting logistical challenge, since it can't be mass-produced by civilians for free unless one already has a massive LG population (which is hard to accomplish for obvious reasons) and its mineral requirements make it harder to quickly establish a self-expanding colony and complicate mineral logistics in a way that I find enjoyable. Sourcing it is an actual problem even in the late-game, where normal infrastucture needs are quickly met either by civilian production or by leeching it from a nearby terraformed world that no longer needs it. This makes low gravity colonies require a lot more thought to establish than normal ones, but colonizing certain mineral-rich dwarf planets, moons and large asteroids is well worth the extra complexity. All in all, I think this change is a mistake, but it's your game, so you do you.
-
Happy to finally see a new entry in the changelog, but I have to confess this is the first change that I personally don't agree with. Low gravity infrastructure always felt like an interesting logistical challenge, since it can't be mass-produced by civilians for free unless one already has a massive LG population (which is hard to accomplish for obvious reasons) and its mineral requirements make it harder to quickly establish a self-expanding colony and complicate mineral logistics in a way that I find enjoyable. Sourcing it is an actual problem even in the late-game, where normal infrastucture needs are quickly met either by civilian production or by leeching it from a nearby terraformed world that no longer needs it. This makes low gravity colonies require a lot more thought to establish than normal ones, but colonizing certain mineral-rich dwarf planets, moons and large asteroids is well worth the extra complexity. All in all, I think this change is a mistake, but it's your game, so you do you.
I concur with all of this, and will add that this change will make an even more pronounced difference when playing as a race with a higher minimum grav threshold than the default humans (0.1).
I recently started a run with a random race.
Their min grav is 0.23.
Turns out, there are a lot of bodies big enough for atmo but below 0.23g.
I have a LG colony on a body that can hold 1.5b pop.
I have many more in the 200m - 500m range.
Providing the LGI that these colonies need for optimal growth is proving to be quite a challenge, since I can't just get LGI for free as trade goods from the homeworld.
If these colonies merely needed regular infra at twice the usual density, a lot of interesting decisions would go away.
-
I'd like to point out that LG infrastructure is identical to regular infrastructure except for that it costs twice as much (and has the added cost of boronide - thanks skoormit for pointing that out). I also believe it *can* be generated as a trade good from other LG colonies, if not the homeworld - so that 1.5b colony should in theory be a reliable source. The only thing the change does is make it so that regular colonies and low-grav colonies can share some infrastructure, with the stated caveat that the low-grav will need twice as much. Oh - I suppose also cargo requirements would change, needing twice as many shipments of regular infra than low grav infra. So, in terms of colonial deliveries, this is actually an *increase* in cost, if you factor in fuel requirements, for the tradeoff of allowing universal use of regular infrastructure.
It is interesting, I'd say, that gravity is reduced to a binary threshold, rather than a gradual increase in infrastructural requirements. IMO, it'd make more sense to me for gravity to be a factor like hydrosphere or temperature requirements, which scale with the difference in ideal vs. actual values. It's a little weird when there can be a colony with perfect 1.0g and a colony with 1.6g or 0.2g without any mechanical difference between the three.
In terms of gameplay decision - shipping low-grav infrastructure to a colony that requires it isn't a decision. But having to weigh the increased infrastructure cost with all of the *other* competing colonies *is* a decision.
-
I like it for the simplicity and making things easier for civilian freighters, myself.
-
I'd like to point out that LG infrastructure is identical to regular infrastructure except for that it costs twice as much. I also believe it *can* be generated as a trade good from other LG colonies, if not the homeworld - so that 1.5b colony should in theory be a reliable source. The only thing the change does is make it so that regular colonies and low-grav colonies can share some infrastructure, with the stated caveat that the low-grav will need twice as much. Oh - I suppose also cargo requirements would change, needing twice as many shipments of regular infra than low grav infra. So, in terms of colonial deliveries, this is actually an *increase* in cost, if you factor in fuel requirements, for the tradeoff of allowing universal use of regular infrastructure.
It is interesting, I'd say, that gravity is reduced to a binary threshold, rather than a gradual increase in infrastructural requirements. IMO, it'd make more sense to me for gravity to be a factor like hydrosphere or temperature requirements, which scale with the difference in ideal vs. actual gravity on a colony. It's a little weird when there can be a colony with perfect 1.0g and a colony with 1.6g or 0.2g without any mechanical difference between the three.
In terms of gameplay decision - shipping low-grav infrastructure to a colony that requires it isn't a decision. But having to weigh the increased infrastructure cost with all of the *other* competing colonies *is* a decision.
Yes, LG infra can be generated as a trade good, just like regular infra.
You need a very large colony to generate either type in large numbers.
You start off with a very large colony with regular infra.
Hence you can get very large amounts of regular infra for free, right from the start of the game.
You do not start off with a very large LG colony.
You have to grow one yourself, using LGI that you make yourself (or wait a couple centuries for enough free LGI to be provided by the growing colony).
That makes LGI different from regular infra in a far more interesting way than the fact that it costs twice as much and requires Boronide.
-
Happy to finally see a new entry in the changelog, but I have to confess this is the first change that I personally don't agree with. Low gravity infrastructure always felt like an interesting logistical challenge, since it can't be mass-produced by civilians for free unless one already has a massive LG population (which is hard to accomplish for obvious reasons) and its mineral requirements make it harder to quickly establish a self-expanding colony and complicate mineral logistics in a way that I find enjoyable. Sourcing it is an actual problem even in the late-game, where normal infrastucture needs are quickly met either by civilian production or by leeching it from a nearby terraformed world that no longer needs it. This makes low gravity colonies require a lot more thought to establish than normal ones, but colonizing certain mineral-rich dwarf planets, moons and large asteroids is well worth the extra complexity. All in all, I think this change is a mistake, but it's your game, so you do you.
I concur with all of this, and will add that this change will make an even more pronounced difference when playing as a race with a higher minimum grav threshold than the default humans (0.1).
I recently started a run with a random race.
Their min grav is 0.23.
Turns out, there are a lot of bodies big enough for atmo but below 0.23g.
I have a LG colony on a body that can hold 1.5b pop.
I have many more in the 200m - 500m range.
Providing the LGI that these colonies need for optimal growth is proving to be quite a challenge, since I can't just get LGI for free as trade goods from the homeworld.
If these colonies merely needed regular infra at twice the usual density, a lot of interesting decisions would go away.
In terms of gameplay decision - shipping low-grav infrastructure to a colony that requires it isn't a decision. But having to weigh the increased infrastructure cost with all of the *other* competing colonies *is* a decision.
I tend to agree here. I like to play with a reduced gravity tolerance, 0.3--1.7 (just enough to allow full colonization of Mars with CC=0.0). In these games, LG infrastructure becomes a lot more interesting because you can more easily find ways to reuse it, whereas under the default settings LGI is kind of useless once you have enough non-manual mines to make populating asteroids rather needless.
That being said, it's really a minor change which does simplify some micromanagement a little bit, so I'm not strictly opposed either. That said:
It is interesting, I'd say, that gravity is reduced to a binary threshold, rather than a gradual increase in infrastructural requirements. IMO, it'd make more sense to me for gravity to be a factor like hydrosphere or temperature requirements, which scale with the difference in ideal vs. actual gravity on a colony. It's a little weird when there can be a colony with perfect 1.0g and a colony with 1.6g or 0.2g without any mechanical difference between the three.
This is interesting and I think a great opportunity with the posted change. Consider having a gravitational tolerance window which is smaller than currently but contributes to colony cost on a sliding scale rather than a binary scale.
For example, suppose humans are given a default gravitational tolerance of ±0.30. Then let
- Within ±1 tolerance width implies CC=0.0 from gravitational effects. So bodies in a range from 0.70--1.30 have no difficulty due to gravity.
- Outside this window, scale linearly with multiples of tolerance away from the window.
- For example, a planet with G=0.4 or G=1.6 has CC=1.0 from gravity.
- A planet with G=0.1 or G=1.9 has CC=2.0 from gravity.
And so on. This would make infrastructure more necessary as terraforming alone will create fewer ideal worlds (e.g., not Mars) and make species gravity more interesting, since different species might have different ideal world types and be more willing to share space (bonus if the AI can be taught to share systems with other races, especially if the different races colonize different bodies).
-
...
And so on. This would make infrastructure more necessary as terraforming alone will create fewer ideal worlds (e.g., not Mars) and make species gravity more interesting, since different species might have different ideal world types and be more willing to share space (bonus if the AI can be taught to share systems with other races, especially if the different races colonize different bodies).
I agree with @nuclearslurpee. However, I think it would be necessary to look at diplomacy in relation to this.
So we could work on signing a concrete treaty with other empires. Not just drop a DIP ship in their territory and hope for the best.
And on the topic of diplomacy:
Don't let it be vague.
I was thinking on a system where we could "work" on a specific treaty. Assign a diplomat to it.
So that there will be a need to collect enough diplomatic points to be able to attempt to sign such a treaty, with a certain % chance.
It would be possible to extend the “work” on a given treaty thus increasing the chance of signing it.
Exp.
Mining rights for a specific body in another empire territory.
If it could be signed, the other side would ignore civilian ships in a particular system, and colony on a particular body.
Or with addition of a specific tonage of a millitary ships/troops in that system.
I know that it is a huge task... ;D
-
The LG change was to allow civilians to better contribute to LG worlds and make the AI better at building up LG worlds. It is already produced by colonies like standard infrastructure but, as mentioned above, on a much smaller scale since you don't start with a large LG colony.
I do like the idea of a narrower standard gravity range and applying a gradual colony cost for gravity, rather than the x2 past a specific point. That would also work for higher gravity worlds, that are currently not habitable at all.
-
I think gravity has an on/off effect.
In real life, low gravity causes big troubles to bones and muscles. So, in terms of colonizations, it should be avoided (by a not genetically modified population).
On the other hand, we know the problems of airplanes pilots at high-g values. So, it should be avoided too.
Outside the gravity tolerance window, no colonization should be possible (again, for a not genetically modified population). While, within this window, some gradual difficulty (and cost) can be foresee, to apply to infrastructure (for example, to dig caves for LG, or be more resistant for HG).
In science fiction terms, in alternative or in parallel to genetics, we could eventually imagine an inertia/gravity generator or suppressor, more expensive (in research and cost) than infrastructures, to colonize LG or HG bodies (the generator is implicitly already present in the game, in the ships engaged in long time duties, to preserve crews from LG effects).
-
...
In science fiction terms, in alternative or in parallel to genetics, we could eventually imagine an inertia/gravity generator or suppressor, more expensive (in research and cost) than infrastructures, to colonize LG or HG bodies (the generator is implicitly already present in the game, in the ships engaged in long time duties, to preserve crews from LG effects).
I think the lore is that trans-Newtonian tech works in gravity, but not quite as well, with diminishing returns for even higher gravity. So while we can compensate for low G, we can't compensate for high G. As such, the ability to mitigate LG with twice as much regular infra makes sense. It takes more effort because we have to use gravity generators, which take more power, etc.
-
The LG change was to allow civilians to better contribute to LG worlds and make the AI better at building up LG worlds.
I guess I don't understand.
Civvies already contribute to LG worlds just like normal worlds.
When space is available for colonists, they will move them there.
They are constrained by availability of infrastructure, just like they are with any other trade good.
You can always build your own LGI and give the civvies contracts to move it. They treat it the same as any other contract.
It's just that regular infra is available as a trade good in large numbers from the very start of the game, and is demanded immediately, and more or less inexhaustibly, by all of your colonies (until you tell them to stop or they reach their population capacity).
The fact that LG colonies can't benefit from that source of free infra is a feature, not a flaw.
The gradual creation of a large LG colony is a worthwhile long-term megaproject, on par with de-centralizing production or turning Luna into a galactic banking center or turning Mars into your primary ground force training colony.
If LG colonies merely need twice as much regular infra, instead of their own kind of infra, then LG colonies start to seem barely different from regular colonies at all.
-
Removal of LG infra was supposed to help NPR's to colonize LG worlds. It's a negligible change from players POV, but colossal help to NPR's. I for one welcome this change.
-
It's just that regular infra is available as a trade good in large numbers from the very start of the game, and is demanded immediately, and more or less inexhaustibly, by all of your colonies (until you tell them to stop or they reach their population capacity).
The fact that LG colonies can't benefit from that source of free infra is a feature, not a flaw.
It absolutely is on the player's part, but it is my understanding that the AI is simply incapable of using its construction factories to manufacture infrastructure for its LG colonies (it seems to struggle with industrial projects in general, at least from what my recent checkups of the respective DB table tells me, perhaps it gets its new installations from elsewhere?). In this case, this change would be mainly aimed at making things easier for the AI, which I would wholeheartedly support, but not at the expense of robbing the LG colonies of their uniqueness.
Perhaps the solution is to allow NPR civilian industry to manufacture small amounts of LG infrastructure on non-LG worlds in addition to their normal output? This would allow the NPRs to grow their colonies while retaining interesting choices for the player. If the goal is to keep things "fair", this could be extended to player civilians, as a game option, although I don't see this being necessary. I guess there's a danger of the AI getting confused by two types of civilian infrastructure of one world, but surely that won't present a significant problem, the AI seems to handle proper installation and trade goods assignment well enough already.
In either case, anything that helps NPRs get better at growing new colonies is welcome, they're severely lacking in that department as of now, but such changes should not diminish the player experience if at all possible.
-
I'm not sure if this is a bug, or not. But since civilian shipping lines are being reworked for 2.6, I felt I should probably mention it here, rather than in the bugreport thread.
My current game, there are some NPRs that have given trade access, and I also have trade access to them, but I can't purchase fuel from their civilian harvesters.
I've not yet seen any naval harvesters, so am unable to check if I can purchase fuel from them either.
I can get fuel from my own civilian harvesters, though it does not generate a distinct entry in the wealth screen, so I am unsure if I have expended any wealth at all, or if it is rolled into the "purchase of civilian minerals" entry for wealth.
So, if you have mutual trade access with a NPR, will you be able to buy fuel from the NPR fuel harvesters, and will it cost wealth that will be separately marked on the wealth screen ?
-
Crew Quarter Design Efficiency
I've added a new tech line called Crew Quarters Design. Researching this tech reduces the amount of space required for crew quarters, by improving the efficiency of the design, so the crew can spend months travelling in relatively small space without feeling cramped. After spending 11 of the last 14 months travelling with my wife in a 25' motorhome, this is a technology I can relate to :)
The levels are similar to fuel efficiency tech and start at 90% for 1000 RP, down to 25% for 120,000 RP. This is a Logistics technology.
Rather curious change, how will the numbers compare to the current system? Will the current baseline be set as 100% efficiency? Because utilizing a quarter of that volume at high tech seems rather low.
I definitely recall seeing suggestions for denser crew quarters on this forum, but I'm rather surprised you chose to approach it this way. If simply setting a lower deployment time is deemed insufficient, research options could provide a way to reduce crew quarter space at the expense of maximum morale or reaction speed, simply dumping RP to dispel your crews' notion of personal space feels rather weird ;D
-
It is also possible to consider 20% of the current hull volume for crew at high tech to be high, after all my crew are downloaded personalities running on the ships computers with a few drone bodies for when needed. As always it is something you can use or not use as it fits your view on the universe of your game
-
It is also possible to consider 20% of the current hull volume for crew at high tech to be high, after all my crew are downloaded personalities running on the ships computers with a few drone bodies for when needed. As always it is something you can use or not use as it fits your view on the universe of your game
Brain-emulated crewmen and officers are a can of worms that I prefer not to touch in my headcanon, since despite providing justification for being able to reassign officers from half a galaxy away, it conflicts with officer and crew casualties being a thing, unless it's somehow impossible to create backups of an uploaded mind. Boarding such ships would need to be viewed differently as well. Not saying you can't still roleplay things that way, but in a vacuum, progressively more compact living spaces seem like an odd tech to have, especially if decoupled from the population density mechanic.
-
I've added a new tech line called Crew Quarters Design. Researching this tech reduces the amount of space required for crew quarters, by improving the efficiency of the design, so the crew can spend months travelling in relatively small space without feeling cramped. After spending 11 of the last 14 months travelling with my wife in a 25' motorhome, this is a technology I can relate to :)
The levels are similar to fuel efficiency tech and start at 90% for 1000 RP, down to 25% for 120,000 RP. This is a Logistics technology.
At a cost of souding like a pain in the ass, does the last sentence mean you finally back home with access to your stable pc and can finally think about releasing this baby?
I bought a telescope last week and finally tried it yesterday evening, watching the moon, I thought about Aurora :'(
-
Crew Quarter Design Efficiency
I've added a new tech line called Crew Quarters Design. Researching this tech reduces the amount of space required for crew quarters, by improving the efficiency of the design, so the crew can spend months travelling in relatively small space without feeling cramped. After spending 11 of the last 14 months travelling with my wife in a 25' motorhome, this is a technology I can relate to :)
The levels are similar to fuel efficiency tech and start at 90% for 1000 RP, down to 25% for 120,000 RP. This is a Logistics technology.
Rather curious change, how will the numbers compare to the current system? Will the current baseline be set as 100% efficiency? Because utilizing a quarter of that volume at high tech seems rather low.
I definitely recall seeing suggestions for denser crew quarters on this forum, but I'm rather surprised you chose to approach it this way. If simply setting a lower deployment time is deemed insufficient, research options could provide a way to reduce crew quarter space at the expense of maximum morale or reaction speed, simply dumping RP to dispel your crews' notion of personal space feels rather weird ;D
Yes, the current baseline will be 100%. The change is intended to allow longer deployment times without prohibitive space requirements. It won't make a lot of difference for ships with low deployment times, as their crew requirements are a much smaller percentage of total hull space anyway.
More efficient use of space is a real concept, not simply a way to 'dump RP to reduce personal space'. Last year two of us lived in about a 20'x7' space for nine months. That space includes a king-sized bed, a shower, a cubicle with toilet and sink, an oven, a three-ring hob, kitchen sink, fridge-freezer, two small couches, a dining table, two seats (driver/passenger), several overhead compartments, plus other storage. It also has 12v and 240v electric systems, plumbing for the two sinks and shower, gas for the over/hob and fridge, central heating, etc.
Yet it always seems like we have plenty of space. That is great design within a limited space - especially as we have been used to living in houses with 5+ bedrooms and multiple, large reception rooms. In fact, we have changed our perspective so much as a result of our time travelling, we are looking for a smaller house, as the previous ones now seem to have a lot of wasted space.
So to the original point, this is a game mechanics change to allow longer duration deployments, particularly for larger ships where the required crew space can be hard to justify vs other systems. Given my own recent experience with how good design can change your perception of space, it seemed like a reasonable way to implement it.
Just for interest, here is the motorhome (and yes, its French :) ).
https://www.rapido-motorhome.co.uk/motorhome_a-class_serie-80df_8096df.chtml
-
I've added a new tech line called Crew Quarters Design. Researching this tech reduces the amount of space required for crew quarters, by improving the efficiency of the design, so the crew can spend months travelling in relatively small space without feeling cramped. After spending 11 of the last 14 months travelling with my wife in a 25' motorhome, this is a technology I can relate to :)
The levels are similar to fuel efficiency tech and start at 90% for 1000 RP, down to 25% for 120,000 RP. This is a Logistics technology.
At a cost of souding like a pain in the ass, does the last sentence mean you finally back home with access to your stable pc and can finally think about releasing this baby?
I bought a telescope last week and finally tried it yesterday evening, watching the moon, I thought about Aurora :'(
No, we are in the motorhome until mid-July, but have sorted a house for at least 12 months after that point.
-
I have no idea how to read that new table with the summaries.
-
I have no idea how to read that new table with the summaries.
The Engines and Fuel line (for example) is just the sum of the specific component lines for engines, jump engines and fuel.
It's optional and off by default, so you ignore if it isn't useful.
-
Grouping component types inspires me to mention something that sometimes strikes me in the ship design window, looking through the components layout in a v2.1.1 campaign I am playing.
Not sure if you have addressed this already in v2.6 but when I am doing sensors for example, hunting high and low for active/EM/TH/ELINT and often wish they were next to each other. Weapons too, gauss rail laser cannonade particle etc and it would make sense to have power plants next door to these, if you see what I mean i.e. having components grouped by class and related purpose, like the way command components are all together.
Alphabetical is usable and logical, as long as you know what the thing you are looking for is called! But if you are adding refinements... just thought this might be worth mentioning.
-
Grouping component types inspires me to mention something that sometimes strikes me in the ship design window, looking through the components layout in a v2.1.1 campaign I am playing.
Not sure if you have addressed this already in v2.6 but when I am doing sensors for example, hunting high and low for active/EM/TH/ELINT and often wish they were next to each other. Weapons too, gauss rail laser cannonade particle etc and it would make sense to have power plants next door to these, if you see what I mean i.e. having components grouped by class and related purpose, like the way command components are all together.
Alphabetical is usable and logical, as long as you know what the thing you are looking for is called! But if you are adding refinements... just thought this might be worth mentioning.
Interesting idea. I could change the component names to (for example) Sensors - Active, Sensors - EM, Sensors - Thermal. Maybe as an alternative option to the existing names.
-
Grouping component types inspires me to mention something that sometimes strikes me in the ship design window, looking through the components layout in a v2.1.1 campaign I am playing.
Not sure if you have addressed this already in v2.6 but when I am doing sensors for example, hunting high and low for active/EM/TH/ELINT and often wish they were next to each other. Weapons too, gauss rail laser cannonade particle etc and it would make sense to have power plants next door to these, if you see what I mean i.e. having components grouped by class and related purpose, like the way command components are all together.
Alphabetical is usable and logical, as long as you know what the thing you are looking for is called! But if you are adding refinements... just thought this might be worth mentioning.
Interesting idea. I could change the component names to (for example) Sensors - Active, Sensors - EM, Sensors - Thermal. Maybe as an alternative option to the existing names.
I don't think a name change is required, perhaps just an extra layer. I.E. current you have type - name, we could move to a category - type - name
The branch view on the ship design will then process
Sensors+
- Active Sensor+
- 2200 Ravelli Systems Active Sensor
- EM Sensor +
- 2200 Ravelli Systems EM Sensor
- TH Sensor +
- 2200 Ravelli Systems TH Sensor
instead of the current
Active Sensor+
- 2200 Ravelli Systems Active Sensor
EM Sensor +
- 2200 Ravelli Systems EM Sensor
TH Sensor +
- 2200 Ravelli Systems TH Sensor
-
Grouping component types inspires me to mention something that sometimes strikes me in the ship design window, looking through the components layout in a v2.1.1 campaign I am playing.
Not sure if you have addressed this already in v2.6 but when I am doing sensors for example, hunting high and low for active/EM/TH/ELINT and often wish they were next to each other. Weapons too, gauss rail laser cannonade particle etc and it would make sense to have power plants next door to these, if you see what I mean i.e. having components grouped by class and related purpose, like the way command components are all together.
Alphabetical is usable and logical, as long as you know what the thing you are looking for is called! But if you are adding refinements... just thought this might be worth mentioning.
Interesting idea. I could change the component names to (for example) Sensors - Active, Sensors - EM, Sensors - Thermal. Maybe as an alternative option to the existing names.
I don't think a name change is required, perhaps just an extra layer. I.E. current you have type - name, we could move to a category - type - name
The branch view on the ship design will then process
Sensors+
- Active Sensor+
- 2200 Ravelli Systems Active Sensor
- EM Sensor +
- 2200 Ravelli Systems EM Sensor
- TH Sensor +
- 2200 Ravelli Systems TH Sensor
instead of the current
Active Sensor+
- 2200 Ravelli Systems Active Sensor
EM Sensor +
- 2200 Ravelli Systems EM Sensor
TH Sensor +
- 2200 Ravelli Systems TH Sensor
Yes, that is exactly the same conclusion I came to as well - working on it right now :)
-
I've been playing around with the categories and currently have this layout. This race doesn't have every type of component, but it has enough to show the principle. I'm not really sure what to do with Command and Control. It seems odd to leave it in its own category, but not sure where to put it. Anyway, I'll take another look in the morning :)
(http://www.pentarch.org/steve/Screenshots/Summary002.png)
-
I've been playing around with the categories and currently have this layout. This race doesn't have every type of component, but it has enough to show the principle. I'm not really sure what to do with Command and Control. It seems odd to leave it in its own category, but not sure where to put it. Anyway, I'll take another look in the morning :)
(http://www.pentarch.org/steve/Screenshots/Summary002.png)
I believe this is a very subjective matter, and there will likely never be 100% agreement on how the categories should be defined. That said, I would approach it with a focus on optimizing the structure of the hierarchy. For example, Command, Engineering, and Life Support could be grouped together under a category like "Core Systems" or "Essential Systems", as they are fundamental to the ship’s operation and survival.
Using the same logic, one might argue that Production, Transport, and Logistics could be grouped under "Support Systems" or "Operational Support", since they relate more to resource handling and auxiliary functions.
I’ll leave the final naming to you, as I’m sure there are even better ways to define and label all components.
EDIT: Back to the quote "I believe this is a very subjective matter, and there will likely never be 100% agreement on how the categories should be defined." maybe a toggle group components may help as those who are used to the old ways can keep using their preferred view. Similar to what is currently setup in the colony view tree.
-
I'm not really sure what to do with Command and Control.
Maybe move Diplomacy Module and Science Department into something like Non-Combat Control.
-
I've been playing around with the categories and currently have this layout. This race doesn't have every type of component, but it has enough to show the principle. I'm not really sure what to do with Command and Control. It seems odd to leave it in its own category, but not sure where to put it. Anyway, I'll take another look in the morning :)
(http://www.pentarch.org/steve/Screenshots/Summary002.png)
I really like this idea and want to encourage it, but also I laughed loudly when I saw that Diplo Modules are under Production :)
-
Yes, the current baseline will be 100%. The change is intended to allow longer deployment times without prohibitive space requirements. It won't make a lot of difference for ships with low deployment times, as their crew requirements are a much smaller percentage of total hull space anyway.
More efficient use of space is a real concept, not simply a way to 'dump RP to reduce personal space'. Last year two of us lived in about a 20'x7' space for nine months. That space includes a king-sized bed, a shower, a cubicle with toilet and sink, an oven, a three-ring hob, kitchen sink, fridge-freezer, two small couches, a dining table, two seats (driver/passenger), several overhead compartments, plus other storage. It also has 12v and 240v electric systems, plumbing for the two sinks and shower, gas for the over/hob and fridge, central heating, etc.
Yet it always seems like we have plenty of space. That is great design within a limited space - especially as we have been used to living in houses with 5+ bedrooms and multiple, large reception rooms. In fact, we have changed our perspective so much as a result of our time travelling, we are looking for a smaller house, as the previous ones now seem to have a lot of wasted space.
So to the original point, this is a game mechanics change to allow longer duration deployments, particularly for larger ships where the required crew space can be hard to justify vs other systems. Given my own recent experience with how good design can change your perception of space, it seemed like a reasonable way to implement it.
Just for interest, here is the motorhome (and yes, its French :) ).
https://www.rapido-motorhome.co.uk/motorhome_a-class_serie-80df_8096df.chtml
I see. Perhaps it's just me never bothering to make long-deployment craft (my 6-month frigates and destroyers allocate around 6% to crewquarters, 1-year capital ships tend to average around 7-8%, 4-year surveyor ships seem to have around 7%) so I never really had any designs that truly suffered from too much crew space. I still feel like having just 2% of a battleship's mass be enough to comfortably sustain its crew for a year might be too low, but on the other hand, I guess building interstellar battleships incapable of operating for more than a year is the unrealistic part? But even with denser crew quarters, one would still have to allocate full space for engineering or maintenance storage, so short deployment times will still result in more effective designs.
I've been playing around with the categories and currently have this layout. This race doesn't have every type of component, but it has enough to show the principle. I'm not really sure what to do with Command and Control. It seems odd to leave it in its own category, but not sure where to put it. Anyway, I'll take another look in the morning :)
(http://www.pentarch.org/steve/Screenshots/Summary002.png)
This is great! Perhaps you could put the Diplomacy Module under "Command" (but outside "Command and Control"), as it does generate a commander slot. Also, having category menus be un-collapsed by default would probably be important since otherwise ship design will gain a lot of extra clicks :)
-
I believe this is a very subjective matter, and there will likely never be 100% agreement on how the categories should be defined. That said, I would approach it with a focus on optimizing the structure of the hierarchy. For example, Command, Engineering, and Life Support could be grouped together under a category like "Core Systems" or "Essential Systems", as they are fundamental to the ship’s operation and survival.
Using the same logic, one might argue that Production, Transport, and Logistics could be grouped under "Support Systems" or "Operational Support", since they relate more to resource handling and auxiliary functions.
I’ll leave the final naming to you, as I’m sure there are even better ways to define and label all components.
EDIT: Back to the quote "I believe this is a very subjective matter, and there will likely never be 100% agreement on how the categories should be defined." maybe a toggle group components may help as those who are used to the old ways can keep using their preferred view. Similar to what is currently setup in the colony view tree.
We seem to be thinking alike. I have had internet issues today (and still can't send or receive much more than text), so not had chance to review the thread, but already moved command and control in with crew and engineering and called it Essential Systems :)
I think production and transport are possibly too large to be a single category, but it does make sense. I am changing the component type descriptions to be more consistent as well, so could prefix those with production. This is the current state of play.
(http://www.pentarch.org/steve/Screenshots/Summary006.png)
-
I might rename "Combat - Energy" to "Combat - Beam". Otherwise looks good to me.
-
The race on the screenshots doesn't have every component type, so here is the list from the database, with the current assignment.
(http://www.pentarch.org/steve/Screenshots/Summary008.png)
(http://www.pentarch.org/steve/Screenshots/Summary009.png)
-
That looks a lot better imho.
-
In my opinion, the Diplomatic Modul belongs more to the group in which Command and Control is (Essential Systems).
-
In my opinion, the Diplomatic Modul belongs more to the group in which Command and Control is (Essential Systems).
Yes, Diplomatic module isn't an easy fit. It isn't really an essential system though as very few ships will have one, while most will have MSP, crew quarters and a bridge.
I put it in production because it produces diplomatic points. Less tangible than minerals or fuel, but it is still creating something that didn't exist before.
-
I'd be tempted to put all the transfer stuff for the different types of cargo all under a single header, but the fuel and ordnance transfer systems would bloat that out massively. Definitely would put the hubs all under the single header of 'hub' though, as there's only 1 hub tech for both ordnance and fuel.
Unless decoy missiles are fundamentally different, I'd shove their launchers under the missile combat header. Yes, even though they are arguably a defensive tool.
IIRC, there's only 1 passenger module, all other colonist transportation is shoving people into cryogenics. Might as well merge the categories.
-
regarding component sorting:
just put engines sensors , defence (shields and armor and decoys) and weapons separately together
command first
everything else last
or if you want to keep alphabet sorting you can name components like SThermal Sensor , SActive Sensor , WGauss , WMissile Launcher - and make function to not display first letter of each string in component list
11/10 im absolutely hyped up for 2.6.0
Carriers for AI finally. and other important stuff, when its going to be released ?
your recent missile changes with DECOYS and decoys on missiles and PD was something that i wanted since first encountering aurora 5 years ago, but your implementation is better than I would recommend
you finally added single ship jump drives (not directly but I also wanted to see long ago)
now my point :
Is there any hope to adding various SHIP IMAGES per class ?
Im btw a little of programmer. Implementation seems more like: image adress maybe string saved to each class, if image not found in files then then default racial image is used.
This can be extended to be used on regular map also, instead of DOTS, and obviously on galactic map.
You already have plenty of images in aurora folders.
Is there any problem with this?
(some things in programming are not that simple for various reasons sometimes)
Additional suggestions:
enable button for NPR AI control over player task group, this can evade lots of micro with fleet combat, i believe this was somehow done in VB Aurora
i found that lots of people claimed that fighters and forward fire directors are not cost effective in planetary bombardment, maybe just give fighters 90% chance to evade AA fire
EDIT: you are srsly a mastermind, I have played or at least tried probably 70% of space 4x games (the more popular ones) since 2000 and your combat mechanics are the best, but also, i like local resource storage, minerals being transported,
But I would also redo / rework various parts of aurora but Im not the author, good luck!
-
regarding component sorting:
just put engines sensors , defence (shields and armor and decoys) and weapons separately together
command first
everything else last
or if you want to keep alphabet sorting you can name components like SThermal Sensor , SActive Sensor , WGauss , WMissile Launcher - and make function to not display first letter of each string in component list
11/10 im absolutely hyped up for 2.6.0
Carriers for AI finally. and other important stuff, when its going to be released ?
your recent missile changes with DECOYS and decoys on missiles and PD was something that i wanted since first encountering aurora 5 years ago, but your implementation is better than I would recommend
you finally added single ship jump drives (not directly but I also wanted to see long ago)
now my point :
Is there any hope to adding various SHIP IMAGES per class ?
Im btw a little of programmer. Implementation seems more like: image adress maybe string saved to each class, if image not found in files then then default racial image is used.
This can be extended to be used on regular map also, instead of DOTS, and obviously on galactic map.
You already have plenty of images in aurora folders.
Is there any problem with this?
(some things in programming are not that simple for various reasons sometimes)
Additional suggestions:
enable button for NPR AI control over player task group, this can evade lots of micro with fleet combat, i believe this was somehow done in VB Aurora
i found that lots of people claimed that fighters and forward fire directors are not cost effective in planetary bombardment, maybe just give fighters 90% chance to evade AA fire
Steve has said for some time that ship images won't be a thing. Part of it is that he wants it to be utterly flexible and up to the imagination of the player. Who's to say that a carrier has to look a certain way? Maybe this carrier isn't a carrier at all. Maybe it's a drone launcher? Anyway, that's what he's said in the past.
-
regarding component sorting:
just put engines sensors , defence (shields and armor and decoys) and weapons separately together
command first
everything else last
or if you want to keep alphabet sorting you can name components like SThermal Sensor , SActive Sensor , WGauss , WMissile Launcher - and make function to not display first letter of each string in component list
11/10 im absolutely hyped up for 2.6.0
Carriers for AI finally. and other important stuff, when its going to be released ?
your recent missile changes with DECOYS and decoys on missiles and PD was something that i wanted since first encountering aurora 5 years ago, but your implementation is better than I would recommend
you finally added single ship jump drives (not directly but I also wanted to see long ago)
now my point :
Is there any hope to adding various SHIP IMAGES per class ?
Im btw a little of programmer. Implementation seems more like: image adress maybe string saved to each class, if image not found in files then then default racial image is used.
This can be extended to be used on regular map also, instead of DOTS, and obviously on galactic map.
You already have plenty of images in aurora folders.
Is there any problem with this?
(some things in programming are not that simple for various reasons sometimes)
Additional suggestions:
enable button for NPR AI control over player task group, this can evade lots of micro with fleet combat, i believe this was somehow done in VB Aurora
i found that lots of people claimed that fighters and forward fire directors are not cost effective in planetary bombardment, maybe just give fighters 90% chance to evade AA fire
Steve has said for some time that ship images won't be a thing. Part of it is that he wants it to be utterly flexible and up to the imagination of the player. Who's to say that a carrier has to look a certain way? Maybe this carrier isn't a carrier at all. Maybe it's a drone launcher? Anyway, that's what he's said in the past.
Sorry but this can be fixed by a toggle button in settings, Use custom Images
edit> but thanks for info !!!
-
-Removed as in the wrong thread-
-
Can you have multiple identical refueling components? Multiple of different types, too? Does something limit how many things can be refueled at once? If I have 80 refueling components can I refuel one thing at 80x speed or up to 80 things at 1x speed?
I don't quite understand how it's supposed to work from the changelog description.
-
Refuelling Changes
Refuelling systems are changed from 500 tons to 1000 tons.
Refuelling Hubs in their current format have been removed from the game. All orders, standing orders and conditional orders relating to refuelling hubs have also been removed.
A new concept called Refuelling Stations has been added.
A ship can transfer fuel at a rate equal to its refuelling rate multiplied by its number of refuelling stations
Any ship with a refuelling system automatically has one Refuelling Station.
The Twin Refuelling Station component is 5000 tons and costs 100 BP. It allows a tanker to refuel at twice the normal rate.
The Quad Refuelling Station component is 20000 tons and costs 400 BP. It allows a tanker to refuel at 4x the normal rate.
The Refuelling Hub component is 80000 tons and costs 1600 BP. It allows a tanker to refuel at 10x the normal rate.
So about this.
Does a ship with multiple refueling systems also have multiple refueling stations? Because if so, it'd be much cheaper to just load up more refueling systems.
And how does this interact with space ports and other planetary infrastructure?
-
You can still only have one refuelling system. I'll edit the post to make that clear.
-
In that case I would encourage switching the refueling systems to a racial tech.
Perhaps one with the following adjustable traits:
Transfer Speed (following current progression of refueling speeds)
Underway Efficiency (following current progression of underway replenishment techs)
Connector Ports (integer number multiplying transfer speeds)
Which combine to calculate the weight/size of the part.
Ships refueling from a space port or similar of course always use the best transfer speed.
-
In that case I would encourage switching the refueling systems to a racial tech.
Perhaps one with the following adjustable traits:
Transfer Speed (following current progression of refueling speeds)
Underway Efficiency (following current progression of underway replenishment techs)
Connector Ports (integer number multiplying transfer speeds)
Which combine to calculate the weight/size of the part.
Ships refueling from a space port or similar of course always use the best transfer speed.
We already have transfer speed and underway efficiency as racial techs. The new component is effectively connector ports.
I've updated the original post to be clearer.
-
By 'racial tech' I mean 'go and design a component with these traits'.
Same as with sensors, weapons, engines, and so on.
-
Very glad to see that we can finally use ordinary tankers to support distant survey fleets as it should have been all along. The arbitrary restriction of standing and conditional orders to only work with Refuelling Hubs was only a source of frustration.
-
So what becomes of the Fighter/FAC Small Refuelling Module?
-
If I'm reading the refueling station changes it becomes more expensive, at least tonnage wise, as it increases? As in it's 1000 tons to refuel 1 ship, 6000 tons to refuel two ships twice as fast (so 1.5x the tonnage per fuel/hour), 21000 tons to fuel two ships 4x as fast (2.6x per fuel/hour), 81000 tons for two ships 10x as fast (4.05x per fuel/hour), and so on. This seems backwards and detrimental to good ship design... is it supposed to be more efficient to use a bunch of smaller tankers?
It's possible I'm misunderstanding the change, otherwise I'd just suggest simplifying it down to only the refueling system and allowing using multiples to improve the transfer rate. So if one refueling system let you transfer 10 liters an hour, two would let you do twenty, and so on. That results in a nice simple system.
-
Yeah I kind of second what bremen said. Why not just have like, three modules:
- One transfers to all.
- One transfers to only one, but is smaller.
- One transfers to only fighters / facs, but does all of them at once and is smaller still.
And you just stack modules to add more transfer rate.
I also am not sure what the thinking is here.
-
Yeah I kind of second what bremen said. Why not just have like, three modules:
- One transfers to all.
- One transfers to only one, but is smaller.
- One transfers to only fighters / facs, but does all of them at once and is smaller still.
And you just stack modules to add more transfer rate.
I also am not sure what the thinking is here.
The first one is the hub module which is getting removed, and I think that's fine. It doesn't add anything from a gameplay perspective once we allow refueling to be additive/multiplicative with additional modules, we simply reach a break point at which the hub becomes more efficient than X number of normal modules.
I like the simple idea of just having refueling modules be stackable - either N modules refuels N ships at once, or N modules refuels N times as fast, either one is fine to me (as long as it doesn't get weird with the increments, like having a 3-hour delay between refueling each ship or something). Same should go for ordnance transfer, of course - frankly, I don't see why all the logistics modules don't work the same way as cargo holds for internal consistency, anyways.
Then we just need two modules: one for big ships and one for fighters/FACs. I don't see a problem with allowing multiple small craft modules, either, since they can only be mounted on small craft - every 50 tons dedicated to an extra refueling module is another 50,000 liters of fuel you can't carry, so it's a fair tradeoff.
-
Thanks for the infinite conditional and standing orders, I am going to push it, I know, but I cannot hold myself.
Any chanche of a "template" system like for standard orders so that we won't need to set same combinations multiple times?
Thanks, still an awesome change, can't wait to use it.
EDIT: Just read the suggestion forum answer from your side, and it seems template are in the works ;D
-
Thanks for the infinite conditional and standing orders, I am going to push it, I know, but I cannot hold myself.
Any chanche of a "template" system like for standard orders so that we won't need to set same combinations multiple times?
Thanks, still an awesome change, can't wait to use it.
EDIT: Just read the suggestion forum answer from your side, and it seems template are in the works ;D
Second on that.
-
Yeah I kind of second what bremen said. Why not just have like, three modules:
- One transfers to all.
- One transfers to only one, but is smaller.
- One transfers to only fighters / facs, but does all of them at once and is smaller still.
And you just stack modules to add more transfer rate.
I also am not sure what the thinking is here.
The first one is the hub module which is getting removed, and I think that's fine. It doesn't add anything from a gameplay perspective once we allow refueling to be additive/multiplicative with additional modules, we simply reach a break point at which the hub becomes more efficient than X number of normal modules.
I like the simple idea of just having refueling modules be stackable - either N modules refuels N ships at once, or N modules refuels N times as fast, either one is fine to me (as long as it doesn't get weird with the increments, like having a 3-hour delay between refueling each ship or something). Same should go for ordnance transfer, of course - frankly, I don't see why all the logistics modules don't work the same way as cargo holds for internal consistency, anyways.
Then we just need two modules: one for big ships and one for fighters/FACs. I don't see a problem with allowing multiple small craft modules, either, since they can only be mounted on small craft - every 50 tons dedicated to an extra refueling module is another 50,000 liters of fuel you can't carry, so it's a fair tradeoff.
I did consider simple 'stackable' refuelling systems, but I was concerned that the refuelling rate technology would become almost irrelevant, unless the individual refuelling systems are made much larger so that a decision to add more is a real choice.
Instead, I went for leaving the current tankers are they are and adding a new component that allows faster refuelling at the expense of size.
Having said that, I accept Bremen's point that my changes in pursuit of that goal will actually create a paradigm where its better to have multiple small tankers in a fleet instead of one large one - which I hadn't considered. In fact, right now you can have multiple small tankers and get around the refuelling rate tech.
Maybe the real problem is that the refuelling rate tech isn't particularly meaningful in small increments anyway. So on reflection, I will change refuelling systems to 2000 tons and allow them to be stackable. I'll start the refuelling tech lower and make the increments more meaningful.
EDIT: BTW, one of the great things about the forum is the collective intelligence that immediately spots inconsistencies that I hadn't considered :)
-
I've modified the refuelling update post in line with the above.
http://aurora2.pentarch.org/index.php?topic=13463.msg173369#msg173369
-
Next update is looking great now! ;D
I might still suggest changing the "Combat - Energy" category to be "Combat - Beam" category, to be consistent.
-
Next update is looking great now! ;D
I might still suggest changing the "Combat - Energy" category to be "Combat - Beam" category, to be consistent.
I choose energy because railguns aren't beams, but I guess we have beam fire controls :)
-
So under the new change, will the Small refueling module still exist for fighters/facs?
-
:) :)Next update is looking great now! ;D
I might still suggest changing the "Combat - Energy" category to be "Combat - Beam" category, to be consistent.
I choose energy because railguns aren't beams, but I guess we have beam fire controls :)
That, and "energy weapon" is a defined research category which notably excludes railguns and Gauss cannons. :)
-
:) :)Next update is looking great now! ;D
I might still suggest changing the "Combat - Energy" category to be "Combat - Beam" category, to be consistent.
I choose energy because railguns aren't beams, but I guess we have beam fire controls :)
That, and "energy weapon" is a defined research category which notably excludes railguns and Gauss cannons. :)
Ah! Excellent point :)
-
Combat - Direct Fire Weapons?
-
Combat - Direct Fire Weapons?
Combat - CLOSE RANGE?!? (https://imgur.com/DdjKcXU)
-
Thanks Steve for these new updates!
The tech progression for the Refuelling Systems from 20k to 900k is it linear?
I think that small increments at the beginning, and larger ones towards the end, could create some subtle intricacies in finding the best balance between the systems to mount on a ship. And would push to invest and improve the tech.
So under the new change, will the Small refueling module still exist for fighters/facs?
Will we use a reduction factor to fit the refuel system to a fighter (like for engines)?
So, in theory, a fighter-tanker could refuel also large ships (rather impractical, but a large fleet of small tankers could).
-
Elated to see the standing orders getting some love, especially with Templates on the way, this was sorely needed! Might I suggest adding a Load Ordnance standing order and/or possibly tucking it under the Replenish Overhaul order as well (so it would add Refuel, Resupply, Load Ordnance followed by Overhaul into the ship order list)? My buoy-deploying survey ships would benefit from it greatly :)
Also, I'm still ruminating about possible ways of making conditional orders interact with conventional order templates for even more automation. One possibility that comes to mind is tweaking the order template UI slightly to allow moving templates up and down in their list and assigning numbers to them then adding conditional orders to execute the template #1-5 in the system where it's triggered. Just a thought!
Another weird quirk of conditionals that comes to mind is their inability to get triggered in sub-3h increments. For most orders this could result in very minor weirdness at most (not knowing for sure which way a Swarm survey ship that just entered the system went because the smallest increment to make it start surveying puts it out of range of your JP buoys) but for more tangentially combat-related ones such as Rescue Lifepod or Activate Sensors/Shields this can be incredibly annoying. If you find yourself needing to pick up 100 lifepods with 10 ships, this takes 30 hours at least, even if they're close enough that manually clicking would get it done in 5 minutes. Would getting rid of the minimum increment length for standing orders be too performance-intensive? (I would also like to bring up my previous suggestion to give diplomacy events the same treatment)
As for the Class Design UI update, this looks lovely, but I think the summaries should be kept out of the ship-specific Wide View section. They actually reduce readability greatly if they're all collapsed by default, and having all those extra lines reduces the threshold for how component-diverse a ship can be before scrolling is necessary to navigate it. I think readability should be prioritized here, and being able to check on every class design's components should require as few clicks as possible, with the old system accomplishing that just fine. Most ship designs don't have so many components that categories for each type would make sense anyway, so if you really want per-ship summaries, then having just the Defense category instead of also having Armour and Shield categories both of which would only ever hold one entry would be more than enough, this would actually result in less lines per screen than we currently have.
-
Thanks Steve for these new updates!
The tech progression for the Refuelling Systems from 20k to 900k is it linear?
I think that small increments at the beginning, and larger ones towards the end, could create some subtle intricacies in finding the best balance between the systems to mount on a ship. And would push to invest and improve the tech.
So under the new change, will the Small refueling module still exist for fighters/facs?
Will we use a reduction factor to fit the refuel system to a fighter (like for engines)?
So, in theory, a fighter-tanker could refuel also large ships (rather impractical, but a large fleet of small tankers could).
The progression for refuelling is 20k, 30k, 40k, 60k, 90k, 135k, 200k, etc.
The small craft version still exists, with half the previous refuelling rate.
-
Clear all Standing & Conditional orders button may be useful.
-
Elated to see the standing orders getting some love, especially with Templates on the way, this was sorely needed! Might I suggest adding a Load Ordnance standing order and/or possibly tucking it under the Replenish Overhaul order as well (so it would add Refuel, Resupply, Load Ordnance followed by Overhaul into the ship order list)? My buoy-deploying survey ships would benefit from it greatly :)
Also, I'm still ruminating about possible ways of making conditional orders interact with conventional order templates for even more automation. One possibility that comes to mind is tweaking the order template UI slightly to allow moving templates up and down in their list and assigning numbers to them then adding conditional orders to execute the template #1-5 in the system where it's triggered. Just a thought!
Another weird quirk of conditionals that comes to mind is their inability to get triggered in sub-3h increments. For most orders this could result in very minor weirdness at most (not knowing for sure which way a Swarm survey ship that just entered the system went because the smallest increment to make it start surveying puts it out of range of your JP buoys) but for more tangentially combat-related ones such as Rescue Lifepod or Activate Sensors/Shields this can be incredibly annoying. If you find yourself needing to pick up 100 lifepods with 10 ships, this takes 30 hours at least, even if they're close enough that manually clicking would get it done in 5 minutes. Would getting rid of the minimum increment length for standing orders be too performance-intensive? (I would also like to bring up my previous suggestion to give diplomacy events the same treatment)
As for the Class Design UI update, this looks lovely, but I think the summaries should be kept out of the ship-specific Wide View section. They actually reduce readability greatly if they're all collapsed by default, and having all those extra lines reduces the threshold for how component-diverse a ship can be before scrolling is necessary to navigate it. I think readability should be prioritized here, and being able to check on every class design's components should require as few clicks as possible, with the old system accomplishing that just fine. Most ship designs don't have so many components that categories for each type would make sense anyway, so if you really want per-ship summaries, then having just the Defense category instead of also having Armour and Shield categories both of which would only ever hold one entry would be more than enough, this would actually result in less lines per screen than we currently have.
I will be adding more standing order options and load ordnance will be included in a 'Replenish' order that is refuel, resupply and load ordnance, plus the Replenish Overhaul order.
I'll move the standings and conditionals into all increments and see how the performance goes.
Diplomacy is tricker, because there are time-related algos, but I agree about the problem. I take advantage myself to sneak through AI systems within the 5-day window :) I'll look at how easy it is to change.
Agree on the class components. I have changed it to group class components only by summary type, without the intermediate component type. I've updated the post.
http://aurora2.pentarch.org/index.php?topic=13463.msg173389#msg173389
-
Clear all Standing & Conditional orders button may be useful.
Added.
-
How will the new standing order templates propagate through to both detaching subfleets and squadrons? I don't actually recall what the current functionality around propagation is though tbh.
-
I will be adding more standing order options and load ordnance will be included in a 'Replenish' order that is refuel, resupply and load ordnance, plus the Replenish Overhaul order.
I'll move the standings and conditionals into all increments and see how the performance goes.
Diplomacy is tricker, because there are time-related algos, but I agree about the problem. I take advantage myself to sneak through AI systems within the 5-day window :) I'll look at how easy it is to change.
Agree on the class components. I have changed it to group class components only by summary type, without the intermediate component type. I've updated the post.
http://aurora2.pentarch.org/index.php?topic=13463.msg173389#msg173389
Great to hear, thank you! If all-increment standing orders don't quite work out, having them trigger in 1 or even 5-minute increments would still be great, honestly having the game run all that logic during shorter increments commonly seen in already performance-intensive naval combat would probably be too much. Also really hoping you'll manage to tweak diplomatic events as well.
How will the new standing order templates propagate through to both detaching subfleets and squadrons? I don't actually recall what the current functionality around propagation is though tbh.
That's a great reminder! Truth is, there is none currently, save for the "Divide Fleet into Single Ships" order which does inherit standing and conditional orders in full. I recall writing a wall of text (https://aurora2.pentarch.org/index.php?topic=13681.msg172081#msg172081) about how great sub-fleets retaining conditional orders will be, this is partially moot given the arrival of standing order templates since manually re-setting them will now be easier, but having all those use cases become possible with sub-fleet standing order retention and a Detach Sub-fleet order is still the dream.
-
Wow Steve! Looooove the standing order changes and fleet waypoints! As if 2.6 wasn't already awesome, you just kicked it up a notch! Can't wait!
-
I appreciate the new Fleet Waypoint concept, this is finally a way to issue orders "in place" to a fleet which has been an occasional need for me.
-
Feeling like with all new changes and time elapsed between this and latest update that Steve should start thinking at a 3.0 version rename instead of 2.6 ;)
-
Thanks for the standing order propagation options. That will be a massive help.
I have a question about the enhanced precursors though - Since there is a delay between the emergence of ground forces and space forces - What happens if all ground forces are eliminated before the space assets wake up? Do they immediately activate, or will combat on the surface immediately trigger the space assets as well?
Since the justification for the delay is for the precursors to secure the surface before launching their space assets, it would be a bit weird if they didn't react to losing the ground engagement and just waited with their space ships. It would also be cool if your forces could potentially discover the dormant spaceships in such cases.
-
Do the new orders also apply to stations, or are those a special case?
-
Do the new orders also apply to stations, or are those a special case?
I'm not sure what stations you mean, but stations are just ships without engines rather than a special case. For example, the Refuel from Ship order would choose a fuel harvester station if that is the closest option.
-
Thanks for the standing order propagation options. That will be a massive help.
I have a question about the enhanced precursors though - Since there is a delay between the emergence of ground forces and space forces - What happens if all ground forces are eliminated before the space assets wake up? Do they immediately activate, or will combat on the surface immediately trigger the space assets as well?
Since the justification for the delay is for the precursors to secure the surface before launching their space assets, it would be a bit weird if they didn't react to losing the ground engagement and just waited with their space ships. It would also be cool if your forces could potentially discover the dormant spaceships in such cases.
I was wondering if someone would ask that :)
As it stands, if you destroy the ground forces, you capture the colony and no more ships appear. I haven't decided yet whether to leave it that way.
-
for conditional orders, will there be things for cargoholds ? and orders to unload cargo onto particular colonies ?
Like, salvage ships have the standing order available to salvage wrecks. Eventually they'll run out of cargo space in their fleet. So they need to unload components and minerals somewhere. You don't want to have them just unload anywhere though. An option to unload components & minerals at shipbuilding colonies would be ideal.
Similarly, lifeboats/hospital ships, that have the standing order to collect lifepods, they need to unload survivors/POWs somewhere, and a relevant destination order would be useful there. iirc the new POW mechanics, you want to unload POWs at a naval HQ location, so maybe that one ?
-
Just wanted to chip in and also express my appreciation for the work being done in this update. Some really nice QoL improvements in this one.
-
Thanks for the standing order propagation options. That will be a massive help.
I have a question about the enhanced precursors though - Since there is a delay between the emergence of ground forces and space forces - What happens if all ground forces are eliminated before the space assets wake up? Do they immediately activate, or will combat on the surface immediately trigger the space assets as well?
Since the justification for the delay is for the precursors to secure the surface before launching their space assets, it would be a bit weird if they didn't react to losing the ground engagement and just waited with their space ships. It would also be cool if your forces could potentially discover the dormant spaceships in such cases.
I was wondering if someone would ask that :)
As it stands, if you destroy the ground forces, you capture the colony and no more ships appear. I haven't decided yet whether to leave it that way.
It's a tricky question. On one hand, as it currently stands it could be pretty easy to cheese the "Advanced" Precursors if you get a couple divisions of troops on the ground and never give them a chance to launch any ships. On the other hand, as noted it would feel silly if defeating their ground troops didn't impact their ship launches at all.
What about a different mechanic that calls back to the old VB6 robot soldier events while excavating the ruins? Excavating a ruin site which might have Precursors has a chance to reactivate the guardians, either a ground combat formation or an ancient ship (or several?) that had been offline for millennia. That way, the lore doesn't imply that defeating the ground forces will impede ship deployment, but you still get that gradual danger that requires a long-term commitment of forces to obtain all the nice, valuable loot.
I considered the original VB6 robot army mechanic to be problematic, since the resulting combat tended to destroy a lot of the loot from excavations and led to some rather cheesy strategies to prevent this, but as an optional mechanic I think it can work well as long as the player knows what they are consenting to when they click that check box. :) The other possibility might be to make an exception (a dangerous suggestion, I know) and have Precursor ground forces do zero collateral damage, which is maybe less realistic but more rewarding for the players.
-
Feeling like with all new changes and time elapsed between this and latest update that Steve should start thinking at a 3.0 version rename instead of 2.6 ;)
Already thought! ;D ;)
...
I really think this is Aurora 3.0. :) :) :)
-
Thanks for the standing order propagation options. That will be a massive help.
I have a question about the enhanced precursors though - Since there is a delay between the emergence of ground forces and space forces - What happens if all ground forces are eliminated before the space assets wake up? Do they immediately activate, or will combat on the surface immediately trigger the space assets as well?
Since the justification for the delay is for the precursors to secure the surface before launching their space assets, it would be a bit weird if they didn't react to losing the ground engagement and just waited with their space ships. It would also be cool if your forces could potentially discover the dormant spaceships in such cases.
I was wondering if someone would ask that :)
As it stands, if you destroy the ground forces, you capture the colony and no more ships appear. I haven't decided yet whether to leave it that way.
It's a tricky question. On one hand, as it currently stands it could be pretty easy to cheese the "Advanced" Precursors if you get a couple divisions of troops on the ground and never give them a chance to launch any ships. On the other hand, as noted it would feel silly if defeating their ground troops didn't impact their ship launches at all.
What about a different mechanic that calls back to the old VB6 robot soldier events while excavating the ruins? Excavating a ruin site which might have Precursors has a chance to reactivate the guardians, either a ground combat formation or an ancient ship (or several?) that had been offline for millennia. That way, the lore doesn't imply that defeating the ground forces will impede ship deployment, but you still get that gradual danger that requires a long-term commitment of forces to obtain all the nice, valuable loot.
I considered the original VB6 robot army mechanic to be problematic, since the resulting combat tended to destroy a lot of the loot from excavations and led to some rather cheesy strategies to prevent this, but as an optional mechanic I think it can work well as long as the player knows what they are consenting to when they click that check box. :) The other possibility might be to make an exception (a dangerous suggestion, I know) and have Precursor ground forces do zero collateral damage, which is maybe less realistic but more rewarding for the players.
Before the conquest of a Precursors planet, it sounds strange to me if there weren't any ships defending the system.
After the planet capture, triggering the rebirth of an ancient ship could depend on several factors, from the initial strength of the colony, to a simple dice roll. As Nuclearslurpee says, ground combat should have consequences on the discovery and on the condition of the Precursors ships, condition that could allow or not their restart, as well as their ability to fly and fight. And it is plausible that the longer the combat the worse the ships condition, down to their wreckage.
We hope, Steve, that programming effort isn't so difficult that you can decide to include this option in the game.
-
I guess "LG: Refuel from Tanker" also includes looking for Harvesting Stations with hubs and defined as "Tanker"?
-
Thanks for the standing order propagation options. That will be a massive help.
I have a question about the enhanced precursors though - Since there is a delay between the emergence of ground forces and space forces - What happens if all ground forces are eliminated before the space assets wake up? Do they immediately activate, or will combat on the surface immediately trigger the space assets as well?
Since the justification for the delay is for the precursors to secure the surface before launching their space assets, it would be a bit weird if they didn't react to losing the ground engagement and just waited with their space ships. It would also be cool if your forces could potentially discover the dormant spaceships in such cases.
I was wondering if someone would ask that :)
As it stands, if you destroy the ground forces, you capture the colony and no more ships appear. I haven't decided yet whether to leave it that way.
It's a tricky question. On one hand, as it currently stands it could be pretty easy to cheese the "Advanced" Precursors if you get a couple divisions of troops on the ground and never give them a chance to launch any ships. On the other hand, as noted it would feel silly if defeating their ground troops didn't impact their ship launches at all.
What about a different mechanic that calls back to the old VB6 robot soldier events while excavating the ruins? Excavating a ruin site which might have Precursors has a chance to reactivate the guardians, either a ground combat formation or an ancient ship (or several?) that had been offline for millennia. That way, the lore doesn't imply that defeating the ground forces will impede ship deployment, but you still get that gradual danger that requires a long-term commitment of forces to obtain all the nice, valuable loot.
I considered the original VB6 robot army mechanic to be problematic, since the resulting combat tended to destroy a lot of the loot from excavations and led to some rather cheesy strategies to prevent this, but as an optional mechanic I think it can work well as long as the player knows what they are consenting to when they click that check box. :) The other possibility might be to make an exception (a dangerous suggestion, I know) and have Precursor ground forces do zero collateral damage, which is maybe less realistic but more rewarding for the players.
Another option I have considered is to have their ships launched from different bodies in the system, except for the orbital bases. In VB6, they used to have bases on multiple bodies with tracking stations and replacement ordnance.
-
I guess "LG: Refuel from Tanker" also includes looking for Harvesting Stations with hubs and defined as "Tanker"?
There are no refuellign hubs they are gone
-
I wasn't precise enough. :)
I usually use Space Stations as fuel harvesters, which are not exactly "tankers", although they are defined as "tankers" with 0 reserve. They will (obviously) not move fuel to colonies and return.
The new order will look for stationary tankers, so I wondered if my stations with refueling systems will still work as intended.
-
I would expect so it is a stationary tanker
-
I wasn't precise enough. :)
I usually use Space Stations as fuel harvesters, which are not exactly "tankers", although they are defined as "tankers" with 0 reserve. They will (obviously) not move fuel to colonies and return.
The new order will look for stationary tankers, so I wondered if my stations with refueling systems will still work as intended.
As I mentioned a few posts earlier, space stations are just ships with no engines. They are not treated any differently. For the purposes of movement orders and standing orders, a tanker is any class with the tanker flag set.
-
You don't want to have them just unload anywhere though.
That sounds like an important player decision and thus something that should not be automated. I know that there are players who get their enjoyment out of cleverly automating their empire to run so that they don't need to do anything but that shouldn't be the general goal of every feature.
-
You don't want to have them just unload anywhere though.
That sounds like an important player decision and thus something that should not be automated. I know that there are players who get their enjoyment out of cleverly automating their empire to run so that they don't need to do anything but that shouldn't be the general goal of every feature.
Hmm. True enough, but... the "Cargohold full" status should probably still be a thing, so that a fleet could be told to drop its standing salvage order, to stop it from wasting resources, which is a potential new player trap.
With a "Cargohold Full" condition, players who are excited by order templates and things, could probably do something fancy.
Right now, for salvage ships, you have to keep an eye on them every time they salvage a wreck, to see how much cargo room they have left. This is a bit of unneeded supervision, there's not much benefit to keeping a close eye on your salvagers, but some penalties if you don't (i.e. wasted resources)
Especially since now ship components will take up the correct amount of space. Managing a salvage fleet's cargospace becomes a lot more important.
-
Would the admin command assigned to the ship still exist if the commander is killed? If so, since an automatic replacement may be triggered for a non-existent ship, how is that handled?
-
Would the admin command assigned to the ship still exist if the commander is killed? If so, since an automatic replacement may be triggered for a non-existent ship, how is that handled?
If the flag bridge is damaged, the admin command is still assigned to the ship but has no benefit. If the ship is destroyed, the admin command is automatically moved to the population of its parent command.
-
While you are working a bit on the automation... one thing that comes to mind is how you automate transfer of mines and factories etc to colonies.
One issue that I have is that you can't tell the ship to wait at a planet until a certain amount of facilities are available and if they try to load something and there is nothing there the order is broken. This means I will always have to time cargo ships in a way that there is at least one facility there. When you set up automation of say building mines at one location and transferring them to colonies you would like to just set it up once and then have it run until you change it. Currently it can be a bit time consuming as you have to manual make sure you never get to zero facilities.
It would be nice if I could say... keep 100 factories and only load once you are above that... if there are only 100 or less then wait, once there is 101 the ship load as many as it can (even if it goes below 100), the next ship/fleet again wait until there are at least 101 factories.
-
Will the new hull category toggle remember the last status between game restarts? Or will I have to toggle it on every time I open the class window?
-
I have two further requests for standing orders:
1. Add a "Send Message" conditional standing order. If people want to do something more complex than possible in the system, they can get a conditional that causes it and then send a message saying what should happen. eg. I set a message on "cargo full" which says "Salvager needs to unload", so I get reminded to do so.
2. Add a checkbox for executing standing orders at all. I regularly end up overbuilding geosurvey capacity, and then having all geological survey ships complain at me that they lack somewhere to go, and having to break away their conditional orders and rebuild them once the gravsurvay has caught up. A checkbox with "just don't run standing orders" would allow me to deactivate those ships without having to remove the standing orders and rebuild them later.
-
Will the new hull category toggle remember the last status between game restarts? Or will I have to toggle it on every time I open the class window?
The toggle status is remembered for each race. The default is on.
-
The new hull and weapons category update is a huge help in middle/late game when you have dozens of classes and guns and your eyes start to rotate because of the mess, thank you Steve!
-
I have two further requests for standing orders:
1. Add a "Send Message" conditional standing order. If people want to do something more complex than possible in the system, they can get a conditional that causes it and then send a message saying what should happen. eg. I set a message on "cargo full" which says "Salvager needs to unload", so I get reminded to do so.
2. Add a checkbox for executing standing orders at all. I regularly end up overbuilding geosurvey capacity, and then having all geological survey ships complain at me that they lack somewhere to go, and having to break away their conditional orders and rebuild them once the gravsurvay has caught up. A checkbox with "just don't run standing orders" would allow me to deactivate those ships without having to remove the standing orders and rebuild them later.
I've implemented the second suggestions.
http://aurora2.pentarch.org/index.php?topic=13463.msg173478#msg173478
The first is more involved as it would require additional functionality for standing orders.
-
Lots of cool changes in the pipeline.
I'm a little curious about hull categories work for custom hull types. For that matter, some sort of way to customize hull types in general would be cool so I don't end up scrolling through a bunch of hull types that have been used in Steve's games, but that's admittedly a minor quality of life issue.
-
Hull categories are a great addition! The hull list can get very difficult to navigate in lategame when you're fielding dozens of hull types.
Speaking of navigating lists, here's a suggestion for your consideration: One can type the first few letters of any name in the Economics, Naval or GU windows, and the game will select the matching population or fleet, which is very useful once you've got too many of them to count. However, this is impossible in windows where every item in the list has a prefix (in the Officer window, anything you can assign an officer to is prefixed with a required rank or admin rating, and in the Ship Combat window, every target is prefixed by its designated hull type) because the game will only search by the prefix, which is largely useless.
If the game could ignore the prefixes in these windows and search through the actual entity names (in case of assigning Ground Force commanders to GUs, I reckon ignoring both the rank and the GU abbreviation prefixes would be optimal), assigning officers to ships, populations and GUs and selecting targets in large naval engagements would be so much easier!
Another option I have considered is to have their ships launched from different bodies in the system, except for the orbital bases. In VB6, they used to have bases on multiple bodies with tracking stations and replacement ordnance.
I'm not sure how lore-friendly this approach to "Necrons" would be, but who cares? Having Precursors spawn throughout the system would be far more interesting than potentially never having to fight a single ship of theirs if you play carefully and station a large garrison on every ruin. It would also lead to very interesting multi-directional engagements. Although I think spawning their scout classes as a first wave a couple weeks or months in advance of the real awakening could be a good idea for large ruins, because getting overwhelmed by a massive fleet with no prior warning might be a bit too much.
There's also an option to spawn Precursor ships as wrecks that would reactivate upon salvage attempts or when the awakening comes, however this might actually provide too much information about the coming threat and make things too predictable. However, random derelict wrecks in general are something that's really missing from the game, in my opinion. We can already find ruins of clearly interstellar civilizations, with two or three systems having been colonized by the same race prior to its extinction, but there's not a single shipwreck to be found!
Maybe they've all been mopped up by the Invaders (who are responsible for the downfall of all prior civilizations in the lore, if memory serves me right?) but it really doesn't have to be that way, encountering actual traces of the extinct empires' navies would add so much character to the game, not to mention interesting salvaging opportunities for the player or for the certain ever-ravenous spoiler.
-
I'm not sure how lore-friendly this approach to "Necrons" would be, but who cares? Having Precursors spawn throughout the system would be far more interesting than potentially never having to fight a single ship of theirs if you play carefully and station a large garrison on every ruin.
I assume that the "old" precursors will co-exist with their sleepy cousins with you also running into already awakened precursors. At least that's how I've understood it.
But yeah I do like the idea of there potentially being multiple precursor fleets dotted around systems where they are present. Especially if you add a mechanic where one group being engaged makes the other groups converge towards the combat zone, further making recon and full sensor coverage more important.
-
I have two further requests for standing orders:
1. Add a "Send Message" conditional standing order. If people want to do something more complex than possible in the system, they can get a conditional that causes it and then send a message saying what should happen. eg. I set a message on "cargo full" which says "Salvager needs to unload", so I get reminded to do so.
2. Add a checkbox for executing standing orders at all. I regularly end up overbuilding geosurvey capacity, and then having all geological survey ships complain at me that they lack somewhere to go, and having to break away their conditional orders and rebuild them once the gravsurvay has caught up. A checkbox with "just don't run standing orders" would allow me to deactivate those ships without having to remove the standing orders and rebuild them later.
I've implemented the second suggestions.
http://aurora2.pentarch.org/index.php?topic=13463.msg173478#msg173478
The first is more involved as it would require additional functionality for standing orders.
If the problem is how the custom message would be entered and stored, then maybe you could create a generic request attention order.
When triggered it could create an event like "<Fleet x> in <system y> is requesting new orders"
-
There's also an option to spawn Precursor ships as wrecks that would reactivate upon salvage attempts or when the awakening comes, however this might actually provide too much information about the coming threat and make things too predictable. However, random derelict wrecks in general are something that's really missing from the game, in my opinion. We can already find ruins of clearly interstellar civilizations, with two or three systems having been colonized by the same race prior to its extinction, but there's not a single shipwreck to be found!
Maybe they've all been mopped up by the Invaders (who are responsible for the downfall of all prior civilizations in the lore, if memory serves me right?) but it really doesn't have to be that way, encountering actual traces of the extinct empires' navies would add so much character to the game, not to mention interesting salvaging opportunities for the player or for the certain ever-ravenous spoiler.
Wouldn't the ancient shipwrecks have already been salvaged by the Raiders? That might have been how they were sustaining their economies after the Fall. You could even posit that the Raiders are the last remaining survivors of the prior age, which would fit their Dark Eldar inspiration.
-
There's also an option to spawn Precursor ships as wrecks that would reactivate upon salvage attempts or when the awakening comes, however this might actually provide too much information about the coming threat and make things too predictable. However, random derelict wrecks in general are something that's really missing from the game, in my opinion. We can already find ruins of clearly interstellar civilizations, with two or three systems having been colonized by the same race prior to its extinction, but there's not a single shipwreck to be found!
Maybe they've all been mopped up by the Invaders (who are responsible for the downfall of all prior civilizations in the lore, if memory serves me right?) but it really doesn't have to be that way, encountering actual traces of the extinct empires' navies would add so much character to the game, not to mention interesting salvaging opportunities for the player or for the certain ever-ravenous spoiler.
Wouldn't the ancient shipwrecks have already been salvaged by the Raiders? That might have been how they were sustaining their economies after the Fall. You could even posit that the Raiders are the last remaining survivors of the prior age, which would fit their Dark Eldar inspiration.
This could actually be pretty cool. If the player discovers a system with derelict wrecks, they have to race against time to salvage the wreck before the Raiders find it or else commit to defending the system to avoid giving the Raiders a jump boost.
Of course, I see no problem with presuming that the Raiders missed a few here and there to justify the wrecks still being present.
-
Awesome to see wrecks being addded! My question is, will their placement be truly random, or will they gravitate towards the ruins of old civilizations, where precursors usually dwell? Let's say I have 2 ruins of the same race in my game, each one system apart, will these 3 systems (and maybe the adjacent systems) have a higher chance of spawning a wreck? If that's the case, any chance of making those wrecks tech-appropriate to the race whose ruins they litter? I reckon this could be accomplished by generating dummy Precursor designs with techs matching TL1 to TL5 and using them for wrecks only? This would make those high-tier ruins even more valuable.
Also, this might be better for the Suggestions thread (and I don't know how difficult this would be to implement), but one thing that had just occurred to me is that ruins could get generated in swathes same way Post-Start Multi-System NPRs are going to be, with the game spawning an entire small derelict empire in one go. This would make exploration even more exciting (a wreck in the middle of nowhere? something interesting might be next door!), possibly alleviate the issue of NPR generation-induced pauses spoiling things (https://aurora2.pentarch.org/index.php?topic=13465.msg172085#msg172085) (you wouldn't know if you're getting an alive NPR or a dead one) and also create opportunities to spawn additional spoilers that could catch the player completely off-guard (especially the one with an affinity for expanding and eating wrecks).
-
Awesome to see wrecks being addded! My question is, will their placement be truly random, or will they gravitate towards the ruins of old civilizations, where precursors usually dwell? Let's say I have 2 ruins of the same race in my game, each one system apart, will these 3 systems (and maybe the adjacent systems) have a higher chance of spawning a wreck? If that's the case, any chance of making those wrecks tech-appropriate to the race whose ruins they litter? I reckon this could be accomplished by generating dummy Precursor designs with techs matching TL1 to TL5 and using them for wrecks only? This would make those high-tier ruins even more valuable.
Also, this might be better for the Suggestions thread (and I don't know how difficult this would be to implement), but one thing that had just occurred to me is that ruins could get generated in swathes same way Post-Start Multi-System NPRs are going to be, with the game spawning an entire small derelict empire in one go. This would make exploration even more exciting (a wreck in the middle of nowhere? something interesting might be next door!), possibly alleviate the issue of NPR generation-induced pauses spoiling things (https://aurora2.pentarch.org/index.php?topic=13465.msg172085#msg172085) (you wouldn't know if you're getting an alive NPR or a dead one) and also create opportunities to spawn additional spoilers that could catch the player completely off-guard (especially the one with an affinity for expanding and eating wrecks).
Wrecks will usually appear in systems with planets. They may be in orbit and, if so, they are more likely to appear in orbit of planets with better environments.
I like the idea of a 'fallen race'. I could probably generate the race normally, then wipe it out, then pass a random amount of historical time to reduce what remains, including radiation. Substantial addition though, so might not be soon.
-
I appreciate the change to only see race portraits once you've observed a member of the race. I know it's purely a cosmetic thing but it appeals to me for flavor reasons.
-
Communication is established
A populated colony of the alien is captured or transferred to the viewing race.
A ship of the alien race surrenders or is captured
A lifepod of that race is rescued.
Sufficient ELINT data is gathered to generate an Intelligence Event
Hmm, will these conditions apply to the "special" aliens, i.e. Precursors, Raiders, Rakhas, Swarm, Invaders ?
Cos at least some of them, the conditions other than the ELINT one are not possible iirc ?
Like, raiders and precursors don't have populations that can be captured, and you can't communicate with them, and they don't have lifepods.
-
Communication is established
A populated colony of the alien is captured or transferred to the viewing race.
A ship of the alien race surrenders or is captured
A lifepod of that race is rescued.
Sufficient ELINT data is gathered to generate an Intelligence Event
Hmm, will these conditions apply to the "special" aliens, i.e. Precursors, Raiders, Rakhas, Swarm, Invaders ?
Cos at least some of them, the conditions other than the ELINT one are not possible iirc ?
Like, raiders and precursors don't have populations that can be captured, and you can't communicate with them, and they don't have lifepods.
They do apply to spoiler races. At the moment, you know immediately if you have met certain races, which takes away some of the fog of war. The only one where it is impossible is Swarm, because you can't board their ships in v2.6. However, I should have included aliens boarding your ships as a condition, which solves that one too.
-
Those are some excellent changes! I longed for some first contact wars that weren't caused by my own stupidity, and having actual fog of war in regards to spoilers is a vast improvement too.
May I suggest changing the "boarding action" bit to a "ground combat event"? This would include boarding actions but also make it possible to identify Rakhas, who wouldn't be able to get identified under current rules (as IIRC species with 100 xenophobia can't generate population intel? maybe their STO active sensors could generate an intel event, but that's terribly counterintuitive) and make Precursors and Raiders easier to identify as well. Swarm will let you know regardless.
Wrecks will usually appear in systems with planets. They may be in orbit and, if so, they are more likely to appear in orbit of planets with better environments.
I like the idea of a 'fallen race'. I could probably generate the race normally, then wipe it out, then pass a random amount of historical time to reduce what remains, including radiation. Substantial addition though, so might not be soon.
Fallen empires, especially ones generated by simulating the destruction of an actual race, do sound complex indeed. I understand postponing that as I would also like to see 2.6.0 before the decade's over ;D Giving wrecks a more direct relationship with ruins feels like a rather natural addition though, albeit with a high enough ruin chance them spawning near low-CC worlds could be close enough. I still think having their tech level correlate with nearby ruin tech level would be neat as hell though.
Have you considered adding a startup setting for random wreck frequency?
-
-Snip-
The progression for refuelling is 20k, 30k, 40k, 60k, 90k, 135k, 200k, etc.
The small craft version still exists, with half the previous refuelling rate.
I do believe then that the main benefit you obtain from having more, smaller tankers is when your fleet is overall very low on fuel. What I mean by that is if you have one large tanker, and ten ships to refuel, then it can only refuel one ship at a time, and so depending on the fuel level of the fleet, you might run out of fuel on the other ships before you finish refueling the fleet, ( I do believe it refuels ship by ship, not the fleet as a whole). Having more numerous smaller tankers however allows you to not only double your refueling rate at the very minimum due to each needing a refueling system, but instead of only refueling one ship at a time, you can now refuel two, three etc, reducing the odds of your fleet running out of fuel while on the move as your tankers will move through your fleets twice as fast.
This generally isn't an issue if you have a tanker that can keep up and it's refueling capacity exceeds the total fuel burn of the fleet, but you can see where in certain cases this might lead to several interrupts for out of fuel. So I would like to request that you consider if another module or Tech can be added/researched that allows for increased simultaneous refueling. Whether this splits the total capacity or in a sense multiplies it is up to you, but it would be a workaround to smaller tankers being superior as you mentioned earlier. If one large Tanker can refuel say 4 ships at once(A good maximum, four ships flying in a plus formation around a tanker seems doable), it is doing the job of 4 smaller tankers. Though making the refueling systems heavier and more "powerful" as you've done would also shift the balance more in favour of larger tankers in general.
As for possible release dates to this long awaited update, are we looking at something late July/August if all goes well?