Battle message for status effect nullification

[QZProductions]

I posted this on RPGMaker.net's forums and never got a satisfactory answer so hopefully y'all can help me out here orz

Is there any way to make the ActionFailure vocab (or even a custom phrase) appear when a status effect gets nullified by, say, a piece of equipment the actor is wearing? Right now it doesn't display any message at all when the effect is nullified and it just looks weird. Not a game breaking bug or anything but I'd like to at least have the game acknowledge it worked LOL.

Thanks!

 

[Roninator2]

Sound like something I saw once before. Something to do with yanfly battle script I think.
What scripts are you using?

 

[Harosata]

Hm, this is going to require some fiddling with Window_BattleLog and Game_ActionResults, which is an object linked to Game_Battler. I'm not home to fiddle with RPG Maker, but here's the general idea of what to do:

1. In Game_Battler, item_effect_add_state_normal deals with states added via skills and item_effect_add_state_attack should deal with states applied to attacks. Both will add the state if successful, so we add an else-statement where we will push the data into a nullified_state object.

1a. If you take a look at add_state, one of the things it does is push the state into the added state object. The battle log uses this object to show states that are added.

1b. The else statement is going to trigger for any missed states. If you want to narrow down the number of nullified states versus missed states getting stored, you'll have to narrow it down. For example, state_resist?(state_id) is based on the State Resistance feature.

2. We'll need to put the nullified_states in the Action Results. Based on the added_state and removed_state stuff in there, we'll also need to initialize/clear this and create a method to display the array.

3. We create a method in the Battle Log for our nullified_states. the display_removed_states should be the one to copy as we probably don't need to worry about identifying either the death state or an empty message.

3a. The display_changed_states show the added and removed states. This would be the ideal method to put our nullified states.

---

Draft and/or tested script may come from me later.

 

[QZProductions]

Sound like something I saw once before. Something to do with yanfly battle script I think.
What scripts are you using?

I actually got that suggestion and looked at the script but it didn't really have anything to do with what I wanted. I also don't want to change from the default battle engine because I'm already messing around with it a bunch and don't want to make it more complicated than it needs to be lol.

Hm, this is going to require some fiddling with Window_BattleLog and Game_ActionResults, which is an object linked to Game_Battler. I'm not home to fiddle with RPG Maker, but here's the general idea of what to do:

1. In Game_Battler, item_effect_add_state_normal deals with states added via skills and item_effect_add_state_attack should deal with states applied to attacks. Both will add the state if successful, so we add an else-statement where we will push the data into a nullified_state object.

1a. If you take a look at add_state, one of the things it does is push the state into the added state object. The battle log uses this object to show states that are added.

1b. The else statement is going to trigger for any missed states. If you want to narrow down the number of nullified states versus missed states getting stored, you'll have to narrow it down. For example, state_resist?(state_id) is based on the State Resistance feature.

2. We'll need to put the nullified_states in the Action Results. Based on the added_state and removed_state stuff in there, we'll also need to initialize/clear this and create a method to display the array.

3. We create a method in the Battle Log for our nullified_states. the display_removed_states should be the one to copy as we probably don't need to worry about identifying either the death state or an empty message.

3a. The display_changed_states show the added and removed states. This would be the ideal method to put our nullified states.

---

Draft and/or tested script may come from me later.

Oh!! That makes sense, I figured it was something of that sort but my scripting knowledge is pretty limited. If you can help me figure this out I'll make sure you get in the credits :3c Thank you!!

 

[Kes]

[move]RGSS3 Script Requests[/move]

 

[Harosata]

#------------------------------------------------
#Dramatic Lightning Presents:
#Nullified State Log 0.9
#Display a message for states that get nullified.
#------------------------------------------------
# In theory, the Battle Log will show a message for any
# states that get Resisted.  This hasn't been tested yet,
# so manual customization at this point.

#We create an array similar to the added_states and removed_states.

class Game_ActionResult

  attr_accessor :nullified_states

  alias :dl_nullstate_clear_status_effects :clear_status_effects
  def clear_status_effects
    dl_nullstate_clear_status_effects
    @nullified_states = []
  end

  def nullified_state_objects
    @nullified_states.collect {|id| $data_states[id] }
  end
end

#Turns out that state_addable? already checks for state_resist?, so we change this so that resisted states are pushed into our results array.

class Game_Battler < Game_BattlerBase
  def add_state(state_id)
    if state_addable?(state_id)
      add_new_state(state_id) unless state?(state_id)
      reset_state_counts(state_id)
      @result.added_states.push(state_id).uniq!
    elsif state_resist?(state_id)
      @result.nullified_states.push(state_id).uniq!
    end
  end
end

#With how similar the add/remove states are processed, we create a similar method.

class Window_BattleLog < Window_Selectable

  alias :dl_nullstate_display_changed_states :display_changed_states
  def display_changed_states(target)
    dl_nullstate_display_changed_states(target)
    display_nullified_states(target)
  end

  def display_nullified_states(target)
    target.result.nullified_state_objects.each do |state|
      state_msg = "The effect was nullified!"
      replace_text(state_msg)
      wait
    end
  end
end

Not tested yet, but if you apply a state to something that has the appropriate State_Resist, the battle log should show "The effect was nullified!".

So it turns out that add_state already has a method/condition that checks if the state can be resisted, and with how the add_state_normal and add_state_attack things work, states that can be resisted will be "added" when successful but not actually added on. I changed the add_state so that if the state can be resisted (rather than simply missed), the data would be pushed into that array.

 

[QZProductions]

Eep! Sorry it wound up in the wrong board, I wasn't sure if it'd require a script or not :V;;

Thanks, I'll test this out in a bit and let you know if it works!!

 

[QZProductions]

#------------------------------------------------
#Dramatic Lightning Presents:
#Nullified State Log 0.9
#Display a message for states that get nullified.
#------------------------------------------------
# In theory, the Battle Log will show a message for any
# states that get Resisted.  This hasn't been tested yet,
# so manual customization at this point.

#We create an array similar to the added_states and removed_states.

class Game_ActionResult

  attr_accessor :nullified_states

  alias :dl_nullstate_clear_status_effects :clear_status_effects
  def clear_status_effects
    dl_nullstate_clear_status_effects
    @nullified_states = []
  end

  def nullified_state_objects
    @nullified_states.collect {|id| $data_states[id] }
  end
end

#Turns out that state_addable? already checks for state_resist?, so we change this so that resisted states are pushed into our results array.

class Game_Battler < Game_BattlerBase
  def add_state(state_id)
    if state_addable?(state_id)
      add_new_state(state_id) unless state?(state_id)
      reset_state_counts(state_id)
      @result.added_states.push(state_id).uniq!
    elsif state_resist?(state_id)
      @result.nullified_states.push(state_id).uniq!
    end
  end
end

#With how similar the add/remove states are processed, we create a similar method.

class Window_BattleLog < Window_Selectable

  alias :dl_nullstate_display_changed_states :display_changed_states
  def display_changed_states(target)
    dl_nullstate_display_changed_states(target)
    display_nullified_states(target)
  end

  def display_nullified_states(target)
    target.result.nullified_state_objects.each do |state|
      state_msg = "The effect was nullified!"
      replace_text(state_msg)
      wait
    end
  end
end

Not tested yet, but if you apply a state to something that has the appropriate State_Resist, the battle log should show "The effect was nullified!".

So it turns out that add_state already has a method/condition that checks if the state can be resisted, and with how the add_state_normal and add_state_attack things work, states that can be resisted will be "added" when successful but not actually added on. I changed the add_state so that if the state can be resisted (rather than simply missed), the data would be pushed into that array.

So I tested this out using the typical method of pasting the script into "materials", equipped my character with the status effect-nullifier accessory in question, and made a battle test with some status-inflicting enemies and it still says nothing when the character is attacked with a status-affecting skill.

Here's the database page for the accessory in question and its state resist properties if it helps:



I also know some scripts have to be placed before or after other scripts in order to work so I'll also try moving it around.

 

[Harosata]

Hm, well, Version 0.9 assumed that the timing of the added states was simple. Apparently, that is not the case, so Version 1.0 is here and tested, ready to show a message when the state is nulled:

#------------------------------------------------
#Dramatic Lightning Presents:
#Nullified State Log 1.0
#Display a message for states that get nullified.
#------------------------------------------------

class Game_ActionResult
  attr_accessor :nullified_states

  alias :dl_nullstate_clear_status_effects :clear_status_effects
  def clear_status_effects
    dl_nullstate_clear_status_effects
    @nullified_states = []
  end

  def nullified_state_objects
    @nullified_states.collect {|id| $data_states[id] }
  end
 
end

class Game_Battler < Game_BattlerBase
  def add_state(state_id)
    if state_addable?(state_id)
      add_new_state(state_id) unless state?(state_id)
      reset_state_counts(state_id)
      @result.added_states.push(state_id).uniq!
    elsif state_resist?(state_id)
      @result.added_states.push(state_id).uniq!
      @result.nullified_states.push(state_id).uniq!
    end
  end
end

class Window_BattleLog < Window_Selectable

  def display_added_states(target)
    target.result.added_state_objects.each do |state|
      state_msg = target.actor? ? state.message1 : state.message2
      state_msg = " is immune to the state!" if target.result.nullified_state_objects.include? state
      target.perform_collapse_effect if state.id == target.death_state_id
      next if state_msg.empty?
      replace_text(target.name + state_msg)
      wait
      wait_for_effect
    end
  end
end

So what I did here instead is that if the state is "added" but is not added, it then checks if it's due to being State-Resisted, and if so, it will force that state into both the added and nullified arrays. The reason for two arrays is for timing, which results in two waves of poison going as inflict-null-inflict-inflict/inflict-null-inflict-inflict rather than inflict-inflict-inflict/inflict-inflict-inflict/null/null

 

[QZProductions]

Hm, well, Version 0.9 assumed that the timing of the added states was simple. Apparently, that is not the case, so Version 1.0 is here and tested, ready to show a message when the state is nulled:

#------------------------------------------------
#Dramatic Lightning Presents:
#Nullified State Log 1.0
#Display a message for states that get nullified.
#------------------------------------------------

class Game_ActionResult
  attr_accessor :nullified_states

  alias :dl_nullstate_clear_status_effects :clear_status_effects
  def clear_status_effects
    dl_nullstate_clear_status_effects
    @nullified_states = []
  end

  def nullified_state_objects
    @nullified_states.collect {|id| $data_states[id] }
  end
 
end

class Game_Battler < Game_BattlerBase
  def add_state(state_id)
    if state_addable?(state_id)
      add_new_state(state_id) unless state?(state_id)
      reset_state_counts(state_id)
      @result.added_states.push(state_id).uniq!
    elsif state_resist?(state_id)
      @result.added_states.push(state_id).uniq!
      @result.nullified_states.push(state_id).uniq!
    end
  end
end

class Window_BattleLog < Window_Selectable

  def display_added_states(target)
    target.result.added_state_objects.each do |state|
      state_msg = target.actor? ? state.message1 : state.message2
      state_msg = " is immune to the state!" if target.result.nullified_state_objects.include? state
      target.perform_collapse_effect if state.id == target.death_state_id
      next if state_msg.empty?
      replace_text(target.name + state_msg)
      wait
      wait_for_effect
    end
  end
end

So what I did here instead is that if the state is "added" but is not added, it then checks if it's due to being State-Resisted, and if so, it will force that state into both the added and nullified arrays. The reason for two arrays is for timing, which results in two waves of poison going as inflict-null-inflict-inflict/inflict-null-inflict-inflict rather than inflict-inflict-inflict/inflict-inflict-inflict/null/null

Just now tested it and it works great! Thanks so much!!

Would you like to be credited for the script as "Dramatic Lightning" or as something else?

 

[Harosata]

Just my username is fine.