I'll be trying to implement the above method but I'm so bad at the data editor, got to remove all line of sight, that it's almost sad so I won't be doing it anytime soon.
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.
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?
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.
Not entirely sure what you mean so could you explain it a bit better or make a small demo?
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.
Today i finished the wall dig selection with perfect camera aiming
Now i'm starting with the AI ;)
Just wondering, how can you make it perfect? Sure it'll select all walls within the co-ordinance but it won't be like you can click on the actor edge of the block and select it if the camera isn't on top of it.
If so could you share your methods? Would be interesting.
EDIT: You made sure to make those green blocks are unit actors so they're hidden from other players right?
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?
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?
Figured that was the only possible solution. I might look into it later down the road though because if I'd have to implement it I'd have to make it work from all angles.
Well, on my part I'm progressing steadily. I'll just list them here:
Taking advantage of records (thanks for telling me about them) to organize the code a lot more.
Better AI code and they're now able to dig, claim paths, and reenforce walls.
Incorporated the build feature, the UI hasn't been implemented yet but trigger wise it works.
Can sell structures
Getting someone to make me a block model. Not entirely sure when but I'll most likely get it within 1/2 weeks.
Some stuff I haven't done yet would be my own custom sight system. This is due to an actor issue. Looking into it later.
I've probably forgot some stuff but that's essentially it.
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?
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
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.
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?
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.
So to the practical usage of this method.
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.
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 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
Well, this isn't an issue for me due to the only blocks having dummy units are blocks that are accessible by foot. This means no dummy that are ot of reach. However, unclaimed paths have dummy units though they're limited to one block away from the claimed ones. Claimed paths don't have dummy units because I don't really have any use for it.
So no issue here on my part. It seems to work really well.
0
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)
The thing is that you still need path blockers. Yeah, you can create your own path blockers but it can require even more variable memory, depending on implementation, so I simply decided to utilize the path blockers from the dummy units so it's not really an issue on my part.
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.
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
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 ;)
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
Quote from Bibendus:
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 then...
----
omg, if this is true, Blizzard is seriously pure evilness with their limitations.. but then again, with decent code, you should not have anywhere near 1000+ threads running at a time :p there is always a work-around to this error I guess, but it still is annoying with all these random limitations..
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
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?
Not entirely sure what you mean so could you explain it a bit better or make a small demo?
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.
Today i finished the wall dig selection with perfect camera aiming
Now i'm starting with the AI ;)
Well done.
I'm presuming the greenish tiles are the ones selected for mining in the pic?
Just wondering, how can you make it perfect? Sure it'll select all walls within the co-ordinance but it won't be like you can click on the actor edge of the block and select it if the camera isn't on top of it.
If so could you share your methods? Would be interesting.
EDIT: You made sure to make those green blocks are unit actors so they're hidden from other players right?
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?
Figured that was the only possible solution. I might look into it later down the road though because if I'd have to implement it I'd have to make it work from all angles.
Well, on my part I'm progressing steadily. I'll just list them here:
Some stuff I haven't done yet would be my own custom sight system. This is due to an actor issue. Looking into it later.
I've probably forgot some stuff but that's essentially it.
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?
I smell MINECRAFT!!
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.
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.
So to the practical usage of this method.
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:
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.
Been thinking about it, maybe.
Hope this will be done, because it looks pretty neat! :D
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
Well, this isn't an issue for me due to the only blocks having dummy units are blocks that are accessible by foot. This means no dummy that are ot of reach. However, unclaimed paths have dummy units though they're limited to one block away from the claimed ones. Claimed paths don't have dummy units because I don't really have any use for it.
So no issue here on my part. It seems to work really well.
The thing is that you still need path blockers. Yeah, you can create your own path blockers but it can require even more variable memory, depending on implementation, so I simply decided to utilize the path blockers from the dummy units so it's not really an issue on my part.
Bed time.
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.
@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
Nice to know you can use data tables for emergency :D
Can I use arrays too? Else it's useless ;)
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
Quote from Bibendus:
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 then...
----
omg, if this is true, Blizzard is seriously pure evilness with their limitations.. but then again, with decent code, you should not have anywhere near 1000+ threads running at a time :p there is always a work-around to this error I guess, but it still is annoying with all these random limitations..