On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote:
If so, seems like we're kind of shooting ourselves in the foot or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
This is a good discussion to start. I'm inclined to eliminate tying
James Turner wrote:
Basically, I can envisage lots of things the ChangeListener API is
perfect for, whether you're observing a value that changes one a week or
50 times a second, but right now those things won't work because some %
of the properties don't tell you they've changed. Now, we
Erik Hofman wrote :
James Turner wrote:
Basically, I can envisage lots of things the ChangeListener API is
perfect for, whether you're observing a value that changes one a week or
50 times a second, but right now those things won't work because some %
of the properties don't tell you
On Thursday, February 6, 2003, at 10:16 am, Frederic BOUVIER wrote:
Aren't the C++ opperators the perfect place to add this kind of action
to tied properties?
I had the same idea reading the message from James.
imagine that template (we are not against templates, aren't we ? ;) :
template
James Turner wrote :
The impression I have is that a bunch of code uses 'tieing' to expose
lots of internal variables directly. I'd prefer an explicit
'publishing' phase, i.e calls to setValue. Of course your template
works fine too, if you're prefer the syntactic sugar.
I see your (rather
These errors are fixed in the latest CVS -
change
typedef list TowerPlaneRec* tower_plane_rec_list_type;
typedef list TowerPlaneRec* ::iterator tower_plane_rec_list_iterator;
typedef list TowerPlaneRec* ::const_iterator
tower_plane_rec_list_const_iterator;
to
typedef list TowerPlaneRec*
James Turner wrote :
I do, but this is not the problem (as I understand it). The tie-ing
system is 'low-invasion' for existing code / code which may not be part
of FG, and works well with existing state variables. Your template /
operator overloading fix the syntax, but I sort of think that's
On Thu, 2003-02-06 at 01:09, James Turner wrote:
On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote:
excerptexcerptIf so, seems like we're kind of shooting ourselves
in the foot or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
Tony Peden writes:
This is a good discussion to start. I'm inclined to eliminate tying
altogether and have every module set properties explicitly; what does
everyone else think?
I'd really like to see tying stay in. I'm not sure we ever would have
incorporated the property tree
Frederic BOUVIER writes:
But I don't think there is a huge penalty here. Classes that are doing
tying now must store the SGPropertyNode as a separated pointer for tying
and untying.
They don't, actually -- the property manager takes care of storing the
node. You just do something like
1. Require every module that ties a property to fire an update event
whenever the value changes; or
2. Poll tied properties with change listeners attached inside the
property system and fire the events when appropriate.
I'd be include towards #2, since it would centralize the polling
Jon Berndt writes:
Let me add that in JSBSim (and for that matter probably any FDM)
just offhand I'd say that almost all of our properties will be
changing every single frame. Aircraft state and EOM are dynamic
things.
I think that we can centralize this and make it invisible to JSBSim
I just committed Jim's changes to CVS. This means you'll need to
update both the base package cvs and flightgear cvs to stay in sync.
---BeginMessage---
embarrassing-note
Let me try again. This time I'll remember the file links and one other change
that I made added to the list. :-)
I passed 100 hours total flying time today, while practicing holds and
approaches under the hood in C-FBJO.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Wow! Not bad for...what is it? 8 months since you started?
Best,
Jim
David Megginson [EMAIL PROTECTED] said:
I passed 100 hours total flying time today, while practicing holds and
approaches under the hood in C-FBJO.
All the best,
David
On Thu, 6 Feb 2003 18:43:43 -0500,
David Megginson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
I passed 100 hours total flying time today, while practicing holds and
approaches under the hood in C-FBJO.
..yehaa! :-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
I couldn't find any good info on what kind of map projection
technique to use for the ND.
ie. mapping lat/lon to x/y-screen coord.
I took a look at the OpenGC source,
and as far as I understand, it uses a technique which converts
RijksDriehoeks to Hayford.
I tried to google a bit on
Jim Wilson writes:
Wow! Not bad for...what is it? 8 months since you started?
Give or take.
Thanks,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Manuel Bessler
I also had the chance to ask a real airliner pilot. He said that on A340
and B744, a line on the NDs represents the shortest path between two
points, ie. a Great Circle route. He also said that on older NDs (A300
or A310, I forgot which he mentioned) the line is not a Great
Hello everyone-
I was just wondering if the subroutine
SGRoute.distance_off_route() calculates accurate
results (or even reasonably usable results for
navigation in fgfs) for waypoints on a wgs84 system.
I've run some tests and it seems okay, but I'm no
expert - can someone verify this?
Also,
John A. Gallas
I was just wondering if the subroutine
SGRoute.distance_off_route() calculates accurate
results (or even reasonably usable results for
navigation in fgfs) for waypoints on a wgs84 system.
I've run some tests and it seems okay, but I'm no
expert - can someone verify this?
Manuel Bessler writes:
Did a little more research... (blindly shooting some search requests
at google)
Something that came up was, the Lambert Conformal Conic Projection.
I also had the chance to ask a real airliner pilot. He said that on A340
and B744, a line on the NDs represents the
Curtis L. Olson writes:
You might be thinking too hard about this.
The following seems to work really slick for me (assuming you are
doing smaller area maps or don't care about some distortion as you get
towards the top/bottom of the map. Even if this isn't quite good
enough for your
John A. Gallas writes:
Hello everyone-
I was just wondering if the subroutine
SGRoute.distance_off_route() calculates accurate
results (or even reasonably usable results for
navigation in fgfs) for waypoints on a wgs84 system.
I've run some tests and it seems okay, but I'm no
expert -
Norman Vine writes:
This works fine for a 'map' but straight lines will not be great circles
which AFAIK is still the standard for *most* aviation 'charts', both
paper and electronic versions
Fair enough ... I guess it all depends on the needs of the end
application. It's about as simple
25 matches
Mail list logo
