Then it's decided. To fix this issue it's better to play a sound :)

In D1692#67009, @smiley wrote:

To be honest, I find this behavior to be more unintuitive. Currently I won't lose my selection if I just wanted to check if there are any idle units (usually, if there are none I would do something with the current selection). But now, I would have to add the units to the selection after.
Maybe it's just me, but I think it would be best to remove that todo. Engine.PlayUISound(filename, looping); if interested.

I have similar thoughts, but I posted them in the ticket: https://trac.wildfiregames.com/ticket/5360 :)

To be honest, I find this behavior to be more unintuitive. Currently I won't lose my selection if I just wanted to check if there are any idle units (usually, if there are none I would do something with the current selection). But now, I would have to add the units to the selection after.
Maybe it's just me, but I think it would be best to remove that todo. Engine.PlayUISound(filename, looping); if interested.

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

I rebuild libcurl and game, I was able to join in lobby, open mod.io

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

Upload the correct patch.

For the textures.xml i'm not sure whether it's not better to have it in the public mod and not in the mod mod. Sounds sane that xml validation be part of the engine, but textures.xml are directly relevant to the textures files one put in his mod. So I don't think it should be part of the engine.

It's the same situation with mod/art/textures/ui/textures.xml it's only present in the "mod" mod, but the directory (without the xml file) also exists in "public".
And these rngs/rncs only exist in the public mod.
./mod/art/textures/texture.rng
./mod/audio/sound_group.rng
./mod/shaders/program.rng
./mod/gui/gui.rng
./mod/gui/gui_page.rng

I package without it all the time :) Unless it's loaded without me knowing.

Whut? It's impossible to package without the modmod currently.

One has to be careful to add a dependency to modmod when packaging the mods. Otherwise you will get bad textures if you remove textures.xml. Those files decide what compression will be used on a png file.

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

Disable all TLS stuff.

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

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

In D1687#66940, @elexis wrote:

Not few flags, libCURLs ./configure --help | grep without yields

In D1687#66939, @Stan wrote:

It would be nice to disable all other librairies if possible.

Ah autocorrect try Itms fix ;) I meant to write--without-brotli.
It would be nice to disable all other librairies if possible.

@trompetin17 It looks like you have yet another system lib which tries to sneak into the build ? Can you try --without-brotli? Just like we did with nghttp2.

Can you pass --without-ssl ?

I tried today and when i tried to build the game It gave me a error:

Clarifying a small thing in Stan's answer (which is correct): when D1687 is committed (tonight probably, as trompetin is testing it as we speak), mod.io will work for everyone, regardless of who built the game.

It doesn't crash on any of those platforms if I build the game.

If it crashes for everyone on 10.9, 10.10, 10.11, we can disable TLS in the config and remove that one TLS sentence for OSX.

In rP21943#31690, @Itms wrote:

The consensus in that topic is the reason why I asked user1 to commit this, but if you want I can formally accept this revision.

The commit contains only few style mistakes. So the accept isn't required. My point that the commit doesn't have any linked diff/ticket or link to its conversation. My first thought was are these bots and rooms already exist.

Perhaps we could use a bugreport on the a24 milestone for the issue reported in previous posts, as users seem to run frequently into that.

Ah right.

@elexis Yeah, it's the clock_gettime thing...

@vladislavbelov In the staff discussions, it seemed that we had reached a consensus on creating this new room, but leaving the other version numbers intact (in order to push people into upgrading, without forcing them). On top of what elexis said, we are legally obliged to push the lobby users into using A23b, so that they can accept the new terms.
The consensus in that topic is the reason why I asked user1 to commit this, but if you want I can formally accept this revision.

If I compile on 10.9.5 I can access the lobby with tls without issues.

Macos 10.8 was released in 2012. Considering how aggressive Mac is when it comes to upgrade and the fact people don't really know our game works on Mac I do not find it so hard to believe.

On versions of OSX/macOS up to 10.11, TLS handshakes can still fail and crash?

(I find it hard to beleve that since Nov 2016, Alpha 21 (SM38 / #3708), noone has tried running a release bundle on macOS 10.8 and reported it as defunct, on the other side I only recall people using recent macOS versions.)

• There is a ticket for removing the instances of the 3 border
• The map should be fixed, the commit should be dug out.
• I recall Petra complains too about stuff outside of the map area.
• I wonder if there shouldn't be a warning or error message about entities placed outside of the map area (in the border or beyond) when parsing the finished mapgeneration. There is a ticket for warnings about gatherable entities that are on a too slopy position to be gatherable). CCmpPosition has the OutsideOfWorld boolean to represent units that are outside of the map area. There might be edge cases where one could argue that entities outside of the map area would be justified (for example there is a skirmish map that has a wonder where 50% of the area is inside the map and 50% in the shroud of darkness). But perhaps these edge cases can all be satisfied with the given restrictions (the center position may not be on a slope and must be inside the map). Otherwise if these edge cases are really relevant, one could add a boolean flag to the map that allows or complains (and possibly removes) entities at invalid positions. Thus adding an automated way of informing map authors when they broke their map. If the engine only loads valid maps, or if the PositionComponent prevents setting such an out-of-world position without setting out-of-world to true, it wouldn't have to add these border checks to every place in the simulation (including here).

Getting an OOS error at a later time in a match versus getting an OOS error at the beginning of a match is not a qualification to change the room in the re-release.
That WFG logs who accepted the new GDPR terms and that players can play without the a23 OOS errors are nice benefits, but not the reason to add this new room.
Most certainly multiple players in a match with 6-8 players getting disconnected at the gamestart and every rejoin attempt on every map due to the petra AI teambonus initialization freezing the non-threaded NetClient for 10+ seconds up to the point where it counts that as a disconnect is.
The only reason many 4v4s currently work is because those people use svn, that includes a petra AI skip and the NetServer and NetClient waiting for up to 60+ seconds on init before disconnect (relevant in case someone did enable AIs or any other code being that slow. The actual patch to use threading in the NetClient is unpublished).
There are a number of other committed C++ fixes, why spend additional effort to provide a partial release?
Usually the lobby becomes empty after the first day of a new release due to the lobby subject and the absence of players and games. The intention is that players can play the game without crashing in several ways and to push the players into actually installing the update, rather than continuing to get N reports about the bugs fixed this summer every day (including the macOS thing and some other OOS errors).
The mod version is not changed, so that people can still replay their old replays, continue their savegames, can use the same mods (which should all be fully compatible except fgod which is currently incompatible with our terms in two ways, so fpre rebasing that means he would fix that.).

In rP21943#31678, @smiley wrote:

Not to mention ~1GB for an upgrade which literally added nothing visible. Not really an issue for most though.

Not to mention ~1GB for an upgrade which literally added nothing visible. Not really an issue for most though.

In rP21943#31673, @Stan wrote:

To me people should upgrade.

Only if needed.

In current alpha 23 square maps are not rejoinable (OOS), aren't they? That would make them sufficiently incompatible.

To me people should upgrade. If we were commercial software, it would be different. But here you literally have no reason not to upgrade.

Do we really need it? I thought we have pretty compatible versions. Also these *b versions aren't running on serverside, no?

Not sure whether intentional, but wont this prevent 23 playing with 23b. I thought that was a requirement judging from all the hassle about compatibility.

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

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

Fix path

can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: 0ad/libraries/osx/build-osx-libs.sh
|===================================================================
|--- 0ad/libraries/osx/build-osx-libs.sh
|+++ 0ad/libraries/osx/build-osx-libs.sh
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored

Path of the file seems off.

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

The patch is currently useless, because xcodebuildsettings was added in premake5 alpha12 (we have alpha10): see https://github.com/premake/premake-core/wiki/xcodebuildsettings.

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

Use the correct option, check if it is set before using it.

I assumed we should use premake variable because options might be undefined.

I agree, but I think you didn't test this? The option must be accessed with _OPTIONS (see the other use of it in the file for an example) and I suggest running the whole premake script with and without the parameter passed.

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

Sounds fair then. Thanks for taking time to elaborate :)

Getting this right doesn't seem like it would hurt the A23 re release was it to be included, right @Itms ?

In D1669#66853, @Stan wrote:

I see. Won't be hard to keep track of all the patches we apply ? For now we only have one but we might have more in the future, no ?

I see. Won't be hard to keep track of all the patches we apply ? For now we only have one but we might have more in the future, no ?

In D1669#66846, @Stan wrote:

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