Re: [Flightgear-devel] reviews etc.
On Wednesday 18 October 2006 22:27, Andy Ross wrote: Lee Elliott wrote: Melchior FRANZ wrote: Weird: http://cgi.ebay.com/FLIGHTGEAR-2006-PROFESSIONAL-AVIATION -FLIGHT-SIMULATOR_W0QQitemZ160036333084QQcmdZViewItem It is actually FlightGear - this person appears to have re-packaged FG i.e. basic system with most of the more complete aircraft included i.e. I found no mention that this stuff is covered by the GPL or if the source-code is included/available, which I believe is a requirement of the GPL. This subject came up on IRC a few days ago. I sent the guy a nice email explaining the requirements, and pointing out that the easiest way to do this is to explain in the auction that this is an open source project hosted at www.flightgear.org. He replied that he already includes the source code and GPL in the package, but that he would be happy to add a flightgear.org link to the auction. I haven't gone back to check. There's actually nothing wrong with selling free software for money, so he's basically fine. It's just slightly misleading to do so without explaining that it is also freely available. Andy If he's complying with the GPL by including the source and a copy of the GPL then, as you say, he's perfectly entitled to sell it. It was because the of way and style that he presented the packages that made me a bit suspicious. Also, I'm not so sure about re-naming it FlightGear 2006 Professional As FG is still at version 0.9 and the consensus of the developers seems to be that FG isn't ready for a Vn 1.0 release yet, having someone selling it as the 'latest' professional version might not do the project's reputation any good. Personally, it doesn't bother me too much as I just use FG to experiment and play with, and then offer whatever results I come up with to the project, to do with as it pleases. The only thing that slightly bothers me about someone passing off any of my work as part of a FlightGear 2006 Professional package is that I don't consider any of my work to be of commercial quality and I wouldn't want anyone else to think that I did so. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reviews etc.
On Tuesday 17 October 2006 18:23, Melchior FRANZ wrote: [snip...] Weird: http://cgi.ebay.com/FLIGHTGEAR-2006-PROFESSIONAL-AVIATION-FLIG HT-SIMULATOR_W0QQitemZ160036333084QQcmdZViewItem m. It is actually FlightGear - this person appears to have re-packaged FG i.e. basic system with most of the more complete aircraft included i.e. Boeing 737-300 Cessna 172 Cessna 310 F-16 Hawker Hunter Messerschmitt BF-109 Piper J-3 Cub Piper Cherokee Warrior II P-51D Mustang Rascal 110 Northrop T-38 1903 Wright Flyer Then there's a separate disk of the remaining aircraft from the FG downloads page and several disks of scenery. One of the screen shots show the old photographic texture for KSJC and I also noticed that FlightGear 2006 Professional is Designed for Windows 95/98/NT/2000/ME/XP Operating Systems I found no mention that this stuff is covered by the GPL or if the source-code is included/available, which I believe is a requirement of the GPL. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] obj-ac conversion question...
On Tuesday 19 September 2006 14:10, Jeff Koppe wrote: Hi All, I've been making/texturing a aircraft model in Wings3d, exporting to .obj and using Blender to convert to .ac. But since either the Blender .obj import or .ac export is not perfect, this workflow requires some tweaking of the final .ac file. So I figured I'd cut out the middleman and write a Ruby script to convert .obj to .ac. Now the question: neither .obj nor .ac formats specify three or four sided polygons. Does FlightGear? Blender does (imperfectly) triangulate/quadrangulate the model but I'm not sure why--I imagine it's a holdover from .3ds format. If FlightGear does not _require_ triangulation, then is it more efficient? Thanks, --jeff Heh:) I cobbled together a rough C prog to convert .obj geometry in to .ac format but I didn't look into the texturing aspects because all I wanted was the geometry. It became redundant when I got the .obj importer for ac3d. Afaik both .obj and .ac formats support n-sided polys whereas I believe that the .3ds format only uses triangles. Everything I've ever exported in .3ds format has been converted to tris. I don't know if using polys with 3 sides is more efficient but the most important consideration is that a triangle will always be perfectly flat whereas polys with 3 sides may not be because all the points don't have to be in the same plane. The renderer that FG uses actually converts all polys into tris and this means that a curved poly, where the points are not all in the same plane, can be interpreted, or split into two tris, in two different ways, producing entirely different surface shapes. Imagine a four-sided poly with it's vertices at: (hope this looks ok) (A)0,0,0(D)1,0,0 (B)0,1,0(C)1,1,1 If this poly was split into two tris by adding an edge between B and D the path between them would be straight but the path between A and C would be curved. However, if you put the edge between A and C instead then the path between B and D would be curved instead, changing the shape of the poly completely. Afaik the renderer decides on how to split n-sided polys into tris is based on the vertex order and this can sometimes produces rendering glitches where it curves a poly in the wrong direction (or at least not the direction intended by the modeller). Ways around this are to either re-order the vertices or manually split the poly into tris. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Problems with 2d panel instruments
Hi all, after updating from cvs a couple of days ago I found that all the 2d instruments I use for displaying info appear to be cropped into the top left hand corner and are now unreadable. Anyone else seeing this? I suspect it's something to do with 're-sizing' them in the panel.xml file - i.e. the sizes in the individual instrument .xml files may different to those used in the panel.xml file Instruments that have action entries don't seem to be affected and I know I have to use a different origin to get the hotspots in the right place. Any ideas anyone? LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YASim feature request
Probably one for Andy... I've been messing about with the B-52F and I've hit a problem with landing in cross-winds. The real a/c has steering on both front and rear sets of wheels so that it can make a crabbed landing and this is where the first aspect of the problem lies - there only seems to be a single STEER control axis available. The second aspect of the problem is that I can't find a reference property to use. Perhaps there's already something there and I'm not aware of it but even if there is, how would I relate it to the normalised steering control input? Basically, I think I need to know the yaw-degrees and be able to set two independent steering control axis in degrees. Actually, I guess a yaw-norm would work ok with two steering-norms... LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view change crashes
On Wednesday 23 August 2006 03:45, Curtis L. Olson wrote: [snip...] For what it's worth I can reliably trigger this bug by running: fgfs --airport=N59 Once FG starts up, hit the v key to switch to the outside view. This seems to trigger the bug every time. Thanks, Curt. Just tried it here and couldn't reproduce this problem. Tried fgfs --airport=N59, a different a/c and also starting at KSFO and then re-locating there. about a week old cvs... LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VRP for Rascal110
On Sunday 20 August 2006 22:53, Martin Spott wrote: To Lee and/or Curt: After our guest we had this evening asked me to take his new model airplane out for a ride, I decided to check with the FlightGear Rascal to renew my feeling for these small aircraft as I didn't fly any model aircraft for more than twenty years. I noticed that the aerodynamical center is located at the nose of the Rascal 3D-model - the aircraft rotates around its nose-feature we already saw with several other aircraft. Would one of the authors consider to move the VRP to the respective location where it makes most sense ? Thanks a lot - I never expected that I some day would be tempted to use FG as a model airplane trainer :-) Martin. I only did the model for Curt, who did all the rest, so I'll leave it to him unless he's too busy, in which case I can take a look. Curt? LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] B52 around the earth flight
On Monday 14 August 2006 23:12, Julien Pierru wrote: I successfully flew around the earth with the B52, following the historic flight flown by 3 B52 in January 1957. It took me around 40 hours and 6 air to air refueling from a KC135 flown by shavlir to make it. Only the first 3 aar were unsuccessful due to non matching and oscillating speeds between mp aircraft. The remaining 3 were perfect and lasted about 20 to 30 minutes to refuel about 3/4 of the tanks. FG handled very well under the circumstances, no noticeable memory leaks, but a few things did break down. (made for a more realistic flight ;-P) For some reasons the 2D panel lost its lighting (red) over Hawaii and I was never able to recover it (landed without instruments in a pitch black night) and the property tree had a few nervous breakdowns as well, would stop updating for a while...Other than that it was awesome. You can see the path taken on FG tracker at: http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHTFLIGHTID= 4015 You might have to zoom out a bit on google map to see the track. there is a corrupted data point in there so you can't see the ground speed. I'll ask KoverSrac to remove that point. Here are some air to air refueling at dawn over Guam: http://fgfs.i-net.hu/modules/xoopsgallery/view_album.php?set_a lbumName=album32 Regards, Julien Well done :) nice pics too LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Abrupt wind visibility changes with real weather fetch
Hi all, it occurred to me that a relatively simple solution to the abrupt wind and visibility changes we get when using real weather fetch would be to write the 'fetched' data to an 'incoming' weather branch in the property tree and then use nasal listeners on each leaf to interpolate the values. If the interpolation time were to be based on the aircraft speed it would give interpolation over distance, instead of a simple interpolation over time, which would probably be a bit more realistic. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
On Tuesday 08 August 2006 12:08, Joacim Persson wrote: On Tue, 8 Aug 2006, Lee Elliott wrote: Thanks for posting this observation - this is clearly a bit wacky (not that accelerating w/o +energy wasn't) - can you reproduce it? Now that I tested it again, I saw however that the FF number didn't fall over from a high number to a negative, but decreased to zero first. Same goes for N1. But it happens quite suddenly. KSFO Fair weather, Noon. 2D mini-panel on. Full throttle (no AB, no flaps or slats). Take-off. Gear up and climb to 1000'. Bank 90° and pull the stick all the way back. After a while the engine sound suddenly changes to a low thunder and not only FF goes negative, but so does N1 and EGT. (I don't think N2 did though) Tank fills up and overfills quickly. FF is *very* negative. The number runs off-screeen. If you get too much altitude the phenomenon stops. Stay low; below 5000', at 1000' or so ...without crashing into anything -- which isn't that easy to avoid in 70G mach 3 turns. If you ease off throttle, you get the reported phenomenon with insane speed instead. (mach 8 and 300G). AoA seems to stay at about 16°. Apparently the magical energy doesn't come from increased mass -- FF is near zero (and positive) with zero throttle and mass doesn't increase. My guess is that this is a bug in the yasim jet engine code somewhere. One of these one-liners that are so hard to find. ;) But at least it's easy to reproduce. I think there's now a patch in for the engine problem - don't know if it fixes everything though. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
On Monday 07 August 2006 11:50, Joacim Persson wrote: On Fri, 4 Aug 2006, Curtis L. Olson wrote: Based on my understanding of YASim, this has to be some sort of bug in the core yasim code since it's getting energy from nowhere. Might be some sort of numerical/roundoff issue, perhaps some of the code in YAsim makes assumptions/simplifications that start to break down at extremely high alpha angles? I've seen the fuel flow meter (2D panel on) go *negative* at supersonic speed and extremely high G turns (like 50G and beyond) at low altitude. It actually fills up the tank. ;) So it do seem to be some sort of type/typecast mixup. (Magically add mass at speed and you increase kinetic energy.) Thanks for posting this observation - this is clearly a bit wacky (not that accelerating w/o +energy wasn't) - can you reproduce it? LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fixes from Maik / compatibility warning
On Monday 07 August 2006 17:50, Andy Ross wrote: Note to all YASim aircraft authors: the first fix discussed below is correct and has to be applied, but will (or at least may) have the effect of modifying the solution results of all YASim aircraft (tails are likely to be more effective: that means aircraft will be more stable on the whole, but less able to achieve high AoA's at full elevator). I'd be appreciative if everyone could take their favorite aircraft out for a spin and report changes -- some may need re-tuning. Maik Justus wrote: Andy Ross wrote: Maik Justus wrote: Therefore for an wing without flap, spoiler and slat [...] no surface element is generated. Ah, OK. Yes, this was indeed a bug; I'm kinda shocked that we never noticed this before, it's been there since the code was written. Here it (the patch) is. Applied. But before testing it with any YASim aircraft: I probably found another bug in surface.cpp. For general lift and flap-lift the effect of stall is calculated in stallFunc() resp FlapLift(). Yup, that looks correct to me. Applied. I'm not sure what the points was of the extra 1.0 in the return value; maybe a holdover from an earlier version where this function returned a scalar coefficient, and not a force? If the fuselage is large in comparison to the wing, this amount can be rather high. I don't think that's correct. As I read the code, you would get 1N of force per fuselage surface (of which there are maybe a few dozen across a large aircraft). The first bug is a whopper. This one is pretty much noise unless you're modeling an R/C aircraft; I'm not surprised it stayed hidden for so long. Andy It's at times like this when I sort of regret trying to populate the FG hanger... :) Reading the comments in the commits, I think it will help things... LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
On Monday 07 August 2006 18:36, Melchior FRANZ wrote: * Lee Elliott -- Monday 07 August 2006 02:16: Can you reproduce it while under control of the A/P? That should help me reproduce it here. Didn't try. It's really easy to reproduce when you follow the instructions. I don't think the AP is involved in any way. m. Hi M, it wasn't that I thought that the A/P might be involved in the problem but just that it would make it easier to reproduce. It's just that scripted flights are more consistent. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fixes from Maik / compatibility warning
On Tuesday 08 August 2006 00:42, Josh Babcock wrote: Lee Elliott wrote: Reading the comments in the commits, I think it will help things... The B-29 seems OK. Actually, one of the things I've been thinking about it to overlay the 3d model with the YASim geometry model... ...but then I figured it would be a lot easier to wait until someone clever enough wrote something that would produce a YASim 3-view view from the definition... LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
On Friday 04 August 2006 15:26, Melchior FRANZ wrote: * Curtis L. Olson -- Friday 04 August 2006 15:34: I will point out that while it's possible to force the YF-23 into this extreme state, if you fly it in a more normal range, it behaves pretty normally. Not for me. I actually noticed the problems during normal flight. I chased the KA6 and, because (unlike in real life) there's no indication how far it's still away, I was a tad too fast when I noticed it coming nearer and nearer. I tried to fly some narrow curves, but unlike in all other fgfs aircraft, this didn't decelerate, but *accelerate*. Of course, I'm not a pilot, and in real life there'd be a FCS with g-limiter, and my body would warn me earlier, too, but that's no excuse. Unfortunately, we don't have a single halfway modern fighter in fgfs, that is not totally broken. The F16 is pathetic and unusable since JSBSim 2.0. The hunter/seahawk work nicely, but aren't exactly modern. So personally I think the YF-23 is a pretty fun plane to fly, even if it isn't 100% perfect. Sorry, no offense to Lee -- it's still very well done 3D model wise, but I find it a bit embarrassing to show off in the NTPS. I'm not even sure if this is an old bug or if it's caused by later YASim changes. I don't remember ever having seen such unrealistic behavior, and I used to fly the YF23 a lot at times. m. Hi Melchior, been out or watching Tintin movies all weekend but I have been following this thread. I haven't flown the YF-23 for a long time but I spent ages on it when I first did it and don't recall ever seeing this behaviour. This isn't to say that it doesn't happen of course - I seem to be the only person who has problems with the weather/altitude settings behaving randomly. Anyway, I just checked the output from the stand-alone solver and there doesn't seem to be anything suspicious in it: Solution results: Iterations: 530 Drag Coefficient: 14.044194 Lift Ratio: 160.218765 Cruise AoA: 0.343368 Tail Incidence: -0.639466 Approach Elevator: -0.593619 CG: -1.609, 0.000, 0.369 Drag's a bit low and the lift is a bit high but you've got to remember that it is a low drag design and the wing is huge - it's defined up to the center-line. I can't see anything there that gives any clues about accelerating without putting energy in. Can you reproduce it while under control of the A/P? That should help me reproduce it here. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Creating a 3D cockpit, new developer
On Saturday 05 August 2006 13:04, Maxwell wrote: As crazy as it sounds, I've been unable to find a large jet in FlightGear with a good, functional 3D cockpit. FGFS seems, however, to have a lot of potential, and I want to contribute if I can. I should say I have a lot more ambition than experience, but I may as well gain that experience here. What I intend to do is model a 3D cockpit for the Antonov An-225, creating new instruments, using photographs of the cockpit in an An-124 for reference. I can, to some pathetic degree, use Blender, and I have a reasonable understanding of the XML involved in making it all work. Relevant information would be useful, if I'm not taking a dive into the Mariana Trench when a kiddie pool is more my level. Eventually, all jets should have thrust reversers included, also. Incidentally, I wanted to do this with the Tu-154, but it needs more work beyond the limited scope of my capabilities, IE with its flight dynamics and exterior model. Max By all means have a crack at a 3d cockpit for the AN-225. I don't have any drawings or photos that might help but I reckon that your idea of using the AN-124 for reference should be sound - the AN-225 is basically a 'stretched' AN-124 with new inner wing sections and a revised tail. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
On Tuesday 01 August 2006 22:50, Melchior FRANZ wrote: * Lee Elliott -- Tuesday 01 August 2006 23:40: Again, IIRC, the real (Y)F-23 could (was intended) get to 65000ft so with the YASim YF-23 under weight and too powerful it's able to climb just a bit too high:) That's a minor problem. The bigger problem is that it *accelerates* in very narrow turns, and even with no throttle at all. And you can fly straight down with 1000 kt, and shortly before touch-down pitch up and fly straight up again. Doesn't seem to have enough mass/inertia. (Yes, the g-load would kill me anyway, so I shouldn't bother. :-) m. Just a thought - what sort of speed are we talking here? AFAIK YASim doesn't 'do' trans/supersonic - might this be a factor? In the sub-sonic regime I was able to achieve some interesting high-AoA manuevours and almost a cobra hook out of the YF-23. With the large lift area and power, combined with the V hstab configuration this seemed reasonable - the v hstab configuration should produce less drag in high-AoA than 'flat' hstabs (this might be a problem with the SU-37 I'm working on but perhaps playing with idrag might help). Then again, I might have given the 'wing' a much too high stall aoa... rumour-millI've seen a quote, apparently from a high-ranking USAF? officer, who said that YF-23 technology (in terms of the airframe design/configuration philosophy) was being made use of. Didn't state where though, of course. I've also seen some drawings of a variable-sweep version of a YF-23 type recon aircraft but this might just be a case of one false rumour re-enforcing another/rumour-mill LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
On Wednesday 02 August 2006 00:03, Josh Babcock wrote: Lee Elliott wrote: dearth of good info on the YF-23 when I originally did it. I Should you find a moment, I feel that I should point this out: http://www.flight-manuals-on-cd.com/YFN.html Josh Ta for that - I might have a look into it when I get back to the YF-23. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
I think this is resulting from a combination of factors. The YASim YF-23, as currently defined, probably doesn't weigh enough and the engines are a bit too powerful, both due to a dearth of good info on the YF-23 when I originally did it. I suspect that this means that it can get to 74000ft at which point, IIRC, YASim stops calculating altitude effects with the result that once you're above 74000ft you can carry on climbing. Again, IIRC, the real (Y)F-23 could (was intended) get to 65000ft so with the YASim YF-23 under weight and too powerful it's able to climb just a bit too high:) I do want update the YF-23 some time soon but I'm already pretty busy with two updates and a new aircraft so it'll have to wait a bit. LeeE On Monday 31 July 2006 05:44, JD Fenech wrote: Is this some sort of bug in the model? It strikes me as something that would either be a tightly held performance spec on the part of the US Gov't, or a glaring flaw somewhere... Stefan Seifert wrote: Melchior FRANZ wrote: $ fgfs --aircraft=YF-23 --airport=knuq --disable-real-weather-fetch - full throttle - climb to 8000 ft - 90 degree bank - pull stick fully back amazingly: you don't bleed off speed, but *accelerate* - at ~1630 kt (after that the speed decreases) 0 degree bank and 90 degree pitch up - climb to 163000 ft in no time If you really want to travel to other planets I suggest just pulling the throttle to zero when you reach the speed limit, while still rotating. This gives you the extra boost you need for interplanetary travel. Nine - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
On Tuesday 01 August 2006 22:50, Melchior FRANZ wrote: * Lee Elliott -- Tuesday 01 August 2006 23:40: Again, IIRC, the real (Y)F-23 could (was intended) get to 65000ft so with the YASim YF-23 under weight and too powerful it's able to climb just a bit too high:) That's a minor problem. The bigger problem is that it *accelerates* in very narrow turns, and even with no throttle at all. And you can fly straight down with 1000 kt, and shortly before touch-down pitch up and fly straight up again. Doesn't seem to have enough mass/inertia. (Yes, the g-load would kill me anyway, so I shouldn't bother. :-) m. Hmm... I don't remember it ever behaving like that but I haven't flown it for ages. I'll have to take a look at it. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Energy worm in hud
On Saturday 29 July 2006 00:18, Melchior FRANZ wrote: * Lee Elliott -- Saturday 29 July 2006 01:03: I saw that the test for ilcanclaw was re-introduced in hud_ladr.cxx and it seems to stop the energy worm from working No. It hasn't ever been changed there (Cockpit/hud_ladr.cxx). I only commented it out in the new HUD code in src/Instrumentation/HUD/HUD_ladder.cxx where it's still commented out. m. Strange - I must have used one of my locally modified files when I thought it was from cvs and then thought the test had been removed from the cvs version. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Energy worm in hud
Probably one for Melchior... I saw that the test for ilcanclaw was re-introduced in hud_ladr.cxx and it seems to stop the energy worm from working. It works again if I remove the test. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture in the new OV10 linked to the A-10
On Sunday 16 July 2006 00:43, Julien Pierru wrote: I don't think we did link, are you talking about the UHF? (we made a copy of the texture in the OV10 directory). Julien [EMAIL PROTECTED]:~$ grep -r A-10 FlightGear/Aircraft/OV10/ FlightGear/Aircraft/OV10/Models/USAFE/Instruments/UHF/CVS/Entries:/A-10-radios.rgb/1.1/Sat Jul 15 18:50:53 2006/-kb/ FlightGear/Aircraft/OV10/Models/USAFE/Instruments/UHF/UHF.ac:texture A-10-radios.rgb [EMAIL PROTECTED]:~$ LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A New Sun
I once tried to do some aurorae using very large 3d objects and while I could see them ok I couldn't get any colour in to them - they just looked white and the transparency I used in the texture was ineffective, so I could see the entire object, sharp edges and all :( dunno if you might have the same problem with using a 3d object for the sun. Haven't got around to trying it yet but meteors might work ok. LeeE On Sunday 16 July 2006 20:14, Mark wrote: Hi Curt, I've been thinking about the idea with the cylinder the last days. What I like about it is, that this way the fog of the distant objects is thicker at ground-level and gets thinner with increasing altitude. And it's less stress on the hardware than shaders. The cylinder could be part of the SGSky class, maybe as atmosphere-object. But I want to get the sun ready before touching anything else. So if anyone else would like to try out implementing the cylinder, that would be great.-) Bye, Mark Curtis L. Olson wrote: Mark wrote: Hi Steve, which line do you mean? The surface of the earth cutting of the sundisc? I agree this looks too sharp but I don't know how this could be improved with standards means. At least the sun's halos are blended with the fog already. I've been wondering about placing a short cylinder between the sky dome and the terrain. This would have fog color at the base and blend to completely transparant at the top. This would help hide the outer fringe of the tiles in some circumstances, and it would allow things like the sun and moon to blend smoothly into the true horizon. This could also help with sky dome - earth transition problems in various areas. We might consider moving this cylinder up and down to match the current view point altitude. This should be really easy to implement without needing any fancy opengl tricks (maybe make it part of they sky dome model), but I just haven't had time to try it out. Curt. -- --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057; dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Texture in the new OV10 linked to the A-10
Hi, I just noticed that the new OV10 references a texture from the A-10 - this might be a problem if someone doesn't have the A-10 installed. It would probably be better to copy the file in to the OV10. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] HUD updates
Hi Melchior, Re your recent updates on the HUD code: I see you have done away with the test on ilcanclaw for the energy worm in hud_ladr.cxx and I've been doing this locally for a few years now. I couldn't trace the source of ilcanclaw or what it was supposed to do but testing for it usually stopped the energy work from working. Usually... sigh... I find the energy worm function invaluable in tuning YASim configs in the high altitude region of the envelope because it shows clearly if the current speed can be maintained during level or climbing flight, or even if significant acceleration is possible. LeeE Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Problem with the generic attitude-indicator
Hello all, I've been having problems trying to get the generic 2d attitude-indicator working - it's permanently rolled over, showing 40 deg roll and 12 deg pitch. I suspected I was missing something in the electrical subsystem but I haven't been able spot it. LeeE Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Wednesday 21 June 2006 08:35, dene maxwell wrote: From: Torsten Dreyer [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Memory leak Date: Wed, 21 Jun 2006 08:58:31 +0200 If this is of any help - starting with the ufo on the ground and sitting there (no movement, controls untouched) the memory grows at a rate of approx. 50kB-100kB per second. Monitored for about a minute. .fgfsrc is blank and all rendering options unchecked, except display framerate This is on a linux-box monitored with ksysguard. Since the ufo has no panel at all, this is either another leak or the problem is not bound to the 2d panel? Torsten I noticed the same on 098a/win me then I looked at the xml files... the ufo-set.xml file has panel visibilty set to false and there in is no panel specified either in the ufo-set.xml or /model/ufo.xml does this mean that with the ufo, a 2-d panel is loaded but not shown till shftp toggles it on because it is certainly a 2-d panel that shows when shiftp is pressed The ufo-set files lists the author as ET... is this a case of ... ET call Torsten ? ;-) :-D ene I don't think that just a minute is really long enough to tell. You get some growth as things like the AI a/c get loaded and start flying about so FG legitimately grabs more memory in the few minutes after start-up. The 2D panel you see with the ufo is the C-172 2D panel, which is the default if none is specified. LeeE All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Tuesday 20 June 2006 08:19, Vivian Meazza wrote: Dave Perry I have had lock-ups on longer X-C flights with the pa24-250 recently that could be from a memory leak. So I used the system monitor to check on VM growth. The only 2D pannel used in the pa24-250 is the radio stack. So I tried commenting out various components of the radio stack in the file radio-panel.xml. If I comment all the radio stack in this file, the memory leak is gone. I did not try all combinations, but the leak rate seems to get greater the more radios are not commented out. I do not remeber this occurring even on very long X-C flights when I first submitted the pa24-250. System info FC4 Linux updated with yum update last Saturday Plib, SimGear, fgfs source, and base all updated from CVS on Saturday also. AMD Athlon XP 3200+ with 512 MB RAM Nvidia GeForce 7800 GS OC with 256MB GDDR3 Hmm - it's beginning to look as if this problem is long-standing. It only seems to involve 2d panels: those ac with pure 3d panels are unaffected. Some 3d panels have 2d elements - these are also affected. Linux and Windows both seem to be affected, but Melchior cannot reproduce the memory leak on his set-up. A date when you first noticed this effect would perhaps help in tracking it down. Vivian Yeah - it could be long-standing. I hadn't done a long flight, long enough to use all my VM for a long time, but I do remember occasions of FG bogging down like this from quite a while back. Can't be sure of how long ago though:( I always have the 'mini' panel open but I don't include radio instruments on them so I don't think it is _just_ due to the radio instruments. I'll try a completely blank panel to see if the problem is due to the instruments or the panel itself. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Saturday 17 June 2006 20:18, Vivian Meazza wrote: Lee On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. Vivian Sounds very much like it - I first noticed under the same conditions. I'll try cvs with Melchior's latest update, but a bit later - I'm of to a birthday now. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A few notes from Blender's AC3D exporter plugin programmer: Sir William P. Germano
On Saturday 17 June 2006 22:35, Roberto Inzerillo wrote: Hi people, I contacted William and asked him to add a simple option to his exporter pulgin. He was soon back with an answer and a new customized ac3d plugin which accomodates my request. He was very kind and, after having read a few archived fgfs-dev threads about the subject, he asked me to post the following notes. I think that's worth a quick reading, since it makes clear a few points. Roberto Hi, I'm Willian, I wrote the ac3d import / export scripts that come with Blender. Checking archived posts here related to them, after Roberto contacted me, I noticed it might be useful to mention a few things possibly not known to all users. - Configuration: There's a script called Scripts Config Editor that you can use to tweak options for the ac3d importer and exporter. It's in the Scripts window Scripts menu System submenu. As soon as you execute the ac scripts once (no need to finish, you can press ESC right after calling them) there will be config data available to be edited. There's another script called Scripts Help Browser in Blender's Help menu. From it you can get info about the configurable parameters and other notes (it's all written in the scripts themselves, this is just a nicer way to read the info). - Exporting single / double sided face info: The Double Sided button in Blender works per mesh, so if you set or unset it all faces in that mesh will be either double or single sided. I decided not to export that info because there is also a simple way to set this *per face*: enter UV Face Select mode (select mesh, press f in the 3d view win) and in the Texture Face panel of the mesh editing buttons tab (F9 in the buttons win) use the Twosided toggle button. To copy the face flags to other faces, so you don't have to do it manually: select them, then select the face with the data (make it active) and press Copy Draw Mode in that same panel. I believe that is the best way (its only drawback is that it's sort of hidden inside the uv face select mode), but since Roberto emailed me stating he still would like to use the Double Sided button, I updated the ac3d exporter with an option to define whether to check per mesh or per faces (defaults to per face, the current behavior). I'll test the script properly and commit it to Blender's cvs (btw, the next release should be out soon, maybe in a week), but already sent a copy to Roberto. Lastly, in the long run I suppose / hope projects like yours will support COLLADA (which we want well represented in Blender, too), but I'm really glad to see those two small scripts I started years ago were and are still useful to some people involved with such a cool project, thanks :) . PS: I'm not subscribed to this list (thanks Roberto for forwarding this), you can reach me at wgermano at ig.com.br That's helpful info - thanks for posting it and to William. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Memory leak
Hello all, Is anyone else seeing a memory leak in current cvs? After using all my real ram fg starts gobbling through VM at about 1 mb every 5 seconds or so, even when flying around the same area. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
What exactly do you mean by compromising Open Source in the context of getting FG working with closed source/proprietary software? While I much prefer O/S I'll use whatever software I want and don't feel any qualms about using C/S proprietary software. Software is a tool, not a religion and developing software isn't about proselytising but making something work. I figure that vatsim would be happy to be able to distribute a suitable interface client but aren't prepared to finance the development of one. If I had current C++ skills, instead of obsolete COBOL FORTRAN experience, I figure the easiest way to solve this would be to write an interface client (a discrete userland prog that could talk to their servers but also communicate with FG though it's existing IO) under their conditions, and give it to vatsim for them to distribute, and if it were taken up and used, further maintain. LeeE On Tuesday 13 June 2006 15:20, GWMobile wrote: Way back on compuserv forums when I first posted the idea of multiple people working together to build an open flight sim along the lines of linux I never expected there would be talk of rolling that into some sim that is proprietary in any way. Build it and they will come. Vatsim will convert to you if make an open source flying network. You shouldn't think of compromising open source one single inch. On Tue, 13 Jun 2006 9:13 am, Arnt Karlsen wrote: On Tue, 13 Jun 2006 13:50:34 +0200, Major wrote in message [EMAIL PROTECTED]: As to my suggestion of linking FG and X-Plane to fly FG on VATSIM, I haven't forgotten the project but haven't actually got a working installation of X-Plane under Linux that would allow me to write a plugin. I'll try and carry on with that once I have X-Plane running again (actually, it's the OpenGL acceleration that currently isn't working on my computer, thanks to ATI being a year behind Linux and Xorg development). ..you've probably heard drop ATI windroid driver and use Xorg's ati|radeon before. Very recent video card? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-deve l Bush's family and their Saudi partners make higher profits by preventing Saddam's huge Iraqi oil reserves from ever being sold. They'll Enron the world - George Watson 2001 For Hurricanes www.globalboiling.com For solar wind and earthquakes www.electricquakes.com Typos caused by two inch mobile phone keyboard ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
On Tuesday 13 June 2006 23:26, Arnt Karlsen wrote: On Tue, 13 Jun 2006 21:29:05 +0100, Lee wrote in message [EMAIL PROTECTED]: What exactly do you mean by compromising Open Source in the context of getting FG working with closed source/proprietary software? ..usually this is done by idiot stunts like signing away your rights in contracts such as EULA's or NDA, where that A is a synonym of the legal term contract, a well known litigation bait. What sort of percentage of people who develop Open Source software would you guess also have a paid job developing proprietary or commercial custom software? Anyone working on proprietary commercial custom software will be working, in effect if not explicitly, under an NDA. This doesn't stop them from working on O/S stuff as well, providing that the Closed Source stuff isn't fed in to the O/S stuff. The terms on an NDA could be draconian but then take-up is going to be low, so a reasonable NDA is going to be more successful. All those people who get paid for s/w development and who also work on O/S projects seem to get by ok, without too many conflicts of interest. While I much prefer O/S I'll use whatever software I want and don't feel any qualms about using C/S proprietary software. Software is a tool, not a religion and developing software isn't about proselytising but making something work. ..it is also a multi-billion business for people like Microsoft and IBM. You never been paid for making something work? ;) I figure that vatsim would be happy to be able to distribute a suitable interface client but aren't prepared to finance the development of one. ..then they are not keen enough. They don't have to be keen. They've done what _they_ wanted - they just haven't done what _we_ want. If I had current C++ skills, instead of obsolete COBOL FORTRAN experience, ..who says this interface cannot be done in one of these 2 lingos? A Cobol or Fortran white box would stand out _prominently_, from the common C 'n C++ code, especially in court. Heh :) COBOL might not be bad at handling comms, now that I think about it - defining and manipulating record types has never been so much fun. I figure the easiest way to solve this would be to write an interface client (a discrete userland prog that could talk to their servers but also communicate with FG though it's existing IO) under their conditions, and give it to vatsim for them to distribute, and if it were taken up and used, further maintain. ...which brings me back here :) LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lee Elliot-ComperSwift
On Wednesday 07 June 2006 13:35, Arnt Karlsen wrote: On Wed, 07 Jun 2006 01:26:22 -0400, Josh wrote in message [EMAIL PROTECTED]: Lee Elliott wrote: lowest I dared stall? Like he had a choice? ..or no chute? Or, not wanting to risk an unique plane? Could be fun modelling it to see how close we get to it. [snip...] Well, yes he did have a choice. At the time that those comments were written there were quite a few Swifts flitting about the sky. In this particular report the pilot was comparing what was then the _current_ model with an earlier version, which he had also flown. He would have been aware, not only from his personal previous experience with the Swift, but also from talking to other pilots who had also flown the type, of what he might expect in the air, so when he went up to check out it's stall performance and characteristics he would have done it at a safe height and with a good idea of what to expect. There is a lot left unsaid though - from the same article: 'Former Cromwellian Leonard Snaith flew the prototype Swift on many occasions and during one flight flick-rolled it. The Swift continued to roll three times, Snaith describing the manoeuvre as a horizontal spin. He did not recall how the Swift recovered or at what altitude. Comper, who had been watching Snaith's display, was later found at the bar downing double brandies' Apparently, when rigged and trimmed correctly for level flight, hands-off you would have been likely to find it yawing to the right and rolling to the left, but this sort of behaviour appears to have been pretty normal for aircraft of the time. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPL licensing question.
On Tuesday 06 June 2006 17:52, Curtis L. Olson wrote: Here's a question for all you amateur lawyers and GPL experts out there. Let's say that someone wants to create a proprietary aircraft within the FlightGear system, and then distribute a larger system that includes FlightGear + that aircraft. In my view, the FlightGear GPL license covers our source code, but not content created with or used by that code (except for things like the base package which is explicitely licensed as GPL.) Is it possible that someone could lay claim to any newly created proprietary content (3d models, artwork, panels, etc.) by way of the GPL? Even if FlightGear is happy to allow people to create proprietary aircraft, could someone upstream in plib or zlib or openal land somehow file a complaint? To me this is analogous to Microsoft demanding all documents created and owned by a company just because they created and edited them with Microsoft Word. I just don't see that ever happening. But I wonder what others think about this issue from a legal point of view. Thanks, Curt. I don't think we need to worry about the source code aspects of GPL in FG - that's fairly straight forward and well understood. It's the situation regarding the GPL'd data that seems a lot less clearer and is causing the most uncertainty. The GPL'd data that comes with FG can be separated in to two areas, broadly defined as artwork and configuration. Now, if someone were to take an aircraft or a building etc model, or a texture and then modify it, it would still be covered by the GPL because it would clearly be a derived work. However, the configuration files are how FG is instructed to work and so can't be GPL'd, even if proprietary configuration files are derived from ones already in FG. Basically, if you want to do the same thing in a proprietary regime as something that has already been done in GPL'd FG, the files will, and in fact _must_ have similar content. I'm not sure exactly how nasal should be treated though. Each script qualifies as a program and would therefore seem to belong with the source code but in fact, nasal use within FG is used as another way of controlling FG - just consider a simple script to toggle a property and how insisting that it is GPL'd would prevent any proprietary use of similar code, which seems nonsensical. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lee Elliot-ComperSwift
On Tuesday 06 June 2006 21:40, dene maxwell wrote: Hi Dene, Just as well I said I would check :) Here are the _correct_ figures for the Comper Swift fitted with the Pobjoy R seven cylinder radial engine (as modelled) Cruise: 120 mph (104.2 kt) Max: 140 mph (121.6 kt) Landing/Stall 40 mph (34 kt) Not sure exactly what is meant by the Landing/Stall speed :s but in a flight report from 1931 the pilot said The elevators give a much better impression of effectiveness down to about 45 mph - which was the slowest to which I dared stall - here he was comparing a model where the cut-out in the wing trailing edge for the cockpit had been smoothed with an earlier model where it was more angular. The same pilot went on to say that he felt happiest landing at 55 mph (47.8 kt) HTH LeeE Thanks Lee thats all I need for a realistic AI Scenario... I don't think anyone will complain if the sim lands at 45-50 knots ... I suspect the Landing/stall figure is in fact *stall in landing configuration* (ie flaps) this seems to be a very popular figure to provide in performance data. Thanks again :-D ene Just thought I'd better point out that the Swift doesn't have flaps ;) LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lee Elliot-CompterSwift
On Sunday 04 June 2006 09:46, dene maxwell wrote: Hi Lee, I have some questions regarding the ComperSwift; I would like to use it in the FGLive-KOSH CD being put together by Arnt... i know under GPL I don't have to ask for permission but would like your comment... particularly as I'm missing one important figure - cruise speed :-)... I don't really have time to download/install and get : familiar with the aircraft as it will be used in an AI scenario and just need to know the basic flight parameters/performance figures I have the J3, 172P C28-161 as low speed(90knt comfortable)aircraft for the standard NOTAM approaches and there are heaps of 140knt+ aircraft to choose from (AIR New Zealand 737 ;-)...but need 5 low speed civilian aircraft. The Rascal110 also looks a good candidate to fill the fifth spot :...similar figures would be required for that too... if you would prefer to take this off list please feel free to mail be direct.. TIA :-D ene Hi Dene, I'll check the figures for you in the next couple of days but iirc cruise speed was 100 mph @ 3000 (eng) rpm, max speed 130 mph @ 3300 (eng) rpm - eng rpm quoted because the prop was geared. Actually, I've flown it quite recently, to do a bit of virtual geology over the Channelled Scab Lands in Washington state (worth a look in FG) and it seems to be flying pretty close to the right numbers, engine included. Not so sure about the handling though - it should be tail-heavy and inclined to loop if you let go of the stick, which doesn't happen in FG. Like I said though, I'll check the numbers and get back to you in the next few days. You make a good point re it being GPL'd - it is and what is in FG isn't mine. However, I think it's probably a good idea to try to talk to any people who created or subsequently developed the work because they will have done a lot of research on it and could save you a lot of time. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
On Sunday 04 June 2006 08:40, Georg Vollnhals wrote: Josh Babcock schrieb: AJ MacLeod wrote: My only request at this stage is an easy one - that the aircraft starts off with the parking brake engaged. There are few things more irritating than having the fg screen fade in only to find yourself pitching off the carrier deck or into the nearest windsock! Hmm, rather than force everyone to start with the P-brake engaged, why don't you just set it in your preferences.xml file? This is the sort of thing that really has nothing to to with the aircraft, and everything to do with the procedures that an individual pilot likes to follow. I always find it irritating when an aircraft designer thinks that they know better how I want to operate in my little world than I do. josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-deve l Hi, I really did a lot of Harrier flights as I am a vertical flight fan. And so I have to state that AJ is right as you *always* have some horizontal forces when starting FG/Harrier and it is *very* annoying to move off your position if space is somehow limited (ship, special terrain) *although* I am with my fingers on SHIFT/b immediately and fast (I think at least). Ok, I solved this *for me* with starting FG with --prop:controls/gear/brake-parking[0]=1 but this is not a good general solution for other FG users not familiar with the property system. I started setting the parking brake to on for the same reason. The Harrier in this stage of development is a nice add-on but very difficult and strange to handle due to the actual flightmodel, that is a pity. But it is as difficult to develop like the helicopter flightmodel, I think. The newer versions of the Harrier have an artificial stability system which makes it a lot more easier to fly the aircraft in low speed procedures - may be the force is with us and we'll see something like that in FG some day :-) Regards Georg HeliFlyer EDDW Actually, I believe that the Harrier flight model is pretty good and is quite faithful to the real-life handling of the early Harriers. Because we can't feel the accelerations through our backsides it's almost impossible to transition and hover 'slickly' but if you're careful and steady it works. Or at least it did when I last tried it a few years ago:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] WIP
Hello all, some screen grabs... http://www.overthetop.freeserve.co.uk/SU-37-00.png http://www.overthetop.freeserve.co.uk/SU-37-01.png http://www.overthetop.freeserve.co.uk/SU-37-02.png http://www.overthetop.freeserve.co.uk/SU-37-03.png ...about 25% done Probably the hardest thing I've ever tried to model - there are hardly any 'straight' curves in any axis and they've all got to be consistent with each other. LeeE --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance monitoring
On Thursday 18 May 2006 16:58, Berndt, Jon S wrote: [HTML snipped...] Can anyone tell me what the name of the routines is that allows one to determine the performance details of a Linux application? Is it 'time' you're thinking of? LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Browser: old dog, new tricks
On Thursday 18 May 2006 18:12, Martin Spott wrote: Melchior FRANZ wrote: - doesn't scroll the list back to top after editing value (which was very annoying) Fixing this is a really great idea. Thanks, Martin. Seconded, thirded.. LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] F-14 undercarriage animation / Blender / SF.net lists
On Thursday 18 May 2006 22:11, AJ MacLeod wrote: Forwarding this to the list as requested. And because there are lots of people here much better qualified than I to answer the animation questions :-) Cheers, AJ -- Forwarded Message -- From: flying.toaster To: AJ MacLeod Hi there I send you this e-mail because the anti-spam at sourceforge is filtering my domain name (voila.fr, which is sort of like hotmail). I know that lots of spam come from that kind of domain but this restriction is kind of violent ! Do you have any idea how I could get my posts sent ? Here is the latest one I wanted to send regarding the tomcat if you want to forward it ... I posted a preview of animations (landing gear retraction) at avsim forum. I think I got the blender inverse kinematics right now, but I am wondering if this is of any use since blender uses bones as a replacement for transforms in the animations (actually bones are pseudo objects redefining the axes of its childs in the hierarchy). Bones are very elegant but I don't think there is such a thing on plib animations. Furthermore, animations are interpolated across multiple frames but how do I export a particular animation for a particular part (say ground spoilers) for use in flight gear ? I just feel like all the pretty work on blender is going to be useless. Anybody tried blender export before ? regards Enrique Hi AJ, Enrique, there's no support for IK in FG - you'll have to use axis and the existing rotate and translate animation methods. This has become a lot easier to do since it was possible to define axis by their endpoints instead of normalised values. Getting them right when the axis is compounded between x, y z still requires some effort and it can help if you temporarily bind the control-input axis for the animation you're working on to one of your joystick axis and then, for rotation animations, set the factor so that the rotating object rotates through 360 degrees. This should make the rotation axis a lot clearer. You've still got to fire up FG after each change to check stuff though. LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] F-14 anyone?
On Tuesday 09 May 2006 06:29, flying.toaster wrote: [snip...] In many respects the F-14 design is very similar to that of the SU-27 family of aircraft. True enough, for instance landing gear design (downlocks are located on the engine nacelle), poded engines, twin tails, blah, blah. But then the Su-27 is much more refined in its aerodynamic layout (and quite tempting to model with its completely outdated flight avionics suite), even though reports seem to indicate that the tomcat *had* (sigh) quite amazing high alpha behaviour. I'm not too surprised about it's high AoA behaviour. The way in which I find it similar to the SU-27 family is that they both use a long chord central lifting body, in to the front of which is inserted a relatively small fuselage nacelle. There's no conventional full-length fuselage, just lots of wing :) The YF-23 is also quite similar in this respect too, but doesn't have the 'tunnel' formed by the widely separated engines. To answer Mathias Fröhlich kind offer, I have a few docs myself (mainly Aerofax volume on the Tomcat), and I am using Airliners.net quite intensely. Photos are as important as good drawings when you want to go into detail. If I get stuck somewhere, I will surely get back to you. I have a large format book on the F-14 detailing the development, design, weapons systems, deployment and service but it's quite old now and doesn't really cover the later models. There's a cut-away drawing but I don't remember off hand how detailed it was. Quite a few side-view colour-scheme drawings and photos. Got a DVD on the F-14 too but it isn't that helpful. Some nice footage though. LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flaps question
On Monday 08 May 2006 19:46, Justin Smithies wrote: Hi all, I have a quick question that someone is bound to know the answer to. On my aircraft model i need the flaps to step through 7 positions. But i noticed that the nasal script controls.nas is hard coded to 3 equal positions only. How do i get around that without changing the controls.nas script as other aircraft might need the 3 equal steps . I just want mine to have 7 steps we ll in fact if i may go a little further could i have the following positions ? 0 Degree 1 5 15 20 25 30 Any fancy scripting ideas without changing any of the default FG source, just the aircrafts folder sources. This has to work from any joystick file too and the default keyboard file. Thanks in advance Justin Smithies Easiest way is to suggest that you have a look at the A-10-set.xml file and scroll down to line 137 (comment header line) and try that. Atm, this is just a branch beneath / but it could probably be moved in to one of the existing branches at some point. LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] F-14 anyone?
On Saturday 06 May 2006 22:02, flying.toaster wrote: 3D model started. You can check out the 1000 polygons on AVSIM forum Cheer up it's only a few months away ;o) Looks like an F-14 :) I've got to say that imo this is quite an ambitious project but it looks pretty good so far. What are you planning to do with the jet-pipe nozzles? It looks as though you have shown different nozzle area settings in the two pics. In many respects the F-14 design is very similar to that of the SU-27 family of aircraft. LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Better way to edit XML files
On Wednesday 03 May 2006 23:44, Curtis L. Olson wrote: Christian Mayer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dene maxwell schrieb: Very interested in VI ...IIRC it is *nix based? ...after quick google search, is VIM VI iMproved? Is there a windows based version of VI(M)? as I would like to see the XML syntax feature you mentioned. http://www.vim.org/ There's also the Windows version. Vim is the successor to vi, so you can safely use it. BTW: it's allways important to know the basic vi commands. You might have to log in remote on a machine and fix something - if at least something works, vi will also work... To stop a holy war: The whole world knows that insert favourite editor the best in the whole mulitverse, and everybody who doesn't believe it is an idiot. And of course, every experienced unix professional knows the original vi was already perfect. These so called improvements in vim are simply a bunch of dumb bandaids and cruches to help out those lazy people who don't have 6 months to learn *real* vi and who think every editor ought to work like notepad in windows. So what happens if you have to access a system remotely and the terminal emulation is broken so you can't do a full screen visual edit of a file. You better be able to find your way around in ed ... at least well enough to reconstruct an ascii terminfo file by hand from scratch! Curt. vi !!! Monty-Python 'Luxury' sketch When I started out in computers it was all teletypewriters. In those days 32K (words) was state o'art. Ferrite core store and none o' yer fancy transistor memory. Mercury delay lines...blah blah blah./Monty-Python 'Luxury' sketch ;) LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Me262
On Tuesday 25 April 2006 20:28, Georg Vollnhals wrote: ng. What the subject said is apparently correct: today the First Flight in Manching / Germany I guess today rellay means today ! That is very right, it is the First Flight of one of the rebuild planes in Manching/Germany. But it is *NOT* the first flight of this American project to rebuild the Me262 - but somehow not really true as there are modern engines and some details changed due to security reasons. This project has an amazing story as the companies who build the planes changed during the development and after the maiden flight there was one accident due to landing gear structure defect only with smaller damage. The testpilot is former German military jet pilot with a lot of experience (Wolfgang Czerny ) and has written a nice book about his work with the Me262. There are several Me262 build, at least 1 for a German flight museum. It might this one which has been tested in Manching. Sorry details lacking as I have them all but could not find them on the run! May be you can find more with Google about this project. Regards Georg EDDW HeliFlyer This is the second Me262 to be built by the Me262 Project and it was first flown by Wolfgang Czaia on August 15th, 2005 from Seattle, where it was built. These new-build Me262s are convertible to tandem two-seaters and the first one to be built, N262AZ, was configured as such. I've been following this story for a few years and there have been regular reports in some of the classic aircraft magazines. LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] menu not working
Hello all, back at the beginning of April I reported a problem where the top menu and any open dialogue windows stop responding to mouse clicks. The problem is intermittent in that some times it happens immediately and sometimes it doesn't happen at all. I get nothing from setting --log-level=warn when this happens So far, no one else seems to have hit this problem but can anyone suggest what might be causing it? Atm, I can't really use FG because of this problem. ...then there's the problem with the correct winds and visibilities not being honoured too, but that's been happening for well over a year now. LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Heads up for Curt.
Hi Curt, I've sent you a few e-mails over the last month re updates and queries but haven't heard anything from you - are my e-mails getting through? LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Textures Part II.
On Monday 24 April 2006 12:16, Martin Spott wrote: Melchior FRANZ wrote: There's a reason why hardly any graphics professional uses a flatscreen for his work. Those people insist on CRTs. My CRT was quite cheap, and doesn't seem to have a linear voltage/brightness curve, but colors are OK. Last year on the LinuxTag I met Harald Koenig again - formerly known as Mr. S3 :-) He was displaying a system for handling and employing colour management profiles. Maybe we can elaborate a recommendation for how to calibrate FlightGear users' screens. Currently I only know of such systems for commercial operating systems (IRIX, MacOS, Windows, ), Martin. Being able to calibrate FG's display would be a useful and professional feature. As to how it would be done though... LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Use of old maps
On Wednesday 12 April 2006 20:23, Jon Stockill wrote: Ralf Gerlich wrote: IANAL, but you might be even better off than you think. At least here in Germany, courts seem to consider only the map itself (its presentation) to be protected by copyright but not the base data (such as elevation isolines, roadlines, etc.), as the base data itself represents reality and does not lend itself to creativity (persönliche geistige Schöpfung or personal mental creation), which is a basic requirement for copyright protection according to German copyright law. Do that in the UK and you'll be very heavily stomped on by the OS lawyers. You want the data, you need to survey it yourself, or buy it (and then there'll likely be restrictions on use). You may have to check whether similar conditions apply to this specific map and Crown Copyright. I repeat: I am not a lawyer ;-) They don't :-) If they did then there'd be no reason for http://www.openstreetmap.org to exist. Jon Actually, I'm pretty sure that Ralf is right even within the UK - it's only the representation of the data that can be copyrighted - not the data itself. The data is there for anyone to collect so it is not possible to prove the origin of the data. There have been rumours that the OS introduced deliberate errors in their maps so that they could be used to identify 'copiers' but quite apart from the fact that this would prove nothing (because it doesn't preclude someone else doing exactly the same thing or simply making a coincidental mistake) the OS also insists quite strongly that is has never, and will never introduce data error. However, have a look at http://publicgeodata.org/Home for the latest bad news... LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Stalls
On Friday 07 April 2006 00:19, Andy Ross wrote: [redirecting to flightgear-devel] Lee Elliott wrote: However, I think this could faked very convincingly already in YASim and probably in JSBSim too, simply by playing with mass distribution depending on conditions (anyone want to give it a go? The right way to do it, IMHO, is with the turbulence input, as that's what the stall buffet is, after all: turbulence over the wings due to flow separation. Modify the number based on the current AoA, probably with a little Nasal (maybe also modify the C++ to sum the turbulence input from multiple properties so as not to confuse the environment subsystem). If audio is required, then this ought to be tied to turbulence also, or maybe to instantaneous acceleration changes (a delta of more than YYY m/s^2 over the last 0.XX seconds triggers the start of a whump sound). Andy For some reason I was under the impression that turbulence didn't work with YASim. As it does then I agree that using turbulence would be a better way. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: AP messed up? agl-hold vs. terrain-follow
On Friday 07 April 2006 07:56, Melchior FRANZ wrote: * Lee Elliott -- Friday 07 April 2006 00:31: now all we need from everyone else is a decision on 'agl-hold' vs. 'terrain-follow'. Okay. I flipped a coin, and agl-hold won! :-P No, seriously: If nobody objects I will tomorrow switch all remaining occurrences of terrain-follow to agl-hold in generic FlightGear files (but not in maintained aircraft, unless the maintainer wishes so). Rationale: - $FG_ROOT/Aircraft/Generic/generic-autopilot.xml uses agl-hold - $FG_ROOT/gui/dialogs/autopilot.xml uses agl-hold (and did before my changes) - all /autopilot/locks/altitude options end with -hold. (all heading options, too, except wing-leveler, which is understandable) Only $FG_ROOT/keyboard.xml and these aircraft use terrain-follow in at least one *.nas or *.xml file: - AN-225 - BAC-TSR2 - A-10 - B-52F - YF-23 - seahawk - MiG-15 - TU-114 - Hunter - CanberraBI8 m. Apart from the Hunter, which Vivian did, and the seahawk, which Vivian has done a lot of work on, the others were all done by me. A simple search replace on 'terrain-follow' /should/ work but will result in some funny property node names. I'll go through them manually and get updates out. Vivian: do you want to do the seahawk or shall I? I guess we need to rationalise the seahawk anyway. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: AP messed up? agl-hold vs. terrain-follow
On Thursday 06 April 2006 10:50, Melchior FRANZ wrote: * Melchior FRANZ -- Wednesday 05 April 2006 07:51: * Lee Elliott -- Tuesday 04 April 2006 22:49: There also seem to be some quirks in the way that the A/P gui handles things - if you already have an A/P mode engaged but didn't set it via the gui it will not be shown as set in the gui and then when you close the gui that setting becomes un-set. That's already fixed in my version of the dialog. Which is now committed. I waited for cvs being tagged for release, because I wasn't sure if it would work well enough already. But it seems to work without problems, so, if a packager wants to include it despite it being in 'instable' CVS/HEAD only ... :-) I also (think I) fixed a bug in gui.nas, that sometimes prevented the autopilot menu entry from getting activated when it should. m. Fixing the behaviour is good work, now all we need from everyone else is a decision on 'agl-hold' vs. 'terrain-follow'. Either is ok to me but as I mentioned, agl-hold is quicker to type while you're testing stuff (although my fingers now 'remember' 'terrain-follow' :) LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Update: Experimental lighter-than-air support for JSBSim and FlightGear
On Wednesday 05 April 2006 10:24, [EMAIL PROTECTED] wrote: Hi! I am experimenting with some lighter-than-air support for JSBSim and FlightGear. The progress is not fast, but it is there. Currently, I have implemented enough to make free flying balloons behave sort of decently[0] and it should be possible to make simple airship models (though, I have not quite grasped how to specify the aerodynamics part in JSBSim yet and that is crucial for airships to behave in a plausible way). You can find my stuff here: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ Are there anyone else interested in lighter than air flight for FlightGear/JSBSim? Comments and suggestions are welcome! Best regards, Anders Gidenstam [0] I have never piloted nor flown with a balloon IRL, though. There is a balloon fdm in FlightGear but the last time I tried it I got some very strange results, and accelerations;) I'd _would_ like to do some Zeppelins though... You are absolutely right about incorporating the dynamic lift aspects of airships - it was a vital factor in their operation. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Menu problem
Hi all, can anyone else reproduce this? Start FG with a flight plan i.e. --flight-plan=foo Clear the route via the menu drop down. Add a way point and hit _return_ The menu no longer responds to mouse clicks but the mouse appears to work ok otherwise i.e. right clicks and on the panel. If you click on OK after entering the way point, instead of keying the return key the menu is fine. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer radar
On Monday 03 April 2006 10:56, AJ MacLeod wrote: On Sunday 02 April 2006 15:15, Lee Elliott wrote: I occurred to me that if the multiplayer aircraft positions were exposed in the property tree it would be pretty (well, relatively) easy to to make a working radar instrument. You mean something like the Lightning (and Crusader) already have? :-) Actually, I haven't had the time to test it much but I suspect something has gone slightly wrong with the Lightning radar when showing up MP aircraft - it was definitely working correctly for AI planes but the MP feature was a bit of a rushed add-on. I still need to add many more possible returns, because in MP there is of course no guarantee that the first three planes in the tree are going to be the closest ones and so the radar is fairly useless. There is also a simple 3d model bug where the returns are under some circumstances visible even through the rubber boot. Let me know if you test it and find that it's definitely broken, Cheers, AJ Ta - I'll have a look. I thought there was only the 2d radar instrument that worked with some AI aircraft/scenarios. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AP messed up? agl-hold vs. terrain-follow
On Monday 03 April 2006 19:54, Melchior FRANZ wrote: There seems to be a problem with terrain following: - the keyboard binding (Ctrl-t) uses terrain-follow - the AP dialog uses agl-hold - half of the aircraft use terrain-follow - the other half uses agl-hold - Generic/generic-autopilot.xml uses agl-hold m. It's been messed up for quite a long time. The original value was 'terrain-follow' and agl-hold turned up later, along with the A/P gui iirc. /Either/ is fine (but agl-hold is quicker to type in to the property tree browser when you're developing/testing stuff) There also seem to be some quirks in the way that the A/P gui handles things - if you already have an A/P mode engaged but didn't set it via the gui it will not be shown as set in the gui and then when you close the gui that setting becomes un-set. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer radar
Hello all, I occurred to me that if the multiplayer aircraft positions were exposed in the property tree it would be pretty (well, relatively) easy to to make a working radar instrument. If the multiplayer server also handled AI aircraft their positions could be exposed and monitored too. Just a thought... LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] b1900d questions.....
On Tuesday 28 March 2006 10:26, Vivian Meazza wrote: Martin Spott wrote Hello Syd, two points I would like to comment on: syd sandy wrote: The flight dynamics seem a bit off , Im not sure if anyone modified them again , but it seems to want to stall at take off speeds... I want to fix that , but I think someone may have tweaked it to be more accurate ... and I'm no expert in that area... if everyone thinks its ok I'll leave it alone. One more - any votes on keeping or removing the popup GPS ? I Although the b1900d flies pretty nice, the stall behaviour is somewhat strange - _and_ after a stall there's almost no chance to recover, even if you are at high enough altitude. I have to admit that I'm not completely sure and I don't want to blame innocent people, still I suspect this is not a problem specific to the b1900d but to YASim aircraft in general. I have not noticed this for other YASim aircraft, but I do note that the approach aoa is 5 degs while the wing stall angle of attack (aoa) is 7.5 degs. The wing stall aoa number looks far too low to me, and being so close to the approach aoa is likely to cause difficulties. Possibly a typo for 17.5 degs? Or perhaps it is correct ... just a thought. Vivian I've been able to get out of /most/ stalls and spins, given enough altitude, but it's vital to ensure that the trims are centered, which is not likely to be the case if you've been using an autopilot. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Particle systems and tile changes
On Tuesday 28 March 2006 16:20, Tiago Gusmão wrote: Hi I'm trying to use particles (there was an older thread), basically they're working, but they're attached to the aircraft, which makes them not very useful. Here are a few screenshots: http://gusmao.home.sapo.pt/p1.jpg http://gusmao.home.sapo.pt/p2.jpg http://gusmao.home.sapo.pt/p3.jpg if i roll the aircraft, the particles will rotate along, and so on. I mailed Luca Masera (he developed particles in the past) and he has a different approach, He attaches the particle system to the scene root and modified the particle system so the emmiter moves with the aircraft, but not the referential. A few screenshots of his work: http://myweb.tiscali.co.uk/vmeazza/FlightGear/snapshot%20-%201 .jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/snapshot%20-%202 .jpg Unfortunately it seems his code is lost. But it had a problem, when the aircraft switched tiles, the referential was no longer valid. I'm thinking maybe this problem could be solved by calculating an equivalent referential when the tile changes. This is currently the big problem, and suggestions are welcome. I also think it would be nice to have the particle systems available as animations and that's my current approach but alternatives are welcome. Cheers, Tiago Hi Tiago, I can't offer any practical help or advice but a working particle system for FG would be great and could be useful in many areas. I hope you stick with it and work something out :) LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airports list
On Sunday 26 March 2006 10:26, Paul Surgeon wrote: On Saturday 25 March 2006 19:48, David Megginson wrote: On 25/03/06, Melchior FRANZ [EMAIL PROTECTED] wrote: The airports list is barely usable: there are so many entries in it that you don't easily find anything. And the slider resolution is much too high for finding an entry with it alone. Move it just one pixel, and you jumped over oodles of airports. The arrow buttons have no repeat function, so they are of limited help, too. I've now hacked the airports widget to allow filtered lists: http://members.aon.at/mfranz/airports.jpg [30 kB] We need to get geopolitical information into our airport list, at least at the country and region (state/province/etc.) levels -- that could make the filtering much more useful. Proximity filtering might also be nice, but that's a much bigger job. All the best, David I did do some work on that a long time ago using the ICAO codes to break up the data by country but ran into a couple of problems. 1. There is no state/province field in the airports db and it can't be deduced from ICAO codes. 2. There are a couple of areas in the world that share the same ICAO code even though they belong to different countries so using the ICAO code isn't a 100% accurate method. The best would be to have a country and state/province field in the airport DB and that would need to come from Robin Peel unless we want to have a different DB again. Regards Paul I think we could identify the appropriate countries accurately using the geometric stuff in postgres (dunno if other dbms have the functions and datatypes). Basically, I believe we would have to take the country outlines and use them to define geometrical shapes that can then be used in a query to see, from the lat/lon which shape (country) an airfield is in. That doesn't address how we would use results though - they'd either have to be used as an additional index/look-up file or to be merged in to the existing airports file, breaking compatibility. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft thumbnails on the download page
On Saturday 25 March 2006 16:00, Curtis L. Olson wrote: Lee Elliott wrote: Hmm... didn't think there was a copy of the Canberra in cvs until we put your updated version in. Just checked and I don't have a copy in my cvs here. When you sent me the first of your updated versions I noticed that you had changed the folder name but because it wasn't already in cvs I just went with it - I suspect it's this original version, which was simply named 'Canberra' and which was in the FG Hanger web page that you've still got hanging around. I must have had a really alpha version to try but not commit. I'll get it cleaned up the next time I build the aircraft download page. Curt. Hi Curt, IIRC I sent you an early Canberra around the time when the developers were considering the issue of including all of the FG aircraft in the base package. You put the Canberra up on the web-downloads page but not in to cvs, which seemed reasonable to me at the time, so I didn't comment. Then, when it was apparent to me that you probably would want it in cvs too, and this didn't mean that it would automatically go in the base package, Josh had already contacted me about re-working it so I then thought we might as well wait until Josh had done his stuff as it would be a big improvement. I was originally thinking that several different Canberra types e.g. PR.9 could all sit in a single 'Canberra' folder but when Josh sent me his first update he had changed the folder name to be specific to the B(I)8 and in the end I thought it would be easier to maintain if they were in their own folders after all so I just went with it, thinking that because there wasn't already a version in cvs, there wouldn't be any problems or confusion... lol :) LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Problem/bug with view centering via mouse
Hello all, Alexis and I have hit a problem while configuring the cockpit view in the A-10. Alexis has used pitch-offset-deg-12/pitch-offset-deg in the view[0]/config to pitch the cockpit view down, which works ok, but we've found that if you switch to a chase view and use the mouse to pan the view around and then reset the view the same -12 deg pitch down gets applied, even if we specify 0 deg pitch in the config for those views. There also seems to be some inconsistencies between the different views. If I bring up the 'adjust view distance' dialogue the headings for the three dials seem to be correct in the cockpit view i.e. Left/Right adjusts the view left and right but if I switch to a chase view the same dial now moves the view up and down. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A-10 with 3D cokpit
On Thursday 16 March 2006 16:58, Georg Vollnhals wrote: Martin Spott schrieb: Lee Elliott wrote: On Wednesday 15 March 2006 01:47, Georg Vollnhals wrote: 2. although this is *not* your problem as you are doing the panel work, I want to report that is was not nice to fly the a/c by hand, I then used the autopilot. It behaves very sensible on the nick axis and lame on the roll axis. I am afraid that the changes to the behaviour of the A-10 and it's autopilot are my fault. I had to re-appraise the A-10 YASim config after a bug concerning the wing incidence in the solver was fixed. Georg's description resemples me of a 'feature' that I know from almost every YASim aicraft that I can remember: They overreact, start oscillating around the pitch axis and get into an unrecoverable stall if you push the elevator a bit too hard. Georg, did you mean this ? Martin. Martin, it is like somesort of a spring is locking the model at its place when you move the joystick forwards, only a *small* movement is done (because you push against the spring-force and when you get over a sudden point of joystick movement, the spring is loosened, a/c nose goes down very heavily and then immediately a little upper (and to stay with the spring exampele, like a spring drawing it back) - this is only in the nick axis (not roll) and with a nose down joystick command. But as I wrote today, first I thought this to be a new behaviour but when I tested the A-10 of 0.9.9 it seems to be the same. But strange anyway. Regards Georg Ah - it's interesting that you specifically mention the nose-down behaviour because I believe some of the developers have been looking in to this already and this may be another example of a suspected problem. Incidentally, changing the roll rate shouldn't affect the other characteristics so I can increase that quickly and easily if that's the general consensus... If you're trying to use Alexis' A-10 tarball with 0.9.9 FG and not cvs you could try changing the wing incidence to positive instead of negative - that should give the same characteristics as with using cvs FG. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A-10 with 3D cokpit
On Wednesday 15 March 2006 01:47, Georg Vollnhals wrote: alexis bory schrieb: hi, I put on my server an .tgz of the a10. http://croo.murgl.org/fgfs/A-10/A-10.tar.gz I'll try to freeze the dev and concentrate in some weigth and textures optimization, plus tiddy up, until (maybe) it's comited and released. hope you enjoy it. Alexis Hi Alexis, I only had a very short flight with the updated A-10 and just want to give some feedback 1. the quality of your panelwork is phantastic! All the details, even if one looks very! near at the instruments. I like that fuel-counter clicking through, very realistic how it is done. And the scratches on the CRT display :-) Very nice sidepanels left and right. Keep up your high-quality work and standard 2. although this is *not* your problem as you are doing the panel work, I want to report that is was not nice to fly the a/c by hand, I then used the autopilot. It behaves very sensible on the nick axis and lame on the roll axis. If I remember right, I enjoyed the A-10 some months ago and something has changed, might be due to the new JSB-Sim flightmodel? Or is it not JSB? And I must admit that I have not upgraded CVS for 2 or 3 days - might be there were some changes there. Also this not as a critics but as a feedback. Thank you once again, you are doing outstanding panel work! Regards Georg EDDW Hello Georg, I am afraid that the changes to the behaviour of the A-10 and it's autopilot are my fault. I had to re-appraise the A-10 YASim config after a bug concerning the wing incidence in the solver was fixed. After the bug was fixed the A-10 config still seemed to solve with reasonable numbers but I had also found out some more information about the A-10 'loiter' mode, where one engine is shut down to save fuel, and wanted to aim towards making this regime work, as well as the normal regimes. This meant changing some of the values I used in the YASim config, which in turn has changed the flight characteristics. This is not to mention the change in the wing incidence, which just in itself makes the 'new' version very much a 0.1 release. For info, from looking at a lot of pictures and drawings, the A-10 appears to have slightly negative wing incidence and flies 'nose-up' most of the time. This would fit with the apparent depressed angle of the cannon (which in the current FG version incorrectly fires straight ahead). The work that Alexis is doing on the cockpit will actually help refine some of the numbers used in the YASim config. For example, when we think that the viewpoint from the cockpit is correct we must also be able to see not only targets that we may be firing upon but also the runway on approach, which in turn narrows down things like the AoA in that regime of flight and which can get fed back in to the YASim config. The autopilot structure/hierarchy has almost been completely re-designed, is very experimental and the A-10 is the first aircraft to use it :) (The Canberra will be the second, when Josh gets the updates sorted out ;) and the third will be the SU-37 I've just started modelling) I wasn't sure what you actually meant by sensible in the 'nick' axis. Anyway, cutting to the chase, what are the characteristics that you don't like or think are wrong in the current version? I guess I should mention that I haven't been able to get my joystick working since moving to alsa (j/s port on soundcard) so I can only fly using the mouse or k/b atm, which isn't very representative. Both the YASim config and the autopilot certainly need more work. Just a last thought - are you using the cvs version of FG? LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] /sim/replay/view gone lame
On Wednesday 15 March 2006 21:33, Josh Babcock wrote: I don't know when this started, but /sim/replay/view no longer does anything for me. Here's what I have in my preferences.xml file: sim replay duration type=double60/duration view type=int6/view /replay /sim Unfortunately, upon starting replay mode I always end up in view 1. Any ideas? Josh Hi Josh, I suspect the view type=int6/view might be your problem. type would normally be a string e.g. typelookfrom/type Specifying the view number would be done with view n=6 Remember that different aircraft have different numbers of views, so view[6] may be different in different aircraft. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A-10 with 3D cokpit
On Thursday 16 March 2006 01:29, Georg Vollnhals wrote: Lee Elliott schrieb: On Wednesday 15 March 2006 01:47, Georg Vollnhals wrote: alexis bory schrieb: hi, I wasn't sure what you actually meant by sensible in the 'nick' axis. Anyway, cutting to the chase, what are the characteristics that you don't like or think are wrong in the current version? I guess I should mention that I haven't been able to get my joystick working since moving to alsa (j/s port on soundcard) so I can only fly using the mouse or k/b atm, which isn't very representative. Both the YASim config and the autopilot certainly need more work. Just a last thought - are you using the cvs version of FG? LeeE Hi Lee, thank you for your long mail and all those information. Ok, first I learned it is not JSB but YASim. Then it is rather difficult to describe for me in English, but I hope you understand I have the A-10 *trimmed in a straight and level flight at 250 knts (that should be not too fast). When I try to get the nose a little down I have to move the joystick *a lot* forwards, much more than normally, because the a/c does not follow the steering command - then at last it goes down quick and heavily with the nose and comes up a little, all this happens in a very short time segment and it is like a little oscillation. Nose up is also with pretty much moving the joystick but without that bad behaviour. It is much more to observe if you have the A-10 not trimmed, but let us first speak about the best status as described above. Further more, if I want to roll the aircraft I have to use a long joystick-way, no bad reactions but I would not expect such a slow roll-rate at this type of aircraft - might be I am wrong. I updated CVS this morning and compiled as my last compile was some days old but the reactions of the a/c are the same. I hope you understand what I want to report. Regards Georg Thanks for the feedback Georg - I'll have a look in to it. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Next FlightGear Release - upcoming.
On Thursday 09 March 2006 19:35, David Megginson wrote: On 09/03/06, Curtis L. Olson [EMAIL PROTECTED] wrote: 3. Any other major issues? The TerraGear scenery bug with the Great Lakes (and possibly other large inland lakes?) is pretty serious -- it leaves many midwest U.S. and central Canadian cities perched on giant cliffs overlooking the lakes. All the best, David -- http://www.megginson.com/ Sounds very scenic ;) LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A-10 3D cockpit progress
On Sunday 26 February 2006 12:09, alexis bory wrote: Lee Elliott a écrit : On Saturday 25 February 2006 17:56, alexis bory wrote: I'll do that ASAP, maybe sunday night or monday. I can't see any need for a separate folder - add your stuff to the A-10, your name and comments to the existing files, especially the author tag in the A-10-set.xml file and send it to one of the cvs maintainers. I have furbished a .tgz of A-10 with the actual 3D cockpit, it doesn't permit yet to disable the added 3D stuff, but why not ;) (Dene, please, will you try it ?) I just wonder who/where to send it ? Alexis Could you send me a copy - I'd like to have a play with it:) I think there has been some misunderstanding with regard to the differences between version 0.9.8(a) and 0.9.9 YASim aircraft. The main issue isn't one of adding new features but of fixing a significant bug and this is why some YASim aircraft have become incompatible between the two releases. The nature of the bug - that of the wing incidence being reversed - means that affected aircraft i.e. those with non-zero incidence are fundamentally incorrect under 0.9.8(a) and so maintaining compatibility with 0.9.8(a) and earlier doesn't really make much sense. As it happened, I did add a couple of new 'features' to the current version of the A-10 but they aren't 0.9.9 specific and could be added to the 0.9.8(a) version but because that version is effectively broken there's not a lot of point in spending the time to do it, especially when I've still got other aircraft to fix - I'm currently working on the Canberra - another aircraft affected by the same bug. LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A-10 3D cockpit progress
On Saturday 25 February 2006 17:56, alexis bory wrote: Lee Elliott a écrit : On Friday 24 February 2006 21:11, alexis bory wrote: 10 more days and I will put a .tgz too :) How are those folk who like flying the A-10 getting on with the current version in cvs? OK, Martin said quite the same thing :) I'm currently figuring out the best way to prepare a separate folder like 'A-10-3Dcockpit' and tidy the mess I made everywhere. I'd like to upload some thing clean ( shall I upload to ftp://ftp.ihg.uni-duisburg.de/FlightGear/incoming/ ? ) I'll do that ASAP, maybe sunday night or monday. Alexis I can't see any need for a separate folder - add your stuff to the A-10, your name and comments to the existing files, especially the author tag in the A-10-set.xml file and send it to one of the cvs maintainers. A separate A-10-3Dcockpit would make the existing A-10 redundant - who would want to fly it without your cockpit? :) LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] model accumulation
On Saturday 25 February 2006 22:08, Melchior FRANZ wrote: Is everyone aware that we *never* free model branches? They are only accumulated until fgfs is exited. If you teleport from KSFO to LOWW/Europe, then you still have the KSFO terminal in memory. Doesn't sound like a good idea to me. Currently we don't have that many individual objects, but as people are contributing to the fgdb, this may become a problem (textures!). And it certainly will be a problem once I got Nasal support for scenery objects into cvs. m. humour This is a good observation and marks the point where FG transitions from the first phase of development into the second phase, according to the DNA (Douglas N. Adams) theory of development. In this theory, the first phase may be symbolised by the question: How can we eat? The second phase may be symbolised by question: Why do we eat? and the third phase by the question: Where shall we have lunch? /humour Humour aside, this is a very good observation. FG has reached the point where it clearly works - how do we do it? Answer: we do it this way, so the 'how' question is answered. The 'why' question then marks the point where you start refining things as you ask: why do we do this in this particular way? Sticking my neck out a bit, as I can't offer much in the way of c++ coding ( I can (could) do COBOL FORTRAN, but they're not much use here) I think now would be a good time to think about re-structuring FG as a long-term goal. Especially important, imo, is consideration for MP systems, and just to make it even more appealing for the developers, to make the graphics distribute-able. The good news is that I figure that only the grahpics would have to be synchronous - I reckon that all that other bits of FG could run asynchronously :) As for the third question, well... :) LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Detlef Faber - links for FW190 question Bf109
Yeah - that's interesting background info that would be useful to include in a readme or something. That's if you haven't already done so:) LeeE --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A-10 3D cockpit
On Wednesday 08 February 2006 06:29, Martin Spott wrote: Lee Elliott wrote: However, if people are flying it and liking it I don't want to break it for them, so it would be handy if people could let me know if they're using cvs FG or the last official release, I've almost always been using CVS. I honour your intention not to break anything, on the other I'd be happy if you manage to get more detailed information on the 'real' thing to make the FlightGear model behave more realistic. Cheers, Martin. Ah - sorry Martin, I knew you were using cvs, That's encouraging though because when I first tried A-10, after finding that it still solved without needing any changes, I thought it still flew ok. Mind you, I've not been able to get my joystick working after moving to a 2.6.15 kernel and Alsa so I've only been able to use the keyboard or mouse - not ideal. I try to get as much real info into the model as I can find but I think that sometimes you've got be careful about the datum under which the info applies. For example, I've seen a good performance plot for the A-10 and normally I'd pick the altitude and speed that I thought most appropriate and use those, together with max-throttle, for the cruise params (currently 0ft 380kt, which seem to be the max-speed conditions) but I also know from a good book on the A-10 that I have, that the A-10 has a 'loiter' mode where one of the engines is shut down to save fuel. The plane then just flies a race-track pattern somewhere convenient until it's either needed, relieved or can otherwise go home. In addition, I believe that the service ceiling is 45k ft and I don't think that the current cvs version can manage either the single engine loiter mode at a reasonable altitude or get anywhere near 45000ft. That was the basis of my thinking for using the loiter mode for the cruise params but then the problem is what altitude and speed do I use? I haven't found any actual numbers. One problem is that there's always a lot of stuff that nearly always has to be deduced e.g. the lift and drag from flaps and spoilers, but where I can get real numbers I use them. In fact, I'd like to make it clear that the A-10 isn't 'my' aircraft - it's GPL'd and part of the FG project, so anyone can fiddle with it. The only thing I wouldn't be very happy about would be if someone, while working on the fdm, wanted to use inaccurate numbers where accurate numbers were known, or at least not without having a well thought out reason for doing so. Having said that, wing geometry definitions are nearly always something of a compromise between the real shape of the wing and what you can specify in YASim, but then that's something that has to be well thought out. Anyway, back to the A-10 - would you like to try the current version that I have? I'd welcome your feedback and would enjoy collaborating with people on improving the fdm. LeeE --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A-10 3D cockpit
On Monday 06 February 2006 23:14, alexis bory wrote: Martin Spott a écrit : alexis bory wrote: Before going farther I'd like to know if any body else allready do the same work. Lee Elliott did the A-10, you'd probably ask him to coordinate the effort. I'd love to see a nice copckpit for the A-10 because I find it's much fun to fly that aircraft, Martin. I just can't wait to show a screenshot: http://croo.murgl.org/img/very-begining.jpg It's the very begining of the work, I hope it will be usable by most people. Did anybody asked about a way to keep the hud's marks inside the hud screen ? btw look at this nice peacefull A-10 :) http://www.firehogs.com/photos/photos.shtml Alexis Looks great - I'd love it if you want to do a cockpit for the A-10. It still seemed to fly quite well without any changes after trying it with the wing incidence fix, so in an effort to screw it up I've been toying with using the single engine loiter mode for the cruise params. Still seems to fly ok but made it a little bit livelier, which seemed about right. However, if people are flying it and liking it I don't want to break it for them, so it would be handy if people could let me know if they're using cvs FG or the last official release, which I believe doesn't include the wing-incidence fix. LeeE --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ILS ceased working for me
On Saturday 28 January 2006 15:32, Frederic Bouvier wrote: Lee Elliott wrote: I think Atlas needs updating now, to correctly align the ILS triangles with the runways... http://sourceforge.net/mailarchive/message.php?msg_id=14599912 -Fred Thanks :) LeeE --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Battery Realism (Nasal Electrical System)
On Thursday 19 January 2006 23:59, Steve Knoblock wrote: I have been digging into the NASAL electrical system code (supplied with the C172---I cannot speak for any other aircraft that runs a modified system). I have always appreciated when a flight sim models behavior of the battery in a realistic manner as is reasonable. Looking at the code, I noticed a comment that Cold Cranking Amps might be a feature to incorporate in the future. I was prompted to do a little research and see if this was reasonable and what approaches might be made to improving the battery model. The main areas I see ready for improvement are: * Cold Cranking Amps: An aircraft should fail to start in very cold weather when CCA is affected by temperature, or when insufficient CCA is available for any reason. * Deep Discharge (or Cycling): Should the battery be allowed to discharge completely, it should fail (i.e. no longer provide energy or sufficient energy to start until the sim is reset). * Battery Response to Temperature: The output of a battery degrades as temperature drops in a fairly predictable manner (at least for a generic battery...it would be unreasonable to turn FG into a battery simulator and the data for an individual battery is very difficult to come by even for industrial uses). [snip...] References == == http://focus.ti.com/general/docs/lit/getliterature.tsp?baseLit eratureNumber=slyp086fileType=pdf http://en.wikipedia.org/wiki/Car_batteries http://mtrl1.me.psu.edu/Simulation/Description.htm http://www.batteryfaq.org/ http://www.uuhome.de/william.darden//carfaq7.htm#cca http://windturbine.ca/batteries.html http://www.batterystuff.com/tutorial_battery.html http://www.uuhome.de/william.darden//carfaq7.htm I believe all these features are achievable with reasonable level of fidelity. I doubt my ability to code these on my own, so feel free to make what you will of the research and make suggestions. Steve Hmm... this made me think about how some aspects of realism and accuracy may not always be a good idea. For example, if the temperature is so low that CCA is inadequate to start the engine what is the solution? In real life I guess you wouldn't be able to fly but a flight simulator that refused to let you get in to the air wouldn't be very useful. That's not to say that an accurate/realistic battery model isn't a good idea but you might have to assume that all aircraft have been stored in a heated hanger before they're pulled out for a flight. LeeE --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Model this?
On Wednesday 04 Jan 2006 16:59, Gerard ROBIN wrote: Le mercredi 04 janvier 2006 à 10:06 -0600, Curtis L. Olson a écrit : If any of you airplane designers are bored with your current projects, here's an idea for you: http://www.billabongclipper.com I've done some work with the chief pilot of this airplane and was inside it before it got painted up and flown to Hawaii. I could probably get lots of technical data on it and first hand pilot reports. http://www.flightgear.org/~curt/Photos/KMHV/Link/img_2715.ht ml http://www.flightgear.org/~curt/Photos/KMHV/Link/img_2719.ht ml http://www.flightgear.org/~curt/Photos/KMHV/Link/img_2743.ht ml Best regards, Curt. Hello Curt, How could you dare, to suggest to anybody a model development, when you concluded that model development is not contribution to FG ? (cf your Message 18-dec 2005 user-mailing list). Which made me to withdraw any model offers and proposals ( Crusader F-8E and Corsair F4U) to FG community. Did you modify your policy, or is it only because that is coming only from you ? Cheers. I can only find one message from Curt to the user-list on 18-Dec-2005. It appears to be a reply to your complaint that no one had rushed to fix a problem you had reported and I cannot find anything in it to suggest that he concluded that model development is not a contribution to FG. What I understood him to be saying is that it is the people who contribute to FG that influence the directions it takes. For example, it was the result of 3d modellers making carrier capable aircraft that FG now has carrier capabilities. If that's not influencing FG development, I don't know what is. LeeE --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: XF-23 has strange shadow
On Wednesday 21 Dec 2005 11:12, Martin Spott wrote: Pigeon wrote: http://document.ihg.uni-duisburg.de/bitmap/FGFS/YF-23_01.jp g So the square shadow is the 'real' shadow of the fake shadow or something? :) The square shadow is the fake. To my knowledge there were only two aircraft that came with a fake shadow: the BO-105 and the YF-23. Lee probably knows better :-) Melchior removed the fake shadow from the BO right after real shadows were in place. Cheers, Martin. You and pigeon have it right. I tried shadow objects with quite a few models but started removing them as I figured that someone (I believe thanks are due to Harald) would eventually come up with a far better solution:) Haven't looked at the YF-23 for ages. Although I do have some plans for it they're down the line a bit. I'll get a quick update out to remove the 'fake' shadow. LeeE --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
