In D1559#63082, @elexis wrote:

So we don't consider the move to InitGame.js, because preventing component construction in the ComponentManager were even better, had a similar effort and we already thoroughly tested this iteration?

I'm not familiar with the NetServer code, but the test plan worked. (I can't double-click fast enough to test D1558.)

/**
 * Disable all registering functions for this component
 * Gets called in case no AI players are present to save resources
 */
AIInterface.prototype.Disable = function()
{
	this.enabled = false;
	let nop = function(){};
	this.ChangedEntity = nop;
	this.PushEvent = nop;
	this.OnGlobalPlayerDefeated = nop;
	this.OnGlobalEntityRenamed = nop;
	this.OnGlobalTributeExchanged = nop;
	this.OnTemplateModification = nop;
	this.OnGlobalValueModification = nop;
};

This was from rP16473, however there's been new functions since then that haven't been added to the list, for example OnDiplomacyChanged and OnTerritoriesChanged. The associated data (events.DiplomacyChanged and events.TerritoriesChanged) gets changed and is serialized. So at the moment we can't add the new functions to the list (otherwise OOS), but that should be done after the re-release. Although this seems pretty hacky, so instead we should find a more general way to disable components.

(rP16473)

Okay. (I also looked for Vector2D that might have been serialized elsewhere, not comprehensive but didn't find anything.)

Tested, works. Would've saved us some time analyzing the recent oos issues, so hopefully will save us time in the future.

In D1538#62508, @elexis wrote:

(As mentioned, testing the full hash every 20 turns instead of every 100 turns makes it a bit slower by default. But it seems it's better to split these two use cases so that one can maximize performance or debugging information. Wasn't 100% sure if other documentation needs to be updated, checking again. Thanks review)

Works as expected.

Think it's good.

Without fixing people won't be able to rejoin on square maps (also territory is wrong, since it ignores hills and water, but original players can still play it), but there's only a few square maps:

random/latium.json:		"CircularMap" : false
random/corsica.json:		"CircularMap" : false
random/phoenician_levant.json:		"CircularMap" : false
random/wall_demo.json:		"CircularMap" : false,
scenarios/Arcadia.xml:  "CircularMap": false,
scenarios/Campaign Test Map.xml:  "CircularMap": false,
skirmishes/Watering Holes (4).xml:  "CircularMap": false,

So I don't know if we necessarily need to include in an A23 rerelease.

Could you upload a short video of the behavior? So people can have an idea of what's going on without having to download and compile everything themselves.

some comments

You could update the summary. I'll take a look at some point, maybe not soon. (I've been playing SC2 lately.)

I don't have a strong opinion on SelectionGroupName stuff.

In D1452#60266, @elexis wrote:

• Perhaps that roman scenario catapult should be equalized for consistency and svn blame archeologists

I'll do 26m to match that.

Lol, fixed in D1032/rP20445, then unfixed in rP20483. (I don't know why I didn't change the mace parent.)

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.
In particular, units in defensive stance won't attack any units on the route until they're close enough to their destination. That doesn't seem correct to me, but I guess we'll see how many bug reports we get.

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.

In rP21785#30453, @Stan wrote:

Did you add new tests for the changed methods or did you just fix the existing ?

Now you can lose with conquest structures even if you have structures left, or lose with conquest units even if you have units left. Non-conquest-critical ones (e.g. market + traders), but still.
Not sure about an alternative solution, other than to advise people not to choose conquest structures when playing nomad.

(Doesn't work great with twin formations, but I'd rather just get rid of those.)

Use 30m min range. It's harder for siege to cover other siege, and if they're spread out then it's easier to destroy them one by one. Still probably doesn't solve the problem but it should help.

In D1458#60069, @mimo wrote:

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.

I don't quite follow the logic. because we have a bug in An, we should keep it in An+1?
Yep, all units would chase in A22 independently of their stance because of the force=true. But that was a mistake to have it so. That's what i keep saying since the beginning of this ticket. That looks like a sterile discussion.

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.

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

I'd be okay with 30m minimum range for both bolt shooter and catapult.
Not sure if catapult needs a nerf or if I just play badly. When units are clumped up one shot can do enormous splash damage.

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.

In D1458#59806, @mimo wrote:

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

But the last version has some drawbacks, as when putting the holdPosition on the current position, you may be drifted very far from your route which is contradictory with the defensive stance (it would work as expected if we could only update the holdPosition when along the initial route, not when we have started to chase ... that may be a way to go but at first sight, it needs quite some changes not compatible imo with such a nearby release (the patch in that last version already modifies too much for my taste).

On the other side, there are use case with the previous version with minimal changes, for example when you want to send your army to an attacked spot, and don't want it to be distracted by possible enemies on the route which would make them drift to a not wanted position.

In D1458#59703, @mimo wrote:

In D1458#59700, @temple wrote:

How should standground behave?

I would say:

• agressive: attack everything on the route, chasing it
• standground: attack everything *on range* on the route, but don't chase (do not deviate from a straight line to the goal)
• defensive: attack everything around the goal, not those enemy which are far from it even if on range

That's what was done in the previous version. But defensive may be subject to different interpretation, not clear to me what most people would expect.

In D1458#59699, @mimo wrote:

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.

Doesn't work for defensive stance, since the held position is where you clicked to attack-move, so they won't respond to any units attacking them along the way (until they get close enough to the held position).

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.
(Shouldn't there be a respondStandGround case in the function ShouldAbandonChase, returning true? Whatever.)

I guess it only needs to update an aura for the player entity for the player that resigned, rather than all players, but whatever.
Other auras are still affecting the defeated player's units, except he doesn't have units anymore so it doesn't matter.

Could also fiddle with acceleration.

How much lag was there, how much did this improve things?

In D1452#59495, @elexis wrote:

In D1452#59452, @elexis wrote:

Catapults have 26min range already.

They have 12 min range, could be increased too.

Apparently I was looking at the roman one. (Sounds like a fun baseless inconsistency.)

I prefer this type of solution rather than having a training limit.

After I downloaded terra-magna I tried downloading it again and it let me. It seems there should be some indication whether you already have a mod on the list (and another if your version is out of date), and a warning if you try to download something you already have.
The "test" one becomes "factionResources" in the main list, but there's no way to tell that. I would've thought the name/version/etc. would be the same in both places.

rebase

I committed some changes in rP21714 for a23.

On the other hand, this will give players something new to complain about (if they notice it).

You forgot to include the new files with the patch.

In D1399#59002, @elexis wrote:

I believe it would also be suitable for Corsica, further advancing the simplification of the code and restoring the previous property of the map to group teams on islands.

In D1439#58690, @elexis wrote:

I've used this to increase the WallPiece size to match the obstruction. That is good for the athen fortress, but for the great carthaginian walls, the obstruction size should be reduced instead:

In D1423#58946, @elexis wrote:

(So there are 4 commits to be found for this revision proposal)

Include gaia or not, either way is fine. Be sure to check tests.

In D1445#58950, @elexis wrote:

This was the case in a22 too because although they had the block construction flag it was never checked.)

Well, you must mean the D21 Foundation.js change. (The flag is checked for each entity checked, the entity itself just isn't).

Changed Jebel Barkal numbers.

In D1399#58936, @elexis wrote:

Not sure about the slice(-1, 1), i.e. if its more common that the map gives the first and last player position. Can be changed later if its a nuisance.