SODE

[fakeflyer737 991]

So I'm using the latest SODE with NYX v2 KEWR. The menu shows up but it says there are no stands. 

I don't know what to do. 

[fakeflyer737 991]

The Jetways apprear but I cant move them....

[downscc 1,327]

The DRW manuals indicate that Ctrl+D activate his implementation of SODE.  He likes to customize things in that way.

[fakeflyer737 991]

Now I'm getting a message that says the aircraft I'm using doesn't have defined Exits (NGX). 

[Jim Young 2,356]

1 hour ago, downscc said:

The DRW manuals indicate that Ctrl+D activate his implementation of SODE

Should be Shift D. 

When you get the message that says the aircraft does not have defined exits (mine says all available aircraft doors already served!) it still works.  IMHO, SODE is a horrible program!  I'm docked perfectly and the jetway smashes into the aircraft or it is so FPS friendly, it doesn't show at certain angles inside the VC.  I suspect I have to play with it more.  Haven't really had much time to play with gadgets like this one.  Wonder if I remove SODE for NY Airports if it will give me back the default jetways.  Reading the Drzewiecki Forums right now and will try to work in reading the SODE manual.

[fakeflyer737 991]

I have found also that it seems to be a terrible program. Sometimes it works, sometimes it doesn't. 

[Jim Young 2,356]

Reading the SODE manual it says you cannot use the Tab S or Shift D to enable SODE as follows: 

"Users of PMDG aircraft may experience that 'Tab+S' does not bring up the text-menu. This is because those aircraft have already mapped the 'Tab' key for their FMS keyboard input." They offer a guide on how to come up with keys for PMDG.  Just one more complication one has to deal with when using a flight simulation program.

Best regards,

Jim

[duckbilled 310]

13 hours ago, Jim Young said:

Should be Shift D. 

IMHO, SODE is a horrible program!  I'm docked perfectly and the jetway smashes into the aircraft or it is so FPS friendly, it doesn't show at certain angles inside the VC.  I suspect I have to play with it more.  Haven't really had much time to play with gadgets like this one.  Wonder if I remove SODE for NY Airports if it will give me back the default jetways.  Reading the Drzewiecki Forums right now and will try to work in reading the SODE manual.

Not to open a can of worms, but

I am really missing AES in P3D. I have GSX, and have had it since it was released. In FSX, I only used AES, because I only need the jetway and pushback. GSX gets you part of the way there, but it is threads like this where it becomes obvious why AES wasn't free. It worked as advertised with almost no issues. No clunky jetways, You even had double and triple jetways working at some airports.

[downscc 1,327]

I found that Shift+D (I guess Ctrl+D was a memory error... ) works but for example at KJFK I must slew the aircraft about 5-10 ft away from the jetway for it to work.  In fact, all the problems I've had with sode are always resolved by slewing the aircraft in and around the parking spot to find where the jetway works.  Most developers provide the sode configuration data in a format that is editable but this developer encapsulates the information in a secure format so it cannot be fixed by the user.

[Jim Young 2,356]

1 hour ago, downscc said:

Most developers provide the sode configuration data in a format that is editable but this developer encapsulates the information in a secure format so it cannot be fixed by the user.

Now sure how he's doing this but I do know that the folders are located in the SODE/SimObjects folder just like all other scenery that uses SODE.

I'm in the process of trying to uninstall SODE but it is difficult in P3Dv4 it is impossible to deactivate or unregister the program (or at least that happened to me).  So I'm going to have to go in and manually find the folders and delete them.  Some are SimObjects associated with FSDT and other programs and I think SODE balks at completely unregistering or deactivating as there are many users of SODE.  I will 'git er dun' though...  I just want to learn GSX as FlightBeam/FSDT airports are the places I mainly use.  If I cannot use the default jetways for Drzewiecki airports, then so be it.

Jim

[downscc 1,327]

Yeah, he uses sdx formatted files instead of xml.  12bPilot provides a module to convert xml to sdx to developers that want to do that.  That's fine as long as the product works but when not then it is a questionable practices in my opinion.

[mikeymike 357]

How is performance with sode?

Can I disable it from AI traffic using it pulling into gate?which may affect performance?

Thanks 

Mike

[Jim Young 2,356]

On 8/22/2017 at 0:29 PM, Jim Young said:

I will 'git er dun' though...  I just want to learn GSX as FlightBeam/FSDT airports are the places I mainly use.  If I cannot use the default jetways for Drzewiecki airports, then so be it.

I cannot "git er dun'.  No problem in FSX but P3D I could not.  Think it is impossible to unregister because it is a component of FSDT/FlightBeam so I'm not going to mess with it. 

1 hour ago, mikeymike said:

How is performance with sode?

Can I disable it from AI traffic using it pulling into gate?which may affect performance?

Thanks 

Mike

I do not see any issues with performance but the jetways look horrible.

[downscc 1,327]

There are beautiful examples of what can be done with SODE by Flightbeam at KMSP and KSFO as well as not too bad at all with FSDT KIAH or KLAS and even Imaginesim does well with KATL (using jetways developed by 12bPilot).  As far as Drzewiecki goes, he is off my machine.  I'd much rather have the better looking even if very old FSDT KJFK.

[virtuali 4,419]

SODE, as a program, works very well.

Yes, there were some growing up issues when the Jetway SDK was significantly updated and overall the program had quite a bit of changes, I believe this happened around about the transition between 1.2 and 1.3. There were some scenery developers that used the 1.2 and earlier versions, and when 1.3 came out, it required an update of the sceneries made with it, since it wasn't entirely backward compatible. Same for jetways: sceneries using the earlier jetway SDK required a recompile of the old jetways, because the animation system changed quite a bit.

We were never hit by these issues, because we never used it for general objects creation (we have our own engine for that), and we never made any Jetways with it until the Jetway SDK was mature enough, and I must say most of the changes were made to improve compatibility with GSX that, in addition to make it easier to use, allows SODE to get data from the airplane exits directly from GSX, which means you'll only have one place to configure your airplane, in the GSX editor, assuming it doesn't already come with a GSX customization either internally or by the airplane developer.

For all of this, remember, Jeffrey doesn't charge a dime, either to the users of the scenery or to developers, so it's not an hidden cost passed to you by means of a license fee.

We also don't mind that, thanks to our feedback, the program improved also for other scenery developers, we are just trying to cooperate to make everybody's life easier. Because, for a developer, making SODE jetways it's way easier, better and more flexible than it was to make default jetways, with all their baggage of bugs.

Now, while SODE jetways are more realistic, sometimes it might be frustrating to use them, because they doesn't seem to work on a certain combination of airplane+parking position+parking size.

But that's NOT a "bug", it's just that SODE correctly refuse to work if the jetway inverse kinematics cannot mathematically solved. With the default system, you had the illusion that jetways "worked" more often, but they might break apart, go underground, etc. That's just because the default jetways system is more lax and allows to move jetways that shouldn't move in the first place, because it would have been impossible to reach the plane door in real life from that position.

There are so many variables, and several things that might go wrong, and should be checked, just like in real world. The more we get close to reality, the more precise we must be, and take into account more data:

- The airplane configuration. Is the airplane configuration correct ? I know it might be confusing but, with the default jetways, the doors are taken from the [Exit] section of the aircraft.cfg, with a 3rd party scenery that use just SODE, they are taken from the internal SODE database of airplanes but if you have GSX installed AND you call SODE from the GSX menu, the data for the exits are taken from GSX.

- The scenery. How big is the parking ? Does it have the proper jetway for its size ? A parking might be visually large enough for a big plane, but it might not have a proper jetway model for the airplanes that are suitable for that spot. Or, you can tweak the AFCAD (or GSX), to force airplane types different than the ones that were supposed to park there, but the combination of jetway model+jetway placement would still be the same, and might not be correct.

- Your parking position. In real life, different planes park at different distances on the same parking, mostly to have their main exit in a *predictable* position (one that doesn't change much), so the jetway that will be installed there can be reasonably sure that, regardless of the plane type, it won't have to move a lot to reach the door. Unfortunately, the sim itself is not helping much, so we had to add a lot of things in GSX and in our software to improve this, like the ability to set the parking position independently from the center of the parking in the GSX scenery customization editor, but we are still improving on this, and several changes will appear in the next GSX update, because reliable parking is one of the most important things to us.

- The Jetway models. Real life jetways have physical constraints, and SODE allows to model them but, of course, the scenery developer is required to follow them as close as possible, taking ALL the previous issues into consideration. The issue is, it's quite a bit of pain to create different jetway models for each parking, but that's how it's done in real life, because jetways comes in many different sizes and it's possible that every parking might have a slightly different model. Unless the scenery has very few jetways, I don't think any scenery developer ever made a different model for each parking, surely not for the 150+ monster sceneries out there. We put ourselves in the list of guilt: most of the time, we model 2-3 different jetways at most, and try our best to fit them across the whole airport. The reason for this is that, historically, it was A LOT of work making a new custom model using the default animation system. SODE is much better, but if a scenery was initially designed to use the default animation system, it's still a lot of work to convert everything to SODE and do it in the proper way, unless you just replace the default models with the new ones.
To put things in perspective: it takes more than 1 year to do an high end scenery, sometimes it's not even enough, and this time can only increase in the next years, because users ask for more and more realism, and this requires work. That's why there are airplanes which has been in development for 5, 7 years and even more. So, what you are looking at today, are mostly sceneries that were initially designed when SODE was way less capable than it is now, especially in the jetways department. This will hopefully change in the future, when developers will start working with SODE right from the beginning of the project, and this means looking at each and every parking on the airport, and decide what jetway to have there and have it modeled it independently, as it is in real life.