** Behavioral change: Fix AI heroes sometimes attempting to probe
teleport exits using data from a previously processed hero, causing
nullptr dereferences.
VCAI::moveHeroToTile has special case logic for revisiting tiles. This
logic could cause teleport exits to be stored in
teleportChannelProbingList, without the list subsequently being
cleared. If the processing of that hero ended immediately after that,
the next hero would believe that the list is accurate for them and
attempt to teleport while not standing on a teleporter.
* The reason is,
the mine has attribute hidden=true;
when enemy unit moves, the code in BattleInfo.cpp MoveUnit() (line 817) will update the revealed to true;
then in the CGameHandler.cpp handleDamageFromObstacle() (line 4846) is checking , and the condition battleIsObstacleVisibleForSide() will return true, so the effect will not be triggerred.
Resolution:
1. Remove the "revealed=true" in moveUnit(), and in handleDamageFromObstacle, remove the "const" restrict for obstacle, and then update revealed to true;
2. After the takeDamage function, add a pack "BattleObstaclesChanged" to update the obstacle to be "revealed=true".
Scenario: In LoadGame Lobby screen, the difficulty toggle group is showing multiple choices, but actually only one valid is working.
The reason is, in the Lobby screen Initialization code will set the difficulty = 0, and each time the player changes a map in the selection, the toggle group control is not resetting the difficulty buttons to disabled state.
How fix:
Add a new method to ToggleGroup class: setSelectedOnly, which will disable all other buttons and then set the selected button.
Note:
During the game loading time, the client is loading the map, and send a NetPack to server: LobbySetMap, and send a NetPack to Interface: LobbyUpdateState.
In the LobbyUpdateState it sets the map difficulty.
Now we have unpacked WoG mod version that dont need specific data files.
As far as I can tell only texts for commanders not going through proper mod system
On Android calling `SDL_RenderSetLogicalSize` with dimensions having a different aspect ratio than the screen will cause letterboxing with blinking garbage data in that areas (instead of having black bars). This is annoying and makes the game really hard to play.
This change will make sure that on Android `SDL_RenderSetLogicalSize` will always be called with dimensions where the aspect ratio is the same as the screen to make sure there is no letterboxing.
The only problem with this is that during drawing the adventure map nothing will clear out the areas that would have been letterboxes, so there is an added explicit clear screen command for `totalRedraw()`.
The changes are only applied to Android builds in order not to affect PC builds - but some changes, especially clearing the screen could be easily added to the PC builds as well
When winning the campaign there is a lock that waits for the old server to stop before allowing to continue with restarting the server. While the lock was released on PC builds as the server runs differently on Android this was missed making campaigns always hang the app when you win.
This change adds a new native method that can be called from the Android app to signal that the server has stopped, so the client can continue with requesting a new server and showing the new campaign scenatio screen.
Note: this change alone doesn't fix the bug but it's required for a fix on vcmi-android's side. It doesn't break anything and can be merged before the vcmi-android changes
Defect:
After my previous change that enabled map layer (`CAdvMapInt`) to listen to all mouse move events via `strongInterest` bool, I noticed that there are a few scenario that start scrolling the map unexpectedly. The two that were the easiest to reproduce were using keyboard arrows to move the hero or dimissing a popup dialog.
I traced this down to unexpected mouse move event (`SDL_MouseMotionEvent`) that SDL seems to dispatch in this situation. The windowID that comes with the event in this scenario is 0 (so no window with mouse focus). I don't know why SDL dispatches this mysterious (to me) mouse move event in that case (note that there is no actual mouse movement in either repro case).
Fix:
Don't handle the mouse move event if the windowID of the mouse motion event is 0.
Notes:
Impacts scrolling of the game map. Did some play testing and didn't notice the scrolling not working when expected. The two specific cases where the map would scroll unexpectedly (move a hero with keyboard arrows or dismiss a popup dialog) no longer move the map.
In fullscreen mode, when the adventure window size does not fill the entire monitor (leaving black bars on each side), mouse movement is ignored in these areas. This results in difficulty scrolling the map in fullscreen mode, since you have to be exactly within [0,15] of the edge of the adventure window.
Fix:
Have the adventure map element, CAdvMapInt, subscribe to all mouse move events by setting the `strongInterest` bool to true. This will extend the scroll region to [min, 15], eliminating the dead mouse move space on the side of the window.
Notes:
Impacts adventure window mouse move event handling. Manually validated the scrolling the map now works without having to precisely aim for the edge of the window.
