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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049/Models
On Sunday 27 November 2005 05:19 pm, Martin Spott wrote: Sets correctly the VRP at the nose : Yep, the VRP appears actually to be located at the nose, but the offset to the CG is still missing :-) Have a try, look at the aircraft from an outside view (chase view w/o yaw), activate the HUD and see where the center of the HUD points at: It points at the nose whereas it _should_ point at somewhere near the wing root, actually at the CG. Currently the FDM still 'thinks' the CG is at the nose. One thing that may be confusing is that the VRP setting given by aeromatic is wrong. In the JSBSim configuration file If the CG location is X, Y, Z, then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the location of the VRP, however it actually defines the location of the VRP *from* the CG (?). I never noticed it in the T-38 and other smaller airplanes because the effect is hard to see. In a big airplane like the 1049 you can see it. The above may seem authoritative, but I'm really only 90% sure it's correct :) I know you have all been waiting impatiently for another VRP thread. 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: 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:
Curtis L. Olson wrote: 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? Works perfectly now - as far as I can tell from a short test, 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC
Martin Spott wrote: I have the impression that the changes to the FlightGear subtree didn't make it into CVS - at least they didn't appear on checkout. Am I the only one who misses these changes ? Silly me: I set a Tag in my CVS tree last week Sorry, 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC AIEntity.cxx, 1.12,
Martin Spott wrote: I have the impression that the changes to the FlightGear subtree didn't make it into CVS - at least they didn't appear on checkout. Am I the only one who misses these changes ? I guess so, the CVS changelog was sent out to me by mail. 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/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/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
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
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:
Martin Spott wrote: No such message as this one ? cc-1020 cc: ERROR File = arch/irix/iris.c, Line = 415 The identifier AL_FORMAT_QUAD8_LOKI is undefined. case AL_FORMAT_QUAD8_LOKI: Ah, yes, now that you mention it. You will need to add #include AL/alext.h right after AL/al.h 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:
Erik Hofman wrote: You will need to add #include AL/alext.h right after AL/al.h Yep, looks good adding to that I suggest to replace alut.h with alext.h or simply remove it in simgear/sound/sample_openal.hxx, line 50, maybe line 47 as well as alut now lives in a separate tree in the OpenAL source, Thanks, 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: Yep, looks good adding to that I suggest to replace alut.h with alext.h or simply remove it in simgear/sound/sample_openal.hxx, line 50, maybe line 47 as well as alut now lives in a separate tree in the OpenAL source, O.k., I see, this is the wrong approach 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear configure.ac, 1.94, 1.95
Martin Spott wrote: Hello Erik, Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear In directory baron:/tmp/cvs-serv29428 Modified Files: configure.ac Log Message: Prepare for OpenAL 1.1 and a separate alut lubrary. Did you actually manage to compile current OpenAL CVS on IRIX ? Sure, just make sure there are no old headers (and library) installed somewhere and do a fresh make (dist)clean and make install. 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:
Erik Hofman wrote: Martin Spott wrote: Did you actually manage to compile current OpenAL CVS on IRIX ? Sure, just make sure there are no old headers (and library) installed somewhere and do a fresh make (dist)clean and make install. No such message as this one ? cc-1020 cc: ERROR File = arch/irix/iris.c, Line = 415 The identifier AL_FORMAT_QUAD8_LOKI is undefined. case AL_FORMAT_QUAD8_LOKI: Maybe I need to do a fresh checkout 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/utils/GPSsmooth Makefile.am,
Martin Spott wrote: Solaris needs '$(X_EXTRA_LIBS)' as well to resolve dependencies that are introduced by '-lplibnet', Does $(opengl_LIBS) work as well? 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/utils/GPSsmooth Makefile.am,
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/utils/GPSsmooth In directory baron:/tmp/cvs-serv8203 Modified Files: Makefile.am Log Message: IRIX fixes. Thanks - works, 'course it works, it's tested on IRIX :-) 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: docs/getstart/pdf FGShortRef.pdf, 1.8,
Martin Spott wrote: BTW, did we have a consensus on the use of EMAil addresses in The Manual ? Because the manual gets posted online, and because of the huge spam problem with any email addresses that are posted online, I'd recommend against putting email addresses into the manual. Perhaps an image of the email address, but these days, anything in clear text is immediately harvested and abused ... 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: docs/getstart/pdf
Curtis L. Olson wrote: Because the manual gets posted online, and because of the huge spam problem with any email addresses that are posted online, I'd recommend against putting email addresses into the manual. O.k., that's fine with me - I just wanted to get some feedback before removing all those addresses, 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
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 08:50, Melchior FRANZ wrote: The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) That approach to have croase objects for intersection tests and detaild ones for views is really a ood one. May be one can have models for a very low level of detail for that case. Anyway, I am thinking and started playing with that ground cache being structured in an octree. That will make the lookup time about log(n) instead of n if n is the number of triangles in the cache. 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
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 14:21, Jon Stockill wrote: I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Hmm, not really. The problem that cache solves is the lookup time when doing queries for altitude computations or in the future intersection tests with whatever (May be crashes with power lines?). If you do that test once for each timeframe and only at one place per aircraft, you can well, and you even have to, traverse the whole scenegraph to get that information. The time to traverse the whole scenegraph is too high if you want to know that information for many points and for different informations like the locations for the wires on the carrier. So the trick is to build a as small as possible subset of the scenegraph and do queries there. The smaller the cache is, the better are the response times. So for that reason, I don't think that this is usable for this task at the moment. What you will need for that will be more something similar like the groundcache covering a much bigger area. But instead of putting every surface into that cache, one could preselect the objects depending on the distance and its size, that is ignore too small ones. And additionally, one should simplyfy the surfaces to some bigger ones if they are far away. A structure like that might recycle and/or share some code with the groundcache. And such a structure can probably be well used for an improoved implementation of radar contacts. That problem is a typical LOD algorithm, I expect to find magnitudes of publications about such and fast algorithms. 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
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Berndt -- Monday 30 May 2005 00:26: Melchior FRANZ wrote: When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) 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/Models/Airport beacon.xml, 1.8,
Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. The groundcache/beacon interaction was only effecting the Yasim FDM, correct? 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: data/Models/Airport beacon.xml, 1.8,
* Dave Culp -- Monday 30 May 2005 09:27: The groundcache/beacon interaction was only effecting the Yasim FDM, correct? I've only tested it with YASim (bo105, b1900d) where I saw it before, but not after fixing it. I can't say if it happened with JSBSim, although I use both regularly. 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/Models/Airport beacon.xml, 1.8,
Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? Jon ___ 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/Models/Airport beacon.xml, 1.8,
Jon Berndt wrote: Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon ___ 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/Models/Airport beacon.xml, 1.8,
On Mon, 30 May 2005 08:50:43 +0200, Melchior wrote in message [EMAIL PROTECTED]: * Jon Berndt -- Monday 30 May 2005 00:26: Melchior FRANZ wrote: When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) ..so we need it on the ground, and immediately before impact. ;o) ..if we disable it at altitude, how much time do we need to load it immediately before impact ? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Monday 30 May 2005 13:21, Jon Stockill wrote: Jon Berndt wrote: Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon Hello Jon, well remembered:) I did give some thought to look-ahead algorithms and I think it would be possible to come up with a rolling max/min type algorithm that would only need one look-ahead sample per frame to get a good straight-line TF target agl. Gets much more complicated if turning, of course:) LeeE ___ 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/Models/Airport beacon.xml, 1.8,
On Monday 30 May 2005 13:21, Jon Stockill wrote: I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon Hello Jon, well remembered:) I did give some thought to look-ahead algorithms and I think it would be possible to come up with a rolling max/min type algorithm that would only need one look-ahead sample per frame to get a good straight-line TF target agl. Gets much more complicated if turning, of course:) LeeE If you are using look-ahead algorithms for terrain following (i.e. modeling a LANTIRN pod or something) this should only be enabled when it is actually used - probably not many models need that. Certainly, the C-172 does not. Jon ___ 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/Models/Airport beacon.xml, 1.8,
Martin Spott wrote: Melchior Franz wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Airport In directory baron:/tmp/cvs-serv27845 Modified Files: beacon.xml beacon.ac Jon, are you going to update the respective entry in our database ? It's not in there. Though there are database entries for the objects in the base package just so everything ties up the model isn't actually stored in the database. So we've nothing to change unless the path or filename changes. -- Jon Stockill [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: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ wrote: For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... ;-) The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. :-) Is this something that people should consider for any high poly structures then? -- Jon Stockill [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: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ a écrit : In less verbosity: this technique does only make sense for objects with high face *density*, not high face *number*. The beacon has a lot of vertical, or near vertical, faces. -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: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ wrote: For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... ;-) The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. :-) Is this something that people should consider for any high poly structures then? Is the ground cache for the benefit of the FDM? Jon ___ 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/Models/Airport beacon.xml, 1.8,
From: Jon Berndt Melchior FRANZ wrote: For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. Is this something that people should consider for any high poly structures then? Is the ground cache for the benefit of the FDM? In a way you could say that, but I think that these things get called an FDM issue, because any time the plane stops it is blamed on the FDM. More accurately, the above describes a situation where the program is getting hung up waiting for scenery related I/O and/or data crunching. To answer your question, the ground cache is for the benefit of the pilot. :-) Best regards, Jim ___ 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/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 03:55, Jim Wilson wrote: To answer your question, the ground cache is for the benefit of the pilot. :-) I could not say that better!!! :) 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/AIModel AIAircraft.cxx,
Martin Spott wrote: Modified Files: AIAircraft.cxx Log Message: Solaris fixes ^^ + #elif defined(sun) || defined(sgi) + # include ieeefp.h ^^^ Hehe ;-) Thanks for applying these fixes ! So far for my hope to sneak it in ;-) 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:
Erik Hofman wrote: All these patches have been committed now. I still have to look into the -pthread issue. Oh, there's no hurry ! This weekend I replaced the Sparc20 on my internet gateway with an Ultra2. While I successfully renewed the whole OS core for the 64-bit architecture (kernel, kernel modules, core shared libs and system utilities, maintenance updates, patches) I somehow managed to break the development environment. As I slept very little the past two nights (I heavily mis-estimated the required effort) I feel I'd better leave the box as-is for at least few days :-/ 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
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: Martin Spott wrote: I found a third location: Great, with the patches I posted these days and an additional '-lpthread' to the final linker run we're up to date with Solaris portability, All these patches have been committed now. I still have to look into the -pthread issue. 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:
Martin Spott wrote: I found a third location: Great, with the patches I posted these days and an additional '-lpthread' to the final linker run we're up to date with Solaris portability, 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
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. HH 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: data/Aircraft/fokker100/Models
Martin Spott wrote: The model looks very nice and the handling feels pretty easy. It's only Thanks. that I'm missing the cabin door being coupled to the parking brake as it was in your first version ;-) No, it's not ... :-) 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_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: data/Models/Weather rain.ac, NONE,
On Monday 03 Jan 2005 16:11, Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Weather In directory baron:/tmp/cvs-serv28318/Models/Weather Added Files: rain.ac rain.rgb rain.xml Log Message: Add a basic model for rain. Test w. the pc-7 This looks quite interesting but I realize that this might result in a bigger task because rain looks very different depending on where your viewpoint is (inside/outside) and at which speed you are cruising. Your model matches the rain while sitting on the runway, waiting for clearance situation. Rain during flight in a small four-seater looks like the screen steaming up combined with heavy clouds which a changing weighting depending on your cruise speed. I can't tell how rain looks at 150 kts and more Martin. Heavy precip in a PA28 at 80-110kts looks rather like an upwards waterfall on the windscreen. Dave Martin ___ 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/Models/Weather rain.ac, NONE,
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Weather In directory baron:/tmp/cvs-serv28318/Models/Weather Added Files: rain.ac rain.rgb rain.xml Log Message: Add a basic model for rain. Test w. the pc-7 This looks quite interesting but I realize that this might result in a bigger task because rain looks very different depending on where your viewpoint is (inside/outside) and at which speed you are cruising. Your model matches the rain while sitting on the runway, waiting for clearance situation. Rain during flight in a small four-seater looks like the screen steaming up combined with heavy clouds which a changing weighting depending on your cruise speed. Well, this will only cover a part of the rain problem. But I noticed there is a huge difference in appearance with different frame rates. It looks as expected on my O2 but it's totally screwed on my PC. :-( 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/Models/Weather rain.ac, NONE,
On Monday 03 Jan 2005 17:32, Erik Hofman wrote: Well, this will only cover a part of the rain problem. I had an idea a while back that being able to change the specular material setting for runways / taxiways 'on the fly' could produce the sort of wet 'sheen' you get on asphalt when it rains. Dave Martin. ___ 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/Models/Weather rain.ac, NONE,
Dave Martin wrote: On Monday 03 Jan 2005 17:32, Erik Hofman wrote: Well, this will only cover a part of the rain problem. I had an idea a while back that being able to change the specular material setting for runways / taxiways 'on the fly' could produce the sort of wet 'sheen' you get on asphalt when it rains. Good thinking! In the mean time I've updated the rain animation again and fixed several issues. 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 preferences.xml, 1.161, 1.162
On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott [EMAIL PROTECTED] Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? It uses the AC3D crease directive, which stock plib doesn't support. More importantly, FlightGear still tries to load the Nimitz even when I'm starting at an airport thousands of miles from KSFO. Is there any way to bind those AI's to a specific area, the way we do with static scenery? All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
David Megginson wrote: On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott [EMAIL PROTECTED] Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? It uses the AC3D crease directive, which stock plib doesn't support. At 03:47 today. Modified Files: nimitz.ac Log Message: Remove crease tag so that people without custom patched versions of plib can still run FlightGear. :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: datapreferences.xml, 1.161, 1.162
Melchior FRANZ wrote: * Martin Spott -- Tuesday 30 November 2004 15:55: Erik Hofman wrote: Comment out the nimitz for now. Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? Yes, he did. But Vivian's changes from today refer to a file nimitz- complex.ac, which isn't in CVS, and was apparently not sent to Erik. This made fgfs abort for me: WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/\ Models/Geometry/Nimitz/nimitz-complex.ac' for reading Fatal error: Failed to load 3D model Just delete -complex There are other things to fix as well. While landing the FA-18A on the carrier worked beautifully after applying Mathias' patches directly, the recent changes to cvs don't allow carrier landings at all. The aircraft falls through the deck, even though I have the alternative carrier-enabled JSBSim version still installed. Yes - that doesn't seem to work. I've tried going back to a date before Mathias' patch, and the patch doesn't apply properly. We appear to have got out of set somewhere along the line. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
From: Lee Elliott On Thursday 18 November 2004 21:03, Martin Spott wrote: Lee Elliott wrote: um, yes - the TSR-2 probably isn't the best a/c for carrier stuff. The FDM needs really an overhaul because the take-off performance isn't right - it currently lifts off at a lower speed if reheat isn't used :( - and it was designed to have a good stol performance, [...] It was designed for ?? STOL performance ? _These_ small wings !? Oh man, I must have missed a lesson ;-)) Martin. Yeah - and rough strips too. I believe the STO was achieved by extending the nose gear strut to increase the initial AoA. Not only would this provide more lift over the wings, it would also result in a useful down-thrust component from the engines, especially when afterburning was used. I also believe the main gear was designed to tolerate less than perfect strips. Don't know for sure but a braking parachute might have been planned too. LeeE The TSR2 also had blown flaps for short and rough take offs: http://patter.mine.nu/tsr2-2.htm Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Tuesday 23 November 2004 13:59, Richard Bytheway wrote: From: Lee Elliott On Thursday 18 November 2004 21:03, Martin Spott wrote: Lee Elliott wrote: um, yes - the TSR-2 probably isn't the best a/c for carrier stuff. The FDM needs really an overhaul because the take-off performance isn't right - it currently lifts off at a lower speed if reheat isn't used :( - and it was designed to have a good stol performance, [...] It was designed for ?? STOL performance ? _These_ small wings !? Oh man, I must have missed a lesson ;-)) Martin. Yeah - and rough strips too. I believe the STO was achieved by extending the nose gear strut to increase the initial AoA. Not only would this provide more lift over the wings, it would also result in a useful down-thrust component from the engines, especially when afterburning was used. I also believe the main gear was designed to tolerate less than perfect strips. Don't know for sure but a braking parachute might have been planned too. LeeE The TSR2 also had blown flaps for short and rough take offs: http://patter.mine.nu/tsr2-2.htm Richard Thanks for posting that link - interesting reading - saved:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Lee Elliott wrote: On Sunday 21 November 2004 21:58, Arnt Karlsen wrote: ..you forget this plane was made to fight WWIII. ;-). In a nut shell, you've got it. Well, the project started in the late fifties, way past WWII. technical/manufacturing problems (there have been a surprisingly high number of books written about the TSR2) [...] and websites. Regarding you previous posting: The TSR.2 actually _had_ a chute: http://www.suchoj.com/andere/TSR2/images/TSR2_03.jpg Cheers, 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Monday 22 November 2004 01:28, Arnt Karlsen wrote: On Mon, 22 Nov 2004 00:24:38 +, Lee wrote in message [EMAIL PROTECTED]: On Sunday 21 November 2004 21:58, Arnt Karlsen wrote: On Sun, 21 Nov 2004 21:32:12 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Lee Elliott wrote: I also believe the main gear was designed to tolerate less than perfect strips. Yes, the main gear looks to be very 'robust'. But I still wonder why they paid attention to these features. To my knowledge the TSR-2 was designed for long range and high cruise speed. This sort of aircraft typically doesn't need rough, short strips, they could safely operate from distant bases ..you forget this plane was made to fight WWIII. ;-). In a nut shell, you've got it. The requirements spec was very demanding and to a degree lead to it's failure. Even so, albeit after prolonged development, it seems as though it was coming pretty close to actually meeting those requirements when the project was cancelled. I've read that if just any one of those requirements had been relaxed just a little the a/c would have cost a lot less to produce and been a lot easier to actually manufacture. Many, if not most of the people involved in the project seem to believe that it was dropped more for political reasons (it had the potential to upset the balance of powers) rather than technical/manufacturing problems (there have been a surprisingly high number of books written about the TSR2) and considering the original specs requirements, it's likely that the TSR2 would still be in service today, had they ever got into production and service. ..any books on it's avionics? These would have needed to be reliable near nuclear firework too. Good point - no, I'm not aware of any books that go into the avionics EMP hardening. However, I've not read anything about an FCS and I believe that the design was aerodynamically stable, so it could have been flown ok as long as fuel was getting to the engines. Perhaps the crew might not have known where they were going but they'd be able to stay in the air. AFAIK, the terrain-following scheme, using a 'ski-toe' ground intersection profile, which was eventually used in the Panavia Tornado, was first developed for the TSR2. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Lee Elliott wrote: I also believe the main gear was designed to tolerate less than perfect strips. Yes, the main gear looks to be very 'robust'. But I still wonder why they paid attention to these features. To my knowledge the TSR-2 was designed for long range and high cruise speed. This sort of aircraft typically doesn't need rough, short strips, they could safely operate from distant bases Cheers, 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Sunday 21 November 2004 21:58, Arnt Karlsen wrote: On Sun, 21 Nov 2004 21:32:12 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Lee Elliott wrote: I also believe the main gear was designed to tolerate less than perfect strips. Yes, the main gear looks to be very 'robust'. But I still wonder why they paid attention to these features. To my knowledge the TSR-2 was designed for long range and high cruise speed. This sort of aircraft typically doesn't need rough, short strips, they could safely operate from distant bases ..you forget this plane was made to fight WWIII. ;-). In a nut shell, you've got it. The requirements spec was very demanding and to a degree lead to it's failure. Even so, albeit after prolonged development, it seems as though it was coming pretty close to actually meeting those requirements when the project was cancelled. I've read that if just any one of those requirements had been relaxed just a little the a/c would have cost a lot less to produce and been a lot easier to actually manufacture. Many, if not most of the people involved in the project seem to believe that it was dropped more for political reasons (it had the potential to upset the balance of powers) rather than technical/manufacturing problems (there have been a surprisingly high number of books written about the TSR2) and considering the original specs requirements, it's likely that the TSR2 would still be in service today, had they ever got into production and service. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Thursday 18 November 2004 21:03, Martin Spott wrote: Lee Elliott wrote: um, yes - the TSR-2 probably isn't the best a/c for carrier stuff. The FDM needs really an overhaul because the take-off performance isn't right - it currently lifts off at a lower speed if reheat isn't used :( - and it was designed to have a good stol performance, [...] It was designed for ?? STOL performance ? _These_ small wings !? Oh man, I must have missed a lesson ;-)) Martin. Yeah - and rough strips too. I believe the STO was achieved by extending the nose gear strut to increase the initial AoA. Not only would this provide more lift over the wings, it would also result in a useful down-thrust component from the engines, especially when afterburning was used. I also believe the main gear was designed to tolerate less than perfect strips. Don't know for sure but a braking parachute might have been planned too. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Martin Spott wrote [...] Did you manage to take off? With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea I don't know. Mathias provides you with a perfectly good carrier-capable aircraft, and you use every other kind ... :-) Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Vivian Meazza wrote: I don't know. Mathias provides you with a perfectly good carrier-capable aircraft, and you use every other kind ... :-) Well, I'm doing everything in small steps: On the Octane it is a larger undertaking to rebuild FlightGear and after I've finished I'd like to know where I made the mistakes :-) 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Thursday 18 November 2004 08:01, Vivian Meazza wrote: Martin Spott wrote [...] Did you manage to take off? With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea I don't know. Mathias provides you with a perfectly good carrier-capable aircraft, and you use every other kind ... :-) Regards, Vivian :) um, yes - the TSR-2 probably isn't the best a/c for carrier stuff. The FDM needs really an overhaul because the take-off performance isn't right - it currently lifts off at a lower speed if reheat isn't used :( - and it was designed to have a good stol performance, albeit with extending nose-gear to increase the AoA. The current FDM is pretty poor in this respect. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), 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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Martin Spott wrote Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), I would think that a side effect of putting Nimitz in the scenery. Remember, YASim gear doesn't 'see' the deck right now. You will only get the proper effects by using a JBsim aircraft. Mathias is doing some work for YASim. But it's not ready yet. Try using it as it was designed, and you should see what I mean. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
This is probably unrelated, but with the 0.9.6 win32 binaries, if you start up with a large FOV (?90), then until you reset, 3d-cockpits are unusable. Giles Robertson -Original Message- From: Martin Spott [mailto:[EMAIL PROTECTED] Sent: 17 November 2004 09:29 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), 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 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Mittwoch 17 November 2004 10:29, Martin Spott wrote: Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), It is thought to work with the ai configuration Vivian was talking about. That means you need to apply the carrier-data.diff from ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ as well as put the nimitz_demo.xml into the Data/AI/ directory. But then, YASim's physics cannot yet 'see' the carrier deck. Changing YASim and the others to see the ground cache is one of the next steps. You will only be able to taxi on the carrier's deck with that JSBSim-dropin.tar.gz from the same ftp location. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Dienstag 16 November 2004 18:25, Martin Spott wrote: into CVS is the addition of the Nimitz - no change to any FDM yet. Did I miss a mail ? True. There are many things to do. I would like to have the basic infrastructure in flightgears cvs. This way I can add the code safely to JSBSim's cvs, work on an update to YASim, etc ... But up to now, Erik gets a segfault. That is a showstopper, not only in Erik's eyes ... I want to know what the cause is. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AInimitz_demo.xml, NONE, 1.1
On Mittwoch 17 November 2004 11:29, Melchior FRANZ wrote: I applied all the stuff and it worked very well. My first carrier landing with the FA-18A succeeded already. The gear code is great! It's fun to taxi over slopes and actually see the aircraft follow them, rather than strangely sliding up with the nose gear below ground. And the FA-18 is very well done and has a nice cockpit with nice night lighting. The only problems I've encountered: * not really surprisingly, the carrier doesn't replay in replay mode. When I watched my landing in replay, the carrier had already moved along. Tricky to fix. :) I observed that too. From my point of view, do one by one ... But help is allways welcome :) * I observed one segfault that I hadn't seen before. The bt, however, didn't look like it had anything to do with the new code. I haven't saved the core file but will do so if I run into that problem again. If you see that again, could you please try to find out where that happens? Thanks! Now I hope that I will soon be able to land the bo105 realistically on slight slopes ... Stay tuned :) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Mathias Fr??hlich wrote: You will only be able to taxi on the carrier's deck with that JSBSim-dropin.tar.gz from the same ftp location. Well, this statement appears to be maybe mostly, but not entirely correct ;-) Apparently different rules apply when you put the carrier into the scenery: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Carrier_01.jpg 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Mittwoch 17 November 2004 22:20, Martin Spott wrote: Mathias Fr??hlich wrote: You will only be able to taxi on the carrier's deck with that JSBSim-dropin.tar.gz from the same ftp location. Well, this statement appears to be maybe mostly, but not entirely correct ;-) Apparently different rules apply when you put the carrier into the scenery: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Carrier_01.jpg That's when you put that carrier statically into the scenery. Then it is in the scenery branch and SSGTRAV_HOT is set in the traversal mask. This is not true for AI models. And a AI carrier will be an AI model. But nice pic anyway :) Did you manage to take off? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AInimitz_demo.xml, NONE, 1.1
Hi, On Mittwoch 17 November 2004 21:52, Melchior FRANZ wrote: Sure. Actually, I do know where it happened. I checked the backtrace, and wasn't thrilled: It was at program exit when freeing property nodes. That's why I didn't really attribute it to the new changes, although I hadn't seen that before. It was a failure not to save the core file, but I had run fgfs in gdb, and this doesn't produce them automatically. Have tried to reproduce the segfault, but it didn't happen again yet. Ok, thanks! Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Mathias Fr??hlich wrote: On Mittwoch 17 November 2004 22:20, Martin Spott wrote: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Carrier_01.jpg [...] Did you manage to take off? With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Donnerstag 18 November 2004 00:32, Martin Spott wrote: With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea ... wait until the c172 gets a launchbar :) Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Thu, 18 Nov 2004 08:15:43 +0100, Mathias wrote in message [EMAIL PROTECTED]: On Donnerstag 18 November 2004 00:32, Martin Spott wrote: With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea .. wait until the c172 gets a launchbar :) ..and for the TSR-2, a nuke AB? ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AInimitz_demo.xml, NONE, 1.1
Melchior FRANZ wrote: To be honest: I don't see any carrier. It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 It should work just with the ai... /ai stuff in my earlier post. And the whole wire/hook thing will AFAIK not work anyway, because it needs Mathias' changes, which are probably only in his branch in the JSBSim repository, but not in FlightGear. All just AFAIK, of course. Mathias has put all the necessary stuff here: ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ The code that he sent me works well, but I haven't tried it from that location yet. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Vivian Meazza wrote: I think you will only see one carrier very close to KSFO. Mathias' code only works for JBSim FDM models, so if you use a YASim model, like the Bo105, you will fall through the deck. From what I've seen on the 'cvslog' list the only change that went into CVS is the addition of the Nimitz - no change to any FDM yet. Did I miss a mail ? I hope you'll give it a go - we need some feedback. I just switched over to FreeBSD after giving SuSE-9.2 a try I'll give it a go as soon as I managed to build FG on FreeBSD, 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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: Sent: 16 November 2004 17:26 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: Vivian Meazza wrote: I think you will only see one carrier very close to KSFO. Mathias' code only works for JBSim FDM models, so if you use a YASim model, like the Bo105, you will fall through the deck. From what I've seen on the 'cvslog' list the only change that went into CVS is the addition of the Nimitz - no change to any FDM yet. Did I miss a mail ? No - the code is available at: ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ Mathias isn't quite ready to commit it yet. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Vivian Meazza wrote: Martin Spott wrote: Did I miss a mail ? No - the code is available at: ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ I know, this is _my_ server ;-)) 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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: Vivian Meazza wrote: Martin Spott wrote: Did I miss a mail ? No - the code is available at: ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ I know, this is _my_ server ;-)) Yes, of course, I had forgotten. Then I didn't understand the question, or is it all resolved? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS: data/Protocolacms.xml, NONE, 1.1
Erik Hofman writes: Jon Berndt wrote: Erik Hofman wrote: Add a protocol for the ACMS protocol which seems to be used as an output format for black-box data flight data. This configuration does not work directly since there is no FDM available that reads the accelerations from the property tree and translates them into actual lat/lon positions. Maybe I misunderstand, but JSBSim (and I assume YASim and LaRCSim, as well) use accels to determine lat/lon. It's geocentric, but it's done in JSBSim. FlightGear takes this and converts to geodetic. The file that Mr. Brito sent doesn't contain positional data but rather accelerations (together with pitch/roll/yaw). What is needed is (as a first start) a way to visualize the performed flight from that data. As a first stab I have updated the generic protocol to also accept input data on regular intervals. But what it does is nothing more than updating properties based on this data. To get back to the contents of the file, when updating the acceleration properties and either specifying --fmd=null or using YASim as it's FDM, the data is just being ignored (and in case of YASim probably just being overwritten). SO now I need a way to update lat/lon based on a starting position and acceleration data. basically velocity = velocity + acceleration XYZ = XYZ + delta_time * velocity LLZ = sgCartToGeod( XYZ ) BUT see LaRCsim / ls_step.c Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releasesFlightGear-0.9.6.tar.gz, NONE,
Frederic Bouvier wrote: Sent: 12 October 2004 18:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releasesFlightGear-0.9.6.tar.gz, NONE, Martin Spott wrote: Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/releases In directory baron:/tmp/cvs-serv18174 Added Files: FlightGear-0.9.6.tar.gz Log Message: Official source release for v0.9.6 I'm asking just to find out: Do we all agree that it makes much sense to build the upcoming binary releases with a crease-patched version of current PLIB CVS ? My Win32 build has it. I test it again and then send it to Curt. I've just downloaded and installed fgfs-0.9.6-20041010 from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/. It crashes, cause unknown. However, fgfs-0.9.6-20041009 works very well, using all the same settings, etc. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Vivian Meazza wrote: I've just downloaded and installed fgfs-0.9.6-20041010 from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/. It crashes, cause unknown. However, fgfs-0.9.6-20041009 works very well, using all the same settings, etc. To my impression there's already a 'release' package: ftp://ftp.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-win32.zip Would you mind to try that one ? 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: To my impression there's already a 'release' package: ftp://ftp.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-win32.zip Would you mind to try that one ? Did that myself and I can affirm that it works marvellous for me - with the current CVS base package, 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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releasesFlightGear-0.9.6.tar.gz, NONE,
Vivian Meazza wrote: Frederic Bouvier wrote: Sent: 12 October 2004 18:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releasesFlightGear-0.9.6.tar.gz, NONE, Martin Spott wrote: Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/releases In directory baron:/tmp/cvs-serv18174 Added Files: FlightGear-0.9.6.tar.gz Log Message: Official source release for v0.9.6 I'm asking just to find out: Do we all agree that it makes much sense to build the upcoming binary releases with a crease-patched version of current PLIB CVS ? My Win32 build has it. I test it again and then send it to Curt. I've just downloaded and installed fgfs-0.9.6-20041010 from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/. It crashes, cause unknown. However, fgfs-0.9.6-20041009 works very well, using all the same settings, etc. fgfs-0.9.6-20041009 use Dlist only for terrain and fgfs-0.9.6-20041010 use them also for static models. They all have the crease patch. Martin already mentionned that I packed a complete build for the release at the usual location. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: Martin Spott wrote: To my impression there's already a 'release' package: ftp://ftp.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-win32.zip Would you mind to try that one ? Did that myself and I can affirm that it works marvellous for me - with the current CVS base package, Maybe we could report success or failure with the name of the card and related info. There could be a limitation on the number of possible instanciable display list or something like that. For me it works great on Windows with an NVidia FX5900 and the latest available driver ( 61.77 IIRC ). I also tested it on Linux with a GF3 ( driver 61.11 ) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Frederic Bouvier wrote: Martin Spott wrote: Did that myself and I can affirm that it works marvellous for me - with the current CVS base package, Maybe we could report success or failure with the name of the card and related info. There could be a limitation on the number of possible instanciable display list or something like that. Radeon7500 series on Win2k with wxp-w2k-catalyst-8-02-040515a-015958c driver, Radeon9200 on SuSE-9.0 with 'stock' XFree86-4.3.0.1 and kernel 2.6.8.1 as well as with Xorg 6.8.1 (from CVS), Octane MXI on IRIX-6.5.22 o.k., the latter is as slow as ever, it's robably even slower as without the recent changes :-( Although this might as well be related to the fact that this is the first IRIX binary I built myelf 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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: Sent: 13 October 2004 09:42 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: Vivian Meazza wrote: I've just downloaded and installed fgfs-0.9.6-20041010 from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/. It crashes, cause unknown. However, fgfs-0.9.6-20041009 works very well, using all the same settings, etc. To my impression there's already a 'release' package: ftp://ftp.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-win32.zip Would you mind to try that one ? That one works as well as fgfs-0.9.6-20041009. Frame rates of up to 75 on a Pentium 4 2.8 512Mb Ram and Nvidia FX5200. A very worthwhile effort by all concerned. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Vivian Meazza wrote: Martin Spott wrote: Sent: 13 October 2004 09:42 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: Vivian Meazza wrote: I've just downloaded and installed fgfs-0.9.6-20041010 from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/. It crashes, cause unknown. However, fgfs-0.9.6-20041009 works very well, using all the same settings, etc. To my impression there's already a 'release' package: ftp://ftp.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-win32.zip Would you mind to try that one ? That one works as well as fgfs-0.9.6-20041009. Frame rates of up to 75 on a Pentium 4 2.8 512Mb Ram and Nvidia FX5200. A very worthwhile effort by all concerned. It's good to read that the final release works :-) It should be a little better than fgfs-0.9.6-20041009 in building areas. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Frederic Bouvier wrote: Vivian Meazza wrote: Martin Spott wrote: Sent: 13 October 2004 09:42 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: Vivian Meazza wrote: I've just downloaded and installed fgfs-0.9.6-20041010 from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/. It crashes, cause unknown. However, fgfs-0.9.6-20041009 works very well, using all the same settings, etc. To my impression there's already a 'release' package: ftp://ftp.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-win32.zip Would you mind to try that one ? That one works as well as fgfs-0.9.6-20041009. Frame rates of up to 75 on a Pentium 4 2.8 512Mb Ram and Nvidia FX5200. A very worthwhile effort by all concerned. It's good to read that the final release works :-) It should be a little better than fgfs-0.9.6-20041009 in building areas. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d the 'release' binary of fgfs does not launch, it calls MSVCR71D.DLL (not on my system). Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Harald JOHNSEN a écrit : the 'release' binary of fgfs does not launch, it calls MSVCR71D.DLL (not on my system). Sorry about that. A corrected package is here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-win32-2.zip The other one is delete Thanks for the report that fortunately came before fgsetup. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
