drobinho

FWIW that's probably a funky result of converting the OSM (openstreetmap) data into autogen (most likely with ScenProc). Compare the Gmaps YVR... https://www.google.com/maps/@49.1992981,-123.1923576,7259m ...with the OSM data... https://www.openstreetmap.org/#map=14/49.19786/-123.19107 ...and you can see how the wetlands/swampy area immediately to the west of 08L are classified. I'd wager that element got converted by ScenProc into a polygon for autogen flora, and the result is a bunch of trees hanging out in the water. The P3D SDK includes the Autogen Annotator, which can be really useful for removing things like that from your sceneries. If you take day to wrap your head around how it works, you could tweak that problematic autogen within minutes. That obviously doesn't solve things like clouds pasted onto the photo tiles, but it can help manage the autogen side of things. Missing OSM data is probably also the reason why certain areas of the photoscenery are missing autogen, too. Check openstreetmap for a particular location, and if it is missing plotted buildings and tree classes then you're probably not going to see autogen for the corresponding photoreal tile. Edit: P3D SDK documentation on Autogen is available here: https://www.prepar3d.com/SDKv4/sdk/world/autogeneration/autogeneration_overview.html An older How-To guide is also available on Avsim here: https://library.avsim.net/esearch.php?CatID=fsxsd&DLID=140537

I've spent way too long looking into & testing this at various airports. Waypoints and approaches are part of the airport data; they live within the <airport> blocks of the xml in the APX.bgl scenery files or your third-party ADE/afcad files, which means you can add/customize approaches for AI and ATC. All this stuff can be tweaked in Airport Design Editor (ADE) (https://www.fsdeveloper.com/forum/threads/ade-version-1-79-7410-dev-is-released-supports-p3d-v5.447279/). For example, using my FlyTampa EHAMv2 ADE file I can get ATC clearance for the ARTIP transition: ART1H transition: https://i.imgur.com/6k7fJVl.png Data in ADE: https://i.imgur.com/7cixPHV.png Test in P3D: https://i.imgur.com/KLIgh6V.png The process isn't so complex once you understand all the pieces, but there are both some tedious parts (like adding all the waypoints) and quirks too ("RNAV" is the only approach type that will recognize waypoint transitions, for example). If you're interested in customizing approaches, I'd say the first place to start would be exploring how they're put together. Download, install Airport Design Editor, and open up an airport. In the top right corner is a button that allows you toggle between "Airport Mode" and "Approach Mode". In "Approach Mode" you can see all the associated waypoints. You can also toggle displays of whatever approaches are also included through the dropdown menus (List > Approaches > [double click on an approach from the popup list]).

Another TimeZoneFixer user here on P3D4. I recommend it, especially if you are interested in longhauls/crossing many time zones. Somewhat related, but I also use a P3D.cfg tweak so that night lighting is activated earlier in the evening, and is disabled later in the morning, though skimming some of the comments in this thread suggests that might behave differently for v5 compared to v4. I personally use DAY_THRESHOLD=55000.

I agree with Dan, it's probably leftover registry entries that are stopping your installers. PKSIM scenery installers add registry entries, so deleting/removing/relocating files without removing the corresponding registry entries will cause this problem. In the future, if you need to move PKSIM files / replace the hard drive / etc, be sure to run the uninstallers first, which should remove the registry entries properly and allow you to run the installers again. Think of it as a light switch; can't turn it on twice without turning it off first. https://i.imgur.com/Hms0t1x.png That said, you can really mess up your machine by making changes in the registry, so it's important you know what you're doing. I strongly advise NOT to delete any registry entries first without making backups and understanding how to re-load your backup entries. That is why I'd recommend starting with Dan's suggestion re: free registry cleanup tools. Also might be worth reaching out to PKSIM and asking for some help. They may be able to help identify all the registry entries that need to be deleted.

So that is probably the 'rogue landings' bug/limitation that you're seeing, which is where AI land on runways that are set to NO for Landings. My understanding of this bug is that if the flight path of the approaching AI is within a couple of degrees of any runway at the airport, ATC will direct that AI to use the runway regardless of the YES/NO settings. This would also apply to the opposite-end of the runway (example: say you have rwy27 set for takeoffs-only, you might see flights from both hdgs 270 and 090 get directed onto 27). So this can essentially be attributed to the right combination of both the AI's and the runway's hdg. From my experience, when you see AI landing on a closed runway, it's an indication that all flights from that destination will be directed onto that runway (fwiw I use bgl files and not aigfp). I've seen this bug in numerous places, such as RJTT, PHLI, KBOS, EHAM, EKCH. Oh yeah, ha, whoops. Yes I did, for my own custom SODE file using jetways from other sceneries. Here's an updated version that includes all the original jetway objects contained in the original TB RJTT ADE file. https://www.dropbox.com/scl/fi/o274l0av5new2o8j5nib6/Rjtt2_adex_tb_dr_jetways.zip?rlkey=n6pmkiabuxgcjqpdomeg59sqb&dl=0

Sorry I'm really pressed for time at the moment (literally on my way out the door to a holiday party that I'm dragging my feet on...!). I might be able to sometime this weekend, but recommend you just take the parking assignments from your original work and copy those into my base files.

Yes, this is intentional and should be left as is. Essentially, it's the only runway that is long enough to accommodate tier 3 aircraft, as all other runways are "not long enough" so the heavies will be directed onto 34R at all times. There are some nuances there, but - for the most part - you can trick tier 3 aircraft onto using a 'closed' runway for takeoff as long as there are no other longer runways around *AND* that the runway in question is *ALSO* set to Y for landings. At least, that's how it works in my sim (v4.5); maybe they patched that out with later releases. Taxiways to the left of 34L were disabled a) because 99% of tier 1/2 aircraft (the only ones that qualify for using the runway) want parking spots to the right; and b) to force the heavies/tier 3 flights taxiing twd 34R for departures to use TWY L10 as the dedicated runway crossing. If you have runway exits on both sides of a runway, it opens up the possibility that ATC will direct an AI to use unintended runway-exits to cross a runway instead of your intended pathway.

Presuming this is for Technobrain's RJTT, feel free to use my personal xwind files as a base. They're a couple years old and could do with a refresh; they also incorporate Oli from AIG's JALD/ANAD domestic assignments. I have two files: one for North flow & one for South flow. Separate directional files are necessary for realistic behavior when using the runway length mod. If you build for one direction, and try to use it in the opposite, you will see funny things like landings occurring half way down the runway. North Flow: Takeoffs on 05 (tier 1/2 aircraft only) with heavies/tier 3 using 34R. Landings on 34L (tier 1/2 only) with heavies/tier 3 using 34R. RWY04/22 is removed completely from this file to prevent rogue landings on 04. South Flow: Takeoffs on 16R (tier 1/2 aircraft only) with heavies/tier 3 using 16L. Landings on both 22 (all aircraft) and 23 (all aircraft). https://www.dropbox.com/scl/fi/6zhfw0yrehtqa2iji6wao/Rjtt2_adex_tb_dr.zip?rlkey=wv35xsfl5xgj9yvt77c6m35l3&dl=0 To install, first make backup copies of your current afcad/ade. Then paste both files in the zip above into your RJTT scenery folder, and remove the ".new.[north/south].off" suffix from the file/direction you want to use. Switch directions by reapplying the suffix to the active file and removing the suffix from the inactive file, and so on.

P3D has some basic logic around aircraft size & runway size that can you can exploit to force AI onto certain runways. The sim has 3 (I believe) categories/tiers of aircraft, which is determined by (again, I believe) the weight values in the aircraft.cfg file. Each of these 3 categories/levels of aircraft has a different min rwy length requirement. So for example, say you have two runways set for departures, but AI continue to use only one runway (closest). You could shorten the runway distance for the closest runway so that it is above the min rwy length value for aircraft tiers 1 & 2, but below the min rwy length value for tier 3. With this edit, all tier 3 aircraft would then start to use the second runway (farthest) for departures, on the logic basis that it is the only runway available & long enough for use. These are the rwy length values that I've personally had success with: Tier 1 (GA + some regionals): No greater than 1828.8m Tier 2 (narrowbodies*): No greater than 2103.1m Tier 3 (everything else): 2103.2m or longer * A321/B739/B757 are defined as Tier 3 in my own sim. Again, I'm pretty sure this is set by weight in aircraft.cfg. Here's my own EHAM as an example. 4 runways set for takeoffs, but 3 of them are set to 2103.1m to allow only tier 1 and 2 aircraft. The result is that tier 3 aircraft will be assigned the Polderbaan (36L - the farthest runway if you're unfamiliar) for takeoff: https://i.imgur.com/dnOqTeN.jpeg

@fnav77 is referring to my reply, where I encouraged anyone interested to PM me directly.

I've done a little bit of testing on this, but this can be an understandably sensitive topic for devs, so check your PMs. You'll need to be proficient with the P3D SDK - including bglcomp and the autogen annotator - along with other P3D tools out there like ModelConverterX / SceneryBuilderX as well as image editors like Photoshop. If anyone is interested in this, feel free to PM me; but I'd ultimately say this is a more complex process than you might expect.

A great thread and a great surprise! Did I happen to stumble upon this exactly as they're releasing it...? Looks like EGLCv2 is already available for purchase: https://orbxdirect.com/product/eglc-v2-p3d Interesting that the product page for EGLCv2 isn't directly available from their product list (at this time, anyway) : https://orbxdirect.com/category/europe/esp

I use GSX L2 for all of my flights, but I've also refused all FSDT updates since the MSFS release, as that seems to be the threshold when a lot of P3D bugs were (re-?)introduced. Thankfully mine is stable, but I'm sure I'm missing a few features. Not sure if this is kosher, but I have two GSX installer backups - one dated from 2018 ("v2.5.0.11") and one from 2020 ("v2.8.2" which I think is the "level 2" installer). If there is any interest in these old installers, I'm happy to share so long as that's not violating anything. Of course you'll still need to register the product with your serial, so I imagine that would be fine...? https://i.imgur.com/Yd03aSC.png Presumably any features added later would be 'unretrievable' with these old installers, because the act of updating would bring you all the way to the latest version (don't think you'll have the luxury to specify how far up the version tree you can go)... so I think the best I can offer is "old & stable" vs "new & unstable". Would be nice if there was an archived repo of older versions!

Right, so the old airport code is WARJ and the new one is WAHH. And yes, the most up-to-date flightplans are most likely going to result in a near-empty Adusijipto thanks to the new Yogyakarta Intl (WAHI), but I meant more broadly speaking: the OP mentioned a discrepancy between their use of WAHH for AI FPs and WARJ for the ADE itself. Regardless of which way they choose to go, they will need to pick one of those codes and reconcile the data for everything to work correctly. Using FAJS/FAOR as an alternative example (since there is no replacement airport to deal with too) -- if you have flightplans set to FAOR but your ADE is FAJS, then AI will never spawn nor land at your airport without A) changing all flightplans over to FAJS or B) installing a correct ADE for FAOR while also disabling FAJS. All of this is probably academic, given most traffic is now at WAHI. If you only care about staying "current", then it probably isn't worth the time to reconcile flightplans & ADE codes for an airport that's barely in use. But you will find that valuable should you choose to use older flightplans (or you could just change those older flightplans to use the new airport lol).

If your airport is set to WARJ while your AI is set to WAHH, you won't see any planes parked at the airport. Additionally, arrivals will reach the vicinity of the airport and then fly in endless circles without ever landing. You'll need to switch all your AI flightplans over to WARJ if you're gonna go with the old code.