Bond697

from now on, anything posted in here that's not a direct contribution of some kind gets deleted and infracted. i'm really getting sick of "how i edit packet?"

xxxx1e02 is a code pointer. it's pointing to the subroutine @ 21Exxxx. in your case, at the subroutine @ 21E7590. the +1 is because it's a thumb routine. also: 0xA7 (167) Main battle overlay- holds the vital battle-related code, loads the other 3 0xA8 (168) gfx-related battle overlay 0xA9 (169) VRAM overlay- global effects, etc 0xAA (170) Trainer AI handler e: are you sure that that's the right pointer value? that pointer is in the middle of a function: http://i.imgur.com/Y0adfYT.png

i'm not sure yet. what will probably happen is that i'll write some kind of special overlay loader/hack that will handle the initial loading/hijack. i have the binaries that are built from user-created code stripped and ready to insert. i'll probably create an overlay info table editor that will let you insert the overlays at the end of the list. then you can load them when you need them. what will basically happen is, i'll have the user define a variable at a certain address and if that address is non-zero, my loader will assume there's a hack present to be loaded, etc. i'm still working it out, but that's the basics.

you can see the pokemon in both of those just from a glance. looks like a lot of the same stuff as when trading. different order, though.

they don't, no.

exactly

people who "interpret" this are really dumb.

http://projectpokemon.org/wiki/Pokemon_X/Y_3DS_Structure added party data to the end.

party pkx files are 272 bytes. e: encrypted the same way, etc etc.

gen 6 pokes would likely have zero-ed conntest stats. we wouldn't be able to tell where they are if they moved.

i'm not going to comment on how it was done or on doing experiments with stuff that might attract (even more) attention from nintendo, but obviously we're not just stopping now that we've gotten this far. we're going to keep checking stuff out and trying to figure out whatever in-game stuff we can given the ability to do what we can do now.

from now on, anything posted in here that's not a direct contribution of some kind gets deleted and infracted. Last night Xfr and I did some work on updating Pokécheck for gen 6. Along the way, we managed to dump and decrypt some of the new pokémon files and decide on the file type for the format. What's new: Box pkxs are now 232 bytes, as opposed to 136 previously. Pkxs store the current owner + the original OT for a given pokemon. The encryption on the pkx files works slightly differently. Hatched eggs save the moves they hatched with separately for the move relearner. This is the current PP Wiki page: http://projectpokemon.org/wiki/Pokemon_X/Y_3DS_Structure Here are some sample .pkx files dumped from my and Xfr's games: http://tmp.pokecheck.org/pkx.zip http://tmp.pokecheck.org/snorlax.pkx http://tmp.pokecheck.org/eevee.pkx And here's the solution for a small program I wrote last night that can decrypt the files: http://hack.thundaga.com/xycrypt.7z The gible named "Wireshark" on the pp.org front page is an edited gen 6 pkx. e: party pkx files are 260 bytes.

i guess i could help out if there's reverse engineering to be done to the game.

pretty sure all that was dumped was garbage. on the off chance it's not though, can you post your save? it should be at least 1mb.

since we're commenting, pokebuilder's "working on it" means that they're waiting for pokecheck or someone else to figure it out so they can rip it from whoever actually does the work.

one thing i've wanted to do and never bothered with is to document the user input system. so let's get started: 0x21418C4 - g_pUserInput(global pointer to 0x21FF960) 0x21FF960 - user input heap/struct - first 2 members are 0x21FF9D0 and 0x21FFA48 0x21FF9D0 - user keypress input(sizeof = 0x44) 0x21FFA48 - user touchpad input(sizeof = 0x78) keypress input: 0x0-0x38 - a variety of keypress recordings that capture that actual keys pressed, not the inverted presses that the hardware captures(i.e. if you press A+B, it will reflect that as 0x3 instead of 0x3FC)- about half are for previous keys pressed and to catch keypress combos and keys being held. 0x3C - frame counter that counts down from either 0x8 -> 0x0 or 0xF -> 0x0 depending on whether keys have changed between video frames or not 0x40 - const, never changes - copied into 0x3C at the end of the countdown when keys don't change between vframes. 0x44 - const, never changes - copied into 0x3C when keys change between vframes. so what will happen is: -player presses A from nothing- keycount will reset to 0xF and so long as the player continues to press only A, it will count down to 0x0, reset to 0x8 and continue counting from 8 to 0. -player either lets go of A or presses another button at the same time - keycount will reset to 0xF and start to count down again. this will go back up to 8 and count down if the combo is held for all 0xF frames. then inside the block from 0x8 - 0x38, about 4 of the entries capture the currently pressed keys, another 4 or so capture the keys from the last frame, a few more capture the delta between frames, and a couple capture the combined keys between frames(pressed or not) looking for key combos. touchpad input: really simple actually, even though the heap is bigger for touchpad input. 2 u16s @ 0x5C are the coordinates of the last touch press u16 @ 0x62 indicates that the touchpad is being pressed(goes with the above, isn't constantly updating) 2 u16s @ 0x64 + u16 @ 0x6A, same as the above for a different purpose 2 u16s @ 0x6C + u16 @ 0x72, constantly updating between 0 and the last pressed position- this is where the rest update from. i'll make changes as i go through and figure out exactly what each of the keypress members and touch press members do. user input heap: a heap with a struct allocated inside of it. 0x3B(0x21FF99B) - backlight switch(this won't change anything on an emulator) 0x3D(0x21FF99D) - keypress type - this switches between 0x1E and 0x3C(30 and 60) and tells the game which keypress type to use because each keypress fetch function can choose between 2 different keypress struct members(the values between 0x8 and 0x38 above). i thought it changed every other frame at first, but it seems to only happen for certain reasons. it basically tells each fetch function to choose between the previous keypress and the current frame's keypress.(or the keypress delta, etc)

how, exactly?

random note: a/0/1/3 is an array of 0x199 10-byte-member struct elements. this array links to a/0/6/0, which is a set of 200 780-byte files. they have something to do with vectors, but what exactly i'm not sure.

at the very least you could make a nice sandwich.

one (or both, probably both) of the code snippets at the top branch to the E-code's copied asm code at the bottom. you need to change the branch lengths at the top to jump relatively to 2002180. snippet 1 5218065C FAC2F6C4 5218165C 07C0981B 0218165C FD98F680 D2000000 00000000 snippet 2 52180B48 D1092801 52181B48 07C0981B 02181B48 FB1AF680 D2000000 00000000 E-code asm E2002180 00000030 F03BB50E 2170FEF5 D00A2808 E006981F F03BB50E 219AFEED D0022808 07C0981F 2027BD0E 306A0200 18529A03 BD0E9203 D0000000 00000000

all you'd have to do is rng with the ar in every time and it would work fine.

i figured out what the 13th bit does. it indicates that diglett/dugtrio use a special animation for popping out of their pokeball. all other pokes jump out of their pokeball when the trainer throws the ball out, but diglett/dugtrio rise out of the ground when the ball is thrown out. if you set it for other pokes, they will rise up out of the ground when their ball is thrown out.

i just threw together a quick program to find which personal files have that 13th bit set out of all 709 files. the only 2 out of everything are diglett and dugtrio. why that could possibly be, i have no god damn idea. source: http://pastebin.com/VD4P3u9n

i put the source for 1.0 back up. it had a problem that needed to be fixed.

no.