Seems to work fine now.

Makes sense to me.

Also works on my Intel UHD620

Any news? Btw you got disconnected from the IRC channel (NetSplit)

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

• Rebased.
• Updated comment.

@Freagarach, are you willing to review this?

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

None at all, “dodging” is not an issue in single-player.

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

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

Seems to work fine on W10 I tried fuzzing the text but could not break it.
Maybe you could commit the cleanup separately. Don't forget headers.

Reimplement "replace", "disable", "op" and token-parsing.

Thank you!

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

• redone (again); @Freagarach?

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

@Freagarach, care to check and commit D2610?
Also:

In D1707#124203, @wraitii wrote:

In D1707#124199, @Nescio wrote:

On a separate note, wouldn't it be better to insert a <Tooltip> inside the <Attack/*/Bonuses> or <Attack/*/Bonuses/*> node, instead of using the <Identity/Tooltip>? Likewise, auras have their own tooltips, and there is a separate <Upgrade/*/Tooltip> node in templates.

This however seems a good idea regardless of the rest of the patch.

I agree with the birds folder, since it follows the same structure as the other folders.
One could argue that they should be in the GAIA folder, though that would imply it inherits from template_gaia. One could do that, but it means the bird-template would get larger (lots of disabling besides the enabling). While I think that would technically be correct I am not convinced it is worth the hassle. If one goes that route it seems logical to also split the fauna/flora/geological in the "gaia" folder into separate folders?

• rebased (again)

This patch breaks the elevation tool on Windows and weirdly caps the max FPS to 32 (144hz screen)

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

In D1707#124205, @Nescio wrote:

In other words, automatically generating bonus attack tooltips seem a lot of work for little benefit.

Don't forget the years ;)

Right. That was it. Apple is lying :p

In D2788#126885, @wraitii wrote:

I really have no idea why we get this failure. This is supposed to be defined in Appkit.h, which I do include -_- .

@Itms would you have an idea maybe? We might need to link against appkit ?

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

I really have no idea why we get this failure. This is supposed to be defined in Appkit.h, which I do include -_- .

True. Though it does make sense to clean up the current situation first, remove things that don't make sense, get a balanced state, and only start differentiating civs from there.

• updated because of D2911/rP23921 by @wraitii

I know ^^ The point was that not all civ's need to be equal, they can be vastly different in their setup.

Why would we need to equalise all civs? We can give Hellenic factions cheap slaves, with expensive citizen soldiers, Celts only citizen soldiers and so forth?

Slaves weren't cheap. Moreover, Celts, Persians, and others had slaves too.

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

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

In D2911#126870, @Freagarach wrote:

Why would we need to equalise all civs? We can give Hellenic factions cheap slaves, with expensive citizen soldiers, Celts only citizen soldiers and so forth?

Kinda hoping this fixes the macos CI, I'm really not sure what's going on there.

In D2911#126774, @wraitii wrote:

So things are already somewhat confusing... Muddying the issue further, societies like the Gauls, from what I gather, did not really have working men that might not be called to war.
If we go Aztec at some point, things will get even messier.

So, on the basis of trying to represent societies of the time, I'm not entirely certain what the best move would be.

Why would we need to equalise all civs? We can give Hellenic factions cheap slaves, with expensive citizen soldiers, Celts only citizen soldiers and so forth?

Nope, different issue. I am investigating for I had that too last week.

Fixes the issue for me in Debug mode SM45, (I had to rebuild gloox, as it was triggering unrelated assertions see IRC from today)

@borg- @Nescio @ValihrAnt @Feldfeld thoughts on this?

According to @vladislavbelov this commit introduced an extra rendering pass that is not needed. Specifics were not given.

Hey there thanks for the patch! I believe you should report that to the upstream of premake :)
I believe @Itms has plans to allow the use of your distro provided premake :)

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

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

Don't crop non maxlength inputs

Fix curpos

@Feldfeld @badosu opnion?

@Feldfeld @badosu opnion?

Tnx !!!

Thanks for this patch, this is a really annoying issue indeed!

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

borg-'s comment before committing.

@Freagarach
I confirm it's the same issue.

Yes, the more I look at it the more I'm convinced this is the issue. I really can't do the rebase today but should be possible to see whether the crash is fixed in the upcoming days. ?

Additionally, given that:

• It happens on the lobby MP gamesetup page
• It doesn't happen on the regular MP gameosetup page

(I realized I forgot to submit inlines highlighting flaws of my OG patch, sorry).

By the way, a better name for the diff and for a future commit would be Fix rooting mistake in GuiPoll{New,Historic}Messages. But it would be great to add a fixes #5655, of course ? I'll rebase the branch upon this commit so that we can test if the crash is fixed.

Ha, this makes far more sense, thank you! ?

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

SM45 compatible version and cleaner patch.

The root of the issue might be around this part of the code, but I'm not convinced with the patch.

cannot we create option to change the password and all users would be required to change it?
That function would try to hash password both ways to verify old one but saving only with the new way.

I'm not completely sure this is exactly the same issue, but this includes a small replay that seems to have the same issue. I'll see if this patch fixes this.