Might I suggest to save this as a patch and apply it on premake when updating update workspaces on OsX ?

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

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

Yet another lib that might be detected by configure even though we don't have it and we don't need it. Disabling it explicitly is needed to link pyrogenesis.

Instead of abandoning this revision which was superseded by D1610, D1609 and D1685 (in order of committing), I take the liberty to commandeer it to include yet another manual disabling of a library we do not use.

This should use premake5.lua's macosx-version-min variable in order to avoid hardcoding. With D1685, this will actually be 10.9.

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

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

Final version.

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

Final version.

In D1684#66783, @elexis wrote:

As you see, I was right, with the patch you need to change a more number of lines to add new values to the GUI stack.
The patch now forbid to use different values passed to the GUI stack, only functions.

"Only functions" is the part that makes no sense to me

As you see, I was right, with the patch you need to change a more number of lines to add new values to the GUI stack.
The patch now forbid to use different values passed to the GUI stack, only functions.

"Only functions" is the part that makes no sense to me

In D1684#66778, @elexis wrote:

In D1684#66775, @vladislavbelov wrote:

The patch now forbid to use different values passed to the GUI stack, only functions.

I think you didn't read the patch right

I think you didn't read my comment right :)

In D1684#66775, @vladislavbelov wrote:

The patch now forbid to use different values passed to the GUI stack, only functions.

I think you didn't read the patch right, because with and without the patch, one passes exactly one argument (that must be cloneable) to the callback function init called from PushGuiPage, and exactly one argument given by the PopGuiPage to the close function passed to PushGuiPage.
The patch does not remove any argument, but moves one property of the initarguments to a separate function argument.
Notice how wrong it logically is to add the function name of the close function to the arguments of function init(data).
So even the contrary - the currently committed code forbids to pass objects with an unrelated callback property to the init function, whereas with this patch that restriction is removed.

The patch now forbid to use different values passed to the GUI stack, only functions. Before the patch someone could easily add another param (with C++/JS modifications).

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

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

Remove core.js closePage function formerly used by viewer.js.

In D1683#66749, @elexis wrote:

the sky is in infinity. So all clouds move together with the camera

If you mean the clouds in the sky texture, that doesn't seem like a problem.
If we want closer clouds, they should be separate from the skybox probably: #46.

Yep, clouds in the sky texture. Separate "clouds" we have only as particles. Anyway close clouds should be separate, yes.

the sky is in infinity. So all clouds move together with the camera

If you mean the clouds in the sky texture, that doesn't seem like a problem.
If we want closer clouds, they should be separate from the skybox probably: #46.

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

The DisplayMessageBox function introduced by rP7390 should have been deleted in this commit, because:

1. This commit removed the only call to DisplayMessageBox
2. As stated by the commit message: "stop hard-coding the message"
3. C++ should be agnostic of JS/XML contents . It can send an event (for example replay-finished or oos-error) to the GUI and then the GUI can decide how to present it.

In D1679#66719, @Stan wrote:

I understand your point. My concern was mainly about people who don't report bugs because it's not a common thing to do :)

I understand your point. My concern was mainly about people who don't report bugs because it's not a common thing to do :)

First of all, I can reproduce the crash on Fedora, and the current patch does fix it when the TLS box is unticked. So the C++ change is good ?

What about people on those platforms who have fixed it themselves. This is more of a library bug rather than the OS.

A better idea.

We could add some text under the TLS encryption saying its broken, on WinXP + OsX < 10.12 + Fedora ?

I guess it’s low priority if it only affect a subset of a platform. Same goes for the glsl crash too.

In D1679#66711, @smiley wrote:

The problem of crashes still persists. The average user would not know (wont even try probably) the cause of the crash. And there would be a lot of “disable TLS” replies to reports. Pop-up or a tooltip would do maybe.

Arguably the previous diff was better, because it didn't confuse the uneducated player further in the login dialog. Arguably this diff is better, because it empowers the educated player.
As a third alternative one could commit only the cpp + default.cfg diff, as linux people are usually smart enough to edit a config file, and the other platforms, macOS and windows, seem tested by us.
Meh.

The problem of crashes still persists. The average user would not know (wont even try probably) the cause of the crash. And there would be a lot of “disable TLS” replies to reports. Pop-up or a tooltip would do maybe.

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

Add the checkbox in to the login/register page instead of options dialog.

I guess it's better if the option wouldn't exist and if there was only a message box popping up, asking the user if he wants to proceed if the connection is unsafe, otherwise presume TLS.
But that would require a bit more rework - first attempting to login with TLS enabled and then asking if that failed - which is also not an option to circumvent any TLS handshake crashes...

Some kind of a warning or a note under places which could end up crashing.

Better would be a fix, investigating.

Compiling the entire GnuTLS / gloox / 0ad stack cleanly everytime in a VM takes 30min and makes my system unusuable or even freezes it, so it ended up being deleted...
especially because the next best platform can have broken gloox as well,
considering how many gloox/gnutls bugs are already reported,
and considering that I hardly know every detail about gloox, gnutls and fedora for every version.

I agree. My intention is just to clarify if we can find something we all agree on so we can aim for that.
And this decision has some impact on this ticket that's why I'm bringing this up.
What's you thought in this, @elexis ?

+1 for that. But thats a lot of new directories. We got a lot of skirmish+scenario maps as well.

We could avoid spreading map related files over different directories by granting maps directories and put all related files there.
(This is what I would understand what @elexis called "logically grouped". Group what is only used by one map into that folder including e.g. the map-preview. There are other possible logical groupings orc..)

While I do agree that the current directory structure is messy (especially the map specific biomes in rmbiome), I dont see a particular issue with this approach. We do the same thing for heightmaps, triggerscripts and pmp files.
But I suppose the object could be moved in to the script. Would not really change anything.

Dunno what the biome discussion is about, this isn't a biome, nor does it claim to be a biome, but it extends the existing biomes, which I think only these two maps currently do.

Looks good to me! Please commit it if this allows Fedora users to work around the crash.

I tried it by stretching the window to give it an 21/9 ratio.

Did you test it on really wide monitors/windows?

The screen height is dependent on the window size.

Just mere guessing, but doesn't that hardcode the ratio of the image rather than the ratio of the screen and tries to make sure that the image is moved into all directions with equal speed?

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

It's only used to compute the offset of the background. it's passed as an argument to the background to offset it.

In D1680#66674, @Stan wrote:

Basically this number is multiplied to whatever the height is. So in case it's 1080 you get 1920 if it's 1050 you get 1866 instead of 1680 (Because it's supposed to be a 16:10 ratio) if you give it 768 (for 1024x768 which is the minimun resolution we support) you get 1366. That is not a 4:3 ratio.

Use TLSDisabled, rephrase, nuke cert verification option until we have at least one machine where it works.

Fedora 29 uses GnuTLS 3.6.4 and gloox 1.0.14.
I've compiled with that GnuTLS version and the most recent gloox windows on Ubuntu 18.04 but can't reproduce there.
I suppose the checkbox is even relevant if the Fedora thing is fixed, because the next best platform might crash randomly as well.

Basically this number is multiplied to whatever the height is. So in case it's 1080 you get 1920 if it's 1050 you get 1866 instead of 1680 (Because it's supposed to be a 16:10 ratio) if you give it 768 (for 1024x768 which is the minimun resolution we support) you get 1366. That is not a 4:3 ratio.

Stan can you describe how this number is used? It is not clear to me from a quick read and quick test (and why 1 is better than 1.7777?)

In D1611#66598, @elexis wrote:

Secondly this is also a gloox premake patch, so this might or might not influence D1654 and vice versa:

gloox has its own config program: gloox-config. When run with the appropriate argument (--cflags) this was returning /usr/include, a directory that is included by default by gcc anyway and, as mentioned in D1582, a directory that if included too early causes problems.

Stacktrace is on the trac ticket.

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

Build failure - The Moirai have given mortals hearts that can endure.

Try to fix the build. Fix warnings.

Assuming you the renames are correct and the proposed changes are made.

Accept if proposed changes are followed.

Cause that file is huge. Also I think it's good practise to do so.

Why separate header? I don't think it helps much. All other components don't have headers.

Build failure - The Moirai have given mortals hearts that can endure.

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