re: [Flightgear-devel] The string class fights back (was: Property browser bugs)
Julian Foad writes: Well, you've improved it. You've made it print to a local buffer in the object, so that memory is at least persistent after the call returns. However, that buffer is already used for make_string() so code like this: sprintf(dest, %s = %s, getPath(), getStringValue()); will go wrong because getPath() and make_string() (called by getStringValue()) both overwrite the same area. I've just checked in some new changes that should fix this problem and make the method more efficient. Each node keeps a persisent copy of its path after the first getPath() invocation and returns that buffer. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
Thanks for the patch -- it's in CVS now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
I've changed the squared default -- thanks for the patch. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RE: [Plib-devel] Autogen/configure now fails, related to GL
In the last few days I can no longer build PLIB. I get (on CygWin): [...] checking for glNewList in -lopengl32... no configure: error: could not find working GL library - Julian That confuses me. Shouldn't glNewList be defined in libopengl32 with Win32 / Cygwin ? - Sebastian I'm getting the same error as Julian on my Cygwin system. I tried old versions of configure.in and it works fine with 1.34 but fails with 1.35. The new code in version 1.35 explicitly checks for glNewList() and glLookAt(), while the old code simply checked for the presence of libopengl32.a and libglu.a. The comment for version 1.35 says, Let's hope that this fixes building on OS-X. If this is true, perhaps we could put a conditional around this code so that it doesn't break under Cygwin. Regards, Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3 effectiveness=nnn for both hstab andvstab
Arnt Karlsen wrote: ..one idea; try make the effectiveness'es a function of the propwash, or thrust initially, and from each engine. May help to get a feel for it, I'm not that sure this is the _right_ way to model it. Negative thrust (say on decent/approach, does not need negative prop pitch, only negative prop blade aoa) also has an impact on the tail surfaces. My current thinking, actually, isn't to treat propellers specially at all. Every surface (propeller, jet, wing, whatever) generates an aerodynamic force, and every surface has a characteristic size. You can use, with a little heuristic handwaving, to determine a downstream wash field for each surface. Basically, how much air at ambient density must be flowing through a tube the size of the surface to create that force? Then you get all sorts of nifty effects for free: + Propwash and jetwash, of course. + Asymmetric stalls when slipping, because the fuselage masks one wing. + Loss of tail authority in T-tail aircraft during stall. The hard part here is deciding what the wash field should look like. It should spread out gradually along some vector between the global velocity and the perturbed velocity, but which? Dunno. There is also a potential performance issue, since the extra calculations will go as O(N^2) in the number of surfaces; I think this isn't likely to be significant in practice, though. 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] ANN: Customized Joystick Bindings and Autodetection
David Megginson wrote: Please send me your bindings for your own device. Under Linux, you can find the device name with a command like. This is a great feature. Very cool. Here are button and axis assignments for my Saitek X-45 under Linux. My actually joystick.xml file is in a terribly hacked state, and probably not useful to anyone. :) Note weirdnesses: The first hat acts like a normal hat under linux -- it maps to two axis values. The other three hats look like buttons to the HID driver. Contrary to documentation, all four hats are fully 8-way capable (this is a good thing, obviously). The axes are in a bizarre order -- nothing at all like a normal joystick. The coordinate convention for the two rotary dials are different (this actually isn't so strange, they are both positive==forward as your fingers interpret them). Name: Saitek Saitek X45 Axes: 0 Roll (positive == right) 1 Pitch (positive == down/back/nose-up) 2 top rotary dial on the throttle (positive == CCW) 3 Rocker switch (rudder control) on the throttle (positive == right) 4 Throttle (positive == back/down/idle) 5 Bottom rotary dial on the throttle (positive == CW) 6 Lower right hat horizontal axis (positive == right) 7 Lower right hat vertical axis (positive == down) Buttons: 0 Trigger 1 Stick top A switch 2 Stick top B switch 3 Stick top launch/fire switch 4 Throttle D switch 5 Throttle mouse switch (tiny black thumb button) 6 Stick pinkie switch 7 Stick front C switch 8 -+left position (M1) 9 +- Throttle mode 3-way switch: middle position (M2) 10 -+right position (M3) 11 -+left position 12 +- Throttle Aux 3-way switch: middle position 13 -+right position 14 Upper left hat in up position 15 Upper left hat in right position 16 Upper left hat in down position 17 Upper left hat in left position 18 Throttle forefinger hat in up/back position 19 Throttle forefinger hat in right position 20 Throttle forefinger hat in down/forward position 21 Throttle forefinger hat in left position 22 Throttle thumb hat in up position 23 Throttle thumb hat in right position 24 Throttle thumb hat in down position 25 Throttle thumb hat in left position -- 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] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controlscontrols.cxx,1.21,1.22 controls.hxx,1.21,1.22
Arnt Karlsen wrote: ..(during the Falklands War, the Britts tested refuelling of Harriers and Sea Harriers, from ships, in-hover refuelling, believe I saw this in Air Progress magazine in the mid 80'ies.) I think what you're remembering is the Sky Hook gadget that was developed but never installed on Royal Navy vessels. It was actually a full-service landing system, not just a refuelling boom. The idea was that the Harrier would come to a stable hover alongside the boat, and then be grabbed from above by the hook. It would then (carefully!) decrease thrust until it was just hanging there, and then be lowered onto the deck like cargo. I can't imagine this was very popular with the pilots. Imagine sweating during the (already very difficult) hover as some 19 year old sailor swats at you with a giant crane. :) 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
