[arkhangelsk]

Originally Posted by AdmiralTigerclaw

I simply applied a quick average from there.
67.035

Either tell me I'm right, or tell me I'm wrong, but don't do both, that's just irritating.

What part of "improper data fusing" do you not get. You do not take the shot velocity of Scenario B (SS Ep12) and assume it applies to Scenario A (A's Ep7), unless you have no data for Scenario A and must extrapolate based on Scenario B data. If observation taken directly from Scenario A contradicts your guess based on Scenario B, then the extrapolation is simply wrong.

Now, since we know the exact flight time of Vita Shot, I'll apply your range calculation to that.
If I knock a second off the flight time for Vita Shot to account for potential overlaps at firing and impact, her distance is still 268 meters out. Based on the average of the range of speed you calculated. And the low end of your calculation puts her at 201 meters. According to what you said earlier. Stadia ranging puts her at 122, nearly half the distance at the low end of the speed calc. either the Stadia ranging is innaccurate because we're assuming Lenses, or we're getting some serious bullet-timing in somewhere, and nobody's telling Morpheus about it. (That, or by some really freaky coincidence, magic has a flare for dramatic timing and pulls back on the speed just before impact to give vita the 'OH SHI-' moment she got.)

The far end of stadia ranging puts her at 122m. Here are some other possibilities - the round in Ep7 flew somewhat slower than the round in SS Ep12. Why is this simple alternative not even a candidate?

So we need to decide if you want to use the half-guesses on perspective/forced perspective and focal lengths, or go with the 'far more reliable' calculations you've done.

Hopefully, you aren't just quoting me, but fully understand why "in plane" is an ideal situation.

The in-plane situation is indeed ideal for distance scaling (one dimension of the velocity scaling problem), but the situation as a whole is not really as reliable for velocity scaling due to the low number of total data points and the horrible time resolution (the other dimension) of lazily-drawn anime. The bolt froze for 32702 and 32703 and moved for 32705 (for some reason, it proved impossible to get a cap of 32704, so for all I know 32704 would have been the same as 32703 as well - which turns it into a 3 stop-1 move situation. Come to think of it, even if 32704 = 32705, it would be a 2 stop-1 move-1 stop situation, with the beam traveling that 16x pixel distance over 4 frames - darn it, maybe I made an error, will have to think on this one...). On 32706, the two beams start to interfere with each other (the explosion begins before the two beams actually collide), thus invalidating the calculation. But what happened in 32701. It was a white frame, but if it wasn't, what would it have depicted? Would it have depicted the beam at a different (farther away) location, thus providing an addition data point to refine the speed, or would it have been the same as 32702 and 32703, thus expanding the timeframe of movement from 1/10 to 1/7.5 second with consequences of slowing down the beam. (The same could actually be said of 32700, but to convention, it is improper to freeze positions more than 3 frames in a row so as to maintain the animation effect, so one assumes it would have shown the beam in a different position).

But even given a reliable velocity estimate, it does not cover using the reliability of using said velocity to calculate range based on TV=R in situations where cut scenes are rampant, and an unknown number of seconds are cut out or repeated with each cut scene.