- 1 Behaviors
- 2 Example Usage
- 3 Behavior: Sub Types (Classes)
- 4 Common Fields
Behaviors[edit | edit source]
Description[edit | edit source]
Behaviours are Data Types which are applied to individual units. They manipulate aspects like damage and movement.
Hints[edit | edit source]
- You can add Behaviours to units with triggers, using the "Add Behaviour" action.
- Behaviours are stackable.
- Behaviours target individual units, while Upgrades target all units of a special type. Upgrades are permanent while a Behaviour has a timer.
- Behaviours are visible in game as tiny icons to the left of the unit icon. This is an optional feature of a Behaviour.
Example Usage[edit | edit source]
Adding a Behavior with triggers[edit | edit source]
You need to have a unit to apply a behaviour to, either as a variable or a unit on the map. Use the action "Add Behaviour" with the following parameters:
- Count: the number of times you would like to stack the behaviour. A unit can have at most 64 Behaviours in total. Also, most Behaviours have a default limit of stacking set to 1. You can edit this number to your liking.
- Behaviour: the behaviour you whish to apply.
- Caster: the caster unit. You can set this to the target unit. The reason of having this parameter is that some behaviours might kill the target, which makes it important to know who was the caster.
- Unit: the target unit. It can be the same as the caster unit.
Active and passive cloak[edit | edit source]
Ghost's cloak applies a behavior using an ability which the player must activate, while the Mothership's cloak is passive (already implented on the unit).
Referencing a Text Key[edit | edit source]
A behavior can be referenced by text keys Ex. a behavior named "Power" could referenced as such: "Behavior/Name/Power" and will generate a text containing the name.
Behavior: Sub Types (Classes)[edit | edit source]
- Attack Modifier
- Click Response
- Creep Source
- Power Source
- Power User
- Unit Tracker
Common Fields[edit | edit source]
(None) - Face[edit | edit source]
Seems to be used for an icon, but this is not seen on UI.
(None) - Sort Index[edit | edit source]
Behavior - Alignement[edit | edit source]
Changes the icon's color
- Negative: the Icon is tinted in red
- Neutral: the Icon remains unchanged
- Positive: the Icon is tinted in green
This is also used to organize behaviors, as buff or debuff in the case of using a Remove Behavior effect, which could take off all the "Negative" behaviors for instance.
Behavior - Behavior Flags[edit | edit source]
- Permanent: This field indicates that this behavior is to be always present in the game (as long it's not removed or disabled). Convenient for being verified by triggers and validators, even beyond unit's death. Used by Sentry - Hallucination behavior to validate the unit at death in order to launch/prevent certain death animations/sounds. A behavior expiring from a duration does not remain.
- Ignore in Editor: (to be completed)
- Enabled While Dead: The behavior remains enabled upon unit's death. This field logically requires the Permanent value to be activated (to be confirmed).
- Disabled: Disables the behavior without the necessity of a requirement/validator to do it. Triggers or other behaviors enabling it should be able to unlock it.
Behavior: Categories[edit | edit source]
These are Filters, used in a similar was to Unit Attributes. Used by Behavior: Modification - Behavior Categories Disabled/Enabled.
Very handy for Remove Behavior effects. Exemple: A Medic restoration spell could have a single effect (instead of specifying each behavior) that removes every "Restorable" categories.
Behavior - Requirements[edit | edit source]
The Requirements that need to be met to enable the behavior
- This is a lot used by actors when using events such as "Behavior" On / Enable / Off /Disable
- A requirement can enable or disable the behavior at any moment like a On/Off switch.
- For a buff behavior, is comparable to the Validator (Disable) field.
Cost - Cost[edit | edit source]
Determines the cost when using the behavior. A behavior is considered used in many different cases. Ex: When applied/enabled
The subfields in this section is like any other cost fields.
Stats: Flags[edit | edit source]
- Always Use Game Text: If the behavior should be Hidden From Default UI, allows the Unit Name Override modfication value to show (otherwise, any name change never displays when the behavior is hidden from UI). This feature can be found on Buff Behaviors.
- Hidden From Default UI: determines if the buff icon is hidden or visible in the UI. Each behavior sub type comes with a different default setting for this case.
Stats - Tech Alias[edit | edit source]
Alias name that can be used by Requirements to to refer this behavior and many others with the same Alias at once (this avoid specifying each behavior in the requirement).
UI - Icon[edit | edit source]
If the flag Hidden From Default UI is disabled, this icon will show up on the unit's UI when the behavior is on/enabled. A unit can still carry a behavior that is disabled, but so will be the icon.