Re: [Flightgear-devel] Property Picker
Semi-static: click on the . (current directory dot) file entry and it refreshes. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: David Megginson writes: Jim Wilson's new property picker is great -- I encourage everyone who hasn't done so already to try it out. I'd also be interested in hearing what enhancements to the property manager (such as constraints) would be useful for the property picker's future development. One thing that would be cool to add to the property picker would be live updates ... right now the info that is displayed is static and probably the state of the variable at the time the window was created. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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 -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] c310 Panel
Anyone working on an airspeed dial? If not I'll make one, probably tomorrow. Also have made a tiny bit of progress on a 3D panel model...but it's at the point where it could be either a c310 or c172 with a little stretching here and there (given my 'experience' with AC3D there's a good chance I'll start over anyway). Any ideas on which is a better one to start with? Am leaning toward the c172 because if nothing else it'll have fewer items to position. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external view
Cameron Moore [EMAIL PROTECTED] said: We probably do need some sane defaults, but it looks to me like more of a viewpoint calc error to me. Start off on the ground with the external view. It works perfectly until you get airborne, and then the model disappears. -- I'm not seeing this, but i'll have to check and make sure I haven't changed anything locally. My plan is to bind properties (which had originally been done...but I'm not sure I did it the right way). It had current and default bindings, the default being the values set at initialization and what you go to when clicking the Reset button. Give me a couple of days and I'll make a better Pilot view offset complete with bindings and a few changes in the GUI and comments so that it doesn't get confused with the FDM pilot offset. Best, Jim Cameron Moore [ Smoking cures weight problems... eventually. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] asi.xml
Melchior FRANZ [EMAIL PROTECTED] said:
The new c310/asi.xml file tries to load Textures/{airsp260,bezel1}.rgb.
These, however, have been forgotten to upload from
http://www.spiderbark.com/fgfs/c310asi.tar.gz, no?
m. :-)
They are in that tarball (path ./Instruments/Textures). Also now in CVS, but
the instrument is in need of another recalibration. Should be close though.
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] property bindings for chase view offset
That was easy. I finally put the property bindings in the correct place and it works fine. You can now set a default for pilot view offset aka chase view offset. The fix is here: http://www.spiderbark.com/fgfs/chaseviewoffset.tar.gz Contains: sgVec3Slider.cxx and sgVec3Slider.hxx Extract the tarball in src/GUI. This is the suggested xml to be included within the sim settings. Note that I have defined an empty view[0] and view[1] for the chase view. Thinking at some point this could be expanded perhaps to give multiple external views to toggle through. sim ... !-- pilot view -- view n=0 descpilot view/desc /view !-- chase view -- view n=1 descchase view/desc default pilot-offset heading-deg180.0/heading-deg pitch-deg0/pitch-deg radius-m25/radius-m /pilot-offset /default /view ... /sim This is working as is now, but we talked about renaming. Seems we talked about Chase View Offset. If that sounds ok to everyone, I'll make the name changes in the classes, property names and the references on the menu (gui.cxx) and elsewhere to the new name. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Observations
Ross Golder [EMAIL PROTECTED] said: Also, if you got into a plane and the first thing you saw was the following, what would you do? http://www.golder.org/~rossg/tmp/2001_12_09_170213_shot.png a) Request clearance to takeoff. b) Go over the pre-flight checks again. c) Call ahead to say you might be a while. d) Get out and go back to retrieve the right side landing gear. :) Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Parse order of configs?
David Megginson [EMAIL PROTECTED] said: John Check writes: Can somebody clue me on the order in which the config files are parsed? First preferences.xml, which picks up joystick.xml and keyboard.xml by inclusion, then whatever is specified on the command-line in the order it's specified (that covers --config, --aircraft, and --prop). The new c310-set.xml file is processing after command-line... had to edit it to use the model/path that I had been loading from the command line previously. The (aircraft)-set.xml is great, but would be nice to have the command line overrides applied. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external view
Martin Olveyra [EMAIL PROTECTED] said: How can be adjusted the camera offset? I can only adjust the FOV and the camera direction. Look at the menu for pilot offset...it'll let you adjust the position from any angle and the radius from the plane. Also if you look at an earlier message today i posted patched source files that will let you set a default in preferences. Look for property bindings for chase view offset Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rudder trim
Thanks, thats pretty much the same binding I used, but did not get any effect with JSBSim. I will give that a try though in YASim. As far as JSBSim I started looking at the code. It doesn't look like JSBSim is reading that one...although the interface does seem to be (initilizing?) a property called fdm/trim/rudder. Tried changing that in the air with propPicker...no effect and besides that just did some grepping of JSBSim code. But thats about as far as I got before resigning to the fact that once you're over forty sleep becomes a necessary thing. Best, Jim Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: Is there any support for rudder trim...partially done or otherwise? The property is there, but it's not mapped to any input keystrokes or buttons in the default configuration. Add something like this to the keyboard.xml file to map rudder trim to and : (warning, untested, check my syntax and my ASCII, etc...) key n=62 namelt;/name descRudder trim left/desc binding commandproperty-adjust/command property/controls/rudder-trim/property step type=double-0.001/step /binding /key key n=64 namegt;/name descRudder trim right/desc binding commandproperty-adjust/command property/controls/rudder-trim/property step type=double0.001/step /binding /key I'm not sure if JSBSim reads it (it probably does), but YASim gets all of its control input via the XML aircraft description. On the YASim planes, only elevator trim is currently included (I was lazy) but adding rudder and aileron trim would be really easy. In the control tags for the appropriate part (wing, hstab, vstab), simply add a new entry. Here's a modified 172 vstab entry with rudder trim: vstab x=-7.16 y=0 z=.17 taper=.5 effectiveness=3 length=1.71 chord=1.54 sweep=20 stall aoa=16 width=4 peak=1.5/ flap0 start=0 end=1 lift=1.3 drag=1.5/ control axis=/controls/rudder output=FLAP0 invert=true square=true/ control axis=/controls/rudder-trim output=FLAP0 invert=true square=true/ /vstab YASim will sum multiple entries together when calculating the control deflection. I'll be putting together a new plane set this weekend with all the control inputs mapped, including things like slats and spoilers on the planes that have them. 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [7] Re: [Flightgear-devel] 3d cockpit and some ideas
Great! I'll probably look for netpbm... the message i'm getting in gimp is it can't read an xwd file. Could be I need a plugin. Thanks, Jim [EMAIL PROTECTED] said: Well, the easiest way to grab a screen shot is probably to use 'gimp' since it is preinstalled on most systems. 'xwd' and the netpbm tools would work as well, and there are probably others. 2) Anyone know of a utility that will screen shot a DRI window in linux? I'd like to be able to share the progress and get some feedback once it looks like something without folks having to have a copy of ac3d. Might just have to take pics off the monitor with my digital. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d cockpit and some ideas
Andy Ross [EMAIL PROTECTED] said: 3) How should I determine the size to make the cockpit? Is there any rule of thumb for scaling? I've just redone the model (for the third or forth time :-)) and right now is a good point to settle on size/scaling. So long as the proportions are consistent, it really doesn't matter. Rescaling a 3D model is really easy. Maybe not in ac3d, but I'm sure a ssg-based transformer (or just a perl script -- what does ac3d format look like? Is it text?) too could be written with no difficulty. It probably already exists. Just make sure you put the origin somewhere meaningful -- the pilot's eyepoint strikes me as the best choice. It's text and it's documented. Might need some help learning the terminology once I get to that point (of figuring out how to scale the values). Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d cockpit and some ideas
Wolfram Kuss [EMAIL PROTECTED] said: Starting small, but being extensible is a good idea. Often, the 3D cockpit model is much more complex than the exteriour model. For example, for BoBs Spitfire: - Cockpit as 3D Studio ascii file: 324 k without the instruments. This melts down to a 45 k binary. - Exteriour model, highest LOD, with hitboxes: 211 k. What I'm starting with is very basic. A flat panel, dash board trim, pilars, etc. Not sure if I'll need to cut holes for instruments, or if we can just float them a tiny bit infront of the panel surface. Any recommnedations? I figured after we've got a panel rendered in 3d space, I can go back and add a power control box in the center and the yokes. But really, I'm just learning so caveats and suggestions are very welcome. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d cockpit and some ideas
These are the reference pictures I'm using right now (for the panel): http://www.vickivt.com/vicki/planes/cessna%20t310q%201974_3.jpg http://www.vickivt.com/vicki/planes/cessna%20t310r%201980_3.jpg The 1980 model looks better IMHO. Yeah I agree. Besides it doesn't have an empty hole in the middle of it :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3d cockpit dimmensions
From what I understand the c310r is 48.5 door to door width. So I'd guess the panel itself is about 47.5 to 48 wide at its widest dimension. From what I understand radios are 6.25 wide...so while the panel in the picture below looks like its 3 equal sections, the comm panel in the center would have to be only about 14 wide. Does that sound about right? Anyone have information on the actual size in the real thing? http://www.vickivt.com/vicki/planes/cessna%20t310r%201980_3.jpg Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Yaw and Roll Trim
Sounds great! Haven't tried it yet but I will tonight. Just thought i'd ask though: Although the bindings are in the *-set.xml for c310 and c182, they can be done elsewhere (as in joystick.xml). Is that right? I assume that aircraft models with trim tabs will ignore after-takeoff adjustments to /controls/rudder-trim? Or can/should that ability/non-ability be defined (as say rudder-trim-type) in the c172.xml/c182.xml/c310.xml so that changes to /controls/rudder-trim would be ignored or acted upon according to the type of trim adjustment on the plane? In any case it seems to me that aircraft specific key/joy bindings could be problematic. For that, even more so, bindings defined at multiple levels (some general, some aircraft specific) are trouble, especially to someone who clearly remembers being ignorant (because I still am:)) about how most of FlightGear works. Best, Jim David Megginson [EMAIL PROTECTED] said: The JSBSim flight models now support yaw and roll trim as well as pitch trim. The new properties are as follow: /controls/rudder-trim for yaw /controls/aileron-trim for roll The values are clamped to -1.0:1.0, as with elevator trim and the elevator, rudder, and aileron properties themselves. You use these properties in different ways, depending on the aircraft. Our Cessna 172, for example, has only an elevator-trim wheel in the cockpit, so you have to set aileron or rudder trim statically on the ground by bending a piece of aluminum (or in our case, by setting the /controls/*-trim property in your .fgfsrc) -- we'll try to provide reasonable default values in c172-set.xml once current work stabilizes, but you can choose different values for your own preferred flight conditions (econo-cruise, speed daemon, low flyer, etc.). For the Cessna 182 and Cessna 310, there is a rudder-trim wheel in the cockpit, so you can change the rudder trim dynamically during flight by using the '' and '' keys (especially useful when you have an engine out on the C-310); you still have to set aileron trim statically before the flight. These keybindings are set in the *-set.xml files, so they are available only for the appropriate aircraft. When we get around to modelling bigger aircraft like the King Air, there will also be an aileron trim wheel in the cockpit, and all three trim axes will be adjustable dynamically during flight. As always, make sure you do a cvs update on both FlightGear and the base package. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3D panel c310 - so far
If anyone is interested, here is the work on the c310 3d panel so far. Sorry, I couldn't get xwd to take a pic of it. Might be something with my X setup...not sure. It can be viewed in ppe and of course ac3d. http://www.spiderbark.com/fgfs/3dpanelpreview1.ac It's pretty basic right now, just the shape of the panel and partial pillars. Comments welcome. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
Cameron Moore [EMAIL PROTECTED] said: Speaking of which, when I hit 's' to switch panel, it looks like we're reading the XML file each time. It funny that loading scenery doesn't cause any hiccups in performance but switching panels does. Yep, I just used the panel-load that was/is bound to a function key after swapping the panel path property. Panel-load is mostly for reloading the panel while making changes to it (without having to reload flightgear). At some point it might be a good idea to create an array of panel objects and load them all at startup. Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Babies
Erik Hofman [EMAIL PROTECTED] said: Famous artists ... (but maybe Elvis isn't the best name to chose) ... like Jake and Elwood ... Man, I love that movie. :-) Erik We got our son's name from David Bowie's guitarist, not that he's a famous or an incredibly talented guitarist, we just liked the name. See http://www.reeveswilson.com for more info. =D Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Which Panel is current
Norman, The current panel is at /sim/panel/path. You can change it by modifying that path and reloading (panel-load command). Jim Norman Vine [EMAIL PROTECTED] said: Norman Vine wrote: Can someone please tell me how I can determine which panel is the active panel I think by reading the FlightGear/Aircraft/aero-set.xml file. I want to leave the mni panel displayed when using MouseView Mode So I need to be able to determine this at runtime. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] altitude hold fix
I've got some values that seem to work in the current autopilot code with the c310. They are: min_climb = 85.0 kts best_climb = 107.0 kts TargetClimbRate = 1500 fpm Also there is this adjustment factor (code snippet from newauto.cxx aprox line 697): // calculate proportional error prop_error = error; prop_adj = prop_error / 4000.0; The numbers for the c172 are 70, 75, 500, 2000.0 (in the same order as those listed above). If someone could spec the XML (which file and keywords) I'd be glad to modify the autopilot code to use them. What should this adjustment factor be called? It basically strikes a balance in a simplistic way between over and under adjusting elevator trim. It's not as good as it could be, but it'll provide a basic altitude hold function for now. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ummm...anyone read this?
Hi all, Was thinking it'd be nice to have a least a minimal heading and altitude hold autopilot working for LWCE. What would be the best file and property tree location to put these values in so that the existing autopilot routine is somewhat adjustable by aircraft? See notes below. Best, Jim Jim Wilson [EMAIL PROTECTED] said: I've got some values that seem to work in the current autopilot code with the c310. They are: min_climb = 85.0 kts best_climb = 107.0 kts TargetClimbRate = 1500 fpm Also there is this adjustment factor (code snippet from newauto.cxx aprox line 697): // calculate proportional error prop_error = error; prop_adj = prop_error / 4000.0; The numbers for the c172 are 70, 75, 500, 2000.0 (in the same order as those listed above). If someone could spec the XML (which file and keywords) I'd be glad to modify the autopilot code to use them. What should this adjustment factor be called? It basically strikes a balance in a simplistic way between over and under adjusting elevator trim. It's not as good as it could be, but it'll provide a basic altitude hold function for now. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ummm...anyone read this?
What I was looking for right now was the simple autopilot that is already in FG...ie something to keep the plane in the air when I let go of the yoke (besides pause :)). I agree it should be done right, but I can get the existing one (which is very basic) working for both c172 and c310 with very few changes. All I need to know is where the XML settings should go. They can always be expanded on. The values I have to able to set per aircraft (to start with) are: min_climb_speed, best_climb_speed, target_climb_rate, and something which for lack of a better term is an elevator_adjustment_factor (controls the severity of adjustment to elevator-trim for a given error). Best, Jim John Wojnaroski [EMAIL PROTECTED] said: Was thinking it'd be nice to have a least a minimal heading and altitude hold autopilot working for LWCE. What would be the best file and property tree location to put these values in so that the existing autopilot routine is somewhat adjustable by aircraft? See notes below. Well, I've cobbled together a 3-axis autopilot I'm using to fly the c310 while working on the glass cockpit displays. It has a attitude hold mode, heading hold mode and a few keyboard commands to change the command values. Bad news it runs over a LAN, and would need a little work to stick into the FG autopilot code. FWIW if interested I'll be glad to send along the control laws and gains. Inputs are the FDM state variables, control surface positions, a couple of state derivatives, and command values. Output is commanded control surface deflections. Has a rudder trim and yaw damper function to handle pFactor. The whole package includes the network interfaces (UDP/TCP/IP) needed to get the state variables and return the command inputs via sockets. You could run it on a second machine to control FG. The tar file is about 200K. Regards John W. ___ 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
Re: [Flightgear-devel] Remote control of flight parameters
Try telneting in to manipulate properties. That'll do what you are talking about. I think you can shut off the engine by setting the RPM to 0. Of course changes can be made using scripts and/or a simple gui program that sends strings out to that same port. Best, Jim Sergio [EMAIL PROTECTED] said: --=_NextPart_001_000A_01C1A023.716309A0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I know the FGFS alows to comunicate with other machine by sockets but = I'd like to know if it's possible to control things as wheather, = breaking engine, etc. by other LAN computer. Is there any module that = supports this feature ? Thank's Sergo Roth ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Breaking OpenGL's hold to ease debugging
David Megginson [EMAIL PROTECTED] said: Norman Vine writes: Again I don't see any compelling reason to move to SDL As an outsider, I'll mention that one advantage is the fact that so many other high-end games seem to be using SDL now. I like PLib, but it hasn't seemed to catch on in the same way. All the best, David I'll second that. There's a lot more help out there with SDL for people like me (interested in learing 3D so I can get a 3D-Panel rendered). Reading the red opengl book now, not that it's needed to use plib. But it sure helps explain some of the terminology. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Configurable Auto pilot
oops. fixed! John Check [EMAIL PROTECTED] said: it's 404 On Saturday 19 January 2002 05:09 pm, you wrote: This makes the current autopilot at least configurable on the verticle for different aircraft. There are two configs included, one for c172 and the other for the c310: http://www.spiderbark.com/fgfs/newauto-020119.tar.gz There are some other features that would be nice to get working (pitch hold, apr/gs capture, etc), but I thought I'd suggest this now as a bug fix for c310 and other faster aircraft users. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: Fuel
David Megginson [EMAIL PROTECTED] said: Hmm -- maybe you could set up a Python script to refill the tanks every few hours. Note that the FGRocket engine model used by the X-15 was already consuming fuel -- proper fuel consumption just hadn't been implemented for FGPiston yet. In flight refueling for a c172? Kewl! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC3 3D Model
Jeff [EMAIL PROTECTED] said: If I could find some outline drawings of the 172 310 I could plug away at that also. Jeff, Check this out: http://aviation.sosu.edu/aircraft/c310.html and these http://aviation.sosu.edu/aircraft/aircraft.html Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash on linux with latest CVS code
James,
I rebuilt again from CVS tonight (2nd time this week) and no problems. When I
do it I do a full rebuild including all the config and makefiles (even if I
think it might not be necessary).
This is a gcc2.95.2/glibc2.1 system for what thats worth. Ran default just as
you did and it loads up fine.
This really looks like corrupted XML. Is it possible that a merge conflict
occured that you missed? You can grep for that. Or you could check any xml
files flagged M or rm -rf the xml files and reupdate.
Best,
Jim
James Gallagher [EMAIL PROTECTED] said:
On Wed, 2002-01-23 at 07:52, Curtis L. Olson wrote:
James Gallagher writes:
I get the following seg fault with the latest CVS version of FG (using
the latest CVS SimGear):
[jimg@dcz FlightGear]$ src/Main/fgfs
FlightGear: Version 0.7.9
Scanning for root: command line
Scanning for root: /home/jimg/.fgfsrc
fg_root = /usr/local/src/X11/fgfsbase
Segmentation fault (core dumped)
Hmmm, this looks like you are dying in the property manager code some
how. Do you have the latest cvs version of the base package? Perhaps
a config file there got corrupted?
I double checked this. I have the latest fg base (from CVS).
Another things worth trying is to rebuild simgear from scratch, make clean;
make, then install it, then make clean; make in the FlightGear tree.
Yup, I tried this too, with metakit 2.4.2 (both with and without Erik's
suggestion of removing the #define bool int (which on gcc won't be
defined, but just to be sure...).
It still crashes.
Stepping through the code in gdb/ddd I saw the following:
In
inline bool fgSetDouble (const string name, double val)
{
return globals-get_props()-setDoubleValue(name, val);
}
The call to globals-get_props()-setDoubleValue(...) has stuff that
makes sense. But inside setDoubleValue the formal param relative_path is
null and that's where the seg fault comes from.
bool
SGPropertyNode::setDoubleValue (const string relative_path, double
value)
{
return getNode(relative_path, true)-setDoubleValue(value);
}
I'm sort of swamped right now, so I haven't taken this any further.
Sorry. Maybe this will be enough of a clue for someone else on the list.
Oh, I was building from CVS just fine until at least late last week, so
whatever is causing this happened relatively recently.
James
Regards,
Curt.
I poked around with gdb/ddd. Here's the stack from the core file:
#0 0x82e5204 in SGPropertyNode::getNode (this=0x0,
relative_path=@0xb2e0, create=true) at props.cxx:1290
#1 0x82e5c24 in SGPropertyNode::setDoubleValue (this=0x0,
relative_path=@0xb2e0, value=-110.6642444)
at props.cxx:1472
#2 0x8089d64 in fgSetDefaults () at fg_props.hxx:328
#3 0x80689d5 in fgInitConfig (argc=1, argv=0xb724) at
fg_init.cxx:219
#4 0x8059089 in mainLoop (argc=1, argv=0xb724) at main.cxx:1487
#5 0x805dd72 in main (argc=1, argv=0xb724) at main.cxx:1816
#6 0x4054b306 in __libc_start_main (main=0x805dd54 main, argc=1,
ubp_av=0xb724, init=0x804d4a4 _init,
fini=0x83a2a78 _fini, rtld_fini=0x4000d2dc _dl_fini,
stack_end=0xb71c)
at ../sysdeps/generic/libc-start.c:129
I tried various things, like not using my ~/.fgfsrc file, et c. but I
still get the seg fault.
Any one else see this?
Thanks,
James
--
__
James GallagherThe Distributed Oceanographic Data System
[EMAIL PROTECTED]
http://unidata.ucar.edu/packages/dods
Voice: 775.337.8612Fax: 775.337.2105
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Curtis Olson Intelligent Vehicles Lab 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
--
__
James GallagherThe Distributed Oceanographic Data System
[EMAIL PROTECTED]
http://unidata.ucar.edu/packages/dods
Voice: 775.337.8612Fax: 775.337.2105
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Andy Ross [EMAIL PROTECTED] said: Geoff McLane wrote: JSBSim stops after the QNAN's, and now YASim c172 seems unable to get speed to lift off ... Just one of those days ... Odd. Jim Wilson also reported a not enough power situation (with the YASim 747) that I couldn't reproduce. I didn't think to ask about platform. Does anyone using MSVC have correct power behavior with the YASim planes? Does anyone see such a problem using non-MS builds? This kind of platform bug gets really scary. :) Andy Andy, I'm running linux. My apologies for not having read the whole thread yet...if this has been alrady been discussed further. The 747 seems to have about the right power for take off. But it seems as though the thrust decreases disproportionately as altitude increases to the point that I can't get above the mid teens for altitude from a near sea level takeoff. I upped the thrust to 63000lb per engine (PW spec) and that helped get it a few thousand feet more. I'll have to try again but I think the c172 seemed a little underpowered here as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GeForce4 announced at nVidia
Curtis L. Olson [EMAIL PROTECTED] said: My previous card was a Voodoo-3 ... this was a 16 bit card, 16 bit textures, 16 bit depth buffer, etc. At the time the mesa based linux drivers had some bugs which led to annoying visual artifacts, and jumpy/jerky motion. Well in defense of a great company that got bought up and shutdown (not necessarily in that order) by the almighty competition...my voodoo3/3000 still works great. Admittedly it was touchy on X3.3.x and earlier X4.0.x, but I'm running with no issues at all right now with decent (by 1999 standards) performance. Smooth motion, no artifacts. So 3dFX should (posthumously) get credit for being the first real 3D card supporting Linux :-) Been thinking about upgrading and I'm somewhat undecided on whether I should get the open source supported Voodoo 5000 (getting cheap these days) or go with nVidia. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] APR button for autopilot
Hi John, This file contains the xml and updated rgb for an APR button on the autopilot. It can be used to lock on to the glide slope on an ILS aproach: http://www.spiderbark.com/fgfs/autopilot_with_apr.tar.gz As it stands now the NAV locks onto the NAV1 localizer and the APR locks on to the NAV1 GS (if it exists). I think (and I'm not quite sure) that on a real autopilot (like the KAP-140) the NAV button will lock on to VOR signals and the APR is used for locking to localizer/ils for both axiis. But without having a manual and knowing exactly how this should work, and making further changes to the autopilot code, this slight modification will make it easier to lock onto a glideslope on approach. Let me know what you think. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Re: Nits
I noticed on mine that the runways come up textured and then turn white. This happens very quickly but you can definately see it, lines and all. Why would that happen? Jim Curtis L. Olson [EMAIL PROTECTED] said: Jon S. Berndt writes: I'm confused. Then why did Melchior say he had no white runways at KEDW? Could he be running an older version of the scenery files? 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] X-15 rumble sound
[EMAIL PROTECTED] said: I'd really like to have a good XLR-99 rumble sound. Right now I don't recall there being any audio indication that the engine is burning. Is there? What is Seems like the wheel rumble could be modified (amplified?) to sound kind of like a rocket rumble. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] [BUG] JSBSim: sudden plane crashes
[EMAIL PROTECTED] said: I believe that these are lingering problems with the propeller models. Is this still present with the newer JSBSim code/files? Strange. It's hard to picture why, when everything has been at equilibrium for a while, why the propeller should suddenly spin out of control. Jon I think it's usually after some sort of event...haven't seen this in normal flight myself. When seeing it mostly I just wrote it off to the model being unusually difficult to get out of a stall or spin, but pushing the nose down suddenly does seem to break it here as well. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim DC3 startup problems
Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: Are you talking about the newer 3D model or newer xml? I'm not sure exactly what affects the position of the model, but using Yasim-DC3 any model including the glider is sideways. Now, that's interesting. I'd just assumed this was a modelling issue, but you're saying it's YASim-specific? Does it happen with the other YASim planes or just the DC-3? I can't imagine what I might have done to get this goofed up, but I wouldn't be surprised if there was something in there. Andy Its the pitch/roll/z setting in the xml. The new 3D model does point to the left by default though. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] tiled panel background
It turned out to be quite easy to add multiple tiles for a panel background. This simple one could be enhanced to have more detail but it does look quite a bit better than a single 256x256 stretched accross the window. http://www.spiderbark.com/fgfs/c310-tiled-panel.png The code for this involves fairly minor changes and is contained in this tarball: http://www.spiderbark.com/fgfs/tiledpanel-021202.tar.gz Note that the rgb files and the xml file contained in the tarball should all be placed in $FGROOT/Aircraft/c310. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tiled panel background
David Findlay [EMAIL PROTECTED] said: On Wed, 13 Feb 2002 15:02, you wrote: Definately. I hope this will go into 0.7.9 so it can be thoroughly tested for the 0.8 stable release. It's probably too late for that. In any case I'd like to revisit the syntax of the xml (take a look at it) and it'd be good to be able to sync the aspect ratio to the most commonly used 4:3 geometry (which hasn't been done yet). The format I'm using for tiling now is this: +---+---+---+---+ | 1 + 3 + 5 + 7 + +---+---+---+---+ + 2 + 4 + 6 + 8 + +---+---+---+---+ Where the numbers represent the textures in the array. It'd probably be fine if it was included...it doesn't break old panels, but I do want to throw in the caveat that it isn't done. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fix for autopilot gui
Hi Curt, This is a three line fix for some inconsistancies between the gui dialogs and the panel controls for the autopilot. The heading dialog would only show the last setting you did through it, even if it was later tweaked with the bug on the hsi. The altitude dialog did a similar thing. Now the values default to the same that show on the panel displays. http://www.spiderbark.com/fgfs/autogui-021302.tar.gz Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: C310
Melchior FRANZ [EMAIL PROTECTED] said: * David Megginson -- Wednesday 13 February 2002 21:15: It's OK, but I haven't tried a lot of long cross-countries. I haven't put much work into the prop model for the C310 compared to the C172 or C182, so I wouldn't be surprised if it's spinning out of control by producing excess power at high speed. You don't need high speed to crash the c310 instantly. Just push the nose down. And I don't agree that this is OK. m. :- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Melchior, What I'm seeing is that you have to hold the nose down for two or three seconds so that the plane goes into a dive. The values go whacky as soon as the craft hits that steep downward pitch, before it accelerates. Is that the same as what you get? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CTRL+U and JSBsim
Just wondering if we should comment out the binding for this since it still doesn't work with the default FDM. Best, JIm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Engines start at idle (was Re: [Flightgear-devel] for the upcoming release)
David Megginson [EMAIL PROTECTED] said: I am convinced that we're best off starting with the engines idling rather than off, since our default start is always on a runway (even Is there a way to set the parking brake at startup so that the plane doesn't roll down (or off) the runway as soon as it loads? I tried a couple things and they didn't work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] CTRL+U and JSBsim
Tony Peden [EMAIL PROTECTED] said:
On Wed, 2002-02-13 at 14:59, David Megginson wrote:
Interesting. I have no objection to removing the binding completely,
but it is showing up a more serious problem with JSBSim's ground
trimming (it tries to trim to the ground on reset even when the plane
is already in flight).
The way its set up right now, it should trim in-air if the speed is
above 10 knots.
From FGJSBSim::do_trim():
if(fgic-GetVcalibratedKtsIC() 10 ) {
fgic-SetVcalibratedKtsIC(0.0);
fgtrim=new FGTrim(fdmex,fgic,tGround);
} else {
fgtrim=new FGTrim(fdmex,fgic,tLongitudinal);
}
If there's a more reliable way to figure out that we want to
be on the ground (aside from a similar hack with altitude)
I'll be happy to change it.
It's doing it at full or near full throttle cruise. Is there an exception
handler that's doing a reset (although it's a bad reset...not going back to
the runway)?
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] CTRL+U and JSBsim
Tony Peden [EMAIL PROTECTED] said:
The way its set up right now, it should trim in-air if the speed is
above 10 knots.
From FGJSBSim::do_trim():
if(fgic-GetVcalibratedKtsIC() 10 ) {
fgic-SetVcalibratedKtsIC(0.0);
fgtrim=new FGTrim(fdmex,fgic,tGround);
} else {
fgtrim=new FGTrim(fdmex,fgic,tLongitudinal);
}
If there's a more reliable way to figure out that we want to
be on the ground (aside from a similar hack with altitude)
I'll be happy to change it.
Ah...one more thing. When it does this jbssim reports that it's setting the
correct altitude, then it goes to the same elevation as the starting position
(just doesn't change the long/lat). Then it seems if you aren't in the right
place it crashes with a Fatal error: Tile not found, attempting to schedule
tiles for a bogus long/lat.
This link below is the output from such an event. It appears that the ground
level at the location where the program crashed was actually 539ft or about
200-300 feet higher than the initial altitude at take-off. Not sure if I'm
reading this right, but maybe you can see something here:
http://www.spiderbark.com/fgfs/ctrlubug.txt
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Engines start at idle (was Re: [Flightgear-devel] for the upcoming release)
John Check [EMAIL PROTECTED] said: I could bind a toggle for the brakes to the indicator. I think it's fairly likely somebody might click on it Yep great idea. Is the at-startup-parking-brake working? I couldn't seem to make it work last night. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Crashes if no scenery file at startup location
Just wondering if this is a necessary JSBsim feature. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
Martin van Beilen [EMAIL PROTECTED] said: I have been playing around with the wind some more, and it seems that JSBSim doesn't only have the up/down winds inverted, but the north and east winds as well. Hmmm...doesn't look like it to me. Just rolling down the runway I applied a 200knot guest from the east and it blew me off the correct side :-) Also the other day I tested an autopilot nav final with a 30 knot crosswind and the plane seemed to be crabbed in the correct direction. North winds are coming from the north, not blowing to the north...which is correct imho. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
Tony Peden [EMAIL PROTECTED] said: I'd be happier if we kept it as is. Wouldn't be the first time engineers have traded correctness for pragmatism. Ah pragmatism! Is that the excuse engineers use when they get their vectors math bass-ackwards? ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
Jon S. Berndt [EMAIL PROTECTED] said: Was there a properties way to do it that is opposite to the above? Perhaps we are given too much power! ;-) In the /environment path there are variables for wind direction that specify a force value as fps from east and/or north, the sum of which articulate direction and speed I presume. I'm not sure how the translation from the command line degrees vector is done, not to mention if it is done the same way. The DIR vector is displayed in the environment path, if it is given, but I don't think changing it makes a difference after startup. I should double check but IIRC the up/down as represented by viewing the properties is counter-intuitive. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tiled panel progress
Alex Perry [EMAIL PROTECTED] said: http://www.spiderbark.com/fgfs/c172r-tiled-panel.png http://www.spiderbark.com/fgfs/c310-tiled-panel.png Very nice. Do you do enough texture re-use that it'll run well on low-texture-memory machines ? I'm doing a demo on Wednesday 8-) Other than that, you need some mini texture fragments with fingerprints, scratches and other dings. It looks too neat and clean the way it is. I really like the way that the cowling looks now, especially the corner. Some reuse. I'm running a 16mb Voodoo3 3000. What will you be using? If you run into trouble try taking the right side textures out. They are normally hidden unless you scroll over there. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with panel code
There's an issue that needs group input. Currently there's a property value called y-offset (there's also an x-offset that isn't used much) and this parameter is used to initialize the panel position adjustment (shift F5 or shift F6). The default is 0. Some of the panel xmls define initial values other than 0. This is done presumably to display panels that fall below the bottom of the window, even though none of them now actually have gauges or switches below the bottom edge of the window. What I'm getting to is this: The code in src/Cockpit/panel_io.cxx somewhere around line 705~708 doesn't allow subsequent panel loads (after the first one) to change the y-offset. This really makes panel coding a challenge, basically because the offset has been defined as non-zero in many cases, and this offset relates to the coordinates of all the objects on the panel. If we are using mini panel for example, it must have the same y-offset as the main panel or the gauges will be mispositioned because the coordinates relate to the other panel's y-offset. If the panel_io.cxx always (re)set the y-offset as defined by the panel being loaded then this issue would go away. IMHO all the code in a panel xml should work as designed when it is loaded, but changing this means that the y-offset will not be settable from the command line, which in very rare circumstances might be desireable. So I guess my question is this: can I change this to allow the panel xml to have final say on the y-offset even though there might be a user or two out there that sets y-offset elsewhere? Or am I underestimating the importance of this? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tiled panel progress
Martin Spott [EMAIL PROTECTED] said: From: Alex Perry [EMAIL PROTECTED] 8MB + AGP in a RagePro chipset UTAH-Glx ? I wonder how you would get RagePro running with plain XFree86/DRI ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends ar This could be tight. Right now I'm using 256x256 textures. This could be reduced but would require a different approach. In any case you're looking at probably 2-3mb in texture memory over and above what is used now at 16bpp. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
David Megginson [EMAIL PROTECTED] said: John Check writes: As for me I'd like to see 1)ground explosion when plane crash the ground (I have a lot explosion textures) Hmm, I'm not sure I see a reason for this one. I'd move it down the list, but it would be a crowd pleaser. People do ask for it. From the crash reports I've read and pictures I've seen, small planes tend to snap or crumple rather than explode (often none of the above). In fact, the more full the tanks, the *less* likely an explosion, since there's less oxygen to help the fuel ignite. Crashed planes are often salvaged and rebuilt, even. Dang, and I was just thinking about how I might hook my flame thrower to the usb port for added realism! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
David Megginson [EMAIL PROTECTED] said:
No, that's not right after all. Following a message from Jon Berndt,
I took a peek at the property browser, and the wind-{north|east}-fps
is the to- direction, not the from- direction. JSBSim was using the
from- direction already, while the other FDM's were usign the to-
direction. In any case, the command-line option now works properly,
and all the FDMs behave the same way; it's just that the properties
need to be interpreted differently.
Note that those properties are also writable. This is a good thing since
at some point we'll probably want a way to manipulate weather changes without
restarting.
So, what do we do?
From where i sit the vectors should be from in the properties. Since the
property manager offers a way for non-programmers to affect the way fgfs works
(through xml or other methods), it should be in a term that most users will
understand.
I think we're all on the same page...but what i'm seeing is this:
The code in the last release displayed property values in fps from north or
east when using JSBsim. Those values could be changed during flight to alter
the wind direction or speed during flight. The values entered would be
interpretted as from their respective vectors. IMHO, without getting into
the internals, JSBsim and the interface to it was correct.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] tiled panel code
Here's the code and textures. The code (panel*.?xx) goes into the src/Cockpit directory. The rest (c172 and c310 directories) go into their respective corresponding directories under $FGFSBase/Aircraft. Let me know how it works, especially with the lower video memory cards: http://www.spiderbark.com/fgfs/tiledpanel-021902.tar.gz Note that the xmls are designed to be used with prior code without failing so if you want to speed things up a very small bit it's ok to delete the definition for the old background texture. If you have texture memory problems, try deleting the last couple multibackground entries in the XML for the panel you are using. This will get rid of the right side of the panel which is normally hidden (and doesn't have any instruments on it yet anyway). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: tiled panel code
Melchior FRANZ [EMAIL PROTECTED] said: No wonder, the patch was not against the latest CVS, so it removed everything that was added later! Very nasty ... :-( m. Sorry about that...actually I was quite current, but usually I like to cvs update one last time before posting. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
David Megginson [EMAIL PROTECTED] said: Andy Ross writes: I have my own peeves about the panel coordinate conventions. I wrote the code after about two hours puzzling through examples in an OpenGL book, which was my first exposure to 3D programming. It works, but I agree that it's ugly. Think I'm reading the same book now :-) One of the things I'd really like to see at some point is the ability to paste a 2D panel onto a polygon in a 3D virtual cockpit. In principle, this should be easy. In practice, the use of screen coordinates makes this difficult. How should one interpret y-offset in a 3D environment, for example? You should ignore it completely -- the pilot position and viewing direction would control what part of the panel you see. The right thing is to integrate the panel code into the main SSG scene graph. Any volunteers? I could be one. Can you explain generally what you mean by integrate the panel code into the main SSG scene graph? Basically, yes I don't yet know what you mean by main SSG scene graph. Otherwise been thinking about two mini projects with the panel in the near term. One is to do an approx model of a real autopilot with a real pitch hold/adjustment, etc. The second is to set up a processor for ribbon textures...that could be configured in XML and used for compasses and/or an integrated (xml defined) GC style instrument. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
Curtis L. Olson [EMAIL PROTECTED] said: This would work best if we put the panel into a different scene graph from everything else: setclipplanesforworld(); ssgCullAndDraw(world); setclipplanesforpanel(); ssgCullAndDraw(panel); Does this make sense? Setting up a seperate scene graph? Perhaps it should be called cockpit so that a 3d cockpit can be added. Now I just have to figure out where to start :-) Time to look at those ssg examples. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] RFC: Aircraft *-set.xml files reorg
David Megginson [EMAIL PROTECTED] said: David Megginson writes: My proposed solution is to add a layer of abstraction to every *-set.xml file. It will be annoying for John and me, but will make things simpler for everyone else. Hmm. On further reflection, this might cause trouble for properties that are tied, like /position/altitude, so it would have to be limited to things like the 3D model and input bindings. Perhaps a cleaner solution would be to extend FlightGear to use multiple root paths. For example, if I had FG_ROOT=/usr/local/lib/FlightGear:$HOME/.fgfs/ then $HOME/.fgfsrc/Aircraft/dc3-yasim-set.xml could contain properties overriding some or all default values from /usr/local/lib/FlightGear/Aircraft/dc3-yasim-set.xml. This same question occured to me when working on the panel stuff. It seems as though the -set.xml files are used to select fdm and aircraft type. On the other hand panels and skin models are similar by aircraft type but not across fdm's. So why not have a -model.xml file that defined the panel and skins parameters and locate it in the Aircraft/(aircraft model) directory? (e.g. $FGROOT/Aircraft/dc3/dc3-model.xml) By modularizing a little bit, the multi-root concept work quite nicely. The only potential idea this would not address is the possibility of having multiple skin models and panels in the distribution that we want to be able to choose from the PUI menu or by key binding. It would be nice to be able to change the skins on the fly, and I'm thinking that a list of available skins could be stored and then copied in to the model/path property. If these were listed in the -model.xml file, the first one in the list could be considered the default. Then the question would be should the secondary root (eg $HOME/.fgfs) be considered a complete override, insert in front or add on to the back of the list. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
Curt, Thanks, this has been very helpful. Been playing around with ssg a little bit and trying to gleen some sort of understanding from the documentation, which is very good but in some cases terse. It looks like the panel graphic objects will need to all be ssgTransform nodes so that they can be rotated, etc. Somehow I need to come up with a system for keeping track of which nodes belong with which instruments so the coordinates can be manipulated. I'm assuming that I will need a node for each individual part of each instrument (ie several nodes for some individual instruments). It's not clear how I can group together the components that make up a given instrument (or even if I should!), so that say a major branch (if there is such a thing) would have multiple ssgTransform nodes on it all belonging to the same instrument...e.g. HSI. Anyway, what I'm trying to do here is outline where my thinking is going so that I can get this fairly right the first time. Mostly I'm interested in whether anyone else has ideas on organizing the scene graph tree. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: David Megginson writes: Jim Wilson writes: And the question that brings to mind is, how will we be able to set the z axis in a way that it can handle the panel? In other words, the scale is so large now that it'll disappear just like airplane model components do when viewed too closely. Can we have two different scales in the same tree/graph? Actually, I'm not sure -- any advice from the PLIB gurus? I'm not sure about your definition of the z axis ... in this case your question makes sense if we define the z axis to be along the center of projection. This really is more of an opengl issue than a plib issue. Opengl defines the view volume to be a frustum (just like a pyramid with a bit of the top lopped off.) You can refer to the picture here for an example: http://www.cs.ucf.edu/~moshell/CAP5725/CAP5725.week4.html So if a portion of the scene is closer to us than the near clip plane, it will be clipped out. That is what happens when you get the external view point too close to the aircraft. Similar wierdness if you set the far clip plane too far away and then get too close to the ground. The good news is that you can reset the clip planes at any time during the rendering process meaning you can render a portion of the scene, then move one or both clip planes, and redraw another portion of the scene, continuing this as much as needed. The bad news is that certain driver optimizations can get screwed up if you move the clip planes (ie. the fog tables in some versions of mesa). Or the driver may be forced to recompute things like fog tables and other values when you change the position of the clip planes. Thus, there can be visual artifact and or performance implications with moving the clip planes. Also, be aware that the precision of the depth buffer is *very* sensitive to the position of the near clip plane: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html The conclusion is that for best depth buffer precision we want to push out the near clip plane as far as possible. The position of the far clip plane is mostly irrelevant, although it has to be beyond the furthest object we want to see. :-) So the point of all this is that we can draw the world, then move the near clip plane in, and then draw the panel. This would work best if we put the panel into a different scene graph from everything else: setclipplanesforworld(); ssgCullAndDraw(world); setclipplanesforpanel(); ssgCullAndDraw(panel); Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
BERNDT, JON S. (JON) (JSC-EX) (LM) [EMAIL PROTECTED] said: From: Michael Basler [mailto:[EMAIL PROTECTED]] Hi, I just received a problem report from a German user on the released version 0.7.9 which I - unfortunately - was able to confirm in part. 1. Start at CL77 Santa Cruz leads to an immediate crash. 2. He reported a crash at Munich EDDM at start (e010n40 installed) which I could not confirm. 3. However, Start at Innsbruck LOWI gave me an immediate crash, too. OK. Has the NTSB been called to the scene[s], yet? :-P Jon Hope they disconnected the usb Flamethrower first :-) I'm getting the same thing with CL77. Some screwy looking airstrip. There still seems to be some problems with altitude between fg and jsbsim. A workaround is to add a --alititude=(runway elevation) to the command line. This perhaps is a naive question, but why aren't we kicking in the FDM after the plane is on the runway during initialization? It seems like there's a lot of trouble trying to get an FDM synced up with scenery/airport data during startup. Why is it that flightgear doesn't just put the plane where it goes and dictate the coordinates at startup (or reset) and let the flight model (re-)initialize with those values? It's pretty obvious that when there's a gross discrepency in elevation data (as with CL77) the FDM has kicked in and the plane is stalling and drifting down to the ground...hence the crash. I guess a side question is to this is why don't the FDM's freeze the lat+long+alt when the parking brake is on and the ground speed is 1? And keep it frozen until the brake is released. Seems like that'd be an easy way to stop the creeping that some people have complained about. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
Tony Peden [EMAIL PROTECTED] said: Did my 'fix' to fgFDMForceAltitude() get in to the 0.7.9 release? Not sure but I think it did. I'm testing with cvs (as of yesterday or so). Anything I can do to help? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
John Wojnaroski [EMAIL PROTECTED] said: Certainly not, when it's gross weight is 800k lbs. :) The weight you quote is close to the zero-fuel weight, which is typical for landing. By default, YASim will top your tanks off at startup. The plane in this condition will indeed have a very high approach speed. Try setting the /sim/fuel-fraction property to something like 0.2 for a reasonable approach configuration. DUH!! (sound of slapping) I knew that! ;-) IIRC the 747-400 comes down pretty fast anyway. I think you're looking at 195 KIAS range for final dropping down to 175 KIAS (with full flaps) at the outer marker. But note again, this is from memory. Still, there is no way that pig flies at 150. The biggest problem I saw with that model was the issue it had with climbing (ran out of climb speed at too low an alititude). IIRC it should climb at least 500fpm even above 30,000. Has that problem been addressed? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
David Megginson [EMAIL PROTECTED] said: Andy Ross writes: The effect is happening because the aircraft isn't consuming fuel. If you take off at full tanks, you never get any lighter. A real aircraft would have burned off a big chunk of its fuel store in the climb, and would have an easier time of it. As a workaround, try starting /sim/fuelfraction at 0.5 or so, to simulate an early-to-mid-flight cruise condition. It should climb much better. Fuel consumption in YASim will get done RSN, I promise. That's a good point. I remember reading an article where the author sat in an A340 cockpit on a London-Vancouver flight; it wasn't until around Greenland that the plane had burned enough fuel that it could climb to full cruising altitude. Yes agreed. And probably with a 747-400 it is only those longer flights like London-Vancouver that get filled to the brim with fuel. Andy, is the aircraft otherwise considered filled to capacity (passenger/cargo) in the fdm? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C 172 panel
Sergio Roth [EMAIL PROTECTED] said: Hi, I´ve found this panel and it seem to be very cool. What do you think ? http://www.avsim.com/pages/1000/dreamfleet/dffull.jpg Yes, I saw that one not too long ago. Very nice vinyl texture. And the metal panel area itself is pretty darn near perfect, lots of nice touches including just exactly the right shine. It looks like it'd be an expensive one performance wise. Yeah that sure is a cool panel. It's not a c172r, but given enough effort something like that could be done. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Model Configuration Changes
David Megginson [EMAIL PROTECTED] said: Instead, if the /sim/model/path property points to a file ending with .xml, the FGAircraftModel class reads a property file at that location to get information about the 3D model. Initially, the following properties are recognized: /path The path to the model, relative to the XML file (not FG_ROOT). /offsets/heading-deg The heading rotation for the model, in degrees. /offsets/pitch-degThe pitch rotation for the model, in degrees. /offsets/roll-deg The roll rotation for the model, in degrees. /offsets/x-m The x-axis transformation, in meters. /offsets/y-m The y-axis transformation, in meters. /offsets/z-m The z-axis transformation, in meters. Great improvement! One thing I noticed as soon as the c172 model went in was that the offsets affected every model that didn't have offsets defined in the aircraft-set.xml file, simply because they were included in the c172-set.xml file that always gets processed by default, even if another aircraft is selected. Does this address that issue? If I switch to a different model in my command line will the offsets for the default model go away? Another question that came to mind (and I apologize in advance if it's a stupid one!): Is it possible to eliminate the requirement of offset values with models built for the base package distribution...ie can we convert all the vertices in the *.ac files so that it isn't necessary to use them? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Curtis L. Olson [EMAIL PROTECTED] said: David Megginson writes: That said, it might be possible to animate the X-15 model that we already have, assuming that the various objects in the model are named. I haven't looked at pretty-poly lately, but it might not be hard to load up the model and assign names to sections (or at least shouldn't be all that hard once pretty-poly is 'finished'.) :-) If someone really wants to do this I'll be glad to load it in my ac3d and name the parts. Just need someone to tell me what to call what (e.g. the flap that opens out of the left side of the upper vertical stabilizer is: blah blah). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Broken Code
John Wojnaroski [EMAIL PROTECTED] said: Excuse me, but if you go back you will see that I allowed to the fact that I was unclear on the idea of the properties, but was willing to give it a go. If this is truely an open source project then other ideas and opinions need to be honored, not just the few with dictatorial commit authority! That doesn't sound quite right from my experience, but i should also say this: Even though these concepts and ideas get discussed on the list often the final decision seems to be done off list. It might be good for someone to pre-announce when they are going to remove or rewrite a major class. While I've seen projects get ruined by too much central authority, personally I appreciate the help of people who already know the project and have a sense of where things ought to be going. I think the FlightGear project strikes a very nice balance. Property names do change occasionally, but the breakages those changes cause are much less violent (and easy to debug using the property browser). I don't agree with that. IMHO that might be true if one is already cognizant and comfortable with the architecture. C++ is a common reference point and moving away from it adds obfuscation. And the more I think about it the less I like it. If one is writing code for a small group then properties might be okay, but in a larger group and open source efforts it seems that changes need to move more slowly and at a more measured pace Having used the property system to learn what I have so far about the code and debug some of it, I'd have to say it helps. Or at least it is more convenient...sort of like having a built in debugger. On the other hand it can badly obfuscate some of the workings since they are not classified the way C++ objects are. As Curt has mentioned recently, we do plan to remove most of FGInterface as well, when we have the chance; we are able to test that nothing in the FlightGear code base breaks, but obviously, we have no way to test external code. Whoa! The arrogance of it all. Sounds like the microsoft way. Do it my way or no way. If your code breaks it's your fault. No the microsoft way is: Yeah we broke that on purpose so you'll have to buy more of our products :-D Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Model Performance and dc3 donuts
The new model animation is very cool so far. One thing I did notice is that there seems to be significantly greater CPU overhead when running these models as opposed to some of the msfs models I've tried. When taking off in chase view there's a great deal of interuption in the sound. Also and this might be a clue, the frame rates run almost double what the same exact view provides with the MDL models I'm using. So it seems like Dave's models are easier on the card but harder on the CPU. Note that I tried this without any animation enabled and the result was the same. Higher frame rate but more breaks in the sound (in fact more silence than sound). Also noticed the rudder control seems to be broken on the dc3 at the moment. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Model Performance and dc3 donuts
John Check [EMAIL PROTECTED] said: I noticed that sometimes the dc3 will get into a rotation on the ground sometimes, especially after a reset. Maybe this is what he is seeing. TTYL J Yep. It does. Applying both brakes seems to stop it. The rudder to brakes binding doesn't seem to work quite right...not sure why yet. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
David Megginson [EMAIL PROTECTED] said: Martin Dressler writes: There is a problem with propeller. With low frame rate I couldn't see diferents between low and high RPMs. Even with a fairly good framerate the prop doesn't look so good yet. What we need to do is switch to a different, blurry-disk object once the RPM hits a certain level, but I probably won't get to that for a little while. I think you can have a single disc object just in front or behind the prop and just adjust the alpha channel (warning: dumb suggestion from someone who's still reading the opengl book :-)) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Product Reviews [was: Model Performance and dc3 donuts]
Andy Ross [EMAIL PROTECTED] said: at all. Definitely recommended. One one caveat: it's USB response is slower than the spec allows, so the linux driver doesn't work out of the box. You need to enable the slow USB devices option when you compile your kernel. The default Red Hat kernels appear to have this Is that the USB_LONG_TIMEOUT option? There isn't a SLOW USB DEVICES setting that I can see. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Product Reviews [was: Model Performance and dc3 donuts]
Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: Andy Ross wrote: at all. Definitely recommended. One one caveat: it's USB response is slower than the spec allows, so the linux driver doesn't work out of the box. You need to enable the slow USB devices option when you compile your kernel. The default Red Hat kernels appear to have this Is that the USB_LONG_TIMEOUT option? There isn't a SLOW USB DEVICES setting that I can see. Uh, yeah, that. :) Andy Hmmm...interesting. I was looking at the Saitek at a local big box store recently. Was concerned about getting it going under linux. Only problem now might be desk space. If nothing else this is one really cool looking controller, bound to impress the ladies :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 model now animated
David Megginson [EMAIL PROTECTED] said: The DC-3 3D model now has the following surfaces animated: Looks really cool! I think right elevator and inner right flap might not be working. Or maybe I banged them up during my sloppy take off :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Problem in current CVS
Jon Stockill [EMAIL PROTECTED] said: Ah! That doesn't appear to be zapped by make clean Nope but make clean-deps does. Maybe we should include that in the cvs building instructions? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] JSBSim changes
David Megginson [EMAIL PROTECTED] said: Tony Peden writes: I certainly like the idea of having some sort of units indicator on every property name, though I agree risk of breakage is high in this case. I can change everything in FlightGear and the base package, but I'm worried about breaking people's private config files, especially for joysticks. It isn't a percent unit either on the controls. Per Cent means per 100. That is getting ridiculous IMHO and I for one would prefer the control names do not get changed. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim changes
Tony Peden [EMAIL PROTECTED] said: On Thu, Feb 28, 2002 at 10:25:36AM -0800, Andy Ross wrote: Tony Peden wrote: David Megginson wrote: Tony Peden wrote: I certainly like the idea of having some sort of units indicator on every property name, though I agree risk of breakage is high in this case. I can change everything in FlightGear and the base package, but I'm worried about breaking people's private config files, especially for joysticks. Well, leaving them as they are certainly won't be a problem for the current developers -- the units for those have been percent for as long as I can remember. And percent are non-dimensional, so no units indicator is probably just as correct as -pct or -nd or whatever. I agree in general. I'd suggest the use of -fraction or somesuch instead of -pct if the range is 0:1, as it is for most of these properties currently. Even non-dimensional numbers need units to tell you how to interpret them. Sometimes percent really is more appropriate; consider N1 and N2 turbine speeds. OK, if you really want to save percent for 0-100 quantities, how about something a little shorter than -fraction, -ratio (-fraction is perfectly good, just long) But if those settings don't represent a form of units--just arbitrary values, why do they need a suffix? The suffixes were intended to reflect units and make sense only when they mean something, like knowing if the value is in feet or meters, degrees or radians, knots or fps. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim changes
Tony Peden [EMAIL PROTECTED] said: To me, no units specified does not automatically imply non-dimensional. It means I still have to ask what the units are. I haven't had this problem in trying to understand these values, but maybe I've just been programming too long. :-) To me, items under the controls category intuitively indicate the potential value within a range of -1 to 1 (except sometimes its 0 to 1!). Calling them something isn't really going to increase the understanding of their meaning or use. Other items such as /autopilot/config/elevator-adj-factor and autopilot/config/integral-contribution have no semantic meaning to someone who isn't looking at the autopilot code. Perhaps integral-contribution does have a meaning, but you still need to look at the code to see where it is applied...in effect asking what it is. On the other hand it is really useful to be able to look at a number and know if it is fpm, fps, or knots! Anyway, thats all I have to say. Think I've already overextended my 2 cents worth! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 310 flaps?
David Megginson [EMAIL PROTECTED] said: Andy Ross writes: Heh, bingo! First google site I tried: http://www.photovault.com/Link/Technology/Aviation_General/TAGVolume04/TAGV04P03_09.jpg Perfect -- that's just what I needed. So the flap will not be visible at all from the top of the wing -- it's strictly underneath, as far as I can see. Searched cessna+c310+flaps on google and got this artists conception(?) of landing configuration from the rear: http://www.flightsimdownloads.com/premier/c310/c310fly.htm Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear first impression
Danie Heath [EMAIL PROTECTED] said: forward to some nice developments. As a fan of anti-Microsoft bans, I can't wait to screw Bill Gates and his company with this amazing piece of software. OT We have a lot to thank Bill Gates for, including the way he (especially) and others got under Richard Stallman's (and others) skin with their shrink-wrap revolution. We owe Bill a debt of gratitude for making sure that open source became a popular idea, even for windows users and developers. :-D Mainly it's just fun to work on something great that's unencumbered by business goals. Welcome! /OT Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot update
Hi Curt, Wanted to make sure I was familiar with all the functions in the autopilot code before making a lot of changes. So to that end I did some work on the gui interface to the waypoint stuff and checked out the waypoint following to make sure it is still working. Description of changes: These changes add to the Add Waypoint dialog so that you can see the entire list in the pui dialog that you are adding to. Also made some minor changes so that the autopilot is now activated (toward first waypoint target heading) when a waypoint is added. Tar file of changed modules (current with CVS as of 03-03-2002 13:18): http://www.spiderbark.com/fgfs/autogui-20020303.tar.gz Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plane above the runway
Alex Perry [EMAIL PROTECTED] said: As far as I'm concerned, the outside view is purely for entertainment since there is nothing realistic about hanging a couple dozen feet behind the aircraft in the open air, operating the controls remotely. Hmmm purely is one of those tricky words. There's nothing realistic about sitting at a pc flying a plane either. And besides, lots pilots out there take lessons and fly real planes for entertainment :-) Also, I think the external view provides a good substitute for the realworld vision and feel that are critical to the last few seconds of flight. It compensates for something else that can't easily be modeled on the typical dekstop. I tend to like it for the takeoffs as well. There are lots of things found in flight sim programs or games (like my mini panel) that cover for some shortfall in what can be rendered 3D on a single screen pc. That said, I'm not sure that animating models serves a purpose like that...but like you said it could be useful in certain applications. For me, learning about 3D modeling is enormously entertaining and interesting. And besides it'll probably attract some new interest in the project. In addition to prop pitch: When we put a 3D human inside the cockpit, please have the head articulate to match the view direction. Also, plan ahead to connect the navigation, landing, taxi, anticollision, strobe, cockpit, panel, nightglow (I've probably missed some) light switches on the cockpit panel to associated features in the model. Finally, is now a good time to mention the operating system specific pilot 3D model, with the passenger seats (to the extent available) filled with the 3D models of our other supported operating systems ? All it needs is for the model to have hooks indicating seat positions, and a model directory in the base with one model per operating system. Err umm...Huh? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plane above the runway
Alex Perry [EMAIL PROTECTED] said: the instrument panel, dubious maneuvers apply a brown overlay to the passenger seats ... hehe...what's the property for that? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
David Megginson [EMAIL PROTECTED] said: I don't think this is an easy option, at least not with a true 3D model wrapped around the viewer. We'll have to find a more robust solution. To start, I can make the depth buffer 0.1 only when the interior model view is enabled, so no one loses without it; old hardware probably won't do well with the interior view anyway. Ummm...why not clear the z-buffer and use a seperate scene graph? Note that there are *lots* of people using pre-geforce generation hardware. Probably more than not. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Curtis L. Olson [EMAIL PROTECTED] said: David, Assuming all of this is being drawn via plib/ssg then you could put all the geometry in a separate ssgRoot node and call ssgCullandDraw() on this root after everything else has been rendered. We have a couple ssgRoot's already so we can have some high level control over sorting geometry ... sky, terrain, lights, cockpit ... Regards, Curt. Please, yes. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on TechTV
Tony Peden [EMAIL PROTECTED] said: Well it turned out to be more of a piece on open source gaming in general and they didn't do much more than show the website. They did, however, have good things to say about FG and the exposure was really cool. Oh well. One of my websites appeared on an ecommerce thing they did on there once, but they didn't even mention what it was...just gave us 1 second of footage. Strangest thing is I don't even get techtv here. Was just sitting in a hotel room in Portland and it came on the screen. It is great that opensource gaming is getting some exposure in the popular press as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question
Hi Mark, What I do is update occaisonally (once or twice a week sometimes more) and keep an eye on the logs (the web based ViewCVS is handy too) in order to know what others are working on. Before sending in code I'll update to current CVS again and make sure things still work. It is much easier for Curt and Dave if you've taken care of any merges and send in code that works with latest CVS. Best, Jim Boslough, Mark B [EMAIL PROTECTED] said: Now that I am modifying code, I have the need to keep it updated. I am a beginner at CVS, so I'm not sure I am doing things properly. Should I be doing CVS updates every day? That requires that I completely recompile and relink every day, is that correct? I want to make sure that I am organizing thinks in a way that doesn't cause me a lot of extra work at some point. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Runway plow
Noticed that the c310 has its wheels below pavement. Is it ok to readjust the models for a recent change or is this a temporary? Or am I the only one :-)? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c310u3a
Oops forgot the screenshot: http://www.spiderbark.com/fgfs/bluecanoe-takeoff.png ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Sounds like it'd be useful for debugging aircraft and autopilot configs too. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: Tony Peden writes: In my day job, my own experience has been that real-time plotting is useful when you know exactly what you are looking for and you only need to see a limited number of parameters. The rest of the time, recording the data and plotting after the fact works out to be better. That said, it *would* be a very cool thing to be able to do. Yes, this would be no substitute for data logging and post processing, but if you know what you are looking for, I do think it could be useful. The immediate thing that comes to my mind is this: As a side project I'm working on integrating a 'commercial' fdm with FlightGear via a network interface. One of the things this code supports is control loading. The hardware guys are chomping on the bit wanting to know what range of values the software is going to kick out. Something like a quick and dirty embedded graphing program would be pretty nifty. cout probably works just as well, but it's not as pretty. :-) And once you had the basic graphing mechanism in place, it would be trivial to let the user specify which property(ies) to graph. Maybe we could even hook up the GUI prop-picker to specify which values we want rather than forcing the user to type them all in. FWIW, I think it's important for the FDM guys to frequenty fly their code in real time. In real time with visuals attached, various incorrect effects and behaviors can really jump out at you ... stuff that you'd never notice when looking through tabular data, or even a graph. Sometimes the trend is correct, but the scale or the sign is way off. I would think that being able to fly in real time, and see some key graphical data output would be an immensly useful debugging tool. For instance, nosing over the c310 causes it to go into an infinite acceleration cycle. Hmmm I wonder of that is drag related? Ok, pop up a live graph of thrust, nose over, watch the graph with everything else going on. Nope, drag looks good. I wonder if it's thrust related. Oooo, look at that thrust go off the chart ... ok now let's graph some individual propellor/engine parameters ... etc. etc. That's how my mind works anyway ... :-) Curt. -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Virtual cockpit notes
FWIW thought I'd make a few comments on the new 3D view stuff, realizing that it is still being worked on. While the commercial sims give a 3D feel to the cockpit they aren't always attempting to be true models. In this screenshot from fs2k, note that while the perspective (eye to panel) is ok, the left piller is missing to give better viewing with 3D mapped to 2D display...where the pilot cannot move their head to change the view. It looks like there are a lot of photo textures being used. It also appears that the perspective is not consistant with the exterior view angle. In some cases it makes sense to do this so that you can see the panel pretty much straight on (necessary to read the gauges) and be able to see the runway well. The yoke must get in the way though (you can't lift your chin and look down over to see a gauge): http://web.ukonline.co.uk/members/dmarch/images/fs2k.jpg This screenshot of a 747? panel shows little concern for 3D realism, but is a highly functional and usable panel. There's only so much you can do with guages anyway. The view perspective gives the computer pilot a straight on view of the panel: http://www.simaviator.com/screen/iam/30.jpg These are in Fly!. And I have to say that the Fly! panels are the ones I like the best. It isn't just the graphics and 3D modeling, but the fact that the panels are unrealistically close to the (in 3D world) pilot's nose and the perspective is always straight on (the same plane). What is rightly sacrificed in realism makes them look sharp, and of course readable. The panels scroll very much like the current 2D FlightGear panels: http://www.intelligamer.com/features/qa/fly/fly03.jpg http://www.avsim.com/pages/1299/fly/capt1pnl.jpg Note that when you change the 3D cockpit view angle in Fly!, the panel in effect becomes disabled and as far as I can tell is just a static texture on the front wall of the aircraft model interior. The knobs and controls are hard enough to see and control using a mouse with a straight on view, let alone when 3D perspective angles are mapped to 2D. Anyway, just thought I'd bring these ideas to the discussion in case they are of any value. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Wolfram Kuss [EMAIL PROTECTED] said: I agree, full 3D is the way new sims work and FGFS should have that as well and not implement now a feature that was state of the art some years ago. Fly! is a 3D cockpit. I was talking about usability, and IMHO it is a more usable panel because of its inaccurate eye point when in use. Just as the panel disappears when you use the mouse scrolling and reappears with a click, it'd be easy enough to snap to an operational centered viewpoint. There may be small artistic freedoms to make things more legible, for example shadows on gauges that partly and non-uniformly shadow digits on gauge faces can make it more realistic and pretty, but harder to read. Also, if in reality there is much space between gauges, you can increase the size of the gauges. Yes, unfortunately reality occurs in much higer resolution than even the best monitor can deliver. How about when the sun is right in your eyes and you can't see anything, even with sunglasses? It amazes me sometimes that people define reality in 3D as being something that looks like it was done with a video camera. To me its a more realistic experience if the gauge I'm looking at can easily be used and is closer to what it would be in size and perspective from my eyes sitting in the chair, not the camera's little box on the screen. I also love a fully 3D, fully functional, fully clickable cockpit. But it is a lot of work, more than exteriour models. Also, an artist can make an exteriour model without help from a coder. If an aritist does a 3D cockpit that holds a switch or gauge or whatever that has not been coded before, he needs the help of a coder. Yeah they are pretty cool, but for me once you've got them figured out (solved the puzzle and repeated it a few times) it's pretty dull. When I first got Fly! a couple years ago I used it a lot for a few months. Now I just dig it out when I'm interested in how the developers might have done something. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
David Megginson [EMAIL PROTECTED] said: As far as I can figure out, there are only three situations we need to deal with in the viewer code: 1. Looking away from a known position. 2. Looking towards a known position from a known distance and angle(s). 3. Looking from one known position towards another. All of the views can still be managed by the view-manager class (a proper subsystem), but we should try to remove all hard-coded dependencies from the rest of the FlightGear codebase. For example, the scenery code doesn't need to know which view is in use; it only needs to know where the coordinates and VIEW matrix for the camera. Comments? Volunteers? I think that the easiest solution is probably a clean rewrite, but paying close attention to how Norm used the matrices and vectors in the original. This sounds interesting. Let me think about it for a bit and come back with sample properties in xml format. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
David Megginson [EMAIL PROTECTED] said: In every case, we want to be able to specify offsets for all six degrees of freedom. I think that it makes sense to put all of this in a single, configurable viewer class, rather than having separater viewer_lookat, viewer_rph, and (eventually) viewer_tower classes that duplicate most of each-others' code. At first look this doesn't seem all that bad. The hardest part is going to be cleaning up the hard coded bits out there. The routines basically all produce the same thing with different methods which helps. Right now what I need to do is map out all the calculations that are being applied and will come up with a proposal to post here. But it should be too bad once I get my head around the whole thing. Basically what I'm going to look at is modularizing the calculation for each matrix component (camera, center, up) so that new methods like some of what Michael described can be easily added. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley [EMAIL PROTECTED] said: The preferences file is not FDM specific at all. The contents of preferences.xml in the base package are for the most part self explanatory, I have to beg to differ on this one. For those few command line arguments that I have used, I can find mappings in the preferences files. Where I do not kow the command line arguments, the preferences file is not very clear. For example: instrument-options nav n=0 has-gs-needle1/has-gs-needle needles-pivot1/needles-pivot /nav nav n=1 has-gs-needle0/has-gs-needle needles-pivot1/needles-pivot /nav hsi n=0 has-gs-needle1/has-gs-needle /hsi dg style0/style /dg /instrument-options Hehe. Yep. Didn't notice that one. Actually I don't know why that would be in the preferences.xml. Anyone know why that isn't in the panel or at least aircraft-set xmls? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ANN: first experimental 3-D cockpit
David Megginson [EMAIL PROTECTED] said:
David Megginson writes:
3. The orientation is incorrect when the view is not straight forward
and the plane is not flying level (waiting for a fix from me, but I
don't understand matrix math well enough) -- that means that when you
look out the side window during a climb or turn, the model will not be
tilted correctly.
Further to this point, could someone who understands matrix math take
a look at src/Main/model.cxx, in the update() method? Where I have
if (view_number == 0) {
// FIXME: orientation is not applied
// correctly when view is not forward
sgMakeRotMat4( sgROT, -pilot_view-get_view_offset()
* SGD_RADIANS_TO_DEGREES, pilot_view-get_world_up() );
sgPreMultMat4( sgTRANS, sgROT );
}
I'm trying to keep the model from following the view around.
Obviously, I have to do some rotations in other planes as well, but
I'm not quite sure how to do it.
Think you have to decide which up vector to rotate. With the pilot-view the
world up vector gets rotated around the x and y. And with model view it gets
rotated around the same for the model's up vector. So pick one and it should
look fine. I guess I would recommend leaving the model fixed so that the
panel isn't bouncing all over the place. That alone would fix the problem.
As far as the matrix math, I think I know what to do, just not sure where the
model rotation is getting applied...see a possibility, but have to head out of
town now until tonight. Basically it is a matter of finding it and not
applying rotation to the model. I can see how getting all this into a single
view class would help here :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Property Logging
David Megginson [EMAIL PROTECTED] said: FlightGear now has the ability to produce multiple logs, each recording the value of user-selected properties at a user-defined interval. Details are available in docs-mini/README.logging; Here's a simple example that logs the rudder and aileron positions to steering.csv every second or so: logging log filenamesteering.csv/filename interval-ms1000/interval-ms entry titleRudder/title property/controls/rudder/property /entry entry titleAilerons/title property/controls/aileron/property /entry /log /logging Here's some sample output: Time,Rudder,Ailerons 6522,0.00,0.00 7668,-0.00,0.00 8702,-0.00,0.00 9705,-0.00,0.00 10784,-0.00,0.00 11792,-0.00,0.00 12808,-0.00,-0.21 13826,-0.00,-0.344000 14881,-0.00,-0.066000 15901,-0.00,-0.806000 16943,-0.00,-0.936000 17965,-0.00,-0.534000 19013,-0.00,-0.294000 20044,-0.00,0.27 21090,-0.00,-1.00 22097,-0.00,-0.168000 Cool! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hack for Virtual cockpit problem
David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: This seems to pretty much correct the problem. Part of the problem is that rotations are occuring at the firewall (model origin) which seems a little un-natural inside the cockpit. The rest of the problem is I am just learning how this stuff works (I know I've been saying this for a couple months now...but hey I'm slow :-)). Thanks -- the internal cockpit view seems much better. Now the ball's in Andy's court to patch up the virtual panel code (and de-quat the mouse code), and we're flying! It's still a little weird with a steep roll angle. Found an article on quarternions. It seems that they can be used to solve the problem of the rotation being off center. Not sure yet how to apply it to this problem. Maybe if we can feed it an axis that appears a little behind the origin, apply the euler pitch, and convert it to a rotation matrix it'll move more realistically: http://www.gamedev.net/reference/articles/article1691.asp#Q47 Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Simplifying the Property Code
David Megginson [EMAIL PROTECTED] said: functions, and object methods. I think that I'm the only one using variable pointers (panel.cxx) static functions (fg_props.cxx), and no If I'm reading this correctly...I am using them in the autopilot code and the pilot-offset-not-to-be-confused-with-Jon's-definition-of-pilot-offset code (GUI/sgVec3Slider.cxx). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Hack for Virtual cockpit problem
Norman Vine [EMAIL PROTECTED] said: Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: So I say lets take a little time and discuss or 'High Level' conceptualization and the possible ramifications of the possible way of doing things before we just tear things apart just to fix the 'current crisis' This makes sense to me. I'm willing to take this one if for no other reason than to fully understand what we have. It'll take a few evenings though, so I just want to make sure that 1) this is a good first step in other's eyes and 2) someone else isn't doing the same exact thing. I don't care who does it However I STRONGLY suggest that the first pass is written in 'pseudo code' and posted to the Net somewhere for Review and Comment before anything is actually implemented. A Wiki would be ideal for this kind of thing :-) What I was volunteering for was something less ambitious. Basically just merging the pilot and lookat viewers, looking at the outputs and combining the ones that are essentially the same kinds of values, and mostly preserving how things work now. Not very ellegant, but by retreiving the bits and peices here and there that effect view data from various places in flight gear and putting them in one place (as a functional equivelant to what we have now), it'll be easier for people like me to know the extent of what's been done to date. And doing so should make it easier to design a complete rewrite for even those who were involved in building it. There will be some redundancy in the remaining bloated class, but we can sort that out in our rewrite. What would be achieved is a single interface that can be outright replaced, modified, and/or have a new class structure plugged in behind it. In a way its more of a patch to the other FG code that accesses view data. Pseudo-code is the next step after this on the way to a complete redesign, which is what is really needed. In any case, if this sounds like a bad idea to go to everyone, i'll hold off. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hack for Virtual cockpit problem
Andy Ross [EMAIL PROTECTED] said: It is not mutable by anything but the mouse code. I want a hat swtich to change view direction. This is not even vaguely possible with the current implementation (especially if you refuse to read properties from the mouse code -- properties are all the hat switch mapping can set). Yes, the mouse input needs to be seperated from the view code, no one disagrees. Could the features be gotten by augmenting and modifying your code? Surely; but my reasonably well-informed opinion is that it would be less work to start from scratch. I'm sorry that the general consensus seems to be to eject your code; really I am. But it just isn't useful to a lot of us. Neither is the view-offset/view-tilt stuff, for that matter. We need something new. Andy there's nothing unique about this situation. This has grown piece by piece and it is time to rebuild the view stuff. Norm's been telling us this, so the polite thing to do would be to read the list and tone down the attack. From where I sit, Norm's work is excellent...and I agree with Dave that we need to preserve his optimizations when possible. Where he's just thrown in something as a temporary patch (aka idea), he generally notes it in the code. Now its time to go back and clean it all up. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
