And I've tested by doing the following:

• svn up and deleted cache
• rebuilt the game with clean-workspaces.sh then update-workspaces.sh
• binaries/system/pyrogenesis

It turns out the problems I reported on the forums last Friday are still there:

• when opening "Learn To Play/Structure Tree" from the main menu:
  • clicking the "History" button closes it and returns to the main menu (instead of opening History)
  • pressing Alt+Shift+H opens History as it should
  • pressing Alt+Shift+T re-opens the Structure Tree (when it's already open, it should close)
• mutatis mutandis for "Learn To Play/History"

Then I did arc patch D2273 and tried again. Clicking the History/Structure Tree button opens the corresponding window, as it should, so this patch apparently solves that problem. However, pressing Alt+Shift+H/T still re-opens the corresponding window, even though it should actually close it when it's already open, so that problem is still there.

Unfortunately I don't understand these lines of codes, therefore I don't consider myself capable of properly reviewing this.

Thank you!

I suppose each item is a civ bonus?

Each entry is a civilization bonus, team bonus, special technology, special building, or hero.

If you have a better suggestion for the comment sentence, feel free to be bold and go ahead!

So I wonder wheter that dot comes from.

Some of the {civ}.json use non-empty placeholder strings; they're removed in D2222.

Thank you for that last explanation!

comment

@Krinkle, yes, I agree, the entire tooltip could use a critical look and perhaps a redesign; especially concerning the various resource stats.
However, what do you mean exactly with fractions? Display 1.2 as 6/5? Wouldn't that make comparing things harder for typical users?

Should also always account for mods.
The simulation templates are 0ad content, but the simulation components (even the GUI too) are meant to work with arbitrary game content (as far as I'm concerned).

The armour percentage for level x is 1 - 0.9^x; although it's theoretically possible for a mod to use decimal levels, I doubt people would really use e.g. x = 1.23.

Perhaps it was originally added because 3.0 crush (27%) looks more noble than 3 crush (27%) x)

Or perhaps it's just because attack damage has (and needs) a decimal?

But I wouldn't say there is no consistency, since the tooltip strings above and below the armor tooltip also uses one decimal place (Capture Attack, Melee Attack, Armor, Speed, Gather Rate)..

Health doesn't have decimals, whereas e.g. resource trickle can have numerous.

I don't have strong disagreement on the armor tooltip itself, so I suppose it's okay.

The current situation or the proposed patch?

(Shouldn't Melee attack come prior to Capture Attack?)

Why? Isn't capturing the default?
Speaking of which, I think it would be more logical to list armour between health and capture attack; but that discussion is beyond the scope of this patch.

(All techs and promotion and whatsoever also result in natural numbers for armor too?)

Yes; unlike attack damage, resource costs, health, etc., which typically use multiply modifications, the data/ files use only add for Armour.

Also perhaps it wouldnt hurt to remove the trailing 0 in the templates.

I suppose I could write a patch for that, if I were sure someone would review it; there is already quite a review backlog.

And perhaps even going further and making Armor a natural number in the simulation component Schema?

That wouldn't hurt, but is it necessary?

Hopefully this is what you meant.

Like this?

Better?

LaTeX I at least understand without difficulty, JavaScript not really.

Commas should also be translated, everything.

But the line-endings ('\n') don't seem to be translated either?

What if there is a language that wants to have the bullet point on the right side, or what if they want to add an addional symbol after the text?

Presumably `translate('• ' + text), however, are the subHeadings here not already translated somewhere else? So wouldn't wrapping it inside mean the string would be translated twice?

What do we do against the duplication?

var item = sprintf(translate('• '));? I don't know for sure, just a guess.

translate

So you mean the bullets ought to be translated?

Well, I do remember a patch where someone (@Angen?) updated the loading tips, I recommended replacing the itemization hyphens with bullets, and you requested moving those from the txt files to the js code. Or did you mean a different one?
In this particular case, the important question is whether inserting bullets improves readability (compare the two screenshots).

There is no consistency for tooltips, nor does this patch aim to implement such a thing. All it does is remove the .0 from the armour values.

All armour levels in 0 A.D. are integers

Is this the truth?
If I look into the code, it looks contrary, no?

In principle I suppose they could have decimals, but in practice all values (do a grep -r Armour in the simulation/data/ and simulation/templates/ ) are multiples of 1, therefore they're all displayed with a trailing zero, which would be removed by this patch.

Did you try this? Because I just observed two (not significant, I know) PetraAI vs PetraAI-matches and they did not produce a war dog (nor a Kennel, but even when I intervened and built a Kennel no wardogs were trained).

Good question! I just ran three Britons vs Britons vs Britons games, but in none of those they built kennels, hence no war dogs.
I do recall Britons training war dogs when I tried this out some weeks ago, but that was in a A23 mod, admittedly, and I may have changed other things then as well; I can't reproduce it with this patch.

!Champion vs Champion

Or perhaps an even simpler explanation: gaia_house doesn't exist, brit_crannog does. And palisades are gaia structures shared by all civs, so they show up too.

Interesting. It seems those structures listed aren't random, though: they're just the ones defined in the specific templates (see e.g. rome_infantry_javelinist_b.xml), without the ones they inherit from their parents (esp. template_unit_infantry.xml). Perhaps it's a problem with the observer GUI or something?

Sorry, I don't understand what you mean, or what I'm supposed to say. Could you rephrase your question?
This patch improved the classes consistency of unit templates; structures are unchanged.
The colony and library templates were last touched by D1759/rP22256, but that was four months ago.

But the problems are solved now, aren't they? That's what matters.

As said, I agree, but I'm usually trying to play the devil's advocate to create a full picture. I hope you don't mind...

No, of course not, please be critical!

Reason for my hesitance: the diff title only talks about aura descriptions, while there is actually a modif-change (yes also one class change). This *could* make it hard to track down possibly.

Well, I only included it here because of your earlier remark, but I could exclude it again, if you think that's better. I don't mind either way, it could be done in a minute.

Is there something wrong with Vulcan today? Why does it simultaneously succeed and fail?

So there *is* objection and I will revert to the desired behaviour.

It doesn't really matter how you call it internally in the code, as long as it is done consistently. However, for user-facing text strings it's best to be precise. (I actually only noticed 0 A.D. does it wrong today, because of your patch; thank you.)

I don't mind where it's done, nor do I have strong objections, I just gave my opinion on the matter ;)

That's perfectly fine, and @Gallaecio specifically asked you, so you can request changes or accept, if you like.

Doesn't probably get said often, but I, for what it is worth, definitely very much like the cleanup/standardisation you do!

Thanks. The public repository is full of inconsistencies, cleaning up things makes life easier for future additions and mods in the long run (even if it might break things occassionally).

A rate (ratio) implies something per something, e.g.

• fertility rate is the number of children born per woman
• incarceration rate is the number of prisoners per 100,000 population
• interest rate is the money paid over money borrowed

Likewise, 3 arrows per 2 seconds is a rate, but 2 seconds is a time (interval). 0 A.D.'s tooltips are actually incorrect, so perhaps you could solve that:

Yes, D2000 would have been the proper place, but I don't know if and when that one will be reviewed and committed.

Again, what is the rate here? Damage per arrow, arrows per time, damage per time, a speed, something else? If it's just <RepeatTime>, then why not call it time?

Why is the file empty? Its previous contents should have remained unchanged, see: https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/actors/props/units/shields/rome_scutum_legionnaire.xml?rev=12183

What does rate mean here?

Now includes extra non-changing modification line, as requested by @Freagarach.

art/actors/props/shields/rome_scutum_legionnaire.xml should have been moved to rome_scutum_legionary.xml but wasn't.

Catapult→StoneThrower in ;uinquereme template

List <VisibleClasses> directly after <Classes>.

Updated because of rP22809 and rP22810.

Updated because of rP22809 and rP22810.

It was actually @elexis' suggestion to remove those scenario height maps.

The requirements may be changed, would it be an idea to keep those names, when correct, just in case? Otherwise they need to search for them again, perhaps?

Why? All information is preserved in the file history. Besides, the technologies in question are not even used, they're deprecated years ago; I think it would be best to simply remove those, but that discussion belongs elsewhere (D1775).

My bad in the commit description I meant production queue not population.

As it is it means the White Horse gives +10 by default and the full +50 when researching the “Glorious Expansion” technology at a different wonder.

it's mostly to differentiate Britons from the Gauls :)

Stonehenge isn't located in France. Whilst I agree brit, gaul, mace, and pers ought to have new wonders, this patch seems to be a change from something somewhat problematic to something potentially more problematic.

The Uffington White Horse is indeed a nice addition. However, I'm not sure making it the Briton wonder is a good idea. Both Stonehenge and this predate our timeframe. Furthermore, although you disabled the <GarrisonHolder> node, it still has the same capture points, health, and costs as other wonders, which, to me at least, seems inappropiate for something that's not a massive temple structure, but merely a pattern in the ground.

no longer gives a population bonus

In that case you should remove the population auras from it.

What happened to the old temple? Is it still available? (E.g. as "shrine"?)

Probably not, mostly I don't trust this thing with moved files. Supposedly it applies well depending on the command to apply the patch.

Thanks for the clarification; I don't really understand phabricator's inner workings.

Unnecessary now yes.
But it would provide room to specify different templates for different civs.
Though if noone works on that indeed it's of limited (as in close to nil) use.
The filenames would be a bit more consistent I guess :P

To me it seems to be just file inflation. If and when someone would create civ-specific palisades, they could add a simulation template then, but right now I fail to see the benefit of adding thirteen identical files.

Thanks for reviewing and committing, I appreciate it!

I recreated the patch actually with an svn mv command and a replace of the pathname in *xml, *js, *json, then compared our results.
The raw patch downloaded from Phabricator actually doesn't include the target file of the move, so I'm glad I did it this way.
The rest of our changes are identical.

So what I did was individually svn mv the files, then update the files that used them, and finally ran arc diff --preview to upload the patch. Is there something I should have done differently?

I suppose those other/palisades_*.xml files should be moved too, but you didn't do it in this patch to make it easier to get the individual diffs committed, in which case I would agree with that.

Yeah, D1796 simplified the palisades' inheritence, this one moved the wallset template, the next one will move the palisade templates to structures/ as well. Afterwards another will move the remaining structures from other/ to structures/.

In particular someone might wonder whether it wouldn't be better to have one palsiade set per civ (possibly inheriting the common one to minimize duplication) to make it more consistent with the stone walls.

That seems rather unnecessary: all palisades of all factions are statistically identical and use the same actors, so there is no need to add palisade wallset templates for each civ. In contrast, that each civ has its own outpost template is because their actors have different garrison flags.

Is there a dedicated forum thread for that?

but that has its own problems (such as researching techs in a particular order might give a better bonus).

Yeah, Cossacks had that; it wasn't great.

Well "replace" is random, but so long as there is only one replacing tech, it should still work correctly.

Shouldn't it be chronological? So if A and B both replace the same attribute, and you research B before A, then A replaces B's replacement.

This looks great!

Can you make the inner circle not transparent, only the borders ?

Just let the gui session files use a circular png.

So it would make it possible to have e.g. uncapturable structures with capturable foundations, or vice versa?

Could you briefly explain why this would be an improvement? To me

<Armour>
  <Armour>
    <Damage>
      <Hack>5</Hack>
      <Pierce>8</Pierce>
      <Crush>10</Crush>
    </Damage>
  </Armour>
</Armour>

instead of

<Armour>
  <Hack>5</Hack>
  <Pierce>8</Pierce>
  <Crush>10</Crush>
</Armour>

seems merely to be twice as many lines for the same thing.

Resistance (or Resistances? @Nescio)

Without s; there is no need to pluralize things. Also, Americans tend to spell armour without an “u” (it doesn't really matter, it's not a user-facing string).

Updated ( this forum post reminded me).

Rebased because of rP22786.

Does this change the order in which they're applied?
Technologies are permanent, auras temporary; values used to be processed as follows:

1. all xml template stats
2. all technology multiplications
3. all technology additions
4. all aura multiplications
5. all aura additions

( https://wildfiregames.com/forum/index.php?/topic/21083-how-to-modify-0-ad/page/2/&tab=comments#comment-336823 )

Personally I don't really mind whether we use −50% or +100%, as long as it is done consistently. Perhaps a forum discussion would be helpful to find out what others think.
However, I strongly believe D1808 should be committed first; afterwards this one could change time to speed, if deemed necessary.

Basically, time is unambiguous, rate and speed can be confusing, apparently.

Let's stick with "Soldiers and Siege Engines −20% melee and ranged attack repeat time." in D1808.
I remember endless and repeated discussions on Age of Kings (which used the +25% attack speed string format) forums years ago, of people who refused to believe 1/0.8=1.25 and insisted the code should be changed to 0.75 to reflect the description. Therefore let's stay as close to the actual modifications to avoid unnecessary confusion.

@Gallaecio?

Let’s go with your original proposal, ‘Soldiers in his formation’, and revisit this topic if we find a better alternative in the future.

That's actually from the current string. I didn't change it, because I couldn't think of something better.

Same, I think we can go with your initial proposal for now (garrison type: [class] he is garrison in [change] [attributes]; garrisoned type: Garrisoned [class] [change] [attributes]), and hopefully revisit this in the future if a better proposal comes to light.

I thought we already had agreement on the garrisoned format (see D1806)?
As for the problematic garrison auras, I changed it to “When garrisoned, the Structure has ...”, staying closer to the original hero_garrison.json string. It can (and should) be improved in a later patch, I agree.