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

I never saw Template Literals in this codepase. I don't object it. :)

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

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

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

Reduce "test_RecoverableError.js"
It should pass the tests now.

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

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

revert

It's not a big problem :)

• docs: Improve Doxygen Visuals and Build process.
• ci: Update CI to use the new Doxygen Build process.

Thx, was already trying that. Again, very sory that i updated the wrong diff :(.

Upload the earlier patch (that would be 11164) again. I could do that tomorow.

well, you will have to revert and update the intended patch @Stan or @phosit should know more, I would also look at phabricator documentation.

Oh Shit, i switched the numbers. That wasn't intentional. How can i fix this @asterix ? My intention was to update 5252.

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

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

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

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

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

by any chance have you @Cayleb-Ordo updated wrong patch?

• docs: Improve Doxygen Visuals and Build process.
• ci: Update CI to use the new Doxygen Build process.

Sometimes there is a long "tooltip"

In D4770#223734, @phosit wrote:

In D4770#223669, @phosit wrote:

It should be visible by non-host-clients if it's a savegame.

Does anybody have an idea where this could be shown?
An idea was to put it near the "cheats enabled" or "rated game" warnings but there is litle space.

In D4770#223669, @phosit wrote:

It should be visible by non-host-clients if it's a savegame.

Does anybody have an idea where this could be shown?
An idea was to put it near the "cheats enabled" or "rated game" warnings but there is litle space.

I think i'll commit it with the deprecated path. We can decide later in the release cycle if we want to keep it. Propably dependant on how long it takes. And propably the will be breaking rmgen changens.

MakeExportable hasn't to be called from js

Remove #undef FLOODFILL

In D5189#221449, @vladislavbelov wrote:

Have you measured performance for those changes?

Revert embarrassing things.

Use promises for GUIpages (see summary)
Remove things related to multithreading.
Use std::queue instead of std::vector because of iterator invalidation.

Ah makes sense.

In D5257#223695, @Stan wrote:

Any reason the renderer and the postproc manager would have different sizes ?

Yeah, because we have multiple render targets with different resolutions depending on a pass: window resolution (UI and post effects), scene resolution (scaled by postprocmanager), reflection/refraction resolution, shadow map resolution.

Don't look at it it's embarrassing ^^

Hide the button in single player
Don't unlock civ-selection when changing assigement

Any reason the renderer and the postproc manager would have different sizes ?

rebase

related https://github.com/0ad/0ad/pull/44

Probably related https://github.com/0ad/0ad/pull/44

The Mauryan emperors were sorted chronologically. I put them in alphabetical order too.

In D5256#223673, @Vantha wrote:

When the AINames are empty or don't exist, the game already throws errors before the step of choosing the names.

When the AINames are empty or don't exist, the game already throws errors before the step of choosing the names.

changing three let to const

We noticed bugs while testing:
When loading a game and changing starting position sometimes the civ column get's unlocked. (It should stay looked)
It should be visible by non-host-clients if it's a savegame. (It's not)
Loaded game should not be ranket. (We didn't acctually test that. I don't know the current behavior)

Guess some of those let could be const instead.

In D4770#223655, @phosit wrote:

Thank you for testing.
I testet "2 humans" localy with two clients.
I could use your help to test it using the lobby. I'll have time on sunday morning (untill 12:00 UTC+2) or evening (from 17:00 UTC+2)

I found a defect myself ^^. When you continue a savegame from the singleplayer gamesetup page, it will start a new one.
I tried to allow to continue a game from the singleplayer gamesetup page but it's not that trivial. I think I'll remove the "load game" button from the singleplayer gamesetup page.

Thank you for testing.
I testet "2 humans" localy with two clients.
I could use your help to test it using the lobby. I'll have time on sunday morning (untill 12:00 UTC+2) or evening (from 17:00 UTC+2)

I started testing it tonight, so far no issues. lmk if you want to test the "2 humans" sometime.

Rebase

See also #6905 for a build failure of sm91 on macOS 14 w. XCode 15 that will also prevent building sm102 on such systems as well.

In rP27996#61951, @phosit wrote:

How does this relate to #305?

How does this relate to #305?

In D5254#223622, @Stan wrote:

Related ? https://trac.wildfiregames.com/ticket/5989

Related ? https://trac.wildfiregames.com/ticket/5989

Dunno, could be a glitchy UI in some cases, the menu being available in SP while it shouldn't (or showing the wrong text) or for observers / defeated players which would be weird or could cause side effects

In D4770#223608, @Stan wrote:

Well, can you break it? (Corrupted savegames, forged ones, spamming buttons, accessing it from somewhere you shouldn't) ? Possible bugs with AIs, rejoin check etc

In D5195#223604, @Stan wrote:

Well I would assume this changes the generated assembly which could be for the worst compared to macros. But I suppose it could / should be profiled.

Well, can you break it? (Corrupted savegames, forged ones, spamming buttons, accessing it from somewhere you shouldn't) ? Possible bugs with AIs, rejoin check etc

Fine by me. :)

Well I would assume this changes the generated assembly which could be for the worst compared to macros. But I suppose it could / should be profiled.

Can somebody take another look. pls.

@Freagarach are you ok with this wording?

Use std::any_of

In D5195#223594, @Stan wrote:

Dumb question, but doesn't that make the code slower?

Dumb question, but doesn't that make the code slower?

Copyright year