Change History (11)

comment:1 Changed 3 years ago by stanislas69

Description: modified (diff)

comment:2 Changed 3 years ago by elexis

Keywords: simple added

comment:3 Changed 3 years ago by mimo

Keywords: simple removed

Auras are based on a rangeManager query to find the entities on range, but the range manager only works for entities with a position and inWorld. So currently most team bonuses (using global auras) are broken as the player entity has no position: auras are correctly applied to templates, but not to entities. A possible solution would be that CCmpRangeManager still performs the query (using 0-0 as position) for such special entities.

There are also some side-effects for this: for example hero auras are not applied to entities created while the hero is garrisoned, it is only when we ungarrison it that the aura is applied. Here, when querying a garrisoned entity, we could take (recursively as a garrisonHolder may be garrisoned) the position of its garrisonHolder.

Finally, once team bonuses works, they should be disabled when the allied at the root of the aura is defeated.

comment:4 Changed 3 years ago by mimo

Keywords: rfc patch added
Milestone: BacklogAlpha 21
Summary: Design Docs : Team Bonuses[PATCH] Team Bonuses (from design doc)

Some global auras, affecting only the templates and potentially the player entities, make a useless rangeQuery (as player entities have no position). Here is a patch to avoid this rangeQuery. As an example of such use, the patch also implements the ptol team bonus. (As the ResourceTrickle? component was used, it also contains some optimization for it, recomputing the rates only when modified and not on each iteration). Finally, there is a TODO in the patch which is here for discussion, about defining a new "player" type for such auras, instead of using the "global" one.

Changed 3 years ago by mimo

Attachment: ptol-teambonus.patch added

comment:5 Changed 3 years ago by sanderd17

Something like this would get rid of the range query, though it still needs extra code for when the receiver is the player entity directly:

It's also completely untested and most likely broken. It serves mostly as an example to start from (f.e. it minimises the global message listeners by letting the AuraManager? listen to it (most aura entities don't have a global aura so wouldn't need the listener anyway)).

Last edited 3 years ago by sanderd17 (previous) (diff)

comment:6 Changed 3 years ago by fatherbushido

Description: modified (diff)

comment:7 Changed 3 years ago by fatherbushido

I try to make it clean in my head.


  1. when the source is the Player entity : entities are not affected (range query fails as the source has no position)
  2. when the source is garrisoned, the aura is not immediately applied : range query fails as the source has no position
  3. when the target is a Player entity : there range query is useless
  4. when the aura is global, there are useless range queries
  5. team bonuses aren't remove when player is defeated

I can perhaps add

  1. The source of an aura is not affected by a range aura (but perhaps it is expected like that).


  1. possible solution suggested in comment1. Perhaps we can use cmpRangeManager.GetEntitiesByPlayer?() instead ? (and a special (from)player aura type in this case ?)
  2. same
  3. adressed in mimo's patch. Indeed in this case a (to)player aura type can be good
  4. adressed in sanderd17 's patch
  5. we must listen to PlayerDefeated? message in aura component and...
Last edited 3 years ago by fatherbushido (previous) (diff)

comment:8 Changed 3 years ago by fatherbushido

Milestone: Alpha 21Alpha 22

comment:9 Changed 3 years ago by javiergodas

I'm trying to do Socii bonus now

comment:10 Changed 3 years ago by fatherbushido

Description: modified (diff)
Note: See TracTickets for help on using tickets.