Re: [Flightgear-devel] An extension to --parkpos

2011-09-20 Thread Durk Talsma

On 17 Sep 2011, at 21:45, Stuart Buchanan wrote:

 
 /sim/dimensions/radius-m
 /sim/aircraft-class ?


 It might be worth having this  multi-valued, so classes
 such as WWII fighter can be identified bit as mil-combat, and WWII.
 

Looking at the -set.xml and Liveries/*.xml files in our aircraft database, I 
think that it should be possible to implement this the way you suggested. The 
radius parameter can go into the -set.xml, and the reasonable defaults could 
also be provided there for the /sim/aircraft-class. 

Then it looks like the essential function that the Liveries/*.xml files to is 
override some default values of properties, so it should be easy to implement 
this. I think I would like to settle on the property names as you proposed:

/sim/dimensions/radius-m
/sim/aircraft-class
/sim/aircraft-operator (which has a slightly broader connotation than 
airline). 

In addition, I would propose adding a fourth property:

/sim/dimentions/parkpos-offset-m

As pointed out in the forum, aircraft don't always park correctly at the right 
location, so it would be desirable to specify an offset, which places the 
aircraft with the nose wheel at the parking. 

I'm awaiting furhter comments. I'll probably make a testcase by adding these 
properties to the 777-200ER (locally, just to test), and if there are no 
objections, I'll investigate if there is a way to automate the adding some 
reasonable default values of all our aircraft in the git repositories. (We have 
519 -set.xml files, 821 Liveries/*.xml files). 


cheers,
Durk
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] An extension to --parkpos

2011-09-18 Thread Arnt Karlsen
On Sat, 17 Sep 2011 22:23:57 +0200, Durk wrote in message 
f2886125-96b7-40ff-a334-f92932287...@gmail.com:

 Hi Stuart,
 
 On 17 Sep 2011, at 21:45, Stuart Buchanan wrote:
  
  However, I think that the properties  you've defined have a use
  beyond just ATC, so hiding them under /sim/atc and only loading
  them as additional config feels like a bit of a wasted opportunity
  to me.
  
 Thanks for your comments. Just to expand a little on my previous mail:
 Your quote is exactly the reason why I wrote in my commit log that
 I'm only providing two sample preset files. I expect things to change
 considerably, but just provided these two presets as a test case. 
 
 I also think that radius should get into the aircraft file, because
 it essentially is a physical property. 

..that can also be calculated from e.g. each aircraft's minimum 
taxiing turn radius.

--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] An extension to --parkpos

2011-09-17 Thread Durk Talsma
Hi All,

I 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_traffic#A_technical_perspective for more 
information.
optionally, the property /sim/atc/airline can be set set to a three letter icao 
airline code. By way of illustration, I will commit a number of startup preset 
files setting these properties shortly.

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--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] An extension to --parkpos

2011-09-17 Thread Stuart Buchanan
On Sat, Sep 17, 2011 at 4:37 PM, Durk Talsma wrote:
 Hi All,
 I 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:

Hi Durk,

This looks like a really nice feature. Thanks!

However, I think that the properties  you've defined have a use beyond
just ATC, so hiding them under /sim/atc and only loading them as additional
config feels like a bit of a wasted opportunity to me.

 /sim/atc/radius:

Surely this is simply a set property of an aircraft, and should be set in the
aircraft-set.xml file itself, rather than in some additional Startup
XML fragment?

I'd say it doesn't really belong under /sim/atc as it's a general
physical property
of the aircraft. /sim/dimensions/radius-m perhaps?

(I'm thinking that there are other physical attributes of the aircraft
that might
be of interest in the future - wing-span, length, door location for animated
jetways/stairs, nosewheel location for towing).

Similarly,  /sim/atc/flight-type seems like it should be a more
generic aircraft class
property and should also be in the -set.xml file. It could be used by
launchers and
web pages to filter the various types of aircraft, as well as by ATC
code. How about
/sim/aircraft-class ? It might be worth having this  multi-valued, so classes
such as WWII fighter can be identified bit as mil-combat, and WWII.

I'm think of this from the perspective of an idea I had a long time
ago to allow users
to filter the visible aircraft. So, for example someone might want to
take part in a
WWII fly-in and only see WWII era aircraft by default.

Equally, being able to filter the aircraft in FGRun or the website so you only
see the civilian airliners would seem to be a good idea.

I'd hope that neither of these of these changes would make much difference from
the AI/ATC perspective, but they open up some interesting new features.

-Stuart

--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] An extension to --parkpos

2011-09-17 Thread Durk Talsma
Hi Stuart,

On 17 Sep 2011, at 21:45, Stuart Buchanan wrote:
 
 However, I think that the properties  you've defined have a use beyond
 just ATC, so hiding them under /sim/atc and only loading them as additional
 config feels like a bit of a wasted opportunity to me.
 
Thanks for your comments. Just to expand a little on my previous mail:
Your quote is exactly the reason why I wrote in my commit log that I'm only 
providing two sample preset files. I expect things to change considerably, but 
just provided these two presets as a test case. 

I also think that radius should get into the aircraft file, because it 
essentially is a physical property. For the other two, things are a little more 
complicated. Because they are not as strictly tied to the aircraft itself, but 
more to its use. Although there usually is a strong correlation between the 
aircraft type and it's use, there are some subtle differences. For instance, a 
DC10 would normally be used as an airliner (albeit one that it rapidly 
dissappearing from the skies), but it could also be used as a military 
transport. or tanker (the latter two would probably both match the 
mil-transport flight-type). My gut feeling is that 99.99% of all of these cases 
could be dealt with by the livery select mechanism; If we set the livery to be 
a commercial airliner, the airline, and flight-type properties should change to 
reflect this, and when we want it to be a ga plane, choosing the new livery 
should change these properties accordingly. Just wondering whether the current 
livery select dialog is capable of changing other properties as well. I once 
played with it, but that was a long time ago. 

With respect to changing the property names, that should be easy. They're 
currently used only in one single isolated section fo fg_main.cxx, so it 
changing names, etc. etc. is really easy. 

Cheers,
Durk--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel