Jon S Berndt writes:
Yeah, I've considered that for some time, just haven't
gotten around to it. But, I guess if it's causing so many
problems, maybe we need to just go ahead and do it.
Another reason I have waited is because even though I know
how to use stuff in other namespaces,
David Megginson writes:
When we get around to modelling ships, we can impose on Norm Vine to
share some of his expertise, since this is his specialty.
Although I have experienced a LOT of it
I have done VERY little modelling of ship motion.
Cheers
Norman
Norman Vine writes:
it would behoove the project to stop thinking in spherical terms
xcept when doing user input / output. Converting back and forth
between sperical and cartesian representation is a time sink that
doesn't need to happen at all as far as the inner workings of the
Tony Peden writes:
The latter would certainly be easier, no code would need to be changed.
Wouldn't it have the effect of forcing client code to keep track of
which vehicle was being referenced in the tree? A good example here, I
think, would be the view manager. Another good example
Jim Brennan jjb - writes:
Now to be really fancy, you'll need to model the pitch and roll of the
carrier deck.
And the changes in height above the sea as the landing area moves up and
down!
Right. And for Canadian aircraft carriers, you'll have to ...
... oh, sorry, we don't have
Norman Vine writes:
But we really need another name and I realize that you are trained
in 'English' and will argue for (1) below however I believe (3)
below is paramount in this case as this class refers to a 'single
point' not a 'set of points' in the 'mathematical sense and Locus
is
On Fri, 5 Apr 2002, David Megginson wrote:
Jim Brennan jjb - writes:
Now to be really fancy, you'll need to model the pitch and roll of the
carrier deck.
And the changes in height above the sea as the landing area moves up and
down!
Right. And for Canadian aircraft
David Megginson [EMAIL PROTECTED] said:
Norman Vine writes:
But we really need another name and I realize that you are trained
in 'English' and will argue for (1) below however I believe (3)
below is paramount in this case as this class refers to a 'single
point' not a 'set of
David Megginson writes:
Norman Vine writes:
But we really need another name and I realize that you are trained
in 'English' and will argue for (1) below however I believe (3)
below is paramount in this case as this class refers to a 'single
point' not a 'set of points' in the
Jim Wilson writes:
Or maybe FGLocalCoordor just FGCoord?
I'd be worried about confusion with sgCoord.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Jim Wilson writes:
David Megginson [EMAIL PROTECTED] said:
Norman Vine writes:
But we really need another name and I realize that you are trained
in 'English' and will argue for (1) below however I believe (3)
below is paramount in this case as this class refers to a 'single
On Fri, 5 Apr 2002 10:27:44 -0500
David Megginson [EMAIL PROTECTED] wrote:
Here's something more interesting (and Canadian) -- what about landing
a Beaver or Otter on a large (i.e. 5km x 5km) moving ice floe during
the spring thaw up north?
What kind of crazy place is this Can ada? I've seen
On Fri, 5 Apr 2002 10:10:10 -0600 (CST)
Curtis L. Olson [EMAIL PROTECTED] wrote:
How about something simple like FGPosition or FGPos ... I thought of
it so it gets my vote. :-)
Curt.
We thought of it three years ago (FGPosition). It's
already in JSBSim.
:-)
Jon
Jon S Berndt writes:
On Fri, 5 Apr 2002 10:10:10 -0600 (CST)
Curtis L. Olson [EMAIL PROTECTED] wrote:
How about something simple like FGPosition or FGPos ... I thought of
it so it gets my vote. :-)
Curt.
We thought of it three years ago (FGPosition). It's
already in JSBSim.
Yes BUT ...
On Fri, 5 Apr 2002 12:11:43 -0500
Norman Vine [EMAIL PROTECTED] wrote:
Yes BUT ... your FGPosition is what I would call FGRigidBody
ie you have velocity and acceleration terms
IMHO the class heirarchy should be something like
Given any 100 people, you'll get 400 different FDMs. :-)
Our
Jon S Berndt writes:
On Fri, 5 Apr 2002 12:11:43 -0500
Norman Vine [EMAIL PROTECTED] wrote:
Yes BUT ... your FGPosition is what I would call FGRigidBody
ie you have velocity and acceleration terms
IMHO the class heirarchy should be something like
Given any 100 people, you'll get 400
Jon S Berndt writes:
On Fri, 5 Apr 2002 12:58:57 -0500
Norman Vine [EMAIL PROTECTED] wrote:
I guess I was just trying to point out that IMHO we shouldn't adopt
the JSBSIM::FGPosition class as is in that it has in the more general
enviroment of FGFS xtra baggage ...
Oh, I certainly
On Fri, 5 Apr 2002 13:00:00 -0500
David Megginson [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
That's actually becoming a bit of a problem -- I couldn't use FGModel
for the 3D model either because JSBSim had already taken it. As Andy
keeps reminding us, it would be a good idea to put JSBSim
David Megginson writes:
Jon S Berndt writes:
We thought of it three years ago (FGPosition). It's
already in JSBSim.
That's actually becoming a bit of a problem -- I couldn't use FGModel
for the 3D model either because JSBSim had already taken it. As Andy
keeps reminding us, it would be a
Jon S Berndt writes:
. In hindsight, we might have preferred to not
call everything FG
I volunteer to change the JSBSim usage of the 'FG' prefix
to anything you want :-)
15-minutes-of-sed'ly-yr's
Norman
___
Flightgear-devel mailing list
* [EMAIL PROTECTED] (Norman Vine) [2002.04.06 12:25]:
Jon S Berndt writes:
. In hindsight, we might have preferred to not
call everything FG
I volunteer to change the JSBSim usage of the 'FG' prefix
to anything you want :-)
15-minutes-of-sed'ly-yr's
15 minutes?
$ find . -name
On Thu, 4 Apr 2002 16:04:53 -0500,
David Megginson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
What about landing a helicopter on top of a moving train in a James
Bond emulator? This is a nasty problem. I do think that it should be
possible to locate the ssgVertexTable under
. In hindsight, we might have preferred to not
I volunteer to change the JSBSim usage of the 'FG' prefix
to anything you want :-)
15-minutes-of-sed'ly-yr's
15 minutes?
$ find . -name *.[ch]?? -o -name *.h \
perl -pi.bak -e 's/FG/JSB/g'
10 seconds to write, 14.83 minutes to fix
Alex Perry writes:
. In hindsight, we might have preferred to not
I volunteer to change the JSBSim usage of the 'FG' prefix
to anything you want :-)
15-minutes-of-sed'ly-yr's
15 minutes?
$ find . -name *.[ch]?? -o -name *.h \
perl -pi.bak -e 's/FG/JSB/g'
10 seconds to
Justin Palamar wrote:
1) A design goal was to have a moving aircraft carrier within the
simulator with the option to land on its deck
There are actually two problems here. The first, making the object
move, is relatively easy. It will require C++ code, though. One way
I've thought about
On Thu, 04 Apr 2002 14:03:10 -0500
Justin Palamar [EMAIL PROTECTED] wrote:
Hello, flightgear devolpers, this is my first message to
this list, so please excuse any question that may sound
'stupid', I'm just a newbie.
We all remember when we were newbies - no question is
stupid. This
Curtis L. Olson [EMAIL PROTECTED] said:
The DCS system would take care of loading and attaching the 3d models
to the correct place in the scene graph and removing them. It would
call the update() routine for each of their engines. And it would
probably provide some sort of property
On Thu, 4 Apr 2002 20:50:18 -
Jim Wilson [EMAIL PROTECTED] wrote:
I've been working toward this sort of thing slowly severing the ties
between the model code and the viewer so that we can have multiples of
both. The new viewer interface will make it possible to have multiple
FDM's and
Jon S. Berndt wrote:
Jim Wilson wrote:
The bigger problem (or so it seems to me :-)) is the one Andy
brought up. How you model stopping on a moving runway.
This really is not a big deal after all, I think
Agreed. Inside the gear model, the problem is basically an extra
addition to
Andy Ross writes:
There are actually two problems here. The first, making the object
move, is relatively easy. It will require C++ code, though. One way
I've thought about doing it is to put the object in the property tree
rather than the static scenery description. Something like:
Jim Wilson writes:
I've been working toward this sort of thing...slowly severing the
ties between the model code and the viewer so that we can have
multiples of both.
I started a model overhaul myself this afternoon (it's been a little
overdue). Basically, I'm separating the animation
David Megginson wrote:
I've considered something similar, but I don't think it's scalable.
Imagine two year from now, if people have created tens of thousands of
custom objects for scenery around the world. This requires more
thought.
True enough. I was really thinking more along the
On Thu, 2002-04-04 at 13:33, Jon S Berndt wrote:
On Thu, 4 Apr 2002 21:24:06 -
Jim Wilson [EMAIL PROTECTED] wrote:
believe. What are you doing with the way FDMs are
instantiated?!
Absolutely nothing. But if your mulitple FDM instances can publish
position/orientation data
Tony Peden writes:
We'll have to talk about how to implement this. Right now, it would
all be in /fdm/jsbsim[1,2,3...]. We need a non-FDM specific way of
handling both this sort of thing and xml-defined parameters.
Here's what I've been thinking of (for a while):
1. Add methods
Jim Wilson writes:
On second thought why don't we go with what you are doing for the
time being. I think I can get by with my view manager and viewer
changes as long as your model code is independent of the viewer and
the view manager. Then if you want to go with the model
David Megginson [EMAIL PROTECTED] said:
While we're talking about refactoring, I think that it might be time
to consider creating something like an FGLocus class, to keep track of
a single location. Its interface would look a lot like the viewer's:
Yes I was thinking the same thing. If
On Thu, Apr 04, 2002 at 07:57:00PM -0500, David Megginson wrote:
Tony Peden writes:
We'll have to talk about how to implement this. Right now, it would
all be in /fdm/jsbsim[1,2,3...]. We need a non-FDM specific way of
handling both this sort of thing and xml-defined parameters.
L.
Olson
Sent: Friday, April 05, 2002 1:01 AM
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Moving carrier, and Repositioning
questions
What I would like to see implimented is a 'standard' DCS system (where
DCS stands for dyanamic coordinate system which is industry lingo for
objects
: [Flightgear-devel] Moving carrier, and Repositioning
questions
Justin Palamar writes:
1) A design goal was to have a moving aircraft carrier within the
simulator
with the option to land on its deck
Right not we have only been able to insert the static model by editing
the
appropriate .stg
39 matches
Mail list logo
