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
Since -g m jumps to da47, the current number of safari balls, it could sometimes break in the safari zone. Lucky's setup is more prone to this since useful code begins at da48 (wDaycareInUse) so some opcodes will interfere with that. Azarokkusu's setup begins useful code a bit later with the rest being safe filler, so it's a little more robust and in fact all legitimate values of safari balls (i.e. <= 30 (decimal)) don't interfere with it jumping to the 3rd bag item; even jr only ends up having an operand of 0 or 1.

However a few values should be taken note of: If you have 2 or 18 safari balls, SRAM will be opened since these opcodes are ld (bc), a and ld (de), a respectively, and bc and de both happen to point to the 0x00??, and a happens to by 0x6A, making rst 38 crashes more deadly, and if you have 8 safari balls you'll end up writing 2 junk bytes (the stack pointer) to the start of VRAM - possibly causing a slight graphical glitch but nothing major.

Also if your item setup depends on registers other than HL (which are rare), just don't use it in the safari zone at all; most ball amounts will break something.
What happens if I transfer a pokemon with numbers in its nickname?
I made a simple checksum system to verify that large amounts of data have been entered correctly on hardware:

I'm currently using (a version of) it to enter MrCheeze's virus, but it could be used to verify other things such as offago's memory editor:
Code: [Select]
Awakening x??   ; length of bytes you want to verify
X accuracy x??   ; low byte of address to verify from
Calcium x ??      ; high byte
Lemonade x1     
Poke ball x174   
HP Up x13         
Fire stone x251
X accuracy x33   
Calcium x217   
Poke ball x119   
Calcium x45     
Poke ball x126   
TM38 x40         
Poke ball x119   
TM01 x any       
Code: [Select]
ld c, ??
ld l, ??
ld h, ??
ld a, 1
inc b
xor a,(hl)
inc hl
dec c
jr nz, .loop
ld l, $21
ld h, $D9 ; hl now points to 1st item quantity
inc b
ld (hl), a
ld l, $2D ; hl now points to .loop (7th item quantity)
inc b
ld a,(hl)
xor a,$28 ; change xor a,(hl) into add a,(hl) and vice-versa
inc b
ld (hl),a
This runs in 2 modes, "add mode" and "xor mode", changing between them on each run, to make it more foolproof, as it would catch errors that may "cancel each other out" under one mode alone. The result of the checksum is written to the quantity of the first item, which can be compared against what you see in an emulator running the same code.

This has NOT been tested. However, following code, which it is based on, has been. This is designed to run through the offago memory editor, from DA00 (where it starts be default). The only differences between the two versions are different addresses, and filler code inserted to avoid glitch items.
Code: [Select]
ld c,??
ld hl, ????
ld a, 1
xor (hl)
inc hl
dec c
jp z .loop
ld hl, $D9FF ; or wherever we want to put the output
ld (hl), a
ld hl, .loop ; DA07
ld a, (hl)
xor $28; change add a,(hl) to xor a,(hl) and vice-versa
ld (hl), a
jp $DA80; where the memory editor is stored

; compiled: 0E002100C83E00AE230D20FB21FFD9772107DA7EEE2877C380DA

Non english versions have a different memory layout, so the codes need to be adjusted a bit, and so does the setup of which pokemon need to be in the box too I think
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?
Pages: [1] 2 3