Merge pull request #77 from EmosewaMC/behavior

Behavior documentation

docs/game-mechanics/behaviors/and.rst

@@ -7,11 +7,16 @@ Parameters
 ----------
 
 The valid parameters all take the form :samp:`behavior X` where
-X is a number starting at 1. There are no numbers larger
-than 10 in the latest database
+X is a number starting at 1. Then execute the behaviors in this order.
+If there are more than 10, the client sorts the list by the behavior number.
+
+Example
+-------
+The :Behavior:`1698` will execute the behaviors in the order 375 (behavior 1), 1700 (behavior 2), 1699 (behavior 3)
+
 
 BitStream Serialization
 -----------------------
 
-| **[behavior in behaviors]**
-|  -> behavior
+| **[foreach behavior in behaviors]**
+|  -> behavior

docs/game-mechanics/behaviors/attack-delay.rst

@@ -1,7 +1,7 @@
 Attack Delay (18)
 =================
 When this node is reached in a behavior tree, the current traversal through this behavior branch is halted
-and will repeat (sync) after a :samp:`delay` :samp:`num_intervals` times.  The server is expected to keep track
+and will :gm:server:`SyncSkill` after a :samp:`delay` :samp:`num_intervals` times.  The server is expected to keep track
 of what behavior is waiting for a sync so the sync can be done at a later time.
 
 The server is then expected to :gm:client:`EchoStartSkill` to all connected clients.
@@ -10,6 +10,10 @@ The attack is then continued later with a :gm:server:`SyncSkill` message from th
 
 See the diagram in :doc:`../skill-system` for a diagram on how this interaction looks.
 
+For skills cast by a client, it is not advised to predict whether or not the player was actually able to cast a skill in real time.
+This is because you will get desync in what a client expects to happen vs what actually happened which will cause invisible enemies,
+mis-match health bars and further issues.  
+
 Parameters
 ----------
 

docs/game-mechanics/behaviors/basic-attack.rst

@@ -57,7 +57,7 @@ Align to the byte boundary
 | Save the offset at this position for use later (referred to here as :samp:`startOffset`)
 
 .. note::
-  | If the target blocked the attack, this value would be a 1. If the target was immune it would be a 2. If the success state branches are reached, then this value also represents the
+  | If the target blocked the attack, :samp:`allocatedSize` would be a 1. If the target was immune it would be a 2. If the success state branches are reached, then this value also represents the
   | sum of all the sub behaviors!  
 
 | **[bit]** - True if the attack was blocked, false otherwise.

docs/game-mechanics/behaviors/block.rst

@@ -1,7 +1,8 @@
 Block (53)
 ==========
 
-Details unknown
+Blocks :samp:`num_attacks_can_block` attacks and casts the :samp:`break_action`
+when you have reached the limit of attacks you can block.
 
 Parameters
 ----------
@@ -13,19 +14,18 @@ Parameters
    * - Name
      - Description
    * - block_damage
-     - ???
+     - True to block basic attack behaviors
    * - block_knockback
-     - ???
+     - True to block knockback behaviors
    * - block_knockbacks
-     - ???
+     - True to block knockback behaviors
    * - block_stuns
-     - ???
+     - True to block stun behaviors
    * - break_action
-     - ???
+     - The behavior to cast when the damage blocked is greater than the amount of damage this behavior allowed you to block
    * - num_attacks_can_block
-     - ???
+     - The number of attacks that can be blocked
 
 BitStream Serialization
 -----------------------
-
-.. todo:: investigate
+| No serialization

docs/game-mechanics/behaviors/car-boost.rst

@@ -1,7 +1,8 @@
 Car Boost (19)
 ==============
 
-Boost a car?    
+Boost a player in a car for :samp:`time`.
+If the player does not have any boosts active, you will cast :samp:`action` otherwise you will cast :samp:`action_failed`
 
 Parameters
 ----------
@@ -13,16 +14,21 @@ Parameters
    * - Name
      - Description
    * - action
-     - Action to execute on success
+     - Action to execute on being able to add the boost.
    * - action_failed
-     - Action to execute when boost failed
+     - Action to execute when the boost could not be activated.
    * - active
-     - ???
+     - Unused in 1.10.64.
    * - time
-     - ???
+     - The amount of time to add the boost for.
+
+
+.. note::
+	The effect played when you succeed in boosting is hard coded in the client. If the :samp:`time` is greater than 3.5, 
+	:samp:`boostCam1` is played, otherwise if the :samp:`time` is greater than 2.0, :samp:`boostCam2` will play,
+	otherwise :samp:`boostCam3` will play.
 
 
 BitStream Serialization
 -----------------------
-
-.. todo:: investigate
+**[bit]** - 1 if able to add active boost, 0 otherwise.

docs/game-mechanics/behaviors/chain.rst

@@ -7,18 +7,26 @@ Parameters
 ----------
 
 .. list-table::
-   :widths: 15 30
+   :widths: 15 30 15
    :header-rows: 1
 
    * - Name
      - Description
+     - Default value
    * - behavior X
-     - Behavior to execute as a chain step, 0 < X
+     - Behavior to execute as a chain step, should be sequential starting from 1 and increasing by 1 for each behavior.
+     - No default
    * - chain_delay
-     - ???
+     - The delay to apply between each attack of the chain.
+     - 0.5 if field is not present.
 
 BitStream Serialization
 -----------------------
 
-| **[u32]** - chain index, basically attack combo in attacks, 1-based
-| -> relevant action
+| **[u32]** - The smallest behavior such that behavior n satisfies the following criteria
+|			- :samp:`chain_delay * n < delay_since_first_behavior_called`
+| -> :samp:`behavior X`
+
+.. note:: 
+	- Like with attack_delay, this delay should not be simulated on a server due to latency adding onto the delay.
+

docs/game-mechanics/behaviors/change-idle-flags.rst

@@ -1,7 +1,8 @@
 Change Idle Flags (36)
 ======================
 
-Details unknown
+Changes the idle flags of the caster by turning the requested flags off/on.
+No serialization.
 
 Parameters
 ----------
@@ -13,11 +14,14 @@ Parameters
    * - Name
      - Description
    * - flags_on
-     - ???
+     - The idle flag to turn on
    * - flags_off
-     - ???
+     - The idle flag to turn off
 
-BitStream Serialization
------------------------
-
-.. todo:: investigate
+.. note::
+	The values in the flags are *not* literal numbers but rather bit indexes.
+	This means the values in the flags *must* be between the values 0 and 32 inclusive.
+	Anything outside of this range is undefined behavior.
+	To add onto this, the behavior is as follows
+	- If flag is zero, use 0.
+	- Otherwise get a value that is :samp:`(1 << (flag - 1))` and set/unset that bit