Do you know that there exists point functions that should (at least when reading their names, haven't used them yet) return things you may need.
I'm not sure about the function name right now, but this one function returns the "pathingcost" (?) between two points. So have a try if this is the distance between the two points or some value which can be used as the distance. It's the same problem like we had in WC3 scripting, after several iterations you simply exceed the operation limit and you would need to use a wait.
I did some testing on the operation limit in WC3 and found a formula where you could simply calculate how often a loop will be executed in its own thread until the game breaks it down. As a basic you can say that more function calls, variable references and operations (like +-*/ ||) drastically decrease the limit. Will post more details later if someone wants to know this. :D
I'm aware of the function but it doesn't help the situation I described because the movement costs are customized and not determined by the actual in game terrain. Also that function will not constrict itself to operate on a very specific grid and instead will find return the cost that starcraft determines is the fastest path between two points.
@crutex: Go
169 nodes is small in reality but it's more actions per trigger than starcraft wants to deal with. I was a little misled because I was testing with the trigger debugger which slows everything down a little bit as well (especially if you have debug output).
I'm working with some pretty complicated triggers that exceed the maximum runtime for a trigger (which according to my testing is about 175ms).
I've discovered that the Wait() command sleeps a trigger and that the trigger duration is not saved over context switches. So by inserting Wait( 0.0, c_gameTime ) into a trigger, it can essentially be broken up to fit into intervals that do not exceed the trigger limit.
This raises an interesting question though - when playing a game online, is the trigger execution time determined by the slowest person's computer? The machine I test on is quite fast and if my map is played by someone with a much slower computer, the way I am splitting my trigger may not work.
In case you are wondering, I am working on a map with a hexagonal game grid where the movement costs for units can vary depending on the grid cell, so a shortest path problem needs to be solved every time a unit is selected for movement. I haven't implemented a priority queue yet so the current implementation I'm working off of is O(n^2) (yuck). To make matters worse, for the maximum range of a unit in my game (7) this turns into n = 169 hexagonal grid cells. Right now the slowest part of the procedure is building the n by n array of weights between the nodes.
Edit: So far I've tested on two computers, a 3.4ghz quad core phenom and a 2.4ghz dual core turion and the runtimes were exactly the same - need to find someone with a really slow computer to see if this trick won't work in all cases.
I'm aware of the function but it doesn't help the situation I described because the movement costs are customized and not determined by the actual in game terrain. Also that function will not constrict itself to operate on a very specific grid and instead will find return the cost that starcraft determines is the fastest path between two points.
@crutex: Go 169 nodes is small in reality but it's more actions per trigger than starcraft wants to deal with. I was a little misled because I was testing with the trigger debugger which slows everything down a little bit as well (especially if you have debug output).
Anyway, I got it working, it looks like this:
I'm working with some pretty complicated triggers that exceed the maximum runtime for a trigger (which according to my testing is about 175ms).
I've discovered that the Wait() command sleeps a trigger and that the trigger duration is not saved over context switches. So by inserting Wait( 0.0, c_gameTime ) into a trigger, it can essentially be broken up to fit into intervals that do not exceed the trigger limit.
This raises an interesting question though - when playing a game online, is the trigger execution time determined by the slowest person's computer? The machine I test on is quite fast and if my map is played by someone with a much slower computer, the way I am splitting my trigger may not work.
In case you are wondering, I am working on a map with a hexagonal game grid where the movement costs for units can vary depending on the grid cell, so a shortest path problem needs to be solved every time a unit is selected for movement. I haven't implemented a priority queue yet so the current implementation I'm working off of is O(n^2) (yuck). To make matters worse, for the maximum range of a unit in my game (7) this turns into n = 169 hexagonal grid cells. Right now the slowest part of the procedure is building the n by n array of weights between the nodes.
Edit: So far I've tested on two computers, a 3.4ghz quad core phenom and a 2.4ghz dual core turion and the runtimes were exactly the same - need to find someone with a really slow computer to see if this trick won't work in all cases.