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] Configurable mouse progress
necessary fix so that PUI can do it's thing input.diffs Description: Binary data
[Flightgear-devel] Elevator Trim Val for HUD
patch to enpower HUD to display elevator trimval hud.diff Description: Binary data
[Flightgear-devel] HUD xml files
previously sent patch for hud.cxx required ! These add a NEW elevator trim marker along side the elevator position gauge also adds missing cemterpoint tick marks FYI With this you can see what the AutoPilot is doing when in one of the 'altitude modes' nhv_hud.tgz Description: application/compressed
[Flightgear-devel] read_animation()
c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/local/include -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c model.cxx model.cxx: In method `void FGAircraftModel::init()': model.cxx:108: no matching function for call to `FGAircraftModel::read_animation (FGAircraftModel::Animation , const char *, SGPropertyNode *)' model.hxx:62: candidates are: struct FGAircraftModel::Animation FGAircraftModel::read_animation(const string , const SGPropertyNode *) model.cxx: At top level: model.cxx:235: prototype for `void FGAircraftModel::read_animation(FGAircraftModel::Animation , const string , const SGPropertyNode *)' does not match any in class `FGAircraftModel' model.hxx:62: candidate is: struct FGAircraftModel::Animation FGAircraftModel::read_animation(const string , const SGPropertyNode *) model.cxx:341: definition of implicitly-declared `FGAircraftModel::Animation::Animation()' model.cxx:341: redefinition of `FGAircraftModel::Animation::Animation()' model.hxx:59: `FGAircraftModel::Animation::Animation()' previously defined here model.cxx:356: definition of implicitly-declared `FGAircraftModel::Animation::~Animation()' model.cxx:356: redefinition of `FGAircraftModel::Animation::~Animation()' model.hxx:59: `FGAircraftModel::Animation::~Animation()' previously defined here make: *** [model.o] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] viewconfig feedback comments
sim view current // xyz offset x-offset-m/x-offset-m y-offset-m/y-offset-m z-offset-m/z-offset-m // orientation rph offsets // the goals should be set if smoothed rotation is desired goal-heading-offset-deg/goal-heading-offset-deg goal-roll-offset-deg0/goal-roll-offset-deg goal-roll-offset-deg0/goal-roll-offset-deg heading-offset-deg0heading-offset-deg roll-offset-deg0roll-offset-deg roll-offset-deg0roll-offset-deg ... you probably mean heading/pitch/roll instead of having roll twice. view nameChase View/name config // Target is the object being looked at target-lat-deg-path/position/latitude_deg/target-lat-deg-path target-lon-deg-path/position/longitude_deg//target-lon-deg-path target_alt_ft_path/position/altitude_ft/target-alt-ft-path target-heading-deg-path/orientation/heading_deg/target-heading--deg-path target-pitch-deg-path/orientation/pitch_deg/target-pitch--deg-path target-roll-deg-path/orientation/roll_deg/target-roll-deg-path .. I don't understand why you have the rotation data for the target, given the axis rotations are specified in the eye position information. view nameTower View/name typelookat/type config // xyz offsets the eye...in lookat these are applied to the eye // position. x moves left/right, y moves up/down, z moves in/out. // In tower view these can be used to simulate err..umm // ..a tower on wheels x-offset-m0/x-offset-m y-offset-m0/y-offset-m z-offset-m0/z-offset-m ... If you don't have axis rotations for the view, does this actually correspond to east, up and north respectively ? Tower on wheels is quite reasonable, especially for chase cars as used by balloons. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] read_animation()
I'm guessing this is an old message that got hung up in the list admin queue for approval. This problem is fixed in the latest cvs. Regards, Curt. Alex Perry writes: c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/local/include -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c model.cxx model.cxx: In method `void FGAircraftModel::init()': model.cxx:108: no matching function for call to `FGAircraftModel::read_animation (FGAircraftModel::Animation , const char *, SGPropertyNode *)' model.hxx:62: candidates are: struct FGAircraftModel::Animation FGAircraftModel::read_animation(const string , const SGPropertyNode *) model.cxx: At top level: model.cxx:235: prototype for `void FGAircraftModel::read_animation(FGAircraftModel::Animation , const string , const SGPropertyNode *)' does not match any in class `FGAircraftModel' model.hxx:62: candidate is: struct FGAircraftModel::Animation FGAircraftModel::read_animation(const string , const SGPropertyNode *) model.cxx:341: definition of implicitly-declared `FGAircraftModel::Animation::Animation()' model.cxx:341: redefinition of `FGAircraftModel::Animation::Animation()' model.hxx:59: `FGAircraftModel::Animation::Animation()' previously defined here model.cxx:356: definition of implicitly-declared `FGAircraftModel::Animation::~Animation()' model.cxx:356: redefinition of `FGAircraftModel::Animation::~Animation()' model.hxx:59: `FGAircraftModel::Animation::~Animation()' previously defined here make: *** [model.o] Error 1 -- 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
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] Configurable mouse progress
Norman Vine writes: necessary fix so that PUI can do it's thing Thanks for the patch, Norm. It compiled fine and didn't cause any obvious problems, but I noticed that the menu didn't disappear with mouse motion as intended. I have no objection to adding the glutPostRedisplay calls (they cannot hurt, since FlightGear redraws the whole window every frame anyway). I am curious, though, about why you moved the puMouse calls from FGInput::doMouseClick and FGInput::doMouseMovement to GLUTmouse and GLUTmotion. I deliberately made the puMouse calls conditional on pass_through so that PUI would *not* see clicks and movement in alternative modes like the view mode -- with your change, PUI will always see clicks and movement, no matter what the mouse mode. Am I totally misunderstanding how PUI works? 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
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] HUD xml files
Norman Vine writes: previously sent patch for hud.cxx required ! These add a NEW elevator trim marker along side the elevator position gauge also adds missing cemterpoint tick marks FYI With this you can see what the AutoPilot is doing when in one of the 'altitude modes' I've updated the source code and base package CVS with Norm's patches, and they work well. Thanks. 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] Normans changes
Erik Hofman [EMAIL PROTECTED] said: Hi, Do Normans changes get applied automatically, or do I have to do it myself? There seem to be some nice features and it would be a pitty to have them left out. Erik Which ones? I did a lot of work on the viewer around the time he sent in his patches to that. But I've since added his patches to what I was doing. There are a couple to the viewmgr that I'll be adding tonight or tomorrow. As for the work in other modules, I'm sure it'll get in to CVS soon if it hasn't already. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Configurable mouse progress
David Megginson writes: Norman Vine writes: necessary fix so that PUI can do it's thing Thanks for the patch, Norm. It compiled fine and didn't cause any obvious problems, but I noticed that the menu didn't disappear with mouse motion as intended. Hmm works fine for me in game-mode no window borders someone might have to tweak this for X but these are the same xy values I used before and I think they worked for everyone ? I am curious, though, about why you moved the puMouse calls from FGInput::doMouseClick and FGInput::doMouseMovement to GLUTmouse and GLUTmotion I deliberately made the puMouse calls conditional on pass_through so that PUI would *not* see clicks and movement in alternative modes like the view mode -- with your change, PUI will always see clicks and movement, no matter what the mouse mode. I didn't try to tweak the code any and just made the minimal changes to get your stuff working with PUI Dialogs HINT - try testing the autopilot adjuster and the Pilot Offset adjuster if you want to see if you are cooperating with PUI when handling mouse events though 'when' you change my code. Norman ___ 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] Normans changes
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: Do Normans changes get applied automatically, or do I have to do it myself? There seem to be some nice features and it would be a pitty to have them left out. Which ones? I did a lot of work on the viewer around the time he sent in his patches to that. But I've since added his patches to what I was doing. There are a couple to the viewmgr that I'll be adding tonight or tomorrow. As for the work in other modules, I'm sure it'll get in to CVS soon if it hasn't already. I think I just got the conformation from both you and David. It's a bit hard to tell if they get applied, when the patches are sent to the list and nobody responds. Erik ___ 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] Normans changes
Erik Hofman [EMAIL PROTECTED] said: I think I just got the conformation from both you and David. It's a bit hard to tell if they get applied, when the patches are sent to the list and nobody responds. Erik cvs logs? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 3D Model Progress
Erik Hofman [EMAIL PROTECTED] said: Yeah, but they don't move ... coughcough Sounds like an easy animation. :-) Best, Jim ___ 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] Configurable mouse progress
Norman Vine writes: HINT - try testing the autopilot adjuster and the Pilot Offset adjuster if you want to see if you are cooperating with PUI when handling mouse events Yes, it works but there seems to be some confusion between passive motion and motion -- I'll look into fixing that. 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] Normans changes
Erik Hofman writes: I think I just got the conformation from both you and David. It's a bit hard to tell if they get applied, when the patches are sent to the list and nobody responds. You need to subscribe to the CVS lists -- then you get an e-mail for every checkin to the repository. 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
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
[Flightgear-devel] Configurable mouse ready to go
I think that we're ready to switch over to the configurable mouse now as the default, and to remove the old src/GUI/mouse.cxx code. There are still a couple of open questions (i.e. mouse cursor-position feedback) and one missing minor feature (automatic menu hiding), but it provides all the main functionality of the old, hard-coded mouse bindings while full user-level configuration. Here's how I have the mouse bound right now: Pointer mode: - all mouse events get passed through - right click switches to yoke mode Yoke mode: - left/right movement with no buttons pressed controls ailerons - left/right movement with left button pressed controls rudder - up/down movement with no buttons pressed controls elevator - up/down movement with middle button pressed controls throttle - right click switches to view mode View mode: - left/right movement with no buttons pressed pans view left and right - up/down movement with no buttons pressed tilts view up and down - left click centres view forward - right click switches to pointer mode All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Base package access via rsync?
Ok, people, please have a look at rsync scenery.flightgear.org::Base and tell me what you think. It should let you track the bleeding edge version of the base package really easily if you don't have local changes. Thank you very much for making this possible! Matthias ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Metakit 2.4.2 = 2.4.3
On Wed, 27 Mar 2002 23:08:59 + Julian Foad [EMAIL PROTECTED] wrote: The SimGear root includes metakit-2.4.2-32.tar.gz. Version 2.4.3 is now available and fixes several potentially serious bugs. I'm not saying Flight Gear is affected by any of them (I have no idea) but I think it's worth considering upgrading. FWIW, under my CygWin systems (on both Win2k and WinME), metakit fails to build on tcl-related stuff and I have to configure --without-tcl. A trivial typo in Julian: I noticed that MetaKit failed to *finish* the make process when I installed it the other evening. However, it failed after it had already installed the required libraries (at least it did so on my system). It *may* be that this is occuring on your system, as well. Did you try make install on metakit, and then trying to build SimGear? You might give that a shot. Maybe your metakit build was good enough? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Configurable mouse ready to go
David Megginson writes: I think that we're ready to switch over to the configurable mouse now as the default, and to remove the old src/GUI/mouse.cxx code. There are still a couple of open questions (i.e. mouse cursor-position feedback) and one missing minor feature (automatic menu hiding), but it provides all the main functionality of the old, hard-coded mouse bindings while full user-level configuration. Hmm - I just updated from CVS and now clicking the right mouse button has no effect what so ever ! This is Win2k with latest glut and CVS plib but that shouldn't make any difference Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Metakit 2.4.2 = 2.4.3
Jon S Berndt wrote: On Wed, 27 Mar 2002 23:08:59 + Julian Foad [EMAIL PROTECTED] wrote: The SimGear root includes metakit-2.4.2-32.tar.gz. Version 2.4.3 is now available and fixes several potentially serious bugs. I'm not saying Flight Gear is affected by any of them (I have no idea) but I think it's worth considering upgrading. FWIW, under my CygWin systems (on both Win2k and WinME), metakit fails to build on tcl-related stuff and I have to configure --without-tcl. A trivial typo in Julian: I noticed that MetaKit failed to *finish* the make process when I installed it the other evening. However, it failed after it had already installed the required libraries (at least it did so on my system). It *may* be that this is occuring on your system, as well. Did you try make install on metakit, and then trying to build SimGear? You might give that a shot. Maybe your metakit build was good enough? I didn't try make install after it failed to build, but I guess that might well have installed enough files to work with. I just fixed the typo in configure and ran configure --without-tcl and make and make install and that was fine. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Inlining
Julian Foad wrote: Code size: secondsbytes options Smallest:203 761360 -g -O1 -finline-limit-6 -finline-functions Smallest O2: 233 767064 -g -O2 -finline-limit-6 -finline-functions Default: 3881328284 -g -O2 Largest: 3881328284 -g -O2 Wow. Good stuff. So basically we're looking at a 2x difference in both size and compile time between the best and (what we're using now) the worst. One nit, though, is that those executables are unstripped (I presume -- the -g option would be useless without it). So presuming that the symbol table never enters the cache at runtime (it doesn't, except when inspected by the debugger) and that the symbol tables should be the same for both the inlined and non-inlined versions (probably true), the actual difference in code size is going to be significantly *larger* than 2x. Eeek. I'm going to start turning off inlining using the arguments above as a matter of habit, I think. If I don't see any significant performance change, I'll come back and start whining to the list that we make this the default. :) 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] MSVC6 Build Progress
Jonathan Polley wrote: I am getting closer. I was able to resolve the link-time errors (added a slew of new files to the MSVC project) and got an executable! There was one build problem in that MSVC did not like an enumeration being used to define the size of an array: .\src\Input/input.hxx(321) : error C2248: 'MAX_MOUSE_BUTTONS' : cannot access private enumerator declared in class 'FGInput' .\src\Input/input.hxx(250) : see declaration of 'MAX_MOUSE_BUTTONS' Changing the enumeration to a series of #defines solved that problem. Once I tried running, I crashed in main.cxx/fgReshape(), line 1166. It appears that MSVC does not generate the proper code for: globals-get_viewmgr()-get_view(i)- set_aspect_ratio((float)view_h / (float)width); and I wound up using a temp variable in order for it to work: FGViewer *Viewer; ... Viewer = globals-get_viewmgr()-get_view(i); Viewer-set_aspect_ratio((float)view_h / (float)width); Finally, I was able to run again and crashed in FGInput::_init_mouse(), FlightGear died in the call to: mode_node-getChild(button, k), line 658-ish Assigning that to a local did not solve the problem, so I am now stuck, again. At least the above line was added in version 1.35 of input.cxx, rather than it being a problem with MSVC that was awoken as a side effect of another change. Any ideas? Thanks, Jonathan Polley p.s. Has a solution been decided upon for the MSVC overloading problem? I was able to work around the issue by renaming the vector methods to have a suffix of _V, but I don't know if that is what is preferred. My vote, if I may have one, is to not overload. This is a personal preference from being burned, in the past, by compilers that aren't too smart. Granted these were older compilers (c. 1985-97), and they weren't C++ compilers (Ada-83 and Ada-95), but I have been made a tad gun shy. Personally, I think I'd like a cast or typedef better than this. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cockpit scene graph
This patch creates a seperate scene graph for the cockpit. The near plane is only moved up when in the interior (pilot) view. This is because with rounding (I presume) it the visible ground is a bit up higher than it is with the older nearplane setting. Not much, but it is enough to bury the wheels. I suspected this might be true but spliting to two sg's confirms it. If necessary we can adjust the model up a bit when in interior view. This might be good so we can set the near plane even closer when in the cockpit (its still at 0.2m). In general this looks a lot better on my Voodoo with this patch. No perceptibel change in frame rate on my system. In terms of future plans I'd see the sense in making the model plug into either scene. This will be necessary when we have multiple model instances in the frame. Here's the patch: Description: Put 3d cockpit in a seperate scene graph. Set near far closer for cockpit scenegraph when in interior view. Files: Whole files: http://www.spiderbark.com/fgfs/cockpitsg-20020327.tar.gz Diffs: http://www.spiderbark.com/fgfs/cockpitsg-20020327.diffs.gz Src files affected: main.cxx model.cxx Current as of 9:45pm EST 03/27/2002 CVS Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Panel locking to z-offset
It looks like somehow the panel is locking the the offset adjustments. So that if you move into the back seat the panel comes with you. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit scene graph
Jim Wilson [EMAIL PROTECTED] said: This patch creates a seperate scene graph for the cockpit. The near plane is only moved up when in the interior (pilot) view. This is because with rounding (I presume) it the visible ground is a bit up higher than it is with the older nearplane setting. Not much, but it is enough to bury the wheels. Does anyone know if this effect is consistant between video cards? What I see is the runway at about the level of the bottom of the panel, just below the flaps control (when using the patch for a seperate cockpit scene graph). If it is, I could make a model transformation correction configurable, otherwise a fixed value would do. Please test this if you can and let me know what you see. Files: Whole files: http://www.spiderbark.com/fgfs/cockpitsg-20020327.tar.gz Diffs: http://www.spiderbark.com/fgfs/cockpitsg-20020327.diffs.gz Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re : Publicity
Hi All I've got a friend who publishes an aviation magazine, and I was wondering what you outlook is on publicity ? Will it be alright for me to organize an article for you guys ? Regards Danie Heath Web Integrator RisC Com cc +27 12 654-5100 083 412 6904 [EMAIL PROTECTED]
Re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson wrote: It looks like somehow the panel is locking the the offset adjustments. So that if you move into the back seat the panel comes with you. Locking? No. Ignoring. :) The virtual panel code always draws itself with the origin at the eyepoint. This is because it was basically done backwards -- it figures out where the panel should be on the screen based on the view direction offset from the aircraft frame. The *right* way to do this would be to just push a transformation on the stack that maps panel coordinates to aircraft coordinates, and assume that the code higher-up has set up the modelview matrix appropriately for the cockpit reference frame. Your changes to put the panel in a scene graph are the big part of the solution. Really, the panel should be drawn immediately after the aircraft model, with the same matrix environment. If you can get this put together (forgive me if you already have -- I haven't read the changes yet), I'll fix the panel. 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
