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