Tim Simpson 1339557

I understand, and agree with the disdain that is being felt about how this was pushed out by VATSIM. For the past decade, if the VATSIM servers caught fire, the BoG wouldn't have acted to put the fire out. Now, they are suddenly shooting from the hip.....LOL. But really, the horse is out of the barn, and there's really no sense in re-hashing the poor roll out. Overall though, I don't get why X-Plane users are upset about the minimum frame rate. I say that, being an XP user myself. If your frames dip, and you get kicked, then just re-connect at your convenience. The BoG said in their

Right. With no crash detection, does it really matter? If two users are landing opposite runways, and p[Mod - Happy Thoughts] through each other, then no harm, no foul. Immersion might suffer a bit, but in the end, it's harmless.

I agree with the option to opt in or out of the automatic disconnect. This is something that should be coordinated between the pilot and ATC, and not at the whim of an algorithm. As consumers these days, it's becoming wearisome to have options taken away, and "features" forced upon us. I'm glad that the pauses and stutters have begun to be addressed, but this forced disconnect issue is a deal breaker for me. It's one more barrier to using the VATSIM network for some folks. Even though xpilot is a nicer, and simpler interface than Swift, I think I will stick with Swift, and watch the

I completely understand that it's a donated side project, and I'm not mocking it. It's just not fair to the controllers during an even to have me pausing in a turn for 5 seconds while they are eeking out every inch of separation during a heavily attended event. When xPilot and the codec matures to the point where the frequency issue is solved, and the stutter/pauses is solved, I will certainly move back to xPilot. Much nicer interface. Very clean and streamlined.

I noticed that myself during a previous FNO. Along with the sutter/pauses that xPilot is causing during events with heavy voice usage, and this sidebar issue, it's clear there is MUCH work to be done with the xPilot client. As a side note, I dumped xPilot for the SWIFT alpha build, and flew into Boston last night. Heavy, heavy traffic. SWIFT did not cause the same issues xPilot is causing, and all worked as advertised. xPilot is a cleaner interface, but I'm sticking to what actually works, vs looks..... Hahahahaha! Lastly, I heard two xplane pilots be queried on frequency about the

There is a "feature" in xPilot that may be the same for XSquawkBox, and might be worth investigating. I've found that you have to have a microphone and a an audio output device hooked up and selected to hear the new codec. So for me, if I want to be receive only, and use my earbuds so's not to wake the family, I still have to plug in a standalone microphone for the audio to be heard.

Not to mention, we are all on the same network servers, so there is no real radar in use. So the "verifying" of the altitude is just part of playing the game, and continuing the immersion. Even if it's off for some reason, it's only electrons on the internet, and no real metal will get bent.

Follow up: Did a couple of test flights in the Oakland and Los Angeles ARTCC's, using all the plugins I normally use. I flew the Zibo and the ToLiss A319. With "normal" traffic levels, and a couple controllers on, there were no X-Plane pauses. Then flew for a bit disconnected from the client offline, with no pauses either. Clearly a client issue, or an overload of the audio server causing an issue with the heavy burden of an event. FYI, the event was the Albuquerque FNO on 11-30-2019.

i7-8700K @3.7GHz RAM 16GB GeForce GTX 1070 Bluebell CSL's Plugins: ASXPConnect Autogate Better Pushback TerrainRadar xPilot X-Plane ATIS switch XPUIPC X-RAAS2 But to re-iterate, I didn't have these issues when using XSQUAWKBOX, only when switching to xPilot. EDIT: It's happening at all stages of the flight. Taxi-TO-enroute-landing-taxi.

I'm at work....I'll answer back when I get home. One thing to note, I'd call the issue a pause, and not a stutter. A stutter is short lived, but motion continues. I'm seeing the sim just stop for 3 to 5 seconds, then start moving again smoothly. I don't see this behavior with low user volumes, like on any non-event flight. Seems like it's either the number of pilots burdening xpilot, or, the number of controller connections that blooms during an event.

This has occurred in the two FNO's I've flown in using xpilot. As the number of pilots on frequency increases, X-Plane starts pausing randomly for 3 to 5 seconds. X-Plane just freezes, and then resumes again after the 3 to 5 seconds has p[Mod - Happy Thoughts]ed. This only happens when I'm logged in with xpilot, and only during high voice volume times during an event. I'll also note that it was two different aircraft (LES SAAB and Rotate MD80). Has anyone else had this happen, or heard of it happening? It's making events not be very fun.

@simon I vote for option two. We already expect ATC and pilots to use current charts/procedures/frequencies for flight when ATC is online. Why not extend that to when the airspace is uncontrolled? I think people are smart enough to figure it out. Heck they figure out the crazy departures and arrivals in Europe, pulling a frequency should be simple, right? LOL. I see your point about simplicity, but it seems at odds with most peoples expectations of simulating real world operations.

I agree with Daniel, that the range should be extended. In the real world, UNICOM can be heard, with frequency overlap for about 50 miles or more, depending on altitude. Ideally the range should be increased dramatically, and the introduction of CTAF's should be expedited as well.

That's good to know. The way that pilots make such a huge deal about the slot sign up day, I thought it was a requirement. It's always fun to hop into a departure airport on the GA ramp, listen to the controllers, and watch the stream of departures on VATTASTIC. I give a lot of credit to the pilots that want to sit in front of their sim for 6 to 7 hours during CTP.

Well, currency, and re-currency requirements are just the tip of the training iceberg. The initial training process is just as flawed. No easy answers, but as often occurs in corporate type settings, arbitrary rules, with no basis in evidence, will often be put in place as feel good measures. The mentality behind them is "it's better to do something, even if it's wrong, than to not do anything at all." Interesting discussion.