Maybe also check that the target has not moved too far if a moving one (by less than vision range?), and otherwise switching to gather-near-position seems preferable to me.

In D1014#39870, @mimo wrote:

Maybe also check that the target has not moved too far if a moving one (by less than vision range?), and otherwise switching to gather-near-position seems preferable to me.

Probably usually not much difference, except with whales? Or if an enemy herds an elephant back to his cc. But I agree with you.

Playing with whales, if you try to gather with a fishing boat, once it swims into the shroud of darkness your boat will stop. But if instead you control-attack the whale, you'll chase him beyond the shroud of darkness!
It seems like this is a bug in general. If you attack an enemy, you'll keep chasing him as long as he keeps moving. I'll explore it...

If you attack an enemy, you'll keep chasing him as long as he keeps moving. I'll explore it...

There's definitely code in unitAI to deal with that so this is odd.

Gather near position if target is a unit (i.e., if it's an animal, if it could move).

Seems sensible, is there any way you can check for actual movability (i.e. unit motion) or is that info just not passed to the GUI there? Because mods can do weird stuff.

We have targetState, and I thought unitAI captured the idea best:

target state = ({id:217, template:"gaia/geology_metal_mediterranean_slabs", alertRaiser:null, builder:null, canGarrison:false, identity:{rank:"", classes:[], visibleClasses:[], selectionGroupName:""}, fogging:{mirage:null}, foundation:null, garrisonHolder:null, gate:null, guard:null, market:null, mirage:null, pack:null, upgrade:null, player:0, position:{x:74, y:21, z:122}, production:null, rallyPoint:null, resourceCarrying:null, rotation:{x:0, y:-2.380615234375, z:0}, trader:null, unitAI:null, visibility:"visible", armour:null, attack:null, buildingAI:null, deathDamage:null, heal:null, isBarterMarket:null, loot:null, obstruction:{controlGroup:217, controlGroup2:0}, turretParent:null, promotion:null, repairRate:null, buildRate:null, buildTime:null, resourceDropsite:null, resourceGatherRates:null, resourceSupply:{isInfinite:false, max:5000, amount:5000, type:{generic:"metal", specific:"ore"}, killBeforeGather:false, maxGatherers:24, numGatherers:0}, resourceTrickle:null, speed:null, extended:true})

target state = ({id:207, template:"gaia/fauna_chicken", alertRaiser:null, builder:null, canGarrison:true, identity:{rank:"", classes:["Unit", "Animal", "Organic", "Domestic"], visibleClasses:[], selectionGroupName:""}, fogging:null, foundation:null, garrisonHolder:null, gate:null, guard:null, market:null, mirage:null, pack:null, upgrade:null, player:0, position:{x:141.1802978515625, y:21, z:182.15350341796875}, production:null, rallyPoint:null, resourceCarrying:null, rotation:{x:0, y:-2.7263641357421875, z:0}, trader:null, unitAI:{state:"ANIMAL.FEEDING", orders:[], hasWorkOrders:false, canGuard:false, isGuarding:(void 0), canPatrol:false, possibleStances:["violent", "aggressive", "defensive", "passive", "standground"], isIdle:true}, visibility:"visible", hitpoints:5, maxHitpoints:5, needsRepair:false, needsHeal:false, canDelete:true, armour:{Hack:1, Pierce:1, Crush:15}, attack:null, buildingAI:null, deathDamage:null, heal:null, isBarterMarket:null, loot:null, obstruction:{controlGroup:207, controlGroup2:0}, turretParent:null, promotion:null, repairRate:null, buildRate:null, buildTime:null, resourceDropsite:null, resourceGatherRates:null, resourceSupply:{isInfinite:false, max:40, amount:40, type:{generic:"food", specific:"meat"}, killBeforeGather:true, maxGatherers:5, numGatherers:0}, resourceTrickle:null, speed:{walk:0.9449462890625, run:1.574920654296875}, extended:true})

I think "speed" would be better as that implies cmpUnitMotion, i.e. that the entity can actually move. Mods could add moving buildings or other moving non-unitAI things I suppose.

Yeah, speed comes from UnitMotion. Guess I gave up reading the list before getting to that one.

They're in components/GuiInterface.js -> GetEntityState if you want to find them easier.

Not sure but this might break woodcutting.
Order 24 workers to cut one tree:
Currently: As one tree can only handle 8 workers, the workers also gather on trees near to that tree.
Is this still the case with your patch?
(It might be I'm totally wrong ;)

I think you should create a test map for this with automated testing of some cases (see D441). It might even be done through just a test script, but that sounds annoying.

In D1014#40715, @Imarok wrote:

Not sure but this might break woodcutting.
Order 24 workers to cut one tree:
Currently: As one tree can only handle 8 workers, the workers also gather on trees near to that tree.
Is this still the case with your patch?
(It might be I'm totally wrong ;)

It's the same as if you selected 24 workers and ordered them all to chop the same tree, so they'll go to trees near that one instead.

In D1014#40917, @temple wrote:

In D1014#40715, @Imarok wrote:

Not sure but this might break woodcutting.
Order 24 workers to cut one tree:
Currently: As one tree can only handle 8 workers, the workers also gather on trees near to that tree.
Is this still the case with your patch?
(It might be I'm totally wrong ;)

It's the same as if you selected 24 workers and ordered them all to chop the same tree, so they'll go to trees near that one instead.

True