Error with "canNotTarget" #11617
Comments
|
ProblemWithcanNotTarget.zip |
|
Check you code and recode |
|
This Problem could do with a 2.6 label/tag otherwise it might get missed. |
|
@asvitkine It still errors in about 1 minute. Set all players to FASTAI. ps. this is not the same error as #11492 |
|
I think same error as this one: I'll dupe that one over to this one, but note that there was some good discussion on that one too. |
asvitkine
added
the
Major
|
I'm actually going to dupe this in the other direction. closing this as a dupe of #10647 since the other issue already has more investigation done. |
|
Actually, keeping this separate from #10647, as the symptom is the same, but the cause is not. In the other one, it's because we were considering infra units as participants in combat for determining step names. In this case, at least from the repro provided by WCSumpton, I think what may be happening is that the step names are determined by the first unit from a list of units, but then this can change if there are casualties, such that the first unit will be a different one for that group. But I need to debug more to confirm. |
asvitkine
added
the
Regression
This was happening because the code to generate step names was not excluding units that would not participate in combat, resulting in infrastructure units getting their own steps (which later did not match what the engine generated once the filtering took place). Uses the same logic as what's done for the battle to exclude units. This change required adjusting a bunch of tests that were previously not careful about which had mistakes in setting up mock battles where the units didn't match the territory (in terms of sea vs. land). Also makes the tests to mock game data properties leniently, so that only the ones being set to true need to be specified (removing lots of LOC). Includes a unit test. Fixes: #10647 Note: Doesn't fix #11617, as the root cause of that error is different, despite the actual error being the same. I will fix that in a separate PR.
|
OK, I believe this is fixed, but I would appreciate if folks can test more as there were at least two different causes of this issue. There may be others that I missed. |
|
Per the forums, looks like there are yet more causes for this error which still happens on the 1941 CD map: Here's one scenario that still causes an error:
|
|
Given the above, I wonder if trying to find the step by name is just the wrong approach. We could just track the attacking units for the corresponding casualty steps and match by those. |
|
I think I understand where you are going with the above. Let me setup some set piece battles and see if I can work out the cause. This will take awhile, I will get back to you with a post here. |
|
Some more info:
So in this case, the "parent" step (DefensiveGeneral) executes and then generates its child steps, but not based on what the units were initially, but based on what they are at this time. So then, it generates a different step name for casualties than what the UI expects (i.e. if there's only one casualty step needed, it generates the generic name, whereas UI may have had multiple specific ones). In an ideal world, I think it would be best to generate all the steps (not just their names) at the start and go through them for the battle. If a step becomes no longer relevant, it can just be skipped. But this is a big refactor that I don't want to do now since it would add a lot of risk to the 2.6 release. Instead, I think I have a solution which is to still save off some relevant information (i.e. firing units for each step) at the time we generate their names. Then, when we encounter the scenario where we can't find the step name, we can use that information to figure out which step it was before (via looking at the new set of firing units and check if they're a subset of one of the previous ones and getting the corresponding step). However, I think the above solution may still have holes, because I'd imagine we can get to a situation where attacking units did not change, but defenders did in a way that results in a split attack getting combined. In such a case, the UI would show two steps, but we're rolling them together. I guess yet another option would be to update the UI when the step list changes. However, it's not clear if this is feasible given that may require a network protocol change which we can't do in 2.6. Sigh. |
|
@TheDog-GH |
|
@asvitkine Using TripleA-2.6+14415 in a test game today 3 whole rounds and no warning messages, but on the 4th my 1st warning messages. This game was 11 rounds with only 8 warning messages. Looking at the time stamps of the warning messages, this might only be 3 actual warning/errors. Also the time stamps warning lines are always in pairs, so the actual number of real warning with be halved. This was a test for rebalancing the 1941 CD map, with 12 extra USSR units because of your TripleA changes, I will need to add more as Germany easily crushes USSR. So I would say for me this has gone from a major to a minor issue. (100+ warning to 8) Meaning you/we should concentrate on other issues to get 2.6 out. :) However, I will spend some time later this week trying to reproduce a setup with much greater occurrence for these warning messages. |
|
As RL was calling, I ran another AI game, this time only one error, with 2 warning messages on round 13 out of 17 rounds. Is it worth adding the Round to the end of the WARN text in the triplea.log, to aid with debugging. |
asvitkine
removed
the
Major
|
@asvitkine Could you add the round & the name of the territory in the text output to the triplea.log ? Here is an example from the triplea.log |
|
Marking as fixed again, via the additional fix here: #11838 Please let me know if you still see this. (Note: There is another type of "Could not find step name" error I saw on a different map that I plan to investigate, but I'm not sure if that one has anything to do with canNotTarget, so still closing this bug.) |
|
Darn, got to round 16 and got this error Im happy for you to come back to this at a future date, as the error is now rare, compared to before. |
|
Thanks, can you post a save game before combat when it happens? |
|
Using TripleA-2.6+14460 Error happened in Germany Round 2 from triplea.log Zip has just before(round even) & during(Germany Combat Move) |
|
@asvitkine You might need v131 Click It errors 3 out 3 times, hopefully you can track it down? |
|
Thanks, will take a look. |
|
As an aside, a lot of step names are generated for that battle: So many that it doesn't even fit in the default window height and there's no scrollbar. Anyway, here's what the log looks like for that battle: So Britain loses both the fighter and bomber-tac. |
|
That looks like the issue, Black Elk also thought it was to do with the loss of aircraft. Could the default window width be increased as some map makers use d12 and it looks very crowded with d12 on each side? In 2023 we have wide screens which were not common back in 2001. If the step frame could be extended to the bottom, touching the space bar frame, then more steps can be seen? |
Using engine version: 2.6.14357
Windows 10
In the unitAttachment "isSea" is false and "isAir" is false and using "canNotTarget" produces the following error: "WARN g.s.triplea.ui.BattleStepsPanel - Could not find step name:(attacking player) select casualties"
In the following save PoS2 game, 'infantry' unitAttachment was modified:
(did not accept save game file)
After loading save game, set Russian to Human and play. Select "done" to end combatMove, and select "Ukraine S.S.R." for your battle. After the error message is cleared, Russian casualties can be selected normally, so the error does not prohibit the selection of casualties, nor does it stop game play.
The following was added:
(did not accept save game file)
Do the same as above, not their is no error now.
Cheers...
The text was updated successfully, but these errors were encountered: