2003.01.03 ~17 Undocumented feature of Q3VM's trap_FS_FOpenFile() The trap never opens a filename beginning with "q3key". This is filename, not pathname, so even "gfx/not/gfx/ha/ha/foold/you/q3keylist" fails to open. For my Scheme UI system, I'm rewriting the UI from scratch. I even have a vmMain() replacement done in Scheme -- that low-level. Since I'm not sure what's happening under the hood, and without a half-decent menu, I can't get the console to open. I think it has to do with all those repeat calls to trap_Key_SetCatcher, but I'm not that desperate to track it down. In any case, since the key event handler is also in Scheme, I wanted to use symbolic names for the keysyms, instead of trying to figure out numerical keycode. In particular, I wanted to use K_F12 to quit Q3 (since console is unreachable). So I wrote up a script to list out the Q3 keysyms, assigning the appropriate keycodes to each symbol. This list of definition went into a scheme file called "q3keys.cfg". Scheme failed to find it (load "qs/q3keys.cfg"). I renamed it "q3keys.scm", and it still couldn't find it. I tried debugging the stdio, unistd, and devfs functions trying to find out what was wrong. I traced flags, file modes, file permission. Everything looked fine. Recalling that the Q3 CD key is stored in a file named "q3key", on a hunch I renamed the definitions file to just "keys.cfg". And blamo, the load procedure suddenly finds it and everything is peachy. The upshot of this undocumented feature is that a malicious mod cannot read the CD key off the filesystem and covertly transmit it. Gotta love undocumented features...