I haven't the discipline to finish this off atm but here's the basics of storing an air units target coordinates for performing actions at said coordinates.



The target x coordinate is practically impossible to obtain from the first address as you need to check within every y-coordinate to get that value; however, it is practical for us to write triggers to obtain the y coordinate simply by brute force.

Target Y coordinate --> counter 1


Next we can obtain the direction, once again by brute force, ground units probably won't work because their direction is effected by terrain, other units, and so fourth, as well as their natural tendency to walk straight up and straight down..

Unit direction --> counter 2

Third, we can by some means obtain the units current position, either by EUDs, or by Exact Coordinate Detection

Unit X coordinate --> counter 3
Unit Y coordinate --> counter 4

now we have:

Target Y coordinate
Unit direction
Unit X coordinate
Unit Y coordinate


lets set this into a picture:



Whoa, it looks like a right triangle has formed!



We can do this math...



B / Sin(b) = A / Sin(a)
B = A * Sin(b) / Sin(a)

but b = 90 - a
so...

B = A * Sin(90 - a) / Sin(a)
B = A * [ Sin(90-a) / Sin(a) ]
B = A * [ Cos(a) / Sin(a) ]
B = A * [ 1 / Tan(a) ]
B = A * 1 / Tan(a)
B = A / Tan(a)

Target X coordinate = B + unit X coordinate

Target X coordinate = A / Tan(a) + unit X coordinate

This is a totally manageable equation, which I estimate will take around 150 triggers to execute (the whole system will, of course, take many more).

If successful, we could quickly obtain the target coordinates of an air unit, we can then create an effect at the location, perhaps a grenade hit or a masser destination, or just a cool graphics effect through the use of Precise Location Placement.

What also springs to mind is creating dreamlike 3rd-person shooters, advanced combat systems, and new selection systems!

Post has been edited 3 time(s), last time on May 23 2012, 1:02 am by jjf28.

Think you made a typo here:


The unit coordinates can also be fixed to make it easier I would think. It's novel, but the discrete nature of the value from which the angle is derived will lead to what I think will be unacceptable inaccuracy through far distances (like 256x256).

Thanks, fixed


(I assume you mean the rotation angle is not very accurate (formal sense)?)

Yeah I imagine this might be a problem, I don't know the specifics of how the value works - only looked at it with a few units & bare clicking

I hope we have enough unique angle values to work with, worse case scenario we have 64 unique values to a 4th of a circle - giving us a max inaccuracy of (90/64x*64 - 90/64*63)/2 = 1.406/2 = .703125 degrees or at the other end of the map, a max of 3.142 tiles (did anyone notice we just about had sqrt 2 and pi? ) -- average of 1.5 tile inaccuracy at that corner, average of .75 tiles for the whole map -- which wouldn't cut it in a lot of cases - if we have more unique angle values to work with then I think this should work smoothly (assuming my assumption noted above is correct!)

What we are given is the Y value of the order coordinate as well as the angle relative to the unit coordinates, which I'll assume to be fixed to the origin in an arbitrary coordinate plane for convenience. In order to find the X value of that order coordinate, it would involve trigonometry which I'll recap for completeness:



If the angle could be any value, then any point on the plane could be represented by those two values (except for when Y=0, where the equation is undefined. This system would not work directly horizontal of the air unit being ordered.).



However the direction is a byte value, therefore having only 256 possible values, and represents a clockwise offset of the unit direction with the value of 0 facing up. It's only reasonable to deduce that each of the 256 values represent linear interpolations of angles ranging a whole circle.



The system loses possible values at points farther away from the origin, as you can visualize there is more concentration of blue near the origin and more white space as the graph goes outward. What this means in terms of the system is that even if the unit is ordered to a white space, the system is going to horizontally truncate it to the nearest blue line, which results in a disparity, or inaccuracy, between the actual and given X values.

But by how much? Is there a systematic way to identify/quantify this inaccuracy?

And this is where I gave up on a formal explanation. Basically, the inaccuracy doesn't depend only on the distance from the origin, but also on the angle itself. As the angle approaches the horizontal axis the system becomes more inaccurate; the limit of the inaccuracy as the angle becomes the horizontal axis is therefore undefined (infinite). As the angle approaches the vertical axis it becomes more accurate, likewise the limit of the inaccuracy as the angle becomes the vertical axis is 0 (think when the unit faces directly up, you know exactly the order coordinates).
Because of this inaccuracy bias, it becomes hard to define an optimal map area (in tiles) that has a maximum inaccuracy of some number.

had some hidden assumptions + an error, I believe they're all demonstrated in this illustration:


calculated left hand-justified limit towards the corner



With a bit of thought prompted by your diagrams and some waiting-room work I came up with optimization for some semi-feasible situations



(fixed at center to take maximum advantage of angle specificity)





(targeter is always mimicing the x-position of the unit with the limited range to take max advantage of angle specificity)



I'm sure equations can be fit to model the inaccuracy; work for later. An individual position's inaccuracy limit can be calculated by taking the absolute value of the mean x value of the two surrounding angles estimation minus the one of said angles' x value - (keeping in mind my assumption that in the system the target-able area is always below the target-er) if my thoughts haven't taken an after-surgery-drug-aided leap

Preview of my upcoming targeting system implementing this math:

Thats crazy! will that work all over the entire map? or more precise in that area?

Yes and no, my intentions are that Navi follows around a separate unit and aims within that unit's range - for those purposes Navi will have consistently high precision about the whole map

For other purposes, see the above convo

Edit:

I think I could get this working across the whole map keeping Navi at a single location with high precision if the player double clicked where he wanted to target.

Edit2:

Next teaser!



Post has been edited 3 time(s), last time on Jun 29 2012, 6:10 am by jjf28.

Sorry to rain on your parade but Lethal and Kaias have done this a while ago.

Exactly this? that would be interesting. As I heard they used two targeting units and used their movement to calculate where to place a unit; would by rule take more than one trigger cycle to have any kind of good accuracy - and would suffer alot of placement problems for large maps unless they also derived a placement system similar to PLP.

iirc they used a single scourge and it looked almost exactly like what you have

That would be rather incredible!

Edit2: After talking/playing with kaias/yoonk it's evidently not the same as old systems generating similar effects, though I did have the privilege of playing one of those maps

Post has been edited 2 time(s), last time on Jun 30 2012, 6:25 am by jjf28.

Yea they used multiple scourges and calculated their path intersection quite accurately.

damnit... I'm pretty sure you just made Metro's combat system obsolete.

Almost, but I think your combat system (if I learned of it correctly) would still be quite useful for single-target weapons - as PLP and this theory have a bit of inaccuracy, a location placed there to damage units would have to be around 8px by 8px to insure that good shots hit the target - meaning it could potentially damage multiple units - if this was a common/sizeable problem, then targetID would be the way to go.

---

Almost done with Navi targeting, just have to finish the new coordinate detection system (to 1px with around 70 trigs, for any ID) to replace the current 2000 triggers that does it to 8px for 1 ID - I'd say 36 hours