Battle System: Remaining, not implemented stuff #821
Comments
is allready handled in master and |
|
The following will be fixed by #905 "Items: Effect: Preemptive Advantage during battle "Ignores agility and attacks at the beginning of the turn." "Items: Half MP Cost " The MP cost required for skills will be halved." |
|
|
|
Not sure if this one has been taken into account in the current list, I'll try to explain in detail. REVIEW: The item not decrease the value of defense, but the different types of defense (sword, fire, water, wind, etc.)
|
if I remember correctly, this affects Pom gets WI-FI, in |
|
"Skills: States. The 2nd non-default option (Heal instead of Inflict) is not handled." breaks the skill Zwiestrich in Wolfenhain. |
|
Not worth opening an extra issue: "Change Battle Commands" |
|
#1373 The number after each issue refers to each commit inside this PR "Items: Effect: Attack twice at the same time " Each normal attack hits the enemy twice."" " Items: Effect: Ignore enemy dodge rate "Attack accuracy ignores the enemy's agility."" " Items: Prevent Critical Hits "Enemy characters will not critically hit the wearer"." "States: Accuracy modifier" |
Ghabry
added
the
Needs feedback
|
@fmatthew5876 The current status should be the following (or pending a merge): Implemented:
Not sure:
Missing?:
|
|
These are in master, please check them off.
This is implemented for weapons. Need to check for armor that inflicts states.
The rest need to be checked further and/or implemented. |
|
Regarding "Items: The 2nd option (heal instead of inflict) for states".. I recommend splitting this into 2 tasks: weapons and armor. As I mentioned, weapons are done. Armor state inflict is more complicated. There are a lot of questions:
Since its a 2k3 feature, I'd expect at least 1 or 2 of these to have bugs in |
This is already in master
In #1562 |
This is fully implemented in 0.6 |
|
okay so if I didnt mess this up this keeps us with.
I will move the enemy flipping in a different issue. Because this one will fall much later and is only visual |
Ghabry
removed
the
Needs feedback
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states.. We keep a record of what we did, then do it again in Apply(). Finally, we replay this record once more to print the messages. This also implements the skill state healing feature from EasyRPG#821
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states.. We keep a record of what we did, then do it again in Apply(). Finally, we replay this record once more to print the messages. This also implements the skill state healing feature from EasyRPG#821 This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states.. We keep a record of what we did, then do it again in Apply(). Finally, we replay this record once more to print the messages. This also implements the skill state healing feature from EasyRPG#821 This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states.. We keep a record of what we did, then do it again in Apply(). Finally, we replay this record once more to print the messages. This also implements the skill state healing feature from EasyRPG#821 This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states.. We keep a record of what we did, then do it again in Apply(). Finally, we replay this record once more to print the messages. This also implements the skill state healing feature from EasyRPG#821 This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
|
With #1726 this is finally done |
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
States are infliced and healed in the order they happen. In order to faithfully replicate this, in Execute() we make a copy of our target and then try to add and remove the states. We keep a record of what we did, then do it again for real in Apply(). Finally, we replay this record once more to print the messages in 2k battle. * Implements the skill reverse_state_effect chunk from EasyRPG#821 * Implements physical skills healing states like normal attacks. This solution is really bad, but so far there appears to be nothing better without a major refactor of how we process battle aglorithms.
This is a meta bug to track the remaining battle stuff that is not implemented.
When fixing bugs please reference #821 in your pull request :)
[x] System2: Flip assets if facing the other direction "Not documented in the help file m("Moved to Battle 2k3: Flip assets if facing the other direction option #1564The text was updated successfully, but these errors were encountered: