1) Assign task to a worker
2) Assign the target to the worker
3) Assign a specific behavior to the worker that stores his current task type (conquest, dig, fortify,
etc)
4) Start an action definition that loops, storing the worker, his target and his current task type
(behavior type)
5) While looping check if the worker has the same task type and the same target, else re-assign the
target task to another worker
Adding custom behavior seems interesting, however, I got another method which I've worked on this morning.
This whole thing will be threaded meaning that each imp has its own process for doing work. Basically, this will make sure that imps will continue to do their job and not depend on an overarching system nor loops.
1) Idle state, contains a wait for condition action until a work is available.
2) If work is available, pass the unit via parameter to another task manager to get specific job.
3) In the task manager action, the unit will be sent to the highest prioritized job available, passed via parameter.
Now we enter the block of Custom Action Definition that will handle the work itself. Let's take digging as an example:
4) Get unit from the parameter, look if there are any work left in this task, if any is then send unit to the work parameter, if none then send unit back to Idle State where the process will start again.
5) ... Do work .... Done send unit back to 4 where he'll see if more work is available.
You missed the part where you manage the work abort.
For loop I mean an action definition that checks every x seconds the AI of the unit (worker).
I'll try to re-write my list being more specific
1) Each time a unit is created, an AI action definition is run on it and keeps looping every 0.5 secs until it's dead.
2) This AI decides the task to assign to its unit if it has the idle behavior (using job priorities and distance check)
3) When a unit get assigned to a specific task:
a) Create a dummy unit in the position of the specified work tile (if it doesn't exist)
b) Assign a behavior to the worker that specifying the task type
c) Assign behavior to the dummy unit that says it's assigned to a worker
d) Assign the dummy unit as follow target of the worker
e) Run action definition loop that checks if the dummy unit still has the same worker assigned, if something changed remove the "assigned" behavior from the dummy unit
4) When point is reached make another check and verify that the job can still be done
5) Complete the task
6) Check for the next task to do, trying to keep the same task type as the previous
I was busy at school. Anyhow, as I promised I'll show you a mockup of my AI. Of course, there are a lot of custom functions, actions, conditions etc. behind this system but it will give you a general idea of how mine works.
What I found quite interesting is that it works really well. Video showing how it performs on Battle.net:
It's handled by the threadded tile conditioner (Bottom right corner).
Basically, in there, I've added a couple of conditions which will run if anything interesting happens such as:
No worker = terminate the thread.
Tile is no longer marked = terminate thread.
Tile is destroyed = terminate thread and make necessary preperation for other stuff.
If any of these do happen a code is run that passes all workers to the job asigner, bottom middle of the image, which decides if the imps should do more tasks or not.
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 :|
Couldn't you make a new FOW data so that it won't fog over areas that have already been explored. Just a thought, I have no idea if it's possible, there seems to be only 2 real options, FOW hidden and FOW Reveal Radius. I imagine some combination of the 2 would make things a bit easier for you. Of course I could be completely wrong.
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 :|
Ok, just another thought I'm throwing out there. You guys will probably know better than me if this would work or not. I'm much more comfortable in the Data Editor than Trigger.
How heavy would it be resource wise to have effectively each "tile" assigned a region? Obviously it creates a bit more work for the map itself, but perhaps it could be a work around for the visability issue.
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
Ok, again I apologise for probably sounding really quite dumb an' all, but for sight, surely it could be as simple as, unit enters region 1, reveal area in region 1 for reminder of game, reveal region 2 for remainder of game, reveal region 3 for remainder of game, etc... up to how far you want the unit to see. Instead of relying on the data field for how far the unit can see, use the regions, so it'll reveal a tile at a time, omni directional for say 3 tiles for an imp, or 5 for a fly (Being a scout). Or is that exactly what you were meaning?
Again sorry for sounding dumb, just trying to help think of a way to get it working.
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
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.
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.
Adding custom behavior seems interesting, however, I got another method which I've worked on this morning.
This whole thing will be threaded meaning that each imp has its own process for doing work. Basically, this will make sure that imps will continue to do their job and not depend on an overarching system nor loops.
1) Idle state, contains a wait for condition action until a work is available.
2) If work is available, pass the unit via parameter to another task manager to get specific job.
3) In the task manager action, the unit will be sent to the highest prioritized job available, passed via parameter.
Now we enter the block of Custom Action Definition that will handle the work itself. Let's take digging as an example:
4) Get unit from the parameter, look if there are any work left in this task, if any is then send unit to the work parameter, if none then send unit back to Idle State where the process will start again.
5) ... Do work .... Done send unit back to 4 where he'll see if more work is available.
Hope you get the idea.
You missed the part where you manage the work abort.
For loop I mean an action definition that checks every x seconds the AI of the unit (worker).
I'll try to re-write my list being more specific
1) Each time a unit is created, an AI action definition is run on it and keeps looping every 0.5 secs until it's dead.
2) This AI decides the task to assign to its unit if it has the idle behavior (using job priorities and distance check)
3) When a unit get assigned to a specific task:
a) Create a dummy unit in the position of the specified work tile (if it doesn't exist)
b) Assign a behavior to the worker that specifying the task type
c) Assign behavior to the dummy unit that says it's assigned to a worker
d) Assign the dummy unit as follow target of the worker
e) Run action definition loop that checks if the dummy unit still has the same worker assigned, if something changed remove the "assigned" behavior from the dummy unit
4) When point is reached make another check and verify that the job can still be done
5) Complete the task
6) Check for the next task to do, trying to keep the same task type as the previous
Are you still here red? :D
I was busy at school. Anyhow, as I promised I'll show you a mockup of my AI. Of course, there are a lot of custom functions, actions, conditions etc. behind this system but it will give you a general idea of how mine works.
What I found quite interesting is that it works really well. Video showing how it performs on Battle.net:
Yeah, I'm still alive.
And what about the work abort?
It's handled by the threadded tile conditioner (Bottom right corner).
Basically, in there, I've added a couple of conditions which will run if anything interesting happens such as:
If any of these do happen a code is run that passes all workers to the job asigner, bottom middle of the image, which decides if the imps should do more tasks or not.
Oh ok, so you are threading units AND tiles as I said :D
Yeah. They're only threading as long as they're idle.
Obviously, there is no sense on keeping a thread alive for each dummy unit on each tile :D
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 :|
Couldn't you make a new FOW data so that it won't fog over areas that have already been explored. Just a thought, I have no idea if it's possible, there seems to be only 2 real options, FOW hidden and FOW Reveal Radius. I imagine some combination of the 2 would make things a bit easier for you. Of course I could be completely wrong.
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 :|
Ok, just another thought I'm throwing out there. You guys will probably know better than me if this would work or not. I'm much more comfortable in the Data Editor than Trigger.
How heavy would it be resource wise to have effectively each "tile" assigned a region? Obviously it creates a bit more work for the map itself, but perhaps it could be a work around for the visability issue.
@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
Ok, again I apologise for probably sounding really quite dumb an' all, but for sight, surely it could be as simple as, unit enters region 1, reveal area in region 1 for reminder of game, reveal region 2 for remainder of game, reveal region 3 for remainder of game, etc... up to how far you want the unit to see. Instead of relying on the data field for how far the unit can see, use the regions, so it'll reveal a tile at a time, omni directional for say 3 tiles for an imp, or 5 for a fly (Being a scout). Or is that exactly what you were meaning?
Again sorry for sounding dumb, just trying to help think of a way to get it working.
@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
Couldn't you use a trigger along the lines of:
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.
@redmarine: Go
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.