Re: [Flightgear-devel] Little Ground Vehicle patch (for Vivian)

[Nicolas Quijano]

Hmm, needs further work... Now, they've taken a liking to going under the
terrain, damn
Will get back with further findings once I've dug deeper (pun intended)
Cheers,
Nic


On Wed, Sep 9, 2009 at 8:05 PM, Nicolas Quijano  wrote:

> Hi Vivian, testing your new groundvehicle class for AI scenarios in the
> context of a "train" of tanks and another of jeeps, I stumbled into their
> wandering in the air.
>
>
>

-- 
Be Kind.
Remember, everyone is fighting a hard battle.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Patches for configure.ac/Makeifle.am in SG/FG

[Tatsuhiro Nishioka]

Hi Torsten,

Thanks for your offer.

Of course I can wait. 
Plus, James Turner was kindly enough to test my patches and it got a linker 
error on SG,
so I need to fix the error (due to the order of static libs, I guess).
It may takes a few days, so no problem at all.
I'll repost the patches when it is fixed.

Best,

Tat

On Sep 10, 2009, at 4:38 AM, Torsten Dreyer wrote:

>> Hi,
>>
>> I've updated the patches for configure.ac and Makefile.am files in FG/SG so
>> Mac developers can build these in a unix way. These also enables Mac
>> developers to choose either PLIB framework or PLIB static libs.
>>
>> The patches work fine on my Mac, and I want linux users to check if these
>> also work OK. This update includes the changes to generic input device so
>> it can be built under both Linux and Mac. Please let me know if there are
>> any problems.
>>
>> Torsten,
>> Could you check if the change to configure.ac and src/{Input,
>> Main}/Makefile.am work on Linux regarding to generic input? If everything
>> works fine, please commit these patches for me.
>>
>>
>> Best,
>>
>> Tat
>
> Hi Tat,
>
> I'll have a look at your changes, but probably not before the weekend.
> Hope you can wait that long ;-)
>
> Greetings, Torsten
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Small fix for fgrun

[Tom P]

Hi

I've noticed that in fgrun there's no way to pass a working 'carrier'
location to fgfs, and this fixes it.
As it is now, both --airport and --carrier are passed, and fgfs defaults to
the airport location, while after applying this fix, if the carrier field is
not empty, the airport selection will be nulled-out and won't be passed to
fgfs.

Tested on Ubuntu 9.04.

  Tom
Index: wizard_funcs.cxx
===
--- wizard_funcs.cxx	(revision 517)
+++ wizard_funcs.cxx	(working copy)
@@ -2029,7 +2029,10 @@
 		airports_->get_selected_name().c_str() );
 p.set( "carrier", carrier_->value() );
 if ( carrier_->value() != string() )
-	p.set( "parkpos", parkpos_->value() );
+{
+p.set( "airport", "");
+p.set( "parkpos", parkpos_->value() );
+}
 else
 p.set( "parkpos", airports_->get_selected_parking().c_str() );
 
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Little Ground Vehicle patch (for Vivian)

[Nicolas Quijano]

Hi Vivian, testing your new groundvehicle class for AI scenarios in the
context of a "train" of tanks and another of jeeps, I stumbled into their
wandering in the air.
The solution is two-fold : one, specify a starting altitude through the
 tag in the groundvehicle's  in the ai scenario, even
though we're using a flightplan (maybe I could have just re-ordered things
around to we don't do GetPitch et al. before popping the first waypoint, but
this was simple ;))
This ensures we don't have zero as elevation in the initial calculations
after applying my patch.

What my  patch does is to stop using an arbitrary 1m lookup for the
geode checks, but rather use the current elevation in meter, to avoid
finding anything else, including buildings, or other models, which was
gradually building up to an error amounting to the whole "train" floating
above ground.

Been testing it in the very hilly terrain in between La Honda and the
Stanford Accelerator center, at the upper edge of Palo Alto.
They conform to the terrain way better after the patch, and setting an
initial altitude.
I'll leave it up to you to see if the patch has any applicability in your
further work with the AIGroundVehicle class, but I wanted to point out the
hovering higher and higher as time goes by behaviour and provide a solution
:)

Cheers,
Nic



-- 
Be Kind.
Remember, everyone is fighting a hard battle.


AIGroundVehicle.cxx.patch
Description: Binary data
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] An input issue on Ubuntu 9.04 (64 bit) ?

[Tom P]

Oh, but that's why I tested also a build from 7/15, I just wanted to exclude
that.

Looking closely, I found a reference to this problem on the forum
afterwards:
  http://www.flightgear.org/forums/viewtopic.php?f=11&t=4880

and, yeah, I can confirm that the accelerometer is usable to control the
plane (think of "a much heavier version of the iPhone"). Funny!

  Tom


On Wed, Sep 9, 2009 at 3:50 PM, Curtis Olson  wrote:

> I was going to suggest the new HID code as another possible thing to
> consider, but I didn't want to just go blaming someone else's code. :-)
>
> Curt.
>
>
> On Wed, Sep 9, 2009 at 5:46 PM, Tom P wrote:
>
>> That was a good hint, because I looked at the property tree, and on 9.04 I
>> see an extra item, /input/joysticks/js
>>
>> Weird, I think, I don't have a joystick.
>>
>> Turns out 9.04 recognized the internal accelerometer on my laptop as a
>> input source and I can control the airplane by tilting the laptop!
>> LOL, what a blast!
>>
>> Not sure if it's a feature, but it made my day!
>>
>>   Tom
>>
>>
>>
>> On Wed, Sep 9, 2009 at 3:19 PM, Curtis Olson  wrote:
>>
>>> On Wed, Sep 9, 2009 at 5:08 PM, Tom P wrote:
>>>
 Hi

 I was wondering if anyone has seen a weird input behaviour on Ubuntu
 9.04.
 I'm building from HEAD but even building an old version (7/15) shows the
 same behaviour.

 Basically the throttle and surface inputs are received, but controls are
 "re-centered" from time to time, like it would be the case if someone
 continuously pressed '5'.
 Plus the throttle is forced to 50%.

 It doesn't seem to be my hardware because on the same laptop I've built
 FG from HEAD and ran on Ubuntu 9.10 alpha (Karmic Koala) without a problem
 in the past.
 Any hint will help, thanks
>>>
>>>
>>> The only time I have seen something similar is when I forgot I had a
>>> joystick still plugged in.  As long as the joystick inputs don't change from
>>> the previous step then I think the joystick is mostly ignored and you can
>>> fly with keyboard and mouse, but if anything gets bumped or jittered you
>>> momentarily snap to the joystick position.
>>>
>>> Regards,
>>>
>>> Curt.
>>> --
>>> Curtis Olson: 
>>> http://baron.flightgear.org/~curt/
>>>
>>>
>>
>>
>>
>> --
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>>
>
>
> --
> Curtis Olson: 
> http://baron.flightgear.org/~curt/
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[Tim Moore]

On 09/09/2009 07:06 PM, John Denker wrote:
> On 09/09/09 06:16, Tim Moore wrote:
> 
 Yes, the 2009 code is different from the 2007 code.
 The 2009 features and bugfixes are a superset of the
 2007 features and bugfixes.  Also the 2009 commits
 were rebased so that they applied cleanly to the FGFS
 release that was current at the time.

>>> That's great! What's the url for the repository that has these changes?
>>> Unless I'm doing something wrong, it seems like 
>>> http://www.av8n.com/repo/fgs/.git
>>> and http://www.av8n.com/repo/sg/.git haven't been updated in some
>>> time.
> 
> I updated that site just now.  I had stopped using 
> it more than two years ago, because it is just a
> fileserver (lots of network connectivity, without
> much CPU capacity) ... meaning it didn't support
> gitweb.  I thought it would be more convenient
> for folks to evaluate my patches if I put my FGFS
> stuff on a gitweb-enabled host.  It turned out it 
> didn't make much difference. 
I find gitweb a poor substitute for cloning  the repository and using gitk
and the command line tools to poke around. But why don't you put your
repositories on a well-known git hosting site that supports gitweb and more?
Most convenient would be to fork my repositories on repo.or.cz and
base your sportmodel on those.
 James Turner looked 
> at a couple of my patches using gitweb, but the 
> only folks who actually downloaded and tested the 
> patches were folks without commit authority.  My 
> FGFS gitweb host died a while back.  I didn't 
> bother to replace it, since it wasn't seeing any
> traffic.
...

> On 09/09/09 07:08, James Turner wrote:
...
>>  simply  
>> that either I need to be able to convince myself that a specific  
>> change is correct  Otherwise, I'll leave any  
>> functional changes to to others.
> 
> What others?  As of January, I was under the impression 
> that you, James, were the one and only maintainer of
> navradio.cxx.  Are you suggesting that there is someone
He is now :)
> with commit authority who was interested and/or 
> qualified to judge the correctness of my code?  I 
> was quite unaware of this back in January.  Has the
> situation changed somehow?
> 
> Several people did try out my code ... just nobody with
> commit authority.  Evidently this kind of testing doesn't
> count.
> 
> Is the criterion that I have to prove that my patches 
> are absolutely correct?  I don't see how it would ever
> be possible to do that.  The code had tons of bugs 
> before I touched it, and it has tons of bugs now.  It 
> seems safe to say that accepting my patches would have 
> resulted in a better feature set and _far fewer_ bugs, 
> to say the least.
No one wants a formal proof, but some comments might be in order. For
whatever reason your patches tend to be controversial.

Anyway, I committed your changes to simgear. I'm sorry that the
author info got lost in the CVS commit; I'll use the -a flag on
git cvsexportcommit in the future.

When I look at your sportmodel branch with my software engineer hat
on (no pilot helmet here), I see features that would be great to
have, but also a lot of code that we already know won't merge cleanly.
So, I propose to pick apart sportmodel as much as possible into patch
series that don't depend on each other. There are a lot of changes to
navradio.[ch]xx, but you and James are in heated discussion,
so I'm not touching that. Instead, it looks like "Two-parameter physics-based
model of atmosphere up to 262,467 ft i.e. the top of the mesosphere. Correctly
exhibits the HALT phenomenon." would be awesome to have and is relatively
independent of the rest of sportmodel. So, I have split out just that changeset
and merged it to my next branch (basically CVS HEAD). I've pushed the result
to the jsd/environment branch in git://repo.or.cz/flightgear.git. Could you
take a look and see if this merge is correct, especially with respect to the
live_update stuff that was introduced since you made your changes? Before
this is checked in to CVS I'd like to see if Unpack.hxx can be replaced with
Boost tuples, but otherwise the code looks good.

Thanks,
Tim


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] An input issue on Ubuntu 9.04 (64 bit) ?

[Curtis Olson]

I was going to suggest the new HID code as another possible thing to
consider, but I didn't want to just go blaming someone else's code. :-)

Curt.


On Wed, Sep 9, 2009 at 5:46 PM, Tom P wrote:

> That was a good hint, because I looked at the property tree, and on 9.04 I
> see an extra item, /input/joysticks/js
>
> Weird, I think, I don't have a joystick.
>
> Turns out 9.04 recognized the internal accelerometer on my laptop as a
> input source and I can control the airplane by tilting the laptop!
> LOL, what a blast!
>
> Not sure if it's a feature, but it made my day!
>
>   Tom
>
>
>
> On Wed, Sep 9, 2009 at 3:19 PM, Curtis Olson  wrote:
>
>> On Wed, Sep 9, 2009 at 5:08 PM, Tom P wrote:
>>
>>> Hi
>>>
>>> I was wondering if anyone has seen a weird input behaviour on Ubuntu
>>> 9.04.
>>> I'm building from HEAD but even building an old version (7/15) shows the
>>> same behaviour.
>>>
>>> Basically the throttle and surface inputs are received, but controls are
>>> "re-centered" from time to time, like it would be the case if someone
>>> continuously pressed '5'.
>>> Plus the throttle is forced to 50%.
>>>
>>> It doesn't seem to be my hardware because on the same laptop I've built
>>> FG from HEAD and ran on Ubuntu 9.10 alpha (Karmic Koala) without a problem
>>> in the past.
>>> Any hint will help, thanks
>>
>>
>> The only time I have seen something similar is when I forgot I had a
>> joystick still plugged in.  As long as the joystick inputs don't change from
>> the previous step then I think the joystick is mostly ignored and you can
>> fly with keyboard and mouse, but if anything gets bumped or jittered you
>> momentarily snap to the joystick position.
>>
>> Regards,
>>
>> Curt.
>> --
>> Curtis Olson: 
>> http://baron.flightgear.org/~curt/
>>
>>
>
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>


-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] An input issue on Ubuntu 9.04 (64 bit) ?

[Tom P]

That was a good hint, because I looked at the property tree, and on 9.04 I
see an extra item, /input/joysticks/js

Weird, I think, I don't have a joystick.

Turns out 9.04 recognized the internal accelerometer on my laptop as a input
source and I can control the airplane by tilting the laptop!
LOL, what a blast!

Not sure if it's a feature, but it made my day!

  Tom


On Wed, Sep 9, 2009 at 3:19 PM, Curtis Olson  wrote:

> On Wed, Sep 9, 2009 at 5:08 PM, Tom P wrote:
>
>> Hi
>>
>> I was wondering if anyone has seen a weird input behaviour on Ubuntu 9.04.
>> I'm building from HEAD but even building an old version (7/15) shows the
>> same behaviour.
>>
>> Basically the throttle and surface inputs are received, but controls are
>> "re-centered" from time to time, like it would be the case if someone
>> continuously pressed '5'.
>> Plus the throttle is forced to 50%.
>>
>> It doesn't seem to be my hardware because on the same laptop I've built FG
>> from HEAD and ran on Ubuntu 9.10 alpha (Karmic Koala) without a problem in
>> the past.
>> Any hint will help, thanks
>
>
> The only time I have seen something similar is when I forgot I had a
> joystick still plugged in.  As long as the joystick inputs don't change from
> the previous step then I think the joystick is mostly ignored and you can
> fly with keyboard and mouse, but if anything gets bumped or jittered you
> momentarily snap to the joystick position.
>
> Regards,
>
> Curt.
> --
> Curtis Olson: 
> http://baron.flightgear.org/~curt/
>
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] An input issue on Ubuntu 9.04 (64 bit) ?

[Curtis Olson]

On Wed, Sep 9, 2009 at 5:08 PM, Tom P wrote:

> Hi
>
> I was wondering if anyone has seen a weird input behaviour on Ubuntu 9.04.
> I'm building from HEAD but even building an old version (7/15) shows the
> same behaviour.
>
> Basically the throttle and surface inputs are received, but controls are
> "re-centered" from time to time, like it would be the case if someone
> continuously pressed '5'.
> Plus the throttle is forced to 50%.
>
> It doesn't seem to be my hardware because on the same laptop I've built FG
> from HEAD and ran on Ubuntu 9.10 alpha (Karmic Koala) without a problem in
> the past.
> Any hint will help, thanks


The only time I have seen something similar is when I forgot I had a
joystick still plugged in.  As long as the joystick inputs don't change from
the previous step then I think the joystick is mostly ignored and you can
fly with keyboard and mouse, but if anything gets bumped or jittered you
momentarily snap to the joystick position.

Regards,

Curt.
-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] An input issue on Ubuntu 9.04 (64 bit) ?

[Tom P]

Hi

I was wondering if anyone has seen a weird input behaviour on Ubuntu 9.04.
I'm building from HEAD but even building an old version (7/15) shows the
same behaviour.

Basically the throttle and surface inputs are received, but controls are
"re-centered" from time to time, like it would be the case if someone
continuously pressed '5'.
Plus the throttle is forced to 50%.

It doesn't seem to be my hardware because on the same laptop I've built FG
from HEAD and ran on Ubuntu 9.10 alpha (Karmic Koala) without a problem in
the past.
Any hint will help, thanks!

  Tom
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[John Denker]

On 09/09/09 14:31, James Turner wrote:

> In practice, all the instruments I've seen so far handle 'parking' the  
> GS needle in two ways: either masking layer above the needle, at the  
> extremities of the range, or an interpolation table where the extreme  
> values map to a particular hidden position.

As with so many things, that is sometimes true and
sometimes not.

Some instruments park the GS needle in plain sight, 
in the middle of the range.  You could argue that 
this is a poor user-interface design, so poor that 
it couldn't get certified today ... but it *is* 
what some real-world instruments do.

It is a Bad Idea for the back-end (navradio.cxx) to 
make assumptions that conflict with what the front-end 
(instrument.xml) needs to do.

The best procedure, which considerably simplifies
the xml, is to allow the _instrument_ to tell
navradio.cxx where to park the needle, not the
other way around.  The instrument.xml file knows
how the needle is supposed to behave.  As a 
separate issue, there really needs to be a "valid" 
flag, closely analogous to the To/Off/From flag 
on theCDI.  The code I wrote in 2007 and rebased 
in January 2009 has all these features.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Compiling newest CVS FlightGear/SimGear Error inprops.hxx

[Vivian Meazza]

Yup, 

 

 

Add this to props.hxx

 

#include 

 

Might not be the right answer, but it works. Fred will fix it properly in
due course.

 

Vivian

 

-Original Message-
From: Randall Green [mailto:randall.gr...@wright.edu] 
Sent: 09 September 2009 20:46
To: FlightGear developers discussions
Subject: [Flightgear-devel] Compiling newest CVS FlightGear/SimGear Error
inprops.hxx

 

I'm trying to compile the newest CVS FlightGear/SimGear and I get the
following long winded error

message. When I click on it, it takes me to:

private:

T_obj

in props.hxx. Anyone have this problem?

Thanks,

Randy Green

2>c:\fg2\simgear\simgear\props\props.hxx(666) : error C2079:
'SGRawValueContainer::_obj' uses undefined class 'SGVec3'
2>with
1>Build log was saved at
"file://c:\FG2\FlightGear\projects\VC90\terrasync\Win32\Debug\BuildLog.htm

"
2>[
2>T=SGVec3d
2>]
2>and
2>[
2>T=double
2>]
1>terrasync - 1 error(s), 0 warning(s)
2>c:\fg2\simgear\simgear\props\props.hxx(672) : see reference to
class template instantiation 'SGRawValueContainer' being compiled
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(671) : while compiling
class template member function 'SGRawExtended
*SGRawBase::makeContainer(void) const'
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(692) : see reference to
class template instantiation 'SGRawBase' being compiled
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(685) : error C2079: 'value' uses
undefined class 'SGVec3'
2>with
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(684) : while compiling
class template member function 'std::istream
&SGRawBase::readFrom(std::istream &)'
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(687) : error C2664:
'SGRawValue::setValue' : cannot convert parameter 1 from 'int' to
'SGVec3d'
2>with
2>[
2>T=SGVec3d
2>]
2>Source or target has incomplete type
2>c:\fg2\simgear\simgear\props\props.hxx(666) : error C2079:
'SGRawValueContainer::_obj' uses undefined class 'SGVec4'
2>with
2>[
2>T=SGVec4d
2>]
2>and
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(672) : see reference to
class template instantiation 'SGRawValueContainer' being compiled
2>with
2>[
2>T=SGVec4d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(671) : while compiling
class template member function 'SGRawExtended
*SGRawBase::makeContainer(void) const'
2>with
2>[
2>T=SGVec4d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(694) : see reference to
class template instantiation 'SGRawBase' being compiled
2>with
2>[
2>T=SGVec4d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(685) : error C2079: 'value' uses
undefined class 'SGVec4'
2>with
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(684) : while compiling
class template member function 'std::istream
&SGRawBase::readFrom(std::istream &)'
2>with
2>[
2>T=SGVec4d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(687) : error C2664:
'SGRawValue::setValue' : cannot convert parameter 1 from 'int' to
'SGVec4d'
2>with
2>[
2>T=SGVec4d
2>]
2>Source or target has incomplete type
2>beacon.cxx
3>-- Build started: Project: fgviewer, Configuration: Debug Win32 --
3>Linking...
2>c:\fg2\simgear\simgear\props\props.hxx(666) : error C2079:
'SGRawValueContainer::_obj' uses undefined class 'SGVec3'
2>with
2>[
2>T=SGVec3d
2>]
2>and
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(672) : see reference to
class template instantiation 'SGRawValueContainer' being compiled
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(671) : while compiling
class template member function 'SGRawExtended
*SGRawBase::makeContainer(void) const'
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(692) : see reference to
class template instantiation 'SGRawBase' being compiled
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(685) : error C2079: 'value' uses
undefined class 'SGVec3'
2>with
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(684) : while compiling
class template member function 'std::istream
&SGRawBase::readFrom(std::

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[James Turner]

On 9 Sep 2009, at 21:47, Torsten Dreyer wrote:

> I don't think clamping the deviation to +/-0.7 degrees and the  
> normalized
> value to +/- 1.0 is a good idea. Instruments like the KI525 HSI move  
> the
> glide slope needle out of sight when the glideslope signal is not  
> valid or
> you are way above or below glideslope.
> If you clamp the values, this information is lost for the instrument.

This is a fair point - the problem is it's a situation the current  
property also handles incorrectly - it acts as if the sensing area for  
the GS is much 'thicker' than it actually is - so rather than  
reporting invalid, we just report extremely large 'valid' values. What  
needs to happen is to communicate the absence of a valid GS signal  
(for whatever reason) some meaningful way.

(This, btw, is why the Mk-VIII has the -ncd flags for each input/ 
output property)

The two solutions I can think of:
- use - (or similar) to indicate an invalid signal OR
- use the (existing) has-gs flag to indicate it (or a new flag, like  
gs-valid)

The second seems much more sensible to me, in terms of minimal changes  
to existing instruments. Note that right now, the has-gs flag is not  
quite useful for this purpose, because we don't update it based on  
radio reception - I'd need to audit current users to see if it could  
be modified that way, or whether a new property is safer.

(the first solution needs special handling by every existing  
instrument and script, I think, though it is a method used elsewhere  
in the code)

In practice, all the instruments I've seen so far handle 'parking' the  
GS needle in two ways: either masking layer above the needle, at the  
extremities of the range, or an interpolation table where the extreme  
values map to a particular hidden position. Also, all the instruments  
I've changed so far have implemented a clamp themselves, either via an  
interpolation table, or min/max values on the animation element - I'm  
not creating any 'new' clamping, that I've seen so far.

So, I think clamping is correct (and matches what we do for the  
heading needle) - what's needed is a flag property, and for panel /  
instrument authors to use that flag to implement a parking behaviour  
if they wish.

Regards,
James


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] navradio

[James Turner]

On 9 Sep 2009, at 21:28, Atadjanov Daniyar wrote:

> Just tested NDB freqs "problem" - everything work good. Sorry for  
> panic.

That's good news indeed! I was worried I'd broken the spatial searches.

Thanks for checking, and please let me know if you see other strange  
behaviour.

James


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[Torsten Dreyer]

> Here is what I'm going to do:
>   - change gs-needle-deflection to report the GS deviation *in degrees*
>  - add a gs-needle-deflection-norm property, reporting the
> deflection as the range +/- 1.0 (I'll probably do that for the CDI as
> well). 1.0 will be on the peg, 0.0 will be centred - no surprises
> here, I hope.
>   - clamp the GS deviation to +/- 0.7 degrees in the nav-radio code (as
> we clamp the CDI deflection to +/-10 degrees). This is significant,
> because many panels currently work due to the value *not* being
> clamped to any range. I.e there will be a peg at the sim level, not
> just a a peg defined at the animation / panel level.
Hi James

I really appreciate your work on this topic! 
I don't think clamping the deviation to +/-0.7 degrees and the normalized 
value to +/- 1.0 is a good idea. Instruments like the KI525 HSI move the 
glide slope needle out of sight when the glideslope signal is not valid or 
you are way above or below glideslope. 
If you clamp the values, this information is lost for the instrument.

Cheers, Torsten

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] navradio

[Atadjanov Daniyar]

08.09.09, 21:47, "James Turner" :

> BTW, for NDBs, FlightGear *should* be picking the closest NDB with the  
> matching frequency - exactly as MSFS. If that's not what you're  
> seeing, that's a bug, and likely my fault. Please let me know a  
> suitable test location and NDB frequencies / idents to reproduce the  
> problem, and I'll take a look.

Hi, James.

Just tested NDB freqs "problem" - everything work good. Sorry for panic.

Daniyar


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Compiling newest CVS FlightGear/SimGear Error in props.hxx

[Randall Green]

I'm trying to compile the newest CVS FlightGear/SimGear and I get the following 
long winded error
message. When I click on it, it takes me to:
private:
T_obj
in props.hxx. Anyone have this problem?
Thanks,
Randy Green
2>c:\fg2\simgear\simgear\props\props.hxx(666) : error C2079: 
'SGRawValueContainer::_obj' uses undefined class 'SGVec3'
2>with
1>Build log was saved at 
"file://c:\FG2\FlightGear\projects\VC90\terrasync\Win32\Debug\BuildLog.htm"
2>[
2>T=SGVec3d
2>]
2>and
2>[
2>T=double
2>]
1>terrasync - 1 error(s), 0 warning(s)
2>c:\fg2\simgear\simgear\props\props.hxx(672) : see reference to class 
template instantiation 'SGRawValueContainer' being compiled
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(671) : while compiling class 
template member function 'SGRawExtended *SGRawBase::makeContainer(void) 
const'
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(692) : see reference to class 
template instantiation 'SGRawBase' being compiled
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(685) : error C2079: 'value' uses 
undefined class 'SGVec3'
2>with
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(684) : while compiling class 
template member function 'std::istream &SGRawBase::readFrom(std::istream &)'
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(687) : error C2664: 
'SGRawValue::setValue' : cannot convert parameter 1 from 'int' to 'SGVec3d'
2>with
2>[
2>T=SGVec3d
2>]
2>Source or target has incomplete type
2>c:\fg2\simgear\simgear\props\props.hxx(666) : error C2079: 
'SGRawValueContainer::_obj' uses undefined class 'SGVec4'
2>with
2>[
2>T=SGVec4d
2>]
2>and
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(672) : see reference to class 
template instantiation 'SGRawValueContainer' being compiled
2>with
2>[
2>T=SGVec4d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(671) : while compiling class 
template member function 'SGRawExtended *SGRawBase::makeContainer(void) 
const'
2>with
2>[
2>T=SGVec4d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(694) : see reference to class 
template instantiation 'SGRawBase' being compiled
2>with
2>[
2>T=SGVec4d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(685) : error C2079: 'value' uses 
undefined class 'SGVec4'
2>with
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(684) : while compiling class 
template member function 'std::istream &SGRawBase::readFrom(std::istream &)'
2>with
2>[
2>T=SGVec4d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(687) : error C2664: 
'SGRawValue::setValue' : cannot convert parameter 1 from 'int' to 'SGVec4d'
2>with
2>[
2>T=SGVec4d
2>]
2>Source or target has incomplete type
2>beacon.cxx
3>-- Build started: Project: fgviewer, Configuration: Debug Win32 --
3>Linking...
2>c:\fg2\simgear\simgear\props\props.hxx(666) : error C2079: 
'SGRawValueContainer::_obj' uses undefined class 'SGVec3'
2>with
2>[
2>T=SGVec3d
2>]
2>and
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(672) : see reference to class 
template instantiation 'SGRawValueContainer' being compiled
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(671) : while compiling class 
template member function 'SGRawExtended *SGRawBase::makeContainer(void) 
const'
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(692) : see reference to class 
template instantiation 'SGRawBase' being compiled
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(685) : error C2079: 'value' uses 
undefined class 'SGVec3'
2>with
2>[
2>T=double
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(684) : while compiling class 
template member function 'std::istream &SGRawBase::readFrom(std::istream &)'
2>with
2>[
2>T=SGVec3d
2>]
2>c:\fg2\simgear\simgear\props\props.hxx(687) : error C2664: 
'SGRawValue::setValue' : cannot convert parameter 1 from 'int' to 'SGVec3d'
2>with
2>[
2>T=SGVec3d
2>]
2>Source or target has incomplete type
2>c:\fg2\simgear\simgear\props\props.hxx(666) : error C

Re: [Flightgear-devel] Patches for configure.ac/Makeifle.am in SG/FG

[Torsten Dreyer]

> Hi,
>
> I've updated the patches for configure.ac and Makefile.am files in FG/SG so
> Mac developers can build these in a unix way. These also enables Mac
> developers to choose either PLIB framework or PLIB static libs.
>
> The patches work fine on my Mac, and I want linux users to check if these
> also work OK. This update includes the changes to generic input device so
> it can be built under both Linux and Mac. Please let me know if there are
> any problems.
>
> Torsten,
> Could you check if the change to configure.ac and src/{Input,
> Main}/Makefile.am work on Linux regarding to generic input? If everything
> works fine, please commit these patches for me.
>
>
> Best,
>
> Tat

Hi Tat,

I'll have a look at your changes, but probably not before the weekend.
Hope you can wait that long ;-)

Greetings, Torsten

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[John Denker]

On 09/09/09 06:16, Tim Moore wrote:

>>> Yes, the 2009 code is different from the 2007 code.
>>> The 2009 features and bugfixes are a superset of the
>>> 2007 features and bugfixes.  Also the 2009 commits
>>> were rebased so that they applied cleanly to the FGFS
>>> release that was current at the time.
>>>
>> That's great! What's the url for the repository that has these changes?
>> Unless I'm doing something wrong, it seems like 
>> http://www.av8n.com/repo/fgs/.git
>> and http://www.av8n.com/repo/sg/.git haven't been updated in some
>> time.

I updated that site just now.  I had stopped using 
it more than two years ago, because it is just a
fileserver (lots of network connectivity, without
much CPU capacity) ... meaning it didn't support
gitweb.  I thought it would be more convenient
for folks to evaluate my patches if I put my FGFS
stuff on a gitweb-enabled host.  It turned out it 
didn't make much difference.  James Turner looked 
at a couple of my patches using gitweb, but the 
only folks who actually downloaded and tested the 
patches were folks without commit authority.  My 
FGFS gitweb host died a while back.  I didn't 
bother to replace it, since it wasn't seeing any
traffic.

Consider the following two lists:
A) 
 -- nice looking livery
 -- nice looking vegetation
 -- nice looking panel layout
 -- et cetera

B)
 -- realistic localizer
 -- realistic glideslope
 -- realistic DME
 -- realistic status flags
 -- realistic IDENT
 -- realistic altimeter and atmosphere
 -- realistic ATIS
 -- et cetera

For the vast majority of FGFS users, the things on 
list (A) are important.  Things on list (B) don't 
matter at all.  They are harmless but irrelevant.

In contrast, real-world instrument flying demands 
close attention to things on list (B).  Things on 
list (A) don't matter at all.  They are harmless
but irrelevant, unless they impair the frame rate;
you can't see the vegetation at night, or when you 
are solid in cloud.

Everybody agrees that features on list (B) would be
nice to have, but years of experience indicate that
nobody with commit authority is interested in working
on such things.  

To some extent this is a chicken-and-egg situation.
So long as FGFS emphasizes gamer features  (list A)
it will attract gamers as users.  If/when FGFS
implements pilot features  (list B) it will attract
pilots as users.

I emphasize that it is _not necessary_ to choose 
between gamer features and pilot features.  FGFS
should implement both.  There is no reason not to.

I guarantee you that a gamer who did not notice the
absence of a working status flag will not notice
the presence of a working status flag.

Everybody says these features are "great".  If 
somebody wants these features enough to actually 
allow them to be committed, please say so.


On 09/09/09 07:08, James Turner wrote:
>>> Yes, the 2009 code is different from the 2007 code.
>>> The 2009 features and bugfixes are a superset of the
>>> 2007 features and bugfixes.  Also the 2009 commits
>>> were rebased so that they applied cleanly to the FGFS
>>> release that was current at the time.

> With apologies, I should note that my recent re-factoring work in  
> navradio will likely mean these patches do not apply cleanly to  
> current trunk.

That's ironic.  If the aforementioned patches had 
been applied back in January 2009, many of the "new" 
features (such as normalized outputs) would already 
be in place and well tested.
 
> My issue back in January was, and remains, that I don't feel qualified  
> to commit major functional changes to the radio code, since radio  
> modelling is far from my areas of expertise. That's not meant as an  
> obstacle to incorporating any particular change or bug-fix 

I'm glad to hear it was not intended as an obstacle.
On this list I've heard lots of euphemisms for "none 
of your code is going to be committed" but at the 
end of the day they all mean "none of your code is 
going to be committed".

Are not the recent changes "major" changes?  Changing 
the semantics of the outputs, so as to a require a
change in every instrument ... that seems kinda major
to me.

I still think it is a Bad Idea to change navradio.cxx
in such a way as to change the semantics of the existing
outputs.  I recommend leaving the existing outputs alone,
and simply _adding_ whatever normalized outputs are 
desired, under new names.  This preserves 100% backward 
compatibility, so that panel designers are free to update 
their instruments _or not_, if/when/however they please.  
This is how my code handled things back in January 2009.

If you really want to rip out the old outputs, in the
name of "internal cleanliness" or whatever, that can wait 
a year or two.  It is always wise to look at things from
the users' point of view.  Users care about bugs they
can see and features they can see.  If/when "internal
cleanliness" contributes to reliability, that's fine,
but in this case it makes a negative contribution.  At
the very least, it distract

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[James Turner]

On 9 Sep 2009, at 17:04, dave perry wrote:

> I have updated  and tested the vor.xml, vor2.xml in Instruments-3D/vor
> as well as the century3.nas in Aircraft/Generic and the corresponding
> PID controllers.  I will do the same for the AltimaticIIIC used in the
> SenecaII as I wrote the CenturyIII and AltimaticIIIC nasal and PID's
> which are very similar to the CenturyIII.  I think we will have to
> change all the nasal GS arm entries.

I agree, sadly. For some devices it's clear what arming sensitivity is  
used (eg the KAP-140 manual says '2 to 3 dots') but for others I'm  
having to make a sensible guess.

> I also am familiar with the kap140
> nasal, so I will update that also.  I have found that the parameters  
> in
> the PID controllers need to be optimised for each aircraft as the  
> plant
> changes with a change in flight model optimisation.  I am not using  
> the
> normalized property.  This made increasing the proportional gain  
>  by
> 5x a very good starting point for re-optimization.  I will re-optimize
> the Cessna 172 PID file.

Okay - I don't have a strong feeling on whether using the normalised  
or degree property is more readable / understandable / maintainable in  
Nasal scripts or autopilot gains - for the KAP-140 arm logic I used  
the -norm property and a 50% threshold (i.e 2.5 dots), but that's  
partly because I wanted to test and commit now, and don't want to edit  
the files again when I remove the 5x factor (see your second email)

I'm going to do the big jets (777, 747, 787, the airbuses, and  
Concorde) next. The b1900 is also mostly done, I just want to test the  
autopilot more before committing.

James

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[James Turner]

On 9 Sep 2009, at 17:22, dave perry wrote:

>> - secondly, I'm changing (or will) the glideslope deviation to be
>> 'correct' degrees: [-0.7 .. 0.7], i.e removing the spurious 5x scalar
>> that has somehow crept in, and fixing many clients which assumed the
>> range was [-10 .. 10], or something else again. This is in keeping
>> with your flight instructor, I believe.
>>
> I just looked at the latest navradio.cxx in CVS.  You added the
> normalised _gsNeedleDeflectionNorm
> but did not remove the 5x from
> _gsNeedleDeflection.
>
> This is to avoid breaking the clients that have not been updated,  
> right?
>
> Am I safe to assume that once most of the client updates are done, the
> 5x will be removed.  That is, is it OK to do the nas and xml updates  
> and
> optimisation using degrees and not the normalized values.

Correct - I want to wait another couple of days before removing the 5x  
hack, because once I do, every existing aircraft will definitely be  
wrong. Since it seems that most of the animation nodes are easier  
fixed by using the -norm property, I can safely update those now  
without upsetting anyone.



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[dave perry]

James Turner wrote:
> - secondly, I'm changing (or will) the glideslope deviation to be  
> 'correct' degrees: [-0.7 .. 0.7], i.e removing the spurious 5x scalar  
> that has somehow crept in, and fixing many clients which assumed the  
> range was [-10 .. 10], or something else again. This is in keeping  
> with your flight instructor, I believe.
>   
I just looked at the latest navradio.cxx in CVS.  You added the 
normalised _gsNeedleDeflectionNorm
but did not remove the 5x from
_gsNeedleDeflection.

This is to avoid breaking the clients that have not been updated, right?

Am I safe to assume that once most of the client updates are done, the 
5x will be removed.  That is, is it OK to do the nas and xml updates and 
optimisation using degrees and not the normalized values.

Dave P


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[dave perry]

James Turner wrote:
> On 9 Sep 2009, at 03:01, dave perry wrote:
>
>   
>> Sorry, I misunderstood you concerning the animation edits.  I will be
>> glad to help with the xml edits and testing.  Getting rid of the
>> spurious 5x for the glide scope and adding the clamps is a good idea  
>> and
>> adding the normalized CDI and GS could make the animators job  
>> easier.  I
>> will start by changing the vor.xml and vor2.xml in Instruments-3D that
>> are used in the pa24 and pa28 and perhaps several other AC.
>> 
>
> I've already changed various aircraft locally, for testing:
>
>   - the generic 2D and 3D instruments
>   - the Seneca, B1900d, 747-400, C172P and Aerostar
>   - the Primus-1000 suite
>
> I don't claim to have done this 100% correctly yet - especially, I  
> need to convince myself the that GS-ARM modes of the various  
> autopilots (eg, the KAP-140 in the default C172) are behaving  
> correctly, since this is generally implemented as Nasal scripts  
> testing the GS needle deflection.
>
> One area I do need help with is the autopilot PID laws: eg, here's the  
> relevant chunk for the B1900d:
>
> 
>   Glideslop Hold
>   
>   instrumentation/nav/gs-needle-deflection-norm
>   
>   
>   0
>   
>   
>   autopilot/settings/target-pitch-deg
>   
>   
>   -1.5
>   1.0
>   0.1
>   0.0
>   10.0
>   0.0
>   
>   -10
>   
>   
>   5
>   
>   
> 
>
> Since I've switched the input to be the normalised prop, we've gone  
> from a unclamped input (swinging from sometimes -60 to 60!) to one  
> which is much 'smaller' in magnitude and clamped to [-1 .. 1]. I  
> *guess* the fix will be to increase the gain on the PID, otherwise GS  
> hold will tend to lag, but that's about the total of my knowledge of  
> tweaking the PIDs.
>
>
>   
I have updated  and tested the vor.xml, vor2.xml in Instruments-3D/vor 
as well as the century3.nas in Aircraft/Generic and the corresponding 
PID controllers.  I will do the same for the AltimaticIIIC used in the 
SenecaII as I wrote the CenturyIII and AltimaticIIIC nasal and PID's 
which are very similar to the CenturyIII.  I think we will have to 
change all the nasal GS arm entries.  I also am familiar with the kap140 
nasal, so I will update that also.  I have found that the parameters in 
the PID controllers need to be optimised for each aircraft as the plant 
changes with a change in flight model optimisation.  I am not using the 
normalized property.  This made increasing the proportional gain  by 
5x a very good starting point for re-optimization.  I will re-optimize 
the Cessna 172 PID file.

None of the above has been committed to CVS.  Shall I send the diffs to 
you James for committing.

Dave P

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Patches for configure.ac/Makeifle.am in SG/FG

[Tatsuhiro Nishioka]

Hi,

I've updated the patches for configure.ac and Makefile.am files in FG/SG so Mac 
developers can build these in a unix way.
These also enables Mac developers to choose either PLIB framework or PLIB 
static libs.

The patches work fine on my Mac, and I want linux users to check if these also 
work OK.
This update includes the changes to generic input device so it can be built 
under both Linux and Mac.
Please let me know if there are any problems.

Torsten, 
Could you check if the change to configure.ac and src/{Input, Main}/Makefile.am 
work on Linux regarding to generic input?
If everything works fine, please commit these patches for me.


Best,

Tat



flightgear-configure.diff
Description: Binary data




simgear-configure.diff
Description: Binary data

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[James Turner]

On 9 Sep 2009, at 14:16, Tim Moore wrote:

>> Yes, the 2009 code is different from the 2007 code.
>> The 2009 features and bugfixes are a superset of the
>> 2007 features and bugfixes.  Also the 2009 commits
>> were rebased so that they applied cleanly to the FGFS
>> release that was current at the time.
>>
> That's great! What's the url for the repository that has these  
> changes?
> Unless I'm doing something wrong, it seems like 
> http://www.av8n.com/repo/fgs/.git
> and http://www.av8n.com/repo/sg/.git haven't been updated in some
> time.

With apologies, I should note that my recent re-factoring work in  
navradio will likely mean these patches do not apply cleanly to  
current trunk.

My issue back in January was, and remains, that I don't feel qualified  
to commit major functional changes to the radio code, since radio  
modelling is far from my areas of expertise. That's not meant as an  
obstacle to incorporating any particular change or bug-fix - simply  
that either I need to be able to convince myself that a specific  
change is correct (which generally means it needs to be pretty small,  
targeting a single bug or feature). Otherwise, I'll leave any  
functional changes to to others.

In general I'd be much more comfortable with a series (even if it's  
20) of smaller changes to the code, with some time for testing and  
settling of the code between each batch.

That said, I would also love to see an improved LOC/GS reception model  
(false lobes, back courses, etc).

Hopefully, with the fixes to the aircraft I'm currently making, one  
area of confusion will disappear from the equation, and the focus can  
be on generating 'good' values for the sim properties.

Regards,
James

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[Tim Moore]

On 09/09/2009 02:57 PM, John Denker wrote:
> On 09/08/09 23:10, Tim Moore wrote:
> 
>> Is this different from this commit in sportmodel?:
>> commit 77a6f88082a74e3187268c9fde4cee49539cae43
>> Author: John Denker 
>> Date:   Sun Jun 24 19:11:34 2007 -0400
>>
>> Fix the azimuthal dependence of localizer service volume ...
>> false localizer courses and all that.
>> Not yet perfect, but waaay better than no azimuth-dependence,
> 
> 
> Yes, the 2009 code is different from the 2007 code.
> The 2009 features and bugfixes are a superset of the
> 2007 features and bugfixes.  Also the 2009 commits
> were rebased so that they applied cleanly to the FGFS
> release that was current at the time.
> 
That's great! What's the url for the repository that has these changes?
Unless I'm doing something wrong, it seems like 
http://www.av8n.com/repo/fgs/.git
and http://www.av8n.com/repo/sg/.git haven't been updated in some
time.

> Specifically I am referring to commits such as:
> 
> commit 85733b769251aca1c2e8cb0f70c723180d6b24f7
> Author: John Denker 
> Date:   Sun Jan 11 15:47:43 2009 -0700
> 
> Localizer sensitivity depends on runway;
> false LOC courses; LOC extended service volume,
> false glideslopes, proper GS flag
> 
> commit f14f10d642d478d922f9eb6cb7af4ef54d37420e
> Author: John Denker 
> Date:   Sun Jan 11 15:50:19 2009 -0700
> 
> Fix ADF bugs ... including still driving the needle when power off.
> 
> commit c5d29402fae8b63bf5922ef3609b10cb3ef85622
> Author: John Denker 
> Date:   Sun Jan 11 15:57:30 2009 -0700
> 
> Many fixes to navradio.cxx:
> Localizer sensitivity depends on runway length as it should.
> Localizer range varies from place to place as specified in nav.dat
> Localizer has appropriate false localizer courses.
> Glideslope range varies from place to place as specified in nav.dat
> Glideslope has appropriate false glideslope signals.
> Glideslope "inrange" flag distinct from localizer "inrange" flag.
> GS needle parks where specified, not necessarily at mid-scale.
> 
> commit 0b6990bba43b2298ebede9225c1fd48f74fa4a7a
> Author: John Denker 
> Date:   Sun Jan 11 15:58:27 2009 -0700
> 
> Better calculation of glideslope, using projection operators.
> Gets rid of various bugs including asin(1.001) bugs.
> 
> commit e67d9c9ae1dce21e030f3d84a317a22487833bc6
> Author: John Denker 
> Date:   Mon Jan 12 03:29:29 2009 -0700
> 
> When selecting a VOR, NDB, or fix by name, prefer the one
> nearest a given position.  Specify position on command-line
> via --vicinity=airport or --vicinity=lat,lon.
> 
> commit be90d4f1b1145c21bd1c07b86a04d49271e7ad48
> Author: John Denker 
> Date:   Wed Jan 28 12:43:13 2009 -0700
> 
> navradio:  fix various range and IDENT bugs, including DME IDENT.
> 
> 
> 
> 
> et cetera.
> 
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> 


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[John Denker]

On 09/08/09 23:10, Tim Moore wrote:

> Is this different from this commit in sportmodel?:
> commit 77a6f88082a74e3187268c9fde4cee49539cae43
> Author: John Denker 
> Date:   Sun Jun 24 19:11:34 2007 -0400
> 
> Fix the azimuthal dependence of localizer service volume ...
> false localizer courses and all that.
> Not yet perfect, but waaay better than no azimuth-dependence,


Yes, the 2009 code is different from the 2007 code.
The 2009 features and bugfixes are a superset of the
2007 features and bugfixes.  Also the 2009 commits
were rebased so that they applied cleanly to the FGFS
release that was current at the time.

Specifically I am referring to commits such as:

commit 85733b769251aca1c2e8cb0f70c723180d6b24f7
Author: John Denker 
Date:   Sun Jan 11 15:47:43 2009 -0700

Localizer sensitivity depends on runway;
false LOC courses; LOC extended service volume,
false glideslopes, proper GS flag

commit f14f10d642d478d922f9eb6cb7af4ef54d37420e
Author: John Denker 
Date:   Sun Jan 11 15:50:19 2009 -0700

Fix ADF bugs ... including still driving the needle when power off.

commit c5d29402fae8b63bf5922ef3609b10cb3ef85622
Author: John Denker 
Date:   Sun Jan 11 15:57:30 2009 -0700

Many fixes to navradio.cxx:
Localizer sensitivity depends on runway length as it should.
Localizer range varies from place to place as specified in nav.dat
Localizer has appropriate false localizer courses.
Glideslope range varies from place to place as specified in nav.dat
Glideslope has appropriate false glideslope signals.
Glideslope "inrange" flag distinct from localizer "inrange" flag.
GS needle parks where specified, not necessarily at mid-scale.

commit 0b6990bba43b2298ebede9225c1fd48f74fa4a7a
Author: John Denker 
Date:   Sun Jan 11 15:58:27 2009 -0700

Better calculation of glideslope, using projection operators.
Gets rid of various bugs including asin(1.001) bugs.

commit e67d9c9ae1dce21e030f3d84a317a22487833bc6
Author: John Denker 
Date:   Mon Jan 12 03:29:29 2009 -0700

When selecting a VOR, NDB, or fix by name, prefer the one
nearest a given position.  Specify position on command-line
via --vicinity=airport or --vicinity=lat,lon.

commit be90d4f1b1145c21bd1c07b86a04d49271e7ad48
Author: John Denker 
Date:   Wed Jan 28 12:43:13 2009 -0700

navradio:  fix various range and IDENT bugs, including DME IDENT.




et cetera.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers

[James Turner]

On 9 Sep 2009, at 03:01, dave perry wrote:

> Sorry, I misunderstood you concerning the animation edits.  I will be
> glad to help with the xml edits and testing.  Getting rid of the
> spurious 5x for the glide scope and adding the clamps is a good idea  
> and
> adding the normalized CDI and GS could make the animators job  
> easier.  I
> will start by changing the vor.xml and vor2.xml in Instruments-3D that
> are used in the pa24 and pa28 and perhaps several other AC.

I've already changed various aircraft locally, for testing:

- the generic 2D and 3D instruments
- the Seneca, B1900d, 747-400, C172P and Aerostar
- the Primus-1000 suite

I don't claim to have done this 100% correctly yet - especially, I  
need to convince myself the that GS-ARM modes of the various  
autopilots (eg, the KAP-140 in the default C172) are behaving  
correctly, since this is generally implemented as Nasal scripts  
testing the GS needle deflection.

One area I do need help with is the autopilot PID laws: eg, here's the  
relevant chunk for the B1900d:


Glideslop Hold

instrumentation/nav/gs-needle-deflection-norm


0


autopilot/settings/target-pitch-deg


-1.5
1.0
0.1
0.0
10.0
0.0

-10


5




Since I've switched the input to be the normalised prop, we've gone  
from a unclamped input (swinging from sometimes -60 to 60!) to one  
which is much 'smaller' in magnitude and clamped to [-1 .. 1]. I  
*guess* the fix will be to increase the gain on the PID, otherwise GS  
hold will tend to lag, but that's about the total of my knowledge of  
tweaking the PIDs.


James

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel