Delenda est and hyrule have custom shaders though.

In D4361#185795, @Stan wrote:

Maybe we should have "ignored" or something instead. 0.0 looks like a normal value to me.

Could have a warning too.

Maybe we should have "ignored" or something instead. 0.0 looks like a normal value to me.

In D4361#185793, @Stan wrote:

Even then, any modder opening the file will be confused.

Even then, any modder opening the file will be confused.

In D4361#185791, @Stan wrote:

Why do you set it to 0 instead of 1.0 even for materials with AO? It's confusing.

Why do you set it to 0 instead of 1.0 even for materials with AO? It's confusing.

Okay, thanks. :)

In D4361#185787, @Freagarach wrote:

Maybe an ignorant question, but why this patch?

Maybe an ignorant question, but why this patch?

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

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

Fixes linter.

Freagarach is right, https://stackoverflow.com/questions/8044750/javascript-performance-difference-between-double-equals-and-triple-equals

BuildingAI
But I'd rather have D3249.

You'll need to rebase this after number 1, so you can wait to implement these changes.

• Code looks good, greps compleat.
• Nice change: improves readability.
• Tested some (~5) games, neither warnings/errors, nor strange behaviour.

In D4334#185734, @Silier wrote:

We don't need enums, thats correct.
But they help when changing strings/values to make change only on one place.

=== checks also for variable type and therefore is slower than == how is this helpful here?
We assign to those variables only enums, do we need to care about the type?

According to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness with == the values are converted before checking so that might actually be slower.

We don't need enums, thats correct.
But they help when changing strings/values to make change only on one place.

We don't _need_ it. :) Nor do we _need_ enums.
But it is nice to have when checking enums, IMHO.

Why do we need strict checking? == is totally sufficient here.

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

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

Some minor changes.

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

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

In D2440#185713, @asterix wrote:

@Stan @vladislavbelov do you know if anyone plans to work on this?

In D3475#185712, @asterix wrote:

Any decision regarding inclusion to master whether we agree and thus it is committable or disagree?

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

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

Replaced the "=="/"!=" with "===" or "!==".

@Stan @vladislavbelov do you know if anyone plans to work on this?

Any decision regarding inclusion to master whether we agree and thus it is committable or disagree?

Use strict checks (===) for comparison with enums and we're good to go.

I think after this pass (change == to ===) this is ready for commit.

r26026 Fixes my reported issue.

Works for me. (libsdl2-dev: 2.0.16)

In rP26023#54525, @vladislavbelov wrote:

I suppose without PCH on Linux? Because on Windows it works.

Aye.

Was pulling <algorithm> from utf16string.h can you try adding it to that file @Freagarach?

In rP26023#54522, @Freagarach wrote:

KeyName.cpp
../../../source/ps/KeyName.cpp: In function ‘SDL_Scancode FindScancode(const CStr8&)’:
../../../source/ps/KeyName.cpp:92:22: error: ‘find_if’ is not a member of ‘std’
   92 |                 std::find_if(scancodemap.begin(), scancodemap.end(), [&keyname](const std::pair<int, std::vector<CStr>>& names) {
      |                      ^~~~~~~
../../../source/ps/KeyName.cpp: In lambda function:
../../../source/ps/KeyName.cpp:93:37: error: ‘find_if’ is not a member of ‘std’
   93 |                         return std::find_if(names.second.begin(), names.second.end(), [&keyname](const CStr& t) {
      |                                     ^~~~~~~
make[1]: *** [engine.make:352: obj/engine_Release/KeyName.o] Error 1
make: *** [Makefile:117: engine] Error 2

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

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

Don't query cmpTurretable twice.

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

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.

Fix test.

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

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

Inline IsTurret.

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

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

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

Fix missing ).

@Langbart can you try again? :)

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

Compiles fine and runs on Debian Sid ("freetype": "2.11.0" reported, as is installed).

Add test.
Fix comment from @Stan.

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

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

Fix more properly.

In D4223#185614, @sera wrote:

Go ahead

Thanks

Go ahead

Also performance is not the question since number of messages for turreted is just subset of original number of messages from garrisoned.
Only additional cost are extra variables but amount of data is not affected.

In D4223#185612, @sera wrote:

"Ralph Sennhauser <ralph.sennhauser@gmail.com>", if nick is required "sera" is fine.

Thank you. We don't use email in the list, so it'll be: { "nick": "sera", "name": "Ralph Sennhauser" }.

Its not complete now.
If someone would want to use it, they would need to update proxy and other stuff in common api.

"Ralph Sennhauser <ralph.sennhauser@gmail.com>", if nick is required "sera" is fine.

Whom I should mention in credits (programming.json)?

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

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