10 minutes ago, theskyisthelimit said:

Yeah.. Drz Miami City X sorry i left that out.. and yeah no scenery, but this is because the "textures" get put into the NAME/Textures folder which is part of the P3D folder structure and already has P3D base "NAME" scenery and texture folders with p3d files in it.  So i guess it adds to the folder.. edit: this is the NAME folder for "Eastern North America" in the old scenery.cfg..  so i'm not sure if my texture addon component will suffice

Ah okay... that NAME as in North America East.  Here is the trap to watch for:  If the DRZ textures have the same name as existing textures in <p3d>\Scenery\NAME\Texture then best to overwrite those with new files to prevent having more than one file per filename, which will cause errors if the textures are global. If the DRZ textures are addon and not replacement, then you can put them in a global scenery addon.component.  My guess is they are replacement textures; otherwise back to the chicken and egg question of figuring out what the textures attach to.

10 minutes ago, downscc said:

Ah okay... that NAME as in North America East.  Here is the trap to watch for:  If the DRZ textures have the same name as existing textures in <p3d>\Scenery\NAME\Texture then best to overwrite those with new files to prevent having more than one file per filename, which will cause errors if the textures are global. If the DRZ textures are addon and not replacement, then you can put them in a global scenery addon.component.  My guess is they are replacement textures; otherwise back to the chicken and egg question of figuring out what the textures attach to.

I took a look.. they appear to overwrite existing textures.. which makes this more difficult.. i'd rather not just overwrite the existing ones.

Wondering if there is some way like with Scenery/Global/Scenery and the whole layer2 setting (and only putting the ones that would have gone here in this folder for various vendors).. if it could be done for the NAME layer.. assuming its layer position is constant.. couldnt i just create another layer above NAME  with these textures (as an addon texture pull down global option?)..  this is where i also dont quite grasp as of yet the difference between global and world in that pull down.  Everything else has been mostly gravy so far.

 

I suppose if i new what to look for at the airport i could probably get a sense if anything i'm doing is working.. like in this case..

MIA_Maintanance.dds
MIA_Maintanance_LM.dds
MIA_MaintancnceSpecular.dds
MIA_Mainterminal.dds  (i guess this might just be the main outside walls of the main terminal perhaps?  i could test once without overwriting, then once with (renaming the old).. then try a trick using the xml files to see if i can replicate )

All this for the glory of modular installs :)

16 minutes ago, theskyisthelimit said:

I took a look.. they appear to overwrite existing textures.. which makes this more difficult.. i'd rather not just overwrite the existing ones.

Wondering if there is some way like with Scenery/Global/Scenery and the whole layer2 setting (and only putting the ones that would have gone here in this folder for various vendors).. if it could be done for the NAME layer.. assuming its layer position is constant.. couldnt i just create another layer above NAME  with these textures (as an addon texture pull down global option?)..  this is where i also dont quite grasp as of yet the difference between global and world in that pull down.  Everything else has been mostly gravy so far.

 

I suppose if i new what to look for at the airport i could probably get a sense if anything i'm doing is working.. like in this case..

MIA_Maintanance.dds
MIA_Maintanance_LM.dds
MIA_MaintancnceSpecular.dds
MIA_Mainterminal.dds  (i guess this might just be the main outside walls of the main terminal perhaps?  i could test once without overwriting, then once with (renaming the old).. then try a trick using the xml files to see if i can replicate )

All this for the glory of modular installs :)

Looks like DRZ is using less than desired practices in their installation of textures.  As a minimum you expect the existing textures to be renamed by the installer to something such as MIA_Maintenance.dds.ORIG, which is exactly how I would mount that goat.  I wouldn't try to do anything elegant with an add-on.xml; rather, I would add ".ORIG" or ".BAK" suffixes to the original texture file and place the replacements in there.  This is the approach taken in many cases to create compatibility between Orbx and other 3d party addons, and when I replace an airport bgl with my own from ADE where I use the ".OFF" suffix.  Over time I also collect a number of APXxxxxxx.bgl files with APXxxxxxx.bgl.bak names after updating navaids and removing marker beacons.  The added extension stands out when one browses the files and makes it easy to find changes.

btw, i stumbled onto the fact KSNA Latinvfr has a p3dv4 installer.. my previous work was with the p3dv3 one.. they allow you to point the install folder anywhere.. however.. at least two files are changed in the main sim's root texture folder.. so they havent completely gotten rid of that need, at least not yet with this initial p3dv4 installer unfortunately.  Means it will be difficult to track down other p3dv4 files that end up in the main p3dv4 directory, unless using sandboxie to try to figure out what ends up where with alot of these vendors.  

OK, I am not a computer person and this whole xml, add-on placement discussion has my head spinning.

For me, it would be much easier to understand if you people that are fluent in computer-speak could show us sheep a visual representation (a la Poppet) of how you do these things.

Still have not purchased v4 while waiting for some aircraft to catch up.  I am hoping by the time those aircraft are released, this will be a simple and clear process.

OK developers, ball is in your court.

3 hours ago, BuddyDog said:

OK, I am not a computer person and this whole xml, add-on placement discussion has my head spinning.

For me, it would be much easier to understand if you people that are fluent in computer-speak could show us sheep a visual representation (a la Poppet) of how you do these things.

Still have not purchased v4 while waiting for some aircraft to catch up.  I am hoping by the time those aircraft are released, this will be a simple and clear process.

OK developers, ball is in your court.

I'd love to make one if noone beats me to it down the road to showcase how this works.. time is tough now.. especially with all these re-installs (haha)..

What would be nice.. is if there was a tool that you could just point it to a directory and it auto create an xml file/folder for each scenery per folder in there.. manually doing these one by one is time consuming.. especially for the mass amounts of freeware ones i have in some cases.

 

5 hours ago, BuddyDog said:

OK, I am not a computer person and this whole xml, add-on placement discussion has my head spinning.

I'm not a computer person either, but the only way you learn is to jump in and do it and learn from mistakes.  If you cannot bear the thought of making a mistake then you might be in the wrong hobby.

However, if I may ask... Was it really necessary for LM to bring this "xml" deal? I mean... Was it really necessary?  I don't know.. but why make things different if there is no need to?  And, if (if) you want to make things different, why not make it simple to follow, rather than having to have people manually create these XMLs?  I understand some people have no problem with this, but the majority would rather not have to go through that stuff. 

3 hours ago, joemiller said:

However, if I may ask... Was it really necessary for LM to bring this "xml" deal? I mean... Was it really necessary?  I don't know.. but why make things different if there is no need to?  And, if (if) you want to make things different, why not make it simple to follow, rather than having to have people manually create these XMLs?  I understand some people have no problem with this, but the majority would rather not have to go through that stuff. 

Lot's of reasons why - well documented - not the least of which is to answer the huge complaint of having to reinstall all addons after every update. There really is no need for the user to do the install at all assuming the developer follows the format. When they make it mandatory all installers will have to follow the format. The problem right now is the transition period is cumbersome because there are devs who won't follow the rules and some who do so you have stuff all over the place.

As a user, I feel it is important to take those that are NOT compliant and edit their install so that they are. Due to some of the testing I do I've had to reinstall several times and it just takes seconds and all my addons are ready to go. THAT alone is a valid reason for this change.

Ultimately it will be a big benefit to us all.

Vic

On 7/27/2017 at 8:19 AM, downscc said:

One key in my work flow during the migration was sticking to one developer at a time. Keep it simple.

So, I committed to setting it up as 1 add-on.xml per developer and have had no issues at all.  It seems as you said the addon managers from FSDT and flightbeam work off relative paths and all seems happy. 

Following you advice, I have been doing these one dev at a time, and I have bumped into LatinVFR and notice that they have an "Information.cfg" file inside each add-on folder that appear to have specific install information.  Did you just ignore those, or handle them in any special way?   Obviously not needed for the scenery to work in the sim... guessing LatinVFR uses it for updates...or maybe it's just an install.log.  No info on the LatinVFR forums that I could tell... I am moving forward with them, but was curious if there was an knowledge about them. 

No issues otherwise.

Also, I have been curious if prepar3d provided a downloadable schema that we can use for validation (i.e. an *.xsd file)?  I've searched with no luck finding anything.  I suppose it's probably not complicated enough to warrant the effort put into it for now.

FWIW - I know you said you moved away from it, but I am using Notepad++ with the XMLTools plugin and it seems fine.  I may ultimately swap out to a dedicated xml editor at some point. I am not sure.  You said you had an issue with the encoding.  I haven't noticed anything yet

Mark

9 hours ago, mherzog said:

I have bumped into LatinVFR and notice that they have an "Information.cfg" file inside each add-on folder that appear to have specific install information.  Did you just ignore those, or handle them in any special way?   Obviously not needed for the scenery to work in the sim... guessing LatinVFR uses it for updates...or maybe it's just an install.log.  No info on the LatinVFR forums that I could tell... I am moving forward with them, but was curious if there was an knowledge about them. 

Apparently not required because I do not have those files, I must have deleted.  Most of their locations also have a configurator.exe and that works independently of P3D and addons, it is a standalone application that turns certain features on and off.

I am not aware of an xsd, probably part of the schema for the simbase.documents found elsewhere.

To be fair to Notepad++, I read about certain precautions that had to be made for encoding UTC16 but the primary reason I when to EditPad was that I needed a binary file editor.  Once I started using EditPad for a few tasks I liked it so much I removed Notepad++.

22 hours ago, downscc said:

I'm not a computer person either, but the only way you learn is to jump in and do it and learn from mistakes.  If you cannot bear the thought of making a mistake then you might be in the wrong hobby.

Oh I make plenty of mistakes, but your snarky reply is really not called for.

Lighten up gentlemen, please.

 

Vic

19 hours ago, vgbaron said:

assuming the developer follows the format

The Elephant in the room

LM started mentioning this in V2. They pressed the issue a little more in V3. More stress now in V4. By the time we're at V5 it will be mandatory. Either you play nice or don't play at all. Prepar3D is the PLATFORM - everything else are ADD ONS. It is up to the add on to conform to the platform NOT vice versa. There isn't a single developer who's product cannot be replaced by someone else and I suspect there are more waiting in the wings.

Ultimately we, the user will benefit.

Vic