12bPilot

Thanks for all the feedback. Here‘s the statement from one of the P3D developers: http://www.prepar3d.com/forum/viewtopic.php?f=6312&t=140126&start=15#p229912 So a fix is being implemented on their side, that‘s great news. Happy that you‘re able to perform flights again using the temporary workaround.

Got news for you: V5.1 added a new feature called „Adaptive Simulation Group“, mainly intended to reduce visual jittering when flying in close formation with other traffic (multiplayer or AI). Due to the way SODE works internally (it basically injects AI objects...), Prepar3D picked them up into that new simulation group and when SODE tried to remove the injected object, the sim crashed. This is going to be fixed within Prepar3D. Until then, there is a workaround (hoping you don‘t do much close formation flying), courtesy of P3Ds dev team: You can disable this new adaptive simulation group system in the Prepar3D.cfg Let me know if this fixes those CTDs.

Thanks. Yesterday, I was able to narrow down the cause for the CTD, it has to do how SimConnect within Prepar3D v5.1 handles a removal of a specific type of object, for example when SODE removes/replaces a jetway. Reported this to LM, waiting for their results.

Hi Alan, I think this has to do with the "manual intervention" into an automatic docking process. I see you have "Aircraft state triggered auto-docking" activated. This setting - intended for home-cockpit users which do not want to use keyboard commands - is not designed to be used together with manual docking. This could potentially lead to "double-triggering" and this can cause crashes in the jetway animation (SimObjectAnimationModule.dll). So if you want to have total control over the jetway-to-door assigment, don't rely on the auto-dock feature (disable it in the SODEPlatformManager -> Tools -> Settings) and assign the jetways manually using SODE's or GSX's menu.

Thanks for the data, they helped me narrow down the conditions and I was able to reproduce the CTD. In my case, SODE's AI detection is OFF, the SODE jetway must have a static variant (gets swapped to a dynamic one when stand is selected...). Using SODE's own text-menu, I select the stand, dock the jetway. Then undock the jetway. Then from the menu, I de-select the stand manually -> CTD. So something when swapping the dynamic jetway back to the static one triggers the CTD (in fact, I am removing the dynamic jetway using SimConnect). And it is exactly this SimConnect object removal call which trigger it. Funny thing is, it only it only crashes when the jetway has moved! When I select the stand and de-select it again without operating the jetway, it doesn't CTD, even though the very same SimConnect removal call is fired...very strange. Worked in all previous P3D versions without any troubles. I need to investigate further to confirm that the removal call is flawed, just thought I give you guys a heads up.

Could you create some "temp" folder in that SODE root folder and copy all the contents of the "cfg" and the "xml" subfolder into it? When the cfg and xml are cleared out, SODE will not have any input files to work with and will run in some sort of "idle-mode". I would be highly interested if the CTD still occur in this idle-mode. Thanks for all your help, guys. Also, to get all the info as I can get, could you turn on "Debug Mode" within SODEPlatformManager.exe -> Tools -> Settings ? This will generate a more detailed SODE.log file. To those who consistently can create CTDs: A SimConnect trace log could be helpful, since it shows all the communications between Prepar3D and the SimConnect add-ons (such as SODE). Maybe I can pinpoint the exact SimConnect call which could trigger the crash. Instructions on how to generate such a trace log: https://sode.12bpilot.ch/?topic=faq, Section D.

Thanks a lot for the various tests and your write-up. I'm trying to CTD with your scenario 2), since that one involves no add-ons except SODE. Did as instructed but couldn't get it to crash unfortunately. Question: Is your SODE xml folder empty (C:\ProgramData\12bPilot\SODE) ? Since those data are shared across simulators, it could be that P3Dv4 objects are still loaded in v5 (from the v4 install), even if the airport is not installed explicitly. I'd be particularly interested if the CTD still happens if the xml folder is empty, and for the same reason the "cfg" subfolder.

Thanks for your tests. What if you went to some „non-SODE jetway“ airport and leave the detection setting on and AI traffic on? This test will reveal if the AI collection within SODE triggers the crash or the activation of the SODE jetways.

Hi, it's the SODE developer. I'll have again a deeper look at it next week, I haven't been able to reproduce the crash so far. Just to rule out some error in the basic SODE logic: Could you just turn off the AI TRAFFIC detection part of SODE via its settings (SODEPlatformManager.exe -> Tools -> Settings)? Still getting the crash? Thanks for your help. -Jeffrey

I think the thread title is a bit misleading here: Of course SODE only is able to reduce stutters that were induced by SODE itself -> injection of non-existing models into the sim. This has been fixed. General stutters such as when panning around the view are not related to SODE (and I can't imagine why it could have an influence on this, it runs pretty much idle when you do not interact with SODE). Just by reading here and at P3D's forums, lots of people experience more stutters with the introduction of P3D 4.2 when turning, panning around. So I think it is more of a general sim issue.

Hehe, thanks for the offer Pete. I'm a real life airline pilot flying A330s and A340s out of Switzerland, so I have plenty of those ;-)

Hi Pete, Not necessary, unless you have a very ancient version (pre V1.3.1) currently installed, where this wasn't supported.

Hi all, Let me shed some light on this topic here. First of all, only jetways are affected. The jetways will be displayed, but you won't be able to trigger them. Other SODE controlled objects work as before. Also, it doesn't matter if the placements are defined in a SDX or XML file. The problem here is that DD implemented the jetway placements incorrectly. Since the introduction of SODE jetways, developers are required to "hook up" the SODE jetway to the underlying AFCAD/ADE parking position. As you may know, those parking positions are strictly defined in the FS SDK, such as GATE_A, PARKING, etc. Not trying to blame DD here, but instead of using those official designators, they somehow introduced own designators like "GATE C123-130" and such. Also, the parking number is a pure integer number as per FS SDK, while they sometimes used "12A" or similar. While the old SODE would not check the gate name/parking number for "SDK correctness", this new SODE does, because it must rely on them from now on. Also, GSX for instance expects correct gate name/parking position combinations. Otherwise it won't be able to select/find the jetway. So it is of interest to have properly set up parking data in the SDX/XML file. Most sceneries using SODE jetways out there have correct parking data linked to them, so there is no issue at all. The SODE.log will indicate when a jetway has incorrect parking data. It's not a break in "compatibility", I'm just enforcing the FS/P3D SDK standards now. The fix here is to provide parking data as per FS SDK. Best regards, Jeffrey - SODE developer

Without that file, you won't see any jetways and SODE will not know about the existance of those. Uninstall or re-install of SODE does not modify anything in this folder, so I can't explain why the file disappeared. I'd recommend to re-install the entire KMSP scenery. I think it's the new Flightbeam Manager that puts that xml file into that folder when you select the "SODE jetways" option.

Is there a 'Flightbeam_KMSP.xml' file in C:\ProgramData\12bPilot\SODE\xml?