Jump to content

Statement about X-Plane Simulation Rate Enforcement


Recommended Posts

Because there's a lot of noise going on about this, I've written an informative article about the decisions and design intent of this feature.

 

Constructive and clarification related discussion only in this thread please.

XSquawkBox - Developer/Maintainer

 

Please post any support related questions to the XSquawkBox support forum rather than private messaging me, thanks.

Link to post
Share on other sites

Hi Chris,

 

thanks for the in-depth explanation. The bottom line is that almost all XP-pilots agree that the FPS problem must be addressed, but as we can see there may be some cases where users are flying with much higher FPS than required and still get warned or even disconnected for short drop of frame rates. Whether this is all legit, I cannot judge.

 

Maybe something interesting to all readers here, one of our ATCOs in Berlin Tegel EDDT has made a video that clearly illustrates the effect of an XP-pilot with low FPS:

Link to post
Share on other sites

I do think there are some flaws in the implementation. I'm posting some screenshots from xpilot, but I'm told by Justin that his code was copied line for line from yours, so I presume the implementation should be the same.

 

Your blog post mentions that after 1 minute of acceptable frame rates, the warning countdown timer should be reset. In the attached image, however, I got the warning countdown, followed by the "your frames are healthy" message. Then 4 and 1/2 minutes later there was another FPS dip and I was disconnected immediately. It doesn't seem to me like the clock resets as you claim. Later, again, there is a period of a minute and a half between warning countdown messages. Based on your blog post that last warning countdown should have started fresh.

 

EDIT to add the relevant p[Mod - Happy Thoughts]age:

To make sure this remains fair, if the frame-rate is consistently good for a certain period (presently 60 seconds), we can treat any other failures previously in the session as transient, and we reset the slow-time pool back to 0.

 

https://i.imgur.com/y2DBJtO.jpg

Edited by Guest

Cheers,

-R.

fvJfs7z.png

Link to post
Share on other sites
I do think there are some flaws in the implementation. I'm posting some screenshots from xpilot, but I'm told by Justin that his code was copied line for line from yours, so I presume the implementation should be the same.

 

Your blog post mentions that after 1 minute of acceptable frame rates, the warning countdown timer should be reset. In the attached image, however, I got the warning countdown, followed by the "your frames are healthy" message. Then 4 and 1/2 minutes later there was another FPS dip and I was disconnected immediately. It doesn't seem to me like the clock resets as you claim. Later, again, there is a period of a minute and a half between warning countdown messages. Based on your blog post that last warning countdown should have started fresh.

 

EDIT to add the relevant p[Mod - Happy Thoughts]age:

To make sure this remains fair, if the frame-rate is consistently good for a certain period (presently 60 seconds), we can treat any other failures previously in the session as transient, and we reset the slow-time pool back to 0.

 

https://i.imgur.com/y2DBJtO.jpg

 

I did a review yesterday and confirmed the behaviour of the timers were correct, there's a bug in the warning code where it doesn't display a warning after a reset until you've burnt off more "slow" time than you have previously. Justin has the fix for that already, and it'll be in the next XSB build/release.

XSquawkBox - Developer/Maintainer

 

Please post any support related questions to the XSquawkBox support forum rather than private messaging me, thanks.

Link to post
Share on other sites
To make sure this remains fair, if the frame-rate is consistently good for a certain period (presently 60 seconds), we can treat any other failures previously in the session as transient, and we reset the slow-time pool back to 0.
In the attached image, however, I got the warning countdown, followed by the "your frames are healthy" message. Then 4 and 1/2 minutes later there was another FPS dip and I was disconnected immediately. It doesn't seem to me like the clock resets as you claim.
there's a bug in the warning code where it doesn't display a warning after a reset until you've burnt off more "slow" time than you have previously. Justin has the fix for that already, and it'll be in the next XSB build/release.

AHA. Right -- I can see where that would still fit the behavior I was seeing; the clock was indeed resetting but the warning messages were stifled by the logic. Good deal; thanks for looking into it.

Cheers,

-R.

fvJfs7z.png

Link to post
Share on other sites

As an experienced programmer (30+ years), my gut feeling is that sampling the frame rate is the wrong way to go about this.

 

We don't actually care all that much about the client's frame rate - I can fly at 8 fps with flightgear, and the ATCO won't even notice a difference, it just makes the aircraft more difficult to handle for me as a pilot. That's because flightgear took a different approach to dealing with insufficient system resources: instead of slowing everything down, it keeps the FDM running at full speed and only slows down rendering. So when I'm running at 8 fps, the FDM still gets 120 updates per second, there's just going to be 15 of them per rendered frame.

 

What we do care about is that when the simulator says your speed is 120 kts, then you should be covering 2 miles per minute according to the VATSIM network. Since position data is uncontroversial, the difference is due to in-sim clock vs. VATSIM clock (which in turn should be identical to real-world clock). So a better approach would be to either detect in-sim clock drift (comparing RTC elapsed time since startup against in-sim time since startup), or to detect deviations in ground speed as reported in-sim vs. as seen on the network.

 

This approach has several advantages:

 

1. It measures what we actually care about.

2. It doesn't require frequent sampling: just getting the current position and ground speed once every 5 seconds or so, figuring out the ground track distance, and checking whether the effective speed is within limits of the reported speed. No averaging of frame rates is needed, just a bit of an error margin (e.g., at 120 kts groundspeed, you'd expect 2 miles in 1 minute, but 1.98 miles is probably still OK, while 0.95 miles is definitely not).

3. It's future proof and relatively sim-agnostic - a client like Swift could easily implement this for all supported simulators. This would detect not just automatic time scaling like XPlane does, but also deliberate or accidental meddling with the time factor, pausing, and other anomalities. And if XPlane decides to make the time scaling thing optional via a configuration switch or something, then users solving the problem this way will not be punished for a crime they didn't commit.

23.png
Link to post
Share on other sites

What we do care about is that when the simulator says your speed is 120 kts, then you should be covering 2 miles per minute according to the VATSIM network.

 

Be careful of how you redefine the problem. That's not what we actually care about.

 

What we care about is that, barring explicit user action, ....

 

Please read CoC B9 which is the main counterforce against doing nothing.

 

We do not accept that misconfiguration is explicit user action, nor that a user can seek permission for a symptom that they do not know is happening.

 

All of your fixes break explicit user action.

 

We are not about to implement ways for time dilation to occur "with permission" because the feature will just be abused so it can be ignored, just as people dismiss the XP11 warning without consideration. I'm not about to go out of my way to break other legitimate actions though.

XSquawkBox - Developer/Maintainer

 

Please post any support related questions to the XSquawkBox support forum rather than private messaging me, thanks.

Link to post
Share on other sites

I think you misunderstood. I'm not saying time dilation should be allowed on the network. Not at all. If a client turns out to dilate time, then disconnecting them is the right thing to do. A client that does this is broken, and it is the user's responsibility to fix it.

 

All I'm saying is that "FPS" is a bad metric for this, and we should be measuring actual time dilation instead.

23.png
Link to post
Share on other sites

All I'm saying is that "FPS" is a bad metric for this, and we should be measuring actual time dilation instead.

 

No, you're suggesting metrics enforcement that cannot differentiate explicit action from time dilation. That simply isn't going to work.

XSquawkBox - Developer/Maintainer

 

Please post any support related questions to the XSquawkBox support forum rather than private messaging me, thanks.

Link to post
Share on other sites
What if a bad pool reset never happens because I run in 60seconds allways in one (only one!) slowdown for short time but exceeding the threshold (object reload, clouds...)?

Stefan -- I wouldn't expect an answer if you are truly asking "what if," as in, asking about a hypothetical situation. If you're saying that you ARE getting disconnected unfairly because of this, I recommend you take some screenshots and/or videos illustrating it clearly.

Cheers,

-R.

fvJfs7z.png

Link to post
Share on other sites

HI Robert.

I tested it a bit. I forced my fps to be at 25fps approx, standing at a gate. With this allready critical fps, but totally ok for the network, every switch to desktop (pdf chart scolling..) and back, or view change (shift+5 very evil) will lead to a collected bad timing, and when I do this within 60sec (e.g. every 50seconds only), I never got a pool reset !!! So the algo collects bad timing and never resets. A disco is only a question of time.

Note: tested XPilot! But he claims to use same algo.

btw: does the logic makes sense to throw out people standing on ground (vgnd < X knots?) who prepare their flight working heavily with 3rd party tools and in a fps intense environment?

I´d propose: for every X seconds "clean" fps (e.g. 10sec), reduce bad pool by 1second

Best regards

Link to post
Share on other sites
HI Robert.

I tested it a bit. I forced my fps to be at 25fps approx, standing at a gate. With this allready critical fps, but totally ok for the network, every switch to desktop (pdf chart scolling..) and back, or view change (shift+5 very evil) will lead to a collected bad timing, and when I do this within 60sec (e.g. every 50seconds only), I never got a pool reset !!! So the algo collects bad timing and never resets. A disco is only a question of time.

 

Yes, because your simulator is demonstrating that it cannot consistently keep above the hard 20fps floor. 20fps is not a target average, it's an absolute minimum.

 

The recovery interval is explained in the statement, complete with its current threshold, which you clearly haven't read, otherwise you'd realise that all you've done is prove that it is working precisely as designed.

 

Before you waste everybody's time trying to argue from ignorance, I strongly suggest you carefully read the statement (linked at the start of this thread) and understand precisely what the goals are and what it's doing.

 

If you want to claim that a behaviour is occuring in error, then you need data to show that it's being applied incorrectly. If you're an XSB user, you can refer to my instructions on the known issues page of the website of what you need to report and how to report it.

 

If you want to claim that the methodology is wrong, you need to make sure that your suggestions:

  1. are aligned to the goals and not your personal desires
  2. are achievable without an unreasonable burden on the developers and/or network and it's staff
  3. can be done solely within the client, that is, without changing the protocol or servers or X-Plane itself
  4. are not so slow in responding to legitimate problems that they go undetected until after the user has already created a significant problem.
  5. do not interfere in authorised or permitted use on the network

 

You will also find that my statement covers approaches I considered and dismissed as not reasonable or not achieving our goals. If you want to argue any of those points, please make sure you're approaching it from a legitimately unconsidered aspect, and not just clutching at straws.

XSquawkBox - Developer/Maintainer

 

Please post any support related questions to the XSquawkBox support forum rather than private messaging me, thanks.

Link to post
Share on other sites
Hello,

Question. I am still using version 1.3.3 with no problems. Is it recommended to update to the latest client? I like the idea that if it's not broke, don't fix it. Thank you.

 

Yes. 1.3.3 lacks ACCONFIG support (which provides ground-level correction & aircraft configuration sharing) & lacks native AFV support. The entire XSB 1.x series will stop working on the network once 2.0 is stable. Given that a lot of the issues have been dealt with (although it looks like another macOS build issue has crept in), and the next release after beta5 will be stable, now is a good time to switch.

XSquawkBox - Developer/Maintainer

 

Please post any support related questions to the XSquawkBox support forum rather than private messaging me, thanks.

Link to post
Share on other sites

Yes. 1.3.3 lacks ACCONFIG support (which provides ground-level correction & aircraft configuration sharing) & lacks native AFV support. The entire XSB 1.x series will stop working on the network once 2.0 is stable. Given that a lot of the issues have been dealt with (although it looks like another macOS build issue has crept in), and the next release after beta5 will be stable, now is a good time to switch.

 

 

 

Thanks for the heads up Mr. Collins. Appreciate all the time and effort that you have invested to make this happen!

 

Regards,

Steve B.

Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...