Codr
-
Posts
1576 -
Joined
-
Last visited
Content Type
Profiles
Pokédex
Portal
Technical Documentation
Pages
Tutorials
Forums
Events
Downloads
Gallery
Blogs
Everything posted by Codr
-
Updated to 2.2. This includes save file support. Please read versions.txt for other changes/additions. Also check the original post for some more information.
-
The "wacky stuff" is the hexadecimal representation of the characters. \xxxx allows you to specifically set each value to what you want. To answer your question, yes, it'll display as exactly what was in the file you loaded. The next version (which may be done tomorrow, but I won't promise that) will have more improved handling for nicknames as well. At the moment, it limits you to 10 of the 11 characters for nicknames, as it automatically puts in FFFF for the last character. You'll be able to set all 11 characters manually with the update.
-
I have no explanation for what could be causing any problems with this, unless you're on a non-Windows OS and the "emulation" software you're using isn't properly handling the Windows functions. The code is simply checking the state of the egg checkbox and setting the egg flag (bit 7 of byte 59). Nothing is going wrong to overwrite it in any way. So I really don't know. I know you're not trying to make the program look bad. I very much appreciate it when people bring problems to my attention, as I don't always notice them. This one is just baffling though. Maybe you could upload a .pkm file of one of the Pokemon that's mysteriously having this bit set.
-
You're referring to the egg checkbox on the main tab, right? I checked the code for that and it's being written as it should be. Are you sure the egg checkbox was unchecked? Were you using version 2.1? There was a recent fix to loading of Pokemon that involved the egg checkbox.
-
I wasn't aware this was happening, it certainly isn't intentional. It'll be fixed in the next release, but it could be a while before then, since it's undergoing significant changes for save file support. Anyway, thanks for pointing it out.
-
If they're writing that data wrong or making it more difficult to select the appropriate information, then yes, they can be inferior. I don't know how you can disagree with that. Please give an example. Even in this situation of needing to change a single byte in the PKM file, I think the majority of people that post on here looking for help (and even the more experienced) would agree that it's more convenient to use a program designed specifically for modifying PKM files over a hex editor. I can't see a purpose to this comment other than antagonism, which isn't justified or appreciated.
-
Having to do extra work because a program fails at its job isn't fun. I can't imagine anyone trying PokeGen and having anything negative to say about it relative to Pokesav in terms of ease of use. With the addition of save file support... soon... hopefully... there won't even be any reason to use Pokesav over this for the purpose of making/editing Pokemon.
-
What exactly is "all methods" referring to? If you're referring to Pokesav and alternatives, saying they're equal is very obviously wrong. It was stated that Pokesav doesn't support alternate Pichu forms (which is, internally, how the spiky-eared one is created), and as far as I can tell, that's correct, it doesn't. My program does.
-
Are you editing bytes that PokeGen even shows as extra bytes? The common "hidden bytes" in Pokesav are handled automatically in PokeGen so that you don't have to do it manually. For example, you don't edit any of the bytes listed here manually in PokeGen. If you actually check the numbers on the extra bytes, you'll see that they aren't 0x44, 0x45, 0x46, 0x47, or 0x85. This isn't related to Pedro's "problem", but I wanted to mention that save file support is coming, along with proper editing of multiple Pokemon at a time.
-
Or, maybe, just maybe, you can not look at Pokesav as the only option for everything! (It sucks.) Have a look at my signature.
-
I don't even know what SendPKM is. I'm assuming it just works directly with .pkm files, but that still doesn't tell me a whole lot. You can create a 136-byte PKM file by not overwriting an existing file. It always saves new files as 136 bytes. Also, the location (as in party/PC) of the Pokemon isn't stored in the .pkm file. No changes should be made to the party/box controls by the program when you load a new Pokemon.
-
As always, the feedback is appreciated. It's what keeps me interested in actually updating the program. (Well... and the fact that Pokesav is SO badly designed that it irritates me that anyone uses it.) I did check those after loading the file. They're all zero like every other Pokemon I've seen. You can load party or PC PKM files and see all of the appropriate data regardless of which size it is. This was true for previous versions too. I've had other requests for support for other operating systems as well, but that's a very, VERY massive task that I don't think I'll be pursuing. That's what I really like to hear!
-
Updated to 2.1. This includes party Pokemon support and chained shiny PIDs, along with some other changes/fixes. To my surprise, chained shiny PIDs are actually very quick to generate. I didn't expect there to be so many combinations possible. Note that the "sync" message in the Legality Checker may show "Invalid" for chained PIDs. I need to talk to Sabresite (the developer behind the Legality Checker) to find out some more information before I can resolve this.
-
Thanks. Yes, and I've thought about doing so. The speed is going to be lower than the other methods, maybe (probably) significantly lower, however. I've read about people experiencing this problem, but haven't tried it myself. Considering all I ever knew had to match was the things mentioned (trainer name, gender, and IDs), it's pretty surprising. There must be something else different, assuming your trainer name bytes are identical. I have no idea what it is though. I can do more research into it when I actually get around to capturing it for myself. As expected, I didn't see anything unusual, but I didn't thoroughly examine it either.
-
As you can see at the top of the post, yes.
-
It'll be going up on the downloads page whenever I get around to writing some information about it. If you're really worried about it being malicious or something, I can't exactly convince you otherwise, but it's had well over 500 downloads through all of the revisions, and as you can see, nobody has posted anything negative about it in that regard.
-
Sure, use a program that works properly, like the one in my signature.
-
Would party support be acceptable if it doesn't have the ability to edit the extra 100 bytes of data that goes with party Pokemon? Anything that's in the "Stats Edit" dialog of Pokesav, basically.
-
I was going to add something about that in the tooltip, but it's really just common sense. It's possible, and probably somewhat easy, to make it simply overwrite an existing Pokemon's code if you've generated one with the same box/slot already. I may do that for the next version. The append thing is mainly a band-aid sort of thing until I add support for multiple Pokemon the right way, assuming that ever gets done.
-
^
-
I have none, that was made clear in my post, which is why I didn't state it as a definite answer. This is assuming that the process or depositing/withdrawing a Pokemon from the PC actually modifies the stored ability index based on the PID. I would expect this to NOT be the case. The only definite situation I know of where the stored ability is modified is when the Pokemon evolves with the first ability, has a PID indicating ability 2, is a species from generation 3 that only had one ability, and has 2 abilities in generation 4. In this case, it does in fact update the ability to ability 2. Edit: Confirmed that PC deposit/withdrawal does not modify the current ability in any way, regardless of the PID, as expected. A lot of their information contains stuff regarding generation 3 as well. I didn't thoroughly read through that post, but I wouldn't be surprised if it's making assumptions from old generation 3 knowledge. (Where the PID solely determined which ability the Pokemon has.)
-
I've talked to various people and have been told that the PID ability doesn't have to match the actual ability the Pokemon has. According to them, it can actually be generated differently by the game, but I haven't done any testing to try to validate this. If you've actually tested this and seen otherwise, please post and let me know.
-
You can attach it to your forum posts. That showed me what I wanted to see, thanks. I'm afraid I don't know enough about exactly what needs to be set for Pokemon to be "legal" to answer your questions. I was just interested in the "sync" part of the legality checker. However, according to the forum post NulMyre linked, it would seem that the "Sync" part does need to be valid in order for the Pokemon to more accurately match what's created by the game. (Assuming that the Legality Checker's "Sync" message isn't referring solely to the Synchronize ability as NulMyre said.) The post says this only applies to wild Pokemon and legendaries that can be Synchronized. I highly, highly doubt that any sort of "official hack check" is that detailed though. Legality Checker only shows "Sync" if the met location is set to specific values, it seems. "Hall of Origin" is one (like your Arceus) that triggers it.
-
The whole thread is interesting, I'm not skipping directly to synchronize! Thanks for the link, I didn't think about checking smogon's forums.