Abstract: This method allows you to place dynamic locations at any desired ultra-fine (as defined in SCMDraft) grid point, by passing in x and y coordinates as death counters. If your x and y coordinates are not multiples of 8, then they will round to the nearest multiple of eight. This method uses partial mobile grids, and thus requires that no air units are in-between the origin and your target location. Extended applications include storing units’ coordinates in death counters via a quick-sort-like algorithm, and custom systems based on knowing the distance between units. In addition to the specific method illustrated, this thread gives the framework for general mathematical movements away from any location.

Recommended pre-readings:
- Death Counters
- Binary Countoffs
- Mobile Grids
- The Offset Glitch
Note that the wiki has a mistake about the offset glitch, subsequent units created at a location will justify to ultra-fine-grid tiles, not fine-grid tiles (shown later).

Limitations:
- Cannot operate near the edge tiles of the map (same as mobile grids)
- Cannot be used in areas in which air units are between your origin and your target
- Cannot (currently) be more accurate than 8 pixels (a tile is 32 pixels, so the accuracy is up to an 1/8th of a tile!)

Requirements:
- 1 dynamic location (for your partial mobile gridding)
- 1 unit or location (to define your origin) or more depending on how many origins you want to use.
- Around 25 triggers depending on how big you want the system to be, and how many static locations you choose to use.
- Zero to (approximately) 64 static locations depending on how CPU intensive you want the system to be. (adding static locations takes away from required computer resources if you're covering a large area, but increases the amount triggers needed).

Procedure

We’ll be using Wraiths, Devourers, Valkyries, Science Vessels, and Hyperion’s in our grids.

If you correct for the offset glitch, and then create a grid of devourers, the devourer directly to the right of the center will be displaced by exactly 48 pixels. Likewise, the bottom devourer will be exactly 48 pixels below the center. I’ve made measurements for other such units as displayed in the table below.



To move your location to the right by one of these distances you select a unit (in this case I chose devourers), create 3 devourers, remove 2 devourers, and center your location on the remaining devourer.

Move right: Create 3, remove 2, center.
Move left: Create 8, center.
Move down: Create 2, center.
Move up: Create 6, center.

Doing the math you can find out how to move any multiple of 8 pixels in any direction. This table displays how to move specific amounts of pixels down and right. Using movement down and to the right is recommended as it requires you to create and destroy less units (lowering the amount/possibility of lag).


Note: you can move the opposite way by doing the exact opposite algorithm! Ex: move left 8 pixels with 1 dev – 1 valk.

Using binary count offs and the above algorithms, you can get to any desired positive (x, y) coordinate within the method limitations (shown at top), and the max area your implementation covers).

In this thread: moving down is positive, moving up is negative; moving right is positive, and moving left is negative (represented in the below graph).



At this point we have enough information to take our passed in death counters [ (x, y) coordinates ] and use binary count offs to get to our desired location.

If your death counter is above the amount a trigger requires, then the trigger would subtract that much, and move that many pixels using the most efficient algorithm possible (shown in the above table).

To figure out how much area your system covers double your largest count-off trigger, and subtract 1. If your system needs to be bigger, then add in a trigger for the next power of 2 (or add a static location… see final considerations).

Your last countoff triggers should be used to round; since the trigger just before it subtracted 8 pixels; your death counter is now between 0 and 7. If you death counter is between 0 and 4 then you’re already where you need to be, if your death counter is between 5 and 7 pixels then you should move 8 pixels.





I’ve implemented a relatively simple example of this in the attachment. In this example, the nuke dot represents your origin [ In the trigger system the first nuke dot is (0,0) ].

You can tell the map where you want the marine to spawn in this trigger!



Extended Applications:

Storing units coordinates in death counters: I’ll finish work on this later, but you can see if a unit is in right half the map, if it isn’t, you know it’s in the left half. You can then check if it is in the bottom half, if it isn’t, you know it’s in the top left quadrant. You can center a new location on half of that area using one of the algorithms, to check if it’s in half of that, and then check half of that, and half of that, and so on till you have its coordinates (you can avoid the rounding limitation by using several extra locations to get it to the dot, but again, this is work for another day).

Knowing the distance between two units: With this system you can determine the exact distance and direction one unit is from another. You make effects happen in the area in-between, around, and so on with this information (ex: some kind of radius spell could be cast, and you could show the concentration of a shock going to and hitting a unit in that radius, regardless of the casting units orientation or movement)

Final Considerations: if we were to use these algorithms to say, go from an origin near the top left of the map to a location near the bottom right, we would be generating an immense amount of lag (in a 256x256 tile map we would have to create and destroy around 240 units and center a location around 400 times) so… we take a shortcut. We center to a static location that is already to the right and down, and subtract the amount of pixels we skipped over from our (x, y) coordinates, this can be done as many times as you can create static locations for, and have the patience to add the triggers for.

Note to readers: I’ll bet some of my English was poor, thanks in advance if you catch something. I also think I may have made some things sound a bit too complicated, shout at me if you can’t understand something, or know how you could simplify something (without losing the accuracy/precision of a statement), or if something is missing. And third, the system hasn’t been perfected, there is obvious room for improvement (ex: move diagonally if you can to save on CPU usage, or use different units/triggers to get closer to the edges) post improvements if you have them.

Attachments:

Post has been edited 18 time(s), last time on Jan 31 2012, 4:16 am by jjf28.

Impressive. Good work.

ty lanth

Fixed up algorithms table, had some older units in there that were not used in map/had been since updated to use units that form perfectly symmetrical mobile grids (overlords were not reversible!)

Question: Would some units take less computer resources to create/remove than others? (often times more than 1 unit would spawn the same distance as others from the grid center).

For anyone helping/doing their own testing, here is a list of (what I'm fairly certain contains) all creatable air units, sorted first by collision box width, then by collision box height. Units with the same widths/heights were collapsed into 1 cell.

Attachments:

Excellent theory. I see this is the next step that mobile grids are to take. Ever since the lurker post I wondered about it, but here you documented it all neatly.

Not to be a downer on this or anything, but this isn't new

It's nice to have it written up though, I guess. This can be used to draw interesting shapes with mobile grids too spell effects get a bit more zing to them.

ty Sac


I would half-expect you to know that of any idea

But more pertinent to your statement, has such an implementation been done before (using binary count-offs + mobile grids to reach desired locations)? Would be nice to include links to such maps here. I’ve seen parts of the idea floating about but never quite this synthesis

Yes, sort of like LIDs, which someone came on and was all like, "HAY THIS ISNT NEW LOLO."

Which is true, I mean it isn't something no one has ever thought of before, but it's something no one has ever fully documented, at least publicly. The entire point behind documenting it is establishing a resource for other people to use and know about. Information doesn't do well if it's floating around, known only to a few experienced mappers.