Noticia completamente en inglés, no la han lanzado en la página de Blizzard en Español aún. Estoy seguro de que si alguien se anima a leerse las patchnotes enteras acaba con dolor de cabeza de lo largo que es
EDITOR UPDATE
We're excited to announce a major update to the StarCraft II Map Editor!
Since Wings of Liberty, your feedback has been consistent: The Editor should be easier to use. This patch aims to address this feedback without losing depth of customization. As such, we've absorbed elements from the Warcraft III editor designed for ease of use without sacrificing existing capability of the StarCraft II Editor. We have also expanded the SCII Editor's capability even further.
We encourage map makers and mod makers to jump in, explore, and send us your feedback as we're always interested in adding more exciting changes in the future. This is the largest Editor update we've ever made, and we're excited to hear what you think! Below is an overview of some of the exciting new features. It is critical for us to get feedback about how your maps are behaving with these changes. So please try publishing your custom maps to the PTR and let us know if you run into any issues or strange behavior on our PTR forum.
Before you start: Please do not to forget to backup your maps before you try them on PTR as PTR is meant to be experimental.
Also: Please keep in mind that while War Chest XP can be earned on the PTR, progress will not carry over onto the other regions, and most rewards from the War Chest will not carry over from the PTR.
Map to Map Loading
- StarCraft II now supports transitioning a multiplayer lobby between two maps.
- The two maps involved in the transition must be published by the same author.
- A new function has been added called "Online Map To Map Load", which allows the author to load an assigned "Map Slot" for all players and assign victory and defeat to different player groups.
- "Map Slots" are assigned in the Manage Published window by using the "Assign Map Slot" portion of the right-click context menu on a published map.
- Map Slots must be assigned in each region individually.
- It is recommended that the first map in the chain contain the asset dependencies required for all other maps that can potentially be transitioned to in order to reduce load times between maps.
- A new "Campaign" genre has been added that can be assigned in the Game Variants menu.
- The "Campaign" genre does not currently show up in the genre dropdown in-game, but you can still see these maps in your "My Published".
Data Collection
A data collection is a new type of catalog that allows users to declare and group a set of data elements in a collection. A collection can be thought of like any other single piece of data such as a unit, ability, or upgrade.
When copying, renaming, or deleting a data collection, the editor will intelligently apply the same action for all data elements in the collection. For example, when copying a data collection, users will be prompted to provide a name for the new collection. The editor will then duplicate every data entry within the collection and name them accordingly. The editor will also set all linked fields such that the new data entries all point to their new counterparts.
Example: Copy the Blizzard collection and set the new data collection name to be Activision Blizzard.
Deleting a data collection will delete all data entries in the collection.
Changing the id of a data collection will also change the ids of all data entries in the collection.
The data entries of a data collection can either be set manually or be auto-populated.
Data collections make use of a new key character, "@", in naming child data entries. The data collection system can automatically search the entire catalog to find any data entry whose id starts with the id of the data collection followed by the character, "@". It will then automatically add them into the collection.
Because of this linked functionality, whenever the effect tree of an ability is changed, the corresponding data collection and its data entries will automatically be updated.
The following is sample data inside an auto-populated data collection:
Though it will not be auto-populated, data that does not follow this naming conversion can be added into data collections manually.
Menu: Data Collection -> Auto Fill Data Collection will automatically search the entire catalog and find any data entry with an id that starts with the data collection id followed by the character "@". It will then automatically add them into the corresponding collection.
Menu: Data Collection -> Auto Name Data Collection will rename the data entries of the data collection based on the name of the data collection.
Data collections also allow us to add extra relationship information between data entries. For example, with data collections, the game can now understand information such as "what is the main actor for this unit?".
Many other features in this update are dependent on this data collection feature.
Data collections expect certain coding conventions or guidelines to expose their full potential:
- All data collection should be as self-contained as possible.
- For example, an "Ability collection" should always work whenever you add it to a unit, and an ability should never be hardcoded to only work on specific units or units with specific weapons. As a cautionary example, in the old SC2 database, there was a Void Ray passive that increased damage after attacking for a long duration. This passive was actually fake, and the functionality was actually hardcoded into the weapon of the Void Ray itself. In this new era with data collections, we heavily discourage this misuse of data. As such, many new features described below were created to help achieve this goal.
"Easy Mode" Data Editor
- The "Easy Mode" Data Editor is an extended feature of data collections. When turned on, the data editor will only show data collections and mimic them as if they were a single "Ability Data", "Unit Data", "Item Data", or "Upgrade Data", etc. You can copy, remove, delete, or rename this data as if it were a single data object.
- This mode is available in table view only. It combines the most important data fields such as Unit HP data or Ability Damage data.
- The fields that are shown in Easy Mode are fully customizable for each data collection type.
- One of the biggest complaints from most SC2 Editor map makers is that it's too complicated to duplicate units or abilities. This is the biggest advantage of the War3 Editor compared to the SC2 Editor.
- The combination of data collections and Easy Mode is our answer.
- In the future, we'll want to create more data based on data collections so that users can interact with them more easily.
- We encourage modders to create their own mods with data collections so they can gain their benefits. We also encourage modders of public mods to define their Easy Mode view so that other modders can easily change and modify their mods.
Accumulators
- Accumulators are a new feature that allows map makers to create formulas based on various input parameters.
- Accumulators can take Unit Custom Values and User Data as parameters.
- Accumulators not only support formulas but also user-defined tables. When combined with validators, accumulators can also be used to provide case switch functionality.
- For example, when an accumulator is used in a behavior that has varying levels and can be cast by multiple players, the accumulator will calculate the result on a per-player basis.
- Accumulators are very versatile and can be used in many places. Examples include Damage, Healing Rate, Life Regen, Damage Reduction, Ability Cost, Armor Bonus, Actor Batch Count, Persist Count, Behavior Count, Behavior Duration, Damage Fraction, Attack Speed, Movement Speed, Vital Regen, Behavior Chance, Vital Modification, etc.
- New String parse token: $AccumulatedValue:xxx$
- This token can be used to calculate AccumulatedValue in the UI. For example:
- This token can be used to calculate AccumulatedValue on UI, example:
- Calls down "d ref="$AccumulatedValue:Effect,JainaBlizzardPersistent,PeriodCount$"/>" freezing ice shard waves. Each wave deals damage to units in an area.
Player Level Response
- Player Response is a new data catalog that allows users to define response patterns when something happens for the equipped player. Designers can use triggers to equip these response patterns to certain players, and the player's units will response to the registered events as if they all had damage response behaviors.
- Users have the option to set priority and fall through methods for Player Responses.
- Player Level Response removes the need to apply certain behaviors to everyone when creating commanders, which greatly improves the performance of the game. Also, since you only need to equip responses when the corresponding commander is responding, the game no longer needs to go through the death prevention data of all the commanders every time.
- Player Response is no longer restricted to "Unit is Damaged" like damage response behaviors. For instance, it can also respond to player spawn, unit spawn, player unit death, etc.
Unsegmented Status Bar
- Trigger action: UI - Override Player Option now allows to map makers to change the style of the default status bars to be more linear and unsegmented. It is useful for custom mods that require more accurate vital fraction display.
Updated Data for the War3 Asset Mod
- On February 2015, we released a War3 Asset Mod. Though the pack only included assets, many modders wanted to learn how to create War3 RPG-style abilities with the SC2 Editor. With so many Editor changes this patch, we'd like to provide modders with some examples with all these new features.
- We worked with the creator of the community mod, Renee's Warcraft III Mod' to recreate his mod with all the new editor features.
- Now the official War3 asset mod includes a whole set of working data that includes races, units, buildings, and abilities. We hope these examples help modders get up-to-speed.
Formation Movement
- StarCraft II now supports formation movement, which can be turned on/off for each player via triggers.
- Unit can move and attack in a square formation with predefined separation distance between them.
- Currently, this formation movement won't force all units in formation to maintain the same movement speed, which is different from the War3 version.
- Modders can tweak this data to customize the behavior.
Water Pathing
- StarCraft II now supports water pathing!
- New Pathing types: Shallow Water and Deep Water.
- New over Pathing Modes: Float and Amphibious.
- Ground units can path on Ground and Shallow Water tiles.
- Float units can path on Shallow Water and Deep Water tiles.
- Amphibious units can path on Ground, Shallow Water and Deep Water tiles.
- Flying units can go anywhere that does not have air pathing blockers.
- These two new pathing types currently can only be painted by the pathing brush in Terrain Editor.
Mutiple Cliff Layers
- StarCraft II now supports up to 15 cliff layers, up from 3.
Upgrade System Revamp
- This is a big part of the Data Collection system and the new Commander system.
- The old upgrade system was not able to be self-contained, which was a deal-breaker with the new data collection philosophy. With the old upgrade system, upgrades specified the abilities or units they affected along with their corresponding upgrade effects.
- The new system allows upgrades to be much more self-contained. Units now need to declare what upgrades they use instead of letting upgrades dictate what units they affect. As an example, upgrades should no longer be implemented in the style of "Increase the life of Marines by 10". Rather they should say "Increase the life of any unit that uses me by 10".
- New CUpgrade field: EffectArrayTemplate
- This field is similar to the old EffectArray field with the following exceptions:
- It supports two additional tokens:
- ParamId: The Id of any data collection that uses the upgrade.
- ParamLevel: The current level of upgrade.
- It supports data references and use of arithmetic. Use brackets, "{" and "}", to create formulas as you would in the text editor.
- Data collections already encourage modders to name all related data with a specific naming convention, so modders can easily use ParamId for data entries related to the unit using them.
- For example:
- EffectArrayTemplate Reference="Effect,ParamId@Weapon,Amount" Value="{DataCollection,ParamId,UpgradeInfoWeapon.DamagePerLevel+3}"/
- This upgrade will increase the weapon damage amount of the unit it's used on by the unit's data collection's UpgradeInfoWeapon.DamagePerLevel field plus three.
- You can put a fixed number into the value column, e.g., Value="4".
- CUpgrade's old fields still exist and remain functionally the same, so all old upgrades still work. You can continue to create upgrades in the old style, but it is not recommended.
- All Unit Upgrade Support
- Since some upgrades are designed to work for "all units" (of a certain type), the CUpgrade now has a flag to enumerate all Data Collection Units.
- Two filter fields, EnumExcludedUserFlags and EnumRequiredUserFlags have also been added to CUpgrade that allow upgrades to filter through all the data collection units based on their flags.
- New Upgrade operations: AddBaseMultiply and SubtractBaseMultiply
- These operations modify the target field based on its default value instead of its current value, which is generally more useful than the Multiply operation. For example, if you have 100 levels of an "increase unit life by 10%" upgrade, you probably want this upgrade to increase life by a fixed number on each level rather than multiplied by the life of the last level every time. Also, Add/SubtractBaseMultiply supports tech downgrades because it can undo itself at any time, which Multiply cannot.
- Upgrades can now be used to enable or disable units for players.
- New CWeapon field: Rate Multiplier
- Has a default value of 1.
- When the game tries to get the period of a weapon or CP effect, it will take this multiplier into account.
- This change allows you to upgrade weapon speeds by a rate percentage instead of having to directly change its weapon period.
Orb System (plus Multishot and Critical Strike)
- Orbs are attack modifiers that are an important part of the MOBA genre.
- StarCraft II's damage response system can be used to create Orbs, but damage response and attack modifiers are actually very different.
- Most of the old SC2 "Orb" abilities do not fit the traditional definition of how Orbs function as they are built into weapons themselves and cannot be easily added and removed from arbitrary weapons. Thus, if you wanted to create an Orb item, it would be unrealistic to build the Orb item effects into all the hero weapons in the game.
- The Orb system we've updated here is an extended concept of generic MOBA Orb systems, which includes official support for Multishot and Critical Strike.
- A true Orb system requires the following functionality:
- Ability to apply its effects to weapon systems on a per attack basis.
- Ability to modify projectile missiles.
- Ability to add special effects when the weapon impacts the target, e.g., Fire, Frost, an Apply Behavior, etc. It should also be able to apply effects both before and after impact.
- For example, the Dark Arrow ability requires the Orb to apply a debuff to the target, and the debuff does something (raises a skeleton) when the target is killed. If the Orb system were only able to apply effects after the impact, the unit might be killed by the impact and a skeleton wouldn't be raised.
- Another example is the Orb ability, Fragmentation Shards. Because it does bonus AoE damage based on primary attack damage, the extra AoE damage effect needs to occur after the impact effect, because the randomized primary damage needs to be generated first.
- When a weapon begins its pre-swing, the attack modifier from the Orb needs to already be registered, even before the attack effect is fired. This allows units to play special attack animations such as with Critical Strike.
- Orbs need to be able to apply consistent attack damage bonuses.
- Orbs should have the option to validate their effects, e.g., the Bash and Critical Strike abilities not procing on friendly units.
- New Effect flag: MainImpact
- When on, this flag marks an effect as the main impact effect of a weapon effect tree so that attack modifiers can know when to fire their modifier effects.
- New Behavior type: CBehaviorAttackModifier
- When applied, modifiers will take effect when a weapon starts. It will register itself to the entire attack effect tree.
- The Chance field determines the chance of the attack modifier, calculated per attack.
- Multiple modifiers added to a unit. The Unique Id field allows users to determine whether they can all work at the same time. In War3, only one Orb effect can take place even if a hero has equipped multiple Orbs. However, modders will probably still want to have the option for multiple Orbs work at the same time.
- The Stack Max field determines the number of times the damage bonuses can be stacked.
- The Damage Bonus fields decide whether there are constant or variable bonuses. These fields also support Accumulators.
- Validator fields determine whether modifiers will work on certain attack targets. For example, you probably wouldn't want to Critical Strike to work when you are attacking your own units.
- The PreImpactEffect field will fire an effect before the impact occurs.
- The DamageInheritEffect field fires an effect after the impact occurs, inheriting the impact damage to the following effect tree. These effects allow users to create a Chain Lighting effect or deal AoE damage based on the impact damage.
- Can determine whether the attack can miss. See the Miss/Deflect/Block System section.
- The Hallucination Visual Only flag allows modders to determine whether the attack modifier will apply the Orb effect if the caster is a Hallucination unit. If the caster is a Hallucination, you probably wouldn't want them to deal AOE damage and raise dead as Skeletons. Still, some modders might want that option.
- With this flag, the attack modifier will still be applied to the attack tree, so the caster unit would still be able to fake a Critical Attack animation and throw a modified projectile missile. However, the attack won't apply a real Orb effect when it impacts.
- The MultishotEffect and MultishotSearchPattern fields allow users to launch a multishot effect to every target in the search pattern given Chance returns true and all validators are met. If the MultishotEffect field is not set, the effect will fallback to the original weapon effect of the attack.
- Can also decide if Multishot targets can also receive the impact effects.
- Can enable weapon by index, so that melee Heroes with the Orb item can use their hidden weapon to attack Air.
- When applied to an attack, the Modifier can populate the WeaponModifier actor term on the WeaponStart event, so that the actor system can play different attack animations based on the current working attack modifers.
- Have 'IsCritical' flag. When checked, could mark the attack as 'Critical', which would trigger Critical actor message, and would populate the SetText and SetTextlocalized message with the amount of the damage, so that modders can do Critical Strike floating texts.
- New Ability Type: CAbilAttackModifier
- CBehaviorAttackModifier can handle the most case of the Orb abilities, but for some abilities like Searing Arrow of the Priestess of the Moon, the Orb spell still need a shell to turn its autocast on and off.
- CBehaviorAttackModifier is a shell of CBehaviorAttackModifier, so that it can add an auto cast/manually cast shell to the orb.
- Can set the Cost to the modifier, so that every time the Orb ability is casted, it cost resources or vitals.
- Has a level property so that it can be leveled up by a hero's Learn abilities.
- New Actor type: CActorActionOverride
- Used to override the missile art, impact art, damage art of CActorAction.
- Has fields Damage Model, Impact Model, and Missile Model to set the overriding model links.
- When CActorAction is initialized, it will start the event, ActionInitModifier.
- CActorActionOverride can capture this event and create itself in the scope of the CActorAction. It can then use ActionOverrideApplyTo to apply itself to CActorActions.
- CActorAction will grab the data from CActorActionOverride and override its attack models.
Dynamic Ability Support
- Modders can now use triggers to add or remove abilities from units.
Ability Swap
- New function: UnitAbilityChangeLink()
- This function allows users to swap an existing ability on a unit to another unit while keeping its old charges, cooldown, and level states.
- Different from Catalog Replacement in that it is per-ability instance based.
- We've also added a new Ability Replace field in the Power User Type Behavior that provides a data version of this feature.
- Can only swap to abilities with the same CAbil class of the old ability. For example, a target ability can only be swapped to a target ability.
- The data version of Ability Swap will also affect the learnable abilities of Heroes.
Passing Struct Reference in Trigger GUI
- Trigger functions and actions can now define Record types as parameters.
- Record variables can now be passed to functions and actions as a parameter by reference.
- Record parameters can be read and modified. Modifications will affect the record variable outside of the function scope.
New Trigger APIs: Data Table Instance
- Works the same way as Data Tables, except that you can have multiple instances, count their values, and copy values between data tables.
- The old Data Table is a single global data table. Adding an instanced version will allow designers to better organize their run time data.
Overriding Item/Ability Tooltips on a Unit/Item Basis
- New natives: UnitSetInfoButtonTooltip, UnitClearInfoButtonTooltip
- This allows users to override tooltips on command buttons.
- The "set" trigger action expects three parameters: the unit/item being modified, the modification key, and the resulting tootip text.
- The Modification key accepts three different formats, allowing for three ways to customize command tooltips:
- Override Command Tooltips via AbilCmd.
- Key would be the AbilCmd e.g. "Stimpack,0"
- Override Command Tooltips via the button link
- Key would be the button id, e.g., Marine
- Override Item Tooltips of the unit itself
- In this case, use "@" as the key.
- Works even if the command panel is overridden to show the command panels of other units.
Skillshot Support
- StarCraft II now has skillshot support!
- New Launch Missile Effect flag field: SearchFlags
- New Launch Missile Effect Search Flag: DynamicSearchArea
- This enables skillshot search. Without it, you get a normal missile.
- New Launch Missile Effect Search Flag: ArriveOnSearchHit
- Configures whether the missile is a "denote if it hits target skillshot" or a "piercing through" skillshot. See below.
- New Launch Missile Effect fields:
- SearchHitArriveEffect
- Only work when ArriveOnSearchHit is on. This effect executes when the missile detonates by hitting a target.
- Note: This effect will be run at the final search point before the missile dies, not at the targeting point of the missile. This functionality is similar to that of a finish effect.
- SearchEffect
- The missile will run this effect every game loop, overriding the Height parameter in the search area based on the missile's current speed. Essentially, it will not leave gaps between each search.
- Note: The TVE cheat will display an incorrect default height instead of the correct height of the override search effect.
- SearchMaxCount
- Denotes the max search count during the entirety of the missile's travel time, not the max search count of each individual search. The missile will stop searching after it found SearchMaxCount targets.
- When SearchMaxCount is reached and ArriveOnSearchHit is not set, the missile will continue to travel to its destination, but will no longer execute skillshot searches.
- When SearchMaxCount is reached and ArriveOnSearchHit is set, the missile will detonate and run SearchHitArriveEffect at its last search point. Note that this is not the missile target, as it will not have reached the target point.
- If SearchMaxCount is 0 and ArriveOnSearchHit is set, the missile will not limit the max count of the search. As long as one of its search effects finds a target, the missile will detonate and run SearchHitArriveEffect at its last search point.
Improved Hero System
- New CUnit class: CUnitHero
- Five new fields (compared to CUnit):
- MainAttribute:
- A single behavior link that is auto applied/unapplied on unit creation/morph.
- No different from a normal behavior field. However, using this as a single field allows it to be easily read via a catalog function to determine a hero's main attribute.
- MainAttributeDamageBonus
- This field dictates how much attack damage bonus a hero unit receives per MainAttribute point.
- AttributePointsInfoArray:
- Sets the starting and leveling attribute points of a hero based on the current level of the Hero. This will only set Attribute Points; it won't apply the Attribute behavior if the hero does not already have one.
- LearnInfoArray:
- This uses the same structure as CAbilLearn_LearnInfo. If any of the indices sets an ability link, it will override the corresponding info of the learn ability on the hero. As a result, you will no longer need to create separate learn abilities for different heroes.
- The command button of Learn Info can also be auto generated when the "Create Default Button" flag is set.
- TierRequirements
- This field will override the tech requirement of CAbilTrain when the ability is used to train the current hero unit and there already exists more than one of the Tech Alias of the current unit for the current player.
- New CAbilityRevive flag: Override Alert Icon
- When a player revives a hero with a CAbilRevive ability with Override Alert Icon on, the ability will set the Alert Icon to the CAbilRevive's icon instead of the hero unit's icon.
- New natives added:
- TechTreeSetProduceCap
- TechTreeGetProduceCap
- These functions can be called by triggers to set a tech limit based on units, upgrades, abilities, behaviors, or effects.
- Can also be used to customize the training limit of Heroes.
- Base Attribute Points and Bonus Attribute Points
- Attribute behaviors on CHeroUnit now have two different point values: Base and Bonus.
- The starting and leveling attribute points of a hero (configured in the AttributePointsInfoArray) will count as the Base value while other point changes such as behavior bonuses will be counted in the Bonus value.
- In the unit info panel, base attribute points will be displayed as a white number while bonus attribute points will be displayed as a (+X) green number.
- The bonuses added by Base attributes points are no longer displayed as (+X) green numbers. Instead, they will be added to the base attack damage/armor/weapon speed fields.
- Attributes added by buffs or items will still be displayed as (+X) green numbers.
- New CEffectApplyBehavior flags:
- SetAttributePoints: When this flag is checked, the effect will set attribute points for the attribute behavior.
- SetAttributeBasePoints: When the flag is checked, it will modify base points instead of bonus points.
- Added new CabilTrain field: IgnoreUnitCostRequirements
- When set, the train ability will ignore unit costs as long as tech requirements are met.
- This can be used to implement special game mechanics like "Your first hero is free".
- Learn Ability Submenu Improvements
- New Learn Ability flag: ClearSubmenuOnPointsSpent
- When set, a unit using this ability will automatically exit its submenu command cards after spending all its skill points.
- New Learn Ability flag: HideSubmenuOnLearnedAll
- When set, the learn ability submenu button will be hidden after a unit using the ability has learned all the abilities it can learn.
- Fixed an issue where if all points were spent, the learn ability button would show "Required Level:" as red text even if the unit had already met the required level.
- Fixed an issue where players could sometimes use the shift key to bypass level restrictions on Learn Ability.
- Added new requirement unit count state: QueuedOrBetterOrRevivable
- When counting tech units, this will include reviving and revivable heroes.
- This is very useful when implementing hero training restrictions. For example, if you have the restriction, "You cannot train more than 3 heroes", you probably don't want to only count living heroes.
- Hero Level and XP Formula
- New CBehaviorVeterancy field: Levels
- Set the max level of a hero.
- This field is also upgradable, which allows modders to change max ability levels at runtime.
- This field defaults to 0, which will fallback the level system to how it worked before.
- New CBehaviorVeterancy fields:
- MinVeterancyXPBonusPerLevel
- MinVeterancyXPPreviousValueFactor
- MinVeterancyXPLevelFactor
- If the size of the VeterancyLevelArray is smaller than the number in the Levels field, the game will automatically generate the "min XP" of the extra levels based on these factors.
- The formula used is as follows where X is the level and F(X) is the min XP of the level:
- F(X) = F(X-1) * MinVeterancyXPPreviousValueFactor + MinVeterancyXPLevelFactor * X + MinVeterancyXPBonusPerLevel
- This is only used when the Level X is greater than the size of VeterancyLevelArray. Otherwise, it will directly grab the min XP from the VeterancyLevelArray table.
- XP Receiving Fraction based on Target Type
- New CBehaviorVeterancy field: XPReceiveFraction
- This field is a Structure Array, which allows users to specify a target filter and an accumulate-able fraction value for each array.
- Whenever a hero receives XP, the game will check the target filters on the victim unit and apply the XP fraction if the victim matches any of the filters.
- Combined with the Accumulators, users will be able to easily create XP formulas such as "summoned units grant half XP" or "Heroes gain reduced XP from creeps based on the current level of the Hero".
- Added new validator: CValidatorUnitCompareAbilSkillPoint
- Check a unit's spent skill points, unspent skill points, extra skill points, or total skill points.
Item and Inventory System Improvements
- Item systems are vital to RPGs, and we are pleased to provide a greater level of Editor support for them.
- Item Build Support
- Items in a unit's inventory can now be used to build structures.
- This item ability can be set to require the hero to maintain a channel. Alternatively, players may "warp in" buildings such as with Protoss structures.
- This type of item can be helpful to build expansions. The hero can buy a Pocket Town Hall and place it at a new expansion; the building would then automatically build itself.
- Show Inventory for Other Players
- New CInventoryPanel property: ShowForAllPlayers
- When true, players will be able select other players' units to see their inventories. However, they won't be able to use these items.
- Cast On Items in Inventory
- CCommandButton now exposes its ButtonOtherUnit property. Now users will be able to use property bind to bind the item unit (the item itself, not the carrier) to either a target frame or other frames.
- With this functionality, users will be able to cast abilities on an item inside their inventories, either to transfer or upgrade it.
- With this feature, users can also now double click on Town Portals to auto-teleport to your highest-level Town Hall.
- Globally Accessible Inventory Panel
- Users can now override the Inventory Unit property of CInventoryPanel in order to show the inventory of a unit that is not current selected.
- Users can also use triggers to create new inventory dialog controls. This supports operators like the command card dialog control introduced in Legacy of the Void.
- Users can set the unit by selecting "Use SetDialogItemUnit". Setting this to null will reset the unit to the selected leader unit.
- Show Buyer's Inventory
- Previously, StarCraft II had poor support for War3-style Neutral Item Shops. Before this patch, when users clicked on a shop unit, they wouldn't be able to see the buyer unit's inventory.
- Now neutral shops will show the buyer's inventory as long as they does not have an inventory itself and the inventory panel is not overridden to show a specific unit's inventory.
- Charge Data on CUnit
- Added charge data to unit and items so that when selling items and units, unit and item data can set their default Stock information (such as starting cooldown in shops, max stocks in shops, etc.)
- A CAbilTrain ability can be flagged to ignore these default settings and use the custom settings in the ability itself.
- If the flag is not checked and the ability has its own data, both instances of charge data will be added together.
- "Real" Power-up Items
- New Item type: CItemAbilPowerUp
- Powerup items can now be implemented as real items instead of having to mimic a unit.
- CItemAbilPowerUp is inherited from CItemAbil. The only differences are that it will be used automatically when picked up, and it can be picked up even when the unit's inventory is already full.
- CItemAbilPowerUp can only be used by units with an inventory. The unit must also have the CanUseItem flag on.
- These new powerup items are real items, so they respect inventory events and can be used in the Loot system.
- CItemAbilPowerUp will test whether the caster can use the powerup ability in CItemAbilPowerUp. If it can't, it will throw an error message, and won't make the caster move to the item.
- The KillAfterUse flag allows the item to be destroyed after the caster has used the powerup.
- A normal unit with an inventory but without the CanUseItem flag on will be able to pick up powerups and carry them to a hero.
- New EAbilInventoryFlag flag: ItemDropOnDeath
- This flag will force a unit to drop all its items on death even if it is revivable. This can be useful for normal units with the WarCraft III Backpack ability.
- New EAbilInventoryFlag flag: CanUseItem
- This flag designates whether units can use items. It aids in creating units with courier inventories, ones that can carry items but not use them.
- New EAbilInventoryFlag flag: CanApplyEquipBehavior
- This flag designates whether units can benefit from item status buffs, e.g., +5 Strength. It also aids in creating units with courier inventories.
- New CItemAbil flag: Transient
- With this flag checked, the item ability will be forced to be cast as Transient, even if the original ability on the item is not a Transient ability.
- Fixed an issue where inventories would still try to pick up items if they are destroyed on approach.
- Fixed an issue where CAbilSpawn did not work.
- Fixed an issue when pawning an item from your inventory at the max pawn distance may cause you to lose the item but not gain resources.
- New sub names to Abil actor events: PawnSource, PawnTarget.
- These will fire when you pawn an item.
- New CAbilInventory field: Requirements
- When set, the inventory ability will be disabled before its tech requirements are met.
- The inventory UI will also be hidden before the requirements are met.
- New CValidatorUnitInventory flag: RequireEnabled
- When checked, the validator will only return e_CmdOK if the targeting inventory ability is enabled and has met its tech requirements.
- For responding to Player Use Effect events, there is a new trigger API that allows users to capture the item used to create the effect, if there is an item, and its item type.
- Ability Items can now choose to use their own cooldown links, overriding the cooldown link inherited from the ability.
Neutral/Allied Shop Support
- Neutral/allied Shops are neutral/allied buildings that can be interacted with by other players with the help of CAbilInteract abilities.
- For all abilities, the Tech Player field now has an additional option: Caster.
- By setting the Tech Player field of a CAbilTrain to Caster, the ability will check the tech requirements of the player who issued the order.
- This is useful in creating a "sell unit/sell item based on the buyer's tech tree" ability.
- New CabilTrain field: AgentUnitValidator
- When set, the ability will always need an agent unit to cast and will check against the validators set in this field when training units.
- With this field, "Item Shop" abilities now can be easily created in SC2.
- For item shops, users will usually want the buyer unit of the shop to have an inventory to be able to purchase items.
- Previously, SC2 didn't have this support, so even if the buyer unit didn't have an inventory, the item would always be created.
- With the AgentUnitValidator field, users can add validators like "Unit has a valid inventory" and "Inventory is not full". Therefore, if the agent unit doesn't have an inventory, the ability would simply throw an error message and wouldn't be cast.
- New CAbilTrain flag: ChargeCasterPlayer
- Normally, neutral shop abilities require buyer and seller players to share the spending of resources with each other via the "Ally Spending" flag. If this is not the case, the buyer would get the error message, "Can't Spend On that Player".
- By default, neutral players share costs with all players. But if a user wanted to create an allied shop, a shop where allied players are able to purchase items or units, he probably wouldn't want these players to share spending. Otherwise, players would be able to spend their allies' money.
- The new flag, ChargeCasterPlayer, is designed to solve this issue. When on, the cost of the sold item or unit will be charged on the player who issued the Purchase order, even if the buyer and seller aren't share spending.
- If there are other players who share spending with the buyer player, and the buyer player doesn't have enough resources to pay the cost, the ability will still charge the cost on these other players.
- New CAbilInteract flag: AlwaysShowCommandCard
- When this flag is on, a shop unit will show its command card to all players that can interact with it (Decided by the CAbilInteract's Target Filter field), even if the player does not have a valid agent unit near the shop.
- Therefore, even if a player doesn't have an agent unit near by the shop, they will still be able to preview what the shop is selling.
- However, this player still wouldn't be able to use the command card if they don't control the shop unit, for instance, if they don't have an agent unit nearby.
- Fixed an issue where interact abilities would constantly try to acquire a unit without checking the ValidatorArray field.
Behavior Unit Tracking System
- New behavior Type: BehaviorUnitTracker
- The behavior works like a unit list. It can store all units that are added to it and has validator and max count fields. Anytime a member of the list does not match the set validator, it will be removed from a list.
- There are also flags that allow users to convert the tracker into a global list or player-based list, which does not require a behavior instance to work.
- New Accumulator: CAccumulatorTrackedUnitCount
- Allows users to use Accumulators based on how many units are in the given list.
- New effects: CEffectAddTrackedUnit CEffectClearTrackedUnits, CEffectRemoveTrackedUnit
- Allows users to add/remove units from a list.
- New effect: CEffectEnumTrackedUnits
- Allows users to loop through the unit tracking list and execute effects on each of them based on filters.
- New Validators: CValidatorCompareTrackedUnitsCount, CValidatorIsUnitTracked
- Can be used to count how many units are tracked via the behavior and check if a unit is in a given tracker list.
- The tracker system is very useful when trying to keep "one to many" mapping between units.
- For example, it can track a summoner unit to its summoned units.
Other Behavior System Changes
- Behavior Stack Alias
- This feature allows behaviors to stack based on a "stack id" instead of a behavior id.
- For example, in WC3, both the Archmage and various creeps have a version of Brilliance Aura. These are two different buffs, and when you own both these types of units, you might not want surrounding units to receive both sets of Brilliance Aura. In this case, the hero version aura should always be prioritized.
- Two new CBehaviorBuff fields: StackAlias (string) and StackAliasPriority (integer).
- If two buffs of the same StackAlias are applied to the same unit, they will share a Max Count, prioritizing the lower one. If their total count exceeds the shared max count, the game will begin removing stacks, starting with the buff with the lowest StackAliasPriority and then the shortest duration. This will occur until the total stack count matches the shared max stack count.
- New Actor Event: BehaviorStackAlias
- Allows users to capture Behavior events (On, Off, Damage Response, etc.) based on the StackAlias of the behavior instead of the behavior id.
- It also allows sharing actors between Behaviors with the same StackAliases, as you probably want all versions of the Brilliance Aura buff share the same art.
- New CEffectRemoveBehavior field: StackAlias
- This allows users to remove buffs based on StackAlias.
- New validator: CValidatorUnitBehaviorStackAlias
- This allows users to count behavior stacks by StackAlias. It will count all behaviors on the unit with the given StackAlias and has the option to count only enabled behaviors.
- Actor Damage Response Floating Text Support
- When CActorMsgBehavior fires an event with a DamageHandled sub name, using SetTextLocalized and SetText messages after the event will now automatically set text via the modified damage amount.
- The damage will replace the '%AMOUNT%' token in the target text.
- This is useful for creating damage floating text for damage responses.
- Better support for Behavior On/Off Actor Events
- Behavior On/Off events will now set effect parameters for the last applied stack or the last removed stack.
- This is useful to more finely configure behavior actors. Previously, users were not able to reference the caster of a behavior under behavior on/off events.
- New Behavior state: Cannot Die
- Marks a unit as "not able to die" unless the behavior is removed.
- Though the use of damage responses is able to achieve a similar effect, death responses can only prevent death by damage. This behavior state prevents death for any reason, e.g., life set to 0.
- This state provides a simple alternative for a trigger-based death prevention system.
- New Behavior state: Suppress Kill Credit
- Prevents a unit from granting kill credits or killed resource credits to the killing player.
- Useful for creating hallucinated units.
- New CBehaviorBuff field: DeathType
- This can override a unit's DeathType and will ignore the death type of the killing damage effect.
- The "Remove" death type may not be overridden in this way.
- Default value is "Unknown", meaning "don't override".
- New Death Type: Reincarnation
- This prevents units from dropping loot and items on death.
- The validator, CValidatorUnitCompareBehaviorCount, and the effects, CEffectRemoveBehavior, and CEffectTransferBehavior now all share the following detailed config fields:
- BehaviorCategories, BehaviorClass, BehaviorAlignment, ExcludeOriginPlayer, ExcludeCasterUnit, RequireOriginPlayer, RequireCasterUnit
- Previously, these validators/effects only had a CEffectBehavior field, and these new additional fields were exclusive to CEffectBehavior.
- These additions allow users to count, remove, and transfer behaviors with more control.
- For example, users may now remove behavior stacks that were added by a target unitcaster player, etc.
- It is also useful in the implementation of "smart dispels", such as only removing buffs applied by enemy units.
- New CValidatorUnitCompareBehaviorCount, CEffectRemoveBehavior, and CEffectTransferBehavior field: Matches All
- Determines whether the effect/validator will be executed if any of the config fields are met or if all config fields need to be met.
Better Corpse Support
- New CEffectModifyUnit_ModifyFlags flag: Remove
- This flag that will directly remove the unit from the game and will destroy the unit actor's entire scope.
- This is added because users are not able to use the "Remove" effect from CEffectDamage to remove a corpse.
- New Unit Filter: Decaying
- A Decaying unit is defined as one that is currently on the ground and has been dead for a while. This is in contrast to one that has already been killed but is still in the midst of falling to the ground and generating a corpse. In technical terms, this is true when Death Time is active, and Revive Delay is over.
- This purpose of this filter is so that abilities that target corpses will not work on units that have recently died and are still in the process of generating a corpse.
- If the unit's Death Time has been set to -1, the decay phase will be skipped. For instance, Warcraft III heroes should never decay.
- New Unit Filter: Raiseable
- CEffectModifyUnit can now set if a corpse is Unraiseable.
- Unraiseable allow us to mark whether a corpse has already been used.
- For example, while a Ghoul is eating a corpse, the corpse still exists, but the modder might not want it to be revivable or raised as Undead. In this case, the modder can set abilities to only accept Raiseable corpses and set corpses to Unraiseable while being eaten.
- New flag: Allow Corpse
- With this flag on, transport abilities will be able to carry corpses in their cargo.
Attack Type, Damage Type and Armor Type System
- New CWeapon field: Attack Type
- Modders can change the damage multipliers of each Attack Type against each Armor Type in the Game Data.
- The Attack Type will affect all damage effects in the entire weapon tree, so modders will now be able to modify damage multipliers on the Weapon level instead of going through every effect entry in the effect tree to change their damage factors.
- New CUnit field: Armor Type
- Armor Type decides the damage multipliers of weapons used against units.
- New validator: CValidatorUnitArmor
- Allow users to check a unit's Armor Type.
- New CEffectDamage field: Damage Type
- Modders can change Target Filters for Damage Type in Game Data.
- Using Target Filters on Damage Types allow users to configure all the damage and AoE damage effects in the game. It can also decide whether certain damage effects can ever damage certain targets.
- For example, by simply filtering out "Ally" targets in every Damage Type, users can easily make all weapons in the game no longer splash allies. This is useful when creating a Co-op mod as it would need to be built on top of multiple other mods, and the AoE weapon and spells in these other mods have various friendly fire effects.
Effect Miss Chance, Blocking, and Deflection
- The Behavior Damage Response structure has now been extended to handle more than just mere damage response cases.
- Miss Chance
- New CWeapon flag: NeverMiss
- By default, weapons will keep their old behavior.
- Attack Modifiers can also add the NeverMiss property to a weapon effect tree.
- If a weapon effect tree says a weapon can miss, when the weapon fires, it will check the Missing Chance on both the attacker and defender sides. It will then mark whether the effect will miss based on validators and chances set in the response structure.
- Ground units attacking targets on higher cliff levels can also have a bonus miss chance, which can be modified in Game Data.
- If a weapon's effect tree has been marked as "Missed", the weapon will not execute impact damage, nor any Orb effects on impact.
- When a weapon misses, it will send an Actor Weapon event with "Missed" as its sub name. This way, modders can decide whether they want to capture this event to create "Miss!" floating text on the unit or display a dodge effect.
- Block Chance
- New CEffect field: CanBeBlocked
- Determines whether the effect can be blocked. By default, set to off.
- When an effect is executed, the game will query the response structure on the impact unit and check its Block Chance and any validators.
- If blocked, the effect will be canceled and won't execute. The effect will then send an actor Effect event with Blocked as its sub name so that users can set appropriate actors.
- This feature is useful for creating spell blocking behaviors.
- Deflect Chance
- New CEffect flag: ValidateImpactDeflection
- Determines whether the effect can be deflected. By default, set to off.
- Deflection is almost identical to Block Chance except the effect that would have occurred will be duplicated and shot back to the caster.
- The deflected effect will have caster and target properties reversed and will count as a shot from the original target unit to the original caster unit. The damage bonus setting in the reflected effect tree will still be set to use the original caster's damage bonuses.
- Another difference between deflection and blocking is that effect trees will only evaluate deflection once each. If an effect has passed the Deflection check once, the rest of the effect tree will not check deflection chance again, even if there are following effects in the effect tree that have the ValidateImpactDeflection flag checked.
Unit Morphing System Change
- Morph/Unmorph Toggle
- New CAbilMorph flag: Toggle
- New CAbilMorph field: InforArrayUnmorph
- When Toggle is on, morph Abilities can be used to toggle back and forth between two different unit type chains.
- New CAbilMorph command index: Unmorph.
- For a togglable morph ability, after the unit has already morphed, the ability can still be issued an Unmorph command, which will cause the unit to start the morphing process defined in the InforArrayUnmorph field.
- For most cases, the InforArrayUnmorph field should be set so that its final unit type is its normal state unit type. This way, the unit will be morphed back to normal with the Unmorph command.
- New CabilMorph field: ValidatorArrayUnmorph
- Validates whether a morphed unit can use the Unmorph command.
- New CabilMorph flag: AutoUnmorph
- Determines whether the morphed unit will automatically try to morph back when possible.
- New CabilMorph fields: BehaviorOn/BehaviorOff
- When set, the ability will apply BehaviorOn buff to the unit when the unit is in its Morphed state; it will apply the BehaviorOff buff when the unit is in its Normal state. These two fields will only work if the morph ability is marked as "Toggle".
- Even if a unit is directly created as the Morphed unit type, morph abilities will still consider the unit as having gone through the morphing process. They will apply the relevant behaviors and allow it to use the Unmorph command.
- Morph Tech Count
- New CAbilMorph flag: ProvideSourceUnitTech
- When on, CAbilMorph will pass the source unit's unit type to the unit it morphed to. The final unit will automatically inherit the source unit's unit link as its Tech Alias.
- This property is inherited throughout the entire morphing chain.
- e.g. Town Hall -> Keep -> Castle
- A Castle would count as both a Keep and a Town Hall. Even a directly created Castle would count as both a Keep and a Town Hall even though it was not actually morphed from either.
- Why don't we simply add Town Hall and Keep to the Castle's alias (by adding them into the Tech Alias field of the Castle)? We use this more indirect route because ProvideSourceUnitTech only takes effect when the unit is in its Completed state. Only then would it count as the source unit in tech count. If we were to use the TechAlias field, the alias would exist in any state, even when the unit is morphing (InProgress state). In this case, when you morph a Keep to Castle, you would be in an awkward interstitial state: because you have a Completed Keep and an InProgress Castle at the same time, the tech count system would think you have an InProgress Keep, which is not the case.
- "Move to and then Morph" support
- New CAbilMorph flags: RequireAcquiredTarget, RequireAcquiredTargetUnmorph
- New CAbilMorph fields: Range, TargetSorts
- When these fields are set, a unit will search its autocast radius, try to find a target within range that matches the validator, and then move to that target. The unit will start to morph after it reaches the target unit. The Range field indicates the highest range a caster can start to morph from.
Resource Performant Units
- New unit flag: NeverThink
- Normally, every unit in the game will check pathing, enemy scanning, ability acquiring, and many other logical checks every game loop (0.0625 game seconds). This flag relieves them from those checking, which could help improve performances in custom maps.NeverThink units cannot have behaviors and abilities with the exception of Resource behaviors.
Other Generic Unit Changes
- Unit Max Speed
- New CUnit field: SpeedMaximum
- Specifies the maximum speed a unit can reach, even if it receives speed bonuses.
- New Behavior field: MoveSpeedBaseMaximumBonus
- Used to change the maximum speed of a unit.
- New CUnit mob type: Warcraft
- A unit's Mob field now has the "Wacraft" mob type selection.
- This allows triggers to differentiate between Warcraft units and StarCraft units.
- New CUnit fields: LifeRegenRateNight, EnergyRegenRateNight, ShieldRegenRateNight
- Can be used to allow Night Elf units to regenerate at night without a behavior for each unit.
- New CUnit field: BuildTime
- An extra place to store a build time on unit data, which can be used to config build times in CAbilBuild, CAbilTrain, and CAbilMorph.
- New CAbilBuild and CAbilTrain flag: IgnoreUnitBuildTime
- If unchecked, a unit's build time will be added to the ability's build time.
- New CAbilMorph array flag for each phase of each section: UseBuildTimeArray
- For each phase with this flag set, the unit's build time will be added to the respective phase's duration.
- New validator: CValidatorUnitCompareAbilStage
- Allows users to validate a CAbilEffect's ability stage.
- If the Ability field is set to None, it will validate the ability stage of whatever ability it is current casting. This means that users can now check whether a unit is channeling with the ability it is casting.
- New Target Filters:
- Powerup: True when the CUnit_PowerupEffect field value is valid.
- PowerupOrItem: A powerup or an item.
- HeroUnit: Units with a hero flag. This is different from "Heroic", which is an attribute.
- New CUnit field: Unit Level
- When set to > 0, if a unit is highlighted, its tooltip will show this level under the unit's name.
- This field can be used to target sort or validate. It can also be used in accumulators.
- Addon Parent Behavior
- New CUnit field: ParentBehaviorLink
- When an addon is linked to a parent building, the behavior from ParentBehaviorLink will be applied to the parent building. The caster of this behavior is the Addon, not the parent building.
- This allows the ParentBehaviorLink behavior to control the parent building based on the state of the addon.
- Morph abilities can validate on this behavior to throw an error message when the parent building is given a lift command while the attached addon is researching.
- CUnit_LifeDamageGain is now upgradable.
- CValidatorUnitState is greatly improved to be able to check up to 100 different unit states, up from 1.
- For example: Idle, Jumping, Highlighted, ArmorDisabled, Revivable, Dying, ArmySelect, etc.
Other Ability System Changes
- Auto Generate Buttons For Abilities
- In order to allow for abilities to be easily applied to any unit, all buttons now have a property to allow modders to set their default button position and submenu Id on the command card.
- On any ability, modders can set whether any given ability command will automatically Generate Ability Buttons such that the ability would work as soon as it is applied to a unit. No longer will users have to set these button and icons in the unit command card manually.
- Trigger API to add and remove abilities on units at run time
- New Trigger API actions: Unit Add Ability, Unit Remove Ability
- Easier Level Configuration
- Most ability types now have a Levels field that can directly set the max level of an ability. Combined with the accumulator system, modders will no longer need to implement 1000 sets of abilities for abilities that have 1000 levels.
- The Levels field is also upgradable so that modders will be able to change max ability levels at runtime.
- When the Levels field is set to 0, the default value, the ability level system will fallback to the previous functionality.
- New CCharge field TimeDelay
- Works for all ability/item/behavior charges.
- Works similarly to TimeStart, but it only affects the first charge of the ability, item, or behavior.
- When TimeDelay = 0, the charge system will work as before.
- When TimeDelay > 0, TimeStart will be ignored.
- When the ability begins to stock charges, the first charge's regen time will use the TimeDelay value, and any following charges will use the TimeUse value.
- New flag: IgnoreTimeDelay.
- This allows abilities to ignore the TimeDelay set in the unit and instead use the ability's own settings.
- Catalog Replacement now supports Item Abilities.
- The replacement is not based on the item's owner but rather the item's user.
- This allows different players use the same item with different effects.
- For example, modders will be able to create different units when an item is used based on the Race of the player.
- SEffectParamsShared now has a m_level member, which saves the level of the ability that started the effect tree.
- Effect trees can use this as a snapshot to get related level data so that even if the ability changes levels after the effect tree begins, the effect tree would still remember the old level of the ability.
- Accumulators can also use this data as ability data.
- CEffectCreateUnit_SpawnUnit can now be configured to create different unit types depending on the level of the effect tree.
- CAbilBheavior can now set different validators for Auto Toggle On and Auto Toggle Off instead of just having one validator for autocast.
- New Ability Categories and Behavior Categories
- Added various new abilities and buff categories.
- Buff behaviors can now enable/disable abilities by category.
- New field for all abilities: State Behavior
- This field creates a behavior when an ability is created. It will destroy it when the ability is destroyed, and it will disable/enable it when the ability is disabled/enabled.
Other Damage System Changes
- New CEffectDamage field: DamageInheritEffect
- The effect set in this field will be fired after the primary damage is done.
- It will inherit the damage amount of the primary damage.
- New CEffectDamage flag: NoZeroDamageInherit
- This tells DamageInheritEffect to not fire when damage done is 0.
- New CEffectDamage: Fraction
- An extra fraction that will be multiplied to all other existing fractions.
- This field supports accumulators, so modders will be able to create formulas based on this fraction.
Weapon Pre-Effect
- New weapons field: PreEffect.
- This is an effect version of PreEffectBehavior, which supports validating on target unit to decide whether the PreEffect should be executed.