StarsMmd

I did my first major tests yesterday and after noticing a few odd things with animations I'd changed I noticed that in the move data there are 2 animations. The one previously identified at bytes 0x32-0x33 but also at 0x1e-0x1f. There are cases where changing only one of them is fine but it's lengthy to explain and not worth it so as a rubric just change both of them to the animation you want. This was in btw. I haven't checked colosseum for this but I reckon it has 2 animations as well.

Since it looks like you're taking a look at now You might like the list of pointers into common_rel from my ram dump of . It starts at 0x4E87C8 I believe.

When XY just came out, welll before the browser exploit, this was how I used to get "legit" hacked pokemon into XY. Of course it was limited to gen V and prior but it was better than nothing. I used my pokemon white retail cartridge, pokesav and a device that can import/export save files from nds cartridges. I can't remember the name of the device right now because it's been over a year since I've last needed it. Try a good search. It plugs into the usb port of your computer and a retail cart can slide into the side of it. I can't remember the proce either but I think it was fairly inexpensive. You simply copy the save from the cart onto your computer and then edit the save file in pokesav. Make sure the pokemon are all "legit" or they obviously won't pass through pokebank. In your case you use the data of the pokemon in those files. After that youbjust put the edited save file back onto the cart and you can use poketransporter to get then into XY. Of course the pokemon won't be kalos native but you can always breed them with ditto. I would recommend creatong a few 6iv dittos and transporting them into XY as well. They make the process of breeding native, 5/6 iv pokemon incredibly easy. You can also change the region of the ditto so that it activates the Masuda method, Good luck. Edit: Look at this thread for a guide on the hardware required. http://projectpokemon.org/forums/showthread.php?29809-3DS-How-to-backup-restore-your-retail-cartridge-save-file-for-3DS-games&p=165717#post165717 The one I have is the NDS adapter plus.

Google search for a hexadecimal tutorial. You should try and understand the basics of what it is. You don't need to worry too much about it though because XSE has a converter built into! On the right hand side you can see the calculator. Underneath the inout bar you can see 2 radio buttons called 'dec' and 'hex'. While it's in dec, type in a decimal number and then click the hex button and whatever you typed in will be converted. Again I highly recommend that you take a tutorial of some sort as hex is the basis of hacking any game.

I'm not an expert on this but I'm pretty sure that all possible trainer IDs have the same chance of finding shinies. It's probably just bad luck. Remember that shinies are many times easier to find now than it was back in GenIII. I'd been playing pokemon for many years before i found my first shiny and I used to spend every possible minute playing pokemon. Now I've found/chained/bred dozens of shinies since XY/ORAS with the vast majority of them being competitively viable. Shinies were meant to be extremely rare so it is plausible that you wouldn't have found one even with all those hours.

1. Make sure you convert the 18 (or 26) to hex before using them in xse. so 0x12 (or 0x1A). 2. I believe you'd have to make sure that any tiles in the town which are visible from the route use tileset 0 (since they both have 0) and vice versa.

1. If memory serves, each sprite has an index assigned to it. Thisbis shown by the calue in the field labeled 'No:'. Use this number with hidesprite. It may be the 'person event no:' value but can't remember. 2. Each map loads a set of tiles. If the tiles in the next route don't match the tileset of the current map then it will come out messed up.

It's cool. We all need help at some point. When you compile the script in XSE a little window pop ups with the offset it placed the acript at. Make sure you copy that offset and assign it to the noc in advanced map.

try #dynamic 0x800000 You should be fine using 0x800000 every time. XSE should automatically find free space for you and will tell you the offset once it compiles.

Yeah the image was just one of the snapshots you see when you select a map so the resolution is really low.

The two main things you need to check are the "Talking level" and "Script offset". Make sure the talking level is at the same height as the movement permission for the map (you can probably just set it to 'Always') and set the script offset to the same offset. I can't think of anything else that could be causing an issue unless maybe you didn't save properly or something.

Just a little update. 0xFFFF08 does indeed change the font colour. The next bytes are in RGBA order but the Alpha channel doesn't appear to have any effect on the font. 0xFFFF38 also changes the font colour but it uses a small group of predefined colours based on the following 1byte. The colours are as follows: 0x00 white 0x01 yellow 0x02 green 0x03 dark blue 0x04 orange 0x05 black The range of colours is small but it uses fewer bytes.

it's been a few years since I hacked gba but hopefully I still know what I'm talking about. If you click on her sprite in route 103 you will see some details on the right hand side of the window. You want copy all of these to the a new sprite you create in petalburg woods. Sometimes the rival appears when you step on a script tile like on route 119. In that case you'd need a to copy that tile and it's values. Finally some scripts are activated by entering a map and there are some that will decide whether a sprite should appear or not. This may require you to tweak some of the scripts depending on the map. Honestly, I would recommend that you find a good advanced map tutorial and a scripting tutorial too since you sound like you're just starting out. I don't know of any personally but there are many and they should be pretty easy to find. Good luck.

When you say it doesn't work, what exactly do you mean? It's hard to help if we don't know where the problem is coming from.

[quote name=Tiddlywinks;205678 A bunch of the "tables" are pretty indecipherable beyond maybe telling how big the entries are. I was able to identify string IDs in some of them' date=' though. Some of those were still hard to figure, though... But I did manage to figure out a few new tables pretty well, too. First, let me just identify the ones that had string IDs but that were difficult to figure out otherwise, in case somebody might feel like taking a look at them... [/quote] My japanese is pretty good and as far as I can tell it's mostly debug text. Stuff from the debug menu and maybe some output logs. You also identified the strings that are very clearly related to the AI. They remain enigmas though. I can say that the table at 0xB9C is almost definitely not to do with music. It seems more like a list of milestones and events from the game. They probably come from a debug menu that the programmers could use to skip to certain parts of the game for testing. [EDIT:] I don't know actually, maybe I'm wrong about it not having anything to do with music. It's pretty hard to ignore the fact that the names of all the sfx and music are listed right after it. Furthermore, I just counted the number of song names and I think it's the same as the number of entries in this table.

It wasn't very clear that you found the pointers in the RAM just spent a good few minutes searching common_rel itself. Also don't the pointers start at 0x478DF8 in RAM? Also I've been wondering how the game decides if the opponents pokemon's HP is visible. It's definitely visible on mt.battle on battle mode but not in story mode. It's probably one of the unknown bytes somewhere in the tables you found. Or maybe it's just incorporated in the battle type values or something. Did you notice this?

It really it is a feature that calculates it for you. I don't know how much you know about using debug mode so I'll start from the beginning. It also shows you the code in hex and in assembly and you can place breakpoints and all that. When in debug mode, choose the 'Symbols' option in the top menu and then 'Generate Symbol Map'. This will get dolphin to name all the functions for you and they will come up in different colours making it easy to see where each one starts and ends. If you look at the 'code' tab. You will see 4 boxes on the very left. The second one shows the names of the functions (Dolphin automatically names them based on their offset and you can change the name to whatever you like if you figure out what it does). The third box shows the functions the current function branches to and the 4th box shows which functions branch to the current function. You can click on any of these and it'll take you straight to that function. Also if you're looking at the code itself you can right click on a branch instruction and there's an option to follow that branch and dolphin will take you to the instruction it branches to. I had a lot of trouble finding a good ASM tutorial as well but then I stumbled across a really good one on the super smash bros melee forums. It uses melee and Sonic adventure 2 battle as examples but it is really easy to follow and should teach you everything you need to know. There aren't any prerequisites either, so I'm sure you'll get it. This one video is all I needed to get started. Here's the link: I hope you give it a go. It's a few hours long but well worth the time. Good luck!

In response to the original question, I've found the ASM function which determines whether the pokemon's shiny model is used or not. This calls the function that calculates whether it is shiny or not. We can quite easily change this to decide whether it uses the shiny image based on if it's a shadow pokemon. The only thing stopping us from using shadow textures for all shadow pokemon is that the model formats aren't understood yet. It would be possible to do it on dolphin by dumping then replacing the textures for every shiny pokemon in the game. Of course, it goes without saying that there would be no shiny pokemon anymore. Personally I would happily make that trade. I haven't had any luck with extracting textures from the model files though...

No worries. Sorry if I wasn't clear. The game often checks for shadow moves in the ASM and probably determines whether it should display the icon or not in the code. For I guessed how the game may check for a shadow move. I'd already tried copying the exact entry for a shadow move and putting it over a regular move and that didn't make it a shadow move so I knew it wasn't in the move data table. The next obvious answer was that the game simply compared the index with 0x164. So I searched Start.dol for the value 0x164 which led me to the instruction "0x2c000164" which is "cmpwi r0,356". I found the same instruction in the RAM on dolphin in debug mode and used break points to test it. A neat feature is that you can see which functions call the function you're looking at. Finding a similar function could be helpful to you. For example, the main part of my phsyical/special split implementation was finding the function that determined the category of a move. I knew it had to check if the move was a shadow move or not so I looked at each of the functions that called the function for checking. I found the function and simply ignored the check so that it always ran the code that checks the move data rather than the move's type. Another helpful way to find ASM functions is to see which values in the RAM are being edited by Action Replay or Gecko codes. You can then begin to look into which functions branch to and from eachother. This helped me find the shiny calculation function. Seeing a bunch of XORs and a comparison to the value '8' were a dead give away. Unfortunately it doesn't seem that displays the contest data. I thought of using it to display an image of the move's status rather than contest category.

I tried looking for pointers before, but like you said my start offsets were a bit off. I concluded that the pointers must have been somewhere else and never thought to look for them again. Very useful indeed. I usually just scroll through the file and adjust the bytes per row until the bytes all align and see if I can spot anything. The really great thing about the pointers though, is that this means we can potentially increase the size of tables. I'm really glad you spotted that! I'm in the process of documenting some of my recent findings in . Maybe Some of it will be of use to you. May have figured out some of the tables you haven't. Also you found some really interesting tables. Clears up a lot of things I'd been looking for.

Yeah that's true, although it is possible that the game is programmed well enough that it wouldn't crash without contest data. Have you tested this?

Sorry, my colosseum data is a bit unreliable at times since it's pretty old. Thanks for that. That makes sense. I noticed the description and still didn't make the connection hahaha. The contests stats aren't actually that 'useless' from a hacking point of view. Since this data is irrelevant it can all be replaced in order to optimise the lzss compression. Decreasing the file size is always nice.

I have a lot of information on which I'll be adding to this post. I've been writing an app to streamline the hacking process and I've pretty much completed the logic and just need to complete the UI now. As a result there is a lot of code that is quite useful as a reference. It's all in the swift programming language which I doubt many people here use but it should be simple enough to figure out what it all does. Here's a link to the repository : -Code'>https://github.com/PekanMmd/Pokemon--Code Part 1 of my tutorials: -hacking-tutorial-part-1-File-decompression-recompression'>http://projectpokemon.org/forums/showthread.php?46250-Stars-Pokemon-colosseum-and--hacking-tutorial-part-1-File-decompression-recompression I'll be updating this post with more details. Enumerations: Constants: Texture Editing: Data Tables: Gift and Trade Pokemon:

So I've been digging through the files in Pokemon XD and I stumbled across an image that is unused in the final version of the game. It shows the main character (Michael) at what looks like an early version of Gateon port. He has a very different design to the final design and it's sooo much cooler than the final version. I wish they'd kept the old design.

Usually these kinds of tables are in common_rel or, less often, in start.dol. However, we know that common_rel is loaded into ram in its entirety and I think almost all of start.dol is as well. You can figure out where these files start and end in ram and if any data in ram is between one of the two offsets you know it is in that file. However, these files are always at the same offset in ram and you say the start of the purification table varies in ram. This potentially means it's created at runtime. I've had a little look myself and can't track it down so my best guess is that it is created by some ASM in start.dol.