The shield model not appear is just visual as you said. I believe this can be resolved just by going into the actor that controls when the shield model appears and adding in new events to make and destroy the model for the new levels of the buff.
I looked at the XML for the actor "GuardianShield" and it's exactly as I thought:
this actor event creates the guardian shield model when the persistent effect starts
since you had to make a persistent effect for each level, you need to add these in as sepearate events
so the shield model will come up
and don't forget to destroy the model when the persistent wears off
<On Terms="Effect.GuardianShieldPersistent.Start; At Caster" Send="Create"/>
Hmm I've had trouble with the same issue before of these add-attribute behaviors not being preserved after a unit has died and been revived.
So far my method has been to know the exact impact of each attribute and then use that to calculate how many add-attributes to add on when the unit is revived. With an attribute like "CNST" which confers 1 point of health per 1 point of CNST, I tally up the max health of the unit before it dies and then whatever the difference is after I add on via the add-attribute behavior. But I haven't run into any issues with the behaviors themselves not being re-added by the trigger. I'll look into it more if indeed there is a possibility for this error.
I set up my actors for visual spell effects exactly as Photoloss' solution describes...simply use the _Unit for the target of set tint and of course make sure to set the tint back to normal when the effect wears off.
I think that doing it this way makes more efficient than indicating in every unit's actor what happens to its tint under an effect...that set up is completely arbitrary, as you're making it a property of the unit actor to change tint when really the tint changing is only happening because of the effect and nothing to do with the unit's actor. Of course if different units had different reactions to the same effect then probably going into the actor events would make more sense.
That being said, what if a unit's actor already tint it one way on creation, how would you restore that original tint set-up (like say I have a custom hydralisk which is tinted 255, 75, 85 and my effect changes its tint to 50, 50, 255). Or is there an actual "restore tint" action?
I switched to using a validator instead of requirement...the ability worked the same more or less except with the validators I no longer needed to specify requirements for the passive ability in the command card (technically the ability is just a behavior). Now, when counting ability levels, does the indexing start at 0 (so a level 1 ability would really be 0 level of that ability)?
As for the effect tree:
Searcher Behavior > Search Area Effect > Apply Disease Effect > Disease Behavior (for duration/period of damage) > Diease Damage
Only carriers can spread this disease, so it's not contagious between infected units (otherwise I would have to give a searcher behavior through the apply disease effect?).
So as it stands I've got a total of 6 behaviors and 9 effects along with 3 validators and 1 actor (for disease cloud effect). Wouldn't have a set with validators for the damage effect technically add a new effect (my 15 vs 16 with set)?
I was curious if there was a way to simplify how I implemented my disease cloud ability. The disease cloud ability is centered on a carrier/unit which causes any enemy units that make contact with the carrier to contract the disease which causes 1|2|3 points of damage/second for 2 minutes but will not kill the infected unit.
The way I have implemented it requires 3 effects and 2 behaviors for one level (a total of 15 for 3 levels). These are:
1) Damage Effect (1|2|3)
2) Search Area Effect (apply behavior disease cloud 1|2|3)
3) Apply behavior disease cloud 1|2|3
4) Area Searcher Behavior 1|2|3 (for each search area)
5) Disease cloud behavior (needs to apply a different damage/s for the periodic effect)
Is there a way to simplify this in the data editor?
Great that works!...I almost thought I was going to have to make a validator for each level (check to make sure the unit has at least X health before doing the damage so it doesn't die).
In SC1, there were spellcasters called defilers that had an AOE ability called plague, that basically damaged all units caught in it by 1 hp/s for two minutes or so.
In WC3, disease cloud was very similar...units caught in the cloud were infected and took 1 damage/second over 2 minutes.
I have no issue in implementing these abilities via the data editor except for one catch: neither ability would ever kill the unit. So say if a unit only has 30 health and is caught in a plague, the plague/disease cloud will bring the unit as low as 1 health (and obviously keep affecting the unit till it wears off) but NEVER kill it. How would I make it so an effect will do damage but not ever kill the unit?
I know next to nothing about models, art, etc. but I wondered what tools I would need to make my own custom icons/buttons. It could be something as simple as being able to create a different color version of an existing icon, like feedback is blue colored but create a red colored version?
I've just gone through making my first 3 spells with the data editor, 2 of which were made from scratch (though of course I borrowed art models, etc. from what's already in data). These spells are very simpleessentially launch some kind of missle that does impact damage and a secondary effect, like:
Frostbolt - damage effect + a stun effect
Firebolt - damage effect + a burn damage over time effect
Each spell also has 3 levels, which required me to make 3 different versions of each effect (damage effect, burn damage effect, apply stun effect, and then 3 versions of the corresponding behaviors). Making the actors for the visual effects was a lot simpler since I could reference all 3 versions of an effect/behavior in the events.
For what seems like a simple ability took about a dozen effects and half a dozen actors. In Warcraft 3 it was a lot simpler because you had almost all the spells already made so it was a matter of customization and required less detail unless you wanted to make something really novel.
Furthermore, the way I made each spell makes it tedious to add new levels or change the behavior/effect since I'd need to go to each one. In total it took me about 1 hour to create a new spell (Firebolt) based off the first spell I made (Icebolt). Is there a more efficient way to do this, since I need to end up creating almost 100 unique spells/abilities (eventually). I'm considering just using a programming language to write my own XML for each ability (once I've got the first levels/effects of it down).
I've been searching through the threads for line of sight blockers (LOS) and all the posts I find deal with not how to make/implement one but rather work around the limitations of the LOS.
I looked through the data using the keyword LOS and found the actors and footprints for the LOS already made as doodads but I couldn't find anywhere that controlled line of sight.
I tried looking at your tutorial for user types but I still haven't found the right way to do what I want (so far the string Array makes the most sense to me, but as you mentioned its not as efficient or fast as user type).
So, I set up a user type that contains two fields: String and Unit (Name and Type).
I have the following set up now:
Event: Any unit dies
Now how do I check if that unit belongs to a user type????
I haven't been able to find a function that returns a boolean like "UnitIsInstanceOfUserType(unit type, unit)"
I am not entirely familiar with most of the functionality of the editor, but I would like to know if the editor has someway to define sets/memberships of any object (actor, unit, model, behavior, ability, etc.).
The syntax I'm looking for to use is for various triggers:
set Birds = {Eagle, Dove, Raven, ..., Hawk}
set Felines = {Cat, Lion, Leopard, ..., Cheetah}
Trigger Bounty
{
event: a unit dies
if "killed unit" is in Birds:
....give "killing player" 5 minerals
else if "killed unit" is in Felines:
...give "killing player" 15 minerals
}
This is just a bunch of pseudo-code but I saw that you can make arrays as global variables, I just couldn't find a way to test for membership...
I learned through these forums that a way to manually more points to an attribute (like WC3 Strength) was to actually add a new behavior that was a permanent buff which then added the appropriate attribute point (so one stack of say "Add Strength" would add 1 point of "Strength" to the unit).
However, using the function that revives units, these buffs are not preserved and thus any additional permanent stat increases outside of the veterancy behavior are not kept.
Naturally I tried to find a work around in my revive trigger by making a variable that represents the stack count of the attribute "Strength" and then after reviving adding the difference between the variable and the current stack count of strength via "Add Strength" behavior. However, this method does not work because the stack count does not include the attribute points added via buffs (so while the unit displays say 25 Strength, the actual stack count might just be 10, with the other 15 added on by some trigger, event, etc.).
So, I tried the next step of instead of counting the strength points to count how many buffs of "Add Strength" were on the unit, save it as a variable and then essentially repeat the previous algorithm. However, no matter how many stacks of the buff "Add Strength" I give to a unit, the stack count of that behavior always returns as a 0.
The only other solution I have entertained is counting the actual unit fields (hitpoints, armor, attack speed) and modifiying them via the stat adding behaviors accordingly based on what a unit's stats are without the buffs (say a unit has 100 health before dying and revives with just 80, meaning 20 pts of health were added via "Add Strength" and if each pt health = 1 pt of Add Strength (= 1 pt of Strength), then I need to add 20 behaviors of Add Strength to the revived unit). The problem with this method is that it lacks generalization...I need to know the exact base stats of each hero for those that are modified by the attributes. This can of course be forced (make every hero have the same values for those stats and create them via attributes, i.e. a hero has a vital base of 0 but starts with 10 strength/10 base health).
I've fiddled around with set scale but the problem is it retains the original radius, inner radius, and other fields that would make sense for the original size but no longer for the new scale! (a massive zergling can still fit through a tiny opening!!).
That's the problem I ran into with upgrades/researchit gives access to exactly what I need but it affects the entire unit type (for the player) and not just a single unit instance.
All of these units will be heroes but again I'm guessing passive abilities/behaviours just can't affect all those fields. But what if you had an ability like warcraft 3 bloodlust or avatar that does make the unit appear larger (pretty sure though collision size remains the same). Would I need triggers to implement that?
To get a more realistic affect I'll probably need several versions for each unit (small zergling-normal zergling-large zergling).
What I'm confused about though is I'm pretty sure Warcraft 3 allowed editing of all those fields dynamically and in game. Perhaps there is a more powerful version of the sc2 map editor out?
0
@BiweeklyAaron: Go
The shield model not appear is just visual as you said. I believe this can be resolved just by going into the actor that controls when the shield model appears and adding in new events to make and destroy the model for the new levels of the buff.
I looked at the XML for the actor "GuardianShield" and it's exactly as I thought:
this actor event creates the guardian shield model when the persistent effect starts since you had to make a persistent effect for each level, you need to add these in as sepearate events so the shield model will come up and don't forget to destroy the model when the persistent wears off <On Terms="Effect.GuardianShieldPersistent.Start; At Caster" Send="Create"/>
0
@strongfoe: Go
Hmm I've had trouble with the same issue before of these add-attribute behaviors not being preserved after a unit has died and been revived.
So far my method has been to know the exact impact of each attribute and then use that to calculate how many add-attributes to add on when the unit is revived. With an attribute like "CNST" which confers 1 point of health per 1 point of CNST, I tally up the max health of the unit before it dies and then whatever the difference is after I add on via the add-attribute behavior. But I haven't run into any issues with the behaviors themselves not being re-added by the trigger. I'll look into it more if indeed there is a possibility for this error.
0
@Zolden: Go
I set up my actors for visual spell effects exactly as Photoloss' solution describes...simply use the _Unit for the target of set tint and of course make sure to set the tint back to normal when the effect wears off.
I think that doing it this way makes more efficient than indicating in every unit's actor what happens to its tint under an effect...that set up is completely arbitrary, as you're making it a property of the unit actor to change tint when really the tint changing is only happening because of the effect and nothing to do with the unit's actor. Of course if different units had different reactions to the same effect then probably going into the actor events would make more sense.
That being said, what if a unit's actor already tint it one way on creation, how would you restore that original tint set-up (like say I have a custom hydralisk which is tinted 255, 75, 85 and my effect changes its tint to 50, 50, 255). Or is there an actual "restore tint" action?
0
@DrSuperEvil: Go
I switched to using a validator instead of requirement...the ability worked the same more or less except with the validators I no longer needed to specify requirements for the passive ability in the command card (technically the ability is just a behavior). Now, when counting ability levels, does the indexing start at 0 (so a level 1 ability would really be 0 level of that ability)?
As for the effect tree:
Searcher Behavior
> Search Area Effect> Apply Disease Effect> Disease Behavior (for duration/period of damage)> Diease DamageOnly carriers can spread this disease, so it's not contagious between infected units (otherwise I would have to give a searcher behavior through the apply disease effect?).
So as it stands I've got a total of 6 behaviors and 9 effects along with 3 validators and 1 actor (for disease cloud effect). Wouldn't have a set with validators for the damage effect technically add a new effect (my 15 vs 16 with set)?
0
Hi everyone,
I was curious if there was a way to simplify how I implemented my disease cloud ability. The disease cloud ability is centered on a carrier/unit which causes any enemy units that make contact with the carrier to contract the disease which causes 1|2|3 points of damage/second for 2 minutes but will not kill the infected unit.
The way I have implemented it requires 3 effects and 2 behaviors for one level (a total of 15 for 3 levels). These are:
1) Damage Effect (1|2|3)
2) Search Area Effect (apply behavior disease cloud 1|2|3)
3) Apply behavior disease cloud 1|2|3
4) Area Searcher Behavior 1|2|3 (for each search area)
5) Disease cloud behavior (needs to apply a different damage/s for the periodic effect)
Is there a way to simplify this in the data editor?
Thanks!
0
@SoulFilcher: Go
Great that works!...I almost thought I was going to have to make a validator for each level (check to make sure the unit has at least X health before doing the damage so it doesn't die).
0
Hi everyone,
In SC1, there were spellcasters called defilers that had an AOE ability called plague, that basically damaged all units caught in it by 1 hp/s for two minutes or so.
In WC3, disease cloud was very similar...units caught in the cloud were infected and took 1 damage/second over 2 minutes.
I have no issue in implementing these abilities via the data editor except for one catch: neither ability would ever kill the unit. So say if a unit only has 30 health and is caught in a plague, the plague/disease cloud will bring the unit as low as 1 health (and obviously keep affecting the unit till it wears off) but NEVER kill it. How would I make it so an effect will do damage but not ever kill the unit?
Thanks!
0
Hi everyone,
I know next to nothing about models, art, etc. but I wondered what tools I would need to make my own custom icons/buttons. It could be something as simple as being able to create a different color version of an existing icon, like feedback is blue colored but create a red colored version?
Thanks!
0
Hi everyone,
I've just gone through making my first 3 spells with the data editor, 2 of which were made from scratch (though of course I borrowed art models, etc. from what's already in data). These spells are very simple
essentially launch some kind of missle that does impact damage and a secondary effect, like:Frostbolt - damage effect + a stun effect
Firebolt - damage effect + a burn damage over time effect
Each spell also has 3 levels, which required me to make 3 different versions of each effect (damage effect, burn damage effect, apply stun effect, and then 3 versions of the corresponding behaviors). Making the actors for the visual effects was a lot simpler since I could reference all 3 versions of an effect/behavior in the events.
For what seems like a simple ability took about a dozen effects and half a dozen actors. In Warcraft 3 it was a lot simpler because you had almost all the spells already made so it was a matter of customization and required less detail unless you wanted to make something really novel.
Furthermore, the way I made each spell makes it tedious to add new levels or change the behavior/effect since I'd need to go to each one. In total it took me about 1 hour to create a new spell (Firebolt) based off the first spell I made (Icebolt). Is there a more efficient way to do this, since I need to end up creating almost 100 unique spells/abilities (eventually). I'm considering just using a programming language to write my own XML for each ability (once I've got the first levels/effects of it down).
0
Hi everyone,
I've been searching through the threads for line of sight blockers (LOS) and all the posts I find deal with not how to make/implement one but rather work around the limitations of the LOS.
I looked through the data using the keyword LOS and found the actors and footprints for the LOS already made as doodads but I couldn't find anywhere that controlled line of sight.
How would I make a unit/destructible be a LOS?
Thanks!
0
Hi everyone,
How would one apply an action/condition to units in a region, like:
Remove X/all unit(s) in region 001
Thanks!
0
I tried looking at your tutorial for user types but I still haven't found the right way to do what I want (so far the string Array makes the most sense to me, but as you mentioned its not as efficient or fast as user type).
So, I set up a user type that contains two fields: String and Unit (Name and Type).
I have the following set up now:
Event: Any unit dies
Now how do I check if that unit belongs to a user type???? I haven't been able to find a function that returns a boolean like "UnitIsInstanceOfUserType(unit type, unit)"
0
Hi everyone,
I am not entirely familiar with most of the functionality of the editor, but I would like to know if the editor has someway to define sets/memberships of any object (actor, unit, model, behavior, ability, etc.).
The syntax I'm looking for to use is for various triggers:
set Birds = {Eagle, Dove, Raven, ..., Hawk}
set Felines = {Cat, Lion, Leopard, ..., Cheetah}
Trigger Bounty { event: a unit dies
if "killed unit" is in Birds: ....give "killing player" 5 minerals
else if "killed unit" is in Felines: ...give "killing player" 15 minerals }
This is just a bunch of pseudo-code but I saw that you can make arrays as global variables, I just couldn't find a way to test for membership...
Thanks!
0
Hi everyone,
I learned through these forums that a way to manually more points to an attribute (like WC3 Strength) was to actually add a new behavior that was a permanent buff which then added the appropriate attribute point (so one stack of say "Add Strength" would add 1 point of "Strength" to the unit).
However, using the function that revives units, these buffs are not preserved and thus any additional permanent stat increases outside of the veterancy behavior are not kept.
Naturally I tried to find a work around in my revive trigger by making a variable that represents the stack count of the attribute "Strength" and then after reviving adding the difference between the variable and the current stack count of strength via "Add Strength" behavior. However, this method does not work because the stack count does not include the attribute points added via buffs (so while the unit displays say 25 Strength, the actual stack count might just be 10, with the other 15 added on by some trigger, event, etc.).
So, I tried the next step of instead of counting the strength points to count how many buffs of "Add Strength" were on the unit, save it as a variable and then essentially repeat the previous algorithm. However, no matter how many stacks of the buff "Add Strength" I give to a unit, the stack count of that behavior always returns as a 0.
The only other solution I have entertained is counting the actual unit fields (hitpoints, armor, attack speed) and modifiying them via the stat adding behaviors accordingly based on what a unit's stats are without the buffs (say a unit has 100 health before dying and revives with just 80, meaning 20 pts of health were added via "Add Strength" and if each pt health = 1 pt of Add Strength (= 1 pt of Strength), then I need to add 20 behaviors of Add Strength to the revived unit). The problem with this method is that it lacks generalization...I need to know the exact base stats of each hero for those that are modified by the attributes. This can of course be forced (make every hero have the same values for those stats and create them via attributes, i.e. a hero has a vital base of 0 but starts with 10 strength/10 base health).
I would appreciate any help, thanks!
0
I've fiddled around with set scale but the problem is it retains the original radius, inner radius, and other fields that would make sense for the original size but no longer for the new scale! (a massive zergling can still fit through a tiny opening!!).
That's the problem I ran into with upgrades/research
it gives access to exactly what I need but it affects the entire unit type (for the player) and not just a single unit instance.All of these units will be heroes but again I'm guessing passive abilities/behaviours just can't affect all those fields. But what if you had an ability like warcraft 3 bloodlust or avatar that does make the unit appear larger (pretty sure though collision size remains the same). Would I need triggers to implement that?
To get a more realistic affect I'll probably need several versions for each unit (small zergling-normal zergling-large zergling).
What I'm confused about though is I'm pretty sure Warcraft 3 allowed editing of all those fields dynamically and in game. Perhaps there is a more powerful version of the sc2 map editor out?