Panda 1.2.1 - shift key blocks events

I made some modifications to the roaming ralph script - especially I added a running mode and a possibility to go backward (but it is only the first one that matters).

The script: … ad/

I decided to use the shift key for running. And that created the problem:
when I press shift and then my desired arrow key nothing will happen. But when I press an arrow key and then shift anything works.

For testing purposes I replaced shift by another key (I’ll choose C for example):

simply replace “shift” in line 84 by “c” and line 91 “shift-up” by “c-up”: voila, anything works as it has to.

So it seems to me that this is a bug in Panda 1.2.1 that should be fixed very soon :wink:

That’s very cool Wolfgke, maybe you should post it in the ‘Code Snippets’ forum too. I’m sure it would be of help to lot’s of people.


It’s not that pressing the shift key first stops the key events working, it’s because there a complete set of “shift-some_key” key events. (and “control-” and “alt-” events)
If you put in a
self.accept(“shift-arrow_up”, self.setKey, [“runningforward”,1])
and add the logic to handle the “runningforward” value, your shift-to-run will work.
(Note there isn’t a shift-arrow_up-up event, when you release the up arrow, it just triggers an “arrow_up-up” event)

It’s a trade-off I guess, in some cases you want to keep the shift handling separate, in some cases it will be more efficient to have the “shift-some_key” events - that’s the way they’ve gone…
When I’ve wanted separate modifier key handling, I’ve used tab or space etc for the modifier.

Thanks for your help.

After your little hint, nb, I even found an easier way than introducing a new var:

I simply added the new 2 lines:

self.accept(“shift-arrow_up”, self.setKey, [“running”,1])
self.accept(“shift-arrow_up”, self.setKey, [“forward”,1])

and, voila, it worked.


Since it was only a little modification of the tutorial code (make a diff if you don’t believe) and I plan to do some more interesting stuff (in hope it will work :wink: ) I’m not convinced that it is a good idea to post it in the code snippet forum at the moment. When I have added more features I will probably do it.

Aha - wolfge, I didn’t realise you could have multiple accepts for the same event. I can see that being quite handy - good tip :astonished:)

(I haven’t been able to find a user-modifiable wiki for P3D where such hints could be added to pad out the P3D manuals - they’re better than most game-engines around - but still have enormous gaps in their detail )


Here’s the real secret: the panda3d manual is a wiki. However, I usually request that people spend a few weeks familiarizing themselves with panda before they start editing the manual. I just feel that the quality of the manual is better if people aren’t too hasty about throwing stuff in.

When the time comes that you feel that you’re ready, look beneath the bottom of each manual page for a tiny dot. That tiny dot is the login button for the wiki. Once you login, you’ll be able to see the wiki controls (at the bottom of the manual pages).

Please read the editing guidelines for the manual, too.

Josh - fair enough - in fact I’m a little surprised wiki account creation doesn’t require your validation… Will tread lightly :slight_smile:

turns out you canNOT have more than one accept statement for a given key - if you have two accepts for “shift-arrow_up”, it ignores the first and only calls the function for the second one.
In your case, the effective (second) function for shift up arrow is “forward”, which works because you press the shift key first then the arrow, the first “shift” key event sets the running flag, then pressing the arrow key gives shift-arrow_up which gives “forward”, and the running flag is already set…

(you can see this by putting a “print key,value” in the setKey function.


Maybe a simple solution:
setKey gets a dict:

def setKey(self, keys):
  for i in keys:
    self.keyMap[i]= keys[i]

if you want to set a Key:

self.accept("a-up", self.setKey, [{"cam-left":0}])
self.accept("shift-arrow_up", self.setKey, [{"running":1, "forward":1}])


Incidentally, the use of shift, control, and alt as modifier keys is not hardcoded into Panda. You can use any set of keys you like as modifier keys, or no modifier keys at all.

To disable the use of modifier keys altogether, so that you can use shift key as an ordinary key, do something like:

mb = ModifierButtons()


It is not expected behavior to block the composing keys when modifier keys are pressed. So, ‘shift-mouse1’ should not block ‘mouse1’ by default. The modifier key ‘shift’ is not blocked itself, so why should the key that it modifies be blocked. It is inconsistant.

The mouse1 event isn’t blocked, it’s modified. When you press mouse1 while the shift key is held down, you’ve actually pressed the button “shift-mouse1”. I don’t see any inconsistency.

If this convention troubles you, there are several ways to turn it off, including the example I posted above; and then you can track the shift keys yourself, or completely ignore them, as you wish.


The above code no longer works. Instead, use:


Actually, the above code does work here? :confused:

it doesn’t on Windows


doesn’t work very well.


only works on Windows…

I tried:

self.accept( 'shift-w', self.setKey,  [ {"run" : 1, "forward" : 1} ] )

But this only works if I press shift before ‘w’… :confused:

somebody help!

I have just added my own Roaming Ralph modification to Code Snippets ( It includes walk-run option. I hope it can be helpful.

Thanks, that helped! :slight_smile:

Still, I think it would be easier to disable the modifierButtons than doing all the combinations of accepts. But… for now this works, thanks again.

Still a problem… :frowning: with all that combinations I can`t run forward and go left/right at the same time. How should I do the accepts to work this? Or better, a command to deactivate these modifierButtons …

In my example it is possible, both when running and walking in any direction. Check it :slight_smile: