What would the "Validator - Field" be? There isn't a list of choices, but it seems to be pulling some keywords that isn't documented anywhere. Such as ShieldMax, EnergyMax, Race, Height, Radius, PlaneArray[0]. Even the values for those Fields aren't documented, such as Race values can be Zerg, Terr, Prot. How are we suppose to know that they limited it to the first four letters of a race instead of a numerical values if they didn't give us those Validators?
So, with that being said, what would be "Validator - Field" for a Region? Or how/where would I set up the value(s) for a particular region so it can be recognized in this Validator?
What I'm trying to do is only allow an ability to target a certain region of the map.
So, one way I was thinking about it was using validators, but I don't see one for region. There is a validator to check if you're building your zerg buildings on creep though.
Obviously it doesn't have to be validators, but the end results has to limit the Target Point of the Ability to a certain Region of the map.
To expand what SouLCarveRR is talking about with the variable, and what I was asking for the scope, is that your variable scope has to be within the bounds of your triggers.
So, easiest way to accomplish this is make a folder, make a variable type of Unit Group, and toss your triggers in there that involves that variable. Here's a working example of what you might want to use.
There's 3 triggers and 1 variable.
Unit Group Kill, a variable of type Unit Group, set to default empty.
Set Unit Group Kill, adds the triggering unit to the Unit Group Kill.
Kill Unit Group Kill, kills the triggering unit if and only if the triggering unit is in Unit Group Kill, else it scales it to 200%.
Remove Unit Group Kill, removes the triggering unit from Unit Group Kill.
Action you're looking for is "Set Unit Property" which gives you parameters of Unit, A Unit's Stats, and to Value.
A possible way of applying this Action is
-Actions
Unit Group - Pick each unit in ____ and do (Actions)
-Actions
Unit - Set (Picked unit) Life (Percent) to 100.0
Look at screenshot for a better view of it. The _____ (blank) part I mentioned above is where you want to apply your Biological condition. I used Unit Group: Units in Region Matching Condition. Not sure if that's what you want. The unit filter when picking units is where you want to filter out Biological required. And probably exclude the rest of the units.
I'd recommend skipping model variations altogether, and just use different models. Less hassle, more direct control.
----
They are different models, they aren't using the variations, which is why it is set to 1. Such as if I were to just change "Apple Tree Model" to use Assets\Units\Terran\Marine\Marine.m3 instead the trigger will change the model to the marine, but scaled at .5 instead of 1.00
Again, the scaling from .25 to .5 trigger works fine. Problem is with the .5 to 1.00 model change.
Marine Screenshot Caption: Blue Marine on the left is when the extra line "Set Unit Scale" action is in placed to modify it to 200%, the Blue Marine in the middle is without that line, and the Green Marine is your default marine with no changes as a reference shot.
It's pretty much just a test trigger to see if it is working, nothing special about it.
Only difference between this one which is changing a unit whose model scale is .5 to a model whose scale is 1.00 from the other trigger which is from .25 to .5 is that extra line, Set Unit Scale. But like I said, I shouldn't need to use that to fix the scale from .5 to 1.00 when the model I'm setting to is already at 1.00.
And yes, I believe so. It's Built-In/Unit/Properties/Set Unit Model Variation
whose actions are Actor - Send actor message (ModelSwap Model Variation) to main actor of unit Unit with the If Then Else clause for the Texture parameter.
The problem I'm having is the scaling is not right when it triggers and sets the unit's model variation. Such as I have 3 different models, all at different scales, .25, .50, 1.00. When it triggers for the first time, it does it correctly and changes the .25 model to the .50 model. However, when it triggers again, it changes the model, but keeps the scale the same as .50 instead of 1.00.
Anyone have any ideas what might cause this? I mean I know I can just slap on another Action to say Set Unit Scale, but that's just putting a band-aid on a problem that shouldn't occur in the first place.
What happens if the object you're trying to attach to has no attachment points. For example, doodads has no attachment points. Would it still possible to use this method to attach with some tweaking? Cause what happens for me is that the object that is attaching to the doodad is just appearing at the origin of that doodad. The local offsets are not applying.
So, I'm having trouble trying to figure out the properties to make this actors connect properly. The problem is the custom medic beam I've created is shooting out of the person being healed, instead of the caster to the target. I've found out that this is because I've forgot that the Actor Model was just th e + animation on the target being healed, which is why the beam is shooting out the person being healed.
Other details which might not be as relevant is the custom medic beam I'm making is not an ability, but just an actor model applied to a weapon, which also applies a buff. All that effect buff and such works fine.
Anyhow, so I've tried to use the Medic's Actors as a template to follow.
So I've got the following Actors; (ignoring the sound effects for now)
/// For the target being healed ///
Medic Heal Model (type - Model)
/// For the Beam Model ///
Medic Heal Beam (type - Beam simple)
Medic Heal Impact Site (type - Site / based on SiteCenter)
Medic Heal Launch Site (type - Site / based on SiteWeapon)
Now the Events for the Heal Model actor has events that calls and signals the Beam actors. So either the problem lies in Events that is calling those actors or the Art model for the Beam. The one thing I'm not sure about is the references it is making in the events. Is it alright if I use the same names (besides the HealModel custom name) references in the event?
My guess is the bounty system would be the most straight forward approach. Such as make a Unit, use the tree model for it, make sure it doesn't flee on attack, and set the "Combat - Kill Resources" to whatever you want to reward the player for killing it.
Probably easiest to just copy a building and change the model to a tree. That's done by changing the Actor associated to the unit.
(edits: you might want to look at the unit "Korhal Tree - Destructible" it is already all modeled up with a death actor animation. If you plan on having harvesting work as attacking the tree, then all you have to do is add bounty. However, if you want it to literally be a harvest point like minerals and v.gas then some more work in involved)
Obviously this is just a quick layout of what to do. There's probably little tweaks here and there you want to think about.
0
What would the "Validator - Field" be? There isn't a list of choices, but it seems to be pulling some keywords that isn't documented anywhere. Such as ShieldMax, EnergyMax, Race, Height, Radius, PlaneArray[0]. Even the values for those Fields aren't documented, such as Race values can be Zerg, Terr, Prot. How are we suppose to know that they limited it to the first four letters of a race instead of a numerical values if they didn't give us those Validators?
So, with that being said, what would be "Validator - Field" for a Region? Or how/where would I set up the value(s) for a particular region so it can be recognized in this Validator?
0
What I'm trying to do is only allow an ability to target a certain region of the map.
So, one way I was thinking about it was using validators, but I don't see one for region. There is a validator to check if you're building your zerg buildings on creep though.
Obviously it doesn't have to be validators, but the end results has to limit the Target Point of the Ability to a certain Region of the map.
0
To expand what SouLCarveRR is talking about with the variable, and what I was asking for the scope, is that your variable scope has to be within the bounds of your triggers.
So, easiest way to accomplish this is make a folder, make a variable type of Unit Group, and toss your triggers in there that involves that variable. Here's a working example of what you might want to use.
There's 3 triggers and 1 variable.
Unit Group Kill, a variable of type Unit Group, set to default empty.
Set Unit Group Kill, adds the triggering unit to the Unit Group Kill.
Kill Unit Group Kill, kills the triggering unit if and only if the triggering unit is in Unit Group Kill, else it scales it to 200%.
Remove Unit Group Kill, removes the triggering unit from Unit Group Kill.
0
Where is this UnitGroup001 being created and what is its scope?
0
Action you're looking for is "Set Unit Property" which gives you parameters of Unit, A Unit's Stats, and to Value.
A possible way of applying this Action is
-Actions
Unit Group - Pick each unit in ____ and do (Actions)
-Actions
Unit - Set (Picked unit) Life (Percent) to 100.0
Look at screenshot for a better view of it. The _____ (blank) part I mentioned above is where you want to apply your Biological condition. I used Unit Group: Units in Region Matching Condition. Not sure if that's what you want. The unit filter when picking units is where you want to filter out Biological required. And probably exclude the rest of the units.
0
Quote from greythepirate:
@odinMapster: Go
I'd recommend skipping model variations altogether, and just use different models. Less hassle, more direct control.
----
They are different models, they aren't using the variations, which is why it is set to 1. Such as if I were to just change "Apple Tree Model" to use Assets\Units\Terran\Marine\Marine.m3 instead the trigger will change the model to the marine, but scaled at .5 instead of 1.00
Again, the scaling from .25 to .5 trigger works fine. Problem is with the .5 to 1.00 model change.
Marine Screenshot Caption: Blue Marine on the left is when the extra line "Set Unit Scale" action is in placed to modify it to 200%, the Blue Marine in the middle is without that line, and the Green Marine is your default marine with no changes as a reference shot.
0
It's pretty much just a test trigger to see if it is working, nothing special about it.
Only difference between this one which is changing a unit whose model scale is .5 to a model whose scale is 1.00 from the other trigger which is from .25 to .5 is that extra line, Set Unit Scale. But like I said, I shouldn't need to use that to fix the scale from .5 to 1.00 when the model I'm setting to is already at 1.00.
0
Scaling is set at model level.
And yes, I believe so. It's Built-In/Unit/Properties/Set Unit Model Variation
whose actions are Actor - Send actor message (ModelSwap Model Variation) to main actor of unit Unit with the If Then Else clause for the Texture parameter.
0
The problem I'm having is the scaling is not right when it triggers and sets the unit's model variation. Such as I have 3 different models, all at different scales, .25, .50, 1.00. When it triggers for the first time, it does it correctly and changes the .25 model to the .50 model. However, when it triggers again, it changes the model, but keeps the scale the same as .50 instead of 1.00.
Anyone have any ideas what might cause this? I mean I know I can just slap on another Action to say Set Unit Scale, but that's just putting a band-aid on a problem that shouldn't occur in the first place.
0
Thanks for the replies, going to come back to work on this part later. Trying to get as much work done as possible first.
0
What happens if the object you're trying to attach to has no attachment points. For example, doodads has no attachment points. Would it still possible to use this method to attach with some tweaking? Cause what happens for me is that the object that is attaching to the doodad is just appearing at the origin of that doodad. The local offsets are not applying.
0
So, I'm having trouble trying to figure out the properties to make this actors connect properly. The problem is the custom medic beam I've created is shooting out of the person being healed, instead of the caster to the target. I've found out that this is because I've forgot that the Actor Model was just th e + animation on the target being healed, which is why the beam is shooting out the person being healed.
Other details which might not be as relevant is the custom medic beam I'm making is not an ability, but just an actor model applied to a weapon, which also applies a buff. All that effect buff and such works fine.
Anyhow, so I've tried to use the Medic's Actors as a template to follow.
So I've got the following Actors; (ignoring the sound effects for now)
/// For the target being healed ///
Medic Heal Model (type - Model)
/// For the Beam Model ///
Medic Heal Beam (type - Beam simple)
Medic Heal Impact Site (type - Site / based on SiteCenter)
Medic Heal Launch Site (type - Site / based on SiteWeapon)
Now the Events for the Heal Model actor has events that calls and signals the Beam actors. So either the problem lies in Events that is calling those actors or the Art model for the Beam. The one thing I'm not sure about is the references it is making in the events. Is it alright if I use the same names (besides the HealModel custom name) references in the event?
0
My guess is the bounty system would be the most straight forward approach. Such as make a Unit, use the tree model for it, make sure it doesn't flee on attack, and set the "Combat - Kill Resources" to whatever you want to reward the player for killing it.
Probably easiest to just copy a building and change the model to a tree. That's done by changing the Actor associated to the unit.
(edits: you might want to look at the unit "Korhal Tree - Destructible" it is already all modeled up with a death actor animation. If you plan on having harvesting work as attacking the tree, then all you have to do is add bounty. However, if you want it to literally be a harvest point like minerals and v.gas then some more work in involved)
Obviously this is just a quick layout of what to do. There's probably little tweaks here and there you want to think about.