Today I tried to spawn 50 workers and I got a wonderful error: too many threads :O
I do too many for cycles to check all nearby tiles for all units for all players and it seems there is a limit of 1000 threads working at the same time!
Need to rework it a bit and I don't know how :O
Just wanted to throw in that Data Tables most likely don't use up additional memory.
You can try using them to store your units and other variables.
The read/write times are higher though. I did some testing a while ago, but I can't remember the exact results. I believe it's about 4-5 times slower than a normal variable access.
Nice to know you can use data tables for emergency :D
Can I use arrays too? Else it's useless ;)
I already use unit pathing only to borderline tiles but I need a unit for each gold resource to show on the map too.
You didn't made the sight trigger so you don't know what I mean ;)
My dummy units have path blocking already have path blocking, now I'll make dummy units with no path blocking for the borderline unconquered tiles too
Well, my map is 64x64 blocks so I use half the memory you use. I'll make sure to keep track of my variable usage.
Actually is not 1/2 but 1/4 less :D
Don't u think 64x64 is too small for a 4 players map? I'm going to make the level generation dynamic so everyone someone creates a game can choose the size of the map depending on his computer and the game mode he chooses to play.
Let's take claming a path as an example. Due to cycling points coordinates being hugely resource demanding I decided simply to create hidden dummy units above these unclaimed paths, just next to claimed ones, and added all of them into a 'unclaimed' unit group variable. This way, I could simply loop through all picked units and find the closest one. What's funny is that this isn't resource demanding.
I feared that, i didn't want to use more units cause i already use them for wall pathing and gold resources.
however it seems better then just cycling all the tiles of the map :D
A worker figures out that unclaimed path exists, the closest unclaimed block is then sent via parameter to a custom action. The worker is then added to the unit group Worker[player][x][y]. (x,y being the location of the closest block)
Now, the custom action checks for these conditions:
Worker[player][x][y] is empty.
The Worker is within 1 range of the block.
If the worker suddenly disappears then the thread is broken and the block is reset. However, if the worker got to the block then wait 2 second and the path is claimed and the worker has to start again.
Hopefully you got an idea on how it works, also take a look at my AI image a couple of pages back.
I will use a slightly different method. I already store in the huge array the confinant tiles to reduce greatly the amount of calculations to just the interesting tiles. I'll use that to create the dummy unit and recreate it on near tiles when it is destroyed (if needed)
As I said the limit for variables memory size is really small, it's something around 300k variables (counting each array index too).
That means that the editable world would be really small
I don't know how is your left available memory space for variables on your map but I reached the limit with the big 128x128 tiles struct array :|
Try to predict now the variables you want to use in the future if you don't want bad surprises :D
For my AI I still didn't decide if looping toward all tiles to check what must be digged out is a good idea, did you save your digging tile coordinates somewhere or you just loop all tiles every 0.5 secs for each worker?
If u can find the camera position you can find the correct point in the trajectory at the height of the wall.
My walls have a height of 3 so I do some maths to get the point at that height in the trajectory between the cam position and the clicked point.
The green blocks are units that get created ONLY if some player has selected the tile. Then I share their vision to all players that selected the single tile.
Do you mean I can use just unit actors or u were talking about units?
Today I managed to finish my sight system, it works well but sc2 sight check can pass through 2 diagonal adiacent squares.
I will need to make my own sight check but for now I'm ok.
Next step is the digging system with AI.
Whenever I have to do massive data editor stuff like that (many units, etc.), I tend to cheat. If I can get away with it, for example, I'll put all the units in an array and catalogfieldvalueset the units at the beginning of the map.
Nobody recommends it, but if you think it would work for you, I could whip something together for you. After all, better to cheat and get it done than not get it done at all.
How would you use catalog fields for that exactly?
No you don't sound dumb :D
Even if your ideas can be wrong don't worry about that, it could help me thinking in a different way finding the solution!!!
The problem is that this kind of map requires huge amounts of optimizations, else I could have used units (buildings) to achieve the exploration.
Unfortunately 16384 units are too heavy to manage on SC2 so I'm trying to figure out the best way to do that with actors.
Coming back to your suggestion it would require 16k regions + 16k revealers instead of just 16k revealers. Still trying to find a better solution that doesnt involve soo many revealers to be used :O
Oh and making 16k regions would require 16k events, added on triggers with galaxy script (ouch) :D
Yes, that's the second point I was talking about, assigning a revealer for each dungeon tile. I'm going to test if it's a huge CPU load or not but the big problem will be the checking of sight.
A periodic trigger is needed to check the sight of each unit and add the revealer where it's missing :|
Oh and this method doesnt allow me to make a pre-explored map with fog of war, I'm forced to use the black mask and that would cause problems in gold searching
The problem is related to doodad positioning when you create them with triggers.
They seem placed in the correct place but they are explored as they are placed on 0,0 coordinates.
That means that you can just explore all of them at the same time but you can't spot the single doodad while exploring.
I'm trying to make a map example to show this bug and I think I will report this in the blizzard forum where noone will read it and it won't be ever fixed :|
I encountered a big problem with line of sight exploration!
It seems that all dodads created by triggers are explored only when you can spot the bottom left corner of the map (coords 0,0)
I suppose that this is a sc2 bug but it blocks the possibility to enable dungeon exploration.
The only solutions for now are:
1) Use a pre-made terrain. That means I can't random generate it and that people with less powerful computers can't play on smaller maps.
2) Make model actors instead of doodads actors. That means that walls will disappear when out of sight forcing me to keep areas explored using triggers :|
Today I tried to spawn 50 workers and I got a wonderful error: too many threads :O
I do too many for cycles to check all nearby tiles for all units for all players and it seems there is a limit of 1000 threads working at the same time!
Need to rework it a bit and I don't know how :O
Nice to know you can use data tables for emergency :D
Can I use arrays too? Else it's useless ;)
@redmarine: Go
I already use unit pathing only to borderline tiles but I need a unit for each gold resource to show on the map too.
You didn't made the sight trigger so you don't know what I mean ;)
My dummy units have path blocking already have path blocking, now I'll make dummy units with no path blocking for the borderline unconquered tiles too
Actually is not 1/2 but 1/4 less :D
Don't u think 64x64 is too small for a 4 players map? I'm going to make the level generation dynamic so everyone someone creates a game can choose the size of the map depending on his computer and the game mode he chooses to play.
I feared that, i didn't want to use more units cause i already use them for wall pathing and gold resources.
however it seems better then just cycling all the tiles of the map :D
I will use a slightly different method. I already store in the huge array the confinant tiles to reduce greatly the amount of calculations to just the interesting tiles. I'll use that to create the dummy unit and recreate it on near tiles when it is destroyed (if needed)
As I said the limit for variables memory size is really small, it's something around 300k variables (counting each array index too).
That means that the editable world would be really small
I don't know how is your left available memory space for variables on your map but I reached the limit with the big 128x128 tiles struct array :|
Try to predict now the variables you want to use in the future if you don't want bad surprises :D
For my AI I still didn't decide if looping toward all tiles to check what must be digged out is a good idea, did you save your digging tile coordinates somewhere or you just loop all tiles every 0.5 secs for each worker?
If u can find the camera position you can find the correct point in the trajectory at the height of the wall.
My walls have a height of 3 so I do some maths to get the point at that height in the trajectory between the cam position and the clicked point.
The green blocks are units that get created ONLY if some player has selected the tile. Then I share their vision to all players that selected the single tile.
Do you mean I can use just unit actors or u were talking about units?
And how is your progress going?
Today i finished the wall dig selection with perfect camera aiming
Now i'm starting with the AI ;)
Today I managed to finish my sight system, it works well but sc2 sight check can pass through 2 diagonal adiacent squares.
I will need to make my own sight check but for now I'm ok.
Next step is the digging system with AI.
How would you use catalog fields for that exactly?
@redmarine: Go
Yep, more or less.
How did u manage the revealing thing? You pre-placed terrain, right?
@Wolf1322: Go
No you don't sound dumb :D
Even if your ideas can be wrong don't worry about that, it could help me thinking in a different way finding the solution!!!
The problem is that this kind of map requires huge amounts of optimizations, else I could have used units (buildings) to achieve the exploration.
Unfortunately 16384 units are too heavy to manage on SC2 so I'm trying to figure out the best way to do that with actors.
Coming back to your suggestion it would require 16k regions + 16k revealers instead of just 16k revealers. Still trying to find a better solution that doesnt involve soo many revealers to be used :O
Oh and making 16k regions would require 16k events, added on triggers with galaxy script (ouch) :D
@Wolf1322: Go
Yes, that's the second point I was talking about, assigning a revealer for each dungeon tile. I'm going to test if it's a huge CPU load or not but the big problem will be the checking of sight.
A periodic trigger is needed to check the sight of each unit and add the revealer where it's missing :|
Oh and this method doesnt allow me to make a pre-explored map with fog of war, I'm forced to use the black mask and that would cause problems in gold searching
The problem is related to doodad positioning when you create them with triggers.
They seem placed in the correct place but they are explored as they are placed on 0,0 coordinates.
That means that you can just explore all of them at the same time but you can't spot the single doodad while exploring.
I'm trying to make a map example to show this bug and I think I will report this in the blizzard forum where noone will read it and it won't be ever fixed :|
I encountered a big problem with line of sight exploration!
It seems that all dodads created by triggers are explored only when you can spot the bottom left corner of the map (coords 0,0)
I suppose that this is a sc2 bug but it blocks the possibility to enable dungeon exploration.
The only solutions for now are:
1) Use a pre-made terrain. That means I can't random generate it and that people with less powerful computers can't play on smaller maps.
2) Make model actors instead of doodads actors. That means that walls will disappear when out of sight forcing me to keep areas explored using triggers :|
Obviously, there is no sense on keeping a thread alive for each dummy unit on each tile :D