Getting Order Coordinates (Air Units), lol math
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 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
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!
This post was edited 3 times, last edit by jjf28: May 23 2012, 1:02 am.
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
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
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.
This post was edited 3 times, last edit by jjf28: Jun 29 2012, 6:10 am.
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.
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
This post was edited 2 times, last edit by jjf28: Jun 30 2012, 6:25 am.
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
0 members in this topic (italic members are currently writing a reply): None
lil-Inferno -- Use a Miracle Berry Fruit Tablet to change the taste of a Miracle Berry Fruit Tablet
lil-Inferno -- Use it on themselves
TF- -- räcräcrä !!
Wing Zero -- Have no idea what to use it on.
Wing Zero -- I actualy bought some of those a while ago but never used it on anything yet.
Wing Zero -- >:3
TF- -- t