Jump to content

codemonkey85

Innovator
  • Posts

    1188
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by codemonkey85

  1. That whole page is specific to how things are stored in the save file only. I am not sure what the ROM defaults would even be in the case of genders though... but I think the enumeration places male with a value of 0 and female with a value of 1, right? So wouldn't male always be the "default" value for a null?
  2. Why? PPSE is faster and nicer looking. And like Jiggy said, these problems need to be found and squashed.
  3. Bam. Also, I'm not entirely sure about the placement of this thread... it seems to me like it would go in Save R&D, but eh.
  4. Here's a link to what you need.
  5. ...No. I think you need to read that post again. Carefully.
  6. Rest assured guys, I am working on it. Well, not for Pokesav obviously, but I am armpit-deep in writing an application to extract PKM files from GBA games, converted to DS format, and 100% legal (if I ever figure out the trash bytes). Stay tuned.
  7. Yup, that's the one. FYI, X-Act from Smogon said a bunch of PKMs were tested and they all conformed to the above.
  8. Again, I don't recommend using Long. Use UInt32. And I didn't show you the page to scare you with the formulas, just to show you the EXP tables and my source.
  9. People get this mixed up all the time. Eggs hatch at level 1, but in the PKM data, the "met" level for an egg / former egg is ALWAYS 0. Note that in the Trainer Memo, there is no mention of a met level.
  10. That's basically what I said. Incidentally, the games themselves don't use those formulas as far as I know; to save performance time, they simply use lookup tables (just like I've been doing, and just like I suggest you do).
  11. 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.
  12. 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
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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]
  20. 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.
  21. I'll leave that job to Sabresite.
  22. 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.
  23. 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.
  24. 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.
  25. 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. >_>
×
×
  • Create New...