Report bugs and errors in unmodified Essentials version 21

[Azeria15]

Magic Bounce is somewhat borked; it forces you into a semi-infinite loop that lasts for about 10 uses of the status moves(and it does deplete pp during this loop)before ending the turn without letting the opponent do anything. I've tested this on both a clean version of 16.1 and my own game and it occurs in both.

 

[The Master]

Hey, Maruno! Sleep Talk seems to not work properly: when the attacker uses this move, the actual round ends, and the self.statusCount is reduced immediately to zero. Clearly, this happens into a clean 16.1 version of Essentials.

 

[pauloalex4091]

I didn´t find this in known bugs or in 16.2 changelog so I believe it is a bug
After Butterfree used whirlwind on my pignite, that used flame charge before,My poliwag used flame charge....A move that it does not have.
https:// www.youtube. com/watch?v=ydPU2f-DxRg&feature=youtu.be
I didn´t change anything in Moves scripts..Only that Skydrop fix that Maruno found out
Sorry bad English

 

[Maruno]

I didn´t find this in known bugs or in 16.2 changelog so I believe it is a bug
After Butterfree used whirlwind on my pignite, that used flame charge before,My poliwag used flame charge....A move that it does not have.
https:// www.youtube. com/watch?v=ydPU2f-DxRg&feature=youtu.be
I didn´t change anything in Moves scripts..Only that Skydrop fix that Maruno found out
Sorry bad English

From the change log for v16.2:

Bug fix: Pokémon that enter battle mid-round (e.g. due to Roar, U-turn, Eject Button) will now not try to do anything in that round.

This thread is for bugs in the latest version of Essentials. This means v16.2 right now. Please only post bugs which you have verified are in the latest version of Essentials. Don't make assumptions.

 

[pauloalex4091]

From the change log for v16.2:

This thread is for bugs in the latest version of Essentials. This means v16.2 right now. Please only post bugs which you have verified are in the latest version of Essentials. Don't make assumptions.

My bad sorry developer....

 

[The Master]

Hey, Maruno. I found some typing errors in PokeBattle_MoveEffects; in particular:

Spoiler:

class PokeBattle_Move_096 < PokeBattle_Move
def pbEffectAfterHit(attacker,opponent,turneffects)
if turneffects[PBEffects::TotalDamage]>0>0

Spoiler:

class PokeBattle_Move_0A4 < PokeBattle_Move
if !opponent.pbCanReduceStatStage?(PBStats::SPATK,attacker,false,self)

Spoiler:

class PokeBattle_Move_141 < PokeBattle_Move
if !didsomething #The check of "didsomething" is useless, because that variable doesn't exists

 

[SpartaLazor]

Well, my Pokemon seem to be missing their abilities now. That wasn't like that in V16.1.

However, I did see this in the changelog for 16.2:

Added defs hasAbility?, hasNature? and hasMove? to the Pokémon class.

It may be related to this, and it might be an error on my part.

 

[pauloalex4091]

Error when using Shadowmist

I was fighting against a shadow pokemon and the game gave an error when enemy used ShadowMist
I have essentials 16.2.

 

[The Master]

Which is your error? Post a screen of the report.

 

[pauloalex4091]

Which is your error? Post a screen of the report.

My bad I forgot...

 

[The Master]

Go into "Pokemon_ShadowPokemon" script section and edit line 671 with this one:

ret=opponent.pbReduceStat(PBStats::EVASION,attacker,2,false)

It should to be ok, now.

 

[pauloalex4091]

Go into "Pokemon_ShadowPokemon" script section and edit line 671 with this one:

ret=opponent.pbReduceStat(PBStats::EVASION,attacker,2,false)

It should to be ok, now.

It worked Ty.

 

[Wrexand]

Pokémon Essentials v16.2 Pokemon stays Mega Evolved

I didn't do anything new to the game, just used one of the default Pokemon that Mega Evolves in the script and they stay changed even after the fight is over. Also the option to Mega Evolve remains when switching to another Pokemon even after Mega evolving with something else first.

 

[tustin2121]

It seems that the $game_temp.battle_abort and $game_temp.battle_main_phase variables are never used. The battle_abort flag is set, but is never read, and the battle_main_phase flag is simply completely unused. They should be removed to avoid confusion, and possibly replaced where applicable. (It looks like there's a few battle variables in there, actually. I suspect they were used in a previous iteration of the battle system?)

Searching 182 files for "battle_abort"

\!Scripts\[008] Game_Temp.rb:
   27    attr_accessor :battle_turn              # number of battle turns
   28    attr_accessor :battle_event_flags       # battle event flags: completed
   29:   attr_accessor :battle_abort             # battle flag: interrupt
   30    attr_accessor :battle_main_phase        # battle flag: main phase
   31    attr_accessor :battleback_name          # battleback file name
   ..
   76      @battle_turn = 0
   77      @battle_event_flags = {}
   78:     @battle_abort = false
   79      @battle_main_phase = false
   80      @battleback_name = ''

\!Scripts\[052] Messages.rb:
   97        if $game_system.timer_working and $game_system.timer == 0
   98          # Abort battle
   99:         $game_temp.battle_abort = true
  100        end
  101        # Update windows

\!Scripts\[053] TextEntry.rb:
 1641      if $game_actors && $data_actors && $data_actors[@parameters[0]] != nil
 1642        # Set battle abort flag
 1643:       $game_temp.battle_abort = true
 1644        ret=""
 1645        pbFadeOutIn(99999){

\!Scripts\[149] PScreen_Mart.rb:
  858  
  859    def command_302
  860:     $game_temp.battle_abort = true
  861      shop_goods = [getItem(@parameters)]
  862      # Loop

5 matches across 4 files


Searching 182 files for "attle_main_phase"

\!Scripts\[008] Game_Temp.rb:
   28    attr_accessor :battle_event_flags       # battle event flags: completed
   29    attr_accessor :battle_abort             # battle flag: interrupt
   30:   attr_accessor :battle_main_phase        # battle flag: main phase
   31    attr_accessor :battleback_name          # battleback file name
   32    attr_accessor :forcing_battler          # battler being forced into action
   ..
   77      @battle_event_flags = {}
   78      @battle_abort = false
   79:     @battle_main_phase = false
   80      @battleback_name = ''
   81      @forcing_battler = nil

2 matches in 1 file

-----

Also, in Game_System's update function, there's some code that seems to be made so that you can skip cutscenes. The way it's written, its only going to work for events that have "Cut Scene" (that exact wording) in a comment as their first command, and the way it seems to try and skip the cutscenes is by setting the event's self switch and then ending interpretation immediately. This code isn't even gated off by a $DEBUG check, so apparently its intended to be in game releases.

  def update
    #[...]
    if Input.trigger?(Input::F5) && pbCurrentEventCommentInput(1,"Cut Scene")
      event=@map_interpreter.get_character(0)
      @map_interpreter.pbSetSelfSwitch(event.id,"A",true)
      @map_interpreter.command_end
      event.start
    end
  end

Is this functionality documented anywhere? This just seems extremely fragile to me. I imagine it could leave a cutscene skipped via this method in an unfinished state, with potentially game-breaking consequences (players stuck in a cutscene area, missing key items, lacking pokemon, etc)... Surely there's a more robust way to handle it? Like jumping the interpreter to a label "Cut Scene Skipped" or something? And then the author of the game could more gracefully handle this stuff if they choose to use this functionality?

 

[Maruno]

(It looks like there's a few battle variables in there, actually. I suspect they were used in a previous iteration of the battle system?)

They'll be leftovers from the original RMXP battle system. They're not doing any harm.

Also, in Game_System's update function, there's some code that seems to be made so that you can skip cutscenes. The way it's written, its only going to work for events that have "Cut Scene" (that exact wording) in a comment as their first command, and the way it seems to try and skip the cutscenes is by setting the event's self switch and then ending interpretation immediately. This code isn't even gated off by a $DEBUG check, so apparently its intended to be in game releases.

  def update
    #[...]
    if Input.trigger?(Input::F5) && pbCurrentEventCommentInput(1,"Cut Scene")
      event=@map_interpreter.get_character(0)
      @map_interpreter.pbSetSelfSwitch(event.id,"A",true)
      @map_interpreter.command_end
      event.start
    end
  end

Is this functionality documented anywhere? This just seems extremely fragile to me. I imagine it could leave a cutscene skipped via this method in an unfinished state, with potentially game-breaking consequences (players stuck in a cutscene area, missing key items, lacking pokemon, etc)... Surely there's a more robust way to handle it? Like jumping the interpreter to a label "Cut Scene Skipped" or something? And then the author of the game could more gracefully handle this stuff if they choose to use this functionality?

I didn't know about this. Interesting.

The only game-breaking consequences is if the game creator didn't set up the event to properly accommodate it being a cutscene... but "it won't work properly if you don't do it properly" is an obvious statement. I think it's really just a matter of making your game properly in this regard, rather than it being something I have to worry about.

 

[Telemetius]

Surely there's a more robust way to handle it? Like jumping the interpreter to a label "Cut Scene Skipped" or something?

Would pbJumpToLabel or (@map_interpreter.pbJumpToLabel) be of any use in this case? I just tried skipping an event and making it jump to a new label but it is ignoring it and ending the event.

 

[tustin2121]

Personally, I'm of the mind that if the code isn't doing anything, it shouldn't be there to confuse people with the option to use it. I especially like the fact that $game_temp.battle_abort is being set in a few places, even though its an entirely unused variable. That just makes it seem like its trying to do something when it never does.

The same can be said for the fact that there is a Scene_Battle class defined for the first and only time in the Messages script section, and its defined solely to have an updatemini function defined for when a Scene_Battle gets assigned to $scene. And yet our battle system doesn't use that class, and never assigns it to $scene, so for all the work it looks like its doing, it's not ever used. It's just a bit confusing having bits of old code lying around.

Would pbJumpToLabel or (@map_interpreter.pbJumpToLabel) be of any use in this case? I just tried skipping an event and making it jump to a new label but it is ignoring it and ending the event.

I haven't actually tested the viability of my suggestion. I actually rewrote that bit a couple times as I looked at the code more. Maybe it's not possible to make robust? It just, again, seems like code that isn't used, and could cause problems if it is. And if it can be used, we should document it on the wiki somewhere.

(It's kind of amusing to me that Murano himself didn't even know it existed. :P Props to you, Murano, for maintaining a codebase you didn't create. Don't think I could do the same.)

EDIT:

The only game-breaking consequences is if the game creator didn't set up the event to properly accommodate it being a cutscene... but "it won't work properly if you don't do it properly" is an obvious statement. I think it's really just a matter of making your game properly in this regard, rather than it being something I have to worry about.

Yeah, at first I thought it was if the event was named "Cut Scene", but if the creator has to put a comment with the text in it, it's less likely to be stumbled upon accidentally.

 

[Maruno]

Well, nothing of what you two are talking about is a bug or an error, let alone one in the latest version of Essentials. There's nothing that needs fixing (or discussing in this thread).

(It's kind of amusing to me that Murano himself didn't even know it existed. :P Props to you, Murano, for maintaining a codebase you didn't create. Don't think I could do the same.)

My name is right there.

 

[tustin2121]

My name is right there.

Oops, sorry. ^_^;

 

[Snapper_Kins]

Not sure if anyone had said this, but when updated to 16.2, Pokemon will stay in their Mega forms after battle. I tested it both in my updated game and in a clean version of Essentials 16 updated to 16.2 (I had to go in an add the Mega ring and Mega stone, otherwise unmodified). Tried with multiple Pokemon in my game, they do not "unmega" after battle as they did in previous versions. It still presents the option to mega evolve in the beginning of the next battle, but if you press Z, it just continues the battle as if you didn't mega evolve (and you're already in the form, so I guess you did).