-
Notifications
You must be signed in to change notification settings - Fork 164
-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Planet invasion only possible on odd turns if planet does not have defence regeneration #2488
Comments
Hi all, do we have a tag for issues which concern effect application order? Or should I open an issue in which i reference relevant issues? |
|
Would a workaround be acceptable? Like always growing shield to minimum value one? |
Better to always attack (trigger combat with) enemy planets even when they have no planetary defences? |
Before planets were only targeted if armed. Not sure actually why. This should fix issue freeorion#2488
The default target condition for only considered armed planets valid targets (not sure why). |
Then ships will attack planets many times pointlessly... players will probably find this annoying, like if ships attacked other already-destroyed ships. |
Absolutely. |
That would basically be the same effect like having one of shield/defense growing to minimum one, right? I am not sure how infrastructure is handled ATM at all. Does it get lowered after defense is shot down to zero? |
I think it is anyway necessary to target all planets which have infrastructure left. Enforcing a minimal value of one construction FOCE is KISS and should do the job of re-triggering combat. In that case only a single bout is wasted on "already defeated" planets. |
? |
I meant "Enforcing a minimal value of one construction using FOCS" |
…ensure combat happens so planets may be invaded Infrastructure (construction) boosts planetary defense so ship weapons should target all planets which have infrastructure left. Enforcing a minimal value of one for construction via FOCS is KISS and re-triggers combat every turn which allows troops to invade the planet. Only a single bout is wasted on "already defeated" planets, which is acceptable.
…ensure combat happens so planets may be invaded Infrastructure (construction) boosts planetary defense so ship weapons should target all planets which have infrastructure left. Enforcing a minimal value of one for construction via FOCS is KISS and re-triggers combat every turn which allows troops to invade the planet. Only a single bout is wasted on "already defeated" planets, which is acceptable.
Just noting that there is another egregious effect of this bug, which is that ground troops continue to accumulate on the planet during these bugged turns. Usually planets under siege do not accumulate ground troops, at least not at the full rate, IIRC. |
It seems this bug has come back or was never fixed. I wonder if it could be solved by swapping the order in which shield regeneration and combat or invasion happens. I think of two alternatives, dunno about any possible backfire:
That way, and assuming ships are targetting shielded planets in combat, the invasion will happen always when shields have been knocked down, and combat can still kill troopers to frustrate the invasion. Or
Thus the invasion happens before shield regen, aborting the shield regen issue, but that makes that defensive ships that came right before this turn cannot kill any troop ships to frustrate invasion, which seems wrong to me. |
Provide a save that demonstrates the issue? |
I've edited OP with a link to the new save file that Heracliton uploaded to the forum. |
I'm playing vs AI using latest weekly test build. I've attacked a system of an AI that has:
It does not have Planetary Defence Network 2, nor Planetary Defence Regeneration 1. My fleet arrived at turn 53, combat ensued, defending fleet was killed and planet defences&shields were zeroed. I assume I should be able to order invasion in this turn 54 if I had troops in the system (I don't). I have not tested Heracliton save file. Edit: once I got troops there, and before the AI got Planetary Defence Regeneration, the button for invasion was available on every turn. Definitively, I cannot reproduce the issue. |
@geoffthemedio @agrrr3 Check out their responses here. That I wasn't able to reproduce the bug might have something to do with the fact that I was using Arc Disruptor (that has no combatTargets clause) and they were using MD/Laser/etc. which does have combatTargets clause. |
Just popping in to confirm that the bug has occurred in the ninth multiplayer game, on turn 23. I had attacked planet Reverie on turn 22 and wiped it out. On turn 23 there was combat but the planet was not attacked so it regenerated. On turn 24 I had to attack it again, and I finally landed my troops on turn 25. Oleg can provide the save (but not to me because the game is ongoing). |
It's now occurred again on turn 30, in a totally game-breaking way: Oberlus has two colonies in the Alnasl system; on turn 29 I attacked and wiped out all ships and one of the colonies, but the other one had some defence remaining. On turn 30 combat occurred again and the other colony was attacked, but the second colony wasn't and regenerated: now I will never be able to zero both planets because the one zeroed last turn will always regenerate! |
Besides the obvious bug - Cant you invade a planet at a time? |
Yes, if my troop ships are sufficient by the time I get there - but every turn the regenerating planet grows more troops, which should. not. happen. |
Can I just ask a dev to explain how much is understood about this bug? It was fixed before and is a regression, so does that make it easier to find and fix? As well there is Oberlus's observation that it doesn't happen with Arc Disruptors, so maybe that helps. I ask because we're considering compiling our own server version for the 9th multiplayer game just to fix this bug, and we have a limited time window before the server admin (Oleg) goes away for a week. If it is a few-line patch I'm happy to apply it and compile and test it myself... |
I haven't looked at it. I don't know if anyone else has. |
This sounds like a serious issue, which should be fixed for the release. Reopening. |
Ah, ok. Good 😃 |
Not fixed for outposts yet I believe - reopen? |
Environment
Description
After the first combat in a system you plan to invade (if you got enough fire power), the planetary defences and shields are knocked down and you can invade.
If the planet has defence regeneration, on the following turns there will be some planetary defence and another combat will trigger, the shields will keep at zero and so the invasion will be possible anytime.
However, if the planet does not have defence regeneration, on the following turn there will be no planetary defences, combat will not trigger, and the planet will regenerate 1 point of shield, stopping your planned invasion on the following turn. Then, after that turn without combat, the planet will have some defence, trigger combat and enable invasion for the third turn. So you can invade this kind of planets on the first, third, fifth, etc. turns, but not on the second, fourth, etc. turns,
Forum thread: https://www.freeorion.org/forum/viewtopic.php?f=25&t=11297
PR that brought in this undesired behaviour (meter growth migration from C++ to FOCS): #1941
I remember there was discussion about this here in github or somewhere in the forum, but I can't find it.
Expected Result
On all following turns after the first combat and as long as there are armed ships ready to attack, all enemy detected planets keep shields at zero, regardless of the defence techs researched by its empire, and so can be invaded on every turn after the first combat.
Steps to reproduce
There is a game uploaded to the forum thread linked above.
To reproduce this on a different game, it is easier to find when invading native planets, that will not have defence regeneration regardless of the game turn.
Edit: issue reappeared or was never truly fixed. Heraclion provided a new save game here.
The text was updated successfully, but these errors were encountered: