View previous topic :: View next topic |
Author |
Message |
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Wed Apr 23, 2003 7:33 pm Post subject: FuhQuake v0.28 (Build 450) with keymap-support |
|
|
You want it - you got it
Here are my FuhQuake-executables for Win32, which include the possibility to
change the keyboard to fit your local needs.
With that feature you can easily create a new mapping for a non QWERTY-keyboard.
All three levels (normal, with shift, with altgr) are possible and you are also
able to switch on the printage of the scancodes when you press or release a key.
The feature is similar to ZQuake's keymap-feature (loadkeys command),
but the keymap-files have a slightly different syntax (which newer ZQuake versions
also support).
It's easy to port existing older zquake-maps to the new syntax.
Look at the FuhQuake-Massas_Changes.txt and FuhQuake-keymap.txt inside the ZIP and also in the commented header of the example keymap-files (german, dvorak, uk, hungarian and the default.kmap as base for own changes).
Have a look at FuhQuake-Massa_History.txt for a chronological ordered list of changes (started at 2003/07/01)
Here we go:
if you just want the keymap-files (currently german, dvorak, uk and hungarian are included):
Also included in the package are updated qwprogs.dat and spprogs.dat;
they are directly compiled versions from Tonik's CVS - look at progs-version.txt to identify the exact CVS date on which they are based.
Please post your comments, problems and other things related to the keymap-features here!
If you're interested in the source code of my FuhQuake-version, you can also download it here:
Note: the corresponding QuakeC sources for building qwprogs.dat and spprogs.dat are also included.
There are a few notes about how to compile the stuff in the file FuhQuake-Massas_Sources.txt (you can find it in the subdir "doc").
Update 14 May 2003:
I made some internal code-changes which makes the copying of the internally used map-arrays (without keymap-feature) to a new keymap work. Test this version carefully, I made changes to a often used function (Key_Event)! This changes should fix the bug that I described here:
https://fuhquake.net/forum/viewtopic.php?p=7472#7472
Also included is oldman's uk.kmap and SyS' hungarian.kmap and
another (small) update to the qwprogs.dat/spprogs.dat
I also slighlty changed the loading of spprogs.dat - files, see FuhQuake-Massas_Changes.txt for details.
And I had to change the mechanism for the input of special character in the console (red-chars and yellow numbers and special chars) because the
old mechanism (made by Tonik) causes now a problem together with the
ALTGR mappings (thanks to SyS for calling my attention to that misbehaviour).
The new mechanism toggles the input with CTRL+R (red characters) and CTRL+Y (yellow characters), see FuhQuake-Massas_Changes.txt for details.
Update 02 Jun 2003:
The changed loading behaviour of spprogs.dat is no longer necessary - Fuh changed the original behaviour
There are some small additional internal changes which should help to bind the console-switching to other keys (originally the '/~ key). I hope it works now better for Hungarian keyboards (SyS, could you please test it)?
Have a look at FuhQuake-Massas_Changes.txt for a detailed description of the changes.
Update 01 Jul 2003:
Update 16 Jul 2003:
small changes, the executables are still the same:
Update of qwprogs.dat and spprogs.dat according to Tonik's CVS changes as of 13 Jul 2003
Update of hungarian keymap file (SyS sent me a small change)
All above files (binary version, sources, keymap) have been updated!
Update 11 Aug 2003:
There's only one small bugfix for the "commands will be executed when separated with ';' even in comments"-bug in the executables
and an additionally set of qwprogs.dat/spprogs.dat with small enhancements related to Tonik's CVS.
Look at the history-file or here in this thread ( https://fuhquake.net/forum/viewtopic.php?p=9887#9887) for further informations.
The above files (binary version and sources) have been updated accordingly!
As always ==> enjoy
Last edited by Massa on Tue Aug 12, 2003 2:48 am; edited 11 times in total
|
|
Back to top |
|
|
Rowdy
Joined: 22 Apr 2003
Posts: 7
|
Posted: Mon Apr 28, 2003 3:57 am Post subject: Thank you, Massa! |
|
|
Massa was kind enough to send me his modified client almost a week ago. I have since been testing it and have found it to work perfectly.
As a non-QWERTY user, keymap support means being able to type comfortably and puts FuhQuake far ahead of competing clients. I used to use MQWCL because I like its HUD system and temporary autorecord, but, for me, keymap support is such a significant enhancement that I am willing to sacrifice those features for it. I would expect most other non-QWERTY users to feel the same way...
Fuh, I really hope that you will integrate Massa's keymap support into FuhQuake. He has already written the code, and he has documented his changes well, so you would only need to review his code and merge it.
<hopeful look>
|
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Mon Apr 28, 2003 6:53 am Post subject: |
|
|
@Rowdy: Thanks for your good assessment
@All: Rowdy gave me a changed dvorak-keymapping, I added it to the ZIP-file and also put it directly here:
http://www.mohrenclan.de/files/dvorak.kmap
(for those who already downloaded the original ZIP)
Enjoy! |
|
Back to top |
|
|
Tonik
Joined: 26 Feb 2003
Posts: 103
Location: St. Petersburg, Russia
|
Posted: Tue Apr 29, 2003 12:42 am Post subject: |
|
|
@Massa
Ahh! I see it now, you made it so that the .kmap file is executed like a normal .cfg file, and at the same its syntax is almost identical to ZQuake's.
IIRC ZQuake understands "keycode ext", too, so changing one line in zquake code will let it load your .kmap files as if they were "native" zquake keymaps :)
While I want ZQuake .kmap parsing to remain the same, there is no reason for the two formats not to be compatible.
One suggestion: do you mind renaming the keymap_layout keyword to, say, keymap_name? Because "keymap" and "layout" mean basically the same thing so "layout" is redundant.
_________________
8) Tonik |
|
Back to top |
|
|
Tonik
Joined: 26 Feb 2003
Posts: 103
Location: St. Petersburg, Russia
|
Posted: Tue Apr 29, 2003 1:09 am Post subject: |
|
|
@Massa
Since the keymap feature is probably your "pride and joy" just like zquake is for me :), I'm throwing in a couple of random ideas:
1. What if some guy types keymap_layout accidentally in the console (TAB completion can be a nasty thing if you don't bother looking at the screen before hitting Enter)? Will it unbind most keys thus leaving the user without means of control? What about adding some terminating command to .kmap files (keymap_end?)
2. It would probably be nice (even though not very useful :-) if a .kmap file could instruct the engine to start with an empty layout (probably good for basic keymaps like qwerty or dvorak), with the default one (qwerty), the current one, and maybe even with another kmap file?
Suppose you splash some coffee onto your beloved keyboard and one of the important keys stops working (say, Esc). Esc is handled specially in the engine, so binding "togglemenu" to another key will not give you the same functionality. What do you do? You build a quick "keymap patch" that looks something like this:
keymap_name "Quick hack"
keymap_base "Dvorak" // whatever
keycode xxx ESCAPE
keymap_end
And there you are :-) And you don't have to touch the original dvorak.kmap file.
Ok I know it's next to useless but anyway.... just my 2 euro-cents.
_________________
8) Tonik |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Tue Apr 29, 2003 6:22 am Post subject: |
|
|
@Tonik:
Quote: |
Ahh! I see it now, you made it so that the .kmap file is executed like a normal .cfg file, and at the same its syntax is almost identical to ZQuake's. |
That was the idea behind it. So it's also easy to set one keycode.
And that was the reason, that I changed the syntax a little bit.
Just the order of the "ext", so that "keycode" is the command
Quote: |
While I want ZQuake .kmap parsing to remain the same, there is no reason for the two formats not to be compatible. |
I had a compatibility version with both, the ZQuake "loadkeys" command and the "keymap_load" command in (actually it's still in the sources with a #define around it). So you could load a zquake keymap with "loadkeys" and then store it in the new format with "keymap_save".
But I did not see any advantage in keeping it, it's really easy to convert on format to the other - just with an text editor.
Quote: |
One suggestion: do you mind renaming the keymap_layout keyword to, say, keymap_name? Because "keymap" and "layout" mean basically the same thing so "layout" is redundant. |
I suggested to name all commands "keymapXXX" and "layout" was your suggestion for the name of the mapping
But you're right, keymap_name would be better...
Now to your ideas:
1.) If they only type keymap_layout it will just show the name of the current layout. Nothing else happens.
And if you type "keymap_layout NewName" you'll rename the current layout that's it
The only thing with which you can destroy your complete mappings is the command "keymap_reset" which (as the name says ) resets the mappings to the default (American keyboard without special mapping)
Initiallly, when enter the engine, no mapping is active (it uses the internal default map). After entering the first "keycode" command, it will copy the internal table to a new mapping-array and then changes the given scancodes.
So you will not leave the user without control (of course you're able to create mappings which confuses you totally with strange mappings but you have to work hard for that )
2.) what's wrong with several combined "keymap_load" commands (or with one "keymap_load" and several "keycode"-patches?)
So you could do this:
keymap_load "dvorak"
keymap_name "Quick Hack" // this only changes the name
keycode xxx ESCAPE
And here you are And you also don't have to touch the original dvorak.kmap file - to make such changes really easy was one of my intends to change it to be real commands.
You can change a single key while inside the game without problems...
(and with the "cl_show_keycodes"- flag you can switch on a mode for viewing the scancodes which your keyboard sends)
So in the end you're "useless ideas" are already done ?
|
|
Back to top |
|
|
Tonik
Joined: 26 Feb 2003
Posts: 103
Location: St. Petersburg, Russia
|
Posted: Tue Apr 29, 2003 5:58 pm Post subject: |
|
|
Oh shit, so you're one step ahead of me :)
Ok, I'll just make zquake understand "keymap_name" for now and thus achieve a reasonable level of compatibility.
_________________
8) Tonik |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Tue Apr 29, 2003 7:20 pm Post subject: |
|
|
O.K. I changed the name of the command "keymap_layout"; now it's "keymap_name".
The dvorak and german keymap-files have also been changed accordingly.
==> please redownload it, the ZIP have been changed (it's size is about 1MB)
BTW, I reread my last posting - please forgive my terrible English in that posting! I was in a hurry when writing it... |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Wed May 07, 2003 7:00 pm Post subject: v0.28-Executables with keymap-support |
|
|
Another update:
I reimplemented my changes in the v0.28-Build425 sources of FuhQuake.
No new feature - just reimplementation
Also included in the package are updated qwprogs.dat and spprogs.dat;
They are directly compiled from Tonik's CVS - look at progs-version.txt
to identify the exact CVS date on which it is based.
O.K. here is the link where it can be downloaded:
http://www.mohrenclan.de/file/FuhQuake_Massa-v0.28_Build425-win32.zip
Enjoy !
As usual: please post all wishes, bugs and other things related to the keymap-features here.
I'm also interested in other keymap-files. Does nobody create some ? |
|
Back to top |
|
|
dkure
Joined: 26 Sep 2002
Posts: 861
Location: Sydney, Australia
|
Posted: Wed May 07, 2003 7:02 pm Post subject: |
|
|
proberly post new link up top, and i might give setting up a bigger then 104 standard us key board, with all the extra keys that are possible. |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Wed May 07, 2003 7:09 pm Post subject: |
|
|
@dkure: I'm sorry, my English seems to be too bad.
I don't understand your last post...
What shall I do? |
|
Back to top |
|
|
oldman
Joined: 10 Sep 2002
Posts: 636
|
Posted: Wed May 07, 2003 7:22 pm Post subject: |
|
|
i've got a uk-english keyboard keymap at home
not really that many differences, " and @ swapped round and a few other minor changes, i quite like having my " in the right place though :P |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Wed May 07, 2003 9:20 pm Post subject: |
|
|
@oldman: then create a mapping-file for your UK-keyboard !
Normally I would tell you to do the following inside FuhQuake:
keymap_name "UK"
keycode 003 2 #34
keymap_save uk
(or to switch on visibility of scancodes with "cl_show_keycodes 1" and identify the correct scancodes)
the first keycode-command will initiate internally a copy of the internally used table to a keymap-table (otherwise keymap_save will say "no keymapping available")
I said above "normally", because I currently identified a bug in my copy-code. The "_" is no longer reachable; it seems that there's something wrong in my code
I will fix it as soon as I have time (maybe this evening)
In the meantime, I generated a "default.kmap" which should reflect the internal US-mapping and can be used as a base for changes.
It is now included in the ZIP and can also seperately be downloaded here:
http://www.mohrenclan.de/files/default.kmap |
|
Back to top |
|
|
dkure
Joined: 26 Sep 2002
Posts: 861
Location: Sydney, Australia
|
Posted: Wed May 07, 2003 10:59 pm Post subject: |
|
|
Massa wrote: |
@dkure: I'm sorry, my English seems to be too bad.
I don't understand your last post...
What shall I do? |
never mind. Got the main point i said about changing the link. But, is that my english is bad as well, but that is mainly due to all the slang and short cuts I use when talking.
|
|
Back to top |
|
|
oldman
Joined: 10 Sep 2002
Posts: 636
|
Posted: Thu May 08, 2003 6:05 am Post subject: |
|
|
sorry u misunderstood, i meant i'd already made one but didn't think people would be interested that much as its practically the same as default
uk.kmap |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Wed May 14, 2003 8:18 pm Post subject: |
|
|
Another update (look at the top of this thread...) |
|
Back to top |
|
|
SyS
Joined: 26 Nov 2002
Posts: 36
Location: Hungary
|
Posted: Wed May 14, 2003 11:19 pm Post subject: |
|
|
Hi Massa!
Sorry for my english i hope u understand me...
The keymap support is prety good, but i have some problem with that.
I made hungarian.kmap file and some chars isn't shown correctly.
if i use the default keymap eg. ctrl+< and ctrl+> makes extra chars like the ocrana leds... its ok, but:
Hungarian layout:
< altgr+(something hungarian)
> altgr+y
# altgr+x
& altgr+c
@ altgr+v
{ altgr+b
} altgr+n
[ altgr+f
] altgr+g
if i press hungarian altgr+y it isnt ">" thats like default ctrl+>
if i hold down the altgr key and press and relase the ctrl key then press y so good. but this "trick" doesn't work eg. with altgr+c (&)
Something wrong in my cfg or its a bug?
_________________
SyS |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
|
Back to top |
|
|
Tonik
Joined: 26 Feb 2003
Posts: 103
Location: St. Petersburg, Russia
|
Posted: Mon May 19, 2003 4:28 pm Post subject: |
|
|
I can see why MS made it work that way.
Programmers are always lazy and often ignorant.
MS made AltGR work that way so that programmers are forced to make their programs work correctly in case someone uses ctrl+alt instead of AltGR.
_________________
8) Tonik |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Wed May 21, 2003 6:13 am Post subject: |
|
|
@Tonik:
Quote: |
MS made AltGR work that way so that programmers are forced to make their programs work correctly in case someone uses ctrl+alt instead of AltGR. |
Humm? I can't follow your arguments.
If I (as programmer) make a program which works with AltGR it does not need to work correctly with ctrl+alt. Because AltGR is the same...
And if I'm in a world region where no AltGR does not exist, a programmer does not care about Ctrl+Alt, because no key will raise such combination...
(or am I wrong?)
So for me it's still a bug
|
|
Back to top |
|
|
|