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

1 Follower

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)
  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. 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 genera
  5. 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.
  6. 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 m
  7. 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
  8. 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
  9. No problem, you're welcome. Flight Training? hehe, flying for an Airline for 4+ years now, but thanks :-) cheers
  10. 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...
  11. Bill, That's the correct path that my installer is suggesting. To let the addon devs install SODE was a mistake as you can see, with addons installing old versions and such. That's why I am providing my own installer to keep things clean for the future. That's also the reason why SODE is installed outside the root folder. That is also to be compliant with P3Dv3 at the same time. SODE needs to run in all sim platforms! This Transition phase to v1.3 is a little unsatisfactory, I know. But once all major airports are upgraded, it'll be a troublefre
  12. That stuttering comes from the Jetway Control System. So if you are near an airport that uses SODE jetways, it will occur once the jetways are loaded. On airports that use SODE for other things but not for jetways, there is no problem. Again, this is for SODE 1.2.2! V1.3 has those issues ironed out. Disabling SODE does not break anything in terms of introducing crashes or such. Depending on how the developer used the module, some objects might not appear. So missing objects are the consequence. For EPWA for instance, these would be the jetways, some vegetation and
  13. Hi Both locations will be read by Prepar3D v3, so both locations are valid. P3D merges the different exe.xml and dll.xml files together. However, LM recommends to use ProgramData (higher priority and Prepar3D default path) over the Roaming folder. When using Prepar3D's own add-on installation mechanism, it will write into the ProgramData folder per default. So that's why I assume this is "the more correct" folder. For reference, this is the source for that piece of info (straight from the SDK, applicable to dll and exe Add-Ons); Libraries and E
×
×
  • Create New...