Re: [Flightgear-devel] New aircraft: SF-25

[Maik Justus]

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 
 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\sf25b>yasim 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  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

Re: [Flightgear-devel] Martin is responding slowly ....

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

 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

[Maik Justus]

 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

Re: [Flightgear-devel] CPRC Autonomous UAV Helicopter

[Maik Justus]

Hello Thomas,
Thomas Hamilton schrieb am 15.05.2010 23:07:
> >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.
> We are going to wait a few days to see if the manufacturer will 
> provide us with a model.  After that we will start the process of 
> measuring dimensions and writing a model right.  What format is most 
> convenient for you?
I just need a 3D-model working in flightgear. I will create the xml file 
describing the fdm.
> If it is at all possible, we would like to learn how you are able 
> to get the values of the parameters.
In principle its very easy. Most of the parameters can be measured 
directly or are defined by the airfoil. For the remaining parameters I 
will guess some values and adjust them to get the heli reacting as I 
expect it to react. ;-)

By the way: I have an adapter for the rc-helicopter simulator called 
reflex. Has anyone a driver for using this adapter with Flightgear on 
Win-XP?
> Thanks.
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

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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] DIY drones "virtual" UAV competition

[Maik Justus]

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® 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] Quadrocopter (Quadcopter) / Mikrokopter / X-UFO / Microdrone

[Maik Justus]

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® 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

[Maik Justus]

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  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/ 
> 
> 
>
> --
> 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
> 
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>   


--
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
___
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

[Maik Justus]

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 
> 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 Schulz
> Subject: Re: [Flightgear-devel] FG - Helicopter FAA - AATD
> To: FlightGear developers discussions
>  
> 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® 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® 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

[Maik Justus]

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 // schrieb am *Mi, 31.3.2010:
>
>
> Von: James Sleeman 
> Betreff: Re: [Flightgear-devel] FG - Helicopter FAA - AATD
> An: "FlightGear developers discussions"
> 
> 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
> 
> 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® 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® 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

[Maik Justus]

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® 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

[Maik Justus]

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® 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

[Maik Justus]

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® 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

[Maik Justus]

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® 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

[Maik Justus]

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® 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

[Maik Justus]

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 
>
>  
>
>  
>
> 
>
> --
> 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
> 
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>   


--
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
___
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

[Maik Justus]

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® 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® 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)

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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:

[Maik Justus]

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

[Maik Justus]

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=4&t=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 ;-)

[Maik Justus]

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 ;-)

[Maik Justus]

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  element, not the  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  element 
> will give more accurate results than a combination of  and 
>  elements because the  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 ;-)

[Maik Justus]

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] New member...and questions ;-)

[Maik Justus]

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] working ridge lift !!

[Maik Justus]

Hi Mathias,

I have many of  these
> CullVisitor::apply(Geode&) detected NaN,
> depth=1.#QNAN, center=(7.62939e-006 2.32357 -311.612),
> matrix={
> -1.#IND -1.#IND -1.#IND -1.#IND
> -1.#IND -1.#IND -1.#IND -1.#IND
> -1.#IND -1.#IND -1.#IND -1.#IND
> -1.#IND -1.#IND -1.#IND -1.#IND
> }
messages (started long ago (before ridge lift). I just updated to OSG 
2.8.1 and set
OSG_NOTIFY_LEVEL=ALWAYS
and hoped to see the name of the scenegraph node. But he result was, 
that the messages disappeared totally by setting OSG_NOTIFY_LEVEL=ALWAYS.
By setting OSG_NOTIFY_LEVEL=NEVER the messages appeared again.

I am using the release version of OSG only.

Best regards,
Maik



Mathias Fröhlich schrieb am 25.04.2009 09:27:
> Hi Curt,
>
> On Thursday 23 April 2009 01:06:08 Curtis Olson wrote:
>   
>> I'm seeing a ton of these nan's when I start at KHAF ... it's just one or
>> two or three per frame, but that ends up spewing an awful lot of extra text
>> to my console.
>> 
>
> If you use todays OpenSceneGraph trunk, then, since friday there is an 
> extended error message when the CullVisitor steps on a NaN, then with the 
> environment vairable OSG_NOTIFY_LEVEL=ALWAYS you should get also the names of 
> the scnenegraph nodes that are taken to get to this NaN. So the chances are 
> better to get an idea where this problem originates.
>
> Greetings
>
> Mathaas
>
> --
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>   


--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Sky dive free fall

[Maik Justus]

Hi,

leee schrieb am 30.05.2009 20:20:
> ...
>  For example, the YASim FDM assigns drag to 
> extended gear elements, which are located at specific points on the 
> aircraft and so act at those points.  It might be possible then to 
> hack the YASim FDM about a bit to remove the need to solve for 
> cruise and approach conditions and just use the gear drag bits, 
>   
you do not need to hack YASim for that. Just do not define a wing and 
define the yasimliftfactor and the yasimdragfactor within a rotorgear 
tag (you do not need to define a rotor for doing that). The solver will 
not be executed in that case.

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] OpenAL in SimGear

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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

Re: [Flightgear-devel] crash in FlightGear\src\Airports\dynamics.cxx, patch included

[Maik Justus]

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

[Flightgear-devel] crash in FlightGear\src\Airports\dynamics.cxx, patch included

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

Hi,

Heiko Schulz schrieb am 23.02.2009 14:22:
>  
>   
>> The bo105 doesn't use Nasal for blade bending.
>> 
>
>
> noticed, so it is indeed a bug in hardcode. Maik has already a patch and is 
> in test on helijah. I wait for the results, because this bug could be also 
> the cause for the sliding.
>   
Meanwhile I have a running flightgear here (with osg 2.8 it works fine).
I can confirm helijahs observation, that the bug reportet by helijah is 
fixed with the patch, but the effect on sliding is smaller than I hoped. 
Maybe the sliding of helicopters is comparable to other aircrafts now. 
Fortunately Diogo has a general patch for the sliding issue.

Please commit my patch.

Thanks,

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

[Maik Justus]

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] northern hemisphere vs southern hemisphere

[Maik Justus]

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 hemisphere

[Maik Justus]

Hi Emmanuel,

good finding.

It seems, that I am mixing up different coordinate systems in line 389 
of Rotorpart.cpp


   float relgrav = Math::dot3(_normal,_rotor->getGravDirection());

While _normal is within the coordinate system of the helicopter, 
_rotor->getGravDirection() is in the world coordinate system.


The enclosed patch should fix this. Unfortunately flightgear does not 
run on my machine actually. I would be thankful, if someone could check, 
if the patch works.


Best regards,
Maik

BARANGER Emmanuel schrieb am 21.02.2009 20:28:

Hi all,

After some tests, I just discovered something amusing in FG.

In fact, you do not know can be, but the gravity is reversed between 
the northern hemisphere and southern hemisphere. Finally it is the 
impression that it was ;)


Look the Bo105 in northen hemisphere : http://helijah.free.fr/LFKJ2.png
the same in southern hemisphere : http://helijah.free.fr/FACT2.png

Or the Aircrane (blades longer) in northen hemisphere : 
http://helijah.free.fr/LFKJ.png

and in southern hemisphere : http://helijah.free.fr/FACT.png

Although this will not interfere with many of us. Many of us live in 
the northern hemisphere. But what should we say to those who live in 
the southern hemisphere ?


Funny is not it ?

Best regards. Emmanuel

--
BARANGER Emmanuel

http://helijah.free.fr
http://helijah.free.fr/flightgear/hangar.htm
http://helijah.free.fr/flightgear/H4-Hercules.htm
http://helijah.free.fr/flightgear/flightgear.htm
http://www.jamendo.com/fr/album/27163
  



--
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
  


Index: Rotor.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Rotor.cpp,v
retrieving revision 1.30
diff -u -p -r1.30 Rotor.cpp
--- Rotor.cpp   27 Jul 2008 16:25:15 -  1.30
+++ Rotor.cpp   22 Feb 2009 12:30:29 -
@@ -830,6 +830,7 @@ void Rotor::calcLiftFactor(float* v, flo
 
 //store the gravity direction
 Glue::geodUp(s->pos, _grav_direction);
+s->velGlobalToLocal(_grav_direction, _grav_direction);
 }
 
 void Rotor::findGroundEffectAltitude(Ground * ground_cb,State *s)
--
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")

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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 
() and the distance where the volume is cutted off 
(). 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  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)

[Maik Justus]

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:




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

[Maik Justus]

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] Doppler

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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

[Maik Justus]

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] stall horn sound

[Maik Justus]

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/ 

  

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=100&url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG - FGFX class

[Maik Justus]

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=100&url=/
___
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?

[Maik Justus]

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=100&url=/
> 
>
> ___
> 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=100&url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Sound positioning and orientation

[Maik Justus]

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=100&url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Input/Output

[Maik Justus]

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] Input/Output (It was: I need a help)

[Maik Justus]

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] I need a help

[Maik Justus]

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"
> 
> 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 
> 
>  
> 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] [Flightgear-cvslogs] CVS: source/src/FDM/JSBSim/models/flight_control FGActuator.cpp, 1.2, 1.3 FGFCSComponent.h, 1.3, 1.4

[Maik Justus]

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

[Maik Justus]

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  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

[Maik Justus]

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

[Maik Justus]

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
>> 
>>
>> Curt.
>> -- 
>> Curtis Olson: http://baron.flightgear.org/~curt/
>> 
>> 
>>
>>   
>> 
> 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

[Maik Justus]

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] Red Bull Air Race for FlightGear

[Maik Justus]

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] Depth percepted cockpit

[Maik Justus]

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] trees

[Maik Justus]

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  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] trees

[Maik Justus]

Hi Stuart,

Stuart Buchanan schrieb am 26.01.2008 22:18:
> --- Stuart Buchanan  wrote:
>   
>> --- Stuart Buchanan wrote:
>> 
>>> Hi All,
>>>
>>> Just a quick note to mention that I've now implemented random tree height,
>>>   
>> and
>> 
>>> multiple textures as suggested by Curt. Screenshot here:
>>>
>>> http://www.nanjika.co.uk/flightgear/forest2.jpg
>>>
>>> Still some work to be done, but it is looking more realistic.
>>>
>>> Tim - I've been cleaning up my code a bit, so unless you've already started,
>>> I'd
>>> hold off trying to kick my previous patch into shape for CVS. I should have 
>>> a
>>> new
>>> patch fairly soon.
>>>   
>> A patch for this is now available from
>> http:/www.nanjika.co.uk/flightgear/trees.tar.gz.
>>
>> Note that there are some additional new files for the tree textures and some
>> re-organizing of the code - see the included README.
>> 
>
> Doh! I didn't notice that I had changed the FlightGear source too...
>
> The patch below adds the appropriate property value check, and I've updated 
> the
> tarball and README to include it.
>
>   
Yes, that did it. There is a problem with the draw ordering leading to a 
transparency bug. It seems, that the trees are done by only two 
triangles, intersecting each other. Due to the intersecting none of the 
two possible orderings are correct. At least one of the two triangles 
need to be separated into two triangle (along th intersection line).
> At some point I'll need to add a setting to the preferences.xml file too, but
> first we need to decide whether the trees should be on by default (like the
> random objects) or not.
>
>   
If it don't affect slower PCs with older graphics hardware I will 
suggest "on" as default. But if it causes frame rate drop on older 
hardware while nothing is displayed, off should be the default.
Maik
> Any opinions?
>
> -Stuart
>
> Index: Scenery/tileentry.cxx
> ===
> RCS file: /var/cvs/FlightGear-0.9/source/src/Scenery/tileentry.cxx,v
> retrieving revision 1.64
> diff -u -r1.64 tileentry.cxx
> --- Scenery/tileentry.cxx 20 Dec 2007 23:20:52 -  1.64
> +++ Scenery/tileentry.cxx 26 Jan 2008 16:18:54 -
> @@ -266,6 +266,9 @@
>  {
>  bool use_random_objects =
>  fgGetBool("/sim/rendering/random-objects", true);
> +
> +bool use_random_vegetation = 
> +fgGetBool("/sim/rendering/random-vegetation", true);
>  
>  // try loading binary format
>  osg::ref_ptr options
> @@ -273,6 +276,7 @@
>  options->setMatlib(globals->get_matlib());
>  options->setCalcLights(is_base);
>  options->setUseRandomObjects(use_random_objects);
> +options->setUseRandomVegetation(use_random_vegetation);
>  osg::Node* node = osgDB::readNodeFile(path, options.get());
>  if (node)
>geometry->addChild(node);
>
>
>
>   ___
> Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
> now.
> http://uk.answers.yahoo.com/ 
>
> -
> 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
>
>   


-
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

[Maik Justus]

Hi Fred, Hi Stuart,

Frederic Bouvier schrieb am 26.01.2008 19:22:
> Stuart,
>
> Stuart Buchanan a écrit :
>   
>> --- Stuart Buchanan wrote:
>>   
>> 
>>> Hi All,
>>>
>>> Just a quick note to mention that I've now implemented random tree height, 
>>> and
>>> multiple textures as suggested by Curt. Screenshot here:
>>>
>>> http://www.nanjika.co.uk/flightgear/forest2.jpg
>>>
>>> Still some work to be done, but it is looking more realistic.
>>>
>>> Tim - I've been cleaning up my code a bit, so unless you've already started,
>>> I'd
>>> hold off trying to kick my previous patch into shape for CVS. I should have 
>>> a
>>> new
>>> patch fairly soon.
>>> 
>>>   
>> A patch for this is now available from
>> http:/www.nanjika.co.uk/flightgear/trees.tar.gz.
>>
>> Note that there are some additional new files for the tree textures and some
>> re-organizing of the code - see the included README.
>>   
>> 
>
> I applied your new patch and I don't have trees, although they were
> working with the last one. 
same here (but your new screenshot looks great).

Maik
> It seems to me that there is a missing bit
> for flightgear because the setUseRandomVegetation function is never
> called and stay to false. Maybe there is a patch to options.cxx sitting
> on your disc.
>
> -Fred
>
>   


-
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] Shader based random trees and improved random objects

[Maik Justus]

Hi Stuart,

Stuart Buchanan schrieb am 22.01.2008 23:04:
> Hi All,
>
> I've been working on a shader-based approach to creating random trees with 
> help
> from Tim Moore.
>
> Here's a screenshot of what I've managed to achieve so far:
>
> http://www.nanjika.co.uk/flightgear/forest.jpg
>
> A patch which includes both the shader trees and improvements to the random
> object placement is available from 
>
> http://www.nanjika.co.uk/flightgear/trees.tar.gz
>
>   
very nice. Low-level-flying is much more interesting now.
> This isn't yet ready for inclusion in CVS, but worth having a play about with.
>
>   
Why not? cvs is the place for developing.
> Notes:
> - Currently all the trees of a given type on a tile will be the same size, 
> shape
> and texture.
> - It's highly likely that this code leaks memory like a sieve.
> - The shader currently doesn't perform any diffuse lighting calculations. For
> some reason including the diffuse lighting causes a "flickering" effect, 
> possibly
> due to the light source being so far away.
>
> Comments are of course welcome.
>   
What comes next? Shader driven swarms of birds, flocks, clouds? ;-)
> -Stuart
>
>
>   
Thank you!
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

[Maik Justus]

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-nl&tab=m1192527562294&vid=8aff5b76-b78d-4b55-8b64-ef7e1d73aab2&playlist=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-28d20a4037ab&from=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 
> 
>
> -
> 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/lis

Re: [Flightgear-devel] view options

[Maik Justus]

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

[Maik Justus]

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] External Cargo, was: Re: screenshots (and "snapshots")

[Maik Justus]

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

Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and "snapshots")

[Maik Justus]

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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AI load_demo.xml, NONE, 1.1]

[Maik Justus]

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] view options

[Maik Justus]

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] view options

[Maik Justus]

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

[Maik Justus]

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] view options

[Maik Justus]

Hi,
it takes into account the aspect ratio of the window. If it is 4:3 
everything is unchanged. If it is larger (e.g. 1024:704) you will get a 
higher field of view. Maybe you can try the patch (or set fov to 
55/(4/3)*(1024/704) = 60 in the property tree: 
/sim/current-view/field-of-view) and check, if it is noticeable, and if 
yes: if it is better or worse than the 55. (replace 1024 and 704=768-64 
with your resolution)

Maik
 
AnMaster schrieb am 04.01.2008 21:46:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> How does this work with windowed mode (that I always use, as maximized 
> window, still showing the 64
> pixels high KDE taskbar at the bottom, and window edges). My monitor is 4:3, 
> but the window isn't.
>
> Regards,
>
> Arvid Norlander
>
> 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).
>>
>> Maik
>> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.7 (GNU/Linux)
>
> iD8DBQFHfpstWmK6ng/aMNkRCjUYAJ9I/h1lTEzVwsVkBfMc1YXJbDfW+wCZAbiE
> ff1ucoiecbrPDlqzMLErIng=
> =5D9E
> -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

[Maik Justus]

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

[Flightgear-devel] fg (plib branch) crashes, probably in groundnetwork.cxx

[Maik Justus]

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] Multiplayer Funfly.

[Maik Justus]

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/ 
> 
> 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.

[Maik Justus]

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/ 
> 
>
> Thanks to everyone who participated and spectated.
>
> Happy 2008!
>
> Curt.
> -- 
> Curtis Olson: http://baron.flightgear.org/~curt/ 
> 
> 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

[Maik Justus]

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

[Maik Justus]

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] view options

[Maik Justus]

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) )

Syd&Sandy 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

[Maik Justus]

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-Pt0&feature=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] RE water crashes or landing - a change in design principle and default is suggested

[Maik Justus]

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

[Maik Justus]

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")

[Maik Justus]

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] Pushback

[Maik Justus]

Hi Gijs,

which airliner (with YASim FDM) you want to modify? I will try to modify 
the files. (I am on a X-mas tour, therefore I will probably have  no 
time before end of the month.)

Maik



Gijs de Rooy schrieb am 21.12.2007 12:55:
>
> > Date: Tue, 18 Dec 2007 23:40:15 +0100
> > From: [EMAIL PROTECTED]
> > To: flightgear-devel@lists.sourceforge.net
> > Subject: 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.
> > >
>
> 
>
> I've tried it, but it didn't worked. I think i've done something wrong.
>
> Could you please copy the needed lines and paste them in a email?
>
>  
>
> Thanks,
>
> Gijs
>
>
> 
> Blijf onderweg online met Windows Live for Mobile! Download 't nu op 
> jouw mobiele telefoon. 
> 
>
> -
> 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] v1.0 Gallery Page

[Maik Justus]

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

Re: [Flightgear-devel] v1.0 Gallery Page

[Maik Justus]

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

[Maik Justus]

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