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!

On 6/8/2018 at 12:12 AM, glider1 said:

 

It would be great if someone wrote an addon.xml for CumulusX in P3Dv4 because it is just begging to be installed that way.

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.

9 hours ago, kevinfirth said:

No.  You only need one set of files for each scenery with custom autogen.  In our example the P3D autogen folder is the one holding the Orbx ones.

Arno has coded ACM to filter out duplicate entries in files, but it is recommended for devs using ACM to only include THEIR custom autogen in additional files, not duplicate other devs stuff.  If you wanted to be purist about it you could download spb2xml, convert the autogen spb files to xml then edit out any duplicate entries in files so you didnt rely on ACM doing it for you, but I suspect most people wouldnt be up for 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

Absolutely, and from what I have seen at OrbX at least publicly, they are willing to share this info and work with other developers to make sure their products mesh well with OrbX products. Is this the way it should be, maybe not, but OrbX is trying to improve and extend an outdated and unsupported product in FSX.

 

This scenario is not impacting NickN's product GEX, since FXTG replaces it. Therein lies the real problem with his posts. Scare users away from FTXG so they will stick with GEX.

 

In reading the majority of posts about FTXG on the interweb, its not working, even with the problems outlined so far.

 

Sent from my Nexus 7 using Tapatalk 4

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

Many thanks for this Rob. So if I understand correctly, the 'texture backup' option offered by the FTXG installer just backs up the textures, not the other FSX files. If so, those who have installed FTXG without backing up the other files (and why would they) cannot go back to their previous setup without re-installing FSX. They can uninstall FTXG and restore their textures, but changes to the other files will remain. Which may or may not cause them problems, depending on what other scenery addons they have now or in the future. Correct ?



Even when the uninstall program is available, it can't help these folks, since the files were never backed up. Or I guess if they are standard FSX files which are not (normally) changed, they could be copied from a vanilla system ?



Major case for doing a full system image backup before install methinks. Even when the uninstaller is available. Thank goodness for Acronis True Image :smile:

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.

Pretty much as I expected. Are you able to list all the files changed, Rob ? Or are there too many ?

Dick,

Specifically terrain.cfg in FSX root; AutogenDescriptions.spb, default.xml, Extrusions.spb, Materials.spb and RoofDescriptions.spb in the Autogen folder; lclookup.bgl in scenery\base\scenery; roofs.bgl in scenery\global\scenery. Some of the changes appear to be additional entries to support the new autogen etc. so won't affect anything else but other changes are modifications to existing entries and will have an effect. A number of textures in scenery\global\texture and the root FSX texture folder also appear to have been updated, although whether actually changed or simply having a different file date and time stamp I can't say. The main ones I've listed were definitely changed though as I did a binary comparison. Interestingly the texture backup made by the FTXG installer seems to contain a number of textures that aren't actually changed like some of the special UTX textures!

The point is that the bgl files above (particularly lclookup.bgl) are key to what textures are displayed by the FSX landclass program code. If these are changed in ways outside of the scope of the FSX SDK landclass specifications then the results may be unpredicatable for other products that do rely on the SDK, hence the warning by Nick. Provided the user can go back to their original files if they wish then all is well (for the user at least, though whether any product should do this is another matter). I assume that the forthcoming FTXG uninstaller will rectify this situation but Orbx have said it will be a stand-alone tool rather than integrated with FTX Central so perhaps not as clean to use if you wish to switch between products easily.

It's just an inconvenience for me as I'm aware of the underlying issues but looking at the posts in this thread it seems that many people are not! I think Nick's comments should be read carefully and not simply from the point of view of a competing product. GEX has been around for as long as Orbx and works fully within the scope of the FSX SDK assuring compatibility with any other add-on which does the same.

As to NickN's comments re FTXG method of overwriting textures - I've known Nick for quite a while and he just tells it like it is. People are reading WAY to much drama into his post.

+1

I have both of these products and want to be able to use either as I see fit. I keep a 'mirror' of my main FSX install and using file comparison software can see EXACTLY what changes have been made - I always do this for a major install which might alter core FSX files as I like to have control over my FSX installation, not the other way around.

I can say for a fact that FTX Global does alter core FSX files such as those in the autogen folder, the key lclookup.bgl file and terrain.cfg. ORBX have said as much in their forums in describing the changes necessary to support their way of 'extending' FSX. What isn't made so explicit is the effect this may have on other products and as it stands restoring any saved textures backed up by the FTX Global installer won't return everything to its pre-installed state. As the new FTX Central app no longer has the default option which used to perform this function it's impossible at the time of writing to return to a pre-installed state unless the affected files were carefully backed up by the user.

I note that Orbx have said they will release a full uninstaller. I will test this once it's available and I hope that will resolve the issue of how to fully revert to another global texture product. I would have much preferred the old default option in FTX Central to have been retained in some form though.

This from a long time purchaser and user of most Orbx and all GEX and UTX products and one who can see the point Nick is making.

Rob W

Hi Phil ('Dougal'),I've been using Acronis very successfully for two years now and although I'm still using version 10 I believe the current version works in very much the same way.As far as I'm aware the clone option applies to an entire disk as you have found. As you may know this clones all the partitions and the partition table of the disk so that the cloned layout is an exact copy of the original. The point here is that the location of the partition on the disk is also copied so that copying the partition data only would not be sufficient.However, using the partition imaging feature of Acronis lets you make a precise copy of all the data in a partition and restore that pretty much to any other partition you want (although bootable operating system partitions must be restored as 'active').Can I ask why you want to clone an individual partition rather than make an image of it? An image only differs from a clone in that the data may be compressed in the backup and the precise layout of data within the image will differ. When you restore it the partition will be created as it was originally.I've used this method many times with no problems of corrupted data etc. and trust it completely now. I've used external image backups to USB drives but most often make use of the Acronis Secure Zone (SZ) for speed and simplicity. All you need is an internal hard disk with sufficient capacity and let Acronis do the rest. I have four disks in my current machine: 2 WD raptors for the OS and FS9/FSX, another disk for media and other data storage and another big disk for backups of software and a big partition dedicated to the SZ. With your machine spec. image backups to the SZ should fly. My machine is similar and it takes me less than 3 hours to backup around 300Gb spread across 7 partitions.You might also want to check out the Acronis forums (http://www.wilderssecurity.com/forumdisplay.php?f=64) as there is loads of useful info and I'm sure your question may get a more expert answer than I can give :) Rob

I'm doing very well thank you. Between jobs at the moment so I have the luxury of plenty of time to follow my interests :) You're right about the partition order only I have it the other way round! :-doh Simple reason being that I installed XP32 before coming across your recommendation for XP64 for FSX. It certainly boots quicker than XP32 but has a simpler configuration so I'm not comparing from the same baseline. However, it is noticeably more fluid running FSX so I'm satisfied. Hmm.. it might be interesting in seeing what's involved in swapping the partitions using my backup images. Both OS's boot as the C: drive as I'm using a boot manager to hide the alternate active partition so possibly all I need to worry about is the MBR although there may be OS dependencies I haven't considered. Apart from my partition images I can easily clone the whole disk beforehand just to be completely safe.But I didn't intend to hijack the thread. I was intrigued by Mike's use of multiple partitions as I have much the same situation (7 spread across 4 drives!). A lot of this is for historical reasons and it would be an absolute pain to try to change the layout in some cases. However, careful consideration of why the methods you posted work showed me that I could get a lot of the benefits by careful assignment of the 'performance' partitions. It's great you take the time to explain this as we all benefit and learn.:-beerchug

Hi Nick, D