Jon S. Berndt writes:
The cleanest solution is to have a separate property tree for each
instance; globals could manage that, and make sure that the right one
is always returned.
In at least one of those cases (i.e. the dumb bombs dropping - or even a
guided missile) it's fine if
John Wojnaroski writes:
Fundamentally, this is a design optimization: it makes the very
common cases of accepting configuration from the user and
exporting state to the panel XML much easier to maintain over
time. These cases are hurt, instead of helped, by having a firm
C++
John Wojnaroski wrote:
Are we sub-optimizing to a point design for convience? Okay some
things get better, but it sounds like this will bypass some of the
basic ideas behind C++.
Which ideas? Encapsulation? No, we got that in properties via the
tie mechanism. Composition? Yup, got that
Curtis writes:
I don't see any of the proposed changes really having any substantial
affect on the network interfaces ... perhaps we might need to do a
tiny amount of redesign in places, but I don't see that as a negative.
David writes:
The problem is that you'll
miss more information as
John Wojnaroski writes:
Curtis writes:
I don't see any of the proposed changes really having any substantial
affect on the network interfaces ... perhaps we might need to do a
tiny amount of redesign in places, but I don't see that as a negative.
David writes:
The problem is that
I think the problem with that though is what about the stand alone
version. I also have visions of a standalone version communicating to
flightgear via network sockets. The nice thing about that is you can
have stable version 1.0 that is known to work and you can have
development version 1.1
David,
I think I will support this proposal under a couple of conditions.
1) We need to be able to have multiple instances of various FDM's
running concurrenty (and with your proposed changes, accessible
through the property manager interface.) I'm thinking of things like
random 'traffic' that
need to create fdm[4], etc. Also probably sooner rather than later,
John is going to want to be able to air drop his X-15 from our Cessna
310. :-)
Yes, there are some things in work that should *really* be nice that involve
multiple instances of JSBSim.
I am not against what David (or even
Curtis L. Olson writes:
3) And we'll need three very large folks to sit on Norman and hold him
down while we do this. :-) :-) :-)
No reason to sit on me,
As you know I have been resisting forking a different way
of doing things for a long time and this will be the little shove
that makes it
Curtis L. Olson writes:
2) As you know, accessing property manager values via static
propertynode pointers is more efficient because you only have to do
the expensive string name hash lookup once the first time the routine
runs. It would be nice to have a set of static property node
On Monday 10 December 2001 9:18 pm, you wrote:
David,
I think I will support this proposal under a couple of conditions.
1) We need to be able to have multiple instances of various FDM's
running concurrenty (and with your proposed changes, accessible
through the property manager
Andy Ross writes:
This is true, but I think the expense of the string lookup step is
wildly overestimated. Compared to the cost of rendering a single
frame, it's noise. YASim doesn't even bother with the node stuff yet;
it does sprintf/fgSet for every property every frame, and I
I think the problem with that though is what about the stand alone
version. I also have visions of a standalone version communicating to
flightgear via network sockets.
I do like having a layer of glue between
FlightGear and the FDM ... really you will still need this layer, you
are
13 matches
Mail list logo
