csharpe

I realize this is an old topic, but I appear to have found a workaround that allows "Airport vehicle density" to remain at maximum and clearance to be granted for the misbehaving aircraft. For aircraft that get stuck in pre or postflight support, the baggage cart function can be disabled for the individual aircraft, allowing it to depart. Simply open the aircraft.cfg file, go to [exits], and make sure "number_of_exits =1". Example: [exits] number_of_exits =1 exit.0 = 0.4, 25.90, -4.5, -1.0, 0 The above setting allows for only the jetway to be active. If you have more than 1 exit listed and do not want to delete the other entries, add a double slash "//" to cancel out the remaining exits. Example. [exits] number_of_exits =1 exit.0 = 0.4, 25.90, -4.5, -1.0, 0 //exit.1 = 0.4, -32.00, 4.5, 0.5, 1 Best, Carlyle

Thanks, Steve!

Jim, Is FSX Gold (Acceleration) compatible with Windows 10 in its native DX9 mode? I'm still with Win 7, as I've had a tough time trying to get any definitive information on this. Thanks, Carlyle

As promised, I have created a "test" landclass to show whether or not grass LC is appearing correctly. The file at AVSIM should help illustrate this easily. http://library.avsim.net/search.php?SearchTerm=grass-tree_test_for_ftxglobal.zip&CatID=root&Go=Search Thanks, Carlyle

B247NG, I hear ya! I tend to avoid the forums for exactly the reasons you state. However, the topic of these texture "reassignments" in FTXG just hits too close to home, so I dived in head first. I actually posted a related question to ORBX on August 26th and have not heard back from them. But to answer your questions... Creating a "hole" for an airport background that intersects with hand-drawn landclass can be time-consuming (with a complex scenery), but it is not a big issue. However, it can only be done on the "developer" side to achieve the correct visual results. I have no problems doing this, and from the developer side, it's probably always safe to create that "blank space" for the airport to reside anyway. Now, the texture reassignment issue is a completely different problem, not to be confused with the scenery "hole" issue. The reassignment of the grass texture affects everyone across the board. This means that if 30 acres of grass was assigned to an area, it will appear as 30 acres of grass+trees with FTXG. This may seem like a small (or even non-existent) issue on the end-user side, because the end-result may be that it "looks" more pleasing. However, it can really mess up sceneries where grass is just supposed to be... grass! What's even more puzzling to me is why FTXG reassigned certain textures at all. Usually, the "reassigning" is done through a 3rd party landclass tool (like those made by Scenery Tech), and they do a great job without messing with the underlying architecture of the texture assignments. I'm hoping that cooler heads will prevail and a reasonable solution can be found. I truly am one of the "little guys" in this debate. But because there are a lot of us out there doing this for free, you can probably see why it is in our interest to try to preserve some consistency, so that the community of FS developers who volunteers their talents can continue to do so freely and willingly. Cheers! Carlyle

Thanks, Jean-Paul. It's nice to know I'm not just a "voice in the wilderness" on this topic. I also have that "Faroe Island" scenery, and that is a perfect example! Perhaps I should have illustrated my point in pictures... it probably would have gotten the point across faster and more effectively. Live and learn! Best, Carlyle

B247NG, Please do not misquote me. I clearly stated that the textures were "reassigned", thus replacing what should be grass with grass+tress. I'll be the first to admit that FSX would have died long ago without the wonderful texture "replacements" that have occurred over the years. However, "replacing" a texture and "reassigning" a texture are two completely different matters. When a company replaces an FSX texture, it is with the assumption that it is an improved, yet comparable, texture, i.e., grass=grass. When a company REASSIGNS a texture, it could be grass=trees or grass=subdivision, etc, etc. I've let Luis over at SBuilderX know about the issue, as he carries a little more weight than I do! Much "drama" could be avoided if people were to read what I'm saying, and not try to read what "they think" I'm saying. ORBX is an innovative company with great products. They just need to work out a few of the bugs.

I can confirm that more recent versions like 6.0.6001.XXXXX are a major headache. Version 6.0.5840.16386 of the UIAutomationCore.dll appears to be the "sweet spot" if it is needed. I can also confirm that FSX (on my system) appears to run fine without the UIAutomationCore.dll. So the options seem to be: avoid it if you can, but if you can't, use only 6.0.5840.16386. Best, Carlyle

Gandy, you've got it all backwards. Companies shouldn't be messing with the core structure of FSX to begin with. Many of us "developers" have full-time jobs that are not related to commercial scenery design, and we provide our service for FREE to the FS community. I have been making small patches for the more glaring problems as they arise, but I cannot address every problem. FTXG knows what they have done, and there are numerous forums dedicated to this issue that have been led by commercial scenery developers with much louder voices and gravitas. The ball is in FTXG's court. Whether they choose to listen is up to them. I will continue to design for what I know works: FSX and FSX+GEX, and I will apply FTXG "patches" when needed.

Sorry, Gandy. I thought my quote was self-explanatory. For every scenery I have created using SBuilderX, the grass has been replaced with the mixed grass/tree texture under FTXG but not under the default or GEX textures. (This has been tested and proven to be so by other users as well.) I do not make statements I cannot support, nor do I make claims. It is already well-known that FTXG changes the underlying architecture of FSX, and this is one of the results. Any other developer using the standard method to assign grass through SBuilderX should encounter this under FTXG. I can only speak to my sceneries (and there are 11 of them if you do an author search for "Carlyle Sharpe"), because as the developer, only I knew I selected "grass" and "grass" was not what was generated by FTXG. It's not rocket science... the sceneries were correct before an FTXG install, and now they are not. I really can't make it any clearer than that. It should be an easy fix for FTXG to return the texture reassignment to its original state, however, it may not be a pretty one. There obviously was a method behind these selective reassignments that led to the dramatic "look" of the overall package. Changing one element could affect the new look they were intending. The only issue is, in their successful effort to transform the FSX world, they inadvertently changed the "look" of every 3rd-party scenery that relies on landclass. The end-user may think it looks "better", but only the developer knows whether it looks "correct"! For people who spend hundreds of hours designing and hand-picking just the right textures to create the most accurate, realistic world as we see it, this is no joke.

Thanks, Jim. Since I'm in Win 7 (and plan on staying there a while), I hopefully will not have to deal with this soon!

I also make sure to keep a backup of the right version of UIAutomationCore.dll (6.0.5840.16386) in a safe place, so that I can easily replace it if it gets overwritten. I apologize if in trying to help, it was perceived that I was sharing "bad information". Sometimes, someone's "bad information" is someone else's "solution". In my case, the information regarding UIAutomationCore.dll has kept my flying "crash free" since I installed it in 2010.

Jim, Are you saying it is OK for us to delete the UIAutomationCore.dll in the main FSX folder? I'm TOTALLY fine with that if deleting it won't break something else. Thanks, B247NG! I've been using the "right version" 6.0.5840.16386 with no problems for several years!

Gandy, Only the developer truly knows if he assigned a grass texture and something incorrect was generated in its place. The end-user has no way of knowing what the developer intended, unless something glaringly wrong appears... for example, a developer will not purposely put trees on a runway. But as someone who creates scenery, I can tell you first-hand, that if I assign "grass" to a scenery, it is no longer generated as "grass" with FTXG installed. That said, I don't use the grass texture very often. However, when I'm trying to create an accurate scenery based off of satellite imagery, and I'm staring at an image that can only be grass with no trees, it would be kind of nice if the simulator would generate the corresponding texture that I assigned... as it did with the default textures and with GEX. Maybe FTXG will go back and reconsider some of these texture reassignments in an update...

Ciaran, you may also want to make sure you have addressed the "fsx uiautomationcore.dll fix" correctly. I read that you "got rid" of it. If you deleted it but did not replace it with the correct version, that could also be part of the problem.

I have been using the "new" GEX for some time, and it really is terrific once you get all those different areas interacting with one another. I was also REALLY excited to see that ORBX was working on their FTX Global product! However, from the "developer" side, FTXG has been creating some headaches. Unfortunately, FTXG has REPLACED the assignment for the standard “grass” texture with a texture that is a mix of grass and trees. (This can also contribute to the “tree issue” with trees in unwanted places…like airport runways and aprons.) This means that any developer assigning the “solid” grass texture from SBuilderX will not find that texture where it belongs with FTXG installed. This also means that any developers who choose to use the “grass” texture as an airport background instead of the standard “Mask Class Map” will not see a solid grass surface. The reason developers sometimes choose “grass” over the “mask” is largely for aesthetic reasons… it just LOOKS BETTER in some instances, but it serves the same purpose. Because the standard grass texture contained NO TREES, it was always a safe (and sometimes preferable) alternative to using the “mask”. FTXG makes the grass texture useless, and thus, “breaks” every 3rd party scenery that has assigned a specific “grass/non-tree” texture based on satellite imagery.

I discovered that landing lights had disappeared on the MS default planes after upgrading from FSX to FSX+Acceleration. After some research, I noticed that the "fx_landing.fx" file, which belongs in the "FSXEffects" folder, disappeared after the upgrade. If you have a standard (before updates) copy FSX, you can copy "fx_landing.fx" from that copy and into an upgraded copy, and the lights will appear again.Best,Carlyle Sharpe

Aerosoft San Francisco TweakAn easy way to circumvent the "Extremely Dense" issue with this specific scenery while leaving your slider set to "Extremely Dense" is to find your "\Aerosoft\USCitiesX-SanFrancisco\Scenery" folder and add the ".off" extension to the 3 file that contain the word "extreme":SanFrancisco_3D_001_Extreme.BGL.offSanFrancisco_3D_002_Extreme.BGL.offSanFrancisco_3D_003_Extreme.BGL.offThis should allow you to fly in and out of the area without having to adjust your sliders, and the scenery will still show excellent detail for VFR flying.

Does anyone know how to get the jetways to work with non-default aircraft?Is there something that needs to be added to the CFG files of the non-default planes that allows the jetways to detect the plane?Thanks,Carlyle