After installation + activation of KLAS all FSDT-FSX sceneries are in test?

[GerdD]

Can confirm that updating the EXE.XML was the issue.
Just to summarize, I did the following:
- replaced EXE.XML by a version before FSDT
   (this version had already a functioning entry from another software)
- installed KLAS
   (this installation has used the start tag for it´s own entry so that one start tag was missing)
- corrected EXE.XML with missing start tag
- started FSX with trusting Couatl
..and everything was fine again!

So FSDT should correct it´s installation into EXE.XML if there is already another entry available.

Many thanks for all the help, ideas and patience.

Gerhard Dresch

[JamesChams]

...So FSDT should correct it´s installation into EXE.XML if there is already another entry available....

Mr. Gerhard Dresch,
I said that to them once too... and, do you want to know what they told me then? 

The famous words "Its NOT a problem here." 

But, in all fairness, I was the only one reporting it as an issue at the time and honestly, untill now, I'd never seen anyone else report it.  But, for me the issues is resolved although, it might happen in the future for another product so it might be a good thing for them to look at it again and get "TIDY.exe" to tidy-up a little better.

Later!

[virtuali]

So FSDT should correct it´s installation into EXE.XML if there is already another entry available.

Don't you think that something as obvious as that has been tested already ? If it wasn't, we would have the installer to fail for EVERY user that has more than an entry on EXE.XML!! Which of course it's not the case.

So, your EXE.XML before the installation must have had something different than usual, and it might be helpful to have a look at it, otherwise there's no chance to improve the installer.

Most of the code in the installer is there JUST to fix issues or anomalies created by others, that's why we first run the XML file with the MS XML validator BEFORE touching it.

[GerdD]

I cannot justify if my EXE.XML had something "unusual".
The only entry in there was always from Goflight´s driver and
was not currupt and worked all the time. This one was always proved
from your installations and found ok. But was corrupt AFTER the FSDT installation
so that the next FSDT installation had problems. (You remember, I have all the 5 airports)
That was the reason why Couatl never came up in FSX for trusting.

These are the facts from a customers perspective. You can accept this and talk to your developer
or you can ignore it and getting faced with the same again. It is not a shame if something does
not work perfectly, but it is a shame not to accept it if it´s obvious.

Kind Regards
Gerhard Dresch

[GerdD]

P.S.
Have sent 2 EXE.XML files to your support email.
The one before FSDT installation and the one after.
Hope this helps identifying and fixing the installer problem.


Gerhard Dresch

[virtuali]

This one was always proved
from your installations and found ok. But was corrupt AFTER the FSDT installation

I'm sorry, but I've just tested the files you sent me now, and there's are no problems with the installer. Your file was correct BEFORE running the installer, and it's still correct AFTER.

This is the file you sent me:

Code: [Select]

<?xml version="1.0" encoding="windows-1252"?>
<SimBase.Document Type="Launch" version="1,0">
  <Descr>Launch</Descr>
  <Filename>EXE.xml</Filename>
  <Disabled>False</Disabled>
  <Launch.ManualLoad>False</Launch.ManualLoad>
  <Launch.Addon>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Name>GoFlight Hardware Interface</Name>
    <Path>C:\Programme\GoFlight\GFDevFSX.exe</Path>
    <CommandLine></CommandLine>
    <NewConsole>True</NewConsole>
  </Launch.Addon>
</SimBase.Document>

and this is the modified file I've get after installing KLAS:

Code: [Select]

<?xml version="1.0" encoding="Windows-1252"?>
<SimBase.Document Type="Launch" version="1,0">
  <Descr>Launch</Descr>
  <Filename>exe.xml</Filename>
  <Disabled>False</Disabled>
  <Launch.ManualLoad>False</Launch.ManualLoad>
  <Launch.Addon>
    <Name>Couatl</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>fsdreamteam\couatl\couatl.exe</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Name>GoFlight Hardware Interface</Name>
    <Path>C:\Programme\GoFlight\GFDevFSX.exe</Path>
    <CommandLine></CommandLine>
    <NewConsole>True</NewConsole>
  </Launch.Addon>
</SimBase.Document>

So, the installer doesn't corrupt it, it must have been something else.

Could be one of your FSDT installers was older ? Because, we keep updating its code, each time we found new "unusual" things, like in this case the empty <CommandLine> tag, which is not illegal, but not very common. The current installer is able to deal with it, but I'm not sure since when, probably after one of the LSGG updates.

[GerdD]

The shown file did not agree with the one I´ve sent you.
In my one the first line was not in. Please check my mail again.

In the file "after Update" I´ve sent you, line 13 was missing.
As this file was updated from the installer in KLAS yesterday,
for me this installation does corrupt this file.
(you remember, I replaced EXE.XML with the one I´ve sent you before the update)

Perhaps this missing 1st line is causing the problem.
I can asure that EXE.XML has never updated by any other
software excpt Goflight + FSDT. Also not manually.

Gerhard Dresch

[virtuali]

The shown file did not agree with the one I´ve sent you.In my one the first line was not in. Please check my mail again.

Yes, you are right, your email file didn't have the XML header.

So, that's the issue: which just confirms what I was saying all along: you had an unusual EXE.XML file, because it didn't had the XML header, which is mandatory for XML docs encoded with the Windows codepages, it's optional only for UTF-8 or UTF-16 files, which is not the case here so, it's good practice to always include one. In fact, the sample EXE.XML provided by Microsoft FSX SDK has the header, and all XMLs produced by any of the MS SDK tools always have an header, and anything on MSDN says the header must be present. And, the companion DLL.XML that is installed together with FSX (EXE.XML is not automatically created, but DLL.XML is) has an header so, I guess this should be considered the official standard.

I think this issue is that the GoFlight installers that originally created your EXE.XML, didn't put the header, and that confused our installer. FSX probably tolerates the file anyway, because it just assumes Windows 1252 code page but, I wonder what might happen on a Japanese or Russian FSX...

So, we just need to add another special case of fixing strange stuff created by others in the installer. Fixing the missing header, before doing anything else, in this case...

[virtuali]

GerdD,

Please, disregard my latest message, I tought the missing XML header in your file might have been a problem, but I haven't checked for it.

I made another test, with exactly the same file you sent me, without the header, and IT WORKS OK! The installer IS able to fix an EXE.XML, even without the header, and there are no problems with GoFlight lines.

However, I need you to do me a favour: can you try again on your system, with the XML file with the missing header, and install the Stand-Alone Addon Manager, being absolutely sure it's the current version we have online right now (it has been updated on KLAS release date ) ?

It's best to use the Stand-Alone version, so there are no issues with uninstalling sceneries, but the XML modying routine is exactly the same so, it's a check that is valid for all installers.

Because, the XML fixing stuff is made launching an included executable program we include with the installer so, if this has failed on your system, it might be a reason why the XML with the missing header hasn't been fixed, and it might be interesting to know why, if this is the case.

[GerdD]

Have downloaded the latest AddonManager and installed it against
EXE.XML without the missing header. (the one I sent You)
The result is below:

<?xml version="1.0" encoding="Windows-1252"?>
<SimBase.Document Type="Launch" version="1,0">
  <Descr>Launch</Descr>
  <Filename>exe.xml</Filename>
  <Disabled>False</Disabled>
  <Launch.ManualLoad>False</Launch.ManualLoad>
  <Launch.Addon>
    <Name>Couatl</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>fsdreamteam\couatl\couatl.exe</Path>
  </Launch.Addon>
  <Disabled>False</Disabled>
  <ManualLoad>False</ManualLoad>
  <Name>GoFlight Hardware Interface</Name>
  <Path>C:\Programme\GoFlight\GFDevFSX.exe</Path>
  <CommandLine></CommandLine>
  <NewConsole>True</NewConsole>
</Launch.Addon>
</SimBase.Document> 

As You can see, the 2nd start tag <Launch.Addon>
is missing. The same as in my yesterdays KLAS installation.
It looks like the missing header is causing something wrong.

Gerhard Dresch

[virtuali]

As You can see, the 2nd start tag <Launch.Addon>  is missing. The same as in my yesterdays KLAS installation.

It looks like the missing header is causing something wrong.

Yes but, as I've said, it only happens on your machine. I just made a test with the file without the header, and the installer both put the header back as it should, and it does not get confused by the lack of it, because all the <Launch.Addon> tags are correct.

Are you sure you haven't seen any error messages during the installation ?

[GerdD]

Absolutely no error messages during installation.

[GerdD]

Made another test.
At my end Addon Manager definitely only updates properly
if the first line is in the EXE.XML.
My system is a very up-to-date XP SP3.
If it updates properly on other systems without this first line,
only Microsoft components could make a difference.
For example, I also have installed MS C++ 2008 Redistributable.