* John Denker -- Sunday 28 January 2007:
> I took the long comments out of location-in-air.xml and moved
> them to
>http://www.av8n.com/fly/fgfs/README.location-in-air
Reviewed and rejected. This contains rather bad code and needs
some serious reworking. It even replaces existing good code
wit
* John Denker -- Sunday 28 January 2007:
>http://www.av8n.com/fly/fgfs/location-in-air.xml.diff
+# We need our own private variables, to have and to hold,
+# without worrying about whether the FDM will mess with
+# them. A subset of these will be copied to FDM variables
+# with similar names.
On Sat, 6 Jan 2007, Martin Spott wrote:
> "Jon S. Berndt" wrote:
>
>> First, which version of JSBSim are you using? From what I understand, Erik
>> just put a new version of JSBSim in FlightGear CVS.
>
> Erik committed the JSBSim update only to the pre-OSG branch - which is
> actually of limited u
> On 01/06/2007 04:25 PM, Jon S. Berndt wrote:
>
> > I'm not sure what you are talking about here. Could you be more
> descriptive?
>
> I'll try!
I'm going to forward this to the JSBSim list. Then I'm off for the day.
Jon
--
On 01/07/2007 01:25 PM, Martin Spott wrote:
>>[...] For my purposes (and
>>I suspect a lot of other purposes besides), is much more useful
>>to be able to warp to some improvised place, without ever having
>>been there before.
>
>
> Without ever having been there before I'd say you'll never know
John Denker wrote:
> [...] For my purposes (and
> I suspect a lot of other purposes besides), is much more useful
> to be able to warp to some improvised place, without ever having
> been there before.
Without ever having been there before I'd say you'll never know in
which state the aircraft is
"Jon S. Berndt" wrote:
> > John, actually, what you're looking for is a routine that allows you to
> > dump the whole property tree at runtime into a file and allow
> > re-loading this as a preset. In order not to break current behaviour it
> > would be necessary to compile a 'standard-preset' fil
> John Denker wrote:
>
> [... reset function ...]
> > All evidence indicates that the function being called was not designed
> > to be used this way, i.e. not to be used in flight and not to be used
> > repeatedly. Instead it was supposed to be used once, during initial
> > startup.
>
> John, actu
On 01/07/2007 12:28 PM, Martin Spott wrote:
> John, actually, what you're looking for is a routine that allows you to
> dump the whole property tree at runtime into a file and allow
> re-loading this as a preset. In order not to break current behaviour it
> would be necessary to compile a 'standar
John Denker wrote:
[... reset function ...]
> All evidence indicates that the function being called was not designed
> to be used this way, i.e. not to be used in flight and not to be used
> repeatedly. Instead it was supposed to be used once, during initial
> startup.
John, actually, what you'r
On 01/06/2007 04:25 PM, Jon S. Berndt wrote:
> I'm not sure what you are talking about here. Could you be more descriptive?
I'll try!
Let's start with some "use case" analysis:
Scenario 1: User wants to practice landings. Using command-line options,
the user initializes the system to 4 mile f
--- John Denker wrote:
> On 01/06/2007 04:46 PM, Stuart Buchanan wrote:
>
> > Thanks for the contribution.
>
> :-)
>
> > 1) The runway specification is missing.
>
> Fixed.
Thanks for that. It probably represents the feature that I've used most
myself in the dialog.
> > 5) Your comments ar
On 01/06/2007 04:46 PM, Stuart Buchanan wrote:
> Thanks for the contribution.
:-)
> 1) The runway specification is missing.
Fixed.
> 2) Title isn't consistent with the menu item. I suggest changing it back
> to "Location In Air".
OK. Done.
> 3) For consistency with the other menu items, yo
"Jon S. Berndt" wrote:
> First, which version of JSBSim are you using? From what I understand, Erik
> just put a new version of JSBSim in FlightGear CVS.
Erik committed the JSBSim update only to the pre-OSG branch - which is
actually of limited use for current development :-/
Martin.
--
--- John Denker wrote:
> Hi --
>
> I have extensively reworked the location-in-air.xml popup.
>
> It is now much more pilot-friendly.
>
> > I would appreciated if other folks would play with it
> and provide feedback.
Apart from one major omission, it is certainly an improvement over
> ## Known bugs:
> ## *) Apparently the reset routine refuses to
> ## apply an offset if the reference point is a lat/lon.
> ## Maybe we could work around this ... or we could just
> ## beseech the FDM authors to fix it on their end.
> ## This is broken both in jsbsim and larcsim.
I'm not
Hi --
I have extensively reworked the location-in-air.xml popup.
It is now much more pilot-friendly.
> I would appreciated if other folks would play with it
and provide feedback.
The latest & greatest version is at
http://www.av8n.com/fly/fgfs/location-in-air.xml
there is also a diff
On 01/05/2007 04:06 AM, Torsten Dreyer wrote:
> Less dirty and more correct should be:
> relocate to the position of the fix, grab the magnetic variation and
> calculate
> the transporter coordinates using bearing and distance. Relocate again to
> these coordinates. You can safely call this pos
> A dirty hack might be to relocate to the new position using the true
> bearing, reading the magnetic-variation property for the new position
> thereafter and relocate again using the new variation.
Less dirty and more correct should be:
relocate to the position of the fix, grab the magnetic vari
On Wed, 3 Jan 2007, John Denker wrote:
*) I spelled out "deg". I tried putting the ° symbol in the
xml file, but it complained of a parse error. Using °
didn't work, either. Any suggestions on how to encode symbols?
Not directly an answer to you question but here's a tip that may be us
> That's a good point. I consider it a bug in what I've written.
> The canonical behavior is to use the magnetic deviation at the
> /reference/ point. Can somebody give me a hint how to obtain
> the deviation at the location of arbitrary navaids and airports?
The magnetic variation is calculated
On Wed, 2007-01-03 at 15:36 -0500, John Denker wrote:
> First, some background information. Suppose we are up in the air,
> 10 nm west of KXYZ airfield (which is colocated with the XYZ vortac).
> 1) If we were inbound to the field, I would report our position
> as 10 nm west, inbound on the
I found a way to make it do what I want. Here's my version
http://www.av8n.com/fly/fgfs/location-in-air.xml
and the diff against the cvs version:
http://www.av8n.com/fly/fgfs/location-in-air.diff
On 01/03/2007 05:19 PM, Curtis Olson wrote:
> Only if you are relocating to a nearby position.
On 1/3/07, John Denker <[EMAIL PROTECTED]> wrote:
I'm coming at this from the perspective of an instrument flying
lesson. Being able to reposition the aircraft a few miles from
the initial approach fix saves a lot of time.
And that is a perspective we fully want to support and promote .
Th
On 01/03/2007 04:00 PM, Curtis Olson wrote:
> we do want this to work intuitively so I would welcome
> any changes to improve the in-air reposition dialog box.
:-)
> I think it makes a lot
> more sense to focus on the gui dialog box.
Agreed.
I'm coming at this from the perspective of an instr
On 1/3/07, John Denker <[EMAIL PROTECTED]> wrote:
First, some background information. Suppose we are up in the air,
10 nm west of KXYZ airfield (which is colocated with the XYZ vortac).
[snip]
To summarize: With rare exceptions, locations are specified using the
bearing /from/ the reference.
26 matches
Mail list logo
