Look in here, it should contain both, a snipe ability with autocast and an autocast for psi storm wich only casts if there are 4+ units within the storm range.
Well, it's been one of my first maps (well, not a finished map, let's say project), I did that before entering the first wc3 forum. A few month after finishing this I learned vJass.
I just wanted to show that I'm not new to this topic and know what I'm talking about. This map is made pretty bad, but its damn old, so it shows that I'm a senior 3D developer (*coughs*).
I've got a working version in galaxy script, at least it would work with floats >.< I am tracking real collision between n-edged or round objects with a flat top and bottom but the error is so big that I sometimes get stuck. The prod function I created (real collisions while prodding till no objects are stuck) made everything lag, so I kicked it out again.
The version uploaded is somewhere from during the development (wich already stopped) but it's one of the playable versions <.<
Our conversation is off topic and I'd prefer pms for further conversation (instead of writing here).
Thanks for the post. But as I said I did make it to not do any redundant checks, so it's already doing n*n/2 checks.
I wasn't saying you did a bad job, I just wanted to show that the speed of O(n²) != O(n²). O(n²) shows how fast the time needed increases with additional objects, not how fast your algorithm is. A slow O(n) can be worse than a fast O(n²) algorithm for n = 1.000.000.
And about the "evil functions" that gives me an idea, maybe instead of taking the square root for the distance I should just square the other side of the inequality. Not sure how much faster that would be.
That's the normal method, a square root is one of the worst functions you can find.
For some reason I can't get my self to like sweep and prune. But you are free to chose, I just wanted to show you a method better than forcing a collision check between every object pair.
I've already done a lot of 3D stuff, it began with this wc3 map:
edit: oh, you might want some information if you want to test that map^^
movement: arrows + j
creating blocks: k (have to be selected via chat, "-model 1-6"), presets: just write "1", "2" or "3" into the chat
camera, hiding objects in your field of view: "-camz x", "-camx x", "-camc x" (greyout value), "-camf x" (transparency)
camera: "-camax x", "-camaz x", "-follow x" (smoothness of the camera movement)
bugs: sometimes you have to move away from new objects or you fall through (moving away one times solves this)
objects placed too low look like they are above ground even though they arent (you can move through the model)
That's actually close to what it does, but it does it by removing the unit from the unit group to prevent redundant checking. It's still O(n2) anyway. Maybe it's not as fast as I think it is because I'm not even sure what the data structure for unit groups is.
It might be true that both options are O(n²), but when programming something with a high runtime you always have to save wherever you can (if it doesn't hurt the program).
Option 1 = n²
Option 2 = n*(n+1)/2
Option 2 allows about 40% more units (sqrt(2) on big numbers).
Example:
100 objects with option 1 = 10.000
140 objects with option 2 = 140*141/2 = 9870
Now use a simple grid, nothing serious, use 9 squares and I think you will probably save more than 50% of your checks.
Example:
1 2 3
4 5 6
7 8 9
Checks to be done:
1 - 1, 1 - 2, 1 - 4, 1 - 5 = 4 checks
2 - 2, 2 - 3, 2 - 5, 2 - 6 = 4 checks
3 - 3, 3 - 6 = 2 checks
4 - 4, 4 - 5, 4 - 7, 4 - 8 = 4 checks
5 - 5, 5 - 6, 5 - 8, 5 - 9 = 4 checks
6 - 6, 6 - = 2 checks
7 - 7, 7 - 8 = 2 checks
8 - 8, 8 - 9 = 2 checks
9 - 9 = 1 check
25 checks
That might seem a lot so lets see how much it is if we group all objects perfectly (will probably never happen, but the worst case is still the same as before):
10 units in every square, so we got 90
every check is 9*10/2 = 45
45 * 25 = 1.125
90 objects without a grid = 90*91/2 = 4095
180 opbjects with perfect grid placement = 5250
Now let's think about a larger grid, like 16 fields: 9*4 + 6*2 +1*1 checks = 49 checks * 1/16² = 49/256 wich is a bit less than 1/5.
.
New question: How do we define the grid size?
Well, the grid can be built on every iteration, sorting everything into a grid every time you need it has a lower runtime than updating the grid by checking borders. (A quadtree would need a lot higher performance because you have to check 4 borders on every iteration or 2 per depth level to find the new position.)
Sorting everything in on every iteration allows us to use a dynamic squaresize wich has to at least be slightly higher than the biggest radius of your objects.
Example, your mapsize is 256 and your biggest object has a radius of 1.5 (diameter of 3). Your gridsize is 2. 128*128 squares, 127*127*4 + 127*2*2 + 1 checks = 65.025 checks
Sounds ridiculous? Sure, the checks will kill your computer, even though you will probably only check for 100 collision if you randomly spread 1000 objects. Oh, and don't forget to empty the grid after each run...
But we can fix that. Add an integer for every grid position and a global one. Increase your global integer every time you run a collision check (for the whole field). Whenever you add an object to the grid position you check if the integer on that field equals your global int, if it doesn't clear the object list for that field and update the integer (then add the object).
Now we get to the second problem, we have to know wich squares are used and wich aren't. We just need another global integer and an integer array wich has to be equal (or greater) than the object count. The integer will be our counter, before we start the whole check we have to set it to -1 (every time). When we add an object to a square in the grid and the integer on that position is updated we have to increase our counter and set our array[counter] to the gridposition.
.
The last thing we have to do is run 4 checks for every gridposition saved in that array:
square with itself (in case there is only 1 object 0 collision checks are needed)
square with the square to its right (0 objects = 0 collision checks)
square with the one below (0 objects = 0 collision checks)
.
1000 objects: worst case (fields to check): 4000 and probably less than 100 collision checks
1000 objects without grid (n*(n+1)/2) = 500.500 collision checks...
.
No evil funcs needed (square root, sin, cos etc. are slow).
Btw. it's still O(n²). Oh, and I'd suggest a grid size between 4 and 8, a slight bit more collision checks and less squares to check.
Thanks for reading (if you did so :D).
edit:
Small note, if you want to add unmovable objects, add a second list to each square in the grid wich contains them. Now you have to check all 9 fields around (including the field where your object is) for unmovable objects and the normal 4 fields for movable objects. This makes unmovable objects your biggest friends because you can add thousands of em and won't even feel it.
Can you upload a full native list? I still use an old version http://paste.sc2mapster.com/1979/ "Date posted 22 Apr 2010". Or tell me where I can find one?
can is set an array to a player like score[2][2] ok so the first 2 would be player 1 or 2 can i set a player to that number and the next 2 is for kills deaths help?
Your assumption is right (the way i understand it). Creating a record for it would just change the names of the variables.
score[player][1] can be used as the first value for a player and
score[player][2] as the second value
Here is my answere to the second challenge!
The zerg run shit scare when they notice the earthquake but they will still attack you when they notice your presence, even on the shaking earth. The zergs enemies must be slayn at all costs.
The earthquake deals a huge amount of damage to nearby buildings, the closer to the center, the more dmg it deals.
Try loading your marine into the medivac to move your eathquake around without fearing those zerglings and ultralisks!
Problems: Giving orders to any unit somehow changes the "target" of all the used effects, so the earth rumbles at any given order target point. Anyone knows how to fix it?
Still trying to wrap my head around exactly how you did this, but holy crap that's cool.
It's kinda complicated and uses too much different stuff (from my view, I want it shorter :D).
The target unittype needs the specific morph ability (found no way around it, but i'm still searching). This morph ability is triggered by an "issue order" via my search area. To add some eyecandy I created a continous model, activating it in the actor events, "moph ability.name.start". This would only add the egg and look really bad (just an egg appearing out of nowhere o.o), to cover this there is an eggsplosion add the beginning and one at the end (the name is "Eggsplosion Generic").
If you got more questions just ask, my descriptions always lack content (I just bad at explaining).
Well, you don't need to create the game yourself, just the terrain. I for example am always searchign for a good terrainer (I don't have any terrain skills at all :P).
If you are willing to help, I'd like to contact you when one of my maps reaches a status where terrain is needed (beta +).
You could just add a boolean for compression (if true compress, if false then not...), experienced mappers will know beforehand if it is usefull (in case you comment accordingly xD).
0
Look in here, it should contain both, a snipe ability with autocast and an autocast for psi storm wich only casts if there are 4+ units within the storm range.
0
My first idea is adding ally to a filter of the drop off ability. I got no editor at the moment so i will check that tomorrow.
0
@HellGateSc2: Go
Well, it's been one of my first maps (well, not a finished map, let's say project), I did that before entering the first wc3 forum. A few month after finishing this I learned vJass.
I just wanted to show that I'm not new to this topic and know what I'm talking about. This map is made pretty bad, but its damn old, so it shows that I'm a senior 3D developer (*coughs*).
I've got a working version in galaxy script, at least it would work with floats >.< I am tracking real collision between n-edged or round objects with a flat top and bottom but the error is so big that I sometimes get stuck. The prod function I created (real collisions while prodding till no objects are stuck) made everything lag, so I kicked it out again.
The version uploaded is somewhere from during the development (wich already stopped) but it's one of the playable versions <.<
Our conversation is off topic and I'd prefer pms for further conversation (instead of writing here).
0
@Arkless: Go
I wasn't saying you did a bad job, I just wanted to show that the speed of O(n²) != O(n²). O(n²) shows how fast the time needed increases with additional objects, not how fast your algorithm is. A slow O(n) can be worse than a fast O(n²) algorithm for n = 1.000.000.
That's the normal method, a square root is one of the worst functions you can find.
For some reason I can't get my self to like sweep and prune. But you are free to chose, I just wanted to show you a method better than forcing a collision check between every object pair.
I've already done a lot of 3D stuff, it began with this wc3 map:
edit: oh, you might want some information if you want to test that map^^
movement: arrows + j
creating blocks: k (have to be selected via chat, "-model 1-6"), presets: just write "1", "2" or "3" into the chat
camera, hiding objects in your field of view: "-camz x", "-camx x", "-camc x" (greyout value), "-camf x" (transparency)
camera: "-camax x", "-camaz x", "-follow x" (smoothness of the camera movement)
bugs: sometimes you have to move away from new objects or you fall through (moving away one times solves this) objects placed too low look like they are above ground even though they arent (you can move through the model)
0
It might be true that both options are O(n²), but when programming something with a high runtime you always have to save wherever you can (if it doesn't hurt the program). Option 1 = n² Option 2 = n*(n+1)/2 Option 2 allows about 40% more units (sqrt(2) on big numbers).
Example: 100 objects with option 1 = 10.000 140 objects with option 2 = 140*141/2 = 9870
Now use a simple grid, nothing serious, use 9 squares and I think you will probably save more than 50% of your checks. Example: 1 2 3
4 5 6
7 8 9
Checks to be done:
1 - 1, 1 - 2, 1 - 4, 1 - 5 = 4 checks
2 - 2, 2 - 3, 2 - 5, 2 - 6 = 4 checks
3 - 3, 3 - 6 = 2 checks
4 - 4, 4 - 5, 4 - 7, 4 - 8 = 4 checks
5 - 5, 5 - 6, 5 - 8, 5 - 9 = 4 checks
6 - 6, 6 - = 2 checks
7 - 7, 7 - 8 = 2 checks
8 - 8, 8 - 9 = 2 checks
9 - 9 = 1 check
25 checks
That might seem a lot so lets see how much it is if we group all objects perfectly (will probably never happen, but the worst case is still the same as before): 10 units in every square, so we got 90 every check is 9*10/2 = 45
45 * 25 = 1.125
90 objects without a grid = 90*91/2 = 4095
180 opbjects with perfect grid placement = 5250
Now let's think about a larger grid, like 16 fields: 9*4 + 6*2 +1*1 checks = 49 checks * 1/16² = 49/256 wich is a bit less than 1/5.
.
New question: How do we define the grid size?
Well, the grid can be built on every iteration, sorting everything into a grid every time you need it has a lower runtime than updating the grid by checking borders. (A quadtree would need a lot higher performance because you have to check 4 borders on every iteration or 2 per depth level to find the new position.)
Sorting everything in on every iteration allows us to use a dynamic squaresize wich has to at least be slightly higher than the biggest radius of your objects.
Example, your mapsize is 256 and your biggest object has a radius of 1.5 (diameter of 3). Your gridsize is 2. 128*128 squares, 127*127*4 + 127*2*2 + 1 checks = 65.025 checks
Sounds ridiculous? Sure, the checks will kill your computer, even though you will probably only check for 100 collision if you randomly spread 1000 objects. Oh, and don't forget to empty the grid after each run...
But we can fix that. Add an integer for every grid position and a global one. Increase your global integer every time you run a collision check (for the whole field). Whenever you add an object to the grid position you check if the integer on that field equals your global int, if it doesn't clear the object list for that field and update the integer (then add the object).
Now we get to the second problem, we have to know wich squares are used and wich aren't. We just need another global integer and an integer array wich has to be equal (or greater) than the object count. The integer will be our counter, before we start the whole check we have to set it to -1 (every time). When we add an object to a square in the grid and the integer on that position is updated we have to increase our counter and set our array[counter] to the gridposition.
.
The last thing we have to do is run 4 checks for every gridposition saved in that array:
square with itself (in case there is only 1 object 0 collision checks are needed)
square with the square to its right (0 objects = 0 collision checks)
square with the one below (0 objects = 0 collision checks)
.
1000 objects: worst case (fields to check): 4000 and probably less than 100 collision checks
1000 objects without grid (n*(n+1)/2) = 500.500 collision checks...
.
No evil funcs needed (square root, sin, cos etc. are slow).
Btw. it's still O(n²). Oh, and I'd suggest a grid size between 4 and 8, a slight bit more collision checks and less squares to check.
Thanks for reading (if you did so :D).
edit: Small note, if you want to add unmovable objects, add a second list to each square in the grid wich contains them. Now you have to check all 9 fields around (including the field where your object is) for unmovable objects and the normal 4 fields for movable objects. This makes unmovable objects your biggest friends because you can add thousands of em and won't even feel it.
0
thanks a lot, that really helped!
0
Can you upload a full native list? I still use an old version http://paste.sc2mapster.com/1979/ "Date posted 22 Apr 2010". Or tell me where I can find one?
0
Your assumption is right (the way i understand it). Creating a record for it would just change the names of the variables.
score[player][1] can be used as the first value for a player and score[player][2] as the second value
0
@Kueken531: Go
oh my god, how did host target get there o.o that doesn't make sense in any way
Thanks for finding that, I was looking through my effects all the time and couldnt find a thing.
Fixed version:
0
Here is my answere to the second challenge! The zerg run shit scare when they notice the earthquake but they will still attack you when they notice your presence, even on the shaking earth. The zergs enemies must be slayn at all costs. The earthquake deals a huge amount of damage to nearby buildings, the closer to the center, the more dmg it deals.
Try loading your marine into the medivac to move your eathquake around without fearing those zerglings and ultralisks!
Problems: Giving orders to any unit somehow changes the "target" of all the used effects, so the earth rumbles at any given order target point. Anyone knows how to fix it?
edit: attached fixed version
0
@fosere: Go
Isn't that just an aoe effect? I thought auras are moving with the emitting unit.
0
@Chiquihuite: Go
It's kinda complicated and uses too much different stuff (from my view, I want it shorter :D).
The target unittype needs the specific morph ability (found no way around it, but i'm still searching). This morph ability is triggered by an "issue order" via my search area. To add some eyecandy I created a continous model, activating it in the actor events, "moph ability.name.start". This would only add the egg and look really bad (just an egg appearing out of nowhere o.o), to cover this there is an eggsplosion add the beginning and one at the end (the name is "Eggsplosion Generic").
If you got more questions just ask, my descriptions always lack content (I just bad at explaining).
lemme see... do I get more points if I fulfill that one too?
0
Challenge accepted :3, sorry, can't add a video, but I hope the map will do! (will probably add some additional eyecandy and a proper description)
0
Well, you don't need to create the game yourself, just the terrain. I for example am always searchign for a good terrainer (I don't have any terrain skills at all :P).
If you are willing to help, I'd like to contact you when one of my maps reaches a status where terrain is needed (beta +).
0
You could just add a boolean for compression (if true compress, if false then not...), experienced mappers will know beforehand if it is usefull (in case you comment accordingly xD).