Board index FlightGear Development

an extension to --parkpos

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

an extension to --parkpos

Postby durk » Sat Sep 17, 2011 3:40 pm

just added some new code to src/Main/fg_init.cxx that allows FlightGear's airport dynamics functions to give you a valid parking position without having to bother about the details of whether the parking is of hte right type, whether it is large enough, etc etc. To achieve this, the --parkpos option recognizes the keyword AVAILABLE (in capitals). However, in order to get it to work, you need to set some properties:

/sim/atc/radius: should be a nummeric estimate of the size of your aircraft. A small aircraft fits into a large parking, but a large aircraft does not fit into a small parking space. Because the AI part of radius is also used for slightly different purposes (prioritizing gate assignmments, the given valuem may deviate slightly from the real aircraft size. See http:/wiki.flightgear.org/Aircraft.radii for an overview of currently used values for the redius property.
/sim/atc/flight-type can be any one of "ga", "cargo", "gate", "mil-fighter", "mil-cargo", or "vtol". See http://wiki.flightgear.org/Interactive_ ... erspective for more information.
optionally, the property /sim/atc/airline can be set set to a three letter icao airline code.

In order to simplify the procedure somewhat, I have just committed two small xml to the git fgdata repository, which you can include in your startup sequence. I deliberately keep the number of sample startup setting files small, because the system may still need some fine tuning and I don't want to end up changing hundreds of startup configuration files.

To give a few examples on using the new option:

Starting up a commercial 777 flight at KSFO:
fgfs --aircraft=777-200ER --airport=KSFO --parkpos=AVAILABLE --config=/path/to/fgdata/Startup/777-commercial.xml

Doing the same, but now explicitly requesting the startup location for a specific airline:
fgfs --aircraft=777-200ER --airport=KSFO --parkpos=AVAILABLE --config=/path/to/fgdata/Startup/777-commercial.xml --prop:/sim/atc/airline=UAL

This feature is highly experimental and I haven't had the chance yet to test it out on a great variety of airports (specifically not on ones without ground networks), so please use with care, but have fun. :-)

Obviously, you do need to build from the latest source or get a recent snapshot dated Sept 17 or later for this to work.

Cheers,
Durk
durk
 
Posts: 352
Joined: Mon Nov 17, 2008 1:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: an extension to --parkpos

Postby D-EKEW » Sun Sep 18, 2011 1:50 pm

Hi Durk,

Since you are working on park positions anyway, did you see my feature request in the 'new features' section of this forum for an aircraft park position offset?

Thanks,

Eric
D-EKEW
 
Posts: 160
Joined: Mon Jan 10, 2011 8:22 pm
Callsign: D-EKEW, ELLX-TWR
Version: git
OS: Linux

Re: an extension to --parkpos

Postby durk » Sun Sep 18, 2011 7:24 pm

Hi Eric,

I saw your proposal, but initially wasn't really sure how to best implement it. As I was looking at the code, I did keep an eye on possible ways of implementing your request. Technically, it should be really easy to do, but my new code might require some changes to the aircraft -set.xml configuration anyhow. Your requested feature would probably need a property similar to the radius property I introduced; in other words a new property describing a physical aircraft dimension.

On the mailing list we've been discussing some alternatives to my current proof-of-principle solution. I'd like to include your offset proposal there as well.

Cheers and thanks for the suggestion,
Durk
durk
 
Posts: 352
Joined: Mon Nov 17, 2008 1:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: an extension to --parkpos

Postby skyop » Sun Sep 18, 2011 7:36 pm

Support just added to the CRJ700 and pushed to its Gitorious repository. This is a neat feature, looking forward to seeing it implemented. :)
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3047
Joined: Mon Jun 14, 2010 12:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

Re: an extension to --parkpos

Postby D-EKEW » Sun Sep 18, 2011 8:29 pm

Hallo Durk,

making an offset will need a change in the -set file as every aircraft has a different length of course. Personally I would handle is just like the runway offset, so no change in the groundnet.xml needed.
Hope it gets implemented one way or the other.

Cheers,

Eric
D-EKEW
 
Posts: 160
Joined: Mon Jan 10, 2011 8:22 pm
Callsign: D-EKEW, ELLX-TWR
Version: git
OS: Linux

Re: an extension to --parkpos

Postby durk » Mon Sep 19, 2011 6:27 am

Hi Eric,

Yeah that's what I am thinking. All you'd need is an extra line in the Aircraft's -set.xml file, and probably two or three lines of additional code in FlightGear itself. No need to change the ground network. But, having said that, I do need to point out that many ground networks are relatively rough estimations of the airport layout, sometimes made independently of the buildings. Unfortunately, we currently don't have an editor to precisely match the parking locations to the buildings. I've been thinking about building in a way to make manual corrections to the gate's positions from within FlightGear. But, this may still take a while.

@Skyop:
Cool, It would be nice to see how you have implemented this. But please be aware that my code is in a very early stage of development and subject to discussion and change (in terms of the property names; see Stuart's comment on the developers list, and my response to that). So, in general, I'd ask aircraft designers to be reluctant to add these new properties until we have settled on a more permanent naming convention.

cheers.
Durk
durk
 
Posts: 352
Joined: Mon Nov 17, 2008 1:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: an extension to --parkpos

Postby D-EKEW » Mon Sep 19, 2011 3:20 pm

Evenin' Durk,

Right, that is one of the problems I encountered. I started of developing ELLX by making a groundnet file with park positions. I took the positions (lon/lat) from the official airport charts in my utter ignorence I could model the airport to the meter precise.
Then some time later after I actually placed buildings as good as I could, I noticed the parking positions were not correct relative to the buildings (talking about 1 - 10m). Further I noticed aircraft were spawning half in buildings...so that is why I asked for the offset feature.

The problem is you have to make the airport lay-out with taxidraw (or WED in the future) and place buildings with the ufo. Both can be very inaccurate if you are not carefull. One thing you can do is place markers while doing the layout as for instance windsocks are translated to the scenerey .stg files by genapts. However not everyone is able to get terragear running. So you are back to doing everything as accurate as possible...

Of course I had the 'luck' of developing the entire airport new and I could correlate (and 'correct') the parkpositions with the buildings later. Other airports may have multiple developers (over time) and would care only for the buildings or only for the parkposition, which will create problems. And that is where a feature like you describe would come in handy. Sounds rather difficult to implement though...

Until then: If scenery and aircraft developers keep in mind that parking positions are defined at the aircraft nose wheel (not sure about taildragger?) we are oke :) .

Thanks,

Eric
D-EKEW
 
Posts: 160
Joined: Mon Jan 10, 2011 8:22 pm
Callsign: D-EKEW, ELLX-TWR
Version: git
OS: Linux

Re: an extension to --parkpos

Postby durk » Thu Sep 22, 2011 8:24 pm

It looks like we have now settled on a more or less permanent solution:

There are now four new properties you need to set, in order to get automatic parking locaton selection working:

Code: Select all
/sim/dimensions/radius-m
/sim/dimensions/parkpos-offset-m
/sim/aircraft-class
/sim/aircraft-operator


As an example of how to use these properties, I have added the following section to the 777-200ER-set.xml file:

Code: Select all
     <sim>
        ....
        <dimensions>
            <radius-m type="double">32</radius-m>
            <parkpos-offset-m type="double">0.0</parkpos-offset-m>
        </dimensions>
        <aircraft-class type="string">gate</aircraft-class>
        <aircraft-operator>BAW</aircraft-operator>
        <aircraft-data>
            <path>/sim/dimensions/radius-m</path>
            <path>/sim/dimensions/parkpos-offset-m</path>
            <path>/sim/aircraft-class</path>
            <path>/sim/aircraft-operator</path>
        </aircraft-data>
        ...
      </sim>


In addition, I modified the Livery Select files, (i.e. the xml files located in Models/Liveries as follows:

BA.xml:
Code: Select all
<?xml version="1.0"?>
<PropertyList>
<sim>
    <model>
        <livery>
            <name type="string">British Airways</name>
            <texture>paint1.png</texture>
        </livery>
        <lights>
            <texture>lights1.png</texture>
        </lights>
    </model>
    <aircraft-class>gate</aircraft-class>
    <aircraft-operator>BAW</aircraft-operator>
</sim>
</PropertyList>



DL.xml:
Code: Select all
<?xml version="1.0"?>
<!-- Delta Airlines 777-200ER Livery by Michael Smith <mdsmith2@highland.net> -->
<PropertyList>
<sim>
    <model>
        <livery>
            <name type="string">Delta Airlines</name>
            <texture>DAL-Livery.png</texture>
        </livery>
        <lights>
            <texture>DAL-Lights.png</texture>
        </lights>
    </model>
    <aircraft-class>gate</aircraft-class>
    <aircraft-operator>DAL</aircraft-operator>
</sim>

</PropertyList>


KLM.xml:
Code: Select all
<?xml version="1.0"?>

<PropertyList>
<sim>
    <model>
        <livery>
            <name type="string">KLM Royal Dutch Airlines</name>
            <texture>KLMlow.png</texture>
        </livery>
        <lights>
            <texture>KLMlow-lights.png</texture>
        </lights>
    </model>
    <aircraft-class>gate</aircraft-class>
    <aircraft-operator>KLM</aircraft-operator>
</sim>

</PropertyList>


This way, you can ensure that your previously selected livery is taken into account when choosing a parking location.

Also, if you were to make a military livery (for example), you would change <aircraft-class> to mil-transport in the corresponding livery file.

Note that the system is still relatively new, and I probably need to test more cases, but the basics appear to work.

Finally, note that parkpos-offset-m doesn't work yet! It should be trivial to implement this, but I haven't had time to do so yet.

Cheers,
Durk
durk
 
Posts: 352
Joined: Mon Nov 17, 2008 1:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: an extension to --parkpos

Postby Gijs » Thu Sep 22, 2011 9:16 pm

Right, I know what to do the upcoming weeks :-P
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9311
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: an extension to --parkpos

Postby durk » Thu Sep 22, 2011 10:11 pm

Updating a livery database... :-)
durk
 
Posts: 352
Joined: Mon Nov 17, 2008 1:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: an extension to --parkpos

Postby adrian » Fri Sep 23, 2011 8:59 am

Is this going to modify the fleet-info/aircraft.txt format? I'm working into storing that in the database along with fleetinfo.txt.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: an extension to --parkpos

Postby durk » Fri Sep 23, 2011 9:35 am

Hi Adrian,

No, this is only relevant for user controlled ("real") aircraft; the AI system is unaffected by it.

Cheers,
Durk
durk
 
Posts: 352
Joined: Mon Nov 17, 2008 1:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: an extension to --parkpos

Postby adrian » Fri Sep 23, 2011 10:16 am

Allright then.
Don't know if you saw that, but I pushed revised Alitalia and AirFrance, because I found some wrong IATA codenames in airports.dat, leading to wrong ICAO airports.
Just a heads up in case you were preparing to upload them.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: an extension to --parkpos

Postby VaLeo » Sun Sep 25, 2011 9:46 am

durk wrote in Mon Sep 19, 2011 6:27 am:Unfortunately, we currently don't have an editor to precisely match the parking locations to the buildings. I've been thinking about building in a way to make manual corrections to the gate's positions from within FlightGear. But, this may still take a while.



I'v done it some time ago for personal purposes.
Script generate .stg from .groundnet, so you can see where parkpos is and its size and rotation.
Then I convert .stg to config .xml, load it with UFO, edit parkpos as objects, export to xml and convert it finally to .groundnet.
Thats my convertors are rather lame - I wrote it as my python hello-world programs. But if anyone want to play with it, i'll put it on server.
VaLeo
 
Posts: 186
Joined: Wed Nov 29, 2006 10:00 am
Location: Ukraine, Dnipropetrovsk
Version: GIT
OS: Debian 7

Re: an extension to --parkpos

Postby adrian » Sun Sep 25, 2011 10:19 am

VaLeo wrote in Sun Sep 25, 2011 9:46 am:I'v done it some time ago for personal purposes.
Script generate .stg from .groundnet, so you can see where parkpos is and its size and rotation.
Then I convert .stg to config .xml, load it with UFO, edit parkpos as objects, export to xml and convert it finally to .groundnet.
Thats my convertors are rather lame - I wrote it as my python hello-world programs. But if anyone want to play with it, i'll put it on server.


That's a very clever trick you did there, which I can see as very useful. I was thinking about the reverse, generating groundnets for airports which lack them from the apt.dat data. Usually those airports don't have 3d models, so gate positions would not be critical. But it's just a thought at the moment, because there are lots of issues to be considered here.
Please do put your code on the web, I'd like to take a look myself when I get the chance.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Next

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest