Re: [Flightgear-devel] Replay system
On Mar 31, 2011, at 11:01 AM, Robert wrote: Hi everyone, I'd like to share some thoughts with you on how we can improve the replay system. Right now only the last minute is recorded at full precision. After that minute we get a precision of 1 fps. And after 10 minutes we get a precision of 1 frame per 10 seconds (please correct me. this number may be wrong). Due to linear interpolation the motion of the plane become jagged (hope you understand what I mean here). Also due to the loss of precision fast rotations of the plane look just incorrect in the replays (reversed direction of the rotation). FIRST SOLUTION: Streaming the replay data to the hard disc drive always at full precision. This is probably the best solution as: We don't need much RAM to save a whole flight (we just need a stream buffer). We get full precision. We solve the reversed rotaton problem. We still should use linear interpolation here as it is faster than monotone hermite spline: SECOND SOLUTION: To solve the jagged motion problem I thought of implementing another interpolator. The monotone Hermite spline interpolator. It has the benefits that it does not oscillate in comparison to the Catmull Rom interpolator. The downside to this solution is that the problem of incorrect (reversed) rotation cannot be solved. Also we will need to feed the hermite spline interpolator with 4 replay frames instead of 2 used in the linear interpolator. p.s. I also thought that it woud be nice if the nearest tower would be automatically computed in replays (as it is done in x-plane), so you don't have to enter the airport code every time. What do you think? Just as additional info, this was how the precision was explained to me last year : http://sourceforge.net/mailarchive/message.php?msg_id=24790011 -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Special Request
On Mar 30, 2011, at 6:06 PM, J. Holden wrote: Hey everyone, There is a lot of custom scenery I've contributed just sitting on the mapserver. Due to some problems it seems as contributions in the scenery department have fallen off recently, despite some great recent work with adding buildings to New York City, and a new contributor adding important skyscrapers from across the world. I've just determined again I can't compile these areas myself. Can someone with TerraGear please download and compile at least one of these scenery areas? The Pacific Northwest (Portland/Seattle) is most interesting to me, there are 8 square degrees(!) of good quality land cover data including some intriguing mountainous terrain. However, Rio de Janeiro, Hong Kong, Toronto, and Connecticut/Rhode Island/Vermont would also be greatly appreciated. There are a couple other areas as well I can't remember, I think Phoenix. Let me know if you have the ability to compile these scenery areas. I would greatly appreciate this and happily host a download link. Yours John There would be a few hundred votes for this to happen if anyone were to ask. I'd like to see the revised airports too, but I'd appreciate the scenery! Peter -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 panel
On Mar 24, 2011, at 12:11 PM, Curtis Olson wrote: Funny (?) story. A friend of mine was part of a flying club a few years ago. The club decided they wanted to expand their fleet and so they found a relatively inexpensive piper super cruiser. The guy selling it was an old farmer from a remote rural area. After they bought it, they came to discover that the guy never bothered to get his pilots license because he just flew it around his farm (!!!) Also, he never bothered to get his AP either, but he did all the maintenance himself. He never worried too much about the FAA and figured he was so remote he wasn't bothering anyone else with his hobby. So by the time they got done pulling all the John Deer (tractor) parts off the airplane the cost at least doubled for them to get it fully certified and air worthy again in the eyes of the FAA. :-) Curt. He obviously understood flying better than most. Peter :) -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where is a rotating beacon defined?
On Mar 15, 2011, at 11:19 AM, Harry Campigli wrote: At WRR Bali, there is a steel tower with a rotating lamp beacon light in the middle of one of the taxi ways, It should be a bit to the west. So i thought I would move it, but nothing seems to work. and I find nothing defined at the position of the tower if I park the plane on it. How is it defined and where? If I look in Navaids/apt.dat I find 14 -08.744474 115.166221 131 0 ATC Tower 15 -08.745233 115.168918 358.00 park Large 15 -08.745573 115.174384 358.00 park Small 15 -08.745843 115.166773 358.00 terminal Narrowbody 15 -08.745430 115.163368 358.00 terminal Widebody 18 -08.744965 115.176491 1 BCN 19 -08.748054 115.154752 1 WS 19 -08.746995 115.180026 1 WS I expected an edit of this line was required 18 -08.744965 115.176491 1 BCN But neither this line or ATC Tower line effects it. Same with the WRR position in the World Scenery? Theres no evidence of these passenger terminals on screen either but thats another issue. -- Regards Harry Probably in the Scenery/Objects folder. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] list of aircraft that don't load in fgdata
On Jan 27, 2011, at 3:21 AM, Erik Hofman wrote: The Bronco has been updated last week and should work properly (I tested it), granted .. not in fgrun. The Fokker50-Denim file seems to be outdated and superseded by the livery selection system. Will update that soon. Erik Erik, I updated the Bronco slightly if you want to take a look. Either file: http://www.mediafire.com/file/1nmskhm0wfk1x21/OV10%2020110303.tgz http://www.mediafire.com/file/5xmhdnin6lk21fg/OV10%2020110303.zip Changes: GPS works in the black pony. All models have canopy doors open and shut via c. All models have a pitot tube instead of that knife looking segment face. Better panel hotspot mapping on the black pony. Was not able to consolidate much yet. That will happen at some point. Peter-- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] list of aircraft that don't load in fgdata
On Mar 3, 2011, at 12:10 PM, Peter Brown wrote: Erik, I updated the Bronco slightly if you want to take a look. Changes: GPS works in the black pony. All models have canopy doors open and shut via c. All models have a pitot tube instead of that knife looking segment face. Better panel hotspot mapping on the black pony. Was not able to consolidate much yet. That will happen at some point. Pete Erik, I fumbled and exceeded the text space in help in the Black Pony set file. There are new folders complete : http://www.mediafire.com/file/zo967hk164bjkzq/OV10%2020110303.zip or http://www.mediafire.com/file/5u4p9833h4xjl9j/OV10%2020110303.tgz Or replace existing text at Line 615 to 619 in OV10_BlkPony-set.xml with only this : text The North American/Rockwell OV-10 Bronco was designed for the forward air control, light attack, observation and utility roles. This model represents an OV-10A of the U.S. Air Force's 601st Tactical Control Wing, based at Sembach Airbase, Germany from about 1976 to 1984. Similarly equipped versions were also based in Korea at that time. Some unusual features of the OV-10 are that the cockpit is entered from the right side, and that each wing has 4 small spoilers for roll assist. When flying the OV-10 be careful of using idle power. If the power levers are brought all the way to the idle stop the propellers will go into flat pitch, and they act as speed brakes as well as spoilers for one-third of the wing. Land with the levers just above idle. /text I apologize to anyone who already downloaded it. Peter-- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Feb 27, 2011, at 10:08 AM, Oliver Fels wrote: Vivian Meazza wrote: Exactly the answer to be expected. Note the association concept. Shouldn't have asked. In the same sense as FlightProSim did not ask to use the IP of others and violate their license? Oliver No, not in your twisted logic. FG is not creating income based upon others work. FG is representing the environment and aircraft created in a realistic manner. A proper analogy would be for FPS to sell the associated livery for a profit. Which if you hadn't brought this up would have been the case. …not a bad idea. Peter -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Feb 27, 2011, at 11:13 AM, Oliver Fels wrote: Am Sonntag, 27. Februar 2011, um 16:23:47 schrieb Peter Brown: On Feb 27, 2011, at 10:08 AM, Oliver Fels wrote: No, not in your twisted logic. FG is not creating income based upon others work. FG is representing the environment and aircraft created in a realistic manner. A proper analogy would be for FPS to sell the associated livery for a profit. Which if you hadn't brought this up would have been the case. …not a bad idea. FlightGear is distributing trademarked items by providing all means of infrastructure to do so - multiplayer servers, download facilities (web server, GIT server, scenery database, etc.) and spreads them into the world. From a legal standpoint there is no denying that at least the owners of the aforementioned distribution channels are violating trademarking rights. With the full knowledge of the infringement now. The trademark owner has the full right to define who does what with his items and trying to hide the violation from him is in no way better as if FlightProSim is trying to hide that they are violating the aircraft owners rights. It is not a question of commercial or not but a question whether people stick to the values and borders defined by legislation. And of personal moral. Oliver By this definition FG would cease to exist. Legislation does not define values, and commercial trademarks are just that, commercial. The purpose of enforcing them is to protect their _commercial_ business. It has nothing to do with personal moral, unless you direct it in that manner. Peter -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Feb 26, 2011, at 5:44 PM, Gene Buckle wrote: On Sat, 26 Feb 2011, Gary Neely wrote: There's a saying in English about bearding the lion in his den. It's probably better to stay beneath the lion's radar. Especially considering the rather top-heavy population of fuzzy bunnies we have around here. :D g. -- ROFLMAO -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Modeling and integrating the Cessna UC 78 Bobcat
On Feb 25, 2011, at 10:27 AM, David Van Mosselbeen wrote: I forward this as it seems the flightgear-flightmodel isn't much active, and dunno if there's still some life in there. Original Message Subject: Modeling and integrating the Cessna UC 78 Bobcat Date: Fri, 25 Feb 2011 16:14:59 +0100 From: David Van Mosselbeen dvanmosselbeen@sun.pinguin.local To: flightgear-flightmo...@lists.sourceforge.net Hi all! I have modeled the Cessna UC 78 Bobcat with Blender (2.56) some time ago. It's still a wip, very low poly and not textured yet and it should be improved. You can find some screenshots here [1] [2] [3]. For the interest of learning blender and in the hope to find a practical path in my learn curve, i would like to integrate this in FGFS. Didn't found this aircraft in the repo and somehow, i hope nobody is modeling and integrating this one ;) Or if so please give a sign asap and will try some other one. [1] http://dvm.zapto.org:8080/~dvanmosselbeen/gallery/galleries/My_Blender_3d_stuff/cessna-uc-78-bobcat_0001.jpg [2] http://dvm.zapto.org:8080/~dvanmosselbeen/gallery/galleries/My_Blender_3d_stuff/cessna-uc-78-bobcat_0002.jpg [3] http://dvm.zapto.org:8080/~dvanmosselbeen/gallery/galleries/My_Blender_3d_stuff/cessna-uc-78-bobcat_0003.jpg Thanks, Kind regards, David Van Mosselbeen David, the Bobcat's a neat old plane. Did you complete just the model or build a complete model with fdm, so it's a flying model? Peter -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default Aircraft Candiates
On Feb 20, 2011, at 11:16 AM, Harry Campigli wrote: Two things cross my mind, whilst I know the designers strive to model the true aerodynamics in the fdm. 1- how many fly these sims on realistic hardware? Would many even go as far as a set of imitation yoke and pedals? 2- I have spent some time in F28s set up for airport navaid calibration surveys in the past, No pax and no bags or cargo, not a lot of fuel onboard, and I have to tell you that aeroplane could really go!, those pilots could and would throw that thing all over the sky. There was never any hint of that performance riding in an F28 on normal passenger service. I suspect most people would run FG airliners without full weight and slack tanks which vastly alters the power to weight ratio of the aircraft. Harry This is very true. I've not explored the parameters of the 777 in FG, but if you fly the MD-81 with no passengers, 1200 lbs of fuel and crew weight, it is extremely different than flying with standard fuel load and passengers. Enough so that you can land, and take off, from the Nimitz. This is not as far-fetched as one may think. A good friend of mine is a 757 and 767 driver. Most takeoffs are all reduced power takeoffs, per airline spec's. He did a deadhead trip (empty) the other day, and just because he could as the captain, he choose to do a max power takeoff. He said you're doing 80 kts before you take a breath, and he was pulling the nose up through 30 degrees before deciding to pull the power back, as it just kept accelerating. The aircraft are built to the airline specifications, but within FAA parameters. The FAA specifies that at maximum gross weight the aircraft must be able to climb out over a 50 ft obstacle one engine (after V1). This means if you lose all other power and you've passed V1 (decision speed), you must be able to get over that tree that FG scenery planted just beyond the threshold. So now add back in the rest of the engines, dump the fuel and kick all the passengers off. Like Harry said, a passenger will never see any hint of the true performance. Airlines all have route planners, and provide a full flight chart to the pilots for each flight. This provides them with the best case for time and fuel burn. Accelerate at x power. Climb out rate, speed, and duration. Fuel burns to climb, cruise and descend. Descent rate, speed, power setting. This is all calculated on all factors - passenger load, fuel load, temperature, altitude, wind, etc. This is how the modern pilot tells you how many minutes to landing. It's not about 30 minutes, it's 27 minutes to touchdown. This is all planned out by the flight department before departure. Peter On Sun, Feb 20, 2011 at 8:16 PM, George Patterson george.patter...@gmail.com wrote: On Sun, Feb 20, 2011 at 10:49 PM, syd adams adams@gmail.com wrote: Like we couldn't see this coming ;) As for the 777 , unrealistic according to who ? I'm not against changing it as one of the default aircraft , there are a lot of other great choices now , but I do get annoyed with these claims by armchair pilots who read it somewhere or saw it on youtube have you piloted one of these in real life ? If so , what could be improved ? When I get FACTS from REAL pilots , I tend to be all ears , there are too many self proclaimed experts to take everything I hear as fact. I've done a huge amount of research on that aircraft , but have never flown one , so I can't say with certainty how accurate the FDM is myself , but still I'd rather hear how it could fixed rather than a hazy '(the FDM is terribly unrealistic) While I am not a real world pilot, I also get annoyed at the subjective Blah is broken where blah is a feature on a particular aircraft. Better is an objective cruise speed of the aircraft at x,000 feet is 500 knots when it should be 520 knots. Note: I have plucked those figures out of the air for the discussion. However, the first statement is open to arguement and the next question of what and how is blah broken. The second example can be responded to as yes you are right the FDM is a little out or No, it's correct as cruise alttiude of air craft should be no higher than y,000 feet. As I deal with vauge user reports with as little information to go on as The Internet is broken, I am all for as much information as can be provided. Which application... the list goes on. Jack, I know you meant well but stating that an aircraft could be replaced with another isn't particularly helpful without naming a successor. It help as other can then agree with your or say that something else is more worthy. I think this discussion comes up every time a new release gets close. Regards George -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
Re: [Flightgear-devel] ..IP and litigation risks, was: AH-1 Merge Request
This is getting ludicrous. I guess there won't be complaints about The Forum anymore. Move on, before you kill FG by removing all content that encourages someone to use it. There are other discussions more worthy of your expertise. Beating this one over and over again will only drive each of you further away from the reason you're here. Curt said it, Gene said it, others stated it. FG uses logos, it's part of the environment. It's part of the texture world. Curt's not worried about any issues arising from it, take some comfort there and leave it be. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] list of aircraft that don't load in fgdata
On Jan 27, 2011, at 3:21 AM, Erik Hofman wrote: On Tue, 2011-01-25 at 19:06 -0700, dave perry wrote: I have tried to load several AC that did not load with filed to load file name errors. So I did a survey of the entire up-to-date fgdata. I used an up-to-date fgrun and went through all the AC. The following do not load even to the viewer in fgrun: 737-100, 737-300, AG-14, Airwave Xtreme 150, CRJ-200, DC-8-63, Fairchild Metroliner, Fooker50-Denim, Jaguar, Late-29, marchetti, MIG-29 Fulcrum, Mirage F1, North American OV-10A USAFE Bronco, Short Empire, x24b, and Zepphelin NT07 multiplayer copilot. The Bronco has been updated last week and should work properly (I tested it), granted .. not in fgrun. The Fokker50-Denim file seems to be outdated and superseded by the livery selection system. Will update that soon. Erik Erik, Thanks for repairing that link in the model file in the OV10_USAFE. While it runs as many use it, the folder needs to be cleaned up. Mr. Perry was correct in an Effects file was removed/missing/etc, and obviously a path was still lingering. If I get a chance I'll try to sort through it all and lighten it up. 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
[Flightgear-devel] Carrier Altitude
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
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 1:13 PM, Curtis Olson 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. Curt, Does it not seem a bit odd to have a divot like this? I expected if flat then the polys would only go down until the mid-span of the ocean surface and then it would rise back up to meet the terrain again. Either way, can I suggest we lower the carriers to a closer approximation of altitude, at least at their default AI locations? Thanks, Peter 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
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 2:20 PM, John Denker wrote: On 01/25/2011 12:14 PM, Curtis Olson wrote: How about having carriers do a terrain height check and follow the polygon curvature of the FlightGear world? Call it a feature. The real ocean has swells. They make carrier flight operations considerably more interesting. Sounds great. How does it get implemented? 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
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 2:14 PM, Curtis Olson wrote: On Tue, Jan 25, 2011 at 1:00 PM, Peter Brown smoothwater...@adelphia.net wrote: I expected if flat then the polys would only go down until the mid-span of the ocean surface and then it would rise back up to meet the terrain again. Isn't that what is happening? I don't believe so, as it's no where near mid-span. If the distance was shorter I'll call it a super-long negative swell(swale?), but the distance between the points shown in the images is longer than that. I'll do some more research in different locations. That said, I was looking for information about it so that the carrier could be at actual sea level, or ocean surface rather than hovering above it. If the height-adjust is possible, that'd be a great solution if it kept in sync across MP. 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
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 2:55 PM, Vivian Meazza wrote: Is there a problem with maintaining vertical sync with MPCarrier? If there is please file a report here: http://code.google.com/p/flightgear-bugs/issues/list Vivian No Vivian, Curt suggested that carriers do a terrain height check and follow the polygon curvature of the FlightGear world. Not knowing if there was something in place to maintain sync with vertical change, I commented that that would be a great idea if possible. 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
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 1:13 PM, Curtis Olson 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. I don't know how big the tiles are, but I ran a ground vehicle due west from the Golden Gate Bridge to see what the variation was. It may just be that the first tile is out of whack? From terrain edge out to 21 miles it goes down and back up. From 21.2 miles out to 100 miles it's totally flat. Ocean surface as compared to 0 MSL : Golden Gate Bridge : 0 Terrain edge/Ocean start/End of channel : 0 Nimitz : -7m MSL 17 Miles out : -7m MSL 21.1 miles out : -3.7 MSL - At vertical wall, assuming Tile edge 21.2 miles out : 0 MSL - Up on new tile(?) 70 miles out : 0 MSL 100 miles out : 0 MSL Screenshots of locations with lat/lon: http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Sea%20Level%20West%20from%20SFO/ 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
Re: [Flightgear-devel] Add screenshot dialog, to select directory
On Jan 17, 2011, at 11:44 AM, Gijs de Rooy wrote: Hi Melchior, I was about to send an email to the mailing list asking for feedback, so thanks for saving my three minutes :) Cheers and once again sorry! Gijs Gijs, You probably know better than I, but do most folks use or need a FlightGear specified screen capture utility? Perhaps I look at it another way, but even if it has one I think I'd still use my computer's screen capture utility. Just an opinion - :) Peter-- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Add screenshot dialog, to select directory
On Jan 17, 2011, at 1:35 PM, Csaba Halász wrote: On Mon, Jan 17, 2011 at 6:40 PM, Peter Brown smoothwater...@adelphia.net wrote: You probably know better than I, but do most folks use or need a FlightGear specified screen capture utility? Yes. Perhaps I look at it another way, but even if it has one I think I'd still use my computer's screen capture utility. A built-in screenshot function does have some advantages. For example, it can temporarily hide the menu bar, can be bound to a joystick button, can be triggered from nasal and more such goodies. At least theoretically it could also produce a single image for a multi-display setup. I personally don't need a dialog for it, though. -- Cheers, Csaba/Jester I see, makes more sense if someone takes constant shots. One the great little tidbits someone already committed was an autohide menu bar. Although a minor enhancement, I find that to be very nice. Thanks, Peter -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Magnetic North
Unfortunately most of the users are not using or able to create individual Terrain builds. If I could without taking computer courses I would, just to make use of those 213 airfield updates! :) :) …trying to be patient. Peter :) On Jan 16, 2011, at 4:23 PM, Martin Spott wrote: John Denker wrote: FG is still using airport data that hasn't been updated since 2008. Depends on your particular definition of FG. To be precise, the file at: http://mapserver.flightgear.org/apt.dat.gz contains 213 airfield updates (currently) which have been merged over the time, which can be used in individual Terrain builds (by importing this file) and which are shown on the 'mapserver.flightgear.org' web map. Here's the list of the updated fields: http://mapserver.flightgear.org/Apt.Dat.txt Additionally, there are a couple of airfields already modified in the Terrain you get via TerraSync, but it's just a small number. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Towable Object Idea
I have an idea to run by you all, and I encourage your input or comment and perhaps to spike anyone's interest. The idea is to create liftable and moveable mp objects, using the current aerotow feature, primarily for helicopter usage. While I am not knowledgeable enough to create it, it's been in the back of mind since Curt suggested demonstrating the Aircrane at a Simulator event by building a virtual tower some time ago. My thought would be create a number of simple objects, with the simplest FDM attached to them. To start these could simply be blocks, although this could expand to pipes/tower sections/etc. Each would use the 'pick' animation feature to bind the aerotow property to lock on and unlock the tow cable. This should get around requiring a second user to lock onto the tow aircraft. One would get within the 60m preset distance of the towable object and then click on it to attach the cable. Lift it, move it, set it anywhere, and click on it to un-attach it. To work in mp appears to be a slightly bigger issue. While it would be ideal from a mp standpoint to have 5-10 simplistic objects hosted on each mpserver, I assume that may not be very feasible. The ideal program would include some minor nasal timers and listeners that would default the object back to the default spawn location, say after 12 hours since last move. This would ensure it doesn't get lost or dropped in an un-retreiveable location. I ran the whole idea by a model builder, and he suggested perhaps having an object spawn other objects, such as how ordnance is dropped from an aircraft. Here's his thoughts - I think your plan could work. I think it would be desirable to have the objects be pseudo-aircraft like the jeep, etc., with dummy FDMs and as simplified as possible, then each can have a nasal system running on it containing custom code to handle special situations like resets, etc., taking this off any server requirements and placing it totally on the number of objects on MP. But each object would be a player-run MP vehicle with all the usual MP resources etc. and its own FG client I presume. So a better system might have one object that spawns other objects rather like ordinance, and then monitor/update them via nasal routines. That way only one MP 'player' need be on for all the objects, and the nasal running on the master object would manage all sub-objects and deal with special interactions. I'm not totally sure this is all possible, but I'll wager it is. Probably one of the FG gurus can think of a better way. I don't know if anyone has considered the possibilities of having generic mp-objects, but without them transmitting data as if an mp-user. If this was possible, it would not be a stretch for one of the FG community to provide a server that hosted these semi-static mp-objects. All of the ideas presented here may not be needed to achieve the base goal, but I believe there is a value to the Flightgear mp environment if it is achievable. (Without going into more tangents, I believe this could also open the door for other Flightgear enhancements) I would appreciate meaningful comments. Thanks, Peter-- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mouse acceleration
On Jan 7, 2011, at 1:13 PM, syd adams wrote:
Yes, the two lines of code I added just write the mouse xy movement to
properties.With nasal I have to calculate the movement,which is done
in the mouse code already.I've set up the Aerostar so I can click and
slide the throttle,mixture and propeller levers in pairs, or
Shift-drag to move each lever individually,by dragging the mouse up
and down.
This is an excellent addition!
On Friday, January 7, 2011, Heiko Schulz aeitsch...@yahoo.de wrote:
Hi,
Can you explain it a bit more detailed?
Is this the same as the manual which you move with the mouse in the
B1900d-cockpit?
Cheers
Heiko
Hi guys.
Is there any interest in mouse acceleration properties,
besides myself ?
I,ve added it locally , and have mouse drag pedestal
controls in the Aerostar .
The calculation is already done in the code,
FGMouseInput.cxx , so
I've simply written each to a property:
At line 317:
if (x != m.x) {
int delta = x - m.x;
fgSetInt(/devices/status/mice/mouse/accel-x,
delta);
for (unsigned int i = 0; i
mode.x_bindings[modifiers].size(); i++)
mode.x_bindings[modifiers][i]-fire(double(delta),
double(xsize));
}
if (y != m.y) {
int delta = y - m.y;
fgSetInt(/devices/status/mice/mouse/accel-y, -1 * delta);
for (unsigned int i = 0; i
mode.y_bindings[modifiers].size(); i++)
mode.y_bindings[modifiers][i]-fire(double(delta),
double(ysize));
}
I figured there was no point doing a patch for 2 lines of
code , and
if no one else sees a use for it , it's easy to do with
nasal...
Cheers
--
Gaining the trust of online customers is vital for the
success of any company
that requires sensitive data to be transmitted over the
Web. Learn how to
best implement a security strategy that keeps consumers'
information secure
and instills the confidence they need to proceed with
transactions.
http://p.sf.net/sfu/oracle-sfdevnl
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: Fwd: Generic Autopilot works by location?
Thought this went to the list. Begin forwarded message: From: Peter Brown smoothwater...@adelphia.net Date: January 4, 2011 11:58:58 AM EST To: Curtis Olson curtol...@gmail.com Subject: Re: [Flightgear-devel] Fwd: Generic Autopilot works by location? On Jan 4, 2011, at 11:38 AM, Curtis Olson wrote: I skimmed through that message but haven't had a chance for a detailed read through. It seemed rather complicated to get to the point where the bug is tickled. I was hoping I could just run ./fgfs --aircraft=someaircraft --airport=someairport and then pull up the autopilot settings dialog and see that things were broken? But it seems like it's much more complicated than that to tickle the bug? Curt. aircraft = MD-81 airport = KBTV --prop:/autopilot/target-tracking/enable=1 Pull up autopilot settings and attempt to change. If unable to change heading, alt hold, or speed to user setting, change /autopilot/target-tracking/target-root = '/ai/models/aircraft[0]' (string) to any number besides [0]. AP should then work. This can be done sitting on the runway. Peter On Tue, Jan 4, 2011 at 10:27 AM, Peter Brown smoothwater...@adelphia.net wrote: Curt, I assume you saw the prior email I sent directly with the screen shots included? If that's what you are referring to then yes, I agree it's strange, but I am unable to narrow it down further due to my lack of programming knowledge. Thanks, Peter On Jan 4, 2011, at 11:23 AM, Curtis Olson wrote: Hi Peter, I haven't had a chance to follow through and try to replicate what you are seeing, but it is strange if there is a link between the hud and the autopilot like that. I'm not sure I've ever played around with target tracking? I've never seen a lock on in flightgear, but I haven't played around with some of the military features much that some of the guys are developing. It seems really strange though if nothing else? If you can condense this down somehow and still feel there is a real problem once you've played with it more, let me know. I can't vouch for how much time I'll have, but I hate having weird obscure bugs lingering around. If too many of them stack up you can end up with an intractable mess. Thanks, Curt. On Mon, Jan 3, 2011 at 5:44 PM, Peter Brown smoothwater...@adelphia.net wrote: Curt, In working it more and more, my general feeling is threefold - 1 - it's likely a case of my not understanding completely how it the AP, HUD, and Target tracking are/were integrated. Meaning that while I assume target tracking allows you to actually lock on to another a/c, most pilots use it as a form of tracking other aircraft, as a visual reference. It appears that this is no longer there in the current git, but that may change when Tat creates a 2.2 build. 2 - I have found that once I enable the target tracking, the autopilot is unchangeable _unless_ I change the mp[x] to at least [8] (at Moffett Field), and then I can change the autopilot numbers to my preference. Once I've done that, I can change the tracking [x] back to any number with no change to the autopilot. At this point none of this matters with the current git files, as enabling target tracking does not bring up the tracking rings on the HUD. Multiplayers on hand while trying this on different aircraft were in the teens. 3 - I have not tried it, but my assumption is now that this same method will work everywhere, provided I keep the current files from git. Why the target tracking is not affected at the northern and southern latitudes is completely unknown. Outside of KSFO all the other airports had no multiplayers within range. So long and short is that seems to be pretty isolated to me. Something changed along the way, for using --prop:/autopilot/target-tracking/enable=1 for tracking ring display did not use to be a problem, and still isn't a problem for another mac user using Tat's snapshot. But obviously it does in what I have set up currently, so now that I know the workaround to get it working I can use it. Sorry for taking up your time. Peter On Jan 3, 2011, at 2:37 PM, Curtis Olson wrote: Hi Peter, I can't think of any reason the basic autopilot functionality would be tied to a particular location. Could you provide a specific aircraft and airport (i.e. command line options) that tickle this bug? Perhaps it's something with your local build? Perhaps it's something really obscure that no one else has noticed? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt
[Flightgear-devel] Fwd: Generic Autopilot works by location?
Hey all, I am finding the Generic Autopilot either works as expected, or loads with unchangeable data, depending on spawn location. I seem to recall some discussion about a location dependent bug, but I thought it was related to weather. (?) FlightGear v2.0 8/21/2010 snapshot from Tat's site. Any aircraft without a purpose built AP seems to be affected, based on the number I've tested, but for these locations listed I was using the popular MD-81 from Gary Neely's website. Airports to the north and to the south are working, where the middle area is not. Working locations tested: To the south - Kathmandu, Nepal, San Antonio, TX; Orlando, FL, and Key West, FL To the north - Rost, Norway; Montreal, QC Non-working locations seem to be anything across the middle third - Burlington, VT (just across the border from Montreal) Atlanta, GA Charles De Gaulle, Paris, France EHAM KSFO What I don't know yet is if this related to latitude/longitude, the airport itself, or something outside of that. But the data at the moment presents itself as a lat/lon issue. In a non-working location bad data consists of a default speed in the 13,000 range, alt hold in the 33,000 range, and headings from 130 - 550 degrees. These values can not be changed by the user. Often the headings and speed values are constantly climbing. A valid working location typically loads with 0 for heading and speed, and a single digit value for altitude hold. These are then changeable. Can anyone enlighten me on it? Thank you, Peter Brown Does no one have information on the Generic Autopilot only working above or below certain latitudes? -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Autopilot works by location?
On Jan 3, 2011, at 2:37 PM, Curtis Olson wrote: Hi Peter, I can't think of any reason the basic autopilot functionality would be tied to a particular location. Could you provide a specific aircraft and airport (i.e. command line options) that tickle this bug? Perhaps it's something with your local build? Perhaps it's something really obscure that no one else has noticed? Thanks, Curt. On Mon, Jan 3, 2011 at 1:28 PM, Peter Brown wrote: Hey all, I am finding the Generic Autopilot either works as expected, or loads with unchangeable data, depending on spawn location. I seem to recall some discussion about a location dependent bug, but I thought it was related to weather. (?) FlightGear v2.0 8/21/2010 snapshot from Tat's site. Any aircraft without a purpose built AP seems to be affected, based on the number I've tested, but for these locations listed I was using the popular MD-81 from Gary Neely's website. Airports to the north and to the south are working, where the middle area is not. Working locations tested: To the south - Kathmandu, Nepal, San Antonio, TX; Orlando, FL, and Key West, FL To the north - Rost, Norway; Montreal, QC Non-working locations seem to be anything across the middle third - Burlington, VT (just across the border from Montreal) Atlanta, GA Charles De Gaulle, Paris, France EHAM KSFO What I don't know yet is if this related to latitude/longitude, the airport itself, or something outside of that. But the data at the moment presents itself as a lat/lon issue. In a non-working location bad data consists of a default speed in the 13,000 range, alt hold in the 33,000 range, and headings from 130 - 550 degrees. These values can not be changed by the user. Often the headings and speed values are constantly climbing. A valid working location typically loads with 0 for heading and speed, and a single digit value for altitude hold. These are then changeable. Can anyone enlighten me on it? Thank you, Peter Brown Does no one have information on the Generic Autopilot only working above or below certain latitudes? -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ I will put together more information. Thank you, Peter-- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Generic Autopilot works by location?
Hey all, I am finding the Generic Autopilot either works as expected, or loads with unchangeable data, depending on spawn location. I seem to recall some discussion about a location dependent bug, but I thought it was related to weather. (?) FlightGear v2.0 8/21/2010 snapshot from Tat's site. Any aircraft without a purpose built AP seems to be affected, based on the number I've tested, but for these locations listed I was using the popular MD-81 from Gary Neely's website. Airports to the north and to the south are working, where the middle area is not. Working locations tested: To the south - Kathmandu, Nepal, San Antonio, TX; Orlando, FL, and Key West, FL To the north - Rost, Norway; Montreal, QC Non-working locations seem to be anything across the middle third - Burlington, VT (just across the border from Montreal) Atlanta, GA Charles De Gaulle, Paris, France EHAM KSFO What I don't know yet is if this related to latitude/longitude, the airport itself, or something outside of that. But the data at the moment presents itself as a lat/lon issue. In a non-working location bad data consists of a default speed in the 13,000 range, alt hold in the 33,000 range, and headings from 130 - 550 degrees. These values can not be changed by the user. Often the headings and speed values are constantly climbing. A valid working location typically loads with 0 for heading and speed, and a single digit value for altitude hold. These are then changeable. Can anyone enlighten me on it? Thank you, Peter Brown -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] More flightprosim offshoots
http://www.airbusflightsimulator.com/index.html http://www.airbusflightsimulator.com/buy-flight-simulator.html http://www.airbusflightsimulator.com/flight-simulator-planes.html -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Do Shader animations support Conditions?
I was attempting to install a few shaders, based on internal or external view, but I have not been able to make it work. Can someone let me know if you can use a condition in a shader animation ? Thanks, Peter -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] productwiki.com another flightgear page
On Dec 15, 2010, at 2:23 PM, Citronnier - Alexis Bory wrote: Hi all 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/ Alexis 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. Peter -- 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] FlightGear Flight Pro Sim Statement
On Dec 10, 2010, at 2:51 PM, Gene Buckle wrote:On Fri, 10 Dec 2010, Alexander Barrett wrote:Sorry I haven't been keeping up with things, but have flightsim.com and simmarket.com run the statement yet?If not I'm sure I can get it on their weekly mailing lists and front pages, been friends with the owners for many years.I would also suggest that if you've got a Facebook account that you spend some time searching within "Flight simulator". Look for the "proflightsim" phony box art to locate their pages and report them as a scam to FB. I've opened "THIS IS A SCAM" discussions on many of the pages. The most entertaining of the threads has unfortunately, been deleted. (I'm not sure how insulting it is when someone yells, "You Zero Affiliate!", but it was pretty damn funny.) It appears that the sock-puppet hurling those "insults" has also been removed from FB, so it does do SOME good to report this crap to them.Thanks!g.Just to add some new info - The flightsim guys (people?) just registered and has public a new website, "Flightgear.us". It's listed as a new group on Facebook, and the whois trace shows Tel Aviv, Isreal as the address, although hosted by a company in Burlington, MA USA as listed below -They are getting more aggressive - and this is direct attack to deceive. It's dated today, 12/13/10. Domain Name: FLIGHTGEAR.USDomain ID: D31250901-USSponsoring Registrar: TUCOWS INC.Registrar URL (registration services): whois.opensrs.orgDomain Status: clientTransferProhibitedDomain Status: clientUpdateProhibitedRegistrant ID: TU3QYDFLMBM80CNQRegistrant Name: alon zurRegistrant Organization: alon zurRegistrant Address1: bakat 5Registrant City: tel avivRegistrant State/Province: NARegistrant Postal Code: 742311Registrant Country: IsraelRegistrant Country Code: ILRegistrant Phone Number: +1.0527121996Registrant Email:Registrant Application Purpose: P1Registrant Nexus Category: C11Administrative Contact ID: TUFR67AUOLT2AJG0Administrative Contact Name: alon zurAdministrative Contact Organization: alon zurAdministrative Contact Address1: bakat 5Administrative Contact City: tel avivAdministrative Contact State/Province: NAAdministrative Contact Postal Code: 742311Administrative Contact Country: IsraelAdministrative Contact Country Code: ILAdministrative Contact Phone Number: +1.0527121996Administrative Contact Email:Administrative Application Purpose: P1Administrative Nexus Category: C11Billing Contact ID: TUNWMNRK7UTC4GYUBilling Contact Name: alon zurBilling Contact Organization: alon zurBilling Contact Address1: bakat 5Billing Contact City: tel avivBilling Contact State/Province: NABilling Contact Postal Code: 742311Billing Contact Country: IsraelBilling Contact Country Code: ILBilling Contact Phone Number: +1.0527121996Billing Contact Email:Billing Application Purpose: P1Billing Nexus Category: C11Technical Contact ID: TUUXA6GBSLBMPAOXTechnical Contact Name: K.L. PetersonTechnical Contact Organization: StartLogicTechnical Contact Address1: 70 Blanchard RoadTechnical Contact City: BurlingtonTechnical Contact State/Province: MATechnical Contact Postal Code: 01803Technical Contact Country: United StatesTechnical Contact Country Code: USTechnical Contact Phone Number: +1.8007258064Technical Contact Facsimile Number: +1.7812726550Technical Contact Email:Technical Application Purpose: P1Technical Nexus Category: C11Name Server: NS1.STARTLOGIC.COMName Server: NS2.STARTLOGIC.COMCreated by Registrar: TUCOWS INC.Last Updated by Registrar: TUCOWS INC.Domain Registration Date: Sun Dec 12 09:40:10 GMT 2010Domain Expiration Date: Sun Dec 11 23:59:59 GMT 2011Domain Last Updated Date: Sun Dec 12 09:40:12 GMT 2010 Whois database was last updated on: Mon Dec 13 21:40:58 GMT 2010 -- 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] FlightGear Flight Pro Sim Statement
On Dec 13, 2010, at 7:08 PM, Victhor wrote: The individual responsible for the page put this there: 1.Sponsoring a child - many kids in our world that aren't able to get even the basic stuff, like food, simple health care, and school. I never knew they were going _that_ far in dubious marketing tactics. The individual(s) are good at their internet game in respect to advertising. I would guess that someone is working at this a good portion of each week to make it happen. From a marketing standpoint the author knows how to sound legitimate, obviously without a conscience or morals. See the first page results of this google search : http://www.google.com/search?client=safarirls=enq=flight+pro+simie=UTF-8oe=UTF-8 At least 95% of the results are some form of theirs. Everything from Is it a hoax? to considered one of the top flight simulators available to the public for quite some time. I suggested Flightgear beat him at his own game back in March - As much as I'd hope what you say would be true, realistically there is not much of a downside for this guy. Everyday people make purchases without knowing all the facts, and for more money buying online than locally. (Ebay can be a good example) From his side of it, unless someone or group is willing to take it through the legal process, any sale he gets is free money to him. And if someone does take to court, does anyone know what to expect for an outcome? Would it be more than a simple stop order? If not, he's already stolen money from unknowning customers, so he's still ahead of the game. While I truly hope this group, or multiple groups can get together and bring him to task for his wrongs, publication of FlightGear.org as a BETTER simulator, which also happens to be FREE, and by the way, that other simulator is just a copy of ours that you have to pay for may be the best way to be combative. Go on the offense, publicize the heck out of it. Encourage users to post more youtube videos, publish your own, make sure every website page has the best language for the google bots to promote FlightGear.org as better, with free being a side benefit. And Curt got the FB page going and many people have expended effort and funds of their own to try to combat his tactics. But, I don't see this as a short-term turnaround. This may be long road to righteousness, and with help from other sites that have already posted statements, and a continued and solid facebook showing, FG may triumph. The second thing to consider, is how to stop the next guy from doing the same thing. Peter-- 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] New release
Seconly, do we want to maintain our current aircraft selection, or do we want to include a (partially) updated selection from our git repository, or -alternatively- do we want to strip the entire selection down to just single aircraft, and make the others downloadable from our main website. Hi Durk, I think the current system of a selection of the best of category is much better than stripping down to one aircraft. Cheers - Dave Agreed. FG needs to make a presentation to the new user upon first visit, and the 10 included should wet their appetite for more. Having only 1 may turn them away. Peter-- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw not running correctly on Mac 10.4
Did you try simply using this version? http://macflightgear.sourceforge.net/wp-content/uploads/TaxiDraw/Taxidraw.cvs-bin-20090416.tgz On Jun 28, 2010, at 1:31 AM, Andrew Gillanders wrote: Before building TaxiDraw, I had to install new versions of wxWidgets (2.8.11, from http://prdownloads.sourceforge.net/wxwindows/ wxMac-2.8.11.tar.gz), libcurl (7.19.4, from http:// www.opensource.apple.com/source/curl/curl-57/) and libtool (2.2.8, from http://ftp.gnu.org/gnu/libtool/libtool-2.2.8.tar.gz). These compiled and installed straight out of the box - nothing to fix for them. There were a couple of minor issues with TaxiDraw to get it to compile. The makefiles did not define the AR and LIBTOOL symbols correctly. Secondly, in src/Main/PreferenceDialog.cpp on lines 252 and 255, the argument for the call to SetValue was changed from 'oss.str()' to 'wxString(oss.str().c_str(), wxConvUTF8)'. All this was done using the usual ./configure and make commands. The executable launches, but does not respond to the mouse. Andrew On 27/06/2010, at 11:59 PM, James Turner wrote: On 27 Jun 2010, at 13:07, Andrew Gillanders wrote: do some work on AI networks, and the wiki says that there are necessary code changes in TaxiDraw that went in after that build was done. I was able to get the code from cvs and build everything, but it isn't running correctly. I haven't tried to build TaxiDraw in years - can you remind me (given that I'm on Mac 10.6, and have FlightGear building), what I need to grab (and from where), the approximate build steps, and what does / doesn't work for you? Hopefully then I can make some more intelligent statements about where the problem might be. James -- 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 -- 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 -- 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] TaxiDraw not running correctly on Mac 10.4
Below are some newer Mac sources. On Jan 2, 2010, at 4:01 AM, Peter Brown wrote: Tat, Have you compiled any more recent versions of TaxiDraw than my 0.3.2 release that I think James Turner did? Yes, I have the App bundle (intel only, OS X 10.5 or later) as of mid Aug. last year. The last change was made on Apr-15-2009 in CVS repository so this is the latest one. Now it's available at: http://macflightgear.sourceforge.net/wp-content/uploads/TaxiDraw/Taxidraw.cvs-bin-20090416.tgz If you want to build it yourself, then the patch is available at: http://macflightgear.sourceforge.net/wp-content/uploads/TaxiDraw/TaxiDraw-MacOSX.diff This patch is to fix a compilation error (related to wxWidgets, IIRC). On Jun 24, 2010, at 5:00 PM, James Turner wrote: On 24 Jun 2010, at 17:04, HB-GRAL wrote: I am running the Tiger binaries (v0.32) from James Turner: http://homepage.mac.com/zakalawe/.Public/taxidraw-0.3.2.dmg Wow, those still exist?! I guess I should do an updated build - I had long forgotten those binaries existed! James -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 8:08 AM, David Megginson wrote: On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown smoothwater...@adelphia.net wrote: Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment (as verified in taxidraw). This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. I'm not familiar with mpmap, but that's not a problem for FlightGear itself - the localizer directions are all specified in Navaids/nav.dat.gz in degrees true, independently of any runways they might be associated with (not all localizers are attached to a runway, and even when they are, the direction might be 10 degrees off from the runway). Here's the example for BTV (where I've flown the localizer in real life as well as in FlightGear): 12 44.4652 -073.14009400342 11030 18 0.000 IVOE KBTV 33 DME-ILS But then, the vast majority of runways don't have localizers. Perhaps the map is just trying to show an extended runway centreline, and the person who designed the app mixed up magentic and true heading. The Airports/apt.dat.gz file does give runway headings in degrees true, not degrees magentic, so there's no need to mess around with magnetic deviation. All the best, David David, yes, as I have as well. The localizer for 33 as you listed above is on a 326 heading per the approach plate, but the mpmap shows ILS data as the runway heading in degrees - as if for users to use as the ILS data. I'm not sure what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) I believe James is correct in that it's probably a question for Pigeon, whom I believe created and maintains the mpmap data. James, You are correct as well, in real life you don't shoot an approach without the plate. (Okay..., you shouldn't...) :) ButFG does have to walk that thin line between sim and reality, and until users get to the point of full reality immersion, they will use the data presented to them for ease of use (if nothing else). While I enjoy FG immensely due to all of the developers work, I doubt I'll be strapping on an approach plate until I'm sitting in a full blown simulator cockpit with the door shut. :) So, I guess I'll see if Pigeon responds about perhaps re-formatting the mpmap code to use actual approach headings instead of runway headings. For anyone that isn't aware of the data presented, I recommend you take a look. It has more info than you may realize, and it helps the user find airports, navaids, and more. Airport data includes the degree of GS (for those rare abnormally high approaches), localizer frequency, and if a CAT 1,2, or 3 approach. For most of the users this is a wealth of information. A side benefit is from an ATC point of view for FG events, you can visually see how well the pilots are flying the localizer. Peter :) -- 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] mpmap ILS data
On Apr 8, 2010, at 1:29 PM, David Megginson wrote: On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown smoothwater...@adelphia.net wrote: David, yes, as I have as well. The localizer for 33 as you listed above is on a 326 heading per the approach plate, but the mpmap shows ILS data as the runway heading in degrees - as if for users to use as the ILS data. I'm not sure what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) The plates give the heading in degrees magnetic; the data file gives it in degrees true. That's still a degree off (BTV is 15W, IIRC), but it's pretty close, and nav.data.gz may be based on old data. All the best, David I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Thanks, Peter -- 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] mpmap ILS data
On Apr 8, 2010, at 4:09 PM, Martin Spott wrote: Peter Brown wrote: I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. or from the navaids. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. They are certainly going to keep the true heading in the navaid file, because the magnetic heading is changing permanently and therefore is a moving target. The navaids collection is meant to place the navaids at their proper location in an unambiguous way - which obviously is the true heading. BTW, feel free to use this service if your're looking for slightly more complete airfield data: http://mapserver.flightgear.org/ms?Service=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter still processing. Cheers, Martin. -- I have no reason to take it out, but I see no reason to not compile a list of approach plate data that the mpmap can retrieve usable data from either, if you don't want to add it to the navaids file. Is there any reason not to? Peter -- 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] mpmap ILS data
On Apr 8, 2010, at 4:58 PM, David Megginson wrote: On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown smoothwater...@adelphia.net wrote: I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Again, I haven't used mpmap, but are you certain it is trying to display an ILS localizer, and not just an extended runway centreline? You're right, of course, that it might have messed up true vs. magnetic (especially if the developer was working somewhere with very little magvar, and wouldn't have noticed during testing). Our files list actual runway headings in degrees true as well, so the only thing I can think is that the developer just took the runway *number* and converted it to a heading. All the best, David No, I'm not sure of any of it. I was thinking I had posed it as a question whose answer was readily available - I wasn't trying to debate it if that's how it came across. I like functionality that the majority of users find useful, since I classify myself as one of those. :) My guess is that as Martin said, he/she probably is grabbing data from the navaids file. To show you what mpmap provides, here's a few links. Note the two heading info boxes when you have the ILS beam on - as if to display Runway heading and Approach heading, since the first info box also lists the runway number, ILS CAT #, and GS degrees. http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50447PM.png http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50447PM.png http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50518PM.png Thanks, Peter-- 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] mpmap ILS data
On Apr 8, 2010, at 5:23 PM, Martin Spott wrote: If you're in need of a human-readable one-shot database table dump, please let me know. Cheers, Martin. -- That'd be great, send it my way. Peter -- 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
[Flightgear-devel] Fwd: mpmap ILS approach data
First email never arrived to the list Might be a question for Pigeon, rather than apt.dat or nav.dat Begin forwarded message: From: Peter Brown pe...@smoothwatersports.com Date: April 4, 2010 10:36:05 AM EDT To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: mpmap ILS approach data Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment in taxidraw. This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. KJFK, runway 31L - mpmap ILS course; 301 degrees Flightaware ILS approach plate; 315 degrees. I have not looked at the 850 airport format, but is there a way in any of the apt.dat data to specify ILS approach data accurately? Currently the heading data is misleading - it would be better to not have it shown than have it incorrect in my opinion. Thanks! Peter -- 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
[Flightgear-devel] mpmap ILS data
Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment (as verified in taxidraw). This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. KJFK, runway 31L - mpmap ILS course; 301 degrees Flightaware ILS approach plate; 315 degrees. I have not looked at the 850 airport format, but is there a way in any of the apt.dat or nav data to specify ILS approach data accurately? Or is this a question for Pigeon, to see about using a different data list? Currently the heading data is misleading - it would be better to not have it shown than have it incorrect in my opinion. Thanks! Peter -- 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] Issue with default starting scenario
On Apr 6, 2010, at 7:06 PM, James Turner wrote: On 6 Apr 2010, at 20:35, Martin Spott wrote: Except in the case of an accident or mechanical failure, you would *never* be sitting on the threshold with your engine off, especially at a big airport like KSFO (unless you wanted to give your plane and yourself a 747-sized colon exam). I think that option #1 is ideal for new users, but option #2 would be OK if we want to distinguish ourselves from MSFS by making things more difficult. Indeed, a valid point ! I've started creating some properties under /sim/realism (mostly booleans for the moment), with the expectation that at some point we can create a GUI, and also use some Nasal to batch-configure the individual settings for different applications - flight trainer, game mode, kiosk, etc, etc. I'd be happy to add a /sim/realism/start-parked and /sim/realism/start-dark (though the latter involves aircraft designer help to hook the optional autostart functions of each aircraft). My concern is touching the dreaded position init code, which is already baroque and complex. There's also the question of guessing a parking position when we don't have parking stand data - eg picking a point some distance away from the runway centerline (runway width * 5, maybe?), level with the threshold - but like all heuristics, this one has problems. Regards, James In terms of simplicity, I would like to offer a suggestion of using one (or more) of the parking positions at airports with (current) parking positions. If the user spawns at an airport without any preset parking positions, a position of :: 90 degrees to the runway and nose at runway edge :: should work for _most_ airports, until that airport is improved and gets a parking position. James suggestion of a multiplier can work, but I would suggest no more then (width*1) from the runway. Too many small airports would drop you in the woods at a greater multiplier. Peter -- 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] Issue with default starting scenario
On Apr 6, 2010, at 7:27 PM, David Megginson wrote: On Tue, Apr 6, 2010 at 7:06 PM, James Turner zakal...@mac.com wrote: My concern is touching the dreaded position init code, which is already baroque and complex. There's also the question of guessing a parking position when we don't have parking stand data - eg picking a point some distance away from the runway centerline (runway width * 5, maybe?), level with the threshold - but like all heuristics, this one has problems. OK, here's my suggestion: *all* aircraft start with the runway threshold with the engine idling, unless the user has overridden that. Engine on/off is a decision that it doesn't make sense leaving to individual aircraft designers, since it's a cross-cutting user experience question. All the best, David From a user's point of view, I disagree wholeheartedly. The individual aircraft designer should have complete control of the aircraft's state when it spawns. Until it's a collision issue, why force aircraft to spawn running? Spawning non-running in more realistic, no matter where it spawns. -- 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] Issue with default starting scenario
On Apr 6, 2010, at 8:05 PM, David Megginson wrote: On Tue, Apr 6, 2010 at 7:34 PM, Peter Brown smoothwater...@adelphia.net wrote: In terms of simplicity, I would like to offer a suggestion of using one (or more) of the parking positions at airports with (current) parking positions. If the user spawns at an airport without any preset parking positions, a position of :: 90 degrees to the runway and nose at runway edge :: should work for _most_ airports, until that airport is improved and gets a parking position. James suggestion of a multiplier can work, but I would suggest no more then (width*1) from the runway. Too many small airports would drop you in the woods at a greater multiplier. I realize I'm flogging a dead horse (and won't be offended if people tune out), but I just want to mention planes will very rarely be parked close to the runway, to avoid accidents if someone gets blown off the runway, ground-loops, etc. A plane parked near the runway with fuel in its tanks could make a deadly fireball out of what would otherwise be a bit of gear damage, a few broken runway lights, or (at worse) a bent wing. I have seen exceptions, mainly at private and uncertified airports (e.g. farm strips), but normally planes are parked with their noses against a taxiway, not the runway (or otherwise, a safe distance away on a field or apron). All the best, David You are absolutely correct David, but to bridge the gap between doing an actual pre-flight on the overnight apron, and flying in FlightGear, I suggested it as a way to not load in directly on the runway, which seemed to be your point. (It was just a short time ago I had issues with runway offsets that spawned me in the water at KSFO, or the woods at other airports) I've never had the opportunity to fly at a FlightSafety facility...I wonder where they spawn. :) Cheers, Peter -- 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
[Flightgear-devel] Route Man / AP
Quick question for James I think - when the route manager passes the last listed nav point, the AP doesn't disengage, it turns west (from the east coast). This is a default heading to KSFO or some other pre-determined home ? Thanks, Peter -- 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
[Flightgear-devel] C1 C2
Does anyone have information on aircraft displayed as C1 and C2 on the mpmap? These two user names were on the Salt Flats for quite a long time, using a jeep as an aircraft, 5 ft off the deck. They have now been repositioned in Virginia, at 36.61231, -79.341052, both as C172p's, and about 3300 feet. (Just off 02 Departure path from KDAN) The reason I ask is while I didn't notice it quite as much with the jeeps, if you fly near the 172's it will stall any helicopter flight, as my framerate when from 30+ to 1. From more of a distance you will see the fv drop when looking at them, but as you get close it kills it, even with a j3 cub. Is someone testing some extremely high polygon count aircraft, or what's going on? ORLY hurts my frame rate, but nothing like these two 172's do. Thanks, Peter -- 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] C1 C2
On Apr 1, 2010, at 5:32 PM, Csaba Halász wrote: On Thu, Apr 1, 2010 at 8:14 PM, Peter Brown smoothwater...@adelphia.net wrote: Does anyone have information on aircraft displayed as C1 and C2 on the mpmap? These two user names were on the Salt Flats for quite a long time, using a jeep as an aircraft, 5 ft off the deck. They have now been repositioned in Virginia, at 36.61231, -79.341052, both as C172p's, and about 3300 feet. (Just off 02 Departure path from KDAN) The reason I ask is while I didn't notice it quite as much with the jeeps, if you fly near the 172's it will stall any helicopter flight, as my framerate when from 30+ to 1. From more of a distance you will see the fv drop when looking at them, but as you get close it kills it, even with a j3 cub. Is someone testing some extremely high polygon count aircraft, or what's going on? ORLY hurts my frame rate, but nothing like these two 172's do. No matter how high poly count the other side uses, you will only see the c172p from your local FG copy. That is, these two should be just the stock c172p. They certainly don't kill my FPS, here. -- Csaba/Jester I understand that, so I don't understand why it's happening. I can fly around KSFO with 40 a/c, but if I fly within 1/2 mile of these two it drops. Apparently you flew up them and didn't have any issue? None-the-less.who/what/why are they there? Someone running a longevity test on the server? Peter -- 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] News from FlightProSim!
As much as I'd hope what you say would be true, realistically there is not much of a downside for this guy. Everyday people make purchases without knowing all the facts, and for more money buying online than locally. (Ebay can be a good example) From his side of it, unless someone or group is willing to take it through the legal process, any sale he gets is free money to him. And if someone does take to court, does anyone know what to expect for an outcome? Would it be more than a simple stop order? If not, he's already stolen money from unknowning customers, so he's still ahead of the game. While I truly hope this group, or multiple groups can get together and bring him to task for his wrongs, publication of FlightGear.org as a BETTER simulator, which also happens to be FREE, and by the way, that other simulator is just a copy of ours that you have to pay for may be the best way to be combative. Go on the offense, publicize the heck out of it. Encourage users to post more youtube videos, publish your own, make sure every website page has the best language for the google bots to promote FlightGear.org as better, with free being a side benefit. I say this for it seems that marketing is his game, although purely a sham. Let's beat him at it, honestly. my .02 worth. Peter On Mar 17, 2010, at 8:38 AM, Jon S. Berndt wrote: I think this is exactly true. And what happens to this guy when more and more people start finding out that they have paid money for something they could have gotten for free? Jon From: Curtis Olson [mailto:curtol...@gmail.com] The guy is building his business on a charade ... and that is a hard thing to keep up long term. He has to spend a large percentage of his time maintaining his charade, covering his tracks, etc. I can't even remember my own forum password half the time ... and this guy has to remember a bunch of user names and passwords. He probably has sticky notes all over his monitor. Maybe he's really good at that sort of thing and will have some leeching success, but it's a shaky business model that could come crashing down around him at any time. He's always going to be looking over his shoulder ... hoping he doesn't inadvertently swindle the wrong person in the wrong country ... hoping the major publications don't catch on to him ... hoping if something does go wrong he can duck into the shadows and re-emerge somewhere else ... reality has a way of catching up with these guys eventually. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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
[Flightgear-devel] Instant Replay, and it's recording of A/C parameters
As I have not been able to find any doc's or forum topics expounding on it, could someone explain a few things to me about Instant Replay? First off, what parameters are logged by it, or what defines if a parameter is logged by it? ie, thrust reverser use do not replay, but flaps do. This doesn't seem to be by model builder choice (?), unless Instant Replay is tied into multi-player parameters? Secondly, in using it to test a few modifications, I found this sort-of-an-issue. I say sort-of, for it would be rare for someone to find it. Took me 2 years. - If you start FG, and attempt to use Instant Replay with the default 90 second timeframe in _less than 60 seconds Sim time_, FG will crash with a CullVisitor~nan nan nan error. - And so, if you start FG and set the replay time for a shorter period than sim time, it will work. makes sense, other than it shouldn't crash FG. But, if you wait for the Sim clock in the property browser to reach 60 seconds, you can enter _ANY_ duration into the replay time menu (200 seconds for example), and the replay function will simply drop you back at the spawn location until the clock counts down to your spawn and movement time. So, why won't it do that under 60 seconds? I only found the issue since I was attempting to see what I could make work in replay. So, it's not really an issue, but thought I'd pass it along. If someone can fill me in on the first question about what is or can be tied into the replay function for aircraft parameters, that would be great. Thanks, Peter ref: tested senario in 2 aircraft and the mibs, to ensure consistency. -- 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] multiple --generic record/playback errors
As noted by John in February, but I did not see it addressed in this thread, is the chase view issue in 2.0. (chase view does not follow heading, and if you select chase while in a turn the viewpoint holds that angle until you leave the viewpoint) I sincerely hope it's not a feature, as there are multiple user complaints about it using v2.0. Was it corrected somewhere and I missed it? Thanks, Peter On Feb 9, 2010, at 5:23 PM, John Denker wrote: = Now for the not-so-good news. The chase views are still messed up. Do we think the cause will be another float versus double issue? I checked the names in playback.xml and didn't find any obvious problem children beyond latitude and longitude. What am I missing? -- 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
Very Nice! Clean, Integrated very well. On Mar 6, 2010, at 7:07 AM, Pete Morgan wrote: Here's an idea http://fg-aircraft.appspot.com/idea/ Am not a graphic designer ;-( 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
Re: [Flightgear-devel] ILS paths and info missing from mpmap
Thank you. On Feb 24, 2010, at 5:58 AM, Pigeon wrote: Hi all again, Found the problem and I believe I have fixed it. Let me know if there's anything still missing. Thanks. Pigeon. -- 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] ILS paths and info missing from mpmap
I found it's only when searching Fix or Airways. All other searches work properly. On Feb 24, 2010, at 3:12 PM, Pigeon wrote: I'm getting this error now when I use nav tab and search all - Database error: Couldn't execute statement SELECT * FROM fg_fix WHERE -73.0316162109375;, errno: 7, errmsg: ERROR: argument of WHERE must be type boolean, not type numeric Different location : Database error: Couldn't execute statement SELECT * FROM fg_fix WHERE -73.48068237304688;, errno: 7, errmsg: ERROR: argument of WHERE must be type boolean, not type numeric Thanks. Fixed. Something went wrong when I was doing some new change in the code. I've reverted it for now. Sorry for the problems. Pigeon. -- 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] Proposed new set of splash screens
Just to make available some more images if anyone wants to create splashes from them, I found a few of these to have nice lighting effects with the setting sun. http://s512.photobucket.com/albums/t325/barefootr/FlightGear%20Screen%20Shots/ Peter On Feb 19, 2010, at 7:47 AM, John Denker wrote: On 02/19/2010 01:48 AM, Erik Hofman wrote: I've created a new set of splash screens based on the images Durk created about two weeks ago. Does anyone have any objections to committing them or does anybody have other possible splash screens to choose from? http://home.telfort.nl/sp004798/emh/Splash1.png http://home.telfort.nl/sp004798/emh/Splash2.png http://home.telfort.nl/sp004798/emh/Splash3.png http://home.telfort.nl/sp004798/emh/Splash4.png http://home.telfort.nl/sp004798/emh/Splash5.png 1) This is important. It is always nice to make a good first impression. The splash screen is the first thing a new user sees. 2) The composition of the pictures is nice and artistic. 3) The resolution is not sufficient to survive zooming to fit a large HD screen. Jaggies appear in the image. The jaggies are particularly noticeable along sharp edges, such as the leading edge of aircraft, and on the lettering. Obvious options include -- Shipping hi-res and low-res versions of each image. -- Shipping some images hi-res and other images low-res. -- Shipping only hi-res images and scaling them down on the fly when running on a screen with fewer pixels. -- Over a *small* range of sizes, don't zoom at all, but rather show a less-than-fullscreen image in the middle of the screen, surrounded by tasteful wallpaper. -- 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] Proposed new set of splash screens
It's the Fouga Magister, from GRTux's site. It is not included in the base package, but like Dave Culp's and Gary Neely's aircraft, IMHO ...some of the best models designed for FlightGear and used by many in FlightGear... are not included in the base package. While some may disagree with me on this, I believe that promotion of any sort should be the best it can be. I think these images are great - http://www.sablonier.ch/flightgear/splash/typosplash05.jpg http://www.sablonier.ch/flightgear/splash/typosplash06.jpg http://www.sablonier.ch/flightgear/splash/typosplash07.jpg And no offense to the creator, but I don't think these provide any advertising excitement at all - http://home.telfort.nl/sp004798/emh/Splash5.png http://home.telfort.nl/sp004798/emh/Splash4.png Peter On Feb 23, 2010, at 6:46 PM, Martin Spott wrote: Peter Brown wrote: Just to make available some more images if anyone wants to create splashes from them, I found a few of these to have nice lighting effects with the setting sun. http://s512.photobucket.com/albums/t325/barefootr/FlightGear%20Screen%20Shots/ Is this really one of FlightGear's aircraft ? I'm unable to identify such variant. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] ILS paths and info missing from mpmap
Martin, Sorry, I listed mpmap in the title as Willie mentioned.See this thread for more info: http://www.flightgear.org/forums/viewtopic.php?f=2t=6967p=64343hilit=ils+missing#p64343 KBTV is my most recent case of disappearing info on mpmap. Peter On Feb 22, 2010, at 6:35 AM, Martin Spott wrote: SWShuttle wrote: Many airports, and the number seems to be growing daily, have lost the airport ILS display. Both projected localizer beams and frequency info boxes have disappeared. What are you actually talking about ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] ILS paths and info missing from mpmap
True, not sure who started the thread - but they were not explicit in the description. Thanks for looking. Peter On Feb 22, 2010, at 4:13 PM, Pigeon wrote: Sorry, I listed mpmap in the title as Willie mentioned.See this thread for more info: http://www.flightgear.org/forums/viewtopic.php?f=2t=6967p=64343hilit=ils+missing#p64343 KBTV is my most recent case of disappearing info on mpmap. Thanks for the link. I'm looking into the problem. BTW, in the forum post the term mapserver is used, which would be confusing because most people would think of mapserver.flightgear.org Pigeon. -- 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] memory hemorrhage
Not sure if I am using different scenery than John was/is, but while I have slightly reduced frame rates at the airport or pointed towards the terminal (20 +), flying around Manhattan or the area does not affect my rate from a normal of 30-40. This is on a Macbook Pro, intel c2d, 3gb usable ram, and Tat's 2.0.0-pre3. Peter On Feb 4, 2010, at 6:03 AM, Martin Spott wrote: Hi Tim, Tim Moore wrote: I haven't looked at NYC in a while, but our urban areas tend to get clobbered, particularly when the scenery guys strut their stuff for a new release. The vast majority of the changes I've recently pushed to the Base Backage CVS had either been moving/sorting files between directories or updating files in order to reflect the past ambient colour change. Very few 'new' files have been added, mostly lightweight stuff and, as far as I remember, none of these affect the NYC area. BTW, even the forementioned 'new' stuff has been around on the usual download locations either at http://scenemodels.flightgear.org/; or via TerraSync (the NYC Scenery hasn't been part of the Base Package anyway). Therefore I'm unable to identify a reasonable cause why recent changes from the Scenery department should be having a noticeable impact in terms of runtime performance, you might have to go finding another culprit :-) The ideal would be to coalesce all the buildings in a city block into one model with one texture. We're doing our best to prevent this Actually one could think of adding a preprocessing stage between the 'raw' ressources (Terrain and AC3D models) and the FlightGear runtime environment by collapsing 1x1 degree or smaller area tiles into a single Scenery file of a format to be choosen, but as long as Sim-/FlightGear doesn't provide the infrastructure to deal with this flavour of Scenery (including all the animation stuff and the like), I don't see us getting there too soon. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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 -- 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
[Flightgear-devel] Chat color
Not sure if it's just Tat's color choice or in all versions, but the chat text color that appears with the Mac 2.0.0-pre3 is still purple, which is very hard to read on screen. I assume it's due to the ambient color changes that happened after 1.9.1. We discussed it in the forums back it was just CVS versions. http://www.flightgear.org/forums/viewtopic.php?f=2t=6508p=55597hilit=chat+color#p55597 Peter -- 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
Re: [Flightgear-devel] Chat color
Good idea. On Feb 4, 2010, at 1:08 PM, Victhor wrote: Add a dialog where you can choose the chat text color. :) On Thu, Feb 4, 2010 at 5:08 PM, Peter Brown smoothwater...@adelphia.net wrote: Not sure if it's just Tat's color choice or in all versions, but the chat text color that appears with the Mac 2.0.0-pre3 is still purple, which is very hard to read on screen. I assume it's due to the ambient color changes that happened after 1.9.1. No. It was a deliberate change: http://cvs.flightgear.org/viewvc/data/Nasal/screen.nas?r1=1.52r2=1.53 screen.nas: better color? I am not saying it is - I use yellow :) -- 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 -- 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
Re: [Flightgear-devel] Threshold bug when using custom scenery enable
Sorry about the duplicate email, looks like the first email finally showed up from a week ago. Yves, as you said, KSFO is part of the default scenery. I'm not following your thought on the forum thread. As far as I can tell this issue has nothing to do with an airport check. I provided data to show the issue/bug. The issue, to paraphrase, is that when using Martin Spott's recommendation that those using terrasync should also use --prop:/sim/paths/use-custom-scenery-data=true, causes a spawn issue. If you noticed in the data provided, this is an issue with not only an early 2.0.0 release, but also with 1.9.1. Syd- thanks for providing a path on tower data for custom-scenery. Peter. On Feb 2, 2010, at 4:55 AM, HB-GRAL wrote: Peter Brown schrieb: Changing tower height in apt.dat file does not affect viewpoint. Peter, Changes of properties like viewpoint in apt.dat takes no effect. Using a wide range of custom scenery is also not a good starting point for debugging a release like the pre-alpha on OSX. But KSFO is part of the default scenery, yes. There is a recent thread about new airports in Scenery Enhancement. You can use this also for posting airport checks or updates. http://www.flightgear.org/forums/viewtopic.php?f=5t=6749 Thanks - Yves -- 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 -- 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
Re: [Flightgear-devel] Threshold bug when using custom scenery enable
Thanks again Syd. As Martin said, displacements must be zero, unless it is known to have a displaced threshold or stopway. Runway spawn issue: Many of the threshold.xml files have offsets, which cause the crash on spawn at airports like KSFO, where it drops you in the water short of 28R. 91 meters short, to be exact. Both Scenery/Airports/ and Scenery-TerraSync/Airports have this offset. At JFK it was 1000 meters. threshold lon-122.357141284717/lon lat37.6135315946418/lat rwy28R/rwy hdg-deg297.90/hdg-deg displ-m91/displ-m stopw-m0/stopw-m /threshold Tower viewpoint issue: twr.xml files are incorrect, showing either sub-terrain viewpoints or ground zero viewpoints. KJFK: twr lon-73.781647001/lon lat40.64341/lat elev-m0.00/elev-m /twr Proper elevation should be 87.78 meters. KSLC is off by 1300 meters. Who or how can these files be corrected? (I am assuming they were auto-generated) Thanks, Peter On Jan 31, 2010, at 5:58 PM, Peter Brown wrote: Hey guys, I'm finding an issue using --prop:/sim/paths/use-custom-scenery-data=true Thresholds on a number of test airports are off by a large degree, and the tower viewpoint is an issue at some. When use-custom-scenery-data=false spawn locations and tower viewpoints are correct. Test photos are linked here: http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Threshold%20Bug/ KSFO spawns you in the water off 28R. Tower viewpoint appears correct. -- 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
[Flightgear-devel] Fwd: Threshold bug when using custom scenery enable
First email disappeared, so I'm sending again - Hey guys, I'm finding an issue using --prop:/sim/paths/use-custom-scenery-data=true Thresholds on a number of test airports are off by a large degree, and the tower viewpoint is an issue at some. When use-custom-scenery-data=false spawn locations and tower viewpoints are correct. Test photos are linked here: http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Threshold%20Bug/ KSFO spawns you in the water off 28R. Tower viewpoint appears correct. KSLC appears to spawn same as normal, but tower viewpoint is far underground. Changing tower height in apt.dat file does not affect viewpoint. KBTV spawns off the end of runway 33, similar to KSFO. Tower viewpoint appears correct. KJFK spawns far off the end of 31L, and tower viewpoint is at zero (0) altitude. (Tower height is 320' in apt.dat, and shows correct when --prop:/sim/paths/use-custom-scenery-data=false) Oddly, other runway spawn locations appear to be unaffected. Issue has tested valid so far using: - Mac OS 10.6.2 (Snow Leopard) and Tat's 2.0.0-pre1(273) - Mac OS 10.4.11 and Tat's 2.0.0-pre1(273) Anyone know what's going on? Thanks, Peter -- 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
Re: [Flightgear-devel] Fwd: Threshold bug when using custom scenery enable
On Feb 1, 2010, at 12:25 PM, Heiko Schulz wrote: Hi, First email disappeared, so I'm sending again - Hey guys, I'm finding an issue using --prop:/sim/paths/use-custom-scenery-data=true Thresholds on a number of test airports are off by a large degree, and the tower viewpoint is an issue at some. When use-custom-scenery-data=false spawn locations and tower viewpoints are correct. Test photos are linked here:http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Threshold%20Bug/ KSFO spawns you in the water off 28R. Tower viewpoint appears correct.KSLC appears to spawn same as normal, but tower viewpoint is far underground. Changing tower height in apt.dat file does not affect viewpoint.KBTV spawns off the end of runway 33, similar to KSFO. Tower viewpoint appears correct.KJFK spawns far off the end of 31L, and tower viewpoint is at zero (0) altitude. (Tower height is 320' in apt.dat, and shows correct when --prop:/sim/paths/use-custom-scenery-data=false) Oddly, other runway spawn locations appear to be unaffected.Issue has tested valid so far using: - Mac OS 10.6.2 (Snow Leopard) and Tat's 2.0.0-pre1(273) - Mac OS 10.4.11 and Tat's 2.0.0-pre1(273) Anyone know what's going on? Thanks,Peter maybe this helps: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg24424.html Thanks Heiko. In reading your link - It appears that Alex created a patch as stated here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg24826.html But that was November, so perhaps the patch is not working or included in Tat's 2.0.0 pre1(273) ? The thread did not mention the tower viewpoint bug, which is also evident. Peter -- 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
[Flightgear-devel] Threshold bug when using custom scenery enable
Hey guys, I'm finding an issue using --prop:/sim/paths/use-custom-scenery-data=true Thresholds on a number of test airports are off by a large degree, and the tower viewpoint is an issue at some. When use-custom-scenery-data=false spawn locations and tower viewpoints are correct. Test photos are linked here: http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Threshold%20Bug/ KSFO spawns you in the water off 28R. Tower viewpoint appears correct. KSLC appears to spawn same as normal, but tower viewpoint is far underground. Changing tower height in apt.dat file does not affect viewpoint. KBTV spawns off the end of runway 33, similar to KSFO. Tower viewpoint appears correct. KJFK spawns far off the end of 31L, and tower viewpoint is at zero (0) altitude. (Tower height is 320' in apt.dat, and shows correct when --prop:/sim/paths/use-custom-scenery-data=false) Oddly, other runway spawn locations appear to be unaffected. Issue has tested valid so far using: - Mac OS 10.6.2 (Snow Leopard) and Tat's 2.0.0-pre1(273) - Mac OS 10.4.11 and Tat's 2.0.0-pre1(273) Anyone know what's going on? Thanks, Peter-- 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
Re: [Flightgear-devel] Bugs: b1900d
Pete, Just as a point of reference - I've been shooting approaches recently with the 1900, and I can enter text in the AP boxes without issue. Did so yesterday enroute to EDDF. I do not have oscillations during turns, selecting new heading or not. As I do not use AP to shoot an ILS I've not seen the other issues. Peter --Original Message-- From: Pete Morgan To: FlightGear developers discussions ReplyTo: FlightGear developers discussions Subject: [Flightgear-devel] Bugs: b1900d Sent: Jan 22, 2010 3:01 AM ## AutoPilot Dialog The IAS and CRS text entry show floats instead on integers. This makes entering new text doffocult and determining current text sometimes impossible. eg CRS = 112.12 IAS=156.12 ## Heading hold On selecting a new heading, the aircraft oscillates throught the turn, until oscillating and getting more violent. Sometimes depending on speed it will crash the aircraft. ## Altitude Select Selecting a new altitude causes the nose to bounce a few times. ## ILS On the turn to final, there is oscillation just before it lines up with the runway. When the glide scope is captured, the aircraft jerks violently -- 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 Sent from Smooth Water Sports, your Malibu Boat Dealer -- 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] Bugs: b1900d
Hey Pete, I understand now what you're saying. You are correct, in the aircraft Flight Director you would not have a decimal point. This was a decision by the builder of that aircraft for FG use, it's not an issue with Flightgear. (And the builder likely just pathed the heading to the AP) FG's generic AP flys point to point, which is less than whole numbers. But, to solve your issue, when you first open up the AP dialog box you can change all the starting numbers to whole numbers. Then if you are using the left and right arrow buttons to change your course, everything will then remain as whole numbers. Keep in mind that as close the FG developers get towards a completely realistic experience, Flightgear is not Flight Safety International. The simulators here are a development from years of dedication by a number of people in an open source environment, and the cost to folks like you and me that use that simulator is the price of a computer and internet connection. On the other hand, Flight Safety (and other training facilities) has arguably the best full motion simulators on the market, and here's some old 2008 pricing if someone is fully qualified to add a type rating to your credentials - MD-87/88 Initial Type Rating, $10,500 B-737-200 Intitial Type Rating, $7,000 A320 Initial Type Rating, $12,200 Citation I/II/VII/Bravo Initial Type Rating, $11,040 Challenger 601 Initial Type Rating, $21,840 I think Flightgear is a great deal! Hope that helps, Peter On Jan 22, 2010, at 3:47 PM, Pete Morgan wrote: Peter Brown wrote: I guess I'm missing your point Pete. Please take a look at this snapshot and you cannot see that the CRS is clearly at 113.947, however only the .937 is visible. http://imgur.com/6vlVE I didn't know that the non integer numbers were accepted, or indeed edge cases where required. Should this be the case then the b1009d is the only autopilot that is correct, as none of the other present the .decimal part. Also looking at the flightdeck images of real aircraft, I have never observed a NAV Hold button for example with .decimals, they are all 0-360. The bug to fix is to show the integer only imho, and am trying to navigate the way through the nasal code to see where It occurs to fix it. kind regards pete The AP will hold 12.34, just like it will hold 156.12 IAS if you desire. If you are saying it should _only_ accept an integer, such as 12 and 156, than you are being too critical. As the pilot you can enter the integer you need. Peter On Jan 22, 2010, at 10:34 AM, Pete Morgan wrote: Peter Brown wrote: Pete, Just as a point of reference - I've been shooting approaches recently with the 1900, and I can enter text in the AP boxes without issue. Did so yesterday enroute to EDDF. Di you enter a heading of 12.34 degrees, no. My issue is that only integers are required, same as a real autopilot. I do not have oscillations during turns, selecting new heading or not. As I do not use AP to shoot an ILS I've not seen the other issues. Peter --Original Message-- From: Pete Morgan To: FlightGear developers discussions ReplyTo: FlightGear developers discussions Subject: [Flightgear-devel] Bugs: b1900d Sent: Jan 22, 2010 3:01 AM ## AutoPilot Dialog The IAS and CRS text entry show floats instead on integers. This makes entering new text doffocult and determining current text sometimes impossible. eg CRS = 112.12 IAS=156.12 ## Heading hold On selecting a new heading, the aircraft oscillates throught the turn, until oscillating and getting more violent. Sometimes depending on speed it will crash the aircraft. ## Altitude Select Selecting a new altitude causes the nose to bounce a few times. ## ILS On the turn to final, there is oscillation just before it lines up with the runway. When the glide scope is captured, the aircraft jerks violently -- 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 Sent from Smooth Water Sports, your Malibu Boat Dealer -- 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
Re: [Flightgear-devel] SoundSystem on MacOS
Erik, The sound on the MacOS does still have a glitch when changing views. If you have a good patch to try I'd be more than happy to test it. If you recall, its most typical in fly by or tower view, and if you adjust your viewpoint in any direction the sound is corrected. It will never happen in cockpit view, and rarely in chase or helicopter views, but is regular in the rest. Peter --Original Message-- From: Erik Hofman To: FlightGear developers discussions ReplyTo: FlightGear developers discussions Subject: Re: [Flightgear-devel] SoundSystem on MacOS Sent: Jan 20, 2010 9:02 AM Erik Hofman wrote: I have read a report an bad doppler for MacOS then asked for some information but got no reply. If this problem still persists could the MacOS users try this patch? Never mind this patch contains an error so I've put it in CVS. If it's wrong please tell me and I'll remove it again. Erik -- 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 Sent from Smooth Water Sports, your Malibu Boat Dealer -- 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] Nominations for Aircraft Selection in theFlightGear 2.0 Release
I'll place a vote after some thought, but I'd like to mention there are a few aircraft that don't really fit the existing categories, but yet are excellent aircraft to represent FG. - Large multi-engine (or historic airliner) : Lockheed L1049h Constellation - Seaplane : Grumman Goose (there's more to this aircraft than meets the eye, and it shouldn't compete with the excellent Beaver) - Carrier Aircraft : T-2C or F-4N (while the F-14 is carrier capable, Dave Culp has some excellent aircraft that don't fit the omnipowerful jet fighter category) I'm sure keeping the number to 14 isn't an easy choice. Peter Sent from Smooth Water Sports, your Malibu Boat Dealer -Original Message- From: Durk Talsma d.tal...@xs4all.nl Date: Sun, 17 Jan 2010 14:09:47 To: FlightGear developers discussionsflightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Nominations for Aircraft Selection in the FlightGear 2.0 Release Hi All, It looks like this is becoming a bit of an annual tradition: With each new major release, we are evaluating which aircraft we wish to highlight by including them in the base package. Due to time constrains, we have fallen a bit behind with the release process this year. Nevertheless, the process is still in motion, and we expect a release real soon (I've mentioned a target date to the people directly involved, but just to keep the tension on, I'm not yet going to announce that publically yet :-) ) Just as a reminder: Last year's FlightGear 1.9.1 came out with the following selection of aircraft: Airliner: Boeing 777-200 World War II Fighter: A6M2 Zero Small TurboProp : b1900d Helicopter : bo105 Small Prop : Cessna 172p Small Business Jet : Cessna Citation X Ultralight : Moyes Dragonfly Aerotowing Capable / Seaplane : DeHavilland Dhc2 Omnipowerful Jet Fighter: F-14b Light Prop : Piper j3cub Light Twin Prop : SenecaII Historic Warbird: Sopwidth Camel Not of this Earth : UFO Airship : Zeppelin-NT Generally, I think that this is a pretty cool selection, but a lot of aircraft development has been going on last year, so there are probably a few of the existing aircraft that we might want to swap. In particular the airliner has seen a lot of development, and I know that Syd Adam's wasn't too thrilled about having the Boeing 777-200 in the base package last year. Please note that we want to keep the selection down to approximately the same number as we have now (which is 14), and have each of the current categories represented. So, basically if one new aircraft enters the base package, an existing one should go. Let the votes begin. :-) Cheers, Durk -- 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 -- 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] Nominations for Aircraft Selection intheFlightGear 2.0 Release
As Syd (and others) changed their license, does that remove the b1900, Beaver, and others from the list as well, or do those fall under a grandfather clause? Sent from Smooth Water Sports, your Malibu Boat Dealer -Original Message- From: Heiko Schulz aeitsch...@yahoo.de Date: Sun, 17 Jan 2010 22:01:05 To: FlightGear developers discussionsflightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Nominations for Aircraft Selection in theFlightGear 2.0 Release Hi Peter, I'll place a vote after some thought, but I'd like to mention there are a few aircraft that don't really fit the existing categories, but yet are excellent aircraft to represent FG. - Large multi-engine (or historic airliner) : Lockheed L1049h Constellation - Seaplane : Grumman Goose (there's more to this aircraft than meets the eye, and it shouldn't compete with the excellent Beaver) - Carrier Aircraft : T-2C or F-4N (while the F-14 is carrier capable, Dave Culp has some excellent aircraft that don't fit the omnipowerful jet fighter category) I'm sure keeping the number to 14 isn't an easy choice. Peter Sent from Smooth Water Sports, your Malibu Boat Dealer I'm sure it is easy, then the aircrafts has to be: -under GNU GPL to fit into the Base package (So David Culp's aircrafts can't be included) -in CVS already - the Lockheed Lockheed L1049h (the h-version!)is not yet included into CVS! My problem is the airliner part. The 777 hasn't been updated since Syd decided to change the licence. And the AP isn't working anymore in CVS-version. I don't see any alternatives. The 737-300 is still WIP and has only the old 2d-panel working. The 787 hasn't been updated as well in CVS. The A380 hasn't been updated in CVS. Maybe the 747-400, but this is still WIP, and not yet really functional compared to the other aircrafts in the base package. I vote for No Airliners for this release! Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- 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 -- 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] Some bugs
On Dec 24, 2009, at 4:33 AM, Erik Hofman wrote: Peter Brown wrote: -the sound is fine in the cockpit and a few views, but from the tower viewpoint (listen to a flyby) and from the model viewpoint (I think there are 3 actually), the sound is corrupted. While I don't know why, what I did discover was if you moved your location one step in any direction (up or down, left or right), the sound returned to normal. This is one step from the default viewpoint, such as tower, model, fly-by, etc. I don't notice this behavior: what version of OpenAL are you using and could you describe 'corrupted' some more? Erik Erik, if you point out a path to me I'll look, but I don't know where to look to check the version of OpenAL. The CVS I'm using was compiled by Tat on the Mac FG site he hosts. If I could describe more accurately I would say that it sounded like the hz was way off, so instead of a recognizable sound wav it is more of a ugly solid tone. If you are using the tower viewpoint and the a/c flys by, the tone still changes as it goes by, but from one solid tone to another. Thanks, Peter -- 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] Some bugs
On Dec 24, 2009, at 5:14 AM, James Turner wrote: On 24 Dec 2009, at 06:36, Peter Brown wrote: -the route manager sometimes will open with 36000 feet in the hold altitude box, and 7240 kts in the hold speed box. Any attempt to change them will default back to these amounts. I am trying to see if relates to any particular aircraft, but to date it's been pretty random. That is very odd, some uninitialized values or similar. Though 36000 is a bit specific. Is it always these exact values, each time? Anyone else ever seen this? Regards, James James, First off, (it was late last night) let me correct my statement. I am referring to the generic autopilot, not the course manager. It does not seem to have any correlation to the course manager. I'm finding it more specific. Example A - Aircraft : AD-6, F-4N, A-3D, RA-5 Airport : KGFL Runway : 30 Heading bug : 130.94 True Heading : unreadable due to it flipping. Click on the box and sometimes I will get 116.835, the other times I can get 344.532 Alt Hold : 18 - This is unchangable Speed Hold : 120 - This is unchangable I'm not flying each model right now, but previously all other parameters would work (wing leveler, pitch hold, VS hold, etc) So I was thinking it was a jsb relation, but then I tried these same aircraft at KPBG and they work fine. Can it be a navaid issue? The issue will carry forward with you. If you change airports using the location menu, the issue will stay, but the numbers will change. If you quit and restart at another airport (that doesn't have an issue such as KPBG) then it works fine. I just tried Gary Buckaroo Neeley's new MD-81, which is a very good yasim fdm but has no other interference as a test bed, and it displays the same data issues in Autopilot. Seems like random airports where this shows up. KBGR and KPBG it works fine, but KALB it's there. KALB Aircraft : dh2w, MD-81, 777-200ER Heading bug : 114.421 True Heading : 265.842, or 100.613, depending when you click the box. Alt Hold : 18, unchangable Speed hold : 120, unchangable So that's interesting - the Beaver and MD-81 has no autopilot, and while I don't fly the 777, I assume it does(?). Hope that helps, Peter -- 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] Some bugs
On Dec 24, 2009, at 11:37 AM, Peter Brown wrote: On Dec 24, 2009, at 5:14 AM, James Turner wrote: On 24 Dec 2009, at 06:36, Peter Brown wrote: -the route manager sometimes will open with 36000 feet in the hold altitude box, and 7240 kts in the hold speed box. Any attempt to change them will default back to these amounts. I am trying to see if relates to any particular aircraft, but to date it's been pretty random. That is very odd, some uninitialized values or similar. Though 36000 is a bit specific. Is it always these exact values, each time? Anyone else ever seen this? Regards, James James, First off, (it was late last night) let me correct my statement. I am referring to the generic autopilot, not the course manager. It does not seem to have any correlation to the course manager. I'm finding it more specific. Example A - Aircraft : AD-6, F-4N, A-3D, RA-5 Airport : KGFL Runway : 30 Heading bug : 130.94 True Heading : unreadable due to it flipping. Click on the box and sometimes I will get 116.835, the other times I can get 344.532 Alt Hold : 18 - This is unchangable Speed Hold : 120 - This is unchangable I'm not flying each model right now, but previously all other parameters would work (wing leveler, pitch hold, VS hold, etc) So I was thinking it was a jsb relation, but then I tried these same aircraft at KPBG and they work fine. Can it be a navaid issue? The issue will carry forward with you. If you change airports using the location menu, the issue will stay, but the numbers will change. If you quit and restart at another airport (that doesn't have an issue such as KPBG) then it works fine. I just tried Gary Buckaroo Neeley's new MD-81, which is a very good yasim fdm but has no other interference as a test bed, and it displays the same data issues in Autopilot. Seems like random airports where this shows up. KBGR and KPBG it works fine, but KALB it's there. KALB Aircraft : dh2w, MD-81, 777-200ER Heading bug : 114.421 True Heading : 265.842, or 100.613, depending when you click the box. Alt Hold : 18, unchangable Speed hold : 120, unchangable So that's interesting - the Beaver and MD-81 has no autopilot, and while I don't fly the 777, I assume it does(?). Hope that helps, Peter James, 3 more notes - At KJFK in either Gerard's Fouga Magister, or the Senecall - these are more typical numbers that I referred to initially. Heading Bug : 249.177 True Heading : 236.009, but every few seconds it jumps to something else and then comes back. Can't click it fast enough to catch the other heading. Alt hold : 36, unchangeable. This is the most common number - 36 or 36000. Speed hold : 8246. unchangeable. This is the most common number here - 7246 or 8246. At KJFK in the KC-135 Heading bug : 249.165 True heading : 235.997 or 275.767, this one jumps just long enough to click and catch the 275.767 - otherwise unchangeable. Alt hold : 36, unchangeable. Speed hold : 8245. unchangeable. Peter -- 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
[Flightgear-devel] Some bugs
Passing along some random information in case anyone recognizes the issues. In a CVS from 12/13 - -all starts show a spawn location off the coast of Nigeria, quite often with a different call sign, and the google we don't have imagery for zoom at this level default. If you zoom out you find the location, and then the a/c symbol disappears. If you refresh the browser your call sign will show up in the correct location. This happens every time, without fail. Once refreshed it works fine. -the sound is fine in the cockpit and a few views, but from the tower viewpoint (listen to a flyby) and from the model viewpoint (I think there are 3 actually), the sound is corrupted. While I don't know why, what I did discover was if you moved your location one step in any direction (up or down, left or right), the sound returned to normal. This is one step from the default viewpoint, such as tower, model, fly-by, etc. -the route manager sometimes will open with 36000 feet in the hold altitude box, and 7240 kts in the hold speed box. Any attempt to change them will default back to these amounts. I am trying to see if relates to any particular aircraft, but to date it's been pretty random. Hope that helps - Peter -- 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] Generic autopilot issues
James, From what I've read, and like the original, your route manager uses the airport center point as the destination. What is the reason for selecting a runway? If the destination point is center-runway of the specified runway, I'm not sure of the benefit over center-airport. Like you mentioned I would tend to break off to enter a manual approach. An option to consider : At the moment if I were to choose a runway, my preference would be to have the destination point be the turn-in point for an ils approach, for both ils equipped and non- precision approach equipped airports. (The documentation would need to reflect the difference in points so the user realized it) Just a thought- Peter Sent from Smooth Water Sports, your Malibu Boat Dealer -Original Message- From: James Turner zakal...@mac.com Date: Tue, 22 Dec 2009 14:10:25 To: FlightGear developers discussionsflightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Generic autopilot issues On 21 Dec 2009, at 18:55, Curtis Olson wrote: What do you think would be a sensible course of action, in the situation you describe? Even if I choose not to add the departure airport for in-air route activation, there's no guarantee that the first route waypoint is where you actually want to be going. Conceptually, including the starting point in the route seems like it could always be problematic.The airport location is some random point on the airport grounds (probably the average of the center points of the runways.) Even if you haven't taken off yet, it would be possible in some circumstances to not fly close to the center of the airport on take off. Then you would get routed back to the starting point before you could continue on to the next way point. I think we are just getting lucky when we fly close enough to the center of the airport in most situations for most runways to satisfy the route manager and it clicks on to the next waypoint. The KSFO airport layout is very friendly in this regards, but other airports like DFW and DEN are more sprawling. That's really an orthogonal issue - I only use the airport location if you neglect to specify a runway. For using these features as a flight planning tool, the first waypoint is my departure runway, which sequences when you cross the threshold / midpoint (not perfectly, I have a known bug to fix in that area). Adding the *destination* airport as a waypt seems useful, even if no runway is selected, because it yields a useful trip distance estimate (and hence, ETA), and I assume people can thus navigate to the vicinity of their destination, and conduct whatever kind of approach they like. A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation I'll do these today (hopefully) - I already fixed the GPS - autopilot drive, and have been doing some reading and testing with the generic autopilot XML, dialog and code. There's quite a few things behaving strangely (especially in the Alphajet), and I don't think most of them are my fault - famous last words! - but I'm getting to grips with it. Will post back here once I have some more definite conclusions, especially regarding why heading hold is being so strange. Incidentally, the PID parameters in the generic autopilot are pretty bad for the alphajet (and many other aircraft, I guess). It'd be lovely if there was a way to tune the response rates for a particular aircraft, but still inherit the basic controller structure (i.e the control laws) from the generic definition. I don't suppose the Autopilot XML loading code could cope with that? 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
[Flightgear-devel] TaxiDraw
Three quick TaxiDraw questions for someone in the know - There is no information in the TaxiDraw wiki regarding runway and taxiway smoothness, but there is a roughness box as a surface parameter in Taxidraw. I am trying to determine if this is on a 0-1 range, as I have only seen existing values of about .25. The second item is that it does not appear to accept roughness data for taxiways or aprons, only runways. Anyone know if this is true, and if so, can it modified to accept a rough taxiway surface? The last question is regarding TaxiDraw itself. I was told that the WED.app would not work with FG due to FG not being able to recognize curved shapes (and perhaps more?). Although TaxiDraw is a great simple tool, it lacks functions and tools for efficient design speed. I assume it's a very low priority, but at best I'm looking to entice additional airport use from the users and at minimum correct the layouts. Does anyone know what the future holds for this? Thanks, Peter Brown -- 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] Autopilot broken, Eric maybe?
One note on using route manager - in a 12/13 CVS - if includes the departure airport as a waypoint automatically. If you activate it on the ground it will move past it on the takeoff roll and proceed to the next waypoint. If you don't activate it until in the air it will circle back to the departure airport as the first waypoint. Peter On Dec 21, 2009, at 12:17 PM, James Turner wrote: On 21 Dec 2009, at 16:33, Heiko Schulz wrote: There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. I think James can tell more! The issue / feature here is that the route-manager code has 'always' (for years, at least) directly set /autopilot/settings/true-heading-deg based on its internal route-following logic. Personally I don't think it's a great feature, but people do use it (the route manager) in conjunction with the generic autopilot dialog to quickly navigate between waypoints. When I broke the feature by accident, it was noticed, and people asked for the feature back. As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? 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] Autopilot broken, Eric maybe?
James, this is what I've found too. Perhaps I don't understand the proper setup method, but I tend to clean it up as well. Sometimes I get a FL value, others times the point adds with a zero altitude. (or two dep. airport waypoints, one with each altitude) It may be a result of most times the route manager loads with the departure airport already listed. For the time being configure it to not load a depature airport on opening? Peter On Dec 21, 2009, at 1:51 PM, Curtis Olson wrote: On Mon, Dec 21, 2009 at 12:43 PM, James Turner zakal...@mac.com wrote: It is not my intention, or expectation, that many aircraft should need to be changed at all. Aircraft that used the old gps or route-manager directly will need changes (eg, the 787, and Concorde INS code, but that's non-functional anyway) but my *intention* was always that most aircraft, whether using the generic autopilot, or a customised XML autopilot, would work exactly as before. With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Hi James, The one aircraft I enjoy flying is the Alphajet ... that uses the generic autopilot/route manager system. My one comment with the new route manager is that I've had some variability in the results of building a route. Maybe I'm not understanding the interface correctly, but sometimes my starting airport gets added, even when I'm in the air. Sometimes it gets in there twice. After creating a route, I always need to go in and manually clean up extraneous stuff before I get what I hoped for. (Sorry for using the word always, maybe I should say I feel like I always have to go fix the route manually.) :-P Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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] --metar and --enable-real-weather-fetch
As a separate issue: With rare exceptions, the largest visibility you will see reported in a metar is 10SM (in the US) or (meters, elsewhere). This is a problem for real-weather fetch, because the _reported_ visibility can be significantly less than the _real_ visibility. I have tried to think of a heuristic to solve this problem, without success. Sometimes a report of 10SM means 10SM and no more, but sometimes it means unlimited visibility. [...] The FG scenery looks nice when the visibility is unlimited. It would be a shame to stumble into a situation where typical users were stuck with 10SM visibility instead of the really real visibility. [...] The bold solution would be to map 10SM and meters to unlimited visibility ... but I'm not bold enough to recommend that. From a users viewpoint, 10SM on a monitor looks like less to the eye than 10SM looking out the window. It would be a disservice to the scenery to run the risk of unlimited visibility being presented as 10SM. IMHO there is no choice other than the bold solution- anything reported as 10SM = unlimited, and 9.99 and less is actual. Peter Brown Sent from Smooth Water Sports, your Malibu Boat Dealer -- 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] --metar and --enable-real-weather-fetch
I'll take a look at those links, thanks. My impression is that a good percentage of users are not to the point of using metar, and apparently may use unlimited all the time. I don't know if there is any data to support that, but I've not seen a low frame rate outside of ksfo. Of the other hand its a way to weed out the gamer... Just thoughts I'm sure were considered before. Peter Brown --Original Message-- From: Melchior FRANZ To: flightgear-devel@lists.sourceforge.net ReplyTo: FlightGear developers discussions Subject: Re: [Flightgear-devel] --metar and --enable-real-weather-fetch Sent: Dec 20, 2009 4:38 PM * Peter Brown -- Sunday 20 December 2009: IMHO there is no choice other than the bold solution- anything reported as 10SM = unlimited, and 9.99 and less is actual. And so guaranteeing the lowest possible frame rate? Sounds like a truly bad idea. The whole thing has been discussed before. (Threads Flying over an island and Estimating visibility). Thomas FOERSTER announced that he'd use some Bayesian analysis to get a formula from various available parameters, such as temperatures, air pressure etc. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15710.html http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15843.html http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15851.html In any case, if someone writes a heuristic, then this does *not* belong into SGMetar but FGMetar. Unless the weather subsystem is the next which is going to be ruined ... m. -- 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 Sent from Smooth Water Sports, your Malibu Boat Dealer -- 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] --metar and --enable-real-weather-fetch
I was not suggesting that FG did want to weed anyone out, but as someone new to the list, I'm gaining knowledge and a better viewpoint with each discussion. I appreciate your response Melchior, and I hope you don't take my responses as being arrogant. Peter --Original Message-- From: Melchior FRANZ To: flightgear-devel@lists.sourceforge.net ReplyTo: FlightGear developers discussions Subject: Re: [Flightgear-devel] --metar and --enable-real-weather-fetch Sent: Dec 20, 2009 5:18 PM I had looked at some research papers at that time, which were about estimating visibility from other, measurable factors. I stopped when Thomas announced his solution. My original idea was a simple formula, based on the idea that: - visibility is derived from humidity (high humidity - low visibility due to water drops) - higher temperature decreases visibility (molecule movements) - higher wind speeds decrease visibility (more dust blown up) - higher AGL increases visibility (no dust) - smog was hard to estimate, as there was no reliable way to find out if there are bigger cities nearby (checking for distance of next airport with concrete runway of a certain minimum length might work); ground material might have an influence, but isn't very reliable All that would have to consider that METAR is weather at station level. This wouldn't have to be very accurate. Simple variability was already an improvement, while randomness was not acceptable (same weather should yield same visibility for MP or sync'ed machines). * Peter Brown -- Sunday 20 December 2009: Of the other hand its a way to weed out the gamer... One of FlightGear's main goals is realism, not to weed out *any* kind of user. Maybe you are wrong here?! m. -- 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 Sent from Smooth Water Sports, your Malibu Boat Dealer -- 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] Braking Power - rate of deceleration
Hi Ron, I did find the bindings and nasal properties as you mentioned here, but thank you for the additional explanations. For the time being I'm going to look at some more normalized braking forces per aircraft based on the following criteria. - individual aircraft average landing weights per mfg specs. - mfg published runway landing distances, per std FAR's (3 degree glideslope over 50' obstacle) - FG user using keyboard braking One thing I may ask about as well is the ability to write a rain condition into it, with reduced braking effect. Most mfg's publish landing distances for both wet and dry surfaces. What I don't know is if you can extrapolate rain from live metar or not. If I find that it can be accomplished with a little time per aircraft than I may just post it in the forum as available for users to add on if they like, or show them how to adjust it for their favorite models. Peter On Dec 19, 2009, at 11:41 AM, Ron Jensen wrote: Peter, Brakes are applied (like most controls) by setting the correct properties in /controls, in this case controls/gear/brake-left controls/gear/brake-right and controls/gear/brake-parking. Most of these properties are normalized so 0.0 = 0% braking and 1.0 = 100% braking. The keyboard b key sets both brakes to 1.0 in 1/2 second. The , and . keys individually set left or right brakes to 1.0 in 1/2 second. This 1/2 second value may be changed by editing $FG_ROOT/Nasal/controls.nas. Look for, and edit, the line that says var fullBrakeTime = 0.5; See also: http://wiki.flightgear.org/index.php/Property_browser http://wiki.flightgear.org/index.php/Property_Tree The amount of braking force per wheel can be adjusted per aircraft in the flight dynamics model (FDM) for that aircraft. This is a deep and complex subject, though. Ron -- 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 Peter Brown FG Farmboy -- 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] Braking Power - rate of deceleration
Even better. Thanks Ron, I'll take a look at that. Peter On Dec 19, 2009, at 12:57 PM, Ron Jensen wrote: On Sat, 2009-12-19 at 12:07 -0500, Peter Brown wrote: Hi Ron, I did find the bindings and nasal properties as you mentioned here, but thank you for the additional explanations. For the time being I'm going to look at some more normalized braking forces per aircraft based on the following criteria. - individual aircraft average landing weights per mfg specs. - mfg published runway landing distances, per std FAR's (3 degree glideslope over 50' obstacle) - FG user using keyboard braking Controlling the amount of braking applied from the keyboard may be a good thing, however some joystick bindings do interesting things to the brakes to give differential braking effects. I actually have two axises assigned as toe brakes on my rudder pedals. Point being this won't be a generic solution. One thing I may ask about as well is the ability to write a rain condition into it, with reduced braking effect. Most mfg's publish landing distances for both wet and dry surfaces. What I don't know is if you can extrapolate rain from live metar or not. Simulating braking coefficients by limiting /controls/gear/brake-* isn't the best way to go. For JSBSim aircraft static friction coefficients for each gear can be adjusted on the fly by changing fdm/jsbsim/gear/unit[*]/static_friction_coeff. I'm pretty sure yasim has something similar... If I find that it can be accomplished with a little time per aircraft than I may just post it in the forum as available for users to add on if they like, or show them how to adjust it for their favorite models. Peter Ron -- 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 Peter Brown FG Farmboy -- 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] Braking Power - rate of deceleration
Ron, Take a look at this and see if you think this would be a good route to go with this. The time and subjective part of course is the number of landings needed to dial in the aircraft model. Mfg reports that I am aware of seem to publish landing distances on both dry and wet surfaces using a std FAR approach (50' ht over threshold, 3 degree slope, published weight, and a Vapp=1.3Vso) - Once I have flown enough landings to determine bp (braking power) and wbp (wet braking power) percentages of the FG base 1 value that closely matches the published figures, put that in a formula including metar rain and snow. I don't know how to code it yet, but this is the formula in laymen terms. (built on a single weight basis) These are the parameters from a yasim fdm. gear/gear[1]/gear-friction-factor='x'(float), where as: x = BP-((BP-WBP) * (greater value, rain-norm or snow-norm or snow-cover)) gear/gear[2]/gear-friction-factor='x'(float), where as: x = BP-((BP-WBP) * (greater value, rain-norm or snow-norm or snow-cover)) /environment/metar/snow-cover='false'(bool) (assuming snow-cover=True to have value of 1, or no braking ability) /environment/metar/rain-norm='0'(double) /environment/metar/snow-norm='0'(double) Example : If : Test results for dry surface = .750 Test results for dry surface = .500 Metar Rain-norm value = .675 Metar Snow-norm value = .110 Metar Snow-cover value = false Then: /gear-friction-factor= .750-((.750-.500)*.675) So braking power applied to model: /gear-friction-factor=.58125 If it works then the file could be used for any model, once the wet-to-dry braking range is found, which as mentioned would be the most time consuming and somewhat subjective part. Peter On Dec 19, 2009, at 12:57 PM, Ron Jensen wrote: Simulating braking coefficients by limiting /controls/gear/brake-* isn't the best way to go. For JSBSim aircraft static friction coefficients for each gear can be adjusted on the fly by changing fdm/jsbsim/gear/unit[*]/static_friction_coeff. I'm pretty sure yasim has something similar... Peter Brown FG Farmboy -- 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
[Flightgear-devel] Braking Power - rate of deceleration
Hey all. Does anyone know of a way to provide more realistic braking power? The deceleration rate seems to be an across-the-board-standard between all aircraft, and from a user point of view I'm not sure it takes weight, mass, or any other physical attribute into account. All I know is if you pushed your toes into the firewall hard enough to slow down that fast, the tires would either shred or catch on fire. I've looked around for a way to apply partial brakes, even such as bindings for b to apply 50% brakes, and Ctrl b can apply 100% brakes. But with my limited knowledge I can't find what provides the brakes to begin with. Has this been discussed before? Thanks, Peter Peter Brown FG Farmboy -- 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] Glide slope (ILS) range
Worrying about GS service volume seems off-scale unimportant relative to other issues. For starters, Stansted has a reversible ILS. The code to handle reversible ILSs in FG has been broken for years, and actually got worse recently. The code to make it possible to fly at airports with reversible ILSs has been available for a long time. From a user's point of view, and don't this wrong for I'm not sure of the long term goals, but if success includes attracting users and retaining them then the little details such as this will enhance that aspect more than some other things. Realistic flight performance, including operations within the airport radius are typically high in value to a user. This isn't to take the side of someone complaining about not getting the glideslope at full volume until 7 miles, he should be well on his way with a standard decent rate out of the turn point. I think the 10 mile minimum should work fine, until it gets enhanced to extend to a trickle out point, which is the ideal. (And often 20 miles) Is there a published list somewhere of the major issues that the developers contributors are striving to correct, enhance, add, etc? Thanks, Peter Peter Brown FG Farmboy -- 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] --config nav.dat
To further that thought, I'd like to request dates added above the first line of airport data in each apt.dat file. I've tested info lines added to my apt.dat file and CVS FG has not had any issue reading the data. I do need to verify older versions will be able to still access it correctly. !--Updated layout 12/18/09, Peter Brown -- In revising taxiways and layouts I find it to be helpful, and feel it may be in this case as well. Thanks, Peter Sent from Smooth Water Sports, your Malibu Boat Dealer -Original Message- From: syd adams adams@gmail.com Date: Fri, 18 Dec 2009 16:42:45 To: FlightGear developers discussionsflightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] --config nav.dat Maybe we could add a KSFO.dat , KHAF.dat, etc, somewhere in the Scenery/ section as a start... Its something I've always hoped for , anyway :) Cheers On 12/18/09, John Denker j...@av8n.com wrote: Extended LOC volumes are fairly common. Extended GS volumes are not so common, but definitely exist. If anybody wants an example of an approach that does require an extended service volume for the GS (and LOC) ... take a look at KIAH ILS RWY 26R http://204.108.4.16/d-tpp/0912/05461IL26R.PDF === The interesting wrinkle is that the current FG apt.dat does not know that these navaids have extended service volumes. 4 30.00716100 -095.36220300 91 11155 18 269.949 IOND KIAH 26R ILS-cat-III 6 30.00828100 -095.33396100 91 11155 10 300269.949 IOND KIAH 26R GS 12 30.00599400 -095.36231900 84 11155 18 1.700 IOND KIAH 26R DME-ILS From time to time I hear someone recommend let Robin take care of it upstream. That's fine as a long-term strategy, but it doesn't work in the short term, especially given how rarely FG updates its copy. Also it is inconsistent with the way FG handles other things, notably the very powerful --config option that can be used on the command line or in the .fgfsrc file. AFAICT the --config option is presently not, alas, powerful enough to update the navaid database. Suggestion: It would be nice to have a configurable _list_ of filenames to scan for navaid data: nav.dat nav-2.dat et cetera. That way users could maintain short supplemental files that would a) tide them over during the oh-so-long time that it takes to get updates into the official nav.dat b) preserve the supplemental information across updates of the official file. c) not require the user to unpack and edit the big official file. Conventional patch utilities do not perform well on this task. Some cleverness needs to be applied to distinguish the case where a navaid is being _replaced_ versus the case where a navaid with a similar name is being simply _added_. A simple + and - convention should suffice. Similar remarks apply to apt.dat but that's more complicated. I haven't thought about the details. Adding and subtracting on an airport-by-airport basis (as opposed to line-by-line) would be better than nothing. -- 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 -- 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] Curt's airfield with dual view fron the rascal
I would assume he must be on the FG-devel mailing list? Peter Peter Brown FG Farmboy On Dec 17, 2009, at 10:35 AM, Martin Spott wrote: Alexis Bory - xiii wrote: http://flightprosim.com/screenshots/SNAG-0281.jpg In the meantime the link has already been replaced with another screenshot - still based on copyrighted material Holy cow, I'm impressed to see this guy is managing to to drop one clanger after another :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
