Oolite Bulletins

Hello All,
I thought I would share my keymap should anyone be interested.
Basically, I have split the up/down and left/right keys, in the spirit of
(but not the same as), the BBC Micro version.
The most important keys (for combat situations,defensive response) have been clustered
around the movement keys for quick navigation.
This layout is in part, due to key mapping oddities for Linux Oolite (don't ask).

Keymap Summary:-

Primary Helm Systems:-

Left = cursor left
Right = cursor down
Down = s
Up = x
Speed + = space
Speed - = c
Laser = cursor right
Missile Fire = a
Missile Lock = d
Missile Safety = w
ECM = cursor up
Energy Bomb = tab
Local Jump = j
Hyperdrive = h
Galactic Hyperdrive = g
Emergency Hyperdrive = b
Escape Pod = Escape
Target I.D. = r
Auto Pilot = q
Auto Dock = z
Scanner Zoom = v

Secondary Helm Systems

Rotate Cargo = y
Dump Cargo = t
Docking Music= u
snapshot = l

Cut and paste the text below into the 'keyconfig.plist' file REPLACING THE EXISTING KEY INFO in the file:-

<key>key_roll_left</key>
<integer>253</integer>
<key>key_roll_right</key>
<integer>254</integer>
<key>key_pitch_forward</key>
<integer>115</integer>
<key>key_pitch_back</key>
<integer>120</integer>
<key>key_increase_speed</key>
<integer>32</integer>
<key>key_inject_fuel</key>
<integer>105</integer>
<key>key_decrease_speed</key>
<integer>99</integer>
<key>key_fire_lasers</key>
<integer>252</integer>
<key>key_target_missile</key>
<integer>100</integer>
<key>key_untarget_missile</key>
<integer>119</integer>
<key>key_launch_missile</key>
<integer>97</integer>
<key>key_next_missile</key>
<integer>121</integer>
<key>key_ident_system</key>
<integer>114</integer>
<key>key_ecm</key>
<integer>255</integer>
<key>key_launch_escapepod</key>
<integer>27</integer>
<key>key_energy_bomb</key>
<integer>9</integer>
<key>key_galactic_hyperspace</key>
<integer>103</integer>
<key>key_emergency_hyperdrive</key>
<integer>98</integer>
<key>key_hyperspace</key>
<integer>104</integer>
<key>key_jumpdrive</key>
<integer>106</integer>
<key>key_dump_cargo</key>
<integer>116</integer>
<key>key_rotate_cargo</key>
<integer>121</integer>
<key>key_autopilot</key>
<integer>112</integer>
<key>key_autodock</key>
<integer>122</integer>
<key>key_snapshot</key>
<integer>108</integer>
<key>key_docking_music</key>
<integer>117</integer>
<key>key_scanner_zoom</key>
<integer>118</integer>
<key>key_map_dump</key>
<integer>33</integer>
<key>key_map_home</key>
<integer>302</integer>
<key>key_comms_log</key>
<integer>96</integer>
<key>key_next_compass_mode</key>
<integer>92</integer>
</dict>
</plist>

capt.Pirk wrote:

This layout is in part, due to key mapping oddities for Linux Oolite (don't ask).

Actually, I think this line does indeed bear some elaboration. I use the Linux version of Oolite. I'm sure there are others who do as well. Is there some bug, or some caveat that the rest of us should be aware of?

Personally, I rather like the standard keymapping myself. It's similar to the layout used on the CBM64 (which I grew up with) and similar also to Elite: The New Kind which I've played a lot more recently.

Ok, You're right and I'm just being lazy!

Well, I tried the original keymap (BBC) and sure enough , . (<>) didn't work.
Again I have not checked time stamps here, but here's the original post I refer to:-

https://bb.oolite.space/viewtopic.php?t= ... ght=keymap

It seems I am wrong on this (fortunately) and it is not a Linux but maybe Oolite issue.

Go figure..
FYI , I longed for the BBC B version, but had to settle for Acorn Electron one ;-\

The trick with oolite keys on Linux/Win32 is that the code that translates from SDL key events to oolite's idea of what keys are pressed doesn't recognise all keys on the keyboard.

There is no reason all the keys can't be mapped, but none of the Linux/Win32 devs have wanted the unmapped keys badly enough to do it. There just always seem to be more pressing issues like fixing other bugs and playing ;)

dajt wrote:

The trick with oolite keys on Linux/Win32 is that the code that translates from SDL key events to oolite's idea of what keys are pressed doesn't recognise all keys on the keyboard.

There is no reason all the keys can't be mapped, but none of the Linux/Win32 devs have wanted the unmapped keys badly enough to do it. There just always seem to be more pressing issues like fixing other bugs and playing

Oh great ;-\
A strange resolve, considering SDL's popularity for games!
I don't know eh? tsk
Thanks for clearing things up here.

capt.Pirk wrote:

dajt wrote:

The trick with oolite keys on Linux/Win32 is that the code that translates from SDL key events to oolite's idea of what keys are pressed doesn't recognise all keys on the keyboard.

There is no reason all the keys can't be mapped, but none of the Linux/Win32 devs have wanted the unmapped keys badly enough to do it. There just always seem to be more pressing issues like fixing other bugs and playing ;)

Oh great ;-\
A strange resolve, considering SDL's popularity for games!
I don't know eh? tsk :)
Thanks for clearing things up here.

Sorry, I don't think I was clear... the problem isn't with SDL, it is with the big switch statement to check for key presses I stuck in the OpenGL/SDL code for the port that Winston never came along and finished off ;)

There is a bug listed in BerliOS for this which is embarrassingly old too. Perhaps it ought to get fixed for 1.65...

capt.Pirk wrote:

Ok, You're right and I'm just being lazy!

Well, I tried the original keymap (BBC) and sure enough , . (<>) didn't work.

I've just been looking at the code - there's no reason it SHOULDN'T work.

But note: it's not < and >. Those are the shifted keys. > and < are only generated if you hold Shift. The keys you actually want to map are comma and period (key code 44 and 46 respectively).

When you do a keymap be sure to use the keycode for the *unshifted* version of the key (unless you really actually want to be holding Shift down, which I doubt you do for your roll controls!)

winston wrote:

capt.Pirk wrote:

Ok, You're right and I'm just being lazy!

Well, I tried the original keymap (BBC) and sure enough , . (<>) didn't work.

I've just been looking at the code - there's no reason it SHOULDN'T work.

But note: it's not < and >. Those are the shifted keys. > and < are only generated if you hold Shift. The keys you actually want to map are comma and period (key code 44 and 46 respectively).

When you do a keymap be sure to use the keycode for the *unshifted* version of the key (unless you really actually want to be holding Shift down, which I doubt you do for your roll controls!)

Sorry for the confusion. My post does say " , . (<>)" meaning 'these keys ( also on this key blah blah..).
Anyway, it didn't work when I first tried (44,46)

For what it's worth, I quite like this key arrangement as it is now..

capt.Pirk wrote:

Sorry for the confusion. My post does say " , . (<>)" meaning 'these keys ( also on this key blah blah..).
Anyway, it didn't work when I first tried (44,46)

Well that's bloody weird. I'll have to try it and see what happens (although someone might have fixed it of course when I wasn't looking, and hence that's why it looks right in svn head)

Just a note, before I do v1.65rc I just committed code to accept strings in keyconfig.plist - which should make this sort of thing easier (I get sick of looking up ASCII codes too).

aegidian wrote:

Just a note, before I do v1.65rc I just committed code to accept strings in keyconfig.plist - which should make this sort of thing easier (I get sick of looking up ASCII codes too).

rc eh? How many d'ya reckon before 'final' ?

capt.Pirk wrote:

aegidian wrote:

Just a note, before I do v1.65rc I just committed code to accept strings in keyconfig.plist - which should make this sort of thing easier (I get sick of looking up ASCII codes too).

rc eh? How many d'ya reckon before 'final' ?

Depends on the crash reports.