Mechanics Game-specific Gen III mechanics bugs

What type of bug are you reporting? Mechanics

What is the bug?
there are two bugs that are both present in ruby and sapphire that are not implemented on sim:
  • one of these bugs is an interaction between Shed Skin and Nightmare, where, after shed skin clears sleep, nightmare still remains active; this was fixed from FireRed and LeafGreen onwards.
  • the other one, first mentioned in a gamefaqs post 15 years ago and only properly researched as recently as september of last year, is an interaction between multi-strike moves and abilities that inflict status on contact. if a multi-strike move (excluding triple kick) is used on a pokemon that has an ability that inflicts status on contact and the effect of the ability activates, there is a 1% chance that the target of the attack will also be statused after the move's final strike, even ignoring the target's immunity to a given status. if effect spore is the ability in this case and the glitch occurs, the target of the move will be statused with the same status condition that effect spore rolled during its initial activation. this was fixed in Emerald.
at this point, you may be thinking: so what? these bugs only occur in RS/FRLG and PS! simulates Emerald, why would any of this need to be implemented on the sim? unfortunately, it's not that simple, and the reason is because of the winner of the "Worst Pokemon to Program Ever" award for 20 years in a row, deoxys.

due to how deoxys' formes are implemented in generation 3, any game involving normal, attack or defense forme deoxys requires the deoxys user to be using RS, FR or LG respectively. this means that, for example, if a game is played between two players both using normal forme deoxys, the RS-exclusive glitches should occur as PS! would then be specifically simulating ruby and sapphire rather than emerald. however, currently this does not appear to be the case on sim. this video (relevant section timestampped) would suggest that matches between emerald and RS/FRLG properly use emerald mechanics and do not activate the multi-strike contact ability glitch, though with this creator only testing a sample size of ~200 double kick uses with only a ~0.33% chance the glitch even occurs on the final strike, more testing and/or decomp prodding may be required to confirm this. the interaction between RS-FRLG link battles and the shed skin nightmare glitch appears to be wholly untested.

so, given all that we know now, the properly implemented flowchart should be:
  • If Deoxys is not present on either player's team:
    • Current implementation is correct
  • If Deoxys (any forme) is present on only one player's team, or if Deoxys-Speed is on either player's team:
    • Current implementation is probably correct
  • If Deoxys-Attack or Deoxys-Defense is present on one player's team, and a non-Speed Forme Deoxys is present on the other player's team:
    • Showdown should simulate FRLG in this case; the Nightmare-Shed Skin glitch not being implemented is correct here and if the other player brought Normal Forme Deoxys it's probably still correct, multi-strike contact ability glitch is not implemented when it should be
  • If Deoxys-Normal is present on both player's teams:
    • Showdown should simulate RS in this case; both glitches are not implemented when they should be
  • If multiple formes of Deoxys are present on either player's teams (Custom Game, etc.):
    • Already not possible on cart so current implementation is correct, Showdown should just simulate Emerald in this case
and just to be clear, i am aware that these are exceptionally rare glitches that will almost never occur in a real game considering the dependency on deoxys for the sim to know what games are being played on and the unviable moves required to activate them so i do think this is a very, very low priority bugfix, but to ensure cartridge accuracy it is something that should probably be done somewhere down the line. we love oldgens!

Are you able to replicate it? If so, how?
https://replay.pokemonshowdown.com/gen3ubers-2086105851 - interaction with nightmare + shed skin. ignore how many turns it took to get this to happen, i'm unlucky >.< turn 14 is when the interaction happens

https://replay.pokemonshowdown.com/gen3ubers-2086099221- interaction with arm thrust + static. since the glitch does not occur 100% of the time my measly sample size of 32 arm thrust uses might not be accurate enough but it should be pretty easy to guess that this interaction is not programmed on sim anyways

thank you!!
 

DaWoblefet

Demonstrably so
is a Battle Simulator Administratoris a Community Leaderis a Programmeris a Community Contributoris a Top Researcheris a Top Tiering Contributoris a Social Media Contributor Alumnus
PS Admin
This is technically correct, but I imagine it would end up needing to go through Policy Review. When the thread that resulted in the do-nothing Deoxys Camouflage Clause came out, there wasn't an answer given for what we should do with game-specific mechanics when a specific Deoxys form is present on a team.

Ordinarily, player 2 is the person considered to be the host. There isn't full footage in this video, but the person started their recording showing Ruby as the game that initiated the battle. That means Emerald wasn't the host of the battle (i.e. Emerald was Player 2, so the battle was using Emerald's mechanics), so they never got to see the interaction if Ruby was host. That explains why their modded test of higher PP Fury Attack appeared as if it didn't go through. I would strongly suspect if Ruby were host, it would have these mechanics when fighting Emerald. But if that's the case, then mechanics on Showdown could be determined by host, and that sounds an awful lot like the switch priority mechanics, where the host's Pokemon switch before the opponent's, regardless of Speed, and that is modded out of Gen 3 formats. So if a Deoxys-Normal player is host on Showdown, the battle would be in RS mechanics, wholly independent of if it's fighting Emerald or not. This is all assuming, of course, that Gen 3 actually operates this way, and doesn't have something in place that actually forces Emerald's mechanics, regardless of host. So that research would need done before the policy review discussions could happen.
 
Ordinarily, player 2 is the person considered to be the host. There isn't full footage in this video, but the person started their recording showing Ruby as the game that initiated the battle.

This is all assuming, of course, that Gen 3 actually operates this way, and doesn't have something in place that actually forces Emerald's mechanics, regardless of host. So that research would need done before the policy review discussions could happen.
I believe the person who confirms the battle type at the counter/Player 1 is treated as the host according to this old Gen 3 thread about the last time host differences came up.

Also I looked into this at the time of that video (I think my comment got eaten by YouTube though) and Gen 3 games will use the mechanics of the latest version involved in the battle if there is a discrepancy, and if all latest versions involved match, then player 1/the earliest player does get control over mechanics. This can be noted from this reddit thread of someone pitting Touhoumon vs Moemon (FRLG hacks) in link battles and the games still fully syncing up based on player 1's mechanics in both cases despite both games having completely different moves, stats, and type charts.

Sources:
The FindLinkBattleMaster function in FRLG/Emerald and its RS equivalent determining which version becomes the master.
https://github.com/pret/pokeemerald...89e526ec29af30bc89b82e/src/battle_main.c#L897

1712382534770.png

(Note: It checks for player 1 having version 0x100 at the start for priority, but it seems like (English) RS sets version 0x101, FRLG has 0x201, and Emerald has 0x300. I don't know if JP Ruby does set this or if it's just a debug remnant.)

1712382894362.png

If nothing is found, then it goes through each player's version and checks for one that isn't equal. I think the comment here is wrong because if the whole loop goes through without breaking (i == numPlayers) and everyone having the same version number, then it just makes player 1/multiPlayerID 0 the master by default.

1712382982096.png
1712383058932.png

Otherwise, the games check for the first player with a version number higher than them or a game of the same version number that has a lower index and breaks if found. If a game goes through this whole loop without breaking, they become the master and basically this just gives it to the first game in order of highest version and player number.

EDIT: Thinking about it, the master flag might just be what the host is though I haven't tested it.
 
Last edited:

Users Who Are Viewing This Thread (Users: 1, Guests: 0)

Top