[AdmiralTigerclaw]

Originally Posted by arkhangelsk

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.

I understand it perfectly. I'm also discarding it on purpose to push towards compiling all data into one large set to cover all situations seen. In this case, apply calculations from scenario B to Scenario A and compare with the Scenario A calculations to see the differences. Then do the reverse for Scenario B.
You don't look at the tactical map to understand the strategic situation. Does that make sense?

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?

Never said it wasn't, it's just needlessly increasing the complications to do so until we've got a full data collection to work with. I want to see what the full ranges of different situations come out with using cross refferenced data sets comes to.

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

I may not be an expert, but I'm not exactly stupid, and knowing why having the attack AND the target in the same depth plane works better. (And why having both attacks in the same frame helps confirm that you are looking directly on profile and confirming it is indeed, same plane.) It means simply that the target object size can be used in direct refference to the attack size, and how far that attack would move in relation to its own size and the target. It's not rocket science. Though you type it out as such...

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).

Do you want me to break out Adobe Premier and get you every frame you need?
I can probably get that one shot...

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.

Sure it can.

It's called 'bullshitting'. I for one, think 'more accurate and consistent' bullshit beats out 'random' bullshit any time of the day.
We have scarce data that is consistent. Where it would be consistent, it's seperated by situation. If there is matching information, such as attack types matching up for the same character, it would be prudent to use that data, and then extrapolate variances rather than sitting around going 'We can't do that!'


It may have its flaws, but it would be consistent and set the line. And the only ones who can go and finger wag at us would be either someone who breaks their own back to calc and recalc this mess, or someone from the actual production staff somewhere who gives official numbers.

Otherwise, we'll have a scene like with the Airport Fire, where Nanoha fires a beam big enough to blow a hole in the top of the airport SO LARGE that her body is pretty small compared to the hole. The same beam which outstrips that size in length alone, and travels its length in under a second. Calc THAT range and velocity. Go ahead, wave the estimated perspective flag at it, see what you get. Compared to any calcs we have here. Traveling a haindwaivium estimated 200 meters or more in a second already blows everything we've done here out of the water like a SUBROC nuclear depth charge to a German WWII Era U-Boat. (Everything we've calced comes to below 100 m/s.)

Actually...


DO IT. I mean it. Calc that shot if you can figure out a way. I want to see what kind of velocity and range that shot has compared to everything else.

You'll want SS episode 1 from 4:29 to 4:36 I don't exactly know how you'll estimate the shot, since everything is shown in perspective. (Must be when 7arcs had the financing to put on the best graphics editing.)

At least, let's get everything cross refferenced to build a full image of speeds and ranges based on the different calculations. More data is BETTER.