Initially wanter to name main class differently and back then getCost make sense.
Then renamed class to CPathfinderHelper, but forgot to rename function back.
Now pathfinder take into account different bonuses for different tuns. So if you only have FLYING_MOVEMENT bonus from Fly spell for one turn then pathfinder will only let you use air layer within one turn only.
That work for cost calculations too. Let's say you have two bonuses:
- FLYING_MOVEMENT with 20% penalty for next 2 turns
- FLYING_MOVEMENT with 40% penalty for 5 turns
Now pathfinder using correct penalty for each turn so movements in air layer going to be more expensive on 3-5 turns.
Now when oneTurnSpecialLayersLimit is enabled hero won't be able to stop on blocked or water tiles between turns.
It's default H3 mechanics so it's enabled by default.
CTerrainRect::showPath behaviour changed so it's will only add cross path graphics on embark/disembark and path ending.
We want continuous paths for flying and water walking even when land<-> water transition occur.
No action going to simplify isMovementAfterDestPossible and should be as well useful for cost calculations.
It's can be also used by client interface to show appropriate cursors and path.
There is two exceptions:
- Hero start movement from guarded tile.
- Hero that embarking into boat that standing on guarded tile.
In other cases future movement is impossible.
It's should be possible to go into air layer from visitable object (but opposite isn't allowed).
And when walking on water player can't really interact with any object at all so future movement always possible.
This way we can avoid layer checks when calculating paths by ignoring unitialized tiles entirely.
Also at this point pathfinder and movement actually works for everything except flying.
This still need investigation, but likely most of external code shouldn't be aware of layers in order to work properly because only LAND and SAIL can be targeted and single tile can't have both of these layers.
Suggested by @DjWarmonger as better alternative from performance standpoint while struct still more organized than bunch of variables.
Other reason of change it's that in future we may need non-boolean options, e.g for patrol movement and some new pathfinder usages.
This is how that works in H3. And on server side it's checked already anyway.
Though it's must be possible to teleport from ally Inferno to your own if both have Castle Gate.
Map graph initialization should be there as well because it's needed for path checking.
This change wouldn't affect anything since currently CPathfinder object created from scratch every time.
There no need in dedicated function for embark / disembark and other conditions belong there perfectly.
This function is going to check what movements are plain impossible so we don't have to bother check their cost.
After 8cad23956c there was several issues remaining:
* Last creature would remain even for town garrisons.
* Impossibility to move last stack even within same garrison.
* Impossibility of partially merge of last stack into other hero stack.
All fixed. However last stack merge to other hero will now make split window appear instead of auto merge.
CToggleGroup. Originally when I added initialization for selectedID I didn't find out that -1 is used for "random" buttons. So as result I fixed uninitialized variable usage, but break initial button state change in RMG options because setSelected ignore state change request because it's see -1 button already marked as selected.
Before UI always highlighted all slots in both town garrisons even if there no visiting here and you can't actually set army on these slots.
Now garrison slots only highlighted if they're owned by us or our ally. If there no visiting hero in town then only suitable upper garrison slots will be highlighted.
Currently when there is computer only players set resetPlayersMap may try to change settings for more than 8 players which obviously cause crash.
Now if any of "players and computer limit" or "computer limit" is set to random we automatically set total limit to 8 players.
Sadly I'm not yet find proper way to block all buttons in CToggleGroup without make them invisible so it's still possible to press buttons for guest. Though CRandomMapTab::updateMapInfo is now disabled for guest so even if guest going to press multiple buttons it's not going to cause crash for him.
ArseniyShestakov