Hi Gerad,

for sceneries I also still use the old scenery.cfg method.

For aicrafts, I use the XML method.

If you install into a P3D FAKE folder, you will see what files have been installed in the effects / sound / world folders. But this is only if you want to move the scenery to an other location and copy the files manually.

Is there any way to verify that all textures, autogen objects etc. are being loaded and no .xml or .cfg file is corrupted because of the character set change?

My problem is that Prepar3D v4 is running about 50% faster than 3.4. For example, where I was getting ~20 FPS in 3.4, I'm now getting 30 FPS (30 FPS locked). So I want to make sure it's actually rendering everything correctly.

Don't look a gift horse in the mouth......  

If there's a problem with one of the xml files, the add on will not load. You can check which are loaded in the options/addons menu in the sim. If it's there, it's loaded.

Same with the scenery library - if it's listed as active, it's loaded.

The only issues hard to determine is if by chance you get a corrupted bgl file in the scenery. You generally won't get an error until the scenery is loaded for use and then it usually results in the sim crashing.

Fly to different specific areas that have noticeable landmarks and see if they look ok.

Or enjoy the increased FPS and don't worry about it.

 

Vic

 

 

 

I have just recently discovered the excellent Addon Organiser by the author of this topic.  When running it I checked for "encoding errors" with the result shown in the image below;

An example of the text from one of the .xml files reported with the error is shown below;

P3D is installed in my D Drive while the "Documents" folder is located on E.

Only one adon-on.xml is not reporting a error but I can see now obvious differences in the format of the text.

All the problem add-on.xml have been created by the installers for the various products and function / show up fine in P3D.

Curious?

 

So how many people like me and quite a few others have hit the xml limit bug in V4?

if you dont know there is a significant bug in V4 with a limit and if you have more xml addons than this variable user to user limit your aircraft models render black textures or entire missung sections depending on the model itself.

i

I hit it at about 80 or so..so installed the excess user scenery.cfg method and problem solved.

The other common traits to trigger this was GSX and/Or FSDT Louisville.

LM are working on trying to find the problem and even with only 70 addons i have black textures in GSX on pushback tugs...disable another 30 addons textures are back.

Hopefully they find a solution if not ill be dumping xml on all my scenery except those that have security tied to it like FSDT and putting them all in via scenery.cfg to this issue.

So if you find your aircraft rendered in black carbon fibre like textures or missing external and internal textures its an easy fix to at least get your aircraft flyable again.

4 hours ago, DEHowie said:

So how many people like me and quite a few others have hit the xml limit bug in V4?

if you dont know there is a significant bug in V4 with a limit and if you have more xml addons than this variable user to user limit your aircraft models render black textures or entire missung sections depending on the model itself.

i

I hit it at about 80 or so..so installed the excess user scenery.cfg method and problem solved.

The other common traits to trigger this was GSX and/Or FSDT Louisville.

LM are working on trying to find the problem and even with only 70 addons i have black textures in GSX on pushback tugs...disable another 30 addons textures are back.

Hopefully they find a solution if not ill be dumping xml on all my scenery except those that have security tied to it like FSDT and putting them all in via scenery.cfg to this issue.

So if you find your aircraft rendered in black carbon fibre like textures or missing external and internal textures its an easy fix to at least get your aircraft flyable again.

Well I had 3 customers last week reporting PD3 crashes during startup, their issues started after having more than 19 add-on.xml files, so it seems the limit varies across systems.

The solution for them was to bundle multiple scenaries / add-on's on single Add-on.xml to reduce the number of "add-on.xml" files and this solved their PD3 crashes during startup.

Regards,
Simbol

Quote

I have just recently discovered the excellent Addon Organiser by the author of this topic.  When running it I checked for "encoding errors" with the result shown in the image below;

You can safely ignore that error report.

It seems the utility is assuming that every configuration file in the sim must be encoded in Unicode ( UTF-16LE ), which is certainly valid for all various .CFG files, like the scenery.cfg, the add-ons.cfg and other .cfg files, it's NOT the case for XML configuration files.

XML configuration files follows the rules of the XML standard instead, which means there's an (optional) header that can specify the encoding and, in order to be legal XML, the actual encoding of the file must match the encoding declaration in the header.

If there's no header, it's assumed the XML it's encoded in UTF-8 with NO BOM (byte-ordering mark) so, as far the file doesn't use characters with a code higher than 127, not having a BOM, it's the same as an ascii file.

Also, I've noticed you posted the add-on.xml for the FSDT Addon Manager, and I see there's an UTF-8 header declaration, which we DO NOT have in our original file, which indicates the file has been altered. We don't add the declaration because, according to the XML standard, it's not required and, if it's missing, the XML standard dictates the file encoding is assumed to be UTF-8 so, it shouldn't make any difference if the header is there or not, I only pointed it out because it seems that someone or something modified our add-on.xml, perhaps that utility added the supposedly "missing" (not required, according to the XML standard) declaration ?

The proper way to check XML files for correctness, would be instead checking the header against the actual file encoding. So, for example, an XML with an UTF-8 declaration (or a missing declaration, which it's the same as saying "UTF-8"), that has been encoded in UTF-16 should have been labeled with an incorrect encoding. Assuming it "must" be UTF-16, just because all the .CFG files are, it's not right.

Of course, the easiest way to check an XML file for being legal XML, would be using the routines supplied with Windows, without worrying about trying to parse the file manually. Basically, if Internet Explorer can open it, it IS legal XML, and it will work in the sim, or with any XML-compliant application. The same routines are available to developers making a Windows application, so that would be the proper way, in a program, to detect if an XML file is correct or not.

Having an utility checking the legality of an XML file IS useful, because the wrong file encoding caused a lot of grief in FSX, that only had ONE XML file which, by convention (this was how the samples in the SDK were made), had an encoding of Windows 1252 (Latin-1), but some bugged installers from other apps added their own sections to it, and in the process changed the encoding to UTF-8, likely because it's the default, without taking care of changing the existing header, which resulted in the XML file being illegal, which would then confuse other (proper) installers, that also tried to add their own sections to it using the standard XML routines that comes with Windows, which would fail if ran over an XML file which was made illegal because of the declaration not coherent anymore with the header.

But now, with P3D allowing for each add-on having its own .XML file, at least, rogue installers will only damage their own .XML files...

 

Quote

All the problem add-on.xml have been created by the installers for the various products and function / show up fine in P3D

Of course they do: which just shows the error message is bogus, and confusing.

Here's my experience with recently purchased FSDT scenery.

I installed FSDT PHNL, Hawaii 1 & 2 into P3DV4 last night. After running P3DV4 and then activating the three packages, I restarted P3DV4. P3DV4 would not run...

P3DV4 was running perfectly before installing the new FSDT scenery. So, I ran the Lorbi addon organizer and checked the encoding options. It stated there were encoding errors in the add-on XML files of these programs along with the add-on XML addon manager.

I opened each of the add-on XML files in NotePad ++ and saved them as UTF-8 BOM. After this, I was able to run  P3DV4 without crashing...

Quote

I installed FSDT PHNL, Hawaii 1 & 2 into P3DV4 last night. After running P3DV4 and then activating the three packages, I restarted P3DV4. P3DV4 would not run...

This doesn't have anything to do with the XML encoding which, as I've said, it's totally correct as installed. No header declaration and no BOM, according to XML standard. This is confirmed to be working and doesn't require any change.

In fact, it shows exactly the opposite: if the XML file wasn't right, the sim wouldn't have even loaded it, so it was impossible that it wouldn't run, because what blocked it from running, was instead a compatibility setting in your system, which conflicted with our software modules. The sim stopped to run because the modules *were* loaded, indicating the XML was right and was in use by the sim.

Quote

I opened each of the add-on XML files in NotePad ++ and saved them as UTF-8 BOM. After this, I was able to run  P3DV4 without crashing...

This was entirely unnecessary and, even if you think this fixed the problem, it was just a coincidence. 

What really happened, is the Windows compatibility flag that has been mistakenly set by Windows automatically on the first run, which was the REAL cause of the crash, has been cleared by something.

We clear it automatically from the Live Update, which is run at the end of every installation, but there are several other utilities that do this, since this setting affects each and every developer module (it's the famous Ignorefreelibrary in the registry), so many other utilities/programs (SODE, etc.) automatically clear it when they are started. Sometimes Windows it's even smart enough to clear it itself when the sim runs another time, just as it was wrong to set it in the first place.

So no, the XML files we install are perfectly fine as they are. I just tested all possible combinations, and these are the results:

1) add-on.xml with no encoding declaration and no BOM, which is how we install it by default. WORKS

2) add-on.xml with UTF-8 declaration and no BOM. SIM WORKS, ADD-ON DOESN'T LOAD

3) add-on.xml with UTF-8 declaration + BOM. SIM WORKS, ADD-ON DOESN'T LOAD.

4)  add-on.xml with no encoding declaration + BOM. WORKS.

5) add-on.xml with UTF-8 declaration, saved as UTF-16LE + BOM. SIM WORKS, ADD-ON DOESN'T LOAD (expected, since the file is now illegal XML, since the encoding doesn't match the declaration)

6) add-on.xml with UTF-16 declaration, saved as UTF-16LE + BOM. WORKS (expected, since the declaration matches the actual encoding).

7) add-on.xml with no encoding declaration and no BOM, with an error (a non-closed tag) added intentionally:  SIM WORKS, ADD-ON DOESN'T LOAD (expected, since the file is now illegal XML)

8) add-on.xml with UTF-16BE declaration, saved as UTF-16LE + BOM. SIM WORKS, ADD-ON DOESN'T LOAD (expected, since the declaration doesn't match the encoding)

This clearly indicates:

- An Add-on.XML which is malformed won't stop the sim from starting, but it will just prevent its own Add-on from loading.

- BOM is required or not depending on the declaration.

9 minutes ago, virtuali said:

What really happened, is the Windows compatibility flag that has been mistakenly set by Windows automatically on the first run, which was the REAL cause of the crash, has been cleared by something.

Umberto,

I totally understand what do you mean because as a comercial member I follow lots of topics and forums inside the PD3 developer forums, however readers of this topic will find the paragraph above confusing and therefore so you might need to give a better explanation / overview regarding the windows compatibility flag and other Windows 10 automatic blacklisting of DLL's techniques in order to allow general public to understand your point better.

Glad to see you here sharing your knowledge.

Best Regards,
Simbol

16 minutes ago, simbol said:

Umberto,

I totally understand what do you mean because as a comercial member I follow lots of topics and forums inside the PD3 developer forums, however readers of this topic will find the paragraph above confusing and therefore so you might need to give a better explanation / overview regarding the windows compatibility flag and other Windows 10 automatic blacklisting of DLL's techniques in order to allow general public to understand your point better.

Glad to see you here sharing your knowledge.

Best Regards,
Simbol

Maybe this thread is not the best place to discuss about this but, the IgnoreFreeLibrary <NAME OF INNOCENT MODULE> has been with us for years, and it affects everybody's modules. For example, here's the victim is FSUIPC:

http://forum.simflight.com/topic/73518-possible-solution-for-fsuipc-access-violation/

In FSX, it would have caused the "Flight simulator has detected a problem with a third party software program”, and *usually* (not always) a crash. In P3D4, it will just lock the sim from starting up with no messages.

This Windows "feature" it's called Program Compatibility Assistant and, the way it works, it seems to kick in automatically when trying to run programs that Windows assumed might have crashed because of not being fully compatible with it. Maybe they crashed for entirely different reasons but, if Windows set that flag, it will stay there until cleared and it will prevent the sim from starting, if the affected module is a .DLL.

It's possible to turn off this feature permanently, by setting the following registry key to 1

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\AppCompat\DisablePCA

Normally, the key doesn't exists so, in order to set it, a new DWORD must be created in that registry key, with a value of 1, and REBOOT the system.

I did message Orbx few months ago regarding this issue.  In my book they are the biggest player for addons, and they need to follow with the new method.  Their official response at this time they won't be following it has P3Dv4 new method is still broken.

 

Current method which I know we all hate puts damn files everywhere in the system, and when time come to upgrading - there is always a chance something could be broken.  And then P3D Team says it is not us it is scenery maker, and then scenery maker says it is not us it is P3D team. 

 

Why can't everyone sit on a table and come up with a new solution.  Installing all addons should be outside the sim period, blame MS for allowing developers use the sim directory for addons and bad habits got created.

1 minute ago, Skywolf said:

Current method which I know we all hate puts damn files everywhere in the system, and when time come to upgrading - there is always a chance something could be broken.  And then P3D Team says it is not us it is scenery maker, and then scenery maker says it is not us it is P3D team. 

Of course, it also depends how it's used by developers.

Using the add-on.xml just for the sake of using it, and continuing to put files in to the sim it's not very smart, yet some developers are doing this.

Using the add-on.xml and placing all the actual files of the addon itself *into* the Documents folder, is not very smart too, since it will force users to waste space on the drive that holds the Documents (usually C:), when the add-on.xml clearly allows to specify any path for the actual files, and the only space "wasted" should be the one taken by the tiny add-on.xml itself, under the Documents\Prepar3d v4 addons folder. 

Using the add-on.xml and not placing it in the Documents folder, it's not very smart either, because this will cause the addon to lose the auto-discovery feature, which means if the sim is reinstalled, and its configuration files are cleared, that addon would require to be reinstalled, or the user would have to manually add it to the now cleared add-on.cfg file.

I just purchased the P3D v4 and I just installed an addon scenery. It says to go to Options / Scenery Library and add the scenery. When I clicked on the Options button on the selection screen, there is NO Scenery Library there. I've also did this within the sim, selected Options from the menu, clicked on Add On, and there is nothing there. The installer is not the problem. I've read the manual and it does not discuss this or anything other than what to do, and I did exactly what it says. What is the problem?

Ken. Manning

Edited March 20, 20188 yr by kmanning

8 minutes ago, kmanning said:

I just purchased the P3D v4 and I just installed an addon scenery. It says to go to Options / Scenery Library and add the scenery. When I clicked on the Options button on the selection screen, there is NO Scenery Library there. I've also did this within the sim, selected Options from the menu, clicked on Add On, and there is nothing there. The installer is not the problem. I've read the manual and it does not discuss this or anything other than what to do, and I did exactly what it says. What is the problem?

Ken. Manning

I belive it's under "world", not under "options". I can't check it right now