[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
* Martin Spott -- Thursday 10 November 2005 16:40: > I can't resist the suspicion that there's something wrong with the 3D > model. At least I get the glider to see and I yet didn't find yout why. > Several XML files and the AC file do have DOS line endings but this > doesn't cause the trouble I've already removed all of them, It tries to load $FG_ROOT/Aircraft/Instruments-3d/trim/trimwheel.xml, which doesn't exist. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Martin Spott wrote: I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Well right now there is no rascal specific dynamics model for any of our core fdm engines, so there's not really all that much to be curious about ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Martin Spott wrote: I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Martin. We went out and flew our Rascal today to collect some more video and data. I posted some pictures here: http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ We had very light / calm winds so I'm hoping the position/attitude/velocity data comes out pretty clean. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: docs/Model fgfs-model-howto.html, 1.4, 1.5
Hello Erik, Erik Hofman <[EMAIL PROTECTED]> wrote: > +href="http://www.flightgear.org/default.css";> [...] > + http://www.flightgear.org/";> src="http://www.flightgear.org/images/fglogosm.jpg"; alt=""> You probably might want to use references _without_ hostname here - like it's already done in all the other places, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Instruments/Textures radar_misc.rgb, 1.1, 1.2
Erik Hofman wrote: Modified Files: radar_misc.rgb Log Message: Add support for a storm blib Excellent. As far as I know, civilian airliners carry radar that is capable only of detecting weather, not small things like aircraft. They also use a separate radar system for ground separation (the radar altimeter). For traffic, they use TCAS, which is equivalent to secondary surveillance radar (i.e. it detects other planes only if their transponders are on, and does not pick up primary targets). I'm sure that some of the very newest airliners can integrate all of this information into a single multifunction display, but for most of the existing fleet, I don't know if traffic and weather would appear on the same display or not. Can anyone chime in with concrete information? I'm sure that military combat aircraft must have radar with primary traffic capability, since the enemy is sometimes too inconsiderate to turn on the transponder. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/f16 f16-3d-set.xml, 1.1,
Erik Hofman wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/f16 > In directory baron:/tmp/cvs-serv29648/f16 > Modified Files: > f16-3d-set.xml f16-set.xml > Removed Files: > f16-3d-jsbsim-set.xml f16-jsbsim-set.xml > Log Message: [...] You should also modify this one: isnix: 11:48:57 ~> head CVS/FlightGear/data/Aircraft/f16/f16-3d-set.xml ^^ This is no longer present, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim YASim.cxx, 1.20, 1.21
"Curtis L. Olson" wrote: > Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim > In directory baron:/tmp/cvs-serv14214/src/FDM/YASim > > Modified Files: > YASim.cxx > Log Message: > Jim Wilson: > > Remove some hardcoded dependencies between fdm, viewer and acmodel classes and > replaced them with property references. Fix roll offset in viewer. I'm sorry to say this but I can't resist to note that some of the changes in your patch reverted David's "the PA-28 rotates around it's nose" corrections. I know that you both have different opinions on which route has to be taken to handle this topic but I'd prefer that you still focus on a working result. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161 pa28-161-set.xml,
"Curtis L. Olson" wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > In directory baron:/tmp/cvs-serv24383 > > Modified Files: > pa28-161-set.xml > Log Message: > Move the center of the various views so they point near the middle of the > aircraft rather than directly at the nose. Thanks for your effort. Unfortunately, this is _not_ fixing for the current 'feature', Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161 pa28-161-set.xml,
Jim Wilson wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > In directory baron:/tmp/cvs-serv21723 > Modified Files: > pa28-161-set.xml > Log Message: > > Missed one. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models bo105.ac, 1.8,
Erik Hofman wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/bo105/Models > In directory baron:/tmp/cvs-serv17582/Models > Modified Files: > bo105.ac bo105.xml shadow.rgb > Log Message: > New updates from Melchior in the color of the day. Ooooh, I found the yellow one definitely nicer, it was a cute, coloured spot in the colloection of mostly uniform coloured aircraft, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models bo105.ac, 1.8,
* Martin Spott -- Wednesday 24 March 2004 16:40: > Ooooh, I found the yellow one definitely nicer, it was a cute, coloured > spot in the colloection of mostly uniform coloured aircraft, Hmm ... but the current one fits the seats better, doesn't it? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models bo105.ac, 1.8,
* Martin Spott -- Wednesday 24 March 2004 16:40: > Ooooh, I found the yellow one definitely nicer, it was a cute, coloured > spot in the colloection of mostly uniform coloured aircraft, Oh, well. Actually I like both versions. I just think that the yellow one got a bit boring already, and that the green one hides the lack of texture better. Once I've textured everything this won't be necessary, but changing colors will then also not be that easy any more. This was the last chance for some change. If more than one prefers the yellow bo105 (and the release date permits it) then I can change it back. It's just the difference between "make install" and "make install mil" for me. :-) BTW: planned are the following changes (probably, but not necessarily in this order) - finish position lights (top red in cvs; bottom red done here) - implement rotor disk and blend in at some rotational speed - interior: cyclic/collective, pilot, eventually medical config - external details (wire cutter, further antennas, ...) - texturing (no idea which livree; certainly not ADAC ;-) - more/custom instruments - bended blades(?) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/bo105/Models bo105.ac, 1.8,
Jim Wilson > > > "Curtis L. Olson" said: > > > Jim Wilson wrote: > > > > >How about this one? ;-) > > > > > >http://www.spiderbark.com/fgfs/barneymobile.png > > > > > > > > > > Is that the don't-ask-don't-tellicopter. > > > > Haha! Is this what they call aviation innuendo? What about > these folks: > > http://www.harrierpilot.com/oct01/purple.jpg > > They must be British. :::duck::: ;-) > Reckon that's a USMC Harrier. I would definitely duck if I were you ! Regards Vivian M. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models bo105.ac, 1.8,
* Jim Wilson -- Thursday 25 March 2004 01:54: > How about this one? ;-) > > http://www.spiderbark.com/fgfs/barneymobile.png That's a nice color, indeed. But it doesn't really go well with the Red Cross. I added it, because the long version of the Bo was constructed for use as rescue helicopter. The original model was only suited for short lying patients. BTW: one can turn the paintings off: --prop:/sim/model/bo105/painting=0 for use with extreme colors. :-) > BTW the cockpit looks great. I recently took it out chasing AI aircraft > around oakland airport. The flight model may not be 100% but it sure is fun > flying it. Nice looking beacon there as well. Thanks a lot. Texturing will improve the cockpit a lot. I hope that the shadow problem can be fixed some day (darker shadow intersection; lost shadows). m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models README, NONE,
Melchior FRANZ wrote: * Martin Spott -- Friday 26 March 2004 15:37: Ha, there is a funny effect: Did you ever fly a loop which shadowing enabled ? When I do this, I see the shadow flipping through the sky - similar to a meteorite :-) Whoops ... I'll look into it, but I don't promise a solution. (You aren't supposed to do loopings with unmodified BO105, let alone with a BO105CBS (which the 3D model is). BTW: Thanks for the colour (and the choice), a salomonian decision. Well, there were two votes for yellow, two for olive, and one for violet. Of course, my vote should count more, but then I thought that fgfs' first and only helicopter better not be a military one (given the violent state the world is currently in). But note that I despise pacifism as much as I love peace. :-) I turned the README file into a patch that can be applied: $ patch < README # switch to military $ patch -R < README # switch back to civilian m. PS: the military one is prettier! :-P ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel I vote for some medevac livery. They tend to be attractive an a flashy sort of way, and it gives you the opportunity to add all sorts of neat stuff in the back of the cabin to suck up that extra video memory. I also think that the military BO105s are pretty ugly with the missile sight tacked on over the cockpit and the TOW tubes just kind of bolted onto the side. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Propeller.cpp, 1.3, 1.4
Maybe I'm misunderstanding why you are doing this. Lower pitch angle, fast spinning prop. That doesn't makes sense? Best, Jim Andy Ross said: > Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim > In directory baron:/tmp/cvs-serv7517 > > Modified Files: > Propeller.cpp > Log Message: > Reverse the sense of manual propellers. Low numbers == fast > propeller, silly. > > > Index: Propeller.cpp > === > RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Propeller.cpp,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -C2 -r1.3 -r1.4 > *** a/Propeller.cpp 1 May 2004 00:25:56 - 1.3 > --- b/Propeller.cpp 1 May 2004 15:18:27 - 1.4 > *** > *** 63,67 > // base value. > if (_manual) > ! _j0 = _baseJ0 * Math::pow(2, 4*_proppitch - 2); > > float tipspd = _r*omega; > --- 63,67 > // base value. > if (_manual) > ! _j0 = _baseJ0 * Math::pow(2, 2 - 4*_proppitch); > > float tipspd = _r*omega; > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/737 737-set.xml, 1.4, 1.5
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/737 In directory baron:/tmp/cvs-serv16470/Aircraft/737 Modified Files: 737-set.xml Log Message: Property /sim/sound/audible renamed to /sim/sound/pause Individual aircraft -set.xml files shouldn't set global sound/volume properties for the entire application. Just for the record, this _used_ to be an aircraft feature to turn of aircraft specific audio events Erik Index: 737-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/737/737-set.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** a/737-set.xml 20 Mar 2004 16:39:11 - 1.4 --- b/737-set.xml 14 May 2004 15:54:22 - 1.5 *** *** 18,22 -true Aircraft/737/Sounds/737-sound.xml --- 18,21 ___ Flightgear-cvslogs mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Flightgear-cvslogs] [PATCH] Re: CVS: FlightGear/src/Controls controls.cxx,1.18,1.19
[re: FGControls::parking_brake] Melchior FRANZ writes: > Yes, you are right. That should be 1.0! > David, could you change this, please? Sorry for the inconvenience. Actually, it doesn't matter -- when the property is bound, FGControls will pick up the default property value anyway. I will change controls.cxx to set a default parking brake value in the constructor, though, just for consistency. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controlscontrols.cxx,1.21,1.22 controls.hxx,1.21,1.22
Arnt Karlsen wrote: > ..(during the Falklands War, the Britts tested refuelling of Harriers > and Sea Harriers, from ships, in-hover refuelling, believe I saw this > in Air Progress magazine in the mid 80'ies.) I think what you're remembering is the "Sky Hook" gadget that was developed but never installed on Royal Navy vessels. It was actually a full-service landing system, not just a refuelling boom. The idea was that the Harrier would come to a stable hover alongside the boat, and then be grabbed from above by the hook. It would then (carefully!) decrease thrust until it was just hanging there, and then be lowered onto the deck like cargo. I can't imagine this was very popular with the pilots. Imagine sweating during the (already very difficult) hover as some 19 year old sailor swats at you with a giant crane. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx,1.3,1.4 main.cxx,1.7,1.8
> Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main > In directory seneca:/tmp/cvs-serv14510/src/Main > Modified Files: > fg_init.cxx main.cxx > Log Message: > Updated from Norman to hack on clouds ... some progress. Hey, this still looks magic :-) http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D02.png Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear/Aircraft/c172'
> Does the R have a 40 deg flap detent? My understanding is that the 40 deg flap setting (over the whole family) is actually related to max gross weight. If you want the 40 deg then you will be limited to 2300 lb; if you make do with 30 deg ... you can have more. However, as the interior gets nicer, the avionics become more complete, you add long range tanks, a larger engine, retractable gear, etc etc ... you're adding empty weight, so that after a while 2300 lb is not enough. You're then _forced_ to eliminate the 40 deg setting to be able to fly. The last ten degrees _are_ mostly drag, but that's what you need (a) to get a steep final in rugged terrain (b) for fast descents in emergency management (c) for a relatively quick flare for short fields ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear/Aircraft/c172'
> I don't really object to that -- except that I wonder how many folks > will be able to really tell the difference. Surely, even in the real > thing, the differences are fairly subtle. I'm also not so sure that we > have the fidelity that making that distinction implies. I recommend the split, although I'd tend to move the "P" back to "N". Analogy: Think of driving two cars - one has carb engine, the other fuel injected (you really care in winter) - one has ABS, the other does not (only matters if you brake hard) - one has sports suspension and the other regular (only for bad roads etc) In normal city traffic, you won't notice the difference. However, for emergency stuff, if you forget ... you'll probably die. When operating at full performance (eg mountain roads for skiing) ditto. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear/Aircraft/c172'
Alex Perry writes: > The last ten degrees _are_ mostly drag, but that's what you need > (a) to get a steep final in rugged terrain > (b) for fast descents in emergency management > (c) for a relatively quick flare for short fields Speaking of quick flares, I'm finally getting the hang of *raising* the flaps to shorten my flare on shorter fields (not when the wheels are higher than a few inches above the runway, of course). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear/Aircraft/c172'
> On Thu, 2002-09-19 at 06:52, Alex Perry wrote: > > The last ten degrees _are_ mostly drag, but that's what you need > > (a) to get a steep final in rugged terrain > > (b) for fast descents in emergency management > > (c) for a relatively quick flare for short fields > (d) to keep %N1 up (for faster spool up) in a jet. I'd _love_ to have concern in a C172 (grin). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear/Aircraft/f16'
Tony Peden wrote: >>I think I've found what causes the instabillity in the F-16 model. It >>looks like the axis systems and me don't get along quite well. Somehow >>it always turns out to be different than what I've thought. > > > Well, hmm. Which system are you getting hung up on. Probably all. :-( I have to take a look at it some time. The F-104 file I sent you proves my suspection. It *was* wrong, and behaved exactly like the F-16. Now it works about right. BTW. DCmin should be CDalpha in that file. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Erik
Well, reading this piece of code, I don't see how it could work. see
below :
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.115
retrieving revision 1.116
diff -C2 -r1.115 -r1.116
*** fg_init.cxx27 Dec 2004 17:35:22 -1.115
--- fg_init.cxx29 Jan 2005 10:22:44 -1.116
***
*** 344,347
--- 344,353
if ( !aircraft.empty() ) {
Aircraft not empty here, otherwise the test had failed
SG_LOG(SG_INPUT, SG_INFO, "aircraft = " << aircraft );
This shouldn't change the aircraft variable
+ if ( aircraft.empty() ) {
useless test because aircraft is not empty ( see above )
+ // Check for $fg_root/system.fgfsrc
+ SGPath sysconf( globals->get_fg_root() );
+ sysconf.append( "system.fgfsrc" );
+ aircraft = fgScanForOption( "--aircraft=", sysconf.str() );
+ }
So the block above is never executed This is dead code.
fgSetString("/sim/aircraft", aircraft.c_str() );
} else {
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Erik Hofman wrote : Frederic Bouvier wrote: I can revert the patch or someone running windows should provide me a patch instead. Or do both, because the current patch seems useless. Is it windows specific ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Frederic Bouvier a écrit :
Erik Hofman wrote :
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Or do both, because the current patch seems useless.
Is it windows specific ?
This one seems better ( move the added block 3 lines upward ) :
cvs -z4 -q diff -u fg_init.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.116
diff -u -r1.116 fg_init.cxx
--- fg_init.cxx29 Jan 2005 10:22:44 -1.116
+++ fg_init.cxx29 Jan 2005 12:56:47 -
@@ -340,15 +340,15 @@
}
}
+if ( aircraft.empty() ) {
+// Check for $fg_root/system.fgfsrc
+SGPath sysconf( globals->get_fg_root() );
+sysconf.append( "system.fgfsrc" );
+aircraft = fgScanForOption( "--aircraft=", sysconf.str() );
+}
// if an aircraft was specified, set the property name
if ( !aircraft.empty() ) {
SG_LOG(SG_INPUT, SG_INFO, "aircraft = " << aircraft );
-if ( aircraft.empty() ) {
-// Check for $fg_root/system.fgfsrc
-SGPath sysconf( globals->get_fg_root() );
-sysconf.append( "system.fgfsrc" );
-aircraft = fgScanForOption( "--aircraft=", sysconf.str() );
-}
fgSetString("/sim/aircraft", aircraft.c_str() );
} else {
SG_LOG(SG_INPUT, SG_INFO, "No user specified aircraft, using
default" );
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Frederic Bouvier wrote: Frederic Bouvier a écrit : Erik Hofman wrote : Frederic Bouvier wrote: I can revert the patch or someone running windows should provide me a patch instead. Or do both, because the current patch seems useless. Is it windows specific ? This one seems better ( move the added block 3 lines upward ) : Ok thanks, it's committed now. Just a note to developers, only real patches are accepted from now on. All other suggestions on how to fix things will be silently ignored by me. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 11:14, Melchior FRANZ wrote: So then add a #ifdef for OS-X around the resize event, so that it is simply ignored? Did you send a bug report to the SDL people? I think you misunderstand, it's not an SDL bug: *FlightGear is relying on assumption about how OpenGL implementations work that does NOT hold on OS-X, and may not hold on some Windows drivers, but which happens to hold in the common case on Windows, and apparently always holds on Linux* There are plenty of SDL + GL applications on the Mac that do re-sizing just fine, but they have the ability to initiate a vid-restart (as they correctly should on *every* platform, strictly speaking) when re-sized. Of course, we can certainly live without the feature on Mac - just be aware the fault lies with FG / PLIB for not providing an API that is somewhat important in real-world situations. I for one would love to be able to switch from full-screen mode to windowed while running, for example. H&H James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 12:53, Melchior FRANZ wrote: Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's a suspicious comment in there: * WARNING, we need to make sure that the previous mode hasn't * already been freed by the video driver. What do we do in * that case? Should we call SDL_VideoInit() again? */ Would be nice if we could identify and fix the bug where it is, instead of removing a useful feature that is certainly *not* the bug. I'm going to restate the problem, just to be very clear. - When a window is resized, SDL (or GLUT) need to re-allocate the GL context. The SDL documentation explicitly mentions that SDL_SetVideoMode will be called again with new size, so a new context will definitely get created on the Mac. I'm putting aside any platform specific ways to modify existing contexts. - There is nothing (absolutely nothing) in the OpenGL spec about the sharing or lifetime of texture objects or displays lists across different contexts - logically they are completely separate. - The current FlightGear code assumes that display lists and textures are preserved across a context switch. - This has not been noticed for the past X years because it *so happens* that the Linux and stock Win32 implementations happen to implement the sharing behaviour between contexts, while OS-X does not. Both behaviours are completely valid and compliant implementations of the OpenGL spec. - Most (if I'm being bitchy, *good*) scene-graph / engine libraries have some kind of 'invalidate' button you can kick that makes them delete all their display lists / textures and reload them. This is what Unreal / Quake / etc are doing which you change full-screen-ness or many other graphics settings while they running, i.e a vid restart. - Making PLIB / FG support vid restarts would be a very good thing to do, but would be a lot of work and invasive. I would be happy to give it a go if I thought the patches would be accepted! - Until such a change is made, re-sizing the window is not going to work right on OS-X - We can live with this situation. But if there are any user bugs reported from Windows users with odd drivers about 'everything looking crazy after I resize the window', well, now you know :-) Regards, James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 20:52: For what it's worth, I don't like this patch. I find the hole more annoying. Unfortunately, I can't fix what you think is the real problem. Shall I revert for now? I'm not saying the hole isn't annoying, I'm just saying that there is a bug because for some reason, the sim thinks you are > 10 meters AGL when you are sitting on the carrier deck. There is some ground intersection problem going on there. If the ground interesection was computed correctly, the system would think you are < 10 meters AGL and everything would work the way it is intended. I'd really like for this to get fixed the right way. When we slap on bandaids without fixing the underlying problems, we end up with a system that has a lot of bandaids on top of a rotting infrastructure. Similarly whenever we see a stray crash or segfault we should pursue it with our utmost agression and stamp those out right away. Anytime we leave these sorts of crashes and problems for later, we end up with a system full of unexpected, unexplained, impossible to debug crashes. That kind of software is an incredible pain to operate. In the past I had more time to defend against these things, right now I don't. You've been granted CVS commit access so use your best judgement. I'd just hate to have this slip through the cracks, and when someone tries to land on an object that is 50.01 meters tall or more, they are going to get a hole again. We could just remove that check and leave the near clip plane in close all the time, but then our terrain rendering will really stink for anyone with a 16bit depth buffer ... It's not an easy problem, but slapping a bandaid ontop will probably mask it long enough so that the person who introduced the orignal problem will be long gone before we get bit again and no one will know how to fix it ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 22:02: You've been granted CVS commit access so use your best judgement. Yes. I don't usually touch such things, because I don't understand much of this. I did it anyway, because: - this change was already in cvs since a great while, and only had been reverted recently - the commit log of the reverting patch didn't explain why this was reverted; it was part of a completely different change and looked like an accident - I mentioned it in this message and got no reactions: http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/039285.html not that this is necessarily an agreement, but together with the other two reasons I though it would be OK, and better than the whole, which I consider a show-stopper. I'd just hate to have this slip through the cracks, and when someone tries to land on an object that is 50.01 meters tall or more, they are going to get a hole again. We could just remove that check and leave the near clip plane in close all the time, but then our terrain rendering will really stink for anyone with a 16bit depth buffer ... Andy (via IRC) has also looked at the code and suggested that the whole 'if' case is probably not needed any more. I just tested it, and indeed, with only scene_nearplane = groundlevel_nearplane->getDoubleValue(); scene_farplane = 12.0f; the hole doesn't occur any more. I'll be doing some more tests. But I won't touch that code again without explicit OK from an expert. :-) Just know that with the near plane set close in, there isn't enough depth buffer resolution on 16 bit cards to properly draw the terrain. If you look at mountains in the distance, you get lots of odd z-buffer fighting. This is on 16 bit cards. If we don't care about 16 bit cards any more (that used to be our only option in the old voodoo-1/2/3 days) then we could remove that whole if statement. For what it's worth, my laptop can only run FlightGear acceptably in 16 bit mode so I'm slightly worried about the ramifications of this change. Ultimately we *really* need to fix the above ground level calculations. Somewhere since the last release, that got broke and it must get fixed. If that was fixed you wouldn't be seeing a hole in the carrier deck. (And the AGL computations in the rest of the sim would start working correctly again.) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 22:22: Somewhere since the last release, that got broke and it must get fixed. If that was fixed you wouldn't be seeing a hole in the carrier deck. The bug was AFAIK there ever since we have helicopters. The same holes were on rooftops. Looking at the code (and only at the code) it looks more like a misunderstanding than a bug. What happens with the HUD is that it behaves like a normal instrument now (and not a perfect one) by that it specifies the AGL relative to the last known good elevation (the airport elevation). I assume it worked more like a radar that could precisely determine the AGL at the aircraft location. So what basically happens now is that at the (startup) airport the AGL would be reported correctly, but once the terrain elevation increases the reported AGL won't change (like in real life). Maybe we need a different naming for exact AGL (which is computed correctly BTW, but under a different name). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
> So what basically happens now is that at the (startup) airport the AGL > would be reported correctly, but once the terrain elevation increases > the reported AGL won't change (like in real life). This sounds more like HAA (height above airport) or HAT (height above touchdown). Height AGL should be the current height above the ground directly below the aircraft. Height AGL should change as the terrain below the aircraft changes. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Dave Culp wrote: This sounds more like HAA (height above airport) or HAT (height above touchdown). Height AGL should be the current height above the ground directly below the aircraft. Height AGL should change as the terrain below the aircraft changes. What would expect the HUD to display? I'm quite sure that the F-16 doesn't have a terrain database or an AGL radar. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Quoting Erik Hofman: > Dave Culp wrote: > > > This sounds more like HAA (height above airport) or HAT (height above > > touchdown). Height AGL should be the current height above the ground > > directly below the aircraft. > > > > Height AGL should change as the terrain below the aircraft changes. > > What would expect the HUD to display? I'm quite sure that the F-16 > doesn't have a terrain database or an AGL radar. So the HUD is displaying the height for the last known QFE ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Frederic Bouvier wrote: So the HUD is displaying the height for the last known QFE ? I think so. I suppose it just a barometric instrument with a digital display. It is synchronized by ATC reports. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Curt,
Is on my todo list for tomorrow (friday) since I saw Melchior's patch.
Greetings
Mathias
On Dienstag 04 Oktober 2005 20:52, Curtis L. Olson wrote:
> For what it's worth, I don't like this patch. It shouldn't make much
> difference on 24/32 bit cards, which is probably most everyone now
> anyway, but I think there is a different problem brewing somewhere.
>
> I haven't had time to look into it, but the AGL reading on the HUD no
> longer reads correctly. Somewhere along the lines we have introduced
> some sort of height above ground bugs. I don't know if that is in the
> ground cache code or elsewhere, but the HUD above ground display isn't
> working right anymore.
>
> If we get that problem fixed so the system knows the correct AGL, then
> we wouldn't need to make this particular huge hack 5 times worse.
>
> Somehow the gear still knows where the ground is, but I recall specific
> patches to the individual FDM's. I've lost track of what is going on
> with this section of code, but it's important and it really should get
> fixed before we get too much further!
>
> I'm going out of town on thursday and rushing to get a bunch of other
> stuff done in the mean time, so I really can't look at this in the near
> term, but someone really needs to volunteer to step up and track down
> what is going on here.
>
> Regards,
>
> Curt.
>
> Melchior Franz wrote:
> >Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
> >In directory baron:/tmp/cvs-serv754
> >
> >Modified Files:
> > renderer.cxx
> >Log Message:
> >prevent view through big hole in carrier deck
> >
> >
> >Index: renderer.cxx
> >===
> >RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/renderer.cxx,v
> >retrieving revision 1.27
> >retrieving revision 1.28
> >diff -C2 -r1.27 -r1.28
> >*** renderer.cxx 1 Oct 2005 09:56:53 - 1.27
> >--- renderer.cxx 4 Oct 2005 18:01:45 - 1.28
> >***
> >*** 499,503
> > - cur_fdm_state->get_Runway_altitude_m();
> >
> >! if ( agl > 10.0 ) {
> > scene_nearplane = 10.0f;
> > scene_farplane = 12.0f;
> >--- 499,503
> > - cur_fdm_state->get_Runway_altitude_m();
> >
> >! if ( agl > 50.0 ) {
> > scene_nearplane = 10.0f;
> > scene_farplane = 12.0f;
> >
> >
> >___
> >Flightgear-cvslogs mailing list
> >[EMAIL PROTECTED]
> >http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
> >2f585eeea02e2c79d7b1d8c4963bae2d
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
On Dienstag 04 Oktober 2005 22:17, Melchior FRANZ wrote: > * Curtis L. Olson -- Tuesday 04 October 2005 22:02: > > You've been granted CVS commit access so use your best judgement. > > Yes. I don't usually touch such things, because I don't understand much > of this. I did it anyway, because: > > - this change was already in cvs since a great while, and only had been > reverted recently > > - the commit log of the reverting patch didn't explain why this was > reverted; it was part of a completely different change and looked like an > accident Well, I reverted. Just because, as it was introduced the first time it was a workaround for something, at this time, hard to fix. At that time, the renderer had a different understanding of ground level than the gear code. I changed that at some time and removed the workaround. I thought that it was clear that it was a workaround, and I silently restored the old, more correct, behavour. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/sr20 sr20-set.xml, NONE, 1.1
Erik Hofman wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/sr20 > In directory baron:/tmp/cvs-serv4330/Aircraft/sr20 > > Added Files: > sr20-set.xml > Log Message: > Add some missing files. I'd suggest these changes to get things going: --- data/Aircraft/sr20/sr20-set.xml~Sat Oct 8 14:21:13 2005 +++ data/Aircraft/sr20/sr20-set.xml Sun Oct 9 16:02:09 2005 @@ -15,7 +15,7 @@ Erik Hofman (3D) yasim - pa28-161 + ../pa28-161/pa28-161 0.8 --- data/Aircraft/sr20/Models/sr20.ac~ Sun Oct 9 13:18:48 2005 +++ data/Aircraft/sr20/Models/sr20.ac Sun Oct 9 16:00:54 2005 @@ -14017,7 +14017,7 @@ OBJECT poly name "cylinder" loc 0.00206628 -0.224544 -0.521943 -texture "/home/erik/src/fgfs/models/SR20/prop.rgb" +texture "/home/erik/src/fgfs/models/SR20/prop2.rgp" numvert 25 0.00203025 0.123811 0.143539 -0.0281066 0.0373752 0.187383 @@ -14313,7 +14313,7 @@ OBJECT poly name "cylinder" loc 0.00194556 -0.343595 0.456208 -texture "/home/erik/src/fgfs/models/SR20/prop.rgb" +texture "/home/erik/src/fgfs/models/SR20/prop2.rgp" numvert 25 0.00203025 0.062403 -0.178993 -0.0281067 0.143591 -0.12606 @@ -14609,7 +14609,7 @@ OBJECT poly name "cylinder" loc -0.0040119 0.568139 0.0657347 -texture "/home/erik/src/fgfs/models/SR20/prop.rgb" +texture "/home/erik/src/fgfs/models/SR20/prop2.rgp" numvert 25 0.00203025 -0.186214 0.0354541 -0.0281067 -0.180966 -0.0613237 Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/GUI prop_picker.cxx,1.1.1.1,1.2 prop_picker.hxx,1.1.1.1,1.2
This is really cool! Looking through the changes I couldn't see...should this work with all properties? The orientation and position path data doesn't seem to update realtime. I can see lots of ways this can be used for debugging. Performance impact is minimal. Best, Jim "Curtis L. Olson" <[EMAIL PROTECTED]> said: > Update of /var/cvs/FlightGear-0.9/FlightGear/src/GUI > In directory seneca:/tmp/cvs-serv9955 > > Modified Files: > prop_picker.cxx prop_picker.hxx > Log Message: > James Turner: > > Here's a change to the GUI property picker I did a few weeks back. > It makes the values in the property pick 'live' (and also re-factors > the picker code to use less arrays, this should be obvious from the > diffs). A good demo is to open up the engine node and observe the rpm, > cylinder head temp, oil pressure and so on while playing with the > throttle and airspeed. It's pretty rough (some rounding of digits would > help) but useful for testing (at least I think so). I'm not sure about > the performance implications either, but it seems fine for me. > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC AIMgr.cxx,1.6,1.7 AIMgr.hxx,1.4,1.5
On 7 Mar 2003 at 8:42, Curtis L. Olson wrote: > Update of /var/cvs/FlightGear-0.9/FlightGear/src/ATC > In directory seneca:/tmp/cvs-serv18953 > > Modified Files: > AIMgr.cxx AIMgr.hxx > Log Message: > Eeek! Emergency fix of a couple "case" problems for includes. > Whoops, sorry, no prizes for guessing which OS I tested that on! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:FlightGear/FlightGear/Aircraft/f16/Panels
Martin Spott wrote: I think, something went wrong here: It looks like it, put the following file in FlightGear/Aircraft/f16/Panels: http://www.a1.nl/~ehofman/fgfs/download/ded.xml Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:FlightGear/FlightGear/Aircraft/f16/Panels
Erik Hofman <[EMAIL PROTECTED]> wrote: > Martin Spott wrote: >> I think, something went wrong here: > It looks like it, put the following file in FlightGear/Aircraft/f16/Panels: > http://www.a1.nl/~ehofman/fgfs/download/ded.xml This one does the trick for the panel. I still see the glider from outside, though, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:FlightGear/FlightGear/Aircraft/f16/Panels
Martin Spott wrote: Erik Hofman <[EMAIL PROTECTED]> wrote: Martin Spott wrote: I think, something went wrong here: It looks like it, put the following file in FlightGear/Aircraft/f16/Panels: http://www.a1.nl/~ehofman/fgfs/download/ded.xml This one does the trick for the panel. I still see the glider from outside, though, yep. Erik ;-D ___ 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.113, 1.114
Michael Selig wrote: At 7/26/03, Jim Wilson wrote: Is there a reason this can't be moved out of the main loop yet? It's been a while since it was last discussed, but I thought something was going to be done with it. The patch was one I submitted to Erik. How about this solution for now: Simply delete or comment out the entire blurb. The UIUC models fly quite alright w/o this bit of code! I checked and the LaRCsim C172 is also OK w/o it. I'll comment it out with a timestamp. Then it can safely be removed after a while. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Scenery/w130n30/w123n37 02Q.btg.gz, NONE, 1.1 ...
Erik Hofman wrote: > Update of /var/cvs/FlightGear-0.9/data/Scenery/w130n30/w123n37 > In directory baron:/tmp/cvs-serv23400/w130n30/w123n37 > > Modified Files: > 59CA.btg.gz 6Q6.btg.gz 942018.btg.gz 942019.btg.gz > 942026.btg.gz 942027.btg.gz 942034.btg.gz 942035.btg.gz > 942041.btg.gz 942042.btg.gz 942043.btg.gz 942049.btg.gz > 942050.btg.gz 942051.btg.gz 942056.btg.gz 942057.btg.gz > 942058.btg.gz 942059.btg.gz 942065.btg.gz 942066.btg.gz > 942067.btg.gz 942072.btg.gz 942073.btg.gz 942074.btg.gz > 942075.btg.gz CL77.btg.gz KCCR.btg.gz KHAF.btg.gz KHWD.btg.gz > KNUQ.btg.gz KOAK.btg.gz KPAO.btg.gz KSFO.btg.gz KSQL.btg.gz > Added Files: > 02Q.btg.gz 0Q2.btg.gz 15CA.btg.gz 16CA.btg.gz 17CA.btg.gz > 1CL3.btg.gz 44Q.btg.gz 45Q.btg.gz 4Q2.btg.gz 55CA.btg.gz > 5CA3.btg.gz CA14.btg.gz CA26.btg.gz CA27.btg.gz CA30.btg.gz > CA63.btg.gz CL41.btg.gz KCSY.btg.gz KJMC.btg.gz > Log Message: > Add Curtis' latest default scenery Erik, there are a number of new airport objects added but you didn't update any .stg files. It seems incorrect to me. When flying around SF, I can see white squares that are the holes for the unloaded airports. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Textures/Terrain airport.rgb, NONE, 1.1
Frederic Bouvier writes: > Erik Hofman wrote: > > Update of /var/cvs/FlightGear-0.9/data/Textures/Terrain > > In directory baron:/tmp/cvs-serv478 > > > > Added Files: > > airport.rgb > > Log Message: > > Add a default airport cover > > binary ? ;-) > > BTW, do you consider applying the cvswrappers trick I posted > to the list yesterday ? Or urge Curt to do so ? This is somewhere on my very long and getting longer todo list... :-( Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38 T38.xml, 1.2, 1.3
Erik Hofman <[EMAIL PROTECTED]> wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38 > In directory baron:/tmp/cvs-serv23354 > Modified Files: > T38.xml I'd vote for a modification of the 3D model. The cones behind the engines don't look _that_ realistic when sitting idle on the runway: http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38 T38.xml, 1.2, 1.3
Martin Spott wrote: > Erik Hofman wrote: > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38 > > In directory baron:/tmp/cvs-serv23354 > > > Modified Files: > > T38.xml > > I'd vote for a modification of the 3D model. The cones behind the > engines don't look _that_ realistic when sitting idle on the runway: > > http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png This is where a blend animation can be useful -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Instrumentation adf.cxx, 1.1, 1.2
Bernie Bright writes:
> Haven't we seen this or something like it before? Instead of "fixing" the
> code every time wouldn't it be easier to supply the missing comparison
> functions for your platform:
>
> inline bool
> operator!=( const std::string& lhs, const char* rhs )
> {
> return lhs.compare( rhs ) != 0;
> }
>
> inline bool
> operator!=( const char* lhs, const std::string& rhs )
> {
> return rhs.compare( lhs ) != 0;
> }
>
> Other comparisons could be added if required.
Good idea. Erik?
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Instrumentation adf.cxx, 1.1, 1.2
David Megginson wrote:
Bernie Bright writes:
> Haven't we seen this or something like it before? Instead of "fixing" the
> code every time wouldn't it be easier to supply the missing comparison
> functions for your platform:
>
> inline bool
> operator!=( const std::string& lhs, const char* rhs )
> {
> return lhs.compare( rhs ) != 0;
> }
>
> inline bool
> operator!=( const char* lhs, const std::string& rhs )
> {
> return rhs.compare( lhs ) != 0;
> }
>
> Other comparisons could be added if required.
Good idea. Erik?
I'll take a look at it when I have some time.
If I get it working I'll scan the code for these problems and remove
them also.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Rotor.cpp, NONE,
Martin Spott <[EMAIL PROTECTED]> said: > "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim > > In directory baron:/tmp/cvs-serv7544 > > > > Added Files: > > Rotor.cpp Rotor.hpp Rotorblade.cpp Rotorblade.hpp > > Rotorpart.cpp Rotorpart.hpp > > Log Message: > > Initial revision. > > > > Maik Justus: First pass at helicopter support for YASim. > > Oh, _that_ one is really nice. Although the heli is really very well > behaved (even with mouse any keyboard control I find it pretty easy to > fly _and_land_) I'm shure that crash detection should definitely be the > next step :-)) > Crash detection should be working. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Rotor.cpp, NONE,
On Thursday 16 October 2003 18:10, Jim Wilson wrote: > Martin Spott <[EMAIL PROTECTED]> said: > > > "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > > Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim > > > In directory baron:/tmp/cvs-serv7544 > > > > > > Added Files: > > > Rotor.cpp Rotor.hpp Rotorblade.cpp Rotorblade.hpp > > > Rotorpart.cpp Rotorpart.hpp > > > Log Message: > > > Initial revision. > > > > > > Maik Justus: First pass at helicopter support for YASim. > > > > Oh, _that_ one is really nice. Although the heli is really very well > > behaved (even with mouse any keyboard control I find it pretty easy to > > fly _and_land_) I'm shure that crash detection should definitely be the > > next step :-)) > > > > Crash detection should be working. > > Best, > > Jim LOL :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Rotor.cpp, NONE,
Hi, Oh, _that_ one is really nice. Although the heli is really very well thanks behaved (even with mouse any keyboard control I find it pretty easy to fly _and_land_)... The bo is a little bit different to most other helicopters. I don't say that this simulation is totally realistic, but it should be really quite similar to the original (as far as I can evaluate that). What still is missing is the aerodynamic of the fuselage and the effect of the downwash to the horizontal stab (which is also missing). Both make it a little bit more difficult. I have builded a file bell206like.xml, use this and see how difficult it is to fly a helicopter. (@curt, jim: could you please add these files to the cvs?) (or change (at the main rotor) relenflaphinge="0.0", delta=".4" weightperblade="55" to get al Jet Ranger like rotor (ok, it has still 4 blades, but its behavior is quite similar to the Jet Ranger)) Or at least remove the 'notorque="true" ' statements in the bo105.xml. Maik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
--- Martin Spott <[EMAIL PROTECTED]> wrote: > I can't resist the suspicion that there's something wrong with the 3D > model. At least I get the glider to see and I yet didn't find yout why. > Several XML files and the AC file do have DOS line endings but this > doesn't cause the trouble I've already removed all of them, Have you synced Instruments-3d ? The new C182 model requires the new yoke, flaps and trimwheel that I submitted at the same time. I assume they were all checked in at the same time. -Stuart ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
Buchanan, Stuart wrote: Have you synced Instruments-3d ? The new C182 model requires the new yoke, flaps and trimwheel that I submitted at the same time. I assume they were all checked in at the same time. Oops, they hadn't. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
Martin Spott wrote: I can't resist the suspicion that there's something wrong with the 3D model. At least I get the glider to see and I yet didn't find yout why. Several XML files and the AC file do have DOS line endings but this doesn't cause the trouble I've already removed all of them, Anyone still having problems with this, even after the most recent round of instrument commits? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Instruments/Textures radar_misc.rgb, 1.1, 1.2
David Megginson wrote: Erik Hofman wrote: Modified Files: radar_misc.rgb Log Message: Add support for a storm blib Excellent. As far as I know, civilian airliners carry radar that is capable only of detecting weather, not small things like aircraft. They also use a separate radar system for ground separation (the radar altimeter). For traffic, they use TCAS, which is equivalent to secondary surveillance radar (i.e. it detects other planes only if their transponders are on, and does not pick up primary targets). I know that in Europe they recently added a requirement for collision detection after two civilian aircraft hit each other when the ATC had given inappropriate directions. The sad part is, the particular air traffic controller has been stabbed to death recently. I'm sure that military combat aircraft must have radar with primary traffic capability, since the enemy is sometimes too inconsiderate to turn on the transponder. Yeah, the engaging aircraft seem to be playing hide and seek now and then. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Instruments/Textures radar_misc.rgb, 1.1, 1.2
Erik Hofman wrote: I know that in Europe they recently added a requirement for collision detection after two civilian aircraft hit each other when the ATC had given inappropriate directions. Is that a requirement for TCAS, or for something else in addition to TCAS? The copilot on one of those planes was a Canadian, so we heard a fair bit about the crash in the news. The worst part was that Swiss ATC tried to cover up their mistake, but the ever-efficient Germans happened to have tapes to prove the Swiss controller's error. That said, I'm sorry to hear that the Swiss controller died. Was it in any way related to the accident? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Instruments/Textures radar_misc.rgb, 1.1, 1.2
David Megginson wrote: Erik Hofman wrote: I know that in Europe they recently added a requirement for collision detection after two civilian aircraft hit each other when the ATC had given inappropriate directions. Is that a requirement for TCAS, or for something else in addition to TCAS? Every passenger plane visiting Europe must have one of them installed (including military aircraft carrying passengers). The copilot on one of those planes was a Canadian, so we heard a fair bit about the crash in the news. The worst part was that Swiss ATC tried to cover up their mistake, but the ever-efficient Germans happened to have tapes to prove the Swiss controller's error. Yes, it wasn't perfect but to my knowledge it wasn't an error for the air traffic controller but rather a management problem involving scheduled (and unscheduled) maintenance. That said, I'm sorry to hear that the Swiss controller died. Was it in any way related to the accident? One of the aircraft was full with children from Russia and the are holding a Russian suspect. You can do the math. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Instruments/Textures radar_misc.rgb, 1.1, 1.2
On Freitag, 27. Februar 2004 15:40, David Megginson wrote: > That said, I'm sorry to hear that the Swiss controller died. Was it in any > way related to the accident? It was not clear up to the yesterday evening news. Have not seen/heared news from today. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Instruments/Textures radar_misc.rgb, 1.1, 1.2
Erik Hofman wrote: David Megginson wrote: Erik Hofman wrote: I know that in Europe they recently added a requirement for collision detection after two civilian aircraft hit each other when the ATC had given inappropriate directions. Is that a requirement for TCAS, or for something else in addition to TCAS? Every passenger plane visiting Europe must have one of them installed (including military aircraft carrying passengers). The copilot on one of those planes was a Canadian, so we heard a fair bit about the crash in the news. The worst part was that Swiss ATC tried to cover up their mistake, but the ever-efficient Germans happened to have tapes to prove the Swiss controller's error. Yes, it wasn't perfect but to my knowledge it wasn't an error for the air traffic controller but rather a management problem involving scheduled (and unscheduled) maintenance. That said, I'm sorry to hear that the Swiss controller died. Was it in any way related to the accident? One of the aircraft was full with children from Russia and the are holding a Russian suspect. You can do the math. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel I might be thinking of a different incident, but my understanding is that both the German and Russian planes were equipped with TCAS, and both units functioned correctly alerting the German plane to descend and the Russian to climb. Unfortunately the Swiss controller made the mistake of ordering the Russian plane to descend, the Russian pilot made the mistake of following the verbal order when standard practice is to never override a TCAS warning. In addition the error was not caught because there were no backup controllers at the Swiss facility and a piece of equipment meant to catch such errors was down for repair. This reminds me of the concept of a "radar assisted collision", a relatively common occurrence in shipping that for many years actually made it more likely for two radar equipped ships to collide when passing then two non-equipped ships. Another case of adding incorrect data to correct data and causing a bad decision. Now what was that original topic again :? Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Instruments/Textures radar_misc.rgb, 1.1, 1.2
On Friday 27 February 2004 14:02, David Megginson wrote: > Erik Hofman wrote: > > Modified Files: > > radar_misc.rgb > > Log Message: > > Add support for a storm blib > > Excellent. > > As far as I know, civilian airliners carry radar that is capable only of > detecting weather, not small things like aircraft. They also use a > separate radar system for ground separation (the radar altimeter). For > traffic, they use TCAS, which is equivalent to secondary surveillance radar > (i.e. it detects other planes only if their transponders are on, and does > not pick up primary targets). > > I'm sure that some of the very newest airliners can integrate all of this > information into a single multifunction display, but for most of the > existing fleet, I don't know if traffic and weather would appear on the > same display or not. Can anyone chime in with concrete information? > > I'm sure that military combat aircraft must have radar with primary traffic > capability, since the enemy is sometimes too inconsiderate to turn on the > transponder. > > > All the best, > > > David Yeah - lots of modes, from narrow angle boresight to vertical & horizontal cross-scans, different doppler stuff for crossing the scan and approaching it... and that's just air-to-air. More and different doppler stuff for look-down A2A, not to mention ground mapping stuff. Trend these days is more for passive optical stuff, both A2A & A2G. Afaik, IR's better for initial acquisition - it's longer lived and so gives a bigger target, but you want to switch to visible as soon as you detect some contrast. Need active lasers for ranging though, I think. Funnily enough, while should be relatively easy to kludge, it seems a bit pointless to me... LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/f16 f16-3d-set.xml, 1.1,
Martin Spott wrote: You should also modify this one: ^^ This is no longer present, Thanks for catching this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim YASim.cxx, 1.20, 1.21
Martin Spott said: > "Curtis L. Olson" wrote: > > Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim > > In directory baron:/tmp/cvs-serv14214/src/FDM/YASim > > > > Modified Files: > > YASim.cxx > > Log Message: > > Jim Wilson: > > > > Remove some hardcoded dependencies between fdm, viewer and acmodel classes and > > replaced them with property references. Fix roll offset in viewer. > > I'm sorry to say this but I can't resist to note that some of the > changes in your patch reverted David's "the PA-28 rotates around it's > nose" corrections. > I know that you both have different opinions on which route has to be > taken to handle this topic but I'd prefer that you still focus on a > working result. I'm not aware of any difference of opinion Martin, but I will look into what you describe. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Scenery/w130n30/w123n37 942050.stg, 1.11, 1.12
Erik Hofman wrote: > Update of /var/cvs/FlightGear-0.9/data/Scenery/w130n30/w123n37 > In directory baron:/tmp/cvs-serv5777 > > Modified Files: > 942050.stg > Log Message: > Put a sock in it. > > Index: 942050.stg > === > RCS file: /var/cvs/FlightGear-0.9/data/Scenery/w130n30/w123n37/942050.stg,v > retrieving revision 1.11 > retrieving revision 1.12 > diff -C2 -r1.11 -r1.12 > *** a/942050.stg 11 Jan 2004 22:34:14 - 1.11 > --- b/942050.stg 21 Mar 2004 08:53:55 - 1.12 > *** > *** 7,8 > --- 7,9 > OBJECT_STATIC sanmateo-fb.xml -122.25 37.5831 0 140 > OBJECT_STATIC KSFO-terminal-fb.ac -122.3859635 37.61748958 5 90 > + OBJECT_STATIC ../../../Models/Airport/windsock.xml -122.360843 37.613877 5 0 To be picky, it should be : OBJECT_SHARED Models/Airport/windsock.xml -122.360843 37.613877 5 0 Otherwise, I am having a negative wind speed, so the windsock stay low. Is is normal ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models bo105.ac, 1.8,
Melchior FRANZ said: > * Martin Spott -- Wednesday 24 March 2004 16:40: > > Ooooh, I found the yellow one definitely nicer, it was a cute, coloured > > spot in the colloection of mostly uniform coloured aircraft, > > Oh, well. Actually I like both versions. I just think that the yellow > one got a bit boring already, and that the green one hides the lack of > texture better. Once I've textured everything this won't be necessary, > but changing colors will then also not be that easy any more. This was > the last chance for some change. If more than one prefers the yellow > bo105 (and the release date permits it) then I can change it back. It's > just the difference between "make install" and "make install mil" for > me. :-) > > BTW: planned are the following changes (probably, but not necessarily > in this order) > > - finish position lights (top red in cvs; bottom red done here) > - implement rotor disk and blend in at some rotational speed > - interior: cyclic/collective, pilot, eventually medical config > - external details (wire cutter, further antennas, ...) > - texturing (no idea which livree; certainly not ADAC ;-) > - more/custom instruments > - bended blades(?) How about this one? ;-) http://www.spiderbark.com/fgfs/barneymobile.png BTW the cockpit looks great. I recently took it out chasing AI aircraft around oakland airport. The flight model may not be 100% but it sure is fun flying it. Nice looking beacon there as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models bo105.ac, 1.8,
Jim Wilson wrote: How about this one? ;-) http://www.spiderbark.com/fgfs/barneymobile.png Is that the don't-ask-don't-tellicopter. 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models bo105.ac, 1.8,
On Wed, 24 Mar 2004 19:52:57 -0600, "Curtis L. Olson" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Jim Wilson wrote: > > >How about this one? ;-) > > > >http://www.spiderbark.com/fgfs/barneymobile.png > > > > Is that the don't-ask-don't-tellicopter. ..using these names sounds like neat nice legal prank. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models bo105.ac, 1.8,
"Curtis L. Olson" said: > Jim Wilson wrote: > > >How about this one? ;-) > > > >http://www.spiderbark.com/fgfs/barneymobile.png > > > > > > Is that the don't-ask-don't-tellicopter. > Haha! Is this what they call aviation innuendo? What about these folks: http://www.harrierpilot.com/oct01/purple.jpg They must be British. :::duck::: ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Propeller.cpp, 1.3, 1.4
Jim Wilson wrote: > Maybe I'm misunderstanding why you are doing this. Lower pitch > angle, fast spinning prop. That doesn't makes sense? Not pitch angle: A lower value of "_j0" indicates a low advance ratio, which increases windmilling speed. This was just a sign bug to the previous checkin, basically. The core change was to fix manual pitch propellers such that a 0.5 value for the axis input matched the value that was solved for in the configuration. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Propeller.cpp, 1.3, 1.4
Andy Ross said: > Jim Wilson wrote: > > Maybe I'm misunderstanding why you are doing this. Lower pitch > > angle, fast spinning prop. That doesn't makes sense? > > Not pitch angle: A lower value of "_j0" indicates a low advance ratio, > which increases windmilling speed. This was just a sign bug to the > previous checkin, basically. The core change was to fix manual pitch > propellers such that a 0.5 value for the axis input matched the value > that was solved for in the configuration. > Ah ok. I'll take a look back further. Sometime in the next few days I should be able to do test the changes with the p51d. Is any of this addressing the low rpm propeller issue discussed last week? (In other words, should I bother trying to correctly adjust the p51d prop config yet?) I realize the main project is adding turboprop, which is itself very exciting! Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Propeller.cpp, 1.3, 1.4
Jim Wilson wrote: > Is any of this addressing the low rpm propeller issue discussed last > week? (In other words, should I bother trying to correctly adjust > the p51d prop config yet?) In theory, yes. I haven't had a whole lot of time to test it yet, but the slow/windmilling propeller regime should be sane now. It would be nice to add stuff like a windmiling parameter to the configuration, so the user can tune it, but the ridiculous torques produces should be fixed. I honestly haven't had time to actually fly this thing yet. I wrote a little program to generate graphs of torque vs. RPM, which looked good though. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Model TODO,NONE,1.1 README,1.1,1.2
Jim Wilson writes: > > - add animations for the model as a whole > > > > - add submodels > > > > - add billboards > > > > - add UV animations > > > > Billboards-? you mean like those big signs they allow in other states? Is > animation for blinking aircraft lights included in the above? No -- I haven't quite decided how that animation should work. Billboards are 2D objects that rotate towards the viewer -- they're especially useful for modelling trees. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Navaids fix.hxx,1.6,1.7ils.hxx,1.16,1.17 nav.hxx,1.22,1.23
David Megginson wrote: > Update of /var/cvs/FlightGear-0.7/FlightGear/src/Navaids > In directory seneca:/tmp/cvs-serv23071/src/Navaids > > Modified Files: > fix.hxx ils.hxx nav.hxx > Log Message: > Mac OS X patches from Jonathan Polley. > *** 37,41 > #elif defined( SG_HAVE_NATIVE_SGI_COMPILERS ) > # include > ! #elif defined( __BORLANDC__ ) > # include > #else > --- 37,41 > #elif defined( SG_HAVE_NATIVE_SGI_COMPILERS ) > # include > ! #elif defined( __BORLANDC__ ) || (__APPLE__) > # include > #else I think we should make more use of the STL_* header definitons in simgear/compiler.h that would make these lines: #include STL_IOSTREAM Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Navaidsfix.hxx,1.6,1.7ils.hxx,1.16,1.17 nav.hxx,1.22,1.23
Bernie Bright wrote: > Erik, I was thinking we could use Boost's compatability library I sent > you as a starting point. I think I agree, but we might face some difficulties when implementing it because only some (combinations) of hardware/compiler needs it. It might be worth a try though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controls controls.cxx,1.21,1.22 controls.hxx,1.21,1.22
> > The only question is how high to set MAX_TANKS. Eight? Twelve? > > Sixteen? > > Is there a reason to have a maximum? (Does the property system > require it?) I always prefer to allocate as necessary to avoid predefined > limits. As soon as you set a limit, someone will come along with an > example of something that can't be done within that limit... FWIW, JSBSim sets no maximum for number of tanks. I'm not sure how this might be affected by lack of ability to control them. Also, is there a standard way to select a source tank and a destination tank in order to cross feed or to replenish one tank from another? Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controls controls.cxx,1.21,1.22 controls.hxx,1.21,1.22
On Fri, 5 Jul 2002 14:37:10 -0500, "Jon Berndt" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > > FWIW, JSBSim sets no maximum for number of tanks. I'm not sure how > this might be affected by lack of ability to control them. Also, is > there a standard way to select a source tank and a destination tank > in order to cross feed or to replenish one tank from another? ...or, between aircraft for in-flight refuelling? ..(during the Falklands War, the Britts tested refuelling of Harriers and Sea Harriers, from ships, in-hover refuelling, believe I saw this in Air Progress magazine in the mid 80'ies.) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controls controls.cxx,1.21,1.22 controls.hxx,1.21,1.22
> ...or, between aircraft for in-flight refuelling? > > ..(during the Falklands War, the Britts tested refuelling of Harriers > and Sea Harriers, from ships, in-hover refuelling, believe I saw this > in Air Progress magazine in the mid 80'ies.) exactly. smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controls controls.cxx,1.21,1.22 controls.hxx,1.21,1.22
On Sat, 06 Jul 2002 13:49:36 -0700, Andy Ross <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > ..(during the Falklands War, the Britts tested refuelling of > > Harriers and Sea Harriers, from ships, in-hover refuelling, > > believe I saw this in Air Progress magazine in the mid 80'ies.) > > I think what you're remembering is the "Sky Hook" gadget that was > developed but never installed on Royal Navy vessels. It was actually > a full-service landing system, not just a refuelling boom. The idea ..could well be both. Was possibly tested in North Norwegian waters, the Britts trained up here, the topography is pretty similar. ..correct afair, the articles mentioned commandeered/drafted tanker vessels, and not using standard issue naval vessels. > was that the Harrier would come to a stable hover alongside the boat, > and then be grabbed from above by the hook. It would then > (carefully!) decrease thrust until it was just hanging there, and then > be lowered onto the deck like cargo. ..the US Navy did hoist Boeing (or Grumman?) pursuit planes in thru the belly of an airship in the late 20-30'ies, climb into the hook, lock it, hoist it in, drop it onto the hangar deck. ..the US Navy also played with condensing water out of engine exhaust gas in at least one of these airships, I'm thinking of trying a wood gasifier in one. First things first, though. > I can't imagine this was very popular with the pilots. Imagine > sweating during the (already very difficult) hover as some 19 year > old sailor swats at you with a giant crane. :) ..uhmmm, yeah, we could model fly swatting too. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/sr20 sr20-set.xml, NONE, 1.1
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/sr20 In directory baron:/tmp/cvs-serv4330/Aircraft/sr20 Added Files: sr20-set.xml Log Message: Add some missing files. I'd suggest these changes to get things going: Ehm, allright. Done. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC AIMgr.cxx,1.6,1.7 AIMgr.hxx,1.4,1.5
[EMAIL PROTECTED] writes: > On 7 Mar 2003 at 8:42, Curtis L. Olson wrote: > > > Update of /var/cvs/FlightGear-0.9/FlightGear/src/ATC > > In directory seneca:/tmp/cvs-serv18953 > > > > Modified Files: > > AIMgr.cxx AIMgr.hxx > > Log Message: > > Eeek! Emergency fix of a couple "case" problems for includes. > > > > Whoops, sorry, no prizes for guessing which OS I tested that on! I was going to rot13 something, but restrained myself. :-) 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] Re: [Flightgear-cvslogs] CVS: FlightGear/src/WeatherCM linintp2.cpp,1.3,1.4 sphrintp.cpp,1.3,1.4
Erik, There is still a missing comma in line 409 of linintp2.cpp. -Fred D:\FlightGear\cvs\FlightGear\src>cvs diff -u WeatherCM cvs server: Diffing WeatherCM Index: WeatherCM/linintp2.cpp === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/WeatherCM/linintp2.cpp,v retrieving revision 1.4 diff -u -r1.4 linintp2.cpp --- WeatherCM/linintp2.cpp 21 Mar 2003 21:12:12 - 1.4 +++ WeatherCM/linintp2.cpp 21 Mar 2003 21:46:35 - @@ -406,7 +406,7 @@ } // create the triangles -SG_LOG(SG_MATH, SG_DEBUG "[ 60%] create the triangles"); +SG_LOG(SG_MATH, SG_DEBUG, "[ 60%] create the triangles"); triangle = new Triangle[numTriangles]; - Original Message - From: "Erik Hofman" > Update of /var/cvs/FlightGear-0.9/FlightGear/src/WeatherCM > In directory seneca:/tmp/cvs-serv24858/src/WeatherCM > > Modified Files: > linintp2.cpp sphrintp.cpp > Log Message: > Add logstream header files when using SG_LOG() ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Flightgear-cvslogs] CVS: source/src/Systems system_mgr.cxx,1.8,1.9 vacuum.cxx,1.1,1.2vacuum.hxx,1.2,1.3
Curtis L. Olson writes: > - Added a redundant (left/right) vacuum pump. Is this optional? Many (most?) low-end singles have only a single vacuum pump, though the newest Cessna 172R/S has two. > - Modified the rpm vs. suction formula to hit much more realistic numbers. > We should be seeing just over 4 inhg at idle and approaching 5 inhg at > full throttle. Excellent. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Networknative_fdm.cxx, 1.12, 1.13 net_fdm.hxx, 1.5, 1.6
On Tue, 22 Jul 2003 18:46:14 -0500
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/FlightGear-0.9/source/src/Network
> In directory baron:/tmp/cvs-serv19507/Network
>
> Modified Files:
> native_fdm.cxx net_fdm.hxx
> Log Message:
> Add gear animation effects to replay.
>
>
> Index: native_fdm.cxx
> ===
> RCS file: /var/cvs/FlightGear-0.9/source/src/Network/native_fdm.cxx,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -C2 -r1.12 -r1.13
> *** native_fdm.cxx22 Jul 2003 20:05:38 - 1.12
> --- native_fdm.cxx22 Jul 2003 23:46:11 - 1.13
> ***
> *** 184,187
> --- 184,190
> SGPropertyNode *node = fgGetNode("/gear/gear", i, true);
> net->wow[i] = node->getDoubleValue("wow");
> + net->gear_pos[i] = node->getDoubleValue("position-norm");
> + net->gear_steer[i] = node->getDoubleValue("steering-norm");
> + net->gear_compression[i] =
> node->getDoubleValue("compression-norm");
> }
>
> ***
> *** 247,250
> --- 250,256
> for ( i = 0; i < net->num_wheels; ++i ) {
> net->wow[i] = htonl(net->wow[i]);
> + net->gear_pos[i] = htonl(net->gear_pos[i]);
> + net->gear_steer[i] = htonl(net->gear_steer[i]);
> + net->gear_compression[i] = htonl(net->gear_compression[i]);
> }
> net->num_wheels = htonl(net->num_wheels);
> ***
These latest changes generate a compilation error:
native_fdm.cxx: In function `void FGProps2NetFDM(FGNetFDM*, bool)':
native_fdm.cxx:252: invalid operands of types `float' and `unsigned int' to
binary `operator&'
The gear_* members should be converted using htonf() instead of htonl().
A minor nit with htonf() is that it doesn't return the converted value like
the other htonX functions. For consistency I wonder if we should change
this.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Scenery/w130n30/w123n37 02Q.btg.gz, NONE, 1.1 ...
Frederic Bouvier wrote: Erik, there are a number of new airport objects added but you didn't update any .stg files. It seems incorrect to me. When flying around SF, I can see white squares that are the holes for the unloaded airports. Yep, Curtis told me about that just yet. I didn't know that (until now). If no one else steps in I'll fix that tomorrow morning. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38 T38.xml, 1.2, 1.3
Frederic BOUVIER wrote: Martin Spott wrote: I'd vote for a modification of the 3D model. The cones behind the engines don't look _that_ realistic when sitting idle on the runway: http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png This is where a blend animation can be useful Done. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38 T38.xml, 1.2, 1.3
On 16 Sep 2003 08:39:26 GMT, Martin Spott <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Erik Hofman <[EMAIL PROTECTED]> wrote: > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38 > > In directory baron:/tmp/cvs-serv23354 > > > Modified Files: > > T38.xml > > I'd vote for a modification of the 3D model. The cones behind the > engines don't look _that_ realistic when sitting idle on the runway: > > http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png ..cut the longer cone in half, for lenght, in that length give it the 3 "blowtorch blues" when on 3/4 to full afterburner, on less power, "clear heat haze" the background, but leave the tail pipe light on, on afterburner on. For WWII thru Cold War military jets on JP4 et al, soot pipes are allowable, its our sim. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Scenery/w130n30/w123n37 942050.stg, 1.11, 1.12
Frederic Bouvier wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Scenery/w130n30/w123n37 In directory baron:/tmp/cvs-serv5777 Modified Files: 942050.stg Log Message: Put a sock in it. Index: 942050.stg === RCS file: /var/cvs/FlightGear-0.9/data/Scenery/w130n30/w123n37/942050.stg,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -r1.11 -r1.12 *** a/942050.stg 11 Jan 2004 22:34:14 - 1.11 --- b/942050.stg 21 Mar 2004 08:53:55 - 1.12 *** *** 7,8 --- 7,9 OBJECT_STATIC sanmateo-fb.xml -122.25 37.5831 0 140 OBJECT_STATIC KSFO-terminal-fb.ac -122.3859635 37.61748958 5 90 + OBJECT_STATIC ../../../Models/Airport/windsock.xml -122.360843 37.613877 5 0 To be picky, it should be : OBJECT_SHARED Models/Airport/windsock.xml -122.360843 37.613877 5 0 Did you test this, according to Melchior this doesn't work. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx, 1.151, 1.152 options.cxx, 1.52, 1.53
I should point out that the reason these were setup as "cout" was so
that we wouldn't lose all output if someone compiled with the
--without-logging option. Now that our default output is much less
verbose, people are probably not compiling with this option so it's
probably not a big deal ... but that was the reason we used cout's here.
Curt.
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv29723
Modified Files:
main.cxx options.cxx
Log Message:
Frederic Bouvier:
trying the --show-aircraft option, I noticed that I had
no output. This is because there are still output to
cout or cerr, that are not triggering my console patch
for windows. The patch attached use SG_LOG instead.
A request to hit a key is also added because otherwise,
the console window will disappear as soon as the program
stop.
This problem is minor though given the fact that fgfs.exe
is shipped with fgrun that do show the available aircraft
in a much nicer manner.
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.151
retrieving revision 1.152
diff -C2 -r1.151 -r1.152
*** a/main.cxx 19 Mar 2004 03:30:18 - 1.151
--- b/main.cxx 30 Mar 2004 09:05:05 - 1.152
***
*** 1511,1518
// tell the operator how to use this application
! cerr << endl << "Base package check failed ... " \
<< "Found version " << base_version << " at: " \
! << globals->get_fg_root() << endl;
! cerr << "Please upgrade to version: " << required_version << endl;
exit(-1);
}
--- 1511,1522
// tell the operator how to use this application
! SG_LOG( SG_GENERAL, SG_ALERT, endl << "Base package check failed ... " \
<< "Found version " << base_version << " at: " \
! << globals->get_fg_root() );
! SG_LOG( SG_GENERAL, SG_ALERT, "Please upgrade to version: " << required_version );
! #ifdef _MSC_VER
! SG_LOG( SG_GENERAL, SG_ALERT, "Hit a key to continue..." );
! cin.get();
! #endif
exit(-1);
}
Index: options.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/options.cxx,v
retrieving revision 1.52
retrieving revision 1.53
diff -C2 -r1.52 -r1.53
*** a/options.cxx 26 Feb 2004 12:57:38 - 1.52
--- b/options.cxx 30 Mar 2004 09:05:05 - 1.53
***
*** 1763,1769
sort(aircraft.begin(), aircraft.end());
! cout << "Available aircraft:" << endl;
for ( unsigned int i = 0; i < aircraft.size(); i++ ) {
! cout << aircraft[i] << endl;
}
}
--- 1763,1773
sort(aircraft.begin(), aircraft.end());
! SG_LOG( SG_GENERAL, SG_ALERT, "Available aircraft:" );
for ( unsigned int i = 0; i < aircraft.size(); i++ ) {
! SG_LOG( SG_GENERAL, SG_ALERT, aircraft[i] );
}
+ #ifdef _MSC_VER
+ SG_LOG( SG_GENERAL, SG_ALERT, "Hit a key to continue..." );
+ cin.get();
+ #endif
}
___
Flightgear-cvslogs mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
--
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx, 1.151, 1.152 options.cxx, 1.52, 1.53
Curtis L. Olson wrote:
> I should point out that the reason these were setup as "cout" was so
> that we wouldn't lose all output if someone compiled with the
> --without-logging option. Now that our default output is much less
> verbose, people are probably not compiling with this option so it's
> probably not a big deal ... but that was the reason we used cout's here.
>
> Curt.
Ack. I will send a better patch to Erik ASAP. I just need to popup the
console window on Windows because I made it non existent by default.
-Fred
>
> Erik Hofman wrote:
>
> >Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
> >In directory baron:/tmp/cvs-serv29723
> >
> >Modified Files:
> > main.cxx options.cxx
> >Log Message:
> >
> >Frederic Bouvier:
> >
> >trying the --show-aircraft option, I noticed that I had
> >no output. This is because there are still output to
> >cout or cerr, that are not triggering my console patch
> >for windows. The patch attached use SG_LOG instead.
> >A request to hit a key is also added because otherwise,
> >the console window will disappear as soon as the program
> >stop.
> >
> >This problem is minor though given the fact that fgfs.exe
> >is shipped with fgrun that do show the available aircraft
> >in a much nicer manner.
> >
> >
> >Index: main.cxx
> >===
> >RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
> >retrieving revision 1.151
> >retrieving revision 1.152
> >diff -C2 -r1.151 -r1.152
> >*** a/main.cxx 19 Mar 2004 03:30:18 - 1.151
> >--- b/main.cxx 30 Mar 2004 09:05:05 - 1.152
> >***
> >*** 1511,1518
> > // tell the operator how to use this application
> >
> >! cerr << endl << "Base package check failed ... " \
> > << "Found version " << base_version << " at: " \
> >! << globals->get_fg_root() << endl;
> >! cerr << "Please upgrade to version: " << required_version << endl;
> > exit(-1);
> > }
> >--- 1511,1522
> > // tell the operator how to use this application
> >
> >! SG_LOG( SG_GENERAL, SG_ALERT, endl << "Base package check failed ... " \
> > << "Found version " << base_version << " at: " \
> >! << globals->get_fg_root() );
> >! SG_LOG( SG_GENERAL, SG_ALERT, "Please upgrade to version: " << required_version );
> >! #ifdef _MSC_VER
> >! SG_LOG( SG_GENERAL, SG_ALERT, "Hit a key to continue..." );
> >! cin.get();
> >! #endif
> > exit(-1);
> > }
> >
> >Index: options.cxx
> >===
> >RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/options.cxx,v
> >retrieving revision 1.52
> >retrieving revision 1.53
> >diff -C2 -r1.52 -r1.53
> >*** a/options.cxx 26 Feb 2004 12:57:38 - 1.52
> >--- b/options.cxx 30 Mar 2004 09:05:05 - 1.53
> >***
> >*** 1763,1769
> >
> > sort(aircraft.begin(), aircraft.end());
> >! cout << "Available aircraft:" << endl;
> > for ( unsigned int i = 0; i < aircraft.size(); i++ ) {
> >! cout << aircraft[i] << endl;
> > }
> > }
> >--- 1763,1773
> >
> > sort(aircraft.begin(), aircraft.end());
> >! SG_LOG( SG_GENERAL, SG_ALERT, "Available aircraft:" );
> > for ( unsigned int i = 0; i < aircraft.size(); i++ ) {
> >! SG_LOG( SG_GENERAL, SG_ALERT, aircraft[i] );
> > }
> >+ #ifdef _MSC_VER
> >+ SG_LOG( SG_GENERAL, SG_ALERT, "Hit a key to continue..." );
> >+ cin.get();
> >+ #endif
> > }
> >
> >
> >___
> >Flightgear-cvslogs mailing list
> >[EMAIL PROTECTED]
> >http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
> >
> >
>
>
> --
> 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
>
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
Erik Hofman said: > Update of /var/cvs/FlightGear-0.9/FlightGear/src/Input > In directory baron:/tmp/cvs-serv26245 > > Modified Files: > input.cxx input.hxx > Log Message: > Make it possible to define a tag in the joystick configuration file. This would make it possible to have different configuration files for Windows. Possible values are: Windows, UNIX or All. Not specifying the tag equals to 'All'. > Just curious, why is this required? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* Jim Wilson -- Tuesday 27 April 2004 15:12: > Erik Hofman said: > > Make it possible to define a tag in the joystick > > configuration file. This would make it possible to have different > > configuration files for Windows. > Just curious, why is this required? Because Unix and Windows don't always agree on axis numeration. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
Melchior FRANZ wrote: > * Jim Wilson -- Tuesday 27 April 2004 15:12: > > Erik Hofman said: > > > Make it possible to define a tag in the joystick > > > configuration file. This would make it possible to have different > > > configuration files for Windows. > > > Just curious, why is this required? > > Because Unix and Windows don't always agree on axis numeration. In fact, they never agree. axis 2 & 3 are reverted, and the hat has different numbering, for the same joystick name. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* Frederic Bouvier -- Tuesday 27 April 2004 15:49: > Melchior FRANZ wrote: > > Because Unix and Windows don't always agree on axis numeration. > > In fact, they never agree. axis 2 & 3 are reverted, and the hat has > different numbering, for the same joystick name. So we'd need two config files for *every* joystick (with more than two axes)? That's IMHO not acceptable. I'd rather prefer a mechanism that makes one and the same config file work for both systems then. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* Erik Hofman -- Tuesday 27 April 2004 16:21: > Melchior FRANZ wrote: > > > So we'd need two config files for *every* joystick (with more than > > two axes)? That's IMHO not acceptable. > Not acceptable won't do in this case unless I see something show up > that is elegant and that works in every situation. I meant "not acceptable" as in "I won't maintain two versions of my Cyborg-Gold-3d-USB joystick config". I don't care otherwise. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* Erik Hofman -- Tuesday 27 April 2004 16:37: > I bet you can come up with a clever solution where only the platform > specific part are in the actual configuration file and everything else > gets included from a shared file ... Rudder property-scale /controls/flight/rudder 0.0 1.0 2.0 m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* Melchior FRANZ -- Tuesday 27 April 2004 16:49: > * Erik Hofman -- Tuesday 27 April 2004 16:37: > > I bet you can come up with a clever solution where only the platform > > specific part are in the actual configuration file and everything else > > gets included from a shared file ... > > Whereby "unix" would be an alias for "n" and the line could also be written as No need for shared files. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
