windows 10
.7746 still ok, .7752 to .8659 not ok
all 270BC maps, Bad-Ass 4 Nation FFA
In 270 BC maps opened from depot, the alliances are all screwed up. If you export the xml from game and look at alliance section. It shows 4 nations listed in both roman and anti roman alliances.
In Bad-Ass 4 Nation FFA, I only noticed a stats panel glitch and roundels listed inconsistently so far. But once the above 270 BC error was established. I also exported the Bad-Ass xml to see if the alliance section is listed incorrectly. And it is incorrect.
Note that the xml is correct if viewing the files from their game folders. So looks like the game engine makes the changes after it loads the xml. And, or the xml export just lists those changes.
270BC, quickest way to see there is a alliance problem is to go to Politics Panel and notice relationships are wrong.
So far these are the changes it added (and don't belong) to the 270BC xml via export (once loaded by game engine), Note, so far I have only looked in the alliance section of xml.
alliance player="Carthage" alliance="RomanAlliance"
alliance player="Numidia" alliance="RomanAlliance"
alliance player="Macedonia" alliance="RomanAlliance"
alliance player="Syria" alliance="RomanAlliance"
Link to the Bad-Ass related bug report here.
https://github.com/triplea-game/triplea/issues/2855
So far these are the changes it added (and don't belong) to the Bad-Ass 4 Nation FFA xml via export (once loaded by game engine), Note, so far I have only looked in the alliance section of xml.
alliance player="Envoy_III" alliance="Envoy_I"
alliance player="Envoy_II" alliance="Envoy_I"
alliance player="Envoy_III" alliance="Envoy_II"
Hopefully it is not changing any other sections of xml as well. Might be a good idea to scan through an entire xml file for any thing else, that stands out. Via the xml export.
Ya I just finished narrowing it down GZ.
It is either this one
https://github.com/triplea-game/triplea/releases/tag/1.9.0.0.7752
or this one
https://github.com/triplea-game/triplea/releases/download/1.9.0.0.7746/TripleA_1.9.0.0.7746_windows-64bit.exe
it works fine in 7743
@General-Dru-Zod @prastle Thanks for doing the heavy lifting of finding which version this broke in. Indeed, I see the problem between 7746:

and 7752:

7752 (via #2681) made some changes to the AllianceTracker class, so that's probably a good place for us to start looking.
@RoiEXLab
Off topic but I am curious why I couldn't download 7746 due to deletion from a virus. Every other download for testing has always worked from GitHub. This is the first time I have ever seen that. Does anyone else have this error from windows defender for this download? or just me? Thus why i couldn't isolate between the two. 7746 and 7752
@ssoloff The only thing that could have altered the behaviour in the AllianceTracker class seems to be this change, because I recall being unsure about that.
However I find that very unlikely, so I'd assume the root cause is lying somewhere else.
I'll look into this tomorrow unless, of course, you can find the cause earlier and fix it.
@prastle
I had just downloaded .7746 today to follow-up on the above topic. It downloaded ok, and I have windows defender and McAfee LiveSafe. So it must be just yours, hehe ;)
KK thanks Gz dam bumpkin internet! :)
@RoiEXLab Reverting the change to AllianceTracker#getPlayersInAlliance() seemed to fix the problem. I'll try to write a unit test to characterize the difference in behavior so we can get the non-Iterator implementation working as expected.
Does this not mean that all current stable users need a new release?
@General-Dru-Zod @prastle This should be fixed in 1.9.0.0.8677 or later.
Does this not mean that all current stable users need a new release?
See my answer here.
@ssoloff Yep, it looks good. Fixed this issue as well as the primary complaint in issue #2855. Thanks
FWIW the current latest has been downgraded to pre-release. We're back to: 1.9.0.0.7621 as latest; before this problem was introduced.
Most helpful comment
@RoiEXLab Reverting the change to
AllianceTracker#getPlayersInAlliance()seemed to fix the problem. I'll try to write a unit test to characterize the difference in behavior so we can get the non-Iteratorimplementation working as expected.