Nice, thanks :)

The behaviour you describe regarding attack/gather are known limitations of the formations. But I can try to see whether it can be fixed as well (in another patch).

In D4279#182360, @vladislavbelov wrote:

In D4279#182345, @s0600204 wrote:

(Also I don't know how much more computationally expensive such an approach is.)

That's the main point. In theory it shouldn't be slower than 4 heightmap traces in your current approach.

@wraitii Is it allowed to move the structures/{civ}/pyramid_small into the builder.xml file? Layout looks better this way.

This makes sense to me and I think expands on one of the “unique” civ aspects in the game.

In D4279#182345, @s0600204 wrote:

I might be wrong, but from what I can tell, the problem with that approach is that it seems to ignore the water plane.

Sure, and you can easily do max(waterHeight, mipmapHeight).

In D4279#182331, @vladislavbelov wrote:

Maybe you could get average height from HeightMipmap?

@Langbart thanks for testing.

The units in a battalion, who were tasked with cutting down trees will only cut down the first tree and then remain idle. They will not look for a new tree.

In D2175#182341, @marder wrote:

Since the battalions are now tied to formations (as far as I understand), is it still possible to have a battalion and send it to gather something or will this disband it, since the formation can not be used for that?
Cause I liked it to be able to select one wood cutter battalion with one click and task them with something different.

I am unable to test the new version at the moment, that's why I'm asking;
Since the battalions are now tied to formations (as far as I understand), is it still possible to have a battalion and send it to gather something or will this disband it, since the formation can not be used for that?
Cause I liked it to be able to select one wood cutter battalion with one click and task them with something different.

Only issue with number as string being key in dropdown is that it depends how is written in config 1.0 and 1.00 or 1 will dispay as 100% in dropdown now, but will not work with dropdown having string as keys

Tested it on the map Hindu Kush (2) with steep hills, Farmland and the scenario map Units Demo. The problem in the referenced ticket can no longer be reproduced. For a player/user this solution works.
EDIT: Also tested in Atlas, works.

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

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

Use const, and reduce number of method calls on the g_Renderer object.

Maybe you could get average height from HeightMipmap?

IRC 0ad-dev (22/Sep/21)

Indeed it was not discussed publicly I believe, as I had a really hard time reaching to @user1

In D2175#182306, @Freagarach wrote:

http://irclogs.wildfiregames.com/%230ad-dev/2021-09-20-QuakeNet-%230ad-dev.log
I'll try to merge this this week then, unless objected.

http://irclogs.wildfiregames.com/%230ad-dev/2021-09-20-QuakeNet-%230ad-dev.log
I'll try to merge this this week then, unless objected.

I will run the --force-rebuild if/when it is committed. :)

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

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

One (final) pass on the CI

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

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

In any code we are going to need two checks, so this is probably the cleanest way to dupe the call.

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

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

I would side with Stan that a getter should be named GetFoo(). Otherwise seems good and greps complete.

Improve the statusEffect handling (removes 2 todo's)

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

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

Fixes "system".

Front doesn't fall, no difference on my system

In D4278#182263, @Stan wrote:

@Langbart can you check cursorbackend="system"

@Langbart can you check cursorbackend="system"

IRC 0ad-dev (20/Sep/21)

19:12 <@Stan> @tell Langbart have you got a retina screen ? Can you test D4278 anyway ?

Yes, I do use a retina screen. Ok.

In D3611#182259, @Stan wrote:

Any errors/warnings? Else it's good to go I suppose @s0600204

Any errors/warnings? Else it's good to go I suppose @s0600204

In D3611#182257, @Stan wrote:

pass --force-rebuild to build-osx-libs.sh

I'm stupid, you need to pass --force-rebuild to build-osx-libs.sh

In D3611#182254, @Stan wrote:

Can you run the script without --preserve libs ;) You need to rebuild the thing for the pc files to be copied.

Same error as above.
Entire terminal output: https://termbin.com/47vw

Can you run the script without --preserve libs ;) You need to rebuild the thing for the pc files to be copied.

In D3611#182252, @Stan wrote:

Can you see if you can find the fmt.pc file? It might be name libfmt.pc or something similar.

Can you see if you can find the fmt.pc file? It might be name libfmt.pc or something similar.

In D3611#182197, @Stan wrote:

@Langbart can you test this maybe we'll be able to debug what goes wrong on macos :)

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

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

taskedResourceType

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

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

Some balancing on the different units: make infantry and animals accelerate faster and ships and siege slower

In D3991#182204, @bb wrote:

Showing all the incompatible mods fills your screen with a lot of blur, a new user certainly shouldn't be seeing. So against this default change.

Well, a new user wouldn't have many mods, but point taken.

There is also a filter valid mods checkbox in the download screen. If anything it should be consistent.

Good point.

I really only see one usecase of the other default: if there are no compatible mods available. However in that case it would be much better to write that instead of the list of available mods.

How about I just adding "there are hidden, incompatible mods" as the last line in all cases where there are some

I see two different cases, how we with the proposed code produce the error:

• A component on a mirage is queried which is not present in the parent. In this case, there is no problem at all, we should just return null.
• A component on a mirage is queried which is present on the parent but isn't fogged. Now there are some sub cases
  • The mirage shouldn't have the component since the mirage isn't expected to have that component (e.g. a mirage doesn't shoot arrows so it doesn't have a buildingAI).
  • The mirage shouldn't have the component since it has its own (e.g. selectable): we probably should be returning the mirage's own component then (having both a miraged and an own version sounds weird and buggy).
  • It should have been fogged: if someone calls QueryMiragedInterface, the calling code will probably not function correctly or at least do something different than expected. Any proper review will check if the requested component is actually miraged if it should be. Since we cannot distinguish this case from the previous, we cannot really error in this case

I really only see one usecase of the other default: if there are no compatible mods available. However in that case it would be much better to write that instead of the list of available mods. Just write like No compatible mods available,. Try to disable some mods or download new mods online.

I see the issue, but don't like this solution (since "rating" says more about game type than player), nor I have a better solution.

@Langbart can you test this maybe we'll be able to debug what goes wrong on macos :)

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

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

Text.

[disclaimer -> not tested]

The new method feels really good. I like it a lot. I like how you can even combine battalions into one. It feels really smooth and useful even. It's a step forward for Delenda Est for sure.

I think TaskedResourceType might be a better fit than 'current'

It'd be great but who knows how long it will take for someone to go out and make it.

Just write it as you like and get it committed to /binaries/data/mods/public, doesn't have to be a complete or perfect plan, a rundown of possibilities will already do, anything else I don't see ever having success indeed.

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

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

Use clone.

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

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