Just came to say that I will no longer be working on this project. Currently busy working on a new Risk Engine that, hopefully, will power Risk Revulsion in the nearest future.
Looks good so far and good luck Bibendus.
You may continue to use this thread as long as you like.
Just want to let you guys know (more specifically Bibendus) that I've postponed all Galaxy editing for now. It's most due to my homework load I've been receiving lately.
So how does your trigger behave? Each wall gets the nearest imp or each imp gets the nearest wall?
Well, I simply add the units to a unit group grid which the block has reference to. Once the unit has been added the block will decide what it does. E.g. if the tile should be claimed then it gets claimed.
So far so good.
EDIT: The workers are added to the block if that block is the nearest tile available.
Today I completed the new custom made sight check. It works good but it's a bit heavy with 50-100 units forcing my computer to make small freezes every 0.5 seconds.
With less units it works great so I will keep it as it is for now.
Now I'm focusing on the wall digging with face occupation check. It usually works but sometimes I get all workers trying to dig the same spot, checking what's wrong ;)
Edit:
Whoa I did it :D
However we are making a mistake working with imps threads because each imp searches for the nearest dig tile, however a dig tile doesn't receive the attention of the nearest imp.
I suppose i must switch the thread to the dig tile instead of the imp.
I actually ditched the imp thread for the block thread too.
Anyhow, I might return to working on the map now. Most of my school projects are done.
For the worker's digging order script I see you didn't occupy slots for each wall side so all zerglings try to dig the same spot even if they can't.
I made this check using custom unit variables but when i was trying to test my trigger with a huge amount of units I found the sight check bug (too many threads) so I'm forced to fix it before giong forward with the digging.
P.S.
You should join SC2Mapster IRC more often ;)
Well, I just haven't added that condition yet due to the fact I've only tested the system with 3-4 units.
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.
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.
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.
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?
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?
Yep, more or less.
How did u manage the revealing thing? You pre-placed terrain, right?
Well, I didn't know of that particular bug until just now when you discussed. In all of my builds it's the minions that reveal the areas. 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.
Yeah, the terrain I haven't messed with, except for digging the dungeon heart holes.
Unit enters any region, reveal area in region at triggering unit?
Nah. I assume he used a map generator to create and store regions across the map and then reveal the area around a specific tile using some sort of loop. That's what I've got in mind.
EDIT: Well, that's one way to trigger the code to reveal an area.
Just came to say that I will no longer be working on this project. Currently busy working on a new Risk Engine that, hopefully, will power Risk Revulsion in the nearest future.
Looks good so far and good luck Bibendus.
You may continue to use this thread as long as you like.
Just want to let you guys know (more specifically Bibendus) that I've postponed all Galaxy editing for now. It's most due to my homework load I've been receiving lately.
Well, I simply add the units to a unit group grid which the block has reference to. Once the unit has been added the block will decide what it does. E.g. if the tile should be claimed then it gets claimed.
So far so good.
EDIT: The workers are added to the block if that block is the nearest tile available.
I actually ditched the imp thread for the block thread too.
Anyhow, I might return to working on the map now. Most of my school projects are done.
Well, I just haven't added that condition yet due to the fact I've only tested the system with 3-4 units.
I don't. I decided to ditch it. If the limit is 1000 then I might as well thread them and make the creature AI threaded as well.
Haven't had time to work on the map for a while. Been busy at school working on projects.
Anyhow, it seems like the performance of my AI has improved quite significantly. Used to be around 50-100 with only 4 back in the old days.
50 workers here. http://i236.photobucket.com/albums/ff147/ep1309i3/Screenshot.png?t=1288621820
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.
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.
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.
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?
Not entirely sure what you mean so could you explain it a bit better or make a small demo?
Well, I didn't know of that particular bug until just now when you discussed. In all of my builds it's the minions that reveal the areas. 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.
Yeah, the terrain I haven't messed with, except for digging the dungeon heart holes.
Nah. I assume he used a map generator to create and store regions across the map and then reveal the area around a specific tile using some sort of loop. That's what I've got in mind.
EDIT: Well, that's one way to trigger the code to reveal an area.
Yeah. They're only threading as long as they're idle.