Mac Keyboard issue

[eagletree]

It appears that in this code:

Code: Select all

                                        if(event.KeyInput.Shift) {sprintpressed=true;walkSpeed=0.04f;} 
                                        else if(event.KeyInput.Control) {walkpressed=true;walkSpeed=0.01f;}
 

While event.KeyInput.Shift works fine, event.KeyInput.Control doesn't on a Mac (10.6). CIrrDeviceMacOSX.mm didn't appear to have a place to test out different modifiers, just keycodes, so I went no further.

I'm wondering if anyone else has run into this with Irrlicht 1.7.2, OS-X 10.6.8.

Thanks

[eagletree]

Having no answers, I thought I should add to this. All I really want to know is if it seems likely this is an irrlicht bug. I don't want to bother developers by reporting something that could have some other explanation. Opinions?

[hybrid]

Well, this can have several causes. Maybe a different key is mapped to Control on Macs. Question is also if this is specific to 10.6. After all, the user base on OSX seems to be quite small, which might be the reason why it is not recognized by too many people. Maybe you can test this also under the recent SVN/trunk version of Irrlicht, just to make sure that this problem was not yet adressed. Next thing would be to locate the position where the Shift key is tested, and to look for a possibility to check for Control key to create a patch.
Meanwhile, I'll move this to bug forum to remember it.

[eagletree]

Well, this can have several causes. Maybe a different key is mapped to Control on Macs. Question is also if this is specific to 10.6. After all, the user base on OSX seems to be quite small, which might be the reason why it is not recognized by too many people.

I'll look into that. It's not something I would have considered since I use a Mac workstation primarily as my terminal into other UNIX systems (the day job), but any difference in keymapping would already have been handled by any application I use, thus control would end up control on a remote or in a program locally (e.g., high level languages like PERL or apps like Blender). Alt versus Option/Command are the normal incompatibilities. I can also check it on my 10.5 laptop though that will require installing irrlicht and bullet.

Maybe you can test this also under the recent SVN/trunk version of Irrlicht, just to make sure that this problem was not yet adressed. Next thing would be to locate the position where the Shift key is tested, and to look for a possibility to check for Control key to create a patch.
Meanwhile, I'll move this to bug forum to remember it.

I'll look at tracking your SVN, I've stayed vanilla releases with irrlicht thus far. Probably first, I'll take the second suggestion here and spend a little time trying to locate the code. Our primary audience will be Windows of course, but I want the game to work as well on OSX, FreeBSD, or Linux. If I find something, I'll report it back to this thread.

Thank you for the time

[eagletree]

It looks uglier than a remap in CIrrDeviceMacOSX.mm as it appears to be an intentional design thing in irrlicht. If I had to guess, it looks like to get Command into Irrlicht, the KEY_CONTROL is used but only for a few character combinations?

In CIrrDeviceMacOSX::postKeyEvent, the control appears to intentionally be intertwined with command. Since command handles system keys (e.g., cut, paste etc), they are specifically skipped in most cases excepting keys C, V, and X and thus won't handle all keys modified this way. I added 'W' to that list in a test hack, because we are using a scheme where W is run, Shift W is sprint, and Control W is walk. Then I could use command in place of control and we have our "walk" key. Not a solution, just trying to get the bool skipCommand set on for later references to NSControlKeyMask (that part didn't work). To test, I hacked this section of postKeyEvent:

Code: Select all

                                        if ([(NSEvent *)event modifierFlags] & NSCommandKeyMask)
                                        {
                                                if (mkey == 'C' || mkey == 'V' || mkey == 'X' || mkey == 'W')
                                                {
                                                        mchar = 0;
                                                        skipCommand = true;
                                                }
                                        }

I added the "W" conditional. This lets skipCommand be set to true which I think is necessary for Control to be recognized too, but it really only lets command work, presumably because Irrlicht doesn't have a "command" in SKeyInput and it is needed for the GUI? I would guess another block is necessary similar to this (only not key specific) that lets that bool be set true on NSControlKeyMask. Control will be set later if skipCommand is true, but sadly, skipCommand appears to be only currently related to NSCommandKeyMask. That implies that one add in a modifier for Command if that proprietary key were desirable, i.e., the SKeyInput would need changing too.

I will mess with that a bit and see if we can get a hack to support control and abandon command, but I'm guessing that supporting both would be the elegant approach. We don't really want any mac specific keys in our game but I could see where the GUI might want that.

Do you think this is an intentional design to get around the fact that Irrlicht doesn't support a Command key modifier in SKeyInput?

I could be in left field with this analysis. I don't have a lot of time to go deeper right now.

Edit: SKeyInput should have been IEventReceiver.h SEvent.SKeyInput which I think is where the bool is referenced for Control. Appears a Command would be necessary there and the GUI routines that reference Cut, Copy, and Paste would require an OR when checking for "Control" such that it's ||event.KeyInput.Control. An example would be to change CGUIEditBox.cpp

Code: Select all

        if (event.KeyInput.Control)

to

Code: Select all

        if (event.KeyInput.Control||event.KeyInput.Command)

There are a few more references to this in the GUI functions. Are you interested in a formal patch like that? It's probably what I will try.

[eagletree]

I forgot to mention the most important issue about why I put the Command W test in. My event receiver gets a true response on event.KeyInput.Control when any of the listed characters are modified by Command. It looks like whoever did this, wanted Command to respond to the Irrlicht modifier definition of Control, but only for C, V, and X.

I had a motive behind the test, wasn't being totally random .