I am back with another analysis; this time about the discrepancy of gas mining rates from different geyser positions. The phenomenon itself was described years ago in detail in Orek's excellent post. However, as far as I know, there has not been an explanation for that. My goal was to find one.
Basically the phenomenon is that some vespene geyser positions generate more income than others, even if symmetry would suggest that it is impossible. I recommend that if you should not be familiar with it, do read Orek's post, because it really covers everything you need to know about it.
The main idea is that the difference, that is, one gas position generating more income than another when they should yield the same, can come from the following reasons:
The workers spend less time inside the gas in some cases.
They spend less time travelling because they have to travel a shorter distance in some cases.
They spend less time travelling because they travel faster in some cases.
All three possibilities seem to be impossible; the first and third for obvious reasons, the second because of symmetry. One of them still has to be the case, though.
To find out which one, I used the Editor once again, as in my previous experiment. Having compared two gas locations that should generate the same income but don't in fact, it turns out that workers always spend exactly 2 gs inside the gas building, and they travel the same distance approximately. In fact sometimes they travel a longer distance in shorter time to one geyser than to the other one. This only leaves one possibility for the reason of this phenomenon, namely that units' movement properties depend on the angle they are facing. That's right, a worker, and any other unit as well, moves faster in certain directions than in others, regarding both maximum speed and acceleration.This is very bad.
For detailed calculations and explanation, here is my usual pdf, and also in the spoiler tag below:
Experiments show that units generally move and accelerate fastest around 225° and slowest around 45°. This seems to be the reason for the mining discrepancy between different gas positions. I have no idea why this happens, though. I, personally, was very surprised to find this, so I wonder what you think about it. Also, any suggestions, criticism and ideas are appreciated .
So we can safely infer on cross spawns one player will always get scouted first even both players send unit at exact same time from exact same distance from the other player.
The jackpot question is I guess, then, should we rotate the map to the direction such that our scv can move more quickly to the gas geysers.
Also if the acceleration and the max velocity are all sinusoidal functions, should that not mean there is a optimum direction (namely, at 225 degrees as defined in your article) that the mineral patch should face relative to the CC?
EDIT: I was always under the impression that overlords travelling southwest were faster. I thought it was only my imagination, but there seems to be truth to it. So my question is: do all units have the same absolute speed-increase when travelling south-west or is it relative to their actual moving speed?
On February 21 2015 09:49 timchen1017 wrote: The jackpot question is I guess, then, should we rotate the map to the direction such that our scv can move more quickly to the gas geysers.
Also if the acceleration and the max velocity are all sinusoidal functions, should that not mean there is a optimum direction (namely, at 225 degrees as defined in your article) that the mineral patch should face relative to the CC?
Or we could just get blizzard to like maybe fix their game >.>? This seems like the most reasonable expectations we can have as a group of players who populate a forum of a game that has been made into an eSport. ... :/
This thing has actually always bothered me tbh. I remember on some of the WoL maps not only were the gas distances further but then you also had the angle. It's easy to understand in retrospect how this is even worse than we even originally thought, but man, I really wish they'd do something about this.
On a random side note: the zergling pushing units is back in the game if your unit is attacking instead of hold position even if the pixel area it occupies is the same size as the unit trying to move past it. AKA by walking into units they can change other units positions even if the space they're trying to move past is the same size as them. It makes no sense >.>
How can stuff like this continue to exist? They're pretty huge bugs...
On February 21 2015 09:49 timchen1017 wrote: The jackpot question is I guess, then, should we rotate the map to the direction such that our scv can move more quickly to the gas geysers.
Also if the acceleration and the max velocity are all sinusoidal functions, should that not mean there is a optimum direction (namely, at 225 degrees as defined in your article) that the mineral patch should face relative to the CC?
Or we could just get blizzard to like maybe fix their game >.>? This seems like the most reasonable expectations we can have as a group of players who populate a forum of a game that has been made into an eSport. ... :/
This thing has actually always bothered me tbh. I remember on some of the WoL maps not only were the gas distances further but then you also had the angle. It's easy to understand in retrospect how this is even worse than we even originally thought, but man, I really wish they'd do something about this.
On a random side note: the zergling pushing units is back in the game if your unit is attacking instead of hold position even if the pixel area it occupies is the same size as the unit trying to move past it. AKA by walking into units they can change other units positions even if the space they're trying to move past is the same size as them. It makes no sense >.>
How can stuff like this continue to exist? They're pretty huge bugs...
It's worth noting that the BW engine had the same property and it was much more apparent there, which allowed for some strange micro interactions.... that being said, it would be probably nice to fix it. (actually, it's a very strange coincidence, is there perhaps a technical reason behind it?) Anyways thanks for shedding some light on this mistery!
This is very well done. I am surprised that this is the case, that things accelerate faster in different directions. It seems obvious that this would be true of the other units as well. Did you test this with any other unit?
Oh wow the very small differences in unit speeds based on the angle you are moving at is incredibly obvious when actively showing a units move speed. Nice find!!!
edit: I think this is probably going to be most significant for situations where moving just a littttttle bit faster than another unit matters. Think chase scenarios, especially where you only need 1-2 more hits to kill. And obviously where the verrryyyy small difference in speed adds up over a long period of time (mining).
[*]They spend more time travelling because they have to travel a shorter distance. [*]They spend more time travelling because they travel faster in some cases.
How would it take more time to travel shorter distance when moving faster??? It feels like an hypothesis made AFTER the research was concluded.
But yeah the fact unit pathing and movement is radian dependant isn't new in a video game. It's a propriety of nearly all pathing that it will favor one side over the other, maybe in this case the engine only refreshes one direction before the other in a cyclic way. Or it may simply be rounding "error" with either the sin/cos functions or the vector additions.
But out of curiousity, wouldn't it mean minimg imbalance of mineral too in diferent patches disposition/orientation? Can you also test few military units (spine crawler, marine, slow/speedling, mamacore, medevac) to see if the acceleration difference is consistant there too?
Anyway thank man for the !!science!!.
*If I may suggest for table 2 to use the same ammount of precision on all values of Total T (add the missing 0s).
On February 21 2015 13:35 decemberscalm wrote: Oh wow the very small differences in unit speeds based on the angle you are moving at is incredibly obvious when actively showing a units move speed. Nice find!!!
edit: I think this is probably going to be most significant for situations where moving just a littttttle bit faster than another unit matters. Think chase scenarios, especially where you only need 1-2 more hits to kill. And obviously where the verrryyyy small difference in speed adds up over a long period of time (mining).
Hmm the differences seem very minor. Can't see this having much effect except for mining.
I'll try to have some input on topic: Pathfinding works because each map has a grid: when you go diagonally the numbers fluctuate a bit, because it is no longer a straight number.
For example in Cartesian system (x,y) as (1,0) sets you at UP position and the game calculates
2.25 speed multiplied by 1 = 2.25.
When you go diagonally it sets you somewhere like (0.981211, 0.019121) or whatever, because of the angle and how normalization of vectors works, meaning the game calculates
(2.25 multiplied by 0.981211) + (2.25 x 0.019121)
to move the unit as a player desires. When engine rounds up this number to 2 decimals it will be shown as 2.25, but actually is going to be 2.249452 or alike.
I can be wrong, but at least I'll know why if you explain
On February 21 2015 10:14 linuxguru1 wrote: *mind blown*
EDIT: I was always under the impression that overlords travelling southwest were faster. I thought it was only my imagination, but there seems to be truth to it. So my question is: do all units have the same absolute speed-increase when travelling south-west or is it relative to their actual moving speed?
I don't know this, but I might test it later. I'm guessing they should have the same increase in absolute value, if this phenomenon is caused by some rounding error. At least the amplitude of the regression sine function is very similar for the SCV and the Stalker speed, both about 0.0026...
On February 21 2015 10:54 ZackAttack wrote: This is very well done. I am surprised that this is the case, that things accelerate faster in different directions. It seems obvious that this would be true of the other units as well. Did you test this with any other unit?
I tested only with a Stalker beside the SCV, and it had the same result. (This is only valuable information for the top speed value though, as stalkers accelerate instantly.)
[*]They spend more time travelling because they have to travel a shorter distance. [*]They spend more time travelling because they travel faster in some cases.
How would it take more time to travel shorter distance when moving faster??? It feels like an hypothesis made AFTER the research was concluded.
But yeah the fact unit pathing and movement is radian dependant isn't new in a video game. It's a propriety of nearly all pathing that it will favor one side over the other, maybe in this case the engine only refreshes one direction before the other in a cyclic way. Or it may simply be rounding "error" with either the sin/cos functions or the vector additions.
But out of curiousity, wouldn't it mean minimg imbalance of mineral too in diferent patches disposition/orientation? Can you also test few military units (spine crawler, marine, slow/speedling, mamacore, medevac) to see if the acceleration difference is consistant there too?
Anyway thank man for the !!science!!.
*If I may suggest for table 2 to use the same ammount of precision on all values of Total T (add the missing 0s).
Of course you are right, I meant to write less. I must have already had the result in my head. Corrected! Since minerals are approximately as close as geysers, this should, in fact, mean that mineral mining is imbalanced as well. *As for the table precision, yeah, it was kinda sloppy .
On February 22 2015 02:39 etofok wrote: I'll try to have some input on topic: Pathfinding works because each map has a grid: when you go diagonally the numbers fluctuate a bit, because it is no longer a straight number.
For example in Cartesian system (x,y) as (1,0) sets you at UP position and the game calculates
2.25 speed multiplied by 1 = 2.25.
When you go diagonally it sets you somewhere like (0.981211, 0.019121) or whatever, because of the angle and how normalization of vectors works, meaning the game calculates
(2.25 multiplied by 0.981211) + (2.25 x 0.019121)
to move the unit as a player desires. When engine rounds up this number to 2 decimals it will be shown as 2.25, but actually is going to be 2.249452 or alike.
I can be wrong, but at least I'll know why if you explain
That video is quite interesting. While I am no expert of this topic, I believe this problem does not have much to do with pathfinding itself, rather it could be the result of rounding, as you also suggested.
I didn't really read your post because im not one to complain about balance even if there is scientific evidence behind it. You would probably do good in some sort of job involving economics, especially if you enjoy doing things like this with your free time. ^^
On February 22 2015 03:57 life617 wrote: I didn't really read your post because im not one to complain about balance even if there is scientific evidence behind it. You would probably do good in some sort of job involving economics, especially if you enjoy doing things like this with your free time. ^^
It wasn't meant to be a complaint, just some surprising facts. And, unfortunately, I'm really not interested in economics.
I would be honest right here... that guy did an incredible job with his research... but everyone look into yourself and ask yourself "did you ever notice it?" nope... do you press your upgrades right after they finished not when 8x3 drones mines 16 gas more? nope.. Your opponens lings were in position in 0.0250 faster... there is no way this is noticable in probler 1v1 ladder game !
But still good job if they fix it they will do it in LoTV because this is engine issue
On February 22 2015 06:09 PharaphobiaSC2 wrote: I would be honest right here... that guy did an incredible job with his research... but everyone look into yourself and ask yourself "did you ever notice it?" nope... do you press your upgrades right after they finished not when 8x3 drones mines 16 gas more? nope.. Your opponens lings were in position in 0.0250 faster... there is no way this is noticable in probler 1v1 ladder game !
But still good job if they fix it they will do it in LoTV because this is engine issue
Well, people did notice the difference it causes in mining rates years ago, so I wouldn't say this is entirely true. I agree, though, that other than that, it can't be noticed anywhere.
In warcraft 2 towers used to fire from the top left hex within them, so that they had longer range north than they did south. It could be similar to that with refineries.
On February 22 2015 02:39 etofok wrote: I'll try to have some input on topic: Pathfinding works because each map has a grid: when you go diagonally the numbers fluctuate a bit, because it is no longer a straight number.
For example in Cartesian system (x,y) as (1,0) sets you at UP position and the game calculates
2.25 speed multiplied by 1 = 2.25.
When you go diagonally it sets you somewhere like (0.981211, 0.019121) or whatever, because of the angle and how normalization of vectors works, meaning the game calculates
(2.25 multiplied by 0.981211) + (2.25 x 0.019121)
to move the unit as a player desires. When engine rounds up this number to 2 decimals it will be shown as 2.25, but actually is going to be 2.249452 or alike.
I can be wrong, but at least I'll know why if you explain
Yeah and since each unit is a singularity in the coordinate system, this zick-zack effect in diagonal movements - similar to graphics when using anti-aliasing - is impossible to get rid of. So even if this is at a very small scale in sc2 which allows for this very fluid movement, it´s probably to be accounted for that blizzard has not included seperate factors to ensure movementspeeds are as wanted through small acceleration boosts.
On February 22 2015 02:39 etofok wrote: I'll try to have some input on topic: Pathfinding works because each map has a grid: when you go diagonally the numbers fluctuate a bit, because it is no longer a straight number.
For example in Cartesian system (x,y) as (1,0) sets you at UP position and the game calculates
2.25 speed multiplied by 1 = 2.25.
When you go diagonally it sets you somewhere like (0.981211, 0.019121) or whatever, because of the angle and how normalization of vectors works, meaning the game calculates
(2.25 multiplied by 0.981211) + (2.25 x 0.019121)
to move the unit as a player desires. When engine rounds up this number to 2 decimals it will be shown as 2.25, but actually is going to be 2.249452 or alike.
I can be wrong, but at least I'll know why if you explain
I agree with your interpretation. I literally just wrote A* for a game in Unreal Engine 4 last week, and you need to realize that the units need to have their position in a grid. You simply cannot escape small fluctutations
1) does the direction the scv face when starting influence the acceleration?
2) as you track every tick, what part of the accelerating is faster? Is it a boost at the very start, or uniformly faster acceleration over the first second?
3) the scv goes back and fourth to the gas, and it seems like the sum of the trip would be constant with a sin dependence. Fastest there would mean slowest back. Doesn't the scv accelerate in both directions during a trip?
4) the difference for 1000 acceleration is ridiculously small. Are you sure it is still not related to acceleration? It would be interesting to see more acceleration values, and how the sine amplitude depends on it. Also, could you try with 10 second travel instead of one, to get the speed. You wouldn't need to try all 360 degrees, just 4 directions would be plenty.
5) can you confirm the acceleration hypothesis from the tick-by-tick data of the mining? Take a cycle and plot the total distance traveled against time for the two gas positions. That would clearly show which of the three possibilities explain the difference.
On March 02 2015 22:36 Cascade wrote: Nice! Some questions:
1) does the direction the scv face when starting influence the acceleration?
2) as you track every tick, what part of the accelerating is faster? Is it a boost at the very start, or uniformly faster acceleration over the first second?
3) the scv goes back and fourth to the gas, and it seems like the sum of the trip would be constant with a sin dependence. Fastest there would mean slowest back. Doesn't the scv accelerate in both directions during a trip?
4) the difference for 1000 acceleration is ridiculously small. Are you sure it is still not related to acceleration? It would be interesting to see more acceleration values, and how the sine amplitude depends on it. Also, could you try with 10 second travel instead of one, to get the speed. You wouldn't need to try all 360 degrees, just 4 directions would be plenty.
5) can you confirm the acceleration hypothesis from the tick-by-tick data of the mining? Take a cycle and plot the total distance traveled against time for the two gas positions. That would clearly show which of the three possibilities explain the difference.
Good job, cheers.
I will try to answer these questions as best as I can
1) In the tests I always made the SCV face the direction it was supposed to move in before ordering it to move. This way it didn't have to turn; always moved in one direction. If it changes direction before accelerating to maximum speed, I assume it will continue accelerating with a different acceleration.
2) There is always a sudden boost at the very beginning of the movement. See here, on Page 3, Figure 3, the yellow graph. The value of that boost is hard to say, because it rather seems to be a simple boost to position (like a tiny teleportation), rather than acceleration. It is possible that this value is also greater in diffrerent directions. Other than that, yes, the acceleration values themselves, at every tick, are uniformly greater in certain directions than in others.
3) That's true, the sum of the accelerations back and forth would be constant in every direction with the sine dependance. However, the time it takes to complete the trip wouldn't. Consider you have to travel 1 m with 2 m/s and then back 1 m with 2 m/s again. This would take t = 1/2 + 1/2 = 1 s in total. Now if you have to travel with 1 m/s there and 3 m/s back, it takes t = 1/1 + 1/3 = 1.333 s, not 1 s, although the sum of the speed values was the same in both cases. Similarly with acceleration, but a bit more complicated (squares in the formulae and stuff). The point is, even though the sum of the accelerations there and back is constant, the time to go there and back will change (I hope I was clear enough). On the other hand, the function is obviously not a sine function; there are quite big fluctuations in it, so it can lead to even greater differences.
4) With an acceleration of 1000, the SCV should be at its maximum speed immediately. So the only way acceleration can factor in is through the sudden boost at the beginning, which might be different at different angles.
5) Yes, I can. In fact, that is exactly what I did. Workers always spend 32 ticks (2 gs) in the Refinery, so that can't be the source of the difference. Also, in one particular case that I observed, the SCV travelled slightly more in slightly less time than in the other direction. This leaves only the possibility of the SCV moving faster in certain directions than in others.
I hope I managed to answer your questions. If you are still interested, I can share the test map I used, so you can try these for yourself.
On March 02 2015 22:36 Cascade wrote: Nice! Some questions:
1) does the direction the scv face when starting influence the acceleration?
2) as you track every tick, what part of the accelerating is faster? Is it a boost at the very start, or uniformly faster acceleration over the first second?
3) the scv goes back and fourth to the gas, and it seems like the sum of the trip would be constant with a sin dependence. Fastest there would mean slowest back. Doesn't the scv accelerate in both directions during a trip?
4) the difference for 1000 acceleration is ridiculously small. Are you sure it is still not related to acceleration? It would be interesting to see more acceleration values, and how the sine amplitude depends on it. Also, could you try with 10 second travel instead of one, to get the speed. You wouldn't need to try all 360 degrees, just 4 directions would be plenty.
5) can you confirm the acceleration hypothesis from the tick-by-tick data of the mining? Take a cycle and plot the total distance traveled against time for the two gas positions. That would clearly show which of the three possibilities explain the difference.
Good job, cheers.
I will try to answer these questions as best as I can
1) In the tests I always made the SCV face the direction it was supposed to move in before ordering it to move. This way it didn't have to turn; always moved in one direction. If it changes direction before accelerating to maximum speed, I assume it will continue accelerating with a different acceleration.
2) There is always a sudden boost at the very beginning of the movement. See here, on Page 3, Figure 3, the yellow graph. The value of that boost is hard to say, because it rather seems to be a simple boost to position (like a tiny teleportation), rather than acceleration. It is possible that this value is also greater in diffrerent directions. Other than that, yes, the acceleration values themselves, at every tick, are uniformly greater in certain directions than in others.
3) That's true, the sum of the accelerations back and forth would be constant in every direction with the sine dependance. However, the time it takes to complete the trip wouldn't. Consider you have to travel 1 m with 2 m/s and then back 1 m with 2 m/s again. This would take t = 1/2 + 1/2 = 1 s in total. Now if you have to travel with 1 m/s there and 3 m/s back, it takes t = 1/1 + 1/3 = 1.333 s, not 1 s, although the sum of the speed values was the same in both cases. Similarly with acceleration, but a bit more complicated (squares in the formulae and stuff). The point is, even though the sum of the accelerations there and back is constant, the time to go there and back will change (I hope I was clear enough). On the other hand, the function is obviously not a sine function; there are quite big fluctuations in it, so it can lead to even greater differences.
4) With an acceleration of 1000, the SCV should be at its maximum speed immediately. So the only way acceleration can factor in is through the sudden boost at the beginning, which might be different at different angles.
5) Yes, I can. In fact, that is exactly what I did. Workers always spend 32 ticks (2 gs) in the Refinery, so that can't be the source of the difference. Also, in one particular case that I observed, the SCV travelled slightly more in slightly less time than in the other direction. This leaves only the possibility of the SCV moving faster in certain directions than in others.
I hope I managed to answer your questions. If you are still interested, I can share the test map I used, so you can try these for yourself.
Thanks!
Regarding 3, the effect you refer to exists, but is second order, in the sense that small changes in speed/acceleration will give a small^2 contribution to the travel time. Your difference in travel time the first second is around 4%, meaning that the expected total difference in time in a cycle will of the order 4%^2 which is nowhere enough to explain the difference in mining rate you see. Increase in speed and acceleration should give the same effect on mining time, as distance traveled is linear with both.
All in all, I don't think excluding other possibilities and then assuming the last one is the reason is enough. Specially when the last one also doesn't show nearly enough difference to explain the mining rate. If acceleration is indeed the difference, it should be easy for you to directly observe it with your data, which would give a much better case for your point.
On March 02 2015 22:36 Cascade wrote: Nice! Some questions:
1) does the direction the scv face when starting influence the acceleration?
2) as you track every tick, what part of the accelerating is faster? Is it a boost at the very start, or uniformly faster acceleration over the first second?
3) the scv goes back and fourth to the gas, and it seems like the sum of the trip would be constant with a sin dependence. Fastest there would mean slowest back. Doesn't the scv accelerate in both directions during a trip?
4) the difference for 1000 acceleration is ridiculously small. Are you sure it is still not related to acceleration? It would be interesting to see more acceleration values, and how the sine amplitude depends on it. Also, could you try with 10 second travel instead of one, to get the speed. You wouldn't need to try all 360 degrees, just 4 directions would be plenty.
5) can you confirm the acceleration hypothesis from the tick-by-tick data of the mining? Take a cycle and plot the total distance traveled against time for the two gas positions. That would clearly show which of the three possibilities explain the difference.
Good job, cheers.
I will try to answer these questions as best as I can
1) In the tests I always made the SCV face the direction it was supposed to move in before ordering it to move. This way it didn't have to turn; always moved in one direction. If it changes direction before accelerating to maximum speed, I assume it will continue accelerating with a different acceleration.
2) There is always a sudden boost at the very beginning of the movement. See here, on Page 3, Figure 3, the yellow graph. The value of that boost is hard to say, because it rather seems to be a simple boost to position (like a tiny teleportation), rather than acceleration. It is possible that this value is also greater in diffrerent directions. Other than that, yes, the acceleration values themselves, at every tick, are uniformly greater in certain directions than in others.
3) That's true, the sum of the accelerations back and forth would be constant in every direction with the sine dependance. However, the time it takes to complete the trip wouldn't. Consider you have to travel 1 m with 2 m/s and then back 1 m with 2 m/s again. This would take t = 1/2 + 1/2 = 1 s in total. Now if you have to travel with 1 m/s there and 3 m/s back, it takes t = 1/1 + 1/3 = 1.333 s, not 1 s, although the sum of the speed values was the same in both cases. Similarly with acceleration, but a bit more complicated (squares in the formulae and stuff). The point is, even though the sum of the accelerations there and back is constant, the time to go there and back will change (I hope I was clear enough). On the other hand, the function is obviously not a sine function; there are quite big fluctuations in it, so it can lead to even greater differences.
4) With an acceleration of 1000, the SCV should be at its maximum speed immediately. So the only way acceleration can factor in is through the sudden boost at the beginning, which might be different at different angles.
5) Yes, I can. In fact, that is exactly what I did. Workers always spend 32 ticks (2 gs) in the Refinery, so that can't be the source of the difference. Also, in one particular case that I observed, the SCV travelled slightly more in slightly less time than in the other direction. This leaves only the possibility of the SCV moving faster in certain directions than in others.
I hope I managed to answer your questions. If you are still interested, I can share the test map I used, so you can try these for yourself.
Thanks!
Regarding 3, the effect you refer to exists, but is second order, in the sense that small changes in speed/acceleration will give a small^2 contribution to the travel time. Your difference in travel time the first second is around 4%, meaning that the expected total difference in time in a cycle will of the order 4%^2 which is nowhere enough to explain the difference in mining rate you see. Increase in speed and acceleration should give the same effect on mining time, as distance traveled is linear with both.
All in all, I don't think excluding other possibilities and then assuming the last one is the reason is enough. Specially when the last one also doesn't show nearly enough difference to explain the mining rate. If acceleration is indeed the difference, it should be easy for you to directly observe it with your data, which would give a much better case for your point.
For the reasons I already mentioned, the only possible reason is that the SCV moves faster in certain directions. This is pure logic, there can't be any other case. The thing is, I assumed moving faster means greater max. velocity or acceleration, as these are the parameters that should describe the unit's movement. This also assumes the basic laws of physics are true. However, as you point out, the difference in acceleration does not seem great enough to cause a difference that great in travelling time/distance travelled in given time. In fact, I did try to calculate back the acceleration values from the measured distance values, and those seemed to be very different in different situations, confirming the suspicion that much greater differences in acceleration values would be required to cause this phenomenon (I can approximately determine the acceleration from the tick-by-tick coordinates). This leads me to believe that the SCV does not follow move with a constant acceleration, as it should, but rather starts with a boost, as I already said. How great this boost is may also depend on the angle of the unit, and this, combined with the difference in speed and acceleration (which do exist, that is fact) may cause the difference in travelling time/distance travelled in given time. To sum up, excluding other possibilities and then assuming the last one is the reason is enough, if you consider all possibilities, which I might not have.
Yes. You thought you has excluded all other possibilities, yet your experiments didn't show the expected difference in the last factor.
What you SHOULD do at that point is to realise that you must have missed something somewhere, not publish your results as if the last experiment had confirmed your hypothesis.
But I'm overly critical, sorry. I can't expect scientific rigour on a gaming forum. Great work collecting data anyway!
EPT![[image loading]](http://i.imgur.com/TIMZtHv.jpg)
![[image loading]](http://i.imgur.com/l0KMIj3.jpg)
![[image loading]](http://i.imgur.com/nBvY3ZE.jpg)
![[image loading]](http://i.imgur.com/AJCoCwJ.jpg)
![[image loading]](http://i.imgur.com/crNxeiY.jpg)
![[image loading]](http://i.imgur.com/wTwopNt.jpg)
![[image loading]](http://i.imgur.com/p81j9Av.jpg)
.
