Re: [Flightgear-devel] An empassioned plea
As an aside: When working on the codebase, I maintain a local script that launches FGFS by disabling whatever features prevent the simulation from being flyable on my development machine. When I am unable to turn off features that prevent the simulator from running, and disabling them in source isn't clean enough to maintain as a local patch, I stop working on the project until the next time I buy a machine ... at which point I revisit the script. Flyability includes being able to sustain at least 3 FPS. It would probably make things a lot simpler for the average user if FGFS included a wizard that automatically identified which combinations of features would be usable on a specific installation. Using that result as constraining logic in the menus would allow unusable features to be kept disabled and trivially cheap features (for the given hardware) to be kept enabled. On Wed, Apr 18, 2012 at 2:36 AM, Erik Hofman e...@ehofman.com wrote: On Wed, 2012-04-18 at 09:46 +0100, Vic Marriott wrote: It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. Why does anybody always expect the most imressive results on their old Intel 486DX? Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serving maps from internet;
On Sun, Oct 30, 2011 at 12:38 PM, Martin Spott martin.sp...@mgras.net wrote: Geoff McLane wrote: As you may know the Atlas project already has a GetMap application, linked with CURL to to do the http requests... written by Fred back in 2004, No, I didn't know. When I talked to Brian Schack about this topic, the conversation somehow got lost (and I do feel guilty in some way ). As far as I can remember the biggest obstacle was set by Atlas's tile schema being organized alongside FlightGear's Scenery tiling schema, being slightly different from what WMS tile servers typically provide. Actually I'm unable to afford the time for providing the introduction into the logic behind WMS(-C) and related protocols, but there's plenty to read at OSGeo and related projects (start at TileCache for example). BUT I'd be willing to set the tile server up - simply because I'm convinced that this is the right thing to do about serving map imagery from a server well, actually the entire infrastructure is already in place, because I've been doing this sort of stuff for years, I'd just have to compile the Atlas imagery into a suitable format. I looked into doing this a couple of years ago and got bogged down in the FGFS-specific assumptions throughout the Atlas pipeline. I came to the conclusion that the integration I had in mind would be ugly, but wasn't willing to take on the burden of forking. What is preventing us from converting the whole Atlas project to WMS, and dropping the old nomenclature? -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serving maps from internet;
On Sun, Oct 30, 2011 at 3:20 PM, Martin Spott martin.sp...@mgras.net wrote: Alex Perry wrote: [...] What is preventing us from converting the whole Atlas project to WMS, and dropping the old nomenclature? I'm just guessing: Backwards compatibility with those users who'd like to use Atlas without being required to have a functional internet uplink ? The FSweekend show next month is typically one of those cases where this schema applies. I don't know what you're getting at. If Atlas knows how to get map tiles from a URL family in addition to the usual disk file name family, that doesn't affect offline use. Having said that, I wouldn't object to Atlas becoming a URL-only utility providing it still knows about file:// to avoid depending on a local webserver! If you're suggesting that the revised Map couldn't write to files any more, I think you're assuming a larger change to it than I had in mind. It might be nice to have a third utility AtlasTileServer which does provide a caching WMS webserver for Atlas and knows how to invoke Map to draw missing tiles at need. It could (1) keep a local Map instance busy between interactive requests, (2) recurse to a remote AtlasTileServer with its correspondingly better cache and higher throughput, and (3) kick TerraSync into fetching any missing Terrain tiles first. Ideally, Atlas and AtlasTileServer are happy keeping the GET request alive (and idle) while a tile is generated on the fly, and Atlas knows how to add the late-arriving tile into the framebuffer once it actually turns up. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
To agree with Alan, but with some additional generalizations. On Tue, Sep 20, 2011 at 2:25 AM, Alan Teeder ajtee...@v-twin.org.uk wrote: When I ran the research flight simulator for a major aircraft manufacturer in the UK (many moons ago when we still had such an industry), we had a saying:- Ask 10 test pilots for their opinion, and you will get 10 different answers 1. IFR commercial pilot: airspace is completely irrelevant as they fly the clearance from ATC, initially filed by another airline individual who is not a pilot. 2. IFR general aviation pilot: airspace is only of interest on the ground when designing a clearance request that will be typed into the web terminal. 3. VFR commercial pilot: Almost irrelevant as tends to operate in areas without airspace restrictions or with full ATC coordination on an ad-hoc basis. 4. VFR cross country pilot: Interested in airspace, but usually just wanting to know where it is, to fly far around it. 5. VFR visiting pilot: Intensely interested in airspace, wants the simulator to help him learn not to accidentally bump into it. 6. VFR local pilot: Probably has it memorized anyway, owns the chart mostly to be compliant with the rules. 7. Antique / simple homebuilt pilot: Doesn't have radios or the like anyway, simply needs a few circles marked 'mode C veil'. 8. Military pilot: Doesn't use civilian charts. Could be fun to have the MTR details transcribed for simulating those fighters. 9. Shuttle pilot: I could ask if needed, but I suspect they count as [2] since they're in class A airspace until the final brick-like landing. 10. Aerobatic pilot: The boxes. And something on the simulator to be sarcastic when you accidentally leave the box. 11. RC pilot: No idea. Curt? 12. ... who is missing from the list? From: HB-GRAL To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html Lovely, keep up the good work. The comments above are intended to clarify and not discourage. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC and radio signal attenuation
If you know the phone number of the ATC facility, you should be able to enter it into a popup that looks like a satphone and communicate with them without the attenuation constraint. Oh, and extend the ATC dialog to understand say phone number and on landing call interactions. On Mon, Sep 5, 2011 at 10:01 AM, Durk Talsma durkt...@gmail.com wrote: Hi Adrian, So far, only ground to AI aircraft and AI aircraft to ground is implemented, as part of the FGATCController class. This system, if proven functional, should probably be split into a separate module and applied to all comunication, including player-to-ground and player- to-player. All code is available in my clone, branch radio-att. I'm a little pressed for time this week, so I have to keep my response a little on the short side. In essence, I think that this would be any extremely cool feature to have. Do you already have a working copy that you would consider merging with flightgear/next? If so, I would like to do so and give it a shot (after having tried it locally and after ensuring that everything works okay). So far, I only have one humble request, which is an option to conditionally disable it. Although I haven't really had the need to listen to distant stations yet, I can imagine that certain situations will arise where I need to be able to follow ATC messages across larger distances. Given that during the development cycle I would rather concentrate on debugging than on deciphering a radio message, I think that an option to conditionally disable ATC signal attenuation would be very welcome. Cheers, Durk -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, Jun 24, 2011 at 6:51 AM, Scott scott.hamil...@popplanet.biz wrote: Using SVN so you can download stuff on the fly is ridiculous, The most popular and platform agnostic way to do downloading from multiple locations, with caching and automatic updates, is HTTP these days. Does anybody know offhand how much trouble it would be for our source code to have all loaders of aircraft files go through a library that understands what a relative URL is? If we can cut that over, anybody can develop and host an airplane simply by sticking some static files on the web somewhere. Which can reference components of other airplanes. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Putting map data on SVN made incremental updates feasible. Both for maintainer uploads, and user caches. A similar argument applies to the aircraft, with the complications that (a) there are more maintainers with less coordination, and (b) the dependency graph between directories is not trivial. On the other hand, we don't need streaming on-demand retrieval since few pilots are expected to change aircraft in mid-flight. 8-) Those two complications mean that either we have to do a whole checkout (in which case we might as well use GIT) or maintainers have to mark up their directories with dependency metadata to support automated update tools (in which case SVN would work but not be ideal). I think the critical question is whether maintainers are willing to do that. Suppose they are. A post-commit hook collects all the dependency data, sprinkled across the directories, into a single self-consistent file. The client side utility does a single update to get that file, and then whatever additional updates it specifies for the desired aircraft. SVN would work well enough. We would know the total bandwidth cost for each aircraft (before caching). Supposing we continue to use GIT for development and whole-repository replication, and replace SVN with HTTP for people who want to do quick and incremental aircraft downloads. We can easily prototype the HTTP version by selecting a 1GB subset of the archive for demonstration using AppEngine free quota ... while the community evaluates that prototype. The replica of GIT head in appengine is about $2/month. Add about $1 for any user who chooses to use HTTP to replicate the entire repository instead of using GIT (but we can discourage that). Assuming most individual aircraft are a tiny fraction of the repository (especially after allowing for texture reuse), the true expenses are probably quite manageable. http://code.google.com/appengine/docs/billing.html There are probably cheaper static web hosting options out there, but I figured these numbers are a useful starting point. Personally, I don't see a value in offering HTTP per-file instead of SVN per-directory, but others may do. Hence the discussion above. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Sat, Jun 25, 2011 at 4:01 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Personally, I don't see a value in offering HTTP per-file instead of SVN per-directory, but others may do. Hence the discussion above. The main problem right now is that Git cannot cope with the size of the data, and it's getting worse by the day. The Git data repo on Gitorious is no longer fit for purpose as currently configured. I'm not trying to defend staying on single-Git, but I think the first step is to implement on-demand loading of individual aircraft (and dependencies) and prove that it works. Otherwise we'll be exposing end users to a lot of breakage. Once we can demand load reliably, breaking the repo into many pieces is relatively trivial. Streaming was mentioned (perhaps as a nice-to-have) in the context of Multiplayer. If you didn't have a particular model then it might be streamed instead of showing the rocket propelled blue and yellow glider. That's an excellent point, thank you. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-interrasync
If occasional 50x responses occur in batches, but not for most simulation runs where you synchronize scenery, don't worry about it and certainly don't blame the FGFS codebase. If 50x's occur routinely for several hours, feel free to let me know. Just in case the shared backend is misbehaving. Aside: I don't think terrasync (and thus probably the integrated library) reschedules failed requests for a few minutes later; maybe it should do so? On Wed, Jun 22, 2011 at 7:28 AM, Alan Teeder ajtee...@v-twin.org.uk wrote: Thanks for the help. The built in SVN is now available and working. Failed to synchronize directory ´Airports/Q', Server sent unexpected return value (502 Bad Gateway) in response to PROPFIND for 'svn/!svn/bln/16328/trunck/data/Scenery/Airports/R' (code 175002) SVN repository cleanup successful for 'Airports/Q' -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
Excellent! On Mon, Jun 13, 2011 at 12:50 PM, ThorstenB bre...@gmail.com wrote: Hi, the final GUI bits for a new feature are now in fgdata - the last feature addition for the 2.4 release from my part... You can download/update scenery directly from FlightGear now (main menu: Environment = Scenery). Credit for the idea goes to James - bugs are mine ;-). It provides built-in terrasync support - with some advantages: * Configuration requires a scenery target directory only (your terrasync directory) and a checkbox to enable. For now, you'll also need to provide the terrasync directory as part of your --fg-scenery paths (otherwise you won't see downloaded scenery). Maybe we can add the directory to the search path internally some time, simplifying things even more. Should help anyway (especially new users) in obtaining world scenery. Not quite as simple as loading scenery with Google Earth yet - but closer... Before someone asks: the scenery server address is displayed in the GUI, but editing is disabled. Is there any reason (right now), why users would want to change? (You could still change using preferences.xml / property browser though). * You can enable/disable scenery download any time using the menu. When you notice mid-flight that scenery is missing, just enable the download checkbox and wait a bit (depending on your connection speed ;-) ). * There is also a (still experimental) option to refresh scenery tiles once their update is complete. You could warp into a new region, initially see ocean only (default replacement for missing scenery) and eventually see the ocean tiles being replaced by actual scenery. That's still experimental though, the update logic requires improvement. Looks weird when scenery tiles are removed when the a/c is just parked/rolling on them (old scenery disappears for a second before the fresh one reappears). Also bad on final approach... And the a/c position and altitude of clouds may need to be adapted when scenery altitude has changed - which is a problem when ocean (sea level) is replaced by actual scenery (mountains...). Usually ok to enable the feature mid-flight. Otherwise, there is also a manual refresh button, so you could choose yourself at what time to replace ocean/missing scenery. The feature reuses the terrasync sources and relies on a subversion client. Either using built-in subversion (when libsvn is installed, which is recommended). Otherwise, fgfs tries calling an external utility (svn) for downloads. All the same as with original terrasync. The built-in svn support is enabled for automake right now (use --with_libsvn=no to disable). It's off by default for cmake builds (we could change that, use ENABLE_LIBSVN to enable for now). The cmake build isn't really well tested yet - except that Hudson seems happy for all targets. And as mentioned, I'd need help with cmake if it wasn't working properly. And it'd also be good to get Hudson to build the Windows/Mac binaries with built-in svn support (seems to do that for Linux/automake already). As usual, report any (new) issues. If you don't like the feature, keep the checkbox disabled and the whole thing shouldn't bother you. You can keep using manual downloads or the separate terrasync utility as before (which lives on), of course. cheers, Thorsten PS: Yes, a complete update (sg+fg+fgdata) is required for things to work. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
Tides? Ocean with LOD? On Tue, Jan 25, 2011 at 10:13 AM, Curtis Olson curtol...@gmail.com wrote: Quick explanation: the world is curved (oblate spheroid) so if in order to have an ocean that measures zero MSL at all points, it would have to be curved. To do this perfectly requires a *lot* of polygons. We have been using large polygons for the ocean so that leads to some errors depending on where you are within the polygon. Near the verticies will be pretty accurate, near the middle could be off by a few meters. Regards, Curt. On Tue, Jan 25, 2011 at 11:57 AM, Peter Brown smoothwater...@adelphia.net wrote: In attempting to place an item on the ocean surface, I came to realize that it's not the Nimitz that is hovering above MSL, it's that the ocean surface is about 7 meters below MSL. I was going to suggest simply dropping the carriers to match, but then looking around I discovered that it was not constant, as the ocean surface is different from front to back of the Nimitz. So the ocean surface is not flat. Where it meets the terrain north of the Golden Gate Bridge the water is at zero MSL. It then slopes down as it you head out to sea, to -8.72 meters below sea level, before starting to come back up again. I did not continue out to see if it continues to rise and fall, or if it's purely a dip in this area. This is different from the ocean surface being curved to match the earth, as it actually has a dip, at least in this spot. See screenshots - Terrain intersection north of Golden Gate [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at102804PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at102804PM.png[/IMG][/URL] At the Nimtiz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at100253PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at100253PM.png[/IMG][/URL] West of Nimitz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at103120PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at103120PM.png[/IMG][/URL] Anyone know why? Or, more importantly, can we set the carriers at an altitude appropriate for their default location, so they are no longer hovering? I'd prefer to do it globally so everyone was at the same altitude. Thanks, Peter -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: Announcing Summer of Code 2011
Seems like FlightGear (as a mentoring organization) has a month remaining to decide what we're going to do. Hello contact - Google is excited to announce Google Summer of CodeTM 2011! Google Summer of Code is a program designed to encourage student participation in open source development by offering these developers stipends to write code for various open source projects. Google will be working with a carefully selected group of open source, free software and technology-related groups to identify and fund a wide variety of opensource projects over a three month period. Since 2005 the program has brought together over 4,500 students around the globe with over 300 open source projects, to create millions of lines of code. [...] Here at Google, we want to inspire young developers to begin participating in open source development. Google Summer of Code provides opportunities for students in Computer Science and related fields to work on projects related to their academic pursuits. We will be accepting student applications from March 28 - April 8, 2011. For more information on Google Summer of Code 2011 and how to apply, please visit: http://socghop.appspot.com For those with further questions, please email: google-summer-of-code-disc...@googlegroups.com Thank You! Google Summer of Code Team -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D clouds and precepitation affects.
On Mon, Nov 29, 2010 at 2:21 AM, Tim Moore timoor...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:39 AM, thorsten.i.r...@jyu.fi wrote: One more observation. Yesterday I was doing tweaks to the spin related functions in my model and during spin tests I noticed that I get the same affect when I am in a spin only the clouds are rotating about a vertical axis Yes - same reason - rapid change of the orientation of the view axis. The problem is generic: a real cloud is a 3-d distribution of droplets, i.e. for rendering purposes a function f(x,y,z) of opaqueness where projections like \int f(x,y,z) dz = c(x,y) determine the appearance of the cloud as seen from the z-direction. I don't quite know if one could render that in real time if enough interpolation is used (I'm no 3d rendering expert), but even coming up with a physically correct f(x,y,z) which projects in all directions into something like a cloud is a pretty hard task. I've been thinking that, especially with multiplayer in mind, what we need is a cloud factory that takes some random (or manually selected) values and generates a realistic looking f(x,y,z) for a given class of weather phenomenon. That lets all the participants share the generator parameters and thereby have consistent rendering of the sky with suitable realism. People whose graphics servers have true 3D voxel support can use the function directly. The current state of the art in cloud rendering does treat the cloud as some kind of 3d density function and then renders it using tricks that more-or-less emulate ray-tracing. Such a system would require a lot of work to implement in fgfs (GSoC project?) The advantage of the current system is that it looks pretty good and doesn't need very powerful graphics hardware. If we outsource the conversion from voxels to blurry texture layers, the machines which are trying to maintain consistent framerate can simply send RPCs with a cone of likely flight paths and get back a cheap decomposition that looks good from those paths. Airplanes in formation or, for example, following a standard departure path will be able to reuse the decompositions. The reason I'd like to get the raytracing off the UI is that the server can use its graphics card to perform the matrix operations for doing decompositions. So we have to fake it by using texture sheets projected onto something, and then there is always some situation in which the nature of the fake is apparent. I can given you clouds which look more or less realistic in level flight and normal airplane operation (by using rather high-resolution cloud images as done now) - but they rotate in an odd way when you do aerobatics. An alternative might be to use non-rotating crosses -- like the trees -- for the cloud blobs. The problem is that the blending between the blobs becomes even trickier than what we have now. It might work well if we have a dodecahedron of textures, but only show six at any given time. That way, we're always blending about one third of our textures in or out ... and it never snaps from one to the next. I can give you static cloud sheets which look great from far below or high above - but they look unrealistically flat when level with them (doesn't work for convective clouds though - I did some of the Cirrus sheets that way). I can give you clouds which are stable against the rotations you observe in aerobatics - but they behave in an odd way when you are close to them. I can give you clouds which are stable against aerobatics and have the right behaviour when you are close to them and look straight - but when you look out of the side window or take an external view they look odd. The problem isn't going to go away - you simply can't make a 2d sheet appear like a 3d object without the 2d nature being revealed somewhere, in some situation - it's like asking from a stage magician that you should be allowed to sit and observe behind the stage as well - if you want something which looks always and everywhere like a genuine 3d object, you need a genuine 3d object. All you can do is decide where you want the problem to be. And I guess that having clouds which are stable against an airplane flying through them are more desirable as clouds which look good from a spin... But you could simply edit the cloud shaders to insert the relative position vector to the object as the reference vector for the transform rather than the view axis just to see if you like that better - it's one line to edit I think. Stacking many 2d illusions into a 3d volume is a step towards a genuine 3d object, and Tim appears to think it can be done I've been looking at the clouds code again recently, which is oddly slow on my monster machine (Phenom II x6, GTX 460) . It has the same problem that the trees code did before a big makeover: it uses instancing techniques on geometry (flat quads) that is to far simple to be treated as an
Re: [Flightgear-devel] productwiki.com another flightgear page
On Wed, Dec 15, 2010 at 12:09 PM, Peter Brown smoothwater...@adelphia.net wrote: On Dec 15, 2010, at 2:23 PM, Citronnier - Alexis Bory wrote: I did (mid october) a flightgear page on Productwiki site. Product wiki is an intersting site where you can describe and rewiew any product on a wiki basis. So feel free to improve the page and add review. Since the creation, additional links appeared on the Product manuals (click see all on the right column). http://www.productwiki.com/flightgear-flight-simulator/ Based on what I saw when following the link, I might suggest that it's not a good way to promote FlightGear, since it's not for sale. There are an Amazon and Ebay link on the site main stage as someplace to buy FlightGear, which purely takes the potential user away from what FlightGear is and exposes them to Flight Simulators that are commercial and available to purchase. I suggest a commercial product page is an excellent place to sell CDs and DVDs that include the binaries (for all platforms), all source code, the base image, and as much scenery as will fit. And the game live disk image that we've had for a while. For a bonus, add links to the t-shirts, mugs and the donation page. 8-) -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hey Curt... :)
On Sat, Nov 13, 2010 at 7:35 AM, Arnt Karlsen a...@c2i.net wrote: On Sat, 13 Nov 2010 09:57:14 +, James wrote in message On 12 Nov 2010, at 23:44, Curtis Olson wrote: My personal rule-of-thumb is to only commit when I've got time to watch the Hudson board go green - it's on an hourly poll at the moment, though we can allow other users to manually kick off builds, if you ask Gene nicely. Ah, sorry to disappoint, but you have to commit to Git first - unlike some setups, we haven't engineered a 'compile before publish' system. Hence my ensuring I have time to watch Hudson *after* a commit, and, for example, make a fix commit if I broke something. ..an idea; a bad commit that doesn't compile successfully, can it be reverted automatically? That way git would stay unbroken, until new unbroken code is added etc and compiles successfully. I like automatic build systems which, if .. * a commit fails to build for any platform, * the prior build passed for every platform, * only one commit happened in that time, * the word CRITICAL is nowhere in the change description, ... automatically rolls back ... and tells someone. As a bonus, if it fails at the third bullet, it can automatically submit builds for all the intervening releases in an attempt to make the bullet pass. As another bonus, after the rollback, the fifth bullet looks back at the first bullet to see whether it failed to build for every platform and, if so, it would be nice for someone to be notified. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter?????? - September 2010
On Sat, Oct 02, 2010 at 02:39:42PM +0100, James Turner wrote: On 1 Oct 2010, at 19:58, Gijs de Rooy wrote: I am proud to announce that the September edition of our newsletter is the longest ever! A big thank you to all contributors! I'm glad to see more and more devs (and users) add their pieces. And a big thanks to Gijs as always for assembling, chasing and editing the newsletter! It's a really good activity indicator for the project, for people who don't follow the forums or IRC. No kidding. We should probably make sure that back issues are persisted more thoroughly (and distributed) than just on the wiki server though. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tue, Jul 6, 2010 at 5:12 AM, Csaba Halász csaba.hal...@gmail.com wrote: On Tue, Jul 6, 2010 at 1:45 PM, fiers...@zonnet.nl wrote: Many modern computers are running multicore CPU's. I have noticed that FGFS only uses one thread in one core. And FGFS appears to be processor bound on my Core-I7, because the one core thread is 100% busy while my FPS are dropping in areas with a lot of scenery details (like Paris, for instance) and lots of rendering goodies switched on. I find it hard to believe that you have performance problems with a core i7, assuming you got a halfway decent graphics card to go with it. Most of the _non-minimal rendering options use considerable CPU power on any GPU that is routinely available in a mobile form factor. If we want to be able to support non-desktop users (as well as simplify demonstrations at trade shows), we need to make sure that the main thread (and in fact that whole core) are entirely dedicated to rendering. FG itself isn't CPU limited, we barely use any processing power :) As such, parallelizing FG subsystems, while a good thing in theory and certainly for the future, wouldn't help much in your case. The reason why FG itself doesn't use any CPU power is that, whenever any of the subsystem developers tries to implement an underlying simulation improvement that requires non-trivial amounts of CPU, there is massive complaint from the eye candy side of the community. This appears as a tradeoff precisely because FG doesn't support multithreading. If we had threading working safely, any simulation subsystem could choose to run in its own thread and eat an entire core as needed. The single threaded limitation currently impacts the implementation of real time weather, microcell airmass, AI operations, non-steam instruments, as well as radio navigation realism. That I'm aware of ... there are presumably others too. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is something amiss with altimeter settings?
On Sat, May 29, 2010 at 10:02 AM, Rob Shearman, Jr. rmsj...@yahoo.com wrote: Hi there -- Recently while flying with the MD-81 at cruise levels of FL330 or so, I noticed there were some significant discrepancies between the displayed altitude and the altitude found in the property tree at /position/altitude-ft. I was able to observe the same problem in the 777-200ER -- I flew a flight at 33000 and the Flight Tracker reported my altitude at close to 35000. So the discrepancy at cruise is as much as 1000-2000 feet sometimes, even when using the altimeter setting reported in the METAR (which, of course, you're not supposed to do above 18,000 in the U.S., but for testing purposes I did so to see if it accounted for the error). However, today loading up my custom ATC scope I observed a discrepancy in altimeter readings which may account for the problem. http://i289.photobucket.com/albums/ll209/rmsjr1974/altimeter-discrep.jpg Notice in the shot that the METAR is reporting 29.94, but the property tree and the scope panel are arriving at 29.90. I presume at high altitude this discrepancy would account for differences in the gauge reading. I don't understand the test you're doing. Did you manually set the instrument altimeter setting as 29.94 (copying the metar to the knob) and are now noticing that, despite doing that, FGFS internally reports what you did as 29.90? Or are you expecting FGFS to automatically copy the metar setting into the instrument, and are disappointed that it isn't doing so? This is with the 25 April CVS build, so if altimeter code has changed since the migration to git, I apologize in advance. Thanks, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Thanks for the Ride
On Thu, May 13, 2010 at 7:20 PM, Innis Cunningham inn...@hotmail.com wrote: Hi I have tried to help with FG for about 7 years but after installing FG 2.0 I give up. As I am not a computer programmer I am not able to help with coding so I tried to help with model building and AI and scenery. With FG2.0 it would appear that the AI is currently unusable and the shading in the models makes seeing things in the cockpit difficult unless the sun is in correct position.If the shading is ment to make things look better then I beg to differ. So thanks for the ride. Cheers Innis Meet local singles online. Browse profiles for FREE! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Thanks for the Ride
[Let me try sending that again] Innis, I personally have appreciated your contributions over the years. Therefore, I hope (and recommend) that you will irregularly take another look, for example after every major release, to see whether the technology implementation has changed and become suitable for you to want to be involved with FGFS again. Over the years, there have been several occasions where the developer team made changes that precluded my involvement with the project. A year or two later, other technology updates occurred that enabled me to rejoin the project again. Given the number of times that's happened to me, and I know of others it also happened to, it seems likely that you can follow the same pattern. Cheers, Alex. On Fri, May 14, 2010 at 4:43 PM, Alex Perry alex.pe...@ieee.org wrote: On Thu, May 13, 2010 at 7:20 PM, Innis Cunningham inn...@hotmail.com wrote: Hi I have tried to help with FG for about 7 years but after installing FG 2.0 I give up. As I am not a computer programmer I am not able to help with coding so I tried to help with model building and AI and scenery. With FG2.0 it would appear that the AI is currently unusable and the shading in the models makes seeing things in the cockpit difficult unless the sun is in correct position.If the shading is ment to make things look better then I beg to differ. So thanks for the ride. Cheers Innis Meet local singles online. Browse profiles for FREE! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for interactive textures backed by VNC and PDF
On Wed, May 12, 2010 at 1:35 AM, Frederic Bouvier fredfgf...@free.fr wrote: BTW, I never managed to build these OSG plugins with MSVC Not having the plugins doesn't break the SimGear side code, but the new feature doesn't end up doing anything interesting. The OSG plugins depend on otherwise-optional libraries and headers, otherwise they don't get built, so it's possible that your windows build environment is complete for OSG but doesn't have those extra source trees available to it? -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for interactive textures backed by VNC and PDF
On Wed, May 12, 2010 at 12:26 PM, Frederic Bouvier fredfgf...@free.fr wrote: Exactly, I didn't find the dependent librairies, either compiled, or compilable, with MSVC. Curious. The documentation in both the Poppler and the libvncserver source tarballs indicate that their maintainers believe the source trees should compile cleanly with msvc. I'm not in a position to verify those claims. You might want to contact them directly with any issues you've encountered. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for interactive textures backed by VNC and PDF
Two screenshots that demonstrate a use case. http://picasaweb.google.com/alex.pamurray/FlightGearAndroid?authkey=Gv1sRgCLXWsq_p96GFPQfeat=directlink I'd appreciate it if someone could review and commit this SimGear feature: http://gitorious.org/fg/alexperry-simgear/commit/95b62ec3fc898ea281dbef28f25058300baae5c3 Adds a new pick animation capability which parallels the existing action for a named object. Specifying vncaction and a transform from model space will enable all mouse clicks on that object to be delivered directly to the OSG image. Currently, the readers for VNC and PDF files yield interactive images; more are likely to be added over time. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
The Android stuff doesn't need patches in the FGFS source code, but does affect the aircraft files (obviously) as well as SimGear and OSG. Please check with me before building in case the associated patches haven't been integrated into upstream yet. On Fri, May 7, 2010 at 9:06 AM, James Turner zakal...@mac.com wrote: I want to make a 2.1 FG release, at the end of this month, or the very start of June. As far as I can see, the current code is pretty good - many bugs have been fixed since 2.0, and while I'm sure some new ones have crept in, I don't have many code quality concerns - if we were to cut tarballs from the source code today, we'd definitely be in a better place than 2.0 in terms of bugs. (If people know of regressions from 2.0, or regressions in 2.0 from 1.9.x, I hope they would mention them here, or even in the bugtracker) Anyway, the key thing - what are the steps to make a release happen. I'm seeking to capture the actual steps (and ideally script them), so even if Curt Durk both get hit by the proverbial bus tomorrow, we can still make a Flightgear release ever again. But also, I'm seeking to remove the human factors from the release process, and especially not feel that we're overloading people just because a release needs to happen - eg, around LinuxTag Durk is often quite busy organising things :) My build system ( http://zakalawe.ath.cx:8080/ ) is working well for Mac and Linux - MinGW is giving me some pain, I will look into cross-compiling mingw this weekend. If anyone wants to volunteer some time, a Windows box with Visual Studio, some disk space, and bandwidth, I am happy to work with them to get an automated VS build going. Adding more automated steps, even ones which only happen for 'special' builds (eg, a release candidate) is extremely trivial. Regards, James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Yoke mounted PDA
Has anyone made a 3D model of a PDA that attaches nicely to the existing yoke XML files? I'm thinking of portrait orientation with the form factor of an iPhone, android phone, etc, etc. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Google App Engine
On Thu, Mar 25, 2010 at 9:25 PM, Pete Morgan ac...@daffodil.uk.com wrote: Advantages * relies on Google infrastructure * does not require one to setup and maintain their own servers * can be coded in python or java * each application scales to three million page views a month or around 1.2 requests a second before it costs * can switch app versions at the click of a button * easy with more than one developer/maintainer/admin * memcached, cron, xmpp/chat and other services are built in and easy * easy to learn api * easy to deploy, built in django or any other python templating * uses googles bigtable to save data as objects * has SDK which means app works locally before deployment * Deals with slashdot with no problem Disadvantages * relies on Google infrastructure * only python or java (php with xercus) * 1000 files limit (although this can be assisted with webzip) I keep most files in the database. Much faster to upload, deploy, etc etc, and no limit on number of files. * can only speak on port 80 * cannot run some libs as a normal server would, and lacks some popular libs, eg lxml * has a 30 second (+1 to catch error) time limit per script * does not have a file system, for example scanning a /gallery/*.png directory for images is impossible * does not have a realational database as such * uses python 2.5 (a leap to 3 is expected as BDFL is at google) * cannot run a process eg a script to poll mpservers every few seconds * requires SDK to develop pete pete -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Web Site
On Tue, Mar 9, 2010 at 2:56 AM, Pete Morgan ac...@daffodil.uk.com wrote: - Do we want to lock ourselves into google? These issues worry me also, and indeed pointing www.flightgear.org to fg-www.appspot.com is likely to have other problems (major 404's will need to be handled) We should be able to design all the website so it can serve off someone's local machine, in addition to the GAE. Personally, I think as an open source project, we need to be _able_ to serve on an independent platform even if the primary webserver is GAE. As was mentioned previously, especially if we use Django ... there should be nothing that we can't easily do off-GAE. I'm tempted to suggest that 'www-disaster.flightgear.org' should continue to be a Curt-managed machine somewhere. Give it an intentionally bandwidth limited Internet connection and ensure it is always running the up to date non-GAE build of the website. That way, we can easily detect when we've accidentally built a GAE dependency into our web codebase. There is the mild concern that (over time) we get our bandwidth usage up to the point where we can no longer afford to host the content on our own machines at need. If we want to prepare for that possibility, which would not be entirely a bad thing, it might be worth keeping the GAE application broken into several pieces, to separate the bits which are serving mostly-static content separate from the ones doing database accesses. Then, if we ever have the need to move off GAE and are running a lot of bandwidth, we can dedicate one server to the database and round robin all the other content across a lot of other servers. A Major issues is that GAE does not support binary files very well, eg gallery, so I'm not sure how this would work. One possibility would be to rename the current machine as www2. or stash. and using it as the binary storage. I've never had any trouble using GAE to serve binary files, providing they're not ridiculously large (such as huge binary tarballs). As I recall, its web server by default doesn't infer content types so you have to set them yourself on dynamic content. If you still see issues, feel free to invite me to the relevant codebase and I'm happy to take poke around. The main site fg-www has no database, so the design could be ported to the current site quite easily, as it used the Django templating engine. Does the current server have python or php installed ? We might decide that none of these issues are an overriding concern. [...] I'd be SOL if google evaporated from the planet. So what's one more dependency? Maybe we should ask Google to sponsor FlightGear? Without speaking for the open source program office, I suspect the answer would be that they're very happy to continue sponsoring FlightGear by providing infrastructure that lets the project focus on its own goals ... autonomously. The things like Project Hosting, GSoC, GAE, conferences, etc ... are all trying to avoid pushing any guidance onto the open source projects that take advantage of them. I like that. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Web Site
I like it too. On Sun, Mar 7, 2010 at 9:22 PM, Pete Morgan ac...@daffodil.uk.com wrote: Have developed the idea a bit further. http://fg-www.appspot.com/ idea is to have a dedicated aircraft and Online site also is this worth pursuing ? Its quite neat and developer friendly on the Google App Engine. pete Curtis Olson wrote: On Fri, Feb 12, 2010 at 9:06 PM, Pete Morgan ac...@daffodil.uk.com mailto:ac...@daffodil.uk.com wrote: I want to help please... Hi Pete, Here's one possible idea. Why not whip together a replacement front page and maybe a sample sub-page, put it in a temporary location, and we can take a look. That way we could present some different ideas and see if we like them, but at the same time, you don't have to do a huge amount of work only to find out that no one likes the new design proposal. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] atomic terrasync, or not
Sorry, I've only just noticed this message sitting in my to-do pile. An interesting point because , yes, checkouts are not atomic. It wouldn't be hard to extend the code to retrofit atomicity around the svn code using directory renames and the like, but before we put the effort into the code I've got one question: Assuming we consistently always do atomic incremental updates to individual directories, do we store the data in the directories such that an arbitrary combination of directory versions is likely to be safe and legal? I believe not. If not, terrasync-atomic has to start by replacing your flightgear-data with a completely empty directory and only, as individual paths are verified against SVN, rename the existing (maybe updated) content into it. This would seem to be exciting, both in terms of how long the directory stays empty during initial verification (so the simulator is unusable) and in terms of how to decide what the initial prerequisites are (so the simulator doesn't get confused). I'm tempted to suggest that we either have to commit to a dependency graph for the directories that terrasync can use (and flightgear can verify at runtime), or flightgear's data loading routines need to become terrasync aware (so their thread can block while waiting for the sync to complete). If someone has a cleaner idea for how to infer the dependency graph among our many different types of directory, I'd love to hear it. John Denker wrote: Hi -- When terrasync is running, are the updates atomic? I suspect not, since terrasync depends on svn, and AFAIK svn commits are atomic but checkouts are not. I've seem some pretty weird irreproducible results which might be explained by FG reading half of a new file plus half of an old file because terrasync was in the middle of an update. So far this is mostly just a hypothesis, but it fits the facts, and I haven't been able to come up with any other hypotheses to explain what I've seen. As an example, FG died via an assertion in navradio. The runway was numbered 0. Needless to say, the airport in question doesn't have any such runway. === I hear rumors of a major upgrade/rewrite to terrasync. This might be something to keep in mind. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch to protect terrasync SVN from ^C
Done. Also added the modified source file.
On Sun, Feb 28, 2010 at 12:09 AM, Frederic Bouvier fredfgf...@free.fr wrote:
Hi Alex,
Please resend this patch gzip and attached. I can't use it as it is.
-Fred
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
terrasync-signals.patch.gz
Description: GNU Zip compressed data
// terrasync.cxx -- JIT scenery fetcher
//
// Written by Curtis Olson, started November 2002.
//
// Copyright (C) 2002 Curtis L. Olson - http://www.flightgear.org/~curt
// Copyright (C) 2008 Alexander R. Perry alex.pe...@ieee.org
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
//
// $Id: terrasync.cxx,v 1.28 2010/01/23 22:27:38 fredb Exp $
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#ifdef HAVE_WINDOWS_H
#include windows.h
#endif
#ifdef __MINGW32__
#include time.h
#include unistd.h
#endif
#include stdlib.h // atoi() atof() abs() system()
#include signal.h // signal()
#include simgear/compiler.h
#include iostream
#include fstream
#include string
#include deque
#include map
#include plib/netSocket.h
#include plib/ul.h
#include simgear/bucket/newbucket.hxx
#include simgear/misc/sg_path.hxx
#ifdef HAVE_SVN_CLIENT_H
# ifdef HAVE_LIBSVN_CLIENT_1
#include svn_auth.h
#include svn_client.h
#include svn_cmdline.h
#include svn_pools.h
# else
#undef HAVE_SVN_CLIENT_H
# endif
#endif
using namespace std;
const char* source_base = NULL;
const char* svn_base =
http://terrascenery.googlecode.com/svn/trunk/data/Scenery;;
const char* rsync_base = scenery.flightgear.org::Scenery;
const char* dest_base = terrasyncdir;
const char* rsync_cmd =
rsync --verbose --archive --delete --perms --owner --group;
#ifdef HAVE_SVN_CLIENT_H
bool use_svn = true;
#else
bool use_svn = false;
const char* svn_cmd = svn checkout;
#endif
// display usage
static void usage( const string prog ) {
cout
Usage: terrasync [options]\n
Options: \n
-d dest destination directory [required]\n
-R transport using pipe to rsync\n
-S transport using built-in svn\n
-p port listen on UDP port [default: 5501]\n
-s source source base [default: '']\n
-pid pidfile write PID to file\n
-v be more verbose\n
;
#ifdef HAVE_SVN_CLIENT_H
cout (defaults to the built in subversion) endl;
#else
cout (defaults to rsync, using external commands) endl;
#endif
cout \nExample:\n
pid=$(cat $pidfile 2/dev/null)\n
if test -n \$pid\ kill -0 $pid ; then\n
echo \terrasync already running: $pid\\n
else\n
nice /games/sport/fgs/utils/TerraSync/terrasync \\\n
-v -pid $pidfile -S -p 5500 -d /games/orig/terrasync \n
fi endl;
}
std::dequestd::string waitingTiles;
typedef std::mapstd::string,time_t CompletedTiles;
CompletedTiles completedTiles;
#ifdef HAVE_SVN_CLIENT_H
// Things we need for doing subversion checkout - often
apr_pool_t *mysvn_pool = NULL;
svn_client_ctx_t *mysvn_ctx = NULL;
svn_opt_revision_t *mysvn_rev = NULL;
svn_opt_revision_t *mysvn_rev_peg = NULL;
static const svn_version_checklist_t mysvn_checklist[] = {
{ svn_subr, svn_subr_version },
{ svn_client, svn_client_version },
{ svn_wc, svn_wc_version },
{ svn_ra, svn_ra_version },
{ svn_delta, svn_delta_version },
{ svn_diff, svn_diff_version },
{ NULL, NULL }
};
// Configure our subversion session
int mysvn_setup(void) {
// Are we already prepared?
if (mysvn_pool) return EXIT_SUCCESS;
// No, so initialize svn internals generally
#ifdef _MSC_VER
// there is a segfault when providing an error stream.
// Apparently, calling setvbuf with a nul buffer is
// not supported under msvc 7.1 ( code inside svn_cmdline_init )
if (svn_cmdline_init(terrasync, 0) != EXIT_SUCCESS)
return EXIT_FAILURE;
#else
if
[Flightgear-devel] Patch to protect terrasync SVN from ^C
Index: terrasync.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/utils/TerraSync/terrasync.cxx,v
retrieving revision 1.28
diff -u -r1.28 terrasync.cxx
--- terrasync.cxx 23 Jan 2010 22:27:38 - 1.28
+++ terrasync.cxx 28 Feb 2010 05:49:01 -
@@ -35,6 +35,7 @@
#endif
#include stdlib.h // atoi() atof() abs() system()
+#include signal.h // signal()
#include simgear/compiler.h
@@ -270,8 +271,23 @@
}
+bool terminating = false;
+sighandler_t prior_signal_handlers[32];
+int termination_triggering_signals[] =
+ {SIGHUP, SIGINT, SIGQUIT, SIGKILL, 0}; // zero terminated
+
+void terminate_request_handler(int param) {
+cout \nReceived signal param ,
+ intend to terminate soon,
+ repeat to force an immediate effect.\n;
+terminating = true;
+signal(param, prior_signal_handlers[param]);
+}
+
+
const int nowhere = -;
+
// parse message
static void parse_message( const string msg, int *lat, int *lon ) {
double dlat, dlon;
@@ -281,8 +297,8 @@
string::size_type pos = text.find( $GPGGA );
if ( pos == string::npos )
{
- *lat = -.0;
- *lon = -.0;
+ *lat = nowhere;
+ *lon = nowhere;
return;
}
string tmp = text.substr( pos + 7 );
@@ -408,7 +424,8 @@
void getWaitingTile() {
while ( !waitingTiles.empty() ) {
- CompletedTiles::iterator ii = completedTiles.find(
waitingTiles.front() );
+ CompletedTiles::iterator ii =
+completedTiles.find( waitingTiles.front() );
time_t now = time(0);
if ( ii == completedTiles.end() || ii-second + 600 now ) {
sync_tree(waitingTiles.front().c_str());
@@ -422,7 +439,7 @@
int main( int argc, char **argv ) {
int port = 5501;
-char host[256] = ;// accept messages from anyone
+char host[256] = localhost;
bool testing = false;
bool do_checkout(true);
int verbose(0);
@@ -485,7 +502,6 @@
// Must call this before any other net stuff
netInit( argc,argv );
-
netSocket s;
if ( ! s.open( false ) ) { // open a UDP socket
@@ -524,7 +540,14 @@
}
-while ( true ) {// main loop
+for (int* sigp=termination_triggering_signals; *sigp; sigp++) {
+prior_signal_handlers[*sigp] =
+signal(*sigp, *terminate_request_handler);
+if (verbose) cout Intercepted signal *sigp endl;
+}
+
+while ( !terminating ) {
+// main loop
recv_msg = false;
if ( testing ) {
// No FGFS communications
@@ -532,6 +555,9 @@
lon = -123;
recv_msg = (lat != last_lat) || (lon != last_lon);
} else {
+if (verbose waitingTiles.empty()) {
+cout Idle; waiting for FlightGear position\n;
+}
s.setBlocking(waitingTiles.empty());
len = s.recv(msg, maxlen, 0);
if (len = 0) {
@@ -584,11 +610,11 @@
}
else if ( testing ) {
- exit( 0 );
+ terminating = true;
} else
ulSleep( 1 );
-} // while true
+} // while !terminating
return 0;
}
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 503
Pete, perhaps we need to create a separate queue for flightgear-usability-bugs-that-gene-doesnt-care-about. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] LinuxTag 2010 - program track
http://www.linuxtag.org/2010/en/program/call-for-papers.html Has anyone submitted a FGFS centric response to the CfP? If not, should I? -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
I am unable to use MSFS. Has someone checked whether they handle reversibles with a heuristic, or are you just guessing? James Turner zakal...@mac.com wrote: On 20 Dec 2009, at 00:02, John Denker wrote: I was also informed [off list] that the code to make reversible ILSs usable had been ignored because it was not good enough. That is not very informative, not very constructive. No clarification has been forthcoming as to what makes it not good enough. The off-list discussion was with me, for the record, and I apologise to John for being a bit glib, and then unresponsive - the last Saturday evening before Christmas, is not the ideal time to be discussing such things. What I should have said is, I don't think John's patch is a reasonable fix to the problem. Or rather, it fixes the major issue from John's perspective, which is un-flyable missed segments, but replaces it with another problem which I consider to be equally bad. (I would guess John will consider that my issue is less serious than the one he is trying to fix, but that's where we differ, I think). Anyway, my objection is that delegating the active runway to a user property (or menu item) is abdicating a hard problem to the user, instead of actually figuring out a 'good' solution. (Hence my glib 'not good enough' remark) It makes sense in a live ATC context, or some other situations (eg an instructor station), but for most users it's a confusing setting. For better or worse, MSFS and X-Plane do *not* require such a piece of user interaction, and therefore it is my position that we should not either. Clearly they have a better heuristic than we do - what I would like is for someone to propose a better heuristic. (My personal guess is that the heuristic will be based on local surface winds, but who knows, as ever I am not a pilot) Aka 'figure out what the user wanted, and do it'. I know John alluded to ESP, but I regard that as abdication - we simply need to try / think harder about a workable heuristic, instead of abandoning the idea in favour of a setting. It could be argued that John's patch is an interim step (with the heuristic being developed afterwards), and should be committed as is, but personally I don't think that's the case, and hence I do not wish to be the person who commits it to CVS - as I said off list, I'm only going to commit other people's code to CVS if I can positively convince myself that I agree with the design and code - any other stance would be untenable, really. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
+1. Reversible approaches should be configured like any other ATC controlled ground system - such as runway lighting. I have no objections to an automatic selector for which ILS end to enable, but it should be based on surface wind (for example) and not the aircraft position. John Denker j...@av8n.com wrote: Back in the 2nd week of September there was discussion of reversible ILSs. Maybe I missed something, but I thought there was rough consensus around the following ideas: a) FG behavior should be reasonably realistic. We should not make artificial assumptions that make approaches unflyable, when better alternatives are readily available. Conversely, we should not require FG to implement features that are not available in real life. b) An instrument approach procedure generally contains a missed approach segment. There is a maxim that says If you are not prepared for the miss, you are not prepared for the approach. The FAA says that half the time, a practice approach should include flying the missed approach segment. Real-world pilots take this seriously. Lives are at stake. c) You cannot show up at a real-world airport and expect both ends of a reversible ILS to be active simultaneously. The physics doesn't permit it. The signals would interfere. If runway 11 is active and you would prefer runway 29, you can ask Tower to reverse the ILS. They might or might be able to grant your wish. d) For years, FG has attempted to divine which end of the reversible ILS the pilot wants to use based on aircraft position and/or heading. This is both unrealistic (see item c) and impossible. There is no objective way to determine whether an aircraft is flying the upwind leg for runway 11 or the downwind leg for runway 29; the only difference between the two is the pilot's intentions. You've heard of problems that are so hard that they are classified as NP-complete ... well, this problem is much worse than that. It is ESP-complete. e) The current code is even more broken than that. At some airports, it gets the wrong answer 100% of the time, so that you cannot fly the inbound segments, never mind the missed approach segment. Bug reports on this issue have been discarded without comment. f) Code to fix all these problems has been available since September. It uses a preferred-approach-deg value in the property tree to decide which end of the ILS to activate. If you prefer the other end, you can easily change this property. All segments of the approach are flyable. Everything is predictable and well behaved. The same words that described the ILS service volume apply here: This is a significant departure from past FG behavior, but it is not wrong. It is feature, not a bug. This code was not committed. It was discarded without comment. === I was recently told [off list] that there was a requirement within FG to permit simultaneous approaches to both ends of a reversible ILS. This came as a surprise to me. I do not recall anybody suggesting this, even as a joke, much less any consensus in this direction. Let's be clear: We all agree it is important for both ends of the ILS to be available without undue hassle, but they don't need to be available at the same time. And without undue hassle doesn't mean without any pilot input at all, especially when the problem is ESP-complete. Most real-world instrument-rated pilots are content to fly the approach that Tower says is the active approach; they don't show up at an airport with inflexible pre- conceptions about which approach will be active. I was also informed [off list] that the code to make reversible ILSs usable had been ignored because it was not good enough. That is not very informative, not very constructive. No clarification has been forthcoming as to what makes it not good enough. Perhaps some folks on this list would be kind enough to look at the code and make constructive comments. Take a look at http://gitorious.org/~jsd/fg/sport-model/commits/sport in particular the item that speaks of reversible ILS. If there are some requirements that I am not aware of, requirements that make unflyable approaches preferable to flyable approaches, please explain. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer
Re: [Flightgear-devel] atlas global tarball
It occurred to me to take a look at the underlying simgear/screen library. The associated self-test binary TestRenderTexture is failing too so this isn't an Atlas oddity. The RenderTexture.cxx implementation is correctly detecting a 1.2 GLX ... and then calling 1.3 features anyway. Odd. On Sun, Nov 22, 2009 at 6:58 PM, Alex Perry alex.pe...@pamurray.com wrote: Having compiled Atlas so I can regenerate a few maps on my laptop, it complains that it needs a GLX 1.3 feature and my X server only supports 1.2 ... so this side project will have to wait until I've got another machine handy. On Sun, Nov 22, 2009 at 3:53 AM, Victhor Foster victhor.fos...@gmail.com wrote: Is your computer too slow to generate them? There's an option in Map that speeds up the process, I think it's --headless-mode. Does someone happen to have a tarball with all the atlas generated map images handy? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] atlas global tarball
Does someone happen to have a tarball with all the atlas generated map images handy? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] atlas global tarball
The computer isn't too slow, no. I'm just hoping to avoid having to download the entire global scenery data first. On Sun, Nov 22, 2009 at 3:53 AM, Victhor Foster victhor.fos...@gmail.com wrote: Is your computer too slow to generate them? There's an option in Map that speeds up the process, I think it's --headless-mode. Does someone happen to have a tarball with all the atlas generated map images handy? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] atlas global tarball
Having compiled Atlas so I can regenerate a few maps on my laptop, it complains that it needs a GLX 1.3 feature and my X server only supports 1.2 ... so this side project will have to wait until I've got another machine handy. On Sun, Nov 22, 2009 at 3:53 AM, Victhor Foster victhor.fos...@gmail.com wrote: Is your computer too slow to generate them? There's an option in Map that speeds up the process, I think it's --headless-mode. Does someone happen to have a tarball with all the atlas generated map images handy? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] least squares code
If I state that variance = mean(x^2) - mean(x)^2 http://en.wikipedia.org/wiki/Algorithms_for_calculating_variance And covariance = mean(xy) - mean(x) mean(y) Then a linear fit of data to: y ~ m x + c c = mean(y) m = covariance / variance On Sat, Oct 17, 2009 at 10:47 AM, Curtis Olson curtol...@gmail.com wrote: 2009/10/17 Mathias Fröhlich mathias.froehl...@gmx.net As always, tell the exact problem. Depending on your problem and requirements the solution ranges from a few lines of code to - 'better use an implementation that already exists is tested and is numerically stable'. Hi Mathias, I will be receiving a sequence of 2d data points in real time. I will start by assuming a linear relationship/fit which I know in advance is a reasonable assumption. I would like to find a way to incrementally compute a simple straight line least squares fit of the data I have received so far. I know incremental approaches exist. Isaias sent me a simple approach, but this maintains sums of all the data received so far and as Alex pointed out, that will be subject to increasing round off errors as the data accumulates (this code could be receiving hundreds of data points per second over the course of hours, days, even weeks.) So yes, a numerically stable approach is important. I suspect the code will just be a few lines, so if I can find an approach that is laid out algorithmically or in terms of some sort of pseudo-code, I'm pretty sure I can create and test my own implementation. Maybe I'm only imagining that such a thing exists, I googled for quite a while yesterday on a variety of search terms that are directly or loosely related and wasn't able to turn up what I was hoping to find. (Thus my cry for help) :-) A method that forgets the oldest data and weights newer data more heavily might also be interesting (versus an approach that sums up the entire history of the data ... although that would be ok too.) I'm happy to start simple and get fancier later on if I need to. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] least squares code
Make sure you use the one that never maintains cumulative totals prior to subtraction ... because the errors mount up too fast. On Fri, Oct 16, 2009 at 6:21 PM, Jon S. Berndt jonsber...@comcast.net wrote: I believe the “Numerical Recipes in C” (available online) has that algorithm[s]. www.nr.com. Jon From: Curtis Olson [mailto:curtol...@gmail.com] Sent: Friday, October 16, 2009 6:20 PM To: FlightGear developers discussions Subject: [Flightgear-devel] least squares code I'm having a duh moment here ... I've googled and looked through my old college text books and can't find something that I think should be easy to find. I'm probably forgetting the proper name of the technique or something stupid. The basic formulas for least squares fitting of a line to a set of data are well know. (I'm referring to the standard linear least squares fit of a line to some data.) I know I've seen a derivation of these formulas that allow you to incrementally build your least squares solution as each data point comes in (based on the current data and the past solution.) I know I've seen this several places in my life, even recently. I'd rather not spend a week re-deriving the formulas from scratch and testing and debugging. Does anyone have a link or pointer to basic code or psuedo-code that implements this incremental (recursive?) least squares approach? Thanks in advance, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RSync for TerraSync down
On Tue, Oct 6, 2009 at 10:02 AM, Martin Spott martin.sp...@mgras.net wrote: Please use 'terrasync -S' instead in order to pull the most recent Scenery via SVN. Note that the directory trees are not 'compatible', you'll have either to set up a new directory from scratch or simply purge the old one, Start a new directory for svn next to the existing one (so everything gets fetched again), but don't delete your existing scenery. Instead, list both directories on the flightgear command line so that, if svn hasn't downloaded an area yet, the simulation will use whatever you'd previously fetched using rsync. That way, there is no hurry with downloading Martin's new scenery data before you can fly again. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Fri, Sep 25, 2009 at 10:05 PM, Alex Perry alex.pe...@ieee.org wrote: On Fri, Sep 25, 2009 at 9:46 PM, Tom P zomm...@gmail.com wrote: Hi I've tried to push a Mercurial test repository (FlightGear converted from CVS) to code.google.com for a few hours, without success. It aborts regularly with the following message: searching for changes abort: error: Connection timed out After digging a bit, it looks like I stumbled on a known issue.. ooops!! http://code.google.com/p/support/issues/detail?id=2716 Could you put the exact repository you're trying to push somewhere where I can get at it? Feel free to try sending a tarball to me directly by email on the off chance it fits through the gateways. The exact tarball Tom sent over uploaded fine for me over home broadband: http://code.google.com/p/support/issues/detail?id=2716#c22 Therefore, in addition to the bitbucket repository Tom mentioned below, we also have: hg clone https://possible-little-test.googlecode.com/hg FlightGear-0.9 Both seem to work for me, so it'd probably be a good idea to do the Mercurial client tool usability testing against both repositories in case there is a difference we care about. So, next I tried on bitbucket.org, which is the mainstream Hg hosting site, and gladly it worked as expected. The complete FlightGear repo got pushed in 11minutes, and for your reference, is available here: http://bitbucket.org/tomp/fg-test/ The only thing that I don't like about bitbucket.org is that repositories are not organized by project, like on gitorious.org, but only per person. It makes sense for an anarchic... err, deeply distributed development model, but could get confusing quickly if we want to stick to a semi-centralized one. I don't think that's a factor for people trying out the client side tools for Hg to see whether they suitably usable. What now? I'll try to break TortoiseGit on the Windows side of things. Somehow I'm not convinced that Qt would use Git if it was so broken on Windows, but it's just me. Have fun! Tom On Fri, Sep 25, 2009 at 12:01 AM, Erik Hofman e...@ehofman.com wrote: Olaf Flebbe wrote: Windows Implementations: git can be tedious to use on Windows: I had big problems working on a project mixing up git repositories on linux pushed and pulled by a windows git via samba. git at some point complained about non existing differences: Somehow line ending issues emerged, or the object store got corrupted. I had no chance to look deeper into details. The stable git command on Windows needs cygwin, which is not a minimal invasive installation. (I wouldn't recommend the msys/mingw installation at this point.) The hg (mercurial) Implementation of Windows is very lean, because no POSIX emulation layer is needed. I (luckily?) had no problems with respect to line endings with hg. This alone leaves me to rethink about git in favor of hg. Either are fine with me in the end but I would hate to lose Windows developers over this. Erik -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Sat, Sep 26, 2009 at 1:50 PM, Olaf Flebbe f...@oflebbe.de wrote: I do not have write permissions to any of the hg or git reprositories... Yeah. I don't think there is a way I can find out everybody's google accounts from their email traffic. To try to speed this up, I've put up a quick web form: https://spreadsheets.google.com/viewform?formkey=dDZYb1RvYkpVRWhST2hhVFltWDQxNnc6MA But, if you prefer, feel free to just email me or Tom directly. * Both the hg https://possible-little-test.googlecode.com/hg and the gitorious repositories have corrupted the VC90 Project files. They should to be CR LF terminated files as they are in the CVS. (For instance projects/VC90/FlightGear.sln: A double click does only work with CR LF endings). If the repositories are wrong in exactly the same way, that likely means Tom made a mistake during the conversion step because I just uploaded his repository. Perhaps you could work with him to figure out what it was? We can reload the Code test repository (don't know about the Bitbucket one) as soon as we've got a fix. * The real thing would be FlightGear data! Yes. Let us figure out how to get binary data into Hg correctly first ... Greetings, Olaf -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Fri, Sep 25, 2009 at 9:46 PM, Tom P zomm...@gmail.com wrote: Hi I've tried to push a Mercurial test repository (FlightGear converted from CVS) to code.google.com for a few hours, without success. It aborts regularly with the following message: searching for changes abort: error: Connection timed out After digging a bit, it looks like I stumbled on a known issue.. ooops!! http://code.google.com/p/support/issues/detail?id=2716 Could you put the exact repository you're trying to push somewhere where I can get at it? Feel free to try sending a tarball to me directly by email on the off chance it fits through the gateways. So, next I tried on bitbucket.org, which is the mainstream Hg hosting site, and gladly it worked as expected. The complete FlightGear repo got pushed in 11minutes, and for your reference, is available here: http://bitbucket.org/tomp/fg-test/ The only thing that I don't like about bitbucket.org is that repositories are not organized by project, like on gitorious.org, but only per person. It makes sense for an anarchic... err, deeply distributed development model, but could get confusing quickly if we want to stick to a semi-centralized one. I don't think that's a factor for people trying out the client side tools for Hg to see whether they suitably usable. What now? I'll try to break TortoiseGit on the Windows side of things. Somehow I'm not convinced that Qt would use Git if it was so broken on Windows, but it's just me. Have fun! Tom On Fri, Sep 25, 2009 at 12:01 AM, Erik Hofman e...@ehofman.com wrote: Olaf Flebbe wrote: Windows Implementations: git can be tedious to use on Windows: I had big problems working on a project mixing up git repositories on linux pushed and pulled by a windows git via samba. git at some point complained about non existing differences: Somehow line ending issues emerged, or the object store got corrupted. I had no chance to look deeper into details. The stable git command on Windows needs cygwin, which is not a minimal invasive installation. (I wouldn't recommend the msys/mingw installation at this point.) The hg (mercurial) Implementation of Windows is very lean, because no POSIX emulation layer is needed. I (luckily?) had no problems with respect to line endings with hg. This alone leaves me to rethink about git in favor of hg. Either are fine with me in the end but I would hate to lose Windows developers over this. Erik -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gitorious repositories for FlightGear and SimGear
On Fri, Sep 18, 2009 at 9:51 AM, Erik Hofman e...@ehofman.com wrote: One thing I have been wondering since this discussion started; Google seems to have found a nice way to add small diffs for binary data[1]. Maybe they have incorporated that into their repository? If they have, it won't help us. We're not distributing blobs of x86 machine code. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Sun, Sep 13, 2009 at 12:56 PM, Stuart Buchanan stuart_d_bucha...@yahoo.co.uk wrote: Tim Moore wrote: On 09/02/2009 09:19 PM, Curtis Olson wrote: Is this an argument to stay with CVS for the data portion of the project? This is a good point to bring up though in advance. The default project quota at code.google.com (is there a shorter abbreviation?) CodeSite? CS? is 1Gb so we'd be fine for SimGear and FlightGear code, but we'd blow way over that for data. I'm happy to ask for a waiver on the size limit for CodeSite SVN or CodeSite Hg, but I wasn't going to bring the subject up with the administrators until our developer community has decided that this is the preferred choice. If it does. I think this is an argument for splitting up the aircraft into multiple repositories. The vast majority of space in data is used by the aircraft. With a small change to flightgear to support a path list for searching for aircraft, the unified data repository could be split into seperate repos for each aircraft author, or it could be arranged by theme (jets, warbirds, etc.) if people preferred that. I know that people do like the ease of finding a large source of downloadable aircraft in one place, in contrast to the MSFS world; the project could maintain a directory of links to available (and GPL compatible) aircraft. I like having the aircraft all in one place, and being able to do a $VCS sync and go for coffee to get them all up to date. If we use lots of different repositories, we'll end up with a script that knows where all the repositories are and how to check them out into a unified directory tree. I suspect that'll be a lot less convenient to maintain in a platform independent manner, especially if we want to allow for subsystem developers who don't want to use cygwin style VCS clients. I'm very strongly in favour of splitting the Aircraft off from the core data, whatever repository we end up using. The number and size of aircraft continues to grow, far faster than the size of the core data. I'd prefer to have a dependency graph (makefiles is fine) that describes to what extent the aircraft directories aren't independent of each other. That would let fgrun do a real time sync of just the aircraft I'm about to fly immediately prior to launching the simulator. It also makes it easier and safe for the aircraft developers to share components. Any aircraft developer who doesn't want to share between aircraft doesn't need to learn how the makefiles work. At the extreme limit of this approach, internet connected simulators wouldn't need to download the base image at all. Just download the binaries, launch fgrun, wait while it checks out the top level makefile, then checks out all the dependencies required for fgrun itself to work. After that quick one-time setup, you can start making selections on aircraft and starting location. If you don't have the prerequisite data, fgrun downloads it for you. If you do, it asks whether you would like to refresh your local snapshot from the VCS before takeoff. Once that is done, we know the data tree is ready for FGFS. The manual command line version of that preflight (i.e. without either fgrun or terrasync) might be as simple as: make Aircraft/c172p Airports/KMYF Such a dynamic demand driven approach is still possible using multiple repositories, but the scripting automation to support it will get ugly pretty quickly. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Wed, Sep 2, 2009 at 12:02 PM, Tom Pzomm...@gmail.com wrote: My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For example, right now a complete checkout of Aircraft is ~ 2 GB, and it would double overnight. If we had a reliable dependency graph across the data files, it would be easy for developers to check out only those bits of the data tree which the test pilot actually intends to use. I imagine it would be possible for non-developer users who launch through fgrun to perform incremental downloads for the requested scenario, but it seems unlikely to me that there would be much of a benefit there. This comment isn't intended to sway the argument either way; I think all three options under consideration can do selective checkouts (given the graph). -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiling CVS FlightGear - is Subversion
You do not require the subversion libraries (and headers) if you don't mind having terrasync shell out to the command line svn command for each of the work units. But it definitely works better, and you don't have to worry about whether your paths are configured correctly, if you link the libraries in. The configure script should automatically take care of distinguishing these two cases for you. On Mon, Aug 24, 2009 at 1:02 PM, Martin Spottmartin.sp...@mgras.net wrote: Randall Green wrote: Is Subversion really necessary to compile terrasync? Yes, obviously, because TerraSync is downloading from an SVN repository, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo, June 24 - 27
Curtis Olson wrote: There is still certainly an events section on the main front page of the FlightGear web site, but lacking any future events, it only contains a link to a google calendar intended to list upcoming MP events. You might want to add a bunch of developers and users into the list of people permitted to add items to the calendar. That will encourage it to be blank less ... -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Parallel make does not work
That failure has been around for several years. On Wed, Mar 11, 2009 at 3:54 AM, Alfredo Tupone tup...@gentoo.org wrote: I did a make -j 20 building flightgear. It gave up while building it saying no rules to make libMain.a (more or less) I have changed one line of the Makefile.am to avoid it. --- src/Main/Makefile.am.old 2009-03-05 16:57:02.0 +0100 +++ src/Main/Makefile.am 2009-03-05 16:57:26.0 +0100 @@ -61,7 +61,7 @@ fgfs_SOURCES = bootstrap.cxx fgfs_LDADD = \ - $(top_builddir)/src/Main/libMain.a \ + libMain.a \ $(top_builddir)/src/Aircraft/libAircraft.a \ $(top_builddir)/src/ATCDCL/libATCDCL.a \ $(top_builddir)/src/Cockpit/libCockpit.a \ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync - location change improvements
Thank you; I was hoping to revisit that file this evening. I like the way you did the cache timing. Did you intentionally retain the cache flush on location update, or should I port that part of my patch onto your version? When we run out of real time requests, I think it is a good idea to finish up the places we used to be, since there is a good chance of the pilot going back to them in future. On Sat, Feb 7, 2009 at 10:44 AM, Frederic Bouvier fredfgf...@free.fr wrote: Alex, It appeared that my last version of terrasync was not up to the standards I asked for your version. It should now work as I was first thinking. I also added a cache with an age to retry tiles already downloaded but not more often than once every 10 minutes. Regards, -Fred Alex Perry a écrit : Thank you, those are both useful bug reports with the approach I took. Let me come up with clean fixes for both of them and then get back to you. On Wed, Feb 4, 2009 at 11:57 PM, Frederic Bouvier fredfgf...@free.fr wrote: Hi Alex, your version compiles under windows, but needs a continuous feed of messages to work. So it doesn't work with the new fgrun button that send a positional message to get a chunk of scenery without having to start the simulator. Moreover, I also thought about a tile cache that will prevent refetching an already downloaded tiles, but it would need to stop terrasync to have updates ( objects are added continuously to the repository ) or implement a sophisticated aging mechanism. So, in other words, I am not keen to commit your changes as they are. -Fred - Alex Perry a écrit : Following up on Fred's improvement to maintain a queue of pending tile syncs, the attached version extends the deque to a priority ordered list and also ensures we never repeat a sync that's already just been performed. Consequently, we're now as responsive as possible to the location change menu item. I'd appreciate if someone could check that this compiles under Windows and then commit. -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync - location change improvements
Thank you, those are both useful bug reports with the approach I took. Let me come up with clean fixes for both of them and then get back to you. On Wed, Feb 4, 2009 at 11:57 PM, Frederic Bouvier fredfgf...@free.fr wrote: Hi Alex, your version compiles under windows, but needs a continuous feed of messages to work. So it doesn't work with the new fgrun button that send a positional message to get a chunk of scenery without having to start the simulator. Moreover, I also thought about a tile cache that will prevent refetching an already downloaded tiles, but it would need to stop terrasync to have updates ( objects are added continuously to the repository ) or implement a sophisticated aging mechanism. So, in other words, I am not keen to commit your changes as they are. -Fred - Alex Perry a écrit : Following up on Fred's improvement to maintain a queue of pending tile syncs, the attached version extends the deque to a priority ordered list and also ensures we never repeat a sync that's already just been performed. Consequently, we're now as responsive as possible to the location change menu item. I'd appreciate if someone could check that this compiles under Windows and then commit. -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] terrasync - location change improvements
Following up on Fred's improvement to maintain a queue of pending tile
syncs, the attached version extends the deque to a priority ordered
list and also ensures we never repeat a sync that's already just been
performed. Consequently, we're now as responsive as possible to the
location change menu item.
I'd appreciate if someone could check that this compiles under Windows
and then commit.
// terrasync.cxx -- JIT scenery fetcher
//
// Written by Curtis Olson, started November 2002.
//
// Copyright (C) 2002 Curtis L. Olson - http://www.flightgear.org/~curt
// Copyright (C) 2008 Alexander R. Perry alex.pe...@ieee.org
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
//
// $Id: terrasync.cxx,v 1.22 2009/02/01 23:42:45 timoore Exp $
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#ifdef HAVE_WINDOWS_H
#include windows.h
#endif
#include stdlib.h // atoi() atof() abs() system()
#include simgear/compiler.h
#include iostream
#include string
#include list
#include set
#include plib/netSocket.h
#include plib/ul.h
#include simgear/bucket/newbucket.hxx
#include simgear/misc/sg_path.hxx
#ifdef HAVE_SVN_CLIENT_H
# ifdef HAVE_LIBSVN_CLIENT_1
#include svn_auth.h
#include svn_client.h
#include svn_cmdline.h
#include svn_pools.h
# else
#undef HAVE_SVN_CLIENT_H
# endif
#endif
using std::string;
using std::cout;
using std::endl;
const char* source_base = NULL;
const char* svn_base =
http://terrascenery.googlecode.com/svn/trunk/data/Scenery;;
const char* rsync_base = scenery.flightgear.org::Scenery;
const char* dest_base = terrasyncdir;
const char* rsync_cmd =
rsync --verbose --archive --delete --perms --owner --group;
#ifdef HAVE_SVN_CLIENT_H
bool use_svn = true;
#else
bool use_svn = false;
const char* svn_cmd = svn checkout;
#endif
// display usage
static void usage( const string prog ) {
cout Usage: endl
prog -p port
-R [ -s rsync_source ] -d dest endl
prog -p port
-S [ -s svn_source ] -d dest endl;
#ifdef HAVE_SVN_CLIENT_H
cout (defaults to the built in subversion) endl;
#else
cout (defaults to rsync, using external commands) endl;
#endif
}
std::liststd::string waitingTiles;
std::setstd::string completedTiles;
void urgentTile(const char* dir) {
if (completedTiles.find(dir) != completedTiles.end()) return;
waitingTiles.remove(dir);
waitingTiles.push_front(dir);
}
#ifdef HAVE_SVN_CLIENT_H
// Things we need for doing subversion checkout - often
apr_pool_t *mysvn_pool = NULL;
svn_client_ctx_t *mysvn_ctx = NULL;
svn_opt_revision_t *mysvn_rev = NULL;
static const svn_version_checklist_t mysvn_checklist[] = {
{ svn_subr, svn_subr_version },
{ svn_client, svn_client_version },
{ svn_wc, svn_wc_version },
{ svn_ra, svn_ra_version },
{ svn_delta, svn_delta_version },
{ svn_diff, svn_diff_version },
{ NULL, NULL }
};
// Configure our subversion session
int mysvn_setup(void) {
// Are we already prepared?
if (mysvn_pool) return EXIT_SUCCESS;
// No, so initialize svn internals generally
#ifdef _MSC_VER
// there is a segfault when providing an error stream.
// Apparently, calling setvbuf with a nul buffer is
// not supported under msvc 7.1 ( code inside svn_cmdline_init )
if (svn_cmdline_init(terrasync, 0) != EXIT_SUCCESS)
return EXIT_FAILURE;
#else
if (svn_cmdline_init(terrasync, stderr) != EXIT_SUCCESS)
return EXIT_FAILURE;
#endif
apr_pool_t *pool;
apr_pool_create(pool, NULL);
svn_error_t *err = NULL;
SVN_VERSION_DEFINE(mysvn_version);
err = svn_ver_check_list(mysvn_version, mysvn_checklist);
if (err)
return svn_cmdline_handle_exit_error(err, pool, terrasync: );
err = svn_ra_initialize(pool);
if (err)
return svn_cmdline_handle_exit_error(err, pool, terrasync: );
char *config_dir = NULL;
err = svn_config_ensure(config_dir, pool);
if (err)
return svn_cmdline_handle_exit_error(err, pool, terrasync: );
err = svn_client_create_context(mysvn_ctx, pool);
if (err)
return svn_cmdline_handle_exit_error(err, pool, terrasync: );
err = svn_config_get_config((mysvn_ctx-config),
config_dir, pool);
if (err)
return svn_cmdline_handle_exit_error(err, pool,
Re: [Flightgear-devel] Very bad surprise with last FG cvs
Not to resurrect an old thread, but even znear=0.1 has the cockpit and some visible runway gutted. I had to adjust the near-field value down as well: FlightGear-0.9/source/src/Main$ cvs diff -u cvs diff: Diffing . Index: CameraGroup.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/CameraGroup.cxx,v retrieving revision 1.14 diff -u -r1.14 CameraGroup.cxx --- CameraGroup.cxx 9 Jan 2009 23:16:44 - 1.14 +++ CameraGroup.cxx 2 Feb 2009 05:17:01 - @@ -455,7 +455,7 @@ bindMemberToNode(gnode, znear, cgroup, CameraGroup::_zNear, .1f); bindMemberToNode(gnode, zfar, cgroup, CameraGroup::_zFar, 12.0f); bindMemberToNode(gnode, near-field, cgroup, CameraGroup::_nearField, - 100.0f); + 0.1f); return cgroup; } On Fri, Jan 9, 2009 at 6:38 AM, Torsten Dreyer tors...@t3r.de wrote: Hello, What happen now with the Cockpit view Getting now the cockpit cutted That's the near clipping pane, you might want to add sim rendering camera-group znear type=double0.1/znear /camera-group /rendering /sim in your model-set.xml Torsten In addition to it , i have never seen, clouds so well displayed in reality, look like soldiers in parade :) this made laughing, guy whom i tried to demonstrate FG. :( :( Cloudstreets - glider pilots love these ;-) Torsten -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] real pilot training using FlightGear ... or not
On Sat, Jan 17, 2009 at 7:54 PM, John Denker j...@av8n.com wrote: On 01/17/2009 05:47 PM, Curtis Olson wrote: You are expecting a complete cockpit enclosure, instruments, radio hardware, instructor station software, plush seat, and FAA certification for free? The FAA doesn't certify a software application (well unless you are looking at a PCATD and even there, it's not just the software they are looking at.) For Level 3 FTD certification and above they certify a complete simulator and at least half of their certification tests involve control loading in some way or another. They go so far as to insist that if you move a simulator to a new location, you must get it recertified. I'm quite sure I wasn't expecting any of that. I agree with Curt's excellent comments in this thread. Are you assuming that an un-enclosed un-certified un-bolted-down un-expensive simulator has no value to pilots? By default, yes. The pilots on the list that use FlightGear for recurrent training are very careful to only apply it for specific purposes - and to back those activities up with a real aircraft. Certainly if you wish to make a self-fulfilling prophecy, you can create a no-value simulator. But why would you want to? On previous occasions you supported the idea of using FlightGear for pilot training, endorsing it in the strongest categorical terms. Has something changed? Nope. Curt was responding to what you said in the other message, which is not the same as what you wrote in this message. If you're sure it can't be done, please explain. That would clear up lot of confusing things I've seen on this list over the last few years. In case there's anybody who doesn't already know, here are some of the things that look doable to me: 1) Instrument procedure familiarization. Suppose you (the pilot) are flying into an unfamiliar field for the first time. It is a big help to run through the instrument approach on the simulator. -- It helps you learn the names of the fixes, the frequencies and codes of the navaids, et cetera. -- It helps you discover little surprises such as stepdown fixes that require nasty steep descents. -- It gives you a chance to practice the missed approach. My dictum is, if you're not ready for the miss, you're not ready for the approach. Procedural trainers are useful and the FAA has a minimum specification (PCATD) which determines how much fidelity is needed to ensure a net positive training value for the student. FlightGear does not currently meet that standard. For that matter, flying into JFK for the first time, you could get seriously lost on the taxiways. Real pilots are willing to practice taxiing. Gamers not so much. 2) Instrument emergency training. There are some things that instructors don't like to practice in the real aircraft, such as -- unusual attitudes in real IMC -- partial panel in real IMC Our instrument simulations are not accurate enough. -- approaches to _below_ published minimums in low IMC Our navaid simulations are not good enough. -- approaches with crosswinds, tailwinds, and/or turbulence I haven't looked recently, but at last count other pilots commented that our near-ground winds model is not usable for training. -- approaches in low visibility. A hood is OK for simulating a ceiling, but what if there is no ceiling, just bad haze? I haven't checked recently, but last time I tried looking at our airport lighting in haze ... the intensities were wrong. -- et cetera. These things are much more safely done in the simulator. Agreed; I used an FTD for this and learned a lot. Also, a subtly failed instrument is incomparably more dangerous than one that is merely covered with a suction cup. There are lots of pilots out there who have never seen this, and have no idea how bad it is. Hah. Always carry suction cups. 3) VFR emergency training. -- Practicing basic procedures -- Continuing the scenario all the way to an off-airport landing I don't think our off airport near ground scenery is useful for visual training. 4) Complex aircraft transition training. Gear handle, prop handle, cowl flaps, speed brakes, et cetera. I'd much rather have the low-time pilot abuse such things in the simulator than in the real airplane. FAA believes the skills only transfer with a realistic throttle quadrant. 5) Systems failures. -- Gear that should be down but isn't -- Flaps that should be down but aren't -- Noticing the oil pressure gauge before it's too late. -- Noticing the fuel gauge before it's too late. -- et cetera 6) Multi-engine transition training. 7) Multi-engine emergency training -- engine-out approaches -- engine-out go-arounds *) Et cetera. If you're sure that FlightGear cannot be of value in any of these ways, please explain. If the net training value (aka transfer of correct skills) is negative, the use of FlightGear is
Re: [Flightgear-devel] gyro compas drift
Laser gyros do indeed behave the way that the wiki page describes. Mechanical gyros, such as you find in light aircraft, have other drift sources that are considerably larger than the diurnal one. And, since the aircraft tend not to move far from their home latitude, there is an attempt by mechanics to adjust the gyro for zero net drift rate (on average). The purpose of implementing the drift in FlightGear is for operational realism, more than scientific accuracy, and therefore the drift value is designed to make the gyro compass be inaccurate if the light aircraft pilot does not reset it regularly. If you want to include the sin(lat) term, be sure to add a flag so we can distinguish between the laser and mechanical variants. On Wed, Jan 14, 2009 at 5:43 PM, jean pellotier jean.pellot...@wanadoo.fr wrote: hi, doing some nav with the pa24-250, i found the gyro compas drift was always -15°/hour. I never went in a real aircraft except as passenger, but if i refer to this page: http://en.wikipedia.org/wiki/Heading_indicator Shouldn't drift be related to the sin(lat), and opposite sign in the southern hemisphere? I think the relevant code is in instrumentation/heading_indicator.cxx, line 77: offset -= dt * (0.25 / 60.0); // 360deg/day but i don't know c++, so can't propose a patch. cheers jano -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On Sat, Jan 3, 2009 at 7:49 AM, Torsten Dreyer tors...@t3r.de wrote: /instruments/navradio[n]/heading-deviation-deg: [-10.0 to 10.0 for a VOR, -2.5 to 2.5 for a LOC] (i.e no 'magic 4' multiple for LOCs) /instruments/navradio[n]/heading-deviation-norm: [-1.0 .. 1.0] /instruments/navradio[n]/gs-deviation-deg: [-0.7 to 0.7] /instruments/navradio[n]/gs-deviation-norm: [-1.0 to 1.0] Does this seem reasonable to all concerned? The CDI needle can move a little further out, than the outermost dot on the scale. Here, also the receiver detects offsets of more than 10deg, just the display is limited to full deflection. Yeah, please don't clamp any of the deviation properties to the nominal instrument full scale. The instrument designer will determine how much travel exists beyond full scale (if any) and apply the appropriate value. I think a clamp is a good idea, but at maybe double full scale, which is probably slightly beyond where the electronic drivers give out anyway. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VOR shack : scenery model upgrade opportunity
Putting on my aluminium foil hat, I'll point out that there are five combinations of VOR/DME/TACAN even before you decide whether it is going to be monitored locally and whether the earth has repeatable conductivity to act as a ground plane. These decisions change what gets physically installed ... it may be worth us having multiple models available. On Fri, Jan 2, 2009 at 11:59 AM, Jon Stockill li...@stockill.net wrote: John Denker wrote: Hi Folks FG puts a model of a VOR shack into the scenery in places where there is supposed to be a VOR shack. So far so good. The problem is, the model seems awfully small. It looks like it is about 5 meters in diameter. I've never seen one in RL that is that small. I've seen them sometimes with twice that diameter and more often with three times that diameter. If you want more data on this, measure some of them using Google maps / satellite view. These things are rather important if you want realism. In the vicinity of a VOR shack, in VFR conditions, pilots really should not be looking at the CDI needle; they should be looking out the window so they don't run into the idiot who *is* only looking at the CDI needle. Having an easily-visible VOR shack model helps with this. There are other useful uses for VOR shacks. Would somebody be kind enough to make a bigger model, or at least in the interim triple the diameter of the existing model? Send me a model, I'll update the database. AFAIK though ther eare currently 2 models in the db, and one at least was modeled on a real VOR. Jon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VOR shack : scenery model upgrade opportunity
On Fri, Jan 2, 2009 at 1:10 PM, John Denker j...@av8n.com wrote: Here's a proposal: 0) If somebody has actual data, use that; otherwise: 1) Put 17m diameter shacks in enroute locations. 2) Put 12m diamater shacks in on airport locations. Anybody got a better idea? Here is a derivative idea. There are several classes of VOR (irrespective of the other radio services that might be colocated) which determine what the receivable range is ... and whether they're usable for jet routes. That change in transmitter power may be a defining factor for how big the shack is. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
No. The standard design is based around 3 degrees slope. With that design, the usable range is 1.4 degrees high, from 2.1 to 3.7 degrees and offers 0.35 degrees per dot. Therefore, a dot equals 50ft per mile range from the touchdown zone of the runway. When the standard design is scaled for terrain or other approach spaces, all that is modified is where the antenna array has the intensity maximuma. Consequently all those numbers grow by up to 8% or shrink by up to 16%. From the point of view of implementation in a simulator, just take the actual slope number for a specific runway and combine that with the aircraft's position to generate a ratio. Repair the ratio to allow for the side lobes (which as I recall are the standard series with a negative at 6 and one you can follow at 9). Then pass that ratio to the instrument implementation. The instrument should probably show full scale from 0.6 to 1.4 with center at 1.0 and dots at 0.77 0.88 1.11 1.23 On Fri, Jan 2, 2009 at 2:09 PM, syd adams adams@gmail.com wrote: Ok , Im getting closer...i think Another manual i have states min glideslope angle = 2.5 degrees , maximum = 3.25 degrees, so does that mean the needle animation range should be 0.25 at the upper second dot, and -0.5 for the bottom second dot ? That approach illustration is really confusing me now :) -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On Fri, Jan 2, 2009 at 3:12 PM, John Denker j...@av8n.com wrote: On 01/02/2009 03:28 PM, Alex Perry wrote: From the point of view of implementation in a simulator, just take the actual slope number for a specific runway and combine that with the aircraft's position to generate a ratio. Repair the ratio to allow for the side lobes (which as I recall are the standard series with a negative at 6 and one you can follow at 9). Then pass that ratio to the instrument implementation. I agree with all of that. And I have implemented it in the code, including the extra lobes i.e. false glide slopes. === Tangential remark: I am surprised by this reference: http://www.freepatentsonline.com/3757338.html which alleges For reasons well known to those skilled in the art but to minor importance here, the first significant side lobe, that is a side lobe which comprises a stable false glide slope indistinguishable from the true glide slope except for its steepness, occurs at 5A. I'm wondering if that's a typo. A 9 degree false glideslope is more-or-less followable but a 15 degree false GS would be too steep to be followable without extraordinary effort. I've seen students actually capture and try to follow a false GS. It's not easy but it can be done. So I've implemented 6-degree periodicity, i.e. 3, 6r, 9, 12r, etc. where r means reverse sensing. OTOH it might not be a typo. I haven't worked out the electrodynamics of the situation, so I can't be sure what's actually going on. Nor me. I recall seeing the analysis somewhere (but I don't remember where). It could be that 2A is a null rather than reversed, in which case 3A is the reverse, 4A would be the next null and 5A is indeed the next followable slope. 9 degrees is 1000 fpm for a C172 and is trivially achievable without special effort. 15 degrees implies intentional increase in drag. However, gear down and approach flaps _is_ an increase in drag ... so the additional drag of taking the engine to completely idle may be enough without adding more flaps. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
John Denker wrote: On 12/31/2008 10:29 AM, I wrote Standard dogma in IFR training is that the VOR CDI indicates two degrees per dot, while the LOC CDI indicates half a degree per dot. These numbers are quite believable. Good practice is to check them as part of the 30-day IFR receiver check. Important clarification: The VOR numbers are quite believable, and are checked monthly. However. The LOC numbers are only a rough rule of thumb. According to the AIM, the localizer beam is supposed to be designed to be 700 ft wide at the threshold. That's ±350 feet if you prefer to think of it that way. That means that as the runway length varies from (say) 6000 ft to 15000 ft, the CDI sensitivity varies from more than 0.6 degrees per dot to less than 0.3 degrees per dot. (I hear rumors that it is artificially pegged at a minimum of 0.3 and a maximum of 0.6, overriding the 700 ft rule, but don't quote me on that.) The 0.5 degree dogma will get you in the ballpark, but that's all. I've observed this variation in sensitivity in practical operations. We can get away with using the 0.5 degree rule, but I'd prefer us to perform the divide-and-constrain that John describes. If you want more detail than the handwave that the AIM contains, go read the FAA technical manual on how to design and deploy LOC antenna arrays ... -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync/SVN should be ready to use
On Thu, Nov 13, 2008 at 11:46 PM, Frederic Bouvier [EMAIL PROTECTED] wrote: BTW, are you aware the use of SVN implies that a second copy of each file is kept in a hidden directory, and makes the scenery directory two times bigger than a directory fetched with rsync or ftp ? Yes, svn is approximately double the local disk footprint of rsync. Both svn and rsync use a chunk size that is 1% of that used by FTP. You're still better off with SVN unless you routinely fly at least 3000 km of distance in each 10x10 tarball you download. Without going closer than 300 km to any other area already flown over. Most people will not achieve that level of utilization, especially if they're either choosing routes for scenic sights or for realistic IFR tracks. A note in the documentation is probably a good idea. Anyone who just wants a snapshot of the whole planet for offline flight would be better off retrieving all the tarballs by FTP. Nobody mentioned any plans to turn down the ftp service, and I certainly haven't been expecting either rsync or svn to replace that bulk option. PS. There may be a clever option for subversion that avoids keeping duplicate files for directories that are not currently being modified (like cvs does). But if there is, I don't yet know about it. If anyone comes across such a thing, we should change the terrasync source code. 8-) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An aircraft which sink ! Yes, with FG that is possible.
Somewhat off topic. Has anyone done the 'ground vehicle AI' for these water environments? In the Florida area, for example, they have a long scaly body and large jaws ... - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
On Tue, Nov 11, 2008 at 6:12 PM, Pep Ribal [EMAIL PROTECTED] wrote: The IVAO team could implement a FlightGear compatible interface into their network. The work would be done on their servers, but then nothing would need to change on the FlightGear side. The IVAO team would not need to expose their proprietary communication protocols, but instead would create an implementaion of our open protocols at their side to accept FlightGear connections. They could create their own proprietary interface to our protocol as long as they don't grab any of our code to do so (or maybe the I thought that if we at IVAO don't distribute the GPL software then we can use it, modify it and keep it private in our network? Wasn't it stated before by Arnt? Yes, but ... There is a legal definition associated with keep it private which many software engineers and system administrators will accidentally fail to comply with ... unless they have careful training or an existing background in commercial use of GPL free software. A clean re-implementation of the protocol will avoid the risk. Before doing that, for any specific FGFS source files that you'd like to use in the IVAO build, you can ask their authors to dual license them as LGPL or even BSD. They may agree if you successfully argue that their benefits from the interoperability outweigh their costs associated with reduced distribution restrictions. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Off topic to Melchior and Ralf's non-technical discussion, but: On Mon, Nov 3, 2008 at 8:29 AM, Ralf Gerlich [EMAIL PROTECTED] wrote: The index concept has some similarity to a B-tree (http://en.wikipedia.org/wiki/B-Tree) in terms of structure, though the balancing aspect and therefore some of the performance estimates do of course not apply. Still, the general intention and the structural aspects are in most points applicable to our index. To truly optimize for load balancing the operating system's directory searches, we should really be reading from the right end of the airport identifier ... which is more uniformly random than the left end. We can drop one level of tree completely, only increase the size of the worst case leaf directory by a factor of two from 58 to 107 files, and reduce the number of organizational directories from 9681 to 1267. The average size of each leaf directory increases from 3 to 21 files which is comparable to the tree directories that now have 36 subdirectories. This naming scheme would cause the example file to become: Airports/A/X/LOXA.ils.xml Having said that, anyone doing non-programmatic access is probably not going to enjoy that hierarchy. So, unless someone wants to assert that Airports/ is going to be under automated maintenance, I continue to think that Ralf (et al) have made a good choice. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Add optional build dependency: libsvn
This patch changes terrasync so it links against the subversion
library if you have it installed. It supports people who build binary
releases for use by non-developers by removing the runtime external
dependency on having command line svn or rsync available. Since the
patch changes autoconf to detect libsvn, I'd appreciate it if people
who release binaries could verify that the detection scripting works
for their platform.
Developer warning: If you do have libsvn developer libraries
installed, terrasync changes its default option from -R to -S to
remove the command line dependency. However, Martin has not yet
uploaded world scenery into the subversion repository so it won't be
useful to fly against and you may want to specify -R on the command
line in the short term. Or run both.
? src/ATCDCL/.deps
? src/ATCDCL/Makefile
? src/ATCDCL/Makefile.in
? utils/Modeller/photomodel
? utils/TerraSync/*.h
? utils/TerraSync/terrasyncdir
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.138
diff -u -r1.138 configure.ac
--- configure.ac 28 Aug 2008 21:19:38 - 1.138
+++ configure.ac 19 Oct 2008 07:59:14 -
@@ -597,7 +597,27 @@
echo
fi
-
+dnl Check for Subversion library support
+save_LIBS=$LIBS
+save_CPPFLAGS=$CPPFLAGS
+LIBS=
+CPPFLAGS=-I/usr/include/subversion-1 -I/usr/include/apr-1.0
+AC_CHECK_LIB(svn_client-1, svn_client_checkout3)
+AC_CHECK_HEADERS([svn_client.h])
+if test x$ac_cv_header_svn_client_h != xyes; then
+ echo TerraSync will shell out for command line subversion
+ svn_LIBS=
+ svn_CPPFLAGS=
+else
+ echo TerraSync will use integrated subversion library
+ AC_SEARCH_LIBS(svn_client_checkout, svn_client-1)
+ svn_LIBS=$LIBS
+ svn_CPPFLAGS=$CPPFLAGS
+ AC_SUBST(svn_LIBS)
+ AC_SUBST(svn_CPPFLAGS)
+fi
+LIBS=$save_LIBS
+CPPFLAGS=$save_CPPFLAGS
dnl Checks for header files.
AC_HEADER_STDC
Index: utils/TerraSync/Makefile.am
===
RCS file: /var/cvs/FlightGear-0.9/source/utils/TerraSync/Makefile.am,v
retrieving revision 1.4
diff -u -r1.4 Makefile.am
--- utils/TerraSync/Makefile.am 12 Oct 2008 09:56:18 - 1.4
+++ utils/TerraSync/Makefile.am 19 Oct 2008 07:59:15 -
@@ -4,4 +4,6 @@
terrasync_SOURCES = terrasync.cxx
-terrasync_LDADD = -lplibnet -lplibul -lsgmisc -lsgdebug $(network_LIBS)
+AM_CPPFLAGS = $(svn_CPPFLAGS)
+
+terrasync_LDADD = -lplibnet -lplibul -lsgmisc -lsgdebug $(network_LIBS) $(svn_LIBS)
Index: utils/TerraSync/terrasync.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/utils/TerraSync/terrasync.cxx,v
retrieving revision 1.14
diff -u -r1.14 terrasync.cxx
--- utils/TerraSync/terrasync.cxx 12 Oct 2008 07:55:09 - 1.14
+++ utils/TerraSync/terrasync.cxx 19 Oct 2008 07:59:16 -
@@ -43,29 +43,186 @@
#include simgear/bucket/newbucket.hxx
#include simgear/misc/sg_path.hxx
+#ifdef HAVE_SVN_CLIENT_H
+# ifdef HAVE_LIBSVN_CLIENT_1
+#include svn_auth.h
+#include svn_client.h
+#include svn_cmdline.h
+#include svn_pools.h
+# else
+#undef HAVE_SVN_CLIENT_H
+# endif
+#endif
+
using std::string;
using std::cout;
using std::endl;
+const char* source_base = NULL;
const char* svn_base =
http://terrascenery.googlecode.com/svn/trunk/data/Scenery;;
const char* rsync_base = scenery.flightgear.org::Scenery;
-const char* source_base = NULL;
const char* dest_base = terrasyncdir;
-bool use_svn = false;
-
-const char* svn_cmd = svn checkout;
const char* rsync_cmd =
rsync --verbose --archive --delete --perms --owner --group;
+#ifdef HAVE_SVN_CLIENT_H
+bool use_svn = true;
+#else
+bool use_svn = false;
+const char* svn_cmd = svn checkout;
+#endif
// display usage
static void usage( const string prog ) {
cout Usage: endl
prog -p port
- [ -R ] [ -s rsync_source ] -d dest endl
+ -R [ -s rsync_source ] -d dest endl
prog -p port
--S [ -s svn_source ] -d dest endl;
+ -S [ -s svn_source ] -d dest endl;
+#ifdef HAVE_SVN_CLIENT_H
+cout (defaults to the built in subversion) endl;
+#else
+cout (defaults to rsync, using external commands) endl;
+#endif
+}
+
+#ifdef HAVE_SVN_CLIENT_H
+
+// Things we need for doing subversion checkout - often
+apr_pool_t *mysvn_pool = NULL;
+svn_client_ctx_t *mysvn_ctx = NULL;
+svn_opt_revision_t *mysvn_rev = NULL;
+
+static const svn_version_checklist_t mysvn_checklist[] = {
+{ svn_subr, svn_subr_version },
+{ svn_client, svn_client_version },
+{ svn_wc, svn_wc_version },
+{ svn_ra, svn_ra_version },
+{ svn_delta, svn_delta_version },
+{ svn_diff, svn_diff_version },
+{ NULL, NULL }
+};
+
+// Configure our subversion session
+int mysvn_setup(void) {
+// Are we already prepared?
+if (mysvn_pool) return EXIT_SUCCESS;
+// No, so initialize svn
[Flightgear-devel] terrasync improved version - patch
Please commit this patch to terrasync into CVS. I've included both
the file itself and the patch. Changelog:
* Doesn't download the area at lot,lon of 0,0 if terrasync starts
before FlightGear is ready
* Attempt to download the Airports directory when no scenery needs to be fetched
* Add svn over http support for flag -S, in addition to the existing
default of rsync
* Add the command line flag -T to just refresh the KSFO surrounding
area and exit
Index: utils/TerraSync/Makefile.am
===
RCS file: /var/cvs/FlightGear-0.9/source/utils/TerraSync/Makefile.am,v
retrieving revision 1.3
diff -u -r1.3 Makefile.am
--- utils/TerraSync/Makefile.am 9 Jul 2003 19:57:22 - 1.3
+++ utils/TerraSync/Makefile.am 12 Oct 2008 01:29:12 -
@@ -4,4 +4,4 @@
terrasync_SOURCES = terrasync.cxx
-terrasync_LDADD = -lplibnet -lplibul $(network_LIBS)
+terrasync_LDADD = -lplibnet -lplibul $(network_LIBS) -lsgmisc -lsgdebug
Index: utils/TerraSync/terrasync.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/utils/TerraSync/terrasync.cxx,v
retrieving revision 1.13
diff -u -r1.13 terrasync.cxx
--- utils/TerraSync/terrasync.cxx 29 Jul 2008 08:27:49 - 1.13
+++ utils/TerraSync/terrasync.cxx 12 Oct 2008 01:29:12 -
@@ -3,6 +3,7 @@
// Written by Curtis Olson, started November 2002.
//
// Copyright (C) 2002 Curtis L. Olson - http://www.flightgear.org/~curt
+// Copyright (C) 2008 Alexander R. Perry [EMAIL PROTECTED]
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
@@ -40,24 +41,36 @@
#include plib/ul.h
#include simgear/bucket/newbucket.hxx
+#include simgear/misc/sg_path.hxx
using std::string;
using std::cout;
using std::endl;
-static string server = scenery.flightgear.org;
-static string source_module = Scenery;
-static string source_base = server + (string):: + source_module;
-static string dest_base = /dest/scenery/dir;
+const char* svn_base =
+ http://terrascenery.googlecode.com/svn/trunk/data/Scenery;;
+const char* rsync_base = scenery.flightgear.org::Scenery;
+const char* source_base = NULL;
+const char* dest_base = terrasyncdir;
+bool use_svn = false;
+
+const char* svn_cmd = svn checkout;
+const char* rsync_cmd =
+rsync --verbose --archive --delete --perms --owner --group;
// display usage
static void usage( const string prog ) {
-cout Usage: prog
- -p port [ -s rsync_source ] -d rsync_dest endl;
+cout Usage: endl
+ prog -p port
+ [ -R ] [ -s rsync_source ] -d dest endl
+ prog -p port
+-S [ -s svn_source ] -d dest endl;
}
+const int nowhere = -;
+
// parse message
static void parse_message( const string msg, int *lat, int *lon ) {
double dlat, dlon;
@@ -105,6 +118,44 @@
} else {
*lon = (int)dlon;
}
+
+if ((dlon == 0) (dlat == 0)) {
+ *lon = nowhere;
+ *lat = nowhere;
+}
+
+}
+
+// sync one directory tree
+void sync_tree(char* dir) {
+int rc;
+char command[512];
+SGPath path( dest_base );
+
+path.append( dir );
+rc = path.create_dir( 0755 );
+if (rc) {
+cout Return code = rc endl;
+exit(1);
+}
+
+if (use_svn) {
+snprintf( command, 512,
+%s %s/%s %s/%s, svn_cmd,
+source_base, dir,
+ dest_base, dir );
+} else {
+ snprintf( command, 512,
+ %s %s/%s/ %s/%s/, rsync_cmd,
+ source_base, dir,
+ dest_base, dir );
+}
+cout command endl;
+rc = system( command );
+if (rc) {
+cout Return code = rc endl;
+if (rc == 5120) exit(1);
+}
}
@@ -134,47 +185,21 @@
}
EW = 'w';
} else {
-baselon = (int)(lon / 10) * 10;
-EW = 'e';
-}
-
-char command[512];
-char container_dir[512];
+baselon = (int)(lon / 10) * 10;
+EW = 'e';
+}
+
+const char* terrainobjects[3] = { Terrain, Objects, 0 };
+const char** tree;
char dir[512];
-
-// Sync Terrain
-snprintf( container_dir, 512, %s/Terrain/%c%03d%c%02d,
- dest_base.c_str(), EW, abs(baselon), NS, abs(baselat) );
-snprintf( command, 512, mkdir -p %s, container_dir );
-cout command endl;
-system( command );
-
-snprintf( dir, 512, Terrain/%c%03d%c%02d/%c%03d%c%02d,
- EW, abs(baselon), NS, abs(baselat),
- EW, abs(lon), NS, abs(lat) );
-
-snprintf( command, 512,
- rsync --verbose --archive --delete --perms --owner --group %s/%s/ %s/%s,
- source_base.c_str(), dir, dest_base.c_str(), dir );
-cout command endl;
-system( command );
-
-// Sync Objects
-snprintf( container_dir, 512, %s/Objects/%c%03d%c%02d,
- dest_base.c_str(), EW, abs(baselon), NS, abs(baselat) );
-snprintf(
Re: [Flightgear-devel] scenery textures
Generally a bad idea for textures used in flight simulation. The image data are viewed obliquely so the visual acuity assumptions that are inherent in lossy compression are wrong. Having said that, if you force the png library to generate lossless files, you'll be fine but I don't know how much savings you get. On Sun, Oct 5, 2008 at 12:22 PM, Syd [EMAIL PROTECTED] wrote: Hello all, I would like to convert all the scenery textures to png's , if I get the go ahead here. I've tested this before , and the png's here are anywhere from half to one third the size of the rgb's. I'm currently attempting to add tire marks to the runway textures , but there are so many segments it's hard to keep things lined up .Anyway , if everyone agrees with this , I can probably get it done today . Cheers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading Textures for Photo-Scenery?
How does it work? Where is the source code for the serving side of the OAM stuff? On Wed, Oct 1, 2008 at 4:26 PM, Martin Spott [EMAIL PROTECTED] wrote: OAM runs on the sister-machine to our Landcover and Scenery Model webservice - same hardware, same location, same storage systems, same network uplink. As far as I can tell, the current OAM webservice, even though it runs on really 'nice' hardware, is to be considered as being a 'prototype'. Therefore it should not be expected to stand the workload of a 'production' system, especially not for a large user base, - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Materials wrong for San Diego bay?
I haven't investigated why and I thought I'd ask whether anybody knows the answer offhand before following up with the underlying data. The entrance to San Diego bay (between North Island airport KNZY and Lindbergh field KSAN) isn't water; it has trees all over it. Is this just a consequence of old land use data, or an incorrect mapping through materials? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Does CVS terrasync work reliably?
The CVS version of terrasync seems to be relying on rsync to notice that the source directory contains more than one file. That's what triggers it to create the destination directory. Seems to me this will fail if there is only one file in the source directory, since it will instead rename that file to the name of the directory. Am I missing something? I've changed my command lines slightly to compensate. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New nasal drop, new syntax
On Fri, Sep 26, 2008 at 11:25 AM, Andy Ross [EMAIL PROTECTED] wrote: Note that a reasonably big Nasal change just went into SimGear. As always, let me know what broke. Negative 8-). When I recompiled SG and FG after pulling the update in, FGFS started working. Either there was something else that got fixed by this extra recompile iteration, or there is some architecture specific bug you happened to provide a fix for. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Good company on the list;
On Thu, Sep 25, 2008 at 3:52 AM, Martin Spott [EMAIL PROTECTED] wrote: FGFS stopped building on my develop machine and I've not resolved the issue yet. May I expect you to increase your participation here if we're going to solve your trouble ? ;-) Heh. Yeah, that's why I poke at it occasionally. Currently, the build finishes and an attempt to run segfaults immediately. I haven't investigated further yet. Using fgfs, simgear, osg, plib from cvs/svn and the rest from debian lenny on amd64. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Good company on the list; Was: FlightGear on 32 bits versus 64 bits system
From: gerard robin [EMAIL PROTECTED] I agree, don't do that +1 PS. In case anyone wonders why I've only been lurking for a year or so: FGFS stopped building on my develop machine and I've not resolved the issue yet. It seemed like a bad idea to say too much on the list when I'm unable to run FGFS! - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGFS is at SigGraph
The ATI booth at SigGraph in Los Angeles this week is demonstrating a single Linux machine with two dual-head graphics cards running four monitors. They are running FlightGear on four monitors (center, left, right, above) with the F15 flying between KSFO and the golden gate bridge. Although the engineers who set it up for the show forgot to mention it on our mailing list, the chap at the demo station was happily telling everyone about how nice the simulator is and telling people about the website. If you're at the show, swing by and say Hi to him ... - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] LinuxWorld application deadline today Friday April 11
If anyone wants to apply for the San Francisco 2008 .org pavilion, now would be a really good time to do so (if they haven't already). - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] reality issues in MP
From: Ron Jensen [EMAIL PROTECTED] My flightgear time is generally limited to after work during the week, so forcing--timeofday=real means I'd always have to fly at night in the KSFO area, or anywhere else in the US for that matter. So why not go fly on a different continent ... ? I was going to agree with real-world weather, but what if conditions in the area I want to fly in are IFR and I want/need to fly VFR? Do I cancel my flightgear time and play sudoko instead? or just forgo the pleasure of watching others fly as I fly, too? I suppose the correct thing is to have each MP server specify some mandatory (and prohibited) commandline options as part of the protocol. I can't find a valid reason to allow speedup however realworld sometimes intrudes into my flightgear session and I am forced to pause briefly to attend to an issue. Are you suggestion disappearing pilots would be better than paused pilots? I'd prefer to have the pause keystroke to usually get redefined during MP. It runs a script that basically reprograms the autopilot to fly a one minute hold pattern at the current altitude and inbound on the current heading to the location where the key was pressed. That lets you recover the flight and continue at any time thereafter, subject to multiples of four minutes and onboard fuel. This is what you might do in real life, if forced to leave the cockpit. And you're also subject to suitable sarcasm from other pilots if you hit that key after the FAF instead of simply telling the autopilot to miss. 8-) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Zero lag altimeter
From: John Denker [EMAIL PROTECTED] I'm under the impresssion that the property called environment/pressure-inhg[0] has a lag computed into the final value. Is that correct or is that the instantaneous value or pressure level the aircraft is at and what I'm looking for? Close. The trick is that altimeters and suchlike are not (and should not be) connected directly to environment/pressure. They are connected to /systems/static/pressure-inhg ... and *that* has an unrealistically huge lag built into it. I would argue that there should be some lag, just not nearly so much. [...] Decreasing the static-system lag from 1 (the previous compiled-in value) to .1 or even .2 makes things look instantaneous or nearly so. There are three types of altimeter in common use: (1) Air data computers, which go to a lot of trouble to report the instantaneous value. Aircraft with such instruments should use the environment value, (2) Basic barometric altimeters, which should have a long lag (second or so, in my experience). Small aircraft manufactured before the 1970s tend to have these, I believe, and this behavior is modelled by the systems value, (3) Corrected barometric altimeters, which have a relatively short lag that is just about observable by eye (therefore presumably around a tenth of a second) when operated in an IFR-like way. Small aircraft of recent manufacture tend to have these, unless the aircraft is aerobatic. As far as I know, we don't have a model for this in FlightGear. Correcting altimeters contain a small accelerometer that detects the vertical component and, using a small bellows, injects a high pass filtered contribution into the static pressure value. The idea is that an increase in vertical acceleration (i.e. more than gravity) implies the aircraft is going up and so the bellows temporarily sucks some air out of the static pressure and causes the instrument to indicate a climb sooner than it would otherwise. Equivalently for descent. This works great for operations in IFR, so normal category light aircraft with an IFR panel tend to have these installed (unless it is an old aircraft with original equipment). To the pilot in IMC, the improvement is comparable to flying with a gyro compass instead of with a wet compass. Of course, the bellows trick of (3) goes wrong for (a) increased G maneuvering and (b) unusual attitudes: (a) If I make a 60 degree banked turn, so the aircraft pulls 2 gravities, the bellows will (for a second or so) cause the altimeter to indicate a higher value than is actually correct. However, providing I roll smoothly into the turn, so the acceleration force picks up gradually, the altimeter information continues to be useful and is not particularly odd. (b) If I'm upside down, changes in apparent G force should have the reverse effect on the altimeter. Some instruments limit out for zero or negative G, so the correction is disabled in unusual attitudes. I suppose it's feasible that there are some which use the absolute value of the apparent G force so they work relatively well when upside down ... but I haven't come across that. Hope that helps ... - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Zero lag altimeter
From: John Denker I don't know of any environment variable relevant to altitude other than /environment/pressure-inhg. Using that bypasses the lag associated with the /systems/static/pressure-inhg which seems like a small and unimportant part of the overall air-data task. It also bypasses the /systems/static/serviceable check, which seems like a bad idea. True. But the servicability of air data goes as the whole system - you'd probably be better having a servicability flag for the whole thing. I don't think you can have just the altimeter portion of an air data installation fail, unless you're asserting that the display piece broke. There is no reason to have a long lag in the static system. Interesting point, yes, you're right. On the modern instruments, anyway. Maybe the old lag was actually due to manufacturing tolerances and the like. Let's just get rid of the long static-system lag. Maybe the long lag should be a non-default option, used in old aircraft. Really? I know that's how an IVSI works, but I've never seen an altimeter that did that, or needed to do that. Yeah, although I recall the transition to precision altimeters having some funny gizmo to get rid of the old lags, I don't recall the details ... and am just assuming they used the same technique as a IVSI. Sorry, can't help there. Compared to an altimeter, a VSI has a much harder problem. Yeah. But that VSI lag has a different origin due to the instrument being inherently a single pole high pass filter. --- [This E-mail scanned for viruses by Declude Virus] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
From: John Denker [EMAIL PROTECTED] Please do not write to me saying that SLP must equal QNH when you are flying at sea level. That's true in that narrow special case, but not representative of the general case. Supporting John's point: In real world operations, even when flying at sea level, QNH is often not equal to SLP. In areas with a dense array of airports, the QNH values are intentionally correlated to increase vertical separation in the airspace between aircraft that have taken off from different airports. As a result, even an accurately calibrated altimeter may not indicate field elevation when sitting on the runway. More generally: It is always very important to distinguish between the facts that arise from the simulation of the planet (such as SLP and variation), and the facts that arise from simulation of the airspace (such as QNH and VOR alignment). There tends to be fairly good correlation between the two, because that makes engineering sense, but the differences are routinely enough to kill people. --- [This E-mail scanned for viruses by Declude Virus] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Forums integration thought
I know our development culture is built around mailing lists. I'm sure the FlightGear community will be decisively split between forums versus mailing lists if I ask people's preferences ... so I'm not expecting a consensus here. Is this anything that is worth exploring? I'd also hate to look in two places. On the other hand, changing how we present the mailing list archives so they look like a forum _and_ allow replying if you have logged in ... would be really useful. Logging in implies an account whose email address has been verified in the same way that mailman does. So it can't be used for spamming unless you could easily have spammed with the mailman list system. --- [This E-mail scanned for viruses by Declude Virus] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightAware flight tracking
From: Martin Spott [EMAIL PROTECTED] Josh Babcock wrote: Sounds like a good reason to fly VFR. I wonder if they have considered the safety implications of this. I know in the US you can request that ATC watch you while you are flying VFR, but I don't know if you need to give your tail number when you do. I would guess that you do. We call this Flight Information Service, FIS - [...] In the US, you request VFR Flight Following from the ATC sector. If approved, you receive Traffic Advisory service (no separation). --- [This E-mail scanned for viruses by Declude Virus] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] event: Flightgear talk in Santa Monica, CA, USA
The Coastal Los Angeles IEEE Section Computer Society Chapter presents ... Introduction to the FlightGear Flight Simulator September 12, 2006 at 7:30pm Alex Perry, Google, 604 Arizona, Santa Monica, CA 90401 FlightGear is a GPL open source flight simulator that runs on a wide range of platforms including Linux, MacOS and Windows. The simulation itself, the worldwide scenery and the aircraft models are free to download from www.flightgear.org and its mirrors. This talk will provide an introduction into the project, its goals, getting started, and a demonstration of the system in action. IEEE membership is not required to attend this talk; we're always looking to grow our membership: http://www.ieee.org/membership/join/ Computer Society: http://www.computer.org/ Section Home Page: http://ewh.ieee.org/r6/coastal_la/ FlightGear project: http://www.flightgear.org/ Directions / Map: http://tinyurl.com/gba8u --- [This E-mail scanned for viruses by Declude Virus] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OT [OT] First flight lesson
From: GWMobile [EMAIL PROTECTED] A steep sideslip approach with full flaps is the most fun you can safely have in a cessna! Take a look at what the US commercial pilot emergency descent maneuver is. 8-) ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] SoC
http://code.google.com/soc/ Is anybody here an eligible student? Would anyone like to offer to mentor? --- [This E-mail scanned for viruses by Declude Virus] --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
