I was wondering how I could make a target location for something such as an AI nuke to appear at a random spot on the map. The only options I could think of all required quite a large number of location.

Post has been edited 1 time(s), last time on Aug 1 2009, 6:31 pm by Qwerty5312.

You could use this method of randomization to get 2 numbers, and then use Mobile Grids to go to those coordinates on your map, and then perform the AI there.

Thanks! That is a great idea!

Another possibility is to nuke to a location following a junkyard dog observer.

I was thinking of the observer idea...though the occurrences would be always fairly close to one another on a large map.

Back to the idea of randomization with mobile grids, I was wondering how the system would work. Once you have the randomization would you set the death counter for two different units and subtract one from each unit for each move in a given direction?

Yeah, you'd have a Death Count for say, going down, and one for going right, and you'd start in the upper left hand corner, and each time it moved in one of those directions, you'd subtract from that Death.

Also, for the randomization method you suggested, would I be running the switch x amount of times based on the death counter? For example, setting a death counter to count down for each time the switch fires, and reset when the whole set of triggers are done, then have another counter adding up for the y axis?

You'd get a random number twice, you could use two different counters, or you can randomize one, go in one direction that far, then randomize the next one and go the other direction. If you want it to be instant you'll have to copy the trigger for the Mobile Grid as many times as it could possibly move, otherwise, it may actually be quite slow.

Did I answer your question?

My last post was actually referring how to limit the times you randomize the switch while another death counter adds to a randomized outcome.

Though now I am not sure about what you mean by copying the Mobile Grid trigger. Wouldn't it still move one unit at a time?

Yeah, it would still move one at a time, however, now it can do it many times in a single trigger loop, also, I was thinking about it, and you can actually move diagonally too, and you'd only need to create 3 Devourers, to move down you'd only need to make 2, to move to the right you'd only need to create 4.

I still am not sure about the idea of copying the Mobile Grid trigger unfortunatly...

Post has been edited 1 time(s), last time on Aug 2 2009, 2:07 am by Qwerty5312.

They look like this. You'll make enough devourers/mutas/arbs/guards at anywhere. This will be the center of the map ,(128,128) on a 256x256 map. Center a location on the unit. remove them all. Repeat until you get where you wanted to go.

For example, say you have a 64x64 map, that means anywhere is at 32,32. You want to put something at 11,17. Let's start out with the x axis, so we have to get down to 11. Make 8 units, center location on one, remove them all. Now we are at 30.5,32. Do this trigger (32-11)/1.5 = 14 times. It's easy enough to break the stuff down into 1.5x1.5 squares, since you can't get to, say, 12 using only this method. Now that we're at 11,32, make 5 units, and center a location, then remove them all. Now we are at 11,30.5. Rinse and repeat until you're at the spot.

It will take a lot of thinking, so be warned. You'll have to figure out a way to get everything to happen in one trigger cycle, and make sure you don't run over any air units.

I finally finished setting it up....but I have no clue what is wrong...

That makes all of us, considering all you said was that it doesn't work. We need details to help you, more specifically, why YOU don't understand it.

Of course, would it be worth it to start it in the middle, or in the top left? If you start in the middle it cuts down your possible distance you would have to move by half, however, if you start in the top left, you only have to move right or down, so you need less than half as many units created to get where you need to, not to mention you only need to trigger for 2 directions, rather than 4.

Ok, I preset a 16 death counter so that all the randomizations only fire once per cycle. From here I did the 8 randomizations for the x and y axis. Then I have the grid move diagonally till one number reaches zero, then it proceeds either horizontal or vertical and place a data disk in final spot. After all this, it should return to the corner using center location and reset the hole process.

Here is the test map...

Attachments:

From what I saw in the triggers, there are no trigger mistakes or flaws with the setup. I feel I am missing something from my lack of experience.

You saw no reasons why it shouldn't work, I saw no reasons why it should work. The triggers seemed to be in a huge mess, so I decided to make the system for you, then explain how it works.

Post has been edited 1 time(s), last time on Aug 2 2009, 10:48 am by JaFF.

Just so you know....those flag beacons were changed to flag markers like they were supposed to... Is it really that bad? There is only one death counter and one switch which hold them in a loop.

OK, here is a very simple version of the system. It always starts at one point, which is why you'll probably notice lag. You can make it less laggy by:

1. Spreading the grid triggers over several trigger cycles.
2. Using wiser starting points. The simplest example is to start in the middle - that will cut the mean amount of grid triggers by half. If you need to reduce lag even more, split the map into quadrants and have a separate starting point per quadrant.

If you have any questions, please ask.

EDIT:

OK, I decided to analyze this from a mathematical point of view. Let each create/remove be one 'laggy' action in the grid. The most effective way to get to the desired point is to move on the diagonal and then in a straight line - this way the number of grid steps needed to get from point (x1, y1) to (x2, y2) is max{mod(x1-x2), mod(y1-y2)}; in other words, it is the largest coordinate distance. In a 1x1 grid, we use 2 laggy actions to move down/left, 3 laggy actions to move down, etc... So if we move in the most effective manner (diagonals -> straight lines), the maximum number of grid steps we have to use is equal to the greatest dimension of the area we move in (in our case, it's 256).

The least average number of laggy operations is used in grid steps associated with moving in the following three nearby directions: down/left, down and down/right (3, 4 and 5 respectively). Hence if we start our grid from the upper left corner, the maximum number of laggy operations needed to cover the entire quadrant/area is (3+4+5)*N/3 = 4N. If we decide to move from the middle of the quadrant/area, the average number of laggy operations is (2+3+4+5+6+7+8+9) / 8 = 5.5. Hence the average is 5.5*N/2 = 2.75N (because we have to move only half the distance).

This means that the middle start position for the grid is less laggy 'in the long run'. This is, however, highly dependent on chance. You may get trigger cycles that require you to use the up/left grid step, which is the laggies one, to cover long distances (this might cause more lag). The upper-left starting position is more stabile i nthe lag it makes, as it will never exceed 5N laggy operations.

Just some info for you to help you make the right choice. I noticed that in the version of the system that I've made, the lag might get quite strong; perhaps I'll enchance it with the help of this knowledge and split it up into quadrants, etc...

Attachments:

Post has been edited 3 time(s), last time on Aug 2 2009, 3:09 pm by JaFF.