[Flightgear-devel] Scenery vs. Base Package; Was: Revision Log / Intended developments
Durk,
Durk Talsma wrote:
Ralf Gerlich and Martin Spott: Complete scenery rebuild based on improved
terragear algorithms / object database updates
In the current state, after setting a deadline, we should be able to
get an entire Scenery release out from the current datasets within just
a few days _plus_ maybe a week of testing in a small circle of people
most of the people we asked didn't respond anyway ;-)
There's one real show stopper - not to the FlightGear release but,
instead, to the Scenery releases, which on the other hand is related to
the way FlightGear reads airport data:
As mentioned before, the Scenery releases are currently tied to the
Base Package because several positions are read from the 'apt.dat', the
'rwyuse.xml' and the 'parking.xml' which is stored in the Base Package.
Now, in order to make each Scenery download package somehow self
contained - nowadays we always have to remain compatible with the
latest official Base Package release - we've been introducing this tree
of XML files in the ${FG_SCENERY}/Scenery/Airports/ directory. It would
be _extremely_ valuable to get FlightGear up to the point to read the
respective positioning information - threshold, ILS, TWR, ground
network and runway use (we might skip the latter) - from this Airports/
tree (having the Base Package as a fallback). Doing so would release
unnecessary burden from the Scenery development and make quite a few
Scenery/Airport contributors happy.
I have the slight hope that the required changes - at least those who
are the most obvious ones to the user (like reading the current startup
position) - might get incorporated in the following effort:
James Turner: Refactoring / unification of Airport and runway code and its
ramifications for AI / ATC / Waypoint managment.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery vs. Base Package; Was: Revision Log / Intended developments
Martin Spott wrote: Durk Talsma wrote: Ralf Gerlich and Martin Spott: Complete scenery rebuild based on improved terragear algorithms / object database updates In the current state, after setting a deadline, we should be able to get an entire Scenery release out from the current datasets within just a few days _plus_ maybe a week of testing in a small circle of people most of the people we asked didn't respond anyway ;-) There's one real show stopper - not to the FlightGear release but, instead, to the Scenery releases, which on the other hand is related to the way FlightGear reads airport data: As mentioned before, the Scenery releases are currently tied to the Base Package because several positions are read from the 'apt.dat', the 'rwyuse.xml' and the 'parking.xml' which is stored in the Base Package. There's another issue. The apt.dat contains more and more heliport definitions. The current genapts tools crashes on these or generates hillarious runways, which obviously are too short for proper normal runway markings. I would have loved to fix that and have genapts generate a proper heliport texture, but that would make the scenery incompatible with the released datapackage. So we might want to include a proper heliport texture (apt.dat knows asphalt, concrete, turf and dirt helipads) in the base package and regenerate the scenery with proper helipads. In the build currently being prepared for release Martin replaced the helipad records by simple taxiway records in order avoid the genapts-trap. He also tried to add a helipad object a few cm above the elevation of the center of the helipad. The additional elevation was necessary to avoid the helipad sinking into the ground. However, either the helicopter now stands above the ground or penetrates the helipad, with hilarious graphical results. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery vs. Base Package; Was: Revision Log / Intended developments
I was wondering what was going on with KCGS. It all makes sense to me now... Cheers, -R. (aka MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as [EMAIL PROTECTED] - Original Message From: Ralf Gerlich [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Sunday, October 5, 2008 8:40:33 AM Subject: Re: [Flightgear-devel] Scenery vs. Base Package; Was: Revision Log / Intended developments Martin Spott wrote: Durk Talsma wrote: Ralf Gerlich and Martin Spott: Complete scenery rebuild based on improved terragear algorithms / object database updates In the current state, after setting a deadline, we should be able to get an entire Scenery release out from the current datasets within just a few days _plus_ maybe a week of testing in a small circle of people most of the people we asked didn't respond anyway ;-) There's one real show stopper - not to the FlightGear release but, instead, to the Scenery releases, which on the other hand is related to the way FlightGear reads airport data: As mentioned before, the Scenery releases are currently tied to the Base Package because several positions are read from the 'apt.dat', the 'rwyuse.xml' and the 'parking.xml' which is stored in the Base Package. There's another issue. The apt.dat contains more and more heliport definitions. The current genapts tools crashes on these or generates hillarious runways, which obviously are too short for proper normal runway markings. I would have loved to fix that and have genapts generate a proper heliport texture, but that would make the scenery incompatible with the released datapackage. So we might want to include a proper heliport texture (apt.dat knows asphalt, concrete, turf and dirt helipads) in the base package and regenerate the scenery with proper helipads. In the build currently being prepared for release Martin replaced the helipad records by simple taxiway records in order avoid the genapts-trap. He also tried to add a helipad object a few cm above the elevation of the center of the helipad. The additional elevation was necessary to avoid the helipad sinking into the ground. However, either the helicopter now stands above the ground or penetrates the helipad, with hilarious graphical results. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
