[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Hello Curt, Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Rascal In directory baron:/tmp/cvs-serv29111 Added Files: README.Rascal Rascal110-set.xml Rascal110.xml rascal-electrical.xml thumbnail.jpg [...] flight-modelyasim/flight-model aeroRascal110/aero fuel-fraction0.8/fuel-fraction 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. -- 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/Aircraft/Rascal README.Rascal, NONE,
Martin Spott wrote: I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Well right now there is no rascal specific dynamics model for any of our core fdm engines, so there's not really all that much to be curious about ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Martin Spott wrote: I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Martin. We went out and flew our Rascal today to collect some more video and data. I posted some pictures here: http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ We had very light / calm winds so I'm hoping the position/attitude/velocity data comes out pretty clean. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049/Models
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049/Models In directory baron:/tmp/cvs-serv7950/Models Modified Files: Lockheed1049_twa.xml Log Message: Thierry: 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. Don't get me wrong, I don't want to hurt anyone, I just want to remind that the issue hasn't been solved yet. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049 - New
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049 In directory baron:/tmp/cvs-serv14998/Lockheed1049 Log Message: Directory /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049 added to the repository The Constellation looks pretty nice, but has a significant drawback: The author has forgotten to implement the offset between FDM center and visual reference point. This means the aircraft rotates around it's nose which makes it almost impossible to accurately rotate for liftoff. Furtheron it looks really funny when the aircraft wags the whole body when you use the elevator ;-) Syd, I presume this is your work. Would you mind adding this offset ? 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/c182 In directory baron:/tmp/cvs-serv2788 Modified Files: c182-set.xml 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, 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/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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC AIEntity.cxx, 1.12,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/ATC In directory baron:/tmp/cvs-serv30924/src/ATC [...] * Use const string rather than string in function calls when appropriate. [...] 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 ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Systems vacuum.cxx, 1.7,
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/source/src/Systems In directory baron:/tmp/cvs-serv25673 Modified Files: vacuum.cxx vacuum.hxx Log Message: Allow a single vacuum system to be driven by multiple pumps. That's fine. This topic becomes even more interesting when you think of the newer PA28's which have a electrically driven backup vacuum pump, operated by a switch at the left panel boundary, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/sr20 sr20-set.xml, NONE, 1.1
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/sr20 In directory baron:/tmp/cvs-serv4330/Aircraft/sr20 Added Files: sr20-set.xml Log Message: Add some missing files. I'd suggest these changes to get things going: --- data/Aircraft/sr20/sr20-set.xml~Sat Oct 8 14:21:13 2005 +++ data/Aircraft/sr20/sr20-set.xml Sun Oct 9 16:02:09 2005 @@ -15,7 +15,7 @@ authorErik Hofman (3D)/author flight-modelyasim/flight-model - aeropa28-161/aero + aero../pa28-161/pa28-161/aero fuel-fraction0.8/fuel-fraction systems --- data/Aircraft/sr20/Models/sr20.ac~ Sun Oct 9 13:18:48 2005 +++ data/Aircraft/sr20/Models/sr20.ac Sun Oct 9 16:00:54 2005 @@ -14017,7 +14017,7 @@ OBJECT poly name cylinder loc 0.00206628 -0.224544 -0.521943 -texture /home/erik/src/fgfs/models/SR20/prop.rgb +texture /home/erik/src/fgfs/models/SR20/prop2.rgp numvert 25 0.00203025 0.123811 0.143539 -0.0281066 0.0373752 0.187383 @@ -14313,7 +14313,7 @@ OBJECT poly name cylinder loc 0.00194556 -0.343595 0.456208 -texture /home/erik/src/fgfs/models/SR20/prop.rgb +texture /home/erik/src/fgfs/models/SR20/prop2.rgp numvert 25 0.00203025 0.062403 -0.178993 -0.0281067 0.143591 -0.12606 @@ -14609,7 +14609,7 @@ OBJECT poly name cylinder loc -0.0040119 0.568139 0.0657347 -texture /home/erik/src/fgfs/models/SR20/prop.rgb +texture /home/erik/src/fgfs/models/SR20/prop2.rgp numvert 25 0.00203025 -0.186214 0.0354541 -0.0281067 -0.180966 -0.0613237 Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
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.cxx1 Oct 2005 09:56:53 - 1.27
--- renderer.cxx4 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
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
* 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? 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
* 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. :-) 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
* 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. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c150/Models/Vintage
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/c150/Models/Vintage In directory baron:/tmp/cvs-serv14308/Models/Vintage Added Files: README.TXT c150-01.rgb c150-02.rgb c150-int.rgb c150-int2.rgb Log Message: Add Mark Miller's c150 vintage look livery. (See http://home.maine.rr.com/millerdesigns/) Oh great, call this aircraft D-EENE and you have the aircraft that I used during most of my training ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear configure.ac, 1.94, 1.95
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 ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.6,
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/b1900d In directory baron:/tmp/cvs-serv4749 Modified Files: b1900d-set.xml b1900d-sound.xml b1900d.xml Log Message: Syd Adams: Here are some updates to the b1900d: The panel looks pretty nice it's just that I failed to deliver appropriate operation. In simple words: May I find a readme which tells me how to start the engines ? I remember someone made such a readme for the Beaver, which I couldn't operate without. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/BAC-TSR2/Models
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/BAC-TSR2/Models In directory baron:/tmp/cvs-serv26968/Models Modified Files: BAC-TSR2-model.xml [...] I really like this aircraft - it spreads some sort of 'charisma', very much like the Concorde ! 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Citation/Panel
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Citation/Panel In directory baron:/tmp/cvs-serv18501/Panel Added Files: Citation-II-panel.xml adf-radio.xml dme-40.xml radios.xml transparent-bg.rgb Log Message: Syd Adams: Changes to the Citation II: BTW, did you notice that the yoke, which apparently is to be connected to the stick, doesn't move fore and aft when you push/pull the stick ? This looks funny: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Citation_01.jpg Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/gui style.xml, 1.2, 1.3
Melchior Franz wrote: Update of /var/cvs/FlightGear-0.9/data/gui In directory baron:/tmp/cvs-serv29971 Ich seh' schon, waehrend die Mehrheit in Urlaub faehrt, baust Du in der Zwischenzeit den halben FlightGear um :-) Tschuess, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/gui style.xml, 1.2, 1.3
* Martin Spott -- Saturday 09 July 2005 11:51: Ich seh' schon, waehrend die Mehrheit in Urlaub faehrt, baust Du in der Zwischenzeit den halben FlightGear um :-) No, I'm not going to rewrite fgfs while the others are on vacation. :-) Although these changes look extensive, they aren't really. If I hadn't committed the font file, and changed some variable names for easier editing, there wouldn't have much been left from the diffs. Just a few lines. And I'm almost done with it. (I just try to split the patches into smaller parts, so that I look busier. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/utils/GPSsmooth Makefile.am,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/utils/GPSsmooth In directory baron:/tmp/cvs-serv20421 Modified Files: Makefile.am Log Message: Fix another dependency. [...] GPSsmooth_LDADD = \ ! -lsgtiming -lsgmisc -lsgdebug -lplibnet -lplibul \ $(joystick_LIBS) $(base_LIBS) -lz Solaris needs '$(X_EXTRA_LIBS)' as well to resolve dependencies that are introduced by '-lplibnet', Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/utils/GPSsmooth Makefile.am, 1.1,
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/source/utils/GPSsmooth In directory baron:/tmp/cvs-serv15890 Modified Files: Makefile.am Log Message: Attempt to add -lwinmm for windows builds (untested.) I'd like to suggest another fix, as the IRIX build lacks -lm, which is apparently needed. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/utils/GPSsmooth Makefile.am,
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, 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/FDM groundcache.cxx, 1.7,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/FDM In directory baron:/tmp/cvs-serv27859/FDM Modified Files: groundcache.cxx Log Message: Mathias Fröhlich: this is basically the past patch I sent to the list and which should now really (...!?!?) fix the no ground below aircraft problem. Unfortunately the 'quick hack' was a better solution for my setup. Could you elaborate the substantial difference between the 'hack' and this patch set ? Cheerio, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/FDM groundcache.cxx, 1.7,
* Martin Spott -- Thursday 02 June 2005 13:35: Mathias Fröhlich: this is basically the past patch I sent to the list and which should now really (...!?!?) fix the no ground below aircraft problem. Unfortunately the 'quick hack' was a better solution for my setup. Could you elaborate the substantial difference between the 'hack' and this patch set ? What about elaborating first why the quick hack was a better solution for you? 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
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 ? 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Stockill -- Sunday 29 May 2005 20:38: Martin Spott wrote: Melchior Franz wrote: Modified Files: beacon.xml beacon.ac Jon, are you going to update the respective entry in our database ? [...] 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. 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. :-) 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Stockill -- Sunday 29 May 2005 21:02: Melchior FRANZ wrote: 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. Is this something that people should consider for any high poly structures then? For similar objects, yes. But you won't easily find something similar. The ground cache doesn't consider a big area, only about the size of the aircraft AFAIK. The Nimitz, for example, has 2071 faces (Only a bit more than twice as much as the beacon! :-) But if you fly over it, only a few hundred vertices end up in the ground cache at the same time. Because of the small size of a beacon, all the 950 went into the cache in one go. In less verbosity: this technique does only make sense for objects with high face *density*, not high face *number*. I could be wrong, of course ... 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml , 1.8,
* Frederic Bouvier -- Sunday 29 May 2005 21:32: 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. I saw them when I edited it in Blender. But how is this relevant? If the FDM stuttered before, and doesn't now? 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,
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/AIModel AIAircraft.cxx,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/AIModel In directory baron:/tmp/cvs-serv670/src/AIModel Modified Files: AIAircraft.cxx Log Message: Solaris fixes ^^ + #elif defined(sun) || defined(sgi) + # include ieeefp.h ^^^ Hehe ;-) Thanks for applying these fixes ! 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/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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Network net_ctrls.hxx, 1.18,
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/source/src/Network In directory baron:/tmp/cvs-serv347 Modified Files: net_ctrls.hxx net_fdm.hxx Log Message: 32 bit integers are somewhat magical and handled pretty well across platforms in terms of predictable packing and byte ordering. Now, as a first step of 'least intrusive' simplification would people agree on this patch ? --- FlightGear/src/Network/net_ctrls.hxx~ 2005-05-06 12:15:48.879996000 +0200 +++ FlightGear/src/Network/net_ctrls.hxx2005-05-06 12:15:48.880005000 +0200 @@ -21,15 +21,11 @@ #ifdef HAVE_STDINT_H # include stdint.h -#elif defined( _MSC_VER ) || defined(__MINGW32__) -typedef signed char int8_t; +#elif defined( _MSC_VER ) || defined(__MINGW32__) || defined(sun) typedef signed short int16_t; typedef signed int int32_t; -typedef signed __int64 int64_t; -typedef unsigned charuint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; -typedef unsigned __int64 uint64_t; #else # error Port me! Platforms that don't have stdint.h need to define int8_t, et. al. #endif --- FlightGear/src/Network/net_fdm.hxx~ 2005-05-06 12:15:39.01000 +0200 +++ FlightGear/src/Network/net_fdm.hxx 2005-05-06 12:15:39.110017000 +0200 @@ -23,15 +23,11 @@ #ifdef HAVE_STDINT_H # include stdint.h -#elif defined( _MSC_VER ) || defined(__MINGW32__) -typedef signed char int8_t; +#elif defined( _MSC_VER ) || defined(__MINGW32__) || defined(sun) typedef signed short int16_t; typedef signed int int32_t; -typedef signed __int64 int64_t; -typedef unsigned charuint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; -typedef unsigned __int64 uint64_t; #else # error Port me! Platforms that don't have stdint.h need to define int8_t, et. al. #endif 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 09:46, Erik Hofman wrote: Modified Files: fg_os_sdl.cxx Log Message: Melchior FRANZ: Make SDL window resizable; This exposes the same problem that many GLUT users have: resizing up may cause a temporary switch to software rendering if the card is low on memory. Resizing down again switches back to HW rendering. (KSFO is texture intensive, but there are no problems in LOWL, and elsewhere.) Less and less users will have the problem as cards become better, and it's no reason not to allow resizing altogether. Bad news - I've had this change in my tree for a few months now, and it doesn't work right on OS-X, due to a fairly deep-rooted problem with PLIB / FlightGear - there doesn't seem to be a way to do a 'vid restart', i.e force every display list / buffer / texture to get deleted and reloaded. This is really something that should be supported at the PLIB level, but, well, that's another story. Anyway, the Linux GL implementation appears to re-use GL contexts upon re-size, but the OS-X sometimes tears them down and re-allocates them. When this happens, I get a very interesting looking, un-textured version of FlightGear; kinda retro but not usable. Incidentally, the OpenGL spec dodges this whole issue, but from porting various other pieces of GL code, the rule seems to be that Windows and Linux tend to re-use contexts (but some Windows drivers don't always), but the Mac drivers are very aggressive about throwing out contexts are starting again. Anyway, the 'display lists and textures are valid across a context change' assumption is basically an unportable one. BTW, this is also the reason it's hard to do a 'full-screen toggle' at runtime (which otherwise would be easy in SDL), or other graphics changing options. However, I had a look around the code and I'm pretty sure trying to make vid-restarts possible at this point would be quite invasive changes, so I didn't even bother to suggest it. Ho hum, James ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 11:37: Bad news - I've had this change in my tree for a few months now, and it doesn't work right on OS-X 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? #ifdef OSX // or whatever the #define is case SDL_VIDEORESIZE: if (SDL_SetVideoMode(e.resize.w, e.resize.h, 16, VidMask) == 0) throw sg_throwable(string(Failed to set SDL video mode: ) + SDL_GetError()); if (WindowResizeHandler) (*WindowResizeHandler)(e.resize.w, e.resize.h); break; #endif m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* Melchior FRANZ -- Wednesday 06 April 2005 12:14: Did you send a bug report to the SDL people? Or the plib people? Anyway, we allow glut windows to be resized, and I wouldn't understand if we wouldn't allow it for SDL on all systems, just because of broken OSX or broken OSX support in plib. 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 12:28: 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. So it's the glViewport() in FGRenderer::resize() that doesn't work with plib/fgfs on OSX? (It's certainly not window resizing on the SDL or GLUT level.) Is there a plib method to save all necessary resources before the viewport change and to restore them afterwards? Norman? :-) 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: 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 14:17: - 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! Sigh ... that's not so sure. - 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 :-) OK, thanks for explaining the third time. I guess even I have fully understood this now. :-) I was just too eager to defend my SDL patch, and worried that the patch would simply get reverted. I think it would be a good idea to describe the problem on the plib list and ask if a fix would be accepted. (And be prepared to wait a few weeks for an answer. You may even have to repost the question until someone bothers to answer. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* Melchior FRANZ -- Wednesday 06 April 2005 13:19: So it's the glViewport() in FGRenderer::resize() that doesn't work with plib/fgfs on OSX? 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. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker100/Models
Hello Erik, Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/fokker100/Models In directory baron:/tmp/cvs-serv14144 Modified Files: f70_cabin.ac fokker70.ac fokker70.xml Log Message: Some final changes, fixes and updates for some time The model looks very nice and the handling feels pretty easy. It's only that I'm missing the cabin door being coupled to the parking brake as it was in your first version ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Erik Hofman wrote :
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv24714
Modified Files:
fg_init.cxx
Log Message:
Geoff Air:
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft.
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
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.cxx 27 Dec 2004 17:35:22 - 1.115
--- fg_init.cxx 29 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
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Huds/Default default.xml, 1.4, 1.5
Update of /var/cvs/FlightGear-0.9/data/Huds/Default In directory baron:/tmp/cvs-serv19455/Huds/Default Modified Files: default.xml Log Message: Disable the runway outline in the hud for now until a few more issues get resolved. (It's a nifty feature though.) What do you think about adding a runtime switch ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Weather rain.ac, 1.1,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Weather In directory baron:/tmp/cvs-serv5714 Modified Files: rain.ac rain.xml Log Message: Model changes and add some select's. Great idea, especially because there's no 'cigar' around the cockpit anymore ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Weather rain.ac, NONE,
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. -- 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/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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/737/Instruments pfd2.xml,
* Martin Spott -- Monday 13 December 2004 22:14: I can confirm that the VSPEED display in the 737 PFD actually always shows the number 0 but I'd say this is still better than a fps display - at least for a real pilot. If the display sticks to 0 the pilot will realize very soon that it is broken, a display that shows totally incorrect numbers might hide a significant risk ;-) The smiley implies that this was meant as a joke, and I should take it as such. (It sounds like one, too). Having a broken instrument isn't acceptable either way. This patch was supposed to *fix* it. I just wasn't sure if fpm was a typo or if the responsible engineer didn't know that (s)he only had to add scale60/scale to make feet per minute out of /velocities/vertical-speed-fps. I even asked on the list and searched the internet[1] to find this out. If nobody feels responsible this is certainly not my fault. If you know better, why don't you submit a better patch? This wouldn't have been more work than complaining here. m. [1] for example here: http://www.b737.org.uk/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
