Mon, Mar 18
Grepping says these are all cases of seige, so correct and complete
Sun, Mar 17
Reads correct, checked all formation templates => accept
I get that some languages use singular for every other prime number, so to speak. But isn't exactly that the reason why we have markForPluralTranslation, so a translation can choose for which values it takes whatever form. If that isn't the case in the current code, we might have found a bug in our code. Stating the same problem more concretely: how is this particular call different from all the other markForPluralTranslation calls? or are all of them just wrong? (there are some in buildrestriction, wonderVictory, CaptureTheRelic, triggerHelper and Treasure Island)
Code should stand on itself, not referring to a phabricator revision. But isn't markForPluralTranslation designed to cover this case? So how does this solve the issue?
Furthermore markForPlural expects 3 arguments, now it only has 2.
Is that lengthy comment really required? Seems obvious from the code (or it is me who has such a language as mother tongue)
Period complaint while at it
Candidate != must be moved, I guess those should be in the children then...
GarrisonHolder: change the Max attribute in the childs, put the rest in the parent
That is a good point indeed, so we should be looking at which properties we can move to the military parent. Territoy, Vision, GarrsionHolder and Sound seem to be the biggest candidates
Can I propose to make a template_structure_military_training (or find better name) template as a parent of barracks, stable and range? That would solve the duplication of this patch and D1790
Patch reads correct, unit demo test succeeded, grep gives translate hate=> accept
Sat, Mar 16
Idea is ok, but patch is inclomplete: your grep doesn't seem to have found the skirmish buildings (the templates under skirmish/structures/)
Indeed inconsistent and misleading naming. Patch correct and complete, front doens't fall, also not in atlas
Game works, Atlas works changes make sense => accept
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....).
Jan 19 2019
Jan 6 2019
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.
Jan 5 2019
grepped for completeness, agreeing on the change, translators will hate
(note to self: be careful with file move)
should be fixed now: rP22030
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
Jan 4 2019
Isn't that what I say too? (notice the capital letter N)
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...
Jan 3 2019
Dec 27 2018
Even better: the error wasn't introduced there
Dec 26 2018
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)
Nov 24 2018
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.
Oct 17 2018
Aug 5 2018
Don't use a common/ global outside common/
Aug 3 2018
Reflect the duplication avoid
Jul 30 2018
fix an elexis' irc comment
Jul 26 2018
complete as in all quotes around I and II are gone => accept
Jul 16 2018
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?
Jul 9 2018
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)
Jul 2 2018
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.
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.
Jul 1 2018
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.