- Joined
- Aug 14, 2007
- Messages
- 13
So I never really posted here much because I didn't enjoy editing Warcraft 3 for very long, but SC2 has resparked my interest in modding. I'm sure you have all at least heard or read something about the new "Data Editor" to be included with the SC2 editor. Here is what Galaxy Editor developer Brett Wood had to say about the tool:
So many of you may be wondering what he's actually talking about. Well, in the MPQ files within the SC2 client, all of this "data" is completely exposed for everyone to look at. All of the data is (thankfully) arranged into .xml files stored within these MPQs. Obviously, these data files are a mess of text that is difficult to understand, but the "Data Editor" within the editor itself will no doubt be a more user-friendly way of creating or modifying all kinds of data without having to open and edit these .XML files themselves.
How does this data work? I've been looking at it and trying to understand it, and I'll attempt to guide you all through an ability in Starcraft 2 created and maintained within the data files. I'm not the biggest code-wizard or anything (don't know any programming languages) of the sort, so if anyone has anything to add to my interpretations, feel free.
First, when you open up the "SC2Patch.archive" file (similar to War3xpatch.mpq), you will see the following files at the bottom:
Now, what do these mean? It's pretty simple. "Abildata.xml" defines things such as the energy cost of an ability, target types, etc. "Effectdata.xml" defines the actual effects used for abilities (effects not meaning special effects, but the actions) and can attach different actions to them. Effectdata.xml essentially runs the abilities. "Behaviordata.xml" is a very important file, which defines behaviors that contain actions to be used within the data of other files. The meat and bones of abilities are contained here. "Actordata.xml" is named, I assume, because it contains all the actions for art/effects (hence "acting" the spell? he he
). When an ability is used, all the effects/art are started and maintained by the data in that file.
I'm going to go through an ability, the Phoenix's "Graviton Beam".
Here's a description of Graviton Beam:
The first thing to look at is to open "Abildata.xml" and ctrl+F "GravitonBeam" and you come up with this:
This part is mostly uninteresting, but here we see things such as the Energy cost, the Targets, the fact that the ability is channeled, cancelable and uninterruptible by damage. Also notice it is "Re-executable", meaning you can cast it more than once. This will probably end up allowing us to put charges on abilities (for things like spider mines), though I believe there's no such abilities in the game currently (interceptors are different).
The next step is to open up "Effectdata.xml", and ctrl+F "Graviton" till we come up to the Graviton Beam ability stuff (using the JASS tool to make it more colorful and easy on the eye):
LOTS of important stuff here. The "Effectdata.xml" file is essentially what runs the abilities themselves, putting together the different behaviors and defining other things. First, at the top, all of the effects are defined. This ability can pull burrowed units out of burrow, so those are present at the top (these are mainly just for art/animation purposes). In addition, the casting Phoenix unit does not regenerate energy while channeling this ability, so that is defined as well.
Next there is this:
Here we see "GravitonBeamDummy" and "GravitonBeamBehavior". The dummy effect is essentially that, it is shown further down in the effectdata.xml file but does not do anything important to the ability's function. Finally, "GravitonBeamBehavior" is defined in the "Behaviordata.xml" file, where this ability gains its actual properties.
Here, the actual behavior "GravitonBeam" is being applied and used.
Same thing here, "GravitonBeamHeight" is being applied and used.
Lastly, the energy disabling behavior is applied. Notice this behavior is not named specifically for Graviton Beam--these behaviors are obviously definable and usable anytime you want, with any ability.
Now, what exactly ARE these behaviors? To find this out, we open up "BehaviorData.xml, and ctrl+F "GravitonBeam" and "GravitonBeamHeight".
So... this is the meat and bones of the ability. You all ought to be able to see what each of these lines do, but I'll go through it anyway.
These lines disable the targets abilities, prevent them from moving, attacking, using their detection, and make them uncommandable. In addition, units raised will not supply power (raising a warp prism, for example).
This part obviously changes the height value of the target unit and changes it's targetting type from Ground to Air for the duration of the ability.
The next thing to look at would be to open up the "Actordata.xml" file, but all that is inside of it is just a bunch of numbers and filepaths for effects/animations which correlate to their respective abilities. No doubt the actual data editor will make things much more streamlined and make it easy to edit these things. Here's that stuff if people want to see it, though:
Essentially, the "Behaviordata.xml" file contains pretty much all the relevant info for abilities. For example, Stim Packs for Marauders:
I'm not an expert on this stuff so I can't exactly tell anyone what every line of every ability within every file does, but people should be able to look at this and see that all the relevant data for abilities is stored within these files. There is obviously more I could get into and there are other things that are meaningful, especially within the "Effectdata.xml" file, but I don't really feel like going into it further. And it should be obvious that the Data Editor itself will provide an interface within the editor to create/modify this stuff very easily. So this is what Brett means by everything being "data driven".
Sooo yeah. Hope you all could ignore my obvious coding stupidity to gain some info from this.
Here's Part 2.
Hunter Seeker Missile
Hunter Seeker Missile uses 6 of the .xml data files for its construction. It uses "Abildata.xml", "Effectdata.xml", "Modeldata.xml", "Behaviordata.xml", "Moverdata.xml", and "Unitdata.xml".
For this ability, Abildata.xml defines the base ability, with it's energy cost, targetting data, etc.
Nothing here is really important, except for this:
This line of text essentially "launches" the "HunterSeekerLaunchMissile" effect, which can be found in Effectdata.xml. Here is the code for "HunterSeekerLaunchMissile" from EffectData:
You'll notice it's very short--but the important things here are "HunterSeekerDamage" and "HunterSeekerWeapon". Essentially what we've seen so far is the ability triggered, then these five lines of code are launched. ImpactEffect is obviously the effect that happens when the missile impacts the target unit. Here is "HunterSeekerDamage", the impact effect from Effectdata.xml:
There are a bunch of things we can gain from looking at this. First, creating a "damage" effect will have its own category of effect within the data editor, presumably. Second, you can easily create AoE's in which damage will be dealt and in a given fraction. Finally you can specify an amount, which can obviously be positive or negative.
Going back to the code above, the other important designation was "HunterSeekerWeapon". Notice the "AmmoUnit value=" in front of it. This led me to believe that this "HunterSeekerWeapon" was actually a unit, so I looked in "Unitdata.xml", and WHALA!!
What knowledge do we gain from this? First, this "missile" is actually a unit with "locust" properties, based on the first line of code. Second, we find this: <EditorCategories value="ObjectType
rojectile,ObjectFamily:Melee" /> . This means "projectiles" have their own Object type in the object editor, similar to Units, Items, Doodads, Destructibles, etc.
Two more things that are important. First, "HunterSeekerMissileTimeout" is a behavior. This is essentially a "timed life" effect from Warcraft III. Here is what it looks like from Behaviordata.xml:
This is very simple, it just means the unit is killed after 15 seconds.
Finally, I hit a dead end when I got here. I could not figure out where the data was that defined, for example, how fast the missile went. but then I saw this:
There is a file in the actual game directory (not the patch file, as I assume it just hasn't had any changes since the launch of the beta client in either of the two patches) called "MoverData.xml". I opened this up, searched for "HunterSeekerMissile", and what do ya know?
This isn't very easy to understand, considering this is going to be a whole new part of the object editor. But essentially Blizzard is letting us create our own projectiles. This is how abilities such as the old "Time Bomb" from the Mothership would have worked--as the game would have reacted to the projectiles defined within this new Projectile tab of the Object editor.
Anyway, you can see four different "motion phases", meaning projectiles aren't locked into one permanent behavior. I haven't actually seen a Hunter Seeker Missile used while watching streams or replays so I can't comment on how that code relates to how the ability actually works. However the code fields should speak for themselves.
So up to now, the ability is cast, the effect is launched, the missile (which is a projectile "unit) is launched, and the missile is then guided by these motion phases defined here. Finally the projectile "unit" will either impact something within 15 seconds, where it will do 100 damage, or it will be killed.
The last thing to find is where the model file for this projectile "unit" is being defined. This does not happen in "ActorData.xml" as we saw with Graviton Beam. This happens in "Modeldata.xml":
Notice how this designation's "parent" is "MissileFX", while the detonation on impact is "ImpactFX":
These are obviously designations to organize the effects for our use within the editor. There is also a "HunterSeekerDeath" impact effect, but its basically the same thing as the above.
So, that's HSM. And that's projectiles, missiles, impact events, damage effects, etc. This one probably revealed a lot more than the last...
Brett Wood said:
So many of you may be wondering what he's actually talking about. Well, in the MPQ files within the SC2 client, all of this "data" is completely exposed for everyone to look at. All of the data is (thankfully) arranged into .xml files stored within these MPQs. Obviously, these data files are a mess of text that is difficult to understand, but the "Data Editor" within the editor itself will no doubt be a more user-friendly way of creating or modifying all kinds of data without having to open and edit these .XML files themselves.
How does this data work? I've been looking at it and trying to understand it, and I'll attempt to guide you all through an ability in Starcraft 2 created and maintained within the data files. I'm not the biggest code-wizard or anything (don't know any programming languages) of the sort, so if anyone has anything to add to my interpretations, feel free.
First, when you open up the "SC2Patch.archive" file (similar to War3xpatch.mpq), you will see the following files at the bottom:
Now, what do these mean? It's pretty simple. "Abildata.xml" defines things such as the energy cost of an ability, target types, etc. "Effectdata.xml" defines the actual effects used for abilities (effects not meaning special effects, but the actions) and can attach different actions to them. Effectdata.xml essentially runs the abilities. "Behaviordata.xml" is a very important file, which defines behaviors that contain actions to be used within the data of other files. The meat and bones of abilities are contained here. "Actordata.xml" is named, I assume, because it contains all the actions for art/effects (hence "acting" the spell? he he
). When an ability is used, all the effects/art are started and maintained by the data in that file.I'm going to go through an ability, the Phoenix's "Graviton Beam".
Here's a description of Graviton Beam:
Anti-Gravity can lift enemy units into the air. Such units lose their ability to attack or use abilities.
When the phoenix uses this ability, it is rendered unpowered. A phoenix lifting a unit off the ground cannot attack. Other units must attack the target.
The Anti-Gravity ability is very useful in taking key enemy units out of commission. It cannot target massive units.
Burrowed zerg units will be unburrowed by the ability, and will reburrow when they fall back to the ground.
When the phoenix uses this ability, it is rendered unpowered. A phoenix lifting a unit off the ground cannot attack. Other units must attack the target.
The Anti-Gravity ability is very useful in taking key enemy units out of commission. It cannot target massive units.
Burrowed zerg units will be unburrowed by the ability, and will reburrow when they fall back to the ground.
The first thing to look at is to open "Abildata.xml" and ctrl+F "GravitonBeam" and you come up with this:
Code:
<CAbilEffectTarget id="GravitonBeam">
<AbilSetId value="Graviton" />
<EditorCategories value="Race:Protoss,AbilityorEffectType:Units" />
<Flags index="ReExecutable" value="1" />
- <Cost>
<Vital index="Energy" value="50" />
</Cost>
<TargetFilters value="Ground,Visible;Neutral,Massive,Structure,Destructible,Invulnerable" />
<Range value="4" />
<CancelableArray index="Channel" value="1" />
<UninterruptibleArray index="Channel" value="1" />
- <CmdButtonArray index="Execute" DefaultButtonFace="GravitonBeam">
<Flags index="ToSelection" value="1" />
</CmdButtonArray>
- <CmdButtonArray index="Cancel" DefaultButtonFace="Cancel">
<Flags index="ToSelection" value="1" />
</CmdButtonArray>
</CAbilEffectTarget>This part is mostly uninteresting, but here we see things such as the Energy cost, the Targets, the fact that the ability is channeled, cancelable and uninterruptible by damage. Also notice it is "Re-executable", meaning you can cast it more than once. This will probably end up allowing us to put charges on abilities (for things like spider mines), though I believe there's no such abilities in the game currently (interceptors are different).
The next step is to open up "Effectdata.xml", and ctrl+F "Graviton" till we come up to the Graviton Beam ability stuff (using the JASS tool to make it more colorful and easy on the eye):
JASS:
<CEffectSet id="GravitonBeamInitialSet">
<EditorCategories value="Race:Protoss" />
<EffectArray value="DisableCasterEnergyRegenApplyBehavior" />
<EffectArray value="GravitonBeamUnburrowCancel" />
<EffectArray value="GravitonBeamUnburrowLurkerCancel" />
<EffectArray value="GravitonBeamUnburrowLurker" />
<EffectArray value="GravitonBeamUnburrow" />
<EffectArray value="GravitonBeamHeightBehavior" />
</CEffectSet>
- <CEffectSet id="GravitonBeamPeriodicSet">
<EffectArray value="GravitonBeamDummy" />
<EffectArray value="GravitonBeamBehavior" />
<EditorCategories value="Race:Protoss" />
</CEffectSet>
- <CEffectApplyBehavior id="GravitonBeamBehavior">
<EditorCategories value="Race:Protoss" />
<Behavior value="GravitonBeam" />
</CEffectApplyBehavior>
- <CEffectApplyBehavior id="GravitonBeamHeightBehavior">
<EditorCategories value="Race:Protoss" />
<Behavior value="GravitonBeamHeight" />
</CEffectApplyBehavior>
- <CEffectApplyBehavior id="DisableCasterEnergyRegenApplyBehavior">
<WhichUnit Value="Caster" />
<Behavior value="DisableEnergyRegen" />
</CEffectApplyBehavior>
- <CEffectCreatePersistent id="GravitonBeam">
<ValidatorArray value="IsNotWarpBubble" />
<ValidatorArray value="NoGravitonBeamInProgress" />
<EditorCategories value="Race:Protoss" />
<WhichLocation Value="TargetUnit" />
<TimeScaleSource Value="Caster" />
<Flags index="Channeled" value="1" />
<InitialEffect value="GravitonBeamInitialSet" />
<PeriodCount value="80" />
<PeriodicValidator value="GravitonBeamValidators" />
<PeriodicPeriodArray value="0.125" />
<PeriodicEffectArray value="GravitonBeamPeriodicSet" />
</CEffectCreatePersistent>LOTS of important stuff here. The "Effectdata.xml" file is essentially what runs the abilities themselves, putting together the different behaviors and defining other things. First, at the top, all of the effects are defined. This ability can pull burrowed units out of burrow, so those are present at the top (these are mainly just for art/animation purposes). In addition, the casting Phoenix unit does not regenerate energy while channeling this ability, so that is defined as well.
Next there is this:
JASS:
- <CEffectSet id="GravitonBeamPeriodicSet">
<EffectArray value="GravitonBeamDummy" />
<EffectArray value="GravitonBeamBehavior" />
<EditorCategories value="Race:Protoss" />
</CEffectSet>Here we see "GravitonBeamDummy" and "GravitonBeamBehavior". The dummy effect is essentially that, it is shown further down in the effectdata.xml file but does not do anything important to the ability's function. Finally, "GravitonBeamBehavior" is defined in the "Behaviordata.xml" file, where this ability gains its actual properties.
JASS:
- <CEffectApplyBehavior id="GravitonBeamBehavior">
<EditorCategories value="Race:Protoss" />
<Behavior value="GravitonBeam" />
</CEffectApplyBehavior>Here, the actual behavior "GravitonBeam" is being applied and used.
JASS:
- <CEffectApplyBehavior id="GravitonBeamHeightBehavior">
<EditorCategories value="Race:Protoss" />
<Behavior value="GravitonBeamHeight" />
</CEffectApplyBehavior>Same thing here, "GravitonBeamHeight" is being applied and used.
JASS:
- <CEffectApplyBehavior id="DisableCasterEnergyRegenApplyBehavior">
<WhichUnit Value="Caster" />
<Behavior value="DisableEnergyRegen" />
</CEffectApplyBehavior>Lastly, the energy disabling behavior is applied. Notice this behavior is not named specifically for Graviton Beam--these behaviors are obviously definable and usable anytime you want, with any ability.
Now, what exactly ARE these behaviors? To find this out, we open up "BehaviorData.xml, and ctrl+F "GravitonBeam" and "GravitonBeamHeight".
JASS:
- <CBehaviorBuff id="GravitonBeam">
<Alignment value="Negative" />
<InfoIcon value="Assets\Textures\btn-ability-protoss-gravitonbeam.dds" />
<EditorCategories value="Race:Protoss,AbilityorEffectType:Units" />
<TimeScaleSource Value="Global" />
<Duration value="0.5" />
- <Modification SightMaximum="0">
<ModifyFlags index="DisableAbils" value="1" />
<ModifyFlags index="SuppressMoving" value="1" />
<ModifyFlags index="SuppressTurning" value="1" />
<StateFlags index="SuppressAttack" value="1" />
<StateFlags index="SuppressCloak" value="1" />
<StateFlags index="SuppressDetection" value="1" />
<StateFlags index="SuppressRadar" value="1" />
<StateFlags index="Uncommandable" value="1" />
<BehaviorClassDisableArray index="CBehaviorCreepSource" value="1" />
<BehaviorClassDisableArray index="CBehaviorPowerSource" value="1" />
<BehaviorClassDisableArray index="CBehaviorResource" value="1" />
<BehaviorClassDisableArray index="CBehaviorSpawn" value="1" />
</Modification>
</CBehaviorBuff>So... this is the meat and bones of the ability. You all ought to be able to see what each of these lines do, but I'll go through it anyway.
These lines disable the targets abilities, prevent them from moving, attacking, using their detection, and make them uncommandable. In addition, units raised will not supply power (raising a warp prism, for example).
JASS:
- <CBehaviorBuff id="GravitonBeamHeight">
<EditorCategories value="Race:Protoss,AbilityorEffectType:Units" />
<BuffFlags index="Channeling" value="1" />
<InfoFlags index="Hidden" value="1" />
- <Modification Height="3.75">
<HeightTime index="Start" value="1" />
<HeightTime index="Stop" value="0.25" />
<PlaneDelta index="Ground" value="-1" />
<PlaneDelta index="Air" value="1" />
</Modification>
</CBehaviorBuff>This part obviously changes the height value of the target unit and changes it's targetting type from Ground to Air for the duration of the ability.
The next thing to look at would be to open up the "Actordata.xml" file, but all that is inside of it is just a bunch of numbers and filepaths for effects/animations which correlate to their respective abilities. No doubt the actual data editor will make things much more streamlined and make it easy to edit these things. Here's that stuff if people want to see it, though:
JASS:
<!-- Graviton Beam
-->
<CActorRange id="GravitonBeamRange" parent="RangeAbil" abil="GravitonBeam" />
- <CActorModel id="GravitonBeamRocks" parent="ModelAnimationStyleContinuous">
<Host Subject="_Unit" />
<HostSiteOps Ops="SOpAttachOrigin SOpShadow" />
<On Terms="Effect.GravitonBeam.Start; At Target" Send="Create" />
<On Terms="Effect.GravitonBeam.Stop" Send="AnimBracketStop BSD" />
</CActorModel>
- <CActorBeamSimple id="GravitonBeam" parent="BeamSimpleAnimationStyleContinuous">
<HostLaunch Subject="_Unit" Scope="Caster" Actor="Find" />
<HostLaunchSiteOps Ops="SOpAttachWeapon09" />
<HostImpact Subject="_Unit" Scope="Target" Actor="Find" />
<HostImpactSiteOps Ops="SOpAttachCenter" />
<On Terms="Effect.GravitonBeam.Start" Send="Create" />
<On Terms="Effect.GravitonBeam.Stop" Send="Destroy" />
</CActorBeamSimple>
- <CActorModel id="GravitonBeamImpact" parent="ModelAnimationStyleContinuous">
<AutoScaleFactor value="0.700000" />
<Host Subject="_Unit" />
<HostSiteOps Ops="SOpAttachCenter" />
<On Terms="Effect.GravitonBeam.Start; At Target" Send="Create" />
<On Terms="Effect.GravitonBeam.Stop; At Target" Send="Create GravitonBeamImpactDeath" />
<On Terms="Effect.GravitonBeam.Stop; At Target" Send="Destroy" />
</CActorModel>
- <CActorModel id="GravitonBeamImpactDeath">
<Flags index="SuppressSaveLoad" value="1" />
<Model value="GravitonBeamImpact" />
<AutoScaleFactor value="0.700000" />
<Host Subject="_Unit" />
<HostSiteOps Ops="SOpAttachCenterStationary" />
<On Terms="ActorCreation" Send="$Death" />
<On Terms="AnimDone; AnimName Death" Send="Destroy" />
</CActorModel>
- <CActorSiteRocker id="GravitonBeamRocker">
<Elevation value="0.100000,0.050000" />
<ElevationPeriod value="2.500000,1.000000" />
<Pitch value="11.997,5.9985" />
<PitchPeriod value="3.500000,10.000000" />
<Roll value="4.9987,4.9987" />
<RollPeriod value="2.500000,1.000000" />
<On Terms="ActorCreation" Target="::Main" Send="RefSetFromMsg ::Host ::Sender" />
<On Terms="Behavior.GravitonBeamHeight.On" Send="Create" />
<On Terms="Behavior.GravitonBeamHeight.Off" Send="Transition Out 1.000000" />
<On Terms="Behavior.GravitonBeam.Off" Send="TimerSet 1.000000 DelayDestroy" />
<On Terms="TimerExpired; TimerName DelayDestroy" Send="Destroy" />
</CActorSiteRocker>
- <CActorSound id="GravitonBeamStart" parent="SoundOneShot">
<Sound value="Phoenix_GravitonBeamStart" />
<On Terms="Behavior.GravitonBeam.On" Send="Create" />
</CActorSound>
- <CActorSound id="GravitonBeamStop" parent="SoundOneShot">
<Sound value="Phoenix_GravitonBeamEnd" />
<On Terms="Behavior.GravitonBeam.Off" Send="Create" />
</CActorSound>
- <CActorSound id="GravitonBeamLoop" parent="SoundContinuous">
<Sound value="Phoenix_GravitonBeamLoop" />
<On Terms="Behavior.GravitonBeam.On" Send="Create" />
<On Terms="Behavior.GravitonBeam.Off" Send="Destroy" />
</CActorSound>Essentially, the "Behaviordata.xml" file contains pretty much all the relevant info for abilities. For example, Stim Packs for Marauders:
JASS:
- <CBehaviorBuff id="StimpackMara">
<Alignment value="Positive" />
<InfoIcon value="Assets\Textures\btn-ability-terran-stimpack.dds" />
<EditorCategories value="Race:Terran,AbilityorEffectType:Units" />
<Duration value="15" />
<Modification MoveSpeedMultiplier="1.5" AttackSpeedMultiplier="1.5" />
</CBehaviorBuff>I'm not an expert on this stuff so I can't exactly tell anyone what every line of every ability within every file does, but people should be able to look at this and see that all the relevant data for abilities is stored within these files. There is obviously more I could get into and there are other things that are meaningful, especially within the "Effectdata.xml" file, but I don't really feel like going into it further. And it should be obvious that the Data Editor itself will provide an interface within the editor to create/modify this stuff very easily. So this is what Brett means by everything being "data driven".
Sooo yeah. Hope you all could ignore my obvious coding stupidity to gain some info from this.
Here's Part 2.
Hunter Seeker Missile
Hunter Seeker Missile uses 6 of the .xml data files for its construction. It uses "Abildata.xml", "Effectdata.xml", "Modeldata.xml", "Behaviordata.xml", "Moverdata.xml", and "Unitdata.xml".
For this ability, Abildata.xml defines the base ability, with it's energy cost, targetting data, etc.
JASS:
- <CAbilEffectTarget id="HunterSeekerMissile">
<EditorCategories value="Race:Terran,AbilityorEffectType:Units" />
<Effect index="0" value="HunterSeekerLaunchMissile" />
<Flags index="AllowMovement" value="1" />
- <Cost>
<Vital index="Energy" value="125" />
</Cost>
<TargetFilters value="Visible;Self,Structure,Missile,Stasis,Dead,Hidden,Invulnerable" />
<Range value="9" />
<CmdButtonArray index="Execute" DefaultButtonFace="HunterSeekerMissile" Requirements="UseHunterSeekerMissiles" />
<ArcSlop value="0" />
<Arc value="29.9926" />
<InfoTooltipPriority value="1" />
</CAbilEffectTarget>Nothing here is really important, except for this:
JASS:
<Effect index="0" value="HunterSeekerLaunchMissile" />This line of text essentially "launches" the "HunterSeekerLaunchMissile" effect, which can be found in Effectdata.xml. Here is the code for "HunterSeekerLaunchMissile" from EffectData:
JASS:
- <CEffectLaunchMissile id="HunterSeekerLaunchMissile">
<EditorCategories value="Race:Terran" />
<ImpactEffect value="HunterSeekerDamage" />
<AmmoUnit value="HunterSeekerWeapon" />
</CEffectLaunchMissile>You'll notice it's very short--but the important things here are "HunterSeekerDamage" and "HunterSeekerWeapon". Essentially what we've seen so far is the ability triggered, then these five lines of code are launched. ImpactEffect is obviously the effect that happens when the missile impacts the target unit. Here is "HunterSeekerDamage", the impact effect from Effectdata.xml:
JASS:
- <CEffectDamage id="HunterSeekerDamage">
<EditorCategories value="Race:Terran" />
<Amount value="100" />
<ResponseFlags index="Acquire" value="1" />
<ResponseFlags index="Flee" value="1" />
<Flags index="Notification" value="1" />
<AreaArray Radius="1.6" Fraction="1" />
<AreaArray Radius="1.2" Fraction="0.5" />
<AreaArray Radius="2.4" Fraction="0.25" />
<ExcludeArray Value="Target" />
<SearchFilters value="-;Missile,Stasis,Dead,Hidden,Invulnerable" />
<Visibility value="Visible" />
</CEffectDamage>There are a bunch of things we can gain from looking at this. First, creating a "damage" effect will have its own category of effect within the data editor, presumably. Second, you can easily create AoE's in which damage will be dealt and in a given fraction. Finally you can specify an amount, which can obviously be positive or negative.
Going back to the code above, the other important designation was "HunterSeekerWeapon". Notice the "AmmoUnit value=" in front of it. This led me to believe that this "HunterSeekerWeapon" was actually a unit, so I looked in "Unitdata.xml", and WHALA!!
JASS:
- <CUnit id="HunterSeekerWeapon" parent="MISSILE_INVULNERABLE">
<Race value="Terr" />
<Mover value="HunterSeekerMissile" />
<EditorCategories value="ObjectType:Projectile,ObjectFamily:Melee" />
<BehaviorArray Link="HunterSeekerMissileTimeout" />
<LifeStart value="5" />
<LifeMax value="5" />
</CUnit>What knowledge do we gain from this? First, this "missile" is actually a unit with "locust" properties, based on the first line of code. Second, we find this: <EditorCategories value="ObjectType
rojectile,ObjectFamily:Melee" /> . This means "projectiles" have their own Object type in the object editor, similar to Units, Items, Doodads, Destructibles, etc. Two more things that are important. First, "HunterSeekerMissileTimeout" is a behavior. This is essentially a "timed life" effect from Warcraft III. Here is what it looks like from Behaviordata.xml:
JASS:
- <CBehaviorBuff id="HunterSeekerMissileTimeout">
<EditorCategories value="Race:Terran,AbilityorEffectType:Units" />
<Duration value="15" />
<ExpireEffect value="kill" />
<RemoveValidatorArray value="NotInLastMotionPhase" />
</CBehaviorBuff>This is very simple, it just means the unit is killed after 15 seconds.
Finally, I hit a dead end when I got here. I could not figure out where the data was that defined, for example, how fast the missile went. but then I saw this:
JASS:
<Mover value="HunterSeekerMissile" />There is a file in the actual game directory (not the patch file, as I assume it just hasn't had any changes since the launch of the beta client in either of the two patches) called "MoverData.xml". I opened this up, searched for "HunterSeekerMissile", and what do ya know?
JASS:
- <CMoverMissile id="HunterSeekerMissile">
<HeightMap value="Air" />
- <MotionPhases>
<Driver value="Throw" />
<Acceleration value="3200" />
<MaxSpeed value="1" />
<Clearance value="0.5" />
<ClearanceLookahead value="3" />
<Outro value="1,1.25" />
<ThrowVector value="0,-1,0" />
</MotionPhases>
- <MotionPhases>
<Driver value="Guidance" />
<Acceleration value="3200" />
<MaxSpeed value="2.5" />
<Clearance value="0.5" />
<ClearanceLookahead value="3" />
<Outro value="-4.5,-4.25" />
<YawPitchRoll value="MAX" />
</MotionPhases>
- <MotionPhases>
<Driver value="Guidance" />
<Acceleration value="4" />
<MaxSpeed value="2.5" />
<Clearance value="0.5" />
<ClearanceLookahead value="3" />
<Outro value="-2.25,-2" />
<YawPitchRoll value="MAX" />
</MotionPhases>
- <MotionPhases>
<Driver value="Guidance" />
<Acceleration value="16" />
<MaxSpeed value="20" />
<Clearance value="0.25" />
<ClearanceLookahead value="3" />
<YawPitchRoll value="MAX" />
</MotionPhases>
</CMoverMissile>This isn't very easy to understand, considering this is going to be a whole new part of the object editor. But essentially Blizzard is letting us create our own projectiles. This is how abilities such as the old "Time Bomb" from the Mothership would have worked--as the game would have reacted to the projectiles defined within this new Projectile tab of the Object editor.
Anyway, you can see four different "motion phases", meaning projectiles aren't locked into one permanent behavior. I haven't actually seen a Hunter Seeker Missile used while watching streams or replays so I can't comment on how that code relates to how the ability actually works. However the code fields should speak for themselves.
So up to now, the ability is cast, the effect is launched, the missile (which is a projectile "unit) is launched, and the missile is then guided by these motion phases defined here. Finally the projectile "unit" will either impact something within 15 seconds, where it will do 100 damage, or it will be killed.
The last thing to find is where the model file for this projectile "unit" is being defined. This does not happen in "ActorData.xml" as we saw with Graviton Beam. This happens in "Modeldata.xml":
JASS:
- <CModel id="HunterSeekerWeapon" parent="MissileFX">
<Model value="Assets\Effects\Terran\HunterKillerMissile\HunterKillerMissile.m3" />
<EditorCategories value="Race:Terran" />
</CModel>Notice how this designation's "parent" is "MissileFX", while the detonation on impact is "ImpactFX":
JASS:
- <CModel id="HunterSeekerAttackImpact" parent="ImpactFX">
<Model value="Assets\Effects\Terran\HunterKillerMissileImpact\HunterKillerMissileImpact.m3" />
<EditorCategories value="Race:Terran" />
</CModel>These are obviously designations to organize the effects for our use within the editor. There is also a "HunterSeekerDeath" impact effect, but its basically the same thing as the above.
So, that's HSM. And that's projectiles, missiles, impact events, damage effects, etc. This one probably revealed a lot more than the last...
Last edited:
