AA-fire/casualty selection issues in Revised (and other versions)
-
@panther said in AA revised minor bug:
@cernel said in AA revised minor bug:
You mean the defender, right?
No, the attacker chooses to take out the air unit casualties shot down by the defending AA gun(s).
Right, got mixed up a bit there. Eh, I wouldn't mind an option for letting the AA firer choose casualties, but this would be an off topic feature request.
-
@cernel said in AA revised minor bug:
Regarding the AA firing for the attacker, thus possibly having same type targets belonging to different players, that is something relevant, as, in custom games, you may have that, as, in TripleA, you can have AA firing against defending units too (like you can even have aircrafts making AA shots against AA guns). This is just one of several cases that will be necessary to take into account, when correcting this bug. Another matter, for example, is that, while in the basic games all AA targets have 1 hitpoint, in TripleA you can have air units with multiple hitpoints or AA targeting not-air units with more than 1 hitpoint. So, in this case, if I have, like, two dragons that are under AA fire, one with 1 damage and the other one undamaged, and I'm using v2/v3/v4 casualties selection, should they count for different groups, when they currently have different hitpoints left, or should the dragons' owner be able to decide what dragon is taking the damage, by having them part of the same group, no matter how much damaged? The other matter is that, while in the basic games you have something like v5, in which you have a limited number of AA shots (up to 3 per AA guns, instead of infinite) and full casualties selection, in a custom TripleA game you can have limited number of AA shots, like in v5, but inter-type random assignation of hits (currently fully random, but this is the bug), like in v2. That would be another challenge, about how that should actually work (If I have 6 AA shots with 13 eligible targets divided into 4 group types, who is going to get the hits, at the end?), in the moment in which the hit assignation is not anymore purely random per specific unit, like instead it (wrongly) works now. And it will be very important to fully document how everything works, in pos2. I hope the developers will make sure of that.
Apart from the core game principles we have already discussed in this thread, your scenarios add another core game principle of A&A games: the multinational defense. In A&A games - as you know - if the attacker scores a hit, the defending players will have to agree about the casualty. If they cannot agree, the attacker chooses. In TripleA you usually see all valid units of all powers involved in the battle screen and can choose the unit you want to take out.
Concerning units with two hitpoints we have that situation in regular battles against battleships. Here the defender is (or the defenders are) totally free whether to assign two hits e.g. to two battleships or to sink one battleship. It is always the choice of the opponent(s) how to assign hits.
Regarding AA-fire (or better "AA-like-fire") I don't see a reason to negate these principles.
All in all I would recommend to resolve this as follows:
- Roll against groups of units if possible (ignoring the defending power and ignoring already assigned hitpoints)
- Among those groups let the defender(s) choose. In case there is more than one defender let all of them agree. In case of two-hit-units let the defender(s) choose how to assign hits, too.
In v5 and Global1940 games this is easier: The number of shots is determined by the number of AA-guns or targets, and (unless special rules apply) the opponent is free to choose.
IMHO this matches the A&A rules as close as possible.
-
@Cernel Unfortunately there appears to be a random factor in casualty selection in v5 (so most likely in 1940_any as well), too. In the attached savegame, 5 bombers (with remaining movement points 1,2,3,4 and 5) bombed the Moscow factory. The AA-gun shot down two of them and the engine removed a bomber with 1 movement point left and a bomber with 4 movement points left. So we have an issue here, too.
0_1538464873078_v5test_2a.tsvg -
So all in all we have a thread that started as "AA revised minor bug" and that turned into identifying and describing some major issues affecting all versions (except maybe v6).
-
@Panther or other, is there another bug report for the major issues uncovered? Could those issues be summarized for a bug report?
-
@LaFayette Yeah, this thing really needs to be fully summarized in a bug report. One of me or @Panther could do that, I suppose, and the other one double check it, but it would be quite a lot of work, for something that maybe will be just closed off in 6 months. Anyways, I'll check it out, if anyone does it.
-
I mean, if there is a developer that it is interested in looking into this bug, to fix it, I can see to summarize it, as it is really something of some importance, but only if also the current behaviour is going to be kept, as an option, even if maybe not currently used by any maps, as I think the official one is really strange.
EDIT: We could keep the current one working for pos2, as, since that map was made by veqryn, we can be pretty sure the behaviour was intended.
-
@Panther said in [Open] AA revised minor bug:
So all in all we have a thread that started as "AA revised minor bug" and that turned into identifying and describing some major issues affecting all versions (except maybe v6).
Yes. All versions but v1 and v6 are surely affected.
v6 is surely not affected.
v1 we still have to clearly define it; so this issue cannot really be fully summarized until that is covered too, actually. -
@Cernel said in [Open] AA revised minor bug:
for something that maybe will be just closed off in 6 months.
Ice box is harsh, but compare that to this bug which has not even been looked at... Which would you prefer, for a tactical decision of "we're not going to get to this" compared to "whoops, we did not even see this."
The other aspect is about maintainer efficiency. We're few and very stretched. It used to be the full time job of multiple people to keep up with the project. So that we can make progress and not just tread water with responding to issues but actually fix issues, there are some efficiency gains needed.
It is also hard to say who will and can pick up the bug. If the "cost of entry" is to spend 45 minutes reading to then figure out this is something you can't work on, that is 45 minutes that could have been spent actually fixing something else. It is the case that new dev's come along and they need projects that are easy to pick up so they can become engaged with the TripleA codebase. Having bugs to require so much background hinders that.
In my professional experience and learnings, bug tracking where you have this situation is a project anti-pattern. It leads to these long bug queues that never get solved and you spend a lot of time curating bugs not actually fixing any.
So yes, we need a summary if there are items that need to be fixed, and ideally they would be placed in the official bug tracker so that the maintainers do not have to spend time bouncing between a set of forum posts and the bug tracker
-
Well, to be honest, for me there is also the issue that I believe how it works now is more realistic, or anyways I prefer it. Of course, this shouldn't matter, as nobody asked me about that, and I'm not saying I like bugged stuff, as I realize a bugged behaviour is not reliable.
And, as I said, we still have to get around clarifying v1, as I believe the official rules and clarifications there are unclear. We might have to get back to someone official there, actually, meaning moving to another forum.
-
@Cernel Okay, if there is something that needs to be fixed, we need a bug report. A bug report has four elements (it's actually kinda formal):
- status: is it open or closed
- reproduction steps: minimized list of actions to create the problem
- problem description: typically a "notice" line that says, notice this behavior, that is the bug
- expected behavior: a description of instead of the 'notice', what should have happened.
Of course, the more terse and to the point the bug report the better, short and sweet. Forums perhaps dovetails here as identifying the actual problem and discussing what the right fix can be difficult. Typically I've seen that best handled by simply re-creating bug reports to be concise summaries of longer threads, so one closes an old bug and opens a new short one (in this way the 10 pages of text is then converted to a proper bug report that then has a better chance to be picked up and fixed). The open/close status is just for efficiency, you need to be able to answer "what are the open bugs? What should I look at?". The repro steps and problem description is so the dev can create the problem and know they are looking at the same issue. The expect fix is explicit so we know how to fix, it can be not obvious what the right fix is. Software is stupid exact, exact steps of what should be done are required. This then combines with the repro steps so that a dev can then repro with a fix to ensure the problem was actually fixed.
Those 4 items define a bug report. As a software project, that is what is needed for us to be able to effectively fix bugs.
I continue to be disturbed we have a 'bug' section in forums as none of those items are properly tracked in a conversation thread, they all need to be simulated by manipulating titles and the 'prompt' of this is the information we need can only come from a 'read this first' post. It can be made to work, but it's for sure simulating proper bug tracking software in forum (aka conversation) software.
-
@LaFayette If this whole matter would be summarized in a way to be complete and understandable (that would really require a number of examples) (which we cannot do until v1 is clarified too), it will be a really long wall of text, and still require the best part of a hour to be fully understood by someone having no idea about it.
-
@Cernel Understood, that wall of text is probably better as a wiki document to summarize how V1 should function. From there, for actual bugs, I'd recommend divide and conquer and break down each independent item to its own bug report.
-
@LaFayette No, actually, what I meant is that v1 is the one we haven't fully sorted out, mostly due to the lack of good documentation, and it might not be bugged, though I doubt it. For the remaining part, this is about a number of different things working differently in v2 OOB, v2 LHTR, v3, v4 and v5/Global. Some of those things are more important than others, and a few are substantially irrelevant, even if theorically wrong.
-
@Cernel Ah, thanks. I'm thinking a wiki document with a summarized set of "this is how it should work" (per ruleset) would be really valuable. We could then compare actual behavior to that document to know where the bugs are. A discussion thread like this is essential for creating that document, it'd be great to see this take the next step so we can incorporate this knowledge back into the game.
-
@LaFayette said in [Open] AA revised minor bug:
@Cernel Ah, thanks. I'm thinking a wiki document with a summarized set of "this is how it should work" (per ruleset) would be really valuable.
Yeah, that would be really cool to have, for each basic maps from v1 to v6, plus a general list for the things that apply to all of them, but it would be really a huge effort that only a very few people can do (practically, you need someone having a virtually perfect knowlenge of the intended rules and a virtually perfect knowledge of the program and maps behaviour, to see where they differ). On top of that, if such a thing would be telling the players what they are supposed to look after (or edit), then it should comprise both issues at an engine and at a map level. In a way, @Deltium has starting doing it for Revised, due to the need of regulating the ToC where TripleA doesn't fully support correctly.
I might see if I can put something together for v3 at least, I guess, but not promising. It would not be a short list...
-
@Cernel said in [Open] AA revised minor bug:
you need someone having a virtually perfect knowlenge of the intended rules
Indeed, though that's a good place to start! The process of comparing what actually happens vs what should can happen over time.
-
@LaFayette said in [Open] AA revised minor bug:
@Panther or other, is there another bug report for the major issues uncovered? Could those issues be summarized for a bug report?
Some time ago I created a list of currently unresolved rules issues here:
https://www.axisandallies.org/forums/topic/32958/triplea-engine-known-rules-related-bugs-issuesI am happy to maintain that list on this forum, too, so I have just copied it. Find it here:
https://forums.triplea-game.org/topic/1549/triplea-engine-known-rules-related-bugs-issuesCurrently I am not aware of any other wwII-game rule issue that we do not already have a Github issue for, at least v3-v6 (including wwII_1940_any) should be investigated and covered well.
Some of those issues mentioned there contain further implications for v1 and v2 - but those never have been investigated any deeper. -
@LaFayette The issues of this specific topic are summarized here:
https://github.com/triplea-game/triplea/issues/4133v2 is elaborated on in detail, the other games in brief.
-
@Panther Looks like that really needs to be closed to ice box.:smirking_face:
Anyways, I think that list is very brief, and more like a items' listing for people already fully knowing what the matter is. For example, when you see something like "incorrect timing of AA fire (different rules for OOB and LHTR apply, but both versions are affected)", there's no way you can know what that means, unless you do (or learn it, for example by reading through this thread).
EDIT: I see that this specific matter has been subsequently detailed and also discussed, in that issue. Sort of duplicating what we already did here.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login