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
I have noticed two sets of issues in sdl12-compat (also in 1.2.68) that didn't exist and go away if I roll back to SDL 1.2.15.
I've reported these in https://openxcom.org/forum/index.php?topic=12069.0. (Previous other OpenXcom issues were handled in #215). But I suppose these are issues in sdl12-compat, because the vanilla SDL works (unless someone can show that the OpenXcom/OXCE code in question is actually wrong).
when you press down CTRL, ALT or some other key, if this should result in a change in GUI, no change is shown (but potentially the behaviour is silently changed). There multiple cases where this occurs.
The easiest to reproduce is when your craft arrives at destination and you press CTRL on the "start mission yes/no screen", the GUI button for "NO" no longer changes to "PATROL". However, if you still press the unchanged button while holding down CTRL, the craft will start patrolling, not return to the base. So this is a "visual problem", not affecting functionality. (Other button-pressing issues are more severe for playability.)
So my uneducated guess is that for some reason either the "isCtrlPressed" condition does not work or "setText" does not work when it should change the already drawn text outputs based on holding down a key.
At least with one major mod, there are lot of really weird beeps and extra noises in battlescape music tracks and SFX. I didn't see this when quickly testing in vanilla.
I couldn't figure out how to test these further, so I rolled back to using SDL 1.2.15. But I suppose I could possibly try again if there is interest in working on these to get these fixed.
The text was updated successfully, but these errors were encountered:
I have noticed two sets of issues in sdl12-compat (also in 1.2.68) that didn't exist and go away if I roll back to SDL 1.2.15.
I've reported these in https://openxcom.org/forum/index.php?topic=12069.0. (Previous other OpenXcom issues were handled in #215). But I suppose these are issues in sdl12-compat, because the vanilla SDL works (unless someone can show that the OpenXcom/OXCE code in question is actually wrong).
The easiest to reproduce is when your craft arrives at destination and you press CTRL on the "start mission yes/no screen", the GUI button for "NO" no longer changes to "PATROL". However, if you still press the unchanged button while holding down CTRL, the craft will start patrolling, not return to the base. So this is a "visual problem", not affecting functionality. (Other button-pressing issues are more severe for playability.)
The OXCE code for this particular thing is in
https://github.com/MeridianOXC/OpenXcom/blob/oxce-plus/src/Geoscape/ConfirmLandingState.cpp#L97:
And the handler is at https://github.com/MeridianOXC/OpenXcom/blob/oxce-plus/src/Geoscape/ConfirmLandingState.h#L36
and https://github.com/MeridianOXC/OpenXcom/blob/oxce-plus/src/Geoscape/ConfirmLandingState.cpp#L325 as follows:
void ConfirmLandingState::togglePatrolButton(Action *)
{
if (_game->isCtrlPressed())
{
_btnNo->setText(tr("STR_PATROL"));
}
else
{
_btnNo->setText(tr("STR_NO"));
}
}
So my uneducated guess is that for some reason either the "isCtrlPressed" condition does not work or "setText" does not work when it should change the already drawn text outputs based on holding down a key.
If the issue were to be found in isCtrlPressed(), it would probably be somewhere around https://github.com/MeridianOXC/OpenXcom/blob/oxce-plus/src/Engine/Game.cpp#L712
bool Game::isCtrlPressed(bool considerTouchButtons) const
{
if (considerTouchButtons && _ctrl)
{
return true;
}
return (SDL_GetModState() & KMOD_CTRL) != 0;
}
I couldn't figure out how to test these further, so I rolled back to using SDL 1.2.15. But I suppose I could possibly try again if there is interest in working on these to get these fixed.
The text was updated successfully, but these errors were encountered: