Blitz-Out Inconsistency (2.5.22294) #10643
Comments
|
@asvitkine May you fix this? I think it is strongly related to what you are doing at |
|
Please help me understand this scenario. How can Russia start a Combat Move in an enemy territory in Revised? |
Yes, this would never actually happen in this game or any other basic ones. However, it rests on basic rules. Do you agree with my (let's say) "extrapolation" of the rules to this case which can never actually happen in the basic games (but certainly can in other TripleA games)? The main thing which I believe we can certainly agree is wrong is the inconsistency between the first and the second points: West Russia should either be conquered in both cases or in neither of them. This said, we may then agree that the preferable solution is West Russia being conquered in both cases, which is my point. Otherwise, a property could be added by which West Russia would be conquered in both cases if false and in neither of them if true. In any case, the current behaviour is inconsistent and should be changed. |
|
Abstracting from the basic games I think I understand your point now. So let's assume a game, which rules allow units starting in an enemy territory. In this case Russia starts its turn in West Russia, that at this point has not changed ownership Now the question is: At which point does a territory change ownership? Abstracting a bit from Revised and enhancing the question to modern core rules (v3-v6 incl. 1940) the rules say that ownership ususally changes at the end of the Conduct Combat phase (during the Conclude Combat step). Only in the special case of a Blitz through an enemy territory the territory blitzed through changes ownership immediately before the blitzing unit continues its move to a second (friendly or hostile) territory. This - and only this - is blitzing. Now in your scenario we must first be clear about two different points:
I leave the first point open for now. As this must be defined by the mapmaker with his intended rules. There are of course several options. Concerning the second point I would say that - if the rules allow this starting position - the Russian infantry should be allowed to move its one point movement to any enemy territory. It should not be allowed to move into friendly territories, as we are in Combat Move Phase. The Infantry's move is totally unrelated to blitzing. (The rules may of course require that at least one unit stays in that territory in order to fight a battle against no one in order to allow for changing ownership). The Russian Tank however is a unit allowed to blitz, so the Tank should be able to enter an enemy territory as his first move (here Belorussia), taking this territory immediately when continuing his move to a second territory (hostile or friendly). So it seems to me that the question of West Russia changing owership is rather unrelated to the question of "blitzing". It might for example be defined that
Alternatively/additionally one could create rules for "land units starting in hostile/contested territories". |
|
@Cernelius Can you clarify how I can use the save game you attached? It doesn't have a tsvg extension and neither unzipping it and adding a tsvg extension or just renaming the zip to add a .tsvg extension makes TripleA be able to open it. Is there some weird trick to use these? Why not just zip up a .tsvg game and upload that? EDIT: Oh, I think it's actually a surprising behavior of the default unzip behavior in macOS. It somehow tries to decompress the inner file after unzipping the outer file. I think this only happens because the zip filename doesn't have include the .tsvg extension before the .zip. |
|
@asvitkine The above zip file contains the*tsvg file. Any zip-software should be able to extract it: |
|
I agree with @panther2 here, I think the state in that save game, which I assume was created with Edit Mode, can't really happen regularly, so now we're talking about custom map territories. So then, I'd treat it more as a feature request to improve the behavior for maps that may want that, as opposed to a bug per se since it won't happen regularly. Having said that, it looks like my blitz PR may change things here a bit, for example it does let the infantry move out of that territory into either of the adjacent enemy territories (since it's not related to blitzing). However, perhaps it shouldn't be doing that - since we want to default "can attack from contested territory" to false, so I think if we're treating this territory as "contested", it should prevent such movement (unless the property is set). |
|
OK, looking more at how this interacts with my current PR, here are my thoughts:
So based on the above, I think my PR is improving things here (reducing inconsistencies) and once it lands, this issue will only be limited to maps that set the new "Cannot attack out of a contested territory" property to true and can end up in a situation like this (empty territory with enemy units). |
This (The fact that I obtained it with edit mode instead of by playing a game regularly.) doesn't matter: it is something that can happen in a number of TripleA games. I could have obtained the functionally similar situation by starting Napoleonic Empires and playing it (without any edits) till getting to that, and the only difference would have been spending more time to do so.
The problem is (as I said) that the current behaviour is inconsistent. Can you explain me why I'm conquering West Russia when I move from West Russia to Belorussia but not when I move from West Russia to Karelia S.S.R.? I don't think there is a sensible explanation for that and it is also inconsistent with the fact that regular blitzing happens all the same in case I'm moving friendly - hostile - hostile and in case I'm moving friendly - hostile - friendly (for example, if I have an armour starting in Karelia S.S.R. (in the save-game), I blitz West Russia both in case I move Karelia S.S.R. - West Russia - Belorussia and in case I move Karelia S.S.R. - West Russia - Karelia S.S.R..
I don't think you should be changing any such behaviours unless you are doing it deliberately and documenting it in PoS2. I think most such behaviours have no documentation nor rules-books behind, so can be changed, but only if this springs from a general plan on how to define them (hopefully better than they are). The next step would be documenting everything in PoS2, so that people may know that how it works is how it is intended to work and won't have to test themselves every case to know how it works. This said, I think point 4 ("Move the infantry to Belorussia: impossible.") is a preferable behaviour. I think an infantry starting in a hostile territory must conquer that territory before conquering anything else but it can conquer nothing else than one territory because it cannot blitz, so the only way for moving the infantry would be point 3 ("Move the infantry to Karelia S.S.R.: West Russia is not conquered."), which I consider a correct behaviour too. If you intend to change either or both of such behaviours, I much suggest you add one or two properties to allow map-makers to go either way, preferably keeping the current behaviour as default. |
|
@Cernelius looks like we replied almost at the same time. Can you check my message above and lmk if you agree with my thoughts and plan here? |
Of course. I've also to reply to @panther2, since I disagree with something he said. |
|
@Cernelius |
Right, I think we can all see an inconsistency here, at least from a "realistic" stand-point. If I can blitz a territory I'm already inside by going to an other hostile territory, there is no reason why I should not be able to blitz it also by going to a friendly territory (Realistically, it should be even easier in the second case, as my units are only conquering one territory as opposed to conquering one territory and also making other combat-related actions on the same turn.).
Maybe, but, since strongly related matters are being addressed right now, it is probably about time to try to settle the whole picture rather than potentially changing behaviours without knowing where we are heading. The fact that we don't have a rule-book telling exactly what is right in every case will make much more difficult in the future to address inconsistencies you might add now.
I'm not seeing any inconsistency here as long as we assume an already existent and reasonable expansion of the implied rules beyond the limits covered for the basic games: I think it is a very reasonable extrapolation of the blitzing rule to blitz a hostile territory you are already inside, so I do believe the current behaviours on the matter are correct and to be kept. Rather, it is needed to document in PoS2 that it is intended for blitzing to apply also when exiting a hostile territory you could blitz by moving through (as I think it is most likely that blitzing by exiting only happening within the program must have been intended albeit undocumented as far as I know) so that everyone may know this is an actual TripleA rule, not something that just happens outside of any rules.
What do you mean? That as default you can do that and there is a property that, if true, makes you unable to attack out of contested territories? This would reverse the current behaviour which, aside from blitzing-out, is as default forbidding doing that. All this said, I agree that you should be unable to attack out of a contested territory if you are unable to blitz, but I believe that you should be able to blitz out (thus potentially attack out too) of a contested territory by blitzing the contested territory if it is a territory you could blitz by moving through. Practically, I think exiting a territory with a unit able to blitz should always be treated the same as blitzing the territory if the territory is eligible for blitzing (A territory is eligible for blitzing if it is hostile and with no enemy units beside infrastructures in v1 and no enemy units at all in v2+.).
This does solve the inconsistency outlined at this topic, but not the way which I think is preferable.
At this point, I start strongly thinking we really need a property that define whether or not you can blitz territories by exiting them even though I still tend to think this is how it should work (by simply expanding the basic blitz rules, which is what the program appears to be already doing albeit inconsistently: only when moving out to an other hostile territory and not when moving out to a friendly one).
As I said, this should better be addressed (right now that all other changes are being made) either:
As I said, I personally disagree that everything detailed is an improvement because I think the current behaviour of allowing units able to blitz to move from hostile to hostile by blitzing upon exiting (whereas the units unable to blitz cannot move from hostile to hostile) is overall much preferable. I maintain that, regarding the exemplified behaviours you can test by moving one of the units which are in West Russia,
I find them all reasonable and consistent except the first one, and would have them changed to:
I think this way they would be both consistent and sensible the most. As a second best, I would agree that the following would be consistent too (but much less sensible):
So I think it may be good to have a property or a set of properties which allow to choose one or the other consistent solution, per game. |
Two powers are in an Allied or Open Borders relationship. However, this is just one way it can happen. |
Sorry, I should have clarified that I was talking about the Napoleonic Empires map, not the Napoleonic Empires game: this is not possible in the Napoleonic Empires game but it is possible in all the other games of the Napoleonic Empires map. The games of that map in which this is possible are the "Napoleonic Empires: FFA 5 Player" and the "Napoleonic Empires: FFA 8 Player". I assume you only played the Napoleonic Empires game of the Napoleonic Empires map and never the other games of the same map. The only game of that map I ever played is "Napoleonic Empires: FFA 5 Player". |
|
@Cernelius Thanks for your detailed reply. Let me reply to your two main points:
I agree it should be fixed, but the code for changing territory ownership is completely in a different place than the move validation code I'm changing. So I think it should be in a separate PR. I don't disagree that fixing it makes sense. As another point, given it's a new area of the code base for me to dig into, I think it would be a worse use of my time than fixing some of the 2.6 regressions also in areas of the code unfamiliar to me, such as #10599 where the wrong number of dice are rolled or #10647 where there's error popups in 2.6.
Here, I disagree, let me explain my thinking. First, we're talking about very much an edge case. It requires a blitzing unit to start in a contested territory, which I think eliminates the vast majority of triplea maps. So the ones left are the ones with limited combat rounds (e.g. civil war), ones where politics can change ad hoc (napoleonic empires) and ones where the starting position or triggers create such a scenario. I think it's telling that we only discovered this as a result of explicit testing and never heard anything about this from players - i.e. it doesn't really happen much in practice. So given it's such an edge case and in particular, it doesn't come up with any rule book we're trying to replicate, so it's entirely up to TripleA how this should work, I think we should strive for something that's the most maintainable and doesn't result in a lot of extra complexity just for this edge case. In particular, my proposed "Can Attack From Contested Territories" property is very clear (given a clear definition of what contested means - but this is already well defined with the existing property "Contested Territories Produce No Income" - territory must not have enemy units). If we instead need to make it take into account blitzing, it becomes quite a mess, because then the new property would need to instead say something like "Non-Blitz Units Can Attack From Contested Territories" (default false) - in order to preserve existing behavior. And then you'd want a "Blitz Units Can Attack From Contested Territories" (default true) if you want to separately control this for blitz units. But it's not even "contested territory" for the blitz case right now, but "blitzable territory" which has its own definition. So as you can see, this would require a lot of complexity - both to explain how it works and in terms of properties that would be needed to support customizing this. But then stepping back, my argument is still that this has nothing to do with blitzing, other than the current engine not making a distinction between blitzes and non-blitzes for these attacks (i.e. some existing behavior that's questionable). If blitz is defined as being able to attack multiple times in a combat move given the unit's movement, then I don't see how it's relevant to the starting territory. (Edit: And all the definitions of blitz in A&A rulebooks talk about entering an enemy territory on your first move, clearly a case that doesn't apply here.) The last thing I want to argue is the question of "Does it really matter?". That is, if the case doesn't really come up all that often, because existing rulesets+maps don't run into this scenario and the ones that do, still need a pretty specific case to happen (i.e. ally -> war while having units in an empty territory), then it's a bad reason to add a lot of complexity in terms of new properties and engine code. Instead, it's better to go with a simpler solution, of which "Can Attack From Contested Territories" is clearly, and the alternative is not. |
I feel it being far from clear and you previously named it as "Cannot attack out of a contested territory", so which one is it? Can or cannot? All considered, I think there is a very high risk that your changes will make default things worse off and possibily damaging existent non-basic games meant to work under exactly the current behaviour. |
Sorry, I mispoke in that reply. It's "Can Attack From Contested Territories" defaulting to false - I did not change the name in my PR, it was this way from when I introduced this, so that false was a reasonable default that intended to mostly match existing behavior (obviously, the blitz case we're discussing is the discrepancy).
Yes, it applies as well. If property says true, you can do it, otherwise you cannot. As to what I want, my intention is to provide a property that allows such movement, hence if it's true, then units can move freely. So the false case is not relevant to that, but obviously we should ensure that the behavior in the default case is desirable. My argument is it is - as it makes it easy to reason about (since "contested territory" is well defined) unlike the current behavior and the current behavior is not based on any Axis and Allies rulebook and I don't think any maps are relying on it, because it's very much an edge case.
Can you clarify why you think it's a high risk? Everything we discussed seems very much an edge case with maps affected by this likely not even considering these cases, let alone relying on them. If we fix bugs in engine code, do you also think we shouldn't do it? (For example, my PR also fixes problems with air transportable units where they can be allowed to "blitz" even if they're not being air transported, as long as at least one of them is being transported.) It's changing behavior, so then you can argue some map might be relying on air transports working in this broken way, even though it's clearly a bug (and the code had a TODO to fix to validate properly). Also, to be clear, the current behavior is the error message is something like "Cannot blitz further into enemy territory", even if the unit doing this is an infantry that doesn't have blitz that started in an enemy territory. So the current behavior is clearly wrong. ... If we really want to keep the current logic, then I suppose we can make the new property something like "All Units Can Attack From Contested Territories". That's arguably an even simpler change than what my PR does, since we just disable the existing logic if that property is set, but imho the result is this strange blitz-specific logic that has nothing to do with blitzing... I'm curious what @panther2 and others (maybe @DanVanAtta who may be the person reviewing my PR) think about this. If everyone agrees that we keep this strange "blitz" behavior which is unrelated to how blitz is defined in the rulebook, then I can certainly rework my PR. |
Such matters have always been an undocumented problems-ridden mess nobody ever wanted (in my experience) seriously to put his/her hands on, to try to make sense of, but I think you are doing it with far too heavy axe-strokes. I reiterate I suggest you fix problems (comprising inconsistencies (for inconsistencies which can go multiple ways you may want to add properties like in the case of blitzing-by-moving-out, which is currently possible only if you go to enemy territory but not if you go to friendly which makes no sense)) while otherwise keeping the program behaviour as close as possible as it currently is. Meaning leaving alone as default whatever has no problems. By the way, while you are at it, are you also fixing that problem that you can use paratroopers or land units on blitzable enemy-owned territories to open the way for other paratroopers? It has been discussed a number of times, but I don't recall was ever fixed. For example, here: |
|
I still don't find the argument for blitzable units being able to exit enemy territories they start in convincing, but the other thing you brought up about moving to your own territories that are contested - I went to check with 2.5, and this is indeed allowed, whereas my PR causes that to change. I do think that may have a more impactful unintended effect, so that convinced me to maybe try to preserve the old behavior as-is when the new property isn't set. The good news is my PR is adding unit tests for all these scenarios, so once we decide what it should be, we'll now have test coverage for them so in the future, they can't accidentally change without someone realizing it. |
That was just an example. My point (that you are proving) is that I believe you should not go ahead changing things you don't even know how they currently work. |
|
To be clear, I'm not against changing things, but it should be at least deliberate: you know exactly how everything works and you know exactly what you are changing and why. |
Thank you, your assumption is correct. |
|
I will take a deeper look into all new information and comment on anything else later this |
|
Having read all the latest comments I don't have very much to add. Maybe let me summarize my thoughts as follows, as always based on core rulesets and the desire to argue close to them:
So I strongly vote for resolving this terriorial ownership loophole at first.
|
Situation:
A unit which is able to blitz moves out of an (enemy-owned) territory into an other land zone, and the territory has no enemy units in it (It does not matter what units are in the other land zone.).
Correct behaviour:
The territory (of which the unit is moving out) ought (always) to be conquered as if blitzed.
Current behaviour:
The territory is conquered if the other land zone is an other enemy-owned territory but is not conquered if the other land zone is friendly.
Savegame:
2022-6-12-World-War-II-Revised(blitz out).zip
Additional information:
You can test all the following behaviours by moving one of the units which are in West Russia:
The behaviour described at the first point is wrong (in that West Russia should be conquered), whereas all other behaviours are correct, so the first behaviour should be changed as to have West Russia being conquered upon exiting but not changing the other behaviours (In particular, West Russia should not be conquered when the infantry moves out because the infantry cannot blitz.).
Notice that this has nothing to do with the armour being able to move two spaces: what matters is the
canBlitzoption being set true, not the movement: the armour would behave here just like the infantry if the armour would have been able to move 2 spaces but unable to blitz.Please fix.
The text was updated successfully, but these errors were encountered: