David Megginson [EMAIL PROTECTED] said:
Curtis L. Olson writes:
I think at some point (maybe sooner rather than later?) we need to do
some tweaking to the aircraft directly layout so it is possible to:
a) make everything related to a particular plane be contained in a
David Culp wrote:
It would be possible to read the data directly from the archive
without ever extracting it. Adding an aircraft would then be as simple
as placing a file into a directory.
This sounds like too good an idea to let die. This way all the aircraft,
including the default C172, can
On Saturday 23 August 2003 9:00 am, Norman Vine wrote:
David Megginson writes:
It's time to develop a package manager for aircraft and add-on
scenery, and perhaps for other stuff as well.
I agree it is certainly time for some kind of 'data' manager
not really sure what 'form' the manager
Erik Hofman writes:
Erik, do you have in mind a library of reading functions and which archive
format to use? Since we already use zlib, would the archive be in tar format
with each file compressed using z? The idea of reading each file directly
out of the archive sounds better
It'll be a real pain developing and testing a/c if a new archive has to be
created after each change.
This might mean that unpacking the whole archive first, then reading, would be
best? This has the benefit of minimizing code changes as well.
- OR -
The reading can be made intelligent, so
On Sunday 24 August 2003 00:57, David Culp wrote:
It'll be a real pain developing and testing a/c if a new archive has to be
created after each change.
This might mean that unpacking the whole archive first, then reading, would
be
best? This has the benefit of minimizing code changes as
* [EMAIL PROTECTED] (Curt Olson) [2003.08.22 14:21]:
Norman Vine writes:
I agree having many FDM's and many Aircraft is one of FGFS's
cooler points, but, IMO there is no reason these all need be in
the 'core' package, esp when just staying current with the core
package gets in the
David Culp writes:
It'll be a real pain developing and testing a/c if a new archive has to be
created after each change.
This might mean that unpacking the whole archive first, then
reading, would be
best? This has the benefit of minimizing code changes as well.
- OR -
The reading
Norman Vine wrote:
Erik Hofman writes:
Erik, do you have in mind a library of reading functions and which archive
format to use? Since we already use zlib, would the archive be in tar format
with each file compressed using z? The idea of reading each file directly
out of the archive sounds
Lee Elliott wrote:
On Sunday 24 August 2003 00:57, David Culp wrote:
It'll be a real pain developing and testing a/c if a new archive has to be
created after each change.
The reading can be made intelligent, so that --aircraft=F16 will be read in
the current way, and --aircraft=F16.tar.gz will
David Culp wrote:
It would be possible to read the data directly from the archive
without ever extracting it. Adding an aircraft would then be as simple
as placing a file into a directory.
This sounds like too good an idea to let die. This way all the aircraft,
including
Before we get too far down this path, there's one major wrench I need
to throw into the gearing. Consider that much/most/all of our model
loading is done through plib's loaders. Some model formats allow you
to reference models in other files (kind of like #includes.) Just
about all 3d model
David Megginson writes:
It's time to develop a package manager for aircraft and add-on
scenery, and perhaps for other stuff as well.
I agree it is certainly time for some kind of 'data' manager
not really sure what 'form' the manager should be though
Can you elaborate a bit on what you
It would be possible to read the data directly from the archive
without ever extracting it. Adding an aircraft would then be as simple
as placing a file into a directory.
This sounds like too good an idea to let die. This way all the aircraft,
including the default C172, can exist each in
On Saturday 23 August 2003 21:09, David Culp wrote:
It would be possible to read the data directly from the archive
without ever extracting it. Adding an aircraft would then be as simple
as placing a file into a directory.
This sounds like too good an idea to let die. This way all the
Norman Vine wrote:
Hi All,
All the new aircraft etc in FGFS is very impressive :-)
But this is starting to add for me anyway an unacceptable
time burden on statying current. i.e. I am trying to debug
a Cloud3D crash which appeared today and assuming that
it was probably something in the base
Erik Hofman writes:
An answer isn't easy though. I only see one (obvious) location
where to save download time in the base package: the aircrafts
section.
It's time to develop a package manager for aircraft and add-on
scenery, and perhaps for other stuff as well. Here are the top ten
David Megginson wrote:
Erik Hofman writes:
An answer isn't easy though. I only see one (obvious) location
where to save download time in the base package: the aircrafts
section.
It's time to develop a package manager for aircraft and add-on
scenery, and perhaps for other stuff as well. Here
On Fri, 22 Aug 2003 16:50:35 +0200,
Matevz Jekovec [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
David Megginson wrote:
Erik Hofman writes:
An answer isn't easy though. I only see one (obvious) location
where to save download time in the base package: the aircrafts
Arnt Karlsen writes:
Matevz Jekovec
Is there any way to checkout certain directories in CVS repository and
not the whole module? If not, IMHO Aircraft and Textures.high should
be in seperated CVS then. Default base package should only include
Cessna 172 and lowres textures.
Not
Norman Vine writes:
I agree having many FDM's and many Aircraft is one of FGFS's
cooler points, but, IMO there is no reason these all need be in
the 'core' package, esp when just staying current with the core
package gets in the way of code development.
I think at some point (maybe
Norman Vine wrote:
Arnt Karlsen writes:
Matevz Jekovec
Is there any way to checkout certain directories in CVS repository and
not the whole module? If not, IMHO Aircraft and Textures.high should
be in seperated CVS then. Default base package should only include
Cessna 172 and lowres textures.
On Friday 22 August 2003 9:05 am, Norman Vine wrote:
Hi All,
All the new aircraft etc in FGFS is very impressive :-)
But this is starting to add for me anyway an unacceptable
time burden on statying current. i.e. I am trying to debug
a Cloud3D crash which appeared today and assuming that
Curtis L. Olson wrote:
I think at some point (maybe sooner rather than later?) we need to do
some tweaking to the aircraft directly layout so it is possible to:
a) make everything related to a particular plane be contained in a
single, dedicated directory tree.
b) allow these aircraft to
On Fri, 22 Aug 2003 13:26:27 -0500,
Curtis L. Olson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Norman Vine writes:
I agree having many FDM's and many Aircraft is one of FGFS's
cooler points, but, IMO there is no reason these all need be in
the 'core' package, esp when
but, IMO there is no reason these all need be in
the 'core' package, esp when just staying current with the core
package gets in the way of code development.
Is it possible to place all the files for an aircraft in a single compressed
archive, and have FG read them in without permanently
Curtis L. Olson writes:
I think at some point (maybe sooner rather than later?) we need to do
some tweaking to the aircraft directly layout so it is possible to:
a) make everything related to a particular plane be contained in a
single, dedicated directory tree.
b) allow
On Friday 22 August 2003 2:26 pm, Curtis L. Olson wrote:
Norman Vine writes:
I agree having many FDM's and many Aircraft is one of FGFS's
cooler points, but, IMO there is no reason these all need be in
the 'core' package, esp when just staying current with the core
package gets in the
On Fri, 22 Aug 2003 14:05:54 -0500,
David Culp [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
but, IMO there is no reason these all need be in
the 'core' package, esp when just staying current with the core
package gets in the way of code development.
Is it possible to
On Friday 22 August 2003 20:00, Erik Hofman wrote:
Norman Vine wrote:
Arnt Karlsen writes:
Matevz Jekovec
Is there any way to checkout certain directories in CVS repository and
not the whole module? If not, IMHO Aircraft and Textures.high should
be in seperated CVS then. Default base
Curtis L. Olson writes
I think at some point (maybe sooner rather than later?) we need to do
some tweaking to the aircraft directly layout so it is possible to:
a) make everything related to a particular plane be contained in a
single, dedicated directory tree.
I am trying to do
Lee Elliott writes
Personally, I'm not much interested in doing panels and instruments so I'd
be
happy to use the generic instruments from fgfsbase, where they exist, but
there needs to be a clearly defined list of what those instruments will be
once all the a/c, apart from the default
On Saturday 23 August 2003 04:07, Innis Cunningham wrote:
Lee Elliott writes
Personally, I'm not much interested in doing panels and instruments so I'd
be
happy to use the generic instruments from fgfsbase, where they exist, but
there needs to be a clearly defined list of what those
33 matches
Mail list logo
