Bug fixes and AI enhancements for transports.#78
Bug fixes and AI enhancements for transports.#78ajkfreelance wants to merge 3 commits intorayfowler:masterfrom
Conversation
1. Fixes the method for setting colony population to ensure enforcement of the planet's current maximum size. Addresses a number of possible bugs (some observed) as per impacts to:
a) Colony.capturedByTransport: Eliminates ability to massively overpopulate a captured colony, *and then potentially forward-transport excess colonists, including in a cascading attack sequence*. Since the game does not cap the maximum number of transports than can land in a ground attack the way MOO1 did, this can result in the ability for a single colony to send a quantify of transports far in excess of any amount that would be allowable even for the best possible maximally terraformed gaia planet.
b) Colony.capturedOrion: (same considerations as capturedByTransport).
c) Empire.takeAbandonedSystem: It appears that it was previously possible to assign an arbitrarily large population when acquiring an abandoned colony.
d) ColonyEcology.commitTurn: (Theoretical) Capping growth to the planet currentSize limit appears to rely entirely on the prior population growth and purchase calculations being done (i.e. constrained) correctly. Based on IDE-assisted search for uses of setPopulation, there is no turn-processing logic for fallback enforcement of the currentSize limit in the event of errors in the calculations. No indications have been encountered of this working incorrectly at this time, but still... brittle.
i) NOTE: The check for setting the populationGrowthCompleted flag also appears possibly flawed as it seems to check against the maximum possible size when all terraforming available to the empire has been applied, as opposed to the amount that has *actually* been applied to the planet. Unclear as to what the impact might be, and thus whether this behaves as intended for whatever consumes this flag.
- Also applied by incorporation to the adjustPopulation method, with corresponding updates to use the adjust method instead of set when appropriate.
- Provided a return value to indicate transports lost due to exceeding the colony max size, and left placeholders for what should probably be notifications to the player when this happens. Not yet sure how to provide the translations for the prospective notification though (Google translate?).
2. Fixes scheduleTransportsToSystem to actually constrain to the maximum amount allowed. (The computed value "xPop" was not actually being used. But it was what was logged!)
3. Fixes logic for determining that the attacker has a fleet in control of the target system, when not using combat transporters. The previous logic was only checking that the empire had a fleet "at" the target system. Unfortunately this led to a (observed) situation where an opponent repeatedly sent large numbers of transports to their certain death, because it would find that a fleet it had sent was at the system. But unfortanately for them, a fleet that has retreated is still considered "at" the system in a deployed (not orbiting) state -- and they kept retreating their fleets because they were not sending anywhere near the force necessary to displace the fleet I was holding in orbit at the system.
4. When relying on combat transporters, adjust force size for the effect of the target having subspace interdictors if indicated by available spy intelligence.
|
Curious if there is any reason why you cherry-picked only fix #4, with no response on the pull request? Is there additional process you're looking for (file issues to track the other fixes or something)? Fixes 3 and 4 could be considered enhancements, but 1 and 2 seem like significant bugs... |
I can't accept any complex changes to the base code this close to release without some way to verify the bug and the fix (e.g. a save where the bug can be reproduced) |
|
Ah okay, I've attached a save game that reproduces the main bug described in point 1. On the next turn of this game, observe the state of the Azuk system after the resolution of combat: max size of 135 but will have some 200+ population. After one additional turn, similar instances of the bug can be observed at Yargol (max 150, pop 300+), Bashnag (max 110, pop 150+) and Dul (max 170, pop 240+). There isn't any clearly straightforward way to demonstrate a repro of item 2 -- it's possible it is masked by UI enforcement of the limit (which may mean only the human player is restricted). But it seems pretty clearly a simple typo bug, since xPop is used three lines prior (and is what is logged). I can factor out the change for item 3 into a separate PR pending a save game that provides a clear repro, and drop the final piece that was already cherry-picked. |
2 participants
a) Colony.capturedByTransport: Eliminates ability to massively overpopulate a captured colony, and then potentially forward-transport excess colonists, including in a cascading attack sequence. Since the game does not cap the maximum number of transports than can land in a ground attack the way MOO1 did, this can result in the ability for a single colony to send a quantity of transports far in excess of any amount that would be allowable even for the best possible maximally terraformed gaia planet.
b) Colony.capturedOrion: (same considerations as capturedByTransport).
c) Empire.takeAbandonedSystem: It appears that it was previously possible to assign an arbitrarily large population when acquiring an abandoned colony.
d) ColonyEcology.commitTurn: (Theoretical) Capping growth to the planet currentSize limit appears to rely entirely on the prior population growth and purchase calculations being done (i.e. constrained) correctly. Based on IDE-assisted search for uses of setPopulation, there is no turn-processing logic for fallback enforcement of the currentSize limit in the event of errors in the calculations. No indications have been encountered of this working incorrectly at this time, but still... brittle.
i) NOTE: The check for setting the populationGrowthCompleted flag also appears possibly flawed as it seems to check against the maximum possible size when all terraforming available to the empire has been applied, as opposed to the amount that has actually been applied to the planet. Unclear as to what the impact might be, and thus whether this behaves as intended for whatever consumes this flag.
Fixes scheduleTransportsToSystem to actually constrain to the maximum amount allowed. (The computed value "xPop" was not actually being used. But it was what was logged!)
Fixes logic for determining that the attacker has a fleet in control of the target system, when not using combat transporters. The previous logic was only checking that the empire had a fleet "at" the target system. Unfortunately this led to a (observed) situation where an opponent repeatedly sent large numbers of transports to their certain death, because it would find that a fleet it had sent was at the system. But unfortanately for them, a fleet that has retreated is still considered "at" the system in a deployed (not orbiting) state -- and they kept retreating their fleets because they were not sending anywhere near the force necessary to displace the fleet I was holding in orbit at the system.
When relying on combat transporters, adjust force size for the effect of the target having subspace interdictors if indicated by available spy intelligence.