Staredit Network Wiki - User contributions [en]

User:Roy

2024-07-25T00:07:54Z

Roy: Adding acquisition of Roy@USEast

Roy Gallant is a StarEdit Network community member who serves as a Global Moderator (GM) for the website and Discord server. As a member of the Staff, he is the most recently appointed GM for the site. Roy has contributed to the community in a variety of ways, including submitting maps, utilities, and guides, as well as being a prominent member in the mapmaking assistance and theory forums.

== StarCraft history ==

Roy was born and raised on the West Coast of the United States, where he first discovered StarCraft. He originally used the handle Roy_Gallant and played on the USWest server, where he proceeded to lag significantly due to his dial-up connection and low-spec desktop computer. Due to these economic challenges, Roy could not play online for long periods of time, and his choice of game gravitated toward custom maps under the Use Map Settings (UMS) category. It was there that he discovered a genre of maps that would become his specialty: bounds. He quickly became one of the more prominent bound players in the early scene, joining the National Bounding League (NBL) under the handle NBL)Roy, where he was recognized as one of their top players.

It wasn't long before Roy began looking into creating his own custom maps, which he could create offline when he had no internet availability. His first map, Hunter Bound, was never released. It featured a lot of similar elements to classic oldschool bound maps such as Heaven Bound or Bubble Bound, but the project was abandoned as it did not meet Roy's standards of what a bound should be. While still in NBL, he would release Ovy Bound, which would be one of the most difficult bounds of its time, and it is still considered to be a challenging map to this day.

NBL's members began to dwindle, including the original founder, NBL)Shabutie, leaving the scene. Roy was eventually promoted to co-leader of the National Bounding League, alongside NBL)Brittany. Due to the high recruiting standards of the NBL, it was difficult to find new members on USWest, and as both leaders were opposed to lowering the NBL's standards, Brittany and Roy eventually agreed to disassemble the league.

Roy continued working on his maps independently on USWest under his original handle Roy_Gallant, where his recognition for mapmaking steadily grew and spread across servers. He was eventually recruited into Bound-Making Revolution (BmR) on USEast under the handle BmR-Roy. With an increased focus on mapmaking, Roy would go on to make several maps, focusing more on his content than participating in clan activities. Due to this, he gained the reputation of always being away-from-keyboard (AFK) in the clan channel, and fellow members would joke about Roy being asleep at his desk.

BmR had management issues, and its existence was short-lived, eventually usurped by a faction of members that were dissatisfied with the state of things. The group was recreated under the name realBounders (rB). Roy didn't release any maps under this clan, however. Roy returned to USWest, and his membership in realBounders was more honorary than compulsory. It was there that, in channel Op R3n0, where Roy and a friend were alone talking together, a mysterious third person, QuiK., shows up. QuiK. claimed to have found an exploit that could surreptitiously get him any game handle he wanted. Skeptical, R3n0 asked for the account "Reno", whereas Roy_Gallant asked for the account "Roy". In a matter of minutes, QuiK. came back with both accounts and handed over the passwords to them, no questions asked. As mysteriously as QuiK. appeared, he vanished without a trace, leaving Roy with his new game handle on USWest.

Eventually Roy officially resigned from realBounders and became independent. Roy still visited USEast on occasion, but he didn't have a good game handle. He would play incognito under the handle TehFck, until one of his friends, Technique (a.k.a. Eminent_Soldier), found the person who had the account "Roy" and traded for it, and then gave the account to Roy. Now Roy had the same handle on both USWest and USEast, due to luck and good friends.

Having released many bounds and a few other maps, Roy had made a name for himself on the mapmaking scene. He was approached by xBc Productionz to join the Bound Creators (xBc). Having been burnt out on joining short-lived clans, Roy initially rejected the offer, and would declare himself "clanless" for several years. However, he remained active in the xBc community, alongside Happybikini, Pie (a.k.a. Marth), Valor, Midna, Adzz, and others, and eventually Roy accepted the offer: it would be the last StarCraft clan he would join.

== Mapmaking ==

Roy predominantly played bounds, and consequently made several bounds of his own. As bounds are considered one of the 'simpler' maps to create, other mapmakers would often disparage or underestimate Roy's extensive knowledge of triggers. Roy has been at the forefront of mapping techniques such as the use of deaths as integer variables, grid systems, hyper trigger evolution, and Extended Unit Deaths (EUDs). Roy has also built specialty tools specifically to make mapmaking easier for the community and abroad.

Some of the bounds Roy has created include:
* 4 Hour Bound
* Bloodshot Bound
* Bloodshot Bound 2
* Dargon Bound
* Fire Emblem Bound
* Hamsper Bound
* Jihad Barbie Bound
* NuBs Bound
* Oblivion Bound
* Ovy Bound
* PGCC Bound
* Quaint Bound
* Radiant Dawn Bound
* Six Way Bound
* Suneric Bound
* Symmetrical Bound
* The Sims Bound
* Utopian Bound
* Viva La Bound
* When Anothing Bound
* WoW Bound
* Wow Bound 2

Roy was additionally fascinated by an extremely niche bound-adjacent genre: auto-scrollers. These maps feature a locked screen that moves, and players must safely navigate their unit through obstacles while staying on the screen to survive. There were very few of these maps that existed: ''Yoshi's Bound'' by MNeox, ''Infinite Shift'' by StarmanJr., and ''The Pan'' by Dreigun. Roy single-handedly more than tripled the amount of maps in this genre with his ''Dash'' series, a set of ten maps, and two maps from the ''Jog'' series, meant to be an easier-to-play version of the game.

Roy also created several experimental maps that tinkered with novel or uncommon mapmaking techniques. The most notable example is ''Super Mario SC'', a map designed to play like a 2D platformer, stylistically mimicking Nintendo's ''Super Mario Bros.'', where players take turns controlling Mario and attempt to clear levels. Other examples include:
* Cannonball/Fireball (alternatives to the well-known Dodgeball map)
* Strength Contest (minigame)
* Guard Your Civilian (minigame)
* Dem0nS1ayer Bound (WASD key movement)
* Phrost (ice puzzle concept)
* RPB (Role-Playing Bound)
* Rat Race (minigame/puzzle)
* Fatty (run-to-goal concept)
* Interceptor Arena (asymmetrical VS)

== StarEdit Network ==

Roy first joined StarEdit Network (SEN) as the 6491st member under the username R0y- on August 13, 2005. He signed up as the 558th member under his current name, Roy, when SENv5 launched in 2007. Roy focused a lot of his early contributions to StarEdit Network making complex solutions more accessible to the average mapmaker, and the majority of his posts in the community are answering and solving mapmaking issues in the SC1 UMS Mapmaking Assistance forum. His most notable contribution in this regard is his "A Mapmaker's Guide for Creating EUDs" post, which took a very complicated subject at the time and put it in layman's terms to make working with EUDs more accessible to the community.

As he did not interact with the community much outside of the assistance forums, Roy's presence was largely unnoticed during his early years at SEN. It would take until July 6, 2010 for Roy to be promoted to Regular after having been recommended by rockz, a Staff member who was also active in the mapmaking assistance forums. Once Roy was put on the radar, the rest of the Staff recognized his knowledge and contributions to the community, and he was promoted to Veteran status in November of the same year, only four months after his promotion to Regular, making him the fastest Regular-to-Veteran promotion in the history of the site.

When StarCraft II launched in 2010, StarEdit Network created new forums for the game, including mapmaking assistance forums. Roy began becoming more active in areas outside of the SC1 assistance forums. He played and hosted Mafia games, posted in non-StarCraft related topics, learned about PC building and helping other members pick out computer parts, and generally increased his presence on the site. Importantly, Roy was one of the few members who invested time into learning the SC2 mapmaking tools, having carried over knowledge from the Warcraft III editor and programming knowledge he had accumulated. As the SC2 forums slowly became more active over the next year, the SC2 forums needed dedicated moderators, and on April 5th, 2011, DevliN asked Roy through the Shoutbox if he would like to moderate the SC2 Triggers and SC2 Data Editor forums. Roy accepted, and officially became a Staff member. DevliN also expanded Roy's moderation to the SC1 Assistance and SC1 Theories and Ideas forums in a subsequent post the same day, which took many by surprise. However, Roy proved that he was capable and qualified to lead these forums, and within a year, his effective moderation and community connection quickly led to DevliN recommending Roy's promotion to Global Moderator. On March 12, 2012, Roy was officially promoted to GM.

Roy's contributions to SEN extended beyond posting on the site. He has built tools specifically for the mapmaking community, such as Bound Maker and EUDGen. Devourer, the sole developer at the time Roy joined the Staff, was becoming increasingly busy and unable to dedicate enough time into managing the website by himself. Roy offered to help in this regard, and Moose (formerly Mini Moose 2707), the site administrator at the time, agreed to give Roy access to the server. While Devourer focused on new features and performance, Roy worked on bug fixes and site stability. Roy also conducted manual fixes, data recovery, and facilitating manual account resets and edits.

Roy has for the most part stopped working on StarCraft mapmaking, deciding that there isn't much left to learn in the scope of UMS maps. Like much of the community, Roy never took a strong interest in SC2 mapmaking due to the myriad of issues with Battle.net's map distribution system, and a general lack of enthusiasm for custom maps in SC2. As he drifted away from the StarCraft scene, Roy still kept a connection with the StarEdit community for many years, though he has become far less active as of 2020, and mostly just fulfills his responsibilities as a Global Moderator for the site.

User:Roy

2024-07-24T23:54:26Z

Roy: initial commit

Roy Gallant is a StarEdit Network community member who serves as a Global Moderator (GM) for the website and Discord server. As a member of the Staff, he is the most recently appointed GM for the site. Roy has contributed to the community in a variety of ways, including submitting maps, utilities, and guides, as well as being a prominent member in the mapmaking assistance and theory forums.

== StarCraft history ==

Roy was born and raised on the West Coast of the United States, where he first discovered StarCraft. He originally used the handle Roy_Gallant and played on the USWest server, where he proceeded to lag significantly due to his dial-up connection and low-spec desktop computer. Due to these economic challenges, Roy could not play online for long periods of time, and his choice of game gravitated toward custom maps under the Use Map Settings (UMS) category. It was there that he discovered a genre of maps that would become his specialty: bounds. He quickly became one of the more prominent bound players in the early scene, joining the National Bounding League (NBL) under the handle NBL)Roy, where he was recognized as one of their top players.

It wasn't long before Roy began looking into creating his own custom maps, which he could create offline when he had no internet availability. His first map, Hunter Bound, was never released. It featured a lot of similar elements to classic oldschool bound maps such as Heaven Bound or Bubble Bound, but the project was abandoned as it did not meet Roy's standards of what a bound should be. While still in NBL, he would release Ovy Bound, which would be one of the most difficult bounds of its time, and it is still considered to be a challenging map to this day.

NBL's members began to dwindle, including the original founder, NBL)Shabutie, leaving the scene. Roy was eventually promoted to co-leader of the National Bounding League, alongside NBL)Brittany. Due to the high recruiting standards of the NBL, it was difficult to find new members on USWest, and as both leaders were opposed to lowering the NBL's standards, Brittany and Roy eventually agreed to disassemble the league.

Roy continued working on his maps independently on USWest under his original handle Roy_Gallant, where his recognition for mapmaking steadily grew and spread across servers. He was eventually recruited into Bound-Making Revolution (BmR) on USEast under the handle BmR-Roy. With an increased focus on mapmaking, Roy would go on to make several maps, focusing more on his content than participating in clan activities. Due to this, he gained the reputation of always being away-from-keyboard (AFK) in the clan channel, and fellow members would joke about Roy being asleep at his desk.

BmR had management issues, and its existence was short-lived, eventually usurped by a faction of members that were dissatisfied with the state of things. The group was recreated under the name realBounders (rB). Roy didn't release any maps under this clan, however. Roy returned to USWest, and his membership in realBounders was more honorary than compulsory. It was there that, in channel Op R3n0, where Roy and a friend were alone talking together, a mysterious third person, QuiK., shows up. QuiK. claimed to have found an exploit that could surreptitiously get him any game handle he wanted. Skeptical, R3n0 asked for the account "Reno", whereas Roy_Gallant asked for the account "Roy". In a matter of minutes, QuiK. came back with both accounts and handed over the passwords to them, no questions asked. As mysteriously as QuiK. appeared, he vanished without a trace, leaving Roy with his new game handle on USWest.

Eventually Roy officially resigned from realBounders and became independent. Having released many bounds and a few other maps, Roy had made a name for himself on the mapmaking scene. He was approached by xBc Productionz to join the Bound Creators (xBc). Having been burnt out on joining short-lived clans, Roy initially rejected the offer, and would declare himself "clanless" for several years. However, he remained active in the xBc community, alongside Happybikini, Pie (a.k.a. Marth), Valor, Midna, Adzz, and others, and eventually Roy accepted the offer: it would be the last StarCraft clan he would join.

== Mapmaking ==

Roy predominantly played bounds, and consequently made several bounds of his own. As bounds are considered one of the 'simpler' maps to create, other mapmakers would often disparage or underestimate Roy's extensive knowledge of triggers. Roy has been at the forefront of mapping techniques such as the use of deaths as integer variables, grid systems, hyper trigger evolution, and Extended Unit Deaths (EUDs). Roy has also built specialty tools specifically to make mapmaking easier for the community and abroad.

Some of the bounds Roy has created include:
* 4 Hour Bound
* Bloodshot Bound
* Bloodshot Bound 2
* Dargon Bound
* Fire Emblem Bound
* Hamsper Bound
* Jihad Barbie Bound
* NuBs Bound
* Oblivion Bound
* Ovy Bound
* PGCC Bound
* Quaint Bound
* Radiant Dawn Bound
* Six Way Bound
* Suneric Bound
* Symmetrical Bound
* The Sims Bound
* Utopian Bound
* Viva La Bound
* When Anothing Bound
* WoW Bound
* Wow Bound 2

Roy was additionally fascinated by an extremely niche bound-adjacent genre: auto-scrollers. These maps feature a locked screen that moves, and players must safely navigate their unit through obstacles while staying on the screen to survive. There were very few of these maps that existed: ''Yoshi's Bound'' by MNeox, ''Infinite Shift'' by StarmanJr., and ''The Pan'' by Dreigun. Roy single-handedly more than tripled the amount of maps in this genre with his ''Dash'' series, a set of ten maps, and two maps from the ''Jog'' series, meant to be an easier-to-play version of the game.

Roy also created several experimental maps that tinkered with novel or uncommon mapmaking techniques. The most notable example is ''Super Mario SC'', a map designed to play like a 2D platformer, stylistically mimicking Nintendo's ''Super Mario Bros.'', where players take turns controlling Mario and attempt to clear levels. Other examples include:
* Cannonball/Fireball (alternatives to the well-known Dodgeball map)
* Strength Contest (minigame)
* Guard Your Civilian (minigame)
* Dem0nS1ayer Bound (WASD key movement)
* Phrost (ice puzzle concept)
* RPB (Role-Playing Bound)
* Rat Race (minigame/puzzle)
* Fatty (run-to-goal concept)
* Interceptor Arena (asymmetrical VS)

== StarEdit Network ==

Roy first joined StarEdit Network (SEN) as the 6491st member under the username R0y- on August 13, 2005. He signed up as the 558th member under his current name, Roy, when SENv5 launched in 2007. Roy focused a lot of his early contributions to StarEdit Network making complex solutions more accessible to the average mapmaker, and the majority of his posts in the community are answering and solving mapmaking issues in the SC1 UMS Mapmaking Assistance forum. His most notable contribution in this regard is his "A Mapmaker's Guide for Creating EUDs" post, which took a very complicated subject at the time and put it in layman's terms to make working with EUDs more accessible to the community.

As he did not interact with the community much outside of the assistance forums, Roy's presence was largely unnoticed during his early years at SEN. It would take until July 6, 2010 for Roy to be promoted to Regular after having been recommended by rockz, a Staff member who was also active in the mapmaking assistance forums. Once Roy was put on the radar, the rest of the Staff recognized his knowledge and contributions to the community, and he was promoted to Veteran status in November of the same year, only four months after his promotion to Regular, making him the fastest Regular-to-Veteran promotion in the history of the site.

When StarCraft II launched in 2010, StarEdit Network created new forums for the game, including mapmaking assistance forums. Roy began becoming more active in areas outside of the SC1 assistance forums. He played and hosted Mafia games, posted in non-StarCraft related topics, learned about PC building and helping other members pick out computer parts, and generally increased his presence on the site. Importantly, Roy was one of the few members who invested time into learning the SC2 mapmaking tools, having carried over knowledge from the Warcraft III editor and programming knowledge he had accumulated. As the SC2 forums slowly became more active over the next year, the SC2 forums needed dedicated moderators, and on April 5th, 2011, DevliN asked Roy through the Shoutbox if he would like to moderate the SC2 Triggers and SC2 Data Editor forums. Roy accepted, and officially became a Staff member. DevliN also expanded Roy's moderation to the SC1 Assistance and SC1 Theories and Ideas forums in a subsequent post the same day, which took many by surprise. However, Roy proved that he was capable and qualified to lead these forums, and within a year, his effective moderation and community connection quickly led to DevliN recommending Roy's promotion to Global Moderator. On March 12, 2012, Roy was officially promoted to GM.

Roy's contributions to SEN extended beyond posting on the site. He has built tools specifically for the mapmaking community, such as Bound Maker and EUDGen. Devourer, the sole developer at the time Roy joined the Staff, was becoming increasingly busy and unable to dedicate enough time into managing the website by himself. Roy offered to help in this regard, and Moose (formerly Mini Moose 2707), the site administrator at the time, agreed to give Roy access to the server. While Devourer focused on new features and performance, Roy worked on bug fixes and site stability. Roy also conducted manual fixes, data recovery, and facilitating manual account resets and edits.

Roy has for the most part stopped working on StarCraft mapmaking, deciding that there isn't much left to learn in the scope of UMS maps. Like much of the community, Roy never took a strong interest in SC2 mapmaking due to the myriad of issues with Battle.net's map distribution system, and a general lack of enthusiasm for custom maps in SC2. As he drifted away from the StarCraft scene, Roy still kept a connection with the StarEdit community for many years, though he has become far less active as of 2020, and mostly just fulfills his responsibilities as a Global Moderator for the site.

List of units

2018-11-18T00:29:49Z

Roy: Fixing table headers

Many values in StarCraft are hidden from the player, even in StarEdit and SCMDraft, and thus are unchangeable. Many of these values are found by using a modding program, like DatEdit or PyMS.

This table was designed to compare all the placeable units in the game.

===Table Description===

*Name - Unit name
*UnitID - Unique number used by StarCraft to differentiate each Unit in memory
*Width - Actual width of the unit's collision box in pixels (sum of left + right + 1)
*Height - Actual height of the unit's collision box in pixels (sum of up + down + 1)
*Left - Number of pixels left from the unit's center
*Right - Number of pixels right from the unit's center
*Up - Number of pixels up from the unit's center
*Down - Number of pixels down from the unit's center
*Sight - Sight radius in tiles
*Acceleration - If the unit is controlled by flingy.dat, this number is added to the speed of the unit each frame while accelerating/decelerating. Each point here is worth 1/256th of a pixel. The larger the number, the faster it moves. Iscript.bin units do not use this value
*Top Speed - The top speed of the unit in pixels/frame, ignoring acceleration
*Rank - The rank of the unit, which tells StarCraft which unit portrait to use.
*Ground WeaponID - Number distinguishing the ground weapon the unit uses
*Air WeaponID - Number distinguishing the air weapon the unit uses (if these are the same, only one weapon will be shown in StarCraft)
*Build Score - Number added to current player's unit or building score. Usually 1/2 of kill score or 1/3 of razing score
*Kill Score - Number added to current player's kill or razings score.
*Crashes? - Some units can't be seen or preplaced or else StarCraft will crash. Nearly all anti-maphacks block these units, so it is irrelevant whether or not they crash on map load or on view.

===Unit Properties===

{| Class="wikitable sortable"
! Name || UnitID || Width || Height || Left || Right || Up || Down || Sight || Acceleration || Top Speed || Rank || Ground WeaponID || Air WeaponID || Build Score || Kill Score || Crash?
|-
|Terran Marine || 0 || 17 || 20 || 8 || 8 || 9 || 10 || 7 || - || 4 || 2 || 0 || 0 || 50 || 100 || no
|-
|Terran Ghost || 1 || 15 || 22 || 7 || 7 || 10 || 11 || 9 || - || 4 || 5 || 2 || 2 || 175 || 350 || no
|-
|Terran Vulture || 2 || 32 || 32 || 16 || 15 || 16 || 15 || 8 || 100 || 6.67 || 6 || 4 || 130 || 75 || 150 || no
|-
|Terran Goliath || 3 || 32 || 32 || 16 || 15 || 16 || 15 || 8 || - || 4.7 || 7 || 130 || 130 || 200 || 400 || no
|-
|Goliath Turret || 4 || - || - || - || - || - || - || 8 || - || - || 0 || 7 || 8 || 0 || 0 || yes
|-
|Terran Siege Tank (Tank Mode) || 5 || 32 || 32 || 16 || 15 || 16 || 15 || 10 || - || 4 || 8 || 130 || 130 || 350 || 700 || no
|-
|Tank Turret (Tank Mode) || 6 || - || - || - || - || - || - || 10 || - || - || 0 || 11 || 130 || 0 || 0 || yes
|-
|Terran SCV || 7 || 23 || 23 || 11 || 11 || 11 || 11 || 7 || 67 || 5 || 1 || 13 || 130 || 50 || 100 || no
|-
|Terran Wraith || 8 || 38 || 30 || 19 || 18 || 15 || 14 || 7 || 67 || 6.67 || 10 || 16 || 15 || 400 || 800 || no
|-
|Terran Science Vessel || 9 || 65 || 50 || 32 || 32 || 33 || 16 || 10 || 50 || 5 || 11 || 130 || 130 || 625 || 1250 || no
|-
|Gui Montang (Firebat) || 10 || 23 || 28 || 11 || 11 || 13 || 14 || 7 || - || 4 || 12 || 26 || 130 || 0 || 400 || no
|-
|Terran Dropship || 11 || 49 || 37 || 24 || 24 || 16 || 20 || 8 || 17 || 5.47 || 9 || 130 || 130 || 300 || 600 || no
|-
|Terran Battlecruiser || 12 || 75 || 59 || 37 || 37 || 29 || 29 || 11 || 27 || 2.5 || 15 || 19 || 20 || 1200 || 2400 || no
|-
|Vulture Spider Mine || 13 || 15 || 15 || 7 || 7 || 7 || 7 || 3 || - || 16 || 0 || 6 || 130 || 0 || 25 || no
|-
|Nuclear Missile || 14 || 15 || 29 || 7 || 7 || 14 || 14 || 3 || 33 || 33.33 || 0 || 130 || 130 || 800 || 0 || no
|-
|Terran Civilian || 15 || 17 || 20 || 8 || 8 || 9 || 10 || 7 || - || 4 || 0 || 130 || 130 || 0 || 10 || no
|-
|Sarah Kerrigan (Ghost) || 16 || 15 || 22 || 7 || 7 || 10 || 11 || 11 || - || 4 || 18 || 3 || 3 || 0 || 700 || no
|-
|Alan Schezar (Goliath) || 17 || 32 || 32 || 16 || 15 || 16 || 15 || 8 || - || 4.7 || 13 || 130 || 130 || 0 || 800 || no
|-
|Alan Turret || 18 || - || - || - || - || - || - || 8 || - || - || 0 || 9 || 10 || 0 || 0 || yes
|-
|Jim Raynor (Vulture) || 19 || 32 || 32 || 16 || 15 || 16 || 15 || 8 || 100 || 6.67 || 17 || 5 || 130 || 0 || 300 || no
|-
|Jim Raynor (Marine) || 20 || 17 || 20 || 8 || 8 || 9 || 10 || 7 || - || 4 || 17 || 1 || 1 || 0 || 200 || no
|-
|Tom Kazansky (Wraith) || 21 || 38 || 30 || 19 || 18 || 15 || 14 || 7 || 67 || 6.67 || 14 || 18 || 17 || 0 || 1600 || no
|-
|Magellan (Science Vessel) || 22 || 65 || 50 || 32 || 32 || 33 || 16 || 10 || 50 || 5 || 15 || 130 || 130 || 0 || 2500 || no
|-
|Edmund Duke (Siege Tank) || 23 || 32 || 32 || 16 || 15 || 16 || 15 || 10 || - || 4 || 19 || 130 || 130 || 0 || 1400 || no
|-
|Duke Turret || 24 || - || - || - || - || - || - || 10 || - || - || 0 || 12 || 130 || 0 || 0 || yes
|-
|Edmund Duke (Siege Mode) || 25 || 32 || 32 || 16 || 15 || 16 || 15 || 10 || - || 4 || 19 || 130 || 130 || 0 || 1400 || no
|-
|Duke Turret || 26 || - || - || - || - || - || - || 10 || - || - || 0 || 28 || 130 || 0 || 0 || yes
|-
|Arcturus Mengsk (Battlecruiser) || 27 || 75 || 59 || 37 || 37 || 29 || 29 || 8 || 27 || 2.5 || 21 || 21 || 22 || 0 || 4800 || no
|-
|Hyperion (Battlecruiser) || 28 || 75 || 59 || 37 || 37 || 29 || 29 || 11 || 27 || 2.5 || 20 || 23 || 24 || 0 || 4800 || no
|-
|Norad II (Battlecruiser) || 29 || 75 || 59 || 37 || 37 || 29 || 29 || 11 || 27 || 2.5 || 21 || 21 || 22 || 0 || 4800 || no
|-
|Terran Siege Tank (Siege Mode) || 30 || 32 || 32 || 16 || 15 || 16 || 15 || 10 || - || 4 || 8 || 130 || 130 || 0 || 700 || no
|-
|Tank Turret (Siege Mode) || 31 || - || - || - || - || - || - || 10 || - || - || 0 || 27 || 130 || 0 || 0 || yes
|-
|Terran Firebat || 32 || 23 || 22 || 11 || 11 || 7 || 14 || 7 || - || 4 || 4 || 25 || 130 || 100 || 200 || no
|-
|Scanner Sweep || 33 || 27 || 31 || 13 || 13 || 13 || 17 || 10 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Terran Medic || 34 || 17 || 19 || 8 || 8 || 7 || 11 || 9 || - || 4 || 3 || 130 || 130 || 125 || 250 || no
|-
|Zerg Larva || 35 || 16 || 16 || 8 || 7 || 8 || 7 || 4 || - || 2 || 0 || 130 || 130 || 0 || 10 || no
|-
|Zerg Egg || 36 || 32 || 32 || 16 || 15 || 16 || 15 || 4 || - || - || 1 || 130 || 130 || 0 || 25 || no
|-
|Zerg Zergling || 37 || 16 || 16 || 8 || 7 || 4 || 11 || 5 || - || 5.57 || 5 || 35 || 130 || 25 || 50 || no
|-
|Zerg Hydralisk || 38 || 21 || 23 || 10 || 10 || 10 || 12 || 6 || - || 3.71 || 9 || 38 || 38 || 125 || 350 || no
|-
|Zerg Ultralisk || 39 || 38 || 32 || 19 || 18 || 16 || 15 || 7 || - || 5.4 || 14 || 40 || 130 || 650 || 1300 || no
|-
|Zerg Broodling || 40 || 19 || 19 || 9 || 9 || 9 || 9 || 5 || - || 6.09 || 8 || 42 || 130 || 0 || 25 || no
|-
|Zerg Drone || 41 || 23 || 23 || 11 || 11 || 11 || 11 || 7 || 67 || 5 || 10 || 43 || 130 || 50 || 100 || no
|-
|Zerg Overlord || 42 || 50 || 50 || 25 || 24 || 25 || 24 || 9 || 27 || 0.83 || 11 || 130 || 130 || 100 || 200 || no
|-
|Zerg Mutalisk || 43 || 44 || 44 || 22 || 21 || 22 || 21 || 7 || 67 || 6.67 || 12 || 48 || 48 || 300 || 600 || no
|-
|Zerg Guardian || 44 || 44 || 44 || 22 || 21 || 22 || 21 || 11 || 27 || 2.5 || 6 || 46 || 130 || 550 || 1100 || no
|-
|Zerg Queen || 45 || 48 || 48 || 24 || 23 || 24 || 23 || 10 || 67 || 6.67 || 15 || 130 || 130 || 400 || 800 || no
|-
|Zerg Defiler || 46 || 27 || 25 || 13 || 13 || 12 || 12 || 10 || - || 4 || 15 || 130 || 130 || 225 || 450 || no
|-
|Zerg Scourge || 47 || 24 || 24 || 12 || 11 || 12 || 11 || 5 || 107 || 6.67 || 6 || 130 || 55 || 100 || 200 || no
|-
|Torrarsque (Ultralisk) || 48 || 38 || 32 || 19 || 18 || 16 || 15 || 7 || - || 7.4 || 15 || 41 || 130 || 0 || 2600 || no
|-
|Matriarch (Queen) || 49 || 48 || 48 || 24 || 23 || 24 || 23 || 10 || 67 || 6.67 || 15 || 130 || 130 || 0 || 1600 || no
|-
|Infested Terran || 50 || 17 || 20 || 8 || 8 || 9 || 10 || 9 || - || 6 || 7 || 54 || 130 || 200 || 400 || no
|-
|Infested Kerrigan || 51 || 15 || 22 || 7 || 7 || 10 || 11 || 5 || - || 4 || 16 || 37 || 130 || 0 || 4000 || no
|-
|Unclean One (Defiler) || 52 || 29 || 29 || 14 || 14 || 14 || 14 || 10 || - || 4 || 15 || 130 || 130 || 0 || 900 || no
|-
|Hunter Killer (Hydralisk) || 53 || 21 || 23 || 10 || 10 || 10 || 12 || 8 || - || 5.71 || 15 || 39 || 39 || 0 || 500 || no
|-
|Devouring One (Zergling) || 54 || 16 || 16 || 8 || 7 || 4 || 11 || 5 || - || 7.57 || 15 || 36 || 130 || 0 || 100 || no
|-
|Kukulza (Mutalisk) || 55 || 44 || 44 || 22 || 21 || 22 || 21 || 7 || 67 || 6.67 || 15 || 49 || 49 || 0 || 1200 || no
|-
|Kukulza (Guardian) || 56 || 44 || 44 || 22 || 21 || 22 || 21 || 11 || 27 || 2.5 || 15 || 47 || 130 || 0 || 2200 || no
|-
|Yggdrasill (Overlord) || 57 || 50 || 50 || 25 || 24 || 25 || 24 || 11 || 54 || 3.33 || 15 || 130 || 130 || 0 || 400 || no
|-
|Terran Valkyrie || 58 || 49 || 37 || 24 || 24 || 16 || 20 || 8 || 65 || 6.6 || 16 || 130 || 103 || 400 || 800 || no
|-
|Cocoon || 59 || 32 || 32 || 16 || 15 || 16 || 15 || 4 || - || - || 2 || 130 || 130 || 0 || 1100 || no
|-
|Protoss Corsair || 60 || 36 || 32 || 18 || 17 || 16 || 15 || 9 || 67 || 6.67 || 8 || 130 || 100 || 350 || 700 || no
|-
|Protoss Dark Templar || 61 || 24 || 26 || 12 || 11 || 6 || 19 || 7 || - || 5 || 12 || 111 || 130 || 325 || 650 || no
|-
|Zerg Devourer || 62 || 44 || 44 || 22 || 21 || 22 || 21 || 10 || 67 || 6.67 || 12 || 130 || 104 || 550 || 1100 || no
|-
|Protoss Dark Archon || 63 || 32 || 32 || 16 || 15 || 16 || 15 || 10 || 160 || 5 || 9 || 130 || 130 || 650 || 1300 || no
|-
|Protoss Probe || 64 || 23 || 23 || 11 || 11 || 11 || 11 || 8 || 67 || 5 || 0 || 62 || 130 || 50 || 100 || no
|-
|Protoss Zealot || 65 || 23 || 19 || 11 || 11 || 5 || 13 || 7 || - || 4 || 3 || 64 || 130 || 100 || 200 || no
|-
|Protoss Dragoon || 66 || 32 || 32 || 15 || 16 || 15 || 16 || 8 || - || 5.25 || 4 || 66 || 66 || 250 || 500 || no
|-
|Protoss High Templar || 67 || 24 || 24 || 12 || 11 || 10 || 13 || 7 || 27 || 3.33 || 6 || 130 || 130 || 350 || 700 || no
|-
|Protoss Archon || 68 || 32 || 32 || 16 || 15 || 16 || 15 || 8 || 160 || 5 || 9 || 70 || 70 || 700 || 1400 || no
|-
|Protoss Shuttle || 69 || 40 || 32 || 20 || 19 || 16 || 15 || 8 || 17 || 5 || 7 || 130 || 130 || 200 || 400 || no
|-
|Protoss Scout || 70 || 36 || 32 || 18 || 17 || 16 || 15 || 8 || 48 || 5 || 8 || 73 || 74 || 650 || 1300 || no
|-
|Protoss Arbiter || 71 || 44 || 44 || 22 || 21 || 22 || 21 || 9 || 33 || 5 || 10 || 77 || 77 || 1025 || 2050 || no
|-
|Protoss Carrier || 72 || 64 || 64 || 32 || 31 || 32 || 31 || 11 || 27 || 3.33 || 11 || 130 || 130 || 950 || 1900 || no
|-
|Protoss Interceptor || 73 || 16 || 16 || 8 || 7 || 8 || 7 || 6 || 427 || 13.33 || 1 || 79 || 79 || 30 || 60 || no
|-
|Dark Templar (Hero) || 74 || 24 || 26 || 12 || 11 || 6 || 19 || 7 || - || 4 || 12 || 86 || 130 || 0 || 400 || no
|-
|Zeratul (Dark Templar) || 75 || 24 || 26 || 12 || 11 || 6 || 19 || 7 || - || 4 || 15 || 85 || 130 || 0 || 800 || no
|-
|Tassadar/Zeratul (Archon) || 76 || 32 || 32 || 16 || 15 || 16 || 15 || 8 || 160 || 5 || 17 || 71 || 71 || 0 || 2800 || no
|-
|Fenix (Zealot) || 77 || 23 || 19 || 11 || 11 || 5 || 13 || 7 || - || 4 || 13 || 65 || 130 || 0 || 400 || no
|-
|Fenix (Dragoon) || 78 || 32 || 32 || 15 || 16 || 15 || 16 || 8 || - || 5.25 || 14 || 67 || 67 || 0 || 1000 || no
|-
|Tassadar (Templar) || 79 || 24 || 24 || 12 || 11 || 10 || 13 || 7 || 27 || 3.33 || 16 || 69 || 130 || 0 || 1400 || no
|-
|Mojo (Scout) || 80 || 36 || 32 || 18 || 17 || 16 || 15 || 10 || 96 || 6.67 || 12 || 75 || 76 || 0 || 2600 || no
|-
|Warbringer (Reaver) || 81 || 32 || 32 || 16 || 15 || 16 || 15 || 10 || - || 1.78 || 12 || 130 || 130 || 0 || 1600 || no
|-
|Gantrithor (Carrier) || 82 || 64 || 64 || 32 || 31 || 32 || 31 || 9 || 27 || 3.33 || 17 || 130 || 130 || 0 || 3800 || no
|-
|Protoss Reaver || 83 || 32 || 32 || 16 || 15 || 16 || 15 || 10 || - || 1.78 || 5 || 130 || 130 || 400 || 800 || no
|-
|Protoss Observer || 84 || 32 || 32 || 16 || 15 || 16 || 15 || 9 || 27 || 3.33 || 2 || 130 || 130 || 225 || 450 || no
|-
|Protoss Scarab || 85 || 5 || 5 || 2 || 2 || 2 || 2 || 5 || - || 16 || 0 || 82 || 130 || 0 || 0 || no
|-
|Danimoth (Arbiter) || 86 || 44 || 44 || 22 || 21 || 22 || 21 || 9 || 33 || 5 || 12 || 78 || 78 || 0 || 4100 || no
|-
|Aldaris (Templar) || 87 || 24 || 28 || 12 || 11 || 14 || 13 || 7 || 27 || 3.33 || 16 || 69 || 130 || 0 || 1400 || no
|-
|Artanis (Scout) || 88 || 36 || 32 || 18 || 17 || 16 || 15 || 10 || 96 || 6.67 || 12 || 114 || 115 || 0 || 2400 || no
|-
|Rhynadon (Badlands Critter) || 89 || 32 || 32 || 16 || 15 || 16 || 15 || 7 || - || 4 || 0 || 130 || 130 || 0 || 10 || no
|-
|Bengalaas (Jungle Critter) || 90 || 32 || 32 || 16 || 15 || 16 || 15 || 7 || - || 4 || 0 || 130 || 130 || 0 || 10 || no
|-
|Unused - Was Cargo Ship || 91 || 32 || 32 || 15 || 16 || 15 || 16 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Unused - Was Mercenary Gunship || 92 || 32 || 32 || 15 || 16 || 15 || 16 || 7 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Scantid (Desert Critter) || 93 || 32 || 32 || 16 || 15 || 16 || 15 || 7 || - || - || 0 || 130 || 130 || 0 || 10 || no
|-
|Kakaru (Twilight Critter) || 94 || 32 || 32 || 16 || 15 || 16 || 15 || 7 || - || 4 || 0 || 130 || 130 || 0 || 10 || no
|-
|Ragnasaur (Ashworld Critter) || 95 || 32 || 32 || 16 || 15 || 16 || 15 || 7 || - || 4 || 0 || 130 || 130 || 0 || 10 || no
|-
|Ursadon (Ice World Critter) || 96 || 32 || 32 || 16 || 15 || 16 || 15 || 7 || - || 4 || 0 || 130 || 130 || 0 || 10 || no
|-
|Lurker Egg || 97 || 32 || 32 || 16 || 15 || 16 || 15 || 4 || - || - || 1 || 130 || 130 || 0 || 500 || no
|-
|Raszagal (Corsair) || 98 || 49 || 37 || 24 || 24 || 16 || 20 || 9 || 67 || 6.67 || 8 || 130 || 100 || 0 || 1300 || no
|-
|Samir Duran (Ghost) || 99 || 15 || 22 || 7 || 7 || 10 || 11 || 10 || - || 4 || 18 || 112 || 112 || 0 || 700 || no
|-
|Alexei Stukov (Ghost) || 100 || 15 || 22 || 7 || 7 || 10 || 11 || 11 || - || 4 || 22 || 116 || 116 || 0 || 700 || no
|-
|Map Revealer || 101 || 27 || 31 || 13 || 13 || 13 || 17 || 10 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Gerard DuGalle (Battlecruiser) || 102 || 75 || 59 || 37 || 37 || 29 || 29 || 11 || 27 || 2.5 || 0 || 21 || 22 || 0 || 4800 || no
|-
|Zerg Lurker || 103 || 32 || 32 || 15 || 16 || 15 || 16 || 8 || - || 4 || 10 || 109 || 130 || 250 || 500 || no
|-
|Infested Duran || 104 || 15 || 22 || 7 || 7 || 10 || 11 || 11 || - || 4 || 15 || 113 || 113 || 0 || 700 || no
|-
|Disruption Web || 105 || 120 || 80 || 60 || 59 || 40 || 39 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Terran Command Center || 106 || 117 || 83 || 58 || 58 || 41 || 41 || 10 || 33 || 1.67 || 0 || 130 || 130 || 400 || 1200 || no
|-
|Terran Comsat Station || 107 || 69 || 42 || 37 || 31 || 16 || 25 || 10 || - || - || 0 || 130 || 130 || 75 || 225 || no
|-
|Terran Nuclear Silo || 108 || 69 || 42 || 37 || 31 || 16 || 25 || 8 || - || - || 0 || 130 || 130 || 75 || 225 || no
|-
|Terran Supply Depot || 109 || 77 || 49 || 38 || 38 || 22 || 26 || 8 || - || - || 0 || 130 || 130 || 50 || 150 || no
|-
|Terran Refinery || 110 || 113 || 64 || 56 || 56 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 50 || 150 || no
|-
|Terran Barracks || 111 || 105 || 73 || 48 || 56 || 40 || 32 || 8 || 33 || 1.67 || 0 || 130 || 130 || 75 || 225 || no
|-
|Terran Academy || 112 || 85 || 57 || 40 || 44 || 32 || 24 || 8 || - || - || 0 || 130 || 130 || 100 || 300 || no
|-
|Terran Factory || 113 || 113 || 81 || 56 || 56 || 40 || 40 || 8 || 33 || 1.67 || 0 || 130 || 130 || 200 || 600 || no
|-
|Terran Starport || 114 || 97 || 79 || 48 || 48 || 40 || 38 || 10 || 33 || 1.67 || 0 || 130 || 130 || 200 || 600 || no
|-
|Terran Control Tower || 115 || 76 || 47 || 47 || 28 || 24 || 22 || 8 || - || - || 0 || 130 || 130 || 100 || 300 || no
|-
|Terran Science Facility || 116 || 97 || 77 || 48 || 48 || 38 || 38 || 10 || 33 || 1.67 || 0 || 130 || 130 || 275 || 825 || no
|-
|Terran Covert Ops || 117 || 76 || 47 || 47 || 28 || 24 || 22 || 8 || - || - || 0 || 130 || 130 || 75 || 225 || no
|-
|Terran Physics Lab || 118 || 76 || 47 || 47 || 28 || 24 || 22 || 8 || - || - || 0 || 130 || 130 || 75 || 225 || no
|-
|Unused - Was Starbase? || 119 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || - || - || yes
|-
|Terran Machine Shop || 120 || 71 || 49 || 39 || 31 || 24 || 24 || 8 || - || - || 0 || 130 || 130 || 75 || 225 || no
|-
|Unused - Was Repair Bay? || 121 || 96 || 96 || 48 || 47 || 48 || 47 || 8 || - || - || 0 || 130 || 130 || - || - || yes
|-
|Terran Engineering Bay || 122 || 97 || 61 || 48 || 48 || 32 || 28 || 8 || 33 || 1.67 || 0 || 130 || 130 || 65 || 195 || no
|-
|Terran Armory || 123 || 96 || 55 || 48 || 47 || 32 || 22 || 8 || - || - || 0 || 130 || 130 || 100 || 300 || no
|-
|Terran Missile Turret || 124 || 33 || 49 || 16 || 16 || 32 || 16 || 11 || - || - || 0 || 130 || 29 || 50 || 150 || no
|-
|Terran Bunker || 125 || 65 || 41 || 32 || 32 || 24 || 16 || 10 || - || - || 0 || 130 || 130 || 50 || 150 || no
|-
|Norad II (Crashed Battlecruiser) || 126 || 96 || 64 || 48 || 47 || 32 || 31 || 10 || - || - || 0 || 130 || 130 || 0 || 5000 || no
|-
|Ion Cannon || 127 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 5000 || no
|-
|Uraj Crystal || 128 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || - || - || no
|-
|Khalis Crystal || 129 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || - || - || no
|-
|Infested Command Center || 130 || 117 || 83 || 58 || 58 || 41 || 41 || 10 || 33 || 1.67 || 0 || 130 || 130 || 300 || 900 || no
|-
|Zerg Hatchery || 131 || 99 || 65 || 49 || 49 || 32 || 32 || 9 || - || - || 0 || 130 || 130 || 300 || 900 || no
|-
|Zerg Lair || 132 || 99 || 65 || 49 || 49 || 32 || 32 || 10 || - || - || 0 || 130 || 130 || 100 || 1200 || no
|-
|Zerg Hive || 133 || 99 || 65 || 49 || 49 || 32 || 32 || 11 || - || - || 0 || 130 || 130 || 100 || 1500 || no
|-
|Zerg Nydus Canal || 134 || 64 || 64 || 32 || 31 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 75 || 225 || no
|-
|Zerg Hydralisk Den || 135 || 81 || 57 || 40 || 40 || 32 || 24 || 8 || - || - || 0 || 130 || 130 || 100 || 300 || no
|-
|Zerg Defiler Mound || 136 || 97 || 37 || 48 || 48 || 32 || 4 || 8 || - || - || 0 || 130 || 130 || 150 || 450 || no
|-
|Zerg Greater Spire || 137 || 57 || 57 || 28 || 28 || 32 || 24 || 8 || - || - || 0 || 130 || 130 || 200 || 1350 || no
|-
|Zerg Queen's Nest || 138 || 71 || 57 || 38 || 32 || 28 || 28 || 8 || - || - || 0 || 130 || 130 || 175 || 525 || no
|-
|Zerg Evolution Chamber || 139 || 77 || 53 || 44 || 32 || 32 || 20 || 8 || - || - || 0 || 130 || 130 || 40 || 120 || no
|-
|Zerg Ultralisk Cavern || 140 || 73 || 64 || 40 || 32 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 275 || 825 || no
|-
|Zerg Spire || 141 || 57 || 57 || 28 || 28 || 32 || 24 || 8 || - || - || 0 || 130 || 130 || 250 || 750 || no
|-
|Zerg Spawning Pool || 142 || 77 || 47 || 36 || 40 || 28 || 18 || 8 || - || - || 0 || 130 || 130 || 75 || 225 || no
|-
|Zerg Creep Colony || 143 || 48 || 48 || 24 || 23 || 24 || 23 || 10 || - || - || 0 || 130 || 130 || 40 || 120 || no
|-
|Zerg Spore Colony || 144 || 48 || 48 || 24 || 23 || 24 || 23 || 10 || - || - || 0 || 130 || 52 || 25 || 195 || no
|-
|Unused Zerg Building || 145 || 96 || 96 || 48 || 47 || 48 || 47 || 7 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Zerg Sunken Colony || 146 || 48 || 48 || 24 || 23 || 24 || 23 || 10 || - || - || 0 || 53 || 130 || 40 || 240 || no
|-
|Zerg Overmind (With Shell) || 147 || 160 || 73 || 80 || 79 || 32 || 40 || 8 || - || - || 0 || 130 || 130 || 0 || 10000 || no
|-
|Zerg Overmind || 148 || 160 || 73 || 80 || 79 || 32 || 40 || 8 || - || - || 0 || 130 || 130 || 0 || 10000 || no
|-
|Zerg Extractor || 149 || 128 || 54 || 64 || 63 || 32 || 21 || 7 || - || - || 0 || 130 || 130 || 25 || 75 || no
|-
|Mature Chrysalis || 150 || 64 || 64 || 32 || 31 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 5000 || no
|-
|Zerg Cerebrate || 151 || 73 || 64 || 40 || 32 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 2500 || no
|-
|Zerg Cerebrate Daggoth || 152 || 73 || 64 || 40 || 32 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 2500 || no
|-
|Unused Zerg Building 5 || 153 || 32 || 32 || 16 || 15 || 16 || 15 || 7 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Protoss Nexus || 154 || 113 || 79 || 56 || 56 || 39 || 39 || 11 || - || - || 0 || 130 || 130 || 400 || 1200 || no
|-
|Protoss Robotics Facility || 155 || 77 || 37 || 36 || 40 || 16 || 20 || 10 || - || - || 0 || 130 || 130 || 300 || 900 || no
|-
|Protoss Pylon || 156 || 33 || 33 || 16 || 16 || 12 || 20 || 8 || - || - || 0 || 130 || 130 || 50 || 150 || no
|-
|Protoss Assimilator || 157 || 97 || 57 || 48 || 48 || 32 || 24 || 10 || - || - || 0 || 130 || 130 || 50 || 150 || no
|-
|Unused Protoss Building || 158 || 128 || 96 || 64 || 63 || 48 || 47 || 7 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Protoss Observatory || 159 || 89 || 45 || 44 || 44 || 16 || 28 || 10 || - || - || 0 || 130 || 130 || 175 || 525 || no
|-
|Protoss Gateway || 160 || 97 || 73 || 48 || 48 || 32 || 40 || 10 || - || - || 0 || 130 || 130 || 75 || 225 || no
|-
|Unused Protoss Building || 161 || 96 || 96 || 48 || 47 || 48 || 47 || 10 || - || - || 0 || 130 || 130 || 0 || 0 || yes
|-
|Protoss Photon Cannon || 162 || 41 || 33 || 20 || 20 || 16 || 16 || 11 || - || - || 0 || 80 || 81 || 100 || 300 || no
|-
|Protoss Citadel of Adun || 163 || 65 || 49 || 24 || 40 || 24 || 24 || 10 || - || - || 0 || 130 || 130 || 200 || 600 || no
|-
|Protoss Cybernetics Core || 164 || 81 || 49 || 40 || 40 || 24 || 24 || 10 || - || - || 0 || 130 || 130 || 100 || 300 || no
|-
|Protoss Templar Archives || 165 || 65 || 49 || 32 || 32 || 24 || 24 || 10 || - || - || 0 || 130 || 130 || 250 || 750 || no
|-
|Protoss Forge || 166 || 73 || 45 || 36 || 36 || 24 || 20 || 10 || - || - || 0 || 130 || 130 || 100 || 300 || no
|-
|Protoss Stargate || 167 || 97 || 73 || 48 || 48 || 40 || 32 || 10 || - || - || 0 || 130 || 130 || 300 || 900 || no
|-
|Stasis Cell/Prison || 168 || 128 || 96 || 64 || 63 || 48 || 47 || 8 || - || - || 0 || 130 || 130 || 0 || 5000 || no
|-
|Protoss Fleet Beacon || 169 || 88 || 57 || 40 || 47 || 32 || 24 || 10 || - || - || 0 || 130 || 130 || 350 || 1050 || no
|-
|Protoss Arbiter Tribunal || 170 || 89 || 57 || 44 || 44 || 28 || 28 || 10 || - || - || 0 || 130 || 130 || 450 || 1350 || no
|-
|Protoss Robotics Support Bay || 171 || 65 || 53 || 32 || 32 || 32 || 20 || 10 || - || - || 0 || 130 || 130 || 125 || 375 || no
|-
|Protoss Shield Battery || 172 || 65 || 33 || 32 || 32 || 16 || 16 || 10 || - || - || 0 || 130 || 130 || 50 || 150 || no
|-
|Khaydarin Crystal Formation || 173 || 128 || 96 || 64 || 63 || 48 || 47 || 10 || - || - || 0 || 130 || 130 || 0 || 2500 || no
|-
|Protoss Temple || 174 || 224 || 96 || 112 || 111 || 48 || 47 || 10 || - || - || 0 || 130 || 130 || 0 || 5000 || no
|-
|Xel'Naga Temple || 175 || 160 || 98 || 80 || 79 || 34 || 63 || 10 || - || - || 0 || 130 || 130 || 0 || 5000 || no
|-
|Mineral Field (Type 1) || 176 || 64 || 32 || 32 || 31 || 16 || 15 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || no
|-
|Mineral Field (Type 2) || 177 || 64 || 32 || 32 || 31 || 16 || 15 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || no
|-
|Mineral Field (Type 3) || 178 || 64 || 32 || 32 || 31 || 16 || 15 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || no
|-
|Cave || 179 || 64 || 64 || 32 || 31 || 32 || 31 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Cave-in || 180 || 64 || 64 || 32 || 31 || 32 || 31 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Cantina || 181 || 64 || 64 || 32 || 31 || 32 || 31 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Mining Platform || 182 || 32 || 32 || 16 || 15 || 16 || 15 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Independant Command Center || 183 || 32 || 32 || 16 || 15 || 16 || 15 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Independant Starport || 184 || 64 || 64 || 32 || 31 || 32 || 31 || 9 || - || - || 0 || 93 || 130 || 10 || 10 || no
|-
|Jump Gate || 185 || 32 || 32 || 16 || 15 || 16 || 15 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Ruins || 186 || 32 || 32 || 16 || 15 || 16 || 15 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Kyadarin Crystal Formation || 187 || 32 || 32 || 16 || 15 || 16 || 15 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || yes
|-
|Vespene Geyser || 188 || 128 || 64 || 64 || 63 || 32 || 31 || 9 || - || - || 0 || 130 || 130 || 10 || 10 || no
|-
|Warp Gate || 189 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 2000 || no
|-
|PSI Disruptor || 190 || 150 || 86 || 80 || 69 || 38 || 47 || 10 || - || - || 0 || 130 || 130 || 0 || 3600 || no
|-
|Zerg Marker || 191 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || yes
|-
|Terran Marker || 192 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || yes
|-
|Protoss Marker || 193 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || yes
|-
|Zerg Beacon || 194 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Terran Beacon || 195 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Protoss Beacon || 196 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Zerg Flag Beacon || 197 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Terran Flag Beacon || 198 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Protoss Flag Beacon || 199 || 96 || 64 || 48 || 47 || 32 || 31 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Power Generator || 200 || 120 || 72 || 56 || 63 || 28 || 43 || 8 || - || - || 0 || 130 || 130 || 0 || 600 || no
|-
|Overmind Cocoon || 201 || 96 || 64 || 48 || 47 || 32 || 31 || 10 || - || - || 0 || 130 || 130 || 0 || 4000 || no
|-
|Dark Swarm || 202 || 160 || 160 || 80 || 79 || 80 || 79 || 8 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Floor Missile Trap || 203 || 64 || 64 || 32 || 31 || 32 || 31 || 6 || - || - || 0 || 99 || 130 || 0 || 100 || no
|-
|Floor Hatch || 204 || 256 || 128 || 128 || 127 || 64 || 63 || 7 || - || - || 0 || 130 || 130 || 0 || 10 || no
|-
|Left Upper Level Door || 205 || 70 || 38 || 25 || 44 || 17 || 20 || 1 || - || - || 0 || 130 || 130 || 0 || 10 || no
|-
|Right Upper Level Door || 206 || 70 || 38 || 44 || 25 || 17 || 20 || 1 || - || - || 0 || 130 || 130 || 0 || 10 || no
|-
|Left Pit Door || 207 || 70 || 38 || 41 || 28 || 17 || 20 || 1 || - || - || 0 || 130 || 130 || 0 || 10 || no
|-
|Right Pit Door || 208 || 70 || 38 || 28 || 41 || 17 || 20 || 1 || - || - || 0 || 130 || 130 || 0 || 10 || no
|-
|Floor Gun Trap || 209 || 64 || 64 || 32 || 31 || 32 || 31 || 6 || - || - || 0 || 96 || 130 || 0 || 100 || no
|-
|Left Wall Missile Trap || 210 || 32 || 32 || 16 || 15 || 16 || 15 || 6 || - || - || 0 || 97 || 130 || 0 || 100 || no
|-
|Left Wall Flame Trap || 211 || 32 || 32 || 16 || 15 || 16 || 15 || 3 || - || - || 0 || 98 || 130 || 0 || 100 || no
|-
|Right Wall Missile Trap || 212 || 32 || 32 || 16 || 15 || 16 || 15 || 6 || - || - || 0 || 97 || 130 || 0 || 100 || no
|-
|Right Wall Flame Trap || 213 || 32 || 32 || 16 || 15 || 16 || 15 || 3 || - || - || 0 || 98 || 130 || 0 || 100 || no
|-
|Start Location || 214 || 97 || 65 || 48 || 48 || 32 || 32 || 1 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Flag || 215 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Young Chrysalis || 216 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Psi Emitter || 217 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Data Disc || 218 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Khaydarin Crystal || 219 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Mineral Cluster Type 1 || 220 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Mineral Cluster Type 2 || 221 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Protoss Vespene Gas Orb Type 1 || 222 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Protoss Vespene Gas Orb Type 2 || 223 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Zerg Vespene Gas Sac Type 1 || 224 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Zerg Vespene Gas Sac Type 2 || 225 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Terran Vespene Gas Tank Type 1 || 226 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|-
|Terran Vespene Gas Tank Type 2 || 227 || 32 || 32 || 16 || 15 || 16 || 15 || 5 || - || - || 0 || 130 || 130 || 0 || 0 || no
|}

Ordering and using interceptors and scarabs

2016-07-12T15:52:48Z

Roy: Fixing trigger

[[Protoss Interceptor]]s and [[Protoss Scarab]]s are ''subunits'', or [[units]] that are built by and stored in other non-building units. Subunits must use different AI because they function in a vastly different manner from other offensive units. These AIs can be manipulated with [[triggers]] to send these units to a location, make them "spray" outwards, or even [[Direct Damage System|manipulate the HP of other units]].

== Ordering Interceptors and Scarabs ==
Normally, when Interceptors move out of their host [[Protoss Carrier|Carrier]]'s range, they quickly turn around and head back. However, this behavior can be circumvented and ''computer-controlled'' Interceptors can be ordered to a location using triggered [[AI scripts]]. This trick is used in maps like [[Particles Arena]]; here are the triggers.

Start by pre-placing ''computer-controlled'' Carriers or Reavers in an enclosure. Place an enemy unit in the enclosure with them. The enemy's presence will prompt the computer to create subunits, which you can capture and control. Wrap the entire enclosure in a [[Location]]; we will call this location "Spawn". Set up triggers to ally the computer with any other players that may approach the controlled subunits; if you do not, then the subunits will ignore your trigger-based commands and automatically attack the other players.

This optional trigger moves the subunits to an enclosed area (marked by a Location called "Storage") and stops them from moving around. This keeps the Interceptors from flying around while attacking, and keeps the Scarabs from exploding on their targets.
{{StarCraft Trigger
|description=Moving the Interceptors or Scarabs to a storage area.
|players=
*Computer Player(s) ''(i.e. Player 7, Player 8)''
|conditions=
*Current Player brings at least 1 ''[Protoss Interceptor or Protoss Scarab]'' to Spawn
|actions=
*Move all ''[Protoss Interceptor or Protoss Scarab]'' from Spawn to Storage for Current Player
*Run AI script Set Generic Command Target at Storage
*Run AI script Make These Units Patrol to Storage
*Preserve trigger.
}}

This next trigger will order the subunits around. The trigger moves the subunits to their starting position (marked by a Location called Start) and orders them to move to the target area (marked by a Location called End).

{{StarCraft Trigger
|description=Moving the Interceptors or Scarabs to an area and ordering them to move to another.
|players=
*Computer Player(s) ''(i.e. Player 7, Player 8)''
|conditions=
*''[Whenever you want to order the subunit.]''
|actions=
*Move 1 ''[Protoss Interceptor or Protoss Scarab]'' from Storage to Start for Current Player
*Run AI script Set Generic Command Target at End
*Run AI script Make These Units Patrol at Start
*Preserve trigger.
}}

Remember that the endogenous attack AI script will override these triggers. You can take advantage of this by sending Scarabs into the direction of vulnerable enemies. The Scarabs will ignore their player's AI script, and attack the nearby enemies. This cannot be exploited with Interceptors; they will just fly back to their host Carrier if it is out of range.

== Spraying effects ==
[[File:Picture1.png|thumb|right|Spraying effect of Interceptors from a bomb in Shrapnel Bombers.]]
Maps such as [[Shrapnel Bombers]] and [[Shrapnel Wars]] produce a "spraying effect", where interceptors are seen to diverge randomly outwards. Use the same setup from the last section to spawn (and, optionally, store) subunits, and use this trigger to control their movement. "Start" is the location they should scatter outward from.

{{StarCraft Trigger
|description=Subunit spray.
|players=
*Computer Player(s) ''(i.e. Player 7, Player 8)''
|conditions=
*''[Whenever you want to scatter the subunits.]''
|actions=
*Move 15 ''[Protoss Interceptor or Protoss Scarab]'' from ''Spawn or Storage'' to Start for Current Player
*Run AI script Junk Yard Dog at Start.
*Preserve trigger.
}}

Junk Yard Dog ordinarily causes a player's movements to wander randomly. Interceptors, however, move so fast that if enough of them are used, they will move outward in a random fashion.

As with before, the endogenous AI used by the subunits can be exploited to make the subunits attack nearby enemies. You can also exploit an Interceptor's endogenous AI; simply move its host Carrier out of range and in the direction you wish to send the Interceptor. This mainly requires tedious triggering, as many locations are required if you wish to move your interceptors in different directions.

== Direct Damage System ==
{{main|Direct Damage System}}
It is possible to forcibly detonate a Protoss Scarab at any arbitrary location. Scarabs explode when a Move Unit action attempts to move them to unwalkable [[terrain]]. These detonations deal splash damage to the Scarab's enemies; it effectively allows mappers to damage a unit without already knowing its health.

=== Triggers ===

Assuming you have a location centered on an enemy called "Enemy", and the enemy under the location "arena".
{{StarCraft Trigger
|description=Trigger #1. Moving the Scarab to the unplaceable terrain
|players=
*''???''
|conditions=
*Current Player brings at least 1 Scarab to [location: arena]
|actions=
*Move all Scarabs from [location: arena] to [location: Unplaceable terran]
*Preserve Trigger
}}

{{StarCraft Trigger
|description=Trigger #2. Moving the Scarab to the unit in which you want to damage
|players=
*''???''
|conditions=
*''When you are damaging the enemy''
|actions=
*Move all Scarabs from [location: Storage] to [location: Enemy]
*Preserve Trigger
}}

=== Notes ===
The trigger order here is important. For some reason, exploding the Scarab by moving it to an unwalkable area only works after one trigger cycle. Therefore, the trigger that moves it to an unwalkable area has to be positioned before the trigger which moves the Scarab next to the enemy.
Because the Scarab is caused to explode, one can use human players! You can also allow Scarab damage to be upgraded, making the spell do more damage.

This system is first described here: [http://www.staredit.net/topic/8240/0/ Direct damage system thread].

A test map by JaFF is also available: [http://www.staredit.net/topic/8240/2/#170456 Test map of new DDS]

[[Category:StarCraft]]
[[Category:Tutorials]]

Grid Systems

2015-11-19T01:14:24Z

Roy: Formatting

==Introduction==

A grid is a method of 'marking' certain points (or 'coordinates') on a map without creating a location for each of the points. The ultimate goal of any grid is to move a location to the desired marked point and perform some actions at that point using that location. Often, having a grid system is the only way to achieve a goal, which is why grids are very important aspects of mapping.

There are three main typse of grids: Static Grids, Mobile Grids and Location Grids. Each type has its own advantages and disadvantages.

Some maps, such as Reflector and Maze Generator use multiple grid systems to achive their disired outcomes.

Static and Mobile grids use the way SC selects units from a location that are subject to certain actions. To understand how these two grid systems work, one must first understand the SC mechanics the systems are based on.

==SC Mechanics Regarding Static and Mobile Grids==

The three most important actions for these grid systems are "Move (Center) Location", "Give Units to Player" and "Remove Units". When any of these actions are performed on a group of units in a location, SC selects the leftmost, last created or moved (in that order) unit. For example, arrange a test map with 5 Terran Marines owned by P1 (red) scattered in a location called "Arena" and a separate, 1x1 tile location called "scan", as shown:

[[File:Gridexample2.png]]

These marines are our grid coordinates. They will represent the points on the map where we want to move our "scan" location. Note that all Marines are placed with a fine grid; from the two marines that are one under another, the top one was created first.

The first and simplest test would be to create a unit (Khalys Crystal) at the location of the first Marine (bottom left). To do that, make the following trigger:

Trigger("Player 1"){
Conditions:
Switch("Switch1", set);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Terran Marine", "Arena", "scan");
Give Units to Player("Current Player", "Player 2", "Terran Marine", 1, "Arena");
Remove Unit At Location("Player 2", "Terran Marine", 1, "Arena");
Create Unit("Player 1", "Khalis Crystal", 1, "scan");
Set Switch("Switch1", clear);
}

Once "Switch1" is set, the trigger will execute the actions in the specified order:

1. Move the location "scan" on the first Terran Marine it finds in the location "Arena". It will first find the leftmost Marine(s) in "Arena" - the one with the lowest X coordinate - and since there are no other marines with the same X coordinate, it will select the bottom-left Marine as desired, and move the location "scan" on it.
2. Select the bottom-left Marine with the same selction process and give it to Player 2.
3. Remove the only Marine owned by Player 2 in "Arena", which is the one it just gave to that player
4. Create Khalis Crystal at 'scan', which is at the location of the Marine that just got removed
5. Clear "Switch1" so that this trigger runs only once on request.

After this trigger runs, the situation will look like this:

[[File:Gridexample3.png]]

Suppose it is needed to create a Khalis Crystal at the location of the Marine that is right below the middle of "Arena". This means the system will have to 'skip' 2 Marines and center "scan" on the required one. To achieve that, the following trigger must be run:

Trigger("Player 1"){
Conditions:
Switch("Switch2", set);

Actions:
Comment("");
Preserve Trigger();
Give Units to Player("Current Player", "Player 2", "Terran Marine", 2, "Arena");
Move Location("Current Player", "Terran Marine", "Arena", "scan");
Remove Unit At Location("Current Player", "Terran Marine", 1, "Arena");
Create Unit("Player 1", "Khalis Crystal", 1, "scan");
Give Units to Player("Player 2", "Player 1", "Terran Marine", All, "Arena");
Set Switch("Switch2", clear);

Following the same logics, it will skip two marines, remove the next one it finds and create the crystal at his position. After the trigger runs, the situation will look like this:

[[File:Gridexample4.png]]

The trickiest case is when several units have the same X coordinate. In this case, SC will select the one that has been created, moved or placed last. Hence, if you followed the guidelines of this article and placed the top Marine (of the two that have equal X coordianates) first, and the bottom Marine last of the two, then running the first trigger associated with "Switch1" will create the crystal at the bottom Marine's location. Hence if you need a set of units all in with the same X coordinate, to know the order of their selection you must know the order in which they were created (or placed). If you want them to be selected from bottom to top, you must create (or place) them in reverse order - from top to bottom.

==Static Grids==

A Static Grid uses preplaced (often burrowed) units as its coordinates. These units are not moved and in most cases, not removed, hence the name 'static'. These grids are very often used to save locations at the cost of units. Static grids function as it was shown in the previous section of this article; the only difference is that most static grids do not remove the grid units, so they can be used again.

Here is a setup of the most common static grid:

The burrowed units are Zerg Zerglings owned by Player 9 (neutral). All burrowed units used in Static grids should be owned by neutral players at all times, because burrowed units owned by active players tend to unburrow when given to another palyer. Note that the Zerglings are placed with a fine grid (even though it may appear that they are lower than the grid points). It is important that each Zergling in every column is placed after the one above it - it is just another way of saying that you must create them from bottom to top in order for the SC unit selection to be consistent.

The action for this example would be an explosion at any desired position. The trigger for it would be similar to this:

Trigger("Player 1"){
Conditions:
Switch("Switch3", set);

Actions:
Comment("");
Preserve Trigger();
Give Units to Player("Player 9", "Player 10", "Zerg Zergling", N, "Arena");
Move Location("Player 9", "Zerg Zergling", "Arena", "scan");
Give Units to Player("Player 10", "Player 9", "Zerg Zergling", All, "Arena");
Create Unit("Player 2", "Terran Wraith", 1, "scan");
Kill Unit At Location("Player 2", "Terran Wraith", All, "scan");
Set Switch("Switch3", clear);
}

The given trigger is generalized to work with any number of grid units, as long as the variable N (in the first 'give units' command) is less than or equal to the number of grid units in the location "Arena" (in this case, there are 25 Zerglings). The units are given between two neutral players (9 and 10) to avoid unburrowing problems.

Problems

Static grids use the "Give Units" command to work, which is one of the most 'lag-heavy' commands in SC. Constantly giving too many units can make the map lag a lot, which is why constantly running big Static grids is a bad idea.

Another problem is the amount of units the grid uses. Some maps such as RPGs or RPs require a lot of units, which conflicts with the grid - it may happen that a too big Static grid will require too many units, causing the map to hit the unit limit.

Try not to use big and accurate (meaning the distance between the grid units is small) grids in areas the player may look at - even if it will not lag because of the give commands, it may lag because of too many units on-screen (even if they are burrowed, they still have this effect).

==Mobile Grids==

Mobile grids are more 'fragile' systems than Static grids, but offer greater capabilities. A Mobile grid is a system that creates a set of air units (in most cases), using the "Remove Unit" action centers a location on the desired air unit and removes the remaining air units. To understand how Mobile grids work, one must understand the patterns in which certain air units are created and chosen by triggers.

There are two main types of Mobile grids: 1x1 and 1.5x1.5 grids. These sizes denote the distance in tiles between nearby grid points in the resulting grid.

The center of a Mobile grid is the location (or coordinate) where the first unit of the grid was created. An accurate mobile grid is one that produces consistent, equally spaced grid points.

1x1

An accurate, 9-unit 1x1 mobile grid is created with the following trigger:

Trigger("Player 1"){
Conditions:
Switch("Switch4", set);

Actions:
Comment("");
Preserve Trigger();
Set Switch("Switch4", clear);
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
Create Unit("Player 2", "Protoss Observer", 1, "Arena");
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
Create Unit("Player 2", "Protoss Observer", 1, "Arena");
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
Create Unit("Player 2", "Protoss Observer", 1, "Arena");
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
Create Unit("Player 2", "Protoss Observer", 1, "Arena");
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
}

//-----------------------------------------------------------------//

Meaning that one must create a Scourge at the center of th egrid, then an Observer at the center of the grid, then a Scourge, then an Observer... and so on. It is very important for the first unit to be a Scourge. The resulting grid contains 9 units, and the grid points are spaced by one tile, hence it is a 1x1 grid.

The units of this grid are created in the following pattern: 
8 7 6 
9 1 5 
2 3 4 

To center a location on the desired unit, one must know the order in which the units are selected by SC: 
2 4 7 
1 6 8 
3 5 9 

Thus, to center a location on the upper-right grid point (in the above diagram, represented by '7'), one must first remove 6 units from the grid and then center the location. If one could see triggers in slow-motion, this is how the creation and removal (or in this case, killing) of the grid units would occur:

[[File:Grid_1.gif]]
Do note that this .gif image was represented using SCMDraft and not in-game.

1.5x1.5

An accurate, 9-unit 1.5x1.5 mobile grid is created with the following trigger:

Trigger("Player 1"){
Conditions:
Switch("Switch5", set);

Actions:
Comment("");
Preserve Trigger();
Set Switch("Switch5", clear);
Create Unit("Player 2", "Zerg Devourer", 9, "Arena");
}

//-----------------------------------------------------------------//

It is important that one uses Protoss Arbiters, Zerg Devourers, Zerg Guardians, or Zerg Mutalisks for 1.5x1.5 grids.

The units of this grid are created in the following pattern: 
7 6 5 
8 1 4 
9 2 3 

To center a location on the desired unit, one must know the order in which the units are selected by SC: 
3 4 7 
2 6 8 
1 5 9 

Thus, to center a location on the middle-right grid point (in the above diagram, represented by '8'), one must first remove 7 units from the grid and then center the location. If one could see triggers in slow-motion, this is how the creation and removal (or in this case, killing) of Devourers would occur:

[[File:Grid_2.gif]]

It is important that the grid units are removed and the location is centered in the same trigger cycle (or even in the same trigger), because other air units or triggers may disrupt the air units of the grid if they are left unremoved for atleast one trigger loop.

Problems

Mobile grids cannot work properly if there are air units in their path, as they will cause the grid units to be displaced, bugging the grid. One must always make sure there are no air units atleast in the area where the grid is about to be made.

Lag is a problem of Mobile grids, just like it is of Static grids, the only difference is that now you create/remove units instead of giving them, which is quite laggy as well.

Lag Reduction and Partial Mobile Grids

A Partial Mobile grid is one where the units of the grid do not form a square with a center i nthe middle of the grid. In other words, it is any grid other than a 9, 25, 49, etc. unit grid.

If only one grid point is needed at a time, one can create the grid only until that point (thus making it a Partial grid). For example, one is interested in the grid point to the right of the grid center, then it is possible to create the grid units as follows:

For a 1x1 grid: 
X X X 
X 1 5 
2 3 4 

And for a 1.5x1.5 grid: 
X X X 
X 1 4 
X 2 3 

With 'X' representing no units at the grid point. This allows to create less units, hence cause less lag. Compare this with the unit selection patterns:

For a 1x1: 
1 4 7 
3 6 8 
2 5 9 

For a 1.5x1.5: 
3 4 7 
2 6 8 
1 5 9 

One can see that removing 4 units for a 1x1 grid and 2 units for a 1.5x1.5 grid and then centering the location will give the required result - the rightmost grid point is selected.

Examples

Mobile grids are a powerful tool in a mapper's arsenal, as it allows to do most things a Static grid can do without any preplaced units. For example, creating a line of crystals.

Spaced by 1 tile. Direction: up.

Trigger("Player 1"){
Conditions:
Switch("Switch6", set);

Actions:
Comment("");
Preserve Trigger();
Create Unit("Player 2", "Zerg Scourge", 1, "Grid");
Create Unit("Player 2", "Protoss Observer", 1, "Grid");
Create Unit("Player 2", "Zerg Scourge", 1, "Grid");
Create Unit("Player 2", "Protoss Observer", 1, "Grid");
Create Unit("Player 2", "Zerg Scourge", 1, "Grid");
Create Unit("Player 2", "Protoss Observer", 1, "Grid");
Create Unit("Player 2", "Zerg Scourge", 1, "Grid");
Remove Unit At Location("Player 2", "Men", 1, "Anywhere");
Move Location("Player 2", "Men", "Anywhere", "Grid");
Remove Unit At Location("Player 2", "Men", All, "Anywhere");
Create Unit("Current Player", "Khalis Crystal", 1, "Grid");
}

//-----------------------------------------------------------------//

Spaced by 1.5 tiles. Direction: bottom-right.

Trigger("Player 1"){
Conditions:
Switch("Switch7", set);

Actions:
Comment("");
Preserve Trigger();
Create Unit("Player 2", "Zerg Devourer", 3, "Grid");
Remove Unit At Location("Player 2", "Men", 2, "Anywhere");
Move Location("Player 2", "Men", "Anywhere", "Grid");
Remove Unit At Location("Player 2", "Men", All, "Anywhere");
Create Unit("Current Player", "Khalis Crystal", 1, "Grid");
}

//-----------------------------------------------------------------//

==The Offset Glitch==

If a grid is created incorrectly, even if following all the instructions and precautions, one is most probably experiencing the Offset Glitch.

The Offset Glitch often occurs when the mobile grid is created at a unit that can move around (like a hero in an RPG). Please note that the unit's motion does not cause the glitch by itself, it is the unit's position that causes it.

SC divides each tile into 4 equal square segments or subtiles. These subtiles are equivallent to the fine grid in the editor. The first unit of the mobile grid is always created directly at the specified location, however, all the following units are created centered on the nearest fine grid point (where subtiles' corners meet). Hence, if the grid center is not on one of the fine grid points, the grid units are created incorrectly, thus ruining the grid:

[[File:OffsetGlitch.png]]

To prevent this, first use a partial grid to move the center one grid point south (down) or south-west (bottom-left). That is, create 2 units (using a 1x1 grid); centre your mobile grid location on a unit there (this will be the south unit). Remove both units, then create a new unit at the mobile grid location (remember, this is now south of where we want the centre). Now we need to move the location back up to where we want it (but centred correctly). To do so, create 7 units and centre the mobile grid location on any unit just created (this will be north of your current location.) This will result in the grid center being centered on the subtile grid without offsets, hence allowing you to use mobile grids normally from that point.

==[[Location Grid|Location Grids]]==
'''See also: [[Location Grid]]'''

===SC Mechanics Regarding Location Grids===
To understand how Location grids work, one must know three facts:

1. A location can never leave the map in any of its dimensions.

2. If a location is attempted to be centered on a unit, the center of the location will be moved as close as possible to the center of the unit in both coordinates without breaking rule (1).

3. If a location A is attempted to be centered on a non-existing unit in location B, then the center of location A will be moved as close as possible to the center of location B in both coordinates without breaking rule (1).

Location grids are capable of moving a location to any grid point on the map. The closer the grid points are to each other, the more accurate the grid. Grid points are defined by the map maker - he has the ability to make a grid of any accuracy within the map limits.

The basic idea of Location grids is to use sets of locations as the X and Y axis along the map borders. Here is an example of a 1-tile-accurate Location grid:

[[File:GridExample8.png]]

The 1x1 tile "X=0" and "Y=0" locations are the coordinate start, the zeros for X and Y. All the axis locations must touch at least two borders of the map (all the shown locations touch the bottom and left borders of the map). All locations centers coinside with the corresponding tile centers. The shown grid can center a location on 9 possible points (3*3=9) buy using rules (1) and (3). One of the axis is chosen to be the 'static' one, and th eother - the dynamic one. For this example, let X be static and Y be dynamic.

Then the actions taken to center a location on a grid point X=1, Y=2 are the following:
1. Center a 'middleman' location "scan" on the required X coordinate, X=1:

[[File:Gridexample9.png]]

2. Center the required Y coordinate location (Y=2) on the 'middleman' location "scan":

[[File:GridExample10.png]]

The two triggers that rearrange the locations for this specific case are:

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "X Coordinate", Exactly, 1);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "X=1", "scan");
Set Deaths("Current Player", "X Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Y Coordinate", Exactly, 2);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "scan", "Y=2");
Set Deaths("Current Player", "Y Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

First, it centers the 1x1 tile "scan" location on the required coordinate of X, then it centers the required coordinate of Y on "scan". This two-step process is much more trigger-efficient than having to make a trigger per grid point.

Note that all the trigger code in the Location Grid section is not valid in the text trigger editor, as the parameters "X Coordinate" and "Y Coordinate" are not accepted - they must be original unit names. They are used simply to make the triggers understandable.

The general trigger system for this grid would be the following:

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "X Coordinate", Exactly, 0);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "X=0", "scan");
Set Deaths("Current Player", "X Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "X Coordinate", Exactly, 1);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "X=1", "scan");
Set Deaths("Current Player", "X Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "X Coordinate", Exactly, 2);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "X=2", "scan");
Set Deaths("Current Player", "X Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Y Coordinate", Exactly, 0);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "scan", "Y=0");
Set Deaths("Current Player", "Y Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Y Coordinate", Exactly, 1);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "scan", "Y=1");
Set Deaths("Current Player", "Y Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Y Coordinate", Exactly, 2);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "scan", "Y=2");
Set Deaths("Current Player", "Y Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

===Map Coverage===

Since each next coordinate location is two tiles longer than the previous one, it is clear that with the setup shown above it is possible to cover only 25% of the map area. Meaning that each such set of coordinate locations covers one corner of a map. A logical solution is to make similar sets of locations for the other 3 corners of the map, but that will require too many locations. Alternatively, one could create 'origin' locations for each corner and reuse the same set of coordinate locations for all corners of the map buy centering them on the required origin locations. So if it needed to center a location on a point in the upper-right portion of the map, it would be enough to center the already existng coordinate locations on the new origin and work from there.

===Pros and Cons===

Though lagless, Location grids eat up locations very fast. The good thing about them is that they make the use of locations not needed - they can detect whether a unit is in a location or not, detect a unit's coordinates and create events at locations; so if all used areas of the map are covered by a Location grid system, other locations are simply not needed.

==Grid Combinations==

It is often wise to combine grid systems to complement the weaknesses of one system by the strengths of another.

===Static and Mobile===

It is possible to reduce lag caused by a Mobile grid traveling too much by creating a spread-out Static grid and launching the Mobile grid from one of the points of the Static grid.

===Static and Location===

To save locations (though sacrifice units) used in a Location grid, it is possible to replace the static axis of the grid with a line of units. One advantage of this is the ability to cover the entire map without going through the trouble of moving the coordinate locations from one corner to another - there are no coordinate locations; all that is needed are two lines of units along two parallel borders of the map or you can use shift locations to cut the units in half. Be advised that such a combination will not allow intense use due to lag that is brought into the system by the static grid unless you have enough units available so you don't have to give any at all.

===Mobile and Location===

Another way of saving locations in a Location grid is making it less accurate and using its grid points as launch points for a more accurate, albeit more laggy and air unit incompatible, Mobile grid.

===Static, Mobile and Location===

The combination of all three: use preplaced units as the static axis for the inaccurate Location grid, and use that grid's points to launch Mobile grids.

[[Category:StarCraft]]
[[Category:Tutorials]]

Grid Systems

2015-11-19T01:04:25Z

Roy: Formatting

Grid Systems

2015-11-19T00:55:22Z

Roy:

==Introduction==

A grid is a method of 'marking' certain points (or 'coordinates') on a map without creating a location for each of the points. The ultimate goal of any grid is to move a location to the desired marked point and perform some actions at that point using that location. Often, having a grid system is the only way to achieve a goal, which is why grids are very important aspects of mapping.

There are three main typse of grids: Static Grids, Mobile Grids and Location Grids. Each type has its own advantages and disadvantages.

Some maps, such as Reflector and Maze Generator use multiple grid systems to achive their disired outcomes.

Static and Mobile grids use the way SC selects units from a location that are subject to certain actions. To understand how these two grid systems work, one must first understand the SC mechanics the systems are based on.

==SC Mechanics Regarding Static and Mobile Grids==

The three most important actions for these grid systems are "Move (Center) Location", "Give Units to Player" and "Remove Units". When any of these actions are performed on a group of units in a location, SC selects the leftmost, last created or moved (in that order) unit. For example, arrange a test map with 5 Terran Marines owned by P1 (red) scattered in a location called "Arena" and a separate, 1x1 tile location called "scan", as shown:

[[File:Gridexample2.png]]

These marines are our grid coordinates. They will represent the points on the map where we want to move our "scan" location. Note that all Marines are placed with a fine grid; from the two marines that are one under another, the top one was created first.

The first and simplest test would be to create a unit (Khalys Crystal) at the location of the first Marine (bottom left). To do that, make the following trigger:
Code
Trigger("Player 1"){
Conditions:
Switch("Switch1", set);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Terran Marine", "Arena", "scan");
Give Units to Player("Current Player", "Player 2", "Terran Marine", 1, "Arena");
Remove Unit At Location("Player 2", "Terran Marine", 1, "Arena");
Create Unit("Player 1", "Khalis Crystal", 1, "scan");
Set Switch("Switch1", clear);

Once "Switch1" is set, the trigger will execute the actions in the specified order:

1. Move the location "scan" on the first Terran Marine it finds in the location "Arena". It will first find the leftmost Marine(s) in "Arena" - the one with the lowest X coordinate - and since there are no other marines with the same X coordinate, it will select the bottom-left Marine as desired, and move the location "scan" on it.
2. Select the bottom-left Marine with the same selction process and give it to Player 2.
3. Remove the only Marine owned by Player 2 in "Arena", which is the one it just gave to that player
4. Create Khalis Crystal at 'scan', which is at the location of the Marine that just got removed
5. Clear "Switch1" so that this trigger runs only once on request.

After this trigger runs, the situation will look like this:

[[File:Gridexample3.png]]

Suppose it is needed to create a Khalis Crystal at the location of the Marine that is right below the middle of "Arena". This means the system will have to 'skip' 2 Marines and center "scan" on the required one. To achieve that, the following trigger must be run:
Code
Trigger("Player 1"){
Conditions:
Switch("Switch2", set);

Actions:
Comment("");
Preserve Trigger();
Give Units to Player("Current Player", "Player 2", "Terran Marine", 2, "Arena");
Move Location("Current Player", "Terran Marine", "Arena", "scan");
Remove Unit At Location("Current Player", "Terran Marine", 1, "Arena");
Create Unit("Player 1", "Khalis Crystal", 1, "scan");
Give Units to Player("Player 2", "Player 1", "Terran Marine", All, "Arena");
Set Switch("Switch2", clear);

Following the same logics, it will skip two marines, remove the next one it finds and create the crystal at his position. After the trigger runs, the situation will look like this:

[[File:Gridexample4.png]]

The trickiest case is when several units have the same X coordinate. In this case, SC will select the one that has been created, moved or placed last. Hence, if you followed the guidelines of this article and placed the top Marine (of the two that have equal X coordianates) first, and the bottom Marine last of the two, then running the first trigger associated with "Switch1" will create the crystal at the bottom Marine's location. Hence if you need a set of units all in with the same X coordinate, to know the order of their selection you must know the order in which they were created (or placed). If you want them to be selected from bottom to top, you must create (or place) them in reverse order - from top to bottom.

==Static Grids==

A Static Grid uses preplaced (often burrowed) units as its coordinates. These units are not moved and in most cases, not removed, hence the name 'static'. These grids are very often used to save locations at the cost of units. Static grids function as it was shown in the previous section of this article; the only difference is that most static grids do not remove the grid units, so they can be used again.

Here is a setup of the most common static grid:

The burrowed units are Zerg Zerglings owned by Player 9 (neutral). All burrowed units used in Static grids should be owned by neutral players at all times, because burrowed units owned by active players tend to unburrow when given to another palyer. Note that the Zerglings are placed with a fine grid (even though it may appear that they are lower than the grid points). It is important that each Zergling in every column is placed after the one above it - it is just another way of saying that you must create them from bottom to top in order for the SC unit selection to be consistent.

The action for this example would be an explosion at any desired position. The trigger for it would be similar to this:
Code
Trigger("Player 1"){
Conditions:
Switch("Switch3", set);

Actions:
Comment("");
Preserve Trigger();
Give Units to Player("Player 9", "Player 10", "Zerg Zergling", N, "Arena");
Move Location("Player 9", "Zerg Zergling", "Arena", "scan");
Give Units to Player("Player 10", "Player 9", "Zerg Zergling", All, "Arena");
Create Unit("Player 2", "Terran Wraith", 1, "scan");
Kill Unit At Location("Player 2", "Terran Wraith", All, "scan");
Set Switch("Switch3", clear);

The given trigger is generalized to work with any number of grid units, as long as the variable N (in the first 'give units' command) is less than or equal to the number of grid units in the location "Arena" (in this case, there are 25 Zerglings). The units are given between two neutral players (9 and 10) to avoid unburrowing problems.

Problems

Static grids use the "Give Units" command to work, which is one of the most 'lag-heavy' commands in SC. Constantly giving too many units can make the map lag a lot, which is why constantly running big Static grids is a bad idea.

Another problem is the amount of units the grid uses. Some maps such as RPGs or RPs require a lot of units, which conflicts with the grid - it may happen that a too big Static grid will require too many units, causing the map to hit the unit limit.

Try not to use big and accurate (meaning the distance between the grid units is small) grids in areas the player may look at - even if it will not lag because of the give commands, it may lag because of too many units on-screen (even if they are burrowed, they still have this effect).

==Mobile Grids==

Mobile grids are more 'fragile' systems than Static grids, but offer greater capabilities. A Mobile grid is a system that creates a set of air units (in most cases), using the "Remove Unit" action centers a location on the desired air unit and removes the remaining air units. To understand how Mobile grids work, one must understand the patterns in which certain air units are created and chosen by triggers.

There are two main types of Mobile grids: 1x1 and 1.5x1.5 grids. These sizes denote the distance in tiles between nearby grid points in the resulting grid.

The center of a Mobile grid is the location (or coordinate) where the first unit of the grid was created. An accurate mobile grid is one that produces consistent, equally spaced grid points.

1x1

An accurate, 9-unit 1x1 mobile grid is created with the following trigger:
Code
Trigger("Player 1"){
Conditions:
Switch("Switch4", set);

Actions:
Comment("");
Preserve Trigger();
Set Switch("Switch4", clear);
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
Create Unit("Player 2", "Protoss Observer", 1, "Arena");
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
Create Unit("Player 2", "Protoss Observer", 1, "Arena");
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
Create Unit("Player 2", "Protoss Observer", 1, "Arena");
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
Create Unit("Player 2", "Protoss Observer", 1, "Arena");
Create Unit("Player 2", "Zerg Scourge", 1, "Arena");
}

//-----------------------------------------------------------------//

Meaning that one must create a Scourge at the center of th egrid, then an Observer at the center of the grid, then a Scourge, then an Observer... and so on. It is very important for the first unit to be a Scourge. The resulting grid contains 9 units, and the grid points are spaced by one tile, hence it is a 1x1 grid.

The units of this grid are created in the following pattern: 
8 7 6 
9 1 5 
2 3 4 

To center a location on the desired unit, one must know the order in which the units are selected by SC: 
2 4 7 
1 6 8 
3 5 9 

Thus, to center a location on the upper-right grid point (in the above diagram, represented by '7'), one must first remove 6 units from the grid and then center the location. If one could see triggers in slow-motion, this is how the creation and removal (or in this case, killing) of the grid units would occur:

[[File:Grid_1.gif]]
Do note that this .gif image was represented using SCMDraft and not in-game.

1.5x1.5

An accurate, 9-unit 1.5x1.5 mobile grid is created with the following trigger:
Code
Trigger("Player 1"){
Conditions:
Switch("Switch5", set);

Actions:
Comment("");
Preserve Trigger();
Set Switch("Switch5", clear);
Create Unit("Player 2", "Zerg Devourer", 9, "Arena");
}

//-----------------------------------------------------------------//

It is important that one uses Protoss Arbiters, Zerg Devourers, Zerg Guardians, or Zerg Mutalisks for 1.5x1.5 grids.

The units of this grid are created in the following pattern: 
7 6 5 
8 1 4 
9 2 3 

To center a location on the desired unit, one must know the order in which the units are selected by SC: 
3 4 7 
2 6 8 
1 5 9 

Thus, to center a location on the middle-right grid point (in the above diagram, represented by '8'), one must first remove 7 units from the grid and then center the location. If one could see triggers in slow-motion, this is how the creation and removal (or in this case, killing) of Devourers would occur:

[[File:Grid_2.gif]]

It is important that the grid units are removed and the location is centered in the same trigger cycle (or even in the same trigger), because other air units or triggers may disrupt the air units of the grid if they are left unremoved for atleast one trigger loop.

Problems

Mobile grids cannot work properly if there are air units in their path, as they will cause the grid units to be displaced, bugging the grid. One must always make sure there are no air units atleast in the area where the grid is about to be made.

Lag is a problem of Mobile grids, just like it is of Static grids, the only difference is that now you create/remove units instead of giving them, which is quite laggy as well.

Lag Reduction and Partial Mobile Grids

A Partial Mobile grid is one where the units of the grid do not form a square with a center i nthe middle of the grid. In other words, it is any grid other than a 9, 25, 49, etc. unit grid.

If only one grid point is needed at a time, one can create the grid only until that point (thus making it a Partial grid). For example, one is interested in the grid point to the right of the grid center, then it is possible to create the grid units as follows:

For a 1x1 grid: 
X X X 
X 1 5 
2 3 4 

And for a 1.5x1.5 grid: 
X X X 
X 1 4 
X 2 3 

With 'X' representing no units at the grid point. This allows to create less units, hence cause less lag. Compare this with the unit selection patterns:

For a 1x1: 
1 4 7 
3 6 8 
2 5 9 

For a 1.5x1.5: 
3 4 7 
2 6 8 
1 5 9 

One can see that removing 4 units for a 1x1 grid and 2 units for a 1.5x1.5 grid and then centering the location will give the required result - the rightmost grid point is selected.

Examples

Mobile grids are a powerful tool in a mapper's arsenal, as it allows to do most things a Static grid can do without any preplaced units. For example, creating a line of crystals.

Spaced by 1 tile. Direction: up.
Code
Trigger("Player 1"){
Conditions:
Switch("Switch6", set);

Actions:
Comment("");
Preserve Trigger();
Create Unit("Player 2", "Zerg Scourge", 1, "Grid");
Create Unit("Player 2", "Protoss Observer", 1, "Grid");
Create Unit("Player 2", "Zerg Scourge", 1, "Grid");
Create Unit("Player 2", "Protoss Observer", 1, "Grid");
Create Unit("Player 2", "Zerg Scourge", 1, "Grid");
Create Unit("Player 2", "Protoss Observer", 1, "Grid");
Create Unit("Player 2", "Zerg Scourge", 1, "Grid");
Remove Unit At Location("Player 2", "Men", 1, "Anywhere");
Move Location("Player 2", "Men", "Anywhere", "Grid");
Remove Unit At Location("Player 2", "Men", All, "Anywhere");
Create Unit("Current Player", "Khalis Crystal", 1, "Grid");
}

//-----------------------------------------------------------------//

Spaced by 1.5 tiles. Direction: bottom-right.
Code
Trigger("Player 1"){
Conditions:
Switch("Switch7", set);

Actions:
Comment("");
Preserve Trigger();
Create Unit("Player 2", "Zerg Devourer", 3, "Grid");
Remove Unit At Location("Player 2", "Men", 2, "Anywhere");
Move Location("Player 2", "Men", "Anywhere", "Grid");
Remove Unit At Location("Player 2", "Men", All, "Anywhere");
Create Unit("Current Player", "Khalis Crystal", 1, "Grid");
}

//-----------------------------------------------------------------//

==The Offset Glitch==

If a grid is created incorrectly, even if following all the instructions and precautions, one is most probably experiencing the Offset Glitch.

The Offset Glitch often occurs when the mobile grid is created at a unit that can move around (like a hero in an RPG). Please note that the unit's motion does not cause the glitch by itself, it is the unit's position that causes it.

SC divides each tile into 4 equal square segments or subtiles. These subtiles are equivallent to the fine grid in the editor. The first unit of the mobile grid is always created directly at the specified location, however, all the following units are created centered on the nearest fine grid point (where subtiles' corners meet). Hence, if the grid center is not on one of the fine grid points, the grid units are created incorrectly, thus ruining the grid:

[[File:OffsetGlitch.png]]

To prevent this, first use a partial grid to move the center one grid point south (down) or south-west (bottom-left). That is, create 2 units (using a 1x1 grid); centre your mobile grid location on a unit there (this will be the south unit). Remove both units, then create a new unit at the mobile grid location (remember, this is now south of where we want the centre). Now we need to move the location back up to where we want it (but centred correctly). To do so, create 7 units and centre the mobile grid location on any unit just created (this will be north of your current location.) This will result in the grid center being centered on the subtile grid without offsets, hence allowing you to use mobile grids normally from that point.

==[[Location Grid|Location Grids]]==
'''See also: [[Location Grid]]'''

===SC Mechanics Regarding Location Grids===
To understand how Location grids work, one must know three facts:

1. A location can never leave the map in any of its dimensions.

2. If a location is attempted to be centered on a unit, the center of the location will be moved as close as possible to the center of the unit in both coordinates without breaking rule (1).

3. If a location A is attempted to be centered on a non-existing unit in location B, then the center of location A will be moved as close as possible to the center of location B in both coordinates without breaking rule (1).

Location grids are capable of moving a location to any grid point on the map. The closer the grid points are to each other, the more accurate the grid. Grid points are defined by the map maker - he has the ability to make a grid of any accuracy within the map limits.

The basic idea of Location grids is to use sets of locations as the X and Y axis along the map borders. Here is an example of a 1-tile-accurate Location grid:

[[File:GridExample8.png]]

The 1x1 tile "X=0" and "Y=0" locations are the coordinate start, the zeros for X and Y. All the axis locations must touch at least two borders of the map (all the shown locations touch the bottom and left borders of the map). All locations centers coinside with the corresponding tile centers. The shown grid can center a location on 9 possible points (3*3=9) buy using rules (1) and (3). One of the axis is chosen to be the 'static' one, and th eother - the dynamic one. For this example, let X be static and Y be dynamic.

Then the actions taken to center a location on a grid point X=1, Y=2 are the following:
1. Center a 'middleman' location "scan" on the required X coordinate, X=1:

[[File:Gridexample9.png]]

2. Center the required Y coordinate location (Y=2) on the 'middleman' location "scan":

[[File:GridExample10.png]]

The two triggers that rearrange the locations for this specific case are:
Code
Trigger("Player 1"){
Conditions:
Deaths("Current Player", "X Coordinate", Exactly, 1);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "X=1", "scan");
Set Deaths("Current Player", "X Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Y Coordinate", Exactly, 2);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "scan", "Y=2");
Set Deaths("Current Player", "Y Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

First, it centers the 1x1 tile "scan" location on the required coordinate of X, then it centers the required coordinate of Y on "scan". This two-step process is much more trigger-efficient than having to make a trigger per grid point.

Note that all the trigger code in the Location Grid section is not valid in the text trigger editor, as the parameters "X Coordinate" and "Y Coordinate" are not accepted - they must be original unit names. They are used simply to make the triggers understandable.

The general trigger system for this grid would be the following:
Code
Trigger("Player 1"){
Conditions:
Deaths("Current Player", "X Coordinate", Exactly, 0);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "X=0", "scan");
Set Deaths("Current Player", "X Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "X Coordinate", Exactly, 1);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "X=1", "scan");
Set Deaths("Current Player", "X Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "X Coordinate", Exactly, 2);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "X=2", "scan");
Set Deaths("Current Player", "X Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Y Coordinate", Exactly, 0);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "scan", "Y=0");
Set Deaths("Current Player", "Y Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Y Coordinate", Exactly, 1);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "scan", "Y=1");
Set Deaths("Current Player", "Y Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Y Coordinate", Exactly, 2);

Actions:
Comment("");
Preserve Trigger();
Move Location("Current Player", "Cave-in", "scan", "Y=2");
Set Deaths("Current Player", "Y Coordinate", Set To, 0);
}

//-----------------------------------------------------------------//

===Map Coverage===

Since each next coordinate location is two tiles longer than the previous one, it is clear that with the setup shown above it is possible to cover only 25% of the map area. Meaning that each such set of coordinate locations covers one corner of a map. A logical solution is to make similar sets of locations for the other 3 corners of the map, but that will require too many locations. Alternatively, one could create 'origin' locations for each corner and reuse the same set of coordinate locations for all corners of the map buy centering them on the required origin locations. So if it needed to center a location on a point in the upper-right portion of the map, it would be enough to center the already existng coordinate locations on the new origin and work from there.

===Pros and Cons===

Though lagless, Location grids eat up locations very fast. The good thing about them is that they make the use of locations not needed - they can detect whether a unit is in a location or not, detect a unit's coordinates and create events at locations; so if all used areas of the map are covered by a Location grid system, other locations are simply not needed.

==Grid Combinations==

It is often wise to combine grid systems to complement the weaknesses of one system by the strengths of another.

===Static and Mobile===

It is possible to reduce lag caused by a Mobile grid traveling too much by creating a spread-out Static grid and launching the Mobile grid from one of the points of the Static grid.

===Static and Location===

To save locations (though sacrifice units) used in a Location grid, it is possible to replace the static axis of the grid with a line of units. One advantage of this is the ability to cover the entire map without going through the trouble of moving the coordinate locations from one corner to another - there are no coordinate locations; all that is needed are two lines of units along two parallel borders of the map or you can use shift locations to cut the units in half. Be advised that such a combination will not allow intense use due to lag that is brought into the system by the static grid unless you have enough units available so you don't have to give any at all.

===Mobile and Location===

Another way of saving locations in a Location grid is making it less accurate and using its grid points as launch points for a more accurate, albeit more laggy and air unit incompatible, Mobile grid.

===Static, Mobile and Location===

The combination of all three: use preplaced units as the static axis for the inaccurate Location grid, and use that grid's points to launch Mobile grids.

[[Category:StarCraft]]
[[Category:Tutorials]]