Old 744 Forum

Archived posts

Flight planning add-ons and PSX company routes

Page: 1

Author Post
Moderator
Registered: May 2009
Posts: 5140
Good evening,

PSX will contain a lot more data in a route than PS1 did. For example, legs may contain RNP data, arc descriptions, vertical path angles etc. pp. Also the route header contains more than just the departure runway, it also contains runway elevation etc. because this stuff makes network syncing easier and faster (less database search actions).

I understand that external flight planning software can't fill all these data when auto-generating an FMC company route for PSX.

For this reason, I want to provide a "light" route format sufficient for essential route data only. Add-ons can copy the route file to a certain PSX folder so that the PSX user can load it into the PSX FMC when desired. During the loading, PSX will generate its internal files for the final operation in the PSX network.

Now, the question is, what data are essential? What variables should the "light" route format be able to store?

Suggestion:

General data:
1. Company route name (the file name itself)
2. ICAO codes of origin and destination airports
3. Departure runway
4. Flight number
5. Cost index (if pre-computed)
6. Initial cruise altitude (if pre-computed)

Data in each enroute leg:
1. Fix identifier
2. Fix lat/lon
3. Airway* identifier or "direct" flag

* or SID, STAR, approach and transition identifiers (if already known)


Obviously, this "light" format cannot store conditional waypoints. These would require the "heavy" format which PSX internally uses and which provides variables for path and termination, speeds, altitudes etc. pp. The "heavy" format is available per network and situation files, in case someone wants to work with that. But my question here is referring to an easy enroute format -- as a special option --, so that flight planners can easily generate a company route for PSX.

Another file is planned for injecting enroute waypoint winds and OATs. This could be done on the Instructor's Dispatcher page or from an external add-on. PSX may load the data into its FMS as well as into its dynamic tropopause weather model, so that the virtual FMS and the virtual planet agree (with some slight random variations). In other words, the waypoint weather data are definitely not stored in the route file, neither in the light nor in the heavy route format. It'll get a separate file.

As usual in PSX, variables are stored in ASCII text format. No binary hacking required.


Cheers,

|-|ardy
« Last edit by Hardy Heinlin on Mon, 21 May 2012 14:32:23 +0000. »
Member
Registered: May 2009
Posts: 479
Location: EFTO
Moi,

Hardy wrote
variables are stored in ASCII text format.

For anything used by add-ons, would some kind of XML format (not necessarily strictly DTD-compliant) be a good idea?

Still ASCII/human-readable, but would presumably make add-on jobs considerably easier (because they could then use a known logical structure, for which lots of tools are available, instead of having to parse strings, fiddle with regex, and such). Might e.g. help with making converters from other flightplan formats to PSX, for which there might be demand.

"Just an idea"...

Cheers,
Martin
Moderator
Registered: May 2009
Posts: 5140
Moi,

XML is sooo bloated. Also, I would have to write extra code just to parse XML tags per se, alone, before I can even start parsing the real flesh.

<FirstWord>XML</FirstWord><AnotherTag>is</AnotherTag><MondayOfAugust>sooo</MondayOfAugust><AuntMarysFamilyName>bloated</AuntMarysFamilyName>

As far as I see, 90% of all flight sim add-ons do not use XML. So, an XML standard wouldn't help anyway.

If I would suggest a standard -- if at all -- I would suggest the ARINC 424 standard.


Cheers,

|-|ardy
Member
Registered: May 2009
Posts: 202
Location: Sydney, Australia
I guess we need to get Christian Grill from Topcat and PFPX to answer
http://www.pfpx.com/
_______________
Moderator
Registered: May 2009
Posts: 2449
Location: KTMB
Suggestion: allow the light format to be loaded into the FMC as well, to build ACARS route uploads. It can be from a file, but not by asking for a name. I typically used a file acars.rou for PS1; PSX could do the same. If file present, offer LOAD> button, or such.

Jeroen
Member
Registered: May 2009
Posts: 479
Location: EFTO
Hardy Heinlin wrote
XML is sooo bloated. Also, I would have to write extra code just to parse XML tags per se, alone, before I can even start parsing the real flesh.

Well, with the XML tools you wouldn't necessarily have to "parse", that's the point. I was thinking of jobs such as "find all the names (but not coordinates) of waypoints which belong to a SID"
Assuming of course that there is a logical structure (hierarchy) to begin with, such as
SID
----Waypoint
--------Name
--------Lat
--------Lon
and so on, the tools could pick out the desired elements via the logical structure, without one having to do low-level line-by-line parsing at all.

Then again, obviously XML is extra overhead, esp. on the "production" side (i.e. just making routes, not processing them).

Hardy Heinlin wrote
As far as I see, 90% of all flight sim add-ons do not use XML. So, an XML standard wouldn't help anyway.


Well, at least the add-on would have to impose some structure (as opposed to linear sequence of text lines) only on the external side... :)

Anyhoo, probably best to wait for practical use cases, and experiment.

Cheers,
Martin
Member
Registered: May 2009
Posts: 309
Location: Winchester, UK
I agree with Matt, that it would be great to be able to receive FPs from PFPX. I hope that PFPX will become THE tool for those wanting extremely realistic plans.
_______________
Cheers, Richard
Moderator
Registered: May 2009
Posts: 5140
Good morning.

Matt, Richard, I was about to post a message there, but my forum account needs to be reactivated first (I informed them; guess it got lost during their move). Anyway, I assumed there are more flight planners available than just one.

Jeroen, that is exactly the plan.

Martin, such a logical structure would be given in the ARINC 424 format as well. You know how trivial the parsing of a 424 text line is :-) (not ironically meant).


Cheers,

|-|ardy
Moderator
Registered: May 2009
Posts: 2449
Location: KTMB
Don't do XML.

Don't.


Jeroen
Member
Registered: May 2009
Posts: 958
Location: Chicago
mcdonar wrote
I hope that PFPX will become THE tool for those wanting extremely realistic plans.


I hope that PFPX will be available for mac...
_______________
Will /Chicago /USA
Moderator
Registered: May 2009
Posts: 5140
I just rejected the idea of providing two formats (light and heavy).

I'm cleaning up the heavy format, and that will be the universal format then.

Variables that add-ons don't know just need to be filled with zeroes, or with an early semicolon separation (if the rest of a data block is blank anyway).

I just thought I keep these optional variables because some of them, like RNP for example, may be very useful, and add-ons that use ARINC files will know the RNP values.

Otherwise, RNP would get into the FMC only when the airway (or terminal procedure) is entered in the PSX FMC by the PSX pilot. Entering a company route which contains no RNP will delete all RNPs in the pilot entered route.



|-|


Edit: Just checked the 424 format for company routes; there's no RNP field. Of course not. There are no lat/lons either, as we know. Just VIA and FIX fields. This stuff should be loaded from the FMC's database. But if we would use this "official" method and if the add-on's and PSX's nav databases are not 100% identical, it could happen that a fix or via may not be found. Using lat/lons in the company route avoids this problem. OK, let's keep the lat/lon method and PSX will load the RNP on the fly for the active leg only, provided the leg has a VIA entry (required to find the RNP in the airway database for this leg).
« Last edit by Hardy Heinlin on Wed, 23 May 2012 02:16:49 +0000. »
Moderator
Registered: May 2009
Posts: 2449
Location: KTMB
You could try to stick to 424 and add lat/lon or other additional fields as an option "at the end of the line". If left empty, the loader will try to match the FMC database. If not found there, the waypoint is dropped. Since the pilot is assumed to review the route no matter where it came from, this should mostly work.


Jeroen
Moderator
Registered: May 2009
Posts: 5140
Yes, agreed.

Page: 1

Old 744 Forum is powered by UseBB 1 Forum Software