Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by 12bPilot

  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. 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.
  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 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.
  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 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.
  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 troublefree experience I hope. I am also helping the devs to get their sceneries updated in the background. -Jeffrey
  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 some hangar doors.
  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 Executables The priority for how add-on library and executable configuration files differs from content and is initialized as follows: ProgramData: Configuration files named dll.xml or exe.xml found at: %PROGRAMDATA%\Lockheed Martin\Prepar3D v3 Roaming: Configuration files named dll.xml or exe.xml found at: %APPDATA%\Lockheed Martin\Prepar3D v3 If multiple configuration files are found, then the list of paths are merged together when processed according to the above priority. When an add-on library is initialized, the dll is loaded. When an add-on executable is initialized, the executable is started. It is a little trickier now having two locations with those xml's, since it could lead to loading a module twice and hence introduce trouble. Cheers
  14. Having read your post, the answer is no. SODE itself works perfectly on your machine (you see the objects, can trigger stuff through the menu etc). It is the actual SimObject which may be coded in a different way than standard lights. I just checked the behaviour of the lights at ENSH and they are defined by the designer for this part of the year to be off during FS time of day "DAY" and when visibility is above 10KM. With lower visibilities, they should turn on, as well during DAWN,DUSK and NIGHT.
  15. Hi Rob, SODE includes two modules, the main exe and the animation dll. So yes, both are required with their respective entries in the dll.xml and the exe.xml. Version 1.3 comes with the SODEPlatformManager.exe which should handle all these entries editing for you. It also takes care of writing the entries into the correct path in case of P3Dv3 (i.e. ProgramData and not Roaming). Hello, I think you should wait until Drzewiecki Design offsers an update for EPWA with a new installer supporting SODE v1.3. If you manually install the new version, all jetways are lost without moving some old files, which is bit tricky.
  16. That is correct. Only jetways are affected, they won't show up in the menu and are not operative until they are recompiled. Also, the folder structure has changed to comply with P3Dv3 recommendations. Until the new installers are out, you may upgrade to SODE v1.3 and perform the migration manually using the guide here: http://sode.12bpilot.ch/?page_id=9
  • Create New...