re: [Flightgear-devel] Modal mouse thoughts
Alex Perry writes: I like the concept of the mice.xml file, but am not really comfortable about having the implied modal state hidden in there. Can we break it out, so that mouse, joystick and keyboard events can be conditional on state variables ? Thanks for looking at the code. There are a few things I'm trying to decide right now. First, I'd like to get all state variables out of the /input tree -- the current mouse mode, x- and y-position, and (soon) button status should all go in some other subtree, such as /devices/mice (we desperately need to do that high-level reorg of the property tree). As for the mouse mode, it is accessible from any bindings using conditions, such as key n=?? binding condition equals property/input/mice/mouse[0]/mode/property value1/value /equals /condition commandproperty-assign/command ... /binding /key In fact, I had originally implemented mice.xml that way (as you suggested in your example), but it seemed very verbose -- I have no objection to putting it back if it doesn't scare away everyone else. Yet another option is to allow a fixed maximum number of modes (say, 10) and make them into pseudo-modifiers; we could do the same for mouse buttons. That's not really necessary any more with conditions, though. The other benefit is that the keyboard can easily become modal. We don't currently support key sequences and stateful decoding of keyboard input, which severely limits our ability to tie useful controls to keys. Modal key input is fully possible currently with clever use of conditions, but it is very verbose. Let's say that we wanted 'X' to start an input sequence: key n=88 binding commandproperty-assign/command property/status/modes/x-mode/property valuetrue/value /binding /key and then 'a' to be the second key of such a sequence: key n=97 binding condition property/status/modes/x-mode/property /condition ... /binding binding condition property/status/modes/x-mode/property /condition commandproperty-assign/command property/status/modes/x-mode/property valuefalse/value /binding /key I agree that that's hideously ugly. It's a little cleaner if you just want X to be a modifier key, since it can clear its own flag on release: key n=88 binding commandproperty-assign/command property/status/modes/x-mode/property valuetrue/value /binding mod-up binding commandproperty-assign/command property/status/modes/x-mode/property valuefalse/value /binding /mod-up /key Exactly the same trick works for any joystick or mouse button. The final benefit is that it explicitly allows chorded buttons on the joystick to be decoded. This is useful for people with low button count joysticks. I also see a benefit in having a clean way (compared to how we do it now) of switching a joystick axis between multiple analog input options. This can be handled the same way, though again, it will be verbose. I'm trying to figure out some structural simplifications. One problem with using conditions is that you have to use them anywhere -- if I set up modal input using conditions, bindings that don't know about the mode will charge on blindly ahead; modifiers, on the other hand, cause bindings that don't know about them to be skipped. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
In fact, I had originally implemented mice.xml that way (as you suggested in your example), but it seemed very verbose Much of the verbosity is because we're attaching the conditional to every occurrence of the combination of mode and of input event. Perhaps we should have the modifier set a property, as we do now, Then take the stateful keystroke and give it a new handler that modifies the key value by prefixing it with the property state. The two resulting keystrokes can be listed and caught further on. Or, another approach is to take a leaf from YACC/LEX and convert the stream of input activity into a unified property=value event list. This has the added advantage of being easy to log what the user does. Then, the event list goes through a series of filters that modify the events, delete events and do stateful inspection of their contents. Many of the filters do things like this (not written in XML) ... /key[46]/mod-down := 1 becomes /controls/brakes[1] := 1.0 /key[46]/mod-up := 1 becomes /controls/brakes[1] := 0.0 For modal stuff, we simply define the rule as a regular expression. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
David Megginson wrote: Alex Perry writes: I like the concept of the mice.xml file, but am not really comfortable about having the implied modal state hidden in there. Can we break it out, so that mouse, joystick and keyboard events can be conditional on state variables ? Thanks for looking at the code. David, What i *realy* like about the new code is the way the mouse pointer moves from one side of the screen to the other side when clipping to the borders. What I don't like is the fact that, when changing pointers, the view stays fixed to the last position. I'm realy lost at where I'm looking at and where I should expect the front of the plane. I would suggest that the view direction would be reset to straight ahead when switching modes. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
Erik Hofman writes: What i *realy* like about the new code is the way the mouse pointer moves from one side of the screen to the other side when clipping to the borders. Thanks. What I don't like is the fact that, when changing pointers, the view stays fixed to the last position. I'm realy lost at where I'm looking at and where I should expect the front of the plane. I would suggest that the view direction would be reset to straight ahead when switching modes. It isn't hard to change the file to make the view snap back when you leave mouse-view mode -- we'll just have to choose a default. Personally, I prefer to have the view direction stay put when I leave mouse view mode, especially when using the 3D cockpit. What does everyone else think? In the meantime, I did bind mouse button 1 in view mode to snap the view forward, and you can use that before clicking out if you want. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
What I don't like is the fact that, when changing pointers, the view stays fixed to the last position. I'm realy lost at where I'm looking at and where I should expect the front of the plane. I would suggest that the view direction would be reset to straight ahead when switching modes. Now I think about it, I agree, but I suspect this is a consequence of the approach. Is there a way, within this approach, to save and restore the cursor position between modes ? That would make it much easier to use the mouse for _both_ controls _and_ view direction in rapid alternation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
David Megginson writes: It isn't hard to change the file to make the view snap back when you leave mouse-view mode -- we'll just have to choose a default. Personally, I prefer to have the view direction stay put when I leave mouse view mode, especially when using the 3D cockpit. What does everyone else think? In the meantime, I did bind mouse button 1 in view mode to snap the view forward, and you can use that before clicking out if you want. I finally got a chance to try the new 3d cockpit interior and it is a very good start. It's pretty awkward trying to fly with the keyboard and pan the view with the mouse since I'm used to flying with the mouse. I did a lot of autopilot assist and it's very interesting. It does give you a much better feeling of being inside an aircraft. Portions of the scene that should be blocked out are blocked out. The only thing missing to make it completely realistic is a large individual in the right seat to totally block your view out there. I personally like having the view stay where you left it. Otherwise it's impossible to use the mouse to position the view and then flip to a different mode where you fly with the mouse (and still have the view wehre you left it.) Clicking the middle mouse button centers the view anyway so this shouldn't be too much of a problem, except for a few people who bought mice with only one or two buttons. That's like buying an outlet with only room for one prong. :-) Anyway, definitely some good stuff. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Modal mouse thoughts
Alex Perry writes: What I don't like is the fact that, when changing pointers, the view stays fixed to the last position. I'm realy lost at where I'm looking at and where I should expect the front of the plane. I would suggest that the view direction would be reset to straight ahead when switching modes. Now I think about it, I agree, but I suspect this is a consequence of the approach. Is there a way, within this approach, to save and restore the cursor position between modes ? That would make it much easier to use the mouse for _both_ controls _and_ view direction in rapid alternation. The old Mouse code however I think the tilt stuff broke this maintained state for each of the Mouse Modes. This was IMHO necessary for the MOUSE_YOKE mode and very useful for the other modes. Some of this was compile time configurable, FWIW this was fairly tricky to get right at first but is fairly straight forward once you figure out what you need. ie when cycling into YOKE Mode you want the cursor to reflect current state of the stick !! It was also quite convenient when in VIEW mode to be able switch between offset view and straight ahead with a left click I think that most of this can be programmed into the newer system if wanted by adding saved_x, saved_y mouse position in each of the modes. ie give each mode state as to cursor location. Then on entering mode you assume the mode's x and y and when exiting a mode you stash your location. I think that this will work, but will undoutably need a little tweaking to reflect a window reshape event. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
Curtis L. Olson writes: I finally got a chance to try the new 3d cockpit interior and it is a very good start. It's pretty awkward trying to fly with the keyboard and pan the view with the mouse since I'm used to flying with the mouse. In that case, consider rebinding the arrow keys to pan the view. That worked well for me (I keep it as a local mod loaded from my .fgfsrc). I'm appending the bindings to the end of this message. I did a lot of autopilot assist and it's very interesting. It does give you a much better feeling of being inside an aircraft. Portions of the scene that should be blocked out are blocked out. The only thing missing to make it completely realistic is a large individual in the right seat to totally block your view out there. I'll accept contributions of 3D models. Here are my bindings for making the arrow keys control the view: PropertyList input keyboard key n=356 nameLeft/name descScroll view left/desc binding commandproperty-adjust/command property/sim/view/goal-offset-deg/property step1/step /binding /key key n=357 nameUp/name descScroll view up/desc binding commandproperty-adjust/command property/sim/view/goal-tilt-deg/property step1/step /binding /key key n=358 nameRight/name descScroll view right/desc binding commandproperty-adjust/command property/sim/view/goal-offset-deg/property step-1/step /binding /key key n=359 nameDown/name descScroll view down/desc binding commandproperty-adjust/command property/sim/view/goal-tilt-deg/property step-1/step /binding /key /keyboard /input /PropertyList All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Modal mouse thoughts
Norman Vine writes: This was IMHO necessary for the MOUSE_YOKE mode and very useful for the other modes. Some of this was compile time configurable, FWIW this was fairly tricky to get right at first but is fairly straight forward once you figure out what you need. ie when cycling into YOKE Mode you want the cursor to reflect current state of the stick !! I don't know how the mouse code ended up, but when I originally wrote it, this wasn't necessary -- I just used scaled mouse movement to move the controls, rather than reading an absolute screen position (as I would with a joystick), so there was no need for the mouse code to remember the mouse's screen position. I'm doing the same thing now in the new input.cxx code, and yoke mode seems to work OK. I think that most of this can be programmed into the newer system if wanted by adding saved_x, saved_y mouse position in each of the modes. ie give each mode state as to cursor location. Again, I use the amount of mouse movement rather than the absolute screen position to control the view (and did in the original GUI mouse code as well), so there is no need to keep the original position except for aesthetics. It wouldn't be hard to code up multiple saved viewpoints, but I think that we should wait to see how Jim's viewer overhaul turns out first. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
David Megginson wrote: Curtis L. Olson writes: I finally got a chance to try the new 3d cockpit interior and it is a very good start. It's pretty awkward trying to fly with the keyboard and pan the view with the mouse since I'm used to flying with the mouse. In that case, consider rebinding the arrow keys to pan the view. That worked well for me (I keep it as a local mod loaded from my .fgfsrc). I'm appending the bindings to the end of this message. I agree wholeheartedly. The most intuitive method for controling view direction is a pan left/right/up/down control. The mouse control is excellent for the tutored, but is hardly obvious to someone just starting with the program. It would break compatibility, but what are people's thoughts on replacing the keypad view controls (where each button corresponds to a 45 degree view octant) with a panning system? The '5' could be used to re-center the view. In a virtual cockpit environment (and IMHO everywhere) having a set of fixed views is an anachronism. And users who want a set of fixed views can already get that in a far more general way with the new view trees in proprties. A standard hat switch binding would be even better, of course, but sadly there aren't any standards for hat switches under linux. The kernel's input stuff is, frankly, a mess. My Saitek X45 has four hats, only one of which maps to axes as documented. The other three look like a set of four buttons (which is simpler and better, anyway). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Modal mouse thoughts
David Megginson writes: Norman Vine writes: This was IMHO necessary for the MOUSE_YOKE mode and very useful for the other modes. Some of this was compile time configurable, FWIW this was fairly tricky to get right at first but is fairly straight forward once you figure out what you need. ie when cycling into YOKE Mode you want the cursor to reflect current state of the stick !! I don't know how the mouse code ended up, but when I originally wrote it, this wasn't necessary -- I just used scaled mouse movement to move the controls, rather than reading an absolute screen position (as I would with a joystick), so there was no need for the mouse code to remember the mouse's screen position. I'm doing the same thing now in the new input.cxx code, and yoke mode seems to work OK. Yes that works except there is no visual feedback as to where the neutral position is. ie it changes depending on where the mouse cursor is located on entering YOKE_MODE. This is AWKWARD at best By storing the mouse xy between mode changes the cursor when in YOKE_MODE can always be prepositioned so as to have the center of the screen be 'neutral stick'. FWIW The old Mouse code has been that way since about a week after you first submitted it so this is what you have been using :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
David Megginson wrote: Erik Hofman writes: What I don't like is the fact that, when changing pointers, the view stays fixed to the last position. I'm realy lost at where I'm looking at and where I should expect the front of the plane. I would suggest that the view direction would be reset to straight ahead when switching modes. It isn't hard to change the file to make the view snap back when you leave mouse-view mode -- we'll just have to choose a default. Personally, I prefer to have the view direction stay put when I leave mouse view mode, especially when using the 3D cockpit. What does everyone else think? In the meantime, I did bind mouse button 1 in view mode to snap the view forward, and you can use that before clicking out if you want. Okay, that seems good enough for me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
Alex Perry wrote: On the 2D panel and the HUD, we already have visual control feedback. On the 3D panel, we can replace the scale indicators with a moving yoke. Right, but in both 2D and 3D mode, the panel/HUD isn't guaranteed to be on the screen. They both disappear if you move your head far enough. In principle, it should always be possible for the pilot to tell where the controls are regardless of head position. In a real aircraft or under joystick control, this is imparted by the feel of hands and feet on the control devices. But mouse and keyboard control doesn't have such a mechanism. Norman's point was that this used to be implicit in the mouse cursor position, and it isn't any more. I tend to agree, although I'd like to see something like the current control position panel object appear in the corner of the screen instead, and disappear properly when mouse control is exited. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
Andy Ross writes: The issue of visual feedback is a good point. I wonder if the best solution would be to turn off the mouse cursor entirely and use the control indicators on the panel or hud? I've been thinking along the same lines. We need some kind of visual feedback, though, so that the user knows what mouse mode she's in. Any suggestions? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
Alex Perry writes: On the 2D panel and the HUD, we already have visual control feedback. On the 3D panel, we can replace the scale indicators with a moving yoke. Yes, that's coming very soon. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
