maznaz
Joined: Jan 26, 2004
|
  Posted:
May 18, 2009 - 20:41 |
|
RamonSalazar wrote: | Your wisdom is endless but i wanted to help Kalimar to programming this easily.
Cheers,
RS |
Loath to agree with shadow but the easiest way is using simple grid coordinates and that chart he pasted. No complex calculations required or even desirable. Very impressed with your calculations, nevertheless. |
|
|
Khudzlin
Joined: May 24, 2007
|
  Posted:
May 18, 2009 - 20:44 |
|
so you mean to store a 2-dimensional array with ranges? meh |
|
|
SzieberthAdam
Joined: Aug 31, 2008
|
  Posted:
May 18, 2009 - 20:45 |
|
I hope that my Excel file will be useful for board designers too. It helps to create the proper ruler for any field unit size. For example if you make a smaller, let's say 2cm based pitch, then for the ruler you only need to moltiply the 'Bounds(p)' values by 2 to get the cm values for the bounds. The width or the ruler will be 2p.
Cheers,
RS
Edit: @maznaz: I am not good at programming but i hope that programming an equation with two variables (witch are the horiz and vert distances) and comparing it with 5 constants seems easier than setting the allowed squares one-by-one, make the restrictions for the out-of-the-field area and paralelly placing an 'almost proper' virtual ruler over it. |
_________________
|
|
XZCion
Joined: Jul 05, 2004
|
  Posted:
May 19, 2009 - 04:39 |
|
If you want to calculate the ranges then try using a simpler method for the calc's:
Let length of square edge = 1 unit
From there the width of the ruler is 1.6 units. The length of the ruler is 13.6 units, etc.
Then if you're still very keen on finding out 'real world' measurements for a ruler just multiply your numbers, which once determined are static for all board sizes, by the actual size of the board squares, in whichever actual length unit you prefer: cm, in or pixels.
Also note that this allows for a simple vector scaling of a ruler graphic to be placed onto the pitch, and that while the chart may be quite easy to read for humans, imagine the intercept allowed charts that would also have to exist for each square you wish to throw to.
*editted for correctness |
Last edited by XZCion on %b %19, %2009 - %06:%May; edited 1 time in total |
|
XZCion
Joined: Jul 05, 2004
|
  Posted:
May 19, 2009 - 06:27 |
|
Assuming the regular throwing range chart is TRUE then Khudzlin's numbers for the cutoffs in squares are correct. Also if the same formulae are used for a hand off it gives 2.3 squares. (Not that it really helps since a Hand Off is a seperate action to a Pass)
Unfortunately using a mid-point to mid-point method would allow incorrect squares to be allowed.
The accurate calculation therefore has to take into account the full size of the square:
R = sqrt (x^2 + y^2) + sqrt (2) * cos (pi/4 - atan (x/y))
With ranges as given by Khudzlin; 4, 7.5, 10.8, 13.6 |
|
|
Khudzlin
Joined: May 24, 2007
|
  Posted:
May 19, 2009 - 08:24 |
|
i tried midpoint to midpoint first, but found out a few inconsistencies between long bomb and out of range... then i remembered the line about crossing any part of the square and thought of using midpoint (of thrower) to far corner (of receiver), the idea being that if the far corner is in range, then the whole square is
my calculation was d² = (x+0.5)² + (y+0.5)² = x² + y² + x + y + 0.5, the unit being the width/length of a square
the idea of using the squared distances is that nonnegative numbers compare the same way as their squares, and it saves square roots, thus yielding a nice and easy formula without any fancy mathematic functions |
|
|
XZCion
Joined: Jul 05, 2004
|
  Posted:
May 19, 2009 - 08:45 |
|
How are interceptions handled in the current code Kalimar? Is it by overlay and compare, or is there a formula used? |
|
|
maznaz
Joined: Jan 26, 2004
|
  Posted:
May 19, 2009 - 10:37 |
|
RamonSalazar wrote: |
Edit: @maznaz: I am not good at programming but i hope that programming an equation with two variables (witch are the horiz and vert distances) and comparing it with 5 constants seems easier than setting the allowed squares one-by-one, make the restrictions for the out-of-the-field area and paralelly placing an 'almost proper' virtual ruler over it. |
I have no idea how the client is coded, but I would have assumed there was already an in memory grid corresponding to the squares of the pitch. It would be quite simple to just use simple calculations to decide if a target square falls within any particular range. In all honest though, what matters is the implementation, and whichever the developer feels can be most clearly expressed in code (and thus giving less chance to introduce bugs, either at first or when modifications happen at a later date) should be used. |
|
|
Khudzlin
Joined: May 24, 2007
|
  Posted:
May 19, 2009 - 12:01 |
|
pass ranges can be easily put in a grid (though they can as easily be calculated), but the conditions for interceptions would require several such grids, depending on the position of the receiver relative to the thrower
for interception, you have that check that
1) the ruler crosses part of the would-be interceptor's square
2) the would-be interceptor has a tackle zone (just a status flag)
3) the interceptor is closer to the thrower than the receiver is
4) the interceptor is closer to the receiver than the thrower is
the last 2 criteria involve calculating distances between squares (i'm assuming center to center distance rather than MA required, but i could be wrong) and the first involves calculating a distance from a line to a square (closest point in the square)
so i think you can't escape distance calculations |
|
|
SzieberthAdam
Joined: Aug 31, 2008
|
  Posted:
May 19, 2009 - 14:29 |
|
XZCion wrote: | R = sqrt (x^2 + y^2) + sqrt (2) * cos (pi/4 - atan (x/y)) |
Excellent approach! The distance is the same as with my method but with a much easier equation!
There is a typo in your eq, you must multiply with Sqrt(2)/2 instead of Sqrt(2). To work it for 360 degress you must calculate Abs(x/y) instead of (x/y), and unfortunately the If-Then cycle for the case if one of the coordinates is zero is also necessary.
Good job!
Khudzlin wrote: | my calculation was d² = (x+0.5)² + (y+0.5)² = x² + y² + x + y + 0.5, the unit being the width/length of a square |
Another good approach:
EDIT There is NO typo in your eq Sorry:)
You can see however that it has a very little distortion. I tested it and it seems so little that it doesnt effect the calculations if there is a tiny modification in the allowed intervals to keep the official rangeset:
Code: | -0,5 1,58113883
3,807886553 4,301162634
7,38241153 7,516648189
10,79351657 10,9772492
13,58307771 13,65650028 |
My points which are keeping the 0.5-0.5-4-4-4-3.125 dimensions(here, Bound(p)-s) are still working with comparing them to these numbers. For the p parameter (which is used to multiply 0.5-0.5-4-4-4-3.125)the allowed interval is (0,86931712;0,874016) thus the allowed interval for 1/p is (1,14414381430088;1,15032820244009). You can notice that 1/1,145 and 1/1,15 is good for using with Khudzlin's equation. The advantage of this equation is that it is extremely simple and there is no need to make If-Then for zero coordinates. The disadvantage is that it uses wrong vector. The difference will grow as Abs(a/b) grow. So i could highly recommend this but only for distance comparision, and using it with a different vector which lies between the two midpoints.
Good job Khudzlin!
Cheers,
RS
EDIT: @Khudzlin: Sorry mate, there is of course no typo in your eq. I ru in through too fast. Was not an offense, of course |
_________________
Last edited by SzieberthAdam on %b %19, %2009 - %15:%May; edited 1 time in total |
|
Khudzlin
Joined: May 24, 2007
|
  Posted:
May 19, 2009 - 15:11 |
|
RamonSalazar wrote: | There is a typo in your eq too:
d² = (x+0.5)² + (y+0.5)² = x² + y² + 2 x + 2 y + 0.5 |
hmm, (x + 0.5)² = x² + 0.5x + 0.5x + 0.25 = x² + x + 0.25 and similarly for y
the only distortion i introduce is by not taking the width of the ruler into account -- though you're going to orient it in the most favourable way, so that probably doesn't amount to much |
|
|
SzieberthAdam
Joined: Aug 31, 2008
|
  Posted:
May 19, 2009 - 16:30 |
|
@Khudzlin: Sorry it was my fault, your equation has no typo in it of course.
The two mesures define a triangle (if a not= b), and your equation gives the hypotenuse of it which must be longer than the two other sides. So your lenght is longer. I already mentioned that the difference is very little, so it was not an offense. |
_________________
|
|
Khudzlin
Joined: May 24, 2007
|
  Posted:
May 19, 2009 - 17:53 |
|
@RamonSalazar: don't worry, i didn't take it as such, i was just defending my position (and i didn't mean any offence to you either)
my measure is too long in certain cases, such as when the passing axis is close to one of the grid axes -- i'm orienting the ruler from the center of the thrower's square to the far corner of the target square rather than its center (so i'm simplifying at the expense of exactitude)
Edit: you need to take the absolute value of your arc tangent too, though, as you don't know which of a or b is higher (but the angle is always less than 45°) |
|
|
SzieberthAdam
Joined: Aug 31, 2008
|
  Posted:
May 20, 2009 - 19:56 |
|
Calculations on interceptions
Sorry for the design. Using the equation for determining a point's distance from a line we can measure d1, d2, d3 and d4 distances, and the shortest of them should be less than the half of the ruler width which is 'p' in my equation because the ruler is 2 inches width = 2*p units width, so the half of it is 1*p unit.
For interception, you have that check that
1) the ruler crosses part of the would-be interceptor's square --> dmin<p
2) the would-be interceptor has a tackle zone (just a status flag)
3) the interceptor is closer to the thrower than the receiver is --> b<c
4) the interceptor is closer to the receiver than the thrower is --> a<c
I tested it on my Excel file, and it seems working fine:
Its not as hard computing as it seems, my excel compute it for 29x29 squares immediately. Moreover, you only need to check the values for the opponent players which are on the field.
Cheers,
RS |
_________________
|
|
Kalimar
Joined: Sep 22, 2006
|
  Posted:
May 21, 2009 - 16:46 |
|
Haven't yet reacted to this thread, but simply followed it with awe.
Guys, thanks for all your good work, but I don't think the client will do anything near this complex for passing ranges. The way the ruler works right now is that it draws proper horizontal rectangles that get rotated following the mouse pointer. Ranges are then calculated according to which rectangle touches the player in question.
I could implement a simple table lookup as given in the scanned in picture above (x and y given in squares), but then the ruler ranges as drawn won't match in all cases. Will look into that ...
The new LRB5 interception rules are not implemented yet (as mentioned in another thread). I had simply overlooked them ... |
|
|
|
| |