Lee wrote

> Sent: 19 March 2008 11:43
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] New problem with submodels
> 
> 
> On Wednesday 19 March 2008 11:05, Vivian Meazza wrote:
> > Lee wrote:
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] 
> On Behalf Of 
> > > LeeE
> > > Sent: 13 March 2008 14:06
> > > To: FlightGear developers discussions
> > > Subject: Re: [Flightgear-devel] New problem with submodels
> > >
> > >
> > > On Thursday 13 March 2008 08:12, Vivian Meazza wrote: [snip...]
> > >
> > > > > > In theory nothing has been changed in submodels in a long 
> > > > > > time, and <aero-stabilised> remains a bool. However I have
> > >
> > > been making
> > >
> > > > > > changes in AIBallistic, so the problem probably lies there, 
> > > > > > and I'm investigating. I can sort of reproduce your bug,
> > >
> > > but here all
> > >
> > > > > > the submodels behave in the same way. If they don't 
> then it is 
> > > > > > possible that you haven't enabled AI Models.
> > > > > >
> > > > > > Vivian
> > > > >
> > > > > Hmm...  I have
> > > > >
> > > > > --prop:sim/ai-traffic/enabled=true
> > > > > --prop:sim/ai-traffic/level=3
> > > > >
> > > > > and
> > > > >
> > > > > --disable-random-objects
> > > > >
> > > > > in my .fgfsrc but they are the only AI related things I
> > >
> > > specifically
> > >
> > > > > set, and disabling the random objects is probably irrelevant 
> > > > > here.
> > > > >
> > > > > Actually, I haven't updated from FG cvs since mid
> > >
> > > February, so this
> > >
> > > > > problem dates from before then.  I'm also pretty sure the 
> > > > > problem wasn't apparent around early/mid December 
> 2008 because I 
> > > > > remember using trajectory markers while I was working 
> on the TFA 
> > > > > stuff for the BAC-TSR2 and I sent the resulting 
> update to Curt 
> > > > > on
> > >
> > > 2008-12-17.
> > >
> > > > > After some more testing last night, I have to revise 
> the ratio 
> > > > > of affected instances to ones that show the problem - 
> far more 
> > > > > instances _are_ affected than work correctly.  I'd now guess 
> > > > > that somewhere around nine out of ten instances are showing
> > >
> > > this strange
> > >
> > > > > behaviour, but there still doesn't appear to be a discernible 
> > > > > pattern.
> > > > >
> > > > > LeeE
> > > >
> > > > You need  --enable-ai-models. Without this you will see 
> > > > AIBallistic stuff, but they won't move correctly.
> > > >
> > > > I think there _is_ bug, but not quite the one you 
> describe. If you 
> > > > could just try again with the correct settings, and let me
> > >
> > > know what
> > >
> > > > you observe.
> > > >
> > > > V.
> > >
> > > I just went to try this and found that I'm already supplying 
> > > --enable-ai-models on the command line:(
> > >
> > > Sorry - I should have checked there as well.  I just use bash 
> > > history to call up my FG start command and thought I only 
> had stuff 
> > > that I change regularly included in it.
> >
> > OK - I've found the bug - the submodels are aligning to a 
> non-existent 
> > external force, because I failed to initialise the value, 
> trivial to 
> > fix. That's the good news. The bad news is that this fix 
> has got mixed 
> > up here with Till Busch's excellent scenery etc. paging 
> patch (which I 
> > recommended highly, and for which more testers are needed), 
> and which 
> > is mixed up with an extensive improvement to the 
> air-to-ground radar. 
> > I hope you can bear with us until we get it all sorted.
> >
> > Meanwhile, the terrain warning stuff has finally reached cvs-head.  
> > While I was about it, I added a more realistic rad alt (the terrain 
> > warning radar tilted through 90 degrees). An example of the use of 
> > these are to be found in the Buccaneer. I hope that you can 
> make some 
> > use of this lot.
> >
> > Hang on - it will get better.
> >
> > Vivian
> >
> > P.S. it all works here - I thought you would like to know that
> > :-)
> 
> Many thanks for looking into it and even more for finding the 
> cause:)
> 
> NP re waiting for it to be fixed - the trajectory markers aren't 
> essential - just useful.
> 
> Re the ground radar/terain warning stuff: I noticed it going through 
> on cvs-logs - is this a development of the ai ballistic sub-model 
> based solution?  I've been busy with the YF-23 update (and a 
> hypothetical drone version) so I haven't had a chance to look into 
> and play with it yet.
> 

No - this is an extension of the weather radar. I've based in pretty closely
on the Blue Parrot radar in the Bucc, but all the parameters are settable.
The 'radar' has a simulated beam width, scan period, and is stabilised in
roll (like the real one). There are a couple of compromises - the horizon is
the visual, not radar horizon, and only terrain is detected, not models on
the terrain. This latter is due to problems with the node masks, which we
are trying to fix, the former - I'm thinking about :-). 

The rad alt also simulates the one in the Bucc - it too has a beam width,
and is fixed in pitch, roll, and heading. Thus errors are introduced if the
ac is rolled too far. Otherwise it shares the same problems as the Terrain
Warning radar (as I said - it's just the terrain warning radar turned though
90 degrees). 

Provided you don't go mad with beam width and scan rates this is all pretty
much free of fps cost. The next step is a surveillance mode which detects
and displays the ground returns - working here, but all tangled up with
other goodies.

We're getting there :-)

Vivian



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to