AA-fire/casualty selection issues in Revised (and other versions)
-
@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.
-
@Cernel said in [Open] AA revised minor bug:
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.
Indeed, at Github I tried to summarize what is spreaded within this thread.
-
@Cernel said in [Open] AA revised minor bug:
@Panther Looks like that really needs to be closed to ice box.:smirking_face:
Maybe it is just time to remove the misleading word "minor" from the title of this thread.
-
@Panther It's actually funny to see that as the title of how many posts thread. I suppose you can feel free to paste the title of your GitHub issue as the title of this thread.
EDIT: Not that really matters about ice boxing it, mind you.
-
@Cernel said in [Open] AA revised minor bug:
@Panther Looks like that really needs to be closed to ice box.
In some ways, if an issue is that old.
In this case, it is still quite current and the topic has come up again; In this case seeing if the task can be sub-divided, re-summarized and created as fresh, but smaller and easier to solve tasks is a valid approach. In theory it would have already been ice-boxed, and without an open issue we would have opened one again. Regardless, perhaps take a look at the old queue @Cernel and see if you really want the few devs to work on those issues or should instead focus on instead something like this? There are lots of issues that became old/stale, maybe one day we'll be able to re-open them. Meanwhile, I'd encourage you to be a bit less butt-hurt about it.. The goal is to shrink the bug queue and have it be sustainably getting smaller. The long tail of less important items detracts from the more important ones; a long queue is a cost in of itself.
-
My e-mail is blowing up with all the activity in this thread! I dare not follow the discussion though. If anyone needs "expert" information on the book rules for AA revised, let me know. Otherwise I'm not of any use.
There was some debate and disagreement following my original post and I'm not even certain how it concluded but I fully stand by my original comment in terms of what needs changing. Basically, the moves made in Combat Movement should be tracked and at the end of Combat Movement the aa should roll. Looks like you have been discussing individualized aa rolling for aircraft - that sounds good to me. Generically, aa casualties shouldn't be electable by attacker or defender, but there are options for that in game set up.
GLHF.
-
@LouisXIVXIV said in [Open] AA revised minor bug:
There was some debate and disagreement following my original post and I'm not even certain how it concluded but I fully stand by my original comment in terms of what needs changing. Basically, the moves made in Combat Movement should be tracked and at the end of Combat Movement the aa should roll.
This has been officially clarified you (and me) were right (tho I was not sure, because I think the rules were not that clear). Of course, that is true the exact same way both for Combat and Non Combat Movement. The only other thing here is the fact that in v2 OOB air units that participated in combat return immediately after combat, so you roll those before the ones that are just non combat moving.
Looks like you have been discussing individualized aa rolling for aircraft - that sounds good to me. Generically, aa casualties shouldn't be electable by attacker or defender, but there are options for that in game set up.
Yes, this has been clarified too (at least I'm taking @Panther word here). Casualty selection is exactly the same for v2 OOB, v2 LHTR, v3 and v4.
On this matter @Panther did we fully officially clarify casualties selection for v5/Global too (where you have AA factories and AA guns for battle only, with limited shots (and escorts/interceptors in case of Global))?
-
@Cernel said in [Open] AA revised bug (AA-fire/casualty selection issues):
On this matter @Panther did we fully officially clarify casualties selection for v5/Global too (where you have AA factories and AA guns for battle only, with limited shots (and escorts/interceptors in case of Global))?
We have analyzed that during this thread and identfied "only" the randomness of casualty selection as issue.
-
@LaFayette @Cernel
Regarding that "Ice Box" discussion:Starting with Veqryn and continuing until today the developers have always assured me that "rules compliance" belongs to the most important targets of the TripleA-project.
My main concern has always been rules compliance. That is why I dedicate a lot of my time to rules clarifications and to rules-bug-hunting and disregard playing by forum or playing the real board games. That is totally fine, I am happy with that - as I decided to adjust my personal priorities this way.Speaking about priorities - looking at those issues discussed in this topic and in the above mentioned list - I see sort of a discrepancy between the target (rules compliance) and the efforts to reach this target code-wise.
This is no complaint. Just a description of the status quo. I totally accept that everybody supports this project according to his priorities. I do nothing else.On the other hand it would be frustrating to see issues like those discussed in this thread being ice-boxed. What about the target "rules compliance"? How important is that? What is the point of discussing rules? What is the point of rules-bug hunting?
In case rules-issues really get ice-boxed, we should really discuss the targets of the project and if rules compliance still is an issue.
-
@Panther If there is something ice-boxed, and it is an active issue and worth the attention, simply create a new bug. Ideally the new bug would be a very well written, short, concise, bug report with a link to the previous bug that was ice-boxed for more background and any other conversation threads.
If you really don't want to go to that trouble, just copy/paste the closed bug report. That level of non-effort might not be that well received, but at the end of the day active issues should be tracked as open issues.
AFAIK all items that are for bad game rules are still open and the issue expiry is being ignored for them. Those issues being on page 3, page 4 of the queue is not a good thing. It might feel good to have a ticket not be closed, but if it's still open and months old, it's not getting looked at. The time having passed is evidence that something has gone wrong, there is no reason to think that waiting N+1 months is going to lead to more success than waiting N months. Breaking up tasks into smaller tasks, making them more concise with easier to follow steps and a clear call-to-action of how to fix can be the difference sometimes.
In general, I would agree that rules compliance is very important. Beyond problems that cause game crashes, correctness of the game rules is about more important than anything else I can think of.
I think my ideal situation would be for the game to define 'rule sets'. In this you could select which rule set to play as an option. So for example you could switch to LHTR V3 rules as simply as you do when adding a bid or going to low luck. I'd like to see each rule under each rule set be selectable as a checkbox option. In this way every rule variant would find its way as a line item in a set of game options. On the code side, it would map to a pretty specific way the rules would be applied to the engine. Personally it's something I'd like to work on, but it's behind a few other initiatives. The barrier is that the current way the code is structured, it's pretty tangled and adding such options would not be clean, the rules are pretty hacked in and there is a lot missing. Due to the importance given to rules, that is why I'm ignoring any kind of ice-box policy for those issues even if them hanging out at the back of the queue is effectively the same thing.
-
Re: ice-box, one item I did not mention is just prioritization. Time elapsed is a proxy for importance and priority. I don't ever want to call a problem low priority, but some impacts are more significant than others. I'll also note that nobody had more issues get ice-boxed then me. I think I had 30 or 40 some problem reports get closed due to age.
Again though, if something is an active issue and there is no open bug, just file the bug report. Part of the goal is we drew a line and then said "anything we get we'll fix within 6 months, or we'll be honest and admit we'll never fix it". Then you try really hard to make sure things get fixed within those 6 months. If an item is worth re-adding, it's important, and it'll then (ideally) get fixed.
One problem of course is our capacity is very low, overhead is really high. So as much as I'd like to say I'll fix all these problems, the reality is I'm going to get 5% done of what I want towards this project over lifetime. It's one reason I keep bitching about maintainer efficiency, in some scenarios I see us spending a lot of effort to not even get 5%, but instead just 1%. I'll be really happy if a third of what I want to get done, gets done in the next half year or year.
-
@Panther said in [Open] AA revised bug (AA-fire/casualty selection issues):
@Cernel said in [Open] AA revised bug (AA-fire/casualty selection issues):
On this matter @Panther did we fully officially clarify casualties selection for v5/Global too (where you have AA factories and AA guns for battle only, with limited shots (and escorts/interceptors in case of Global))?
We have analyzed that during this thread and identfied "only" the randomness of casualty selection as issue.
I'm not sure what you mean. I believe v5/Global are not bugged, as in those games there is not any kind of randomization (or groups separation) of AA casualties.
However, at the GitHub issue, I see that, for v5/Global, you have listed "attacker cannot choose casualties (casualty apparently is taken out on a random basis), tested with factory-built-in AA gun against a bunch of bombers)".
I've tested "World War II 1942 Second Edition" and "World War II Global 1940 2nd Edition" a few times using TripleA 1.9.0.0.13066. In a total of 4 tests for each one (for Global2, I had the units never starting from a territory with an airfield) in which any bombers were shot down, the program always took out the ones with the lowest movement left; so, aside from this being a coincidence, it doesn't seem to behave purely random like, say, v3. Moreover, I tested bombing raiding with both bombers and tactical_bombers in Global2 (editing the factory and the fighter out of France, then sending all bombers and tactical_bombers at reach to raid the airfield), and it allowed me to select AA casualties between tactical_bombers and bombers (I got 1 hit and I was able to select either a tactical_bomber or a bomber as casualty), as I believe it should be. I cannot do this second test for v5, and I know the only way to test this for sure (beside reading the assigned properties in the xml and assuming they behave coherently, at least) would be making a mod in which we have multiple types of bombing raiders (like giving bombing ability to the fighters too), and see if the program lets you pick the type. Anyways, I can at least say that, based on what I know, I cannot confirm there is a bug here, until it happens to me too. If you want to upload a savegame showing in v5/Global the behaviour that you have described in GitHub, I'll take a look at it.
On this matter, but more in general, when you can fully select casualties (that is the case for AA guns too in v1 and v5/Global, but not for the rulesets between those), TripleA always takes (amongst the same type) aircrafts with the least remaining movement first. Am I correct that, for all games since v1 onwards, this is arguably a TripleA issue, as, instead, you should be able to take aircraft with higher movement left first, if you so want (and TripleA doesn't allow you to)?
So, to be exact, for v5/Global only:
1: The AA Guns are not bugged (beside the fact that aircrafts with the lowest movement left are always selected first), and work as intended, as they are supposed to work just like Classic, except only for battle and with a 3 shots each limit.
2: The self-defending factories under bombing raids are not bugged (beside the fact that aircrafts with the lowest movement left are always selected first (but in case of bombers, this should be actually what you always want)), and work as intended, as they fire only at bombers (never at fighters), and the defender is supposed to freely pick casualties, anyways.
-
@Cernel said in [Open] AA revised bug (AA-fire/casualty selection issues):
Anyways, I can at least say that, based on what I know, I cannot confirm there is a bug here, until it happens to me too. If you want to upload a savegame showing in v5/Global the behaviour that you have described in GitHub, I'll take a look at it.
I have uploaded that savegame already here:
https://forums.triplea-game.org/post/16633Another user experienced it as mentioned here: https://github.com/triplea-game/triplea/issues/4133#issuecomment-445928137
-
@Panther Any information on the TripleA version used to make those savegames?
-
@Cernel You can use the current stable to look into it.
-
@Panther Using the current stable, I confirm it happens to me too on the game "World War II v5 1942 SE TR". However, unless that is a stupendous coincidence, "World War II 1942 Second Edition" and "World War II Global 1940 2nd Edition" appear always taking the bombers with the lowest movement left first.
Can you test the same situation on those games too, se if it happens there too (you don't need to send any fighters in attack; I've no idea why you did). I'm starting thinking it might be something wrong with the "World War II v5 1942 SE TR" mod only, assuming this is not related to some changes for that "tournament rules" version only.
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