simmerhead

Rant: Developers, wake up!

Recommended Posts

Since Prepar3D v3 add-ons should be made to install outside of the P3D folder structure, preferably in the folder of choice of the user. An xml file in the My Documents\Prepar3D v4 Add-ons folder is all that P3D need to make it work in the simulator.

Now, for some reason, some developers continue to make life miserable for the user by ignoring good practice by making a mess of the main P3D folders with completely unnecessary negative side effects. Many developers have been graciously awarding us with P3Dv3 and v4 upgrades, only to stumble on the finish line by providing us with poor install routines.

So what can be gained by following the prefered method of install add-ons outside of the main P3D folders? Here are some of the benefits:

  1. In theory you can uninstall and delete the P3D folders without deleting the add-ons, hence making a clean reinstall simple and easy. When a new install of P3D is in place it will look up all the addons in the My Documents\Prepar3D v4 Add-ons folder and you’re back up and running WITH NO NEED TO REINSTALL THE ADD-ONS ALSO! Of course there are some exceptions to the rule, but stuff like aircraft, AI traffic, avatars etc. will have zero issues with this method.
  2. You can delete an addon by simply deleting the folder where YOU chose to install it and the folder containing the xml file in the My Documents\Prepar3D v4 Add-ons folder. No need to track down files scattered all over the place… As most of us have experience, even those add-ons containing uninstallers can mess up or miss files that should have been deleted.
  3. You can spread your add-ons over as many drives as you like with zero fuzz. We all know that with a lot of scenery the hard drive containing P3D fills up fast – even worse if you have a few more sims installed as well.
  4. It is a nice to have add-ons that are compatible with more than one version of the sim gathered in one place.
  5. You have too many aircraft or AI aircraft installed? Just move the folders from the My Documents\Prepar3D v4 Add-ons folder into a temporary folder. When you need them again, it's a simple drag and drop, no need to go through tedious install processes again, find those passwords and go through online license checks.
  6. Last, but not least – It lets the user have full control over where files are stored on their own computer.

I’ve been slowly adapting to P3Dv4 since my P3Dv3 runs great with everything installed and tuned to perfection. However, I can’t escape the VAS issue, so over the last few weeks I’ve slowly started to install P3Dv4 add-ons side by side. ORBX is in place, and sadly they don’t use the external approach. However I know scenery is a bit more complicated to install, so I will leave them out of the rant for now.

The first aircraft I bought for P3Dv4 was the A2A T-6 Texan Accusim. It did just as it was supposed to do and put all the files in the add-on folder, although I wish I could have selected another external folder for everything but the xml file entry. I was also eager to try out the new Ultimate Traffic offering, UT Live. Flight1 has obvisouly both gotten the memo and read it. UT Live installed right where I wanted it to! HiFiSim’s Active Sky 2016 and REX Soft Clouds play nice too.

Sadly JustFlight and Carenado were big disappointments. My JustFlight Chipmunks and Carenado C208B Grand Caravan used the old “FSX-method” and messed up my nice and tidy P3Dv4 folders…

  • Upvote 11

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

Agreed, I recently installed the new LatinVFR update for KSAN and it didn't create an addon.xml and was installed into the root of the sim folder.  I then had to mess about putting it in the Addon's folder where it should go in the first place.  I think LM need to force this on Dev's in the next update because it makes total sense.

Share this post


Link to post

Carenado can be installed to a unique folder outside of the P3D root. Then you can manually or use Lorby's AO to create the XML file. So it's not a complete failure to comply.

 

Vic

  • Upvote 2

Share this post


Link to post

Well, it goes both sides.

I made my add-on  .xml method complaint and what I discovered after 2 months? Users overriding manually the P3D default files and deleting the add-on.xml file from their documents.

I had to put warnings all over the place in an attempt to stop this.

I guess not everyone is ready for this technique including users, but I am sure this will change with time.

Regards 

Simbol 

  • Upvote 5

Share this post


Link to post

Lorby-Si's excellent Addon-Organizer for P3Dv4 helps immensely; but the OP is right.

It really ticks me off when developers; and not just for P3D, this also applies to Windows apps, Autodesk apps (don't get me started); ignore published SDKs that make things crystal clear and go and do their own thing which ultimately screws up your entire system.

Example - Autodesk's insistence on using outdated DRM that relies dodgy block-level editing of your system disk, provided by an even more dodgy DRM provider with proven links to certain global intelligence organisations. Essentially it's a rootkit, which is why they tell you to switch off your AV when you install it, and on top of that all their software demands that your users must run as Admin (because it needs block-level disk access, right?). What could possibly go wrong with everyone running as Admin? (Ok, I got started).

LM P3D is utterly benign, and the default install is damn near perfect. 100+fps with default install at only mid-range settings on my mediocre rig and it still looks better than FSX:SE at max settings and IMHO looks as good as X-Plane. Actually better then X Plane - because I fly mostly in Australia.

My first attempt at installing P3Dv4 was disastrous when I simply installed all my addons - I was left with a glitchy P3D install that CTD's frequently and framerates in the low TENS.

I deleted the whole lot and started again, this time using a directory-change-management tool (FolderChangesView by NIRsoft) and Windows Shadow Copies for roll-back when addons inevitably screwed with stuff the SDK clearly tells you NOT to screw with. I used Lorby's Addon Organizer to build my own XML files; and guess what? I've got full ORBX, OZx, FS Global 2018 terrain, high-res textures, dynamic lighting, dynamic shadows, full Traffic X 360 at 50% for airliners and general av, detail levels at mid-range and I'm getting solid 30fps at busy airports, and solid 60+FPS at altitude / VFR country.

Who knew following the published SDK procedures would work so well?

  • Upvote 2

Share this post


Link to post
9 hours ago, simbol said:

Well, it goes both sides.

I made my add-on  .xml method complaint and what I discovered after 2 months? Users overriding manually the P3D default files and deleting the add-on.xml file from their documents.

I had to put warnings all over the place in an attempt to stop this.

I guess not everyone is ready for this technique including users, but I am sure this will change with time.

Regards 

Simbol 

We all know how hard it is for old dogs to learn new tricks, but it's a poor excuse in my humble opinion. Someone has to lead the way and in the long run I thikn it will solve more problems than it creates.

Share this post


Link to post

In theory you can uninstall and delete the P3D folders without deleting the add-ons, hence making a clean reinstall simple and easy. When a new install of P3D is in place it will look up all the addons in the My Documents\Prepar3D v4 Add-ons folder and you’re back up and running WITH NO NEED TO REINSTALL THE ADD-ONS ALSO! Of course there are some exceptions to the rule, but stuff like aircraft, AI traffic, avatars etc. will have zero issues with this method.

With a little forward thinking this can be perfectly well achieved by careful file management

You can delete an addon by simply deleting the folder where YOU chose to install it and the folder containing the xml file in the My Documents\Prepar3D v4 Add-ons folder. No need to track down files scattered all over the place… As most of us have experience, even those add-ons containing uninstallers can mess up or miss files that should have been deleted.

Very few add ons scatter files "all over the place".

You can spread your add-ons over as many drives as you like with zero fuzz. We all know that with a lot of scenery the hard drive containing P3D fills up fast – even worse if you have a few more sims installed as well.

This can easily be done already, scenery can be placed anywhere and referenced in the scenery library.

It is a nice to have add-ons that are compatible with more than one version of the sim gathered in one place.

This is already possible using the scenery library, as above.

You have too many aircraft or AI aircraft installed? Just move the folders from the My Documents\Prepar3D v4 Add-ons folder into a temporary folder. When you need them again, it's a simple drag and drop, no need to go through tedious install processes again, find those passwords and go through online license checks.

Or just create a folder named say "Hangar" and drag the aircraft folders into that.

Last, but not least – It lets the user have full control over where files are stored on their own computer.

This is already the case.

Share this post


Link to post

If you got nothing better to do in life than micro manage files on your hard drive, be my guest...

Share this post


Link to post

Thank you, I will.

I was just pointing out a few reasons why people may not have jumped to adopt something "new".

Share this post


Link to post
1 hour ago, simmerhead said:

We all know how hard it is for old dogs to learn new tricks, but it's a poor excuse in my humble opinion. Someone has to lead the way and in the long run I thikn it will solve more problems than it creates.

Not sure if I understand your comment, I implemented the method as per your rant long time ago lol but sadly it was ignored by many simmers!.

All the best,
Simbol

  • Upvote 1

Share this post


Link to post
1 hour ago, simbol said:

Not sure if I understand your comment, I implemented the method as per your rant long time ago lol but sadly it was ignored by many simmers!.

All the best,
Simbol

Sorry for being unclear. You seem to be one of the "good guys" and I see that you weren't making excuses, just pointing out that people seem to ignore your good practice :)

However, I hope developers won't use user mistakes as an excuse for not moving with the times.

From a usability perspective changes are challenging, especially for software that people have been using for a long time. I've seen some of the rants coming from Windows, Photoshop and Excel users when major changes have been done - I'm an economist and expert Excel user for 20 years. When the menu system was overhauled some years ago it took me one year to get comfortable in Excel again. Deleting and installing a new autopilot is hard for the brain ;)

However, some changes are for the better, and the less developers tamper with the main P3D folder, the better for all of us in the long run, even though putting the files in the "My Documents" folder is an odd choice. Maybe it would have been much easier if P3D just made a second folder on the root drive of the install called Prepar3D Add-ons - or let the user chose the folder during the install routine. I'm sure there are a lot of Prepar3D user that still have no idea that there is such a thing as the Add-on folder inside My Documents :)

In general third party software should stay away from using the My Documents and My Photos folders. They are MY folders after all... Who considers add-ons documents anyway?

Share this post


Link to post

Of course if you are keeping your C drive as small as possible either for it to be on an SSD or for regular cloning backups of the OS it is not very nice if people keep trying to fill it by hard wiring things into the C program files or the C:/user/docs folders.

Choice is fine but let the choice be ours, our Sim, our Money and our Time.

  • Upvote 2

Share this post


Link to post

It's nice that, after getting so much flak on June 1st 2017 (P3D V4 release date), when we provided proper V4 installers for all our products on Day 0, all using the add-on.xml method in the best way possible, and after being attacked everywhere by being the usual weirdos doing things their own way, people is starting to realize how much better the new system is.

Since P3D is getting fairly regular updates, it should have been obvious that, using the old ways was going to be a recipe for disaster, very soon. It might have worked, somewhat, since nobody ever patched FSX in 10 years (with the exception of a couple of minor Steam patches), but not today.

However, even those using the add-on.xml method, sometimes don't seem to get it entirely:

1) Why placing all files related to the addon in the Documents folder ??? That should contain ONLY the small add-on.xml, with <Path> comands pointing to the actual location of the files, which can be everywhere, even on a different drive. Placing everything in the Documents\Prepar3D V4 folder forces (again) users to have the addon files in the same folder as their documents, which usually is the boot drive, which might be a smaller SSD, compared to a larger (cheaper) external drive holding all the addons.

This might be explained because, by default, if there's NO path set in the <Path> line of the add-on.xml, the files are being searched in the folder directly below of the add-on.xml file itself. This way, installers would be easier, since they could just distribute a pre-made add-on.xml, without caring to set the actual paths in the <Path> lines of the XML. So it makes for an easier installation routine, even if it's worse for users

2) Even more wrong than placing the addon files in the Documents folder, is using the add-on.xml and continue to place stuff inside the SIM folder! Somebody IS doing this but...WHY ??? This can only be explained by not getting the whole idea of the add-on.xml concept...

 

  • Upvote 7

Share this post


Link to post

Thank god some of they use the old method! While add-on.xml method would be fantastic, it has its downsides:

- Some add-ons install the whole stuff to the documents folder, which (at me, and some other users I think) on the C drive which is a small SSD for the system, and the sim is on an other (much larger) drive.

- In the Sim, add-on.xml entries order cannot be changed in the scenery library, so with a lot of addons it can made a mess, even with a couple sceneries as soon as the install order is not in a predefined way (e.g if I buy orbx vector after an airport scenery and both would use add-on.xml method it won't work because vector must be below airports). Of course it can be reordered by an external tool, but that's not the best for beginner simmers/IT beginners.

- In some cases addon sceneries overwrites some default files in the scenery/world folder (personally, I don't like this).

 

I personally put all sceneries to the ecosystem folder and add to the library by hand or modify the paths in add-on.xml and/or scenery.cfg and I think there is no problem with this until it can work and we have our choices. :)

Share this post


Link to post
Quote

In the Sim, add-on.xml entries order cannot be changed in the scenery library, so with a lot of addons it can made a mess, even with a couple sceneries as soon as the install order is not in a predefined way (e.g if I buy orbx vector after an airport scenery and both would use add-on.xml method it won't work because vector must be below airports). Of course it can be reordered by an external tool, but that's not the best for beginner simmers/IT beginners

This is the part about the new system that I fail to understand. Surely, if you are going to introduce a system where the order of the scenery entries can't be changed, you need to eliminate the "some sceneries need to be higher than others in the pecking order" problem? :huh:

Share this post


Link to post
28 minutes ago, Christopher Low said:

This is the part about the new system that I fail to understand. Surely, if you are going to introduce a system where the order of the scenery entries can't be changed, you need to eliminate the "some sceneries need to be higher than others in the pecking order" problem? :huh:

Of course, but I'm almost certainly sure it's not eliminated, otherwise the forums wouldn't be full of these kind of issues. To be honest I still don't understand the concept behind that these items cannot be moved in the library.

However add-on switch on/off and install would be much easier with the new method, but because of this issue I still feel that this is "unfinished" development.

Layer numbers can be edited in the XML (that's what Prepar3D add-on organizer does), so maybe they cannot be moved because the correct layer order would be the responsibility of installers? That can cause other issues as well..

Share this post


Link to post

While I do not object to the "new" xml method, the way it is at the moment would suggest that there is equal disregard on both sides for the others' requirements.

There are some products that require that core files are modified and most certainly there are many products that need a certain position in the scenery library that depends entirely on what else is already there and cannot therefore be predetermined.

I would hope that the development of the xml system is not at an end but at present, it appears to offer nothing that cannot already be achieved using long established, tested and effective methods. It does, however, appear to have an adverse effect on the scenery library, which needs additional software to mitigate and this does appear to defeat the object.

 

 

 

Share this post


Link to post
20 minutes ago, fatal said:

However add-on switch on/off and install would be much easier with the new method, but Layer numbers can be edited in the XML (that's what Prepar3D add-on organizer does), so maybe they cannot be moved because the correct layer order would be the responsibility of installers? 

I guess the real reason why they cannot be moved is because the Scenery Library UI in the sim could become more complex, because it would have to take into account both items from the scenery.cfg and items added with the add-on.xml. Which is, basically, what the Lorby organizer does so yes, it would be nice it LM could do the same in the default UI.

Ideally, if the scenery.cfg would just go away in a future major version of sim (and you can bet we'll try to do our best lobbying to obtain this), it might be easier to have the default UI rearranging sceneries that are all installed in the same way.

Share this post


Link to post
29 minutes ago, virtuali said:

I guess the real reason why they cannot be moved is because the Scenery Library UI in the sim could become more complex, because it would have to take into account both items from the scenery.cfg and items added with the add-on.xml. Which is, basically, what the Lorby organizer does so yes, it would be nice it LM could do the same in the default UI.

Ideally, if the scenery.cfg would just go away in a future major version of sim (and you can bet we'll try to do our best lobbying to obtain this), it might be easier to have the default UI rearranging sceneries that are all installed in the same way.

That could be the answer regarding the scenery library. As a software engineer (not flightsim related) and as a user (simulators) I can certainly understand both sides. The new method is more forward-looking if the entries can be moved in the scenery library. Until then we have this hybrid method which imo not the best solution.

 

I also hope that LM will add back the scenery library button to the main menu, currently I don't understand why it was removed from there in the first place. At a reinstall with a lot of sceneries, it's a pain in the word not allowed to load a flight just because I need to add some new entries, but this is a different topic.

Share this post


Link to post
3 minutes ago, nolonger said:

There are some products that require that core files are modified

That's not the case. Unless you are referring to very specific cases, like addons that needs to replace things such as the default landclass assignment table, the add-on.xml method has been designed to let developers override a default file, with their own version of the file, using the same name, located elsehwere. So, they can can, in fact "modify core files"; without actually replace them!

Unfortunately, this is not entirely clear in the SDK (one has to read between the lines), and there are still some bugs left which will should fixed in the next version of the sim, but surely the idea behind the add-on.xml method was to allow addons to replace files from the sim with their own version, without really replacing, so by just disabling the addon, the original file would came back, because it was just shadowed.

The issue of the default landclass and autogen table (which OrbX and other does change), it's unfortunate, because there's still a central file for it, while it might have been nice if an addon could define its own local version, but this was already an issue with the scenery.cfg method, it's not really a "problem" caused by the add-on.xml, and it could be solved if this was another localized thing that could be added to it.

 

Quote

 

and most certainly there are many products that need a certain position in the scenery library that depends entirely on what else is already there and cannot therefore be predetermined.

Again, this was already an issue before, and the add-on.xml surely DOES allow layering. The inability for users to easily rearrange areas it's only a shortcoming of the default UI of the sim, which has been already taken care of by a freeware external utility (which means LM could probably add it anytime).

 

Quote

 at present, it appears to offer nothing that cannot already be achieved using long established, tested and effective methods.

Well, no. It allows the following, which wasn't possible before:

- In addition to Scenery and Texture files, Add-ons can have their own folders for Effects, Sounds, Fonts, Autogen, Shaders, Gauges and Weather, in addition to have an easier way to add Simobject paths without touching any the core files of the sim.

- The whole sim can be uninstalled and its folder could even be wiped out, including its preferences in %APPDATA%, %PROGRAMDATA% or %LOCALAPPDATA%, which means a totally CLEAN reinstall, yet addons (the good ones, those using the add-on.xml method properly), can be reactivated automatically, thanks to the Auto-discovery feature of having their add-on.xml placed into the Documents\Prepar3D V4 Addons, and that's why the add-on.xml it's placed *there* (to quote someone that said "why they used the Documents folder which should contain MY files only??"), because it's assumed that if you want to do a clean reinstall of the sim, you will remove the sim folder and the sim preferences, but not your Documents folder.

  • Upvote 1

Share this post


Link to post

Thanks.

Can you explain how the xml method can be used to replace all the default terrain textures please

and if it is possible, what would the advantage be of having two complete sets of default textures?

Share this post


Link to post

I have been stating this info for years on LM and Orbx forums.  That we need addons to be installed outside.  X-plane does it (as far as I have tested on it).

Orbx states that the current system is broken, and now even Flightbeam is installing inside the Sim directory (why???).  Only FSDT and UK2000 follow the P3Dv4 installation by default.

 

Bottom line is - We need Orbx to install everything outside the sim (exceptions to Global only is understandable)...till the biggest player moves out only then rest will follow.  LM needs to HARD enforce the policy.  Till then install addons carefully, and not mess the sim.  Current method just wastes damn time.  And in my line of work, TIME is money.  Can not recover TIME but can recover money.  My addon buying has drastically reduced as I have to allocate how much time can be spend installing stuff now.

 

With the P3d upgrades there is always a chance that something inside a SIM will break.  We may have moved to 64bit but legacy installation methods are still there...which is annoying

Share this post


Link to post
49 minutes ago, nolonger said:

Thanks.

Can you explain how the xml method can be used to replace all the default terrain textures please

The SDK has only one line about this, and it's not very clear but, I can assure you LM thought about this, and starting with 4.1, for each texture there's an internal ID, in order to prevent collisions caused by addons using a texture with the same name of a default one. And, the feature still has bugs, which might explain why developers never tried to use it but, it surely indicates that LM assumed someone would want to replace a default file with something with the same name, without having the addon replacing the original file, which was the idea behind the add-on.xml concept.

 

49 minutes ago, nolonger said:

and if it is possible, what would the advantage be of having two complete sets of default textures?

That you can disable the addon, and the default textures would come back, without having to reinstall the whole sim to restore them.

As long the sim won't try to load *both* at the same time (and it will be very silly if it did that), the only side effect would be they would take additional disk space. Space that would still have to be wasted anyway, if the developer of such addon made a backup of the original textures, which I'm sure they did.

  • Upvote 3

Share this post


Link to post
1 hour ago, virtuali said:

like addons that needs to replace things such as the default landclass assignment table, the add-on.xml method has been designed to let developers override a default file, with their own version of the file, using the same name, located elsehwere. So, they can can, in fact "modify core files"; without actually replace them!

I want just to reiterate that Umberto is absolutely correct, I am using this technique for my Add-on's.

Best Regards,
Simbol

  • Upvote 1

Share this post


Link to post
11 minutes ago, virtuali said:

The SDK has only one line about this, and it's not very clear but, I can assure you LM thought about this, and starting with 4.1, for each texture there's an internal ID, in order to prevent collisions caused by addons using a texture with the same name of a default one. And, the feature still has bugs, which might explain why developers never tried to use it but, it surely indicates that LM assumed someone would want to replace a default file with something with the same name, without having the addon replacing the original file, which was the idea behind the add-on.xml concept.

 

That you can disable the addon, and the default textures would come back, without having to reinstall the whole sim to restore them.

As long the sim won't try to load *both* at the same time (and it will be very silly if it did that), the only side effect would be they would take additional disk space. Space that would still have to be wasted anyway, if the developer of such addon made a backup of the original textures, which I'm sure they did.

Again Umberto is absolutely spot on, the add-on.xml is what gave me the possibility to release my first freeware so successfully as it allowed me to "override logically" all the system lights default effects without touching any LM original files which is absolutely essential under their LM new guidelines and rules for developers.

Best Regards,
Simbol

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now