All pointers held by bonus itself are now const.
To support OppositeSideLimiter (the only stateful limiter) bonuses now
hold their player owner instead.
No changes in functionality or mods
Should no longer result in false positives. True positives when entire
list is being replaced (1.6-style) or if same item is modified should
still be reported
- Added missing docs on addInfo of some bonuses
- Unified naming in docs to match json keys
- Removed addInfo from bonuses that don't actually support it
- Added loading of addInfo to bonuses that support it
- Added bonus type MULTIHEX_UNIT_ATTACK - configurable version of Dragon
Breath.
- Added bonus type MULTIHEX_ENEMY_ATTACK - configurable version of
Cerberi multi-headed attack that only hits enemies
- Added bonus type MULTIHEX_ANIMATION - optional bonus that does not
affects gameplay, but allows to define in which cases game should use
alternative attack animation.
- All existing multi-hex attack bonuses other than ATTACKS_ALL_ADJACENT
are presumable deprecated, but will be supported for now.
- It is now possible to precisely configure which hexes are targeted by
MULTIHEX_XXX bonuses. See docs for details.
- Unified logic of all multi-hex attacks, all existing bonuses are now
implemented as specific case of MULTIHEX_XXX bonus
- Added tests to cover Cerberi attack logic, and fixed incorrect edge
case of Dragon Breath
- CClient now inherits directly from CPrivilegedInfoCallback, like
IGameCallback did before. However CClient no longer needs dummy
implementation of IGameEventCallback
- CGObjectInstance hierarchy now uses CPrivilegedInfoCallback for
callback. Actual events can only be emitted in calls that receive
IGameEventCallback pointer, e.g. heroVisit
- CGameHandler now inherits directly from both CPrivilegedInfoCallback
and IGameEventCallback as it did before via IGameCallback
- CStackInstance::count is now private with accessor methods
- CStackInstance::experience renamed to totalExperience and now stores
total stack experience (multiplied by stack size) to reduce rounding
errors
- CStackInstance::totalExperience is now private with accessors methods
- stack experience is now automatically reallocated on stack management
- Removed buggy BulkSmartRebalanceStacks pack, that mostly duplicates
BulkRebalanceStacks
- Renamed BulkSmartSplitStack to BulkSplitAndRebalanceStack to drop
unclear "smart" in name
- Reworked split-and-rebalance logic to correctly reallocate stack
experience
- files now generally contain only 1 class (except for tightly coupled
classes)
- files are now located in lib/entities/artifact directory
- removed excessive includes
No changes to functionality
Fixes Adela specialty that was apparently broken back in #1518 and
replaced with logic that was clearly not tested - it was neither
functional, nor it was following H3 behavior.
- `HAS_ANOTHER_BONUS_LIMITER` now accepts `null` in place of bonus type,
for cases when limiting is needed by bonus source or bonus subtype. This
allows Adela Bless specialty to always work, irregardless of which
bonuses are provided by Bless.
- Implemented `DIVIDE_STACK_LEVEL` updater that functions same as
`TIMES_STACK_LEVEL`, but it divides bonus value, instead of multiplying
it (to make Adela specialty weaker for high-tier units, as in H3)
- Implemented `TIMES_HERO_LEVEL_DIVIDE_STACK_LEVEL` updater that
combines two existing updaters, to implement `val * heroLevel /
unitLevel` formula needed for Adela specialty
- Removed deprecated `ARMY_MOVEMENT` updater. Its functionality has
already been removed in 1.6.X releases, and it was remaining only as a
placeholder
- Updated modding documentation to account for these changes & to remove
some TODO's
Fixed regression from #777 that could led to either duplicated bonuses
or to multiple application of updaters. It introduced double-recursion -
node parents were gathered recursively, and then bonuses were also
collected recursively within each parent. This created situation where
updater could be applied different number of times. For example, hero
bonus that is propagated to unit in combat could be selected directly,
or via hero->combat unit chain, or via hero->garrison unit->combat unit
chains, leading to different calls to updaters if updater handles
garrison unit node type
It is now possible for mods to modify json lists precisely, without full
replacement. Supported options:
- `append`: appends a single item to end of list
- `appendItems`: appends multiple items to end of list
- `insert@NUM`: inserts a single item *before* item NUM (item counting
is 0-based)
- `modify@NUM`: allows editing of a single item NUM (item counting is 0-
based)
Example - addition of a new item into town hall slots:
```json
"hallSlots":
{
"modify@4" : {
"append" : [ "dwellingLvl7B", "dwellingUpLvl7B" ]
}
},
```
This would modify 4th element (last row) by appending new entry to the
end of last row
```json
{
"modify@4" : {
"insert@1" : [ "dwellingLvl5B", "dwellingUpLvl5B" ]
}
},
```
This would add new slot not in the end of last row, but before 1st item
(between 5th and 6th dwellings)
This should fix rather common problem with mods, where two unrelated mods
accidentally use same file name for a config file, leading to very unclear
conflict since this result in a file override.
Now all config files referenced in mod.json are loaded specifically from
filesystem of mod that referenced it. In other words, it is no longer
possible for one mod to override config from another mod.
As a side effect, this allows mods to use shorter directory layout, e.g.
`config/modName/xxx.json` can now be safely replaced with `config/
xxx.json` without fear of broken mod if there is another mod with same
path to config. Similarly, now all mods can use `config/translation/
language.json` scheme for translation files
Since this is no longer a problem, I've also simplified directory layout
of our built-in 'vcmi' mod, by moving all files from `config/vcmi`
directory directly to `config` directory.
- Overrides for miscellaneous configs like mainmenu.json should works as
before
- Images / animations (png's or def's) work as before (and may still
result in confict)
- Rebalance mods work as before and can modify another mod via standard
`modName:objectName` syntax
