The current setting is 20px increments for grid snapping with a default placement for new systems of 140 px.
I would much, much rather the ratio between these be even so I can arrange systems hexagonally.
The current setting is 20px increments for grid snapping with a default placement for new systems of 140 px.
I would much, much rather the ratio between these be even so I can arrange systems hexagonally.
Maybe it was asked before: in tactical map, would it be possible to show colonies and populations in different ways (e.g., a circle and a diamond around the bodies)?
And if there are populations and colonies of different races, show them in different colours (assigned in the Intelligence window)?
Usually when I’m setting a reserve amount for minerals, I’m setting the same amount for all minerals. So it would be really great if you could double click the “Total” row to set the same reserve amount for all. Or perhaps a “set reserve for all” checkbox at the bottom.
Create a “Planned Updates” thread in Patch Notes. This will be a list of suggestions that have been accepted for consideration (but not definitely will be implemented) or links to them, and Steve’s own ideas, for which we could suggest one of the implementation options. Something like a “ToDo” list. Maybe with some polls.
For example, I already suggested adding the Standing Order “Active Sensors Off”, and I do not know if this suggestion was noticed or forgotten behind a layer of other work. ![]()
Expanding the list of Standing Orders conditions.
The current list of conditions is very small and undetailed. It might be much more convenient to organize it into drop-down lists “Fuel”, “MSP” and so on, each with more conditions (“Fuel < 60%”, “Fuel > 60%”, “Deployment 50%” and so on).
It is bold of you to assume that Steve plans the updates. ![]()
Still, having a list is much more convenient than remembering the plans you made yesterday. ![]()
(This is especially a problem for me, as I sometimes forget various things that I would like to suggest here. “Expand the Standing Orders” I forgot 3 times.
)
Make bodies with sufficient eccentricity ineligible for the Tidal Lock tag.
Rationale: tidal locking in-game assumes for non-moons a “twilight zone” which reduces the usable living space but also reduces the temperature effect on CC as the population is assumed to live in that twilight zone. Sufficiently eccentric orbits eliminate the twilight zone due to the difference in orbital speed and rotational speed at various points throughout the orbit which exposes different parts of the surface at different points in the orbit, or are associated with tidal locking at other than a 1:1 resonance.
Without doing proper analyses you could just assume that bodies with greater than probably 0.15 or 0.20 eccentricity are either in an other-than-1:1 resonance (like Mercury with about 0.20 eccentricity in a 3:2 resonance) or throughout the orbit show enough of the surface to the star that there’s not actually anywhere for people to live that counts as “in the twilight zone.”
In Aurora, “tidally locked” includes bodies with non-1:1 resonances, including Mercury. This is by design, as Steve has said in the past he did not want to create special rules for each different resonance that could occur. Since the current rule also helps give more locations for colonization, I suspect this is unlikely to be changed.
That would involve a level of organisation and planning that has hitherto been entirely absent ![]()
I’ve avoided the detail of 3:2 resonance or similar, by going with either tidal locked or not. I like the principle of some orbits being too eccentric for tidal-locking, although that will slightly reduce the number of colonizable worlds.
It’s not really “planning”, it’s more like “I liked that idea over there, but I’m busy right now, I will write it here and think about it next week when I finish my current business”. ![]()
In the end, I think that Steve largely uses this thread for that purpose. And he comments on the post when he’s actually done something. Now, not all suggestions are created equal (which I think is your point). But by saying “I’m planning on X, but not Y” Steve creates another opportunity for those inclined to debate with him about his priorities, so in Steve’s shoes, I definitely wouldn’t publish my ‘intended roadmap’ ever beyond the occasional, “one day I’d like to make Star Trek monsters be a thing” or whatnot.
But, I think its genuinely possible my curmudgeon quotient is higher than Steve’s. ![]()
While looking around in the database, I saw there is still a table of squadron names (that VBAurora would pull from when you made a fighter squadron), but I don’t think there’s any way to use the table right now. Any chance a squadron nickname button in fleet organization is a possibility?
Suggestion: Change fire controls to have three states: Fire as Assigned Target, Fire at Will, and Hold Fire.
This would eliminate the issue where players (new and old) sometimes forget to hit “Cease Fire Fleet” and continue to experience 5s time increments until they realize it’s their own FC that’s causing the issue.
It would also improve the Fire at Will command since it would auto-retarget, making mopping up after a battle (or dealing with large groups of fighters) require a lot less button clicking.
I’d suggest a relatively simple algorithm to prevent about 99% of “impossible” surprizes, currently possible beause of the pulsed game mechanics.
My supposition is that nearly all significant issues appear near the destination point, not in the middle of the route, where, in addition, even if some impossible event do happen, the player never notice it after, so the gameplay wouldn’t suffer actually.
So, the suggestion is to add a possible-future check somewhere before movement phase, just by going through the list of destination points with times-to-arrive less then the current pulse length, and processing the same check as with “real” moving object positions. In the case some moving object destination is indeed would be in range with any hostile sensor during this pulse - the pulse length is automatically decreased to prevent jumping-out-of-blue events.
I would like to expand on that suggestion and ask for tooltips to support not only text, but also simple image files. The reason for this would be to allow players to add custom graphics for their ships and planets. I often have a folder of images for my current campaign, and I would love to see those graphics in-game when hovering my mouse over a specific planet.
For Steve, per request about additional traits!
Add an option in the ship design screen to disable life pods. As soon as the ship explodes, all crew and officers go down with the ship.
This way I can design “drone” ships (without leaving tens of thousands of “conscripts” out in the void to die a slow but inevitable death) without needing to pick up the defective drone models responsible for the loss of yet another Automated Cruiser.
Have ship’s crew gain experience when the ship fires weapons, takes damage, etc. On the Job Training (OJT) should be a better teacher than sitting in port with the engine running ![]()