Game works, Atlas works changes make sense => accept

Idea seems good.

The option doesn't do anything outside the in-game so I suppose in-Game is the place...

One fairly trivial change required => accept

Something in the lioness changed, small rebase

Broke the mp while at it, fix incoming

@smiley: what would you think a "toFixed" would do on a vector? What we wanted to achieve is reducing the size of the command.txt for positioning units, thus dropping the precision after the 3rd decimal (as who cares about that?). To avoid duplication for any further such request a toFixed was added in the vector file. Regarding your example: if you use toFixed you expect a string, thus + gets a certain definition, so I don't see anything wrong....

The horizontal size indeed is computed in js, since that size can change when you click on another tab, however the vertical size is the same always so coded in the xml. What went wrong in the initial slide panel commit (so it's not you who broke things nani, I did) is that the xml value or the background and front panel got different value. This was then masked by the ontick, but when that was removed, the real bug came out. However notice that the bug only happens when the panel width is maximal: in a small window everything is just aligned (Probably the reason I didn't find it....).

well from a ownershipchange we can't see if it will be a rename, so when the new ent is brought up, we don't know it actually replaces another (one could change the entitylimits and allow two wonders, so an owners check wouldn't work), so the new timer will always be activated, which afterwards needs to be removed. Also from the destroy we don't know if it is a rename (one could very well create and destroy different wonders at the same turn), so we have to do it with the ent rename.

grepped for completeness, agreeing on the change, translators will hate
(note to self: be careful with file move)

should be fixed now: rP22030

see revision, proposed the same

I guess every gui page should be able to access this file, also the mod-selection, thus mods/mod/gui/common should be the correct place

Isn't that what I say too? (notice the capital letter N)

Don't be fooled by those two extra calls D997 tries to do, 1 of the function got removed by rP21243, and the other seems a phab bug

Tested against DE, correctness forces me to press accept

Accepting because it is correct and complete for Danubius, but while looking at D1694, I guess the same bug can happen in (most of) the victory conditions, and potentially the other trigger scripts too (SotF, JB etc.)

Excuses for not replying to previous comments, and making you do an extra iteration...

reffing D997

Even better: the error wasn't introduced there

That should work

While committing thought of the programming.json: @nani please put your nick and if you want name in there and upload in a new patch on the revision so you are credited

introduced in rP20945 (code got shuffled a bit afterwards)

And here the guy to blame :S, can't even put off the blame by saying it was copied from the main-menu or ingame menu...

fix the edgy case when only nonConquestCritical structures/units remain

Was about to commit it, but the time displayed is minutes : seconds, so shouldn't the unit be something like minutes:ss?

15 removed cases, 10 added ones (if counting holds, the 15 goes down to 13 given the structure_defense_* comment)

Testing on fedora 28: patch doesn't solve the segfault, with or without the patch both segfault on lobby join. If required I could get access to a fedora 29 machine for testing.

Don't use a common/ global outside common/

Reflect the duplication avoid

fix an elexis' irc comment

complete as in all quotes around I and II are gone => accept

If that is so => accept

In D1590#63984, @Stan wrote:

What if as per article 18 one says he doesn't want his data processed for ratings. Do we delete the account ? Or do we force him not to go on rated games ? He might want to play with a fixed rating or no rating at all with player who want to get rated. How does it go

Which clause of art 18.1 applies?

Some digging in the GDPR leads me to two concerns (I am in no position to say if these are fixed everything is ok but would doubt if there are more problems)

Read the code and comments, but as having very limited knowledge about these matter (nor an urgent will to become an expert), can't say anything about the completeness.

In rP21441#31049, @elexis wrote:

Objectives should be as straightforward as possible, as simple as possible, so I'd rather have went with only the first rule as was the case before (which doesn't mean that there might be a simple alternative satisfying more).

The objective is straightforward now, as the timer is reset on every event that the "winning team" changes

If my allies were defeated or declared war on me, that shouldn't make me lose the victory timer.

Certainly agree for lms, but in an allied victory game loosing a team member for me is enough reason to say the "team" is defeated. But as there is a new team meeting the victory conditions, a new timer is set for that team.

The trick here is defining when the counter needs to be reset, to me defeating a player defending a wonder is enough reason to reset the countdown, one can argue differently however. But as the case is specifically named in the commit message Reset counters on playerDefeat requesting verification, further discussion should be in a trac ticket imo.

In D981#60827, @wraitii wrote:

Addendum: well while the above still seems true, another problem is that makeGoalReachable does not use a rounded rectangle but a flat one.

Checking for completeness is equal to going through all strings manually, so only checked for the Town Phase, I and II cases:

For some reason (couldn't quickly find why) a formation moves extremely slow right after it is created, when reforming (as in setting another shape) the problem is solved.

binaries/data/mods/public/gui/session/unit_actions.js has one too

So in code it technically needs to be playerName, interesesting (out of scope comment)\

Seems to be a pleonasm between research and technologies, but with costs also there => meh => ok

certainly better

fine with me too

Same for the brit one

Seems to be the correct English spelling indeed for the strings, in code I presume it should be BackSlash however => patch complete

If it would crash for mods, the mods would receive an error in the current code, thus not caching the file wouldn't change much there.

In the code there are many more cases of colour which strictly speaking should be changed, but whatever

Looks like fixed

certainly (didn't check if more of these cases occur, presumably yes, but that requires reading through all strings => meh)

Have a look at these also: (AI comments can be left out in imo)

Technically speaking of code and animations, the field is just as "constructed" as any other building, but probably sounds better otherwise