c912039

mSparks gave an excellent answer, in a manner that negated any flare-up or 'ammunition' against XPlane. It was a mature response, well handled, without the need to inflame the topic, or rile up the Avsim user posing the question.

I find this response is really disappointing! I thought that Avsim was an open forum where users and enthusiasts could exchange ideas, ask for advice, add to our understanding of aviation, physics etc. Instead, now we are going to judge each and every user as to whether they are worthy of a reply or response? If this trend continues, this forum will be no better than 'the org'. It is a valid question, especially if someone may be contemplating and upgrade in graphics cards, and are balancing up whether having to shell out extra money to buy into Nvidia is worth it, if XP is more likely to support FSR instead of DLSS3. The answer is still the answer regardless of who might of asked it, or whether they might be a user or fan of the other sim or not. And believe it or not, they are probably other users who are interested in whatever info you might be able to shed on the subject, whether they are dedicated XP enthusiasts, XP users, or user who are trying to stir up a fiery debate. If there are shortcomings with a product (on either side) then one can be diplomatic in the response instead of deeming if someone is 'worthy' of a reply. You have lots of really good, useful information that ALL Avsim readers would benefit from (XP and non XP users). Please dont go down the road of making sharing information hyper-partisan. Everyone, please play nicely!

Something else Ive observed. As there isn't much circuit traffic at YPPF today (perhaps FTA and the students are on Xmas break), I noticed a tug aircraft (VHBOT) and a Glider (VHGER) at a gliding field near YPPF (YGAW), so I moved there to observe. VHBOT (for some reason RT displays a/c type as TRIN, whereas both FlightRadar24 and RadarBox both show this a/c as PA-25-235 so not sure where RT is getting its a/c type from). was shown stationary, and then took off, towing a glider (not visible in RT as it didint have a transponder). The tug was shown to take off in PSXT, and after completing its towing, landed back at YGAW, for a full stop, and then parked at the apron still squawking. Sometime later, it towed another glider (this time VHGER with does have a transponder) and RT showed both tug taking off and the glider being towed. PSXT did not show the glider in tow or even airborne (it had previously displayed it on the ground as a glider), and the tug failed to gain any altitude in PSXT, despite RT showing its correct altitude. So whatever might be causing T&G aircraft to not take off properly after touching, might also be impacting VHBOT, even though the a/cc had come to a full stop, parked up, left the XPDR on, and then after a few minutes, taxied and took off again (with the climb issue showing up). Ive also had a look in the FSLTL_PA28A flight_model.cfg file (model used for the DA40s, and VHBOT aircraft Ive been observing) and noticed that the reference speed for rotation_speed_min is set to 70 and takeoff_speed is set to 80. The DA40s would probably be able to both rotate and take off at speeds below 70 and 80 respectively. Would the values in the flight model config files be causing PSXT injected aircraft using this model not be able to rotate and climb if the real RT data has the real aircraft rotate and take off at speeds less than the model config? If so, I could experiment and change those 2 speed values to see if it makes a difference?

v33.2.1 MSFS testing. I tested realtime circuit traffic at YPPF (starting at around 2330 UTC) however there wasnt a lot of circuit training happening. of the few aircraft that I was able to observe, a few climbed as expected on T&G circuits on RW 03R, a few took beyond threshold of 03R before they climbed rapidly (I'm assuming to try to catch up with RT's altitude data at that point, and a few remained hugging the ground. I thought it might be useful to compare with the results I observed from 16/12 beginning from 0140 UTC. I only have a standard RT license, but felt it worthy of me buying an upgraded RT license so I could test the same traffic as per on the 16th, given that you are making an effort in trying to solve this issue. Anyway, T&G circuits on the 16th were using RW08R (predominantly) with some also using 08L. These 2 YPPF runways are much shorter that 03/21. I noticed that compare to the traffic observed on the 19th (using RW03), T&G traffic took well beyond threshold of o8R before they 'lept' up into the air to finally climb to correct CCT height. I did notice on after touchdown, when the aircraft starts to accelerate again (acceleration isnt all that noticeable with PSXT) I did observer that the aircraft (all using FSLTL PA28 model) did attempt to rise slightly above the runway, before being 'pushed down' as if the model was attempting to begin the climb but MS refused to let it rise and climb. I'm not sure how MS 'flies' your injected traffic, and to what extent the model flight model/params determines if the aircraft should be flying or not - could it be that there is enough gap in valid speeds between the real DA40's and the PA28 model to stop MSFS from 'flying' the injected traffic off the deck during T&G's? Also, given MSFS cant provide 'historic' weather, it means that whilst Im playing back traffic for the 16th, MSFS is using weather for the 19th (different duty runway), would the difference in wind direction have any affect in the replay traffic doing T&G on 08R from the 16th, with MSFS realtime winds favouring 03 (on the 19th)? Anyway perhaps 25% of the T&G traffic never got off the ground, the remainder eventually got off the ground (some only until turning crosswind) but almost all never got off the deck until well past the threshold. Compare that to aircraft taking off for the first time, and all of them climbed off the deck and climbed as per expectations. I hope these observations are helpful. Regards David

I was going through the list of exceptions/errors PSXT would report to see if I could fix/clean up some of the aircraft issues. I had the HPG balloon in my community folder, and PSXT listed it as an exception. I had a quick look at the aircraft file, and HPG decided to list the icao_designator_type to "HotAirBalloon" which is not the correct ICAO code. As I'm reluctant to change official 3rd party configs, and to learn more about how PSXT matches models, I decided to try an experiment and to add an entry to fixes.xml (Yes I know this file gets overwritten by subsequent PSXT releases, but this was an experiment only, and if it worked, I was going to suggest adding this 'fix' in future fixes.xml releases). I added <fix wrong="HotAirBalloon" correct="BALL" /> however next start of PSXT gave me an error that ! wrong fix HotAirBalloon->BALL, the latter is not a valid type As BALL is actually the correct ICAO code, I assumed that you had not included the special designators in PSXT list of allowed codes, hence my request. I read with interest that you exclude SHIP and BALL data; does RT data for a balloon or airship cause problems for PSXT? Would it be possible in future editions of PSXT to be able to support other object types (like balloons/airships?) David

Hi Mike, you might be onto something there. After watching a couple of hours worth of T&G at YPPF (using all sorts of different models for PSXT to use to depict the DA40s), and reading your comments, I believe you have described what I saw, that PSXT seems to have problems with aircraft that are doing T&Gs in the circuit. In general, aircraft that were taking off for the first time and heading out NW to the training area seem to show takeoff and climb out correctly. David

I use FSLTL but not AIGAIM objects. I had configured PSXT to look in community folder for aircraft. PSXT found the FSLTL library, but also the couple of GA 3rd party aircraft Im currently flying. PSXT was using the JustFlight PA28 Warrior as the model for some of the DA40s. (By the way I didnt experience any performance or frame rate drop when those models were used, I am limiting my frame rates to 30fps but Im also using an old 1080Ti GPU - I was surprised I didnt get fps drop below 30 when these complex models where used instead of out of FSLTL. After your response, I set up file in regcodes to force all of the DA40 regs that fly out of YPPF to use a specific model, so I could test different configs, so I can better understand what might be happening. I set up the regcode entry to use FSLTL_HTAI_P28A_ZZZZ for all the DA40 regs belonging to FTA. After forcing PSXT to rebuild the AI_liveries.xml, all the DA40s were represented by that model, however no change was observed in circuit flying. The DA40s that were on touch & go still did not take off and completed the entire circuit at ground level, despite RT showing their correct altitude, speed and (sometimes questionable) VS. I also noticed that for the very few instances, they seem not to become airborne at the correct runway point (that RT showed they were lifting off) but instead PSXT had them use the entire runway length PLUS more length extending into the field before takeoff. The same happens for the aircraft that are actually airborne, on final PSXT has them touch down way before the runway, and yet RT seems to show the correct touchdown location. For the record, I am using AUSCENE YPPF third party airport scenery. I have a livery for the FTA DA40s that uses Asobo's DA40 model. So, thinking that perhaps the FSLTL_HTAI_P28A_ZZZZ model performance config was a mismatch for the DA40's, I experimented by putting in the FTA DA40 livery into community, and modifying my regcode text file for the DA40 reg codes, forced PSXT to use the FTA DA40 livery/Asobo DA40 model. There was no change to the problems with the aircraft flying circuits. No matter if I used the Asobo DA40 model, or the FSLTL_HTAI_P28A_ZZZZ, neither model in PSXT flew or matched the positional information that RT was providing. (By the way, having all those DA40s depicted with the Asobo model, also didnt appear to cause me to loose any FPS.). So, in summary, even after forcing PSXT to use the simple FSLTL_HTAI_P28A_ZZZZ model, GA aircraft flying circuits dont seem to depict the real life A/C height from RT. The reason I'm so keen for this to work, is using RT & PSXT I can simulate what it was like to try to fly with upwards of 5-6 other aircraft in the circuit at one time when I was flying there (ex student of FTA). Therefore its important that the aircraft fly the patterns exactly matching the data coming from RT, and, if possible be the same size/shape as the real aircraft, and it having to use Asobo's DA40 model for DA40 traffic ends up with too much of a FPS hit, then having the much simpler FSLTL_HTAI_P28A_ZZZZ model is better than nothing. By the way, as a sub-note, Asobo have a number of 'generic' models that they can use when showing other live users. asobo-aircraft-generic-piston-multiengines,asobo-aircraft-generic-piston-singleengine etc. I thought these might be useful simple models to depict GA aircraft where there is no FSLTL or AIGAIM models to match. The aircraft.cfg probably doesnt contain the info that PSXT might be expecting, but I wonder if there might be some way for PSXT to make use of those simple generic models that Asobo provide, to increase/bolster the number and types of generic models that could be used with PSXT and MSFS. Regards David

DA40's

Hi, I seem to be having issues with GA aircraft flying circuits at an airfield used by a large flight school. The GA aircraft never seem to actually leave the ground and continue to trace the circuit pattern all at ground level. I have RealTraffic radar showing, as well as LittleNavMap so I can compare the data between what RT believes is the aircraft speed, heading and height, and what PSXT is injecting into MSFS (using LMP and clicking on the simulated GA aircraft to view what PSXT is setting for speed, height etc. RT definitely shows the aircraft climbing to a cct height of 1000 ft, and yet the PSXT aircraft shows it never leaves the ground. Any ideas why the PSXT GA aircraft might not be flying at the correct height that RT is showing it at? For reference, the airport is YPPF, and the UTC date is Dec 16 @ 0100 UTC and thereafter. Regards

Hi, Would it be possible to add these ICAO special aircraft designators please https://www.icao.int/publications/DOC8643/Pages/SpecialDesignators.aspx Many thanks

Many thanks

Hi, The ICAO type might not be valid, BUT, it is the code that Asobo are using in their DG100 aircraft as part of their base package. As this is found in the official MSFS install directory (under OneStore), and will get updated/overwritten by Asobo for any new MSFS releases, I really dont think anyone should be editing/changing any of Asobo's default aircraft config files! Is it possible that you might be able to code some sort of workaround to cater to default Asobo aircraft that might not meet exact ICAO codes? I'm sure this wont be the last time that Asobo release default aircraft with incorrect ICAO codes and fixing/changing official MSFS files is probably not a good idea. Regards David

Hi, Would it be possible to update PSXT and supporting data files, so that the new default Asobo Gliders are automatically detected as compatible Glider models that PSXT can use? I'm guessing that Asobo's atc_type value for their default gliders isnt matching what PSXT might be looking for? For the DG100, Asobo have used atc_model="DG 1001 e Neo" icao_model="DG1001eNeo" icao_type_designator=DGF and for the LS8 they have atc_model="LS8_18" icao_model="MXS-R" icao_type_designator = "MXS" Regards David

Blingthinger, please, just give it a rest! If I remove/ignore all of your comments/replies in this discussion, then it becomes an interesting, enjoyable read. Add all of your comments back in and it turns into a toxic rant against the product, its developers, and users who enjoy the product. For the record, I like reading your comments over on the XPlane forum, when you discuss technical issues/topics, without any sly reference to competing sims. You clearly have a lot of technical knowledge and expertise, but it quickly turns into a depressing spiral of spiteful vitriol when you get started on slinging fud/mud at other sims, their developers and their users. I feel you have a lot of knowledge and wisdom to give in these forums, but please stick to technical discussions without the snide comments/shading against other sims.

I'm not in the beta and I got this update today. A date check against folders in Official\OneStore directory seems to indicate that contents in workingtitle-instruments-gns might have been updated.

Hi, I've configured the installer as per level7's link, and I'm currently testing this version on a 6hr flight (was previously on Experimental version). First indications were that the performance has improved, enough that I was able to depart from Gaya's LOWW without it being a total stuttering mess (performance still isn't great at LOWW but I believe that is probably a problem with Gaya's airport). At cruise FPS seem to have improved as well. I'm locked to 30fps on very modest hardware (8700k@5G, 1080Ti) and whilst its not welded to 30fps, the drops below 30fps (2fps) are no where near as great a drop than compared to non-V2 version (anywhere up to 6fps). For me, ND-V2 has made using FBW320 much more enjoyable so far.

🙂 Many Thanks!!!!!

How/where? I tried doing searches in Discord for any info, and couldnt find anyhting relevant.

FSDT GSX - Own goal? I'm a long time user of GSX in P3D, and was looking forward to the release for MSFS. Sadly, I see that FSDT have caused the same major headaches for customers with this version, repeating EXACTLY the same problems that drove some P3D customers crazy on multiple occasions - and its do to do with installation/updates. I can understand the reason behind using CloudFlare to assist in distributing installation packages around the world. However, just like with numerous major updates with the P3D version, customers were getting faults/failures with this installation, simply because not all of the updated GSX files had synced across all the content servers. I was hoping that FSDT would have duplicated the required files and installed in a special MSFS directory, so that previous P3D versions did not impact the MSFS version (if the full MSFS version had not been fully rolled out yet). Secondly, I was hoping that FSDT would have come up with a better release/trigger to allow, say 2 days for ALL of the update code to be replicated over the content servers BEFORE making the update package available to new customers. Instead, because of the same problems with content not fully replicated, many users have ended up with a 'bad taste' from GSX, having just purchased it and it not working at all for 1 or more days (due to content servers still not fully refreshed. Had a better release mechanism been used, at least there would have been far less unhappy customers, in that at least a full correct version would have been installed first time around. It would have vastly reduced the number of issues/complaints on the FSDT forum as well! As it stands now, here in the Antipodes, I still cant have my P3D and MSFS versions installed without the MSFS failing to start. I know FSDT will eventually sort out new installers for P3D version, and the content servers will eventually have the right files for a full and complete install, but its a headache that has happened before and could have been prevented for this important and iconic release. I'm glad I bought GSX for MSFS and it will just get better and better as time goes on, as FSDT are very prod and enthusiastic for their product (and so they should be).

Another tip would be that prior to running ProTAC for the first time, download the latest Navigraph dataset for ProATCX and install the updated Navigraph data into the dataimport directory. ProATC SR comes with a default Navigraph data set from 2017, in case users dont have their own subscription. The Navigraph data set is read in, in conjunction with your default sim runway data and Community scenery (collected by makerwys)

I would add that anyone who uses MSFS Addon Linker, and who only enables a hand full of airports they are flying to at any one time, are best to enable ALL airports and scenery via AddOn Linker PRIOR to starting PATC for the first time, and anytime you want to re-run makerwys. Once makerwys has completed, then you can go back in Addon Linker and disable all but the few airports/sceneries you might be using for that session. Otherwise you will have to rerun makerwys and reimport into ProATC everytimew you change your linked sceneries.

Ive also tried to duplicate a networked setup (as Im currently running with P3D & PATC), and no matter what I have tried, PATCSR will not accept any type of mapped or URL type reference to MSFS installed on my FS PC (which is sharing out disk access, which I know works with P3D & PATCX). I know that I need to run mkrunways (which Ive done), So I was thinking that a 'dummy' directory on the local networked ATC PC might be enough, but I cant work out what files/folders PATCSR is looking for in the 'MSFS install directory) to be satisfied with a 'dummy' location. UPDATE: Ive "fixed" the network install "MSFS path" issue by directly editing the file proatc.xml file in the networked ATC install directory for proatcSR, and manually edited the <options><app><fspath> value to point to my network share where the AppData,LocalCache,LocalState,RoamingState etc directories are located for MSFS. After editing this and starting PATCSR, I was able to import the outputted data from makerunways (which I had to run locally on the FS PC, and then copy results over to the makerunways directory on the networked ATC PC).

Once I finally get my key and download link from Pointsoft, Ill install and probably post my thoughts in the 'first impressions' thread, rather than here. I own Pilot2ATC, FS HUD, and now PROATCSR for MSFS. I purchased each of these (in order shown above) to improve on the default ATC, as well as getting close to the ATC experience I am used to in P3D (with PROATCX). I purchased FS HUD, because I wasnt quite happy with aspects of Pilot2ATC. I purchased PROATCSR because of prior knowledge of the product (in P3D) but also, because there are aspects of FS HUD that I'm not quite happy with. It may take me a few days to really dig into PROATCSR to know what has carried over from the P3D versions (that are appropriate in MSFS), and is lacking (due to differences between P3D and MSFS), Then I hope to be able to write up a summary of positive and negative aspects of each of the products.

As a long time user of Pro ATC X, I just purchased this version for MSFS. Sadly, I have not received my email containing my lic key or download links. Ive checked my SCAM/Junk folders just to make sure the confirmation email hasnt been moved there. I got confirmation from PayPal to indicate the transaction went through. I can only guess that perhaps their store system is under heavy load, after 30 mins I still havent received my license key/download link yet.

thanks