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
_
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 namespa
Arnt Karlsen writes:
> ..adding to the fun, in WWII, several merchantmen were converted
> to "auxillary aircraft carriers", for convoy escort duty, such as
> to Murmansk, Russia, essentially by "roofing" the ship.
> These were small enough to heave, pitch and roll etc in weather.
> Anyone h
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/
> > >. 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
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 u
* [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?
$ fin
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
[E
On Fri, 5 Apr 2002 13:00:00 -0500
David Megginson <[EMAIL PROTECTED]> wrote:
>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 and possibly
>SimG
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
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 JSB
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
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 agree - I didn't mean to i
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 good idea to put JSBSim
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 g
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 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 JSBSi
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
___
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
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
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]
http://mail.flightgear.org
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
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
* [EMAIL PROTECTED] (David Megginson) [2002.04.06 09:31]:
> ... oh, sorry, we don't have any aircraft carriers, or even
> battleships (does anyone still use battleships?) or cruisers, I think.
The US doesn't have anymore battleships in service. The last two were
decommissioned after Desert Storm
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 air
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
>
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 ha
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 exampl
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
t: re: [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
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
ob
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 parameter
David Megginson writes:
>
>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:
>
> class FGLocus
> {
> public:
>FGLocus ();
>vi
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 thin
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
> positi
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 someth
Jim Wilson writes:
> Oops, yes it does, I've been doing a similar thing, althought
> haven't done anything with the animations. Can you send me what
> you've got and I'll try and merge with what I have?
I'll send you what I've got a little later this evening.
> Also: what I would like to d
Jim Wilson <[EMAIL PROTECTED]> said:
>
> Oops, yes it does, I've been doing a similar thing, althought haven't done
> anything with the animations. Can you send me what you've got and I'll try
> and merge with what I have?
David,
On second thought why don't we go with what you are doing for t
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
David Megginson <[EMAIL PROTECTED]> said:
> I started a model overhaul myself this afternoon (it's been a little
> overdue). Basically, I'm separating the animation code out so that it
> can be used for any 3D model (windsock, aircraft carrier, waving field
> of grain, or what-have-you) rather t
Andy Ross writes:
> True enough. I was really thinking more along the lines of a few
> objects that need to be controllable and/or scripted. Moving carriers
> are like this, consider a Python script or whatnot that handled the
> battle group's movements through the property system.
>
> Other ty
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 th
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
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 scenery file, including
> "OBJECT_STATIC sarat
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
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
additi
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 into a seperate property tree location for
>ea
Jon S Berndt <[EMAIL PROTECTED]> said:
> >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 changes I'm planning for t
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 a
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. The new
> viewer interface will make it possible to have multiple FDM's and changes I'm
> planning for the model code over the
"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 propert
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 *an
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 that move in the scene ... their local coordinate system is
'dyanamic'.
I'm envisioning a DCS manager where you can register 'entities' with
an asso
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
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.
Also if this is posted to the wrong mailing list, I apologize, let me know
and I'll redirect to the proper place.
I am currently a member of a developmen
55 matches
Mail list logo
