2.6 Release Getting Close - Need Volunteers to Help Beta Test 2.6

[zlefin]

@myrd

I don't understand why you mention doing a battle calc on another player's turn not being considered, as my issue was occurring when i did battle calc on my own turn, which caused my own nation to be the attacker and defender

at any rate, ty for the work on fixing it, which ever path is chosen.

Personally I'd revert it to the behavior it used to have: which iirc is that of the first hostile nation in the list.

[LaFayette]

@zlefin The code for choosing attacker/defender is reasonably well commented: https://github.com/triplea-game/triplea/blob/master/game-app/game-core/src/main/java/games/strategy/triplea/odds/calculator/AttackerAndDefenderSelector.java

In your game, is the current player not at war with anyone? In this case, it looks like you could see the behavior of same attacker/defender. Namely due to this logic:

// Add the territory owner add the end of the priority list.  This way, when attacking an
// empty territory, the owner gets preferred even though they have no units in their land. In
// case the owner has units in the land, then they are already in the list but adding a second
// entry to the list doesn't impact the algorithm.

If there are no hostile nations, and you own the territory, and you are already the attacker, it looks like we could wind up with same attacker/defender.

[zlefin]

@lafayette

the nation in question was at war with some nations. It's a map with two fixed sides that are at war with each other from the start.

[Myrd]

@zlefin

I guess the "attacker == current player" logic was implemented and discussed here: https://github.com/triplea-game/triplea/pull/9602

I agree it doesn't make sense if the current player is clicking on their own territory, though.

[LaFayette]

Attacker == current player is consistent; predictable, usually desired since the current player is attacking and not defending.

When clicking own territory, it is essentially the same as selecting the attacking units first rather than using the territory that is to be attacked. This is common in multiplayer games. In multiplayer games you do not want to plop units into the territories you are thinking of attacking, it's shows exactly which battles you are considering.

The odd thing is that the defender should not be the same player, any of the opposing factions would be fine. Ideally it would be the next at-war faction based on the turn order of the game. For example, in Revised, as Russia, if you ctrl+b click your own territory, it should be setting up an attack (russia is on offense) and the next opposing faction is Germany. When Germany does similar, it would be UK on defense.

[zlefin]

I suppose that makes sense; personally when I'm attacking I just use the ctrl-a to add the relevant units.
When I open battle calc on my own territories its for checking the defensibility vs counterattacks or future turn hostile attacks.

As long as there's an easy way to do that as well I guess I can get used to the new system; since adding ssettings to let people choose how they want that behavior to be done would be too much work, at least given the numerous other work demands at present.

[LaFayette]

@zlefin Roger. Having options/variations might over-complicate things from both a code & user perspective. At the same time, it's not fun to constantly redo various clicks (which speaks to a poor UX).

Interestingly enough, it's surprisingly detailed how we expect the calc to work. The way I think it would ideally work (cc: @Myrd ) :

"ctrl+a" -> units owned by the current player from the given territory are selected as attackers. If no units are owned by the current player, then whomever owns the most units in the territory is chosen as the attacker. If the territory is empty, then the attacker is selected to be the territory owner (which could be "the neutral" player).

"ctrl+d" -> similar to 'ctrl+a' but operates with defense & ignores the current player (current player should be selected as the attacker)

"ctrl+b" -> same as "ctrl+a"

---

If the above sounds wrong/unreasonable - please speak up - but please add your comments here: https://github.com/triplea-game/triplea/issues/12688

[zlefin]

That sounds like you'd be changing the existing system so that ctrl-a and ctrl-d are opening battle calc windows of their own, rather than adding units to the existing battle calc window. I don't see how that would work with adding multiple locations worth of units together, which is one of the major purposes of those commands.

Since multiple calc windows can be open at once I don't think that would work at all.

[LaFayette]

@zlefin I see your point. I failed to mention that is a description of only initial behavior if no window is open. If there is an existing window, then 'ctrl+a' and 'ctrl+d' would work as they do now.

[LaFayette]

This is big: 2.6 lobby is up with some bots

There's some more to do, but the current 2.6 lobby and its 4 bots should stay running. Please give it a thorough vetting.

To access the 2.6 lobby, just use the 2.6 version of the game. 2.5 will continue to connect to the 2.5 lobby.

cc: / @Myrd

[LaFayette]

Couple Known problems:

• Admin toolbox is still broken in 2.6..
• bot info log needed needs attention. Looks like more things are printed in chat than before

[beelee]

@lafayette

Gave it a couple quick test runs last night and then just now.

Tested "Global 40 Expansion UHD Boxes" and "UHD World War II Global" on bot 101

Got the same errors in the chat box. Couldn't find a test map in the yaml or something. I will post them in full below.

G 40 wouldn't fire up but UHD did, so maybe I need to update the yaml on triplea and try it ? I just updated the repo last time.

I will try a different bot as well as a yaml update.

In case you need a saved game. UHD only one to fire.
2024-7-10-UHD-World-War-II-Global 2.6 Lobby.tsvg

[beelee]

@LaFayette

Tried bot 104 and got EXP to fire up. Wasn't able to get it to fire on 101 though. This is after updating the mapyaml at git.

I will try 101 again.

Also got this error

I think they need time to switch to the other map maybe.

[beelee]

@LaFayette

Is this where you want these reported ? I can't edit my posts.

[Cernel]

@beelee said in 2.6 Release Getting Close - Need Volunteers to Help Beta Test 2.6:

@LaFayette

Is this where you want these reported ? I can't edit my posts.

https://forums.triplea-game.org/topic/2998/2-6-testing-report-2-6-problems-here

[LaFayette]

re: where to report

For reporting.. "filing a bug" AKA, creating an 'issue' in in github never really hurts. At this juncture, IMO let's mostly stick to this forum thread. Forum threads do have a weakness where it is hard to maintain a conversation across multiple topics at once. At the same time, I think this thread really has become the "command-and-control" of 2.6; thus let's mostly stick to this thread please.

[LaFayette]

G 40 wouldn't fire up

Sounds like a problem. I would like to learn more about this.

Also got this error (Expected countries...)

Go ahead and click "Report to TripleA"; later if you would, please find the issue it created & update it with the map name, bot name, etc..

I think they [the bots] need time to switch to the other map maybe.

Good thought, though nothing updates the maps on the bots automatically once they are downloaded. They can be re-downloaded though. That would need to happen. Further, bots need to be restarted to see any changes.

---

The errors in the bots need to be cleaned up and/or fixed, but are otherwise benign:

[WARN] Error found in ..... "test-map/map.yml"

This comes up when all maps are parsed, and it is essentially saying, "out of all the maps that I have - this one is bad". The test-map is likely not available for play. Which is just as well. The 'test-map' is there for test - during code builds we actually verify that we can pull down and read the details of the test-map.

So, we just need to delete the map from the bots. I think the maps-server was previously configured to ignore it, and the maps.yaml file is not updated to have it -so that map is effectively invisible otherwise.

The 'download maps' scripts also needs to be a bit smarter to not download that map again after we remove it..

---

[Error] failed to save game

This is more serious, but very fixable. I didn't set up the bots quite fully just yet. The folder '/home/bot' does not exist & needs to be created. That will fix the problem. In the meantime, the auto-saves aren't being saved.

[LaFayette]

Re: testing 2.6 - help needed! Compat of save games from 2.5 to 2.6

Something that occurred to me. If people can help with this aspect - we need to try and be sure the 2.5 to 2.6 upgrade path is pretty smooth. I'm thinking to make sure that 2.5 save games can be played in 2.6 for sure.

[ubernaut]

@lafayette i think with TWW at least they r not can test if u like but pretty sure

[LaFayette]

@ubernaut only caveat is if something didn't work in 2.5, it might not work in 2.6; Otherwise, I'm really eager to see how the latest 2.6 does in lobby with the 2.6 bots.

2.6 just had a few patches, bots too, & moderator toolbox was recently fixed.

I'm not currently not aware of anything that is badly broken for sure, but you guys are kinda of hinting at some things!

Yeah, mention details of anything that seems broken!