You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 and m_state it presumably should not occur, because m_prevState == MOUSESTATE_DEPLOY when onNotifyGameEvent 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.
// Remember previous state as long as it is not the PLACE state, since we can't go back to that state
if (m_state != eMouseState::MOUSESTATE_PLACE) {
m_prevState = m_state;
If onNotifyGameEvent is handled twice, or an even number of times, the current code toggles first to m_prevState, but consequently setting m_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..).
EDIT: a less invasive bugfix for the problem described is
diff --git a/controls/cGameControlsContext.cpp b/controls/cGameControlsContext.cpp
index 365fcfcf..49fdf4ea 100644
--- a/controls/cGameControlsContext.cpp+++ b/controls/cGameControlsContext.cpp@@ -229,8 +229,8 @@ void cGameControlsContext::onNotifyKeyboardEvent(const cKeyboardEvent &event) {
void cGameControlsContext::setMouseState(eMouseState newState) {
if (newState != m_state) {
- // Remember previous state as long as it is not the PLACE state, since we can't go back to that state- if (m_state != eMouseState::MOUSESTATE_PLACE) {+ // Remember previous state as long as it is not the PLACE or DEPLOY state+ if (m_state != eMouseState::MOUSESTATE_PLACE && m_state != eMouseState::MOUSESTATE_DEPLOY) {
m_prevState = m_state;
if (newState == eMouseState::MOUSESTATE_REPAIR) {
m_prevStateBeforeRepair = m_state;
The text was updated successfully, but these errors were encountered:
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..
Dune-II---The-Maker/controls/mousestates/cMouseDeployState.cpp
Lines 93 to 95 in c307d16
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.Dune-II---The-Maker/controls/cGameControlsContext.cpp
Lines 217 to 221 in c307d16
If
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
The text was updated successfully, but these errors were encountered: