Creating "Switch states" No script

● ARCHIVED · READ-ONLY
Started by CWells 3 posts View original ↗
  1. This tutorial is for creating states that will allow users more control over the duration of special skills.

    With what I call a "switch state", players can decide for themselves when a certain effect should be turned off or on in combat.

    These particular skills require 1 common event and 1 dummy state. And of course, they require the actual state. At the end I will explain the purpose of the dummy state and why it is necessary to prevent mass activation.

    First, you would create a skill normally. In the skill features window, you will add both the dummy state which functions as the switch, and the common event. Be sure to add the dummy state first. Right under the dummy state, you add the normal common event for that skill.

    Here is how the skill should look:

    Spoiler
    The dummy state should be left blank. But be sure to turn on the end removal time to 1 turn. So the duration should be 1-1 for when this gets removed. I didn't do that in this pic. However, there is an exception when a character needs to cast a state that affects the entire party, but that one character must function as the controller of the state. See the last paragraph for more info.:

    Spoiler
    How the common event will put everything to use:

    Spoiler

    So if you have compaction and want control, you will need CompactionSwitch. Notice the inner section of the common event. It is checking to see whether the character has the real state on or off. If off, it adds the state. If not off, it removes the state.

    Why use a dummy state?

    Because this method relies on conditional branches and one common event per skill to avoid clogging up your

    list with multiple copies of skills and states, you need the dummy state to act as a switch that will help the event figure out who activated what. If you ignore this and create a common event with If Actor is in party, and you have multiple people who can use the same skill, regardless who activates the skill, everyone will end up being placed under that particular state. This might be fine for states that are meant to affect a group. But this can be a disaster for single target spells. Especially if these switch states come with a certain negative side effect such as draining mp per turn or drain HP per turn.

    You need the dummy states to act as an identifier in your common event. As far as I know now, this is the safest way to handle that without scripts.

    Oh, about the first pic, you wont need multiple skills for the same spell. Everything is checked through the state and common event. So ignore that I have two skills of the same name for each character.

    The exception to the switch state lasting only one turn:

    If you have a character that casts a skill like "Mages wall" which is a protective barrier meant to affect the whole party, but want the controller of the spell to have extra effects tied to the casting, you should add the extra effects inside of the switch state so that the actual state does not have these extra effects. This will allow you to isolate who gets the negative effects of certain spells.

    So using the pics above, you should have the switch like this for a group spell:

    MagesWallSWITCH

    Removal: none

    Features: -3% MRG per turn.

    In the common event, where the actual state gets removed, simply add an extra line where you remove the switch state

    from the controller of the spell when that controller turns the spell off.
  2. Added some extra (and hopefully clearer) info regarding group spells dependent on a single controller. Sorry about the leave out.
  3. So how does the user turn on or off a state while in battle? Can you give a screenshot?


    Plus - I don't see the dummy state listed in your screenies. Compaction and SwitchCompaction are the pair that are essentially the skill and the ability to control the skill, right? Or is SwitchCompaction the Dummy? You kind of use the term in your explanation but I never quite connect to where it goes in your implementation.


    BTW ,You say Skill Features Window (3rd Paragraph) but I think you mean the Skill effects window.


    thanks for this.