Build was aborted.

So what's the "new" stack model that this patch introduces exactly?
Is the current GUI Model that we can only have one "axis", so pushing 5 times from the same pages results in:

• Main -> Page1 -> Page2 -> Page3

Instead of the (more expected):

Main -> Page 1
     -> Page 2
     -> Page 3

?

Main Menu -> Host Game -> Back -> Segfault upon NetServer delete

Also consider this code:

		for (let i = 0; i < 5; ++i)
			Engine.PushGuiPage("page_splashscreen.xml", {}, () => { warn("close " + i)});

Rebase

Current behavior of PushGuiPage(pageName, arguments, callback) (for civ/structree in rP21339, utilizing Pop/PopCB split in rP14496).:

• (1) The page is closed without callback function being called
• (2) a different page is opened that decides to call the callback handler when that gets closed

Add <condition_variable> header.

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

Fix debug. RC.

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

Clean up some of the weirdness.

Merged back into D274

m_MapSize ought to be signed but that sounded like it'd change many more lines.

Thanks for the quick fix!

Ideally there would be no type conversions and all values are constructed in the right type, and the functions receiving them expect exactly that type.
I didnt check much of the code, but GetVertexGroundLevel expects the signed variant already, so it might be right with signed.
Should check that there arent unintented implicit type conversions.

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

Shown by gcc 9:

../../../source/renderer/WaterManager.cpp: In member function ‘void WaterManager::RecomputeWindStrength()’:
../../../source/renderer/WaterManager.cpp:1131:17: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
 1131 |     if (point.X < 0 || point.X >= m_MapSize || point.Y < 0 || point.Y >= m_MapSize)
      |         ~~~~~~~~^~~
../../../source/renderer/WaterManager.cpp:1131:56: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
 1131 |     if (point.X < 0 || point.X >= m_MapSize || point.Y < 0 || point.Y >= m_MapSize)
      |                                                ~~~~~~~~^~~

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

panels

Ran some profiling, and I'm not actually sure this speeds things up. But it's still better behaviour as there are some artefacts with the existing code on e.g. Polynesia near the edges, and it's more readable imo so I'll commit anyways.

Before I can update this, we still need to find a proper format for the formation and garrison aura types.

Maybe what we need first is to have two completely different words to refer to (1) formation as in a way a group of units can organize themselves and (2) formation as in a specific group of units. For example, if we used ‘group’ for the latter, “Same group [class] [change] [attributes]” may work.

A group is an arbitrary selection of entities, which can be defined by e.g. Ctrl+1 and selected by pressing 1 or clicking on the group panel at the left of the screen.

In D2110#90731, @Nescio wrote:

Those extra white lines are undesirable.

Then it's obviously a no-go ;)

[font="sans-bold-16"]
Modes
[font="sans-14"]
The main menu gives access to two game modes:

This means four lines, two of which show up as white lines in game; cf.

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

Updated, keeping flavour text and capitalizing classes.

In D2110#90707, @Nescio wrote:

As for the font tags, I don't fully understand your point. The number of tags remains unchanged. What this patch does is instead of having one font tag in two lines, e.g.

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

As for the font tags, I don't fully understand your point. The number of tags remains unchanged. What this patch does is instead of having one font tag in two lines, e.g.

[font="sans-bold-16"]Modes
[font="sans-14"]The main menu gives access to two game modes:

it is changed to two font tags in one line, e.g.

[font="sans-bold-16"]Modes[font="sans-14"]
The main menu gives access to two game modes:

to be consistent with e.g.

• [font="sans-bold-14"]Multiplayer[font="sans-14"] – play against human opponents over the internet.

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

Abandoning since won't get committed.

emplace_back instead of push_back to avoid the braces, and init the move inline.

As you can see Siege Engines is capitalized, as requested. Other exceptions probably ought to be listed on the https://trac.wildfiregames.com/wiki/EnglishStyleGuide page.

I think we should capitalize them.

Agreed.

So basically you prefer [verb] for [resource] instead of [verb] [subtype] for [resource]?

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

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

• Give variables slightly more informative names.
• Test.
• Some other simplifications.
• Properly update when entities die and probably also when changing owners.

Those are not philosopher names, those are titles of works.

The tooltip and name must be as transparent as possible, it's probably okay. I think I have to accept this unless you want to change it.

Make ordering consistent:

• PlayerChanged is sent
• Entities are changed owner from invalid to player
• player ent is destroyed

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

RemoveLastPlayer sends before deletion, ReplacePlayer sends after deletion. It should be the same order as for regular entities.

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

Working version, worked around the fact thats SDL semaphores keep a count of how many times they were asked to wake up.

I’ve left a comment regarding font tags.

I’ve left a few comment. However, I’m not in a position to review the changes as a whole, I unsure whether or not the element removals are OK. Please, add other reviewers for those.

In D1806#90158, @Nescio wrote:

We can post-pone this discussion and merge as is.

If you mean whether or not classes should be capitalized […]

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

Clean up formatting.

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

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

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

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

Cleaned up.

ESC → Esc

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

Add include, RC

Updated because of rP22650.

Feels like this should be the default to me to be honest

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

Rebase following preliminary commits.

In D1684#87801, @elexis wrote:

Quick-glance review by Yves on January 17th:

Ich glaube man kann einfach mit dem "=" operator eine JS::UndefinedValue() zuweisen, habe es aber nicht ausprobiert.