Update contributors.md #1
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
IntelOrca
pushed a commit
that referenced
this pull request
Feb 10, 2016
Some Objective-C Code Cleanup
IntelOrca
pushed a commit
that referenced
this pull request
Feb 10, 2016
Added OpenRCT2#2783 files to Xcode
IntelOrca
pushed a commit
that referenced
this pull request
Mar 10, 2018
While looking at OpenRCT2#7176 (comment) I got a crash with stacktrace: OpenRCT2#0 0x7f9e81fa2e30 in object_entry_get_entry(int, unsigned long) ../src/openrct2/object/ObjectList.cpp:181 #1 0x7f9e81fa24ae in get_loaded_object_entry(unsigned long) ../src/openrct2/object/ObjectList.cpp:142 #2 0x7f9e8215d64f in S6Exporter::Export() ../src/openrct2/rct2/S6Exporter.cpp:169 #3 0x7f9e8216de71 in scenario_save(char const*, int) ../src/openrct2/rct2/S6Exporter.cpp:757 #4 0x7f9e81c932b0 in game_autosave() ../src/openrct2/Game.cpp:1590 #5 0x7f9e828625b6 in scenario_autosave_check() ../src/openrct2/scenario/Scenario.cpp:297 #6 0x7f9e81c8a958 in game_update() ../src/openrct2/Game.cpp:439 #7 0x7f9e81c6731f in OpenRCT2::Context::Update() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10f331f) #8 0x7f9e81c6674c in OpenRCT2::Context::RunVariableFrame() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10f274c) #9 0x7f9e81c6402d in OpenRCT2::Context::RunFrame() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10f002d) #10 0x7f9e81c638f4 in OpenRCT2::Context::RunGameLoop() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10ef8f4) #11 0x7f9e81c627bf in OpenRCT2::Context::Launch() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10ee7bf) #12 0x7f9e81c5b08a in OpenRCT2::Context::RunOpenRCT2(int, char const**) ../src/openrct2/Context.cpp:170 #13 0x56323695b95e in main ../src/openrct2-ui/Ui.cpp:60 Sadly I cannot reproduce it anymore
IntelOrca
force-pushed
the
develop
branch
5 times, most recently
from
b35f8c3 to
65da39f
Compare
IntelOrca
force-pushed
the
develop
branch
2 times, most recently
from
d64bbb3 to
5925d5f
Compare
IntelOrca
pushed a commit
that referenced
this pull request
Nov 28, 2021
This commit ignores keypresses when the mod key is held.
The reasoning is that an odd interaction happens between SDL applications and
tiling window managers. Tiling window managers like Xmonad and i3 usually use
the mod ("windows") key and a number to change workspaces. When changing
workspaces, however, the WMs still send the number key through instead of
"eating" it. It's not clear why, exactly, but it seems universal.
Mod+1 -> Goes to workspace #1
Mod+2 -> Goes to workspace #2
...
Mod+9 -> Goes to workspace #9
Most applications don't even see the number key being sent, so if you move to
workspace 1, Firefox won't type "1" into the browser bar, Vim won't type "1"
into your file, etc. But SDL applications, for whatever reason, DO see this
keydown. Of course, they'll handle it like a regular key press. So if you move
to workspace 1, which contains OpenRCT, it inadvertently toggles x-ray mode.
I first found this bug in another SDL game, The Powder Toy. After some
discussion with the devs, they fixed it like this, by ignoring keydown events
when the mod key is pressed, since the mod key is reserved for the window
manager anyway. It works well and should be in the next release.
The-Powder-Toy/The-Powder-Toy@c761938...93b920a
I did the same thing here.
IntelOrca
added a commit
that referenced
this pull request
Nov 28, 2021
Ignores keypresses when the mod key is held.
The reasoning is that an odd interaction happens between SDL applications and
tiling window managers. Tiling window managers like Xmonad and i3 usually use
the mod ("windows") key and a number to change workspaces. When changing
workspaces, however, the WMs still send the number key through instead of
"eating" it. It's not clear why, exactly, but it seems universal.
Mod+1 -> Goes to workspace #1
Mod+2 -> Goes to workspace #2
...
Mod+9 -> Goes to workspace #9
Most applications don't even see the number key being sent, so if you move to
workspace 1, Firefox won't type "1" into the browser bar, Vim won't type "1"
into your file, etc. But SDL applications, for whatever reason, DO see this
keydown. Of course, they'll handle it like a regular key press. So if you move
to workspace 1, which contains OpenRCT, it inadvertently toggles x-ray mode.
I first found this bug in another SDL game, The Powder Toy. After some
discussion with the devs, they fixed it like this, by ignoring keydown events
when the mod key is pressed, since the mod key is reserved for the window
manager anyway. It works well and should be in the next release.
The-Powder-Toy/The-Powder-Toy@c761938...93b920a
I did the same thing here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.