Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jfb1337

Pages: [1] 2 3
So that makes like 14 or 15 now?
Or perhaps the rule that if multiple games are used, each one has to start from a blank save file, and total A presses are counted over all games used
Yep, the bootstrap code in your party is basically
- set hl to D322
- jump to hl

So in your items code you can always assume hl is D322.
I think all english versions are identical
Generation I Glitch Discussion / Re: Save restoreation with 8F
« on: June 30, 2017, 02:20:53 pm »
In future, look at a pokemon's sprite before doing anything risky, that way if it crashes it's unlikely to corrupt the save since it would need to change SRAM banks
Come to think about it I've never had a save wipe on BGB except when I deliberately opened SRAM to try to get a save wipe, but I've had at least 3 or 4 save wipes on VC. So it's possible that SRAM isn't properly or at all.

I just checked with my offgao mem editor and A000-BFFF was all FF. But when I looked at a sprite to open bank 0, and checked again and there was data there. From A858 onwards was alternating 00 39, and before that was actual data.
Then I saved, and it was back to all FF again.
Then I manually opened SRAM by incrementing a byte ending in 9 somewhere in ROM, and there was data up until B524 after which was 0039, which was also there before A598. I tried manually opening and closing it a few times, which seemed to work as expected, though one time it seemed to take 2 attempts to actually get it to close: could be something interesting (closing SRAM sometimes fails??) or could just be that I didn't actually write something when I thought I did. Edit: Most likely explanations is just that I wrote to the wrong part of ROM. Anyway, my thumb is now tired from holding the select button so much.
I think I have a hypothesis on what could have happened, but haven't tested this: The item in question could have had a super glitch name, which causes things to be copied stuff from CD6D to CF4B. But if there were NO 0x50 bytes in this range, this would cause it to eventually start reading from where it was written to, causing the entire memory to be hosed, until it wraps around to ROM in which 0x50 byte gets found since it can't be overwritten. This corrupts both the stack and the OAM procedure, either of which can cause unpredictable code to run, which is likely to hit an rst38, possibly after happening to open SRAM, causing it to be hosed.
The fastest way to get the 8F setup would be to encounter missingno via Trainer Fly, not Old Man Trick. This can be done by losing to the 2nd trainer's machop in Saffron dojo after setting up the TFly.

What do you mean by not having the right inventory? Once you have 255 x specials, all you need are two of any tossable item to do the dry variant of Item Underflow.


Furthermore, is there any general explanation on some of the Items? Do Items like Lemonade, fresh water, the X items, Carbos and so on have a general function in EVERY code, or are they for exampe only doing certain things in different setups?
For example I see, that many glitches regarding the boxes have carbos and many codes use X-Acc or X-Speed.

Thanks for the nice guide and the huge discussion here on this forum,

The items basically correspond to certain opcodes (instructions) in Z80 assembly. You can learn about it by this guide on the site, or by plenty of other resources online too. The game stores items by an ID number followed by the number of them you have, and ACE takes odvantage of that by making the game reinterpret that list of numbers as code to be run. A list of which items items correspond to which opcdes is here.

The items you see a lot in scripts basically correspond to commonly used opcodes, for example Lemonade is "ld a, $xx" (where xx is the next number n memory, the quantity of this item stack), which sets the "a" register to whatever you want, which is very useful since that can then be written to somewhere in memory or you could do arithmetic to it or whatever. Carbos and X accuracy correspond to "ld h, $xx" and "ld l, $xx" respectively, which are used most often to determine where something should be written in memory, or sometimes where to jump to.

Non-Core Game Glitch Discussion / Re: Minor Pokemon Go Glitches
« on: May 30, 2017, 01:03:42 pm »
Another thing is that when a nest migration happens, the nest pokemon immediately changes into the new one in the overworld map, and can not be clicked on until restarting the app.

Can be seen here:
How much space is required to store the Marill sprite?
Also, I don't think CD3D would actually be possible since it gets written to when you select a pokemon, at which point there's no way to change it before the point it is read when you select one of the feild moves. I was originally thinking about super glitch corruption from the unused field move, but the game stores names of field moves separately so this one is just a properly terminated empty string.

I didn't see you "git grep "jp hl", though ? And I can't do it because lack of Linux etc.

Code: [Select]
pokered$ git grep "jp hl"
engine/menu/naming_screen.asm:  jp hl
home/text.asm:  jp hl
home/text.asm:  jp hl

Does HRAM manipulation also count as ACE? Or not because the only way to get it is by already having ACE in the first place?

Anyway, I decided to do a search for jp [hl] to find other potential ACE entry points (besides the ones that mess with the stack such as trade centre RCE, or exotic stuff like cartswap and HRAm manip, or potentially anything that messes with the ROM bank in an unexpected manor, or anything which pushes something to the stack and then rets to it, though I don't know if the game ever does this):

Code: [Select]
pokered$ git grep "jp \[hl\]"
engine/battle/animations.asm:   jp [hl] ; jump to special effect function
engine/battle/animations.asm:   jp [hl]
engine/battle/animations.asm:   jp [hl]
engine/battle/animations.asm:   jp [hl]
engine/battle/battle_transitions.asm:   jp [hl]
engine/battle/core.asm: jp [hl]
engine/battle/core.asm: jp [hl]
engine/battle/core.asm: jp [hl] ; jump to special effect handler
engine/battle/trainer_ai.asm:   jp [hl]       ; execute modification function
engine/battle/trainer_ai.asm:   jp [hl]
engine/cable_club.asm:  jp [hl]
engine/items/items.asm: jp [hl]
engine/menu/start_sub_menus.asm:        jp [hl]
engine/menu/text_box.asm:       jp [hl] ; jump to the function
engine/overworld/player_state.asm:      jp [hl]
engine/overworld/ssanne.asm:    jp [hl]
engine/palettes.asm:    jp [hl]
engine/slot_machine.asm:        jp [hl]
engine/trade.asm:       jp [hl] ; call trade func, which will return to the top of the loop
home.asm:       jp [hl]
home.asm:       jp [hl]
home.asm:       jp [hl]
home/overworld.asm:     jp [hl] ; jump to script
home/predef.asm:        jp [hl]

OK so that's 24 possibilities (for R/B at least, haven't checked Y):

- The 4 in animations.asm look like they're either non-manipulable, or fall under Glitch Move ACE (via animation pointers)

- The 1 in battle_transitions.asm is non-manipulable (only influenced by bc which is set to 0, then only set by a few functions that never set bc to something invalid)

- The 3 in core.asm are either non manipulable or fall under Glitch Move ACE (via move effects)

- The 1 in trainer_ai.asm is the ZZAZZ trainer ACE (are there other glitch trainers that trigger ACE too?)

- The 1 in cable_club.asm is seemed interesting, but it turns out that the address it reads from to determine the jump, CC38 aka wTradeCenterPointerTableIndex, is set right before every time the function that contains the jump is called, so it's unmanipulable.

- The 1 in items.asm is Glitch Item ACE, the 8F that we all know and love

- The 1 in start_submenus.asm is for out of battle moves, which seemed interesting since there is an unused field move $B4, but it would just act like surf since in its place is an extra pointer to the surf function. But maybe $cd3d AKA wFieldMoves could be manipulated somehow? Though this is very unlikely.

- The 1 in text_box.asm doesn't seem manipulable since it searches through a table that is properly terminated by $FF

- The 1 in player_state.asm looks interesting: It's determined by wSpriteStateData1 + 9, aka $C109, the player's current direction. Could that be potentially manipulated somehow?

- The 1 in ssanne.asm is ALSO based on wSpriteStateData1 + 9

- The 1 is palletes.asm is about SGB pallete commands. But it seems like every time RunPaletteCommand is called, b is set to a valid palette command already, so there doesn't seem to be room for manipulation.

- The 1 in slot_machine.asm is for a pointer to a reward function that's based on the symbol on the wheel that matched. Unfortunately that doesn't seem possible to manipulate.

- The 1 in trade.asm is non manipulable, as the pointer it uses is only ever set to a valid trade animation function which just follows a fixed sequence defined entirely in ROM.

- The 3 in home.asm are in Bankswitch, CallFunctionInTable, and CheckForHiddenObjectOrBookshelfOrCardKeyDoor.
--The latter is non manipulable since it searches for a pointer in a well-terminated array so it only loads valid hidden object pointers.
--Bankswitch is also non manipulable since it always sets hl properly before being called.
--CallFunctionInTable is only used in scripts (which would fall under the map script ACE methods) and a couple of places in home.asm, one also to do with map scripts, and the other for NPC movement scripts, which after a quick glance over where the addresses involved are used, they seem to all be only set to constant values, unless $CC57 or $CF10 could be manipulated somehow.

- The 1 in overworld.asm is the map script, which covers 3 types of map pointer ACEs.

- Finally, the one in Predef.asm is for Predef pointers. Probably not manipulable since a predef ID is always set before calling Predef.

I was surprised that TextCommandProcessor doesn't show up, but I discovered that actually uses "jp hl" instead of "jp [hl]" like I was searching for.

There are 2 other instances of "jp hl": One also in text.asm to a non manipulable function table, since it's only used when a < 0xE [even if this were manipulable, it wouldn't be very useful since it's part of the text command processor which you can already use 08 to turn into ACE anyway]. The other is in naming_screen.asm, on a non-manipulable table for button input.

Anyway, the next interesting thing to search for is TextCommandProcessor itself:

Code: [Select]
pokered$ git grep TextCommandProcessor
engine/cable_club.asm:  call TextCommandProcessor
engine/menu/pokedex.asm:        call TextCommandProcessor ; print pokedex description text
home.asm:       call TextCommandProcessor
home.asm:       jp TextCommandProcessor
home/text.asm:  call TextCommandProcessor
home/text.asm:  call TextCommandProcessor
The calls in text.asm are the handlers for TX_FAR, and Char55, which points to a fixed text in ROM.
The call in cable_club.asm is also a fixed text string.
The call in pokedex.asm is this ACE method!
The calls in home.asm are part of PrintText, which gives us something else to search for, and TrainerEndBattletext. Could we possibly manipulate the win/lose text pointers at d08c from within battle?

At this point I searched for PrintText... and there are TONS of results., too many to list here and more than I'm willing to check at the moment. They probably fall into the category of glitch text box ACE though.

But if anyone wants to add a 13th method to the list, PrintText is a good place to start.

Also, note that ACE doesn't necessarily need to point to RAM - Maybe there's something which points somewhere in ROM that's in the middle of a function that messes with the push/pop balance, causing the game to jump again to somewhere else when it hits a ret? A bit like how Coin Case ACE works.

Also, research into what unlocks SRAM would be nice, since sometimes when I hit an rst 38 I lose my save, and sometimes I don't, with no pattern I can see, so it would be nice to know what unlocks SRAM so I could take precautions.
Here is a script that should work for an arbitrary encounter level:

Repel x[Species index]  ; ld e, [species index]
Awakening x[Level]      ; ld c, [level]
X speed x64                 ; ld b, e / ld b, b
TM05 x72         
Lemonade x201           ; call 3E38 / ret

Replacing the lemonade x201 with a lemonade x4 followed by a TM01 x[any] would also work. (x4 corresponds to inc b which basically does nothing at this point). But the lemonade is important.
Pages: [1] 2 3