Self generated parkpos GIT Repo 2.5.0 / OSG #377 FGFS failed

[D-ABBA]

Hello FlightGear friends,

I am an FlightGear user since 2009. I solve problems with the topics in the Forum. Thanks for that.
But now I am to be at a loss.

I create an Custom Scenery (DABBACustomScenery_V3). You can fetch it at http://www.marc-kraus.de/fg .
It´s an assembly of a view known customs and four airports (EDGS, EDFH,ELLX,EDFE). Placing Enviroment. Using tiles
of the official Scenery from FlightGear and the airport datas (apt.dat.gz). Of course I create parkpositions, to using for.

Now my problem:
up of Jenkins OSG #377 (-->I use FlightGear GIT-Repositry (Version 2.5.0)). I cannot start with my aircraft on my definded parkpositions. FlightGear doesn´t start with error "Bad Gateway 2xx, no pushpack route defined...". Startup, for example, on EDDF V107 and change the location after start (Position Aircraft on Ground) to an from me defined parkposition.
That´s possible.

Thanks for your Help
D-ABBA
(CitationII,777-200,787-8,b1900d,SenecaII...)

[durk]

Hi,

This is a part of the AI/ATC integration, in which the ATC part now tries to find a route to the active runway for the user controlled aircraft. I'm working on a fix for this (note that the uneven version number 2.5.0 indicates that you're running a development version, where some instability might be expected).

Cheers,
Durk

[D-ABBA]

Thanks for your help,

Please tell me when the problem is solved. I hope thats my self defined parkpositions are usable...

Bye and see you in FlightGear World...

D-ABBA

[durk]

You're Welcome.

Just to follow up my previous message (which I actually wrote while in a hurry), I would recommend you to have a look at following description on how to build ground networks / adding parking positions using taxidraw:

http://wiki.flightgear.org/Interactive_ ... he_network

The "proper" solution for your problem would actually to build a full fledged ground network, because that's actually how parking positions were designed to function. Nevertheless, I will investigate how FlightGear should be able to deal with partially implemented ground networks.

Cheers,
Durk

[clrCoda]

Durk gives the "proper" solution, but I can give you a good temporary hack to get your parking positions while you wait for developers to fix the actual problem.

If you have in your launching program, such as FGrun for instance, a listing for a parking position in the airports list, and then try to load and you end up on the runway, you may find that you do not have a needed parking definition in the proper folder under the correct name.

If, like above you do have a listing in FGrun, then you can go to "flightgearDirectory"\data\AI\Airports\"folder of the airport in question"\ and there will be a parking.xml file in that folder, if and only if you DO have a position in the FGrun airports selection. If you don't then you can create a parking position xml file.

But for now, lets say that you DO happen to have this file. You can use that file and move it to another folder so that you start in the parking position and not in the runway when you select the parking position in FGrun.

Copy the "folder of airport in question"\parking.xml and put it in a folder in your terrasync directory.

For instance, if you wanted to do this for EDDF then You would go to your

"flightGearDirectory"\data\AI\Airports\EDDF\
folder and copy the parking.xml and then put the copy in

"flightGearDirectory"\terrasync\Airports\E\D\D
folder and rename the parking.xml to
EDDF.groundnet.xml


If you do not already have a file in either one of these folders, then you can make one using the idea that I outline here

viewtopic.php?f=21&t=13013&p=133466#p133301


Ray

[durk]

Durk gives the "proper" solution, but I can give you a good temporary hack to get your parking positions while you wait for developers to fix the actual problem.

Hi Ray,

Thanks for your comments, but I'm afraid that D-ABBA, problem is rather different from the one you describe. Your problem related to our recent switchover between the locations of the ground network within the file system (marking a change between fgfs 2.0.0 and fgfs 2.4.0), whereas D-ABBA's problem relates to a new use of the ground network by the ATC controller. Moving files to differnt location is not going to help in this case.

Cheers,
Durk

[clrCoda]

Thank you, Durk, for the correction. I must have lost the point of the conversation in translation. I had assumed that D-ABBA was trying to get a custom parking position to work now when it used to work when ever it used to work. ( shesh is that a proper sentence?)

If you do not mine, what is D-ABBA really talking about? Now I am truly confused. Is there some form of system that allows one to form parking positions automatically? Is that what this is about?

Much thanks for education,

Ray

[durk]

The problem described by D-ABBA basically comes down to the fact that he's using the new development branch of FlightGear, which contains some very new code that uses the ground network for allowing the ATC system to plan a route between the current parking position and the active runway. This code, however, relies on the requirement that the currently selected parking is connected to the runway. Earlier versions of FlightGear would except ground networks consisting of only parking positions, without them being connected to the runway. My own preference would be that we only allow fully working ground networks in FlightGear, but I can see that this is a slightly draconian requirement for a lot of situations that don't require any ATC / AI involvement, but do require the presence of a parking position. For this reason, I'm trying to come up with a good compromise between silently shutting down the ATC subssystem in cases of an incomplete ground network, vs. flagging it as an error.

Cheers,
Durk