Staredit Network

I was working with a pretty normal unit grid:
32 burrowed Drones owned by P9 in 4 rows with 8 drones each. These rows get filled with units one by one; the topmost row from left to right, then the next row and so on. I made the correct triggers for that, it was working well until some point.
The triggers effectively were like this:

C:
Brings exactly 0 units to GridLocation
A:
Give all Drones by P10 to P9
Give 3 Drones by P9 to P10
Move Location1 on Drone by P9

Then the new unit is spawned at Location1. Next trigger:

C:
Brings exactly 0 units to GridLocation
A:
Give all Drones by P10 to P9
Give 7 Drones by P9 to P10
Move Location1 on Drone by P9

Should be clear now.

Ok, as I said, everything worked well, I was able to fill all the rows a dozen times.
Additional information: I was using SCMD2 for all of this; might be important because of the order it saves the preplaced units.

Then I removed the top-left-most Drone for testing purposes, as well as the one directly to the right of it. The first 2 Drones in the first row. Then I added them back in.
Here it begins: The units don't spawn correctly anymore. The first unit is placed in the second row, first column. Next is second row, second column, then first row, third column. The two spots at the top-left are filled when normally 4-1 and 4-2 would be filled. The first 2 colums are shifted down by one, so to speak.

I backupped that version. Then I removed all the drones and added them back in in the correct order, row1, row2 and so on. NO other changes. Works as it should now.

Actually, this is not the first time I experience something like this, but it's the first time I backupped it and took it seriously.
Soooo... I guess we have a wrong understanding of the way how SC chooses a unit in actions like "give". It is usually assumed that SC chooses the leftmost, then bottommost unit there is. But since this doesn't seem to be correct, we will have to rethink this.

I once heard that SCXE saves the preplaced units in this order: leftmost-bottommost. Sounds familiar. SE would save them the same way then, probably. But how does SCMD2/SF save them? Does someone know? SI/Heimdal especially Finding out with a hex-editor would be annoying.

So I suspect that SC chooses units based on the unit list (which would be a lot more reasonable programming-wise). I have not yet thought it through in detail, so there may be some more specifications.
Yeah, well, start discussing.

Btw, maybe I'll upload the 2 maps later.

Edit: I hex-checked the unit order... In the weird-behaviour-one the units are listed in this order:

(Some other units, no Drones included)

1: Row1, Column3
2: 1-4
3: 1-5
...
6: 1-8

7: 2-1
8: 2-2
...
14: 2-8

15: 3-1
...
22: 3-8

23: 4-1
...
30: 4-8

Then there are lots of other units, including 32*3 P9 Drones, all placed to the right in similar shape.

"31": 1-1
"32": 1-2

These are the very last units in the list.

So from this I assume that SCMD2 keeps the order you inserted your units. But then again I am not too sure about that because I don't think I placed the very first units (some pylons) in the order they are listed. I might be wrong though.

So how does this fit together...

StarCraft selects units from the left-bottom corner. We all know that. Now, let's imagine that you have 4 units placed in a column with using grid, so they "should" be selected like this in the game:
[4]
[3]
[2]
[1]

That works only if you place them in this order in the editor: 4,3,2,1. If you place them normally (1,2,3,4), the grid will be screwed.

I don't know what is the source of this bug.

We "know" that. Well, we obvously have been wrong, there is no point in insisting on the old knowledge. Just like Newton and Einstein, and this is indeed pretty similar, as this problem only occurs if you use an editor that doesn't write UNIT in the "normal" order.
I bet if I open-save the map in SCXE, the problem disappears


So, I made some more tests.
Until now it seems to be that way: SC uses the leftmost unit that has the highest index in the unit list.
As an example, I'll build another column, this time the numbers indicate in which order they are listed in the unit list:

[3]
[2]
[1]

All with the same x-coordinate. SC would choose [3] at first, then [2], then [1].

[2]
[3]
[1]

Would result in the same choosing: 3-2-1.

From that I would expect that SE/SCXE stores units in this order: leftmost-topmost, contradicting what I had in mind before.

So again, I say that SC chooses units leftmost-highestIndex. I'd be glad if someone could verify this, or prove me wrong.

About the different writing functions in the different editors: If someone knows them, please tell me.
Concerning SCMD2, I suppose units are stored in a linked list within the editor; whenever you delete one, the entry is deleted and the gap is closed. Any new entry is appended to the end of the list. UNIT is written in the same order as the linked list. Am I right, SI?

Edit:
Oh, and JaFF: it's no "bug", it's our own fault, since we simply don't know every detail of SC's engine. In fact, the behavior I suggest is much more reasonable than the "old" one. Or which unit would SC choose in a perfect stack of units if the old behaviour would apply? I just wonder what the leftmost-part is there for, but from my tests it is there.

you really wrote ALOT spines, so i didn't bother reading it all. so excuse me if this post is irrelevant.

anyhow, from what i can remember about this, the units ARE removed according to their unit index. but SE/SCXE reorder the preplaced unit indexes so they are removed according to left-to-right, bottom-to-top. Whereas SCMD2(and presumably SF), do NOT rearrange the unit index.

its been a LONG while since i last read about this stuff, so my memory may be off. just as a note, i've never bothered to test this, its just what i've read.

ps i know absolutely nothing of the mechanics of the SC/SE engine in this process.

Player 9???

What the hell? Are you sure that works...

ADDITION:
Player 9 isn't good for anything, that's your problem.

What are you talking about? Player 9 is plenty useful. It's just as good as any other neutral player.

Who brings?

Ya, I'm confuzled. Don't listen to me.

Scmdraft doesn't order the units in any particular way, just the order they are placed, and if deleted / undone its back at the end of the list. I'm fairly sure SC itself doesn't reorder the units everytime they swap positions, but the select units at location function has an internal buffer, it may sort them according to something

Ok, thanks SI.

@ Rantent: P5 brings. There are P5 units placed on top of the grid, and I set the next position based on the number of present units.

@ Zeratul: Oh come on, most of the lines have only a few characters - I could have written a lot more

So, I still can't find a reason for that leftmost-thingy, I'd expect it to be a lot more efficient to take the first unit that is inside the specified location, but the leftmost-thing does exist. Too bad, actually, we could have extremely efficient grids if it was different.

Well ok, seems like the leftmost-highest index order is correct. Maybe this should be mentioned in some tutorial, I had to find it out myself. And if you are a newb and read a grid-tutorial and it doesnt't work then that's not nice for the newb

Oh, and I have been using P9-12 a goddamn lot, they DO work fine.