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

let -> const

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.

Not too sure about the SetRebuildableFromEnt name but it's a WIP after all. Added get/set functions in Foundation.

Reads correct.

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

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

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

No I haven't tested multiplayer.

Formatting, range based looping, avoid stack allocation in Game::IsFinished.

@Mercury thanks for all the work on this so far. Can you address the not done inlines? Did you test in multiplayer? @vladislavbelov said he would look after Feature Freeze.

Those were not forgotten, and there are more than two team cases as well. See the comment on the diff.

How does this new version perform with regards to performance?

@jprahman the issue is that the new patches applied on top of sm91 prevented it to build on Windows. We first need to address those before switching to 102.

Looks good from my end for the most part. A few lingering nit type comments left, but otherwise great.

I did some more testing. Teams are correct in a 3v2 or 2v3 or 3v4 or 4v3, but in a 2v4, the placement is incorrect.

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

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

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

I haven't deeply read the code for source/lib/allocators/* or the code which uses them so I don't know.

changed range based loop to std::for_each in destructor.

What should be the outcome when there are 2v2v2 and other related configurations?
The current code would place three slots on either side and divide one team. Which might be acceptable. But 2 slots on one side, and 4 slots on the other side with no divided teams is also an option. I would actually prefer the current behavior because asymmetrical placement would get quite messy with extreme configurations.

imo, this is a bug fix, not a new feature, so it should get merged before a26 is released if it can get reviewed in time.

Units in formation respond fluently to new targets, as shown here. (Tested @ 27036)

In D4750#202235, @s0600204 wrote:

In D4750#202204, @Freagarach wrote:

A globalscript fix would be [...] way more work with added chances of breakage.

Indeed it was (and is): P282

I haven't exhaustively tested it; by all means leave it until after A26 gets out the door.

ah that's what you meant.
Yeah what Stan said, same button, just accept again if its ok.

Either accept or resign from the revision.

Yeah but isn't that on a different page? What do i need to do here?

In rP26956#58608, @Grapjas wrote:

What is expected from "This commit now requires verification by auditors."?

In D4697#202408, @wowgetoffyourcellphone wrote:

In D4697#202056, @marder wrote:

thx for the acceptance, but I still think this part of the summary has to be done to complete the change:
Building stats (health & capture points) will probably need to be adjusted to accommodate this.

This would probably require quite a bit of testing and would be facilitated better if the patch was committed.

In D4697#202056, @marder wrote:

thx for the acceptance, but I still think this part of the summary has to be done to complete the change:
Building stats (health & capture points) will probably need to be adjusted to accommodate this.

What is expected from "This commit now requires verification by auditors."?

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

Question: Should we use a custom allocator for the std::vectors? Those in source/lib/allocators/*

@Stan some of it will be coming from avoiding unnecessary copying, passing by reference. The theoretical complexity cost of removing the capacity limit is negligible. I would want to do more runs and average them together before I trusted that number to mean anything beyond that it hasn't gotten any worse. But I'm too tired to do that right now.

So better than initial? Nice. Would be nice to compare a frame to see what's reduced.
Still 10% sounds almost too good to be true.
EDIT: Can't read.

@Stan %12.7 👍 (based off one run)

@jprahman @Mercury
Some areas of improvement are probably the messaging system; For instance in late game, each entity that dies notifies all the entities on the map through a global message, while it's not really necessary, but we don't have dynamic subscription. All of that has to be copied to the AI too might be no longer relevant since the unthreading of the ai (D3769
);
frame of units combat (huge):

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

Hello @jprahman, thank you for your help! I think there is more performance to be found, some in network and some in SpiderMonkey GC. Hopefully some more in territory calculations. After those we may want to try multi-threading. A lagless TG might be possible :)

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

How does this new version perform with regards to performance?

Added more tests, made ComponentDataHolder::Pools return a reference, renamed AllocFunc to ConstructFunc, use for_each in ComponentDataHolder::Destruct, use range based loop in ComponentManager::ResetState.

I'd say yes.

@lyv

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.

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.

Change to use cmpFoundation to get the currentTemplateName, with this, there is no need to use cmpTemplateManager.

In D4740#202201, @Freagarach wrote:

A bit more explanation seems in place.
You use now the template of the foundation (foundation|<sometemplatename>). However, Foundation.js has a property called finalTemplateName, which is the truth about what the foundation will become when finished. E.g. foundation|<sometemplatename> may become foundation|<someothertemplatename> when finished.
As such, when cmpFoundation is present, it ought to be used. Else one can use the current template name (no need for the includes then).

Let me know whether this sounds about right.

Works for me. Thanks @marder

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.

Patch based on comments. Hopefully fixed build issues too.

This unfortunately breaks units responding properly to enemy units while in formation. Reported on the forum (read from that point and onwards). Video of the behavior

Works for me.