Re: [Flightgear-devel] New aircraft: SF-25
Hi, the correct cg for a SF25C is 0.143 .. 0.334m behind the wings tip (measured 0.52m from the center line). Regards, Maik am 15.08.2011 22:07 schrieb TDO_Brandano -: BTW, you can get a pretty good idea of where the CG is on a plane from the landing gear position. On a tail dragger the CG will be slightly behind the main wheel. Too far back and the tail won't have enough authority to lift for takeoff, too far forward and the plane will nose over when braking, or ground loop when rolling on the ground. In this specific model it might be a little further back than most, since it has to keep the tail on the ground with the weight of the passengers. I believe the CG will be approximatively coincident with the pilot position, since in a motorglider that will be the largest variable mass. Date: Mon, 15 Aug 2011 13:18:53 -0400 From: grne...@gmail.com To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] New aircraft: SF-25 On Mon, Aug 15, 2011 at 12:18 PM, Viktor Radnai viktor.rad...@gmail.com wrote: Hi all, Athanasios Goritsas (cc-d) created a nice Falke 3D model with a basic Yasim profile, based on the aircraft he flew with. I would like to develop his model further (I'm doing my PPL on the real thing atm). We would both like to see it in Git (under a GPL license), maybe more people would join in developing it further. (If you need a statement on this directly from Athanasios, as he's the primary author, let us know.) In the meantime, could you please check out the plane and shed some light to some Yasim parameters. You can grab it from http://www.avatarzenekar.hu/files/sf25b.tar.bz2 The biggest issue with the FDM is that the plane does not seem to have enough drag -- it easily goes over Vne, and it's impossible to land without spoilers unless you stop the engine (and even then it takes forever). Compared to the Grob 109, I had to use an absolutely huge drag multiplier to force the bird down (150 instead of 2.5). 150 is probably a bit much -- maybe 100-120 would be enough, but I think the airframe or the wings are just not generating enough drag. Not sure if I did a good enough job with the fixed prop. The diameter should be correct, not sure about the rest. My school's falke has the 2L engine and it spins up to about 2600 when stopped. No idea about the prop's most efficient speed and horsepower values are pretty much guesses. Anyway, please let us know if this is good enough to go into the repo, and any suggestions for improvement. Some (working) 3D instrument panel would be great, but I have no idea how to make that. Any pointers on that would be very much appreciated. Since Falkes have fairly varying instrumentation, even a copy of the Grob 109's panel could be OK. Ah, and the splash screens I've made do not load. What did I do wrong? Thanks in advance. Cheers, Vik Vik, Looks like a great start. The first thing I would do before anything else is make sure your CG is positioned reasonably. In your SF-25, the CG is much too far back; given the forward-swept wings, it looks to be about a meter behind MAC: E:\FlightGear projects\sf25byasim sf25b-yasim.xml Solution results: Iterations: 1292 Drag Coefficient: 10.955851 Lift Ratio: 291.677826 Cruise AoA: 1.469686 Tail Incidence: 2.793443 Approach Elevator: -0.014301 CG: x:-0.900, y:-0.000, z:0.284 Inertia tensor : 1831.357, -0.000, 78.171 [kg*m^2] -0.000, 2075.542, 0.000 Origo at CG 78.171, 0.000, 3856.738 The command-line YASim solver is showing CG at x=-0.9, well behind the wing's root chord position at x=-0.371. It isn't worth messing with other YASim values until CG is about right. I'd first try to locate the real CG range from a certification sheet or pilot's handbook and then use a YASim ballast element to shift some of the plane's mass forward toward the nose. Once you get CG better positioned, you'll have much better luck with other factors. After CG, a couple of other things to watch in the solver: Lift ratio is very high-- this indicates the glides-forever issue. For this plane I'm guessing you'll want a value somewhere between 100-130, but the actual value will depend on flight experimentation. Lots of YASim parameters affect that value. (Note that these YASim drag and lift numbers should not be treated as real lift/drag ratios; don't try to make them match a real L/D ratio.) Approach elevator is much too small-- this value means you'll need almost no elevator to hold an approach. Look for something in the -0.7 to -0.9 range for starters. In any case, don't try to tweak these until CG is resolved. Wing and hstab stall AoA values look really high at 30 degrees. Most conventional high-lift general aviation airfoils seem to be in the 15-18 range. If you know the airfoils used, you can get camber and stall values from the airfoil data. I have a little and rather incomplete
Re: [Flightgear-devel] Martin is responding slowly ....
Hi Martin, congrats! You probably noticed, the world spins different now. Regards, Maik Am 25.07.2011 17:14 schrieb Martin Spott: Hi, if anyone is wondering why I'm responding even slower as usual, this might be caused by the simple fact that I'm being distracted by our daughter who was given birth last night. Cheers, Martin. -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by
Hi, Am 18.05.2011 21:09 schrieb Heiko Schulz: If the drawbacks introduced by the new FDM are really that obvious and serious as you've stated here, I'd say you/we should take a revert of the latter change into account. At least the author of the first and in my eyes much more realistic fdm has to decide if he accepts the new made changes or not. actually I don't have a up to date Flightgear installation on my computer. Therefore I was not able to make a testflight with the new fdm. But I had a look to the xml file of the fdm and I am 99% sure, that this fdm has nothing to do with the flight behavior of the real aloutte 2. Does anyone know, if JM-26, the author of the new fdm, is reading the devel list or has an email address for me to contact him directly? Regards Maik -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
Hello Heiko, does your local FDM still uses default approach fuel etc? But even if not, there should be no difference in the flight behavior. The only effect of the approach fuel level is (for a rotorcraft) within the gear solver. By the way: I would prefer to use the old default values for the gear solver. The spring constants of a gear should not be a function of the approach fuel settings. Maybe some gears would need some tuning with the patch otherwise. The _approachWeight = _emptyWeight + totalFuel*_approachFuel; should be moved behind the gear solver call. Maik Am 17.04.2011 22:37 schrieb Heiko Schulz: Hi, Well, I'm glad it helps. The patch should not affect the solution too much in most cases, I've checked this myself. I have tested it, and well, at least for helicopters there seems a difference. No idea how long we have this bug now- but I guess a very long time. I was working on the bo105 to get to a more realistic climb rate by keeping the flight behavior matching to the known detailed datas. The bo105 doesn't have a realistic climbrate, but while reaction time, rate and control sensibility matches exactly the real one. I can now see a difference between before and after this patch, and now it seems the climb rate is even less than before. Heiko -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
Hello, to avoid this happen again in the future: Is it possible to add a metar-server functionality to the mpservers? If the NOAA protocol / access changes we only have to modify the mpservers, not the clients? Maik m schrieb am 06.11.2010 09:30: Thanks. I think it is pretty inconsiderate of the NOAA to change this two days before our largest flightsim event worldwide :-D But as you pointed out, METAR will have stopped working for older releases too. Which is even worse. m Op 05-11-10 20:37, ThorstenB schreef: That was a problem with the simgear METAR loader. Obviously NOAA is using a shared server for their websites now (one IP for several sites). The new webserver couldn't tell for which website we were asking for. HTTP requires a GET and a Host line - we were missing the latter. A fix is in GIT now. Unfortunately this means METAR is broken (probably permanently) for all previous FG versions now... Anyway, what are the plans for the next FG release? -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim, Quadcopter and MatLab
Hi Julien, Julien Peeters schrieb am 19.09.2010 11:29: Hi, I've just used you model. But I have few bugs. The first one is that the quadcopter stays under the ground when I launch FG. there is no 3d-model for the quadcopter. It is very small, much smaller than most other flightgear aircrafts. The second is that I cannot control it with usual keyboard keys. All commercial quadcopters have gyro stabilization, but this one has none (should be not much work to program one in nasal or using the autopilot). This quadcopter needs much experience in controlling of model helicopters to be flown. I think it is impossible to fly it by keyboard. Maik Any idea? Best, Julien. PS: Sorry if my questions are a bit boring... It's the first time I do such things. Le 18/09/2010 23:13, Maik Justus a écrit : Hello Julien, please find enclosed the yasim configuration for a quadcopter. Regards, Maik Julien Peeters schrieb am 18.09.2010 22:47: Hi readers, For my first post on this mailing-list I am looking for people who already have built a working model for a quadcopter using the Yasim FDM. I am a student in electronics and embedded systems and I aim to build one for an experiment. Next, I would like to do such hardware in the loop simulation and validation. So I would like to be able to make Yasim/FlightGear interacts with real hardware or at least Matlab. Is it possible? Some of you already do that? Best, Julien. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim, Quadcopter and MatLab
Hello Julien, please find enclosed the yasim configuration for a quadcopter. Regards, Maik Julien Peeters schrieb am 18.09.2010 22:47: Hi readers, For my first post on this mailing-list I am looking for people who already have built a working model for a quadcopter using the Yasim FDM. I am a student in electronics and embedded systems and I aim to build one for an experiment. Next, I would like to do such hardware in the loop simulation and validation. So I would like to be able to make Yasim/FlightGear interacts with real hardware or at least Matlab. Is it possible? Some of you already do that? Best, Julien. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel !-- copter config for Autonomous Quadcopter - University Bremen by Maik Justus see README.yasim -- !-- mass of the empty quadcopter in pounds (1 lb = 0,373241721 kg) -- airplane mass=2.4200 !-- Approach configuration, only for gear solver :-) -- approach speed=200 aoa=0 alt=0 control-setting axis=/controls/engines/engine[0]/throttle value=0.05/ /approach cruise speed=2 aoa=0 alt=0 control-setting axis=/controls/engines/engine[0]/throttle value=0.2/ /cruise !--position of the cockpit -- cockpit x=0 y=0 z=0.5/ rotor name=left x=0.0 y=0.3 z=0.16 nx=0 ny=0 nz=1 fx=1 fy=0 fz=0 diameter=0.25 numblades=2 weightperblade=0.001 relbladecenter=0.52 chord=0.027 twist=-12.0 taper = 0.37 rel-len-where-incidence-is-measured=0.7 rel-len-blade-start=0.0 rpm=17600 phi0=0 ccw=1 maxcollective=100.0 mincollective=-100.0 mincyclicele=0.0 maxcyclicele=0.0 mincyclicail=0 maxcyclicail=0 airfoil-incidence-no-lift=1.0 incidence-stall-zero-speed=15 incidence-stall-half-sonic-speed=14.5 lift-factor-stall=0.28 drag-factor-stall=2.0 stall-change-over=5.5 pitch-a=0 pitch-b=0 delta=0.125 airfoil-lift-coefficient=3.85 airfoil-drag-coefficient0=0.0075 airfoil-drag-coefficient1=0.25 rotor-correction-factor = 1 dynamic=1.0 rellenflaphinge=0.01 sharedflaphinge=0 delta3=0 translift-maxfactor=1.3 translift-ve=20 flapmin=-15 flapmax=15 flap0=-.15 flap0factor=0 notorque=0 dragfactor=0.30 ground-effect-constant=0.1 number-of-segments=4 number-of-parts=4 cyclic-factor=0.8 downwashfactor=1 control-input axis=/controls/engines/engine[0]/throttle control=COLLECTIVE src0=0.0 src1=1.0 dst0=-0.01 dst1=0.1/ control-input axis=/controls/flight/aileron control=COLLECTIVE src0=-1.0 src1=1.0 dst0=-0.015 dst1=0.015/ control-input axis=/controls/flight/rudder control=COLLECTIVE src0=-1.0 src1=1.0 dst0=-0.025 dst1=0.025/ /rotor rotor name=right x=0.0 y=-0.3 z=0.16 nx=0 ny=0 nz=1 fx=1 fy=0 fz=0 diameter=0.25 numblades=2 weightperblade=0.001 relbladecenter=0.52 chord=0.027 twist=-12.0 taper = 0.37 rel-len-where-incidence-is-measured=0.7 rel-len-blade-start=0.0 rpm=17600 phi0=0 ccw=1 maxcollective=100.0 mincollective=-100.0 mincyclicele=0.0 maxcyclicele=0.0 mincyclicail=0 maxcyclicail=0 airfoil-incidence-no-lift=1.0 incidence-stall-zero-speed=15 incidence-stall-half-sonic-speed=14.5 lift-factor-stall=0.28 drag-factor-stall=2.0 stall-change-over=5.5 pitch-a=0 pitch-b=0 delta=0.125 airfoil-lift-coefficient=3.85 airfoil-drag-coefficient0=0.0075 airfoil-drag-coefficient1=0.25 rotor-correction-factor = 1 dynamic=1.0 rellenflaphinge=0.01 sharedflaphinge=0 delta3=0 translift-maxfactor=1.3 translift-ve=20 flapmin=-15 flapmax=15 flap0=-.15 flap0factor=0 notorque=0 dragfactor=0.30 ground-effect-constant=0.1 number-of-segments=4 number-of-parts=4 cyclic-factor=0.8 downwashfactor=1 control-input axis=/controls/engines/engine[0]/throttle control=COLLECTIVE src0=0.0 src1=1.0 dst0=-0.01 dst1=0.1/ control-input axis=/controls/flight/aileron control=COLLECTIVE src0=-1.0 src1=1.0 dst0=0.015 dst1=-0.015/ control-input axis=/controls/flight/rudder control=COLLECTIVE src0=-1.0 src1=1.0 dst0=-0.025 dst1=0.025/ /rotor rotor name=front x=0.3 y=0.0 z=0.16 nx=0 ny=0 nz=1 fx=1 fy=0 fz=0 diameter=0.25 numblades=2 weightperblade=0.001 relbladecenter=0.52 chord=0.027 twist=-12.0 taper = 0.37 rel-len-where-incidence-is-measured=0.7 rel-len-blade
Re: [Flightgear-devel] CPRC Autonomous UAV Helicopter
Hello Thomas, Thomas Hamilton schrieb am 08.05.2010 04:03: Maybe it's easier if you just provide a (maybe very simple but right size) 3d Model of your helicopter. Then I can make a FDM similar to my rc-helicopters. At the end we only need to adjust it to make it fly as your helicopter does. I can do this without too much work, maybe it would be less work for both of us though, if I just sent relevant dimensions and specifications. I was rather hoping that I would be able to do this myself though. Is there any more documentation on this subject besides the readme included in the installation? The meanings of some of the flags and parameters are not very clear to me; and a few are altogether missing. My team is going to be changing gear around and rebuilding the vehicle several times, so it is necessary for us to learn eventually. No, there is no additional documentation, only the readme and the .xls file for the airfoil parameters. If we have a working FDM the tuning need only modification of very few parameters. Therefore I am sure, that modifications on the real helicopter can be adjusted in the .xml file by your team. thanks again, Thomas Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CPRC Autonomous UAV Helicopter
Hello Thomas, Thomas Hamilton schrieb am 05.05.2010 19:57: Thank you for the response Maik, I am sure your helicopter has flapping. Maybe not a visible flapping hinge, but some elasticity within the blades or the blade holder. The Bo105 and the Ec135 has no flapping hinge as well. I gather then, that we need to somehow measure effective values for all of the parameters that aren't obvious? How would you recommend measuring or calculating the effective flap hinge ratio? For the flap hinge I would use the value which is used at the bo105. Up to now there is no example of a helicopter with a bell-hiller rotor head for flightgear. The UH1 has the bell rotor head with stabilizer bar, but as far I know the cvs version of the uh1 is broken since some days. I have no idea, if or when helijah will commit my patch. Maybe it's easier if you just provide a (maybe very simple but right size) 3d Model of your helicopter. Then I can make a FDM similar to my rc-helicopters. At the end we only need to adjust it to make it fly as your helicopter does. Thanks again, Thomas Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CPRC Autonomous UAV Helicopter
Hello Thomas, Thomas Hamilton schrieb am 01.05.2010 20:33: Hello, I am a member of a college robotics team and we are currently building an autonomous UAV helicopter. We wish to use FlightGear for research and development, however after an exhaustive search we have failed to find even one small-scale helicopter FDM. We would like to know if it is possible to create an accurate FDM for such a vehicle, there are no size limitations in the rotor logic within YASim, and as far as I know, the same is valid for YASim itself. and if so are there any nuances in YASim that we need to account for in scaling and/or stripping off some features that don't apply to this vehicle (such as flapping). I am sure your helicopter has flapping. Maybe not a visible flapping hinge, but some elasticity within the blades or the blade holder. The Bo105 and the Ec135 has no flapping hinge as well. Our specific helicopter is a Bergen Tazer, it has about a 6 foot diameter rotor span and runs on 4 Li-po batteries. If it is possible, we will begin developing one and possibly making it available to the public. Thank you for your time and effort. Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Quadrocopter (Quadcopter) / Mikrokopter / X-UFO / Microdrone
Hello Andreas, what is the actual status of the 3D-model? Best regards, Maik Andreas Bresser schrieb am 18.07.2009 02:31: Hi Maik, Nice. Will the finished model be published with GPL license? Would be nice to have such a model within cvs. Yes, definitely (and if not GPL than some other free license, but I think I'll go with GPL)! This model is now just for one Quadcopter, but there are a lot models out there that are quite simmilar, so I think I will modify the visible and physical model a bit and create some more Quadcopter-models (would be cool to see a swarm of them in the air :-) ) I had a look into these files and have a flying version of the Quadcopter now. cool! But it is very unstable. not so cool... I have to check, if these is caused partly by wrong parameters in the xml File (I don't have any experience with simulating such small rotors with YASim...). But it will definitively need an autopilot. (E.g. the V22-Osprey has a simple autopilot. The same concept should work for the quadcopter, too.) I will send you updated files in the next days. Thank you very much! If you need more data or other informations, just ask. I can't wait to see this thing flying. Andreas -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DIY drones virtual UAV competition
Hello Curt, Curtis Olson schrieb am 12.04.2010 18:27: Hi Maik, Do you still have the FDM for the small quad-copter? Is this something that could be added to CVS? I think it could generate a fair amount of interest. yes, I still have the FDM, but no 3D-model. The FDM contains only the rotors and the mechanic. With some rc-helicopter experience it is flyable. But now I know, why all these small quadcopters are gyro stabilized. The limitation of the FDM is, that it works with constant RPM for all four rotors and varies the collective. Most (all?) real quadcopters have fixed rotors with individual engines. Adding some gyro stabilizers should not be so hard with some nasal coding. There were some mails about a year ago about his topic; I will see, if Andreas, who asked for the FDM, has a 3D-model now. I think for CVS we should have a (at least simple) 3D-model. Best regards, Maik Thanks, Curt. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DIY drones virtual UAV competition
Hello, some time ago I made a FDM for a small quad-copter. Therefore flightgear also could be used for simulating this kind of uav. Sensors like acceleration and gyroscope should be easy to simulate with all their inaccuracies. Laser scanner and ultrasonic sensors (using some discrete rays) should also be possible now. Cameras we have, too. And the competition could be shared live over the multiplayer protocol. Depending on the task even human competitors could be allowed Best regards, Maik Curtis Olson schrieb am 28.03.2010 16:58: Hi, I could use a little help from one of our aerodynamics experts. First a little background. DIYdrones.com is a group of hobbiests with an interest in building hobby / open-source uav's. Actual projects vary widely, but often they are based on small electric powered foam gliders (like an easy star.) For most people hardware costs are in the couple hundred dollar range. One of the interesting things about DIYdrones.com is that it was started by Chris Anderson who is an editor at Wired magazine. Part of his effort is an experiment into open-source hardware as well as open-source software. (And for hardware, it's the design that's open-source and free to copy and modify, it still costs money to build a physical widget.) A couple of weeks ago I did a podcast interview with Chris Anderson and Tim Trueman on the subject of using FlightGear for hardware in the loop testing. This is an area that many hobby level uav-ers haven't considered. If you are *really* bored you can dig around the diydrones.com http://diydrones.com site and probably find a link to my interview ... it's about 30-45 minutes and was done very late on a Sunday evening, so there are a couple times where the little electrons in my brain ran up against a sleeping brain cell ... I wasn't on my A game, let me just say it that way. :-) DIYdrones.com sponsors a periodic for fun contest and this time around they are thinking about doing something FlightGear based. The DIY drones contests are setup so that individuals can compete on their own and submit their results to the contest coordinator. It's based on the honor system, and avoids requiring people from around the world to travel to a central contest location. There is a thread here: http://www.diydrones.com/profiles/blogs/proposed-next-t3-round If you scroll down a bit, you can see that someone found an AC3D model of an easystar glider (this is a relatively cheap and small and light and slow flying RC hobby airplane.) What I am hoping is that someone here could help put together an initial flight dynamics model configuration for the easy star. I don't have any specs, but if we have someone willing to help out, I'm sure we could get answers to questions from the diydrones community. The goal here would be to put together a reference easystar aircraft package (3d and flight dynamics models) that could be used as the basis for the DIY drones contest. Do we have anyone willing to help get an aircraft package together? (I have no idea what the licensing on the easystar ac3d model is, but worst case scenario if it isn't GPL compatible we can distribute the aircraft package separately for the diydrones contest or perhaps one of our 3d modelers would want to create our own GPL compatible easy star.) Thanks! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 48, Issue 2
Hello Emmanuell, Heikos Mail wasn't an attac. He just noted that the fdm is actually broken and he offered his help. I prefer to revert to the last version of the fdm, even if some coordinates are wrong. The resulting flight characteristic is correct. Best regards, Maik P.S.: the uh1 has a stabilizer bar which i have simulated using a third rotor (it produces no lift) Original-Nachricht Datum: Fri, 02 Apr 2010 18:46:19 +0200 Von: BARANGER Emmanuel embaran...@free.fr An: flightgear-devel@lists.sourceforge.net Betreff: Re: [Flightgear-devel] Flightgear-devel Digest, Vol 48, Issue 2 Message: 4 Date: Tue, 30 Mar 2010 23:57:48 + (GMT) From: Heiko Schulzaeitsch...@yahoo.de Subject: Re: [Flightgear-devel] FG - Helicopter FAA - AATD To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Message-ID:741574.96640...@web23204.mail.ird.yahoo.com Content-Type: text/plain; charset=iso-8859-1 Hi, The UH1 was the one with the most realistic flightmodel. Unfortunately as helijah corrected the fuselage shape in YASim, he broke the whole balance settings. Tensors and CoG seems not right anymore, visible as the whole aircraft is turning on ground with stopped engine. That didn't happen before. I don't find the time right now to look and fix it, but maybe in 2-3 weeks unless someone other is faster. Regards Heiko. I'm sorry, but this kind of attacks wearies me. I actually changed the work of HHS. But not for the worse, but simply to make it logical and usable. And I show you the results to prove it. http://helijah.free.fr/uh1-fdm.png Maik, if you accept, without question, the presence of a third rotor in an UH-1 FDM, then I have nothing more to say. But it will still show me its usefulness. Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG - Helicopter FAA - AATD
Hello, Heiko Schulz schrieb am 31.03.2010 01:57: The UH1 was the one with the most realistic flightmodel. Unfortunately as helijah corrected the fuselage shape in YASim, he broke the whole balance settings. Tensors and CoG seems not right anymore, visible as the whole aircraft is turning on ground with stopped engine. That didn't happen before. ups, not nice. Probably just reverting to the old FDM (Aircraft/UH-1/uh1.xml) should fix this. Maybe its necessary to add an offset to the 3d-model in the uh1-set.xml file, but don't modify the old FDM file. Maybe the geometry or the coordinates of the ballast seem to be wrong, but overall they match nearly exactly the original values (mass, inertia tensor, static and dynamic reaction on control input/power, ...) I don't find the time right now to look and fix it, but maybe in 2-3 weeks unless someone other is faster. I don't have access to a PC in the next 10 days. Regards Heiko. Best regards, Maik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG - Helicopter FAA - AATD
Hello, yes, the FDM for the Bo105, Aircrane und UH1 are tuned to match the data given in some NASA Reports, in particular Report NASA-CR-3144 A compilation and analysis of helicopter handling qualities data. Volume 1: Data compilation, which is public available. This report contains the most comprehensive data collection I ever found for helicopter. It describes the static and dynamic parameters of five different helicopter. E.g. control and power settings for a lot of different flight attitudes containing the dynamic reaction for changing each of the controls. Therefore I can note: As long as you stay within normal operation limits the three mentioned flightgear helicopter behave(d) very realistic. For out-of-normal-operation-limits I have no data to compare. Best regards, Maik Heiko Schulz schrieb am 31.03.2010 11:02: Hi, On the one side we have free available datas provided by the NASA. The Bo105 and the Aircrane uses the same data, a MD500 would be also possible. Maik did all the work! Derivated from the Bo105-data is the weight and balance for the EC135, so this heli behaves regarding in weight and balance like given in the manual. And then of course, we have a real Bell UH1-pilot as user, who tested the FGFS's UH-1 and was really impressed. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html --- James Sleeman /flightg...@gogo.co.nz/ schrieb am *Mi, 31.3.2010: Von: James Sleeman flightg...@gogo.co.nz Betreff: Re: [Flightgear-devel] FG - Helicopter FAA - AATD An: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Datum: Mittwoch, 31. März, 2010 02:23 Uhr On 31/03/10 12:57, Heiko Schulz wrote: The UH1 was the one with the most realistic flightmodel. Purely out of interest, what is the assessment of realism based on, have you/somebody actual real world experience UH-1 piloting and compared to FG, or is it more the numbers seem right and it doesn't really do anything weird, so probably realistic? -Integrierter Anhang folgt- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -Integrierter Anhang folgt- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net /mc/compose?to=flightgear-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel * __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Translating getstart.pdf to German
Hi Jörg, Jörg Emmerich schrieb am 30.03.2010 11:05: Hi Maik, that is wundervoll news. Surely I will use the then completed translation. But why wait? I will start with the review / translation short time after my Eastern vacation. Best regards, Maik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Translating getstart.pdf to German
Hi Jörg, Jörg Emmerich schrieb am 29.03.2010 16:05: Hi Maik, thank you for offering help in translating your chapter about the Helicopters. But I am a little confused: I just compared the getstart.pdf chapter A Helicopter Tutorial with the wiki Flying the Helicopter - and on first sight they look exactly the same. What I do not understand: There is already a translation De/Fliegen mit dem helikopter -- so why do you want to translate it again?? At least at http://wiki.flightgear.org/index.php/De/Fliegen_mit_dem_helikopter the article is only partly translated. And even the translated part I would like to review. Best regards, Maik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Translating getstart.pdf to German
Hello Jörg, Jörg Emmerich schrieb am 26.03.2010 10:23: ... For the example of the Helicopter (and similar) I am not yet sure about the best way: But I am convinced also here we do need a chapter about the Basics of how to fly a Helicopter in the manual -- and point to the wiki for enhanced maneuvers and different types of helicopters etc. etc. (Helicopter-flying seems to be THE trend right now!). thanks for any help joe For the helicopter chapter I offer my help. Best regards, Maik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Translating getstart.pdf to German
Hi, just a remark, probably already know: Some parts of the getstart.pdf are in the wiki, which is partly translated to German. Best regards, Maik Adrian schrieb am 25.03.2010 08:44: Hey Joe! Where d'you want me to go with that pen in my hand? :-) Just tell me which pages you are translating, I'll then translate some others. Sorry, I will not be able to generate such a big output like ten pages a day or something, but many a little makes a mickle. Ciao, Adrian Am Mittwoch, den 24.03.2010, 17:53 +0100 schrieb Jörg Emmerich: I searched for a good, affordable FlightGear tutorial for my German friends - but was not very lucky. So I made up my mind to translate the FlightGear Standard getstart.pdf. Because translating that 218 pages may not be done in a couple of weeks I just want to make aware of that I started - so that we might avoid multiples of such a bigger task. As soon as I have a complete first draft i will make it accessible here for reviews etc. And especially provide suggested changes to the original to Stuart and or Martin. joe -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG - Helicopter FAA - AATD
Hello Christian, the helicopter flight model is very realistic, for my point of view it is the the most realistic flight model which is available for normal PC users. The setup of the configuration is a bit tricky, esp. for the auto-rotation, therefore it does not work realistic for most helicopters in flightgear, but the hornet (an autogyro) is simulated well in flightgear. The helicopters with the most realistic flightmodels in flightgear are: bo105 aircrane uh1 Best regards, Maik Christian Menge schrieb am 22.03.2010 13:39: Hi Developers, We are looking into the idea of creating an Helicopter (rotary) FAA AATD. Does anyone have any comments / thoughts about the quality of flight modeling for rotary wing aircraft in FlightGear? This is an important question as students must have the ability of practicing advanced maneuvers like auto-rotation and this can be a very complicated feature to model properly. Thanks! Christian FreedomWorks Inc. US: 609-858-2290 Canada: 905-228-0285 Fax: 347-296-3666 Email: christ...@freedomworks.ca www.FreedomWorks.ca www.freedomworks.ca -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Translating getstart.pdf to German
Hi Martin, Martin Spott schrieb am 25.03.2010 22:34: Maik Justus wrote: just a remark, probably already know: Some parts of the getstart.pdf are in the wiki, [...] Oh, are people really duplicating The Manual on the Wiki ? I don't know. But at least my two cents to The Manual (chapter A Helicopter Tutorial was copied from the Wiki to the manual.) Martin. Best regards, Maik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Hi Erik, Erik Hofman schrieb am 03.11.2009 14:01: And now the Doppler effect is also fixed (sort of). I needed to multiply the velocity vector by 100 to get some sort of Doppler effect going on. Maybe you are calculating the velocity as m/frame instead of m/s? Or you transformed the m/frame to m/s by multiplying by dt instead of a division by dt? Best regards, Maik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about yasim's rotor model
Hi, Heiko Schulz schrieb am 29.10.2009 22:27: Hi, ...just the rotor 3D object turns clockwise (the 3D rotational axis is z negative), the main rotor is still counterclockwise (/rotors/main/blade/position-deg increases, a clockwise rotor should decrease this value?). So much as I know this is more a nasal thing, as the YASim-heli-fdm don't have support for engines, and this is faked by a nasal script. This position-deg is more for animation. (The bo105 uses this, the s76 make use of rotor-rpm for that as an example) the position-deg is not the rotation about the rotor axis, it is the rotation in the rotation-direction of the rotor. If I would define the meaning of this value today, I would define it as rotation around the rotor axis Maik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear in industry use
Hi Arnt, Arnt Karlsen schrieb am 28.10.2009 17:26: ..aye. One problem, they provide FG binaries, but no source??? http://www.cloudcaptech.com/download/Piccolo/FlightGear/ Do they have to provide the source to everyone? Or do they just need to deliver the license within the download and provide the source to everyone who asks for it (or, if they didn't altered the source: a link to http://www.flightgear.org/Downloads/source.shtml ) Maik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear License, was: Re: Fwd: [Flightgear-cvslogs] CVS:
Detlef Faber schrieb am 25.10.2009 11:33: I sympathise with Durks intentions, at least he is trying to adress the issues that gives a lot of FG devels a headache (including me). Rather than shouting down his well intended move I would expect some Suggestings how to deal with this appropriately. So don't come up with a Stop contributing if you don't like it solution. I'm sure there are alternatives. Greetings I think we are discussing the wrong topic. The real question is: Do we want another license for Flightgear? Or for some parts of Flightgear? E. g. some essential source files? The scenery? Some aircrafts? Some textures? Maik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Quadrocopter (Quadcopter) / Mikrokopter / X-UFO / Microdrone
Hello Andreas, Andreas Bresser schrieb am 17.07.2009 19:22: Hi. I am working on a Quadrocopter (http://www.mikrokopter.de) model in Flightgear with YAsim. Nice. Will the fiinished model be published with GPL license? Would be nice to have such a model within cvs. After the loading of the model the Simulation hangs (in an endless-loop?). Can anyone help me and take a look at my yasim-xml file? It can be found at http://phidev.org/~andreas/copter.zip I had a look into these files and have a flying version of the Quadcopter now. But it is very unstable. I have to check, if these is caused partly by wrong parameters in the xml File (I don't have any experience with simulating such small rotors with YASim...). But it will definitively need an autopilot. (E.g. the V22-Osprey has a simple autopilot. The same concept should work for the quadcopter, too.) I will send you updated files in the next days. The comments in the file are in german, if you have any questions ask me. I have no problems to read german comments ;-) P.S. HHS suggested I should ask here, so this is identical with the forum post http://www.flightgear.org/forums/viewtopic.php?f=4t=5413 Greetings, Andreas Maik -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New member...and questions ;-)
Hi LeeE leee schrieb am 26.06.2009 13:57: I just thought I'd point out that the YASim solver sets the incidence for the hstab element, not the wing element. Thanks for correcting me. I checked the code. The only difference between wing and mstab are: - you have to define one wing (only for aircrafts, not for helicopter) - the wing is used for calculating the ground effect, the mstab isn't ... For the main lifting surface then, using a full-span wing element will give more accurate results than a combination of wing and mstab elements because the mstab elements will be ignored. As I wrote: I think the only difference is the ground effect, not more. Am I wrong? Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New member...and questions ;-)
Hi, Olivier Faivre schrieb am 26.06.2009 14:04: Interesting. Will try both possibilities. if mstab is not use by the solver, What about biplane ? Not so clear anymore in my mind... I think the comment in the README.YASIM is wrong. I thought the solver sets the incidence of the wing, but I was wrong. The mstab is not used for calculating the ground effect while the wing is. That's all. However, if i cannot set incidence to the mstab, my idea is dead... No, you can define the incidence of the mstab. You can't set the incidence of the hstab (the solver sets the hstab-incidence) Olivier Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New member...and questions ;-)
Hello Olivier, Olivier Faivre schrieb am 25.06.2009 20:52: Hello guys, ... Actually, the wing is done with only one piece, 7° dihedral, no twist. Can I use the mstab command to specify the outer wing and the regular wing command for the inner one ? yes In the readme file, I read this for mstab : these surfaces are not involved with the solver computation these surfaces are not involved with the solver computation... I'm not sure to well understand. if you define a yasim FDM you have to define two configurations with different airspeed, typ. cruise and approach. Yasim modifies lift and drag factors and the incidence of the wing to meet these configurations. Therefore the incidence of a wing will be modified by the yasim solver (only once - when the model is loaded) while the incidence of a mstab is unchanged. Second question about readme : I read this in the fuselage section: Factors for the generated drag in the fuselages local coordinate system with x pointing from end to front, z perpendicular to x with y=0 in the aircraft coordinate system. E.g. for a fuselage of a height of 2 times the width you can define cy=2 and (due to the doubled front surface) cx=2 Again, I' don't understand the meaning of CX=2 and CY=2... a fuselages generates drag. In former time Yasim assumed fuselages to have equal width and height. This was changed by the addition of cx, cy,... If you have a very narrow fuselage the drag in z-direction (vertical) should be smaller than in y-direction. Lets think of a fuselage 1m in width and 4m in height: For this case you can define the width as the mean value of width in z- and y-direction (2m) and modify the drag value in z-dircection by a factor of .5 (cz=0.5) and in y-direction by a factor of 2 (cy=2). But I think for most aircrafts these effects are small. These factors were added for fixing problems with helicopters, where the fuselage is in the downwind of the main rotor. Thanks for your help ;-) welcome Olivier Faivre From France Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New member...and questions ;-)
Hi Heiko Schulz schrieb am 25.06.2009 22:06: Hi, ... Can I use the mstab command to specify the outer wing and the regular wing command for the inner one ? In the readme file, I read this for mstab : these surfaces are not involved with the solver computation these surfaces are not involved with the solver computation... I would suggest to try instead vstab: regular wing for the inner, vstab for the outer. vstab's parameters are equally settable, That's why I would use this maybe. in former time there was no mstab in YAsim. For a biplane you defined one of the wings with the wing-element, and the other by two vstab-elements. Since the mstab was added to YAsim the mstab is easier to define the second wing (or the outer wing of the DR400). Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL in SimGear
Hi Matias, Matias D'Ambrosio schrieb am 26.05.2009 22:55: Hello all, I have just subscribed to this list, but I did search in the archives for emails regarding OpenAL and the doppler effect in particular. Hopefully I didn't miss any important emails. I have some experience with OpenAL, definitely a lot more than I do with FlightGear and SimGear, so when someone in #flightgear mentioned a lack of doppler possibly dating to changing from the OpenAL SI (0.0.8) to OpenAL Soft (many versions, the one I used as reference here is 1.4.711) I decided to investigate why. Very good, thank you! SNIP On the use of AL_VERSION_1_2 to detect a functioning doppler effect... well, there is no OpenAL 1.2 specification. Yes, indeed. The check for AL_VERSION_1_2 is just a placeholder to keep the code for Doppler with correct OpenAL-Doppler in the files. The idea was: I hope, that in far future the OpenAL Doppler will work again. Best regards, Maik -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] *** SPAM *** Re: Scene ambient and specular color changes
Hi Erik, Erik Hofman schrieb am 01.04.2009 08:42: (heavy clouds will only be possible in situations with reduced visibility anyhow). I am not sure that I got your point 100%, but I think visibility and cloud layers are not well correlated. E.g. actual Metar for EDDS: 012020Z 05012KT OVC034 10/05 Q1016 NOSIG (Maximum visibility and overcast in 3400ft). Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in FlightGear\src\Airports\dynamics.cxx , patch included
Hi Durk, Durk Talsma schrieb am 31.03.2009 07:12: Thanks for the update. Did you install additional traffic at KSFO, or copy the old demo over? Not by intention. I just made a diff on the traffic folder and found no diff. Can traffic be in an other file? Or can a MP aircraft causing to call those functions? But on the other hand it was s small bug in checking the size of the vector which is fixed now. Therefore I would not spend much time in trying to reproduce that. The reason I'm asking is that with FlightGear 1.9.0 and later there is currently hardly any traffic at KSFO and/or surrounding airports. So the chances of finding a problem with the existing setup at KSFO would be rather small if you have a default setup. Cheers. Durk Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in FlightGear\src\Airports\dynamics.cxx, patch included
Hi Durk, Durk Talsma schrieb am 30.03.2009 08:01: Hi Maik, Committed. Thanks for looking into this. BTW: At / near which airport did you see this crash? I'd like double check a few things regarding this at the crash site, if possible. KSFO, about 1 in after starting fg. Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in FlightGear\src\Airports\dynamics.cxx, patch included
Hi, Maik Justus schrieb am 30.03.2009 08:59: Hi Durk, Durk Talsma schrieb am 30.03.2009 08:01: Hi Maik, Committed. Thanks for looking into this. BTW: At / near which airport did you see this crash? I'd like double check a few things regarding this at the crash site, if possible. KSFO, about 1 in after starting fg. ups, that should read: KSFO, about 1 *m*in after starting fg. sorry for the noise, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] crash in FlightGear\src\Airports\dynamics.cxx, patch included
Hello,
I had several crashes in FlightGear\src\Airports\dynamics.cxx.
Please commit the enclosed patch.
Best regards,
Maik
? Airports.diff
Index: dynamics.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Airports/dynamics.cxx,v
retrieving revision 1.26
diff -u -p -r1.26 dynamics.cxx
--- dynamics.cxx16 Mar 2009 16:37:40 - 1.26
+++ dynamics.cxx29 Mar 2009 17:43:36 -
@@ -545,11 +545,11 @@ int FGAirportDynamics::getGroundFrequenc
if (freqGround.size() == 0) {
return 0;
}
- if ((freqGround.size() = leg-1) (leg 1)) {
+ if ((freqGround.size() leg-1) (leg 1)) {
groundFreq = freqGround[leg-1];
}
if ((freqGround.size() leg-1) (leg 1)) {
- groundFreq = (freqGround.size() (leg-2)) ?
freqGround[freqGround.size()-1] : freqGround[leg-2];
+ groundFreq = (freqGround.size() (leg-1)) ?
freqGround[freqGround.size()-1] : freqGround[leg-2];
}
if ((freqGround.size() = leg-1) (leg 1)) {
groundFreq = freqGround[leg-2];
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Hi Csaba, Csaba Halász schrieb am 21.03.2009 02:48: I also wonder if property change listeners should get an additional argument, giving the index of the changed item. But of course the change would need to be detected first, which basically means we can not directly expose a writable vec3d/4d contained in the property. but we already can tie a property directly to a variable. Listeners (AFAIK) do not work for these constructs right now. Therefore that would not be a difference to the existing property tree. Maik -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Hi, Stuart Buchanan schrieb am 20.03.2009 16:22: My immediate thought is that one could write some fairly straightforward code to interpret a given property node with 3 child values as a Vec3. Could we subvert the property attributes to indicate that a given nodes contains a Vect3. That way internal code could interpret it as a Vec3, while external interfaces would be preserved. Or we do it vice versa. We store the vec3 directly in the property tree, e.g.. surface/color, but you can access any components over the property tree in the approved way. (surface/color/red, curface/color/blue, ...). From telnet, MP, property-browser, etc. everything keep unchanged, but from c++ you can directly access the vec3. We even can allow to store any (?) class directly in the property tree. The class must present functions to map it's components to the property tree in the common way. The nodes and actual basic datatypes would be just classes as any other class in the property tree. We even can take care, that a cast from and to the basic datatypes must be present. By mapping of all class members to the property tree in the approved way, we are able to ex- and import the property tree via xml. Best regards, Maik -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern hemisphere
Hi Heiko Heiko Schulz schrieb am 22.02.2009 13:41: Hi, I had just a test, and I'm not sure about a mistake in Rotorpart.cpp. I had just a test with the Ec135 and it wirk like it should. Bo105 and S64E Skycrane using Nasal for the blade bending, the ec135 not! So it could be that it has to do with the nasal code instead then rather a bug in the code! HHS I would be not surprised, if the mistake is within rotorpart.cpp. And this could be the cause for the sliding of the helicopters on the ground. Maik -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern
Hello Emmanuel, BARANGER Emmanuel schrieb am 22.02.2009 20:40: Hi Maik, I just tested your patch. This seems to work properly. I continue testing Best regards. Emmanuel Thank you very much. Can you check, if the sliding on ground (with engine off) is reduced? Best regards, Maik -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim sliding helicopters bug (+ ugly fix)
Hi, Melchior FRANZ schrieb am 02.02.2009 18:43: Ever since helicopter support was added to the YASim FDM there's an annoying bug: even when parked, with rotor off and braked, helicopters slide happily around on the ground. some time ago I dug into this problem and tried to fix it. My idea was, to check, if the movement is smaller than a very small number epsilon, and if yes, set the movement to zero. The movement need to be measured against the ground, which could be the carrier. This should fix the sliding on ground. But the fix didn't work, because there is no very small movement. All gears I was looking at (only a very small number) were oscillating with a frequency of 60Hz. The amplitude was much to large to neglect. I was not able, to kill these oscillations. The cause, why you can see this problem mainly on helicopters, are some simplifications in the rotor calculations, which cause the rotors to generate a very small force, even when not rotating. Non rotor aircrafts should show the same problem, if some wind is blowing. Maik -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
Hello, James Sleeman schrieb am 22.01.2009 01:14: Hi Maik, ... Just to clarify on the reference-dist, is it that this value is a diminishing effect, that is for reference-dist of 1 after distance 1 the volume is half original, after distance 2 the volume is 1/4 original (half of a half), distance 3 it's an 1/8th (half of a quarter). yes, exactly. Maik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
Hi, Maik Justus schrieb am 22.01.2009 13:45: Hello, James Sleeman schrieb am 22.01.2009 01:14: Hi Maik, ... Just to clarify on the reference-dist, is it that this value is a diminishing effect, that is for reference-dist of 1 after distance 1 the volume is half original, after distance 2 the volume is 1/4 original (half of a half), distance 3 it's an 1/8th (half of a quarter). yes, exactly. not exactly, it's 1/8th at distance 4 (doubled distance result in half volume). Maik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
Hi Vivian, Vivian Meazza schrieb am 22.01.2009 11:17: I would think that the attenuation of sound in air is amenable to mathematical calculation. Yes it is. (at lest if your distance to the sound source is large compared to the size of the source). Surely we shouldn't be guessing at some arbitrary reference distance? The problem is, we don't know, which distance the author was thinking about, as he defined/recorded the sound. For in-cockpit sounds the distance from the sound source to the cockpit may be a good guess, for out-of cockpit sounds the typical viewing distance of the aircraft could be a good guess, too. Therefore we will have two different guesses for e.g. the engine sound (as long as there are no different sounds defined for cockpit and external view)... Vivian Maik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
Hi James, the effect you are discussing is not the Doppler effect, but just the volume as a function of the distance. Every aircraft has its own sound definition including the distance, where the volume is halved (reference-dist) and the distance where the volume is cutted off (max-dist). The volume as a function of the distance is calculated by Openal. Therefore we need to know the aircraft, with wich you have the wrong effect and the kind of sound (most probably the engine sound?). If the sound configuration for this specific sound has reasonable definition for reference-dist we need to know your operating system and openal version. With this information other users can check, if they have the same problem. Maybe we can drill it down to a openal problem or maybe the distance passed to openal is wrong... Unfortunately I actually do not have a running flightgear; therefore I can not perform tests. Maik James Sleeman schrieb am 21.01.2009 13:46: The doppler effect (which I currently have working through the USE_SOFTWARE_DOPPLER define) has never sounded very real to my ear. Recently I've wondered if it might be to do with the volume dropoff not being enough. It's hard to subjectively quantify the dropoff in the flyby, but for example if we switch to tower view, it seems you can always hear the aircraft no matter how far away you get, for example, I was 100 miles from the tower and yet I had no trouble hearing the aircraft at all. Is the dropoff (if there is one at all, perhaps my mind is filling in the blank and making one), configurable at all through some property, I couldn't find one? It would be good to be able to play around with the numbers and see if it makes an improvement to the subjective convincingness of the doppler effect. --- James Sleeman -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] division by zero in YASim/Airplane.cpp (possibly caused by bad 787 model)
Hi
LeeE schrieb am 08.01.2009 12:40:
On Wednesday 07 January 2009, Csaba Halász wrote:
0x006a3b59 in yasim::Airplane::compileFuselage
(this=0xc066688, f=0x7f84f00bf930) at
src/FDM/YASim/Airplane.cpp:512 512 float segWgt =
len*wid/segs;
(gdb) p segs
$1 = 0
(gdb) p *f
$3 = {front = {-13.604, 0, 1.3998}, back = {-13.604,
0, 1.3998}, width = 5.901, taper = 0.10001,
mid = 0, _cx = 1, _cy = 1, _cz = 1, _idrag = 1}
Possible cause in Aircraft/787/787.xml:
fuselage ax=-13.6 ay=0 az=1.4 bx=-13.6 by=0.00
bz=1.4 width=5.9 taper=0.1 midpoint=0/
Oh yeah, and if the model is using the standard FG VRP (Visual
Reference Point) to align the 3D model and FDM config, ax ay (and
nearly always az) should all be 0.0.
What is not a problem. It is only a div by zero, if the length of the
fuselage is zero. (ax==bx, ay==by, az==bz)
az might be different in some
aircraft, like the Nimrod MR for example, because the nose has a
large offset in the YASim z axis.
LeeE
Maik
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Hi James, James Sleeman schrieb am 20.12.2008 13:21: Csaba Halász wrote: http://kcat.strangesoft.net/openal.html Some distributions (notably debian) have switched to this version from the original implementation. Ahh I see, using Ubuntu here and yes it appears to be this soft version. I think the Doppler effect even should work with openal-soft. Can you check, what is defined after #ifndef HAVE_WINDOWS_H #ifdef AL_VERSION_1_2 #define USE_OPEN_AL_DOPPLER should work #else #define USE_OPEN_AL_DOPPLER_WITH_FIXED_LISTENER better than nothing #endif #else // the Open_AL Doppler calculation seems to be buggy on windows #define USE_SOFTWARE_DOPPLER seem to be necessary #endif (file simgear/sound/sample_openal.hxx lines 65ff) and evaluate if Doppler works for you if you define one of the other two USE_ macros (and undefine the defined one). Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Hi Melchior, Melchior FRANZ schrieb am 20.12.2008 15:56: * Melchior FRANZ -- Saturday 20 December 2008: I just defined USE_OPEN_AL_DOPPLER after that #if* group, but Doppler didn't work. PS: not just after the group, but instead of it, so the other optional symbols weren't defined. m. Did you try to #define USE_SOFTWARE_DOPPLER instead? Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Hi Melchior, Melchior FRANZ schrieb am 20.12.2008 17:54: * Maik Justus -- Saturday 20 December 2008: Did you try to #define USE_SOFTWARE_DOPPLER instead? No, AFAICS that enables your manual Doppler calculations, which you added for openal implementations with broken Doppler (or with correct Doppler that doesn't work with our broken setup ;-). Yes, that is the actual state under windows. And the manual calculation works quite fine. And if it works with openal-soft we should use it with openal-soft. I only wanted to know if openal-soft's Doppler works with fgfs, and apparently it doesn't. (Though, as you know, the openal-soft maintainer claims that his version is correct and that some of the others are buggy. So our code might be tuned for broken openals and, thus, not support openal-soft.) Yes I know. Unfortunately I do not have a openal implementation with working Doppler here; therefore I can not investigate, what need to be changed, to get it working with openal-soft. I had a quick look over the code and couldn't find any suspicious line. m. Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Melchior FRANZ schrieb am 20.12.2008 18:29: * Maik Justus -- Saturday 20 December 2008: And the manual calculation works quite fine. And if it works with openal-soft we should use it with openal-soft. Ah, ok. I re-tried with USE_SOFTWARE_DOPPLER, and that only worked for a very short time (less a minute), and then there was no sound at all. m. Strange, in this mode I only modify the pitch value in the same range any sound.xml file can do even without Doppler. Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Hi, Melchior FRANZ schrieb am 20.12.2008 20:01: Yes, USE_SOFTWARE_DOPPLER works with openal-soft. Is there any chance to get to know at compile time, that openal-soft is used? If not: is there any chance to get to know at runtime, that openal-soft is used? if yes: we need to change the concept of choosing the Doppler algorithm at compile time to do so at runtime. Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn sound
Hi Curt, Curtis Olson schrieb am 07.11.2008 23:12: On Fri, Nov 7, 2008 at 2:55 PM, Curtis Olson wrote: Question: has anyone noticed anything odd with the stall horn sound in the default c172p in the current cvs (although it's likely been an issue since we migrated to openal?) When the stall horn goes off, it used to be a clean/constant tone, however in openal it's warbly disjointed crackly sort of sound. It's enough to be very aurally annoying. I almost wonder if this issue affects all our sounds, but because the stall horn audio is such a clean sine wave with no extra noise or character, any little imperfection in the audio system really jumps out when the sound is played. This really seems like it could be related to inconsistent positioning of the listener versus the sound source? The audio imperfections seem to be correlated with frame rate changes. Anyone have any ideas on this? Replying to my own message here ... In src/Main/main.cxx the sound positions and velocities are updated. I observe that the velocity is computed as (current position - last position) / dt. However, this approach leads to inconsistent velocities because of some very subtle issues related to the flight dynamics update loop. If I force the velocities to be zero, the sound quality *greatly* improves, and not just with the stall horn. The overall sound is much more rich and vibrant (at least to my ears.) Unfortunately I do not have a running flightgear now. I assume, that you are in the cockpit. Can you check what happens, if you change line 642 from globals-get_soundmgr()-set_source_vel_all( model_vel ); to globals-get_soundmgr()-set_source_vel_all( listener_vel ); This forces the velocities of all sounds to be the same as the listener velocity. In theory these two values should be exactly the same when you are in cockpit view. If the sound is ok after this, there is an issue with the order of view position calculation, model position calculation and sound calculation. If the sound is not ok, it could be either a bug in the Doppler calculation (which kind you are using: USE_OPEN_AL_DOPPLER, USE_OPEN_AL_DOPPLER_WITH_FIXED_LISTENER or USE_SOFTWARE_DOPPLER?) or (again) a bug in the view position calculation or in the model position calculation. If you are not using USE_OPEN_AL_DOPPLER I am rather sure, that the viewer and the model position are not aligned, probably due to the order of updating these values. I'm not sure the best solution here since I'm sure we need correct velocities to get correct doppler effects. I am trying to understand the code a bit more and I see that both the listener and the sound velocities are rotated into a new coordinate space. Is this necessary? It seems like the important thing is the relative velocity of the sounds, not what coordinate system they are transformed into? No, not only the relative velocity is from interest. If you are in front of a mach 2 flying jet you will hear nothing from the jet, even with a relative speed of zero. But you can use any coordinate system as long as it is not moving compared to the air. If I remember correctly, we are using a coordinate system with its orient at the listener position in the same orientation as the aircraft.. Therefore we need only an offset to transform the sound source coordinates to this coordinate system and don't need to transform the sound source orientation. Is it worth giving up on doppler effect to get reasonable cockpit sounds, or is doppler a big enough win to put up with really crappy cockpit sound with lots of artifacts? I think its worth to dig down this bug. It wouldn't be hard to add an --enable/disable-doppler configuration option? sure, but better fix the problem instead of adding a switch to choose between two problems. From my point of view the Doppler effect adds much realism to flightgear. As a workaround we could switch off the Doppler effect in all internal views. But there are other bug reports about the Doppler sound, maybe your observations lead us to the right track to fix some of them. Thought/comments? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ Regards, Maik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG - FGFX class
Hi Erik, Erik Hofman schrieb am 23.10.2008 18:47: Vladimir Karmishin wrote: I need any thoughts, imaginations about which way can it be modified to let it work with multiple 3d sound emitters. Reading this again there might be some confusion; aircraft can have multiple 3d sound emitters already, they are just tied to the main aircraft right now (and the listener is always facing the main model, this is probably why doppler doesn't function too well). no. The Doppler problems are due to OpenAL bugs and limitations. On most systems (at least at all which are using Open AL software Doppler calculation) I got strange effects. On Linux systems a workaround was to use only the relative velocity of listener and sound, which is physically not correct. But on windows even this approach results is strange effects. There I use my own software implementation in simgear and pass the calculated pitch and volume to Open AL. But Open AL clamps the pitch factor (If I remember correctly to 0.5 ... 2), and additionally many aircrafts modify the pitch by them self. This limits the Doppler effect in Flightgear. Melchior sent me a note, that actual Open AL might be less buggy, but he still noticed strange effects. But you can already define the position an direction of each sound effect. Yes, and many aircrafts make use of this, e. g. the S58 or the Bo105. The remaining problem is to make the AI models also emit sound effects. Erik Maik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim not be able to simulate small aircrafts with canard-config?
Hello Heiko, Did you try to call the main wing in the fdm file hstab and the canard wing with the real incidence values? And check the position of the c.g. Maik Heiko Schulz schrieb am 12.09.2008 03:51: Hi, Some months ago I began to model a Gyroflug Speedcanard SC-01B, a well-known german canard-aircraft. (this one: http://www.airliners.net/photo/Gyroflug-SC-01B-160-Speed/1389966/L/) Very similar to the Long-EZ by Rutan, but the fuselage is from a Twin-Astir, the airfoils by Eppler ( the exactly name I can give you, if you want). It has a 160PS strong engine and flys like a jet. My attempt to create a fdm was not successful: it always fell down, or spinned. So I asked Oliver Predelli, (author of the Braunschweig scenery and some YASIm-aircrafts) for help. At least he had the same problems, but he managed to get a stable fdm- but the perfomance was far away from realistic: it went never be faster than 90 kn though it had an engine power of 4000 PS! Some days ago I discovered the LongEZ by Helijah- but the fdm is fake. I got my hands on it and just changed the position of the canard and the main wing, so it has canard config: The same behavior: spinning, slow though it had enough power... So it seems to me, that YASim is not be able to simulate this type of aircraft correct. Am I right? In the attachement you will find the fdm-file by Oliver in hope someone can help. Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound positioning and orientation
Hi Erik, Erik Hofman schrieb am 21.08.2008 14:25: Hi, ... There are two options, modify the code to reflect what is described in README.xmlsound or modify the README file. I would prefer to modify the README file. I made some asymmetric sound for helicopters (S58, bo105) and adjusted them, that the result give the correct sound. But if there are other aircrafts with asymmetric sound (e. g. multi engine aircrafts), which have wrong sound now... Does anyone know of an aircraft, with wrong sound? I think I already know the answer, but which of the two is preferred by others? If no one cares that much I'll modify the SimGear code to reflect what is described in the README file to prevent the need to modify too many configuration files. I am not sure, if there is any need to modify configuration files if only the documentation is corrected. Erik Maik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Input/Output
Hi Tat, Tatsuhiro Nishioka schrieb am 24.06.2008 06:05: HI, I guess spinning the cockpit around z axis can roughly achieve what Curt says. When making a coordinated turn with 15 degree bank, you can rotate the cockpit around roll axis about 15 degree, and then, spin the cockpit around z axis. this way you can keep yourself on the seat depending on the speed of the spin. (spinning too fast may make you feel sick and is not very realistic though :-p). But you need two spinning centers, one for right turns, and one for left turns. And even more for wider and narrower turns. Just calculate the aircrafts acceleration, add the gravity and calculate the direction of the resulting acceleration vector. Rotate the platform, that the gravity vector shows in the same direction, that's all. Maik - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] I need a help
Hi Héber in which direction can you rotate platform (is z the vertical axis)? I think you should not only use the aircrafts orientation for the rotation of the platform, but the acceleration, which should give a much more realistic feeling. The interface to flightgear should not be a problem. Maik Héber Cos.Fer. schrieb am 21.06.2008 23:34: Thanks RON for your answer. So, my hardware will be a joystick that i will made by myself and my group, with joystick/yoke and pedals. (Our project is made thinking about the CESSNA airplane.) Then, we need help about the comunication of the game with the joystick. In this comunication I need send of the game to the hardware angles of rotation on axis X and Y. I think it's made on Input Classes, with the angles that the control panel use for show rotation of airplane. Do you undestand what I try saying? I can undestand your English, ok. Thanks. Héber Costa Ferreira I CO 1:25 Porque a loucura de Deus é mais sábia do que os homens; e a fraqueza de Deus mais forte do que os homens. --- Em *qui, 19/6/08, Ron Jensen /[EMAIL PROTECTED]/* escreveu: De: Ron Jensen [EMAIL PROTECTED] Assunto: Re: [Flightgear-devel] I need a help Para: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Data: Quinta-feira, 19 de Junho de 2008, 21:02 On Thu, 2008-06-19 at 18:51 -0700, Héber Cos.Fer. wrote: Hi guys, Im new in here. I have a college work with a fisical flight simulator, with a Joystick and a rotational plataform. Then, I need a game that give me variables of rotation of airplane. If someone could help me about it, I will be grateful. Imagine the FlightGear with a rotational plataform. It would be wonderful. Forgive my english, i will improve this. Héber Costa Ferreira Héber, Sorry I don't speak Portuguese. :) Hooking the Flight Gear Flight Simulator up to a motion platform sounds like an interesting experiment. You must be more specific about what you need. We need more details about what you want to do: - How you connect to your hardware? - What exactly is your hardware? - Do you want to write software? Try the IRC channel, too. Boa sorte, Ron - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Novos endereços, o Yahoo! que você conhece. Crie um email novo http://br.rd.yahoo.com/mail/taglines/mail/*http://br.new.mail.yahoo.com/addresses com a sua cara @ymail.com ou @rocketmail.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Input/Output (It was: I need a help)
Hi Héber Héber Cos.Fer. schrieb am 23.06.2008 21:53: Maik, I think it's better to receive angular position than acceleration, because my plataform is limited in less than 90º (+45, -45). It's only a prototype. But you can not feel orientation directly, you only can feel acceleration. Therefore I expect it to be much more realistic if you try to use the acceleration for your platform. Of course you can not change the magnitude of the acceleration, but you can control the direction. Therfore take the aircrafts acceleration add the gravity and determine the direction of the resulting vector and use this for calculating the two angles. Think of an aircraft ready for take off, you push the throttle to maximum and you can feel acceleration (you only need a few degree tilting of the platform for this) with 45° tilting you can simulate an additional acceleration up to 1g (unfortunately only direction, not magnitude). Maik - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/FDM/JSBSim/models/flight_control FGActuator.cpp, 1.2, 1.3 FGFCSComponent.h, 1.3, 1.4
Hi Fred, Frederic Bouvier schrieb am 07.06.2008 10:14: I was able to compile JSBsim and FG today, except a small glitch with non portable code in new_gui.h I was able to fix using plib. Thank you! Thanks, -Fred Maik - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/FDM/JSBSim/models/flight_control FGActuator.cpp, 1.2, 1.3 FGFCSComponent.h, 1.3, 1.4
Frederic Bouvier schrieb am 05.06.2008 22:15: These changes are very unfortunate. Like it or not, cin, cerr and cout are defined in iostream under MSVC. FG is no longer compilable for me :-( -Fred Hi Fred, don't know what is different here, but yesterday evening I compiled fresh cvs osg-fg on MSVC-express without problem (based in Olaf Flebbes project files). I have the problem, that some parts of the static scenery isn't found (alcatraz, stadium near KSFO and many others, but not all). The fg-root path is added twice, so I changed my starting directory, that fg-root can be added twice (fg-root=../../fg-cvs/data). I don't know, when this problem started, my last build was rather old... Maik - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS - Frame Rates under Windows XP
Hi Frederic Bouvier schrieb am 01.04.2008 08:52: I have a Core2 Duo 2.66 ( E6600 ) and a 7600GT. I always saw the greatest fps increase after upgrading CPU and was disappointed by several GPU-only upgrade. All I can tell is that with the Seahawk, at KSFO, I have 75hz steady ( with vsync on ) if I wait for 2 minutes. In the meantime, fps vary greatly from 40 to 75, during the threaded model loading process. And this is done with a 50% CPU usage. Here (WinXP, Core2 Duo 3Ghz, 8800GT) FG consumes more than 50% CPU. Directly after starting (when the 3D scenery is displayed for the first time) the CPU usage is 90%. Therefore the loader-thread seem to run on a different core than the rest (or is there another thread?). -Fred Maik - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 350 Mb movie
Hi, Georg Vollnhals schrieb am 01.03.2008 03:41: Curtis Olson schrieb: I just posted a movie of one of the things I've been working on this week. It's a light-twin flight simulator with full cockpit and 7 visual channels (LCD displays). This movie shows an approach into 6WA8 (Ranger Creek) along with the touch down. This movie is straight off my camera without any editing or compression so it weighs in at a whopping 345Mb. But if you have the bandwidth to burn I think it's pretty cool. The 7 visual channels combined with terrain, tree cover, full instrument panel, and cockpit enclosure really give you an immersive feel. http://baron.flightgear.org/~curt/tmp/MVI_0250.AVI http://baron.flightgear.org/%7Ecurt/tmp/MVI_0250.AVI Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ Thank you very much for sharing this. It is very impressing. Seems you really do not need projection screens if you have this 7 LCD displays arrangement. FlightGear combined with the right hardware does a good job. Georg EDDW great. I think the Depth percepted cockpit idea combined with the 7 LCD Displays could increase the realism further. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Red Bull Air Race for FlightGear
Hi Torsten Torsten Dreyer schrieb am 01.02.2008 22:01: Thank you very much for this work. Unfortunately I am not able to get it running. I can't see any pylon. I just want to know, if it works for someone else? Hi Maik, please check: did you use the --prop=/sim/rbar/filename=Berlin_2006.xml argument? is the Berlin_2006.xml file in your $HOME/.fgfs directory? That was my problem. I placed this file in my $FGROOT/data directory. (Maybe this would be the better place for that? For no other extension I had to install any data in the home directory. And the home directory is not within the cvs-tree.) Thank you very much and best regards, Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth percepted cockpit
Hi Joacher, a very interesting and promising idea. Is the needed hardware available separately? If yes: how much does it cost? Maik [EMAIL PROTECTED] schrieb am 01.02.2008 20:59: I think I have to emphasize this: There are two heads: Your real one in front of the monitor and the virtual one inside the planes cockpit (aka camera position). The idea is, to translate the virtual head according to the translations of your real head in front of your monitor, thus leading to the shown depth perception. Of course the virtual head can't follow every translation the real head can do, because usually a office is bigger than a cockpit. But its not to discover your cockpit from new exciting perspectives, it's to provide you a depth perception. So the virtual camera has strong constraints in the extend of its translation. Consider it as a maximum of 25 cm in each direction around the default position. So you won't be able to discover your leg room, to lean out of the window or to examine your flightsticks back! It should just use your head shaking to provide you a depth perception. Not more, not less. Regards, Joe - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Red Bull Air Race for FlightGear
Hi Torsten, Torsten Dreyer schrieb am 01.02.2008 17:49: Hi all, here is something that might kill your weekend. So if you promised your kids a great weekend at the zoo or wanted to paint your house: *** STOP READING *** But if you have some time to spare: go on! I have written some peaces of Nasal code and a little other stuff to make a the Air Race flyable in FlightGear. The pylons have been in the fgfsdb for a while and I thought it might be some fun to get scored for flying through them. You may find a short introduction and the required files to do the Berlin-Tempelhof AirRace from 2006 at http://www.t3r.de/fg/fgfs-rbar.html Expect to get addicted... Enjoy, Torsten BTW: Comments and/or bug-reports are welcome. Thank you very much for this work. Unfortunately I am not able to get it running. I can't see any pylon. I just want to know, if it works for someone else? Thanks Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Hi Stuart, Stuart Buchanan schrieb am 28.01.2008 10:25: If you have a look in the data/Textures/Trees/ directory you will see that the .rgb files are actually a strip of different trees, evenly distributed along the x-axis. You can change them in any way you want, as long as you ensure that they are evenly spaced, and you update the tree-varieties tag in materials.xml to match. The transparency--bug appears only, where the alpha channel of the texture is neither 0 nor 100%. Therefore I changed the alpha channel to be only zero or 100%. But the problem is not solved. The texture is scaled (mip mapping?), and therefore the new alpha value is interpolated between the original values resulting in semi-transparent values. If it would be possible to exclude the alpha channel of the tree-textures from the interpolation, the transparency problem could be solved fully without any sorting (just by changing the textures). If it is not possible: sorting of the triangles within each tree would help in many cases. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pushback
Hi Gijs, a few days ago Jester, simstick and me tried to get the pushback working over the MP-protocol. In principle it worked. But the problem is the time lag between th different users. To avoid ugly oscillations it was necessary to use a very elastic junction between pushbak und 787, which looks (and is) very unrealistic. I think many users would rate this as a bug. At aerotow the elastic tow is not so noticeable. I think for simulating pushback (or skydiver; anything where a non-elastic junction is needed), we need another concept. The FDM of the airliner in pushback (or the FMD of the skydiver while lifting) need to be switched off and the the pushback (or of the jump-plane) need to do all the simulation. Therefore we need to set position and orientation of another aircraft over the MP-protocol instead of transmitting forces. For the skydiver nearly anything is there. We just need one Nasal listener on the skydiver side, which listens for setting position/orientation/speed by the FDM and overwrites this with the values (+ offset) of the jump-plane. And we need something similar at the jump-plane to set the position of the skydiver inside the jump-plane (without the skydiver would follow the jump plane in some distance (due to the time lag)). For the pushback we need something similar. Additionally the pushback need to know the gear positions of the airliner to simulate it properly. But all this should be possible in Nasal. Best regards, Maik Gijs de Rooy schrieb am 21.12.2007 16:06: Ok, let's try the 787-8 than. Gijs Date: Fri, 21 Dec 2007 15:54:41 +0100 From: [EMAIL PROTECTED] To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Pushback 787-8 --- Gijs de Rooy [EMAIL PROTECTED] schrieb: The 737 is JSBSim - it only works with YASim. HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Well, what aircraft do you recommend? _ Bekijk Yes-R's real life soap op MSN Video! http://video.msn.com/video.aspx?mkt=nl-nltab=m1192527562294vid=8aff5b76-b78d-4b55-8b64-ef7e1d73aab2playlist=videoByUuids:uuids:50b732c2-c105-41e9-adf0-36bd627d4eaa,0813da8c-031b-423f-a79d-35d925aee805,5cce447e-948d-43af-9862-45bb6bb9d6d8,6a39138c-f562-4254-be70-9d93343650f8,f9b8d78f-05a4-4c74-8e4b-28d20a4037abfrom=NLNL_Yes-R - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Plan je evenement, nodig mensen uit en deel je foto's met Windows Live Events http://events.live.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Dave, same here. But it is ok, if I start with 4:3 window and maximize it when fg runs (my normal start procedure). Maik dave perry schrieb am 06.01.2008 05:08: Maik Justus wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Hi Maik, I have had a 16:9 flat pannel for some time. For the first time in several months, I built fgfs for osg from fresh svn and fresh cvs. What I noticed right away that has changed is that osg fgfs does not handle the --geometry=1680x1050 correctly anymore. The height of the image is too small for the width. The gages are not round. The plib branch still handles this correctly. Are you seeing what I am seeing or have I missed a patch? When I adjusted the width of the window until round objects are round and then measure the aspect ratio of the adjusted window, the aspect ratio is 4/3. Here is what comparing the plib to the osg response to changing the value of /sim/current-view/aspect-ratio-multiplier tells me: In plib, it adjusts the displayed aspect ratio. I can get the same distortion in plib fgfs as in osg fgfs by changing this value to ~1.2 instead of 1. But if I try to fix the view in osg fgfs by adjusting this value from 1 to 0.8333, all it does is scale the distorted image. i.e. it is adjusting the effective fov, not the aspect ratio. - Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Dave, I checked again, if I start with a 4:3 resolution the gages remain round when maximizing to 1680*1050 by clicking the square in the upper right corner. I am running win xp, compiled on msvc-express. The same, if I start with --resolution=800x600. If I start with --resolution=1680x1050 the gages are not round, but the property browser seem to show the same values in sim/current-view. Maik dave perry schrieb am 06.01.2008 16:55: Hi Maik, If I use the command line to launch with the default 800x600 window and then use the gnome window maximize (i.e. click the square in upper right corner of the window), I get the distorted-aspect-ratio image filling the screen. I am running Fedora 7 with nvidia graphics, gnome window manager. What is your environment? -Dave Maik Justus wrote: Hi Dave, same here. But it is ok, if I start with 4:3 window and maximize it when fg runs (my normal start procedure). Maik dave perry schrieb am 06.01.2008 05:08: Maik Justus wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Hi Maik, I have had a 16:9 flat pannel for some time. For the first time in several months, I built fgfs for osg from fresh svn and fresh cvs. What I noticed right away that has changed is that osg fgfs does not handle the --geometry=1680x1050 correctly anymore. The height of the image is too small for the width. The gages are not round. The plib branch still handles this correctly. Are you seeing what I am seeing or have I missed a patch? When I adjusted the width of the window until round objects are round and then measure the aspect ratio of the adjusted window, the aspect ratio is 4/3. Here is what comparing the plib to the osg response to changing the value of /sim/current-view/aspect-ratio-multiplier tells me: In plib, it adjusts the displayed aspect ratio. I can get the same distortion in plib fgfs as in osg fgfs by changing this value to ~1.2 instead of 1. But if I try to fix the view in osg fgfs by adjusting this value from 1 to 0.8333, all it does is scale the distorted image. i.e. it is adjusting the effective fov, not the aspect ratio. - Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Arvid, maybe your pixels are not of square size? If yes: can you look to /sim/current-view/aspect-ratio-multiplier? If it is not 1, then we need to scale 47.5 with this factor (to get a larger fov). Thank you very much, Maik AnMaster schrieb am 05.01.2008 11:40: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Maik Justus wrote: Hi Arvid, AnMaster schrieb am 04.01.2008 23:13: My resoltion is 1400x1280, not 4:3 nor 16:9 ? 20 1400x1280 TFT. I got no idea what format it is, but the monitor works well for me. The screen area of the monitor is about 30.5 cm high and 41 cm wide (+/- a few millimeters). but you also have to consider window borders. Not sure how large they are, however the screenshots I took at www.flightgear.org (A10-KNID-01 for example), were in maximized window. Should be possible to calculate from that. I think the borders have only very small effect to the calculation. Just try a fov of 47.5 (if your resolution is 1400x1280). Will try that. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHf16yWmK6ng/aMNkRCpB3AKC1T7k0jRgCUM/DwB7bqJDnt6IeZACfQyXE Sq8oyfTGeHGv2xiyuOh/rhA= =6nKA -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Arvid, AnMaster schrieb am 05.01.2008 14:48: it is 1400x1050. ok (4:3). Try 58.6. Thank you, Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AI load_demo.xml, NONE, 1.1]
Hi Georg, Georg Vollnhals schrieb am 05.01.2008 15:32: Hi Vivian, very nice to notice that there is activity around the external load development. I activated your scenario after compiling Tim Moore's additional source code. The load is visible at KSFO - even at night with luminescend arrows!!! - but I could not catch it with a helicopter. So I think some additional nasal code has to be written like for the banner catching with the Dragonfly. I am working on that. Or is there a trick I should know? no, unfortunately no trick ;-( Regards, Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots)
Hi Vivian, Vivian Meazza schrieb am 21.12.2007 00:11: Christmas has arrived slightly early! I've got something which: A. runs B. looks OK with limited testing The ballistic object aligns with the direction of flight in pitch and heading with an external force applied. It would be possible to align it with the direction of the external force, but I think that would need roll as well. I'm not sure which one would look best. The external force is defined in terms of: Magnitude (lbf) Azimuth (deg, North = O) Elevation (deg, up = 90) In a user-defined property. Of course, some external program needs to set the external force data. This all now needs testing in a more realistic environment. I'm not totally convinced that the ballistic object won't disappear into space/to the centre of the earth, or oscillate like a deranged spring. Vivian Thank you for the enhancement of AIBallistic. The external load works here, but not perfectly. I need to limit the force to approx 1000 lbf (which is not enough to simulate it properly). If I do not limit the force, the load (the 3d-model) disappears, but it is still in the property tree and reacts on forces (maybe not correct, not sure, but it is still there). Any idea, what could cause this? Best regards, Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots)
Hi Vivian, Vivian Meazza schrieb am 06.01.2008 01:01: Maik Justus wrote: Hi Vivian, Vivian Meazza schrieb am 21.12.2007 00:11: Christmas has arrived slightly early! I've got something which: A. runs B. looks OK with limited testing The ballistic object aligns with the direction of flight in pitch and heading with an external force applied. It would be possible to align it with the direction of the external force, but I think that would need roll as well. I'm not sure which one would look best. The external force is defined in terms of: Magnitude (lbf) Azimuth (deg, North = O) Elevation (deg, up = 90) In a user-defined property. Of course, some external program needs to set the external force data. This all now needs testing in a more realistic environment. I'm not totally convinced that the ballistic object won't disappear into space/to the centre of the earth, or oscillate like a deranged spring. Vivian Thank you for the enhancement of AIBallistic. The external load works here, but not perfectly. I need to limit the force to approx 1000 lbf (which is not enough to simulate it properly). If I do not limit the force, the load (the 3d-model) disappears, but it is still in the property tree and reacts on forces (maybe not correct, not sure, but it is still there). Any idea, what could cause this? Hmm - the mass of the load in load_demo is only 170 lbs - applying 1000lbf could well send it into orbit! Note your mass is in slugs, and you need a realistic Cd and eda. I _think_ the math is correct, but I'll look at it again Vivian Sorry, I limited the force to 1000N (about 200lbs). 200lbs are enough to lift the load. Lifting works. Therefore the math itself is correct. But something strange happens, if I do not limit the force. (and sometimes forces greater than 200lbs are needed ) Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fg (plib branch) crashes, probably in groundnetwork.cxx
Hi, with the plib branch (actual cvs, source and data) fg crashed here from time to time. Now I have a new (faster) PC and fg crashes much more often. It seems, that the frame rate has influence on the crash rate. Compiled with debugging information and running in the debugger I got no crash, without debugging information I get the crashes. The debugger points to groundnetwork.cxx line 935. With the osg branch I get no crashes. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi,
Maik Justus schrieb am 26.12.2007 20:38:
Hi Syd,
what's about an algorithm, which checks the ratio of the screen and sets
fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) /
(16/9) )
Maik
P.S.:
for non-physicists:
(55 / 73,333 = (4/3) / (16/9) )
Meanwhile I have a new computer wit 16:9 screen and the same problem.
I've modified the calculation in viewer.cxx as mentioned above. Syd,
please check, if this would work for you. Then we can think about, how
to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT
case?). The patch is for the osg-branch, but it works with the plib
branch, too (maybe some lines offset).
Maik
Index: viewer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/viewer.cxx,v
retrieving revision 1.27
diff -u -p -r1.27 viewer.cxx
--- viewer.cxx 5 Nov 2007 22:19:39 - 1.27
+++ viewer.cxx 4 Jan 2008 19:54:11 -
@@ -640,15 +640,15 @@ FGViewer::get_h_fov()
{
switch (_scaling_type) {
case FG_SCALING_WIDTH: // h_fov == fov
- return _fov_deg;
+ return _fov_deg/_aspect_ratio/4*3;
case FG_SCALING_MAX:
if (_aspect_ratio 1.0) {
// h_fov == fov
- return _fov_deg;
+ return _fov_deg/_aspect_ratio/4*3;
} else {
// v_fov == fov
return
-atan(tan(_fov_deg/2 * SG_DEGREES_TO_RADIANS)
+atan(tan(_fov_deg/_aspect_ratio/4*3/2 * SG_DEGREES_TO_RADIANS)
/ (_aspect_ratio*_aspect_ratio_multiplier))
* SG_RADIANS_TO_DEGREES * 2;
}
@@ -666,19 +666,19 @@ FGViewer::get_v_fov()
switch (_scaling_type) {
case FG_SCALING_WIDTH: // h_fov == fov
return
-atan(tan(_fov_deg/2 * SG_DEGREES_TO_RADIANS)
+atan(tan(_fov_deg/_aspect_ratio/4*3/2 * SG_DEGREES_TO_RADIANS)
* (_aspect_ratio*_aspect_ratio_multiplier))
* SG_RADIANS_TO_DEGREES * 2;
case FG_SCALING_MAX:
if (_aspect_ratio 1.0) {
// h_fov == fov
return
-atan(tan(_fov_deg/2 * SG_DEGREES_TO_RADIANS)
+atan(tan(_fov_deg/_aspect_ratio/4*3/2 * SG_DEGREES_TO_RADIANS)
* (_aspect_ratio*_aspect_ratio_multiplier))
* SG_RADIANS_TO_DEGREES * 2;
} else {
// v_fov == fov
- return _fov_deg;
+ return _fov_deg/_aspect_ratio/4*3;
}
default:
assert(false);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Arvid, AnMaster schrieb am 04.01.2008 23:13: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 My resoltion is 1400x1280, not 4:3 nor 16:9 ? but you also have to consider window borders. Not sure how large they are, however the screenshots I took at www.flightgear.org (A10-KNID-01 for example), were in maximized window. Should be possible to calculate from that. I think the borders have only very small effect to the calculation. Just try a fov of 47.5 (if your resolution is 1400x1280). Other than that I think Alex Bory's suggestion was very good. That's what the patch is doing. Regards, Arvid Norlander regards, Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Funfly.
Hi Curt, thank you very much for this great event. Unfortunately my hardware forced me to be a spectator (due to thermal problems my notebook throttles down after some minutes of flightgear; I need to clean the cooling system again. And I am thinking about buying a new computer). What could help us with such competitions would be an client, which assists in the time-recording. Like a state machine, which responds on chat-messages and has a state for every mp-aircraft. With a chat message like competition the state of a mp-player changes to a new state, which checks for groundspeed 1 kts. The next state could be groundspeed 10 kts (with time stamp). The next state could be groundspeed 1 kts, with reporting of the difference to the last time stamp. This can be enhanced witch checks for positions, additional messages, checks for aircraft-type, checks for plausibility of speed and acceleration, checks for orientation, additional scoring (penalties), included web-server with best of day, best of week, best of ever grouped by aircraft. All this for several competitions, activated by different chat-messages of the competitor. With such a system the todays events could be rated very easy. And events like the red bull racing or reno air racing could be possible. Anyone interested in coding such a client? And I like Hans idea of Fly Ins (with basic ATC?) (and with sight seeing tours...) Maik Curtis Olson schrieb am 01.01.2008 18:26: On Dec 31, 2007 1:25 PM, Curtis Olson wrote: I am thinking it would be fun to schedule a multi-player fun fly tomorrow (New Year's Day). The FunFly is now complete! We had 9 active participants and at least 9 spectators, maybe more at times. I think everyone had a good time. It was really fun to see all the airplanes concentrated together like that! I think someone brought their camera, so we will post pictures at some point when the film is developed. I have posted the final results here: http://baron.flightgear.org/~curt/funfly/ http://baron.flightgear.org/%7Ecurt/funfly/ Thanks to everyone who participated and spectated. Happy 2008! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Funfly.
Hi Curt, Curtis Olson schrieb am 01.01.2008 21:54: A sailplane/soaring competition would be another fun one. Maybe we sign up a couple tow operators who stay busy towing people up, and then see who can stay aloft the longest. Sounds great. E. g. build teams with one tow aircraft and one glider each. All teams start at the same time. All tow aircrafts need to land within 200s at a small runway and then see, which glider lands last (on the small runway). Maik Another angle that could be fun is to come up with some team competitions. How about a sky diving competition? If we can do aero towing, can we attach MP skydivers to a jump plane. Then individuals can choose when to jump out and the person that gets closest to the target wins? We'd probably need an improved parachuter model ... might be a fun project for someone ... Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] fix ATC chat
Hi Stuart, Stuart Buchanan schrieb am 31.12.2007 14:39: I'm 90% sure that this is a side-effect of the problems we're having with MP servers, rather than the chat code itself (though there were certainly problems with the chat code before, so I could be wrong). ... Based on this, I think what is happening is that the servers are out of sync, and one is passing old data, which is periodically over-written by the data from another server, causing an oscillation in the properties. If you are right, all user (at least, if they are connected to the same server) should see the same repeated messages. But sometimes I saw messages like oh, I have the repeating-message-bug without having them here (but maybe I was on another sever). But this should be easy to check if it occurs again. If it is not a server problem it could be due to the possibility of the synchronization of the time-bases (/offsets) of the MP-players with the user on the user side. IIRC: if the received package is older than 10(?) seconds or is from the future, the time offset is corrected. This could lead to a repetition of an old message. Maybe there is a bug within this code? Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] helicopters flight dinamics models
Hi Veronica, veronica galli schrieb am 27.12.2007 11:14: Hello, I'm Veronica Galli, an Italian student of aerospace engineering. I'm trying to develope a good flight dinamics model for helicopters and I'm just watching FlightGear's ones. It sounds me that the only one which supports helicopters is YASim but I can not run it standalone. There is a standalone yasim-test for running the solver without flightgear. You only need to add input and output interfaces and you can run YASim standalone (AFAIK). Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RE water crashes or landing - a change in design principle and default is suggested
Hi, Shad Young schrieb am 26.12.2007 10:00: GWMobile wrote: You are really missing the point. What I am saying is no one interested in reality is going to land on water in the first place so the people who would expect a crash indication won't be doing the landing anyway. Well, maybe so, then again... maybe not... http://ca.youtube.com/watch?v=01E_6oxvlQA This should be possible with all YASim aircrafts; but I am not sure, if we have such flat water in Flightgear. And this can be done, too: http://ca.youtube.com/watch?v=W7o--nT-Pt0feature=related (and we get realistic behavior even without simulating structural damages). Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) SydSandy schrieb am 26.12.2007 06:25: Hi everyone , and merry christmas... I'm busy playing with my new 1440x900 flat - panel monitor ...wow what a difference in FG ! Which gave me an idea maybe others would appreciate too Before this , a default field 0f view of 55 was about right ... now I need to set it to 70 for a good view . Rather than modifying my set files and possibly ruining someone else's setup ... maybe a field-of-view slider in the view options would be an idea ? Im poking around in view.xml now but might take a bit to figure it out :) Cheers - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RE water crashes or landing - a change in design principle and default is suggested
Hi, GWMobile schrieb am 25.12.2007 14:57: The original post quoted below exemplifies why I beleive it is a mistake to ever have crash detection for water in a flight sim however let me lay it out simply. 1. Anyone who lands on water in a flight sim knows they are doing it. It is highly likely they WANT to do it - ie have a float plane or want to ditch. Setting a crash default is silly. It forces people to not be able to do what they want and it isn't realistic. Just to clarify: YASim does not crash, because you land with an airplane on water. With most aircrafts you will get a nose-roll-over (due to the high drag of the gear in the water) and the crash is the result of this nose-roll-over. If the parameters are unrealistic you can tune them. You can even describe the fuselage of an aircraft with retractable gear as a float to get emergency-water-landing-capability. And you can add additional gears to aircrafts with retractable gears defining the fuselage as a skid on ground. For an example try the dhc2F. You can land it on grass with retracted gear, but you should not try to land on water with extended gear. Therefore everything you are asking for is already there. The only question is, if the aircraft maintenancer is using all these features. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The north pole is gone
Hi Gerard, gerard robin schrieb am 24.12.2007 01:14: BTW: i could not use the c172 because mine makes difference between water and solid Cheers Yes, all YASim aircrafts do. But while the default scenery looks like water it is marked as solid. Therfore you can land on water everywhere you have no scenery installed. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots)
Hi , Vivian Meazza schrieb am 21.12.2007 00:11: I wrote: Sent: 19 December 2007 09:17 To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maik Justus Sent: 18 December 2007 23:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots) Hi Viviam, Vivian Meazza schrieb am 18.12.2007 23:41: I've just a few moments ago added a few lines of code to AIBallistic which apply an external force (using the same math as above). The rest works as before. I just need few properties to set the magnitude and vector of the external force and it will be done, at least for testing. Thank you, very good. Is it possible to pass the forces in the earth fixed coordinates axes base? (in Newton or pof)? I'm planning, and have tested the passing of the force in terms of magnitude (pound force), azimuth (degrees, north = 0) and elevation (degrees, horizontal = 0, up = 90). I hope this is what you need, and can work with. It's trivial really, but I'm assuming that the external force applies no rotational force to the object. I think this could be easily faked. e.g. new_roll = old_roll + cos(old_roll) * force_in_y_direction * a_magic_constant * dt but i f I read the code correctly, yaw and hdg are pointing at the speed direction (slightly filtered)? Therefore we need something like _elevation = atan2(force_in_z_direction,force_in_x_direction) and then your filter to add some inertia? Right now there are 2 options - 1, the ballistic object aligns with the velocity vector (damped), or 2, it remains static. These options both work with the new code. I think option 1 will do for an under slung load? I haven't a great deal of time available in the run up to Christmas so no promises on completion. Same here. I will have very limited access to my computer (family visiting tour). Fortunately my computer is a notebook, but I am not sure if there is any space in the car for my joystick. We have a horde of family visitors over the coming days - all competing for my time and the computer. We'll see how much can be done (not a lot I expect). Similar here (but with the difference, that we are part of the horde of family visitors ;-) ) Christmas has arrived slightly early! I've got something which: A. runs B. looks OK with limited testing The ballistic object aligns with the direction of flight in pitch and heading with an external force applied. It would be possible to align it with the direction of the external force, but I think that would need roll as well. I'm not sure which one would look best. The external force is defined in terms of: Magnitude (lbf) Azimuth (deg, North = O) Elevation (deg, up = 90) In a user-defined property. Of course, some external program needs to set the external force data. This all now needs testing in a more realistic environment. I'm not totally convinced that the ballistic object won't disappear into space/to the centre of the earth, or oscillate like a deranged spring. Vivian I will try to combine this with YASims winch feature (but I think I will not find time earlier than end of the month). Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] v1.0 Gallery Page
Hi, Curtis Olson schrieb am 19.12.2007 01:19: On Dec 18, 2007 5:21 PM, Maik Justus wrote: Heikos page is now working for me with also some other screenshots (worth to be in the gallerie, too): http://www.hoerbird.net/index.htm Hi, right now I still cannot connect ... would someone who can connect be willing to pull the images and send them to me? Done Thanks, Curt. Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] v1.0 Gallery Page
Hi Gerard, gerard robin schrieb am 19.12.2007 14:44: Here Osprey with rotors all folded up, on elevator http://pagesperso-orange.fr/GRTux/Osprey_on_carrier.jpg I only got huge difficulties because, when the elevator get down ( mid position) the blades suddenly fall down ??? The problem is: The fdm itself does not support folding of the blades. For the fdm the rotor is unfolded and vertical. When the elevator gets down, the fdm detects a crash (rotor vs. ship). Regards Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] v1.0 Gallery Page
Hi Gerard, gerard robin schrieb am 19.12.2007 15:51: On mer 19 décembre 2007, Maik Justus wrote: Hi Gerard, gerard robin schrieb am 19.12.2007 14:44: Here Osprey with rotors all folded up, on elevator http://pagesperso-orange.fr/GRTux/Osprey_on_carrier.jpg I only got huge difficulties because, when the elevator get down ( mid position) the blades suddenly fall down ??? The problem is: The fdm itself does not support folding of the blades. For the fdm the rotor is unfolded and vertical. When the elevator gets down, the fdm detects a crash (rotor vs. ship). Regards Maik Oh, yes i forgot that feature (sorry, i am more aware with JSBsim, where i can give any specific contact point, though no perfect). Thanks But it can be fixed quite easily: The fdm allows to tilt the whole rotor. I just need to add tilting of the rotor in a vertical position along the fuselage. Then the contact points are within and above the fuselage. As I added the blade/ wing fold I was not thinking about the elevators. I thought, the remaining contact points would never hurt. Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots)
Hi, Vivian Meazza schrieb am 18.12.2007 00:27: Maik wrote Hi, Melchior FRANZ schrieb am 17.12.2007 02:18: * Georg Vollnhals -- Monday 17 December 2007: Just now (!!!) remembering Torsten's Dragonfly banner-trick (!!!) which is pretty similar: Yes, it's clearly a job for Maik's winch/anchor feature. He has already lifted me via MP: I was in a sgs233, and Maik lifted me with a bo105. There's just no visible rope (yet). Can an external force be added to the AIBallistic Objects? I don't see why not. Just designing on the back of an envelope - we already have one - wind. So in principle we add something like another wind. Not in the next few days though. Vivian I had a look to AIBase.?xx and AIBallisitic.?xx. I think all we need is already there. The objects speed can be modified by a Nasal script. YASims winch/aerotow/anchor can be connected directly to any AI object and (with some Nasal code, which copies the location) to anything else. The force on the other object is calculated and stored in the property tree. Some Nasal code only need to take this force, multiply it by dt and divide it by the objects mass and add the result to the objects speed (which need to be converted to (and afterwards back from) the earth-coordinate system). If we use a AIBallistic object, the gravity and drag effects would be calculated automatically. Therefore external cargo missions, SAR missions or even banner-towing with realistic forces on the aircraft should be possible with fg1.0.0 Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pushback
Hi Gijs, Gijs de Rooy schrieb am 18.12.2007 22:09: Hi folks, I did a lot of work last week on a pushback truck model. The model is done, the steering is working (could be better) but we still need the possibility to push/pull planes. Please see the forum page for some more info and screens and a download link: http://www.flightgear.org/forums/viewtopic.php?t=734 I think this option is possible with the aerotow function. I can't do it myself, so I would ask if there's somebody who'd like to help me with this. Please contact me. Yes, in principle it is possible with the aerotow feature. The only problem is, that due to the time lag of the MP protocol, some elasticity of the tow is needed. With a 60m tow this is possible without looking unrealistic, but we should try to to that with the existing code. 1.) Copy the aerotow part of the fdms .xml file and of the -set.xml file of an glider (bocian or ask21) to the airliner, the position should be the nose wheel. 2.) Copy the aerotow part of the dhc2w (.xml and -set.xml) to the truck. The position should be the end of the push-bar. 3.) Change the parameters of the tow length (length, min-tow-length and initial-tow-length: much shorter, maybe 5m) and increase the break-force. Maybe you need to modify the elasticity (elastic-constant). (these parameters need only to be changed at the airliner; the tow truck will copy these values automatically) If I remember correctly, the airliner will use the center of the tow truck for calculating the distance (and the forces). With 60m tow you would not see a difference, but for the push-truck this could be visible. On the other hand, we maybe need this distance between the truck center and the end of the the push bar for the elasticity. Just try it as it is and if it works, but the distance between truck and the airliners front gear can not be adjusted by modifying the elasticity and tow length, then you need to shift the truck center a bit. Some of the things I think we need: * The pilot of the aircraft has to accept the pushback to push the plane. The same as we have in aerotow. The glider pilot connects ... * The pilot should be allowed to disconnect at any time. and disconnects (the dhc2w pilot can only disconnect). * There should be an chat interface between the pilot and the pushback truck driver. That last one is already possible with the new version. Cheers, Gijs Regards, Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots)
Hi Viviam, Vivian Meazza schrieb am 18.12.2007 23:41: I've just a few moments ago added a few lines of code to AIBallistic which apply an external force (using the same math as above). The rest works as before. I just need few properties to set the magnitude and vector of the external force and it will be done, at least for testing. Thank you, very good. Is it possible to pass the forces in the earth fixed coordinates axes base? (in Newton or pof)? It's trivial really, but I'm assuming that the external force applies no rotational force to the object. I think this could be easily faked. e.g. new_roll = old_roll + cos(old_roll) * force_in_y_direction * a_magic_constant * dt but i f I read the code correctly, yaw and hdg are pointing at the speed direction (slightly filtered)? Therefore we need something like _elevation = atan2(force_in_z_direction,force_in_x_direction) and then your filter to add some inertia? I haven't a great deal of time available in the run up to Christmas so no promises on completion. Same here. I will have very limited access to my computer (family visiting tour). Fortunately my computer is a notebook, but I am not sure if there is any space in the car for my joystick. Vivian Best regards, Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] v1.0 Gallery Page
Hi James, James A. Treacy schrieb am 19.12.2007 00:02: On Tue, Dec 18, 2007 at 04:15:24PM -0600, Curtis Olson wrote: Here is a prototype for the v1.0 Gallery: http://baron.flightgear.org/~curt/tmp/v1.0/ I've taken the best of the pictures that were submitted on the mailing list and organized and arranged them. Very nice! I am curious about the second image (camel-ksfo). Are the front wheels sunk partway into the runway? I think two things causes that. 1) reduced pressure in the air-wheels (simulated by placing the wheels in the 3D-Model a few cm below the position in the FDM) 2) the bumpiness of the surfaces which only the YASim-aircrafts can see/feel, but which is not visible in the OpenGL rendering Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] v1.0 Gallery Page
Hi AJ MacLeod schrieb am 18.12.2007 23:33: On Tuesday 18 December 2007 22:15:24 Curtis Olson wrote: 4. Do we have a nice outside view of a glider or two? Heiko's ASK looks very nice though, and he has some very good screenshots of it too - hopefully he will reappear with them soon... Heikos page is now working for me with also some other screenshots (worth to be in the gallerie, too): http://www.hoerbird.net/index.htm Cheers, AJ Regards, Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots (and snapshots)
Hi, Melchior FRANZ schrieb am 17.12.2007 02:18: * Georg Vollnhals -- Monday 17 December 2007: Just now (!!!) remembering Torsten's Dragonfly banner-trick (!!!) which is pretty similar: Yes, it's clearly a job for Maik's winch/anchor feature. He has already lifted me via MP: I was in a sgs233, and Maik lifted me with a bo105. There's just no visible rope (yet). Can an external force be added to the AIBallistic Objects? Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots (and movies)
Hi Heiko, Heiko Schulz schrieb am 17.12.2007 16:46: Hi, for all, who are interested: I also did a video starring the EC 135 ÖAMTC in her natural environment! you can find it here: http://www.youtube.com/watch?v=XkeApfVUnVk or here: www.hoerbird.net/index.htm Have fun HHS very good video and screenshots! Regards, Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft downloads page update
Hi Curt, could you please delete the as350 and the bell206 from the download page? Both have no 3D-model and a very poor FDM. The hornet and the fk9mk2 are done by Emmanuel Baranger (3D) and me (FDM). Melchior: Whats about changing the bo105 status from beta to production? Best regards, Maik Curtis Olson schrieb am 17.12.2007 21:25: Hi, I have updated the aircraft downloads page with all the lastest versions of the available (CVS) aircraft. Many of the new ones do not have a thumbnail image for the web page, and a few of them have been copied from other aircraft and are incorrect. It would be great if people could grab a quick preview image and submit/commit it for the aircraft that don't yet have one. http://www.flightgear.org/Downloads/aircraft/ Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
Hi Melchior, Melchior FRANZ schrieb am 10.12.2007 19:32: Note that loops/listeners that were started in nasalload have to be stopped/removed in nasalunload! Otherwise they will keep running (which is a feature), and you might accumulate them over time. The bo105 does that correctly, the v22 does not! :-) Thanks for reporting. I sent a patch to Emmanuel. Should be in cvs, soon. Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] The Release: Whats New
Hi, there are two What's New lists in the wiki: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Changes_since_0.9.10 and http://wiki.flightgear.org/flightgear_wiki/index.php?title=FlightGear_pre-release_changelog_summary Which one will be used as the official What's new list? I would prefer the first one (more detailed). Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
