Jump to content
Mathijs Kok

SODE issues

Recommended Posts

On 2/2/2016 at 4:22 AM, yakyak said:

I think that Jeffrey can't be blamed for how developers use his product. It's useful to note again that the product is also free for developers to use. If it was a paid product the expectation would certainly be much different. I personally use SODE V1.22 and SODE V1.3 with no problems, although using them both at the same time is problematic if you wish to use the animated jetways while both versions are running. This has been discussed above. Additionally I appreciate Jeffrey's input to these posts concerning SODE, remembering it is a free product. Please keep up the good work Jeffrey, hopefully this is a momentary bump in the SODE evolution.

Nick

Yes Nick, it is a free product but developers are using it in the products we pay for. I have never had any issues with any Aerosoft scenery (and I have plenty of them) until this SODE thing came into existence. This SODE thing has only giving me headaches with the engine stopping every second and jetways disappearing both in FSX and P3D. The jetways also never align themselves with my aircraft's doors correctly and I only use the PMDG 737 and the Aerosoft A320, my passengers have to climb up or down. I never had issues with ctrl-j usage or AES, now I can not buy sceneries I want because of this, like Valencia. There should be an option in the installation giving paying customers the option of choosing this freeware SODE or normal jetways. I see in the forums a lot of issues about SODE, so it have plenty of problems, if something is not broken why fix it with something that does not work correctly. Maybe this is the future but developers should have waited until it work correctly to use it in their paywares. I can guarantee you that if the CRJ wings would disappear from time to time or the FMC usually stop working in beta testing Aerosoft would not release it until those issues were fixed, so why release sceneries with this horrendous feature that have so many problems?.

Share this post


Link to post

Thanks for you input. I agree that some people have had various problems with the implementation of SODE in recent times and I also agree and take your point that we are paying developers that use SODE in their sceneries. My point was that Jeffrey cannot be held to account for how other developers use the tool he created. I also like your idea of having the option to either use or not use the animated jetway part of SODE, noting it is the only part of that add on which had suffered from the move to the new version. I'll bow out of the conversation at this point as I'm sure the moderators have given me enough latitude. Thanks again for your input.

Nick

Share this post


Link to post

While the discussion goes on, still no news from Aerosoft about the LIRF update...

Share this post


Link to post
6 minutes ago, ca210270 said:

While the discussion goes on, still no news from Aerosoft about the LIRF update...

 

Share this post


Link to post
On 2/1/2016 at 5:09 AM, Mathijs Kok said:

Before we can release we need to test, make installers, update systems etc. I will ask if we have received new files.

 

 

Hi Mathijs,

 

For those Airport developers releasing products under the Aerosoft umbrella, is it possible for you to establish (if not already) a series of guidelines, rules, procedures for developers to adhere to in some minimal way ... ensuring your path forward avoids the current SODE situation?

 

It looks like the trend moving forward is to use SODE and as it has been made clear, the developer of SODE is under no contractual agreement to ensure any level of backwards compatibility ... it would be unfortunate to see this issue resurface again in the future with say a SODE v1.4.

 

Cheers, Rob.

 

Share this post


Link to post
35 minutes ago, Rob Ainscough said:

establish (if not already) a series of guidelines, rules, procedures for developers

 

Interesting observation Rob.

 

A year ago a few developers and I spoke about implementing a few important standards for Flight Simulation Software.   While I know you're not reaching that high, your comment touched on the issue. I've worked a great deal with such standards and the organizations and committees which manage them.  Unfortunately there simply isn't the level of understanding, will, or money to accomplish this in the flight simulation world.

 

That said, your idea is very important, and this certainly could be managed at a developer level and written into contracts. I'll go so far as to say it definitely should be, and Mathijs has likely considered this very thing.

 

 

 

Share this post


Link to post

Hey Dave,

 

I know the Orbx crew operate under a "guideline" and developers frequently migrate across publishers.  I don't think "market size" is an issue if the guidelines aren't draconian (overly restrictive and micro-managed) ... they just need to cover the bases.

 

I think it is important if we want to see a minimal level of consistency and provide an easier path for end users.  Every company I've ever coded for has software development policy/procedures (be very small 5 person to very large 120,000 people).

 

In some regards this is where Dovetail Games have an advantage for their DLC ... they can enforce such standards.  But for Lockheed Martin and/or Laminar it's probably something that needs to happen to ensure a "less involved" end user experience and hence increased sales/revenue.

 

Many existing installers all need to be updated any time a new major P3D Version comes out (2 series, 3 series) ... this IMHO is not necessary if you build installers to check back to a server for self updates (this is actually pretty common in my world software development - large or small).  Good examples are PrecipitFX folks (I believe they are using Microsoft's Click Once technology - but there are others) where their installers will update itself and/or application from a central server where deployment occurs.  If you look at many of the FSX/P3D installers of today, they are hard coded versions ... FS9, FSX, FSX-SE, P3D V1.4, P3D V2.x, P3D V3.x ... they're being coded with the hope that at some point platform development will stop, and that's just NOT going to happen.

 

Going forward the overhead for these versions is just going to become (if not already) unmanageable, leaving end users out in the cold, developers frustrated, and publishers not realizing optimal revenue.

 

There are two ways to approach this, the competitive approach or the unified approach ... given the size of this market I would think the unified approach would be most beneficial to all 3rd party.  But unified will not work unless participation happens and enforcement to minimal dev/deployment standards.

 

My 2 cents,

 

Cheers, Rob.

 

Share this post


Link to post

Both Rob and Dave point out some interesting thoughts that I would not have expected in a thread about SODE issues.

For the benefit of anyone that also finds this interesting maybe it would be an idea to open a new thread about it.

Maybe in this new thread Mathijs and the various devs could also chime in and maybe we might get a ball rolling here.

Share this post


Link to post

thats a subject probably suited on FSDev,
just take initiative and post SODE Dev guidelines article!
it will eventually turn to a discussion many will follow,

Share this post


Link to post
On 2/5/2016 at 11:01 AM, The Dude said:

an idea to open a new thread about it.

 

 

Right you are.  I'll get one open and forward to Rob (I believe I have his offline info) and to Frank and Mathijs.

 

Share this post


Link to post
On 01/02/2016 at 2:09 PM, Mathijs Kok said:

Before we can release we need to test, make installers, update systems etc. I will ask if we have received new files.

 

Well I just purchased this scenery and we are now a month further down the road something tells me that there is a problem somewhere down the line...

Any ideas gentlemen?

 

Share this post


Link to post

All I have read this entire thread with interest as I have recently purchased a number of sceneries with SODE and am now having issues similar to those mentioned.

Specifically I have the following:

 

HTKJ, TNCB, UWGG and most recently LOWS which is when the trouble started.

 

Right now I have SODE 1.21 in my FSX folder and 1.30 in my C\program files folder however I now have the following:

HTKJ - no runway, taxiway or apron lighting

TNCB - no PAPI

UWGG - no runway or taxiway lights

LOWS - no runway or taxiway lights

When I go to these airports and access SODE via the addons menu and click on the SODE text.dll I get a response - jetway system ok

When I enter TAB S  the response for all is : no triggerable objects within 12kms

 

Question: Are all the above issues related to SODE?

 

For each airport what response should I get when I enter TAB S?

For TNCB I understand I should get an option to switch PAPI on but its not there?

I get the impression that currently neither 1.21 or 1.30 is working correctly for me?

 

Cheers James

 

Share this post


Link to post

Your impression is correct.  Take a look at your exe.xml and dll.xml files and see what is being loaded.  You may run only one version of SODE at a time...

 

DJ

Share this post


Link to post

Well I decided the best option was to go back to pre SODE days so uninstalled SODE 1.21 and 1.30 and also HTKJ, TNCB, UWGG and LOWS.

Then I removed all remnants of SODE from DLL.XML and EXE.XML.

I then reinstalled UWGG which installed SODE 1.21 followed by HTKJ and TNCB and all 3 worked including the PAPI lights switching on and off at TNCB.

I then backed up my DLL and EXE and all the SODE entries in my FSX root.

Next was a reinstall of LOWS which ofcourse installed SODE 1.30.

I checked the DLL and XML and the entries had changed to point to my C drive rather than D where I have FSX.

I loaded up all 4 sceneries and LOWS worked but the other 3 ofcourse didn't.

Next step was to copy the DLL and EXE entries for SODE 1.21 and paste them so that now I have 2 entries for SODE in both DLL and EXE with one pointing to C\program files and the other to D\FSX.

I changed the manual load entry for all 4 to TRUE.

When I loaded up FSX I was ofcourse asked to accept the 4 entries for SODE which I did.

When the loadup was complete my addon dropdown had 2 entries for SODE. For all 4 sceneries all the lighting worked but I had no DLL test and for TNCB I couldn't switch the PAPI,s on or off.

When I amended the DLL and EXE back to TRUE and loaded up FSX answering yes to SODE 1.30 and no to 1.21 I got full functionality at LOWS and v.v.

So now until the other sceneries are updated to 1.30 I will keep 1.21 and 1.30 installed and select one or the other each time I load up FSX dependent on where I am flying....done and thanks to the above post which suggested same!

Share this post


Link to post

Does Graz use SODE and if so which version?

 

Share this post


Link to post

Just FYI, I can confirm for you that on my setup HTKJ, TNCB and UWGG All work perfectly under SODE V1.3.1. You just need to move the related files from the old SODE V1.2 X directory to the new SODE V1.3x directory.

Nick

Share this post


Link to post
vor 21 Stunden , jdxrb sagte:

Does Graz use SODE and if so which version?

 

 

No, it comes without.

Share this post


Link to post

Nick thanks for the advice but for me it isn't working.

In FSX root Simobjects misc I had HTKJ, SODE_TNCB and UWGG folders which I moved to C drive - SODE - Data - Simobjects - where I already have an entry for LOWS - correct?

In FSX root SODE I copied the CFG and XML folders to C drive SODE noting that cfg folder is empty and xml folder has entries for TNCB, HTKJ and UWGG - correct?

 

Right now using 1.31 SODE 1.31 and LOWS works fine but the other 3 don't - no lighting at all at HTKJ, no PAPI control at TNCB and no lighting at UWGG.

 

Is there anything else I have to do please?

James

 

 

 

 

 

Share this post


Link to post

Hi James. Make sure that the entries in the dll.xml and exe.xml for SODE V1.2x are disabled and that SODE V1.3x is enabled. You will have problems if both versions are enabled at the same time.

Nick

Share this post


Link to post

Did I miss the link to updated SODE v1.31?  Are there still compatibility issues with SODE and Virtuali?

 

Cheers, Rob.

Share this post


Link to post

I got the link from the DD site. Not sure if it's up on Jeffries site, I haven't checked. Also not not sue on the Virtuali question.

Nick

Share this post


Link to post

Update...It is available on Jeffries site, just checked.

Nick

Share this post


Link to post

Hey Nick,

 

So this one v1.3.1?  

 

So we can remove SODE v1.2.x but some Jetways make not work in some airports as the only side effect?

 

Didn't see any mention of incompatibility with GSX?

 

Cheers, Rob.

Share this post


Link to post

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