Clearly, he was expecting Doodle to respond favorably to this:

Quote from Heinermann

What the hell is that? The rest of the explanation is even worse. Also, we don't modify the unit number anymore.
START OVER

It's so constructive, how could Doodle do otherwise?

I'd love to contribute to the Senzine but I'm afraid I am no expert in EUDs. The only one I consider really qualified to write the hearty article EUDs deserves is Heinermann himself. Whether he chooses to or not is really his prerogative, however, write-ups like this tell me that he is certainly capable.

I suppose I should just write an article on something I am an expert on. There isn't any point in waiting for round 2.

Quote from Heinermann

4) The reader doesn't know ANYTHING except for basic english.

that's a bit of a stretch too

Sorry about being rude. I just want SENZine to be of the highest quality.

Alright so what we still need now is:

1. an article about something recent or just unexplored dealing with SC2

2. RE: Raccoon City Classic map article to be finished by Excalibur.

3. A Map of The Week article on a map thats getting the most attention on the public list (phantom/starquest)

4. A Gem article on a map that is good but

5. (optional) An Up & Coming article on Starquest - it's changes, appeal, and what to expect in the future for it.

6. A Starforge: Ultimate announcement article

7. An opening introductory modding article that just talks about what modding is and what is/ins't possible with it (possibly in relation to custom mapping)

That's it. When those are done the first issue can become a reality.

I am planning on writing about SFU, so I will gather up some information and build up an article, I am guessing this will be the feature, seeing as it's pretty much the biggest change in terms of overall Mapping at the moment?

"StarForge: Ultimate, is it too little... Too late?"

Too strong? I was thinking about having that as a first line and making it more appealing as time goes on.

I think it's a little early to start talking like that. I just want to let everyone know about it first. I wouldn't mind seeing that article in issue 2 though.

So for now, priorities?

Quote

1. an article about something recent or just unexplored dealing with SC2

The new Wings of Liberty video? I believe some pretty awesome things were shown in that, namely rising lava/water? I squealed like a little girl in excitement.

Quote

2. RE: Raccoon City Classic map article to be finished by Excalibur.

...Very well.

Quote

3. A Map of The Week article on a map thats getting the most attention on the public list (phantom/starquest)

StarQuest, the b.net-ified AG. So of course it would make MOTW xD

Quote

4. A Gem article on a map that is good but

I believe more people should know about Armored Core, it's really a fantastic game.

Quote

5. (optional) An Up & Coming article on Starquest - it's changes, appeal, and what to expect in the future for it.

StarQuest or Temple Siege for Up & Coming? I believe a MOTW shouldn't double up an issue, but that's up to you.

Quote

6. A Starforge: Ultimate announcement article

I thought this would have made a good Feature, talking about the old Starforge, our good friend Draft and how the tools have evolved over time.

Quote

7. An opening introductory modding article that just talks about what modding is and what is/ins't possible with it (possibly in relation to custom mapping)

Modders, assemble!

Quote from

Quote from

3. A Map of The Week article on a map thats getting the most attention on the public list (phantom/starquest)

StarQuest, the b.net-ified AG. So of course it would make MOTW xD

Alright, well I will start on my end with the 'Feature,' since apparently I stand alone in the department.

If anyone has anything to add onto the subject of how the tools we use in mapping have evolved in the past decade, PM me. I may or may not quote you, depending on if what you have to say is relevant. kthx.

I have a very large article incoming on Location Grids. I built it to be easily transposed into a wiki article, which, unfortunately, sacrifices a lot of emotion and flare. Its not what the doctor ordered, but EUDs don't seem to be getting anywhere. Hopefully you'll have a use for it.

Quote from ClansAreForGays

Quote

I believe more people should know about Armored Core, it's really a fantastic game.

Definitely.

I can't say I'm unbiased here, but there is a certain beauty within the simplicity of that game. It's also withstood the test of time to an extent, as I've been playing it recently.

Quote from Kaias

I have a very large article incoming on Location Grids. I built it to be easily transposed into a wiki article, which, unfortunately, sacrifices a lot of emotion and flare. Its not what the doctor ordered, but EUDs don't seem to be getting anywhere. Hopefully you'll have a use for it.

It's your article - you're certainly welcome to post it both as an article and in the Wiki. In my opinion, it would be better that way. Though it would be more work if you plan to write it in different styles. I can't say if that's worth it for you.

Quote from Mini Moose 2707

Quote from Kaias

I have a very large article incoming on Location Grids. I built it to be easily transposed into a wiki article, which, unfortunately, sacrifices a lot of emotion and flare. Its not what the doctor ordered, but EUDs don't seem to be getting anywhere. Hopefully you'll have a use for it.

It's your article - you're certainly welcome to post it both as an article and in the Wiki. In my opinion, it would be better that way. Though it would be more work if you plan to write it in different styles. I can't say if that's worth it for you.

I wrote it geared towards a wiki article because I couldn't write this thing twice and the wiki is less temporal.

Location Grids
The following article entails an in-depth explanation of the largely obscure Location grids. It is both long and long-winded, but if you stay with me you may end up learning a thing or two. It is my hope that at least someone benefits from this knowledge in furthering his or her understanding of Starcraft and the potential it can have despite its many, many limitations.

Put briefly, a location grid is a type of grid system that can place a location anywhere within where it is built. It utilizes certain Starcraft mechanics in offsetting locations of variable length to create a grid with a built-in resolution and dimensions. In order to understand and create a location grid one should be well versed in starcraft mechanics of location centering, trigger order and unit priority. It is also crucial to understand the concept of centering a location in another- when Starcraft attempts to center a location on a unit in a location and no such unit exists instead it places that location in the center. Whenever a location is centered in another it is implied that it is done by centering on a non existent unit; I like to use map revealers because it is impossible for them to exist inside a location.

How it works
If a location is centered anywhere that would place its borders outside of the map boundaries Starcraft shifts or 'slides' the location back into map boundaries until the location no longer violates the map borders. A location grid merely uses this concept of sliding to get the middle of many location lengths to many specific lengths from the map border.

In the image below, three locations are being centered on a Goliath- one being 5x1 tiles, one 9x1 tiles, another 13x1 tiles- and a Wraith is killed at each. Because the Goliath is too close to the right border, all three locations are being offset a specific distance from the right border of the map. As long as the Goliath is close enough to the border, the locations will Always center that distance from the edge.


Now suppose the objective was to create a Hydralisk a 6 tile distance from the left border of the map. Because units are created in the center of locations, a location twice the desired distance would be required to place the center where it is needed- in this case, a location 12 tiles wide. In the example shot a burrowed lurker is used to hold the vertical coordinate to center the 12x1 location on.


The basic concept of a location grid is to use sets of these locations to center at desired distances both vertically and horizontally. Two main parameters need to be identified in creating any grid:
1. How much area do I want to cover with my location grid?
2. To what definition, or resolution, do I want to make my location grid?

The answer to both questions will be limited by map resources: Locations, space, and units. In case you aren't aware, a Broodwar map has a limit of 255 locations (including the preset location "Anywhere").

Pure Location Grids
Pure location grids use these location sets to center for both X and Y axis offsets. In a pure location grid, the map is divided into 4 equal quadrants and a location placed in each corner.


Lets say our map dimensions are 10x10 tiles and we want a location grid that can place units within a tile definition, or in other words resolution, (in Scmdraft that is equivalent to the normal grid- Hotkey Alt+G; if we wanted a resolution output of 1/2 a tile it would be equivalent to the fine grid- Hotkey Alt+F). Whatever resolution/definition you decide on will determine the length difference between your location grid axis locations. Because it is the center of the location that we want to distance properly, whatever definition we will pick (in this case one tile) will have to be added to either end of each progressively long location to cover the axis. So in the case of the 10x10 dimension map and 1 tile definition, each progressive location will be 2 tiles wider than the last. The image below shows this



The first map in the image shows the locations needed to cover the x axis, spread out to display the difference in distance between their middles- 1 tile, the definition we desired. The second section in the image shows the same for the Y axis and the last shows the same locations stacked and offset from the bottom right corner- covering the bottom right quadrant. The wraith explosions denote the middle of each location, which as you can see, are all 1 tile distant. These axis locations can only cover half the map, thus the need for quadrants.

Now lets actually apply the pure location grid. Say our objective is to create a Goliath at coordinate 7,5 (the point of origin of my coordinates for the rest of the article will be from the top left with values more right being greater positive X and more down being greater positive Y values). Applied to this situation 7,5 means to the right 7 and 5 tiles down from the top. In order to know which quadrant to use we need to see the actual numbers:

In this example, the top right quadrant covers X values 1-5 and Y values 1-5. The top right quadrant covers X values 6-10 and Y values 1-5. The bottom left quadrant covers X values 1-5 and Y values 6-10; the bottom right quadrant covers X values 6-10 and Y values 6-10; this places the desired coordinates 7,5 in the top right quadrant.


This diagram illustrates the actual process in placing the Goliath at coordinates 7,5.
• Location 'x-04' is centered on location 'Top Right'
• General purpose location 'Main' is centered on location 'x-04'
• Location 'y-05' is centered on location 'Main'
• Location 'Main' is centered on location 'y-05'
• A Terran Goliath is created at location 'Main' for red player

How many locations will your location grid take? I've devised a simple equation to help us with that:
[# of locations needed to cover an axis] = ( [Axis length in tile units] / [Desired definition in tile units] ) / 2

Like I said, it's quite simple. This equation is just for one axis, however, and in a pure location grid both the X and Y axises must have location sets. My example plugged into this equation is:
[# of locations needed to cover X axis] = (10 tiles / 1 tiles) / 2 = 5
[# of locations needed to cover Y axis] = (10 tiles / 1 tiles) / 2 = 5

The location total for the entire grid is given by the equation:
[locations for Y axis] + [locations for X axis] + 4 (four corners) + 1 (general purpose) = [Total]

For the example:
5 + 5 + 4 + 1 = 15


Hybrid Location Grids
A Hybrid Location Grid combines the location grid concept and a static grid. Rather than aligning both axises with locations and dividing the map into quadrants, a hybrid grid exchanges one axis of locations and instead aligns that axis with an assortment of units on either side of the map, waiting to be centered on. This method saves an entire axis of locations, allowing for a potentially higher resolution grid; however, for every location saved it requires four units, which, for large maps and high resolutions, can add up unacceptably fast.

For example, in a 256x256 dimension map, it would require all the locations in the map to do a 1 tile definition pure location grid. With a hybrid location grid, you could save half of those locations but use up 512 units; with the extra locations you could double the resolution of the grid to a half tile definition (which would take up 1024 units).

In the hybrid location grid the objective is to create 2 columns (or rows, depending on which axis of locations you're replacing) of unique units on either side of the map. For example purposes I am going to be replacing the Y axis of locations with two columns of burrowed units owned by various neutral players.

The map is now divided into two halves, rather than the four quadrants of the pure location grid. The units allow centering the X locations anywhere within the defined Y axis; the left column allowing you to reach the left side of the map and the right column allowing the right side of the map to be reachable.

Now suppose we wanted to explode a wraith at coordinates 3,9 (using the same reference from before (top left corner being the origin)). First we have to decide which half of the map (and thus which column of units) we need to use. Fortunately, this is much easier to decide than the pure location grid to figure out; for our example 10x10 dimension map X value between 1 and 5 uses the left column and any X value between 6 and 10 uses the right column.

First we center the Y column location on the appropriate set of units (left column in this case). The purpose of the Y column is to center on the correct set of unique units. Then we center the appropriate X location on the appropriate Y holding unit. In this case, the appropriate X location is, of course, x-03 (for 3 tiles to the right) and the appropriate Y unit is a player 9 hunter killer (you can't tell from the image since it happens to be burrowed)

• Location 'Y column' is centered on location 'Top left'
• General purpose location 'Main' is centered on Hunter Killer owned by player 9 at 'Y column'
• Location 'x-03' is centered on location 'Main'
• Location 'Main' is centered on location 'x-03'
• A Terran Wraith is created and killed at location 'Main'

Location shifting
For the cost of one more location, the unit cost of a Hybrid Location Grid can be effectively halved. This is accomplished using the technique location shifting; this wiki article link is provided here. To quote:

"Location shifting is a technique used to shift locations directly to either the left or top side of the map from it's current position. It is done by centering a location twice the width of the map (for left shifting) or twice the height of the map (for top shifting) on the location you wish to shift and then centering that location on the shift location.

When a location is centered beyond the bounds of the map Starcraft 'slides' that location back into the map boundaries. Starcraft first checks if the left and top boundaries are exceeded and then the bottom and right boundaries; because a left shifting location is twice the width of the map it first violates the left border (and is slid back into the map) and then violates the right map boundary (and is then slid back into the map from the right side). This sliding places the middle of the left shifting location directly on the left border of the map."



This idea is important because using it we can remove the entire left column in the hybrid location grid (or, if your axis of units is along the top and bottom you can remove the top row). Rather than accessing the left half of the map through the left column, the left shift location is centered on the appropriate Y unit and the appropriate X location then centered on the left shift location. Here is a depiction of this in action:

• Location 'Y column' is centered on location 'Top right'
• Location 'Main' is centered on Hunter Killer owned by player 9 at 'Y column'
• Location 'Left Shift' is centered on location 'Main'
• Location 'x-03' is centered on location 'Main'
• Location 'Main' is centered on location 'x-03'
• A Terran Wraith is created and killed at location 'Main'

Some call it magic, some call it Hybrid Location Shifting Grid.

Application
The uses of a Location grid are vast as it grants the ability to place a location anywhere within the defined parameters. The disadvantage of locations grids is the obvious large location requirement; of course, if you do have a location grid it is unlikely that you'll need too many other locations.

The map Elementa, by Lethal_Illusion, is the perfect example of the power of location grids. It employs a hybrid location grid with a 2 pixel definition (there are 32 pixels in a tile) covering two 20x12 areas (the size of the screen). By sliding locations across the playing field using the location grid, it can scan the coordinates of two defilers, two dark swarms, order the two different computer defilers to mirror the exact replica location of the players across the two screens and create the effects for each of the player's spells dynamically across the screens. Lethal Illusion uses the player and swarm coordinates retrieved from the location grid coordinates and runs a line calculation which generates a coordinate to place each successive frame of any spell in action. A system takes this coordinate and places a location with the location grid to wherever the input coordinate describes.

In closing
Location grids were first implemented by (U)Bolt_Head and further developed by Fishgold in his work on the map Pointer (v1 and v2). The idea was taken another step forward in the development of Microscan, by Fishgold, which first used the concept of sliding locations across the map to scan the location of a unique unit. Lethal_Illusion further did his part in the modernizing the location grid with the first Hybrid Location Grid. He also made the first pixel definition grid and introduced Location Shifting.

Location grids have come a long way over a very long time. Unfortunately, they don't see the light very often as they are relatively complex. With some luck this article will alleviate some of this.

I'll begin working on chopping it up, and show you what I turned it into. Then you can tell me if it still works.

I'm open to criticism and will deal with it professionally. I'm also a bit unsure of all the 'in closing' history; it'd be helpful if I could get some confirmation on it.

That article is -very- well written. I now understood the single little detail which always made me lead to a fail into applying this theory, thank you!
Just some questions: in your diagram, why is the 'X' at the coordinate (7,4) instead of (7,5)?
Also, you made some little typos right there:

Quote from Kaias' Uber Wiki Article, near the start

[...] versed in starcraft mechanics [...]

Quote from Kaias' Uber Wiki Article, near the end

[...] screens. Lethal Illusion uses the player [...]

I also wondered if you meant an 'at' right there:

Quote from Kaias' Uber Wiki Article, near the middle-start

[...] Hydralisk a 6 tile distance from the left border of the map [...]

... and you've miss-written "SCMDraft":

Quote from Kaias' Uber Wiki Article, near the middle

[...] (in Scmdraft that [...]

Again, very good work over this!
(I'll let you edit your own Wiki Article so I do not mess-up with it and ruin it :S)

P.S. As a last note, shouldn't you use parenthesis to show coordinates?
7,5 -> (7,5)

EDIT: Would my Brush Project (initially made for the SENZine) work? I could make more brushes and edit the actual ones ;o

Quote from payne

That article is -very- well written. I now understood the single little detail which always made me lead to a fail into applying this theory, thank you!
Just some questions: in your diagram, why is the 'X' at the coordinate (7,4) instead of (7,5)?

At Lethal's suggestion I put the X down to denote where the coordinates depict. If I accidentally misplaced the X when I went back and quickly added it, I wouldn't know because I haven't refreshed my cache yet and I still see it without it.
EDIT: I went ahead and fixed it.

Quote from payne

Also, you made some little typos right there:

Quote from Kaias' Uber Wiki Article, near the start

[...] versed in starcraft mechanics [...]

I don't care about Capitalizing Starcraft, if a Chief Editor does, then I'll change it.

Quote from payne

Quote from Kaias' Uber Wiki Article, near the end

[...] screens. Lethal Illusion uses the player [...]

I did that intentionally.

Quote from payne

I also wondered if you meant an 'at' right there:

Quote from Kaias' Uber Wiki Article, near the middle-start

[...] Hydralisk a 6 tile distance from the left border of the map [...]

I don't consider this wrong. Perhaps I should add hyphens to connect it

Quote from payne

... and you've miss-written "SCMDraft":

Quote from Kaias' Uber Wiki Article, near the middle

[...] (in Scmdraft that [...]

I always write it as 'Scmdraft'

Quote from payne

Again, very good work over this!

Thanks

Quote from payne

P.S. As a last note, shouldn't you use parenthesis to show coordinates?
7,5 -> (7,5)

Because I had used parenthesis many times to interject modifications and side-notes I thought it best to not put the coordinate pair in parenthesis- to keep it on the same plane of thought. Technically you're right.

Since Starcraft is an actual title, it should be capitalized. Though that is something the editor(s) can fix, as you point out. I've also seen it typed as StarCraft, and I think if an editor does fix it, there should be some sort of uniformity from now on as to the actual capitalization of the title.

Very good article, by the way.

Everyone else with an article should head on over to the Copy Editing step. I presume CAFG would like to publish someday.