vcaptain747

@Eraneva Do you use a proxy to get to the internet ? or connected to a proxied network (corporate or public) ? Maybe try switching to your cellphone HubSpot internet connection to check if you get different results. In general, Curl SSL Connect error means that the SSL client (PSXT) is not able to verify the server identity due to SSL certificate mismatch. When you use a SSL proxy, than the proxy SSL certificate is presented to PSXT instead of RT server's certificate, causing curl to drop the connection for security reasons. But the error could be also related other things like bad connection, bad DNS,unsupported cipher suites,etc @kiek can you confirm if you're disabling CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST? curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L); curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);

Hi Nico, I have two suggestions that would like to share, nothing outstanding, but I think would be nice to have : Suggestion 1 : Vertical Range This one might reduce the FPS impact of PSXT. This should be particularly useful when plane spotting in an airport with a crowded airspace. Currently, if you increase the traffic injection range, than you might end up with a lot of planes at high altitude that are of no interest when plane spotting, but still causing an FPS overhead on the sim. If you reduce the range , than you lose approaching planes to your airport. So if we could set up an altitude limit (in thousands of feets), than you'll be able to keep low altitude planes (approaching or departing) , while getting rid of traffic of no interest. Suggestion 2: Beacon light before pushback We all know that setting the beacon to ON before pushback is a standard procedure and part of the before start checklist. The idea is to make PSXT set these lights to ON as soon as it detects that an airplane is about to pushback. This should be possible due to the delay between RT data and the injection time. This should help plane spotters identify pushing aircrafts at least 15 and up to 60 seconds before they start pushing (depending on the buffer seconds) Thank you! Amine.

No it does not . On my end, it doesn't seem to be required either. Are these folks using PSXT or something else ?

Each aircraft folder will have a systems.cfg_origbak file . It's the same folder where your systems.cfg is located. You can use the restore button to revert the changes. No manual work is needed. you're welcome 🙂

Hi, for anyone interested in this, I wrote a small tool to make the changes to all systems.cfg files with a click of a button. Just choose your airplanes folder and hit the fix lights button. It will also create backups of your original files in case you want to undo the changes. Thank you @AeroMaster12 for sharing your findings! Cheers, Amine.

I was referring to the snapshot feature that saves the current parking and gates and reload them if a restart is required , so no learner required. The reason I miss it is that it allowed me to place one or more aircrafts exactly where I wanted them to be if I needed to. I fully understand the reasoning behind it 🙂

Hi Abanpuko, You need to tick the flush check box only when you get close to your destination airport and see it loaded as the current airport in PSXTraffic GUI. My understanding is that you won't have all aircrafts that landed during your flight duration, but you will have only the live parked ones. I think that is still possible in PSXT_MSFS since it generates a snapshot (something I really miss in PSXTraffic ) once you get close to your destination. the snapshot is filled with real-world information based on landed and departed aircrafts during your flight time. Hope it helps, Amine.

Thank you Nico. That would solve the first issue at least. Amine.

Hi Nico, I'm experiencing the same behavior at YUL. The Close To Gate (CtG) feature is very useful when coverage is not that great (or pilots turn off the transponder before parking). But I think it might be improved by excluding those aircraft that just pushed back from a gate to prevent these from swinging in and out of the gates (up to 10 times in some cases). Here some suggestions to achieve that: Suggestion1: before activating the CtG on aircraft, check the departure IATA of the aircraft. If it's the same as the current user airport, then leave the aircraft alone even if if it disappears from RT. it sure will show up few seconds later and start taxing . Suggestion 2: Since not all aircrafts have the Departure IATA set at the time of pushback, then maybe you can assign a dummy flight plan at the pushback start where departure is set to the current user airport and destination to something else. Then you apply OPTION 1 to spare it from the CtG. When the real flight data become available, then the orig and dest will get updated with real flight data as usual. Suggestion 3: flag an aircraft as departing if engines change state from off to on. then check the flag before applying CtG. The above suggestions assume that PSXT does not keep track of the different aircrafts states (i.e, parked, pushing back, taxiing, etc..). If it does , then just spare aircrafts with status "pushback" and "Taxi to runway" (or whatever the name is ) from the close to gate. One last suggestion for arriving aircrafts, would it be possible to add a delay before applying CtG . When RT data is poor , I sometimes see arriving aircrafts parking to and pushing back from literally every gate on it's way to it's final gate, emptying all these gates in the process due to collision avoidance feature, and downgrading the immersion level we all used to . Not sure if departing aircraft do the same, but maybe a Destination IATA check can prevent this behavior: if destination == current user IATA, then enable close to gate (after a delay). Cheers, Amine.

That should do it. Thanks! Amine.

Hi Nico, Please reconsider that decision. I find the idea of separating live and static useful. Or as an alternative, add a checkbox to show parked live traffic only if you're going with one percentage. Cheers, Amine.

is PSXT still giving the error after deleting the registry keys? Sinon, tu peux toujours essayer de supprimer ou renommer le "repertoire" dans le registre et voir ce que ca donne. Juste fait un clic droit la-dessus et clique supprimer ou renommer. https://drive.google.com/file/d/1AGI-MJrGa43HaJBWWCAVoekAfEaeGp7X/view?usp=share_link

Yes , that's the one. You can delete it if P3D V4 is not installed on your system.

Hey. Are you looking exactly for string P3DV4 in the registry? if yes, then try prepar3d v4 instead of P3DV4 when searching with regedit.

Oh now I understand. You were wishing to have the smoke effect for AIG models , not FSLTL. Well, glad it worked for you with FSLTL. Can you please share your FX.xml file ? I don't see the effect with the FSLTL injector nor with PSXT. I had to tweak FX.xml file to make them work. Also, are you using the last updated model (v1.2.0) ? The effect looks a little exaggerated indeed. From a distance, you can't tell if it's touchdown effect or the plane is on fire 😄, but at least it's there.

My bad . FX2.xml available here.

I came up with two different approaches to get the smoke effect for FSLTL model that you can test by following these steps: download FX1.xml from here download FX2.xml from here go to <path_to_you_community_folder>\fsltl-traffic-base\ModelBehaviorDefs\FSLTL\Misc Make a backup of the FX.xml file inside the folder. Replace the content of the FX.xml file with the content of FX1.xml and save. Restart the sim if already running. Do your testing and note any observations and noticeable side effects. Next, close MSFS and replace the content of the FX.xml file with the content of FX2.xml and save. Start the sim if already running. Do you testing and note any observations and noticeable side effects. Please share your testing results for FX1 and FX2 once your testing is complete so I can adjust as needed. Cheers, Amine.

I think you missed this sentence in my earlier FSLTL post 😉 . Most FSLTL models have the Reversers animation now. FSLTL added the animations in their last models update released after the OP date, so yes, you should expect reversers animation in FSTLT by setting the negative values, and I confirm it's working on my end (animation & sound).

Good catch 😉 . It did return exception 7 indeed, but I did not give it a second thought since the end result is the same as far as Just flight models are concerned. JF models require only one of the two simvars to be set to 1 to trigger the reverser animation for both engines, but it's better to set both in case other models (existing or future) rely on these for the animation.

You will have to take my word for it, INT32 will not work. I did try it with the code I posted above and it did not work with exception EXCEPTION_INVALID_DATA_SIZE (19) returned , and here is a plausible explanation as to why: The description of the simvar Bool & Boolean units in the documentation is : "The only reliable numeric equivalent is that 0 is returned for False. Non-zero values, especially both 1 and -1, are used to indicate True." This means that any simvar of type Bool can hold negative values, hence cannot be of type SIMCONNECT_DATATYPE_INT32 since we have already settled that simconnect INT32 is unsigned and cannot take negative values. Using INT32 to set a non INT32 simvar won't cut it and causes the EXCEPTION_INVALID_DATA_SIZE (19). INT64 and FLOAT64 did the trick, at least for my test code. Overall, Simconnect INT32 seems to be problematic and I would avoid using it altogethe. Same goes for float32, I did try it on my other projects and caused side effects and unexpected behaviors. I stick to float64 whenver possible as it seems to be the simconnect by default type.

it seems to be working now .. not sure why it did not in the beginning.

Hey Nico. It doesn't look like it's working on my end. Both simvars are being set to 100 for FSLTL models , so no animation there. I thought I might be mixing the old and new 37.0.0 versions at first , but I confirm I'm not.

@pmbThanks for confirming! I might have a working solution to get the smoke effect without the need to make changes to PSXT code. Expect more on that later today. Regards, Amine.

My testing code :

That's another thing with MSFS SDK. I know for a fact ,based on my testing, that a good deal of the supposedly non settable simvars per the SDK are indeed settable. Solution1: use this : SimConnect_AddToDataDefinition(l_hsimconnect, DEFINITION_REVERSE_THRUST, "GENERAL ENG REVERSE THRUST ENGAGED:1 ", "Bool"); SimConnect_AddToDataDefinition(l_hsimconnect, DEFINITION_REVERSE_THRUST, "GENERAL ENG REVERSE THRUST ENGAGED:2 ", "Bool"); and make sure the value you pass in the struct is of type double. Note that if you don't specify a datatype, then float64 is used by default. Solution2: if you insist on specifying the DATATYPE for better memory usage management, then use this: SimConnect_AddToDataDefinition(l_hsimconnect, DEFINITION_REVERSE_THRUST, "GENERAL ENG REVERSE THRUST ENGAGED:1 ", "Bool", SIMCONNECT_DATATYPE_INT64); SimConnect_AddToDataDefinition(l_hsimconnect, DEFINITION_REVERSE_THRUST, "GENERAL ENG REVERSE THRUST ENGAGED:2 ", "Bool", SIMCONNECT_DATATYPE_INT64); and make sure the value you pass in the struct is of type int64_t.