updated patch

Rewritten (and extended) patch which now also allow to set the angle of turrets from the xml. There is still a problem with walls whose in and out directions is not clear and for them, we use the direction of the move to garrison as it is most often from inside to outward.

In D1420#58215, @temple wrote:

I think it's better to set when setting the turrent parent, as you suggested earlier.

add a comment

In D1403#58155, @temple wrote:

In D1403#57928, @mimo wrote:

And while testing, there is nonetheless a problem with promotion (not linked to the patch) which is that promoted units don't face towards the same direction as the initial one (usually the opposite direction, i don't understand why). The following patch would fix it. But it is maybe better to add the angle in CCmpPosition:SetTurrentParent?

turretDirection-v1.patch1 KBDownload

From CCmpPosition.cpp: "when the entity is a turret, only m_RotY is used, and this is the rotation relative to the parent entity". I can see why that's useful, but it causes some problems here. Units sometimes do a weird twirl when they first garrison, I'm guessing related to interpolation and that change in m_RotY meaning.

I did some tests with your patch, and also could not reproduce #3539, nor seeing any bad side-effect.

Yes, agree with the patch.
Maybe changing the name of the function IsWalkingAndFighting to indicate that it is not restricted to WalkAndFight would help? but i've not found good proposition.

In rP21108#29857, @elexis wrote:

@mimo The conquest default as is is a problem, because it prevents endless games on random and skirmish maps.
So I (or you if you prefer) can either:

• remove the default Conquest and just have it log the loaded victory conditions (to inform the user that it's an endless game),
• or implement an --endless argument which would set an empty vector to victoryConditions (even if other victory conditions are passed)

In rP17154#29842, @elexis wrote:

@mimo When debugging the issue in the gif of #4473 (easily reproduce by trying to garrison a wall turret in a bad angle of the iberian starting walls), I observed that CCmpUnitMotion::TryGoingStraightToTargetEntity returns true, because it ignores the wallpiece as it has the controlgroup of the wall turret. But the unit can never reach the garrison range of the turret because the entity does collide with the wall and that is detected later.

In comment:4 of #3539 you had described an inconsistency which sounds identical to the one found here.

Maybe the shortrange pathfinder was changed to not ignore the target obstruction anymore and TryGoingStraightToTargetEntity was forgotton to be adapted for this?

(After performing the mentioned revert and the revert of rP17146, I still can't reproduce #3530 anymore.)

Patch is good (including the removal of AutoGarrison state) and works as expected in my tests.
There is nonetheless a remaining test on AutoGarrison in gui/session.js which should now be removed.

update patch

Ok now i see the problem when promoting. The visible garrison is only set when messages are processed (EntityRenamed) and thus UnitAI IsTurret is false when the cheer order is processed, and the order is thus killed by line 4851 of UnitAI.
With your approach, this works as IsGarrisoned is also only set when messages are processed. So let's go for it.

In D1403#57908, @temple wrote:

In D1403#57845, @mimo wrote:

For A23, the two changes i described above (moving one line in UnitAI and fixing the InitGarrison stuff) are all we need.

That doesn't fix the first issue, units promoted on walls.

In D1403#57820, @temple wrote:

In D1403#57819, @mimo wrote:

As far as I can tell, the point of this.IsGarrisoned is to say whether the unit is currently garrisoned inside some garrison holder. As far as I can tell, the only way for that to happen is for the unit to go through Garrison in GarrisonHolder. If that's the case, then it makes perfect sense to set this.isGarrisoned there and nowhere else.

In D1403#57815, @temple wrote:

In D1403#57814, @mimo wrote:

And i also repeat myself :) isGarrisoned in an internal UnitAI flag, it does not say that the entity is garrisoned, but that it is in the GARRISON unitAI state,

That's wrong, turrets have this.isGarrisoned = true and are in the IDLE state (or COMBAT.ATTACKING or whatever else they can do while being a turret).

And i also repeat myself :) isGarrisoned in an internal UnitAI flag, it does not say that the entity is garrisoned, but that it is in the GARRISON unitAI state, and why would GarrisonHolder have anything to say about the internal guts of UnitAI.
For your specific case, i think it is enough to move the line 3012 of UnitAI (this.isGarrisoned = true) to just after line 747.

What bothers me is that isGarrisoned is a UnitAI flag, which says that the unit is either in a GARRISON or AUTOGARRISON FSM state, which implies two things: the current order is Garrison or AutoGarrison and the holder is the target of that order. Setting it elsewhere without giving also the Garrison or the Autogarrison order may (and certainly will) result in a weird state. And if we need this (Auto)Garrison order, why not set the flag when entering this order as is done currently.

In D1406#57692, @bb wrote:

(Still thinking "moving out of range if killed" is a hack as noticed in that old revision meh)

upload the right version of the patch (taking garrisoning into account)

isGarrisoned is a UnitAI internal flag, set when entering in the INDIVIDUAL.GARRISON or INDIVIDUAL.AUTOGARRISON state. Thus that would look strange to me to have it set from inside GarrisonHolder. In the cases reported, i suspect that the units were not set in the proper UnitAI state: they should have undergone either a Garrison or an AutoGarrison order and not rely on GarrisonHolder to define their state.

In D1280#57363, @elexis wrote:

AI, AI-Difficulty, Teams, Civ do extend the playerData array and those seem to be all player commandline options.
@mimo do you recall how you reproduced an issue originally or can imagine a way how it could be achieved?
The only thing I can think of is maybe passing player 1 and player 3 but not player 2.

In D1245#57274, @Hannibal_Barca wrote:

Maybe we can just implement the ability and delay adding it into gameplay.

OK thanks for the explanations.
Maybe preventing GarrisonHolder::Garrison to MoveOutOfWorld if already out would be cleaner, but does not seems really necessary if that does not trigger warning messages.

Sorry, i thought it had worked. But i must have been confused by some non-autostart games.
and thanks for D1393

And sorry, i was focalised on gate and did not pay attention to the rest: i understand that in reality, making a hole in a wall does not depend on its length, but here, we are not only making a hole but the whole wall is destroyed. So having smaller health had some sense.
I've no strong opinion on it, so let's see if other people have some input.

I still don't get what you mean: do you really think it is crucial for gameplay that the ratio gate/wall = 5/6 and that 0.8 or even 0.85 would be a poor choice?
The only problem i see with mul is aesthetic, we prefer to have nice round max health in the gui. But even that is an argument for using mul as if the resulting health of gate happen to be a weird number when somebody changes the wall health, it will be noticed immediately. While with absolute numbers, it may take some time before somebody notice that the gate was forgotten in the change.

yes, it can be 0.83 or whatever (it's rater arbitrary as is 2500, and i don't care). But my point was with a mul, you would not have to fix it again in some months from now when somebody will decrease a bit the health of walls.

I've not tried to check if this patch is really the faulty one, but i guess so. In autostart, the "-autostart-victory="capture_the_relic" does not anymore spawn any relics.

In rP21537#29524, @Angen wrote:

Scenarios looks ok
Skirmish gets error

Same problem here, but curiously only starting docks give error. On islands map, we get

ok looks good (although i have not tested it in game)

See D1382 for a way to display all AI messages.

Although i stressed in the discussion you linked that such a change would be useful, i'm wondering if adding such a specific option (countdown timers) is really what is needed. We should take the time of thinking about what we want and how: my view was to design two ways of displaying information, one most aimed at competitive players and one for others. Countdown are certainly part of it, but there may be other displayed information which could benefit from such an option.

Thanks for the fix

Thnaks for the patch

In D1373#56564, @bb wrote:

grepping yields:
./binaries/data/mods/public/simulation/ai/petra/headquarters.js: if (this.canBuild(gameState, "structures/{civ}_temple_apedemak"))
./binaries/data/mods/public/simulation/ai/petra/headquarters.js: templateName = "structures/{civ}_temple_apedemak";

In rP21121#29256, @temple wrote:

I'm not saying it's not something to "fix", I'm explaining the situation. There's two things that should be displayed but right now we only show one of them at a time. In a22 the repair status had precedence, so if you were repairing and gathering from a field at the same time, it would show the repairer number rather than the gatherer number. In svn we also show the repair icon when there's no builders but the structure is at less than 100% health, so that's what's done with the field here.

Should the gatherers have precedence instead? Should there be a special case when no repairers to instead show the gatherers? Should we try to find a way to show both?
I'd be fine with making the gatherers have precedence, if that's an acceptable solution to you.

update patch following elexis suggestions

In rP21121#29247, @temple wrote:

In rP21121#29216, @mimo wrote:

When a field has not 100% health, we can no more see the number of gatherers, even when no builders because the test on numBuilders > 0 has been removed from line 247.

That was noticed, but you can give arguments both ways, whether the repair status or resource status should have precedence, and it was only relevant to fields (besides mods of course), so I said meh.

With that patch, the game crashes

When a field has not 100% health, we can no more see the number of gatherers, even when no builders because the test on numBuilders > 0 has been removed from line 247.

Looks good.

I don't know what tells you what is a "regularly played map" unless you mean on the lobby which is quite a heavily biased sample.
Usually, "on most maps", once you've built all the other structures that you need, you've no more room for the amun temple (except if you are already winning and control most of the territory). Specially that one temple is already allowed without the choice, so you'd have to find room for two such temples!
So the choice is about choosing amun to have a tech healer but being certainly unable to build other temples, or choosing apademak which allows more temples? i would not hesitate a second.

While i'd like to see more pair techs in the game, i'm far from convinced by this temple one. I don't think anybody will ever want to build more than one amun temple (and even zero in most cases just because there is no room for it in most of our maps). And a pseudo-choice where you always choose the same output looks rather like an annoyance to me.

Right :) i completely forgot rP19900 which was a better and more general fix. I must be losing my memory!

Patch is good.

You may want to add these two templates in ai/petra/config.js line 60. These are templates for which petra has not (yet?) any strategy to build, and are thus only built in phase_3 when enough resources (in the order given in that list).

In rP20810#29050, @elexis wrote:

Should the _unpacked postfix be removed, since Pack is disabled and we don't have a _packed file? (It's the only file having this property and apparently not referenced by any template)

In rP21423#28997, @Imarok wrote:

In rP21423#28996, @mimo wrote:

In rP21423#28994, @Imarok wrote:

I think it would be good to update the description in binaries/data/mods/public/simulation/ai/petra/data.json which currently says:
"The AI has a bonus/penalty on resource stockpiling (either gathering rate or trade gain) varying from -60% for Sandbox to +60% for Very Hard (Medium 0%). In addition, the Sandbox level does not expand nor attack."

Agree, i didn't do it because i had no good sentence.
"In addition, the Sandbox level does not expand nor attack and the easiest levels have an increased production and building time." ?

What about:
"The AI has a bonus/penalty on resource stockpiling (either gathering rate or trade gain) varying from -60% for Sandbox to +60% for Very Hard (Medium 0%) and the easiest levels have a slower production and building rate. In addition, the Sandbox level does not expand nor attack."