modder

Have anyone been using the cyber save editor to edit pokemon data on Pokemon X and Y? Does anyone know how to make the modified pokemon able to enter the battle house?

I already have flashcards including DSTWO(and that's how I dumpped the game in order to start hacking), but what I want is something looks like a real game because I am kind of a perfectism. Playing via a flashcard and playing via a cartridge might not be a difference to most of people but not me. Eitherway, it seems that this topic involves legal issue, so I decide to not ask about this any more and moderators/admins can feel free to close this thread.

Here's how move effects work: 1. The game performs a move. 2. The game checks if the move has a special handled effect. 3. If true, the game apply the special-handled effect, and try to apply the normal effect as well if possible. The normal effect will be ignored when it conflicts with the special effect. 4. If false, the game apply the normal effect. Normal effects: stored in the a/0/2/1 narc, usually being a general effect and uses some other parameters also in the narc file. ROM CHANGER only edits these effects. Special effects: The POINTER TABLE is stored in overlay093 for BW, overlay167 for BW2. Have specific code for each effect and not every move has one. The pointer table is stored in format CC CC 00 00 AA AA AA AA where C is the move code, A is the address. I haven't digged into the actual code yet as I am currently working on something else. The address seems to be somewhere in RAM (based on information bond097 posted) but I believe it's definitely possible to associate the overlay address with the RAM address somehow. If what you want to do is to make a sef-destruct effect COMBINED WITH another special-effect, you are basically making a new effect, you cannot just change the pointer table, you need to create new effect or modify the self-destruct "actual effect code" so that it does the new effect (possibly by copying the acutal effect code of the other effect at the end or make a jump to the other effect's address at the end) Actually, the easiest alternative, if you don't want to get into these massive code in overlay(as it requires at least basic programming knowledge), is to make the move power to 500 instead of 250.(EDIT:Probably the max is 255 though...then you don't have this choice then. I am not in a rom-editing environment now so I can't confirm if it's only 4 byte) However I understand the feeling of trying to make things look "perfect". You need to spend a lot of time and learn a lot of things in order to achieve that "seemingly perfectness" for even a slight change sometime.

If rom changer's effect code does not work (I guess that's the reason you are asking here) then you have to modify overlay. Take a look at this. (In addition to that, I have confirmed in White 2 Japanese version the code IS in overlay0167, but instead of pointing to XX XX 1E 02, the move effects are pointing to XX XX 1D 02 addresses) To ignore a effect, search for the move code to find the place and change the move code to something like FF FF (or just delete the entry which should work but I have never tested) To add a effect, if the move you are trying to change already has an entry, change the pointer to the effect you want, otherwise insert an entry.

Hello there, I have two questions here about the "read-only-memory" of the cartridge and I will really appreciate any help. 1. Is it possible to somehow RE-FORMAT the ROM(read-only) session of the retail cartridge (either through a software way or a hardware way with extra tool) and then inject my hacked rom in it? (I am talking about DS cartridge here) 2. Apparently I found a website stating that they allow you to choose games and they will create "bootleg" DS cartridges for you. Is there anywhere that allow you to give them a hacked rom and possibly a custom sticker image and they will make the corresponding cartridge for you?

The thing is that I am using BLACK JAPANESE version and that's why I am not sure whether the value will be the same. That's why in other version it's better to search something like "1E 02 F8 01" (end of previous block + beginning of current block which is the move code) which does not contain any address-specific information. There is another possibility: Some effect might only be part of another effect or multiple effects share the same beginning parts (which does not really do any noticeable thing). This happens pretty often in the GBA emerald version's move effect code, I cant clearly remember the exact format but I think one move can have a session 28 xx xx xx 08 which refers to the address xxxxxx, while that address can be a part of (in the middle of) another effect or an effect itself. The assembly code looks like variables based on current stack pointer is used as a parameter to call another process. Then probably it's doing something like storing the current stack information->call another procedure->use that information to go back, just not in a conventional function calling way like BL first and then STMFD/LDMFD. I am not really good at assembly things so probably I'm totally wrong though. Just my guess based on the experience of emerald move effect editing.

I guess you might have to create a custom effect for raising all stats.The "default" stat raising thing only support up to 3. The move shell smash is specially handled in overlay0093.bin However, if you just want to make it the same effect as shell smash, I have actually tested and confirmed it working on Black Version by NOTE: Do not just do what I did until you read until the end as we use different versions. 1. Do what you did, copy the data for shell smash and replace the quiver dance's. 2. Unpack the rom. (I used DSLAZY, which is equivalent to ndstool) 3. Decompress overlay0093.bin using BLZ.exe 4. Go to address 0x3D490 and change "F8 01" to "E3 01", then copy the uncompressed file to replace the original overlay009.bin 5. modify the overlay table in y9.bin, 0xBBF byte to 00 (02 should theoretically work as well I never tested) 6. Repack the rom. IMPORTANT: 1. I used BLACK version, which is different from white 2 version. HOWEVER you shuold go to overlay167 and search for "F8 01 00 00 91 75 1E 02". However it's not guaranteed the code will be there as I dont have a BW2 dumped rom with me currently. If it's not found try to search for "02 F8 01" and look for if anything looks like that format. 2. I replaced the effect call of shell smash with quiver dance to make sure it works. What you might want to do is to insert "E3 01 00 00 91 75 1E 02" after "F8 01 00 00 91 75 1E 02" so they both use that effect. 3. After you increase the size of the file, you must go to overlay table 0xBA8-0xBAA (in black version) to update the corresponding file size. NOTE that for overlay 93, how you get BA is by multiplying 93 by 2 so the entry for overlay 167 should be 0x14E0-0x14FF in the overlay table. 4. You can recompress the file but in this case you need to update the recompressed size as well (the 3 bytes before the last byte of the entry). The benefit of recompressing is that you can insert the modified files into the original rom without repacking. This will guarantee other files stay where they are and if you have other in-progress modifications which, for example you recorded some important locations, you won't lose them. 5. The thing before each "1E 02" looks like some pointer to some effects However I haven't looked into it. Possibly after some researching you may be able to find the actual code for the effects and be able to create your custom effect (such as raising all 5 stats).

Oh god this is amazing. Im definitely going to use it when it comes out. By the way is this going to be independent of an original rom? Or you will need to compile your code to some specific binarys (like arm9.bin) and combine it with some resource files from the original rom (like narc files)?

Actually that data in a/0/0/6 is for sprites or pallets (at least graphics-related) which is called spa file format apparently so it actually has nothing to do with move effects... By the way I have found the code just now where it specify the effects for the moves "thrash/outrage/petal dance" finally after almost a year of mindless searching. I can't actually even believe this myself because I just prayed for the god to help me find it and I will actually believe that Jesus exists from now on because the possibility I found it was so little. The place was overlay0093.bin after decompression.(The real miracle is that I just figured out how to get the compressing stuff work yesterday ) Im assuming the corresponding overlay in BW2 which contains the type table will contain this information as well. In the pokemon black Japanese version the code for move "petal dance" is at 0x3CF38 but if you search for "AD 21 1E 02 50" you should find where it is in the other versions. (since black and white has some slight differences apparently) The 0x50 is the move code for petal dance and I tested changing it to 0x3A (code for ice beam) and now petal dance act like a normal move while ice beam attacks 2-3 turns and the pokemon using it becomes confused. Just near this position there's a 0x25 and a 0xC8 before and after the 0x50, with a similar format 0x50 is in, which I believe should be the code for thrash(25) and outrage(C8). However I did not test it yet as my main purpose was modifying petal dance. I have very little knowledge about arm-assembler and my first guess is that in the original C code these are some switch-case statements. Good programmers might understand what the code exactly is doing by disassembly the code. Probably this information is useless for most people but at least I have seen a post in this forum that asked about outrage before (and I asked about petal dance using a different ID which I forgot password) although I couldn't found it out any more. AND there are possibly other "specially-handled" moves other than these three moves and people may refer to somewhere near this place whenever such case happens. ---------------------------------------------------- EDIT I tried changing that move code to something greater than 0x022F (the last move) and bugs are not detected after several battle testings. Also it's perfectly fine to use the original move data structure to add new effect codes to these three moves as well. (Well this works originally but to get rid of the effect of 2-3 turns consecutive attacking & confuse you must do what I described)

Hello, there. It seems that there are some really good people here and I decided to ask my question about a/0/0/6 here. Based on the information I gained from the rom info page, the a/0/0/6 should contain the move effect info and I am struggling trying to understand what the effect scripts mean. Well I am trying to pretend I am smart while I am not, in fact I am even struggling trying to know how are the effects mapped. Based on my observation, the offset-mapping-table at the beginning of the file has 732 entries in Black version. Which does not make sense to me as there are 336 effect codes (the last being the effect for cross thunder) for the moves and there are 559 moves in total. Furthermore, the Black 2 version's a/0/0/6 file seems to have two more entries than the Black version which makes me even more confused. I am going to assume the files are the "corresponding" ones on each versions based on the similarity of the entry format which starts with something like FF 7F 00 00 20 41 50 53 31 32 5F 31 which is consistent and similar to those of the GBA versions(something always start with 00 02 03 ... can't really remember) However I am having trouble understanding the thing. The main reason is that I can't map each entry to an actual effect (I have no means to know which entry correspond to which effect as the total number of entries is different from the total number of effects). I am now even curious is a/0/0/6 really the move effect files. I know this is because of my lack of knowledge but I am really stucked here. Is there anything good for me to start with?

Oh my ogd finnaly I have found the reason. My guess was totally wrong. The overlay table actually has 3 bytes before the compress-or-not flag byte that indicates the size of the overlay binary. I set that 3 bytes to the new value which is 4 bytes less than the original value and things worked.

An update here I modified the overlay table so that the program now reads into the memory without compressing, and packed directly using the uncompressed version of the modified overlay_0093.bin and the battle does not white out anymore. It is clear now that the problem is the compressing. Is it supposed to not work? Am I missing some extra options or anything? Even though things worked now I am still curious about why the compressed version does not work.

Hello everyone, I am new to DS rom hacking and I need some help on the compressing of overlay files on black/white. 1. What I have done. I have unpacked using DSLAZY and decoded the overlay_0093.bin using BLZ.exe, then modified some entries on the type effectiveness table. I never inserted or deleted anything (which means file size stays exactly the same for the uncompressed version). Then, I re-compressed the overlay_0093.bin using BLZ.exe -en option, and packed using DSLAZY again. The game whites out whenever I enter a battle, which means, very likely the effectiveness table is not loaded correctly. 2. Some guesses and testing 2.1 TEST1 I then realized the size of the re-packed nds file is not same as the original one because of some possible trimming by ndstool, which is basically called by DSLAZY.bat. I wanted to try some other packing tools but I am not able to use dsbuff on my windows 8 environment as the windows size is messed up and I am not able to see any button on the bottom portion of the window so I don't know will that one be able to generate a same sized file. However, then I tried using the original overlay_0093.bin and re-packed using DSLAZY, this time it worked fine, which leads to the conclusion that it's not likely to be packing problem. 2.2 TEST2 I also tried to manually insert the compressed file into the original .nds file (replace the section of the original file in a hex editor), but that did not work either. Based on test1 and test2, I would say it's 99% not because of packing issue and is 99% because of compressing issue. 2.3 TEST3 I decompressed the original overlay_0093.bin (lets say it's Ver0) using -d option and immediately recompressed it without any modification. The resulting binary (lets say it's Ver1) is much different from the original one. (ver0 different from ver1) However, when I tried again decompressing ver1 and immediately recompress it back, the resulting binary ver2 is exactly same as ver1. In addition, the decompressed version of ver0, ver1, ver2 are all the same. I am kind of out of idea now because it is either the decompressing of ver0 is wrong or the compressing process is wrong but I can't figure out which it is. Well since someonehad successfully modified the type table before I would say the BLZ code itself is not wrong. I can only think of two possibilities: A. I am not using the BLZ correctly B. Only partial portion of the file is compressed and I need to somehow only decompress and compress that portion. Can anyone help me with this? Especially if someone had successfully done some modifications on the type effectiveness table could help me I would really appreciate! At last, thank you for taking the time reading this long post. Sincerely, modder