Looks sensible to me.

thanks for the patch

Slipped through in rP19194

In D1877#78342, @elexis wrote:

One argument for the button is that it looks more streamlined

Yes, I understood your reasoning and it's not inherently wrong to use a button, especially depending on which graphics represent the control elements. I just wanted to point out that that typically checkboxes are used for binary settings and buttons for actions. If I don't use red color, it's not a contractual obligation to perform changes.

Yes, I also understood your reasoning and found the arguments for a checkbox better than the arguments for a button, so I used a checkbox instead. (It appears that also is a reduction in LOC ;) )

Fix indent

Use a checkbox instead of a toggle button

In D1877#78328, @elexis wrote:

It's a multiple choice, either it shows the stats grouped per team, or it shows the stats grouped per player.
So naturally the options are:

• A checkbox
• A dropdown
• Radio buttons (in HTML, we don't have it in Pyrogenesis GUI)

The purpose of a button to perform an action, not to trigger an option.
So a checkbox [x] Group per team seems more nearby to the purposes of GUI object types me.

Yeah, that seems like a better alternative. (One argument for the button is that it looks more streamlined.)

Remember the state of g_ShowTeamCharts when summary is closed.

player graphs:

I guess you should apply the comments of the linter.

In D1849#78009, @elexis wrote:

I think it's just a minority of mac users.

@vladislavbelov got numbers on mac users and perhaps number of mouse buttons?
Even without numbers, if we can estimate that the option is relevant to half of mac users, it sounds relevant.
Imagine you have to play on a mac and can't use right click. Your ability to use the game is strongly impacted, no?

Many mac users have normal external mice.
There will also be many that just use "two-finger clicks".
So there should only be about 2%-10% remaining. (I am no mac user, so I am just estimating)

In D1751#77632, @elexis wrote:

I'd prefer to not use the simulation as imho minimap pings shouldn't be in the simualation. They are a purely gui thing, just as chat.

Seems like I was arguing with myself. I already do the pings as simulation commands. xD Sorry for my confusion.

Rounding for INTEGER and PERCENTAGE. Seems saner to me.

In D1751#77680, @elexis wrote:

Yeah it's bad that it will be defined for all GUI objects, but I don't see this as a blocker.

rP22134, adds only a little bit of mess, not a blocker, someone else can fix it afterwards
D1781, adds only a little bit of mess, not a blocker, someone else can fix it afterwards
D1751, adds only a little bit of mess, not a blocker, someone else can fix it afterwards
Who will fix it?
Why should he fix it?
When will he fix it?
Why should the code be introduced with a known defect?
Why do I get accused of wanting to stop people from progressing if I point out anti-patterns that only add a little defect for now that can be fixed in the future by someone else?
Created #5442.

@weberkai I guess this newer version of the patch still fixes your issues?

In D1849#77631, @elexis wrote:

Sure, but I don't think that would match in the manual.

What stops us from keeping the manual in sync?

Yeah, why not.

And why is the manual not the first place to look at if the purpose of the diff is to inform mac users how to adapt their thing rather than in the source that only developers see?
If the setting is relevant to all or the majority of mac users (is it?), why would it be overkill to expose it in the GUI?

I think it's just a minority of mac users.

Make the License Bear happy ;)

In D1877#77655, @Stan wrote:

How does it handle changing teams during the game ?

Tiny style fix

Hide the Toggle button if no teams

direct return

Fix comments.

No idea, but does it make sense to test against that behaviour?

Cache replay directory path

Way better. Can't see any performance loss compared to svn anymore. 👍

In D1851#76602, @Freagarach wrote:

In D1851#76566, @Imarok wrote:

Yeah, that doesn't always have a meaning ;)

I know, but since I had an idea about how to do it, I thought I could just share it with the community and perhaps get some feedback in the process. It is not that I *expect* this to come into the main game, I think it is merely a start ;) And perhaps a help to others.
It would be a shame if bad ideas get lost ;)

In rP19674#33135, @weberkai wrote:

Hi!
Good news!
The Differential D1852 fix the issue!
Awesome work guys! Congratulations!
Thank you very much!

In D14#76593, @wraitii wrote:

In D14#76586, @Imarok wrote:

Hmm, seems like it takes far longer to load a map.
Just quickly tested with Corinthian Istmus (4):
Svn took about 7 seconds.
With D14 it took about 18 seconds and I got a notice from my OS that it seems like the program has hung up and if I want to go on or quit the program.

That's weird. Is it stuck at 100%? The only thing I can see taking more time is the thread creation, but that really shouldn't add 9 seconds

Yeah, sorry. I measured the time I was stuck at 100%.

Hmm, seems like it takes far longer to load a map.
Just quickly tested with Corinthian Istmus (4):
Svn stuck about 7 seconds at 100%.
With D14 it stuck about 18 seconds at 100% and I got a notice from my OS that it seems like the program has hung up and if I want to go on or quit the program.

In D1751#76309, @elexis wrote:

Perhaps draw vs. display can be made consistent.

Yeah, sure.

There is a conflicting name MT_MinimapPing in components/CCmpMinimap.cpp.
There should only be one minimap ping, so one of the two should be renamed.

I know. I planned to rename the MT_MinimapPing to MT_MinimapBlink

So in the current revision it works this way:

1. GUI -> send simulation command and displayMapPing locally
2. Commands.js -> record to replay and broadcast GUI message
3. messages.js -> displayMapPing -> GetGUIObjectByName("minimap").ping = true and GUIInterface drawTargetMarker;

yes

I mentioned GetGUIObjectByName("minimap").ping(position, template); is also possible by editing the JSInterface_IGUIObject.cpp function (this file should be split into one file per GUI Object type, since the new function will be added to every GUI Object type).
But not having to hardcode the GUI objects seems preferable, then people can add a second minimap if they'd like to, or rename it.

That was what I looked for. Thank you ;)
I'd prefer to take that way. Yeah it's bad that it will be defined for all GUI objects, but I don't see this as a blocker. We can still use two minimaps as long as they both use the MiniMap class.
I'd prefer to not use the simulation as imho minimap pings shouldn't be in the simualation. They are a purely gui thing, just as chat.

In D1849#76530, @elexis wrote:

Where would you add that to inform the users?

In the files that inform users about hotkeys? Which are the same as:

Which two other places are traditionally kept in sync with this file?

A third place was mentioned in the comments too.

Fix years

In D1851#76554, @Freagarach wrote:

Also I saw the ticket

Yeah, that doesn't always have a meaning ;)

See D1852

@elexis should GetDirectoryName really called that name? Isn't GetDirectoryPath more appropriate?

Picking hidden gaia entities really sounds like cheating. ;)
Also do we really need scouting? With a few shift+clicks on the minimap a unit can be ordered to scout the whole map.

In rP19674#33124, @elexis wrote:

@Imarok wanna fix this, have it tested by @weberkai and approved by vladislav and me?

In D1849#76384, @elexis wrote:

In D1849#76361, @Imarok wrote:

In D1849#76307, @elexis wrote:

Which two other places are traditionally kept in sync with this file?
Also, how many mac players will look at default.cfg?

To my knowledge this is the only place where macmouse is mentioned. It's neither in the manual nor on the hotkeys wikipage as it is no hotkey.

So the intention is just to inform developers who modify default.cfg, but not to inform users with a mac mouse that their hotkeys might need to be changed?

In D1849#76307, @elexis wrote:

Which two other places are traditionally kept in sync with this file?
Also, how many mac players will look at default.cfg?

Imho the large bar looks to big for the small fishing boat

In D1751#70488, @vladislavbelov wrote:

I think we should restrict the number of pings, because I'm sure there will be many spammer on servers.

Rebase and apply the proposed changes

Ok, seems like I shouldn't try using the private svn for phab ^^

Rebase

In rP22230#33084, @Polakrity wrote:

So it was intended. :d

In D1754#76083, @elexis wrote:

(Also am I the only one using libboost 1.69.0-2 or am I just the only one too stupid to resolve the build errors? I better get them resolved if I want to commit my own patches)

See https://github.com/boostorg/random/issues/49 (Found by Vladislav)
(Also see discussion at irclogs 2019-04-04 around 21:44)
TLDR: just ignore the notes and wait for boost 1.70

In D1752#72574, @elexis wrote:

I guess worldclick doesn't work since it only reacts after left-click; unless we make that hotkey a modifier (minimap click + hotkey(default shift) for instance).

Yes.

So the question is how minimap ping should be implemented for the people who don't have a third mouse button.
Isn't the usual way to add a button near the minimap, that if clicked changes the input.js state, and if that state is set, both the minimap "worldclick" events and the clicks on the actual 3D world would equally trigger the 'minimap ping'?

Fix indent spotted by Stan

Rebase. Disable Website button if selected mod has no url.

Apply comments of elexis

In D665#76122, @elexis wrote:

The expected player experience is that the ship moves to the closest point to the shoreline where the units to be picked up are.
The current behavior is that the ship moves to the correct island, but upon every garrisoning moves to a presumed better location again (which turns out to be a waste of time in many cases).
If I understood the patch correctly, the behavior of the patch is that the ship moves to the closest shoreline, which may be on an entirely different island, at least.
So if I understand the patch correctly, it changes one defect for another.
But the patch might be adapted to match the expected user behavior.

One easy fix would be that the ship won't move if the units can be garrissoned with the ship not moving.
Or just never move the ship.

Seems like that won't work cause of template_unit_ship_fishing.xml

Do changes according to inlines

In D1461#73338, @elexis wrote:

Good.
Now the question remains how we make it visible to the players that this click-feature exists.
Usually the mouse cursor changes when one hovers a link. Underlining won't be supported by our small font base, but adding a sprite should be easily possible (resource icons in tooltips.js / setup_resources.xml as an example).

Didn't look closely at it, but we definitely shouldn't copy the general fsm definition, but instead put it somewhere where UnitAI and input.js can use it.

In D1837#75515, @wraitii wrote:

not an expert then again.

In D1482#75880, @Stan wrote:

In D1482#75878, @Imarok wrote:

In D1482#75871, @Stan wrote:

I can't really review my own patch ^^

But you can review the changes of the guy that commandeered.

Nothing changed :D

Then I don't see, why he has commandeered it...

In D1482#75871, @Stan wrote:

I can't really review my own patch ^^

@wraitii I guess you have overseen @vladislavbelov's inline comments. ;)