If you are giving the same command(s) to many fleets you could just copy the list of orders into the order templates, then select them on all the fleets.
1 Like
That would be fine with large number of orders to small number of fleets.
Less so when ordering ten squadrons to transit, or move towards planet / land on mother ship, ie, large number of fleets and small amount of orders
1 Like
Negative tax rate
Is there a way we could set a negative tax rate, effectively subsidising commercial shipping proportionally to each journey made?
SJW: No, I removed the ability to subsidize shipping lines as it was too powerful.
Iām of the mind that diseases and bioweapons are too hard to balance and either create busywork in terms of keeping up with research, at which point it doesnāt affect you, or you donāt and you basically lose the game because bio weapons are absolutely terrifying. Thereās also the nuance of how different alien biology would be, to the point where youād kind of have to start from figuring out from basics in biology to find what to attack. Though some kind of anti spoiler one hit plague missile might be something a decent number of people want.
On a seperate note, the UI for the civilian shipping bit is a bit clunky, and adding stuff like āOrderā templates would do a lot to make it a lot faster to use. I believe it was suggested somewhere, but a checkbox for āmake avalible to Civ Supplyā when ordering installations might also be neat.
I also saw mentioned somewhere that it was more efficient to scrap a ship and then build a new ship mineral wise than refitting, as the parts that were being replaced during the refit simply vanish. I wouldnāt mind if those components were to be auto scrapped instead, which makes sense from a practicality standpoint. I believe most home planets start at around 100k-500k of most resources, which compared to the yearly usage of steel if it is in metric tones, is pitiful, So it would make sense for any components no longer needed to be recycled as efficiently as possible when thereās potential resource shortages afoot. Even historically I doubt they threw away perfectly good metal when it could be sent to a steel mill and recast into whatever they needed it for.
On that topic however, it might be of interest to add life-span mechanics, ergo, ships can only āoperateā For a certain number of years before age and wear and tear makes maintenance more expensive than just scrapping and building anew. This could manifest as an increased cost of maintenance needed per year for ships over certain ages, with research able to increase planned lifespan and reduce the ramp up of maintenance cost for instance. The cost increase could also be in wealth rather than pure MSP, as while the material costs are similar, finding someone willing and able to build 60 year old components is a known problem even in our reality, usually associated with fairly high costs.
Because scrapping isnāt 100% efficient, this would shift the āDrainā of resources from refits to the overall scrapping and rebuilding process, it would also manifest in the increased maintenance costs, thus preserving the resource balance. It also removes a decent number of build and forget designs, such as armorless stations, where an increasing wealth maintenance is required as time goes on to compensate for the fact that the teraforming platform is 300 years old, or the orbital habitat hasnāt changed materially in 100 years etc.
You could probably also influence the lifespan in terms of design āRuggednessā which would more easily allow for 40k style ships that are very mass inefficient, but will last for hundreds if not thousands of years, as opposed to smaller ships that have a design lifespan of 20-40 years.
If nothing else itās a potential way to increase the amount of decisions and trade offs. Do I intend to frequently replace these warships, thus have them be more efficient cost wise, but Iāll need to scrap and dedicate shipyard time to building new ships, or do I build inefficient forever ships that I can refit for the next 200 years no problem etc.
Finally, I was wondering if some kind of speed limit on tugs actively tugging might be appropriate, scaling by engine tech. As it stands, tugging everything everywhere is sort of the optimal strategy. By adding a speed limit, it means dedicated spaceships with the same modules will have a potential speed advantage over towing. Making the decision less clear cut than it currently is. As it stands, itās more efficient to build cargo, colony, tanker, collier and troop transport āPodsā and then use large tugs to zip them around very quickly, instead of building dedicated vessels for each, which will end up with āwastedā engines just sitting idle. This could apply to all tugging operations, or just the tugging of armor-less stations.
1 Like
They just seem like adding downsides to set play styles.
3 Likes
Solar Mirror / Shield
Currently, we permanently terraform bodies with gases. Solar Mirrors or Shields could be modules which only work as long as they are in orbit, acting upon albedo.
How?
In my mind, there are a few ways they could be used.
- In orbit around a planet, to reflect sunlight away (raise albedo)
- In orbit around a planet, reflecting additional sunlight onto the planet (lower albedo)
- In orbit around the sun / suns, focusing more sunlight onto a body (raising solar radiation)
Why?
I am far from an experienced player, so I donāt want to imagine situations that rarely happen, and am happy to be told this is lame.
I was thinking about military sieges, however, and how some cities had wells or water outside their walls that they had to defend alongside the town proper, forcing them to sally out.
I can imagine a similar situation in Aurora - youāve got a strong defending fleet, but the planetary population is dependant upon the solar mirrors orbiting the sun to keep the temperature sustainable. You can drag the defenders away by threatening this body.
Or the opposite - you build solar mirrors on the sun and start to cook the planet, while they rush to build mirrors of their own to counteract your increased radiation.
If you conquer such a planet, destroying the solar infrastructure that kept it habitable would be another cost / risk to capture.
I feel this would add some strategic depth, but happy to be told that I am wrong
1 Like
There is an exensive discussion about this in this discussion.
1 Like
It would be very helpful the possibility to update the missiles.
Scrapping the old ones to build the new ones causes the loss of many minerals.
Version 3.0 has the missile series feature, where you can set a series of missile versions as a whole in orders, templates and fire controls, so upgrading missiles is more streamlined.
When have you ever heard of missile recall and updates?
1 Like
On the subject of missiles, would it be possible to have planetary bodies be, by default, targetable?
There probably is a better way of doing this, but the current process I use is setting waypoints on each body and then targeting them. A collapsible drop-down for planetary bodies subdivided by planets moons etc. would save me a lot of clicking!
1 Like
Small addon: when a new Officer is ācreatedā would be nice also to know the Academy he is coming from. Close to the name would be nice to have like (Luna Military School), (Callisto University). Like this: Maria Komarov (Callisto University) Survey 15%, Reaction 5% etc..
A movement order along the lines of āwait at colony until it has less than X of specified mineralā (or fuel or MSP) would be really useful.
A freighter using that order would be able to automatically respond to mineral usage at a particular colony. For example, a freighter set to cycle the orders:
- Wait at Planet A until it has less than 10k tons of Gallicite
- Load Gallicite from Planet B until full
- Unload all minerals at Planet A
Would be able to react to increased usage of Gallicite at Planet A, without the player having to manually adjust freighter schedules every time Planet Aās usage changes.
But what I like most about this idea is that it makes it practical to set up long chains of intermediate buffer colonies. As it is right now, if a mineral demand at the end of the chain increases its demand you need to go through every step of the chain and manually increase throughput. But if the intermediate freighter lines can dynamically respond to increased demand, that reduces the demand (hah) on the playerās time. (Youād of course still need to monitor the intermediate stops to make sure that the demand is still within max throughput, but thatās way less work. And importantly itās way less upfront workā¦)
Give Naval and Ground Force Officers a tiny chance to enter the ācivil serviceā as Administrators when they retire from military service.
10 Likes
Maybe even bump that chance a bit for high-ranking decorated officers. Because, lieutenants who spent their entire career unassigned have much lesser chance to be voted for, compared to well-known generals.
4 Likes
On the other hand, it seems like the politicians today who most boast about their military service / careers did the least soldieringā¦
4 Likes
I have a short and simple suggestion regarding Ground Units. I love the trope of people from a specific world being terrain specialists for that kind of world, like Tallarn Desert Raiders or Catachan Jungle Fighters. Itās lovely that this is already represented in game by the capabilities, but perhaps if you train an infantry type element in a world with this specific terrain they could come with itās relative capability with no increased cost? This way you get rewarded for putting in the effort in finding or terraforming a world to the specifications, then setting up a population on it, then training ground units in said population.
Iām not sure how the code works, but I believe the easiest way to implement this is checking to see if you have the tech for the capability, like desert warfare capability, whenever you train an infantry unit in a world with that particular type. If it detects that you have the capability and the infantry was trained in a world of that type then the unit would automatically get that specific capability, even if the unit was not designed with that capability.
This should only work for Infantry, a tank of the same type built in a desert world wouldnāt be inherently better at being a tank in a desert. You need a new project ground unit for that.
I know that this is a niche within a niche, but if itās easily added it would be lovely to have.
1 Like
The game already does something similar. If you have a formation with desert capability (for example) and you train it on a desert world, you donāt pay for the desert capability.
The same applies to jungle, mountain, rift valley, extreme pressure, extreme temp, high and low gravity.
3 Likes
Thanks for the clarification! I had no idea, even though I tried searching around the web before making my suggestion. Canāt help but make the classic blunder of suggesting something thatās already in the game. Thatās a good implementation as well! Iāll definitely go around my Empire setting up different GFCCs in strategically varied worlds.
Itās in the v2.6 patch notes.
3 Likes
There is a problem when putting AMMs in multi-missile pods (what I call >=2 missiles as second stage in a 0 ton 1st stage), it seems that the system to auto-fire PD missiles only looks at the 1st stage speed when deciding to fire AMMs and will refuse to fire the pods because their speed is too low to intercept enemy missiles (logical, since the 1st stage has a 0km/s speed).
Itās not a problem for anti-ship missiles a long as their sĆ©paration range is >= to the 2nd stageās range, the 2nd stage separates as soon as the pod leaves the tube and inherits the 1st stageās target.
In the case of AMMs in a missile pod, would it be possible to check not just the first stageās speed but also the second stageās to decide whether or not to fire the missiles? I really like making versatile ships and having the option to use size 3 or 4 box launchers to fire both AMMs and anti-figher/light anti-ship missiles would be quite good.
I did make size 3 ECCM and retarget capable AMMs, but iād like to have more options.
1 Like