3 minutes ago, theskyisthelimit said:

I probably am just over thinking this.. ill keep this part simple from here forward.  

FWIW, I went thru the same thing with Oliver. I kept playing the what-if game re World Scenery. Finally  I understood the concept and it's been a breeze since then. Again, the problem now is those dev's who do not follow the guidelines and plop their scenery wherever. That WILL change down the road or they may notice sales dropping significantly.

Vic

6 minutes ago, theskyisthelimit said:

So the questions would be.. how do I either undo the Lorby Tool so auto detection works.. or how do i use his tool to "find" the new xml file that i made so it can be added to the list.  (or why is the add-on.cfg not working despite my manual addition of the new entry).

The Lorby tool created a backup folder with my original add-on.xml in it,  one day I will thank him for that courtesy.  I deleted the add-on.cfg and all lorby created files and uninstalled the tool.  However, you might want to use the lorby tool, in which case you will have to ask him those questions.  The reason I want to set things up myself is so when something doesn't work I know how to fix it.  So far that has worked for me.

3 minutes ago, downscc said:

The Lorby tool created a backup folder with my original add-on.xml in it,  one day I will thank him for that courtesy.  I deleted the add-on.cfg and all lorby created files and uninstalled the tool.  However, you might want to use the lorby tool, in which case you will have to ask him those questions.  The reason I want to set things up myself is so when something doesn't work I know how to fix it.  So far that has worked for me.

I edited the previous post.. its working now.. at least after i manually (fixed) the add-on.cfg file.. the last entry for my grouping xml had an error.. once i fixed that the tool opened and there were all the entries from this file i manually created.

18 minutes ago, theskyisthelimit said:

the last entry for my grouping xml had an error.. once i fixed that the tool opened and there were all the entries from this file i manually created.

I had to abdandon Notebook++ when P3Dv4 came for for two reasons, one was the way it might mishandle UTC16 encoding and the other was I needed a good xml editor.  I found EditPad Pro and have been using it for several months and I love it, and it is a fourth of the price of UltraEdit whose price has increased by five times since I first starting using it.  EditPad will highlight the xml tags in green if the code is good and red if there is a problem such as a missing </ or whatever.  Very nice to have when editing more than a couple of xml files.

Some more food for thought/questions..

Is anyone messing with bigger products like UTX.. trying to determine where all the files get put by installing to a dummy p3dv4 folder and then creating custom xml for these entries?  I think that would be too messy.

And.. for other things like WashDCX or NYCX.. is anyone moving their install paths after the fact (to their own custom folders) and modifying the xml? Or is it maybe better just to let them live in their default location for ease of updates later on, which will likely be confused on the location of the files if they are moved?

55 minutes ago, theskyisthelimit said:

Or is it maybe better just to let them live in their default location for ease of updates later on, which will likely be confused on the location of the files if they are moved?

I don't have any experience with city scapes and the such, other than Orbx and I let it do it's thing but it has a very powerful configuration and update application in FTXCentral.  Most times I clean up after a scenery installer is done, and move or configure it the way I want it.  I notice FlightBeam is the first one to allow you the opportunity to choose where things go.  FSDT may have been the first to use add-on.xml but I don't like their method of providing an addon component link to every scenery and texture subfolder so that go changed.  In the long run all my addons are attached to P3D in the same consistent way, makes it easier to trouble shoot.

Hello @ll,

IMHO most of this confusion stems from the fact that we are doing something that LM did not intend to happen. I am pretty sure that they did not plan for people to layer scenery add-on.xml components inside the numerical range of the scenery.cfg, and on the same layer at that.

That sceneries occupying the same layer in the range of the scenery.cfg have the same layer numbers is normal, and basically according to spec (it doesn't say that you are not allowed to do this - only the scenery library dialog complains). Further sequencing on those identical layer numbers can be achieved by changing the sequence that the components appear in the add-on.xml and how the packages are stacked in the add-ons.cfg files.

The latest version of the Addon Organizer (1.08) will do that for you. It will rearrange the component and package definitions so they reflect what you expect to see in the scenery library. There are exceptions to what is possible though, and I have tried to describe them in the release note for 1.08 in the Lorby-SI freeware forum here on AVSIM.

Best regards

 

On 7/24/2017 at 3:03 PM, downscc said:

  I have one file for each developer

Do you have a workflow for this?  

Specifically, do you just let scenery installer run it's course (perhaps pointing to a folder you want, if they allow that or if not just move all the files to where you want them to go when its done), then delete any add-on folder the installer may have made and enter all the xml data for that add-on into your single-developer add-on.xml?

 

Also - how are you getting makerwys.exe to see the scenery you have installed as add-ons?  I thought Lorby-SI addon manager was required for that to work? Perhaps you don't use that or perhaps my information is old. 

 

9 hours ago, mherzog said:

Do you have a workflow for this?  

Specifically, do you just let scenery installer run it's course (perhaps pointing to a folder you want, if they allow that or if not just move all the files to where you want them to go when its done), then delete any add-on folder the installer may have made and enter all the xml data for that add-on into your single-developer add-on.xml?

Also - how are you getting makerwys.exe to see the scenery you have installed as add-ons?  I thought Lorby-SI addon manager was required for that to work? Perhaps you don't use that or perhaps my information is old.

That is my basic workflow.  I stuck a zero size prepar3d.exe file in my addons folder (I should have named it something else but it works) and it satisfied some installers like FlyTampa.  Others I could point to where I wanted like FlightBeam (I love them) and still others insisted on not allowing the user any say in the matter.  Regardless of the installer, I move the folders if required and delete scenery.cfg entries if any and edit the add-on.xml files to be consistent.  One key in my work flow during the migration was sticking to one developer at a time. Keep it simple.

Last I checked, Lorby required the makerwys to see addons, but also it is required to set up a temporary scenery.cfg with all locations for Orbx Vector AEC Tool.  Once the tool has run and found the airports with elevation exceptions you then delete the temporary scenery.cfg.  I use it for that and updating runways for RAAS only since I do not use the Lorby tool.

2 hours ago, downscc said:

st I checked, Lorby required the makerwys to see addons, but also it is required to set up a temporary scenery.cfg with all locations for Orbx Vector AEC Tool.  Once the tool has run and found the airports with elevation exceptions you then delete the temporary scenery.cfg.  I use it for that and updating runways for RAAS only since I do not use the Lorby tool.

Yes... exactly.  I am on board (mostly) with your exact approach.  I am a little scared about how an upgrade in scenery may work on some of those locations where dev's might be less than flexible on how they implemented the install in the first place.  But I suppose if that means every once in a while you have to install the original scenery back to where it wants to be, in order to do the upgrade, that may not be a huge cost.

 

I still am debating the add-on.xml per developer vs add-on.xml per scenery, and would love to hear your arguments for the "per developer".  I assume it allows you to have a single entry for "effects" or the like that a developer may have and share across sceneries, but do you find it's harder to disable a single scenery?   I guess you have committed to always working with the xml files (and not just unchecking the scenery in p3d)... which seems fine.  But the fact that no developer (we'll have to wait on FlightBeam until he moves another scenery over to his new addon manager) is creating a single add-on.xml to manage their work, again makes me a little uncomfortable that ultimately any updates/changes they want to push to us may not fully work right, if we start combining all their sceneries into a single add-on.xml file.  (i.e. won't a developer want to search for their add-on.xml, so they can determine where we installed the scenery so they can push the upgrade?)

 

For now I am heading in your direction, with fewer folders and fewer files to actually have to manage being better than having lots of fine scale add-on management within the p3d file itself (i.e. unchecking add-ons in p3d)... but I have been keeping my ears and eyes open to some of these conversations just to get a better understanding of what the consequences of this decision might be in 6 months time, when I will be much more committed to this approach of single add-on.xml per developer.

 

Mark

 

 

 

1 minute ago, mherzog said:

and would love to hear your arguments for the "per developer".  

It was simple decision.. I just didn't want 80 folders in the documents addon folder.  Esoterics I guess,  just don't like the idea of a directory for one small file repeated over and over.  Since the file name must be add-on.xml I figured it best to put all FlyTampa together.  When it came to FSDT and Flightbeam, who's installers created separate folders for each, I found that their update apps worked just as well when all their locations were in one xml.

30 minutes ago, downscc said:

who's installers created separate folders for each, I found that their update apps worked just as well when all their locations were in one xml.

Perfect.  Thanks.

3 hours ago, downscc said:

That is my basic workflow.  I stuck a zero size prepar3d.exe file in my addons folder (I should have named it something else but it works) and it satisfied some installers like FlyTampa.  Others I could point to where I wanted like FlightBeam (I love them) and still others insisted on not allowing the user any say in the matter.  Regardless of the installer, I move the folders if required and delete scenery.cfg entries if any and edit the add-on.xml files to be consistent.  One key in my work flow during the migration was sticking to one developer at a time. Keep it simple.

Last I checked, Lorby required the makerwys to see addons, but also it is required to set up a temporary scenery.cfg with all locations for Orbx Vector AEC Tool.  Once the tool has run and found the airports with elevation exceptions you then delete the temporary scenery.cfg.  I use it for that and updating runways for RAAS only since I do not use the Lorby tool.

Thats how i've been rolling along.. i have dummy folders for everything from fsx to p3d with dummy files and registry entries.. i capture those files and move them around as needed, working well so far.

The one i ran into that was a little difference was a scenery/NAME/texture folder.. since this one didnt have scenery per say it couldnt be added as a "scenery" element.. not sure if adding it as a texture "addon" component is correct either but its what i did for now.. (just adding a blank scenery folder doesnt help either)

1 hour ago, theskyisthelimit said:

The one i ran into that was a little difference was a scenery/NAME/texture folder.. since this one didnt have scenery per say it couldnt be added as a "scenery" element.. not sure if adding it as a texture "addon" component is correct either but its what i did for now..

Interesting addon.  Texture only no scenery??  Is it to replace existing textures?  Otherwise, I'm lost as to what is using those textures.  I can add that only scenery category uses the name tag, and all names must be unique. 

9 minutes ago, downscc said:

Interesting addon.  Texture only no scenery??  Is it to replace existing textures?  Otherwise, I'm lost as to what is using those textures.  I can add that only scenery category uses the name tag, and all names must be unique. 

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