Re: [Flightgear-devel] Prime Meridian Crash
On 11 Dec 2009, at 19:32, Csaba Halász wrote: 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. The code isn't 'aware' of it, but I was aware, when I wrote the code - I just opted to ignore the fact, on the basis that the results I got from testing seemed plausible. By the time you're at a latitude where it matters, you're running low on navaids/fixes anyway. 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. Well, this might surprise you, but it's actually used quite rarely *at the moment* - mostly by the GPS code, and the marker beacon code. The GPS code uses it extensively, of course - and the usage will increase quite a bit more - but most positioned users currently find things by ident or frequency. 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. Fundamentally we need a better algorithm, and probably a new data-structure - Mathias has a potential solution using a hierarchical triangle map, though the code is a bit template-heavy for my liking. Before writing the current algorithm, I experimented with various linear hashes of the lat/lon, but effectively that's what the bucket number from SGBucket gives you - and it doesn't help with 'find me all the buckets within 'x' nm of this lat/lon'. I'll take another read over Mathias' code today, but I don't think I'll like it any more than I did the last few times I read over it. Other suggestions welcome, or proposals for a sufficiently accurate 'all the SGBuckets within a given radius of position P' - allowing for behaviour at the poles and in the Pacific. BTW, it would also be possible to spatially index FGPositioneds by their cartesian position, potentially even using a BSP or similar. (Or an oct-tree). This would avoid all the wrap-around problems at the poles and -180/180 longitude search. Again, this is something I made some algorithmic doodles for, but never developed into working code. Actually, the more I think on it, the more I think the cartesian approach may be a win - assuming you can find the bsp/octree/whatever node that contains your 'search sphere' (sphere of radius set by the cutoff, centred on search location), ordering all the contents by distance is just X^2 + Y^2 + Z^2 and a sort - no geodetic computations at all. I'll think on that some more now. (And it's fairly amenable to the filtering methodology too) 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
[Flightgear-devel] nan-a-palooza
Afte taxiing a little ways down runway 31L at JFK, the display freezes and the sim starts spewing messages to the console: Warning:: Picked up error in TriangleIntersect For additional details see http://www.av8n.com/fly/fgfs/nan--25387.log This is observed when some properties are being displayed on-screen (airspeed, wind speed, and throttle position). This is reproducible chez moi, in the sense that in three attempts, I was unable to taxi more than three thousand feet down the runway (although the exact distance varied from run to run). In contrast, with no properties displayed on the screen, I was able to taxi the full length (14,000 feet or so). For details concerning the system on which this was observed, see http://www.av8n.com/fly/fgfs/barf.log -- 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] nan-a-palooza
On 12/12/2009 04:53 AM, I wrote: Afte taxiing a little ways down runway 31L at JFK, the display freezes and the sim starts spewing messages to the console: Warning:: Picked up error in TriangleIntersect For additional details see http://www.av8n.com/fly/fgfs/nan--25387.log This is observed when some properties are being displayed on-screen (airspeed, wind speed, and throttle position). This is reproducible chez moi, in the sense that in three attempts, I was unable to taxi more than three thousand feet down the runway (although the exact distance varied from run to run). In contrast, with no properties displayed on the screen, I was able to taxi the full length (14,000 feet or so). Update: It happens about half the time even with no properties being displayed on the screen. Update: The same thing is observed at SFO, not just JFK. It may happen lots of other places as well; I haven't checked. -- 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] cleared to land
John, I as I understood we don't have any real artificial/ interacting ATC in FGFS. That means the messages are more or less just for fun. If we use a generic rwy no we could argument that it is the wrong rwy for the given wind. The better solution would be to program a working/ interacting ATC as MSFS shows as an example Regards HHS Overheard at KSFO in FG: Golf Foxtrot Sierra Cleared to land This is not realistic. It would be quite unusual for SFO Tower to give a landing clearance without specifying which runway. Suggestion: Cessna Golf Foxtrot Sierra, runway one zero right, cleared to land ^^ ^ Reference: ATC-order-7110-65s section 3-5-10(a). Even in situations when Tower is arguably not required to restate the landing runway, they tend to do it anyway: Reference: http://www.liveatc.net/search/?icao=ksfo -- 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 __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- 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] nan-a-palooza
On 12/12/2009 05:16 AM, Csaba Halász wrote: Hi John, Could you please use the --enable-fpe option and try to get a backtrace? Sure. In one case I had to taxi a little while before getting an FPE: http://www.av8n.com/fly/fgfs/fpe--27376.log In another case I got an FPE very early, while the splash screen was still showing: http://www.av8n.com/fly/fgfs/fpe--27465.log (I saw the early FPE on another occasion but didn't have gdb running.) === Another observation: I find the bug is easy to reproduce when options are passed on the command line ... and harder to reproduce when the same options are requested via the .fgfsrc file. It's hard to know what to make of this, but as always we must consider the possibility that memory is getting trampled ... such that the code first affected by the bug is not the code that caused the bug ... which is no fun to debug. -- 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] cleared to land
On 12/12/2009 10:25 AM, Heiko Schulz wrote: I as I understood we don't have any real artificial/ interacting ATC in FGFS. That means the messages are more or less just for fun. If we use a generic rwy no we could argument that it is the wrong rwy for the given wind. The better solution would be to program a working/ interacting ATC as MSFS shows as an example If you want to implement an interactive AI ATC function, that would be great. In the meantime, I am reminded of the proverb: Don't let the perfect be the enemy of the good. There is already a method apt-getActiveRunwayForUsage()-ident() for determining the active runway. There is already code in tower.cxx that uses this. It seems to me that the landing clearance generated by tower.cxx could use the already-available information in a much more realistic way. We're not talking about rocket surgery. -- 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] terragear
Hi guys , Ive started some scenery developement ,have learned a fair bit in the last few days , but have more questions than answers at the moment. Ive been using the original hgt files for the Vancouver area , Im more interested in fixing the materials , roads, streams , coastline , etc. I did discover that fgfs-construct's lon , lat is the center of the work area . not bottom left like i assumed , and you need to delete the AirportArea and AirportObj folders before regenerating the airport again or you end up with holes ... Can the order of material clipping be controlled , or is that hardcoded somewhere ? I use the Mapserver shapefiles , and modify them with Qgis , but two different types of vector layers dont seem to snap together , so I get a fair bit of overlap . I think I might have ask this one before , but... why a single texture assigned to several material names ? Just a shortage of textures , or is there a limit to the amount of textures that can be used ? I also see that one material can have several texures assigned . Are they selected randomly at startup ? If anyone can shed light on some of these I'd be grateful , trying to shorten the learning curve . Thanks -- 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] terragear
On Sat, Dec 12, 2009 at 1:59 PM, syd adams adams@gmail.com wrote: Hi guys , Ive started some scenery developement ,have learned a fair bit in the last few days , but have more questions than answers at the moment. Ive been using the original hgt files for the Vancouver area , Im more interested in fixing the materials , roads, streams , coastline , etc. I did discover that fgfs-construct's lon , lat is the center of the work area . not bottom left like i assumed , and you need to delete the AirportArea and AirportObj folders before regenerating the airport again or you end up with holes ... Can the order of material clipping be controlled , or is that hardcoded somewhere ? I believe the clipping order is hard coded in the polygon.[ch]xx (or is it names.[ch]xx) file off the top of my head. I use the Mapserver shapefiles , and modify them with Qgis , but two different types of vector layers dont seem to snap together , so I get a fair bit of overlap . I think I might have ask this one before , but... why a single texture assigned to several material names ? Just a shortage of textures , or is there a limit to the amount of textures that can be used ? A part of it is to limit the amount of texture used for scenery (although we've never had a formal texture budget for different parts of the program.) And part of it could be that no one as developed a nice looking texture for that material type. I also see that one material can have several texures assigned . Are they selected randomly at startup ? This I believe was added so that you could do some randomization and reduce the problem with repeating artifacts in the land cover ... the downside is that this randomization doesn't blend well at the borders like you can do with a single tiling texture ... but there are always trade offs to everything I guess. 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] --metar
I have some basic questions about the --metar command-line option. AFAICT the getstart.pdf manual doesn't mention this option. The --verbose --help message mentions the option, and implies that it takes an argument ... but doesn't say anything about the syntax or semantics of the argument. I was hoping that something like --metar= 012345Z 0KT 10SM CLR 59/M01 A2992 would work, but it doesn't. Can somebody please explain what the --metar option is supposed to do, and/or how to specify static weather via the command line? -- 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] nan-a-palooza
Update: To observe this bug, I don't even need to taxi. I can just sit at the starting point of runway 31L at JFK with the engine off. After sitting about 8 minutes, I observe nan messages on the console. One interesting thing is that *no* floating point exception was raised this time. The FPE trap was enabled but didn't catch anything. This is in contrast to previous times where either the trap was disabled or the FPE preceded any nan messages. This time I got only a finite number of nan messages ... in contrast to previous times when I got an apparently endless spew. This was with options passed via .fgfsrc not via the command line. This is more-or-less necessary when the FPE trap is enabled, if I want the sim to live long enough to get past the splash screen. For details, see http://www.av8n.com/fly/fgfs/nan--27763.log As before, the barf of system information is at http://www.av8n.com/fly/fgfs/barf.log -- 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] nan-a-palooza
On 12/12/2009 02:03 PM, Heiko Schulz wrote: I could solve that issue with disabling AI-Traffic (Not the Interactive Traffic) I hate to ask silly questions, but ... are you suggesting --disable-ai-models Disable the artificial traffic subsystem. The last time I used that option somebody told me I was doing the wrong thing. In any case, I observe that --disable-ai-models does not make the nan problem go away. Specifically: After being parked for a few minutes I observed a finite number of nan messages on the console. This is pretty much the same as without the --disable-ai-models. The sim remained alive, but was severely obtunded. It was using 100% of the CPU, but the frame rate was down around 18, which is about half of what I would normally expect under the circumstances. Any additional suggestions for things to try would be welcome. -- 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] nan-a-palooza
On Sun, Dec 13, 2009 at 12:21 AM, John Denker j...@av8n.com wrote: Any additional suggestions for things to try would be welcome. It is very strange because I have never seen a NaN slip past the --enable-fpe guard. You could try to build my nan-fixes branch from gitorious (http://gitorious.org/~jester) to see if any of my changes make the problem go away for you. -- Cheers, 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] nan-a-palooza
On Sat, 2009-12-12 at 16:21 -0700, John Denker wrote: On 12/12/2009 02:03 PM, Heiko Schulz wrote: I could solve that issue with disabling AI-Traffic (Not the Interactive Traffic) I hate to ask silly questions, but ... are you suggesting --disable-ai-models Disable the artificial traffic subsystem. The last time I used that option somebody told me I was doing the wrong thing. No, --disable-ai-models simply hides the ai-traffic from you. It still runs. You need: --prop:/sim/ai-traffic/enabled=0 --prop:/sim/traffic-manager/enabled=0 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
Re: [Flightgear-devel] basic flight dynamics
On Sat, 2009-12-12 at 07:29 +, Ron Jensen wrote: On Fri, 2009-12-11 at 10:44 -0700, John Denker wrote: 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. Sorry, I was thinking about the angle of the relative wind to the prop disk not the individual blade AoA. You are correct, the individual blade AoA is highest with no forward velocity. I've been too deep in propeller theory lately :) 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
