In D1723#68508, @vladislavbelov wrote:

In D1723#68498, @gentz wrote:

Yes, but you will need to login to upload/vote on/comment on/report replays, so might as well have them log in.

Should it be a requirement - to login?

Well, requiring users to login for those actions will help moderators moderate. I guess the alternative would be to remember the IP which did an action, but that doesn't strike me as a good alternative.

In D1723#68506, @elexis wrote:

• Ideally it should work with the pyrogenesis engine in general, not only with 0ad that uses it. Other pyrogenesis games may use different replay attributes, so it would be more versatile to avoid hardcodings where possible. (Perhaps such a game would have to specify an own set of supported properties that the backend would have to load to support them.)

Yeah, that's a good idea. I'll add it to the todo list.

In D1723#68492, @vladislavbelov wrote:

In D1723#68484, @gentz wrote:

I was planning to host it myself on an OVH VPN, as I don't imagine it will consume that much space.

I'm not sure that it's possible to store WFG collected data on third party servers.

Wouldn't be this be no different than modio? WFG doesn't host that either, afaik.

Remove some things.

In D1723#68482, @vladislavbelov wrote:

Before review I have arch-questions:

• Why boost.asio was used? ModIo uses CURL and actually does the same thing. So I'd prefer to not have different ways for the same goal.

In D1723#68465, @smiley wrote:

(Might want to ask who ever maintains the WFG servers whether this is something that is affordable space wise)

Some of Stan's suggestions.

Prep for the Replay viewer.

Username querying.

Fix feedback. Make code more consistent. Add window that opens when replays are pressed on. Add UserDatas parsing code.

Add submission date column and fix scrollbar.

In D1723#68257, @elexis wrote:

Wanna post a description what this feature is about?

In D1717#68290, @elexis wrote:

One could also make it a COList setting whether or not to use linewrapping. Could even make it a config option for the replay menu, but I'm not sure if it's useful enough (as it costs some user attention time / GUI space).

If linewrapping is enabled (whether forced or not), then one must also consider the possibility for an item producing so much height that the COList becomes unusable.
Perhaps the number of characters per cell could be limited to account for that.
For example the lobby gamelist could contain games whose gamename has practically arbitrary length (ticket somewhere).

Isn't this sort've unrelated to this PR? Linewrapping has always been enabled for the items. It's just that prior to these changes, it would start wrapping too late.

I forgot to include CMultilist.{cpp,h}

In D1717#68205, @vladislavbelov wrote:

I didn't find your name in credits (wasn't you added yet): are your credits in the D953 are up to date?

They are up to date.

In D1717#68034, @vladislavbelov wrote:

The context is still unavailable. Also usually a patch needs to be created from the root folder for an easy apply.

I can't add context without dragging in changes I don't want in. Here is it done from root, however.

In D1717#68027, @elexis wrote:

Not sure about the removal of the headerheight property. I guess the setting is not so important, because noone wants the column header height to be lower than the textsize, nor does anyone reasonably want wasted space there.
But consider that the column sorting sprites also need to be accounted for.

And now I have to manually edit the patches... (via svn diff COList.* ../../binaries/data/mods/mod/gui/common/modern/styles.xml ../../binaries/data/mods/mod/gui/gui.* | vipe | arc diff --raw)

I've been doing svn diff COList.cpp | arc diff --raw, because I didin't want to pull in my other changes to the different parts of the code base.

Accounted for cases where width is absolute. Also made it sow that the header expands to fit the whole text.
https://i.imgur.com/u8M8jKN.png

Missed one

Translation thingy

Made it throw an error instead.

@elexis @Imarok What exactly should I change? Do you want me to make it only send the differences across the network?

In D1195#48465, @elexis wrote:

What does it show if I change every gamesetting while nobody set ready? Only the last setting changed or every setting changed? If it's the first, it seems misleading, if it's the last it seems too spammy, no?

Even when I was not ready I got every change message from more options.

Fixed these 3 bugs:

1. 3 random messages the host gets when he starts hosting, how do I get rid of those?
2. Scrolling too fast makes it cycle between the real message and another message
3. The first proper message appears twice for some reason

Maybe have it so that the summary is by default at where the options go right now and then have the options take its position when their tabs are presses? Honestly, I've never actually read the map description cause I've found it easier to glance at the map settings.

Can the map description bellow the tab buttons be converted into a tab like the rest of the settings? If you do that then the tabs buttons could be made less wide which I think would make them look better.

IMHO I think D1027 is a better solution for cramming more things in the bottom. I've removed things related to the map options. (A.k.a 90% of this patch)

This looks awesome but I've experienced a couple issues:

1. You get pinged every time you enter the lobby if your name was mentioned in the past. It should only ping once.
2. Leaving games, or having others start games or others leaving games gives the following error:s

In D953#37332, @leper wrote:

Both change set "b70ae970d45d" (Part 1's parent) and change set "336759fb7df0" (Part 9) fail with the linker errors mentioned previously. So it was fixed earlier than that,.

later, not earlier.

My bad.

I've started git bisecting the issue, gimme a couple days at most to finish bisecting.

In D953#37300, @leper wrote:

Do you still have that git(?) using thing around? If yes, care to test if the fix occured in April 2016? (At least that is when some of the related code changed https://bugzilla.mozilla.org/show_bug.cgi?id=933257.)

In D953#37274, @leper wrote:

(and only add one cast if it turns out to be ok).

You'd need both casts, as after you cast the first one, it gives a similar warning for the second.

Fixed small typo

Sorry for taking to long to get back on this.

Fixes comments