"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> This is dangerous though ...
>
> - it will be hard to track plib changes (or easy to miss plib
> changes.)
>
> - sometimes the loaders are dependent on the internals of a particular
> development version of plib, so we might end up with our code
On Monday 25 August 2003 17:53, Erik Hofman wrote:
> Curtis L. Olson wrote:
>
> > - I'd like to see each aircraft be completely self contained in it's
> > own subdirectory (except for "standard" base package stuff it could
> > feel free to reference.) These standard pieces wouldn't necessaril
Curtis L. Olson writes:
> Ok, if you start at Disney world,
That's in Florida. I always remember it as Disney *LA*nd in LA. I
think that your directions led to Mexico, and that you suggested we
speak mainly Spanish in Canada.
All the best,
David
___
[EMAIL PROTECTED] writes:
>
> Am Montag, 25. August 2003 20:43 schrieb Arnt Karlsen:
>
> > > > I thought the LZW patent had expired?
> > >
> > > At least not in Europe. You'll have to wait until 2004.
> >
> > .."Europe"??? Where is that?. ;-)
> >
> > ..for our US website, we're ok:
>
> USA
[EMAIL PROTECTED] writes:
> Am Montag, 25. August 2003 20:43 schrieb Arnt Karlsen:
>
> > > > I thought the LZW patent had expired?
> > >
> > > At least not in Europe. You'll have to wait until 2004.
> >
> > .."Europe"??? Where is that?. ;-)
> >
> > ..for our US website, we're ok:
>
> USA Wh
Am Montag, 25. August 2003 20:43 schrieb Arnt Karlsen:
> > > I thought the LZW patent had expired?
> >
> > At least not in Europe. You'll have to wait until 2004.
>
> .."Europe"??? Where is that?. ;-)
>
> ..for our US website, we're ok:
USA Where is that? >:-o
Regards,
Oliver C.
___
- We would move each of the -set.xml to also live in the individual
aircraft tree.
- Then to install an aircraft you need to drop the aircraft's
directory somewhere inside the top level Aircraft directory. We
could have abitrary subdirectories to organize by aircraft type or
livery or era
On Mon, 25 Aug 2003 14:51:50 +0200,
Erik Hofman <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Jon Stockill wrote:
> > On Mon, 25 Aug 2003, Erik Hofman wrote:
> >
> >
> >>Regarding ZIP files, is it legal to use the compression algorithm
> >>without any limitations at the moment (f
Curtis L. Olson wrote:
- I'd like to see each aircraft be completely self contained in it's
own subdirectory (except for "standard" base package stuff it could
feel free to reference.) These standard pieces wouldn't necessarily
need to live in the Aircraft subdirectory too.
- We would elimi
Erik Hofman writes:
> Curtis L. Olson wrote:
>
> > If nothing else we should first work on being able to have completely
> > self contained aircraft trees (rather than needing a -set.xml file in
> > one directory (possibly the aircraft fdm config in another direcotry)
> > and everything else in a
Curtis L. Olson wrote:
If nothing else we should first work on being able to have completely
self contained aircraft trees (rather than needing a -set.xml file in
one directory (possibly the aircraft fdm config in another direcotry)
and everything else in a separate area.)
The directory layout I'v
Erik Hofman writes:
> James Turner wrote:
>
> > Oh, I just did some browsing of the SSG loaders they're full of
> > fopen / fseek calls. Damn. Much work to be done there, I think.
>
> Yep, although the AC3D load doesn't use seek. I was thinking of moving
> the SGI texture loader and AC3D
James Turner wrote:
Oh, I just did some browsing of the SSG loaders they're full of
fopen / fseek calls. Damn. Much work to be done there, I think.
Yep, although the AC3D load doesn't use seek. I was thinking of moving
the SGI texture loader and AC3D model loader over to SimGear and declar
James Turner wrote:
On Monday, August 25, 2003, at 11:57 am, Erik Hofman wrote:
As a unix user the first thing that comes to my mind is off course tar
and gzip (or maybe bzip2). I am aware of the limitations of the tar
format, but the scan once for a TOC method seemed fast enough for me.
For
On Monday, August 25, 2003, at 02:44 pm, Erik Hofman wrote:
Not necessary, it is mainly the number of files that causes the
slowdown. You can jump from one info block to another without actually
reading any date in between them (there is a pointer in the current
info block that points to the n
Jon Stockill wrote:
On Mon, 25 Aug 2003, Erik Hofman wrote:
Regarding ZIP files, is it legal to use the compression algorithm
without any limitations at the moment (for example GIF has a similar issue).
I thought the LZW patent had expired?
At least not in Europe. You'll have to wait until 200
On Monday, August 25, 2003, at 11:57 am, Erik Hofman wrote:
As a unix user the first thing that comes to my mind is off course tar
and gzip (or maybe bzip2). I am aware of the limitations of the tar
format, but the scan once for a TOC method seemed fast enough for me.
For very large archives, I
On Mon, 25 Aug 2003, Erik Hofman wrote:
> Regarding ZIP files, is it legal to use the compression algorithm
> without any limitations at the moment (for example GIF has a similar issue).
I thought the LZW patent had expired?
--
Jon Stockill
[EMAIL PROTECTED]
___
James Turner wrote:
I did a bit of background research on the packaging / bundling issue,
partly for my own curiosity, and in the vague hope of helping someone
who wants to take a crack at this..
This is a nice summing of the possibilities.
As a unix user the first thing that comes to my mind is
I did a bit of background research on the packaging / bundling issue,
partly for my own curiosity, and in the vague hope of helping someone
who wants to take a crack at this..
Essentially, anyone who's installed add-ons for MSFS (any version)
knows what a pain it is, and uninstalling them is ne
20 matches
Mail list logo
