Hotkey Conflicts

[SpiderMunky]

This is getting really annoying now. Whenever I remove binds from the default keys and replace them with my own, things seem to work. But when I exit and later re-load the app the defaults come back and conflict with my new keys setup. Very irritating.

I'm using wings3d 0.98.31, does this happen in the older releases too?

Greg

[nemyax]

I also tried to redefine keys for those functions at one point, but the key bindings seem to be hard-coded. For example, key 102, which is F, is not bound in the prefs.
I suggest you not waste time on that and come up with some other hotkeys. In the meantime, you can try posting this problem at the dev forum.

[Fro Lee]

When I was setting up my hotkeys I noticed the same thing at first. The secret was to delete and then reassign the original, default hotkey before you added a conflicting one to another command.

For example, I use the 'a' key for movement - it was originally supposed to be used for aim. I deleted the assignment of 'a' for aim and then set up the 'a' key to be move freely on the vertex, edge, face, and object levels. The I assigned the 'b' key to aim. It works fine if you have something selected or highlighted - otherwise, the 'a' key will still aim if I have nothing selected and my mouse is not over anything.

Try reassigning the default binds a new hotkey after you deleted their defaults. If that does not work - ask the devs.

- Fro.

[nemyax]

Fro Lee, he means hotkeys that are not defined by the preferences. All that you listed can be changed without any hassle. But F, E, V and B are different.

[SpiderMunky]

Thanks for the replies. :)

To be honest I've had problems even when I delete the original key assignments first, especially when trying to re-assign the number keys for example. All I want to do is assign hotkeys that are laid out rationally but it ain't working. It's the only thing that's really frustrating me with this app. Other than this, it's a fantastic modelling tool.

I was trying to report it as a bug earlier on the sourceforge site but there were some connection problems. I'll maybe try again later.

Thanks again,

Greg

[puzzledpaul]

<< especially when trying to re-assign the number keys for example. >>

Depends which...
6,7,8,9,0 - these are hard wired and can't do much about them.
2,3,4,5 - these can be re-assigned from cut 2>5 without any probs. (have been using these for other ops for a couple of yrs) - using the delete first, then re-assign route as prev. mentioned.

All on std.keybd, btw - not numeric pad

pp

(now cut > n is available and hotkeyable, one could almost consider forgetting cut 2>5 keys anyway :) )

[SpiderMunky]

God knows what I'm doing wrong then. :D I've been doing the deleting first but the original binds just seem to be re-appearing. I'll keep at it, I'm sure I must just be overlooking something.

Thanks,

Greg

[im a fly on the wall]

Some fuctions work better with hot key assignment to coded hotkeys

your top menu options are always avalible so there are no problems assigning them to coded keys
but when we start trying to add context menu items we start running into problems

the onlly true solutions are these
strip the hotkeys from the source and recompile (this can cause problems since some are not hot keyable + - 1 6 7 8 9 are the main ones)
the other option and this is what i did
buy a programable key pad
this will allow you to simply move the keys to where you like
and may support macros as well, which is an added bonus

the n52 speedpad is designed for gamming but i have found
it to be a less costly alternative and works well with wings

cheers

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.