Re: [Flightgear-devel] GPS find nearest.
On 10 Dec 2009, at 21:41, Scott Hamilton wrote:
I can't seem to find it in airportinfo(), this is what debug.dump shows;
{ id: 'YMML', elevation: 131.97839, lat: -37.66986124, name:
'Melbourne Intl', has_metar: 1, lon: 144.842831907, runways: {
16: { id: 16, stopway: 60.045599, heading: 171.6, lat: -37.669491,
width: 45.1104, lon: 144.837952999, length: 3661.5624, threshold: 0 },
H2: { id: 'H2', stopway: 0, heading: 260.57999, lat:
-37.684215, width: 34.137599, lon: 144.856781, length:
34.137599, threshold: 0 },
H3: { id: 'H3', stopway: 0, heading: 206.95999, lat:
-37.664935, width: 34.137599, lon: 144.850311, length:
34.137599, threshold: 0 },
09: { id: 09, stopway: 60.045599, heading: 94.20, lat:
-37.661513, width: 45.1104, lon: 144.83517, length:
2278.98960001, threshold: 0 },
34: { id: 34, stopway: 60.045599, heading: 351.6, lat: -37.669491,
width: 45.1104, lon: 144.837952999, length: 3661.5624, threshold: 0 },
27: { id: 27, stopway: 60.045599, heading: 274.20999, lat:
-37.661513, width: 45.1104, lon: 144.83517, length:
2278.98960001, threshold: 0 },
H1: { id: 'H1', stopway: 0, heading: 260.57999, lat: -37.675007,
width: 34.137599, lon: 144.844390999, length: 34.137599,
threshold: 0 }
} }
Whoops, you are quite correct.
However, I shall now *add* that information to airportinfo :)
(One of the outcomes of the past year's navaids / airports work, is that
runways now have a reference to their associated ILS/LOC, so getting the
frequency is trivial)
James
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Gear on Windows
On Thu, 2009-12-10 at 11:29 -0500, Joshua C. Stonestreet wrote: RE: Building SG/FG in native MS Windows using MSVC You do not specifically state which MSVC build files you started with, but assume you used those in the respective SG/FG cvs or tar.gz sources? Nearly ALWAYS the MSVC build files are OUT-OF-DATE! This is a FAST changing project, and it is nearly IMPOSSIBLE to keep MSVC build files fully up-to-date! But that said, it is usually a simple matter to start with the current build files, and (a) delete files that no longer exist in the respective source, and (b) when you come to the link, if new files have been added to either SG or FG they will show up as unresolved externals, and you just search for where the particular functions is defined in the source, and ADD those new files to the respective projects. And while you do not particularly need to re-create exactly the same folder structure, not doing so will always mean making more adjustments in the MSVC IDE Property Pages - Configuration Properties - C/C++ - General - Additional Include Directories, and Linker - General - Additional Library Directories, and/or Linker - Input - Additional Dependencies. I have dedicated a section of my site to building flightgear, but it too will always be out-of-date, sometimes just hours after putting it there ;=)), and I now use a 'complete' - that is _ALL_ dependent sources - approach _NOT_ suited to all ;=(), especially since it depends on re-creating the EXACT folder structure for SOURCE and then copies everything to a WORK folder, using the SETUPFG.BAT file... but it works well for me ;=)) See :- http://geoffair.net/fg , specifically http://geoffair.net/fg/fgfs-047.htm , but many other pages with hopefully helpful hints... I too have NOT done an update for a while, due to some new systems (sound, shaders, etc) being modified/added recently, such that I have not yet been able to build a fully stable WIN32 version using MSVC9. Two important things hold me back at the moment, and they are :- (i) a red/orange (and sometimes dark) pall, overlay, over the scene in certain, very repeatable, circumstances, see - http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-orange-pall , and http://geoffair.net/tmp/fg/ , and (ii) using the reset causes a crash! The only other MSVC build file set I know about is here :- ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ - and the sub-directory - ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ Maybe others could remind us of other MS WIN native, MSVC build help locations... and I read here and there some have good success with CygWin... But 'old' MSVC build files in native windows is a way of life in fast changing projects ;=)) Hope this helps. Geoff. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
Hi!
Alex was kind enough to give me shell access to his machine so I think
I have this beast figured out.
1) The immediate cause of the crash is due to
DistanceOrdering::operator() accessing an invalid pointer
2) The reason for that is std::sort indexing before the array (man, I
hate templates!)
3) In turn, that is because std::sort doesn't do range check instead
assuming the comparison function is consistent
4) the comparison function (the same as in point #1) is apparently not
consistent when compiled with optimization/inlining. This may have
something to do with the 80 bit FPU in x86.
5) the problem arises when comparing the same item to itself
6) the spatialGetClosest is inserting the same item multiple times
into the array, triggering #5.
Tracking down the problem was hard because
* valgrind didn't work
* problem only happened with optimized build
* even debug prints sometimes made the problem go away
Hence, I am not entirely sure about the mechanism involved in #4.
Nevertheless, adding a special case for a==b does seem to fix the
segfault. But that is only symptomatic treatment, so let's have a
little peek at spatialGetClosest:
// base case, simplifes loop to do it seperately here
spatialFilterInBucket(sgBucketOffset(lon, lat, 0, 0), aFilter, result);
for (;result.size() aN; ++radius) {
That's a wrong start. The nearest items need not be in the same bucket
as the reference point. Consider if the point lies at the edge of the
bucket - its closest neighbour may very well be on the other side of
the boundary. I think the same applies to the loop itself - you can't
simply stop due to having the required number of items because they
are not guaranteed to be the nearest ones. Also, I am not entirely
sure that the current cutoff distance checking is sufficient. Let's
suppose a coordinate system centered on the bucket containing the ref
point at the +,- corner. (See attached diagram) Assume bucket size 1,
requested range 1.05. So the ref point is at +0.5,-0.5. Box left
bottom bucket center at -1,-1 left top at +1,+1, distance from ref
point is 1.58 for both. That satisfies the 1.5 * 1.05 = 1.575 cutoff
condition so the code will never look at the bucket centered +2,0
which could contain a point at +1.5,-0.5 with distance 1.
for ( int i=-radius; i=radius; i++) {
spatialFilterInBucket(sgBucketOffset(lon, lat, i, -radius),
aFilter, hits);
spatialFilterInBucket(sgBucketOffset(lon, lat, -radius, i),
aFilter, hits);
spatialFilterInBucket(sgBucketOffset(lon, lat, i, radius), aFilter, hits);
spatialFilterInBucket(sgBucketOffset(lon, lat, radius, i), aFilter, hits);
}
That seems to walk the four edges of the box, but it touches the
corners twice. Which is bad because it inserts duplicates that the
rest of the code doesn't expect.
I have attached the quick fix for the benefit of the people plagued by
the segfault.
--
Cheers,
Csaba/Jester
--- old/src/Navaids/positioned.cxx 2009-12-01 20:37:01.0 +0100
+++ new/src/Navaids/positioned.cxx 2009-12-11 03:23:03.0 +0100
@@ -243,6 +243,7 @@
throw sg_exception(empty reference passed to DistanceOrdering);
}
+if (a == b) return false;
double dA = distSqr(a-cart(), mPos),
dB = distSqr(b-cart(), mPos);
return dA dB;
attachment: bucket.png--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Understanding scenery archatecture
Hey gang. I've just started putting together some visual aids in understanding what happens in a scenery build process. That's well and good, but I'm having an issue with terrafit. I've recently discovered that my understanding of how terrafit works is wrong. I'd always assumed it took a grid of elevations, calculated planes of best fit, using the max error threshold, then adjusted all the heights in the grid. It turns out that it actually leaves the heights unchanged, but deletes any that aren't deemed significant. I've been reading through terrafit.cc, but I can't figure out anything about what it does to determine significance. Could anyone explain to me how terragear uses the error threshold to determine what the list of points to be included is? The very beginnings of my site for this have been slapped together (like, 20 minutes ago), so what's there is VERY MUCH still being written, expanded, and edited. But you can get an idea of what I'm trying to do at www.cullam.com/flightgear.htm. If you have Google Sketchup, you can actually see the 3D models I've built, as some of the pictures aren't very useful in two dimensions. My models of terrafit's process are obviously wrong, as I made them to model my understanding at the time. But if somebody can better explain it to me, I'll do more accurate models. With any luck, this guide will eventually be useful for people who want to get into the scenery game. -cullam __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Understanding scenery archatecture
On Fri, Dec 11, 2009 at 9:58 AM, cullam Bruce-Lockhart culla...@yahoo.comwrote: Hey gang. I've just started putting together some visual aids in understanding what happens in a scenery build process. That's well and good, but I'm having an issue with terrafit. I've recently discovered that my understanding of how terrafit works is wrong. I'd always assumed it took a grid of elevations, calculated planes of best fit, using the max error threshold, then adjusted all the heights in the grid. It turns out that it actually leaves the heights unchanged, but deletes any that aren't deemed significant. I've been reading through terrafit.cc, but I can't figure out anything about what it does to determine significance. Could anyone explain to me how terragear uses the error threshold to determine what the list of points to be included is? It's actually pretty straightforward and a cool algorithm. I'll try to briefly explain it here. Imagine two piles of grid/elevation points. (1) The pile of points that are available to use in the final fit (but haven't been selected yet) and (2) the pile of points that we have used for the final fit. We start out with all the grid elevation points in the available pile and an empty used pile. Step 1 is to select the 4 corners and move them from the available pile to the used pile. Now we triangulate the used pile of points (which should be two triangles at the start because we have 4 points.) We then look at all the available points and find the point that is furthest away from these triangular planes. This point gets moved from the available pile to the used pile. Next we triangulate the used pile of points again (now with 5 points which will yield 3 triangle surfaces.) We look at all the remaining available points and find the point that is furthest away from the new surface and add that to the used pile. Now we triangulate the used points again (6 points, 4 triangles) find the available point that is furthest from this surface, add it to the set of used points, and keep repeating. We repeat this process, incrementally improving our fitted surface, until one of two conditions is met. (A) we hit a maximum number of final points (to keep final scenery complexity under control) or (B) none of the remaining points are outside our error threshold (i.e. if our error threshold was 10m, then all the remaining available points are within 10m of the fitted surface.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] scenery opportunity : nexrad towers (and VOR shacks)
Hi Folks -- There is is an opportunity to add some interesting, aviation-related features to the FG scenery. Here is a list of NEXRAD (weather radar) sites: http://www.mmm.ucar.edu/pdas/ftp/data/nexrad-craft.net http://www.cimms.ou.edu/~langston/hybridscan/radarinfo.html And here are the specifications and a picture: http://www.roc.noaa.gov/WSR88D/Engineering/NEXRADTechInfo.aspx A 39-foot diameter sphere on a tower tends to be pretty good landmark, useful to pilots. == Of course adding nexrad towers is less important and more work than enlarging the VOR shacks: http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-vor-shack VOR shacks are definitely important visual checkpoints. How hard would it be to make a more realistic VOR shack? Fifteen meters would be a lot closer to the normal diameter in the US. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Understanding scenery archatecture
On Dec 11, 2009, at 10:58 AM, cullam Bruce-Lockhart wrote: Hey gang. I've just started putting together some visual aids in understanding what happens in a scenery build process. That's well and good, but I'm having an issue with terrafit. I've recently discovered that my understanding of how terrafit works is wrong. I'd always assumed it took a grid of elevations, calculated planes of best fit, using the max error threshold, then adjusted all the heights in the grid. It turns out that it actually leaves the heights unchanged, but deletes any that aren't deemed significant. I've been reading through terrafit.cc, but I can't figure out anything about what it does to determine significance. Could anyone explain to me how terragear uses the error threshold to determine what the list of points to be included is? see http://www.cs.cmu.edu/afs/cs/Web/People/garland/scape/ specifically http://www.cs.cmu.edu/afs/cs/Web/People/garland/scape/scape.pdf Norman-- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] print() from keyboard and joystick
Not too long ago, it was possible to print to stdout from nasal scripts called from keyboard event handlers and joystick axis handlers. In the current (development) version, print() statements have no effect chez moi. Similarly, runtime nasal error messages are not appearing. Is this intentional? Is there a fix and/or a workaround? -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] basic flight dynamics
On Fri, 11 Dec 2009, John Denker wrote: Anybody who is tempted to look at this is reminded of the output ... /output section at the end of c172p.xml I have sometimes found it useful. Does anybody know if/where this feature is documented? It is documented in section 3.1.11 (starting at page 50) in the JSBSim reference manual: http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] basic flight dynamics
This reduces by an order of magnitude the amount of adverse yaw _in cruising flight_ in the c172p. This is much more realistic. There is still a ton of adverse yaw during slow flight. commit 74e59d6c9fb1eca08fb446c26c7b5d873c45b0ea Author: John Denker j...@av8n.com Date: Fri Dec 11 11:12:08 2009 -0700 Vastly less adverse yaw during cruising flight. (Still plety during slow flight.) diff --git a/Aircraft/c172p/c172p.xml b/Aircraft/c172p/c172p.xml index 0eae36b..d9304b3 100644 --- a/Aircraft/c172p/c172p.xml +++ b/Aircraft/c172p/c172p.xml @@ -879,7 +879,8 @@ propertymetrics/Sw-sqft/property propertymetrics/bw-ft/property propertyfcs/left-aileron-pos-rad/property -value-0.0053/value +value-0.00030/value +propertyaero/alpha-deg/property /product /function function name=aero/coefficient/Cndr -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On Fri, Dec 11, 2009 at 4:13 PM, Csaba Halász csaba.hal...@gmail.com wrote: are not guaranteed to be the nearest ones. Also, I am not entirely sure that the current cutoff distance checking is sufficient. Let's suppose a coordinate system centered on the bucket containing the ref point at the +,- corner. (See attached diagram) Assume bucket size 1, requested range 1.05. So the ref point is at +0.5,-0.5. Box left bottom bucket center at -1,-1 left top at +1,+1, distance from ref point is 1.58 for both. That satisfies the 1.5 * 1.05 = 1.575 cutoff condition so the code will never look at the bucket centered +2,0 which could contain a point at +1.5,-0.5 with distance 1. Upon closer look, not only that the code won't look at the *next* box (radius=2), it won't even look at the *inner* box (radius=1), because the cutoff check comes before processing. Clearly that is wrong. Also, the whole positioned code seems to be ignorant of the fact that buckets don't have the same size. Staying with the spatialGetClosest, it assumes it can just use NxN boxes when in fact a different row (latitude) could have half or double the bucket size. spatialFind() even uses the width/height of the current bucket explicitly. In light of this, not even the patch I proposed on IRC is halfway correct, so James please don't commit that. In my opinion, such a low-level and widely used piece of code must work correctly otherwise a lot of things can break. Thus I consider this a show-stopper for the release and an attitude of the issue of terminating with 'not actually the closest', I know of, but don't really care about isn't acceptable. -- Csaba/Jester -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Gear on Windows
Geoff, I agree with all you have said, but would add the following: The reset bug has been sorted. The crash-on-exit bug has probably been sorted, but I haven't had time to test it yet. I don't see the red/orange effect you report. There is a binary here - a few days old, and using osg rev. 10753 - ftp://ftp.abbeytheatre2.org.uk/fgfs/executable/ It might be helpful if you could test it to see if it solves any of your bugs. Vivian -Original Message- From: Geoff McLane [mailto:ubu...@geoffair.info] Sent: 11 December 2009 12:37 To: FlightGear developers discussions Cc: joshua.c.stonestr...@ivv.nasa.gov Subject: Re: [Flightgear-devel] Flight Gear on Windows On Thu, 2009-12-10 at 11:29 -0500, Joshua C. Stonestreet wrote: RE: Building SG/FG in native MS Windows using MSVC You do not specifically state which MSVC build files you started with, but assume you used those in the respective SG/FG cvs or tar.gz sources? Nearly ALWAYS the MSVC build files are OUT-OF-DATE! This is a FAST changing project, and it is nearly IMPOSSIBLE to keep MSVC build files fully up-to-date! But that said, it is usually a simple matter to start with the current build files, and (a) delete files that no longer exist in the respective source, and (b) when you come to the link, if new files have been added to either SG or FG they will show up as unresolved externals, and you just search for where the particular functions is defined in the source, and ADD those new files to the respective projects. And while you do not particularly need to re-create exactly the same folder structure, not doing so will always mean making more adjustments in the MSVC IDE Property Pages - Configuration Properties - C/C++ - General - Additional Include Directories, and Linker - General - Additional Library Directories, and/or Linker - Input - Additional Dependencies. I have dedicated a section of my site to building flightgear, but it too will always be out-of-date, sometimes just hours after putting it there ;=)), and I now use a 'complete' - that is _ALL_ dependent sources - approach _NOT_ suited to all ;=(), especially since it depends on re-creating the EXACT folder structure for SOURCE and then copies everything to a WORK folder, using the SETUPFG.BAT file... but it works well for me ;=)) See :- http://geoffair.net/fg , specifically http://geoffair.net/fg/fgfs-047.htm , but many other pages with hopefully helpful hints... I too have NOT done an update for a while, due to some new systems (sound, shaders, etc) being modified/added recently, such that I have not yet been able to build a fully stable WIN32 version using MSVC9. Two important things hold me back at the moment, and they are :- (i) a red/orange (and sometimes dark) pall, overlay, over the scene in certain, very repeatable, circumstances, see - http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-orange-pall , and http://geoffair.net/tmp/fg/ , and (ii) using the reset causes a crash! The only other MSVC build file set I know about is here :- ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ - and the sub-directory - ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ Maybe others could remind us of other MS WIN native, MSVC build help locations... and I read here and there some have good success with CygWin... But 'old' MSVC build files in native windows is a way of life in fast changing projects ;=)) Hope this helps. Geoff. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Gear on Windows
I am no longer seeing the first two bugs which seem to have been sorted out this week, but do have a similar problem with sound. See my thread with Eric. From: Vivian Meazza Sent: Friday, December 11, 2009 9:13 PM To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Flight Gear on Windows Geoff, I agree with all you have said, but would add the following: The reset bug has been sorted. The crash-on-exit bug has probably been sorted, but I haven't had time to test it yet. I don't see the red/orange effect you report. There is a binary here - a few days old, and using osg rev. 10753 - ftp://ftp.abbeytheatre2.org.uk/fgfs/executable/ It might be helpful if you could test it to see if it solves any of your bugs. Vivian -Original Message- From: Geoff McLane [mailto:ubu...@geoffair.info] Sent: 11 December 2009 12:37 To: FlightGear developers discussions Cc: joshua.c.stonestr...@ivv.nasa.gov Subject: Re: [Flightgear-devel] Flight Gear on Windows On Thu, 2009-12-10 at 11:29 -0500, Joshua C. Stonestreet wrote: RE: Building SG/FG in native MS Windows using MSVC You do not specifically state which MSVC build files you started with, but assume you used those in the respective SG/FG cvs or tar.gz sources? Nearly ALWAYS the MSVC build files are OUT-OF-DATE! This is a FAST changing project, and it is nearly IMPOSSIBLE to keep MSVC build files fully up-to-date! But that said, it is usually a simple matter to start with the current build files, and (a) delete files that no longer exist in the respective source, and (b) when you come to the link, if new files have been added to either SG or FG they will show up as unresolved externals, and you just search for where the particular functions is defined in the source, and ADD those new files to the respective projects. And while you do not particularly need to re-create exactly the same folder structure, not doing so will always mean making more adjustments in the MSVC IDE Property Pages - Configuration Properties - C/C++ - General - Additional Include Directories, and Linker - General - Additional Library Directories, and/or Linker - Input - Additional Dependencies. I have dedicated a section of my site to building flightgear, but it too will always be out-of-date, sometimes just hours after putting it there ;=)), and I now use a 'complete' - that is _ALL_ dependent sources - approach _NOT_ suited to all ;=(), especially since it depends on re-creating the EXACT folder structure for SOURCE and then copies everything to a WORK folder, using the SETUPFG.BAT file... but it works well for me ;=)) See :- http://geoffair.net/fg , specifically http://geoffair.net/fg/fgfs-047.htm , but many other pages with hopefully helpful hints... I too have NOT done an update for a while, due to some new systems (sound, shaders, etc) being modified/added recently, such that I have not yet been able to build a fully stable WIN32 version using MSVC9. Two important things hold me back at the moment, and they are :- (i) a red/orange (and sometimes dark) pall, overlay, over the scene in certain, very repeatable, circumstances, see - http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-orange-pall , and http://geoffair.net/tmp/fg/ , and (ii) using the reset causes a crash! The only other MSVC build file set I know about is here :- ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ - and the sub-directory - ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ Maybe others could remind us of other MS WIN native, MSVC build help locations... and I read here and there some have good success with CygWin... But 'old' MSVC build files in native windows is a way of life in fast changing projects ;=)) Hope this helps. Geoff. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Gear on Windows
Vivian Meazza a écrit : Geoff, I agree with all you have said, but would add the following: The reset bug has been sorted. The crash-on-exit bug has probably been sorted, but I haven’t had time to test it yet. I don’t see the red/orange effect you report. got something like that too on linux, but guess what? with an ati card it's related to shaders, as once i remove the shader effects, scenary is ok. depending on sun and orientation, scenery get sudenly darker, or green, or blue affecting differently far and close field. some screens: http://janodesbois.free.fr/fg_screens/decembre09/fgfs-screen-005.png http://janodesbois.free.fr/fg_screens/decembre09/fgfs-screen-006.png http://janodesbois.free.fr/fg_screens/decembre09/fgfs-screen-024.png and an other (ati?) bug: if i have a look on the airport from obove vertically, then texture become a mess, and all is fine once shaders removed: http://janodesbois.free.fr/fg_screens/decembre09/fgfs-screen-027.png ps: and to answer to the question why have you taken an ati card? that was the only way to flight with shaders on an agp card, and so my PC can last some years more :) . using fglrx, on a debian sid with an ati radeonhd4650. jano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Gear on Windows
* jean pellotier -- Friday 11 December 2009: got something like that too on linux, but guess what? with an ati card I'm better off on Linux (with an nvidia card). I can at least decide whether I want clouds *or* material animations broken: http://members.aon.at/mfranz/material-shaders.jpg [54.9 kB] m. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] basic flight dynamics
On Fri, 2009-12-11 at 10:44 -0700, John Denker wrote: On 12/03/2009 10:18 AM, Stuart Buchanan wrote: I took the opportunity to check the PoH against the simulator experience. While I didn't go as far as getting the OAT exactly right, the errors I came across were fairly signficant (using a HUD to get accurate altitude/TAS etc.) The current c172p is better but still not great. One thing I noticed: With the throttle all the way back: -- In flight at 60 kias : tachometer = 1000 rpm -- Parked, 0 kias : 900 rpm J=V/nD so, In flight J = 60 knot/ ((1000/min)*75 in) ~=0.97 Parked J = 0.0 Cp @ 0 = 0.058, Cp @ 1 = 0.020 E.g., it takes about 3 times more power to turn the prop parked at 900 rpm than in-flight at 60 kcas and 1000 rpm. This tells me the effect of the prop loading the engine is not being modeled correctly. So, given a Cp and RPM we can estimate the required horsepower... P = Cp*rho*n^3*d^5 ((0.00238 slug/ft3) * ( 900/min)^3 * (74 in)^5) * 0.058 ~= 7.6 hp ((0.00238 slug/ft3) * ( 700/min)^3 * (74 in)^5) * 0.058 ~= 3.6 hp ((0.00238 slug/ft3) * (2700/min)^3 * (74 in)^5) * 0.058 ~= 204 hp Since our engine only reaches 160 hp@ 2700 rpm we can't spin 2700 static RPM, we can only reach 2300-2400 rpm. This is in-line with my understanding of the performance of this aircraft. The parked tach reading should be quite a bit lower. Please define quite a bit lower. Also, from a standing start, with the throttle all the way back, the model will accelerate to 30 knots in a few thousand feet. This is wildly unrealistic. I did not observe this in JSBSim stand-alone. I let the sim run for 30 seconds at 900 rpm and only reached 9 knots, after 5 minutes the speed was only 26 knots. Perhaps you had a tail wind or were headed down hill? That said, reducing idle engine power to 4.4 hp yielded a propeller RPM of 730 and a 300 second speed of 0.3 knots. Changing the throttle detent so that the throttle can be more fully closed would help with this, and maybe also with the static tach reading (above). Since thrust is directly related to RPM, yes, reducing RPM will reduce thrust here, as noted above. But there may also be issues with the prop efficiency at ultra-low airspeed (high blade angle of attack). Low blade angle of attack? Increasing airspeed increases blade AoA assuming RPM is held constant. In RL the prop efficiency is markedly reduced under such conditions. Depends on the propeller, actually. Ron -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
