1. Updated Resource Submission Rules: All model & skin resource submissions must now include an in-game screenshot. This is to help speed up the moderation process and to show how the model and/or texture looks like from the in-game camera.
    Dismiss Notice
  2. DID YOU KNOW - That you can unlock new rank icons by posting on the forums or winning contests? Click here to customize your rank or read our User Rank Policy to see a list of ranks that you can unlock. Have you won a contest and still havn't received your rank award? Then please contact the administration.
    Dismiss Notice
  3. The Lich King demands your service! We've reached the 19th edition of the Icon Contest. Come along and make some chilling servants for the one true king.
    Dismiss Notice
  4. The 4th SFX Contest has started. Be sure to participate and have a fun factor in it.
    Dismiss Notice
  5. The poll for the 21st Terraining Contest is LIVE. Be sure to check out the entries and vote for one.
    Dismiss Notice
  6. The results are out! Check them out.
    Dismiss Notice
  7. Don’t forget to sign up for the Hive Cup. There’s a 555 EUR prize pool. Sign up now!
    Dismiss Notice
  8. The Hive Workshop Cup contest results have been announced! See the maps that'll be featured in the Hive Workshop Cup tournament!
    Dismiss Notice
  9. Check out the Staff job openings thread.
    Dismiss Notice
Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

Preview to Data Editing in Galaxy Editor

Discussion in 'StarCraft I & II' started by sixbrownsnakes2, Feb 28, 2010.

  1. sixbrownsnakes2

    sixbrownsnakes2

    Joined:
    Aug 14, 2007
    Messages:
    13
    Resources:
    0
    Resources:
    0
    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:

    Show Image
    [​IMG]


    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 :thumbs_up:). 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:

    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.


    The first thing to look at is to open "Abildata.xml" and ctrl+F "GravitonBeam" and you come up with this:

    Show Code
    Code (Text):
    <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):

    Code (vJASS):
    <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:

    Code (vJASS):
    - <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.

    Code (vJASS):
    - <CEffectApplyBehavior id="GravitonBeamBehavior">
      <EditorCategories value="Race:Protoss" />
      <Behavior value="GravitonBeam" />
      </CEffectApplyBehavior>


    Here, the actual behavior "GravitonBeam" is being applied and used.

    Code (vJASS):
    - <CEffectApplyBehavior id="GravitonBeamHeightBehavior">
      <EditorCategories value="Race:Protoss" />
      <Behavior value="GravitonBeamHeight" />
      </CEffectApplyBehavior>


    Same thing here, "GravitonBeamHeight" is being applied and used.

    Code (vJASS):
    - <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".

    Code (vJASS):
    - <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).

    Code (vJASS):
    - <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:

    Show Actordata.xml
    Code (vJASS):
     <!--  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:

    Code (vJASS):
    - <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. :grin:

    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.

    Code (vJASS):
    - <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:

    Code (vJASS):
      <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:

    Code (vJASS):
    - <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:

    Code (vJASS):
    - <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!!

    Code (vJASS):
    - <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:projectile,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:

    Code (vJASS):
    - <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:

    Code (vJASS):
      <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?

    LONG section of Code. Missile "mover" data from MoverData.xml
    Code (vJASS):
    - <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":

    Code (vJASS):
    - <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":

    Code (vJASS):
    - <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: Mar 2, 2010
  2. Ice Bane

    Ice Bane

    Joined:
    Feb 6, 2007
    Messages:
    72
    Resources:
    0
    Resources:
    0
    Great, GREAT post!
     
  3. Darkness-4ever

    Darkness-4ever

    Joined:
    Nov 4, 2007
    Messages:
    763
    Resources:
    0
    Resources:
    0
    *Brain explodes* hope they include user friendly interface, I mean sure this gives you a ton more room to customize as you please, but I prefer learning in GUI form then onto custom script form such as this, to start off right away with this would be too much for me.
     
  4. wd40bomber7

    wd40bomber7

    Joined:
    Aug 25, 2006
    Messages:
    974
    Resources:
    0
    Resources:
    0
    This is the data, not the script. So yes this will be controlled by gui, but no there won't be a custom script form. There's simply no point in putting one. In this case GUI will be able to handle everything writing by hand could, and in a much more user friendly format. There WILL be/IS script, but it is stored in the .galaxy files not in the xml format files.
     
  5. Zergleb

    Zergleb

    Joined:
    Dec 14, 2004
    Messages:
    84
    Resources:
    1
    Maps:
    1
    Resources:
    1
    I've used a lot of XML editors, and I still prefer to use just a good old XML file with a good schema over the XML visualizers and the such. So I hope they allow a "custom script"(I mean text editor with schema) format to edit.(I hate XML visualizers).
     
  6. sixbrownsnakes2

    sixbrownsnakes2

    Joined:
    Aug 14, 2007
    Messages:
    13
    Resources:
    0
    Resources:
    0
    Edited the OP to add a second section with Hunter Seeker Missile data.

    In addition, tooltip data suggests that SC2 supports arithmetic-based Dynamic Tooltips, allowing a tooltip to pull any field of data from any data file and do arithmetic with it.

    The "<d ref=" is a data reference. There may be other references as well, but any stored data can be retrieved for a tooltip and manipulated mathematically.
     
  7. sixbrownsnakes2

    sixbrownsnakes2

    Joined:
    Aug 14, 2007
    Messages:
    13
    Resources:
    0
    Resources:
    0

    Of course there's going to be a GUI. That's what the "Data Editor" is. It will have a GUI just like your Trigger Editor has a GUI. You'll notice all of the Editor Classifications within the data code itself from virtually any of the data code I've pasted in the OP. These are obviously there to organize the different data designations for more streamlined use within the Editor itself.

    Data editing will make ability making much faster, easier and more accessible to beginners.