[Flightgear-devel] Re: making instrument scales with MetaPost
* Jim Wilson -- Thursday 20 May 2004 01:46: Melchior FRANZ said: Here's a small MetaPost file that I used to make the Bo105 rotor tacho (which is totally made up; need some expert advice first): Check out: http://www.airliners.net/open.file/438320/L/ Hey, very cool. The best cockpit photo that I've seen so far. How could I miss that. The sad thing is that none of the photos agree on instrument layout. (I miss an ADF, btw.) Looks like Maik's rotor RPM numbers are off (442 RPM). I can't make sense of the dual tacho. Maybe I can get some better pictures in the future: A RL Bo105 pilot contacted me for the 3d model and said he could send me some photos. He hasn't tried fgfs yet and I'm not sure if he will. But he's an army pilot and where there's one, there should be others. Once our FDM is considered finished, I could try to pick up a tester. :-) http://members.aon.at/mfranz/tach.mp (1.9kB) Looks interesting. ... and it's easier to learn than Perl, as long as you stay away from the more obscure language features. (Those can be scary.) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
* Roy Vegard Ovesen -- Wednesday 19 May 2004 22:22: http://home.tiscali.no/rvovesen/fuel.png (19,964 bytes) Nice! With the MetaPost user number at least doubling within just one day I'd say that this is now the preferred way to make instrument faces. ;-) http://home.tiscali.no/rvovesen/rose.mp If your example is not the best coding style then I would say that mine is probably _the_ worst coding style. :-) First of all: I cheated. The not the best style statement was for the first upload, but I consecutively improved the style and uploaded new version. And then: TMTOWTDI (there's more than one way to do it) and the result counts. Nothing else. I used polar coordinates to draw the scale lines at desired angles and radii. So did I. Except ... I also used polar coordinates to place the numbers at the exact same angles as the lines. It looks to me like you have carefully chosen the cartesian coordinates to place the number labels at. ... for the digits. That's because digits have rectangle shape and can't be placed evenly. There's some fine control required, and I made use of the symmetry properties of 0/2/4/6 and 1/5. I opened the postscript file with Gimp. Upon opening, one can select the resolution (DPI) and the amount of anti-aliasing of graphics and text separately. I have a Makefile that creates the rgb and drops it into the bo's instrument dir. No intermediate, manual steps. I would have used gimp, though, if convert hadn't produced a decent texture already. What I would change in your *.mp file, is: (1) The position and size of the image: the center of the face should IMHO be at origin (0,0). That's a lot more natural, makes rotations easier, and the code easier to read. The canvas should take the later size into account: my faces are already 2^n * 2^m in size. No later cropping required, only convert foo.1 foo.png. (2) I prefer to use relative units. I don't define u in terms of length units (1 cm), but such that (0u,0u) is the center, (100u,100u) the upper right corner, and (-100u,-100u) the lower left corner. (2) I'd rather use (0,10u) rotated i instead of (3u+10u*cosd(i),3u+10u*sind(i) (provided that you considered (1). Or even left scaled 10u rotated i. (3) The position of 10, 12 and 14. That's why I didn't use polar coordinates for that. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
* Melchior FRANZ -- Thursday 20 May 2004 09:37: What I would [...]: (1) [...] (2) [...] (2) [...] (3) [...] And finally: (7) learn to count m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Atlas CVS: fails to render 1024x1024 png maps
Hi. I should probably be asking this in atlas-devel, but at first glance it looks pretty dead there; and I'm guessing someone here has encountered this, or can easily. I recently built Atlas from CVS (that took some work, but that's a different conversation). I then set about generating maps, using the philosophy outlined on the Atlas website -- some 1024x1024 images for highres, and 64x64 images for lowres. See the bottom of http://atlas.sourceforge.net/index.php?page=run under Map Resolutions. The maps generated fine; looking at the .png's in an image viewer, they all look gorgeous. But using them in Atlas, I encounter trouble. As near as I can tell, Atlas is incapable of rendering 1024x1024 .png images. Here's what I find. 1. if image files for a location are not present, Atlas shows the airports and navaids on top of a light blue background (sensible, since the standard FlightGear assumption is that missing scenery is water). The same is true if the needed files are present, but are *not* .pngs (e.g. I just copy some random file in and give it an appropriate name, so that Atlas can try to load it and fail). 2. if the image files for a location *are* present, but are 1024x1024, Atlas shows an off-white background, with the airports/ navaids on top of that. 3. if I zoom out until I cross the highres/lowres threshhold of 1:100, Atlas tells me it's moving to the low-resolution maps, and *bingo*, I have maps as a background. 4. if I regenerate the low-resolution maps at a higher resolution, I get the same result as #3, UP TO the low-resolution maps having a size of 512x512. If I make the low-resolution maps at 1024x1024, run Atlas, and zoom out to where the low-resolution maps should be used, I have an off-white background. So it seems that 1024x1024 files are the problem. Does anyone else see this with a current Atlas from CVS? Any suggestions on what I can do to fix this? Obviously since the webpage was written as it was, it was intended that making and using 1024x1024 .png files be possible. What can I do to make this work? Thanks for advice, -c P.S. Oddly, when *making* the 1024x1024 images, Map is able to display them just fine. It's only when Atlas tries to do so that problems occur. -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpbRbQce51C9.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
* Josh Babcock -- Thursday 20 May 2004 01:01: On Tuesday 18 May 2004 19:09, Melchior FRANZ wrote: http://members.aon.at/mfranz/tach.mp (1.9kB) [instrument faces created with MetaPost] Ok, this stuff looks really cool, but I am encountering a pretty steep learning curve with MetaPost. Does someone out there want to cook up a generic template with plug-in values for all the variables and enough documentation that someone can just pick it up and go? Just take one of the two presented *.mp files, add a new instrument (beginfig or, in my case, begininstrument) and add some drawing commands. They are pretty self-explaining. Then run the file through MetaPost: $ mpost foo.mp # may be called metapost $ for i in foo.*; do convert $i $i.png; done Writing templates wouldn't make sense. It would be like writing a template for poems. The language isn't hard to understand (at least the parts that we used). The documentation that comes with MetaPost is sufficient -- look in /usr/share/texmf/doc/metapost/base/ or wherever your TeX dir is). Ask if you have problems. Here's a short tutorial: z0=(2,3); % define coordinate, can also be written as x0=2; y0=3; drawdot z0;% draw a dot, obviously at z0 (draw works, too) draw z0--z1; % draw a straight line between from z0 to z1 draw z0..z1..z2; % draw a smooth line through the points z0=z1 rotated 30; % does what it says it does ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] YASim prop changes
Jim Wilson wrote Andy Ross said: Vivian Meazza wrote: Performance: max = 437mph at combat emergency power at 25000ft, 413mph at 15000ft, 395mph at 5000ft, cruising speed 362mph, climb rate 3475 ft/min. Service ceiling 41,900ft. How much is combat emergency power? The trick is getting the actual Well...hmmm... The Air Force page shows the horsepower rating at 1695, see: http://www.af.mil/history/aircraft.asp?dec=1940pid=123006547 Most everywhere else it says 1590. One of those scans from the manual shows WEP at 3300 rpm. So perhaps 1695 @3300 is with WEP and 1590 @3000 is w/o WEP? WEP basically jumps the MP up to 67 Hg. Normal max throttle w/supercharger is 61 Hg up to 30,000 ft (sea level horsepower is available up to 30,000ft). We are suffering from information overload. No two source documents seem to quite agree, even the most seemingly authoritative. This is from a contemporary report on the Merlin 66 (=Packard V-1650-7): The principal results at combat conditions (i.e. 3000 rpm and +18 lb/sq.in. boost) ... I have not seen any reference to the Merlin safely exceeding 3000 rpm in level flight. I think 1695 HP could be the output in MS (Medium Speed) supercharger gear - rated altitude 5,750 ft. This would be consistent with this reference: http://www.wwiitechpubs.info/hangar/ac-uk/ac-uk-eng-rolls-royce-merlin/ac-uk -eng-rolls-royce-merlin-br.html If we stick to the broadly accepted figure of rated output 1590 hp at 3000 rpm at the rated altitude of 16,000 ft and get YASim working with that, we would be getting somewhere. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
BTW: this is my little transparency trick: in my fgfs.mp library file I have this: color foreground, transparent; background:=black; transparent:=white; white:=255/256white; foreground:=white; which lets white actually be written as 254/254/254 ... white enough (who needs true white, anyway), and transparent areas are 255/255/255. Note that 1/2a is the same as (1/2)a or .5a, and not 1/(2a). *** now I can draw foo withcolor transparent *** and later, in my Makefile I have lines like these: foo.rgb: foo.mp Makefile mpost foo.mp convert -density 1024x1024 foo.1 -transparent white -resize 256x256 sgi:foo.rgb m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On 5/17/04 at 12:58 PM Chris Metzler wrote: At any rate, as far as manually placing them and putting that capability in TaxiDraw, sure, that'd be cool! In the short-term, though, I have another request: a scrollbar slider for the taxiway list brought up with the z key. You can use numpad 9 and 3 to scroll the list up and down. (Numpad 8 and 2 move a selected taxiway up and down in the order). I agree it's not very intuitive though - I'll try and put in a proper list control with automatic scroll bar for the next release. To learn how to use TaxiDraw, I wanted to pick an airport and get going. Since the tutorial docs that come with fgfs suggest starting out at KSQL, I decided to work on that one. It had some taxiway/ apron work already, but it didn't match the pics at all. So I went to work. But to do it right, there end up being a ton of taxiways. There's a taxiway perpendicular to the runway at each end (2). There's one that runs parallel to the runway on the southwest side (3). There's one that runs parallel to the runway on the northeast side; but it changes surface partway down, and then turns and goes into a runway end at an angle, so that's three more (6). There are five short taxiways used to access the runway from the main taxiways: two that go all the way across, from parallel taxiway to parallel taxiway; one that connects the runway with one taxiway; and two that are angular (11). And with that layout, there are 39 corners that (according to the pictures) ought to be rounded; and using three at each corner, that's 117 more taxiways (128). And we haven't even got to the aprons yet. With these kind of numbers, using the taxiway list to set the taxiway ordering doesn't work, because half the taxiway list is off the screen. A slider would help. Incidentally, this long list is an illustration of why #2, above, might be a good idea in general; would Robin Peel really want those 117 small taxiways put in purely for aesthetic reasons? I'm not entirely sure where the acceptable number of segments / amount of detail trade-off will end up. Jon Stockill has done some very detailed UK military layouts with hundreds of segments to show all the dispersal areas, but I don't think he's submitted them yet. So far the airports I have done haven't had more than about 100 segments, less than some of the default ones. I deliberately avoided KSQL after seeing the massive extra aprons on the aerial photos! Hopefully what is acceptable to Robin in terms of number of segments vs. detail vs. accuracy will become more clear after I get some X-Plane export filters in and users start submitting in a format he can accept. Perhaps a better way of handling curved intersection corners would be to generate for each intersection a set of four boolean flags indicating whether or not that corner should be rounded, and let TerraGear round the corners when it puts the taxiways into the scenery? But I bet that requires hard work on their part, so maybe not such a good idea. It's a good idea, but as you say requires a lot coding in TerraGear as well. Better handling of taxiway/taxiway and taxiway/runway intersections is something that's been mulling in the back of my mind for ages, but realistically I haven't got a chance of finding time to work on it in the foreseeable future. It would still be a job to get them placed automatically without them overlapping other taxiways or runways, and that would probably require coding in TerraGear. Yeah, it does seem like a hard problem. And in the long run -- in some future world where all the scenery everywhere is in wonderfully perfect, local idiosyncratic shape -- I guess we wouldn't want auto-generated signage because they differ somewhat in style from place to place. One other sign that would be nice to generate (with the same avoiding taxiways problem) would be the signs that indicate how much runway is left. There's lots of room for improvement to the airport modelling. I guess that ultimately artistic orientated folk will start doing custom scenery for certain areas, rather than relying on the automated processing of compiled data as we do at the moment. Adding buildings to all the base-area scenery airports would make a hell of a difference, and the results could go in CVS. Yeah. I'd like to do this; I'm using it as an excuse to learn Blender. The problem I have at this point is good source photos. As far as I can tell, a lot of US GA airports have large numbers of fairly generic, low, white or light-grey hangars. It would be very good to get some of these into the default GA airports, and wouldn't really require fancy textures from photos. Oh, I agree completely, and that's where I'm starting as I learn this stuff. At the same time, though, I bet there's a natural tendancy for all of us to want to fly at airports we're familiar with in real life. Giving them scenery that, in real life, makes those airports distinctive is
Re: [Flightgear-devel] RFD: JSBSim Cessna 172p stability patch
Jon Berndt wrote: Thanks, David. There are a couple of things I can think of to do, here. One is that I sure wish I had time to make a DATCOM model of the C-172 that could give me some aero data for comparison. But with my schedule now I can't make any promises, but I will get to this someday! The second comment is that it ought to be possible to get some real numbers for you pretty quickly from comparable aircraft. I think I can do that tonight or tomorrow. Third, there are some equations that ought to shed some light on things. Fourth, it will be interesting to see if pilot perceptions suggest altering all/most coefficients in the same direction for all aircraft in order to give the perception of proper flight characteristics. That is a tricky issue, because using spring-loaded controllers gives a significantly different feel than fully-loaded aircraft controls, and there is always a danger of altering the flight characteristics to compensate for the control differences. To try to avoid that problem this time, I tried to concentrate on rates (how fast the plane could bank, pitch, and yaw), coupling (how much adverse yaw a particular bank causes and how much bank a particular yaw causes), and recovery (how the plane recovers from a yaw or pitch disturbance). I deliberately ignored control feel. The model I posted seems a lot closer to what I remember of the 172 and what I observe in my PA-28, but unfortunately, I do not currently have measurements to test it against. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: JSBSim Cessna 172p stability patch
Jon Berndt wrote: Given these numbers I'd suspect that if there is a problem, perhaps we need to review our MoI's. That makes a lot of sense -- I was worried that the damping numbers were masking a different problem. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: JSBSim Cessna 172p stability patch
That is a tricky issue, because using spring-loaded controllers gives a significantly different feel than fully-loaded aircraft controls, and there is always a danger of altering the flight characteristics to compensate for the control differences. FWIW, I sent an email to Cessna customer support last night asking them about the availability of some aero and mass props data for their C-172 - or at least Ixx and Clp. I wonder if I will even hear back. To try to avoid that problem this time, I tried to concentrate on rates (how fast the plane could bank, pitch, and yaw), coupling (how much adverse yaw a particular bank causes and how much bank a particular yaw causes), and recovery (how the plane recovers from a yaw or pitch disturbance). I deliberately ignored control feel. The model I posted seems a lot closer to what I remember of the 172 and what I observe in my PA-28, but unfortunately, I do not currently have measurements to test it against. I have data for the PA-28 somewhere. I ought to validate the PA-28 JSBSim mode we have and see how they all compare. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: making instrument scales with MetaPost
On Thursday 20 May 2004 08:13, Melchior FRANZ wrote: Looks like Maik's rotor RPM numbers are off (442 RPM). I can't make sense of the dual tacho. What doesn't make sense? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
I'm under a serious spam attack from an infected computer of someone on the list. Here is where the spam is originating: user-24-214-247-18.knology.net Many of the spams are arriving with Curt's e-mail address spoofed on them, and unfortunately, baron.me.umn.edu seems happy to relay them for the infected computer. In fact, baron is relaying *all* of the spam, even the stuff return addresses like [EMAIL PROTECTED] All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
David Megginson wrote: I'm under a serious spam attack from an infected computer of someone on the list. Here is where the spam is originating: user-24-214-247-18.knology.net Many of the spams are arriving with Curt's e-mail address spoofed on them, and unfortunately, baron.me.umn.edu seems happy to relay them for the infected computer. In fact, baron is relaying *all* of the spam, even the stuff return addresses like [EMAIL PROTECTED] Going on the defensive here. mail.flightgear.org is *not* an open relay. It only accepts mail for addresses @flightgear.org. It does *not* accept email from an arbitrary location and forward to any other arbitrary location. The big problem is that these viruses can leverage the user's address book to spoof plausible to/from addresses and they get lucky far too often. The spammers/viruses are nearly making email useless :-( I average receiving a new spam mesage about every 5 minutes. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: making instrument scales with MetaPost
Melchior FRANZ said: * Jim Wilson -- Thursday 20 May 2004 01:46: Melchior FRANZ said: Here's a small MetaPost file that I used to make the Bo105 rotor tacho (which is totally made up; need some expert advice first): Check out: http://www.airliners.net/open.file/438320/L/ Hey, very cool. The best cockpit photo that I've seen so far. How could I miss that. The sad thing is that none of the photos agree on instrument layout. (I miss an ADF, btw.) Looks like Maik's rotor RPM numbers are off (442 RPM). I can't make sense of the dual tacho. The rotor can exceed the drive shaft speed (e.g. autorotation). Is that what you are asking? Those ticks are a percent of something, note that label Percent RPM on the face in that pic. I think online somewhere you might find a helicopter manual for Fly 2 that explains some of this. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] animation bug
I think I found another bug in the animation code. Here is a snippet of the xml. This code (with the comment) causes both of the right hand objects to move when the right brake is applied. This does not happen to the left pedal arm since I commented out the left pedal from the rudder animation. Somehow grouping two objects in a rotate causes any subsequent rotates performed on one of those objects to be performed on both. The rudder animations work fine (except for my debugging comment). E-mail me if you want the whole aircraft, it's a little under two megs. I am putting in a workaround, but saving the files that show this behavior. Josh !-- Pedals -- animation typerotate/type object-nameLeftPedal/object-name propertycontrols/gear/brake-left/property factor-20/factor center x-m1.28/x-m y-m0.0/y-m z-m-0.185/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type object-nameRightPedal/object-name propertycontrols/gear/brake-right/property factor-20/factor center x-m1.28/x-m y-m0.0/y-m z-m-0.185/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type !-- object-nameLeftPedal/object-name -- object-nameLeftPedalArm/object-name propertycontrols/flight/rudder/property factor-10/factor center x-m1.408/x-m y-m0.0/y-m z-m0.152/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type object-nameRightPedal/object-name object-nameRightPedalArm/object-name propertycontrols/flight/rudder/property factor10/factor center x-m1.408/x-m y-m0.0/y-m z-m0.152/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
* Al West -- Thursday 20 May 2004 14:43: On Thursday 20 May 2004 08:13, Melchior FRANZ wrote: Looks like Maik's rotor RPM numbers are off (442 RPM). I can't make sense of the dual tacho. What doesn't make sense? The ticks are labeled from 0 to 140, with a lot of colored marks around 100. Where would 442 fit into this range? It's not guaranteed that Maik's 442 is right, of course. I'll ask my adviser. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
* Jim Wilson -- Thursday 20 May 2004 15:18: The rotor can exceed the drive shaft speed (e.g. autorotation). Is that what you are asking? No, I couldn't see where 442 would fit into that scale, and what 140 should stand for (140 RPM? ... too low; or 14000 RPM? ... too high), but ... Those ticks are a percent of something, note that label Percent RPM on the face in that pic. hh ... now that makes sense. I couldn't read the word PERCENT. I guess one needs to be native English speaker to be able to decipher that. OK, I'll do this instrument now -- only the rotor hand, though, because there's no turbine RPM in YASim (?). Maybe I'll make the turbine RPM up with Nasal ... I think online somewhere you might find a helicopter manual for Fly 2 that explains some of this. Hey, I have a real Bo105 pilot at hand since a few days. Just need to ask him and wait for response. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
Curtis L. Olson said: David Megginson wrote: I'm under a serious spam attack from an infected computer of someone on the list. Here is where the spam is originating: user-24-214-247-18.knology.net Many of the spams are arriving with Curt's e-mail address spoofed on them, and unfortunately, baron.me.umn.edu seems happy to relay them for the infected computer. In fact, baron is relaying *all* of the spam, even the stuff return addresses like [EMAIL PROTECTED] Going on the defensive here. mail.flightgear.org is *not* an open relay. It only accepts mail for addresses @flightgear.org. It does *not* accept email from an arbitrary location and forward to any other arbitrary location. The big problem is that these viruses can leverage the user's address book to spoof plausible to/from addresses and they get lucky far too often. The spammers/viruses are nearly making email useless :-( I average receiving a new spam mesage about every 5 minutes. We're getting creamed here but not seeing most of it. SpamCop which we've been using for a while, does a good job of blocking those idiot virus spams from misconfigured mail servers. Of course this has started producing some (a very small number) complaints as legit servers get listed. It is currently getting 25 per hour (based on prior 5 weeks average) and that is double what it was a month ago. Also I've added a slew of procmail rules to filter out the stupid subjects they use (e.g. re: Thank You!). After all that I still end up manually clearing about 25 a day. On the Postgres list someone mentioned that he discovered a signature in the HELO that he was able to use to trap most virus emails. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation bug
Josh Babcock said: I think I found another bug in the animation code. Here is a snippet of the xml. This code (with the comment) causes both of the right hand objects to move when the right brake is applied. This does not happen to the left pedal arm since I commented out the left pedal from the rudder animation. Somehow grouping two objects in a rotate causes any subsequent rotates performed on one of those objects to be performed on both. The rudder animations work fine (except for my debugging comment). E-mail me if you want the whole aircraft, it's a little under two megs. I am putting in a workaround, but saving the files that show this behavior. Josh !-- Pedals -- animation typerotate/type object-nameLeftPedal/object-name propertycontrols/gear/brake-left/property factor-20/factor center x-m1.28/x-m y-m0.0/y-m z-m-0.185/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type object-nameRightPedal/object-name propertycontrols/gear/brake-right/property factor-20/factor center x-m1.28/x-m y-m0.0/y-m z-m-0.185/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type !-- object-nameLeftPedal/object-name -- object-nameLeftPedalArm/object-name propertycontrols/flight/rudder/property factor-10/factor center x-m1.408/x-m y-m0.0/y-m z-m0.152/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type object-nameRightPedal/object-name object-nameRightPedalArm/object-name propertycontrols/flight/rudder/property factor10/factor center x-m1.408/x-m y-m0.0/y-m z-m0.152/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation Keep in mind that a single callback is generated for each animation group. What this means is if you combine together two objects in an animation, then that group will end up inheriting whatever has already been defined as an animation callback for the first one in the list. I think that accurately describes the effect. Play around with defining the grouped animation before the individual object animation. Or maybe even changing the order of the objects in the group (so that something that doesn't already have a callback is listed first). This was probably designed this way to be more efficient. The alternative would be to apply a separate callback for each object in the group. There might be other issues...not sure. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: making instrument scales with MetaPost
Melchior FRANZ wrote * Jim Wilson -- Thursday 20 May 2004 15:18: The rotor can exceed the drive shaft speed (e.g. autorotation). Is that what you are asking? No, I couldn't see where 442 would fit into that scale, and what 140 should stand for (140 RPM? ... too low; or 14000 RPM? ... too high), but ... Those ticks are a percent of something, note that label Percent RPM on the face in that pic. hh ... now that makes sense. I couldn't read the word PERCENT. I guess one needs to be native English speaker to be able to decipher that. OK, I'll do this instrument now -- only the rotor hand, though, because there's no turbine RPM in YASim (?). Maybe I'll make the turbine RPM up with Nasal ... I think online somewhere you might find a helicopter manual for Fly 2 that explains some of this. Hey, I have a real Bo105 pilot at hand since a few days. Just need to ask him and wait for response. :-) N1 N2 ? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
Jim Wilson wrote: Curtis L. Olson said: David Megginson wrote: I'm under a serious spam attack from an infected computer of someone on the list. Here is where the spam is originating: user-24-214-247-18.knology.net Many of the spams are arriving with Curt's e-mail address spoofed on them, and unfortunately, baron.me.umn.edu seems happy to relay them for the infected computer. In fact, baron is relaying *all* of the spam, even the stuff return addresses like [EMAIL PROTECTED] Going on the defensive here. mail.flightgear.org is *not* an open relay. It only accepts mail for addresses @flightgear.org. It does *not* accept email from an arbitrary location and forward to any other arbitrary location. The big problem is that these viruses can leverage the user's address book to spoof plausible to/from addresses and they get lucky far too often. The spammers/viruses are nearly making email useless :-( I average receiving a new spam mesage about every 5 minutes. We're getting creamed here but not seeing most of it. SpamCop which we've been using for a while, does a good job of blocking those idiot virus spams from misconfigured mail servers. Of course this has started producing some (a very small number) complaints as legit servers get listed. It is currently getting 25 per hour (based on prior 5 weeks average) and that is double what it was a month ago. Also I've added a slew of procmail rules to filter out the stupid subjects they use (e.g. re: Thank You!). After all that I still end up manually clearing about 25 a day. On the Postgres list someone mentioned that he discovered a signature in the HELO that he was able to use to trap most virus emails. I use popfile under windows and I must say that it is able to filter nearly 100% of junk mail and viruses popfile is multi platform and can be found at sourceforge -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: making instrument scales with MetaPost
On Thursday 20 May 2004 14:02, Melchior FRANZ wrote: * Al West -- Thursday 20 May 2004 14:43: On Thursday 20 May 2004 08:13, Melchior FRANZ wrote: Looks like Maik's rotor RPM numbers are off (442 RPM). I can't make sense of the dual tacho. What doesn't make sense? The ticks are labeled from 0 to 140, with a lot of colored marks around 100. Where would 442 fit into this range? It's not guaranteed that Maik's 442 is right, of course. I'll ask my adviser. It's showing Percentage RPM. Some marks of bo105 have an autothrottle to maintain Rotor RPM which is what some of the coloured marks represent. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: FlightGear news letter
I hope not to be late with my suggestions for the upcoming FG newsletter. Title: Higher, Faster, Farther. But Simulated. I think this reflects what FG is all about: aviation and simulation Size Format Frequency: Looking at JSBSim newsletter, I think that's pretty cool: 4 pages (no more) in US Letter or A4 size, and released quarterly (4 issues per year is quite a number, specially to prepare it). One thing I'll add to the .PDF downloadable file, is another .PDF file with two pages (A3 size) in order to be able to print only one A3 sheet and then fold it to have a real newsletter in just one piece (not two separated sheets like JSBSim right know) Sections Contents: 1. A definitive main section per issue, as the In Depth from JSBSim. 2. Upcoming Events, about aviation and/or simulation events, shows, congress, fairs during the issue's quarter 3. Hardware Corner, a place to review gadgets, joysticks, video cards, etc. thier performance and the way to make them work with FG 4. Technology matters, a revision of some item about simulation technology (i.e. weather, traffic control, FDM, etc.). 5. Who's who, an interview/bio with one guy at a time from the people involved with the project. Their experiences with FG, their motivations, contributions, etc. 6. Software tricks, tips and techniques about programming, related libraries, how to compile FG under certain platform, etc. Well, although with no much spare time, I'll try to help with the newsletter somehow. Just my 5 cents. Regards, Pablo. - ¿Todavía no navegás con Keko? Hacé click aquí: http://www.keko.com.ar ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation bug
Jim Wilson wrote: Josh Babcock said: I think I found another bug in the animation code. Here is a snippet of the xml. This code (with the comment) causes both of the right hand objects to move when the right brake is applied. This does not happen to the left pedal arm since I commented out the left pedal from the rudder animation. Somehow grouping two objects in a rotate causes any subsequent rotates performed on one of those objects to be performed on both. The rudder animations work fine (except for my debugging comment). E-mail me if you want the whole aircraft, it's a little under two megs. I am putting in a workaround, but saving the files that show this behavior. Josh !-- Pedals -- animation typerotate/type object-nameLeftPedal/object-name propertycontrols/gear/brake-left/property factor-20/factor center x-m1.28/x-m y-m0.0/y-m z-m-0.185/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type object-nameRightPedal/object-name propertycontrols/gear/brake-right/property factor-20/factor center x-m1.28/x-m y-m0.0/y-m z-m-0.185/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type !-- object-nameLeftPedal/object-name -- object-nameLeftPedalArm/object-name propertycontrols/flight/rudder/property factor-10/factor center x-m1.408/x-m y-m0.0/y-m z-m0.152/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type object-nameRightPedal/object-name object-nameRightPedalArm/object-name propertycontrols/flight/rudder/property factor10/factor center x-m1.408/x-m y-m0.0/y-m z-m0.152/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation Keep in mind that a single callback is generated for each animation group. What this means is if you combine together two objects in an animation, then that group will end up inheriting whatever has already been defined as an animation callback for the first one in the list. I think that accurately describes the effect. Play around with defining the grouped animation before the individual object animation. Or maybe even changing the order of the objects in the group (so that something that doesn't already have a callback is listed first). This was probably designed this way to be more efficient. The alternative would be to apply a separate callback for each object in the group. There might be other issues...not sure. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Oops, my bad. I already dealt with this in the yoke, but forgot. The order that the definitions has to go in are counter-intuitive for me, and I didn't think to put the parent before the child. I guess I still don't really understand how the callbacks work, but this problem is fixed. The order of the objects within the animation doesn't seem to matter here, I tried it both ways just now. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
* Vivian Meazza -- Thursday 20 May 2004 16:07: Melchior FRANZ wrote only the rotor hand, though, because there's no turbine RPM in YASim (?). Maybe I'll make the turbine RPM up with Nasal ... [...] N1 N2 ? Yes, but there's no way to start/stop the turbines in YASim, so the values don't increase/decrease when the turbine is spooling up/down according to the sound. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: making instrument scales with MetaPost
Melchior FRANZ wrote: hh ... now that makes sense. I couldn't read the word PERCENT. I guess one needs to be native English speaker to be able to decipher that. OK, I'll do this instrument now -- only the rotor hand, though, because there's no turbine RPM in YASim (?). Maybe I'll make the turbine RPM up with Nasal ... Well, as of last week, there *is* a working turbine RPM output. The problem is that there's no turbine model in the helicopter stuff. The engine is essentially hardcoded into the Rotor class, it can't be shared with the rest of the code. What needs to happen is that the rotor code should simply export a torque, and let the external code (either PropEngine, or something like it) do the RPM integration. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: making instrument scales with MetaPost
Melchior FRANZ wrote * Vivian Meazza -- Thursday 20 May 2004 16:07: Melchior FRANZ wrote only the rotor hand, though, because there's no turbine RPM in YASim (?). Maybe I'll make the turbine RPM up with Nasal ... [...] N1 N2 ? Yes, but there's no way to start/stop the turbines in YASim, so the values don't increase/decrease when the turbine is spooling up/down according to the sound. m. They go from idle to max, isn't that enough? V ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
* Vivian Meazza -- Thursday 20 May 2004 17:00: [turbine RPM] They go from idle to max, isn't that enough? no m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: JSBSim Cessna 172p stability patch
On Thu, 2004-05-20 at 05:17, David Megginson wrote: Jon Berndt wrote: Thanks, David. There are a couple of things I can think of to do, here. One is that I sure wish I had time to make a DATCOM model of the C-172 that could give me some aero data for comparison. But with my schedule now I can't make any promises, but I will get to this someday! The second comment is that it ought to be possible to get some real numbers for you pretty quickly from comparable aircraft. I think I can do that tonight or tomorrow. Third, there are some equations that ought to shed some light on things. Fourth, it will be interesting to see if pilot perceptions suggest altering all/most coefficients in the same direction for all aircraft in order to give the perception of proper flight characteristics. That is a tricky issue, because using spring-loaded controllers gives a significantly different feel than fully-loaded aircraft controls, and there is always a danger of altering the flight characteristics to compensate for the control differences. To try to avoid that problem this time, I tried to concentrate on rates (how fast the plane could bank, pitch, and yaw), coupling (how much adverse yaw a particular bank causes and how much bank a particular yaw causes), and recovery (how the plane recovers from a yaw or pitch disturbance). I deliberately ignored control feel. The model I posted seems a lot closer to what I remember of the 172 and what I observe in my PA-28, but unfortunately, I do not currently have measurements to test it against. Another good way to take the controls out of it are with the Dutch roll and phugoid characteristics. Once the initial rudder and elevator inputs, respectively, are complete the aircraft response should be about the same. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: making instrument scales with MetaPost
OK, here's a new version, just so you can see how easy instrument face creation with MetaPost is. Note that there's a function @() defined, that maps the real instrument angles to MetaPost angles. So I could directly input all the values as I saw them on the cockpit photo. Also, the program outputs the correct fgfs angles for the *.xml interpolation table. (Modeled after http://www.airliners.net/open.file/438320/L/) http://members.aon.at/mfranz/bo105.mp (3.3kB) http://members.aon.at/mfranz/tach.png (27kB) m. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
David Luff wrote: I'm not entirely sure where the acceptable number of segments / amount of detail trade-off will end up. Jon Stockill has done some very detailed UK military layouts with hundreds of segments to show all the dispersal areas, but I don't think he's submitted them yet. So far the airports I have done You told me to wait for the X-Plane export in the next version :-) haven't had more than about 100 segments, less than some of the default ones. I deliberately avoided KSQL after seeing the massive extra aprons on the aerial photos! Hopefully what is acceptable to Robin in terms of number of segments vs. detail vs. accuracy will become more clear after I get some X-Plane export filters in and users start submitting in a format he can accept. It won't be too hard to simplify my stuff if he decides there's too much detail there. Of course. I only say the default airports because then the changes can be easily shown to everyone, by having them committed to CVS. I hope that eventually people will start making detailled representations of their local areas available, in a similar manner to MSFS scenery designers. That's my plan - the taxiways just seemed like a good place to start. I've got a reasonable representation of a t2 hangar now too, and will be working on a c type when I have a few more details, so I can start populating airfields with buildings. -- Jon Stockill ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] animation bug
Vivian Meazza said: Josh Babcock wrote: I think I found another bug in the animation code. Here is a snippet of the xml. This code (with the comment) causes both of the right hand objects to move when the right brake is applied. This does not happen to the left pedal arm since I commented out the left pedal from the rudder animation. Somehow grouping two objects in a rotate causes any subsequent rotates performed on one of those objects to be performed on both. The rudder animations work fine (except for my debugging comment). E-mail me if you want the whole aircraft, it's a little under two megs. I am putting in a workaround, but saving the files that show this behavior. Josh !-- Pedals -- animation typerotate/type object-nameLeftPedal/object-name propertycontrols/gear/brake-left/property factor-20/factor center x-m1.28/x-m y-m0.0/y-m z-m-0.185/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type object-nameRightPedal/object-name propertycontrols/gear/brake-right/property factor-20/factor center x-m1.28/x-m y-m0.0/y-m z-m-0.185/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type !-- object-nameLeftPedal/object-name -- object-nameLeftPedalArm/object-name propertycontrols/flight/rudder/property factor-10/factor center x-m1.408/x-m y-m0.0/y-m z-m0.152/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation animation typerotate/type object-nameRightPedal/object-name object-nameRightPedalArm/object-name propertycontrols/flight/rudder/property factor10/factor center x-m1.408/x-m y-m0.0/y-m z-m0.152/z-m /center axis x0.0/x y1.0/y z0.0/z /axis /animation If you link 2 objects in any animation they are linked in all animations. Just separate the 2 objects into different animations. A feature not a bug :-) That's not exactly true. See my earlier post and other past discussion of this on the list. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Atlas CVS: fails to render 1024x1024 png maps
On Thursday 20 May 2004 08:43, Chris Metzler wrote: Hi. I should probably be asking this in atlas-devel, but at first glance it looks pretty dead there; and I'm guessing someone here has encountered this, or can easily. I recently built Atlas from CVS (that took some work, but that's a different conversation). I then set about generating maps, using the philosophy outlined on the Atlas website -- some 1024x1024 images for highres, and 64x64 images for lowres. See the bottom of http://atlas.sourceforge.net/index.php?page=run under Map Resolutions. The maps generated fine; looking at the ..png's in an image viewer, they all look gorgeous. But using them in Atlas, I encounter trouble. As near as I can tell, Atlas is incapable of rendering 1024x1024 .png images. Here's what I find. 1. if image files for a location are not present, Atlas shows the airports and navaids on top of a light blue background (sensible, since the standard FlightGear assumption is that missing scenery is water). The same is true if the needed files are present, but are *not* .pngs (e.g. I just copy some random file in and give it an appropriate name, so that Atlas can try to load it and fail). 2. if the image files for a location *are* present, but are 1024x1024, Atlas shows an off-white background, with the airports/ navaids on top of that. 3. if I zoom out until I cross the highres/lowres threshhold of 1:100, Atlas tells me it's moving to the low-resolution maps, and *bingo*, I have maps as a background. 4. if I regenerate the low-resolution maps at a higher resolution, I get the same result as #3, UP TO the low-resolution maps having a size of 512x512. If I make the low-resolution maps at 1024x1024, run Atlas, and zoom out to where the low-resolution maps should be used, I have an off-white background. So it seems that 1024x1024 files are the problem. Does anyone else see this with a current Atlas from CVS? Any suggestions on what I can do to fix this? Obviously since the webpage was written as it was, it was intended that making and using 1024x1024 .png files be possible. What can I do to make this work? Thanks for advice, -c P.S. Oddly, when *making* the 1024x1024 images, Map is able to display them just fine. It's only when Atlas tries to do so that problems occur. I think it's always been like that - I've never been able to use 1024x1024 maps either. As you've found, 512x512 maps are ok, so I use that res. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
On Thursday 20 May 2004 13:51, David Megginson wrote: I'm under a serious spam attack from an infected computer of someone on the list. Here is where the spam is originating: user-24-214-247-18.knology.net Many of the spams are arriving with Curt's e-mail address spoofed on them, and unfortunately, baron.me.umn.edu seems happy to relay them for the infected computer. In fact, baron is relaying *all* of the spam, even the stuff return addresses like [EMAIL PROTECTED] All the best, David These e-mails almost certainly have spoofed 'From' addresses and just about the only thing you can be sure of is that they don't come from where they say they do. The addresses are harvested from websites and publicly viewable mailing list archives. In addition to the ones from list members here, I also get lots that have been allegedly sent from my domain using unique contact e-mail addresses that I never use for sending e-mail, which are then bounced from the mail servers and 'returned'. I understand that this could be solved if the ISPs used SMTP authorisation, to confirm the originating address but they seem reluctant to do so. In the mean time there's little that can be done about it. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
Lee Elliott wrote: I'm under a serious spam attack from an infected computer of someone on the list. Here is where the spam is originating: user-24-214-247-18.knology.net These e-mails almost certainly have spoofed 'From' addresses and just about the only thing you can be sure of is that they don't come from where they say they do. That's not the return address -- it's the last Received: header (i.e. the first hop that the e-mail took). The infected user almost certainly had this domain, though his or her ISP might have a different name. If anyone one the list has the IP address 24.214.247.18 right now and is unfortunate enough to use Windows and Outlook, please disconnect your ethernet cable immediately and then get help disinfecting your system. In the mean time there's little that can be done about it. On a case-by-case basis, you can hunt down the individual infected machines by examining the headers. It gets tiresome after a while, though, especially when I was receiving a couple of thousand of these a day. The worst b*ds in this whole mess are not the virus writers, slimey as they are, or Microsoft, incompetent as they are; rather, it's the enterprise anti-virus software vendors, who sell systems that automatically send useless virus warnings every time a message like this comes. Either (a) they're complete idiots who couldn't be trusted with the washroom key at a gas station, much less corporate network security; or (b) they know perfectly well that they're making the problem worse and that their warnings are going to the wrong people, but cannot resist the free advertising (but it's not SPAM, it's a VIRUS WARNING!). I'm leaning towards (b), because (a) scares me even more. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
On Thu, 20 May 2004 15:34:02 -0400 David Megginson [EMAIL PROTECTED] wrote: Lee Elliott wrote: I'm under a serious spam attack from an infected computer of someone on thelist. Here is where the spam is originating: user-24-214-247-18.knology.net These e-mails almost certainly have spoofed 'From' addresses and just about the only thing you can be sure of is that they don't come from where they say they do. That's not the return address -- it's the last Received: header (i.e. the first hop that the e-mail took). The infected user almost certainly had this domain, though his or her ISP might have a different name. If anyone one the list has the IP address 24.214.247.18 right now and is unfortunate enough to use Windows and Outlook, please disconnect your ethernet cable immediately and then get help disinfecting your system. Right now, that address doesn't respond to pings. A traceroute suggests that it's dynamically assigned to users in Florida, and possibly south Georgia. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp7hTIMmYiY4.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack
David Megginson wrote: The worst b*ds in this whole mess are [...] the enterprise anti-virus software vendors, who sell systems that automatically send useless virus warnings every time a message like this comes. Either (a) they're complete idiots who couldn't be trusted with the washroom key at a gas station, much less corporate network security; Would this be a good time to point out that my day job is at McAfee Security (the artist formerly known as Network Associates)? :) I will say that I have nothing to do with email worms, though. My group does embedded stuff. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
On Thursday 20 May 2004 8:48 pm, Chris Metzler wrote: On Thu, 20 May 2004 15:34:02 -0400 David Megginson [EMAIL PROTECTED] wrote: snip If anyone one the list has the IP address 24.214.247.18 right now and is unfortunate enough to use Windows and Outlook, please disconnect your ethernet cable immediately and then get help disinfecting your system. Right now, that address doesn't respond to pings. A traceroute suggests that it's dynamically assigned to users in Florida, and possibly south Georgia. Geobytes http://www.geobytes.com suggests a 98% probability that this IP address is assigned in Panama City, Florida. Ths is supported by the last hop I get on a traceroute from here in the UK qam1-1-3.Panc.FL.US.Knology.Net (24.214.0.141) Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack; open relay at baron.me.umn.edu
On Thu, 20 May 2004 21:26:39 +0100 Jonathan Richards [EMAIL PROTECTED] wrote: On Thursday 20 May 2004 8:48 pm, Chris Metzler wrote: On Thu, 20 May 2004 15:34:02 -0400 David Megginson [EMAIL PROTECTED] wrote: snip If anyone one the list has the IP address 24.214.247.18 right now and is unfortunate enough to use Windows and Outlook, please disconnect your ethernet cable immediately and then get help disinfecting your system. Right now, that address doesn't respond to pings. A traceroute suggests that it's dynamically assigned to users in Florida, and possibly south Georgia. Geobytes http://www.geobytes.com suggests a 98% probability that this IP address is assigned in Panama City, Florida. Ths is supported by the last hop I get on a traceroute from here in the UK qam1-1-3.Panc.FL.US.Knology.Net (24.214.0.141) Right. I did the traceroute to the same point, but couldn't guess what town Panc referred to. Panama City makes good sense. But, as you note, that's where it's being assigned, but not necessarily where it's being assigned *to*. Some customers of my ISP that live in Pennsylvania get their IPs assigned by a POP in Washington, D.C; hence my comment about south Georgia. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp5voxDQxR76.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WARNING: Flightgear spam attack
Andy Ross wrote: (a) they're complete idiots who couldn't be trusted with the washroom key at a gas station, much less corporate network security; Would this be a good time to point out that my day job is at McAfee Security (the artist formerly known as Network Associates)? :) OK, I'll revise that -- all of them except Andy are complete idiots who couldn't be trusted with the washroom key at a gas station. (Or, in other words) all right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim C-172 Performance
Well, I got a note back from Cessna and (as I pretty much expected) they were tight-lipped about supplying any aero/mass props data, saying instead that the owner's manual was about all I could get. After thinking about this some more, there are three possibilities I can see for any perceived problems: 1) The stability derivatives are indeed low-balled. I find this unlikely, as the numbers for rate-damping are in line with other aircraft in the same class. 2) The MoIs are too low. This is possible - I have not yet checked these out, but again I believe we will find these numbers to be pretty good. 3) This one just occurred to me: I wonder if the control inputs from stick and rudder are linear? Or, are they perhaps graduated? In our FCS model, we take the joystick input and map it linearly to the range of values that the control surfaces can see - essentially. It might make sense that for small excursions about center (no control inputs) that control movements are kept small, but as one makes bigger inputs, that the gain increases. Does anyone have any comments on this? If this was in fact the case, it would not be difficult to modify our control system to model this. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get cesna to follow a set of way points.
Hi Jim, I was the one who asked this question but when i tried to implement the solution it resulted in the same flight behaviour. I will detail the changes i implemented so you can see if i did anything incorrectly. 1) I changed, in file Aircraft/c172/c172-610x-null-set.xml, pathAircraft/c172/610x-autopilot.xml/path to pathAircraft/Generic/generic-autopilot.xml/path 2) I call the program passing in aircraft=c172. When a waypoint is added the plane still flys in circles and does not fly towards the waypoint, Seamus On Thu, 20 May 2004, Jim Wilson wrote: Just change the autopilot back to the generic version in the *-set.xml file. This was answered within the last couple of weeks but maybe it was someone else asking the same question. Best, Jim Seamus Thomas Carroll said: I went out of town for a coulple of weeks and looking through my list of emails i dont think a recieved a response to the question below. I would like the cesna to be able to follow a set of waypoints but due to the new autopilot this no longer seems to be a possiblity. Any thoughts on how i would be able to achieve this functionality? Seamus On Wed, 5 May 2004, Seamus Thomas Carroll wrote: Are there plans to add a route manager to the KAP140? If not what property do I change to use the generic autopilot? I have tried different changing values in different xml files but with no success. Seamus On Wed, 5 May 2004, Roy Vegard Ovesen wrote: On Wednesday 05 May 2004 06:17, Seamus Thomas Carroll wrote: To test if a problem resides with the cesna autopilot i tested using Add Waypoint and instead of the autopilot guiding the plane to the waypoint it just flys in cirlces until it spirals into the ground. This autopilot with the cesna did work correctly that last time I tried it a couple of weeks ago. Has someone changed cesna autopilot config file to cause this incorrect behaviour? The default Cessna (--aircraft=c172-3d and c172-2dpanel) have changed autopilot from the generic to a KAP140 autopilot. A new instrument has been added to the cockpit and this should be visible below the ADF radio. The KAP140 does not have a route manager so consequently you can not define a route for it to fly. For instructions on how to operate the KAP140 you should download the Pilot Guide from the Bendix/King website. Is it a problem with the set up on my end? You can of course edit your *set.xml file to change the autopilot back to the generic. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] multiple windows problem again - heading still not working
Hi I posted a message that adjusting the offset for the side windows is not working with the new version. Curt suggested a method. (See the attachment). What he suggested works for the pitch axis, but not for the heading. I tried both the Linux and Windows version, but nothing works. Would any developer please confirm this? - Keeyoung Message: 1 Date: Wed, 12 May 2004 18:41:31 +0900 From: Keeyoung Choi [EMAIL PROTECTED] Subject: [Flightgear-devel] multiple windows - offset setting not working To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi, I posted this message to the user's group, but no one responded there. My department has a 3-screen setup for flightgear. With the old versions, it was possible to set the viewing angles for the right and left screen using command line option. However, with the current version (or recent few versions maybe), it doesn't work. I have to mannually adjust the offset. Could any developer take a look at this? Thanks. - Keeyoung -- Message: 2 Date: Wed, 12 May 2004 07:06:38 -0500 From: Curtis L. Olson [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] multiple windows - offset setting not working To: FlightGear developers discussions [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Keeyoung Choi wrote: I posted this message to the user's group, but no one responded there. My department has a 3-screen setup for flightgear. With the old versions, it was possible to set the viewing angles for the right and left screen using command line option. However, with the current version (or recent few versions maybe), it doesn't work. I have to mannually adjust the offset. Could any developer take a look at this? Thanks. In current versions you need to use something like: --prop:/sim/view/config/heading-offset-deg=45 --prop:/sim/view/config/pitch-offset-deg=3 Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get cesna to follow a set of way points.
On Thursday 20 May 2004 23:50, Seamus Thomas Carroll wrote: Hi Jim, I was the one who asked this question but when i tried to implement the solution it resulted in the same flight behaviour. I will detail the changes i implemented so you can see if i did anything incorrectly. 1) I changed, in file Aircraft/c172/c172-610x-null-set.xml, pathAircraft/c172/610x-autopilot.xml/path to pathAircraft/Generic/generic-autopilot.xml/path Did you see?: http://baron.flightgear.org/pipermail/flightgear-devel/2004-May/028021.html The *-set.xml file for --aircraft=c172 is actually Aircraft/c172p/ c172p-set.xml. This is the file that you have to modify. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
Jon S Berndt wrote: 3) This one just occurred to me: I wonder if the control inputs from stick and rudder are linear? Or, are they perhaps graduated? The controller devices can be all over the place, but as I mentioned, I'm trying to factor that out -- for example, I'm looking at how the aircraft reacts to a perturbance rather than how much stick it takes to bank, etc. Tony mentioned phugoids and Dutch roll, both of which I've been watching. I also tested both with a spring-loaded joystick and with the mouse (which has no autocentering action at all). I think you might have been onto something with the moments of inertia: our current IXX, IYY, and IZZ apply to a Cessna 182, which is a heavier plane than a 172, though with the same wing area and wingspan. Here are the 182 numbers we're currently using: IXX = 948 IYY = 1346 IZZ = 1967 What numbers do you have for the Cherokee? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
On Thu, 20 May 2004 18:48:13 -0400 David Megginson [EMAIL PROTECTED] wrote: I think you might have been onto something with the moments of inertia: our current IXX, IYY, and IZZ apply to a Cessna 182, which is a heavier plane than a 172, though with the same wing area and wingspan. Here are the 182 numbers we're currently using: IXX = 948 IYY = 1346 IZZ = 1967 What numbers do you have for the Cherokee? I'm not sure I see how the 182 figures into this. Higher values for MoI will make the aircraft slower to react to control inputs, and slower to react to damping. From your discussion yesterday I got the feeling that you were stating that the 172 was too wild - i.e. it was not damping out enough. Smaller MoIs would give better damping results (I think). But it would also make the plane more squirrely when it comes to control inputs. I can try and come up with a better estimate of MoI, but we need to be careful how the fuel numbers figure into that - we need to look at the run-time MoI and not the empty weight MoI in the config file. I have two MoI values at least that I can think of offhand: the Navion and the Cherokee. They are both at home. I ought to be able to compare and contrast those, and define a line, then see where the 172 falls with that. It ought to give me a pretty good estimate. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
Jon S Berndt wrote: Well, I got a note back from Cessna and (as I pretty much expected) they were tight-lipped about supplying any aero/mass props data, saying instead that the owner's manual was about all I could get. You could always send up a volunteer to do some flight testing. :-) Don't forget to record temp, pressure, flaps settings, etc. I could suggest some good tests to fly. I hear that often people will video tape the instrument panel so they can go back later and double check and verify the results and so they can concentrate on flying and not on recording data. After thinking about this some more, there are three possibilities I can see for any perceived problems: 2) The MoIs are too low. This is possible - I have not yet checked these out, but again I believe we will find these numbers to be pretty good. I have access to a commercial C172 model that has been FAA certified for a level 3 FTD. I wish I could share more of it, but I will say that the IXX, IYY, IZZ we use in FG are *exactly* the same numbers the commercial C172 uses. I looked at some of the other parameters and they are at least an order of magnitude different so they must be using different units or different conventions or something. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
Jon S Berndt wrote: I'm not sure I see how the 182 figures into this. Higher values for MoI will make the aircraft slower to react to control inputs, and slower to react to damping. From your discussion yesterday I got the feeling that you were stating that the 172 was too wild - i.e. it was not damping out enough. Smaller MoIs would give better damping results (I think). As an experiment, I tried halving and doubling the MoI's, and both shared many of the same handling problems. I suspect that the problem might be hiding somewhere in the yaw-roll coupling, but that's a tricky one to debug (it also doesn't help pitch control, of course). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim C-172 Performance
2) The MoIs are too low. This is possible - I have not yet checked these out, but again I believe we will find these numbers to be pretty good. I have access to a commercial C172 model that has been FAA certified for a level 3 FTD. I wish I could share more of it, but I will say that the IXX, IYY, IZZ we use in FG are *exactly* the same numbers the commercial C172 uses. The empty weight values? I suppose they must have originated from the manufacturer. I looked at some of the other parameters and they are at least an order of magnitude different so they must be using different units or different conventions or something. For C172: Clp = -0.484 if p is in rad/sec = Clp = -0.0084 if p is in deg/sec This number is highly reliable by calculation and by comparison. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim C-172 Performance
Relevant technical reports (I think the C-172 is included in this report): http://www.dfrc.nasa.gov/DTRS/1966/Bib/H-451.html Abstract: A review of existing criteria indicated that the criteria have not kept pace with aircraft development in the areas of dutch roll, adverse yaw, effective dihedral, and allowable trim changes with gear, flaps, and power. This study indicated that criteria should be specified for control-system friction and control-surface float. Furthermore, this program suggests a method of quantitatively evaluating the handling qualities of aircraft by the use of a pilot-workload factor. --- Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get cesna to follow a set of way points.
Thanks Roy, I looked at the post and it is dated the day i left so i must have missed it. I would like the autopilot to adjust to new waypoints faster but I do not know how to make the plane turn quicker using the generic autopilot. Looking at the documentation i am guessing i need to modify the u_min and u_max but after modifying the heading bug hold i am not noticing and improvements. Does anyone have a hint? Seamus On Fri, 21 May 2004, Roy Vegard Ovesen wrote: On Thursday 20 May 2004 23:50, Seamus Thomas Carroll wrote: Hi Jim, I was the one who asked this question but when i tried to implement the solution it resulted in the same flight behaviour. I will detail the changes i implemented so you can see if i did anything incorrectly. 1) I changed, in file Aircraft/c172/c172-610x-null-set.xml, pathAircraft/c172/610x-autopilot.xml/path to pathAircraft/Generic/generic-autopilot.xml/path Did you see?: http://baron.flightgear.org/pipermail/flightgear-devel/2004-May/028021.html The *-set.xml file for --aircraft=c172 is actually Aircraft/c172p/ c172p-set.xml. This is the file that you have to modify. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Atlas CVS: fails to render 1024x1024 png maps
On Thu, 20 May 2004 19:54:51 +0100 Lee Elliott [EMAIL PROTECTED] wrote: On Thursday 20 May 2004 08:43, Chris Metzler wrote: So it seems that 1024x1024 files are the problem. Does anyone else see this with a current Atlas from CVS? Any suggestions on what I can do to fix this? Obviously since the webpage was written as it was, it was intended that making and using 1024x1024 .png files be possible. What can I do to make this work? I think it's always been like that - I've never been able to use 1024x1024 maps either. As you've found, 512x512 maps are ok, so I use that res. OK, thanks. It's kind of unfortunate that the Atlas web page suggests 1024x1024 maps, then. I spent a couple of nights making those maps; now making them again at 512x512. Not to grouse too much; it's a very nice app, I think. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpRsLOSvYSMz.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Are we using spline for the taxi way at the moment? Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
