@bb Got a stacktrace for the lobby crash ? To see if it has anything in common with Mac ?

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

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.

@Itms @s0600204 The ticket where this build failure is reported is on the a23 milestone and I'm not sure if this irrelevant enough to be pushed. There was another bugreport on Nov 20th on the lobby:

Maanyavar: 0ad doesnt work on slackware 14.2

I find less files easier to maintain then multiple files BTW.

In particular for Hellas typos when refering from JS to JSON were a bit painful.
The same argument is also often given for JS files, but there are also advantages to splitting things into different files (logical grouping, preventing fragmentation, etc).

As mentioned in https://trac.wildfiregames.com/ticket/5349#comment:4 the question is whether gloox::TLSOptional should not rather become gloox::TLSDisabled in XmppClient.cpp if it crashes when trying the handshake.

(We should decide wether or not to add those to biomes or remove them from the map)

Why are those the only two options? As said, these are things *based* upon the selected mod. Not the biome itself. What would happen in “new_map” which want to do something extra like ponds or something if the selected biome was “xyz.json”. Sure, we could add the function to the core or let the map extend it.
In this case, the buildings were a nice addition. And most likely, they would be map specific. So we could either;

• Do nothing and keep a bunch of related data seperately in the map.
• Take all those data, combine them and make one nice json file.

...and another map may not want to use that base texture for that specific biome

At that point, isnt it a different biome in technical sense? When a map want to do something like that, they are already using a new map specifc biome regardless of how the script does it. Change enough, and you have to something like gulf_of_bothnia or fields_of_meroe.

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

In D1660#66565, @smiley wrote:

The way I see it, this is not a biome at all.

Then don't pot it into a biome file.

This is just defining entities based on the biome.

...which is exactly what a biome does (alongside terrain textures and actors).

I do not think these should be put in to the biome files for the reason.

I can't follow that reasoning (see above). However, removing the camps and farms would be an alternative clean solution (though maybe not desired).

The next such map may not want to have Romans in the Alpine biome.

...and another map may not want to use that base texture for that specific biome. That's always a possibility. Also I'm absolutely fine with changing the entities.

So, I think that keeping this as part of the map would be best.

Could do. But then:

The way I see it, this is not a biome at all. This is just defining entities based on the biome. I do not think these should be put in to the biome files for the reason. The next such map may not want to have Romans in the Alpine biome. So, I think that keeping this as part of the map would be best.

I find less files easier to maintain then multiple files BTW.
Also this biome is not meant to be unique to this map.

So far I can tell that warnings are solved. I did not try to run game with this patch yet.

Can't fix those warnings, because they have no reasons to be.

You can't remove braces see the comment I added : "scoping braces are important to indicate where an element ends. If you don't put them the tag won't be closed until the object's destructor is called, usually when it goes out of scope."

The problem isn't in macros, because we use scoped block to solve the redeclaration. Probably it was missed somewhere. If you still remove macros, you need to remove scoped blocks too.

I will see if I can fix those warnings in terrain.h

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

With this fix, the detection from gnutls' configure script will be overridden.

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

Thought I find the Obect[] syntax quite misleading for the content of the array is more prominent than the array itself this way.

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

Change documentation once more

In D1676#66499, @vladislavbelov wrote:

Do I understand it correctly, that IPv4 won't work when IPv6 is enabled?

In D406#66521, @vladislavbelov wrote:

the double > JS::Number conversion loses precision.

I think that is why we have FixedPoint number type in C++. (I guess it's mainly use in simulation)

double > JS::Number conversion loses precision

But we already do that conversion and that conversion is not really related to this patch or the adapted one?

In D406#66520, @elexis wrote:

Don't see a reason why an epsilon issue could not be fixed.
You mean stepWidth = 5 given in options.json will become 4.999,

Sort of.

so that the slider position wills be 0, 4.99999.., 9.9999...

No, the slider position will be correct in C++ (with an epsilon correction), but the double > JS::Number conversion loses precision.

Then min and max can also be 4.9999 and the current patch is as affected by epsilon as the change that I request, where is the issue?

Min, max can't be 4.999, the problem is only for the return to JS value.

In D406#66519, @vladislavbelov wrote:

In D406#66518, @elexis wrote:

We can convert a JS::Number <-> double well, so is it about some epsilon / rounding phenomenon?
Getting min + i * width rounded as wished shouldn't be so hard to accomplish, regardless which implementation is introducing the epsilon.

You can check it by returning a fixed number, like 4.5. JS may get from C++ the 4.499999 value. And for JS these values are different.

In D406#66518, @elexis wrote:

We can convert a JS::Number <-> double well, so is it about some epsilon / rounding phenomenon?
Getting min + i * width rounded as wished shouldn't be so hard to accomplish, regardless which implementation is introducing the epsilon.

You can check it by returning a fixed number, like 4.5. JS may get from C++ the 4.499999 value. And for JS these values are different.

In D406#66507, @vladislavbelov wrote:

In D406#66464, @elexis wrote:

In D406#66462, @Stan wrote:

We really need this feature for the GUI.Scale options. I think there is already a differential but if Not I can submit a patch

The patch for UI scale is uploaded but abandoned, should be reclaimed and receive an ugly workaround (message box that if not clicked after 7 seconds will reset the UI scale)

Not a workaround solution requires improvements in the our option page logic. Because we shouldn't change visible scale while a user is dragging the slider.

In D1668#66513, @elexis wrote:

In D1668#66496, @vladislavbelov wrote:

Smart, but the (N)RVO isn't guaranteed. Only since C++17.

https://de.cppreference.com/w/cpp/language/copy_elision looks more like C++11, only some other features C++17?

Yeah, compilers started optimize these cases a long time ago. But there're many nuances.

In rP20625#31622, @FeXoR wrote:

(The obelisks are just meant to show the center e.g. to show where it is on fortress (the "center of mass") compared to e.g. regular polygons/circular where it's just the center of symmetry)

The obelisk in the center is good, just saying walls should not be replaced with placeholders to work around.

In D1668#66496, @vladislavbelov wrote:

Smart, but the (N)RVO isn't guaranteed. Only since C++17.

(The obelisks are just meant to show the center e.g. to show where it is on fortress (the "center of mass") compared to e.g. regular polygons/circular where it's just the center of symmetry)

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

Documentation correction

In D1023#66466, @elexis wrote:

We also want to use the Red buttons, so all GUI pages use the same button style (although I found/find grey ones more appealing sometimes) (the patch can be considered one of multiple independent improvements of something that is free of big defects.)
(We should have a ticket and a good reference to this patch with regards to the golden bar thing)

In D406#66464, @elexis wrote:

In D406#66462, @Stan wrote:

We really need this feature for the GUI.Scale options. I think there is already a differential but if Not I can submit a patch

The patch for UI scale is uploaded but abandoned, should be reclaimed and receive an ugly workaround (message box that if not clicked after 7 seconds will reset the UI scale)

Not a workaround solution requires improvements in the our option page logic. Because we shouldn't change visible scale while a user is dragging the slider.

In D1515#66454, @elexis wrote:

I agree with the patch, it's a good cleanup. A Color entirely is not a Shape and it will leave behind cleaner code if we don't include the shapes header if we only need the color.
(I suppose one could lose a lot of time reinvestigating the completeness of includes, better don't even start).
Otherwise I suppose one could test it by compilign without precompiled headers, running every function that uses colors and then it could be committed if it still doesn't fall apart and everything is confirmed to be the same code flow as before.

Do I understand it correctly, that IPv4 won't work when IPv6 is enabled?

In D1437#66465, @aeonios wrote:

In D1437#66450, @elexis wrote:

I think the problem is that this GL error is not reported to the user in a way that the average user comprehends.
Or rather the problem, nor the setting change are reported at all (barring the unreadable barely noticeable openGL mainlog error).

I sort of fixed that in my unrelated shadow revision. Sort of. The error is still reported via the GL error text, but I made it more understandable and just had it recursively reduce the size until it allocs properly or fails completely. Also the settings GUI won't update until you close it and open it again even after the resolution has been reduced by the backend code if/when it fails. I don't think there's any way around that due to the way the settings panel works.

I can close this ticket, if you'll solve the problem in your diff.

In D1668#66468, @elexis wrote:

@vladislavbelov are most compilers really smart enough to use copy elision for strings here as widely claimed on the internet?
(Some places use one pattern, other places use the other pattern, we should make up our mind what we want, otherwise it sounds contradictory if we claim there to be good reasons for both.)

Sounds good, would make separate revision proposals.

(Missing increment in the while loop L74)

-function SimpleGroup(objects, avoidSelf = false, tileClass = undefined, centerPosition = undefined)
+function SimpleGroup(objects, avoidSelf = false, tileClass, centerPosition)

Havent really checked for correctness. This was pretty old. Pasted because this was almost lost. Some stuff might be useful.
And I didnt really feel like creating a whole new proposal just for these. Can fix when changing something near.

• Confirmed with warn(uneval()) that the line is actually executed
• The patch must be correct for any mapsettings, because there is only one call to sortPointsShortestCycle, that receives the argument from groupPlayersCycle, that receives the argument from getStartLocationsByHeightmap on wild lake and caledonian meadows and that function always returns a Vector2D array.

No issues still. Generated caledonian_meadows and roads are correct.

About the unintended wallsets:

In rP20625#31616, @elexis wrote:

ping @s0600204, doesn't this satisfy the problem described in #2631 and provides more flexibility to the random map author than the skirmish replacer, i.e. can be marked as fixed or won't fix?

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

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

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

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

In D1674#66477, @Itms wrote:

So the big flaw of rP19669 is that the Phabricator Jenkins plugin has this issue: https://github.com/uber/phabricator-jenkins-plugin/issues/224
The script is useless as long as issue 224 prevents the job from posting comments on autobuilder i18n commits.

Ah, it sounded like it would post on revision proposals. Posting red flags on autobuild commits indeed helps.

So the big flaw of rP19669 is that the Phabricator Jenkins plugin has this issue: https://github.com/uber/phabricator-jenkins-plugin/issues/224

In D1649#66373, @Imarok wrote:

Anything more that needs review?

As said, not besides the comments I wrote.

In D1556#66171, @Imarok wrote:

The proposed renames in the patch description sound sane. ?
The added descriptions are also good. (Besides the comments I gave)

@vladislavbelov are most compilers really smart enough to use copy elision for strings here as widely claimed on the internet?
(Some places use one pattern, other places use the other pattern, we should make up our mind what we want, otherwise it sounds contradictory if we claim there to be good reasons for both.)

In particular: If we already have a script that satisfies this purpose, why didn't we find the broken sprintf arguments before?

"it have been 2 years there"

I agree that this looks ugly in

In D1437#66450, @elexis wrote:

I think the problem is that this GL error is not reported to the user in a way that the average user comprehends.
Or rather the problem, nor the setting change are reported at all (barring the unreadable barely noticeable openGL mainlog error).

I sort of fixed that in my unrelated shadow revision. Sort of. The error is still reported via the GL error text, but I made it more understandable and just had it recursively reduce the size until it allocs properly or fails completely. Also the settings GUI won't update until you close it and open it again even after the resolution has been reduced by the backend code if/when it fails. I don't think there's any way around that due to the way the settings panel works.

In D406#66462, @Stan wrote:

We really need this feature for the GUI.Scale options. I think there is already a differential but if Not I can submit a patch

We really need this feature for the GUI.Scale options. I think there is already a differential but if Not I can submit a patch

And we don't know, was it really initialised.

Shouldn't there also be a callback function on failure then, used when globals are initialized by a config value?

The JSON syntax should be tuned for people who modify the options file, not for the C++ code.

I agree with the patch, it's a good cleanup. A Color entirely is not a Shape and it will leave behind cleaner code if we don't include the shapes header if we only need the color.
(I suppose one could lose a lot of time reinvestigating the completeness of includes, better don't even start).
Otherwise I suppose one could test it by compilign without precompiled headers, running every function that uses colors and then it could be committed if it still doesn't fall apart and everything is confirmed to be the same code flow as before.

In D1437#61080, @aeonios wrote:

shadow map size may be set in local.cfg, in which case the shadow map quality setting does nothing

I didn't test, so I don't know if this patch handles the error gracefully with an affecting local.cfg.
If it doesn't, it would be safer to update the renderer to use shadow maps if and only if shadow maps can be used and are configured to be used; i.e. possibly don't change the configuration value, only a renderer value.

In D1437#59336, @OptimusShepard wrote:

I think this patch have to be in alpha 23. It doesn't solve the problem of #4883, but it saves from his consequences.

This is a reasonable argument.
But we still need to check that the patch doesn't introduce other unintended consequences (which can be hard to tell for all possible platforms before a release) and that the patch is the final way to address the problem (so that we dont have to start investigating this issue from scratch).

@Stan Maybe...
I wrote if myself but I'm pretty sure someone else did wright something similar before ;D

Perhaps instead of an object with 2 properties or an arry with 2 items, it would even be cleaner to use a function / constructor with 2 arguments (texture, entity = undefined), like using SimpleTerrain or RandomTerrain which receives an array of SimpleTerrain?

Now this should really be tested in action with maps but I don't know how to change the test plan or the title.
Caledonian Meadows uses this. Generate some maps, if no paths cross each other it should be fine.

Added using Vector2D.distanceTo() to simplify code.

In D1674#66409, @Itms wrote:

Thank you for the patch! Unfortunately those checks are the same as what is checked by build/jenkins/lint-translations.sh. The thing that is missing from this is a check for broken custom tags (like [font] ones, typically).
I am adding a note to ReleaseProcessDraft so the translation lint script is better advertised.

At the moment we have:

• Terrain strings, those containing the terrain separator
• simpleTerrain objects
• randomterrain objects
• Texture strings in the Map object
• Terrain entities in the map object

did I miss something related?

Thank you for the patch! Unfortunately those checks are the same as what is checked by build/jenkins/lint-translations.sh. The thing that is missing from this is a check for broken custom tags (like [font] ones, typically).

In D1676#66386, @vladislavbelov wrote:

Isn't the flag needed in the premake4.lua too?