Open cm8 opened 8 months ago
If this bug exists to intentionally mimic behavior of the original 1990s game, and if people care to retain those bugs for nostalgic sake, eventually a command line option to d2tm executable makes sense as to activate 1990s conformance or not. But its more work to implement..
https://github.com/stefanhendriks/Dune-II---The-Maker/blob/c307d16b7da71e435588d79b142052ef778f8c1f/controls/mousestates/cMouseDeployState.cpp#L93-L95
After a special launched (e.g. combo Deathhand / Harkonnen), the mouse may not return from
MOUSESTATE_DEPLOY
, but rather sticks to it. This is observable in the game by the crosshair cursor colored red.Since the following logic snippet prevents identity of
m_prevState
andm_state
it presumably should not occur, becausem_prevState == MOUSESTATE_DEPLOY
whenonNotifyGameEvent
handler is called, but rather because it is called twice or more times. Not having debugged this directly, this seems to be the only explanation for the game's observable, unexpected behavior. https://github.com/stefanhendriks/Dune-II---The-Maker/blob/c307d16b7da71e435588d79b142052ef778f8c1f/controls/cGameControlsContext.cpp#L217-L221If
onNotifyGameEvent
is handled twice, or an even number of times, the current code toggles first tom_prevState
, but consequently settingm_prevState == MOUSESTATE_DEPLOY
doing this. On the second call it reverts/swaps these states again, such that the player is unable to further control game's actions (instead of waiting for another special being ready..).There may be a better or more general solution to this, so instead of a PR, please review and test wip-d2tm-fix-sticky-deploy-mousestate.patch.zipEDIT: a less invasive bugfix for the problem described is