Ah, my mistake; setting the Count to 0 in the Enumerate Area will make the validator return true only if there are 0 units with 0 of the buff in that area. What you did was make it so it searched to ensure that an infinite units in the area have 0 of the buff.
In other words, my solution contained a double negative, returning true only if there are 0 units with 0 of the behavior within the area.
The other way you could have fixed it would be by setting the (Basic) Validator: Value field in the Unit Compare Behavior Count validator to evaluate for greater than or equal to 1 or greater than 0; this would make the Enumerate Area validator run true if 0 units in the area have one or more of the buff on them.
I feel like this belongs more in the Data section of the forums.
If you haven't solved this already, simply set the Animation Properties dropdown list to Stand under the Walk index of the Animation: Baselines + field of the flying Starport actor.
Perhaps you could create a new Harvest ability using the same marker and make the Stats: Resource Time Bonus^ + field, when added to the Harvest Time as specified in the resource unit itself, equal the morph time. From there, you would set the Stats: Resource Amount Multiplier^ + field of the Harvest ability to 0 for all resources.
The idea here is to have a dummy unit (or, if possible, the Refinery itself) "harvest" from the Refinery, occupying it and preventing other units from entering and harvesting resources until the dummy unit finishes harvesting.
I have never actually attempted something like this myself, it will be interesting to see how this works out (though, I'm sure there must be a better way).
I presume you are looking for something to the effect of the minigame with the Abominations and the hooks from Uther Party in Warcraft III (or, more recently, Stitches' hook in Heroes of the Storm).
This is more complex than merely changing the target to Target Point. I imagine you would have to have a Behavior or Create Persistent effect attached to the Abduct missile to periodically check for targets along its path to attach to.
I believe he is trying to increase the arc of the Search Area effect with each successive period in a Create Persistent effect.
I can think of no other way to accomplish this other than creating a separate Search Area effect for each arc angle, from the initial angle to the final angle, and running them in chronological order in a Create Persistent effect.
I believe the problem lies in your actor events. It sounds like you have the actor events set up similarly to:
Effect.Persistent.Start
At Target
Create
Effect.Persistent.Stop
Destroy
However, for the second event, it references any Create Persistent effect of the same ID due to the way it is linked, not necessarily the specific effect which caused the creation of the actor. That is, the Destroy action runs as soon as the actor finds the stopping point of a linked Create Persistent effect within the same effect tree.
To fix this, you have a couple of options: if there are relatively few Create Persistent effects generated in succession, you can duplicate the effect and create a separate actor for each effect; otherwise, as the said method requires that there is a set amount of Create Persistent effects generated (and tends to be rather tedious), you can run a Timer Set action triggered by an Actor Creation event to destroy the actor after a set time, synced with the total duration of the Create Persistent effect.
In your case I would recommend the latter, since the amount of Create Persistent effects is variable, depending on the amount of units your primary missile encounters along its path.
I mean, you could always have the Widow Mines be trained, hidden by an opacity actor event, spawned externally for a split second, and momentarily loaded into the cargo of the Hellion/Cyclone...
Off the top of my head, I can only imagine a way to have an ability kill the Archon and create two completely new High Templar, not the two that originally merged.
Go to the Effects tab. Create a new Create Unit effect called something along the lines of "Archon Separate (Create Unit)". Set the (Basic) Effect: Spawn Unit^ field to High Templar. Change the (Basic) Effect: Spawn Count^ field to 2.
Create a new Set effect called something along the lines of "Archon Separate (Set). Add Suicide and the previously made Create Unit effect to the (Basic) Effect: Effects^ field of your Set effect.
Go to the Abilities tab. Create a new Effect - Instant ability called something along the lines of "Archon Separate". Set the (Basic) Effect: Effect + field to the Set effect created in the above step.
From here, add all the desired buttons and miscellaneous items needed to spruce up your ability for your Archon.
Create a Unit Compare Behavior Count validator. Change the (Basic) Validator: Behavior field to the buff behavior and ensure that the (Basic) Validator: Value field is set to 0.
Create an Enumerate Area validator. Set the (Basic) Target: Location + field to Caster Unit/Point. Under the (Basic) Search: Areas + field, click the green plus (+) to add a field. Set the Arc to 360, Compare to Equal To, Count to 0, and the Radius to the desired "nearby"range in which you want the validator to evaluate units for the state of the ability's auto cast. Set the Validator to the Unit Compare Behavior Count validator you created earlier.
From there, assuming you have the auto cast filters and other fields set up correctly for your ability, all you have to do is add this newly created Enumerate Area validator to the Ability: Auto Cast Validators + field of your ability.
I hope I understood your problem correctly; this makes it so that if units with the said buff are within the radius designated in the Enumerate Area validator, the ability will not be auto cast.
I imagine you could simulate the desired effect by using Morph abilites to switch between two units, identical except for their collision flags.
Let's say your unit is a Marine.
In this case, you would change the ID of the Marine to "MarineStanding" and add the Editor Suffix "(Standing)" to help you differentiate between the two. Duplicate your Marine (along with its actor) and change its name to "Marine" and ID to "MarineMoving", with the Editor Suffix "(Moving)". From here, uncheck all collision flags on the unit Marine (Moving) and check only one of the unused collision flags. This enables all Marine (Moving) units to collide with each other.
Create two buttions, one called "Moving Mode" and one called "Standing Mode". Icon and tooltips do not matter since these will be added into an inaccessible submenu on each unit's command card.
Next we need to add a Morph ability to enable them to switch between the two. Create a Morph ability called "Moving Mode". Under the (Basic) Stats: Flags + field you would check the Ignore Placement and Ignore Collision boxes. Set the button for Execute under the (Basic) Ability: Commands^ + field to Moving Mode. Under the (Basic) Ability: Info^ + field, right click and add a value, setting the unit to Marine (Moving Mode).
Repeat the above process, creating a Morph ability this time called "Standing Mode" and setting the parameters accordingly.
Duplicate the "Not Moving" validator and rename it "Moving". Change the (Basic) Validator: Compare field to Greater Than.
Add an Issue Order effect called "Morph to Moving Mode". Add the validator "Not Moving" in the Effect: Validators + field. Set the (Basic) Effect: Ability field to Moving Mode and the (Basic) Effect: Unit + field to Caster. Repeat this step, calling the effect "Morph to Standing Mode", validator Moving, and ability "Standing Mode".
Create a Buff behavior called "Marine Moving". Set the (Basic) Stats: Period^ field to 0.0625. Set the (Basic) Effect: Effect - Periodic field to Morph to Moving Mode. Set the (Basic) Behavior: Validators (Disable) + field to Moving. Repeat this step with another Buff behavior called "Marine Standing", filling in the appropriate fields.
Now back to the Units tab. Add a separate command card to the Marine (Moving) unit. Add the Standing Mode ability to its ability array. Create a new command card and add the Standing Mode button with the Standing Mode ability. Add both the Marine Moving and Marine Standing behaviors to its behavior array. Repeat this step with the Marine (Standing) unit, adding the ability Moving Mode to a new command card in addition to both behaviors.
You should now have the functionality you are looking for... I did this to accomplish something similar: I had a small unit with a large shield model and a radius that matched the shield model. Upon running out of shields, it automatically lowered its radius, so that units had to move closer in to attack it.
Have you considered using actor events in the Editor itself to accomplish this?
Once you have your actor set up with the said model, you can add a new event in the Events tab of the actor. Set the event to Actor Creation and the action to Set Opacity. From there, you can set the opacity from 0.0 to 1.0 over a set blend time, 0.0 being completely invisible and 1.0 being completely opaque. Be sure to input a name under the Label field, otherwise the opacity change will not be applied.
Sorry for the necro-post, but I just thought I should mention that with HotS it should be possible with the new bullet shell models provided by the "Korhal Palace Turret" from the last mission of the campaign.
Using multi-stage parabolic and/or ballistic movers paired with arbitrary overlays on a Launch Missile effect triggered via a "Set" effect combined with whatever "Damage"/"Launch Missile"/etc. effect is triggered on the weapon, it should be possible to create a similar visual effect, given the proper offsets on each effect or actor.
You could also possibly create a modified "Physics Capsule" unit rotated, re-textured using BorgDragon's tutorial (link below) and changed scale to look more like a bullet shell. Then you would use a "Create Unit" effect, trigger its death animation (the actual physics) and use some sort of force actor to propel the resulting bullet shell.
However, what strikes my curiosity more is if it is possible to utilize the exact physics and actors used by the actual "Korhal Palace Turret" when it fires each shot. I looked over the data for the "Korhal Palace Turret" model and the bullet shells are not included in the animation and therefore must exist in some sort of actor form or special model data within the "Korhal Palace Turret's" actor given their interaction with the terrain and sounds produced at impact. However, I have yet to figure out how this was accomplished.
Well when I did it the spines didn't render... wouldn't that conflict with the signals relaying from the Uberlisk anyway?
Also, what would be inputted into the "Inherit Type" and "Overriding Length" fields? I'm assuming "Inherit Type" should remain at "Continuous" but I am unsure as to what the "Overriding Length" field does...
BUT I did find out that the problem is actually in the Local Offsets... when I use only the Attachment Site Operations, anything updates correctly. But when I attached the marine models and gave them the Local Offsets, even they did not update. Hopefully that gets us somewhere.
Well, I successfully attached a marine model and it behaved as I want the Spine Crawlers to (with the only thing under "Host Site Operations +" being "SOpAttachSpineL/R"... however the Crawlers still do not function as planned...
Do you perhaps mean attach a [Marine] model via this method and then attach the Crawlers to the model instead of simply adding the model (I bet the answer is yes)?
Also, the AutoScan (aggro) and direct attacking worked by simply checking the "Can Initiate Attack" under the "(Basic) Weapon: Options" field per each "Impaler Tentacle" weapon, for anyone who would like it.
0
Ah, my mistake; setting the Count to 0 in the Enumerate Area will make the validator return true only if there are 0 units with 0 of the buff in that area. What you did was make it so it searched to ensure that an infinite units in the area have 0 of the buff.
In other words, my solution contained a double negative, returning true only if there are 0 units with 0 of the behavior within the area.
The other way you could have fixed it would be by setting the (Basic) Validator: Value field in the Unit Compare Behavior Count validator to evaluate for greater than or equal to 1 or greater than 0; this would make the Enumerate Area validator run true if 0 units in the area have one or more of the buff on them.
0
I feel like this belongs more in the Data section of the forums.
If you haven't solved this already, simply set the Animation Properties dropdown list to Stand under the Walk index of the Animation: Baselines + field of the flying Starport actor.
0
Perhaps you could create a new Harvest ability using the same marker and make the Stats: Resource Time Bonus^ + field, when added to the Harvest Time as specified in the resource unit itself, equal the morph time. From there, you would set the Stats: Resource Amount Multiplier^ + field of the Harvest ability to 0 for all resources.
The idea here is to have a dummy unit (or, if possible, the Refinery itself) "harvest" from the Refinery, occupying it and preventing other units from entering and harvesting resources until the dummy unit finishes harvesting.
I have never actually attempted something like this myself, it will be interesting to see how this works out (though, I'm sure there must be a better way).
0
I presume you are looking for something to the effect of the minigame with the Abominations and the hooks from Uther Party in Warcraft III (or, more recently, Stitches' hook in Heroes of the Storm).
This is more complex than merely changing the target to Target Point. I imagine you would have to have a Behavior or Create Persistent effect attached to the Abduct missile to periodically check for targets along its path to attach to.
0
@vailreth: Go
I believe he is trying to increase the arc of the Search Area effect with each successive period in a Create Persistent effect.
I can think of no other way to accomplish this other than creating a separate Search Area effect for each arc angle, from the initial angle to the final angle, and running them in chronological order in a Create Persistent effect.
0
I believe the problem lies in your actor events. It sounds like you have the actor events set up similarly to:
Effect.Persistent.Start At Target Create
Effect.Persistent.Stop Destroy
However, for the second event, it references any Create Persistent effect of the same ID due to the way it is linked, not necessarily the specific effect which caused the creation of the actor. That is, the Destroy action runs as soon as the actor finds the stopping point of a linked Create Persistent effect within the same effect tree.
To fix this, you have a couple of options: if there are relatively few Create Persistent effects generated in succession, you can duplicate the effect and create a separate actor for each effect; otherwise, as the said method requires that there is a set amount of Create Persistent effects generated (and tends to be rather tedious), you can run a Timer Set action triggered by an Actor Creation event to destroy the actor after a set time, synced with the total duration of the Create Persistent effect.
In your case I would recommend the latter, since the amount of Create Persistent effects is variable, depending on the amount of units your primary missile encounters along its path.
0
I mean, you could always have the Widow Mines be trained, hidden by an opacity actor event, spawned externally for a split second, and momentarily loaded into the cargo of the Hellion/Cyclone...
0
Off the top of my head, I can only imagine a way to have an ability kill the Archon and create two completely new High Templar, not the two that originally merged.
Go to the Effects tab. Create a new Create Unit effect called something along the lines of "Archon Separate (Create Unit)". Set the (Basic) Effect: Spawn Unit^ field to High Templar. Change the (Basic) Effect: Spawn Count^ field to 2.
Create a new Set effect called something along the lines of "Archon Separate (Set). Add Suicide and the previously made Create Unit effect to the (Basic) Effect: Effects^ field of your Set effect.
Go to the Abilities tab. Create a new Effect - Instant ability called something along the lines of "Archon Separate". Set the (Basic) Effect: Effect + field to the Set effect created in the above step.
From here, add all the desired buttons and miscellaneous items needed to spruce up your ability for your Archon.
0
Create a Unit Compare Behavior Count validator. Change the (Basic) Validator: Behavior field to the buff behavior and ensure that the (Basic) Validator: Value field is set to 0.
Create an Enumerate Area validator. Set the (Basic) Target: Location + field to Caster Unit/Point. Under the (Basic) Search: Areas + field, click the green plus (+) to add a field. Set the Arc to 360, Compare to Equal To, Count to 0, and the Radius to the desired "nearby"range in which you want the validator to evaluate units for the state of the ability's auto cast. Set the Validator to the Unit Compare Behavior Count validator you created earlier.
From there, assuming you have the auto cast filters and other fields set up correctly for your ability, all you have to do is add this newly created Enumerate Area validator to the Ability: Auto Cast Validators + field of your ability.
I hope I understood your problem correctly; this makes it so that if units with the said buff are within the radius designated in the Enumerate Area validator, the ability will not be auto cast.
0
I imagine you could simulate the desired effect by using Morph abilites to switch between two units, identical except for their collision flags.
Let's say your unit is a Marine.
In this case, you would change the ID of the Marine to "MarineStanding" and add the Editor Suffix "(Standing)" to help you differentiate between the two. Duplicate your Marine (along with its actor) and change its name to "Marine" and ID to "MarineMoving", with the Editor Suffix "(Moving)". From here, uncheck all collision flags on the unit Marine (Moving) and check only one of the unused collision flags. This enables all Marine (Moving) units to collide with each other.
Create two buttions, one called "Moving Mode" and one called "Standing Mode". Icon and tooltips do not matter since these will be added into an inaccessible submenu on each unit's command card.
Next we need to add a Morph ability to enable them to switch between the two. Create a Morph ability called "Moving Mode". Under the (Basic) Stats: Flags + field you would check the Ignore Placement and Ignore Collision boxes. Set the button for Execute under the (Basic) Ability: Commands^ + field to Moving Mode. Under the (Basic) Ability: Info^ + field, right click and add a value, setting the unit to Marine (Moving Mode).
Repeat the above process, creating a Morph ability this time called "Standing Mode" and setting the parameters accordingly.
Duplicate the "Not Moving" validator and rename it "Moving". Change the (Basic) Validator: Compare field to Greater Than.
Add an Issue Order effect called "Morph to Moving Mode". Add the validator "Not Moving" in the Effect: Validators + field. Set the (Basic) Effect: Ability field to Moving Mode and the (Basic) Effect: Unit + field to Caster. Repeat this step, calling the effect "Morph to Standing Mode", validator Moving, and ability "Standing Mode".
Create a Buff behavior called "Marine Moving". Set the (Basic) Stats: Period^ field to 0.0625. Set the (Basic) Effect: Effect - Periodic field to Morph to Moving Mode. Set the (Basic) Behavior: Validators (Disable) + field to Moving. Repeat this step with another Buff behavior called "Marine Standing", filling in the appropriate fields.
Now back to the Units tab. Add a separate command card to the Marine (Moving) unit. Add the Standing Mode ability to its ability array. Create a new command card and add the Standing Mode button with the Standing Mode ability. Add both the Marine Moving and Marine Standing behaviors to its behavior array. Repeat this step with the Marine (Standing) unit, adding the ability Moving Mode to a new command card in addition to both behaviors.
You should now have the functionality you are looking for... I did this to accomplish something similar: I had a small unit with a large shield model and a radius that matched the shield model. Upon running out of shields, it automatically lowered its radius, so that units had to move closer in to attack it.
0
First of all I would like to remark how excellent of a tutorial this is. It has proven to be extremely useful to me in the past week.
@shinzaraku: Go
Have you considered using actor events in the Editor itself to accomplish this?
Once you have your actor set up with the said model, you can add a new event in the Events tab of the actor. Set the event to Actor Creation and the action to Set Opacity. From there, you can set the opacity from 0.0 to 1.0 over a set blend time, 0.0 being completely invisible and 1.0 being completely opaque. Be sure to input a name under the Label field, otherwise the opacity change will not be applied.
0
Sorry for the necro-post, but I just thought I should mention that with HotS it should be possible with the new bullet shell models provided by the "Korhal Palace Turret" from the last mission of the campaign.
Using multi-stage parabolic and/or ballistic movers paired with arbitrary overlays on a Launch Missile effect triggered via a "Set" effect combined with whatever "Damage"/"Launch Missile"/etc. effect is triggered on the weapon, it should be possible to create a similar visual effect, given the proper offsets on each effect or actor.
You could also possibly create a modified "Physics Capsule" unit rotated, re-textured using BorgDragon's tutorial (link below) and changed scale to look more like a bullet shell. Then you would use a "Create Unit" effect, trigger its death animation (the actual physics) and use some sort of force actor to propel the resulting bullet shell.
However, what strikes my curiosity more is if it is possible to utilize the exact physics and actors used by the actual "Korhal Palace Turret" when it fires each shot. I looked over the data for the "Korhal Palace Turret" model and the bullet shells are not included in the animation and therefore must exist in some sort of actor form or special model data within the "Korhal Palace Turret's" actor given their interaction with the terrain and sounds produced at impact. However, I have yet to figure out how this was accomplished.
BorgDragon's retexturing tutorial:
http://www.sc2mapster.com/forums/resources/tutorials/20772-data-actor-events-message-texture-select-by-id/
0
@DrSuperEvil: Go
Well when I did it the spines didn't render... wouldn't that conflict with the signals relaying from the Uberlisk anyway?
Also, what would be inputted into the "Inherit Type" and "Overriding Length" fields? I'm assuming "Inherit Type" should remain at "Continuous" but I am unsure as to what the "Overriding Length" field does...
0
@DrSuperEvil: Go
I tried that... it didn't work...
BUT I did find out that the problem is actually in the Local Offsets... when I use only the Attachment Site Operations, anything updates correctly. But when I attached the marine models and gave them the Local Offsets, even they did not update. Hopefully that gets us somewhere.
0
@DrSuperEvil: Go
Well, I successfully attached a marine model and it behaved as I want the Spine Crawlers to (with the only thing under "Host Site Operations +" being "SOpAttachSpineL/R"... however the Crawlers still do not function as planned...
Do you perhaps mean attach a [Marine] model via this method and then attach the Crawlers to the model instead of simply adding the model (I bet the answer is yes)?
Also, the AutoScan (aggro) and direct attacking worked by simply checking the "Can Initiate Attack" under the "(Basic) Weapon: Options" field per each "Impaler Tentacle" weapon, for anyone who would like it.