Drzewiecki Tallinn (EETN)

[Panman]

It would seem that upon installing this software that GSX no longer loads automatically when starting FSX.

I have checked my [Trusted] section in my fsx.cfg and coatl entry is there.

I originally posted this on the Drzewiecki forum and they acknowledged this and said that currently GSX and Tallinn are not compatible.  I will be reinstalling GSX as they recommended.  I'm just wondering if FSDT and Drzewiecki could work together to solving this problem as Drzewicki intend to use this new feature in all upcoming sceneries and I don't want a broken GSX because of it.

PanMan

[Bruce Hamilton]

He knew it broke GSX, and still released it... he should fix it.   

[virtuali]

Do they use some kind of add-on module ? That's the only explanation I can think of why a scenery wouldn't be compatible with GSX, the other being released with a defective AFCAD.

[Panman]

Yes it's called SimObjectDisplayEngine (SODE for short).

So far it stops EZDOK and GSX from loading at FSX startup.  Waiting to see if anything else is affected.

PanmaN

[Bruce Hamilton]

I just looked at the web site for SODE, it's made to allow developers to control animations based on events or triggers, such as opening and closing hangar doors.  Might explain why it breaks Couatl.

[sas407]

I found out the problem why UT2, ezca and GSX didn´t start..the exe.xml (C:\Users\Niclas\AppData\Roaming\Microsoft\FSX) with command lines for ezca, UT2 and couatl(gsx) were empty except for command lines for SODE. SODE deleted my existing file when I installed EETN and this is now confirmed by DD

http://drzewiecki-design.net/forum/viewtopic.php?t=280&postdays=0&postorder=asc&start=15

[Panman]

Well I manually added them back into the exe.xml file and all is well.  Though at Tallinn I can only use either GSX or SODE but not both.  Depending on what stand I use will govern whether I use GSX or SODE.  One with a jetty then SODE, one with out then GSX.  But fancy overwriting and not appending to a fsx xml config file....

PanmaN

[virtuali]

But fancy overwriting and not appending to a fsx xml config file...

I found their explanation even more disturbing:

I was not aware that this file is used by other add-ons (scenery developers usually don't need it), hence why the problem occur.

The "scenery developers usually don't need it" doesn't make any sense: even if it's not common for scenery developers to add their own modules to the EXE.XML file (but THEY did it!!), it's not obviously a good reason to wipe it out and replace it anew, instead of using proper XML parsers to add their section in the correct way, like we did for ages, and of course the EXE.XML is used by MANY other 3rd party modules, like UT2, Saitek, GoFlight, Opus, EzDoc Camera, and many others, without even considering GSX and/or XPOI, that aren't sceneries, and all of them will be disabled by this faulty installer.

[Bruce Hamilton]

This is what can happen when you beta test your own sceneries, community beta testers would've been all over them about this.

[w6kd]

Well I manually added them back into the exe.xml file and all is well.  Though at Tallinn I can only use either GSX or SODE but not both.  Depending on what stand I use will govern whether I use GSX or SODE.  One with a jetty then SODE, one with out then GSX.  But fancy overwriting and not appending to a fsx xml config file....

This is an old problem, but while I was doing some digging into this scenery today, I found that DD used a different naming convention in their SODE sdx file (the jetway gates are named Gate_A in the sdx file) and in the airport/ADE file (the jetway gates are named "Gate" without the "A").  If you rename the terminal parking spots in ADE, changing "Gate" to "Gate_A", and recompile, then GSX finds the SODE jetways and controls them just fine.

Regards

Bob Scott