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

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

Build is unstable, some tests have failed - The Moirai have given mortals hearts that can endure.

Rename back to PushGuiPage
include precompiled.h

In D3807#223896, @phosit wrote:

RunGuiPage isn't the best name.

• elexis recomended to stay with PushGuiPage.

Careful if you make a new file, you need to tell Transifex to pull it.

Store extracted messages from gamesettings in a new output file, public-gamesettings.pot.

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

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

I addressed most of the suggestions.

In D5256#223912, @Vantha wrote:

Ok, updated the diff. Is this how you wanted the comments?

Related bug: #6912 ( Translations are missing for gamesettings). Fixed in D5259.

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

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

Ok, updated the diff. Is this how you wanted the comments?

When you await (asyncronously wait) for the promise to settle you essentially enqueue the rest of the async function as a continuation. The function (with or without the await) doesn't block (untill the child page finishes) the engine or the thread or...

Only because you await it no? If you didn't it would not block therefore the method itself is async? Or am I missing something

By asyncronous i mean it doesn't block untill the child page is closed.
It blocks untill the child page is pushed. So that part is syncrosous.

If you return a promise then it is ?

That looks good indeen. I'll have to test.

Well the pushing isn't async.

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

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

Like this?

How about PushGuiPageAsync ? Else popguipage but not sure that works.

RunGuiPage isn't the best name.

• @marder recomended ShowGuiPage.
  • - That doesn't reflect that the pages form a stack. And might be confused with SwitchGuiPage
    • + ShowChildPage would be a solution.
• elexis recomended to stay with PushGuiPage.
  • + that would make the diff lot smaller.
    • - but harder to review since the occurences have to be searched manually.
  • + PushGuiPage(...) only pushes the page.
  • - await PushGuiPage(...) wrongly indicates that the code continues when the page is finished pushing.

The regex doesn't match the name when the format string is translated. A solution would be to also store the unformated name (or just the index of the name).

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

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

I added/updated the comments. Do you also want a comment before line 95? This.CountLabel is already marked for translation at this point (and has a comment explaining what it is).

By the way, do not forget to test translations.

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.

Put the queue in the ScriptContext.

I can image it took much effont to find that. Great work.
It needs a rebase then it can be commited.

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

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

Pass a wchar_t* to ScriptException::Raise

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.

There is a little "Savegame" note on non-controler-clients when a savegame is loaded.
The tooltip and the warning don't move. (That's a feature, but might be it's own diff)

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

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

Ok, nice. Made the change and added the trac ticket.

I thought we have to duplicate the "%(playerName)s (%(nameCount)i)" so that the, script which collects the strings to translate, finds the string.
Apperently there is markForTranslation which would better fit:

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

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

If you zoomed out and rotated, there were artifacts

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

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

Ok, I made the change.

Oh, you mean that ^^
The count and the translation aren't much related. I'd do two if's. Going from 2*2 to 2+2 branches (yea doesn't really mather ;)).

const label = this.settings.isNetworked ? this.CountLabel : this.TranslatedCountLabel;
const translatedChosenName = this.settings.isNetworked ? chosenName : translate(chosenName);

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

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

Don't use if constexpr in a lambda. I think that lead to the error.
Again change variable names and comments.

OK, and what's preferred?

Looks like Windows CI does not like it.

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

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

Change naming and comments a bit.

In D4770#223669, @phosit wrote:

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

The information if a savegame is loaded is with this implementation only available to the controler.
The easiest solution would be to make the loadsaved-ness an init-attribute / setting like wraitii suggested. That requires me to rewrite and test much again.

In D5256#223809, @Vantha wrote:

In D5256#223808, @phosit wrote:

Before this diff the "forat translation" is allways done. That's almost certainly an issue.

Not sure what you mean by this, though. What should I change?

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

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

In D5256#223808, @phosit wrote:

Before this diff the "forat translation" is allways done. That's almost certainly an issue.

Not sure what you mean by this, though. What should I change?

In D5256#223805, @Vantha wrote:

What do you suggest? Something like this?

GameSettings.prototype.Attributes.PlayerName.prototype.CountLabel =
	translate("%(name)s (%(count)s)");

Yes, almost. I assume the "s" is for strings. count is an integer so it should be translate("%(name)s (%(count)i)").

In D5189#223719, @phosit wrote:

In D5189#221449, @vladislavbelov wrote:

Have you measured performance for those changes?

It's nearly the same:

In D5256#223797, @phosit wrote:

I don't like it when data is mutated. (With the +=)
If one wants to know what's in the variable one has to reason about every point where it get's mutated.
If it's const one only has to reason abot the initialization.
Ideally there should be a chosenName and a translatedChosenName:

const translatedChosenName = this.settings.isNetworked ? chosenName : translate(chosenName);

elexis just wrote me again :)
User visible strings shouldn't be concatinated by + (or +=).

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

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

In D5256#223792, @Vantha wrote:

Do you want me to change it? I thought ' (${count})' looked better than " (" + count + ")".

No, I'm ok with that.

In D5256#223783, @phosit wrote:

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

This inline went missing

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