Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won



About 12bPilot

  • Rank
    SODE Developer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sorry, unable to install that FSInn1.3 into my Win10 setup here...some ocx file needs a dplayx.dll from DirectX 6.1 (!).
  2. What's the name of that VATSIM software? Maybe I can download it and try it here...
  3. Hey @Christoffer, try to re-download the full GSX installer from FSDT. I also had troubles getting the SODE jetways to dock via GSX, re-downloading the full installer fixed it for me.
  4. For the guys who don't have an entry for SODE in the Add-Ons menu in the sim: Could you please give this updated SODE version a try -> http://sode.12bpilot.ch/?wpdmpro=sode-v1-5-2 It contains a fixed SODEPlatformManager.exe Thanks and sorry for the hassles...
  5. Which v3 version are you running? 3.4? 3.3? 3.2?
  6. Nothing to worry about... I was optimizing the code and those errors got mistakenly introduced in V1.4.2. Technical background info: I was removing key-press handlers when no customized menu is needed, but forgot to remove the corresponding SimConnect API call. That's why SimConnect is moaning about non-existing handlers...Doesn't change the behaviour of SODE nor does it crash something. Fixed in V1.4.3 by the way... Also, I have degraded the VDGS message in the log from WARN to INFO in V1.4.3. Sorry for the confusion.
  7. Hi James, While questions 1) and 3) are for the respective scenery developers, I can answer 2)... There should be no other data probe object. As you figured out, the basic SODE data probe should be used for every airport. It has always been like that since the very first SODE release. I don't know why ENAT comes with an own one It is not necessary to supply a separate data probe, unless the author had a good reason for it and is aware that he must use a different SimTitle for it (no duplicate titles allowed, could crash the sim!) Some words on 1) It is *not* wrong for the developers to put their SimObjects into the Misc subfolder instead of the C:\ProgramData\12bPilot\SODE location. It's their decision. As long as they are not placed at both locations (did I mention that duplicates are bad), all is good. Moving files by your own is possible, but only if you know the consequences like updating eventually the texture.cfg paths, uninstaller maybe looking at the original path, etc... All this is clearly outlined in the SODE guide for developers. I can only hope they follow those guidelines...
  8. Difficult to tell from here, initially, the error was because the PlatformManager could not find the exe.xml. Best approach would be a TeamViewer session, I am available this evening from 20:00 Central European Time. Please PM me if you want to have a session.
  9. Not necessarily, just if you want the hood to (more or less) nicely connect to the fuselage. The file is AircraftParameters.ini located at C:\ProgramData\12bPilot\SODE. There are two entries for [CONCORDE] and [CONC] with identical data.
  10. As the SODE developer (-> tech provider) I have to rely on the scenery developers who use the SODE technology to properly implement the features according to my own SDK. Most of the issues reported here originate from faulty scenery installers (files in wrong places) or faulty xml or cfg data, in other words, the basic file setup is messed up. You can imagine that I do not have control over all those sceneries, installers, etc and this was my intention from the beginning, to delegate the responsibility of providing proper setup to the scenery developer. This works pretty good in general. I also do not own all those sceneries using SODE...I just provide the base engine...so I can't test Addon XYZ for correctness, I have to use TeamViewer to assess the situation on the user machine. So if you got SODE perfectly working at some airport and not at an other, then there must be something wrong in the setup of that other airport, and that is something the scenery developer has to sort out. However, as shown, I am able to help through TeamViewer and if I wasn't in New York right now, I'd glady help you out another time :-) I'll PM you when I'm back on Tuesday. But I hope the other guys are able to provide a solution until then, because it seems MYNN and SODE play together ok generally.
  11. Just checked here on my system on yes, you need to flag the parking stands with a jetway in GSX separately for the GSX-SODE integration to work.
  12. SODE and Malaga issue solved together with Ray. It was a naming issue in the config file for LEMG. After the correction, GSX is able to send the correct gate name to SODE and the jetway can be moved through the GSX window. Simwings needs to correct the config file.
  13. Solved during a TeamViewer session with Ray. The configuration xml file for LEMG was faulty by designating the stands as "PARKING" instead of "GATE", which is the category used in the actual AFCAD. Also, for GSX to work, we needed to customize the parking position using GSX and tick the "Parking has a jetway" checkbox. Ray, could you attach the corrected LEMG xml file here in the forum? It is located at C:\ProgramData\12bPilot\SODE\xml. Many thanks.
  • Create New...