Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?

2004-07-03 Thread Chris Metzler
On Sat, 3 Jul 2004 01:19:27 +0100
Lee Elliott [EMAIL PROTECTED] wrote:

 As I understand it, the 3d model and texture handling in FG is done via
 plib, which treats the texture map path incorporated in the .ac model
 file as a relative path.

Relative to what?  To the directory containing the .ac file that uses
the texture?  To the directory containing the .xml file that has the
Model tags?  Relative to something else?

Because if I understand it (and I may not), that's the heart of Erik's
approach (and I'm hoping he'll jump in here if I've got it wrong).
You have different subdirectories for each livery.  Each one has the
textures for that livery in it, as well as the xml file that specifies
the 3D model, but NOT the 3D model itself (which is, say, in the parent
directory).  The .xml file gets read; the Modelpath tags provide a
relative pathname from where the .xml is located upstairs to the .ac
file; the .ac file calls textures which are loaded from the directory
the thread is currently in -- namely, the one with the .xml file.

This presumes that when the .xml file sends plib off to get the .ac
file in a different directory by specifying a relative path, the place
plib looks for subsequent file opens won't be in that different
directory.  That seems sensible.  Do I have it right?

If so, then the trick is having something in the (aircraftname)-set.xml
file that makes the modelpath be conditional based on the livery.
For example, for the 737, which currently has in its 737-set.xml

  model
pathAircraft/737/Models/boeing733.xml/path
  /model

and Aircraft/737/Models/boeing733.xml currently has 

  pathB737-300.ac/path
  offsets
stuff
  /offsets

  animation
etc.

you could instead have something like 737-set.xml containing

  model
pathAircraft/737/Models/United/boeing733.xml/path
condition
  equals
property.../livery-name/property
valueunited/value
  /equals
/conditon
  /model

  model
pathAircraft/737/Models/Southwest/boeing733.xml/path
condition
  equals
property.../livery-name/property
valuesouthwest/value
  /equals
/conditon
  /model

Then, in Models/United/boeing733.xml and Models/Southwest/boeing733.xml,
you have exactly the same content:

  path../B737-300.ac/path
  offsets
stuff
  /offsets

  animation
etc.

so they both use the same 3D model; but the textures are drawn out of
the directory that boeing733.xml is being read from, which means
putting different textures in Models/United and Models/Southwest would
do the trick.

(in fact, since they have exactly the same content, each of the
different boeing733.xml files could just read their content from
elsewhere through an include)

Does this make sense?  Am I understanding you, Erik?

-c

-- 
Chris Metzler   [EMAIL PROTECTED]
(remove snip-me. to email)

As a child I understood how to give; I have forgotten this grace since I
have become civilized. - Chief Luther Standing Bear


pgp1FBBM6muCM.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?

2004-07-03 Thread Erik Hofman
Chris Metzler wrote:
On Sat, 3 Jul 2004 01:19:27 +0100
Lee Elliott [EMAIL PROTECTED] wrote:
As I understand it, the 3d model and texture handling in FG is done via
plib, which treats the texture map path incorporated in the .ac model
file as a relative path.
Relative to what?  To the directory containing the .ac file that uses
the texture?  To the directory containing the .xml file that has the
Model tags?  Relative to something else?
Because if I understand it (and I may not), that's the heart of Erik's
approach (and I'm hoping he'll jump in here if I've got it wrong).
You have different subdirectories for each livery.  Each one has the
textures for that livery in it, as well as the xml file that specifies
the 3D model, but NOT the 3D model itself (which is, say, in the parent
directory).  The .xml file gets read; the Modelpath tags provide a
relative pathname from where the .xml is located upstairs to the .ac
file; the .ac file calls textures which are loaded from the directory
the thread is currently in -- namely, the one with the .xml file.
I just tried this out. It doesn't work. :-(
Plib expects the textures to be in the same directory as the geometry 
file which (at this moment) means you will always have to duplicate the 
.ac file.

I think we need to push a patch to the plib developers list that 
optionally lets one specify the texture directory when loading a 
geometry file, but still default to the geometries own directory.

I expect that approach might stand a chance of getting accepted.
Does this make sense?  Am I understanding you, Erik?
That is what I was hoping should work, but it doesn't.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] Spitfire model

2004-07-03 Thread Vivian Meazza


Hi,

I've forwarded the current state-of-play Spitfire model to Curt for release
in CVS. The model is also available here:
 
http://myweb.tiscali.co.uk/vmeazza/FlightGear/spitfire.tar.gz

There are 2 versions: spitfireIIa with legacy YASim propeller/engine code,
and spitfireIIa-mod1 with the current propeller/engine code. Only
spitfireIIa flies, spitfireIIa-mod1 only allows you to taxi, and that
barely. 

The POH is here:

http://home.clara.net/wolverine/BOB/misc/Spit_Hurri_Manuals.zip

You might also need this

http://myweb.tiscali.co.uk/vmeazza/FlightGear/spitfire_key_bindings.pdf

The model should operate as advertised!

The sound remains a mess right now, and until the YASim propeller/engine
gearing problem is solved, I can't progress it

There are also unresolved errors in the -set.xml file:

controls 
  engines 
engine n=0
magneto-switch type=bool1/magneto-switch
magneto-switch type=bool1/magneto-switch 
magnetos3/magnetos
/engine
  /engines
/controls

I then try to access it elsewhere.

This works:

binding 
commandnasal/command
script
setprop(controls/engines/engine/magneto-switch[0],1);
/script
/binding
   
But this doesn't:
 
binding 
commandnasal/command
  script
setprop(controls/engines/engine/magneto-switch[1],1);
/script
/binding

I have left this code in so that the problem can be investigated, but I can
work around it.

I hope that we can resolve the YASim propeller/engine gearing problem soon.

Regards

Vivian





___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?

2004-07-03 Thread tiagogusmao
Hi

I'm new around here, and to the FG/plib way of doing these things,
but i'd like to point that there are a lot of textures that can be shared, take
a look at the 747 for example, and so my ideal directory structure would be
like:

example:
a 757 with a panel.rgb, gear.rgb and fuselage.rgb

Data/Aircraft/some_aircraft/Models/base0 : here put all the files, with
fuselage.rgb having some default fallback (useful for online play or so, not
everyone may have the livery someone else used in disk)

Data/Aircraft/some_aircraft/Models/base1 : imagine someone redoes the panel
texture with another style, put's the new panel.rgb here along with the old
gear.rgb and fuselage.rgb, so you pick the panel you like most

Data/Aircraft/some_aircraft/Models/United : if someone does a United Airlines
painting, creates this folder and just put's the new fuselage.rgb here, since
panel.rgb and gear.rgb don't change from airline to airline

so you just specify something like this:

  base_livery/base0base_livery
  livery/United/livery

and files with the same name in the United folder override files in the base0.

One can imagine an arbitrary number of folders and priorities can be made, but i
think this way should be enough.
Of course this doesn't require remaking all aircrafts, but to use it properly,
relevant textures must appear in different files.

Hope i was clear :P

Regards,
Tiago






O SAPO já está livre de vírus com a Panda Software, fique você também!
Clique em: http://antivirus.sapo.pt

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] Property references

2004-07-03 Thread Jon Berndt
I need some references to papers, articles, discussions, etc. regarding properties. If
anyone can suggest where I might find writings on this subject, please let me know 
ASAP.
I'll be looking around, too, so I may find something shortly, but this is a timely and
urgent need. Thanks a bunch.

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] RE: [Jsbsim-devel] Property references

2004-07-03 Thread Jon Berndt
 I need some references to papers, articles, discussions, etc. regarding properties. 
 If
 anyone can suggest where I might find writings on this subject, please let me know 
 ASAP.
 I'll be looking around, too, so I may find something shortly, but this is a timely 
 and
 urgent need. Thanks a bunch.

 Jon


Found the perfect reference for my needs:

props.html

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?

2004-07-03 Thread Lee Elliott
On Saturday 03 July 2004 09:49, Erik Hofman wrote:
 Chris Metzler wrote:
  On Sat, 3 Jul 2004 01:19:27 +0100
 
  Lee Elliott [EMAIL PROTECTED] wrote:
 As I understand it, the 3d model and texture handling in FG is done via
 plib, which treats the texture map path incorporated in the .ac model
 file as a relative path.
 
  Relative to what?  To the directory containing the .ac file that uses
  the texture?  To the directory containing the .xml file that has the
  Model tags?  Relative to something else?

It's relative to the directory containing the .ac model.  The default is for 
the texture map to reside in the same directory as the .ac model but you can 
edit the .ac file to change the texture path.

I just tried creating a 'Textures' sub-dir in the 'Models' dir, which holds 
the .ac file, and moved the texture into it so that the .ac file was in 
'Models', together with the xxx-model.xml file, but the texture.rgb was in 
the 'Models/Textures' sub-dir.  Then I edited the .ac file to change the 
'texture' entries from 'texture.rgb' to 'Textures/texture.rgb' and this 
seemed to work ok in AC3D.

This doesn't really help though because it's still hard-coded into the .ac 
file.

 
  Because if I understand it (and I may not), that's the heart of Erik's
  approach (and I'm hoping he'll jump in here if I've got it wrong).
  You have different subdirectories for each livery.  Each one has the
  textures for that livery in it, as well as the xml file that specifies
  the 3D model, but NOT the 3D model itself (which is, say, in the parent
  directory).  The .xml file gets read; the Modelpath tags provide a
  relative pathname from where the .xml is located upstairs to the .ac
  file; the .ac file calls textures which are loaded from the directory
  the thread is currently in -- namely, the one with the .xml file.

 I just tried this out. It doesn't work. :-(
 Plib expects the textures to be in the same directory as the geometry
 file which (at this moment) means you will always have to duplicate the
 ..ac file.

See above, but you still need to duplicate the .ac file to specify different 
textures - wherever they're put.


 I think we need to push a patch to the plib developers list that
 optionally lets one specify the texture directory when loading a
 geometry file, but still default to the geometries own directory.

 I expect that approach might stand a chance of getting accepted.

  Does this make sense?  Am I understanding you, Erik?

 That is what I was hoping should work, but it doesn't.

 Erik

A patch to plib that allowed a prefix to be added to the  texture path 
specified in the .ac model is really the only answer to this problem.  The 
prefix could be used to either specify a sub-dir containing the required 
texture.rgb or it could be a simple file prefix to allow choosing between 
say, UA-737.rgb or MyAirline-737.rgb textures - in this case the texture 
specified in the .ac file would just be 737.rgb

As Innis suggested, it would be possible to replace the named texture with the 
one you want to use at run-time, and this could be coded into FG but it would 
have serious security implications.  The FG user would need to have write 
permissions to the FG installation to permit the overwriting of the installed 
files, and that's not really on.

LeeE

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] props.html

2004-07-03 Thread Jon Berndt
Can anyone tell me if/where the props.html file is that describes the property system? 
I
can't seem to find it in the source tree or on the web sites - but it IS in simgear 
CVS.

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] props.html

2004-07-03 Thread Vivian Meazza


Jon Berndt wrote
 
 Can anyone tell me if/where the props.html file is that 
 describes the property system? I can't seem to find it in the 
 source tree or on the web sites - but it IS in simgear CVS.


It used to be around - I have a print-out of it! What bit do you want? I
could scan it in.

Vivian 



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] props.html

2004-07-03 Thread Jon Berndt
 Jon Berndt wrote

  Can anyone tell me if/where the props.html file is that
  describes the property system? I can't seem to find it in the
  source tree or on the web sites - but it IS in simgear CVS.


 It used to be around - I have a print-out of it! What bit do you want? I
 could scan it in.

 Vivian

I actually need to refer to it as a reference, but I don't see that it actually exists 
as
a live document on any web site.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] props.html

2004-07-03 Thread Erik Hofman
Jon Berndt wrote:
Can anyone tell me if/where the props.html file is that describes the property system? 
I
can't seem to find it in the source tree or on the web sites - but it IS in simgear 
CVS.
There doesn't seem to be a file called props.html, and as far as I can 
remember there hasn't been any.

The property system is best described as an in-memory LDAP database 
which holds the state of global variables. The system has a tree like 
hierarchy (like a file system) and has a root node, sub nodes (like 
subdirectories) and end-nodes (variables).

All variables are kept internally as raw values and can be converted to 
any other supported type (boolean, int, float double and string).

Like a file system, every node can be accessed relative to the current 
node, or absolute to the root node.

The property system also allows aliasing nodes to other nodes (like 
symbolic linking files or directories to other files or directories) and 
may be assigned read-only or read-write.

If necessary it would be possible for parts of the program to hold it's 
own property tree, which is inaccessible from the global property tree, 
by keeping track of it's own root-node.

Property I/O code allows one to easily read the tree from, or write the 
tree to an XML file.

HTH
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] props.html

2004-07-03 Thread Vivian Meazza


Vivian Meazza wrote


 Sent: 03 July 2004 14:52
 To: 'FlightGear developers discussions'
 Subject: RE: [Flightgear-devel] props.html
 
 
 
 
 Jon Berndt wrote
  
  Can anyone tell me if/where the props.html file is that
  describes the property system? I can't seem to find it in the 
  source tree or on the web sites - but it IS in simgear CVS.
 
 
 It used to be around - I have a print-out of it! What bit do 
 you want? I
 could scan it in.
 

Is this what you were after?

Source/docs-mini/README.properties

V.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] props.html

2004-07-03 Thread Jon Berndt
 The property system is best described as an in-memory LDAP database
 which holds the state of global variables. The system has a tree like
 hierarchy (like a file system) and has a root node, sub nodes (like
 subdirectories) and end-nodes (variables).

 All variables are kept internally as raw values and can be converted to
 any other supported type (boolean, int, float double and string).

 Like a file system, every node can be accessed relative to the current
 node, or absolute to the root node.

 The property system also allows aliasing nodes to other nodes (like
 symbolic linking files or directories to other files or directories) and
 may be assigned read-only or read-write.

 If necessary it would be possible for parts of the program to hold it's
 own property tree, which is inaccessible from the global property tree,
 by keeping track of it's own root-node.

This is pretty good - I may incorporate some of this in the paper.

 Property I/O code allows one to easily read the tree from, or write the
 tree to an XML file.

After reading this, I suspect that we (JSBSim) could be using the property system 
inherent
features more advantageously. This will all come when we incorporate a better XML 
parser,
I expect.

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] props.html

2004-07-03 Thread Jon Berndt
That just appears to be a list of properties.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Vivian
 Meazza
 Sent: Saturday, July 03, 2004 9:00 AM
 To: 'FlightGear developers discussions'
 Subject: RE: [Flightgear-devel] props.html
 
 
 
 
 Vivian Meazza wrote
 
 
  Sent: 03 July 2004 14:52
  To: 'FlightGear developers discussions'
  Subject: RE: [Flightgear-devel] props.html
  
  
  
  
  Jon Berndt wrote
   
   Can anyone tell me if/where the props.html file is that
   describes the property system? I can't seem to find it in the 
   source tree or on the web sites - but it IS in simgear CVS.
  
  
  It used to be around - I have a print-out of it! What bit do 
  you want? I
  could scan it in.
  
 
 Is this what you were after?
 
 Source/docs-mini/README.properties
 
 V.
 
 
 
 ___
 Flightgear-devel mailing list
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] props.html

2004-07-03 Thread Vivian Meazza


 Jon Berndt wrote

 Sent: 03 July 2004 15:12
 To: FlightGear developers discussions
 Subject: RE: [Flightgear-devel] props.html
 
 
 That just appears to be a list of properties.
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] Behalf Of Vivian 
  Meazza
  Sent: Saturday, July 03, 2004 9:00 AM
  To: 'FlightGear developers discussions'
  Subject: RE: [Flightgear-devel] props.html
  
  
  
  
  Vivian Meazza wrote
  
  
   Sent: 03 July 2004 14:52
   To: 'FlightGear developers discussions'
   Subject: RE: [Flightgear-devel] props.html
   
   
   
   
   Jon Berndt wrote

Can anyone tell me if/where the props.html file is that 
 describes 
the property system? I can't seem to find it in the 
 source tree or 
on the web sites - but it IS in simgear CVS.
   
   
   It used to be around - I have a print-out of it! What bit do
   you want? I
   could scan it in.
   
  
  Is this what you were after?
  
  Source/docs-mini/README.properties
  
  V.
  

It is :-). There is also a short, and not very useful, discourse on XML
available, but I think Eric's description is about as good as it gets.

V.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] props.html

2004-07-03 Thread Jon Berndt
 The property system is best described as an in-memory LDAP database 
 which holds the state of global variables. The system has a tree like 
 hierarchy (like a file system) and has a root node, sub nodes (like 
 subdirectories) and end-nodes (variables).
 
 All variables are kept internally as raw values and can be converted to 
 any other supported type (boolean, int, float double and string).
 
 Like a file system, every node can be accessed relative to the current 
 node, or absolute to the root node.
 
 The property system also allows aliasing nodes to other nodes (like 
 symbolic linking files or directories to other files or directories) and 
 may be assigned read-only or read-write.
 
 If necessary it would be possible for parts of the program to hold it's 
 own property tree, which is inaccessible from the global property tree, 
 by keeping track of it's own root-node.
 
 Property I/O code allows one to easily read the tree from, or write the 
 tree to an XML file.

Would you say that the JSBSim property tree is grafted onto the FlightGear tree?

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] props.html

2004-07-03 Thread Ampere K. Hardraade
May be it is time we update the Source/docs-mini/README.properties to include 
Erik's description.

Regards,
Ampere

On July 3, 2004 10:28 am, Vivian Meazza wrote:
 It is :-). There is also a short, and not very useful, discourse on XML
 available, but I think Eric's description is about as good as it gets.

 V.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] Does changing paintjob/livery requirea duplicate aircraft?

2004-07-03 Thread Norman Vine
Lee Elliott writes: 
 
  I think we need to push a patch to the plib developers list that
  optionally lets one specify the texture directory when loading a
  geometry file, but still default to the geometries own directory.

 see ssgLoad.cxx

void ssgLoaderOptions::setModelDir ( const char *s )
{
  delete [] model_dir ;
  model_dir = ulStrDup ( s ) ;
}

void ssgLoaderOptions::setTextureDir ( const char *s )
{
  delete [] texture_dir ;
  texture_dir = ulStrDup ( s ) ;
}


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?

2004-07-03 Thread Chris Metzler
On Fri, 02 Jul 2004 16:43:23 -0500
Curtis L. Olson [EMAIL PROTECTED] wrote:

 For a particalar model it would be possible to just modify the existing 
 textures to give it a new livery.
 
 If you want to create an entirely new livery without disturbing the 
 original, you could make a copy of the aircraft-set.xml file.  Then 
 make a copy of the .ac file and update the new -set.xml file to point to
 
 the new .ac file.
 
 .ac files can be hand edited with a text editor and it's pretty easy to 
 find texture names and change them.  So you could copy all the textures,
 
 give them new names and then update the .ac file to point to the new 
 names.  Then you can modify the copies of the original textures to the 
 new livery.

This makes perfect sense, and I think Innis Cunningham made the same
point as well; but I think I did a crappy job of describing what I was
getting at.  Definitely you could change liveries by just replacing the
texture, or by having more than one .ac file which differ only in the
texture names, with different .xml files pointing to the different
.ac's, and then different -set.xml files pointing to those.  But in
such cases, the paint job replacement is universal; all Cessnas or
Piper Cubs or 747s in a scene at the same time will have this same
different paint job.  I was trying to imagine how one might have
multiple instances of the same aircraft, but with different paint jobs,
in a scene at the same time (e.g. taxiing towards take-off in your
Cessna behind another Cessna that looks different from yours).

-c

-- 
Chris Metzler   [EMAIL PROTECTED]
(remove snip-me. to email)

As a child I understood how to give; I have forgotten this grace since I
have become civilized. - Chief Luther Standing Bear


pgpHS9r0tV2nq.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] props.html

2004-07-03 Thread Erik Hofman
Jon Berndt wrote:
Would you say that the JSBSim property tree is grafted onto the FlightGear tree?
Yes, that sounds like a good description of the situation.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Does changing paintjob/livery requirea duplicate aircraft?

2004-07-03 Thread Erik Hofman
Norman Vine wrote:
Lee Elliott writes: 

I think we need to push a patch to the plib developers list that
optionally lets one specify the texture directory when loading a
geometry file, but still default to the geometries own directory.

 see ssgLoad.cxx
void ssgLoaderOptions::setModelDir ( const char *s )
{
  delete [] model_dir ;
  model_dir = ulStrDup ( s ) ;
}
void ssgLoaderOptions::setTextureDir ( const char *s )
{
  delete [] texture_dir ;
  texture_dir = ulStrDup ( s ) ;
}
Look here!
I did a quick scan of the ssg texture loading code but didn't notice the 
setTextureDir was already available. Now I have to find out if this can 
be sent at model load time, or using a crippled construction prior to 
loading the geometry.

Thanks for the hint Norman.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] domain name

2004-07-03 Thread Alex Perry
From: Chris Metzler [EMAIL PROTECTED]
 Martin Spott [EMAIL PROTECTED] wrote:
 Ampere K. Hardraade wrote:
 On June 28, 2004 05:32 pm, Curtis L. Olson wrote:
  I have just reregistered the flightgear.org domain name for another
  year...
  I sense someone is asking for a donation... lol
  PayPal !?  ;-)
 This is just what I was thinking.  Lots of open source projects
 have set up PayPal accounts for collecting donations.

We have a sourceforge account for the project, and SF offers
some kind of built in capability for accepting donations.
I don't know how it works and have never used it,
but it might be worth investigating sometime in the next 11 months.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] domain name

2004-07-03 Thread Jon Berndt
 We have a sourceforge account for the project, and SF offers
 some kind of built in capability for accepting donations.
 I don't know how it works and have never used it,
 but it might be worth investigating sometime in the next 11 months.

Yes. It's not that hard to set up. I've turned on the feature for JSBSim, hoping beyond
hope that some kind souls would send a few pennies our way. As you know I've got a
conference I'm supposed to present a paper at in several weeks. Unfortunately, the
conference has not been deemed to be work-related enough to justify my company sending 
me
there, so it will be on my dime. :-(

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel