Opened 7 years ago
Closed 7 years ago
#4425 closed defect (fixed)
Rallypoint on huntable animals broken
Reported by: | elexis | Owned by: | Imarok |
---|---|---|---|
Priority: | Must Have | Milestone: | Alpha 22 |
Component: | UI & Simulation | Keywords: | |
Cc: | Patch: |
Description
When setting a rallypoint on a huntable animal like chicken or deer, the trained unit moves to the animal and heads back to the building instead of killing and gathering.
Bug reported by Hannibal Barca.
Change History (5)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
I've just did it this way, because leper said in #1807:
Thanks for the patch. The special handling for templates is probably the best solution apart from rewriting EntityGroups (which would cause other problems) or rewriting a lot of the gui code.
A possible improvement would be to allow the ally to unload all of his units at once (by using unload-all-own and rewriting that to take the player as an argument).
follow-up: 4 comment:3 by , 7 years ago
Indeed that ret.template = "p" + ret.player + "&" + ret.template
part in the GUI interface seems bad, we could perhaps just add a new property owner
or ownership
to the extended entity state and take it from there.
comment:4 by , 7 years ago
Replying to elexis:
Indeed that
ret.template = "p" + ret.player + "&" + ret.template
part in the GUI interface seems bad, we could perhaps just add a new propertyowner
orownership
to the extended entity state and take it from there.
That won't be enough, as the whole EntityGroups, etc. has to be aware, we are sorting by player. So the clean fix would be to let EntityGroups not only sort by templates, but also by player.
yep, broken by r18979 as the trick to add the player number inside the template is used for all units with UnitAI (so also for animals) while it was previously only used for garrisoned units. There may be other side effects with pieces of code relying on templates. We should implement a less hacky way to separate templates according to owner.