Recently we have seen a lot of codes used to unlock our products being offered for discounted prices. Almost all of them are bought using stolen credit cards. These codes will all be blocked by our systems and you will have to try to get your money back from the seller, we are unable to assist in these matters. Do be very careful when you see a deal that is almost too good to be true, it probably is too good to be true.

Jump to content

12bPilot

Developer
  • Content Count

    72
  • Joined

  • Last visited

  • Days Won

    1

12bPilot last won the day on December 7 2015

12bPilot had the most liked content!

Community Reputation

43 Excellent

2 Followers

About 12bPilot

  • Rank
    SODE Developer

Recent Profile Visitors

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

  1. 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.
  2. 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...
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. The installation of SODE up to V1.2.2 including entries in the xml files was in the hands of the individual add-on makers. They were responsible to check for old installs etc, I have written guidelines about it. But obviously they were not always followed and old SODE versions got installed over newer ones, entries written into the xml without checks for any existing entries etc. So looking back, this distribution scheme has proven to be wrong. (Remember, SODE is a free product and I can't devote all my freetime to check each developer's installer). That's why I have decided to make my own V1.3 installer that should be used by the add-on makers from now on (bundled into their own installers). The new installer checks for old/new installations as you suggested and all of the xml handling is done by a separate easy to use utility. I will release each update using an own, incremental installer. I do hope that with this new distribution scheme, the old problems will not appear anymore. I know this transition time now is a bit frustrating, it surely is for me. I only can ask for a little more patience until the airports are upgraded to V1.3. Thanks for your input.
  10. I have always said that it is not recommended to run two SODE modules in parallel! While it may work just for display of objects, triggering jetways will certainly crash because there are two jetway engines running simultaneously writing/reading into the same memory area. DJ, SODE has always been backwards compatible from V1.0 to V1.2.2. Due to a design/concept error in the jetway engine (the pause issue), I had to rethink the way how the engine should handle jetways and introduced the solution in V1.3. This stuff happens when you try to push the boundaries of the SimConnect API and what is possible with it. Ideally, this issue should have been caught during beta testing of the add-ons implementing SODE, but they have been released and I had no reports of that issue at that time. Also, at the same time, LM released P3D v3 which reorganized the way of how to install add-ons. V1.3 is by a large extend backwards compatible, it's just the jetways that won't work (but they are displayed) and you need to move around some files and folders to get old sceneries working if you don't want to wait for the official updates of the developers. I am even helping a couple of devs (EPWA, UUEE, EETN) out by creating the jetways for them to get the updates quicker to all of you. LIRF is already made V1.3 compatible according to their facebook page and they are beta testing the update.
  11. Hi, Some sceneries use relative texture paths for their SimObjects, e.g. EPWA. Check the texture.cfg in the DrzewieckiDesign_EPWA\texture folder. I have edited mine so that it points to the main texture folder of the scenery: [fltsim] fallback.1=D:\Lockheed Martin\Prepar3D v2\Addon Scenery\EPWA Warsaw Chopin Airport X\Texture
  12. No problem, you're welcome. Flight Training? hehe, flying for an Airline for 4+ years now, but thanks :-) cheers
  13. Worst case scenario when installing SODE v1.3 for old airports: Missing objects and/or inoperative jetways. You can however restore all missing objects by moving old folders and files to a new location. Only the jetways remain inoperative since they need to be recompiled. E.g. I have a working EPWA under v1.3, just the jetways are not moving yet. I have written a migration explaining all this: sode.12bpilot.ch, downloads section. I'd love to write a little tutorial here, but I want to enjoy my holidays here...
×
×
  • Create New...