This is written for JaFF, so I'm going to spare the background, elaboration and explanation needed for most people to understand what I'm talking about.

Inverted locations:
Left: 0
Top: 0
Right: map width
Bottom: n

Will be refereed to as y_n.

Up and Down refer to the size of the unit according to DatEdit.

Function previous (c):
Center y_n around the location that was centered around the unit c cycles ago.
Select the y_n with largest value n that contains the unit.
Return the n of that location.

That is a function that you can actually call in starcraft to gather information. Now the question is how do those functions work numerically. The answer is:

Input in this is the number of pixels the unit has moved since c cycles ago. It's actually a signed integer, with negative values being up and positive value being down.


Using previous(1), previous(2) and the value of previous(1) the one cycle ago, Lethal was able to gather the three values necessary to do his map. I use the same data.

a is return value of previous(1)
b is the return value of previous(2)
c is the return value of previous(1) last cycle

Now I convert it into a numerical relation:

Alpha is the signed pixels that the unit has moved since last cycle.
Beta is the signed pixels that the unit has moved since two cycles ago.
Beta - alpha is the distance the unit has moved between last cycle and two cycles ago.



Now I can finally state the problem. Given up, down, a, b and c, we want to find alpha, which will give us the magnitude of movement. To see if the direction has been changed we need to find beta, and then if alpha is positive, the unit has changed direction if beta is less than alpha, and if alpha is negative, the unit has changed direction if beta is greater than alpha.

Now if X was a one to one function this would be easy. We would just call inverse_X on a and b. However it isn't. So what we do is we call inverse_X on a, b and c to get a1, a2, b1, b2, c1, c2. Then we brute force it:


Now lets take a unit, with up 14 down 10. It's location one tick ago was 4 pixels upwards from its current location. It's location two ticks ago was 8 pixels upwards from its current location. -8 - -4 = -4.
alpha = -4
beta = -8

a = X(-4) = 20
b = X(-8) = 12
c = X(-8 - -4) = 20

If you invert those you get:


Because only the first one is true, we know from the values of a, b and c, the values of alpha and beta. We can then use alpha and beta to detect the pixel coordinates.

Now the question is, will there always only be one true combination? If the answer is yes than we can build a generalized pixel perfect coordinate detection system.

EDIT:


Post has been edited 2 time(s), last time on Nov 13 2009, 12:14 am by scwizard.

It's 1am for me, I'll read through later. Thanks for posting. This is, by the way, for everyone who saw Lethal's map, not just for me.

Err, I'd say it's more for the people who understand how Lethal's map works.

Although realistically, given the (non existent) amount of explanation I attacked to the OP, I'm not expecting anyone to understand this who doesn't:
1. Understand how Lethal's map works
2. Understand why Lethal's map would not work if the ghost was replaced with a dark templar
3. Have a bit of programing language experience

Eh, what map? Link please!

Got intrigued.
What I don't understand clearly is the problem itself. What does one want to achieve with the method proposed?
Is the goal to keep track of the exact pixel coordinates of a single given unit in two given DCs?

Haven't tried to understand yet but Dark Templar is a "bad" unit with shifted middle, bet that is the problem.

Few questions.
We're talking about the middle of the unit. DatEdit states ghost is 10px up and 11px down from the middle. Is the height of the ghost rectangle 19, 20 or 21 pixels? (Guess 19, right?) Given the even height of the unit (location) rectangle 2h, what of the following is considered the middle: h or h+1? (Guess h, right?) Am I right that the unit is inside of the location when (UnitTop <= LocBot) & (UnitBot => LocTop) & (the same for Left-Right)? (What I am not sure about is the strictness of the inequalities.)

Edit: I bullshit-talked ;o

Post has been edited 1 time(s), last time on Nov 14 2009, 8:41 pm by payne.

Nvm guys, actually it turned out I've seen the map (and as far as I remember it is you payne who have shown it).
Just haven't recognized.

After reading over it a second time, I managed to understand it visually, but not mathematically. >_< Have you spoken to Lethal/Kaias abut it yet?

Then you have the opposite problem that I do. I understand it mathematically but not visually >_<

Understanding it mathematically is all I need to implement it though. I know how to collect the input, and what algorithm to run on it to generate the output. I'll post the full algorithm in a bit.

Here's the full algorithm.

I hope everyone here likes Python, because I do: http://codepad.org/2q8pIXVR

Yes, the problem with Lethals pixel perfect detection is that it doesn't work for bad units. My method however works for all units.

Yeah, when a location centers around a unit, it centers around the "middle" of the unit (the problem is that that is not always the middle!)

Man, if they want to know about the latest in UMS theory, they should come to the UMS forums. I have no reason to hunt them down.

That being said, it looks like Kias at least wants to know about the latest in UMS theory (he's reading the topic).

EDIT: Or not

I'm going to implement this over Christmas break by the way. Wish me luck

Post has been edited 8 time(s), last time on Nov 16 2009, 12:43 am by scwizard.

I have 2, and 3, but I haven't ever bothered with anyone to ask exactly how 1 works, mainly because I didn't want to beg anyone to explain it to me. The first thing I did was look at the map, and I noticed how his locations and units were set up. Then I quickly scanned his triggers and came to the conclusion that in order for me to understand how what he made actually works, I would need to see a theoretical explanation and not the triggers themselves.

So could anyone give a quick rundown of exactly how his map works? I haven't seen any posts about how it works already.

[Edit]Never mind, ignore this post.

Post has been edited 2 time(s), last time on Nov 16 2009, 7:14 am by CecilSunkure.

Wrong map; this is the one he's talking about
I can explain Elementa, though, if you're interested.

Attachments:

Oooh, well now I feel sheepish.

I would like to hear an explanation of Elementa, though, I've been interested ever since I saw it.

First he detects if you unit has moved.

If the unit has moved he runs all this stuff:
He centers the "stripy" inverted x and y locations around the spot where the unit was one tick ago.

He uses them to determine how many pixels the unit has moved since the last tick. If the unit still exists at y1, then it's moved one pixel up/down. If the unit doesn't exist at y01, but exists at y02, then it's moved two pixels up/down etc. He stores this value in "deathcount 1"

To determine direction he takes another two values. How many pixels the unit has moved since two ticks ago ("deathcount 2", and the value of "deathcount 1" last tick ("deathcount 3").

Now if the unit has moved without changing direction, then the number of pixels it moved the previous tick ("deathcount 3") added to the number of pixels it moved this tick ("deathcount 1") should equal the number of pixels the unit has moved since two ticks ago ("deathcount 2").

If this is not true, then the unit must have changed direction.

If the unit changes direction toggle the direction switch.

If the direction switch is in one state, then add "deathcount 1" to minerals/gas. If it's in the other state subtact "deathcount 1" to minerals/gas.

EDIT: Whoops I gave you the non programmers explanation and wasted a lot of my time.

Also what the heck is elementia?

Ok I searched it. What is confusing about how this map works? Seems quite clear to me.

Here's the explanation:
Step 1: Accurate mobile grids
Step 2: Apply basic math to extrapolate the slope
Step 3: Apply accurate mobile grids and basic math along with slope to shoot spells
Step 4: Apply shiny effects
Step 5: PROFIT!

Post has been edited 3 time(s), last time on Nov 16 2009, 7:25 am by scwizard.

I'm sorry about that, I was talking about a different map.

Here, let me guess as to how this works by looking at the map:

This map uses inverted locations to detect pixel coordinates by centering a few inverted locations on a unit, each varying in length by 2 pixels (for a y coordinate detection that would be 1 pixel for both the up and downward direction). However, you don't need to cover the entire map and use a complicated process, you only need to center as many locations as pixels that can possibly be traveled within a single tick.

But I'm still unsure how he detected whether or not the unit moved left or right, and up or down. As in, with what I just described you could detect the absolute value of the change in x and y values, but not in which direction along the x axis or y axis to which the unit moved.

I'll take another look tomorrow, but I really need to go to bed

@Sci
What is confusing about it? Well, all I did was look at the map and skim the triggers, so I have little idea as to how it works without asking anyone anything about the map at all. I also don't have the time to spend "reading" his triggers

I could do step 2-5 on my own, unsure of step 1 though

My previous post explains this in great detail. As well as a not so detailed explanation of elementia.

Well I didn't even do that. I just read people describing the map in the topic. I'll get around to playing it sometime later.

You have the idea but you're completely off with mobile grids. First off, there is no such thing as "Accurate mobile grids"
Even getting mobile grids to displace .25 tiles takes a lot of effort. Mobile grids would also slow the units down and would create massive amounts of lag.

Elementa uses a location grid- essentially it centers locations of increasing increment width on burrowed units aligning the right side of the map so that the 'center' of the location is slid back into the map a specific distance in. He just takes X and Y coordinates, and centers the appropriate location on the appropriate burrowed unit to get a location where it is needed. In Elementa's case, the location grid has a 2 pixel definition (so each location is 4 pixels wider than the last). Here's the wiki article I wrote on it: Location Grids. From the article, Elementa uses a Hybrid Location Grid.

To follow your format:
1. Players' defilers and screens are in two separate locations so that their dark swarms can be differentiated
2. Locations are centered down and across the arenas scanning for the coordinates of the defilers and dark swarms; coordinates are stored in deathcounts
3. Slope is calculated between whichever points are needed (swarm point 1, swarm point 2, defiler, tree, preset offset, etc)
4. Decides where the spell should be based on velocity and time; grid coordinates are produced
5. Grid system places location based on input coordinates on both players' screens/arenas
6. Apply shiny effects
7. Profit

Probably a more in-depth explanation than either of you needed; oh well.

Don't worry, no one is forcing me to read the whole post.

I should have assumed location grid, since that's what Letahal was using for everything at the time, but I thought the map was more 2006/7 for some reason.

Greetings.

Attachments:

This is old. What I'm planning on making is a generalized version of what you have there.

The map you posted is functionally the same as the one that Kaias attached to this post.

That means it has the same problem, that of not working with units who aren't "balanced."

Basically what you have in your map is specialized pixel perfect detection (works with one unit) and what we're discussing here is generalized pixel perfect detection (works with every unit).

Post has been edited 1 time(s), last time on Nov 17 2009, 6:15 am by scwizard.

The up/down/left/right values can easily be changed to accommodate different and/or irregular unit sizes.