Just a hint: what was the only stable in game at that time? was it a barracks?
Then if people had commited (without any review) inconsistent stable templates, i would not have expected petra to create some hacky code to support them in the future, but to first make all templates consistent. It seems that this took 1 year.

Could you explain what is the point of raising a concern on a commit when the problem is created by a posterior commit? maybe just give some feeling of activity?

I meant that from what i witnessed, i would never have expected such a ban.

In D1754#76534, @elexis wrote:

mimo if I call your work crap without having seen it or knowning what it is about and you wouldn't like that, does that mean you just can't stand my criticism?

In D1754#76533, @Itms wrote:

I'm sorry if I hurt someone's feelings while trying to cheer up and encourage people who are still at WFG. I'll try to be more vigilant about how I appear, but I really mean what I said and I can't be too hypocritical about how I truly feel. Apparently you can't restrain yourself from insulting people either, so you must understand me.

In D1754#76519, @Itms wrote:

This vague allegation should not block us from progressing. Unhelpful and rude remarks about our work were the reason he was banned in the first place. Saying there is a defect and refusing to point it out is childish at best. The assumption that we would have to re-re-release A23 was (is?) a similar kind of bullcrap, and thankfully we didn't wait for them to reveal The Secret (tm) to release.

The button looks fine to me, but i'd rather put it after the "you've been attacked" message, possibly with some help text, for example "click to go there" as new players may not guess what is its use. Other alternatives would be to add an explicit icon (but looks really small) or at the very least a tooltip to that button.

tested rP21810 and works as expected

Yep, i've just tested the patch and it works as expected. I don't have in mind any other template which could have that problems.
By the way, i've seen that problem (and used also for checking the patch) on wild lake random map. There are so much fishes on that map that it's ideal for testing that patch, but i don't think that is what was wanted. Maybe something to fix in that map for a24?

Same problem still happen for dock foundations when placed above fishes.

I did some basic tests, and works as expected. Thanks.

Thanks for spliting the uncontroversial part.

I've noticed that all 3 kush walls also have a wrong SelectionGroupName (either ptol or mace). That could be added to that patch.
Otherwise, I've no real preference on elexis' question,

In rP21784#30464, @temple wrote:

In rP21784#30460, @mimo wrote:

This commit make things worse for packing units in attack-move (as explained several times in D1458, if they are now in standground stance, it is for a reason).

It doesn't make them worse because in a22 every unit (except packable units) in standground would chase in attack-move, and now packable units will also chase (the point of your original commit was to remove the inconsistencies with packable units) rather than being bugged.

But as it seems that now, the new rule is to commit patches without acceptation,

You said

I agree with temple proposition in rP21630 (switching the order of the standground check and the pack)

and

That said, having the canPack at the place you mention seems to be useful to avoid units to be stuck.

which sounded to me like you agreed with the changes I made.
I didn't say "Reviewed by mimo" because you didn't official accept them, but still.

In rP21786#30465, @temple wrote:

This doesn't really have much to do about packing or rP21630, it's changing the attack-move sub-orders from forced to not forced so units won't chase targets anymore.

This commit make things worse for packing units in attack-move (as explained several times in D1458, if they are now in standground stance, it is for a reason). But as it seems that now, the new rule is to commit patches without acceptation, i've done the same and committed my own fix in rP21786.

In D1458#60068, @temple wrote:

In D1458#60001, @mimo wrote:

In D1458#59987, @temple wrote:

This seems to solve the chase problem for siege? (And attack-move changes can be saved for a24.)

Not really, that would make the siege to chase, but that's an unwanted behavior as its default stance is standground. When attack-move with catapults, you don't want them to chase any nearby units (which are much faster than them) but rather bomb anything on their route. Once again, the root of the problem is that the Attack suborder of a move-attack is considered as force=true while it should be force=false so to behave as expected from its stance.

That said, having the canPack at the place you mention seems to be useful to avoid units to be stuck.

In a22 non-packable standground units do chase, so I think we should keep force=true for a23 anyway.

In D1458#59987, @temple wrote:

This seems to solve the chase problem for siege? (And attack-move changes can be saved for a24.)

In D1458#59893, @temple wrote:

In D1458#59879, @mimo wrote:

In D1458#59831, @temple wrote:

Then you (or somebody else) has to accept the patch, as simple as that. I also don't have time nor interest to discuss further the way stances should work in attack-move, so if anybody is interested, he should commandeer this patch, otherwise i'm fine with the first version and will commit it when accepted.

I accept moving the pack lines, I don't accept changing the attack-move behavior.

In D1458#59831, @temple wrote:

The packing bug should be fixed in any case. (I'm not interested in taking this over or making decisions on how stances should behave.)

Before that patch, all stances would be nearly equivalent in attack-move as all orders were treated as forced, which has precedence on stance.
Now, we have quite different behaviors and choosing different stances has some consequences, so that's fine with me and i cannot say better than "commandeer the patch and commit the version you like more" (i don't really mind, and you can consider it as accepted by me as I wrote it).

In D1458#59700, @temple wrote:

In D1458#59699, @mimo wrote:

How should standground behave?

In fact, on second thought, i'd prefer the previous version: when in defense stance with attack-move, it means that you want to defend something around the position you give and it makes sense to start the real attack-move only when you are around that position, otherwise you'd better choose the aggressive stance.

update patch

Good catch, but that's rather a walk-and-fight definition: if in defensive mode, it may be wanted that the attack-move only starts when around the target (otherwise why choosing that defensive stance?).
But i'm also aware that this is not necessary the expected behaviour. If the expected behaviour is a "standard" attack-move, the fix is to set the current position as heldPosition when searching for new targets (as done in the new version of the patch).

In D1457#59651, @temple wrote:

Forced orders never abandon chase, so it works for the first attack. Doesn't work for later attacks when they have to chase since the held position is still back at home, but that happens for regular attacks too.

In D1294#59071, @bb wrote:

New code looks much simpler and less error prone

the elexis comment seems simple enough => accept

In D1433#58973, @elexis wrote:

To me the objective was to remove the duplication, which is not easily achievable when we want to implement a CLI help and keep a readme.txt.

In D1433#58958, @elexis wrote:

In D1433#58512, @mimo wrote:

also developper :) usually i use that doc when i try to modify the Gamesetup.cpp file, it is much simpler to have it there than having to go through the directory hierarchy to find the readme.txt

Since the exact filepath is printed there, one doesn't have to type anything besides the fileviewer program, for instance gedit ctrl+v at worst (when using an IDE like eclipse it may only be ctrl+R + ctrl+V).
If the effort argument is true, then we could copy many things to many places leading to the duplication pattern problems.
For instance the other commandline options explained in readme.txt could be copied to the other files where the commandline options are implemented, resulting in even more files to keep in sync.

When exactly is the less-effort use case met?
When wanting to use the binary without reading or changing Gamesetup.cpp, the effort to open the readme and Gamesetup.cpp file are identical.
When wanting to extend Gamesetup.cpp, one has to change readme.txt too.
When wanting to modify but not extend Gamesetup.cpp, one has the name of the broken property already given.
I can abandon this without being convinced by the presented arguments however.

Thanks for the review.

Thanks for the review.

In D1426#58814, @temple wrote:

In D1426#58809, @mimo wrote:

I'm fine with both features: auras do not affect gaia (does not have use on gameplay, so if it can save performance it's a good change)

For example that sele hero that affects enemy building health, with the patch it won't apply to gaia buildings.

In D1426#58808, @temple wrote:

We should decide something on gaia.
I think at the moment gaia isn't affected by technology? At least the advanced/elite bonuses.
Currently auras affect gaia but this patch would change it so that they wouldn't affect gaia.
However, gaia entities can still have auras that affect players.

Faster to reproduce (at turn about 5000) with
pyrogenesis -autostart=random/mainland -autostart-seed=5137 -autostart-aiseed=4193 -autostart-players=4 -autostart-ai=1:petra -autostart-civ=1:brit -autostart-ai=2:petra -autostart-civ=2:mace -autostart-ai=3:petra -autostart-civ=3:iber -autostart-ai=4:petra -autostart-civ=4:maur -autostart-nonvisual -autostart-victory=regicide

In D1434#58513, @temple wrote:

In D1434#58509, @mimo wrote:

And why not setting the relative health (as is done in Promotion or Transform)? Having foundations which are usable without full health may be useful for mods even if we don't use it in vanilla game.

? Foundations are completed (turned into new buildings) when their relative health (i.e. build progress) is 1, but new buildings are initialized at max hitpoints.

In D1433#58491, @elexis wrote:

I agree that having a command line option to show all command line options would be great.
But that use case for the user, not for the developer.
Which use case does the Gamesetup.cpp contents serve for the reader of this file that can just as well read the same thing in readme.txt?

And why not setting the relative health (as is done in Promotion or Transform)? Having foundations which are usable without full health may be useful for mods even if we don't use it in vanilla game.

I agree with such a duplication removal, but i don't find the "RTFM" quite handy. I'd rather have an option "autostart -help" which would display it on the console.

SetTurretStance uses SwitchToStance from UnitAI which has an early return for outOfWorld units, so the stance was not correctly set for such units. This is fixed with rP21656.
But it may be worth fixing directly UnitAI as there are no real reason to not switch stance if not InWorld.

updated patch

In D1429#58364, @temple wrote:

Tests okay. I think only the gather rate multiplier and cheat time multiplier are relevant with respect to resource gatherer, but I guess it can't hurt to do time multiplier too.

In D1420#58313, @temple wrote:

In D1420#58307, @mimo wrote:

In D1420#58272, @temple wrote:

I think it's a bug that setting the turret position changes the angle silently (by changing the definition of m_RotY but not changing the value), so we should include that fix rather than doing some subtractions to account for it. (Of course then we'll have to do an addition in a different spot, but still.)

Well, i would not call it a bug per se, but i fully agree that having the meaning of the rotation angle changing according to turret or not is really bugprone and should be changed. But that's outside the scope of that patch, and is more a post A23 feature than a bugfix.

I'm saying that it's expected that GetRotation().y before SetTurretParent is the same as GetRotation().y after. Setting a turret parent shouldn't turn the unit! Since we're here, we should fix that (it doesn't require any changes to m_RotY, just the two lines getting the rotation and setting it).

update

See D1429

In D1420#58272, @temple wrote:

I think it's a bug that setting the turret position changes the angle silently (by changing the definition of m_RotY but not changing the value), so we should include that fix rather than doing some subtractions to account for it. (Of course then we'll have to do an addition in a different spot, but still.)