Anything that needs to be trained, @Stan?

The consensus is clearly against.

Also improve indentation for better readability.

into

• Because wall segments are not buildable on their own, moved their tooltip to template_wallset.xml.
• Also standardized <Identity> and <Upgrade> tooltips of all gates.
• Purged meaningless tower <Upgrade> tooltips, since the entity it will be upgraded to and the resources upgrading cost are already present in the automatically displayed tooltip. Having and additional <Tooltip> string just means more text, not more information.
• While at it, renamed tower <Upgrade> nodes for clarity and consistency.

This would fix all your complains. Improved from the version elexis mentioned before by making the edges not overlap with the slider button.

Actually I'm not sure it would. Also, I agree with elexis those sliders in your screenshot look a bit ugly, though they are clearer.

Also dropdowns require hardcoding the values whereas a slider only has 3 datapoints (min, max, step)

Thanks, I agree that's an improvement.

Gamespeed (1) has labels, so it would remove something, also stepsize other than 1, so I would have added a worse workaround until there was D406.

Perhaps move the game speed setting to the top, to make things visually more pleasing? This looks a bit ugly to me:

• The sliders are rather narrow and because you have to click on them, this makes them harder to use than the vertically much larger drop-down boxes.

It would be nice if clicking above the slider, rather than exactly on the line, would also work. It shouldn't be too hard to increase the (vertical) sensitive area? And maybe make the arrow keys work with sliders as well?

Then one could at most use a 5 minute step dropdown, but that would also not allow chosing 2 minutes or 38 minutes for example.
It is also easier to pick values with a slider if there are 60 of them.

True; the question is how likely it is people would want 38 minutes, rather than 40.

Ceasefire has the main use case at < 5 minutes on nomad.

Then why not reduce it further, to e.g. 30 or 20? (Just curious.)

The number of relics is the number of civs, each relic is spawned at most once.

So each mod that adds civs ought to edit the gui files?

Why did you use it for these four settings, but not others?

This had been discussed as well. It seems not publicly.
There are dropdowns with few choices where the labels are more informative than numbers, for example mapsize "small" is more descriptive than mapsize 192.
For starting resources the upper limit is infinite / 50.000, so using that as a scale wont work well.
For the population limit, maybe, I never said that this should be the final layout, but it was used for the durations first and foremost because those are continuous values selectable.

Understood, I was thinking more of settings with narrower ranges, e.g. game speed (up to 2×) or number of players (up to 8).

A few minor points:

• The sliders are rather narrow and because you have to click on them, this makes them harder to use than the vertically much larger drop-down boxes.
• The ends are noticeably faded, which is somewhat confusing. (Are the min and max values less valid options?)
• The relic and wonder time go from 0 to 60 minutes, ceasefire from 0 to 45; why not 60 as well, for consistency? 60 minutes ceasefire used to be an option. (Off-topic, why exactly is 13 the maximum number of relics?)
• Why did you use it for these four settings, but not others? Having a drop-down for game speed directly above the ceasefire slider is a bit ugly.

Overall, I'm not entirely convinced sliders are better (more user-friendly) than drop-down lists, though I don't have very strong feelings either way.

"SB1" and "SB2" appeared exactly once, in the maur.json file, and were obviously placeholders; other civs leave this string empty ("").
Inserting SpecialBuilding is rather meaningless, because the fact that they're “special” (i.e. not available to all civilizations) is the very reason they're listed in the civ files in the first place.

"SB1", "SB2"

All Armour values got consistent now, feel free to removing trailing 0's from other template values too

D2000 removes trailing zeros from aura files, D2222 improves the civ files.
For templates, maybe later, preferably after D2502 (adjusting wall footprints) is in, because rebasing that would be a lot of work.

In case phabricator can't handle the images (D889#38774), here's a zip with the textures:

Initially, I did 0.90 but then they were slower than Heavy Skirmishers, which didn't feel too correct.

That made me wonder, so I looked up the current walk speed numbers:

                      citizen , champion , hero
cavalry javelineer  : ×1.95   , ×2.25    , ×1.9425 (= 1.85 × 1.05) 
cavalry archer      : ×1.95   , ×2.25    , ×1.85
  patch proposal      : ×1.792  , ×2.07    , ×1.85
infantry javelineer : ×1.4    , ×1.75    , ×1
infantry archer     : ×1.1    , ×1.2     , ×1

The differences are especially pronounced for the infantry javelineer. (Maybe something to revisit in a future patch?)
Regardless, I wonder why champions are significantly faster than citizens. They have a lot more armour and health and can't gather (hunt). If anything, I'd expect champions to be slower or at most equally fast.
The current differencea between citizen and champion walk speed go back to rP20230, which introduced relative speeds (multipliers). Prior to that template_unit_cavalry.xml, template_unit_champion_cavalry.xml, and template_unit_hero_cavalry.xml all had a walk speed of 1.65; the commit message says: “No significant value change.”

now with svn add

new iteration requested by @elexis

(Finding good numbers would take some time, and to me its currently not broken.)

Yes, I understand, I meant some approximate mock-up values.

(Also equations like -144+120 should be computed)

Actually I kept those intentionally: the third number is the position at 720 pixels, since the second number cancels out the percentage.
And 1280×720 is equivalent to 3840×2160 at 300% zoom.

I would keep the organization logo and build information grouped, otherwise looks ok to me (and the product logo offset looks better than not having it so this iteration improves that).

So E is 0% and C is 60%?

Perhaps the projectinformation box should also be moved further below, or kept aligned at the organization logo.

diff 11136 appears best

That's why I've uploaded it last :)

If we want the images bigger, we can just render a bigger one...

That could be nice. Currently it looks like this on 3840×2160 at 300% zoom:

EDIT: I meant the watermark product could be used in the main menu;

The design is similar, but the watermark colours look brighter, presumably to have better contrast on various backgrounds?
Besides, mods might want to replace the main menu logo but keep the 0 A.D. watermark logo unchanged.

Allow floating digits for mods that would want decimal armor levels, but remove the enforced .0 from the default armor tooltip.

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.

brit and gaul wall tower

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:

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

192 width

256 width

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

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.

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:

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.)

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?

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.)

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.

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?

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?

The crannog and colony are fundamentally centres and should thus be listed together.
And it'll only show up to those civs that actually have the template, if that's what you meant.

mercenary/ies → Mercenary/ies
recruit → train

True, there are no Elephant-specific technologies, though e.g. archery tradition does apply to elephant archers.
Something that could be tried is introducing two technologies, the first upgrades elephant archers from basic (one archer) to advanced (two archers), the second to elite (three archers). I'm not sure it's a good idea, though. And probably beyond the scope of this patch.

Thanks! Now let's hope a team member agrees with the change and is willing to take responsibility for committing it.

@ValihrAnt, any thought on this?

crannog

• build restrictions
• technologies
• wood, stone, *and* metal
• redistributed fortress tooltips

greater differentiation between early strategies

But the patch is doing the opposite of that and forcing the player to build A B C and D instead of making it his choice which direction to go.

Right now it doesn't matter what you build, all structures count towards the phase requirements. With this patch players will have to choose: do I build what I want (e.g. several houses to train more women) first or do I prioritize the phase requirements instead?

Disagree both with reducing the amount of structures necessary to be built (the phases are usually eco-rushed through quite quickly)

corral + farmstead + house + storehouse = 375 or 450 wood
5 small houses = 375 wood or 5 storehouses = 500 wood
blacksmith + market + temple = 500 wood + 300 stone
4 large towers = 400 wood + 400 stone

For your information, I implemented this patch:

svn revert -R *
svn up
arc patch D1958
cd build/workspaces/
./update-workspaces.sh -j7
cd gcc/
make -j7
cd ../../..
binaries/system/test
binaries/system/pyrogenesis

Then I decided to try out the “Sandbox - The Britons” scenario, because that one has Boudica. When generating the map, 0ad closed itself, but pyrogenesis continued running in the terminal. I shut it down and tried again, twice, but with the same result.
Afterwards I removed the patch, recompiled the game, and tried the scenario: no problems at all.
Conclusion: there is something wrong with your code.

svn propset svn:mime-type text/json elephant_worker.json
svn propset svn:eol-style native elephant_worker.json

"all": on a new line

For territory root see also D2005.

Yeah, but it's unclear if and when that one will be committed, or in what form. Removing "Territory root." from the <Tooltip> strings later shouldn't be much work.

Hack, Pierce, Crush again.

Would this allow the Mauryan elephant archer with a melee elephant upon which places can play an arbitrary number of archers?
If so, great!

Apparently it no longer is:

Updated.