I'm turning completely crazy because of one strange phenomena which ruins my map, I've spend the whole day trying to figure out what and why happens but it's beyond me. [u]This is the situation:[/u] I'm working on a chess map. There is a static grid made of burrowed P8 Infested Terrans; every 3rd box (normal size grid, SCM Draft2) there's an Infested Terran so they are not too close to each other. An IT represents a single position. By casting Disruption Field with your Corsair you can select an unit (unburrowed unit, not an IT) and by casting it again on another location you order it to move there, but only if the path to it is free. To check if the path between starting and ending point is free I use the static grid of IT's. First I move a location ontop of the unit which covers all the spaces around it as well (a 3x3 location). Then by giving a number of IT's to another player (P7) I select one IT and center the 3x3 location [i]and[/i] a checking location on it. Then I just repeat the process until all the spots between starting and ending point have a checking location on them. This is done practically instantly in all possible directions. As it is chess, certain units can only move in specific directions like only diagonal or vertical, etc. When all the checking locations are in place, it checks if the selected unit is able to move to that location and if the spots between start and end are not already taken. [u]This is the problem:[/u] I noticed that when I ordered an unit to the edge of the game-board and tried to move it from there something went wrong. Suddenly a Bishop could not move diagonal but only horizontal/vertical and vica versa for the Rook. After hours of testing I am pretty sure about what is going wrong. In the case of the Bishop the check locations should be at North West, NE, SE and SW. However sometimes it is NW, E, SE and SW; or NW, NE, E, W; or something similair wrong. The stupid thing is, is that I have not discovered any pattern in when it does or not does go wrong. Sometimes the locations are placed perfectly but when you move one box to the left the locations are NOT placed as they should. They stay constant though: so if at one spot the locations are placed as they should then every time you are at that spot they will be placed as they should, same goes for errors. In case it is all a bit confusing I created two masterpieces of art. See attached images. [u]What I have already tried:[/u] - I've removed and replaced the Infested Terrans static grid multiple times - Extended the size of the grid not rule out 'bounce' errors (like bouncing locations near edge of the map) - Removed and changed terrain multiple times - Re-checked all triggers for possible errors - Re-checked all locations for possible size errors If someone is up to it I'll send the map but it has nearly 1300 lines of code, though a lot are just triggers which repeat themselves slighty different.

I'm turning completely crazy because of one strange phenomena which ruins my map, I've spend the whole day trying to figure out what and why happens but it's beyond me.

This is the situation:

I'm working on a chess map. There is a static grid made of burrowed P8 Infested Terrans; every 3rd box (normal size grid, SCM Draft2) there's an Infested Terran so they are not too close to each other. An IT represents a single position. By casting Disruption Field with your Corsair you can select an unit (unburrowed unit, not an IT) and by casting it again on another location you order it to move there, but only if the path to it is free.

To check if the path between starting and ending point is free I use the static grid of IT's. First I move a location ontop of the unit which covers all the spaces around it as well (a 3x3 location). Then by giving a number of IT's to another player (P7) I select one IT and center the 3x3 location and a checking location on it. Then I just repeat the process until all the spots between starting and ending point have a checking location on them. This is done practically instantly in all possible directions.

As it is chess, certain units can only move in specific directions like only diagonal or vertical, etc.
When all the checking locations are in place, it checks if the selected unit is able to move to that location and if the spots between start and end are not already taken.

This is the problem:

I noticed that when I ordered an unit to the edge of the game-board and tried to move it from there something went wrong. Suddenly a Bishop could not move diagonal but only horizontal/vertical and vica versa for the Rook.
After hours of testing I am pretty sure about what is going wrong. In the case of the Bishop the check locations should be at North West, NE, SE and SW. However sometimes it is NW, E, SE and SW; or NW, NE, E, W; or something similair wrong.

The stupid thing is, is that I have not discovered any pattern in when it does or not does go wrong. Sometimes the locations are placed perfectly but when you move one box to the left the locations are NOT placed as they should. They stay constant though: so if at one spot the locations are placed as they should then every time you are at that spot they will be placed as they should, same goes for errors.

In case it is all a bit confusing I created two masterpieces of art. See attached images.

What I have already tried:

- I've removed and replaced the Infested Terrans static grid multiple times
- Extended the size of the grid not rule out 'bounce' errors (like bouncing locations near edge of the map)
- Removed and changed terrain multiple times
- Re-checked all triggers for possible errors
- Re-checked all locations for possible size errors


If someone is up to it I'll send the map but it has nearly 1300 lines of code, though a lot are just triggers which repeat themselves slighty different.

Which editor are you using? SCM Draft is funny in how it places units, even preplaced ones, it sets their ID numbers in the order they are placed.

Which editor are you using? SCM Draft is funny in how it places units, even preplaced ones, it sets their ID numbers in the order they are placed.

For finding adjacent boxes of 3x3 tiles you use a mobile grid I suppose. Using devourers you'd get a 2x2 grid, but you need either 3x3 with 9 units (not possible) or a 1,5 with 25 units. I'm not sure how you'd achieve that. Looking at your pictures I suppose your mobile grid locations are not perfectly placed above the burrowed IT's and may overlap to the wrong IT. A quick fix to check for that would be to make the location(s) of the mobile grid smaller. you could also create/kill test units at each of the mobile grid locations to check for correct centering on the IT's.

For finding adjacent boxes of 3x3 tiles you use a mobile grid I suppose. Using devourers you'd get a 2x2 grid, but you need either 3x3 with 9 units (not possible) or a 1,5 with 25 units. I'm not sure how you'd achieve that.
Looking at your pictures I suppose your mobile grid locations are not perfectly placed above the burrowed IT's and may overlap to the wrong IT.
A quick fix to check for that would be to make the location(s) of the mobile grid smaller.
you could also create/kill test units at each of the mobile grid locations to check for correct centering on the IT's.

I do not use a mobile grid. At first I did use one but like you said it is a pain to get correct sizes for 3x3. I don't like using 2 grids anyway so I used a different (more efficient and smaller) method so that I only need the static grid. So the only grid around is the static one with IT's which I thought would be placed perfectly with SCM Draft (that's indeed the editor I use). When I get home from work I'll try to place all the IT's in the same order as starcraft checks them (ie: bottom left to upper right). I hope it works. I would make sense that [i]that[/i] would be the problem because the bug seems to be happening more and more frequent. Since at first I thought I accidently stacked some IT's I deleted/re-created a few just to be sure, and then a few more and a few more, etc. So the whole grid will be mess if you look at the ID's and in-game the locations are a mess... which is hopefully not just a coincidence. Oh, Nuderaider, I'm already using constant create/kill triggers to find out the positions of the locations. The locations are in fact placed perfectly centered, but just on the wrong spots. After having decreased the size of the 3x3 location I figured that the centering was not the problem. Thanks for your input, the both of you! BTW, do you know if anyone besides GoldenUrg ever made chess? (GoldenUrg made chess years ago, but took 13k lines of code and over an hundred locations, which seems rather odd to me.)

I do not use a mobile grid. At first I did use one but like you said it is a pain to get correct sizes for 3x3. I don't like using 2 grids anyway so I used a different (more efficient and smaller) method so that I only need the static grid.

So the only grid around is the static one with IT's which I thought would be placed perfectly with SCM Draft (that's indeed the editor I use). When I get home from work I'll try to place all the IT's in the same order as starcraft checks them (ie: bottom left to upper right). I hope it works.
I would make sense that that would be the problem because the bug seems to be happening more and more frequent. Since at first I thought I accidently stacked some IT's I deleted/re-created a few just to be sure, and then a few more and a few more, etc. So the whole grid will be mess if you look at the ID's and in-game the locations are a mess... which is hopefully not just a coincidence.

Oh, Nuderaider, I'm already using constant create/kill triggers to find out the positions of the locations. The locations are in fact placed perfectly centered, but just on the wrong spots. After having decreased the size of the 3x3 location I figured that the centering was not the problem.

Thanks for your input, the both of you!

BTW, do you know if anyone besides GoldenUrg ever made chess? (GoldenUrg made chess years ago, but took 13k lines of code and over an hundred locations, which seems rather odd to me.)

Falkoner, I love you! :wub: It was indeed the ID number of the units which messed it all up. I had to remove all the IT's and carefully re-place them in vertical lines from down left to upper right. Result? It works perfectly, just like it should. Now my method appears to have no more flaws works it will only take 1 trigger per piece. The castling move might proof tricky though, and pawns as well (different advance-attack; en passant; promotion, double advance on first move). When I make some more progress I'll probably start a production thread, just for the fun of it I guess (and for input on which tournament/multiplayer options should be implented). EDIT: Btw, I would like to know more about this phenomena. You say that SCM Draft is funny with the way it places units as it gives them ID's in the order you created them. Does Staredit give unit ID's on their position? I remember that in-game created units also receive ID's in the order they are created so how is it that SCM Draft is strange for doing the same for pre-placed units? (btw, doesn't that allow you to use UED commands on pre-placed units?) Also, first I thought (and was told) that Starcraft selects units based on their position (ie: first left under) hence the possibility of static/mobile grids. Apparently Starcraft first checks X coordinate, then ID and then Y coordinate (which only matters on pre-placed grids). I'm still thinking of how this could be taken advantage of, but until now it only seems rather iritating. Meh.

Falkoner, I love you!

It was indeed the ID number of the units which messed it all up. I had to remove all the IT's and carefully re-place them in vertical lines from down left to upper right. Result? It works perfectly, just like it should.

Now my method appears to have no more flaws works it will only take 1 trigger per piece. The castling move might proof tricky though, and pawns as well (different advance-attack; en passant; promotion, double advance on first move). When I make some more progress I'll probably start a production thread, just for the fun of it I guess (and for input on which tournament/multiplayer options should be implented).

EDIT:

Btw, I would like to know more about this phenomena. You say that SCM Draft is funny with the way it places units as it gives them ID's in the order you created them. Does Staredit give unit ID's on their position? I remember that in-game created units also receive ID's in the order they are created so how is it that SCM Draft is strange for doing the same for pre-placed units? (btw, doesn't that allow you to use UED commands on pre-placed units?)
Also, first I thought (and was told) that Starcraft selects units based on their position (ie: first left under) hence the possibility of static/mobile grids. Apparently Starcraft first checks X coordinate, then ID and then Y coordinate (which only matters on pre-placed grids). I'm still thinking of how this could be taken advantage of, but until now it only seems rather iritating.
Meh.

y-coordinate is not taken into account. The rest is like you say. Probably the myth about units with higher y-coordinates are checked first was created by the use of mobile grids. Units are usually created bottom to top (or was it vice versa?) when there's no space at the center of the location. However that means, units with lower y coordinate units have lower IDs, so the y-coordinate rule often works when working with grids.

y-coordinate is not taken into account. The rest is like you say.

Probably the myth about units with higher y-coordinates are checked first was created by the use of mobile grids. Units are usually created bottom to top (or was it vice versa?) when there's no space at the center of the location. However that means, units with lower y coordinate units have lower IDs, so the y-coordinate rule often works when working with grids.

Yes, and that's why SCM Draft is annoying when working with grids, because it sets their IDs based on placement, the other editors simply set them going from left to right, then from bottom to top, like the game does when creating them.

Yes, and that's why SCM Draft is annoying when working with grids, because it sets their IDs based on placement, the other editors simply set them going from left to right, then from bottom to top, like the game does when creating them.

Top to bottom actually. When saving in Staredit units are ordered based on their position, rather than the order you placed them in like in Scmdraft2. Higher ones are first and lower ones are last, which means the lower ones have higher IDs and are therefore selected first by triggers. I don't know what you mean about the game creating them like that. You know it uses some crazy spiral pattern.

Top to bottom actually. When saving in Staredit units are ordered based on their position, rather than the order you placed them in like in Scmdraft2. Higher ones are first and lower ones are last, which means the lower ones have higher IDs and are therefore selected first by triggers.
I don't know what you mean about the game creating them like that. You know it uses some crazy spiral pattern.

I was talking about that: [Quote=Wiki, Removal order of mobile grids] 3x3 03 04 07 02 06 08 01 05 09 4x4 04 05 10 13 03 08 11 14 02 07 12 15 01 06 09 16[/center] [center]5x5 05 06 11 16 21 04 10 13 18 22 03 09 15 19 23 02 08 14 20 24 01 07 12 17 25[/quote] Leftmost row is removed bottom to top. 2nd row from left too, with the exception of the top unit.

I was talking about that:

Quote from Wiki, Removal order of mobile grids

3x3

03 04 07
02 06 08
01 05 09

4x4

04 05 10 13
03 08 11 14
02 07 12 15
01 06 09 16[/center]

[center]5x5

05 06 11 16 21
04 10 13 18 22
03 09 15 19 23
02 08 14 20 24
01 07 12 17 25

Leftmost row is removed bottom to top.
2nd row from left too, with the exception of the top unit.

Yeah, does anyone know why the units get created displaced like that? Is it just because the units aren't perfectly 2x2?

Yeah, does anyone know why the units get created displaced like that? Is it just because the units aren't perfectly 2x2?

its only a guess but uhm maybe the removal order really is just from left to right... like look: Creation order 07 06 05 08 01 04 09 02 03 in letter form: G F E H A D I B C and everytime one of the units are created, each one is offset a little to the left of the unit before it... so none of them really have the exact same pixel x pos (can prolly be checked via EUD, i wouldn't know im not to familiar wit EUD's) then, they just get removed from left to right... so if i gave every unit a 'unit' x itd probably be: A: 0,0 B: -1,-100 C: 98,-100 D: 97,0 E: 96,100 F: -5,100 G: -106,100 H: -107,0 I: -108,0 i made each Unit 100 U's (U in place of an actual unit of measure for simplicity) wide and tall so that the small X's offset would be easy to follow without making the situation impossible to imagine ok so removing units just based off of their pos X itd go: I,H,G,F,B,A,E,D,C or 09, 08, 07, 06, 02, 01, 05, 04, 03 heres the grid again, to compare: 07 06 05 08 01 04 09 02 03 G F E H A D I B C which translates perfectly to the wiki's removal order: 03 04 07 02 06 08 01 05 09 so iono, i think Blizz made it so that every unit is offset by a given X amount every time its created so they could have a simple way of removing/killing units (the most left 1) Blizz did pretty much simplify a lotta stuff so maybe this is another 1 of 'em edit: whoops, the very firs grid was wrong... fix'd it : )

its only a guess but uhm
maybe the removal order really is just from left to right... like look:

Creation order

07 06 05
08 01 04
09 02 03

in letter form:

G F E
H A D
I B C

and everytime one of the units are created, each one is offset a little to the left of the unit before it... so none of them really have the exact same pixel x pos (can prolly be checked via EUD, i wouldn't know im not to familiar wit EUD's) then, they just get removed from left to right... so if i gave every unit a 'unit' x itd probably be:

A: 0,0
B: -1,-100
C: 98,-100
D: 97,0
E: 96,100
F: -5,100
G: -106,100
H: -107,0
I: -108,0

i made each Unit 100 U's (U in place of an actual unit of measure for simplicity) wide and tall so that the small X's offset would be easy to follow without making the situation impossible to imagine

ok so removing units just based off of their pos X itd go:

I,H,G,F,B,A,E,D,C

or

09, 08, 07, 06, 02, 01, 05, 04, 03

heres the grid again, to compare:

07 06 05
08 01 04
09 02 03

G F E
H A D
I B C

which translates perfectly to the wiki's removal order:

03 04 07
02 06 08
01 05 09

so iono, i think Blizz made it so that every unit is offset by a given X amount every time its created so they could have a simple way of removing/killing units (the most left 1)

Blizz did pretty much simplify a lotta stuff so maybe this is another 1 of 'em



edit: whoops, the very firs grid was wrong... fix'd it : )

Ah, so they are created in a sort of spiral, I see, thanks for pointing that out.

Ah, so they are created in a sort of spiral, I see, thanks for pointing that out.

Nice idea, ZzEzZ, but it isn't because they're displaced to the left, it's because they're created last = higher Unit ID = removed first. Btw. when it would solely depend on coordinates, what would happen when you move a bunch of burrowed units somewhere. They'd definitely have exact same coordinates. ;)

Nice idea, ZzEzZ, but it isn't because they're displaced to the left, it's because they're created last = higher Unit ID = removed first.
Btw. when it would solely depend on coordinates, what would happen when you move a bunch of burrowed units somewhere. They'd definitely have exact same coordinates.

oo, true true... didn't consider burrow thingys >.< and ooo its unit ID order? ic... so what about a unit that is created first, but moved to the "square" last? does it get removed first or last? or sumwhere in between? and np falk : )

oo, true true... didn't consider burrow thingys >.< and ooo its unit ID order? ic... so what about a unit that is created first, but moved to the "square" last? does it get removed first or last? or sumwhere in between?

and np falk : )

moving a unit does not change its ID. Sc first checks x coordinate and then ID. When it's been created last it's removed first.

moving a unit does not change its ID.
Sc first checks x coordinate and then ID.
When it's been created last it's removed first.