What diff made this change possible ? Seems like a good idea.

Another option that might be more resilient: Can you simply remove the if entirely, and let the AI run? That should clear up the saved events, but maybe there are other issues ?

It seems like the use case of an AI not being defeated but not having entities for a long time might be kinda legit in campaigns/scenarios, to be honest. But perhaps the best course of action then would be to reinitialise it?

Rebase, fixup, and settle on ParseCmdLine option

Good idea with the namespace, see inline.

In D5001#214320, @phosit wrote:

In D5001#214314, @wraitii wrote:

I am not sure you need a class in MapGenerator.h, these look like they could be static functions TBH.

It's there to mark one function private.

Yeah I sorta guessed that. Guess I'm OK with it then.
Still think the name is kinda clunky.

I think this looks quite good.

Rewrite the diff again as rebase.

In D4786#214284, @phosit wrote:

Yea, this diff just makes the state hash check a _bit_ faster ;)

Would it help to use another hash function? Propably it's not worth the time changing that.

I think it would be straight-forward to add some logic that if a PlayerDefeated event matching the AI playerId is seen, you mark the AI as defeated and early-return. That would play nicely.

Did some profiling on some upstream SM 115: https://share.firefox.dev/42zTa7H
If you look inside ComputeStateHash, it seems we're spending 10-15% of the time doing raw MD5 updates, but also significant time in GetPrototypeInfo, GetScriptBackrefTag, and then it's mostly just overhead from string manipulation.

I can confirm the performance drop and the fact that this helps.

This looks like an awesome find. I'll double-check the profiling, but it seems likely right.

What are the situations in which the device can be nullptr ?

Thanks Freagarach, was wondering why it wasn't an option already :P

In D5040#214206, @vladislavbelov wrote:

ConfigDB (reads the value from files) > RenderingOptions (gets the value from the config) > JS (overrides the value) > RenderingOptions (gets a notification about the changed value) > Renderer (adjusts stuff according to the value from RenderingOptions)

If we'd add a separate config for cinematics then we'd have another layer of duplication for the silhouettes option.

In D5040#214201, @vladislavbelov wrote:

Just config isn't enough because it's not as flexible as we have it now. It'd be same problem we have for options.json.

I'm not sure what you mean here.

In D5040#214199, @vladislavbelov wrote:

I meant the config flow should go through JS to allow to modders to adjust it according to their needs. It might be adjusted differently for different cutscenes or different game states. And the updateCinemaPath function is the only one correct place to do so.

Not if the cinematic itself has config metadata. Conceptually I think a cinematic could ask for stuff that isn't really part of the config, like changing the skybox, switching to a different LOD, doing other things like that. Worse, settings should sometimes change mid-cinematic, potentially.

In D5040#214197, @vladislavbelov wrote:

This is terrible code and really we should have a 'playing cinematic' mode in the renderer to offset this stuff.

Removing silhouettes from JS reduces the flexibility for modders.

Not necessarily, we could configure that behaviour separately by loading a cinematic XML data or even at the cinematic level, by having some specific per-cinematic data. I think that would be best.

Small tweaks, reuse more existing translations, fix small bug with timeout, remove debug comment in C++

Un-comment essential line.

Sorry @real_tabasco_sauce, got distracted by something and forgot to credit you :(

Works on my mac os 12 and looks OK. Let's get this going !

In D5020#214028, @vladislavbelov wrote:

In D5020#213981, @wraitii wrote:

Guess what, this doesn't actually change hashes on CombatDemoHuge because we always short-circuit.
It's probably the single biggest improvement we've ever had on that particular map.

Do you have not logarithmic but linear per-turn stats?

In D5032#214032, @sera wrote:

Your intro begs the questions:

• If IFSPIKE is bad code, can it be fixed?

Nah, the approach is bad. If specific messages / code needs to be tested, a specific test can be added by the programmer, as things stand they're useless.

• If IFSPIKE is useless why not remove the macro (and code) for good?

'Cause I wrote the code and it's a little bit of a mess to cleanup and I didn't want to do that now.

Not worth doing as-is

Guess what, this doesn't actually change hashes on CombatDemoHuge because we always short-circuit.
It's probably the single biggest improvement we've ever had on that particular map.

SM92-compatible version

In D5004#213436, @phosit wrote:

IMO GetJSInstance should not be const. I'm ok with the mutable cache but i dislike the const_cast.

Don't really have a strong opinion, but semantically I think it's 'const' until we make the script a part of Component fully

Update for SM92

Profile on a an AI 2v2 on very large mainland:

Quick profile on an AI 2v2 on a Very Large Mainland map:

Updated patch: do GCs more often, 6ms per frame.

Profile from an AI 2v2 on very large MainLand that ran for 35 minutes.

SM92 compatibility + run a shrinking GC after game Init, as that is likely useful at that point.

Some Profiler2 replays:
An AI 2v2 on a very large map, I waited until one player was defeated: about a raw 10-15% improvement on Sim update & AI update.

They also exist on SM92, so here we go.

Should do the message part as part of D5026

Wrong diff ,this is the correct code

Remove unrelated code

There's basically the same code in createMountain, should change that as well...

In D5020#213870, @Freagarach wrote:

This doesn't seem to give the same result when we have another entity with preference 0, but I guess that is kind of undefined anyway. ^^

In D5023#213736, @vladislavbelov wrote:

What's about memory differences? Does the #2611 ticket blocks it for Windows?

Slightly bigger change, but I figure after some more profiling that it's probably worth doing at the same time (avoids adding PersistentRooted that will be deleted).

Change GetJSInstance to return a HandleValue. This avoids an unnecessary rooting which is slightly faster.

Yeah that seems a straighforward improvement here.

In D3938#213334, @phosit wrote:

Most (when not all) uses of PackedArray<bool> could be replaced with std::bitset.
For the other cases: are you sure PackedArray is faster than std::array?

For the particular case of the Los enum (which is two bits) I had tested it to be much faster, and I think that that point it makes some sense to use the same thing over std::bitset somewhere. Could be argued otherwise.
Part of the problem is that we do quite a few mask-comparisons, which are quite a bit slower on std::array.