Suggestions Thread for v2.0

[mike2R]

Raiders are a great early game enemy but become a micromanagement hassle by the mid game.  A sunsetting mechanic for them would be nice.  Yes you can just turn them off after a while, but that feels less thematic. 

I'd love to see a sunsetting mechanic, something like:
    - A tech that can be researched which can stop raiders spawning
    - Research and build a device that stops spawns in a system
    - Having all the jump points stabilized would prevent spawning in that system by stabilizing the ether
    - A certain amount of PPV in a system would lock that system down
    - Research a jump drive that can jump to their home base and destroying it would stop the spawns
    - Spawn of some sort of "boss" fleet after a set amount of time/exploration that when defeated would stop the spawns

Anyways, that is my 2 cents. .

Would an interesting alternative be that the Raiders attack less frequently, but in greater force, as the game advances? That way as an empire grows, the micromanagement load from Raiders would not grow so much, and they would hopefully remain challenging enough to fend off that they remain fun to play against.

Personally I'd much prefer something like that, if a solution is needed (my own game has seemed very light on Raiders after the early game, to the point where I've unticked Raiders attack NPRs in the hope I might get a bit more of their attention).  But I definitely want to have the need to guard rear areas throughout the game - thats the whole point of enabling them for a game IMO.

I do think their weapon choice may not be the best - fighting raiders just means being able to intercept with a single ship that can make 5000kms plus, and has a beam weapon range of at least about 190,000km.  I'd prefer a design where they get to land some hits if you come at them with beams, so a big fleet would be a different level of threat - right now the only difference between fighting a single destroyer and a fleet is the amount of patience needed to slowly plink away at them.

[Droll]

Raiders are a great early game enemy but become a micromanagement hassle by the mid game.  A sunsetting mechanic for them would be nice.  Yes you can just turn them off after a while, but that feels less thematic. 

I'd love to see a sunsetting mechanic, something like:
    - A tech that can be researched which can stop raiders spawning
    - Research and build a device that stops spawns in a system
    - Having all the jump points stabilized would prevent spawning in that system by stabilizing the ether
    - A certain amount of PPV in a system would lock that system down
    - Research a jump drive that can jump to their home base and destroying it would stop the spawns
    - Spawn of some sort of "boss" fleet after a set amount of time/exploration that when defeated would stop the spawns

Anyways, that is my 2 cents. .

Would an interesting alternative be that the Raiders attack less frequently, but in greater force, as the game advances? That way as an empire grows, the micromanagement load from Raiders would not grow so much, and they would hopefully remain challenging enough to fend off that they remain fun to play against.

Personally I'd much prefer something like that, if a solution is needed (my own game has seemed very light on Raiders after the early game, to the point where I've unticked Raiders attack NPRs in the hope I might get a bit more of their attention).  But I definitely want to have the need to guard rear areas throughout the game - thats the whole point of enabling them for a game IMO.

I do think their weapon choice may not be the best - fighting raiders just means being able to intercept with a single ship that can make 5000kms plus, and has a beam weapon range of at least about 190,000km.  I'd prefer a design where they get to land some hits if you come at them with beams, so a big fleet would be a different level of threat - right now the only difference between fighting a single destroyer and a fleet is the amount of patience needed to slowly plink away at them.

I think giving them short-range torpedoes or self-guided missiles as an alternative load-out might make fleet engagements involving them more interesting. Those are both weapons that have long enough range to out-range any beam weapon while not having oppressive range.

[mike2R]

Very minor QoL request: I've built up a fairly large collection of text files with different naming themes - ones that people have posted in the suggestion thread, but didn't get picked for inclusion. I import these into the game whenever there is a new db update. 

One thing that's a bit of a chore is having to enter a name for each list by hand - I was wondering if the file name could be used as the default name for the list.  It asks you for the name before you select the file, but maybe if the default was something like "(will use filename if unchanged)" then this could be used as a flag to just grab the name of the file once the user selects it.

[Steve Zax]

I was wondering what I was missing from VB aurora till i saw some old screenshots.  Please bring back the checkbox on the commander list for "only show unassigned commanders"

[Lazygun]

Trying to terraform a small asteroid for use with LG infrastructure, my single terraform station was rated as being able to supply 76 atmospheres worth in a year.  So in a single 5 day production period it was vastly overdoing the atmosphere then when I tried to fix the overpressure it was vastly undershooting.

Can you make it so that if a terraform gas overshoots its level that you assume the engineers turned off the machines early, and so you get the amount you set as a limit?

[Garfunkel]

Trying to terraform a small asteroid for use with LG infrastructure, my single terraform station was rated as being able to supply 76 atmospheres worth in a year.  So in a single 5 day production period it was vastly overdoing the atmosphere then when I tried to fix the overpressure it was vastly undershooting.

Can you make it so that if a terraform gas overshoots its level that you assume the engineers turned off the machines early, and so you get the amount you set as a limit?

Unfortunately, there is no easy solution for this because we do not want turn resolution to be slowed down by the game triple-checking every terraforming operation being done by every race. Instead, try making your production delay shorter - turn it down from 5 days to 1 day, for example, that should help. If it doesn't, then build a smaller TF station specifically to handle smallish asteroids.

[Andrew]

Trying to terraform a small asteroid for use with LG infrastructure, my single terraform station was rated as being able to supply 76 atmospheres worth in a year.  So in a single 5 day production period it was vastly overdoing the atmosphere then when I tried to fix the overpressure it was vastly undershooting.

Can you make it so that if a terraform gas overshoots its level that you assume the engineers turned off the machines early, and so you get the amount you set as a limit?

Unfortunately, there is no easy solution for this because we do not want turn resolution to be slowed down by the game triple-checking every terraforming operation being done by every race. Instead, try making your production delay shorter - turn it down from 5 days to 1 day, for example, that should help. If it doesn't, then build a smaller TF station specifically to handle smallish asteroids.

Or after getting the overshoot use the SM settings to set the atmosphere to the lower level you need

[nuclearslurpee]

Or after getting the overshoot use the SM settings to set the atmosphere to the lower level you need

This is the way. SM mode is not cheating, it exists specifically to fix such situations where the game mechanics lack fidelity to the player's intentions.

[mike2R]

Trying to terraform a small asteroid for use with LG infrastructure, my single terraform station was rated as being able to supply 76 atmospheres worth in a year.  So in a single 5 day production period it was vastly overdoing the atmosphere then when I tried to fix the overpressure it was vastly undershooting.

Can you make it so that if a terraform gas overshoots its level that you assume the engineers turned off the machines early, and so you get the amount you set as a limit?

Unfortunately, there is no easy solution for this because we do not want turn resolution to be slowed down by the game triple-checking every terraforming operation being done by every race. Instead, try making your production delay shorter - turn it down from 5 days to 1 day, for example, that should help. If it doesn't, then build a smaller TF station specifically to handle smallish asteroids.

Would it really slow down turn time by an appreciable amount?  It would literally be one extra check per planet being terraformed, per 5 days.  Just check if the new gas amount would breach the target amount, and set the amount to exactly equal the target amount in that case.  The game must be doing thousands upon thousands of similar operations in a 5 day cycle.

[Lazygun]

The game is already checking so that it can notify the player and set the gas to 'none' in the environment tab.  So that would be very very few extra checks. 

Another suggestion:
Civilian shipping companies in my current game keep on building colony ships even though there is no work for them to do.  I just got through deleting about 50 fleets.  Can you make it so that if there are idle ships of a particular type, or more than a couple of idle ships, the shipping line won't build extras.

[Demetrious]

If the current layout of the code supports this change with relatively little issue, I would like to propose a low to moderate chance of worlds that would otherwise be tidally-locked spawning as worlds that, instead, enter a stable 3:2 spin-orbit resonance with their host star. Mercury is a real-life example of such a planet; the motion of the sun in the sky of Mercury is as affected as much as Mercury's orbit around the Sun as it is Mercury's own rotation. Cribbing from the notes from my in-progress sci-fi novel, around your average cool red dwarf with the very close-in habitable zone this can result in orbits where the local solar day lasts two years, and the local year is only 96 hours long - with a modestly dense atmosphere this would result in pretty good heat conduction all across the planet as well as something approximating a diurnal cycle.

Given the nature of Real Stars games, I feel this might make things a little more interesting. Aside from large terrestrial moons around close-orbiting Jovian planets, (which are regrettably but likely realistically rare) good colony candidates in Real Stars games can be few and far between if you roll snake-eyes on Alpha Centauri.

[nuclearslurpee]

If the current layout of the code supports this change with relatively little issue, I would like to propose a low to moderate chance of worlds that would otherwise be tidally-locked spawning as worlds that, instead, enter a stable 3:2 spin-orbit resonance with their host star. Mercury is a real-life example of such a planet; the motion of the sun in the sky of Mercury is as affected as much as Mercury's orbit around the Sun as it is Mercury's own rotation. Cribbing from the notes from my in-progress sci-fi novel, around your average cool red dwarf with the very close-in habitable zone this can result in orbits where the local solar day lasts two years, and the local year is only 96 hours long - with a modestly dense atmosphere this would result in pretty good heat conduction all across the planet as well as something approximating a diurnal cycle.

Given the nature of Real Stars games, I feel this might make things a little more interesting. Aside from large terrestrial moons around close-orbiting Jovian planets, (which are regrettably but likely realistically rare) good colony candidates in Real Stars games can be few and far between if you roll snake-eyes on Alpha Centauri.

This has been suggested in the past, and Steve has indicated that he is aware of this but doesn't think it would have enough of a game impact as whether a planet is fully locked or in 3:2 resonance, it will still be mostly uninhabitable in most cases. To model habitable planets with 3:2 resonance would be rather more involved of a planetary dynamics simulation than I think Aurora is suited for.

I would however not mind seeing some refinement of the colonization mechanics for these bodies, since in principle the light or dark side of a locked planet should still be colonizable at a similar cost to any other body at that temperature. However that would again probably be more complex than is really necessary in Aurora, especially now that OrbHabs, pardon me, Ark Modules are now viable as an alternative to infrastructure.

[Demetrious]

This has been suggested in the past, and Steve has indicated that he is aware of this but doesn't think it would have enough of a game impact as whether a planet is fully locked or in 3:2 resonance, it will still be mostly uninhabitable in most cases. To model habitable planets with 3:2 resonance would be rather more involved of a planetary dynamics simulation than I think Aurora is suited for.

This may no longer be the case, as capture into any non-tidally locked orbital resonance seems to be pretty dependent on orbital eccentricity, and that feature is now in the game. However, this still leaves the question of feature implementation. Depending on how the extant code is written, implementing such a feature might be a troublesome amount of work for trivial benefit. More importantly, though, it might not be the best way to implement the feature in the first place.

As a "storytelling tool," Aurora is neither purely a computer game nor a table-top rules system, but somewhere in-between. Sometimes that balance can be struck via direct implementations, (the player-defined RP modules being a good example,) sometimes it cannot as it goes against fundamentally important gameplay mechanics, making it better implemented in a "house rule" fashion using GM - I mean, SpaceMaster - fiat (the recurring request for regenerating minerals being a neat example of the latter two.) This spectrum is important to consider because it has implications beyond the theoretical implementation of $feature. Again, the RP modules are a good example; a whole framework allowing much greater flexibility than manual implementation of various and sundry RP modules could have, and with far less work required.

In short: what's the most elegant and concise way to implement this?

I would however not mind seeing some refinement of the colonization mechanics for these bodies, since in principle the light or dark side of a locked planet should still be colonizable at a similar cost to any other body at that temperature. However that would again probably be more complex than is really necessary in Aurora, especially now that OrbHabs, pardon me, Ark Modules are now viable as an alternative to infrastructure.

This is a good example - Ark Modules are not hard to re-fluff as orbital infrastructure for tidally-locked worlds (e.g. orbital mirror arrays to illuminate parts of the dark side and matching orbital sun-shades to shield parts of the day-side.) I'm not sure how to simulate a 3:2 world with the tools currently available, however. If direct editing of the population limit in the database won't cause Aurora to crash, then it'd be relatively straightforward to implement this with a small third-party software tool (reads planet values from the database and flags any that are candidates for spin-orbit resonance capture so the player can edit his database as they see fit. With eccentricity values now calculated by the game and gas giant effects considered, most of the work is already done; interested players need only build on that.) Implementing it with currently extant in-game tools would be preferable, however, as it simplifies bug reporting (obviating the need to replicate the bug with a pristine database) and makes the option more accessible to less motivated players.

Does anyone have ideas relating to this? (I'll make a thread for it if there's more than a few paragraphs/posts worth of meat here. [There may not be.])

[Jorgen_CAB]

One thing that I really miss is an option for a transport to wait on a planet until it can fill its cargo with something you order it to Load, instead of just failing to pick up something.

This would make it easier to make cycling orders for pickup of installation as you don't need to calculate how much you produce and inserting wait orders so the planet never have anything to pick up.

Sure... you can end up with a transport sitting there indefinitely as it tries to pick up something that will never be built, but that would be a trade-off I'm willing to take as it would be an optional order type.

There would need to be a check if multiple fleets are waiting for the same thing as only one such fleet should load something at the same time.

[TallTroll]

>> Sure... you can end up with a transport sitting there indefinitely as it tries to pick up something that will never be built 

How about adding a cut off condition/s? "75% load OR 180 days have passed "?