• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

[Error] Why does my Forecast Buff cause crashes?

429
Posts
4
Years
  • Castform is awful so I decided to buff him by making his Forecast ability check his held item, setting one of his three weather types if he's holding the appropriate Weather-Extending Rock.

    Code:
    BattleHandlers::AbilityOnSwitchIn.add(:FORECAST,
      proc { |ability,battler,battle|
        next if item == :DRYROCK
        pbBattleWeatherAbility(:Sun, battler, battle)
            next if item == :DAMPROCK
        pbBattleWeatherAbility(:Rain, battler, battle)
            next if item == :ICYROCK
        pbBattleWeatherAbility(:Hail, battler, battle)
      }
    )

    However, this code causes a crash on startup. What's wrong with it?

    When I run the game it says "Unexpected end of input, expected end".
    If I add a "end" it says there are too many ends. If I swap the ) with a "end" it says it expected a ")" instead of a "end".

    Anyway this code is supposed to activate (like Drought) every type the pokemon with FORECAST is sent out, even if it's not Castform. However, Castform with FORECAST still has the usual "Switch forms depending on weather" code already in the game.

    I also buffed Castform to have 120 HP and 100 in every other stat.
    His weather forms have the ability FORECAST too, but their hidden ability is Adaptability.
    Basic Castform's ability and hidden ability are both FORECAST.
    So you get to decide whether you want your Castform to swap Forecast for Adaptability upon becoming a Weather Form, or keep the existing Forecast ability and swap types whenever the weather changes
    I thought to myself... What if Castform checked for existing weather conditions, then swapped forms to that, only setting the weather type of his held stone if there is no weather? That could let trainers send out a weather-setter, swap to Castform, utilize him and Weather Ball in the current form, then when the weather runs out after its usual number of turns, his held rock would activate and change the weather to match his held rock for an extended duration. However, this would make Castform a poor thing to send out against enemy weather-setters, as he would be unable to ruin an enemy weather team's day by changing the weather to benefit him. Making him suck at the primary job of a weather-setter didn't seem worth any potential shenanigans one could have if their team utilized this theoretical gimmick to revolve around setting different weather types depending on the situation. Weather teams are designed to set a weather type and stick with it, after all.
     
    Last edited:
    429
    Posts
    4
    Years
  • Update: What if Castform could learn any offensive TM and, upon selecting a Fire or Water or Ice attack, set the matching weather type before using the move(transforming in the process)? It could tie into the theoretical "Multiple weather setter" playstyle, a niche no other Pokemon could pull off quite like this one.
     
    1,407
    Posts
    10
    Years
    • Seen today
    A few things are wrong here, before you even get to your "end" problem. First of all, the item is called Heat Rock, not Dry Rock (unless you changed that). Secondly, you never define what "item" is here, so you're checking if something non-existing is "true", which will probably cause an error even if you got passed your current error. Thirdly, you're using "next" here, which would do the opposite of what you want, even if the rest of the code was functional. "Next" in this context means "skip all the code below this line if the following is true". So basically, if Castform is holding the appropriate rock, the code will actually SKIP initiating any weather. So you've got it set up backwards.

    Funnily enough, the one issue you DONT seem to have is your syntax with the brackets, so I'm not sure why you're getting an "end" error. Perhaps it has to do with completely unrelated code above it. Anyway, here's how I would set this ability up if I were making it myself:

    Code:
    BattleHandlers::AbilityOnSwitchIn.add(:FORECAST,
      proc { |ability,battler,battle|
        item = battler.item
        next if ![:HEATROCK, :DAMPROCK, :ICYROCK].include?(item)
        weather = (item==:HEATROCK) ? :Sun : (item==:DAMPROCK) ? :Rain : :Hail
        pbBattleWeatherAbility(weather, battler, battle, true)
      }
    )

    Untested obviously, but this seems like a more optimized version of what you're trying to pull off.
     
    429
    Posts
    4
    Years
  • Update: I fixed Forecast.

    Code:
    BattleHandlers::AbilityOnSwitchIn.add(:FORECAST,
      proc { |ability,battler,battle|
        item = battler.item
        pbBattleWeatherAbility(:Rain, battler, battle) if item == :DAMPROCK
        pbBattleWeatherAbility(:Hail, battler, battle) if item == :ICYROCK
        pbBattleWeatherAbility(:Sun, battler, battle) if item == :HEATROCK
      }
    )

    Anyone who wants to use this code is welcome to do so, it only takes one copypaste (and giving Castform at least 100 in every stat) and suddenly Castform goes from an awful garbage pokemon so trashy that three dumpster fires laugh at it every day to a decently good Pokemon with a unique edge over any other weather-setter as he can also benefit greatly from being sent out when weather is already present.
     
    Back
    Top