There is video proof of the flanker STR comparison. The values in statshark are not reproducible.
I proved WTRTI numbers are much closer to localhost. While statshark are not, simple conclusion really.
The up to 40x more inaccurate was for the F-106 FM at slow speeds that came up in the thread. Its simple math, I calculate the STR with an equation with the localhost values and check which one has more accuracy. Which is WTRTI, of course, often by a huge margin when talking about high AoA situations
Just because statshark doesn’t provide a specific value that another app does is not indicative of inaccuracy.
You were the one who brought it up in that same thread.
Yet those thrust numbers are nearly identical? Why is that? You’d expect something that’s “inaccurate” to be outside the margin of error, yes?
Try to give it a read at least. The reference values are from locahost, which are factually correct.
Again, you providing reference values from local host means nothing when there’s no corresponding statshark values to compare it to. Unless you have both, here, then this is just lip service.
And what’s to say just because WTRTI pulls from local host that statshark doesn’t? Even things like missile data on statshark is pulled right from game numbers.
Thrust numbers are correct, that is simple info you can take from statshark with no issues, at least as far as I have seen. Same with top speeds.
E-M graphs are more complicated and statshark drops the ball. Because of that I avoid using StatShark as a source for anything because it is unreliable.
Again, you keep saying “drop ball” this “Inaccurate” that. No proof = means nothing. If its wrong, point it out where its wrong. Show the wrong E-M graph. Otherwise, don’t bother.
Why you keep saying that while I provided the poof on the other thread with the video methodology and the localhost math?
Localhost is the most accurate way you can take the values, and the STR video is not so bad if you do a bunch of turns and average it out but still has user error with timing the exact frames.
If localhost says 20, WTRTI says 20.1, Statshark says 22. Guess which one is more accurate? That’s essentially it. Its not hard to understand, but I don’t think you even had the trouble to read the thread, and you insist on pushing back for some reason.
All I see is you say statshark shows. You don’t provide a single image of a statshark value. You insist on your math and methodology, but you show one without the other.
Of course I’m not going to believe you when you just say “well my app is more accurate statshark shows this number” and I ask for where you found that number and its deafening silence.
Self citing your own statshark values is not a statshark source. Give me a statshark.net screenshot then I’ll see for myself.
I provided the localhost values, and the result of the STR equations which you can calculate yourself easily. Compare with the values with statshark and they don’t match.
The STR video calculations also match reasonably well (another proof against statshark in the case of the flanker). I didn’t put any screenshot of the WRTRI because even if I did, the value itself would not prove I was doing a consistent turn. That’s why the flanker video instead.
The point was to prove that StatShark is inaccurate against localhost, which I did. In that discussion I wasn’t even leaning on WTRTI values, I was just saying that the values it game me were around 0.1deg/s of difference just for context. It didn’t matter if you believe my WTRTI figures, you can easily check yourself and that is beside the point because WTRTI is essencially just a localhost shortcut.
So again, localhost can differ from statshark by a considerable margin. So Statshark is incorrect. The end. Proof is all there, and very easy to reproduce by yourself.
There you go… Its not that hard since you can open all the graphs yourself for comparison, won’t the actual statshark website be better than a screenshot that I provide myself? Anyway… The F-106 is a good example because the error is gigant.
Try to get a 19deg/s sustained turn at that speed at min fuel, or any other speed for that matter.
Check against localhost which is the best way possible.
Again, saying “its easy” “just compare it”, with no documentation or proof is not evidence. While I can assume and understand some inaccuracies with statshark, if you said something as outrageous as “up to 40x more inaccurate” something that big would leave a trail yes? Where’s the calculation, the documentation, the proof that it’s that inaccurate?
Fair, I did not prove the claim that Statshark can be up to 40x more inaccurate than WTRTI in that case because I just presented the WTRTI values in text, with the reference being the localhost results which is the actual proof to prove statshark is incorrect, which was my point.
“Statshark can be up to 40x more inaccurate, reaching errors of 2 to 4deg/s at SEP=0 line alone.” Was my claim. Was aimed at the f-106 that was among the worst cases I’ve seen in statshark. Because WTRTI had like a 0.1deg/s difference and statshark was around 40x that. But thats just “anedoctal” because I didn’t provide documentation like you said.
This exact point in the graph:
The proof is the STR calculated from localhost, taking the real speed and G load in the instance of the sustained turn, you can calculate the STR, which is what WTRTI does in real time, but with a very small margin of error.
I won’t go record a video and all just to prove that WTRTI has reliably just around 0.1deg/s of error. I don’t care because I was using localhost to prove that statshark is innacurate, and it’s known to be inaccurate. Like the suggestion moderator said, he also said WTRTI is a lot more accurate, if thats enough for you.
I might waste my time proving that another time, but not right now.
AIM-7Fs? Bad?
lol
But yeah, the superior F-15 should be played instead.
