On Wed, 5 Apr 2006 15:17:14 +0200
Melchior FRANZ wrote:
>
> The idea that all the taxi/runway-signs would flood the fgfsdb is rather
> ridiculous. Are windsocks in the fgfsdb? No. The *.stg files are for
> static objects, period. This has *nothing* to do with the fgfsdb.
> The question was neither if we want those signs (of course we do), or
> if they are static objects (of course they are), but only how they
> should be created. I think it makes the most sense to use the existing
> (yet to be fixed) OBJECT_{RUNWAY,TAXI}_SIGN mechanism, because of the
> sheer number of possible combinations. Probably less effective methods
> would be to use "animated" xml/ac files (tex_translate etc.), or the
> use of render-to-texture.
>
> Of course the signs would have to be placed automatically, while manual
> corrections/additions should always be possible. Just like for
> windsocks, beacons etc.
We do indeed place the windsocks and beacons automatically; we're able
to do that because their positions are specified in the apt.dat file.
But plenty of other airport facilities with known positions, such as
ILS glideslope/localizers, inner/middle/outer markers, etc., *are* in
the object database, despite similar knowledge of location in fgfs
standard files. In principle, those could be handled the same way as
the beacons and windsocks; but right now, they're currently in the
fgfsdb. I don't see that as "ridiculous". But I agree with you that
if there's no need to place a million new objects in the db to cover
the signs, that's preferrable (like I said, the best way to solve that
problem was a holdup for me to continue in the first place).
-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
signature.asc
Description: PGP signature
