Page MenuHomeWildfire Games

Clean up group win messages in EndGameManager
ClosedPublic

Authored by temple on Dec 6 2017, 3:57 AM.

Details

Summary

Clean up group win messages in EndGameManager.
History at rP18441 and rP19955.

Test Plan

Verify that it's the same.

Diff Detail

Repository
rP 0 A.D. Public Repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

temple created this revision.Dec 6 2017, 3:57 AM
Vulcan added a subscriber: Vulcan.Dec 6 2017, 4:01 AM

Successful build - Chance fights ever on the side of the prudent.

Updating workspaces...
Build (release)...
Build (debug)...
Running release tests...
Running cxxtest tests (308 tests)....................................................................................................................................................................................................................................................................................................................OK!
Running debug tests...
Running cxxtest tests (308 tests)....................................................................................................................................................................................................................................................................................................................OK!
Checking XML files...
bb added a subscriber: bb.Dec 12 2017, 10:50 PM
bb added inline comments.
binaries/data/mods/public/simulation/components/EndGameManager.js
54 ↗(On Diff #4591)

things are ultra bugged with that is relicgames but out of scope

72 ↗(On Diff #4591)

not only for groups, since 1 player is just as treated as a group as 8 players would, IMO comment can be removed

77 ↗(On Diff #4591)

ack

83 ↗(On Diff #4591)

We can avoid this check by using the QueryPlayerIDInterface(playerID).getMutualAllies() function and storing those players in winningPlayers in advance. But that results in looping over all players twice, so perhaps meh

(seeing the relic case, the winningPlayers could perhaps be better given as an argument, but out of scope too)

96 ↗(On Diff #4591)

butbutbut that should be always true, since playerID is in it

104 ↗(On Diff #4591)

(this one is ok though, since everyone else can be non-active and stuff, or everyone allied)

temple added inline comments.Dec 12 2017, 11:14 PM
binaries/data/mods/public/simulation/components/EndGameManager.js
72 ↗(On Diff #4591)

I took it as a verb, we're grouping together each of the win/defeat messages.

83 ↗(On Diff #4591)

I didn't think about that, but I guess since we want to ignore previously-defeated players we can't avoid the loop.

temple updated this revision to Diff 4755.Dec 12 2017, 11:15 PM
This revision was automatically updated to reflect the committed changes.

Successful build - Chance fights ever on the side of the prudent.

Updating workspaces...
Build (release)...
Build (debug)...
Running release tests...
Running cxxtest tests (308 tests)....................................................................................................................................................................................................................................................................................................................OK!
Running debug tests...
Running cxxtest tests (308 tests)....................................................................................................................................................................................................................................................................................................................OK!
Checking XML files...