Change "Prepar3D v4 Add-ons" dir

[Lorby_SI 2,038]

8 minutes ago, SimonC said:

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.

Well, I don't know. When the spec describes the scenery cfg in the reference section, the entries are all "scenery areas". And those include both subfolders. Historically an "area" always included both.

If LM wanted them separated, then why does the sim still read the area like it used to = including the textures?

But this is futile, only LM knows.

Best regards

[SimonC 116]

1 minute ago, Lorby_SI said:

But this is futile, only LM knows.

I agree. Sometimes we just can't resist to guess... same with product release dates

[simbol 5,821]

You two still at it? 

I started drinking by the time Vic was on the same page as me, then Lorby joined the party confirming my explanations and I could not stop drinking.

Anyway, I am glad you guys are now consumed by it, welcome to the dark side..

LM intentions are to avoid developers overwriting their base files, the idea was to provide developers with tools so we can implement changes to the sim and leave LM original base files intact.

For example imagine I need to deploy new textures to improve threes or default gen buildings, I just need to create a texture folder, and a XML, copy my newly created textures to my desire destination with the same name of the default textures and voila, the sim will use the new textures and leave the original base files created by LM intact.

That is the fundamental idea of the add-on method via XML, you guys are just extending the usage for others purposes, which can be done but will make you very dizzy indeed as it is not the original intended purpose, in hence why I keep warning people about it.

Cheers up🍻🍻

Simbol 

[SimonC 116]

8 hours ago, simbol said:

Anyway, I am glad you guys are now consumed by it, welcome to the dark side..

Ta-ta-taaa ta-tata, ta-tata...

[SimonC 116]

I'm currently in a process of testing a scenery, from one of the very known devs, that was adapted for P3Dv4 (not really beta, more just troubleshooting some problems and discussing the xml-topic), and there are some interesting points.

With component texture, there are two options, global and world. What do these exactly do? Some tests revealed that using world will prevent that texture to be used outside of that one scenery. So even if two different sceneries were to use the same filename, using texture folder as world, will prevent the texture to be used for other scenery.

And this is where topic priority comes into question. Say we are using global texture component, which is the default too, which component will take over, does it go then according to the layer-priority, so the last layer loaded, if it contains a texture with the same filename, will take over?

 

[downscc 1,327]

19 hours ago, SimonC said:

With component texture, there are two options, global and world. What do these exactly do?

There is a third as well according to the SDK, UI, which is only used internally.  I asked LM in their forum and I've asked here earlier what the differences between global and world might be and had not read a response that answered the question.  There also seems to be a difference in behavior between not declaring type, which defaults to global, and an explicit declaration of global.  That was unexpected.

There is a comment in the LM forum today from McCarthy that a change in 4.1 introduced a texture bug so I guess we are all still learning.

[somiller 694]

4 minutes ago, downscc said:

There is a third as well according to the SDK, UI, which is only used internally.  I asked LM in their forum and I've asked here earlier what the differences between global and world might be and had not read a response that answered the question.  There also seems to be a difference in behavior between not declaring type, which defaults to global, and an explicit declaration of global.  That was unexpected.

There is a comment in the LM forum today from McCarthy that a change in 4.1 introduced a texture bug so I guess we are all still learning.

I'm glad this came up. I read the SDK info regarding "Type" and there isn't enough of an explanation that would indicate why one would use global as opposed to world or vice versa. Your comment about a difference between not declaring type which defaults to global, and an explicit declaration of global being different behaviors is indeed unexpected. Unfortunately, there appears to be no way to determine what the difference means.

Of all the .xml addon sceneries I have installed, ONLY FSDreamTeam have "Type" specified...as Global, all others, including FlightBeam, don't include any "Type" information.

I'm curious what would happen if the Global specification were removed from FSDreamTeam addon.xml's?

[SimonC 116]

1 hour ago, downscc said:

There also seems to be a difference in behavior between not declaring type, which defaults to global

Can you elaborate please?

[SimonC 116]

1 hour ago, somiller said:

Unfortunately, there appears to be no way to determine what the difference means.

Not so. I'll be doing some tests with this soon, based on some compiled objects, textures and effects (scenery stuff), which I plan to combine to see what differences I can find between the two modi.

[virtuali 4,421]

On 30/10/2017 at 11:38 PM, Lorby_SI said:

Well, I don't know. When the spec describes the scenery cfg in the reference section, the entries are all "scenery areas". And those include both subfolders. Historically an "area" always included both.

If LM wanted them separated, then why does the sim still read the area like it used to = including the textures?

But this is futile, only LM knows.

Best regards

I've just got confirmation from LM devs, that BOTH methods are equally correct and supported, saying that having separate <Scenery> and <Texture> component is simply more "specific".

In addition to that, since I've specifically asked about scenery using Simobjects that needs to access the same textures in the Scenery Area \texture folder, they confirmed the proper way to ensure that Simobjects would always find the textures, is having a separate <Texture> component with the <Global> type specified pointing to that path.

And of course, since our (FSDT) sceneries all use Simobjects that access textures in the Scenery Area \texture folder, this is precisely why we used that method.

So, to reply to another user that said he "fixed" our add-on.xml, by changing the separate <Scenery> and <Texture> components into a single <Scenery> component pointing to the parent Scenery Area folder, this was entirely unnecessary, since our add-on.xml was fine as it was, and, had we not included a Fallback in the texture.cfg of those Simobjects (which is still needed by FSX), it would have caused textures to disappear.

Also, I would suggest not wasting time trying to fix the "disappearing" textures after a certain number of add-ons are added. The issue it's a confirmed bug in 4.1 that changed some behavior related to handling textures to prevent add-ons using the same texture filename of a default one to display correctly (the default one would take precedence in that case), but it's being worked on.

[SimonC 116]

Umberto, thank you for your reply - now at least we know more about global.

I would really like to have a definitive answer from LM regarding:

What is the difference between adding a Scenery Area (as in one entry for both \scenery and \texture) and a scenery and texture (global) separately? From your answer I would conclude that if texture is not declared separately, the textures cannot be found globally (as in, through other addons). If here the answer is yes...

Then what does world (for texture) do exactly?

Can you ask LM that?

[downscc 1,327]

8 hours ago, virtuali said:

So, to reply to another user that said he "fixed" our add-on.xml, by changing the separate <Scenery> and <Texture> components into a single <Scenery> component pointing to the parent Scenery Area folder, this was entirely unnecessary, since our add-on.xml was fine as it was,

No sir, I did not say or imply fixed.  I did say that I do want to be uniform in the application of addon methods and I recognize either method is proper.  I just don't see the reason to be more specific than simply pointing to the parent directory.

[virtuali 4,421]

2 hours ago, downscc said:

No sir, I did not say or imply fixed.  I did say that I do want to be uniform in the application of addon methods and I recognize either method is proper.

But you can't just be uniform, for uniformity's sake. Every scenery might have specific requirements you might not be entirely aware.

Quote

I just don't see the reason to be more specific than simply pointing to the parent directory.

The reason was Simobjects requiring access to textures in the scenery area folder, which would require the separate <Scenery>+<Texture> syntax. 

As I've said, you haven't noticed any difference, but that's just because we also have a Fallback in the texture.cfg for those objects, pointing back to the same texture folder, which is required by FSX, but we might have changed this at any time, maybe in future P3D-only versions of the scenery, and in that case the single <Scenery> component method would have failed.

[virtuali 4,421]

4 hours ago, SimonC said:

From your answer I would conclude that if texture is not declared separately, the textures cannot be found globally (as in, through other addons). If here the answer is yes...

That seems to be the case.

If a scenery textures are not needed by other add-ons (other sceneries, or Simobjects created programmatically), the single declaration will do nicely, otherwise the two separate declarations are required.

The difference between Global and World types is still not very clear, maybe World would allow only other scenery (.BGL) to access the textures, while Global would allow everything, like Simobjects/Airplanes to find that folder. But I'll try to ask anyway.

[somiller 694]

32 minutes ago, virtuali said:

while Global would allow everything, like Simobjects/Airplanes to find that folder. But I'll try to ask anyway.

But I would've thought that in any case, any add-on.xml is only read when that particular scenery is called by P3D, and if that's the case, how would P3D, or any other scenery know to search that particular scenery's texture directory to find something for a different scenery/simobject, etc.?

Are we sure that Global and World don't relate to the Global and World directories in P3D\Scenery?