Some keyboard control suggestions

[Cholmondely]

I usually have to press "u" several times to deselect the current unwanted target.

Hmm. I’ve never had a problem with unselecting a target, which suggests it’s probably a combination of OXPs that are competing for your attention and auto selecting targets for you.

Put it this way: if the OXPs were working correctly and pressing “u” once was enough to deselect your current target, would it be a big leap to switch to a toggle switch, rather than having two buttons?

Probably too many targeting OXPs (Fast Target Selector, SniperLock (automatic), Military Targeting System (automatic), Telescope (automatic but disableable) & Target System Plugins). But honestly, all this is irrelevant as I play on an AppleMac!

[hiran]

Probably too many targeting OXPs (Fast Target Selector, SniperLock (automatic), Military Targeting System (automatic), Telescope (automatic but disableable) & Target System Plugins). But honestly, all this is irrelevant as I play on an AppleMac!

The last sentence says it all. We are unable to build Oolite on that platform. Unless resolved none of the improvements will have any impact.

[phkb]

With the option of changing the behaviour of "t" and "r", I've had a rethink, largely because I missed part of how these two keys work. If you already have a target, pressing "r" or "t" again clears that target so you can find a new one. So, the base game supports a use for pressing either key twice, thus having it turn off that function on the second press would be unwise.

The only way this system could work would be to only turn off the function if there was no current target set. So, the gameplay loop would be: press "t" to arm missiles; find target; press "t" to clear target; press "t" again to disarm missiles.

To my mind, this is complicating the system unnecessarily, so I'm going to call time on that update. So, never fear, Cholmondely, I won't be removing the "u" key.

Which leaves the other suggestion re: combining the sensitivity functions.

As for the issue with Mac builds, yes, this is a problem. However: (1) we can still do a Mac release (even if it's complicated and involves a single person being available with their VM to create it), and (2) I don't want to pause all development of the game while we wait and hope for a solution, even if there is one. So I'd prefer to move forward with the assumption that we will get a Mac build eventually, somehow.

[hiran]

As for the issue with Mac builds, yes, this is a problem. However: (1) we can still do a Mac release (even if it's complicated and involves a single person being available with their VM to create it), and (2) I don't want to pause all development of the game while we wait and hope for a solution, even if there is one. So I'd prefer to move forward with the assumption that we will get a Mac build eventually, somehow.

100% with you. The Mac platform cannot be a showstopper.

But Cholmondely's comment was not asking to wait.
He just pointed out the impact your changes would have to his piloting career.

[Cody]

So I'd prefer to move forward with the assumption that we will get a Mac build eventually, somehow.

Mac maintainers for this type of game are rare as hens teeth. Pioneer had the same problem for years, now it's Linux and Windows only.

As an afterthought: I don't think I've ever used the "u" key.

[hiran]

One more experience with the new keyboard configuration interface. I like the possibilities, but it somehow is still a bit quirky.
So what I tried to do was to reassign the buttons for turning the ship and setting the views to the numeric keypad. While going there I discovered something else.



Above the table showing all the configurable settings the "Current keyboard layout: Default (US)" caught my attention. I am not on a US layout. Or am I? So I checked the system settings...



No, definitely not US. Also there is no second keyboard layout configured that I could switch back and forth to. And I discovered something that would finally end the discrepancy with "which key is which": It marries up the physical keys with the characters my configured keyboard layout applies:



BTW, this application is capable of hilighting each key that I press. Even combinations, everything is nicely detected. So the hardware for sure can do the needful. But back to Oolite.

Since the display of the Default (US) display is simply wrong I moved the cursor up there and pressed Enter. In response Oolite terminated.
I started it again, and used the mouse to doubleclick that setting. In response Oolite terminated.
From Latest.log I see no reason why Oolite would terminate. Is this a bug?

Code: Select all

14:57:26.466 [LogEvents]: gui screen changed from GUI_SCREEN_STATUS to GUI_SCREEN_OPTIONS
14:57:31.079 [LogEvents]: gui screen changed from GUI_SCREEN_GAMEOPTIONS to GUI_SCREEN_KEYBOARD
14:59:38.966 [LogEvents]: gui screen changed from GUI_SCREEN_KEYBOARD to GUI_SCREEN_KEYBOARD_LAYOUT

In the logs of OoliteStarter however I find something. Here is the whole snipped from launching Oolite until it crashed:

Code: Select all

2023-08-15 14:57:15,544 WARN o.s.Oolite [Thread-6] executing [/home/hiran/GNUstep/Applications/Oolite-trunk/oolite.app/oolite-wrapper, -load, /home/hiran/oolite-saves/Jaeger3.oolite-save] in /home/hiran/GNUstep/Applications/Oolite-trunk/oolite.app
2023-08-15 14:57:15,546 WARN o.s.u.StartGamePanel [Thread-6] launched(oolite.starter.model.ProcessData@5eba707a)
2023-08-15 14:57:16,335 ERROR Oolite [Thread-8] AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
2023-08-15 14:57:17,013 ERROR Oolite [Thread-8] Cannot connect to server socket err = No such file or directory
2023-08-15 14:57:17,014 ERROR Oolite [Thread-8] Cannot connect to server request channel
2023-08-15 14:57:17,015 ERROR Oolite [Thread-8] jack server is not running or cannot be started
2023-08-15 14:57:17,016 ERROR Oolite [Thread-8] JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
2023-08-15 14:57:17,016 ERROR Oolite [Thread-8] JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
2023-08-15 14:57:17,018 ERROR Oolite [Thread-8] Cannot connect to server socket err = No such file or directory
2023-08-15 14:57:17,018 ERROR Oolite [Thread-8] Cannot connect to server request channel
2023-08-15 14:57:17,020 ERROR Oolite [Thread-8] jack server is not running or cannot be started
2023-08-15 14:57:17,020 ERROR Oolite [Thread-8] JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
2023-08-15 14:57:17,020 ERROR Oolite [Thread-8] JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
2023-08-15 14:59:39,102 ERROR Oolite [Thread-8] Segmentation fault (core dumped)
2023-08-15 14:59:39,102 INFO Oolite [Thread-7] 
2023-08-15 14:59:39,102 INFO Oolite [Thread-7] Erk. It looks like Oolite-trunk died with an error. When making an error
2023-08-15 14:59:39,102 INFO Oolite [Thread-7] report, please copy + paste the log above into the report.
2023-08-15 14:59:39,103 INFO Oolite [Thread-7] 
2023-08-15 14:59:39,103 WARN o.s.u.StartGamePanel [Thread-6] terminated()
2023-08-15 14:59:39,185 ERROR o.s.u.StartGamePanel [Thread-6] Could not run game
oolite.starter.ProcessRunException: Oolite terminated with code 139
	at oolite.starter.Oolite.run(Oolite.java:547) ~[OoliteStarter-0.1-SNAPSHOT.jar:0.1-SNAPSHOT]
	at oolite.starter.Oolite.run(Oolite.java:421) ~[OoliteStarter-0.1-SNAPSHOT.jar:0.1-SNAPSHOT]
	at oolite.starter.ui.StartGamePanel$6.run(StartGamePanel.java:304) [OoliteStarter-0.1-SNAPSHOT.jar:0.1-SNAPSHOT]

[phkb]

Since the display of the Default (US) display is simply wrong I moved the cursor up there and pressed Enter. In response Oolite terminated.
I started it again, and used the mouse to doubleclick that setting. In response Oolite terminated.
From Latest.log I see no reason why Oolite would terminate. Is this a bug?

Yes, it was a bug. It was fixed in https://github.com/OoliteProject/oolite/pull/440

[hiran]

Since the display of the Default (US) display is simply wrong I moved the cursor up there and pressed Enter. In response Oolite terminated.
I started it again, and used the mouse to doubleclick that setting. In response Oolite terminated.
From Latest.log I see no reason why Oolite would terminate. Is this a bug?

Yes, it was a bug. It was fixed in https://github.com/OoliteProject/oolite/pull/440

Confirmed. In the current latest this phenomen does not happen. I was now able to select the German keyboard. Not sure what/how much it changes though.

[phkb]

Since the display of the Default (US) display is simply wrong I moved the cursor up there and pressed Enter. In response Oolite terminated.
I started it again, and used the mouse to doubleclick that setting. In response Oolite terminated.
From Latest.log I see no reason why Oolite would terminate. Is this a bug?

Yes, it was a bug. It was fixed in https://github.com/OoliteProject/oolite/pull/440

Confirmed. In the current latest this phenomen does not happen. I was now able to select the German keyboard. Not sure what/how much it changes though.

Essentially I made sure that what you have to press on a German keyboard matches the standard keyboard configuration. So, for example, for things like \ and |, I made sure the right combination of keys are set for each one. Hope that makes sense.