drobinho

If you're familiar with editing your system registry, you can add v4 entries to trick installers into thinking it's installed. Drzewiecki Design explains the technical side of it here: https://www.drzewiecki-design.net/forum/viewtopic.php?t=293 I'm primarily a V4 user, but I used the details laid out in that thread to add P3Dv5 entries to my registry so I can extract V5-specific scenery. Edit: Disclaimer to those who are unaware -- mistakes in your system registry can really mess things up so I would NOT recommend experimenting with the registry.

It's probably something to do with the model or aircraft.cfg. I've noticed the newer FSPXAI releases have some unusual choices around model types. I haven't played around with their 737/A320 packages yet, but I know the EJets and 767s both require specific phrases included in the title= field to control this stuff. This is something that's usually been managed with separate models whereas FSPXAI seems to use a different approach. https://i.imgur.com/pXeEZAJ.jpeg

If that's the ADE available on AIG forums, that would be the one by Brad & me; and I wrote the taxi logic. As the previous poster correctly mentions, it's all about "the shortest distance from starting point to runway entry." Some important caveats here. On the taxiing side, it boils down to a game of geometry and finding the shortest distances. If you look closely at taxiway intersections, you'll see triangular connecting links of varying size, which influence the shortest distance calculations and ultimately which taxiways AI will use. You'll also notice that some intersections don't actually have true connections, but instead the lines simply overlap. This is another way of controlling the direction of AI, and ultimately the runway entrance they pick. For example, let's look at AI taxiing down to RWY33L from Terminal 2 (KAL). AI could feasibly pick any parallel taxiway that connects taxiways A & B (the long north/south taxiways), but how do I control which taxiway they use...? Compare the triangular taxi links for taxiways A11 and A9, and you'll see that the connecting link for A11 is 13.5m vs 11.4m. Geometrically, because A11 is a longer hypotenuse relative to A9, that is a shorter route to the runway entry thus AI coming from T2 will always use A11 instead of A9 (or any other) when headed to RWY33L. Keep in mind that whatever shortcuts you build for departing traffic will also be potentially available for arriving traffic too (depending on where they're coming from - which runway - and where they're going to - which gate - so you have to be mindful of arrival vectoring). On the runway side, the entrances need to be within a certain runway length from one another. I can't tell you exactly what the exact maximum length/distance is between entries (because I don't know it), but if you hover over the runway vector between the entries on RWY33L, you'll see it's a length of 26.1m (so maybe use that as a max value in your own builds...?). In order to make that happen, you can see the taxiway vector that sits on top of the runway. One side effect of this is that AI entering the runway from the southernmost entry will take a little bit longer to taxi into position compared to the northernmost entry. It's all a bit tricky and definitely requires patience testing all the values, but I hope this helps.

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.

How to update default airports to new codes: 1. Use ADE to identify the default APX file - and its file path - containing the old airport: https://i.imgur.com/MxcmwtW.png * WARJ/WIJJ/WAHH is one of the Indonesian airports that's been re-coded multiple times 2. Copy the APX file from the folder/path displayed in ADE and paste into your own working folder, open with BGL2XML https://i.imgur.com/RYQ4cce.png 3. Validate the input path, and set the output path for BGL2XML, hit "Go" to decompile. https://i.imgur.com/XDk7dnI.png 4. Open the new XML file in an editor, find & replace all instances of the old airport code with the new one https://i.imgur.com/E5vH7fS.png 5. Save your changes as a new XML file, with a naming convention to help distinguish the edit https://i.imgur.com/vTNbBPw.png 6. Compile your new XML file into bgl with BGLComp from your P3D SDK https://i.imgur.com/0shF1st.png 7. Clean up the filename if necessary, copy & paste back into the original P3D folder where the default file lives. Archive/disable the old file. https://i.imgur.com/niy5EYG.png EDIT: If anyone's interested, here's my own working/partial list of impacted Indonesian airports. I'm sure I've missed some(/many), but this is at least a good start: https://www.dropbox.com/scl/fi/tj7utdbild65taopv2ws2/Indonesian-Airport-ICAO-Code-Updates.txt

I recently went through the process of rejigging all my Indonesia sceneries and flightplans (I'm building out a retro database), and this was one of the biggest hurdles. Be mindful that this also impacts AI flightplans; so if you want to get more traffic into WAHH, you'll not only have to use some older flightplans - as most flights have moved over to the new airport - but you'll also have to re-code them from WIJJ to WAHH too (maybe there's a sweet spot of flightplans around 2018-2019 where the old airport was still in use but they were using the newest code..?). As for getting the ADE/scenery/sim to play nice, I believe there are three different approaches to this. Ultimately, you'll want to pick a single code and run with it across all your data, but that does mean identifying all the instances of that code and making updates. All of these options require the use of ADE, BGL2XML, your P3D SDK, and AIFP; so I'd start by first making sure you have all those installed. 1. Re-code the default airport from WIJJ to WAHH (this would allow P3D to "recognize" the duplicate codes and prevent overlapping scenery). 2. Re-code BDO's scenery from WAHH to WIJJ (this would allow old AI flightplans to more immediately work with your scenery) 3. Isolate & remove the default airport entirely, leaving only your third-party scenery (you would still need to make adjustments to AI FPs to make sure they use the right code). I ultimately did Option 3 above but realized that Option 1 might have been a slightly easier alternative. Options 1 and 3 require older AI flightplans to be updated while Option 2 does not. Option 2, however, is more challenging where old airports are closed completely (and subsequently removed from charting & flightplanning databases like Simbrief). I'll put together a little job-aid and circle back here.

Thanks for posting this. Happy to see they ported their new version over to P3D after initially releasing it for MSFS. I'll probably pick it up sometime soon. Static jetways should only be a small speed bump; only take a few mins to create a SODE/GSX alternative. FWIW that old scenery was built by the same developer - FSDG (Thorsten) - it was just published by Aerosoft. It's definitely better than default, but it's easy to see how out-of-date it is. https://aerosoft-shop.com/shop-rd/bilder/screenshots/fsx/malex/maldives-x (19).jpg https://secure.simmarket.com/images/products/a/af/19363/345851_vrmm_08.jpg A cursory comparison shows the new one includes the expanded islands, bridge connector, new seaplane base, full-parallel taxiway & new runway, and obviously the new terminal complex. Also will be nice to have updated texture sets. Comparatively speaking, suppose it should be noted that both these new "Maldives Atolls" and "Male" will cost ya 27EUR combined, while the all-in-one FSX package still remains at 15EUR.

The manual I have for ImagineSim WSSS Singapore specifically calls out Water Detail = Ultra as a cause of water conflicts, so I wouldn't be surprised if the same design/development choices are in play with your KLGA scenery. They don't offer a reason - just the culprit - but I'd nonetheless recommend reducing Water Detail to High when flying in/out of ImagineSim sceneries.

An alternative approach you might consider is cloning & replacing the drive. For example, when I migrated my P3D install onto a new nvme drive, I: Installed the new nvme drive and assigned it a random, new drive letter Cloned all content - including the folder structure - over from the old drive to the new drive Used Disk Management to give my new drive the old drive letter that my previous drive was using This step is vital to ensuring that all those pathway mappings that Rogen refers to above remain valid FWIW if your new drive is a Samsung, and your old HDD contains your Windows install, then you can use the Samsung Magician software to clone your Windows-installed drives.

Yeah it takes a little getting used to, like any interface, but it's one of the tools I use the most. Let me know if you ever have a change of heart re: GSX-vs-SODE jetways and run into questions with editing/placing jetways. I prefer SODE jetways for the things the GSX jetways can't do (like connect w/ AI after landing, or connect multiple jetways to AI) and have spent too many hours fiddling with this stuff. Here's the SODEplacer tutorial: https://sode.12bpilot.ch/?document=tutorials/sode-placer-workflow And all the rest of the documentation is available here: https://sode.12bpilot.ch/?page_id=101 SODEplacer basically has two distinct methods for adding objects, depending on the object type: 1 is jetways (by selecting parking locations and then adding jetways), and 2 is everything else (windsocks, runway lights, trees). Took me far too long to figure out *how* to add the second set other than copying existing placements. To add a new placement, select "Add Library Object" from the Edit dropdown menu (or the shortcut: Insert key). From there, the process is essentially the same: move cursor > left click to place > then double click into the placement to configure it (select model, choose name, set altitude). "SimObject Name" is that individual instance or placement's ID. It's a free-text field intended for dev organization; it's not something that needs to match a folder or filename. For Library Objects like windsocks, the ID is helpful for identifying the block of code within the raw XML data; and it also displays in the Object Details (see second screenshot > top left window "Edit Jetway SimObject" > Name value), but other than that it doesn't carry too much weight. If you copy and paste an existing object multiple times, you might end up with SimObject Names like "[original.name] 1 1 1 1 1". On the other hand, for jetways: it's also the name of the jetway that appears within sim panels like SODE or GSX windows.

FWIW Ray, SODEplacer is an effective and fast front-end tool you can use like ADE to make tweaks/new files without tooling around in the raw XML (you can also "connect" it to a live session with your sim to display your aircraft location in real-time, giving you another way to trace-spot specific coordinates/locations). You also don't need to copy/clone the SimObjects content into a custom folder, you can just use SODEplacer to build the xml placement files for your existing assets. Creating new custom folders adds complexity - specifically around model names, folder names, and cfg files, as you've just experienced - that isn't necessary when using already-installed material. For example, my SODE edit for FSDT's PHLI airport borrows Flightbeam jetways: https://i.imgur.com/CE4HgEH.jpeg The placement file maps to assets from the Flightbeam KSFO folder, which is also easily selected with SODEplacer: https://i.imgur.com/oGpaROR.jpeg Modifying/cloning existing content in the SimObjects folder itself should only be necessary in extreme cases. The only time that was ever necessary for me personally was when I discovered that ORBX KSBA and [unknown.scenery.#2] use identical names for the SODE models, which resulted in the wrong SODE models spawning at the wrong airports. This was resolved by renaming the content and updating all the corresponding cfg's and xml files.