What happens if they were right next to each other and both of them need to be refreshed? at the same time!

Well for one that is very unlikely and second if you put the triggers player by player and give them their own location it will not matter.

OMG YES IT WILL.. The grid system works like this

Now lets watch what happens when they get in the same area...
0
00 000
000 000 <--- see the air units conflict with each other since to do a movement detector they need to be constant on
00 000 create/remove unit.. so when they are close its like omg.. i am not a perfect square anymore! if that makes any sense! So that mean up is really like right left down.. because the units are conflicted and are not being created in a perfect 3x3 square!.. No with my system you don't use units so you can be as close as you want and it only takes 2 locations!

Post has been edited 2 time(s), last time on Jul 25 2008, 5:24 pm by Ashamed.

Actually, no, because you only create the units when the player moves, mainly for lag reduction, and they won't have problems overlapping, because the units are created and then completely removed in a single trigger, so they are basically never there. I admit, you can save on locations, but I don't think it's a problem with the kind of map he's helping with.

I would like to see this.. because i have already tried ><! please make a demo because i want to know what i am doing wrong...

another example: Imagine the units are being created and removed when they move. They move in each others 3x3 area.. It does not matter if its almost instant it is still there... if lets say we have to zealots fighting... and running around each other... you can not honestly say that it won't be messed up.

Now the units will be messed up... now even imagine this... one guy wants to go up.. when hes right next to the other.. and the other moves down.. I am sorry i have tried it... And i would love to see a demo.. Because i could be wrong and i could of been doing something wrong!

-the other problem is i am going to have land/air units to be used mr. air guy can't fly next to mr. land guy and visa versa!

Post has been edited 1 time(s), last time on Jul 25 2008, 7:00 pm by Ashamed.

Your first problem isn't really a problem, because the grids should never exist at the same time unless you're leaving the units there for some inexplicable reason. The second problem, however, is completely valid...if you have both ground and air units that are staying on the map, and if you find stopping their movement every time a grid came through unacceptable (which I assume you would, for gameplay reasons), then you're going to have issues with the grids bumping into the permanent units. I tried out what you provided, and though it sometimes glitches and would lose responsiveness if used for more directions, it might be better than a mobile grid for your purposes.

I actually got it to work for all 9 directions.. a few more triggers but it works!

Yeah, it will work, but in my tests, it makes the system less responsive, because it needs enough information to determine that the unit is moving both vertically and horizontally, which means not going off and resetting every time it gets information in either direction. Maybe that doesn't matter for what you're using it for, though.

It's true >< its not as responsive as i would like but i think i can get it to work mby a bit better! i just have to toy with it a bit!

Triggers execute one at a time. If you have the grid air units creating, giving, centered, removed. All in one trigger then another trigger for the next player, it won't mess up the gird at all, because the units will be removed before the next trigger executes. Therefore there will not be any units in the way when creating the grid. (Correct me if I'm wrong...)

edit: oops wrong quote (fixed)

Hello people. I remember doing exactly what this topic is requesting a few days ago. Here is the map.

[attach=1424]

For some reason the unit is slowed down terribly (the game does not lag) on single player, but on battle.net it runs very smoothly. Compared to my earlier experiments, this one works nearly flawlessly. It is based on meticulous location sizing and precise ordering of triggers to better anticipate changes in direction and also to prevent direction bias (as in, north appears more frequently than northwest if you are going somewhat northwest).

Supports diagonal movement. The "current direction" is stored in a death count.

If you want to use this in your map:

P1, Alan Schezar (Goliath) deaths is your direction:

1 - N
2 - NE
3 - E
4 - SE
5 - S
6 - SW
7 - W
8 - NW

I also used P1, Terran Marine in a death counter to have the locations relocated only when movement has been done.


Edit:
Here are some numbers to work with.
You have to move 8-12 pixels in order for it detect movement. This could be lowered by resizing the locations, no trigger modifications needed, but it may reduce accuracy.
The leeway you have for direct cardinal movements are 30 degrees both ways.

Attachments:

It might be being slowed down due to constant updating of the grid, rather than whenever you move.

The locations only update when movement has been detected. I think I may have made it so that it constantly refreshes, tested it on single player, made it so that it only refreshed after your unit has been moved, then tested it on battle.net

The one thing for sure is that on battle.net this system will not lag.

edit: nvm, the system is very glitchy on single player but works great on battle.net. I have no idea why.

If you want serious accuracy, you can use the Micro Scan method, shown in the map below:
[attach=1425]

In the map, you can see your current X and Y coordinate by looking at your resources, and from your X and Y change it calculates how fast you're moving and what direction.

Attachments:

Post has been edited 1 time(s), last time on Jul 25 2008, 8:19 pm by Falkoner.

Your guy is slowed down by the units you create above him!