* 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 01/28/2007 05:12 AM, Melchior FRANZ wrote:
> I would, for example, have felt responsible for your
> location-in-air dialog, as I had worked a lot on GUI matters.
> There were reasons why I didn't pick it up: (1) I wasn't at
> my computer at that time.
Please check again the next time you are
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.
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 090 radial.
2) If we were outbound from the field, I would
28 matches
Mail list logo
