Re: [Flightgear-devel] auto-coordination

[Eric van den Berg]

Hi Curt

Well actually there are quite some RL aircraft having a so-called 
rudder-aileron interconnect. Of course in these aircraft it acts both 
ways: A spring (so not hard linked 1:1) pulls the rudder at aileron 
deflection and vice versa. The reason is however a very different one 
namely a lack of "tendency to raise the lower wing" which is a FAR 
requirement. This "tendency" is directly related to having a low enough 
Cl_beta (moment around the aircraft x-axis due to sideslip). More 
Dihedral or more sweep angle on the wing will improve the 
characteristic. But these things also have a decremental effect on 
performance, so sometimes it is better to have a bit more complex 
control system.


The point being that in these aircraft the autopilot will have to deal 
with this spring also. But as it is a spring and no hard linkage, having 
strong enough autopilot servos will do the trick.


For simulation purposes I would agree that the auto-coordination should 
be switched of with AP engaged. There are some complications though. 
What if only a HDG or NAV mode (roll servo only) is engaged? Or there is 
no servo on the rudder at all (which is quite common)? And from the 
other side what if only the yaw damper or yaw trim is active (common on 
multi engine aircraft)? In those cases auto coordination should remain 
active!


So auto coordination should be switched off only when both a roll mode 
and yaw mode are engaged. Also it might be a good idea (for realism) to 
have the auto-coordination work both ways just as in RL.


Cheers

Eric

On 03/09/2012 09:05 PM, Curtis Olson wrote:
The counter argument here is that the existing "auto coordination" 
system is nothing more than one line of code that forces some rudder 
deflection in proportion to aileron deflection -- 
basically implementing some sort of hard linked manual system.  I am 
sure there are very few (if any?) real life aircraft rigged in such a way.


Curt.


On Fri, Mar 9, 2012 at 1:57 PM, Renk Thorsten wrote:

> Ok I haven't entirely given up on the idea of removing the
> auto-coordination from the code.

Why?

> Wouldn't it be more appropriate to add
> that rudder control to controls.nas?

Nasal runs per graphical frame, FDMs may need to run faster at low
framerates. Nasal AP systems tend to become unstable below 15 fps
or so (see the F-14b).

> Then it can be replaced if need be on a per aircraft basis , but not
> break anything otherwise.

You can replace it now on a per aircraft basis at the simple
expense of setting a single property to false. If the aircraft is
equipped with a better system, then that system can do so. Why is
that a problem?

> And maybe it could be slip/skid-ball driven ... my whole
> point is NOT to disable it but make it configurable.

Yes, them make it configurable on any aircraft you like. But it
should not be absent from any aircraft you haven't touched.

Cheers,

* Thorsten

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/flightgear-devel




--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/ 


http://www.flightgear.org - http://gallinazo.flightgear.org


--
Virtualization&  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[George Patterson]

In response to the auto-coordination question, it does need to be
there for users that do not have pedals or a twist stick joystick.

Ideally, the autopilot should either disable auto-coordination and
then restore state afterwards, if enabled by user or fly despite it.

I personally think that stating that only gamers use auto-coordination
is counter productive and doesn't resolve the issue.

Regards


George

On 10 March 2012 10:11, Gary Neely  wrote:
> On Fri, Mar 9, 2012 at 5:58 PM, syd adams  wrote:
>>> On the subject of novices, would it be a good idea to have an idiot-startup
>>> button or menu, which makes everything all systems go and ready to take off?
>>>
>>> Alan
>>
>>

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Rembrandt feedback (was: Project Rembrandt - next steps)

[Frederic Bouvier]

Thanks, I prefer that one ;-)

-Fred

- Mail original -
> De: "Olaf Flebbe" 
> À: "FlightGear developers discussions" 
> 
> Envoyé: Vendredi 9 Mars 2012 23:00:47
> Objet: Re: [Flightgear-devel] Rembrandt feedback (was: Project Rembrandt -
> next steps)
> 
> Hi Fred,
> 
> I found the correct extension for unsigned uniforms:
> 
> --- a/src/Main/CameraGroup.cxx
> +++ b/src/Main/CameraGroup.cxx
> @@ -906,6 +906,7 @@ const char *ssao_vert_src = ""
>  
>  const char *ssao_frag_src = ""
>  "#version 120\n"
> +"#extension GL_EXT_gpu_shader4 : enable\n"
>  "#line " TOSTRING(__LINE__) " 2\n"
>  "uniform sampler2D normal_tex;\n"
>  "uniform sampler2D depth_tex;\n"
> 
> Greetings,
> Olaf
> 
> 

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] scenery loading cleanup

[Mathias Fröhlich]

Hi Jon,

On Friday, March 09, 2012 10:43:55 Jon Stockill wrote:
> Can you explain exactly how the loading now works, and if it's still
> possible to use extra local objects trees in the way I describe?

Thanks for the response.
Well, I guess this hits the same problem that I try to solve now with the 
previous mail.

Greetings

Mathias

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] scenery loading cleanup

[Mathias Fröhlich]

Hi,

On Thursday, March 08, 2012 23:13:56 Clement de l'Hamaide wrote:
> Without this little tweaks the tile can't be loaded. In conclusion, with
> your change we need to associate Object AND Terrain folder. It's just a
> feedback of my experience, don't take it as a critics ;)
That's fine.

Have written something longer in response to Anders. I think this maches your 
problem as well. So I guess we are on the way ...

Greetings
Mathias

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] scenery loading cleanup

[Mathias Fröhlich]

Hi,

On Friday, March 09, 2012 21:37:32 Anders Gidenstam wrote:
> This change breaks my setup. I consider it a feature that FG used
> to load objects from all scenery directories visited up until the first
> one that contains terrain for the tile. It made it possible to have
> scenery object directories with extra objects by just putting them early
> in the path (useful not least for keeping work-in-progress object
> placements separate from terrasync data). It appears you removed that.
> 
> Can you clarify what the new behaviour is?
> 
> Is the first object .stg found for a tile the only one that is loaded now?

The problem with accumulating all stg files' content is that you get duplicate 
models.
So the situation that I was trying to fix is as follows:
Assume you have the base package installed and assume you have terragears 
scenery installed. Terragear has some improoved models from buildings included 
where the older models already are contained in the from the base package.
What you would observe are models that are technically just needlessly drawn 
twice and if the models are not identical or may be placed at different 
altitudes because of the base tile providing a sightly different ground 
elevation you will at best see some kind of z fighting between the two models 
and at worst two shifted models in each other with occasionaly z fighting.
You can see this with a lot of buildings in San Francisco.

Now you might argue that I should omit the FG_ROOT/Scenery from FG_SCENERY 
since it already contains all that the base package contains. Then I take an 
other example with reversed coverage of the scenery:
I have terragear worldwide and the nice innsbruck scenery. And both include 
some of the hangars at the airport. You will in this case see that described 
z-fighting for the tyrolean writing on the wall of one of the most east airport 
buildings.
For the uglyness in the scene and for the needles model duplication for draw I 
do not think that we want that.

Ok, the lookup for stg files is as of today:

for path in FG_SCENERY
  probe tiles files in path/{Objects,Terrain}///.stg
  if one is there, stop probing.
end

Why do I stop at the first found file/file pair:
I got told that some scenery tiles do contain sea tiles there we only have an 
Objects directory with offshore windmill models for example. If I do not want 
them in the same way duplicated like described above you need to stop at some 
point.
With the windmill example I tend to say, ok, let's just duplicate them. We do 
not have so much models on the sea. So then we could start accumulating all up 
to the point where we find either a base tile or run out of serach path.
But I think a complex oil drilling platform on the northsea breaks this 
argument a little.

Ok, I get an idea:
The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg for 
example) with models never contain a base tile line where we could know when 
to stop seraching the FG_SCENERY directory sequence.
So for this kind of tiles we could probably place someting into the stg file 
that signals that we should stop seaching here and finish with a sea tile.
May be we could place a

OBJECT_BASE .seatile

into the above drilling platform stg tile example to terminate the search.


An other alternative might be to also probe for a Devel directory structure 
for a given scenery path extending the search to

for path in FG_SCENERY
  path/{Devel,Objects,Terrain}///.stg
...


An third alternative could be that we explicitly flag stg files that should not 
terminate the FG_SCENERY search. So you could just put that flag into your 
development stg files.


The first alternative would require modifications to those scenery files, but 
it 
works today as good/bad as it worked yesterday and it works fine if the 
terminating OBJECT_BASE is inserted.
The second one would be a code only change.
The third one would be a change only for those people that develop scenery.


Does this match your concerns? Would it solve? Thoughts?
And sorry for breaking at first ...

Mathias

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Ercoupe (was auto-coordination)

[Ron Jensen]

On Friday 09 March 2012 14:45:45 Adam Dershowitz, Ph.D., P.E. wrote:
> Few, but at least one:
>
> http://en.wikipedia.org/wiki/ERCO_Ercoupe
>
>
> --Adam

As the FDM maintainer for the Flightgear version of this airplane I have 
searched the interwebs for details on its rudder system and came up with 
nothing. Right now its implemented as a simple linear ratio of aileron to 
rudder. Is that how they're really built?

Thanks, 
Ron

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Gary Neely]

On Fri, Mar 9, 2012 at 5:58 PM, syd adams  wrote:
>> On the subject of novices, would it be a good idea to have an idiot-startup
>> button or menu, which makes everything all systems go and ready to take off?
>>
>> Alan
>
>
> Mine already have such a button , in the menu called "autostart'.


I do the same on my models, following Syd's example. I think a number
of others also do so. A location for such an item might be
standardized, but the functionality would vary considerably, since the
properties that must be set may vary widely with each aircraft. I
don't mean to get too far off topic though.

-Gary

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Recent shader stuff vs 2.4

[Gijs de Rooy]

Hi Martin,

> Actually this slider doesn't override anything, instead it's being
> overridden by the defaults.

It does override the custom settings, whenever the slider is touched. But just 
setting 
the property via commandline (or anything other than the dialog) was something 
I 
didn't think of (stupid mistake), so that doesn't overwrite anything, like you 
experienced.

> As far as I can tell, that's still the case in the current state of
> GIT:

Somehow I forgot to fix it before the release. But I got a fix ready to be 
shipped.
The only issue left is that I don't know where to put the required Nasal code. 
It
used to be inside gui/dialogs/rendering.xml, but to check properties on startup
it needs to be executed whenever FlightGear is loaded.

For now I've placed it in Nasal/gui.nas, but maybe it's better to create a 
seperate
effects.nas or shaders.nas? Because it doesn't only matter to the gui, but also 
when
you just want to disable the shaders with a single property...

Advise is welcome!


Cheers,

Gijs  --
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

> On the subject of novices, would it be a good idea to have an idiot-startup
> button or menu, which makes everything all systems go and ready to take off?
>
> Alan


Mine already have such a button , in the menu called "autostart'.

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Alan Teeder]

Not many aircraft are designed to be flown using a keyboard or a mouse either. 
;.)

The TSR2 prototype actually had a knob to allow a variable amount positive or 
negative rudder to be input from the roll taileron command.

This auto-co-ordination may well help novice simulator “gamers” and for this 
reason should be available, but perhaps not set by default.

It will negate the efforts of those who have made accurate FDM and AFCS systems.

On the subject of novices, would it be a good idea to have an idiot-startup 
button or menu, which makes everything all systems go and ready to take off?

Alan

From: Curtis Olson 
Sent: Friday, March 09, 2012 8:05 PM
To: FlightGear developers discussions 
Subject: Re: [Flightgear-devel] auto-coordination

The counter argument here is that the existing "auto coordination" system is 
nothing more than one line of code that forces some rudder deflection in 
proportion to aileron deflection -- basically implementing some sort of hard 
linked manual system.  I am sure there are very few (if any?) real life 
aircraft rigged in such a way.

Curt. 

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Rembrandt feedback (was: Project Rembrandt - next steps)

[Olaf Flebbe]

Hi Fred,

I found the correct extension for unsigned uniforms:

--- a/src/Main/CameraGroup.cxx
+++ b/src/Main/CameraGroup.cxx
@@ -906,6 +906,7 @@ const char *ssao_vert_src = ""
 
 const char *ssao_frag_src = ""
 "#version 120\n"
+"#extension GL_EXT_gpu_shader4 : enable\n"
 "#line " TOSTRING(__LINE__) " 2\n"
 "uniform sampler2D normal_tex;\n"
 "uniform sampler2D depth_tex;\n"

Greetings,
Olaf


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Adam Dershowitz, Ph.D., P.E.]

Few, but at least one:

http://en.wikipedia.org/wiki/ERCO_Ercoupe


--Adam



On Mar 9, 2012, at 12:05 PM, Curtis Olson wrote:

> The counter argument here is that the existing "auto coordination" system is 
> nothing more than one line of code that forces some rudder deflection in 
> proportion to aileron deflection -- basically implementing some sort of hard 
> linked manual system.  I am sure there are very few (if any?) real life 
> aircraft rigged in such a way.
> 
> Curt.
> 
> 
> On Fri, Mar 9, 2012 at 1:57 PM, Renk Thorsten wrote:
> > Ok I haven't entirely given up on the idea of removing the
> > auto-coordination from the code.
> 
> Why?
> 
> > Wouldn't it be more appropriate to add
> > that rudder control to controls.nas?
> 
> Nasal runs per graphical frame, FDMs may need to run faster at low 
> framerates. Nasal AP systems tend to become unstable below 15 fps or so (see 
> the F-14b).
> 
> > Then it can be replaced if need be on a per aircraft basis , but not
> > break anything otherwise.
> 
> You can replace it now on a per aircraft basis at the simple expense of 
> setting a single property to false. If the aircraft is equipped with a better 
> system, then that system can do so. Why is that a problem?
> 
> > And maybe it could be slip/skid-ball driven ... my whole
> > point is NOT to disable it but make it configurable.
> 
> Yes, them make it configurable on any aircraft you like. But it should not be 
> absent from any aircraft you haven't touched.
> 
> Cheers,
> 
> * Thorsten
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> 
> 
> 
> -- 
> Curtis Olson:
> http://www.atiak.com - http://aem.umn.edu/~uav/
> http://www.flightgear.org - http://gallinazo.flightgear.org
> 
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

ah overlooked that , thanks

On Fri, Mar 9, 2012 at 2:07 PM, ThorstenB  wrote:
> Am 09.03.2012 21:46, schrieb syd adams:
>> Hmmm another thought . Wouldn't setting that value to 0.0 still force
>> the rudder to center , still overriding other systems ?
>
> No, since Torsten's suggested patch contained a condition
>
>     && auto_coordination_factor->getDoubleValue() > 0.0 ) {
>
> so nothing changes at values <= 0 ;-).
>
> cheers,
> Thorsten
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[ThorstenB]

Am 09.03.2012 21:46, schrieb syd adams:
> Hmmm another thought . Wouldn't setting that value to 0.0 still force
> the rudder to center , still overriding other systems ?

No, since Torsten's suggested patch contained a condition

 && auto_coordination_factor->getDoubleValue() > 0.0 ) {

so nothing changes at values <= 0 ;-).

cheers,
Thorsten

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

Hmmm another thought . Wouldn't setting that value to 0.0 still force
the rudder to center , still overriding other systems ?

On Fri, Mar 9, 2012 at 1:39 PM, Anders Gidenstam
 wrote:
> On Fri, 9 Mar 2012, Torsten Dreyer wrote:
>
>> Currently the rudder is set to 0.5 * aileron if autocoordination is
>> enabled. The value of 0.5 is hardcoded.
>
> Perhaps this could be implemented with a property rule in preferences.xml
> instead of in C++ code - couldn't such a rule easily be replaced by an
> aircraft specific rule if needed?
>
> Cheers,
>
> Anders
> --
> ---
> Anders Gidenstam
> WWW: http://gitorious.org/anders-hangar
>      http://www.gidenstam.org/FlightGear/
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

On Fri, Mar 9, 2012 at 1:19 PM, Gijs de Rooy  wrote:
>> Curt wrote:
>> I am sure there are very few (if any?) real life aircraft rigged in such a
>> way.
>
> There are also very vew (if any?) real life aircraft flown by mouse :-)

or flown looking through a monitor , using a keyboard :P

>
> Altough I tend to control rudder seperately (also when flying with a
> mouse!), I do
> agree that auto-coordination should remain available.
>
> Just in case people are unaware of the actual property that was mentioned
> before:
> /sim/auto-coordination it is
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

Now that sounds like an even better idea.Less chance of breaking
anything , but still adjustable.Thanks Torsten.

On Fri, Mar 9, 2012 at 1:32 PM, Torsten Dreyer  wrote:
> Am 09.03.2012 20:44, schrieb syd adams:
>> Ok I haven't entirely given up on the idea of removing the
>> auto-coordination from the code.Wouldn't it be more appropriate to add
>> that rudder control to controls.nas?
>> Then it can be replaced if need be on a per aircraft basis , but not
>> break anything
>> otherwise.And maybe it could be slip/skid-ball driven ... my whole
>> point is NOT to disable it but make it configurable.
>
> Currently the rudder is set to 0.5 * aileron if autocoordination is
> enabled. The value of 0.5 is hardcoded.
> An easy and portable way to implement your request might be to introduce
> a new property (e.g. /sim/auto-coordination-factor) with the default
> value of 0.5. and change the code
>  if ( auto_coordination->getBoolValue() ) {
>         set_rudder( aileron / 2.0 );
>  }
>
> to
>
>  if ( auto_coordination->getBoolValue()
>    && auto_coordination_factor->getDoubleValue() > 0.0 ) {
>    set_rudder( aileron * auto_coordination_factor->getDoubleValue() );
>  }
>
> so that setting /sim/auto-coordination-factor to a value of zero or less
> disables the hardcoded auto-coordination but leaves the command-line
> argument and the enable-property usable.
>
> Torsten
>
>
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Anders Gidenstam]

On Fri, 9 Mar 2012, Torsten Dreyer wrote:

> Currently the rudder is set to 0.5 * aileron if autocoordination is
> enabled. The value of 0.5 is hardcoded.

Perhaps this could be implemented with a property rule in preferences.xml 
instead of in C++ code - couldn't such a rule easily be replaced by an 
aircraft specific rule if needed?

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://gitorious.org/anders-hangar
  http://www.gidenstam.org/FlightGear/

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] scenery loading cleanup

[Anders Gidenstam]

On Thu, 8 Mar 2012, Mathias Fröhlich wrote:



Hi,

Also for the breginning of the development cycle, I started working on
improoving fgviewer and cleanup scenery/model loading.

I have now checked in a change that should fix some long standing 
problems with modelss that appear to have z-fighting. This change should 
not harm and works so far for all I have tested. But it slightly changes 
the way stg files paths are handled.

So if this really introduces a problem, please tell me.


Hi,

This change breaks my setup. I consider it a feature that FG used 
to load objects from all scenery directories visited up until the first 
one that contains terrain for the tile. It made it possible to have 
scenery object directories with extra objects by just putting them early 
in the path (useful not least for keeping work-in-progress object 
placements separate from terrasync data). It appears you removed that.


Can you clarify what the new behaviour is?

Is the first object .stg found for a tile the only one that is loaded now?


Cheers,

Anders
--
---
Anders Gidenstam
WWW: http://gitorious.org/anders-hangar
 http://www.gidenstam.org/FlightGear/--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Torsten Dreyer]

Am 09.03.2012 20:44, schrieb syd adams:
> Ok I haven't entirely given up on the idea of removing the
> auto-coordination from the code.Wouldn't it be more appropriate to add
> that rudder control to controls.nas?
> Then it can be replaced if need be on a per aircraft basis , but not
> break anything
> otherwise.And maybe it could be slip/skid-ball driven ... my whole
> point is NOT to disable it but make it configurable.

Currently the rudder is set to 0.5 * aileron if autocoordination is 
enabled. The value of 0.5 is hardcoded.
An easy and portable way to implement your request might be to introduce 
a new property (e.g. /sim/auto-coordination-factor) with the default 
value of 0.5. and change the code
  if ( auto_coordination->getBoolValue() ) {
 set_rudder( aileron / 2.0 );
  }

to

  if ( auto_coordination->getBoolValue()
&& auto_coordination_factor->getDoubleValue() > 0.0 ) {
set_rudder( aileron * auto_coordination_factor->getDoubleValue() );
  }

so that setting /sim/auto-coordination-factor to a value of zero or less 
disables the hardcoded auto-coordination but leaves the command-line 
argument and the enable-property usable.

Torsten



--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

On Fri, Mar 9, 2012 at 12:57 PM, Renk Thorsten  wrote:
>> Ok I haven't entirely given up on the idea of removing the
>> auto-coordination from the code.
>
> Why?
>
because its hard-coded...

>> Wouldn't it be more appropriate to add
>> that rudder control to controls.nas?
>
> Nasal runs per graphical frame, FDMs may need to run faster at low 
> framerates. Nasal AP systems tend to become unstable below 15 fps or so (see 
> the F-14b).
>
that i know all too well ... I have been here awhile ;)

>> Then it can be replaced if need be on a per aircraft basis , but not
>> break anything otherwise.
>
> You can replace it now on a per aircraft basis at the simple expense of 
> setting a single property to false. If the aircraft is equipped with a better 
> system, then that system can do so. Why is that a problem?
>
no you cant, it's either on or off and overrides rudder control of
other systems...


>> And maybe it could be slip/skid-ball driven ... my whole
>> point is NOT to disable it but make it configurable.
>
> Yes, them make it configurable on any aircraft you like. But it should not be 
> absent from any aircraft you haven't touched.
>
That's why i suggested adding it to controls.nas, so it wouldn't be
absent from any aircraft ... I thought that was fairly clear.It would
if it were an autopilot only function...

> Cheers,
>
> * Thorsten
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Gijs de Rooy]

> Curt wrote:
> I am sure there are very few (if any?) real life aircraft rigged in such a 
> way.

There are also very vew (if any?) real life aircraft flown by mouse :-)



Altough I tend to control rudder seperately (also when flying with a mouse!), I 
do
agree that auto-coordination should remain available. 

Just in case people are unaware of the actual property that was mentioned 
before: 
/sim/auto-coordination it is

  --
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Torsten Dreyer]

Am 09.03.2012 20:57, schrieb Renk Thorsten:
>> Ok I haven't entirely given up on the idea of removing the
>> auto-coordination from the code.
>
> Why?
>
>> Wouldn't it be more appropriate to add
>> that rudder control to controls.nas?
>
> Nasal runs per graphical frame, FDMs may need to run faster at low 
> framerates. Nasal AP systems tend to become unstable below 15 fps or so (see 
> the F-14b).
>
>> Then it can be replaced if need be on a per aircraft basis , but not
>> break anything otherwise.
>
> You can replace it now on a per aircraft basis at the simple expense of 
> setting a single property to false. If the aircraft is equipped with a better 
> system, then that system can do so. Why is that a problem?
>
>> And maybe it could be slip/skid-ball driven ... my whole
>> point is NOT to disable it but make it configurable.
>
> Yes, them make it configurable on any aircraft you like. But it should not be 
> absent from any aircraft you haven't touched.
What he probably wants is to set --enable-auto-coordination and _not_ 
use the hardcoded auto-coordination but his own system.

Torsten

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Two small weather issues

[Torsten Dreyer]

Am 08.03.2012 19:43, schrieb ThorstenB:
> On 08.03.2012 19:21, Curtis Olson wrote:
>> I bet there's a line of code somewhere that looks like:
>>
>> if ( visibility_meter>  1000 ) {
>>  do_sky_dome_stuff();
>> }
>
> Ha, Curt, I know you cheated! You just looked at the code, right? ;-)
> simgear/scene/sky/sky.cxx, SGSky::repaint:
>   if ( effective_visibility>  1000.0 ) {
>   enable();
>   dome->repaint();
>   stars->repaint();
>   planets->repaint();
>   oursun->repaint();
>   moon->repaint();

Thanks for the hint, that was easy enough for me ;-)

Thorsten,

the hardcoded value of 1000.0m is now settable at runtime with
/sim/rendering/minimum-sky-visibility
and defaults to 1000m, so the default behaviour is unchanged.

For the precipitation effect, I'm currently working on exposing most of 
the effect's properties to the property tree and implementing the 
current "magic" using property rules with a disable-switch.
That way you get access to particle speed, -size, -color and many more.

I somehow expect that one day you might want to correctly model the size 
and color of the snowflakes ;-)

Torsten

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Curtis Olson]

The counter argument here is that the existing "auto coordination" system
is nothing more than one line of code that forces some rudder deflection in
proportion to aileron deflection -- basically implementing some sort of
hard linked manual system.  I am sure there are very few (if any?) real
life aircraft rigged in such a way.

Curt.


On Fri, Mar 9, 2012 at 1:57 PM, Renk Thorsten wrote:

> > Ok I haven't entirely given up on the idea of removing the
> > auto-coordination from the code.
>
> Why?
>
> > Wouldn't it be more appropriate to add
> > that rudder control to controls.nas?
>
> Nasal runs per graphical frame, FDMs may need to run faster at low
> framerates. Nasal AP systems tend to become unstable below 15 fps or so
> (see the F-14b).
>
> > Then it can be replaced if need be on a per aircraft basis , but not
> > break anything otherwise.
>
> You can replace it now on a per aircraft basis at the simple expense of
> setting a single property to false. If the aircraft is equipped with a
> better system, then that system can do so. Why is that a problem?
>
> > And maybe it could be slip/skid-ball driven ... my whole
> > point is NOT to disable it but make it configurable.
>
> Yes, them make it configurable on any aircraft you like. But it should not
> be absent from any aircraft you haven't touched.
>
> Cheers,
>
> * Thorsten
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Renk Thorsten]

> Ok I haven't entirely given up on the idea of removing the
> auto-coordination from the code.

Why?

> Wouldn't it be more appropriate to add
> that rudder control to controls.nas?

Nasal runs per graphical frame, FDMs may need to run faster at low framerates. 
Nasal AP systems tend to become unstable below 15 fps or so (see the F-14b).

> Then it can be replaced if need be on a per aircraft basis , but not
> break anything otherwise.

You can replace it now on a per aircraft basis at the simple expense of setting 
a single property to false. If the aircraft is equipped with a better system, 
then that system can do so. Why is that a problem?

> And maybe it could be slip/skid-ball driven ... my whole
> point is NOT to disable it but make it configurable.

Yes, them make it configurable on any aircraft you like. But it should not be 
absent from any aircraft you haven't touched.

Cheers,

* Thorsten
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Then it can be replaced if need be on a per aircraft basis , but not
break anything
otherwise.And maybe it could be slip/skid-ball driven ... my whole
point is NOT to disable it but make it configurable.
Syd

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

On Fri, Mar 9, 2012 at 4:28 AM, Martin Spott  wrote:
> syd adams wrote:
>
>> Actually I'd prefer the auto-coordination property to remain , and the
>> options to enable it too , just that it be handled in an autopilot
>> file rather than hard-coded.
>
> I'm not sure if I understood what you had in mind, therefore, beware, I
> might miss you point.  Anyhow from my perspective the auto-coordination
> is very much user specific and in no way aircraft specific.  Therefore
> I think it's not a clever idea to remove the global auto-coordination
> feature because those who don't have pedals will need it for _every_
> aircraft.
>
> Cheers,
>        Martin.
> --
>  Unix _IS_ user friendly - it's just selective about who its friends are !
> --
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

My thoughts were to keep the auto-coordination option , that is user specific,
but to have the autopilot files manage the controls rather than having
it hard-coded,which would allow it to be fine tuned per aircraft , but
the general opinion seems to be 'bad  idea' which is fine with me .
Syd

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[syd adams]

OK ,I was just gathering opinions , and it appears it should stay.Now
I know how to proceed.
Thanks guys.
Syd

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Flightgear and Simgear multiple format string vulnerabilities

[Andres Gomez]

Hi,

I have found multiple format string vulnerabilities in Flightgear and
Simgear. This could allow an attacker to execute arbitrary code in a
Flightgear user's machine. This is possible because user controlled format
string is passed directly to printf family functions without any
validation.  For example if I have an aircraft xml model with a section
like this:



Registration
text-value
/sim/multiplay/callsign
%s
true
.
.
.


the format string "%s" in label

%s

is passed directly to snprintf. This line can be changed for something like
"%s %s %s %s" which will make Flightgear to crash. Even more if "%n"
specifier* *is used, arbitrary code execution can be achieved. Until now I
have found this issue in the following files:

fgfs/flightgear/src/Cockpit/panel.cxx:1237
fgfs/flightgear/src/Cockpit/panel.cxx:1240
fgfs/flightgear/src/Cockpit/panel.cxx:1245
fgfs/flightgear/src/Network/generic.cxx:222

simgear/simgear/scene/model/SGText.cxx:72
simgear/simgear/scene/model/SGText.cxx:74

but others locations could also be affected. A solution for this bug would
be at least to validate that "n" specifier is not present in the format
string.

Regards,

Andrés Gómez
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Roberto Inzerillo]

How could I think that parking brakes would have been such a hot topic??!! :-)

Anyway, I appreciate the long detailed point of views. It's clear to me I have 
to be generic enough with this input device.
Well, it's going to stay as a 'double' but not a 24bit resolution anyway!


-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Martin Spott]

Eric van den Berg wrote:

> I see, I am sure there are more. I must admit I am more familiar with
> aircraft that are a bit more modern then the models you mention.

I've flown at least two rather modern aircraft (different types) but I
still prefer the aged ones for their style and atmosphere - and for
their charter rates  :-)

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Eric van den Berg]

I see, I am sure there are more. I must admit I am more familiar with aircraft 
that are a bit more modern then the models you mention. But I do know (I just 
had a look) that an old PA28-200 has a seperate, parallel cylinder with a 
handle in the middle console and a knob to fix it.
Using the master cylinder (or a seperate one) is not a very smart thing to do 
as they are notoriously leaky. I guess that is why newer aircraft designs use a 
seperate brake valve...

But I would say a 'double' property is appropriate and the characteristic 
depends on the individual aircraft. 

Cheers,

Eric

BTW Stefan: FAR/JAR/CS23 requires that the brakes are able to keep the (braked) 
wheels from turning with engine at take-off power. It does not require to hold 
the aircraft at its position (thus slipping is allowed).

> To: flightgear-devel@lists.sourceforge.net
> From: martin.sp...@mgras.net
> Date: Fri, 9 Mar 2012 12:46:25 +
> Subject: Re: [Flightgear-devel] Double Input Resolution?
> 
> Eric van den Berg wrote:
> 
> > Agreed, but the as you are saying, the brake is hydraulic and
> > therefore there will always be a valve that traps the hydraulic fluid
> 
> No.
> 
> At least the older C172's  are having mechanically operated parking
> brake levers which apply force onto the same hydraulic master cylinders
> as the pedals do.  The DR300's and maybe even the very early DR400's
> are using the same principle and, as far as I remember, that's quite
> similar on the C150's and PA28's (the DR300 doesn't have toe brakes at
> all ).
> Thus all their parking brakes are featuring an analogue characteristic.
> 
> The modern DR400's are having a parking brake valve according to your
> explanation and our old C175 has a mechanical ! arrestor on the
> hydraulic master cylinders.
> 
> Did I forget one ?  Maybe.
> 
> Cheers,
>   Martin.
> -- 
>  Unix _IS_ user friendly - it's just selective about who its friends are !
> --
> 
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel



  --
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Martin Spott]

Eric van den Berg wrote:

> Agreed, but the as you are saying, the brake is hydraulic and
> therefore there will always be a valve that traps the hydraulic fluid

No.

At least the older C172's  are having mechanically operated parking
brake levers which apply force onto the same hydraulic master cylinders
as the pedals do.  The DR300's and maybe even the very early DR400's
are using the same principle and, as far as I remember, that's quite
similar on the C150's and PA28's (the DR300 doesn't have toe brakes at
all ).
Thus all their parking brakes are featuring an analogue characteristic.

The modern DR400's are having a parking brake valve according to your
explanation and our old C175 has a mechanical ! arrestor on the
hydraulic master cylinders.

Did I forget one ?  Maybe.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Stefan Seifert]

On Friday 09 March 2012 13:27:19 Eric van den Berg wrote:
> Agreed, but the as you are saying, the brake is hydraulic and therefore
> there will always be a valve that traps the hydraulic fluid and keeps the
> pressure on the brake pistons. This valve will always only be fully closed
> in the end position (Just as a tip if you will be using a 'double'). This
> is standard on _most_ small aircraft as there is only one predominant
> supplier for wheels and brakes for small aircraft. The implementation may
> be different, the equipment is the same on every single aircraft.

Most gliders I've flown do not even use hydraulics for brakes. And the parking 
brake often is nothing more than some hook or lever which can be used to lock 
the brake lever. But it's still a 0 or 1 thing. The brakes either are locked 
or not. Of course, full brake may still not be enough to keep the aircraft in 
place or not even to prevent it from taking off...

Stefan

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Eric van den Berg]

Agreed, but the as you are saying, the brake is hydraulic and therefore there 
will always be a valve that traps the hydraulic fluid and keeps the pressure on 
the brake pistons. This valve will always only be fully closed in the end 
position (Just as a tip if you will be using a 'double'). This is standard on 
_most_ small aircraft as there is only one predominant supplier for wheels and 
brakes for small aircraft. The implementation may be different, the equipment 
is the same on every single aircraft.  

BTW when I say small aircraft I mean Part 23 aircraft, excluding anything 
bigger then a six-seat single turboprop.

Cheers,

Eric



> To: flightgear-devel@lists.sourceforge.net
> From: martin.sp...@mgras.net
> Date: Fri, 9 Mar 2012 11:22:38 +
> Subject: Re: [Flightgear-devel] Double Input Resolution?
> 
> Eric van den Berg wrote:
> 
> > How a parking brake on small aircraft works:
> 
> Well, from my experience I'd say there are almost as many different
> types of small-aircraft parking brakes as there are different
> manufacturers.  I remember having flown at least six different types of
> small aircraft by three different manufacturers and in these aircraft
> you'll find three or four different implementations (depending on how
> close you look at the details) of a parking brake.
> I'm really talking about different techniques, not just different
> designs or positions of a parking brake handle.  The only thing these
> aircraft had in common is that the brake discs (one or two maybe even
> had drums) are being operated hydraulically.  Some very light aircraft
> or microlites are having the discs/drums operated directly by the
> Bowden cable without hydraulic transmission.
> 
> Therefore, if you're aiming at defining a general rule for mapping
> small aircraft parking brakes, make it as flexible as possible.
> 
> > So the parking brake will have two effective settings: open and
> > closed.
> 
> Indeed, that's true for _some_ of the small aircraft, but it's untrue
> for some other very popular types.
> 
> Cheers,
>   Martin.
> -- 
>  Unix _IS_ user friendly - it's just selective about who its friends are !
> --
> 
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
  --
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Martin Spott]

syd adams wrote:

> Actually I'd prefer the auto-coordination property to remain , and the
> options to enable it too , just that it be handled in an autopilot
> file rather than hard-coded.

I'm not sure if I understood what you had in mind, therefore, beware, I
might miss you point.  Anyhow from my perspective the auto-coordination
is very much user specific and in no way aircraft specific.  Therefore
I think it's not a clever idea to remove the global auto-coordination
feature because those who don't have pedals will need it for _every_
aircraft.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Martin Spott]

Eric van den Berg wrote:

> How a parking brake on small aircraft works:

Well, from my experience I'd say there are almost as many different
types of small-aircraft parking brakes as there are different
manufacturers.  I remember having flown at least six different types of
small aircraft by three different manufacturers and in these aircraft
you'll find three or four different implementations (depending on how
close you look at the details) of a parking brake.
I'm really talking about different techniques, not just different
designs or positions of a parking brake handle.  The only thing these
aircraft had in common is that the brake discs (one or two maybe even
had drums) are being operated hydraulically.  Some very light aircraft
or microlites are having the discs/drums operated directly by the
Bowden cable without hydraulic transmission.

Therefore, if you're aiming at defining a general rule for mapping
small aircraft parking brakes, make it as flexible as possible.

> So the parking brake will have two effective settings: open and
> closed.

Indeed, that's true for _some_ of the small aircraft, but it's untrue
for some other very popular types.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] scenery loading cleanup

[Jon Stockill]

On Thu, 8 Mar 2012 23:13:56 +0100, Clement de l'Hamaide wrote:

> I've encountered a problem about this change but I fixed it. Some
> explanation :
> I use 5 sceneries folders and some of them add some data to the
> precedent scenery folder.
> I use this argument :
> 
> --fg-scenery=/home/clement/Scenery_test:/home/clement/fgdata_paf/Scenery:/home/clement/Scenery_elmaxo:/home/clement/Scenery_papillon81/Scenery:/home/clement/Scenery_italy:/home/clement/Scenery
> In order to fly at LFHU (France) I use these data:
> ~/fgdata_paf/Scenery/Object/e000n40/e006n45/3056064.stg
> ~/Scenery_elmaxo/Terrain/e000n40/e006n45/3056064.stg
> ~/Scenery_elmaxo/Terrain/e000n40/e006n45/3056064.btg.gz
> ~/Scenery_elmaxo/Terrain/e000n40/e006n45/LFHU.btg.gz
>
> Since you have changed I need to move associated Terrain in the same
> Scenery folder of Object folder. So I copied/pasted Terrain data in
> the same Scenery folder contains Objects and now I use these data:
> ~/fgdata_paf/Scenery/Object/e000n40/e006n45/3056064.stg
> ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/3056064.stg
> ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/3056064.btg.gz
> ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/LFHU.btg.gz

I have something similar in that my scenery path has 
/export/LocalScenery:/export/Scenery

The LocalScenery directory contains only an objects directory which 
adds extra objects that I'm currently working on. Previously these 
objects would be displayed along with the objects and terrain from the 
/export/Scenery directory but now I just get the objects and no terrain. 
Removing the first directory from the search path brings the terrain 
back again.

Can you explain exactly how the loading now works, and if it's still 
possible to use extra local objects trees in the way I describe?

-- 
Jon Stockill
li...@stockill.net

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Eric van den Berg]

How a parking brake on small aircraft works:
There is a hydraulic line between the brake cylinders at the pedals ('toe 
brakes'). The hydraulic pressure pushes pistons in the brake saddle (aircraft 
fixed) against the brake disk on the wheels.
In this line there is a valve that can block this line effectively keeping the 
hydraulic pressure on the brake saddle pistons although the pilot releases the 
toe brakes.
This valve is usually actuated by a so-called Bowden cable. The pilot only sees 
the bowden cable knob which he has to pull to close the parking brake valve. Of 
course the valve needs to be kept in the closed position, so the Bowden cable 
needs to be able to keep its position. To do this there are two types, both 
have a typical travel of around 100mm (4inches):
1. with a knob: push the knob on the centre of the Bowden cable handle to move 
the cable freely, release the knob to fix it
2. with friction: the friction is high enough to keep its position in any case, 
often there is the clicking noise when moved.

So the parking brake will have two effective settings: open and closed. Any 
position in between will mean the valve is partially open and therefore the 
parking brake is ineffective. So apply brake pressure, pull Bowden cable out 
fully and this will keep your plane from slowly rolling into an other rather 
expensive object.

Cheers 

Eric  


> Date: Fri, 9 Mar 2012 10:57:18 +0100
> From: rob...@gmx.net
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Double Input Resolution?
> 
> >>> Parking brake is just a on/off flag (1bit).
> >>
> >> Well, right, but not totally. I've seen aircrafts accepting a double
> >> value, and I'd like to make it consistent. Intermediate values make
> >> sense here since it's a lever that moves along a path (or at least
> >> rotates around a hinge). It's not a two positions switch. Anyway,
> >> that's not the point, I'm just disgressing :-)
> >
> > ..I've seen levers 'n pedals used on parking brakes, if you set
> > it slowly enough, they go "click click click click", just count
> > the clicks. ;o)
> 
> That's good information :-)
> 
> A detail to Torsten: how does the SenecaII Parking brake "moves" along 
> its path in real life? Does it click like an old car parking brake or 
> does it slide smoothly?
> 
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
  --
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG_SERVER::Loop() - Bytes <= 0!

[Geoff McLane]

Hi Roland,

Maybe Oliver can add more... but -

1: I am working with the version in my own clone of 
master, geoffmcls-fgms-0-x, but it is the SAME in 
that code area.

In a recent test setup I too was 'flooded' with 
this particular message. That turned out to be 
due to port 5000 udp in/out, and/or port 5001 tcp 
in/out had NOT been enabled on that machine...

Maybe Yves could explain what he needed to do 
to change that...

And even after the change still get some of these 
message from a telnet queries...

So that is one thing to look at...

2: The only recent (September 27 2011) change to that 
code was -
-if (! Bytes)
+if ( Bytes <= 0 )
 {
SG_ALERT (SG_SYSTEMS, SG_ALERT,
 "FG_SERVER::Loop() - Bytes <= 0!");
continue;

That is changing the if test from just !Bytes, which is 
Bytes == 0, to Bytes <= 0, to reflect what the SG_ALERT 
states.

Maybe if you change that back to if (! Bytes) you would get
'less', or no SG_ALERT messages to the log, but that does 
not deal with the reason for the 'select' -
  Bytes = m_DataSocket->select (ListenSockets,0,m_PlayerExpires);
returning -1, an ERROR.

And if you added strerror(errno) to the SG_ALERT, like say -

SG_ALERT (SG_SYSTEMS, SG_ALERT,
   "FG_SERVER::Loop() - Bytes <= 0! " << 
   Bytes << " errno " << errno << " msg " << 
   strerror(errno) );

you would be able to also see the specific error returned 
by select(), and maybe deal with it...

HTH,

Regards,
Geoff.

On Thu, 2012-03-08 at 21:55 +0100, "Roland Häder" wrote:
> Hi,
> 
> I get this message flooded into fgms.log file with latest master. Can you 
> please take a look?
> 
> Regards,
>   Roland
> 



--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Double Input Resolution?

[Roberto Inzerillo]

>>> Parking brake is just a on/off flag (1bit).
>>
>> Well, right, but not totally. I've seen aircrafts accepting a double
>> value, and I'd like to make it consistent. Intermediate values make
>> sense here since it's a lever that moves along a path (or at least
>> rotates around a hinge). It's not a two positions switch. Anyway,
>> that's not the point, I'm just disgressing :-)
>
> ..I've seen levers 'n pedals used on parking brakes, if you set
> it slowly enough, they go "click click click click", just count
> the clicks. ;o)

That's good information :-)

A detail to Torsten: how does the SenecaII Parking brake "moves" along 
its path in real life? Does it click like an old car parking brake or 
does it slide smoothly?

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Pedro Morgan]

Some of us don't have a joystick and fl with a mouse and autopilot..

auto-coordination has to stay.. however.. just realised it DOES mess up the
autopilot...

pete



On Fri, Mar 9, 2012 at 6:51 AM, syd adams  wrote:

> On Thu, Mar 8, 2012 at 10:19 PM, Curtis Olson  wrote:
> > Hi Syd,
> >
> > That was a hack from the very early days of the project, so if it went
> away,
> > it wouldn't bother me.  Fred might have a check box in the window
> launcher,
> > and there may be a command line option or property value to hunt down and
> > remove.
> >
> > Curt
> >
>
> Thanks , Curt.
> Actually I'd prefer the auto-coordination property to remain , and the
> options to enable it too , just that it be handled in an autopilot
> file rather than hard-coded.
> I've added a sort of auto coordination to the R22  below a certain
> airspeed, otherwise I cant get it off the ground no matter how fast I
> tap those rudder keys , and enabling auto-coordination would be a
> easier in these situations, i think.
> At least for those of us without rudder pedals.
> It would mean more work for aircraft designers , but a simple filter
> should easily do what the code does.
> Syd
>
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] auto-coordination

[Torsten Dreyer]

Am 09.03.2012 07:51, schrieb syd adams:
> On Thu, Mar 8, 2012 at 10:19 PM, Curtis Olson  wrote:
>> Hi Syd,
>>
>> That was a hack from the very early days of the project, so if it went away,
>> it wouldn't bother me.  Fred might have a check box in the window launcher,
>> and there may be a command line option or property value to hunt down and
>> remove.
>>
>> Curt
>>
>
> Thanks , Curt.
> Actually I'd prefer the auto-coordination property to remain , and the
> options to enable it too , just that it be handled in an autopilot
> file rather than hard-coded.
> I've added a sort of auto coordination to the R22  below a certain
> airspeed, otherwise I cant get it off the ground no matter how fast I
> tap those rudder keys , and enabling auto-coordination would be a
> easier in these situations, i think.
> At least for those of us without rudder pedals.
> It would mean more work for aircraft designers , but a simple filter
> should easily do what the code does.
> Syd

I can add it to the generic-autopilot-helper or generic-autopilot and 
remove the hardcoded part. Aircraft overwriting the generic-autopilot 
(defining their own A/P) will have to implement their own 
auto-coordination, though.

Torsten

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel