Resolving Paths

This article is a stub. You can help the wiki by expanding it.

SimGear has a "path resolving" function that takes a relative path and outputs an absolute path using various mechanisms to generate plausible paths. In FlightGear, you can do this is in C++ with SGPath resolve_maybe_aircraft_path(std::string&) and Nasal with resolvepath() (which returns an empty string if the path could not be resolved).

Paths searched

Given a relative path path, the following places are tried:

1. High priority:
   • If path starts with "Aircraft/":
     1. If the second part of the path matches the last part of the current aircraft directory (aka the directory of the *-set.xml file). E.g. "Aircraft/f16" and "/some/outside/dir/of-aircraft/f16".
        • {/sim/aircraft-dir}/{rest of path}

        If there is no existing file at this path, the search stops here in order not to use files from other versions/forks of the current aircraft that might be present in $FG_AIRCRAFT.

     2. $FG_AIRCRAFT/{path minus Aircraft/}
   • {/sim/aircraft-dir}/path — see note below
2. Default priority:
   • $FG_ROOT/path
   • $FG_HOME/path

Note that the levels are numbered if they occur in a fixed order or bulleted if the order is unspecified.

Best usage

Caution  As far as I can see, if users could freely choose the name of their aircraft directories it would be impossible to find the model for a remote player with any certainty short of searching for it based on something else than its name/path. The model file name alone can in no way be assumed to be unique, whereas the expectation that the <aircraft-directory>/Models/<foo>.xml path could be kept unique is somewhat higher. — AndersG (Jan 5th, 2016). Re: Late Christmas/Early New Year present from Kerdigarage. (powered by Instant-Cquotes)

NOTE: Using the short path ("Models/f16.xml") as suggested here for the path to the main 3d model file in the -set file will mean that the aircraft cannot be shown over MP as not all of the information needed to find the model is transmitted over MP then. (The string is sent as is, and "Models/f16.xml" is just not enough to find the right model in the right aircraft directory.)

In the 2.10 release, the rule above allowing paths relative to the current aircraft directory was introduced (e.g. "Models/f16.xml" works instead of "Aircraft/f16/Models/f16.xml"). One of its benefits is solving the problems related to moving aircraft around: one could not simply move "Aircraft/f16" to "Aircraft/f16-modded" and expect the aircraft to work normally, due to the many links using the latter example above. However, if all aircraft paths used the aircraft-relative style, renaming would pretty much be possible. (Btw: Has anyone tested this?) Thus, aircraft developers are strongly encouraged to use aircraft-relative paths in all of their code.