Bond697

your save is 100% completely empty. yet again another problem that has nothing to do with pokegen.

you can adjust the volume of the main snd player @ 2149384 - 0x7F is max volume and 00 is min volume. if you want to adjust the sub-players, it's 0x2149384 + (i * 36) where i is the player number. there are 16 total possible players, but gen 5 uses 4. so use 0-3.

C#

i just tried doing this. it works perfectly. e: yeah, there's no way i'm registering ".pkm" as a pokegen file automatically.

extract pokegen's entire archive to a folder on your desktop then try to use it and see if you still have trouble.

you can't insert gifs. the moving pokemon in bw/bw2 use a very complex set of sewn together pieces and animations.

stop loading save states and things will start working.

using crystaltile2, if you extract and decompress the arm9.bin file from the rom and then go to 0x13F0C in the arm9, you'll see these 2 numbers: "08 28" change the 08 up to FF to increase the shiny rate. once you're done, do NOT re-compress the arm9. simply insert it back into the rom.

you're using english black 1?

it's not a narc. it's entirely code changes.

what do you want to make the chance? the very most you could easily increase the chance would be 32x better or 256/65536. after that it gets difficult.

why do you care about this in any way? what consent did the creator get from gamefreak to make the hack in the first place? (hint: none) anyone who makes any kind of rom hack and tries to control it in any way really couldn't be more of a hypocrite.

at 0x209DA98 in white 2 is a very important set of data. it's 24 bytes, 6 members: typedef void (*VBlankIntrFn)(void*); struct SystemVframe { VBlankIntrFn* callback; void* heap_1; u32 unused; u32 vram_transfer; void* vbl_intr_fn_arg; void* gfl_std_use; }; Address Offset Use 0x209DA98 0x209DA98 0x0 vblank callback function- changes based on what player is doing 0x209DA9C 0x4 ptr to first object in memory(objects being heaps) 0x209DAA0 0x8 unused- set to 0 while initializing 0x209DAA4 0xC u32 counter- successful vram transfers 0x209DAA8 0x10 vblank callback argument 0x209DAAC 0x14 ptr to gfl_use system blocks it's basically the vblank manager. one very interesting thing to note: all ds and gba games handle graphics the same way- they draw to the screen while the screen is empty(i.e. during vblank) to avoid casuing tearing, artifacting, etc on the screen while the game is running. the system and sdk graphics systems are obviously designed around this, etc. gamefreak does handle their graphics during vblank, but not in the conventional way. when the system boots, they enable the vblank interrupt callback in the interrupt table: ARM9:02005124 ; void __fastcall TwlMain() ARM9:02005124 TwlMain ARM9:02005124 F8 B5 PUSH {R3-R7,LR} ARM9:02005126 00 F0 1D F9 BL SystemInit ARM9:0200512A 00 F0 C5 F9 BL setupSystem ARM9:0200512E 25 49 LDR R1, =(_HBlankIntr+1) ; function ARM9:02005130 02 20 MOVS R0, #2 ; intrBit ARM9:02005132 74 F0 0B FE BL OS_SetIrqFunction ARM9:02005136 24 49 LDR R1, =(VBlankIntr+1) ; function ARM9:02005138 01 20 MOVS R0, #1 ; intrBit ARM9:0200513A 01 24 MOVS R4, #1 ARM9:0200513C 74 F0 06 FE BL OS_SetIrqFunction ARM9:02005140 03 20 MOVS R0, #3 ; intr ARM9:02005142 74 F0 AB FE BL OS_EnableIrqMask (note VBlankIntr) it looks something like this in normal code: void TwlMain() { SystemInit(); setupSystem(); OS_SetIrqFunction(OS_IE_H_BLANK, HBlankIntr); OS_SetIrqFunction(OS_IE_V_BLANK, VBlankIntr); OS_EnableIrqMask(HBlankIntr | VBlankIntr); anyway, what's weird is that they do the vblank thing and they do do graphics-related stuff in the vblank callback, but the only time the callback does anything of note is when you enter a building. a function runs that does a bunch of floating point math and a few other things. the actual graphics are updated during vblank, but outside of the vblank callback. the code (called updateGfx) runs as soon as the vblank callback finishes, which is fine. there's nothing wrong with doing it the way they do, it's just different.

Anybody play this? It's so incredibly good. I really can't say enough good things about it. I finished the main campaign last week and am on "The Knife of Dunwall" now. Can't wait for the last DLC come August. It reminds me a lot of Bioshock- it has that same extreme level of atmosphere and the size and sumptuousness of the world. The same sort of world building, but in a different way. Just really, really cool. And tons and tons of cool powers. And you don't have to kill anybody. You can play completely non-violently if that's your thing. Assassinating people with the powers is SO much fun, though. http://www.dishonored.com/ Just watch the trailers:

the last few obstacles to this are finally gone. i was worried about getting devkitpro to produce binaries with nothing but the user-created code instead of a full nds binary, but a custom makefile and linker file solved that. my other concern was that the symbol file used with the makefile was causing all generated branches to be done in ARM, but all of b2w2 are in THUMB. i found a (thankfully simple) way to change that that i didn't think would work, but fortunately does. the only other even minor issue was using asserts. you can't use assert or sassert and there's no console, stdin, or stderr, so outputting text to the screen would be difficult to say the least unless i added it to the rom and did a whole lot of unnecessary work. so i found a compromise: when you throw an assert (using special asserts i'll provide), the screen will turn that black and blue and ask you to reset like when there's a normal in-game error and you'll be able to go to 0x23DFB00 to view the text from the assert sitting in memory in ASCII. it works surprisingly well. e: the asserts will look like this: http://i.imgur.com/ZDWHsdu.png

i posted this awhile ago somewhere else, but i found it again in some code i was working on tonight and figured i might as well throw it up here. typedef u32 OvlID; typedef void (*OvlStartupFunc) (void); typedef void (*OvlEndFunc) (void); struct OvlTblInfo { OvlID id; u8 *ram_address; u32 ram_size; u32 bss_size; OvlStartupFunc *constructor; OvlEndFunc *destructor; u32 file_id; u32 sz_compressed:24; u32 ovl_flags:8; }; struct OvlWork { int ovl_num; bool is_loaded; }; struct OvlInfo { OvlTblInfo head; Proc cpu_target; RomRegion file_pos; } OvlTblInfo is the overlay table data entry in y9 and y7.bin, though there are never any arm7 overlays, so y7.bin is always empty. the constructor and destructor don't necessarily have to run. only if you need to initialize and end things when loading/unloading the overlay. sizeof(OvlTblInfo) is 32. e: i wrote a quick program to dump the relevant info from overlay tables and provided a folder of all the necessary overlay info tables as text files here: http://projectpokemon.org/forums/showthread.php?29665-I-m-Done

the SaveBlockInit table for the small block with the pwt, vsplayer, musical narc, etc is @ 0x208EED4.

the reason the game loads immediately when you pick your save, but takes awhile to save when you're done, is that the savegame is read as a contiguous 0x26000 byte file into memory and written in blocks back to the save- 1 block at a time, 74 blocks total. e: other general save info: when the game boots, a function runs that pulls from the save data info table @ 0x208F18C. the table is 73 entries and each is a struct like so: typedef void (*SaveFn)(void); struct SaveBlockInit { int blkID; SaveFn blkSize; SaveFn callback; }; basically, one function goes through and builds the table @ 0x220528C using the blkSize function pointers and some simple math. a second function iterates through all 73, running the callbacks one after the other to prepare the blocks for play. the 74th block is checksums. this is actually really good news because it means that extending the size of a save block is as easy as changing that block size value to something bigger and then writing to the rest of the space. the only issue is that the pieces of unused block in each save block aren't very big. the reason that the padding exists in the first place is that each block is padded to the nearest 0x100 bytes. they have a bit of math to account for this when building the save data block table. e: an example: 18E00 19333 19336 Party Pokemon the party pkm block runs from 18E00 to 19337, but the padding extends to 193FF. that means that 19338-193FF is padded with FFs and unused. so if you change the block size in the config table, you can have read/write access to 0xC8(200d) bytes for managing your own save data. and you wouldn't have to do anything but read and write to it in memory because after adjusting the table, gamefreak's code would do all the management. to find the right block in the table to change, you do this: block_num * 0xC + 0x208F18C + 0x4 then you go to that address and follow the pointer at that address. somewhere very close by that address, you'll see 00000534 in ram/in the arm9. add up to 0xC8 more bytes to that and you have your own private save data.

0x8011 is the variable that holds the map npc number for the speaking npc - this is usually 0224742A

at the end of the scripted event for the pokemon, there will be a script command that sets a flag. remove that command and the pokemon should keep showing up.

it doesn't matter, this is not a bug.

i bet it wants a party pokemon not a box pokemon.

updated once more: -added a directory of text files with info on all the overlays in all the gen 4 and 5 games. -added the full source/solution of ovl_info, the textfile dumper used above

this was updated with some new info: spreadsheet - script environment, scrcmd, scrcmd global, adventure data block idb - new script commands, the entire block 37 reader, a bunch of random functions, a bunch of dsi stuff, a few overlay binaries added scrcmd.txt - added lookup for callstd library, added lookup for registered script plugins, added script commands batch files - decompress.bat is updated to decompress many files at a time http://projectpokemon.org/forums/showthread.php?29456-B2W2-Scripting-Thread&p=166095&viewfull=1#post166095 http://projectpokemon.org/forums/showthread.php?29456-B2W2-Scripting-Thread&p=166116&viewfull=1#post166116

this has not a damn thing to do with pokegen. and, gen 4 pokemon that have an origin of a gen 4 game keep their ability. clearly you need to fix something. what evandixon said.