Change "Prepar3D v4 Add-ons" dir

[Lorby_SI 2,038]

1 hour ago, SimonC said:

That would mean that one shouldn’t have trouble even if having multiple textures with same name in multiple folders.

The sim doesn't care about folder names. The content element requesting a texture, effect or sound usually does this by only providing the file name, without the path and mostly even without the ending. How would the sim know which one to load if there are many files with that name? So it just yields the first one.This is nothing new either, it has always done that if you had for example the same content library bgl in multiple sceneries in different flavors - only the first one found was used, resulting in black objects if the developer used an updated version of the same library in another scenery that had higher priority. 

Btw. is it certain that external files of the same name override internal ones now? It used to be the other way around IMO, the sim returned the first file that it found, not the last one - ?

Best regards

[vgbaron 3,627]

9 hours ago, Lorby_SI said:

Btw. is it certain that external files of the same name override internal ones now? It used to be the other way around IMO, the sim returned the first file that it found, not the last one - ?

I believe that what simbol is saying is that the add-on.xml method established the search priority so that IT is the FIRST searched and used which would obscure the default *IF* they both had the same name.

That is MY understanding - not set in stone.  

Vic

[simbol 5,821]

Well at least Vic understood me! I will have a drink for that!! 

Simbol 

[SimonC 116]

On 10/29/2017 at 7:54 PM, downscc said:

As for where stuff goes on my machine, all my non-Orbx scenery addons use the xml method regardless of how the developer installs it. I put restrictions on what I allow, for example most will create folders for each product which I modify to one folder for each developer and all their products go in the same xml file.  Less clutter.  Also, if the developer opts out of the auto discovery method I will undo that and force it into my method such that all addons are done the same way with the exception of 12bPilot's SODE which has a logical framework and works so I leave alone. Maybe it's my OCD but I don't allow developers like FSDT to list both scenery and texture components.  All my scenery component paths are to the folder the contains the scenery and texture subfolders and with over 100 addons this seems to work well enough.  Just keep it simple and uniform.  My practices work for all scenery except Orbx of course and I suspect they will start using the xml method in the future just as I think PMDG will too... they have had a full plate just keeping up with multiple platforms and did not want to change their installer method in the middle of that.

Hi Dan,

could you please take a little time and explain this a bit better? I'm merely trying to build my own system (even if it resembles yours), so I can actually start adding addons.

What I understand (or don't):

When you say folder per product, you mean for instance folder per airport? Because if not doing that, how else? When you say per dev, that would mean mixing scenery files into one folder, for instance say you've got Aerosoft EDDF and EGLL, so you would go ahead and merge scenery folders, textures folders etc?

When you say to list both scenery and texture components. What do you mean with list?

And then you mentioned again scenery and texture subfolders - which I thought I understood differently...?

Again, appreciate a bit more detail.

Thanks

[Lorby_SI 2,038]

23 minutes ago, SimonC said:

When you say folder per product, you mean for instance folder per airport? Because if not doing that, how else? When you say per dev, that would mean mixing scenery files into one folder, for instance say you've got Aerosoft EDDF and EGLL, so you would go ahead and merge scenery folders, textures folders etc?

Hi,

this is not about the folders themselves, but the XML definition files that connect the addon to the sim. Many users think that they have to have an XML file for each airport/scenery/aircraft etc. This is not true. The XML definitions files can reference thousands of sceneries/aircraft/whatever at the same time. So you just keep a couple of XMLs, for example grouped by geography or by developer, and simply add every new scenery/content to the existing XMLs instead of creating a new one every time. Where you actually install the addon is of no consequence, you tell the sim where it is through the XML file. Only the XML file itself should be in the autodiscovery folder structure (which is \Documents\Prepar3D V4 Add-ons\<anyfolder>\add-on.xml)

Best regards

[SimonC 116]

5 minutes ago, Lorby_SI said:

this is not about the folders themselves, but the XML definition files that connect the addon to the sim. Many users think that they have to have an XML file for each airport/scenery/aircraft etc. This is not true. The XML definitions files can reference thousands of sceneries/aircraft/whatever at the same time. So you just keep a couple of XMLs, for example grouped by geography or by developer, and simply add every new scenery/content to the existing XMLs instead of creating a new one. It doesn't matter where the content folders themselves are, only the XML file should be in the autodiscovery folder (which is \Documents\Prepar3D V4 Add-Ons)

Best regards

Mentally, it's actually very hard to separate oneself from folder per xml concept (doing it like that for past 15+ years doesn't help), yet I do quite well understand that they are not connected. It's also how I understood it in your tool - I can either add to xml or have it create new.

Still doesn't explain completely what Dan said.

Also I'm still confused about what takes precedence - see Beau's linked thread, in which he said that what's "local", takes precedence (as in Effects\Texture).

[Lorby_SI 2,038]

Just now, SimonC said:

Still doesn't explain completely what Dan said.

I think that it does. He is doing the grouping by developer, with a single XML for each dev.

And the second part: when he references sceneries, he is linking the scenery area in the XML (=the top folder with \scenery and \texture it it) instead of linking \Scenery and \Texture separately (which is possible and some developers actually do that)

Best regards

 

[SimonC 116]

Just now, Lorby_SI said:

And the second part: when he references sceneries, he is linking the scenery area in the XML (=the top folder with \scenery and \texture it it) instead of linking \Scenery and \Texture separately (which is possible and some developers actually do that)

Ah, that is what I was missing. Thank you. I actually always linked the top folder, as it was the case with scenery.cfg.

I edited thing about precedence above... (you answered too fast )

[Lorby_SI 2,038]

26 minutes ago, SimonC said:

I edited thing about precedence above... (you answered too fast )

TBH, I am not sure. My initial tests yielded different results to what most people seem to think - but that may just have been me.There must be more to it than meets the eye. The prevailing theory is, that the file that the simulator finds first takes precedence. Kind of like what would happen if you manually copy the contents of all folders of a specific type (effects,textures,sound) into a single directory without overwriting - only one single file of those that have the same name can survive.

The big question is, where is P3D looking first - into the internal folders of the sim itself or into the XML files. Vic & Simbol suggest that the XMLs are discovered and read before anything else. The actual sequence then is the order of the addon packages in the two add-ons.cfg files, followed by the sequence inside the XML, and last but not least by the order in which the files appear in the file system (like with ATC, where the sim always uses the .gvp file that it finds first, no matter how many there are and what they are called).

Scenery works differently, because sequence can be forced with the Layer tags.

Best regards

[SimonC 116]

When you say Scenery, you mean Addon-Scenery-Folder which contains both scenery and textures folders, and is as such added to the xml? It's somewhat confusing for me to understand what we are sometimes talking about. Component is everything. But two components, scenery and texture, when added with parent-folder, is called what officially?

And if FSDT is doing that, what is wrong about that? Because according to LM, we only have Scenery component, which doesn't imply textures-folder per se. But if there is one, how does it go about recognizing it automatically, if it's true what Beau said?

I'm getting dizzy...

 

And if I understand it now, hopefully correctly, when you start adding Components, like effects, no matter what you set under path, these components are always used globally, as in for the whole sim. And it would be *really* stupid of LM to not implement a safeguard really, as in local texture search will first look into local folder (e.g. \scenery in \texture, \effects into \effects\texture etc.). Because you can't really "limit" it with an xml. Only my opinion.

[vgbaron 3,627]

12 minutes ago, SimonC said:

I'm getting dizzy...

And you haven't even started!!  It took me a while and I still have to stop and think it through. What makes it worse is the Scenery Library and the Scenery.cfg file are ordered in complete reverse. In the SL the entries are read from the highest number to lowest with the lowest having the highest priority. The scenery.cfg file lists them from lowest to highest with the highest having top priority.

fun times.....

Vic

[Lorby_SI 2,038]

17 minutes ago, SimonC said:

scenery and texture, when added with parent-folder, is called what officially?

Scenery Area. Just like it always was.

What is wrong with keeping them separate? Nothing really. Or everything. Depends on your point of view and on the spec- if it says "scenery" or "scenery area".

"Stupid": well, all of those components are global entities unless you consciously make them local. Always have been. In the old days, devs had to use unique file names for effects or gauges too if they plonked them into the global folders. Can't see any reason to get sloppy now, quite the contrary.

Best regards

 

 

[SimonC 116]

3 minutes ago, Lorby_SI said:

unless you consciously make them local.

What do you mean by that? How do you define them as local? We are just saying this whole time they are always global...

[Lorby_SI 2,038]

8 minutes ago, SimonC said:

What do you mean by that? How do you define them as local? We are just saying this whole time they are always global...

For example, developers can decide to put their gauges into the aircrafts panel folder, instead of the global directory. Use unique filenames. Things like that. Nothing the user can do though.

Btw, just had a look into the SDK documentation in the learning center. When it describes the addon components (SDK->Add-Ons->Addon packages) it says

Quote

Scenery - Refers to a component that adds an additional scenery area to Prepar3D's world.

Notice "scenery area", not "scenery". So keeping \scenery and \textures separate IMHO is against the spec.

Best regards

[SimonC 116]

9 minutes ago, Lorby_SI said:

Notice "scenery area", not "scenery". So keeping them separate IMHO is against the spec.

Well spotted. I would have understood it the other way though. Component scenery adds a scenery area. It doesn't say "with texture-folder". So maybe it is their intention to separate everything, even texture from scenery area. Strike that: because \texture is read when you add a scenery area. So that means your IMHO is right. I am throwing in a towel for today