robmw

I avoided updating until this afternoon having purchased AccuSeason from Orbx but it seems to be working ok at the moment using the RexAxis registration method with the old AccuSeason license key and purchase email. Maybe tomorrow it won't be!

Just found this thread while installing CumulusX to use with Aerosoft sailplanes in P3D v4.5. Although it's a while ago I thought I'd add some info as I've done exactly what glider1 asked. I created a 'Soaring' folder in the P3D Add-ons folder in My Documents (obviously it can be called whatever is desired). The CumulusX (and its cloud objects) can then be copied as below from their dummy install locations as explained in glider1's post: CumulusX SimObjects\Misc\CumulusXCloud Then create an 'add-on.xml' (note hyphen in name) containing the following: <?xml version="1.0" encoding="utf-8"?> <SimBase.Document Type="AddOnXml" version="4,0" id="add-on"> <AddOn.Name>Soaring utilities (CumulusX)</AddOn.Name> <AddOn.Description>Utilities to enhance soaring flights - CumulusX</AddOn.Description> <AddOn.Component> <Category>SimObjects</Category> <Path>SimObjects\Misc</Path> </AddOn.Component> <AddOn.Component> <Category>EXE</Category> <Path>CumulusX\CumulusX.exe</Path> </AddOn.Component> </SimBase.Document> To finish, add the location of the above add-on.xml to one of P3D's 'add-ons.cfg' files: [Package.n] Path=<users docs location>\Prepar3D v4 Add-ons\Soaring Active=TRUE Required=FALSE The add-on.xml definition can easily be enhanced to include other soaring utilities. In my setup I also have WinchX and the Aerosoft variometer DLL for use in their sailplanes. It all works well in P3D v4.5 but I don't have v5 so can't comment about that.

Yes, this is how ACM is intended to be used by developers, just to include their autogen definitions in a folder under their scenery which is then merged with all the others to create the required files in the sim's default autogen folder. The fact that ACM can also handle duplicates enables it to work as discussed here. ACM actually uses the SDK tools (spb2xml) to do some of the conversion work behind the scenes. I've made the effort myself for some add-on scenery products to extract and compare autogen definitions from the default autogen files before and after installation to see exactly which autogen definitions have been added. I then put just these definitions into a folder under the scenery for ACM to use, effectively doing some of the developer's work for them. Yes, it is tedious and not for the faint-hearted but something I thought worth doing when I realised it was possible. Rob

I'm not sure about the flipped dds textures now - the problem may be with FS Repaint which is quite old now. I've looked at the same textures in ModelConverterX and they appear ok with the switch to flip textures set off by default. In addition some of the texture folders have both bmp and dds present for the same texture and the bmp is being used in preference. My comments about missing models and textures still stand though and I'll try to start fixing these. I've so far found cases where textures for the wrong variant are present (e.g. B737 textures in B727 texture folders) and where the wrong model is specified in the cfg file. The latter are easy to fix once found. It will be the case that these problems are not showing up if the problem variants are not actually used in any schedules so what I'm doing might be unnecessary.

Has anyone else noticed any of the texture issues I think are present? As an example the UTT B787 has a number of flipped dds textures. It looks as if bmp textures were converted directly to dds without compensating for the fact that bmp textures are flipped internally by the sim before display. It's only some of the dds textures but I've found quite a few so far as there are such a large number of additional aircraft in Pete's updates! I think I can pinpoint missing models and textures automatically but the only way to find the flipped textures is by eye going through all the variations using a tool like FS Repaint. It would be very time consuming doing this in the sim as you'd need to make sure a schedule was active with the aircraft you want to see. That might be why there haven't been many comments from elsewhere as you'd have to be in the right place at the right time to notice the missing / flipped textures?

Hi Pete, I think I've found an error with the AIA Westjet 767 which would have prevented it displaying. The cfg file specifies the PW model but the actual textures are labelled for the GE model so I changed the cfg file to point to the GE model and the livery displays in FS Repaint at least. Perhaps this was the problem? In the course of optimising the textures I've come across quite a few aircraft where the cfg files point to the wrong models or texture folders preventing them from displaying. Also a number of DDS textures appear to be flipped so not displaying properly. I need to write something to scan through all the aircraft folders to pinpoint the above which should make it easier to go in and fix the problems. Could you PM me a link with your latest update from last week please so that I'm working with the latest version. Thanks

I've used Nick's setup guides for each system I've built since early 2007 with great success. The rationale is to squeeze the best possible performance out of well-specified hardware, and yes all the steps need to be followed in the correct order to work as intended. The thing that convinced me that his advice was worth following in the first place, and continues to be so, is that he properly explains the how and why of each step in some depth without being too technical or relying on too much jargon. He also explains clearly how these steps relate to the working of the FSX engine and why they help with performance. His latest guide, although dealing in some detail with current generation hardware (Haswell, GTX780 etc) still has much generic advice which will remain true into the forseeable future. Rob W

And once again we come down to the fact that FTXG, as released, makes some changes to core FSX files that will cripple certain parts of another landclass texture product (e.g. GEX) that relies on the FSX SDK being followed. Any product comparisons made under those circumstances ARE NOT FAIR. Those of us who are aware of and understand these changes can fix things. Until an uninstaller is available or uninstall instructions made available and promoted with reasonable visibility (say as a sticky post) most people will not really appreciate this FACT. Does anyone think there's a level playing field at the moment as far as FTXG and GEX are concerned, given the above? I have bought most of Orbx's products from day one plus all the GEX regions. I also happen to owe Nick a debt of gratitude for all the information he has shared over many years regarding both PC hardware and FSX. There are not many people who really know their stuff like Nick does and spend the time and effort to share it. Rob W

The central issue in all of this has in no way been resolved yet. FTX Global, when installed, makes changes to certain core FSX files which are not 'owned' by any developer. They are part of the original shared core of FSX. Updating these files has been done by many developers in the past to extend the scenery capabilities of FSX - I can name Orbx, Scenery Solutions (UTX etc.), FSAddon (Tongass Fjords), Aerosoft and Earth Simulations just in my own experience. All of the products from these developers have had the means to either automatically uninstall the changes or instructions of what is changed and how to reverse those changes. In some cases the changes are additive and do not affect anything else so wouldn't cause problems. However, in the case of FTXG, some of the changes make modifications to existing autogen and landclass lookups which will directly affect any other product that expects these to be as defined by the FSX SDK. So these products will be broken in that they won't display properly or may suffer performance issues. As FTXG targets global landclass textures the changes directly affect any other global landclass texture product the main one of which is GEX at present. So of course the developer of GEX is right to point this out! I note that Nick also makes a point of saying this isn't just about GEX as any other similar product will potentially have the same problem. As I've said before this would be ok if a simple and obvious way to reverse the changes was available. All I can say is that the necessary files have been backed up and anyone who knows what they are doing can restore these to allow other products like GEX to work properly again. I've done this myself so I have no problem living with FTXG. But what does a user do if they don't have the knowledge or confidence? It's been three weeks now since FTXG was released without the uninstaller that was supposed to be part of it. We've been promised an uninstaller a few times now within a matter of days but it hasn't yet appeared and as far as I can see isn't part of the forthcoming patch. If anyone wonders why I'm making a fuss about this it's simply because I don't like the misinformation that seems to be common currency about this issue. In my 10+ years of experience with FSX I've never seen a payware product make these kind of changes without a means to go back. Rob W

I'm concerned that a lot is being missed in this discussion and I've attempted to set out the facts as I see them in the other thread on this topic: http://forum.avsim.net/topic/415393-more-attacks-against-orbx-by-nickn-over-at-flight1/?p=2740501 Rob W

I want to set the facts straight here as far as I’m able because I’ve had a concern about the way FTX Global is installed and what is does to FSX from the day I first installed it last week. Please be clear that I use and enjoy many FSX scenery products both from Orbx and others including GEX, UTX etc. I respect both Nick for his expertise and long-time contributions to the hobby and the Orbx developers – my experience there goes back to the VOZ days in FS9. I have no affiliation with any developer other than as a long-time purchaser of FSX add-ons and I simply wish to keep reasonable control over what is installed and configured on my PC system so that whatever I choose to install works as the developer intended. I must say that I’m not happy about the way FTX Central no longer has a default option to return FSX to its pre-FTX Global state but even though this was stated by John Venema he also said publicly that there would be an uninstaller with FTX Global on release. Anyway, the facts to date: Fact - Backup copies of some of the files are available in an Orbx folder with the exception of the original terrain.cfg on my system but I can't say what would happen after an install of FTXG without any prior FTX products having been installed. Fact - Backup copies of the files lclookup.bgl and the autogen descriptions are available in the Orbx\scripts\backup folder with the exception of the original terrain.cfg on my system but I can't say what would happen after an install of FTX Global without any prior FTX products having been installed first. Fact - A backup of the terrain.cfg file exists in a different location in the Orbx scripts\FTX Global\backup folder. However, there is also a rather stern note in that folder that tells me never to move this backup file, that if I do Orbx software will not work and Orbx will not give me any support (‘!Important - Backup Readme.txt’). This note also refers to having the ability to uninstall FTX or to switch to FTX OFF mode (the old FTX default switch which has disappeared with FTX Global). What I gather from this is I may not move the terrain.cfg or change its contents. However, it seems to me that a user who is not technically confident may read that notice and think they cannot even use that terrain.cfg file backup to recover if it is ever needed. That isn’t true and the wording used is misleading in that it declares that a user should never remove the file or change its contents but what Orbx fails to specify in their documentation is that this file can be used to recover or switch back to FTX default mode or switch back to what the user was running prior to FTX Global being installed. Note also that on my system there are no warning text files added to any of the other script sub-folders, except in the FTX Global\backup folder itself! So it appears that Orbx is trying to tell me to not use my original backup file for anything. Fact - There is currently no automated method of any kind to restore these backup copies to their proper locations – to the contrary Orbx appear to be dissuading me from doing anything manually with the files that could be used to restore with that stern warning. This is very concerning to me because of the next two facts; Fact - As far as I can see there are no comprehensive instructions provided by Orbx explaining how to recover manually and even if there are they are not promoted at the current time in any meaningful way. Nor is there is any documentation on the details of what they did or how to reverse it or switch back if a user wishes to do so and again there’s that warning advising me not to switch those files on my own. Fact - Orbx no longer allows switching with FTX Central where I might want to use another product in different regions of the world and simply switch when needed. This was always a feature with Orbx in the past and FTX Central was specifically recoded for FTXG so putting all these facts together I feel these changes must have been planned. This has taken me some time to put together and might seem unnecessary by many of you but what’s clear is that the underlying issues are being glossed over. In summary, Nick appears to be correct in his statements of the effects of FTX Global and questions remain to be answered by Orbx. What happens when an uninstaller is released is yet to be seen but I think as it stands right now what Nick has posted is true and should not be obscured by the fact that he is the developer of a competing product. Rob W

And this is the heart of the problem really, isn't it? In this scenario everyone has to work with what Orbx are doing rather than the original SDK which by definition is the baseline, so de facto, Orbx becomes a new baseline. This will be resolved when the uninstaller is available or better FTX default is an option in FTX Central again :smile:

I just want to say that I don't think this is a fuss about nothing unless one only ever intends to use FTXG. One of the great strengths of FSX is it's extendability but there are core elements, as specified in the SDK, which if changed will have effects on anything that is using the SDK. Orbx have made changes to these core files from the beginning to great effect but have always to date allowed these changes to be reversed in an obvious way through FTX Central. So why didn't they do the same with FTXG? I was fully expecting a new FTX Global option in FTX Central alongside the original region switches plus the old default option to return everything back. The option to backup textures at install time is an incomplete remedy and even that relies on the user to manually copy the textures back to the right place. IMO a separate uninstaller (when available) isn't really the same thing as having that option in FTX Central. I believe a major issue with FTXG is that it has addressed the problem of landclass texture calls shared by certain regions of the world (present in default FSX which can result in inappropriate textures being shown) by remapping certain of those texture calls - JV describes this in his FTXG posts at the Orbx forum. Unless another product knows about these changes they will have unexpected consequences on the product, and yes we are talking about global add-ons like GEX. Developers might not always want to work together on such things, particularly if one side is forcing the change away from the published standard that everyone can agree on (the SDK). Although I have fixed this problem for myself I want Orbx to return the default option to FTX Central where it belongs. And yes I would still like to be able to use GEX if that's what I decide. To be honest none of this is really new and I've fixed similar problems in the past caused by the occasional freeware and payware add-on I've used. What is different is that Orbx are a big player in the add-on market and for some reason didn't deal with these changes to core files in the way they have previously. (BTW I can imagine that A2A might be quite upset if RealAir were to change a core DLL that supports gauges for example to implement some new feature they couldn't do any other way but which broke how gauges work for others. Fortunately that won't happen because the inner workings of the FSX gauge code aren't modifiable but in the case of landclass the relevant BGLs can be recompiled and the effects may be quite subtle in another product until the user notices that something doesn't look right and blames that product even though it isn't the cause!)

I've purchased nearly every Orbx scenery since they started out plus all the GEX regions and use both of them. FTX Central has always had the default option to return core FSX files to their default values which is what John Venema referred to in a post at the Orbx forums explaining how FTXG works in terms of landclass lookups and their previous regional products. Extending core FSX files is key to how FTX regions are able to have local landclass and autogen for example. John V said this was approved by the MS Aces team at the time provided there was a way to return to the default files - hence the default option in FTX Central. As released FTXG does not do this and I expect the forthcoming uninstaller will not be part of FTX Central and will have to be run separately (I'm happy to be proved wrong on this count). However, provided it works there will then be a way to restore the core FSX files. The problem here is that the changes to core FSX files potentially change the way in which any other product which does adhere to the FSX SDK will work such as displaying unexpected textures, misplaced autogen etc. So if you were the developer of a product which relied on the original FSX files being present (acording to the SDK standard) and then found that these were replaced without an obvious method to revoke the changes such that this had a negative impact on your product, don't you think you'd be a bit annoyed? Irrespective of how Nick expresses himself (or how it is received) what he says is correct in terms of the effect to FSX and other add-ons. Personally I question that this was an oversight because FTX Central has always restored the core files until now. So when the uninstaller is available there should no longer be a problem but the underlying issues need to be understood. I don't often feel the need to speak out as I can and do sort out these kinds of problems for myself but in this case I felt I had no choice. Rob W

Yes, all the above is correct. Backing up and restoring those key FSX non-texture files is what FTX Central used to do with FTX default mode. So far this option is missing with FTXG and is presumably what the uninstaller will address, although not from the new FTX Central I'll bet. There are a number of other add-ons which make changes to the autogen description files etc. such as Earth Simulations products and interestingly they have just released compatible versions of these for use with FTX which presumably contain the necessary definitions for both products. I think this is being extended to Aerosoft products which also make changes to these files. However, FTXG also makes changes to the global landclass system in lclookup.bgl in order to extend the range of textures that can be displayed and this will cause problems with other texture replacement products which expect the FSX default landclass to texture mapping. I expect the FTXG uninstaller will restore default versions of these files where possible or undo edits to the other files such as autogen and terrain descriptions. However, there's a well known fixed version of the original lclookup.bgl which corrects the landclass shown on slope elevations (I use this myself) which would probably not be the one FTXG restores. So this is the problem with FTXG apparently not backing up all the files that are being replaced! This might all seem overly complicated and not worth worrying about which is probably true if the user is going to stick with FTXG but if not... BTW - I've been imaging my entire system for many years (using Acronis like you) but after installing FSX to a dedicated PCIe SSD I kept the old mechanical drive as a mirror of my FSX install which is how I can see what changes an add-on makes. Restoring images isn't a very practical long term solution if say you want to use both FTXG and GEX as what happens when you want to install other add-ons - do you keep multiple images at the point your FSX installation split? This is a classic problem in change management of software and there are no easy answers. My solution is to keep copies of what has been changed and use a script to restore these files when necessary - FTXG will of course take care of itself.