[PATCH] Team Bonuses (from design doc)

[Stan]

Since r18115, some civ have team bonuses thanks to fatherbushido, it would be nice that all civs may benefit from it.

Some ideas can be found in design docs (not all can/could/must/should be implemented as that docs are a bit outdated):

​http://trac.wildfiregames.com/wiki/Civ%3A_Athenians#TEAMBONUS: ​http://trac.wildfiregames.com/wiki/Civ%3A_Britons#TEAMBONUS: ​http://trac.wildfiregames.com/wiki/Civ%3A_Carthaginians#TEAMBONUS: ​http://trac.wildfiregames.com/wiki/Civ%3A_Gauls#TEAMBONUS: ​http://trac.wildfiregames.com/wiki/Civ%3A_Iberians#TEAMBONUS ​http://trac.wildfiregames.com/wiki/Civ%3A_Macedonians#TEAMBONUS: ​http://trac.wildfiregames.com/wiki/Civ%3A_Mauryans#TEAMBONUS: ​http://trac.wildfiregames.com/wiki/Civ%3A_Persians#TEAMBONUS ​http://trac.wildfiregames.com/wiki/Civ%3A_Ptolemies#TEAMBONUS: ​http://trac.wildfiregames.com/wiki/Civ%3A_Romans_Republican#TEAMBONUS ​http://trac.wildfiregames.com/wiki/Civ%3A_Seleucids#TEAMBONUS: ​http://trac.wildfiregames.com/wiki/Civ%3A_Spartans#TEAMBONUS:

[mimo]

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.

[mimo]

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.

[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: ​http://pastebin.com/9460Khhn

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

[fatherbushido]

I try to make it clean in my head.

Problems:

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

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

Solutions:

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

[javiergodas]

I'm trying to do Socii bonus now