Support overload. We are currently seeing 65% more demand for support then we normally see. We can only assume this is because more people are at home due to the corona crises. Our complete support staff is online and they are working flat out, but it will take some days before we can scale up resources. Please be patient.

Jump to content
Mathijs Kok

SODE issues

Recommended Posts

Just got an email from Evgeny, that you can use also version 1.21 of the SODE engine and he is already in contact with Jeffrey.

Share this post


Link to post
Share on other sites

That was quick from Evgeny. By the way, just if somebody has updated SODE to V1.22 from Jeffreys web site a while ago. This version does also work with LOWS and the other v.1.21 airports. Just in case someone worries.

Share this post


Link to post
Share on other sites

I did a clean install last night. I put LOWS on first and then EPWA by Drzewieki all is working fine now with lights at Salzburg and Jetways at Warsaw. 

 

At least there is some way to resolve

 

Share this post


Link to post
Share on other sites
On 12/31/2015 at 9:12 PM, Cargostorm said:

Be aware that LOWS installs SimObjectsDisplayEngine.exe (v.1.03), which will break the correct functionality of all other SODE airports that were developed with v1.21 SODE as this file is replaced during installation ( you will not see the SODE menu for instance or TAB-S / jetways will not work). Just replace the v.1.03 with the the (hopefully) backuped v.1.21 file, and all SODE airports will work again. So far I have found no issues with LOWS running with v.1.21. I am sure the developer of LOWS, Evgeny, will come out with a patch soon.

OK - I have SODE 1.21 and LIRF (also have DD ULLI) and was about to buy LOWS today until I read this problem. I had a look in my FSX folder to find a SODE folder. In there the SODE.exe says version 1.21. If I were to go ahead and purchase LOWS (I really like it but I can wait until I receive a reply from DD - I sent them an email just now asking if they were aware of this problem), how do I back up my current SODE installation? Are there registry entries as well that I need to worry about? Would just hanging on to the SODE folder I have now be good enough and simply paste it back in my FSX later work? 

 

I've already lost a default FSX stock key shortcuts because of SODE (Shift + -) and had to change "decrease selection" to another key combination so I can zoom out. What really bothers me about this is the fact that there is zero documentation on how to even use SODE - at lease not any that I can find! What's the point if it can't be used to actually move non AES/FSXstock type jetways? I already use AES and have spent way too much money on it to ditch it for something I know nothing about. 

 

Anyway - just need to know if I should wait for DD to update LOWS or if it is safe to go ahead and install if I save my current SODE folder. 

 

Cheers folks,

Bill A

Share this post


Link to post
Share on other sites

Bill, simply backup the SODE folder (1.21) and after installing LOWS (which will overwrite the SimObjectDisplayEngine.exe with an old one), simply copy back from your safed folder the "SimObjectDisplayEngine.exe" one and overwrite the one installed by LOWS.

Nothing else will be affected by the LOWS installation as I was told

Share this post


Link to post
Share on other sites
On 1/7/2016 at 11:08 PM, mopperle said:

Bill, simply backup the SODE folder (1.21) and after installing LOWS (which will overwrite the SimObjectDisplayEngine.exe with an old one), simply copy back from your safed folder the "SimObjectDisplayEngine.exe" one and overwrite the one installed by LOWS.

Nothing else will be affected by the LOWS installation as I was told

Thank you so much for your reply Otto. It works just fine this way. While on the subject, Evgeny says that the latest SODE version will be included in the full installer an about a week. I believe that is v1.3 ...

 

Best to all! 

Share this post


Link to post
Share on other sites

If its version 1.3 then it will break all of the previous sceneries that use SODE jetways as they haven't yet been recompiled. Certainly the DD ones haven't and I don't think LIRF has either.

Nick

Share this post


Link to post
Share on other sites
9 minutes ago, Er!k said:

LatinWings LEVC also makes use of SODE v1.3...

Don't think so, from the manual:

2016-01-22_13h00_29.jpg.576d3eb87c05e824

Share this post


Link to post
Share on other sites
On 12/21/2015 at 3:09 PM, 12bPilot said:

SODE includes two modules, the main exe and the animation dll. So yes, both are required with their respective entries in the dll.xml and the exe.xml. Version 1.3 comes with the SODEPlatformManager.exe which should handle all these entries editing for you. It also takes care of writing the entries into the correct path in case of P3Dv3 (i.e. ProgramData and not Roaming).

 

I just installed EPWA which comes with SODE 1.2.2 but I'm a bit confused because when I check the dll.xml and exe.xml in C:\ProgramData\Lockheed Martin\Prepar3D v3 they are both empty with on addons. However when I check the same files in C:\Users\<MyUserName>\AppData\Roaming\Lockheed Martin\Prepar3D v3 they are normally populated by the addons I've installed so far that do write things to these files such as ASN, FSUIPC, some PMDG stuff and so on. And still I'm using P3Dv3.

 

So...looking at what you say it should be the other way around in P3Dv3...that the correct location for these files would be ProgramData and not Roaming as it is in my case. Does this indicate I have some problem with my P3Dv3 installation? Still everthing so far seems to be working just fine so doesn't appear to be an issue although the path is incorrect according to what you say for P3Dv3.

Share this post


Link to post
Share on other sites
vor 2 Stunden , WebMaximus sagte:

 

I just installed EPWA which comes with SODE 1.2.2 but I'm a bit confused because when I check the dll.xml and exe.xml in C:\ProgramData\Lockheed Martin\Prepar3D v3 they are both empty with on addons. However when I check the same files in C:\Users\<MyUserName>\AppData\Roaming\Lockheed Martin\Prepar3D v3 they are normally populated by the addons I've installed so far that do write things to these files such as ASN, FSUIPC, some PMDG stuff and so on. And still I'm using P3Dv3.

 

So...looking at what you say it should be the other way around in P3Dv3...that the correct location for these files would be ProgramData and not Roaming as it is in my case. Does this indicate I have some problem with my P3Dv3 installation? Still everthing so far seems to be working just fine so doesn't appear to be an issue although the path is incorrect according to what you say for P3Dv3.

 

Hi

 

Both locations will be read by Prepar3D v3, so both locations are valid. P3D merges the different exe.xml and dll.xml files together. However, LM recommends to use ProgramData (higher priority and Prepar3D default path) over the Roaming folder. When using Prepar3D's own add-on installation mechanism, it will write into the ProgramData folder per default. So that's why I assume this is "the more correct" folder.

 

For reference, this is the source for that piece of info (straight from the SDK, applicable to dll and exe Add-Ons); 

Libraries and Executables

The priority for how add-on library and executable configuration files differs from content and is initialized as follows:

 

  • ProgramData: Configuration files named dll.xml or exe.xml found at: %PROGRAMDATA%\Lockheed Martin\Prepar3D v3
  • Roaming: Configuration files named dll.xml or exe.xml found at: %APPDATA%\Lockheed Martin\Prepar3D v3

If multiple configuration files are found, then the list of paths are merged together when processed according to the above priority. When an add-on library is initialized, the dll is loaded. When an add-on executable is initialized, the executable is started.

 

It is a little trickier now having two locations with those xml's, since it could lead to loading a module twice and hence introduce trouble.

 

Cheers

Share this post


Link to post
Share on other sites

Many thanks for this great info answering my question spot on!

 

Still a bit surprised though why all addons I installed so far writing stuff to these files have used the old path when they claim to be P3Dv3 compatible. According to your info it will still work since both pathes are processed but would make more sense using the new and most correct one.

Share this post


Link to post
Share on other sites

Richard,

 

it's totally ok for those Add-Ons to claim to be compatible as LM clearly states to read both locations. 

 

I think the reason why LM introduced the new location and also favors it is, that they wanted to get rid of configuration data being tied to a user account, but instead being tied to a machine. Even MS is doing it the same way, as the "All Users" folder is a link to the "ProgramData" folder. Not sure since when exactly MS is doing this, bus at least since Windows 8.

 

So for LM it was just logical to move their stuff also there (to become machine and not user tied anymore), but of course they needed to keep compatibility.

Share this post


Link to post
Share on other sites

Thanks for your input Tom and sorry if my last post maybe came out a bit wrong.

 

I didn't mean to imply it was incorrect to use the old path since the SDK clearly states that path is still used. I guess what I wanted to say and meant was that if I was about to write an addon for P3Dv3 and I knew the new and recommended path I would prefer to use that one rather than the old one even if the old one still works.

 

I guess the main problem if you ask me is you now have to check 4 files rather than 2 if you have any issues where you suspect the culprit could be within the contents in these files.

 

The user vs machine thing isn't a problem in my case since I only use one single account for everything but I do see why LM (and MS) rather use a path not tied to a specific user account for software that could be used by multiple users on the same computer.

Share this post


Link to post
Share on other sites

Another question on the same topic.

 

Reading the post #12 earlier in this thread found here it says you can manually download the latest version of SODE and then migrate the titles not yet oficially updated with help from a migration guide.

 

Did someone in here already try this for EPWA for example? I haven't paid that much attention to SODE up until now but the way I understand it the version of SODE that is installed with the current version of EPWA for example (1.2.2) can cause stutters and pauses and of course I would like to avoid that if possible.

 

I guess another option would be to simply disable SODE in both exe.xml and dll.xml until the products have been updated to be compatible with the latest version of SODE but if there's an easy way to accomplish the same things yourself without having to wait of course that could be interesting.

Share this post


Link to post
Share on other sites

DD Stanislaw (DRZEWIECKI DESIGN) just stated in his forum that his airports will be updated with SODE 1.3 sometime in spring time.

 

Better to stay with SODE 1.21 or 1.22 for the moment. Valencia X will only work with 1.3 though, which is not backwards-compatible to SODE 1.21 / 1.22.

Share this post


Link to post
Share on other sites

Yep, I'm thinking the same thing. Probably best to wait for the official updates.

 

One question though, the problem with SODE 1.2 people have been talking about with stuttering and micro pauses does that happen only when close to a SODE airport or everywhere just by having 1.2 of SODE installed?

 

And is disabling SODE in the exe and dll xml files a good and safe way to enjoy the scenery only without features provided by SODE or could it brake other things as well? 

Share this post


Link to post
Share on other sites

Of course you can disable SODE, and there will be no crashes. But you will be missing runway/taxi lights, which can be a bit annoying during night time.

Share this post


Link to post
Share on other sites

That stuttering comes from the Jetway Control System. So if you are near an airport that uses SODE jetways, it will occur once the jetways are loaded. On airports that use SODE for other things but not for jetways, there is no problem. Again, this is for SODE 1.2.2! V1.3 has those issues ironed out.

 

Disabling SODE does not break anything in terms of introducing crashes or such. Depending on how the developer used the module, some objects might not appear. So missing objects are the consequence.

For EPWA for instance, these would be the jetways, some vegetation and some hangar doors.

Share this post


Link to post
Share on other sites

Ok, thanks guys!

 

I think for now I'll disable SODE because I rather miss some objects and features vs suffering from stuttering issues.

Share this post


Link to post
Share on other sites

is there any news about a timeline when SODE 1.3 compatible jetways for the "1.21 airports" will be available? - there's an awful silence about that

Share this post


Link to post
Share on other sites

Do the jetways even work on Valencia? or are they disabled at all for now? I don't quite get it, seeing as the s tab combo does nothing, even though the dll check comes back working.

Share this post


Link to post
Share on other sites
19 minutes ago, Victoroos said:

Do the jetways even work on Valencia? or are they disabled at all for now? I don't quite get it, seeing as the s tab combo does nothing, even though the dll check comes back working.

 
LEVC X is ready to work with SODE 1.3 but not until aerosoft authorizes no such version is released,
 to prevent other scenarios that work with 1.2 suffer any damage , static moment this friend .

Share this post


Link to post
Share on other sites

This entire "SODE saga"  seems to have opened a huge can of worms (for me anyway). At the least, it has me extremely confused (and worried) for a number of reasons. Why not simply use one version of SODE and dispense with all these other ones?  

 

I have SODE v1.22 sitting in my FSX/SODE/ folder. This one is for ULLI, LIRF, and some Drzweiki airports. Today, Evgeny updated LOWS and as I finish the install routine, I have stopped right here (see the top screenshot) with the final installation of SODE 1.3 that wants to install into C:\Program Files(x86)\12bPilot\SODE\  <<< why put it here and not in FSX root directory?

 

If i go ahead and install it as it shows here, will it break my SODE 1.22 airports that I mentioned above?  I am too afraid to go ahead with this installation until I know for certain it won't break anything else I have. I have taken screenshots of my current SODE folder in the FSX root directory to hopefully clarify what airports SODE 1.22 is supporting.

 

Your replies will be greatly appreciated.

 

Thanks, Bill A

1.25.2016 23-28-24.jpeg

1.25.2016 23-34-52.jpeg

1.25.2016 23-35-11.jpeg

1.25.2016 23-35-21.jpeg

1.25.2016 23-35-25.jpeg

1.25.2016 23-35-31.jpeg

Share this post


Link to post
Share on other sites
18 minutes ago, phantomflyer said:

I have SODE v1.22 sitting in my FSX/SODE/ folder. This one is for ULLI, LIRF, and some Drzweiki airports. Today, Evgeny updated LOWS and as I finish the install routine, I have stopped right here (see the screenshot) with the final installation of SODE 1.3 that wants to install into C:\Program Files(x86)\12bPilot\SODE\ 

Interesting path;, but dont believe that this is correct. Look at the path for the sode dll in the dll.xml, what has been written there. Also I would contact Evgeny about this.

Share this post


Link to post
Share on other sites

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

×
×
  • Create New...