Rob Ainscough Posted April 26, 2014 Share Posted April 26, 2014 If this has already been asked, my apologies ... but do I really need a separate line entry in my DLL.XML for each Orbx airport? Are the DLL's really specific to just that single airport? Over time and many installed airports, my DLL.XML could get large. What I currently do is just set Disable = true for each airport that I know I'm not going to be using in my flight ... is this standard approach being used? Cheers, Rob. Link to comment Share on other sites More sharing options...
bdrichmond Posted April 27, 2014 Share Posted April 27, 2014 Greetings Rob, I couldn't find the thread quickly for the definitive answer on this one. But as I understood the Orbx Gurus: 1) Yes there is a .dll for each airport, but 2) they aren't loaded/activated until you get within a certain distance, so they don't muck with memory usage if they aren't in your AO. Mind you this is the info I think they were telling us... Respectfully, Brian Link to comment Share on other sites More sharing options...
Rob Ainscough Posted April 27, 2014 Author Share Posted April 27, 2014 Thanks for the response Brian ... if you find that thread let me know, I searched and couldn't find anything. Cheers, Rob. Link to comment Share on other sites More sharing options...
B77X Posted April 27, 2014 Share Posted April 27, 2014 PIggy backing on this topic, I accidentally removed them from the dll.xml file, is there a script that will add them back for me? Link to comment Share on other sites More sharing options...
Rob Ainscough Posted April 27, 2014 Author Share Posted April 27, 2014 Replace the ICAO code for each airport you have and add this text to your DLL.XML: <Launch.Addon> <Name>ObjectFlow_11S_P3D</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>V:\Lockheed Martin\Prepar3D v2\ORBX\FTX_NA\FTX_AA_11S\scenery\ObjectFlow_11S_P3D.dll</Path> </Launch.Addon> Repeat this entry for each airport replacing the ICAO (in above case your replace 11S with your ICAO and replacing the drive and path to match your install location. Alternatively you can uninstall and re-install the airport. Cheers, Rob. Link to comment Share on other sites More sharing options...
bdrichmond Posted May 3, 2014 Share Posted May 3, 2014 Greetings Rob, I finally found that thread: Performance Gain (De)activating DLL.xml Entries? Started by TheMan_RJ, Mar 23 2014 08:55 AM One of the developers, Alex Goff, gives a decent explanation of what is going on. Respectfully, Brian Link to comment Share on other sites More sharing options...
Rob Ainscough Posted May 4, 2014 Author Share Posted May 4, 2014 Greetings Rob, I finally found that thread: Performance Gain (De)activating DLL.xml Entries? Started by TheMan_RJ, Mar 23 2014 08:55 AM One of the developers, Alex Goff, gives a decent explanation of what is going on. Respectfully, Brian Hi Brian, Do you have a link? I did a search and with you topic and came up empty (even google search also). Cheers, Rob. Link to comment Share on other sites More sharing options...
Alex Goff Posted May 4, 2014 Share Posted May 4, 2014 Hi Rob, here's my post that Brian is referencing: http://www.orbxsystems.com/forum/topic/76189-performance-gain-deactivating-dllxml-entries/?p=697294 The reason for separate DLL's goes back to when ObjectFlow was first released. In the original releases there was no auto-update feature that we have now. The way this impact airports was that if they all used a shared module, then a user could potentially install a newly released airport, then later an older airport with an older version of the module causing the newer airport to break. Since you're a fellow software developer I'm sure you could imagine the more obvious solution being that instead of including the module with airports to instead roll it into the libraries so that as long as the user has the latest libraries, the module is kept up to date. But back at that time the libraries didn't contain nearly the number of core programs it does now, it was really just scenery libraries at that point. So that's how it ended up with the module distributed in each airport. It could conceivably all be done through a single module, especially since we have the auto-update feature. But that would require a repackaging of every airport with new installers... But for now each individual module has a small memory footprint and the scenery objects loaded have a similar footprint to their BGL counterparts. Link to comment Share on other sites More sharing options...
bdrichmond Posted May 5, 2014 Share Posted May 5, 2014 Thanks Alex! Respectfully, Brian Link to comment Share on other sites More sharing options...
Rob Ainscough Posted May 5, 2014 Author Share Posted May 5, 2014 Thank you Alex ... answered exactly what I needed to know ... agree, over time designs/implementation changes and retaining compatibility with older products is always a challenge ... but armed with your information, I can optimize my flights a little more. Many thanks, Rob. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.