Speedbird 217

Apart from the fact that the initial post is completely inconsistent, self-contradictory, overdramatic, entirely hypothetical and asking questions no one can answer at this point, it also looks like this has the potential to turn into the next avsim blockbuster thread. Based on some of the initial responses here I'm getting the popcorn ready... That's the first result you get when you google, and it's wrong. Before throwing around words and definitions, people may at least try and do a little bit of research into them without just blindly repeating them. Literally the first line from wikipedia (not the best source in general, but in this case accurate) "In the computer industry, vaporware (or vapourware) is a product, typically computer hardware or software, that is announced to the general public but is never actually manufactured nor officially cancelled. Use of the word has broadened to include products such as automobiles." https://en.wikipedia.org/wiki/Vaporware So using this in the context of MSFS2020 is categorically wrong at this point in time.

Did you even read my post? I’m clearly saying there will most likely still be scope for enhancements, like detailed aircraft and airport scenery addons. But to keep with the naval references, if everything goes well those enhancements will be some racing stripes on the side or a golden anchor chain, not bucket upon bucket to keep the whole thing from sinking because the hull has more holes than a Swiss cheese... I really cannot fathom all this negativity in here. Just seems there’s no pleasing some. Shouldn’t this be a massive opportunity if you’re a developer? I have said this before, this is generating some significant mainstream media coverage and it will be released as a state of the art platform by a renowned software company which without, funny enough, we wouldn’t even have the sim this forum is about. There is lots of potential for a much bigger market once this goes live, as new and younger people get involved that just don’t fancy installing an essentially decades old sim which then requires thousands of pounds in investment to make it look just about acceptable and may or may not let you complete a flight without frustration. If you have a strong addon product then this should be great news to Mr Developer (more people to sell to) and in turn great news to the customer. The only reason to explain some of the behaviours here is that of course this has the potential to upset the market, make it easier for new, talented entrants to start developing as well as they don’t need to understand a jurassic core platform with all its intricacies and then code something with a hundred workarounds to make it function in the sim. A bigger market also means it becomes more attractive to developers that today don’t take notice or don’t care enough to get involved. More competition means developers need to up their game and cannot charge ridiculous amounts of money for addons that shouldn’t be required in the first place anymore. So yeah, I guess you can see why developers don’t like this.

It's a unique situation, because while I and many others are very grateful for all those third party addons, the need for a lot of them is only created by the countless flaws in our core simulator, which - despite what some say - dates back to the early 2000s. Don't get me wrong, it's amazing what LM have done with P3D, but it's a bit like a 737MAX - we are at a point where there's so much lipstick on a pig that we can't plug all those holes any longer. A lot of the third party developers' bread & butter is plugging those holes with their software, so it's quite frankly normal they don't like that shiny new next gen A350 or whatever in the form of MS20. Because it removes the market for them to sell all those hole plugs... I love my sim, but it also drives me crazy. For every one flight where everything goes to plan, everything looks nice and is immersive, nothing hangs/crashes/doesn't do what it's supposed to do there's another 9 flights were something goes wrong. And with that I mean one of the 10+ addons I have running in the background does somethings silly, something in sim looks bad or glitchy totally killing the immersion or the fact that I even have to run all those things in the background causing the sim platform to crash and leave me frustrated halfway through my flight. Again, I'm grateful there are all those things I can run in the background, but as a consumer I shouldn't have to! Why do I have to purchase an addon to fix time zones that are wrong in the core sim? Why another one to dynamically manage the FTFF so I can actually fly into big airports on top notch hardware without seeing a slideshow on reasonable settings? Why another one to simulate something resembling ATC? And why do I need half a dozen addons alone just to make it look acceptable via shaders, textures, effects, cameras and whatnot. Not to mention all the time spent on researching, purchasing, installing, setting up, updating and maintaining all those different tools. My hopes for the new sim are that it embraces current technology and provides a good enough experience out of the box. Does that mean there's no need for addons? Absolutely not! I am convinced we will still want more detailled airport sceneries and aircraft - good news for any scenery developer and the big aircraft studios. Weather? Maybe the standard engine does the job, but I'm sure there's more that can be done with it. That's ok. What I don't want is a dozen apps fixing things, running in the background at all times and causing instability because the core software is so stretched to its limits and flawed that I cannot enjoy it otherwise. So all those developers currently providing things that will probably be redundant will just have to find another way to add value to the new sim or find something else to do. I for one am quite impressed by the open approach Microsoft have chosen for this, and without them we wouldn't have a flight simulator to begin with.

I can only add my thanks! The team at AIG (OCI. model conversions etc), FAIB, the various gifted repainters and I would like to add Nico and his PSXseecontraffic to the list. All of them are amazing and free - thanks for populating my skies and airports!

Some very narrow minded and short sighted views in here. I also find this pointy finger attitude displayed by some in here quite patronising. Yes, I am considering myself on the side of caution for spending my hard earned money on my sim hobby at this point in time. It doesn’t mean I’m not spending any money at all on my sim, but it means I’m thinking twice before making a purchase, weighing price vs potential quality, use and time. Let’s use the hopefully soon to be released FSL321 as an example - I will buy this on day of release because I have been enjoying their 319/320 immensely and I know that even if FS20 will be the best sim ever, we are extremely unlikely to have an Airbus on that level for at least a few years to come. On the other hand there are sceneries, tools, aircraft and other environment addons that I’m holding off on buying because I simply don’t know how much use I will get out of them. And that’s absolutely fine and perfectly within my right to do so as a consumer. That is completely normal behaviour in a market, considering that a new product has been announced and I’m not going to invest a lot in something I may or may not be using in a year’s time. Now, how will all this pan out? Nobody knows, and either FS20 is going to be the best thing since sliced bread or not. However, some of the suggestions in here are quite frankly ridiculous. Let’s imagine we are living in the golden age of VHS right now and someone has just come out and said there’s this new format coming out called DVD/Blu-ray and you’re standing there arguing that everybody should keep buying those wonderfully bulky VHS tapes. Because if not, you say, you’re putting all those passionate and dedicated film makers out of business. Same thing as what’s happening here right now and you have to admit you’d be pretty foolish if you had followed that advice. Last time I checked there were also still lots of passionate and dedicated film makers out there... Now, is FS20 our DVD/Blu-ray moment? Who knows, but there’s a fair chance, so why risk it? The addon developers need to keep moving with the time, just like all other aspects of business and life. Quite a few are already working on or announcing they will be working on FS20 and they’ll be the ones coming out on top. If you want me to buy addons for a potentially soon to be dying platform, discount them and I will reconsider. Or offer me credit, like PMDG did recently so that I know my investment is future proof. One other point I’d like to raise and something that has been bugging me for quite some time on here. Addon developers are businesses and they’re providing me a product/service for a price. I’m a customer. While there are some incredible developers out there who constantly raise the bar and do display all this passion and dedication talked about here, there are also a lot of mediocre developers and some black sheep. I don’t understand why I often see developers, no matter the subject or suggestion, lifted on a pedestal and being told to be nice because if not they will stop developing. I’m paying for a service here, so I’m well entitled to complain or make suggestions. If that’s enough to make them “stop developing” then that’s quite frankly bizarre. I also don’t have to be grateful for whatever they put in front of us, bugged and unfinished. I’m paying a lot of money for this product, so I have rights as a consumer as well. Of course there is a balance and we absolutely should praise and encourage those that deliver us products of the highest standard and constantly keep updating them, even adding new features (FSL, Flightbeam, FSDT to name a few). Which brings me to my final point: money and access to this hobby. When I was young and started simming, addons were cheap and yes, maybe not as sophisticated. There was also tons of amazing freeware around. That means, it was relatively easy for me to really get into this hobby, build a nice catalogue of sim products, and start exploring a lot of different things in this virtual world with the little pocket money I had. Skip forward to today and I count myself lucky to have a salary that allows me to keep up with how expensive this hobby has become. I imagine myself trying to maintain my hardware and sim on the little pocket money I had disposable back when, and I struggle to see how any young person today can really become involved in this hobby of ours unless they either have very deep pockets, get all their stuff in illegal ways or have some sort of family ties to the hobby. When addons run into the hundreds of $ and I have to buy a dozen different tools and addons just to have a basic sim platform to use then that certainly doesn’t bode very well for the future of this hobby. I would argue that’s a far bigger threat to our hobby than some buyers caution and a new sim, and don’t forget that many of these young people may become the addon developers of tomorrow...and obviously that will never happen if they can never get involved in this hobby in the first place. That’s where Microsoft come in and they certainly have the experience and scope to make flight sim affordable and accessible for young people interested in our hobby again! That alone should encourage us to look forward to what’s coming, it’s called progress.

Try turning off any overclock you have and see if the crashes stop. If they do, slowly try to overclock again - step by step - until the point where it's stable.

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.