From: Florent R. <f.r...@fr...> - 2022-08-23 20:39:36
|
Florent Rougon <f.r...@fr...> wrote: > If I remove the final 'else' clause, it works. AIUI, one of the > providers ignores the 'aContext' argument which is somewhat inconsistent > with 'aResource' in these cases... or does something stranger. The two immediately visible problems when the final 'else' keyword is kept are: 1) Weird splash screen font: this is because in src/Viewer/splash.cxx, the font is specified with SGPath path = globals->resolve_resource_path(fontFace); and resolve_resource_path() is defined by: SGPath FGGlobals::resolve_resource_path(const std::string& branch) const { return simgear::ResourceManager::instance() ->findPath(branch, SGPath(fgGetString("/sim/aircraft-dir"))); } so, for instance, the ResourceManager receives requests with an absolute path like $FG_ROOT/Aircraft/ufo/Fonts/LiberationFonts/LiberationSans-BoldItalic.ttf, which should really be $FG_ROOT/Fonts/LiberationFonts/LiberationSans-BoldItalic.ttf. This nevertheless “works” in the current state of SG & FG because FGGlobals::set_fg_root() does: simgear::ResourceManager::instance()->addBasePath(fg_root, simgear::ResourceManager::PRIORITY_DEFAULT); which looks for the resource under $FG_ROOT using the 'aResource' argument of ResourceManager::findPath(), ignoring its 'aContext' argument (the addBasePath() call adds a BasePathProvider). Problem solved by replacing the above line from src/Viewer/splash.cxx with e.g.: SGPath path = globals->get_fg_root() / fontFace; 2) materials.xml can't be loaded (from line 79 of simgear/simgear/scene/material/matlib.cxx). This one is nastier. fgdata/Materials/regions/materials.xml has many lines like: <landclass-mapping include="Materials/base/landclass-mapping.xml" /> <!-- Base materials --> <region include="Materials/regions/global.xml"/> <region include="Materials/regions/global-summer.xml"/> which don't really conform to what I understand as being the intended semantics of 'include=' in PropertyList files: // simgear/simgear/props/props_io.cxx:271 else if( att_name == "include" ) { try { SGPath path = simgear::ResourceManager::instance() ->findPath(val, SGPath(_base).dir()); Here, _base is the path (first arg) that was given to this func: void readProperties (const SGPath &file, SGPropertyNode * start_node, int default_mode, bool extended) i.e., in our case, $FG_ROOT/Materials/regions/materials.xml (an absolute path). Normally, the included path would be interpreted relatively to the dir() of this file, namely $FG_ROOT/Materials/regions. So, the examined paths (in a first step) are: $FG_ROOT/Materials/regions/Materials/base/landclass-mapping.xml $FG_ROOT/Materials/regions/Materials/regions/global.xml $FG_ROOT/Materials/regions/Materials/regions/global-summer.xml etc. Naturally, they don't exist. Like before, this only works, in the current state of SG & FG, because among the registered providers, we have a BasePathProvider whose base path is $FG_ROOT, which will ignore the 'aContext' argument of findPath() and use the first arg as a path relative to $FG_ROOT. So, in this case, the included files are found by the code at the end of ResourceManager::findPath(), not by the part that constructs an SGPath from the 'aResource' and 'aContext' arguments. Cleanly solving this one would probably require restructuring the materials stuff... or adding some variant of readProperties() where included files are looked for relatively to $FG_ROOT (!). Let's say that I didn't buy a ticket for this trip. So, unless someone has a good idea for this one, I'll probably omit the 'else' keyword and add a comment that explains why. Regards -- Florent |