Rant: Developers, wake up!

[fatal 0]

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?

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..

[Reader 2,009]

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.

 

 

 

[virtuali 4,419]

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.

[fatal 0]

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.

[virtuali 4,419]

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.

[Reader 2,009]

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?

[Skywolf 992]

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

[virtuali 4,419]

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.

[simbol 5,811]

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

[simbol 5,811]

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

[simmerhead 885]

Thanks for all you input Umberto and Simbol. 

And all addons that actually install inside of the main P3D folder and/or make changes to stock files should be clearly labeled as such. That way customers don't have to discover this after the fact. 

By fully implementing the "external xml-method" one can in theory return the sim to its default  state in one quick operation.No more headaches when that one addon screws everything up... 

[simmerhead 885]

2 hours ago, nolonger said:

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.

I don't agree with that sentiment at all. The xml-method is the one LM want developers to use.

For those that don't like it, nothing has changed. They are still free to move whatever files they want into the main P3D folder, and/or replace stock files, edit cfgs and tweak to their hearts content. No need for them to resist a positive change in usability for the majority of users...

[Reader 2,009]

Food for thought here, thanks to those who answered my concerns.

[hs118 707]

Great discussion. Really appreciate the research and thoughtful comments by @simbol and @virtuali.

I have shoehorned all my addons, aircraft and scenery, into addon.xml EXCEPT in those cases (Orbx, Milviz) that could not work otherwise.

Even have Carenado aircraft working without P3D folder install.

Feel pretty strongly that LM will work to get this right, it is an unappreciated capability.

 

[Bruce Nicholson KMFR 20]

I do the same as Henry and some of the others posting here. All of my add-ons other than the few that require it, are located outside the main sim.

The problem with the developers that choose not to use the XML method and/or install outside of the sim (Orbx & Milviz excluded) is that I must "test" every installation before I actually install it. I then build the XML with Lorby's fantastic AO product and move the product files to where I want. I'm paying money for a product and having to manually override the installation process just to protect that product during a future P3D4 upgrade or reinstall.

I agree with Simbol's rant in this topic. Developers, wake up! There are very few reasons why the files need to go into the sim folders. Even the World/Scenery files and Generic texture files can go into external folders and still work properly, when properly set up with the XML method.