Hi Thomas,

I am not part of the USA Games mailing list so didn't see that message, I only saw this request for suggestions and figured I'd throw my own in with the rest. Smile.


Of course I don't know how your code is structured so my comments may be completely off, but it is actually very simple to put a key pressed function into place on top of key down. You just have a separate array with all keys, where each array entry corresponds to a state of the key. In my implementation 0 means not down before, 1 means just pushed down and 2 means already down. So when key_pressed is called in BGT, for instance, it simply calls key_down and updates the state in the second array accordingly. Again, of course I have no clue how your code is structure so if this suggestion still would require major rewriting, just ignore it and change the keyboard layout based on what you feel is best and what other people on the list may want.

Kind regards,

Philip Bennefall
----- Original Message ----- From: "Thomas Ward" <thomasward1...@gmail.com>
To: <phi...@blastbay.com>; "Gamers Discussion list" <gamers@audyssey.org>
Sent: Friday, April 29, 2011 2:05 PM
Subject: Re: [Audyssey] Interrupting Speech in MOTA


Hi philip,

Thanks. That's a good suggestion. Although that means a major rewrite
of the G3D input code. At least for Windows. I'm not really willing to
put that many hours into bug fixes right now. As I explained on the
USA Games list I'm looking for quick and simple solutions to bugs so I
can get MOTA 1.0 out of the door. I can worry about rewriting input
handling at some other point. I've already got my hands full
completing the Windows version let alone finish updating the Linux
version of the G3D engine and releasing a cross-platform version of
MOTA.

Cheers!





On 4/29/11, Philip Bennefall <phi...@blastbay.com> wrote:
Hi Thomas,

There is a third option, which will let you maintain the current keyboard
layout. You can first perform a check to see if the ctrl key is pressed, if
this is the case then interrupt the speech. This should obviously be a key
pressed rather than a key down check, so that it only reports true again if
the user releases the key and then pushes it down once more. Then you can
check if the w key is pressed, and if this is the case check if the ctrl key
is down. This is what I do in my upcoming game to solve this issue and it
works very well. Just make strategic use of key down versus key pressed and
there won't be a problem. What will end up happening, of course, is that
speech is first interrupted when the control key is pressed but then
immediately restarted again if w is pressed and control is still down.
However speech won't be interrupted again on the next loop iteration because
control will just be down, but not newly pressed. similarly the status
command won't be restarted over and over again because w has not been newly pressed either. Using a key pressed rather than a key down check would also
solve the slight quirk where holding down one of the number keys starts a
violent stutter of the weapon name as it gets retriggered on every single
loop iteration.

Kind regards,

Philip Bennefall


---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gamers@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.

Reply via email to