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

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

14:50 < Freagarach> Find idle units no longer requires entities to keep the garrisoned order and stay in the garrisoned state. Any objections to remove? ;)

This is not related to this patch, for the record.
[EDIT}: In rP9498 the isGarrisoned-flag was introduced and that actually also introduced that units stay in the garrisoned state with a garrison order. Which was two solutions (proposed by @historic_bruno) where one was needed?

I guess unit carrying resources or on a resource should obey orders and leave the wall or maybe a flag in the garrison holder that says unit are able to 'dismount' and should ignore orders

In D2377#99209, @smiley wrote:

Since apparently I had commented on this before, I have a feeling this would not quite work the way it should in certain cases.

Then again, its just a feeling. Consider that before wasting hours on potentially nothing.

Since apparently I had commented on this before, I have a feeling this would not quite work the way it should in certain cases.

I'll search.

Original patch was made by Amplikon, but has been mostly rewritten.

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

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

That inline got me wondering, wouldn't a saner implementation be to specify the build animation and fallback in the cmpIdentity ?

that line was explained in the line in the revision proposal

Before calling something an intrusion and doing a commit, one would expect to have at least read the differential revision proposal to see the reason why the code was written the way it was written.

From http://irclogs.wildfiregames.com/2019-10/2019-10-14-QuakeNet-%230ad-dev.log

14:50 < Freagarach> Find idle units no longer requires entities to keep the garrisoned order and stay in the garrisoned state. Any objections to remove? ;)

As of?

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.

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

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

Test.

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.

Can confirm it also affects windows + 10% CPU

@Stan This patch does not seem to be able to repair the damaged stone walls and arrow towers directly. I have tried several factions, Athens, Macedonia, Carthage, the Indian Peacock Dynasty.

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

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

Now has a ticket at #5620

Reverting the UserReporter back to rP22771 proves it is the UserReporter

With this revision the CPU usage of 0ad on my machine is always 12 percentage points higher than before this revision.
That equals exactly one virtual core, so one thread. Guess you are badly polling somewhere.

In the future the translated strings can be updated only if the selected language changes.

While the GUI selectively updates for certain config changes, this is not feasible for the language, because the strings defined in the XML file would not be updated.
Changing the language ingame currently means the mainmenu page is reloaded (switchpage), but this is out of reach currently for the session due to too many state variables that would be lost in the session.

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

In D2353#99093, @elexis wrote:

In D2353#99092, @Imarok wrote:

(OptimusShepard got an OOM after about 30 minutes when playing on a big map with 8 AIs that might be related to this issue.)

Reproducibly? (For example by replaying the match or starting a new match with the same settings)

No idea. Didn't got any more information.

It sounds unexpected that a magic number comparison would trigger an out-of-memory during a match later.
If the same happens without the patch (commenting out the ENSURE), then it's not the patch.
Also then it would be something in the simulation, in which case a replay and some profiling on that to figure out what happens might be useful.

Yeah, I also don't think it has anything to do with the patch, but I can't rule it out 100%.

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

• Fixed test.
• Some stuff which will be split into other diffs.

In D2353#99092, @Imarok wrote:

(OptimusShepard got an OOM after about 30 minutes when playing on a big map with 8 AIs that might be related to this issue.)

In D2353#99090, @Woodhousezb wrote:

Great Work!

I conform that the modification on line 92 dows the trick for my ryzen 3600. Now working. The packager for Archlinux has already included this patch in the a23.1-6 version of 0ad

I checked only checkrefs.pl warnings. Death and Sitting should be reexported

Doesn't seem fixed actually:

ERROR: art/animation/quadraped/camel_death.dae: Assertion not satisfied (line 393): failed requirement "recognised skeleton structure"
ERROR: Could not load animation 'art/animation/quadraped/camel_death.dae'
ERROR: CSkeletonAnimManager::GetAnimation(art/animation/quadraped/camel_death.dae): Failed loading, marked file as bad

Happens upon destroying persian trader.

Great Work!

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

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

Test has to be fixed yet.

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.

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

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

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