Speedbird 217

Could also be that a lot of traffic is overloading your system to a point where it becomes unstable. What is your hardware and do you have any overclock?

The problem with the FSPXAI models is that the developer doesn't follow the SDK for P3D. It's also causing a bunch of issues with the newly released FSReborn AI Lights product and means the models are not compatible with it. Quite sad that a payware developer cannot seem to figure out how to follow SDK, when all the freeware AI models and AIG conversions for old FS9 models work perfectly and in lines with the SDK. My guess is that this is causing the erratic behaviour mentioned in this thread for those models - I myself am well aware of the FSPXAI A380 taxiing and taking off with spoilers deployed. I'm currently in the process of reverting back to TFS models (look over on the Alpha India group forum, they have done a lot of work to convert them for P3D, incl. adding PBR and dyn lights to them) and UTT for the 787. It's a real shame, especially considering that I paid good money for the FSPXAI models and yet have to go back to freeware because it's better.

Thanks Bob, I’ll give that a try. I’m testing ok on Memtest for XMP, but apparently the FSLabs taxes the system to the point where I get CTDs. Usually a couple of hours into the flight with an ntdll. Tried a full windows reinstall, all OC off (except XMP) and they kept occurring. Read about XMP being the possible culprit and have been testing ok so far. Even better if the voltage trick works so I don’t have to sacrifice performance and maybe even reinstate my CPU OC.

If the CTDs continue, check your OC. I have a similar setup to yours and my G.Skill 3200C14 32GB on XMP keeps causing CTDs with the FSLabs. Thats even without any CPU or other OC. Dialling the XMP down to 3000 seems to improve stability (still testing). It appears we are pushing the boundaries of current architecture...

The gates are too tight. The same applies at JFK T7, a lot of the BA 777/747 (and the LCY A318 as a matter of fact) enter the ramp and then get towed in. Not sure if UGCX simulates any of that though or if it's just gate to gate?

In case anyone finds these useful, I might keep posting them here. KSFO - full 24 hr cycle num_real_live_parkpos = 142 (of 199 or 71%) num_real_live_options = 407 num_defined_hours = 2558

Nico has done a fantastic job implementing this, thanks! This is a game changer and my airports will never look the same. Some stats from beta testing 16.1 with AIG OCI. The process is: set sime time to x UTC, RT to x UTC. Wait until PSXT has updated parking file, repeat and set x+1,2,n... & RT x+1,2,n... EGKK - full 24 hr cycle Total time spent on generating: <30 mins num_real_live_parkpos = 111 (of 120 or 93%) num_real_live_options = 400 num_defined_hours = 1719 KDFW - full 24 hr cycle Total time spent on generating: <30 mins num_real_live_parkpos = 170 (of 221* or 77%) num_real_live_options = 489 num_defined_hours = 2898 KIAH - full 24 hr cycle Total time spent on generating: <30 mins num_real_live_parkpos = 143 (of 203* or 70%) num_real_live_options = 373 num_defined_hours = 2332 LIPE - 8 / 24 cycle (traffic read every 3 hours)** Total time spent on generating: <10 mins num_real_live_parkpos = 22 (of 37 or 60%) num_real_live_options = 37 num_defined_hours = 122 *Includes some unused positions like "wp1001" and GA stands; adjusted % of total "daily in use stands" much higher **Custom accurate AFCADs used for all but LIPE

Thanks Nico, I have sent you a PM. One more question on the non-matches, what if I don’t add the reg? Does it just not write anything to the parkpos or does it write something generic? If you just want to install OCI for testing purposes, it operates completely separate from your existing AI database. On my setup I have my extensive PSXT traffic folder with thousands of repaints and custom aircraft.cfgs. When I installed OCI, I just pointed it to a new folder. It installs all its files there and adds itself via addon.xml. So when I want to do something with OCI i just disable my PSXT folder addon.xml entry and activate the OCI one and set the traffic slider in P3D. For my normal sim activities, I then just reset traffic slider to 0, disable the OCI xml entry and activate my PSXT folder entry. Looking forward to testing 16.1!

On second thought, whilst accurate in terms of what type it is, I’m not sure if aircraft type from the BGL comes in the right format (ICAO), so it may be a good idea to include that in the reg lookup. You have it in the AILG file already. You don’t want it pulling “Airbus A320-200” instead of “A320”?!

Sounds good to me. How would you treat non-matches, i.e. a reg in simconnect is not available in AI_liveries.xml? As a perfectionist I'd like to make sure I get as many perfect matches as possible. The OCI AI bgls are based on a flightplan and aicraft table unique to each airline. The flightplan has accurate regs for each aircraft type and they are linked to an "AC#X" entry. This entry is then looked up in the aircraft table to find the sim title and place the aircraft. So you'd have a representative schedule for PH-BKA for the week, it is identified by "AC#10" and then the aircraft table has "AC#10 = KLM B787-10". So that should not be an issue.

Thanks Nico. The registration match method would work well for me. I have close to 34,000 registrations in a spreadsheet against airline ICAO and they all filter through into the aicraft.cfg atc_id fields read by AILG. Just to understand the process, are you suggesting something like this? the xml created by AILG is read to compile a Reg=ICAO lookup when doing the steps 1-6 from further above, it reads reg from simconnect, looks up ICAO in the table from 1. and then writes airline+type into the parkpos xml In my mind that makes sense. I would still like to have an error log of missing regs vs ICAO, so I can hunt them down and add them. There may even be cases where the BGL uses a flightplan from W18 and calls a DLH A320 reg that since has been retired and therefore doesn't feature in my AILG liveries file anymore, so the error log would allow me to make sure it still gets matched against a DLH A320 for parking purposes. How would this lookup table you talk about be different from the mapping described above?

I just had a look in sim. The string in the view menu shows as "Airbus A319-100 - G-EUPP". So you are right, it doesn't include the ICAO airline code. They are still used to position the aircraft according to AFCAD, so they must be processed somewhere in the inner workings of the sim. I guess this brings me back to my previous point, you could either look up the ICAO via the registration (more tedious) or via the callsign (simpler). When I say callsign, it's the radio callsign for the airline only, without flight number. So SHAMROCK, SPEEDBIRD, KLM (that one actually works ha) or AMERICAN. I'm thinking along the lines of having a lookup xml in the format "Callsign = ICAO". There are already plenty of extensive lists out there, I'm happy to help if you want to test this method. Some examples are here in column 4 https://en.wikipedia.org/wiki/List_of_airline_codes. If you come across one of the few small airlines that may not have a callsign, the logic could either generate a generic "PVT/GOV" or the user could just add a unique callsign to that small airline in the aircraft.cfg and define it in the xml lookup, i.e. " Atc_airline = GENERIC1" and then add "GENERIC1 = XYZ" to the xml. It might be useful for the logic to print any non-matches to an error file, so it's easier to hunt down missing ones. Storing it in an xml would have the advantage that it's easier to add/edit callsigns similar to the way you already do it for airlines and aircraft types. You could then read the info from the sim, look up the ICAO via callsign and then write to the parking xml. Would that work?

Thanks Nico. I'll let you know tonight what OCI looks like in sim and whether if features ICAO airline codes. Atc_airline=xxx is the callsign. Callsigns should be standardised and unique, so a simple lookup against ICAO might be a workaround if the ICAO code does indeed not feature? Example, atc_airline=SPEEDBIRD, lkup SPEEDBIRD=BAW.

Another thought - you're saying "default traffic". So I'm assuming you're testing with the default traffic.bgl which uses those fictional airlines and default simobjects? Could it be that the aircraft.cfg of the default traffic simobjects doesn't have the "atc_parking_codes=XXX" line for fltsim.x entries? If it doesn't, can you add it and see if that changes what you see in the sim?

I will check tonight what the view says with OCI traffic. Surely the airline parking code (ICAO) must get processed somewhere, not least because without it the AFCAD wouldn't know where to put the object.

Nico, just to clarify; is the above process (steps 1-6) already possible without limitations today or are you working on an update to facilitate this properly? Ha, thanks! I’m afraid I already have a job. I agree that the most efficient way would be to go straight into the BGLs, as you have described. There are a couple of issues that would need to be solved first though. I listed them a few posts above, but the main ones are around the way P3D takes the BGLs and combines that information into the AI traffic it injects into the sim. Nico would need to have to read all BGL files, decompile them, look up the aircraft.cfg files to match the aircraft title from the decoded BGL to an airline (=ICAO) and then analyse the AFCAD file for each airport to decide where to place the aircraft. That sounds like a huge chunk of work for Nico. Sure, the advantage would be that you instantly get 24/7 coverage at all airports worldwide. Either way, the method mapped out in this thread allows us to get much more accurate parking files much quicker than before. At least we won’t have 5x Cargolux 747-8Fs and 2x BA A380s parked at Inverness and only get airline/type combinations that actually operate at an airport. Thanks, and of course you are right. This method should still be magnitudes better than the current generic approach. As you say, there are improved AFCADs out there, and Nico has confirmed here that XMLs populated via BGL will continue to receive live updates.

Thanks Nico. I think it's fantastic how you listen to feedback and try to implement new features. The above makes sense. So let's say I want to create a morning, afternoon and evening snapshot at KDFW. I would follow steps 1-6, load KDFW but need to do the following: Morning snapshot - set time in P3D to i.e. 03-Sep-19, 09:00 UTC and sync in RealTraffic to 03-Sep-19, 09:00 UTC using the time offset feature for the past. I now have my morning snapshot from the bgl files Afternoon snapshot - set time in P3D to i.e. 03-Sep-19, 14:00 UTC and sync in RealTraffic to 03-Sep-19, 14:00 UTC using the time offset feature for the past. I now have my afternoon snapshot from the bgl files Evening snapshot - set time in P3D to i.e. 03-Sep-19, 20:00 UTC and sync in RealTraffic to 03-Sep-19, 20:00 UTC using the time offset feature for the past. I now have my evening snapshot from the bgl files It therefore makes sense to do it for a date in the past, so you can sync P3D and RT time using the time offset. That's why I chose yesterday's date in my example above. Correct?

The more I think about it, the more I agree that reading it straight from the sim is cleaner and easier. P3D does a lot of work in the background and uses information from the Traffic bgl, the AFCAD and the respective aircraft.cfg files of each AI aircraft and combines it to inject traffic into the sim. I like your idea a lot and think it would improve realism and immersion a lot! I have disabled the default P3D traffic.bgl (the one located in World/Scenery) by naming it to *.off anyway. So when I do set the traffic slider to >0 it only injects "real" traffic from airline bgls. As I said earlier, my gates look realistic and great that way, but any moving traffic is 1,000x better with PSXT - so this presents an opportunity to combine the two and get the best of both worlds. How exactly does your proposal work then? I currently understand it as: Start P3D Set traffic slider to >0 (ideally 100%) Open RealTraffic and turn off GND TFC Run PSXT and it will log any bgl injected traffic at the gate into the xml file for more accurate parking Repeat for any airport and as many different days of the week / times of day you want to improve the xml Turn traffic slider to 0 Next time I fly, I only run PSXT and I will have my xml updated with the output from above. If I change the time in the sim while at step 4, it will timestamp different options into the xml, i.e. "09:00 BAW B77W, 14:00 BAW A320, 20:00 BAW A321"? What about when I use time acceleration? I think the traffic bgls support up to 4x, so theoretically traffic runs at 4x. It also should still continue to update the xml with real traffic after that, correct? So the order would be: Run Parkposgenerator to create the initial XML file for an airport Follow steps 1-6 above to create an accurate XML from bgls XML continuously gets updated each time I fly to that airport with traffic slider set to 0 with live traffic at gates

I don't know what's easier. I can send you a sample traffic bgl file later tonight if it helps? If you go straight to the bgl rather than via sim, you would need to read all of them in at once. My bgl folder has 600 or so airline_x.bgl files, so they would all need to be read individually, combined into one and then converted into the individual airport.xml files for PSXT. As I said earlier, there's already tools that can combine them all into one, so it's possible. I guess the advantage of this is that you could create 24/7 coverage for all airports at once. I believe the gate information would not be in the bgl itself. The bgl contains airline, aircraft type, dep airport, arr airport, dep time, arr time, days of operation. When the sim reads this it gets injected and the aircraft get placed according to the AFCAD. My understanding is that copy right should not be an issue as long as this takes place on your own computer and is not used for anything else? So if I have bgls installed and press the button to read them into xml and use them in my sim I don't see any difference to a lot of what happens today already. There are plenty of tools that decompile traffic bgls and turn them into different flightplan, aircraft and airport .txt files today.

It's just another option. If users want to continue to only use the generic Parkpos xml plus the live updates that is ok. For other users that have BGL traffic installed as well (and I would think there are actually quite a few that do, be it payware or the really easy to use free OCI from AIG) it gives them an option to quickly generate highly accurate parking xmls. I don't know if anyone would install BGLs just for this purpose, but if you have them sitting idle already, then why not use them in this way? I'd venture a guess that quite a few people actually started their AI collection with some sort of add on and now use the models with PSXT. If they still have the flight plans that would work nicely. It doesn't even have to be 100% accurate. For example, if you have flightplan BGLs from 2016 or 2017 for a particular airline, when you load an airport it will still be much more accurate than the generic generation of xmls, because the snapshot will say there are 3x Easyjet A320s, 2x Ryanair B737s and a DHL B757F at this airport at 20:00. This should be quite representative, even if flightplans vary slightly between seasons. It might also encourage people to share their accurate xmls more, like the couple live ones you already host on your site today. To your last question - most traffic addons use one BGL file per airline. So when you install with the One-click installer from AIG it automatically installs all the repaints and models for an airline and one BGL with the schedules for that particular airline. If you install them all you end up with hundreds of BGLs for all the different airlines. I believe there are tools and ways to combine them all into one BGL file though if that makes any difference. In my mind the BGL file itself is irrelevant though, other than to do its job of injecting the traffic into the sim when setting the slider to >0. With my limited understanding of how this could work, I see PSX "interrogating" the sim via simconnect as to what traffic is at the airport. So you load the sim with 100% traffic, the BGLs do their job of injecting it all, and then you snapshot via your tool and get something like "EHAM 20:00 - 28x KLM B737, 15x KLM B738, 7x KLM B744, 1x UAE A380, 1x AFR A320, 1x DLH A319, 2x DHL B757...". I'm not familiar with the detail, but I think it should even give you the stand/parking position coordinates to match? You could then take this information and populate the xml file with it, much like today with the live updates.

If you use either one of the payware AI addons or freeware (like the OCI from Alpha India Group) you get hundreds of accurate and recent BGL flightplans for AI traffic. This provides great coverage at the gate, but once they start moving the shortcomings of the BGL method become apparent. When I turn on BGL traffic I have ca. 90% of real world airlines at any airport based on flight plans from the past 2 years or so. My proposal is to snapshot that information and you get an accurate and pretty up to date list of Airline+Aircraft Type+Stand/Gate with a timestamp for any airport you want in seconds. So being able to temporarily set the BGL traffic to 100% would give you a current snapshot of airline movements at an airport based on schedules. If there was a way to snapshot what's parked at the gate via BGL and feed it into the parked xml you would get the best of both worlds. Once you've taken the BGL snapshot at an airport you just dial back the BGL slider to 0% and use PSXT with an accurate parking xml for an airport. The advantage in doing this would be that it would take you a couple of minutes to create 80-90% accurate xmls based on current BGL flightplans, vs days and weeks of running the live update to the xml. I hope that makes sense? If not drop me a message and I can explain further.

Hi Nico, Currently there are essentially 2 ways to write to a parkpos generated xml file - the initial file created when an airport folder is scanned, and the regular updates with real life parked aircraft as time goes on. The second option works great for airports where I fly frequently, i.e. my LHR and LGW are very accurate. The first method doesn’t give me good results at all. I know I can configure ac types in the UI and select airlines by region in a separate file. However, when flying to airports that I don’t frequent much, I get highly inaccurate results that totally kill the immersion. The other day I wanted to do a flight to BLQ and when checking in sim I had about 15 wide bodies from carriers parked there that only flew 320s to BLQ, as well as a bunch of 747 freighters. I then checked DFW and had 4 KLM 747s parked there... This got me thinking about how to quickly generate more accurate parking XMLs for an airport, including those that one flies to maybe once in a blue moon. I had the following thought: Is there a way to use .bgl traffic to populate your xml? Here’s an example - I’ve just installed BLQ. I run parkpos generator to create the xml with the correct positions. I then fire up P3D and turn my traffic slider for bgl to 100%, which means I get a pretty accurate representation of traffic at that airport as my bgls are based on current flight plans. Either through PSXT or Parkposgen a snapshot of my current airport location’s bgl traffic is made and used to update the parking xml similar to how you do it with live aircraft today. This could either be just a list of airline + aircraft type or more advanced by matching airline, aircraft and stand/gate. Whatever is easier to implement, both would be a massive improvement vs today. The whole thing takes 2 minutes and before actually flying I turn off bgl traffic again, restart my sim if necessary and use PSXT as today for my flight. Does this make sense and is it possible? Using the above way you could create very accurate parked traffic snapshots for multiple airports in a couple of minutes. It’s basically turn on bgl traffic, load BLQ, snapshot, write to xml, load next airport, snapshot, write to xml, repeat, turn off bgl, use PSXT as today. You could maybe even take it even further and i.e. load BLQ at 0800, 1400 and 2000 local to write different times and have more options - just like the live updates do today with their timestamp. You could then still keep updating those XMLs with real updates as you do today (hierarchy being initial generic file < bgl populated file < live updated file), but it provides a kickstart and also helps at airports where ground coverage is poor so there are no live updates to the parked pos. Just a thought but it would be amazing if this was possible to get better accuracy and immersion. Thanks!

Awesome, thanks Nico!!

I was just thinking about special liveries that may be painted on 2 aircraft. But I guess there aren’t many examples of that.

Hi Nico, That’s fantastic, thanks for implementing this! I’m travelling at the moment, so won’t have a chance to test until the weekend. You specifically state that “special” only seems to work if the atc_id contains only a single reg. So if there was a special livery with 2 regs the “special” in the title would not do anything and it would still get placed as static? Is that the case? Thanks!