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

fix spaces around { and }

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.

(Rebased.)

Rebased to account for other changes in the repos since mid-September.

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

Superseded by rP23172. Looks like three other issues were introduced there but I will fix those separately so as to not confuse the references to this patch number.

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

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

First attempt at using arc

Updated python dependencies and fixed bug when built w/o the RL interface.

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

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

Try with ps/trunk/ prefix

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

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

Add missing file.

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

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

Switch includes, fix premake.

Reason of this diff is to move Preprocessor file to third party files, what is completed and moving a file does not break its functionality.

This patch does step 1 "moving" and the next one will do the "update part"

thread

thread

Remove an useless reassign of isMe with the same value.

From D2409

the same value than above

Incorrect.

(I didn't check the semantics)

In D2338#102497, @Angen wrote:

Tests are passing.
Shader errors are reported.
From what I have seen shaders do work as without patch.

I can't tell from that if you have read the patch too or only blackbox tested it.

Tests are passing.
Shader errors are reported.
From what I have seen shaders do work as without patch.
If it is third party file it should be in that folder.

I don't think the OOM can be related to this, as this code (or the result of using it) is never used again after initialization, as far as I know.

I tested the game with, and without the patch for several times. With the patch the game crashes with an OOM after 30-45min. The OOM report isn't every time the same. Without the patch the game crashes only at the start. I have tested it with following settings. Mapsize big, very huge start ressources, 4 ai vs 4 ai, anatolien plateau, speed 20x.
In my opinion someone should take the current documentation of AMD and make a clean implementation.

Sounds like something @Gallaecio could review.

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

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

fix linter warning

In D2353#99092, @Imarok wrote:

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

Please report back if you have any bugs with the patch.
(@OptimusShepard got an OOM after about 30 minutes when playing on a big map with 8 AIs that might be related to this issue.)

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

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

style changes

This might work now, but it will not with D1462 or if we disband formation with less than 2 members as that is done anyway after lonely units in formation gets order. In that cases formation cannot be disbanded because member was renamed.

Actually there is no error (shown), probably because the formation-entity is disbanded the following turn. So at first the entity is added, but then the formation is disbanded and the lonely entity is also not in formation anymore.
Nevertheless, it should probably be made such that previous behaviour is restored.

This code has long been planned to be removed (precisely because I expected things like this to happen), if things are difficult to fix a good alternative is just to stop calling this code, but it's all a bit messy to figure out where this code is called from. See also #4451.

Can you test if the OOM is reproductible though?

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

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

Some minor stuff, thanks for picking this up again :)

Unit packs and unpacks as expected. Unit correctly cancels unpacking or continue packing when is ordered to move somewhere.
Issue when player cannot move unpacked siege unit because enemy is in range and unit keeps unpacking have been solved in this diff in the way, player does not have to click to cancel unpacking manually but just gives order to move.
LeaveFoundation works as expected for packable units and stays the same for other.

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

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

style change

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

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

Fix LeaveFoundation unpacking behavior. This required some refactoring to avoid code duplication. As a result, all of LeaveFoundation behavior (siege unpacking, ordinary units, units in formation, animals) needs testing now.

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.

split precondition test

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

LeaveFoundation

Unit packs and unpacks as expected. Unit correctly cancels unpacking or continue packing when is ordered to move somewhere.
Issue when player cannot move unpacked siege unit because enemy is in range and unit keeps unpacking have been solved in this diff in the way, player does not have to click to cancel unpacking manually but just gives order to move.

Yeah which is why it should be committed if that's the right fix ;)

In D2353#102347, @Stan wrote:

This person also runs out of memory #5645 without the fix, maybe it's the same reason.

@Angen thoughts on this patch? All it does is move code to third party.
@linkmauve in case you want to look at the GLSL preprocessor code
For the record I chatted on the Ogre Gitter, and they are still making some fixes to it + the ones we currently have because we are a lot versions behind...

@StanleySweet then you might be interested in this: https://github.com/OGRECave/ogre/issues/614

code that takes care about renamed entities is shorter, cleaner and mostly correct.