Jump to content

codemonkey85

Innovator
 View Profile  See their activity

  • Posts

    1178

  • Joined

  • Last visited

  • Days Won

    15

 Content Type 

Everything posted by codemonkey85

  1. codemonkey85
    The level is also calculated on the fly for PC storage Pokémon (Pokémon that are only 136 bytes, or 0x88 in hex). What you need to do is determine the growth rate of the PKM you are looking at, read its EXP, and find that value (or the next one down) in an EXP table. See here for more info.
  2. codemonkey85
    greentea is right about that. You need to do the floor on several parts of the equation separately for the whole thing to come out right. ;p
  3. codemonkey85
    Once again, you should be more precise. Don't forget that "offset 90" the way you refer to it should really be 0x90, since it's a hex value. Anyway, for PC storage Pokémon, the stats are calculated on the fly. X-Act posted the formula here. Note that BS = the base stat, I = the IV, and EV and Level are obvious enough.
  4. codemonkey85
    Yes, I finally stumbled across that Bulbapedia article regarding the GBA Pokémon index numbers last night after much frustration. If I ever meet someone from the team that programmed the GBA games, mark my words, I will kick them in the shins. Repeatedly. And vigorously. Anyway. The current task is to convert the GBA data to DS data. Right now I am constructing a function to copy data from the GBA structure properties to the DS structure properties, but I am wondering if I will have to make a lookup table to convert item index values and stuff to the DS values like I had to do with the species ID (I assume I will, argh!). So it's tedious work, but it's coming along.
  5. codemonkey85
    This is incorrect; see below. In regards to ties for highest IVs, I posted this on Smogon a while ago: For the actual Characteristic texts, I recommend the article at Bulbapedia... I haven't looked at Serebii in a while, but I think there were typos in there somewhere. EDIT: By the way, the table at Serebii is a bit more complex than it needs to be. You're better off doing IV Mod 5 to figure out which of the five Characteristics to use for a particular IV.
  6. codemonkey85
    I would think some of the values are stored in bitfields as well, to compress the data more easily. After all, what better way to store True / False values than a simple 1 / 0? That would easily take care of the "hax" variables. I really doubt this. There's no need to store the entire PKM; just the results of the battle itself. The only things it probably keeps from the PKM are species, forme, gender, & shininess so it knows which sprite to use.
  7. codemonkey85
    Unfortunately, for some odd reason I am getting the wrong species ID number from any Hoenn Pokémon when reading the save file, and until I fix that I can't do anything. Other data is correct, and the species ID is correct for Kanto / Johto Pokémon, so I'm not sure what the problem is... blargh. But when I am finished (and have GBA --> DS working right), I will consider a DS --> GBA converter as well. It's an interesting idea to be sure.
  8. codemonkey85
    If you have a ROM image of your game on your PC, you can load a save file along with that ROM using NO$GBA.
  9. codemonkey85
    Please take note that the project known as PokeMod has become Project Pokémon Save Editor (PPSE for short). Sabresite is no longer the sole programmer; in fact, so far, SCV and Jiggy-Ninja have been doing most of the programming, with some support from others. So anytime you ever see someone mention "PokeMod", they are really referring to PPSE (even if they don't know it!). If there are any questions, please post in one of the relevant PPSE stickied threads, or PM one of the aforementioned developers (or myself). [unstickied by evandixon because no one has mentioned either of these programs in years]
  10. codemonkey85
    All right, I changed the topic names to PPSE. But rather than replace all of the text in each post, I think I will make a sticky announcement regarding the transformation of PokeMod to PPSE.
  11. codemonkey85
    I'll leave that job to Sabresite.
  12. codemonkey85
    Naturally. My code library is, after all, going to be open source. I'm almost there... just turns out unshuffling / decrypting the PKM data is slightly more annoying than I thought it would be.
  13. codemonkey85
    Ken, it's okay. PPSE is PokeMod, only with more people working on it than just Sabresite. It will still be the end-all Pokémon DS save hacking program, and as the developers continue to work, eventually all of the features you were looking forward to should appear. Of course, like with PokeMod, there's no schedule or ETA for any of it... patience is always a virtue.
  14. codemonkey85
    EDIT: If there are any mods around, maybe this thread should be moved to Save Research & Development at this point. Nevermind, that first question was answered by the answer to the second question. Sometimes I word things all funny-like. I'll check my PMs, thanks! EDIT: Just a quick update: thanks to Pup and his wonderful information and explanations, I have spent my lunch hour writing up structure definitions for GBA save blocks, GBA save block footers, and a couple of bare-bones definitions for RSE and FRLG save files. Thanks to the miracle of binary serialization, it is a trivial matter to extract the 28 save blocks, and hopefully tonight I can finish my function for unshuffling those blocks and converting the data portion of each block into a complete save file. If I can get that to work, I'll get to work on the explicit layout of the save files, and then the conversion of GBA PKMs to DS PKMs, and after that... the Pal-Parking will commence! FYI Shiny164, if I get to that point, I will help you by creating a program to directly edit your OT info.
  15. codemonkey85
    So the 28 blocks of the save file, once they are unshuffled and stripped of their footers, are all in sequence with no spacing / padding? When you say there is padding, is that padding located at the end of the save file? Or is there padding between the two halves of the file? I believe the save file is 0x20000 (131,072) bytes long, AKA 128kb... is that right? I wish I had a GBA save to look at now, but I'm at work actually. >_>
  16. codemonkey85
    Wow, what a pain in the neck. Hm. Well, that covers the important stuff. Since I already have the aforementioned text table and months of experience in hacking DS saves, this is all the info I need to do... everything. Thanks! ---------- Post added at 07:08 AM ---------- Previous post was at 06:38 AM ---------- Couple questions: If Block ID only goes to 0xD, does that mean there are only 14 blocks instead of 16? You say that each block has a save ID, but some data crosses block boundaries. Does that simply mean half of the blocks comprise the current save and half comprise the backup, like in DS saves? And data within one half can cross block boundaries within that same half?
  17. codemonkey85
    Since Jiggy-Ninja made a new thread for PPSE, I am closing this one.
  18. codemonkey85
    Check out my thread for backing up and restoring retail carts. The only thing is that it only backs up half of a Platinum save file, so make sure to save twice before backing it up.
  19. codemonkey85
    So the data type of this array is Byte? Or is it String? Because if it is a Byte array, it would be much easier for you to arrange the data in a line-by-line format, so you can simply use the index number as a sort of pointer to the correct data in the file. If it is a String array, then I insist that you are doing things the hard way.
  20. codemonkey85
    This isn't meant for personal use; I plan to add Pal-Parking as a feature in my code library, and I know PPSE will have such a feature as well. It's meant so that you can import Pokémon from GBA games to DS games in a way that is 100% legal and accurate. Not to mention the million other uses I could think of if one were able to extract PKM data from GBA games, like mass-dumping of PKM files for instance.
  21. codemonkey85
    I don't think you're understanding what the Move Tutor does with Heart Scales. You can't re-teach your Pokémon moves based on what it used to know; only level-up moves that it could have learned at that point, and only for the evolution level the Pokémon is currently at. This is how the ROM functions, so no save editor can change the moves your Froslass can learn via Heart Scales. EDIT: I just re-read your post and now I'm a bit confused. Did you try scrolling the list of available moves? It should be able to learn anything listed here.
  22. codemonkey85
    I would like to open this discussion up, for sure. For starters, do you know the overall placement of the blocks comprising the GBA save files, and what purpose each block serves? Do you know how to tell which blocks are current and which are backups? There appears to be info out there already for how to calculate block checksums and how to encrypt / shuffle PKM data in the GBA, so if the above questions are answered, I may start digging into GBA save files this week to see if I can extract Pokémon data. At that point, it should be easy enough to convert that data into the DS structure. Then a "virtual Pal Park" app should be doable.
  23. codemonkey85
    I do not understand what you are doing. Your database will be in an external text file? What format is the data going to be stored in? How are you performing these searches? What is this "hex array" you are referring to... is it a String array? Those numbers are just index numbers. You could easily make a List(Of String) and add each move to that list at startup. Then you could pull the name of a given Move by using List(index), where index is the number of that move. Either 100 or &H64 would pull up the same move. FYI: When I first started PKMDS, my data was also in external files, in CSV format. In order to obtain info, I would iterate through the file, reading one line at a time, and splitting each line into a string array using String.Split(","). Later I wisened up and began hardcoding my data, so now I use Dictionaries (basically hashtables) for lookup. It's much faster and more reliable than external files, and there is minimal (if any) data conversion necessary.
  24. codemonkey85
    Why? VB knows that 1 is the same thing as &H1, just like it knows 10 is the same thing as &HA. There's no need to convert anything as far as index numbers are concerned; the 1 - 467 will be fine.
  25. codemonkey85
    Well, there is of course Bulbapedia for a simpler presentation. But the data at Legendary Pokémon is much more comprehensive. The number of the move (on the leftmost column) is the decimal representation of the "hex value". OT gender is mentioned in the Pokémon data structure article for the NDS, in both Bulbapedia and our own wiki. It's stored as a bit in byte 0x84 of the PKM data.
×
×
  • Create New...