GaryGB

Hi again: At the same time that NewScenery.Cfg is copied and created (to then contain any "pending" changes to the FS scenery library), OldScenery.Cfg is also copied and created from that original Scenery.Cfg. FS writes to / reads from the NewScenery.Cfg file any "pending" changes to the FS scenery library ...until it exits and is re-started. When FS is (fully and successfully) re-started, the NewScenery.Cfg over-writes the Scenery.Cfg, and the OldScenery.Cfg and NewSceneryt.Cfg should be deleted, as after this point, there are no further changes to the FS scenery library "pending" unless one makes changes to the scenery library again via ex: the FS menu GUI. When another program (ex: a scenery.Cfg maintenance utility such as "SCE") works with the FS Scenery.Cfg in between FS task sessions (when FS is not running), it is important that it work with the above same set of files and the same sequence of events that FS itself would have. Thus the recommendation of the SCE utility author cited above: http://fs-sceditor.sourceforge.net/setup.html "The “Follow the NewScenery convention” option should almost always be set. In this convention when you open the default scenery file, it will be saved as NewScenery.cfg. This helps Flight Simulator notice there is a change in scenery.cfg. You want this to happen. Just be aware that when you open the default scenery.cfg when you save it will be saved as NewScenery.cfg not scenery.cfg." Hope this helps ! :smile: GaryGB

After FS has been re-started, the 'NewScenery.cfg' file will over-write the existing Scenery.cfg file, FS reads the updated Scenery.cfg file, then the 'NewScenery.cfg' file is deleted (until any new 'pending' changes to the scenery library are made during a FS task session). :wink: GaryGB

FYI: The "NewScenery.cfg" file is an intermediate version of the Scenery.Cfg file which cues pending changes made to the Scenery Library GUI in FS (ex: during a flight) which will later be applied to the actual working copy of the Scenery.Cfg file after FS is next re-started. The "NewScenery.cfg" file is created by- and an intended part of- how the FS program itself works (it is created on the fly via code inside a FS executable created by ACES / MS Games Studio). As stated under "Technical Notes" on the "Initial Setup" documentation page for the above cited "SceneryConfigEditor" (aka "SCE"): http://fs-sceditor.sourceforge.net/setup.html The “Follow the NewScenery convention” option should almost always be set. In this convention when you open the default scenery file, it will be saved as NewScenery.cfg. This helps Flight Simulator notice there is a change in scenery.cfg. You want this to happen. Just be aware that when you open the default scenery.cfg when you save it will be saved as NewScenery.cfg not scenery.cfg." Hope this helps ! :smile: GaryGB

Many thanks to Bill and Jim for sharing these helpful "worked examples" ! :smile: GaryGB

While I do believe it would be a good idea for MSFS / P3D add-on developers to include their own "Do's and Don'ts" document within their product manuals, I am further compelled by what I have read thus far in this thread to now: "...address issues involving the very real, and IIUC, in most cases 'purposeful' logistical and methodological complexities involved with how (ex OrbX FTX products are distributed / configured / updated on an end users system". I believe that the best course of action for the OP and others similarly concerned about installing / maintaining / updating MSFS / P3D add-on products such as OrbX FTX, is simply to use a hard drive / SSD which is sufficiently large enough to accommodate the existing MSFS / P3D folder chain, and to allow for future expansion of installed add-on content etc.. Backups of any files which are not intended to be subject to changes by configuration / update procedures of any MSFS / P3D add-on products such as OrbX FTX, certainly may be kept on separate physical or logical storage drives formatted with the NTFS file system. In theory, 'certain' files and/or folders kept on such separate physical or logical storage drives formatted with the NTFS file system may be "linked" to nested ex: "OrbX" sub-folder locations in one's ex: MSFS / P3D folder chain. However, I would caution against using "link" technology for any files / folders which are- or which in the future "may be"- subject to changes ...by configuration / update procedures of any such MSFS / P3D add-on products such as OrbX FTX. When files and/or folders kept on separate physical or logical storage drives formatted with the NTFS file system are "linked" to folder locations in one's ex: MSFS / P3D folder chain, without 'proper' Windows NTFS security permissions, those 'remote' files may- or may not- be accessible ...to allow intended configuration / update procedures of any such MSFS / P3D add-on products such as OrbX FTX. And when proper Windows NTFS security permissions are in place, while those "linked" 'remote' files may then be accessible to allow intended configuration / update procedures of any such MSFS / P3D add-on products such as OrbX FTX, they may also be vulnerable to mishaps of un-intended file management ...as recently discussed in this thread: http://www.fsdeveloper.com/forum/threads/windows-10.434667/page-2#post-717285 http://www.fsdeveloper.com/forum/threads/windows-10.434667/page-2#post-717302 For those who feel they 'must' utilize linked files / folders (hopefully on either a very carefully considered and/or IMHO, "temporary" basis ex: while saving up for a larger storage drive), use of "Symbolic Link Clones " via the excellent Link Shell Extension (aka "LSE") utility by Hermann Schinagl, rather than more commonly used link technology, might be a 'comparatively safer' option to consider ...as also discussed in the above thread. http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html However, even this latter 'comparatively safer' method would subsequently involve additional very carefully considered manual maintenance by the end user, to copy and/or move files from the ex: OrbX nested sub-folder chain following intended configuration / update procedures of any such MSFS / P3D add-on products such as OrbX FTX. IMHO, this latter scenario would be a process fraught with risk of error, and would likely be a time-consuming and redundant task. Thus, I would again advise 'most' end users to not attempt using "link" technology for any files / folders which are- or which in the future "may be"- subject to changes ...by configuration / update procedures of any such MSFS / P3D add-on products such as OrbX FTX. Another concern which I am compelled to address is the (well-intended) use of a utility such as "DupeGuru - Picture Edition" with MSFS / P3D to analyze / identify "duplicate" image files among the multiple legacy, current (and future ?) FS image file formats, which in many cases are either completely- or semi- proprietary, and may have unique internal attributes and data structures. I would advise against attempting to use such a utility with MSFS / P3D image file formats, as it may not be able to properly identify the numerous 'unique attributes and data structures' required / utilized in MSFS / P3D image files. Even if one used a utility which was 'fully-compatible' with all the multiple legacy, current (and future ?) image file formats of MSFS / P3D (ex: some utilities by Martin Wright) to identify "true duplicates", all those image files are located in specific locations under specific file names, for reasons of implementing scenery display according to the developers' intended method of file utilization, to allow proper rendering at run time in MSFS / P3D. Thus, one would risk disrupting operation of the MSFS / P3D rendering engine by changing / moving / deleting certain files. :wink: For the same reasons, IMHO, one should not attempt to combine "all your scenery files into one scenery folder and all your texture files into another texture folder" as suggested earlier in this thread: :excl: http://www.avsim.com/topic/472281-tens-of-gb-of-orbx-texture-duplicates-found-across-product-line/#entry3277419. Again, AFAIK, the configuration / update procedures of any such MSFS / P3D add-on products such as OrbX FTX may not be able to perform their intended functions, and one would risk disrupting operation of the MSFS / P3D rendering engine by changing / moving / deleting certain files. I hope this info may prove helpful to all the boys (and girls) who are "fans" of MSFS / P3D add-on products such as OrbX FTX. :smile: GaryGB

* Accept the fact that people now have (and IMHO, should always have) the right to ask questions on- and discuss- issues related to OrbX products in the AVSIM "Unofficial FTX | ORBX Support Forum" (or anywhere else on the 'inter-web') ...in addition to- or instead of- any "Official FTX | ORBX Support Forum". * Recognize that the manner in which authorized Orbx representatives and/or "FTX fan-boys" reply to threads in the AVSIM "Unofficial FTX | ORBX Support Forum" (or anywhere else on the 'inter-web' including any "Official FTX | ORBX Support Forum") ...may have a greater impact on potential future OrbX FTX product sales, than any questions raised / opinions expressed / aspersions cast / rumors spread etc. ...in posts by existing or prospective end users of such products. My reply in this thread is (thus far) not intended to address issues involving the very real, and IIUC, in most cases "purposeful" logistical and methodological complexities involved with how OrbX FTX products are distributed / configured / updated on an end users system, and only has to do with the ongoing issues cited above. :wink: GaryGB

I think the OP has expressed a valid concern and opened a discussion on a number of valid issues. IMHO, AVSIM should use some reverse psychology, and bestow a "SNAVE Award" to the person(s) who consistently post the most reprehensible content in these forums. Perhaps a "SNAVE alert" button can be provided under every post to allow easier voting by forum members ? :rolleyes: GaryGB

Hi Maarten: In your post above, when you refer to "FSG", are you referring to "FSGenesis" terrain mesh add-ons (for which there are many ongoing users from the past that are accustomed to seeing the familiar abbreviation "FSG" used in association with that product line) ? Or are you instead referring to the FS Global product line from pilots.de with your 'own' abbreviation of "FSG" ? Thanks in advance for your clarification on use of the "FSG" abbreviation above. :smile: PS: Would you post a link here to the forum thread describing how to "mix" both the FreeMesh X and the "FSG" mesh ? Thanks again ! GaryGB

Keeping backups is important, and having a tool to make backups manually or even automatically is a good thing. :smile: To repair an already corrupted DLL.XML file, Flight1 freeware page also offers: FSX DLL.XML Viewer and Repair Utility http://www.flight1.com/files/FSXML.zip

Interesting overclocking results with such a small over-volting increment ! I'd previously read a general rule that for every 10 degrees Celsius of over clocked and/or under-cooled operation of a chip over the manufacturers specified temperature range, the life of a processor chip is cut in half. It would be interesting for future reference to know what your method was for de-lidding a processor (sure beats partitioning off the processor socket area and buying tanks of liquid Nitrogen to super-cool chips when over-clocking to run P3d at maximum settings) ! GaryGB

Hi Clutch: IIRC, in FSX the hard-coded AGN display distance limit was reported by Bill Womack (based on a personal disclosure by ACES ?) ...as "approximately" 14 Kilometers (14 Km = 7.559376 Nautical Miles). I would assume the exact math on this to be based on the QMID / LOD Grid Quad sizes and their associated sizes in Meters (on the ground and/or in-flight Altitude) in various locations within the FS 3D spheroid world model. I am not certain yet, what the hard-coded AGN display distance limits may be in P3D, nor what "units" are for the mysterious new P3D.Cfg AGN parameters cited above, ex: "AUTOGEN_TREE_MAX_DRAW_DISTANCE=12000.000000 AUTOGEN_TREE_MIN_DISTANCE_TO_LOD=2500.000000" Perhaps this forum thread post might give a few clues ? http://www.prepar3d.com/forum-5/topic/autogen-re-architecture-confusion-ref-03-24-14-prepar3d-v2-2-developer-blog/ NOTE: That thread references this Prepar3D v2.2 Developer Blog post on 03-24-14 by Wesley Bard: http://www.prepar3d.com/news/2014/03/4904/ Hope this helps ! :smile: GaryGB

Hi Martin: It would be interesting to see what your VB scripts might do to help other FS9 users, if you would be so kind as to make them available. :wink: Would you please post some commonly seen examples which others may wish to remedy via the creation of Dummy folder / file paths, and Windows registry entries ...for FS9 ? Thanks ! :smile: GaryGB

It was my impression based on your description in the post at the top that you might only require a video recorder. Hope you find an alternative to FSRecorder that can also record FS internal data. :smile: GaryGB

Would I be correct that the OP is referring to this thread in which Nick Needham (aka Nick_N) posts regarding Prepar3d (aka P3d) ? :wink: http://www.simforums.com/forums/thanks-nick-for-your-bible_topic52380.html

The author of FSRecorder on his website suggested "Game Cam" as a possible alternative: http://v2.planetgamecam.com/