cr001

I remember messing around with HackingToolkit9ds which did not work as well. Eventually I used DotNet3DSToolkit to build as CIA and worked, probably you should try that too.

I have done a scripted search in Battle.cro to see if there is any relative address referring to the starting of the special handled move ID list, but found nothing (Obviously the absolute address reference search failed too). Did also do some manual inspection of nearby byte structures but nothing seems interesting (i.e. like a 343-item pointer table). Pretty much stuck at this point. One thing I still believe in is that the actual handling code of the special moves is still in Battle.cro, not some other file like exefs code.bin. The reason I believe this way is that the move ID list is in the code section of the cro file and not the data section. Here's my Python script for searching relative address, if anyone is interested in taking my idea and making some improvements: -------------------------------------------- with open("battle.cro", mode="rb") as file: byte = file.read(1) count = -2 previous = [] while byte != b"": if len(previous) >= 2: addr = bytearray(b'') addr.extend(bytearray(previous[len(previous) - 2])) addr.extend(bytearray(previous[len(previous) - 1])) addr.extend(bytearray(byte)) # 0x105df0 == 1072624d, the starting addr of special handled moves for Ultra Moon addr_rel = 1072624 - count; if (addr_rel >= 0): addr.extend(bytearray(b'\x00')) else: addr.extend(bytearray(b'\xff')) addr_int = int.from_bytes(addr, 'little', signed=True) if (abs(addr_int - addr_rel) < 8): print(str(hex(count)) + ", Addr: " + str(addr) + ", RelAddrDiff: " + str(abs(addr_int - addr_rel))) previous.append(byte) if len(previous) > 2: previous.pop(0) byte = file.read(1) count += 1 -------------------------------------------- I am going to stop messing around with this at this point as I have actually spent a lot of time trying to solve the "Pinpointing Special Move Handlers Code" problem several years ago without success. Maybe someone else with better hacking knowledge can figure it out, I would be very grateful too (To be honest, I am even willing to pay 100 dollars (via Paypal) to whoever figure this out), as well as other questioners preseumably.

I have confirmed in Ultra Moon that the move is a hard-coded special handled move that forces a move to be super effective against water type, by the following steps: 1. Open Battle.cro in hex editor, and search for the following pattern: "36 02 00 00 00 00 00 00 31 02" 2. There should be a "3D 02" (Move Id for Freeze-Dry) that comes next, change it to "28 02" (Move Id for Fiery Dance) 3. Save the file and rebuild the rom. 4. Visually confirm that the move "Fiery Dance" is super-effective against Water Type in the game. The special handled move list begins with "A0 00 00 00 00 00 00 00 25 01 00 00 00 00 00 00 72 00 00 00 00 00 00 00 8A 00 ...." in Ultra Moon (Notice the list might be different in other versions) and the "3D 02" is the 279th entry. If we can find out where the script location is for the first move "A0 00" (Conversion), then we might use offset calculation to find out where the script for Freeze-Dry is. Also the list seems to consist of 343 entries so if anyone found anything that looks like an array of code that consists of 343-ish number of entries, please share the result so we can continue the research together.

I suspect that it is a hard-coded special handling. It should be the same file (battle.cro) as the type chart if the move id is in the special handled move list. That is, you might be able to get other moves to be super effective against water but that’s probably the best you can do without disassembling the code or the scripting language. This could be very hard as one has to first pin down the script location for the special handling and then understand what each byte is doing as a script. I used to figure it out in emerald but that’s almost a miracle and very luck-dependent. I wasn’t able to figure anything out on later versions beyond the special-handled move Id list layer.

I was able to modify rental Pokemon during run-time using Cheat Engine and Citra with following steps: 1. Attach Cheat Engine to Citra. 2. Go to a Exchange Center and look at the Current 3 pokemons, record the first pokemon Index from battle tree pokemon ID list one can be found here (https://pokemongohub.net/post/pokemon-sun-and-moon/sun-moon-battle-tree-pokemon/). The left-most column is the ID. Search for a 2-byte value using Cheat Engine with that ID. For example if a Lilligant with moves "Charm-Sleep Powder-Petal Dance-Healing Wish" shows up, you would search for the value "255". 3. Shuffle once with the Exchange Center, then look at the new 3 pokemons, record the first pokemon index, and search for it again using Cheat Engine with the new ID. This should pin down an address with the pokemon ID. 4. Shuffle again with the same Exchange Center or another Exchange Center. However stop right before the owner asks you Yes or No to confirm the shuffle and go to Cheat Engine. 5. Open the address in step 3 using Memory Viewer of the Cheat Engine. Right click on the value and add a "Data Breakpoint - Break on Write" on that address. 6. Go back to Citra and continue to confirm Yes. Let the game run until the Breakpoint is hit in Cheat Engine. Visually confirm that there is an assembly line "mov eax,[r15+14]" very closely above the line that is hit by the breakpoint. 7. Go to the address [r15+14] where r15 is the value of the R15 register in the register list on the right side of the Memory Viewer. Add 14 to that value, which is the address we want, and enter "ctrl + g" to go to that address. 8. Modify the value of that address to the battle tree ID you want, in little endian hex representation (for example 255-Lilligant would become FF 00 and 256-Darmanitan would become 00 01) 9. Remove the breakpoint (Menu - View - Breakpointlist, right click, delete breakpoint), and resume the game by clicking on the Run button in Cheat Engine. The first pokemon of the shuffle result would become the pokemon you want. You must immediately choose that pokemon when the owner asks you after the shuffle; the pokemon would become the "original intended pokemon" the next time you talk to the excange center owner so you won't be able to to choose afterwards. I hope my research result will help if anyone is trying to do/researching similar things. Also I would like to know is there a more direct way to modify the pokemon without the need to use breakpoints, and preferably without the need of re-shuffling, as my method is a bit tedious and not clean; any help is appreciated.

Looks like it’s because you didn’t do step 1. You should download and manually merge the fbs file from pknx GitHub and put it inside the same input folder.

You can do this manually, but it requires some very basic understanding of programming (specifically, the meaning of "includes", "struct" keywords), some understanding of Json files, and some time to edit some files. Fortunately I see PKNX actually added most of the needed romfs fbs information on their source code around 5 month ago. This should be the file for Wild Pokemon Encounter https://github.com/kwsch/pkNX/blob/master/pkNX.Structures.FlatBuffers.SV/Schemas/World/EncountPokeDataArray.fbs Includes files are all in the parent folders of the above files in github. Steps: 1. Download the above file, and all its "includes" files, and copy paste them together into one fbs file, removing any duplicate "namespace" lines if necessary. Make sure the included contents come before the EncountPokeData. 2. Download TrinityLoader (should be easy to find via Google search) and use it to open the romfs folder. Use the Treeview functionality of TrinityLoader to extract the file "romfs/world/encount/pokedata/pokedata/pokedata_array.bin". You should learn about how to use the Trinity Loader from online sources if you meet any problem. You should also understand that in SV all the romfs files are packed in to one "data.trpfs" file, and TrinityLoader is the tool to pack/unpack that file. 3. Download "Game Mechanics Editor (Flatbuffers Converter Tool)" via easy Google search. Put the fbs file you edited in step 1 and pokedata_array.bin into the Flatbuffer-Converter "Input" folder and run "Convert to Json fbs.bat". You should learn about how to use the Flatbuffers Converter Tool from online sources if you meet any problem. 4. Edit the Json file in the Output folder, to whatever encounter information you want. 5. Put the editted Json into the Input folder and run "Convert to Bin fbs.bat" 6. There should be a new "pokedata_array.bin" generated in the Output folder. Copy-paste it back to the location you extracted "romfs/world/encount/pokedata/pokedata/pokedata_array.bin" using Trinity Loader, replacing the original file. 7. Zip the romfs folder into a zip and add it to the Trinity Loader using "Add Mod" button (uncheck the TreeView option first) and then Apply Mod. This final output should contain the modded "data.trpfs" file inside the romfs folder, and is what you would put into the LayeredFS Mod system of Yuzu. (Or if you are using other Mod system go your way)

Yes I have tested with the newest DLC version, it is still working.

I found some additional information on special handled moves, for example the forcing of 2-3 turn continuous attacking of outrage, thrash and petal dance. The special handled move info data are stored in exefs/main. Decompress it using nx2elf first, then search for the pattern "00 00 00 00 00 00 00 00 00 00 00 00 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8A 00 00 00" using hex editor. That's the list of IDs for special handled moves. For example, going down the list you get a "50 00 00 00 ..." which specifies the special handling of move "petal dance" (ID=0x00000050). If you change it to another move ID then that move will have the 2-3 turn attacking effect instead. You can also change the ID to some non-valid value such as 0x0000FFFF to get rid of the special handling, but as for now there isn't a way to set another move to use the special handling without swapping out the original one (in other words, the size of the special handling list of move IDs is fixed and no insertion is allowed without further deeper investigation, possibly involving pointer arrays).

I think I got it working. I needed to change certain "table"s into "struct"s in the fbs file. For further reader convenience I will upload my working fbs here. waza_array.fbs

I found a tool here:https://gamebanana.com/tools/11399 I also created an fbs file based on the linked code you posted and online flatbuffer references, but nothing appeared in the output folder. I think I am on the right track but I must have created the fbs file wrongly. (I assumed the "sbyte" in C# is the same as "short" in fbs syntax but that might be wrong, also there might be other things missing) Could you help me what am I doing wrong? I have attached the fbs I created.

Thank you for the information. I see what happens. Probably the data size difference comes from the data being Flat-Buffer compressed. The flat buffer thing is indeed something I was not able to understand, as I edited earlier versions using PKNX itself. However since PKNX does not support scarlet/violet yet, I would like to know is there a way to de-compress and re-compress flat buffers using external tools so that I can edit move effects using hex-editing?

I was able to edit type/category/power/accuracy/PP for moves but that's pretty much all. It looks like the data size is not fixed for each move and pretty hard to understand what each byte means. I.E. Sometimes the type comes right before the category and sometimes there is an extra byte between the type and the category. This probably means if we want to change the move additional effect we need to edit some pointer table too. I would like to know if there is any available and shareable results so that I (and other potential readers) don't need to research everything from the beginning.

I think there is a bug in pokemon teachable TR editing for SwSh version. The source code PersonalInfo8SWSH.cs has lines public const int CountTM = 128; public const int CountTR = 128; while the actual counts are clearly both 100. This causes the bug that pokemons have wrong learnable TRs in the checkbox and the wrong results are saved to the pml personal bin once edited.

I have figured it out. It's actually pretty simple: 1. Search for the nx2elf tool and elf2nso tools online and download them. I cannot post link to other sites here, but if you search for "nx2elf" in Google you will find some site specifically asking for edting the "main" file in exefs. That web page has a bundled version of the two tools that can be downloaded (All credit to masagrator). 2. Use nx2elf to decompress the "main" file in exefs. If you downloaded the bundled version in step 1 there is a batch file to do it in one click. 3. Open the decompressed main.elf. in binary editor. Search for the pattern "04 04 04 04 04 02 04 00 02", there should be one single place with the pattern. 4. That's the start of the type chart, in exactly the same format as older versions (all DS, 3DS versions but not the GBA versions). I will not explain the format here but you can find the explanation for B2W2 here on the second page by Bond697 (and all credits to Bond697): (But notice that Fairy type is added in SwSh versions so the chart is longer) 5. After editing, save the main.elf file and recompress it into main.nso using the elf2nso tool. Again, if you downloaded the bundled version there is a one-click batch to do this. 6. Rename main.nso to main and put into your ModName/exefs directory of Yuzu and/or other directory for mods. 7. The game should have the type chart changed. Hopefully PKNX will include this functionality in its nice GUI, I have posted this in the PKNX thread too.

I have tested the above editing (decompress NSO to elf in binary -> edit the elf -> recompress back into NSO main) and at least it worked with Yuzu Emulator Layered Mod File system. So Type Chart editing actually works in SwSh. If this tool could include that functionality in a GUI interface it would be helpful.

I think I found something important for the Type Chart in SwSh. The main file in exefs is in compressed NSO format and once we decompress it to elf using the nx2elf tool, the type table that starts with "04 04 04 04 04 02 04 00 02" is indeed present and can be found. I will try later when I have time if I can edit and re-compress it successfully using the elf2nso tool and test in the game.

Any partial research/result/info on SwSh Type Chart? The source code of PKNX still shows function name as NotWorking_EditTypeChart only for SwSh versions. I am pretty much stuck trying to find out where the type chart is stored. The pattern "04 04 04 04 04 02 04 00 02" is not found in exefs/main. I have done some scripted search in romfs folders with suspicious names such as "battle", "appli" but the pattern is not found. (I haven't done a full search on every single file as that takes forever for my script/computer for the big resource files) PS. I don't currently have a GoPikachu/Eevee Rom so I don't know how that looks like in exefs/main looks like in those PKNX-type-chart-editable versions. However based on PKNX source code I would assume the pattern is "04 04 04 04 04 02 04 00 02" as appeared in previous generations. On the other hand, I would say since GoPikachu/Eevee and Sun/Moon all store the type chart in exefs I have enough reason to believe it is still in exefs but stored in a different format. Any idea/direction on how to find this out would be helpful, I can do the work.