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.
Trigger
Players
Conditions
Actions
More Example Triggers
Collapsable Box
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.
TheNitesWhoSay - Clan Aura - github
Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.
Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.