Anonymous user
ItemDex/RB:085: Difference between revisions
Update info
(Update info) |
|||
| (5 intermediate revisions by one other user not shown) | |||
Line 4:
|2=55
|3=085
|4=00:a7d0 (SRAM)
|5=No
|6=Yes
|7=0
|8=0
|9=$81, $f7, $85, $50}}
[[File:B1F glitch item name.png|link=]] (hex:55) is a [[glitch item]] in {{RB}}. Its name is taken from lists of lift destinations.
Line 20 ⟶ 21:
==Application with SRAM ('Hall of Fame') corruptions==
As demonstrated by TheZZAZZGlitch, with a series of SRAM corruptions (empirically, these may be seen as Hall of Fame corruptions), it is possible to manipulate the data within the program counter area of B1F (beginning at SRAM:A7D0). If the corruptions are due to sprite decompressions from [[glitch Pokémon]] (as viewed from the Pokémon summary in the party; as this opens SRAM specifically in the un-banked area), the outcomes are [[
As the process is complex, viewing certain glitch Pokémon sprites without further knowledge can be viewed as an elaborate pseudo-random number generator for an outcome of bytes in the SRAM, if the initial SRAM is interpreted as a 'seed' (pseudo-random as given the sprite pointer of a glitch Pokémon is not from RAM or SRAM itself, the input SRAM would in theory always produce the same output SRAM).
Line 49 ⟶ 50:
Other examples of the usefulness of calculated/planned sequential SRAM corruptions from viewing summary glitch Pokémon sprites are:
*As a means of precisely manipulating
*The contents of [[TrainerDex/RB:052|Trainer (0x34)]]'s roster 1 (0xFC from 0xD059 and 0x01 from 0xD05D, hence the required Special stat is 252, and the required Attack stat modifier is -6. Specifically however, it is just the representation of $CD2D and $CD2E effectively) depends on the contents of pointer 0xA5A5 in SRAM. This is within the region that can be changed through glitch Pokémon sprite corruptions such as LM4. If the player is able to corrupt the sprite pointer region of a glitch Pokémon for those sourced in SRAM like [[GlitchDex/RB:244|ゥ₽ (F4)]] and its front sprite pointer of SRAM:A922, grinding (or calculating the series of corruptions) for an interesting front sprite is an option as well (see also: [[arbitrary sprites]]).
*As a means of manipulating SRAM arbitrary code executions other than 10F (and not strictly limited to glitch items); there are other arbitrary code execution exploits which can attempt to execute SRAM.
Line 118 ⟶ 119:
*"The file data is destroyed!" message does not appear. (An example of an issue may be a bad save checksum).
*That it's possible in the first place to achieve the desired result while meeting the criteria above through calculation or a tool/SRAM corruption emulator.
As a general concept, the subject may also have implications for the logistics of programming a tool (such as a SRAM corruption emulator). If the tool is given support for algorithmic or mathematical models or a metaheuristic (e.g. [[wikipedia:Simulated annealing|simulated annealing]]) it may be possible to follow/visualise simulations and calculate desired outcomes to the SRAM from a 'seed' as well.
{{clr}}
| |||