Alright, here's what I got... it's not a flexible solution and it isn't even 100% accurate, although it should suffice for typical melee gameplay conditions, and it's the best I could do.
Unfortunately there's no simple built-in function to count the number of harvesters on a resource, and even though it's possible to access attribute values via triggers when (and only when) such attributes change, the harvester count shown in the unit info panel seems to be a special attribute that isn't detected by triggers. This is an area that Blizzard really ought to improve...
My solution consists of 2 behaviors, 18 validators for those behaviors (4 per worker, including MULE, to check harvesting status, plus two Combine validators - I tried to make a pun on "combine harvester" in the names, but couldn't think of anything funny), 1 trigger to apply the behaviors, and 4 functions to get harvesting information.
The first behavior, Harvester, is applied to harvesters and acts as a reference to the resource being harvested via the Unit Behavior Effect Unit function. The second behavior, Harvested, is basically the same, except it's applied to the resource from the harvester unit. The validators make sure that the behaviors are removed when necessary (I tried doing this through triggers at first, but it was much more convoluted – and probably also slower).
The Harvested behavior is allowed to stack up to 65,535 times (more than the amount of units that can be on the map at any given time, just in case you were worried), and the stack count simply gives you the number of harvesters via the Stack Count Of Behavior On Unit function.
To add a new harvest ability to this system, you'd have to:
Duplicate the following validators, rename them and update the (Basic) Validator: Ability fields:
Caster Is Gathering Target (Drone)
Caster Is Returning Cargo (Drone)
Target Is Gathering Caster (Drone)
Target Is Returning Cargo (Drone)
Add the first two to the Caster Is Harvesting validator, and add the last two to the Target Is Harvesting validator.
Duplicate one of the Unit Uses Ability events from the trigger and update the Ability parameter.
This is assuming that no unit has multiple harvest abilities (otherwise you'd need more behaviors and more validators and more complicated triggers and functions).
A test map is attached to this post and if you want to check it out, there's a little debug inspector showing the number of harvesters on a resource. You can choose a different resource to inspect by pinging on it.
Follow-up question which I'm also 99% sure I already know the answer to: is there any way to do make use of this name-to-ID lookup through triggers?
I'm making a unit spawning UI where you can filter unit names by typing into a search box and I just want to be sure there are no built-in functions I can take advantage of before I do all of the translations myself and store them in user data, like this...
I'm 99% sure of the answer to this question, but I'd like someone to confirm this: if you're using a different language than English (e.g. Deutsch, Français, Polski, etc...), are unit IDs like Marine and ZerglingBurrowed translated into your language and by extension does the makeunit cheat when you test a map create units based on the translated IDs of the units?
No, you can't get the refinery from the return cargo order as far as I know. That reference must be stored internally as part of the harvest ability, but it's not available to triggers.
Yes, you can get the unit which cast a behavior on a unit with the Unit Behavior Effect Unit function, but in this case it turns out that the caster is the SCV itself, so it's unhelpful.
I'm trying to work out a solution using dummy behaviors as a way of keeping a reference to the refinery on the SCV and vice versa, but it's a little tricky when to remove the behaviors. You'll hear from me later this week if I can figure it out and no one else beats me to it, or you can try to take a stab at it yourself.
This is clearly a bug and I'm experiencing something similar but not exactly as you describe (no flickering for me).
Does it happen in fullscreen only, in windowed mode only, or in both?
Does it happen if you completely exit SC2 and then Test Document? Or does it only happen after you Test Document a second time while SC2 is already running in windowed mode and then click on the SC2 window?
Sorry for the late reply... I found it's much easier to just create your own dialog item and fade it manually, than adapting the screen image triggers.
How can I display the scripts when I am inside the built-in library ?
Most things in the built-in library have a native implementation which cannot be seen. However, the screen image stuff can be found in this folder: Built-In / Dialog / Screen Image.
It's part of a small example map which I've attached to this post in case you want to see the details. The trigger in this map is slightly more fleshed out.
Yeah, it's better to create your own dialogs. Screen buttons/images are easier to use, but they'll limit you in the long run.
Screen buttons/images are actually just dialog items, provided by Blizzard as a convenience. You can check out the implementation of "Pulse Screen Image" in the Built-In library. Just enable View —> Show Libraries and navigate to the folder Built-In / Dialog / Screen Image. You can copy everything there, paste it into your document and modify it to suit your purposes.
I can't seem to find the field you are refering to on the footprint?
It's a flag that you can set in the footprint editor in the Placement Apply layer. It applies to every square of the build grid where the footprint is painted with that set (in the example below it's pale blue).
Also, how would I place the doodads afterwards? Can I do it on the invisible platform I'm using?
I don't know what invisible platform you're talking about. All you should need is the doodad with the properly configured footprint and cliff boost level on the actor.
0
Alright, here's what I got... it's not a flexible solution and it isn't even 100% accurate, although it should suffice for typical melee gameplay conditions, and it's the best I could do.
Unfortunately there's no simple built-in function to count the number of harvesters on a resource, and even though it's possible to access attribute values via triggers when (and only when) such attributes change, the harvester count shown in the unit info panel seems to be a special attribute that isn't detected by triggers. This is an area that Blizzard really ought to improve...
My solution consists of 2 behaviors, 18 validators for those behaviors (4 per worker, including MULE, to check harvesting status, plus two Combine validators - I tried to make a pun on "combine harvester" in the names, but couldn't think of anything funny), 1 trigger to apply the behaviors, and 4 functions to get harvesting information.
The first behavior, Harvester, is applied to harvesters and acts as a reference to the resource being harvested via the Unit Behavior Effect Unit function. The second behavior, Harvested, is basically the same, except it's applied to the resource from the harvester unit. The validators make sure that the behaviors are removed when necessary (I tried doing this through triggers at first, but it was much more convoluted – and probably also slower).
The Harvested behavior is allowed to stack up to 65,535 times (more than the amount of units that can be on the map at any given time, just in case you were worried), and the stack count simply gives you the number of harvesters via the Stack Count Of Behavior On Unit function.
To add a new harvest ability to this system, you'd have to:
This is assuming that no unit has multiple harvest abilities (otherwise you'd need more behaviors and more validators and more complicated triggers and functions).
A test map is attached to this post and if you want to check it out, there's a little debug inspector showing the number of harvesters on a resource. You can choose a different resource to inspect by pinging on it.
0
Thanks!
Follow-up question which I'm also 99% sure I already know the answer to: is there any way to do make use of this name-to-ID lookup through triggers?
I'm making a unit spawning UI where you can filter unit names by typing into a search box and I just want to be sure there are no built-in functions I can take advantage of before I do all of the translations myself and store them in user data, like this...
0
I'm 99% sure of the answer to this question, but I'd like someone to confirm this: if you're using a different language than English (e.g. Deutsch, Français, Polski, etc...), are unit IDs like Marine and ZerglingBurrowed translated into your language and by extension does the makeunit cheat when you test a map create units based on the translated IDs of the units?
0
This is a known bug. The game thinks the unit is standing. There's no easy workaround, I'm afraid.
0
I'm trying to work out a solution using dummy behaviors as a way of keeping a reference to the refinery on the SCV and vice versa, but it's a little tricky when to remove the behaviors. You'll hear from me later this week if I can figure it out and no one else beats me to it, or you can try to take a stab at it yourself.
0
If I swap your new critical section with the built-in one I get the same behavior, so I think it works for me?
0
This is clearly a bug and I'm experiencing something similar but not exactly as you describe (no flickering for me).
0
Just a heads-up that the UI editor (at least on mac) is extremely buggy and crashy. You're in for a good time!
0
Sorry for the late reply... I found it's much easier to just create your own dialog item and fade it manually, than adapting the screen image triggers.
Here's a simple trigger I created for this: http://peeeq.de/gui.php?id=3916
Map is attached to this post.
Most things in the built-in library have a native implementation which cannot be seen. However, the screen image stuff can be found in this folder: Built-In / Dialog / Screen Image.
0
You can do this with the Set Targeting Order action.
Here's a basic example: http://peeeq.de/gui.php?id=3912
It's part of a small example map which I've attached to this post in case you want to see the details. The trigger in this map is slightly more fleshed out.
0
Yeah, it's better to create your own dialogs. Screen buttons/images are easier to use, but they'll limit you in the long run.
Screen buttons/images are actually just dialog items, provided by Blizzard as a convenience. You can check out the implementation of "Pulse Screen Image" in the Built-In library. Just enable View —> Show Libraries and navigate to the folder Built-In / Dialog / Screen Image. You can copy everything there, paste it into your document and modify it to suit your purposes.
0
It's a flag that you can set in the footprint editor in the Placement Apply layer. It applies to every square of the build grid where the footprint is painted with that set (in the example below it's pale blue).
I don't know what invisible platform you're talking about. All you should need is the doodad with the properly configured footprint and cliff boost level on the actor.
0
I think you may need to change the cost of the unit itself.
There's also an "Ignore Unit Cost" flag for morph abilities.
0
Convert Player To Player Group
0
On the doodad actor, set the (Basic) Actor: Boosted Cliff Level to 1.
Then on the doodad's footprint, enable the Boost Cliff flag on the Placement Apply layer where you want the cliff level to be raised.
That's basically how you make bridges and custom cliffs/walls.
Check out the for a cool example of how this can be used.