Some notes. Can you add yourself to the credits? Keep up the great work!

With more testing, in high number deathmatch, there was still high usage in CVertextBuffer::Release (gprof)

The structures/maur_defense_tower is missing a ..

Not done: this patch standardizes <Identity> tooltips. <Upgrade> tooltips could be done in a future patch.

Just wondering: train seems like D1245 and recruit more like what is done when clicking the button? I think this can be comitted as is and we can discuss "train" vs "recruit" elsewhere, if you want?

https://trac.wildfiregames.com/wiki/EnglishStyleGuide#Actions says “train (human units)” and that's also the verb used in the aura descriptions and technology tooltips (“training time”), so for consistency's sake we should stick with that in this patch.
A future patch could replace train with conscript/enlist/recruit, if people think that's clearer.

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

brit and gaul wall tower

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

Just wondering: train seems like D1245 and recruit more like what is done when clicking the button? I think this can be comitted as is and we can discuss "train" vs "recruit" elsewhere, if you want?

Then why not lower heavy skirmisher speed?

Fewer to test, basically. An additional benefit of the change being more minor, which is something I aimed to do when balancing. Avoid making big sweeping changes and if a change turns out to be too minuscule it can be further adjusted in the future.

Or raise cavalry javelinist speed?

Obviously, this would make javelin cavalry stronger, which I think is very unneeded as they're in a good spot balance wise currently.

By the way, this makes elephant archers slower, since they have the horse archer as their parent. Also, keep in mind there are two cavalry speed technologies (+10% each), from which elephantry and infantry don't benefit.

Didn't actually realize that was the case, will fix it in the patch soon. Getting the first speed upgrade will actually restore cav archer speed back to slightly higher than initially.

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

• Remove if in addBuilder.
• AddSingleBuilder -> AddBuilderHelper.
• Don't say orders have changed when they might have not been.

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

Added undefined type.

bug disappeared

Reported bug has been fixed, one can notice that the animation changed in the case when switching from 2 to 1 tab (there now is a gap between the panelButtons and the settingsPanel). New version fine with me too

That sounds nice.

I guess committing this means adding a PR to delenda est :D

If you make a https://github.com/0ADMods/deprecated_art mod I could these files to there, and Delenda Est could then be fixed by simply adding a dependency.

This patch will also solve gaps like this:

I guess committing this means adding a PR to delenda est :D

In D2584#108479, @elexis wrote:

I don't know what you refer to when you speak about MP savegame features, because so far there is only one MP savegame feature on the table, which is picking a savegame, starting a host, and then running that match.

Well, I don't know either, so I'll leave it up to you to figure out what should be done with deprecated art.

In D2584#108308, @Stan wrote:

I think it would be nicer to have the MP savegame features

Maybe those textures should be moved to the old public folder in https://trac.wildfiregames.com/browser/art_source/trunk/old_public

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.

192 width

256 width

In D2531#108430, @Stan wrote:

In D2531#108428, @vladislavbelov wrote:

I've reproduced that assertion locally on macOS 10.14.6 in debug-mode. I've figured out the reason: it seems that OSAtomicAdd64 doesn't work as expected in debug mode, maybe address was misaligned.

Can it be fixed?

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

C = 50%, A, B, D, E, F 10%.

In D2531#108428, @vladislavbelov wrote:

I've reproduced that assertion locally on macOS 10.14.6 in debug-mode. I've figured out the reason: it seems that OSAtomicAdd64 doesn't work as expected in debug mode, maybe address was misaligned.

I've reproduced that assertion locally on macOS 10.14.6 in debug-mode. I've figured out the reason: it seems that OSAtomicAdd64 doesn't work as expected in debug mode, maybe address was misaligned.

Refs D2476.

MemorySizeMiB and its usage was added in rP9546, was removed in rP13892.

In rP23423#41006, @Nescio wrote:

This is a great improvement, many thanks!

This is a great improvement, many thanks!

Given it was committed in rP6904 I assume checkrefs.pl --check-unused reports it?

Yes it does, amongst hundreds of other files.
grep -r decal_struct_wall_med didn't yield any results either.

Changes in collada do not matter :) It's just best to avoid them when there is no reason :)

Blame arcanist; I have no idea what those .dae files are, I didn't even open them.

Initially, I did 0.90 but then they were slower than Heavy Skirmishers, which didn't feel too correct. When I tried 0.95 (in a single-player test environment) I didn't feel like the change was significant enough. So 0.92 was a nice middle ground.

Then why not lower heavy skirmisher speed? Or raise cavalry javelinist speed? (Again, just curious.)
By the way, this makes elephant archers slower, since they have the horse archer as their parent. Also, keep in mind there are two cavalry speed technologies (+10% each), from which elephantry and infantry don't benefit.

Out of curiosity, why exactly 0.92, not 0.95, 0.90, or 0.85?

Initially, I did 0.90 but then they were slower than Heavy Skirmishers, which didn't feel too correct. When I tried 0.95 (in a single-player test environment) I didn't feel like the change was significant enough. So 0.92 was a nice middle ground.

(I guess it takes a bit of time, but it wouldn't hurt to document the test sample (i.e. approximate number of matches, list of participating players who may be considered either capable of judging or capable of playing representatively for competitive players. If its easier, one could also just upload replays and perhaps a link to the mod. The purpose of the list of test participant would allow (1) the reviewers to determine in how far the patch was tested and (2) later consumers of the patches (a24 players and devs) to find identify which players were capable of judging, or what might have gone wrong or right in case it was a fail or success.)

Changing just speed is my idea. Christmas wanted the changes to include a reduction to speed and range, but an increase to dmg. badosu suggested having a small (0.3 to 0.5) damage increase to make up for the reduced speed. Then lastly I have Boudica and Stockfish agreeing with how they are nerfed.
Test match wise I have participated in 8 matches were cavalry archers were used. Though, the matches were spread across the mod versions, which I only have the last one on hand. 2 of the matches had cavalry archers as the main army, in the others they were used for rushing.

Could this make skirmisher cavalry rushes too strong?

I don't see how this makes skirmisher cavalry rushes any stronger. Previously skirm cav struggled to get even 1 hit off on camels running away, now they should be able to fire off at least one shot. Still, when the camels are back at home they will simply be laying suppressive fire from the safety of the CC due to their vastly superior range.

Given it was committed in rP6904 I assume checkrefs.pl --check-unused reports it?

Also, I didn't rename, art/meshes/props/decal_struct_wall_med.dae, because I'm unsure what to do with it; I couldn't find any file that uses it.

Any reason for those collada edits? I know Linux needs EOF to be on a newline, but stuff handling DAE seems not to care at all...

Did I break something? arcanist was complaining, first about mime-type (which I set to text/plain), then about something:

>>> Lint for binaries/data/mods/public/art/meshes/structural/brit_wall_medium.dae:

Something went wrong with the gaul_infantry_slinger.png, which should have been this:

If changing ao files, strip the _AO suffix, as they already are in an ao folder (I only do it on a case to case basis)
Any reason for those collada edits? I know Linux needs EOF to be on a newline, but stuff handling DAE seems not to care at all...

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

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

Perhaps it's easier if you'd state the percentages how you'd like to distribute the empty space?
A: space between top and logo
B: space between logo and buttons
C: space between buttons and project box
D: space between project box and water mark
E: space between water mark and bottom
(The total vertical space currently required is 660 (100 for the logo, 200 for the buttons, 266 for the project box, and 84 for the watermark), which leaves 60 at 1280×720, 420 at 1920×1080, and 1500 at 3840×2160.)

Looks good to me :) Thanks for the patch.

Perhaps the logo can be moved something like 25-100px depending on resolution, perhaps a percent number to the bottom, and then some margin to the buttons?

Perhaps it would look best if the space between the top of the window and the product logo, between the product logo and the mainmenu buttons, and between the main menu buttons and the top of the project info box, and the bottom of the project info box and the bottom of the window would be divided uniformly?

This is what you meant, right?

Test plan: Changes were tested on the balance mod.

(I guess it takes a bit of time, but it wouldn't hurt to document the test sample (i.e. approximate number of matches, list of participating players who may be considered either capable of judging or capable of playing representatively for competitive players. If its easier, one could also just upload replays and perhaps a link to the mod. The purpose of the list of test participant would allow (1) the reviewers to determine in how far the patch was tested and (2) later consumers of the patches (a24 players and devs) to find identify which players were capable of judging, or what might have gone wrong or right in case it was a fail or success.)

Personally I think icons ought to match the actor. The ptol archer uses the mace actor, which looks the same as the athen actor, so it would make sense for all three to use the same icon.
Both brit and gaul slinger deserve a new icon, I believe their actors were separated and updated last year.

Regardless of the implementation, the productLogo would need to be moved to a different parent object.

Do you mean the 0 A.D. at the top or the Wildfire Games at the bottom?

One could make a mockup with different size numbers and then decide if it looks better or not (for 3840×2160).
Actually another possibility would be to use percent numbers. So perhaps one can use something like 10% +/- offset for the product logo, so that its not aligned at the utter top for large resolutions, only for small ones. (Its quite boring to compute / implement, so I guess one can also argue with the best implementation being too boring to implement and this one being the best one that is feasible given motivation.)

(The idea was actually to improve things for 1280×720; if it works for a small screen, it typically works for a higher resolution as well; the reverse is not true; anyway, I'll do some tinkering with the numbers and see what I can get.)

In D2586#108360, @Nescio wrote:

Keep in mind many ship, siege, and support units currently share a single icon for templates of different civs.

In D2568#108351, @Nescio wrote:

This is the patch I uploaded at https://code.wildfiregames.com/rP23387#40853 so it would be correct to credit that.

did you mean you want your username explicitly mentioned?

Yes. (I don't care about this one line changed here, just in general. Discussion != patch)

Keep in mind many ship, siege, and support units currently share a single icon for templates of different civs.

@elexis, you make valid points. Nonetheless, I still believe this patch in its current form is an improvement over the status quo.

In D2586#108352, @Nescio wrote:

For the ones using an incorrect civ, wouldn't it make more sense to duplicate the icon to have both brit and celt, mace and athen etc?

Maybe, though that would mean having two exactly identical images. Wasn't it your intention to try reducing the download size?

For the ones using an incorrect civ, wouldn't it make more sense to duplicate the icon to have both brit and celt, mace and athen etc?

Maybe, though that would mean having two exactly identical images. Wasn't it your intention to try reducing the download size?

This is the patch I uploaded at https://code.wildfiregames.com/rP23387#40853 so it would be correct to credit that.

Again, I'm not sure what you mean, the summary already starts with “As discussed in rP23387”. Or did you mean you want your username explicitly mentioned? (No problem!)

Perhaps it would look best if the space between the top of the window and the product logo, between the product logo and the mainmenu buttons, and between the main menu buttons and the top of the project info box, and the bottom of the project info box and the bottom of the window would be divided uniformly?

I suppose I could try out how that would look, although I don't think floating elements would be an improvement.
Is there a XML equivalent to (La)TeX \vfill?

For the ones using an incorrect civ, wouldn't it make more sense to duplicate the icon to have both brit and celt, mace and athen etc?

Thanks, I've tried it (on Fedora 31 with Gnome desktop), and it works as described in the summary and test plan.

Out of curiosity, why exactly 0.92, not 0.95, 0.90, or 0.85?

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