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
-
Let's get away from editing raw data, ok? (Unless you're using a non-English game, but that's going to change in the near future!)
-
Thanks!
-
If you could upload the save file for me to test, I might be able to find out what the problem is.
-
This doesn't satisfy the GTS. Try it yourself.
-
That's sloppy (what a surprise...), it'd be better off having a second format that's just a group of .pkm files coalesced. I can't say when anything will be added like this, but it's going on my list of things to do.
-
Is this done with a single 4080 byte file?
-
As I said, I think they're blocked. I didn't thoroughly check it. I just checked the few things that I know the GTS validates, and they were right. It's possible, but very unlikely at this point, that PokeGen itself is corrupting your save file. It's hard for me to answer your question without knowing more about what you're doing. The save file currently needs to be >= 512KB.
-
I had trouble sending a Shaymin over the GTS as well. Even with everything set properly. I'm not sure if they just have all Shaymin blocked or what.
-
It's not just not worth the effort, it's completely pointless, given the DS sleep scenario. Nintendo, nor anyone else, could say that a PID has to be related to the date the Pokemon is caught because of this. Not difficult, impossible, based on date. You got it, although you made that a little more complex than it needed to be.
-
Based on the URL I gave you, this is correct.
-
1, 2, 4, 7 Although Sabresite thinks that it could be 1-9 for generation 3. Some are just extremely unlikely to occur normally. 1 Based off of http://www.smogon.com/ingame/rng/pid_iv_creation#rng_pokemon_generation.
-
4294967295 isn't an arbitrary value. You're right... I didn't consider that. With this in mind, there almost definitely isn't any way to link the PID and date caught.
-
Taking out the Smogon-born RNG program's terminology, you're saying there's a location in memory where the seed is stored and that value never changes throughout the duration of the game? So... this supposed seed location in memory does in fact change, but doesn't actually change the RNG calls? But not the new value that's in the seed's supposed memory location, correct? Haha, this showed up in the quoted text, but not in your post yet. So I guess this essentially answers question #2, that this supposed seed memory location changing doesn't actually affect RNG calls at all. The end result of all of this being: If the RNG is in fact only seed a single time based on the date/time + some other value at the beginning of the game... and it's not possible for the RNG to be called 4294967295 times within 24 hours... it should be possible to link a PID to the date the Pokemon was met. As I originally said though, this is RIDICULOUSLY extreme. Edit: After giving it a little more thought, the only way to even verify this PID/date relationship would be to step through potentially billions of iterations of the RNG. I guess this wouldn't be too big of a deal if it's an option and not forced. Surprisingly, it only took about 8 seconds with my Phenom 955 processor to go through 4294967295 calls.
-
How do you know this? I'm not saying you're wrong.
-
The seed is considered the first number that's fed to the RNG function. (At least from a programming point of view... I wouldn't be surprised if the Smogon community has their own unique (and inaccurate) definition.) I can't speak for Jonathan, but I've personally assumed that the RNG function gets that first seed and uses the result of every RNG call for each successive call for the rest of the game. It's certainly possible that the game actually starts the process over with a new seed at any point, I just don't know.
-
This would be correct. Maybe once the current in-progress changes are done, I'll look into the date thing, but even when considering it, there's going to be an absolutely ridiculous number of possibilities in a 24-hour period. It may even cover all 0xFFFFFFFF possibilities in that amount of time. (In which case PokeGen isn't lacking anything.) I don't know how often the RNG function is called. As far as I know as well, yes. The result is the same as this series of events, but that isn't how I do it. It's done in reverse, because I have to start with the IVs. Doing it with the seed first would make PID searching take a very, very long time with varying IVs. (There's no negative effect to doing it in reverse anyway.) It's more that it doesn't fit with the way PIDs are generated, and I didn't think it would serve a purpose. In the case of wanting absolute perfection with the date/time, I guess it can serve a purpose, though. Yes. Assuming all 0xFFFFFFFF values aren't sifted through in the span of 24 hours, yes.
-
Thanks for the compliment + actually reading the thread. I bet a lot of people don't bother. This is going to a pretty extreme degree, but to answer your question, no, the date met is not taken into account. I don't even know enough about that aspect of the RNG function to be able to add support for such a thing either. I suppose it would be detectable by someone who wants to go to that degree to check for validity. If the GTS is any indication, Nintendo doesn't do anywhere near as good of a job as everyone else does at validity checks. (I've heard that the tournaments are more strict, but haven't heard any details about in what way.)
-
Did you even try using US codes? My limited research on it has shown that they aren't different in terms of codes.
-
It's important to note that loading the PGT or PCD file doesn't always result in a proper Pokemon. For example, if the PID has a value of 1, it's meant to be generated by the game, as I understand it. Older (generation 3) events are probably different than that too. I'm also not entirely sure how IV generation works or when it's done. Maybe only when all IVs are 0.
-
C++ with only the CRT. Is there a particular reason you asked?
-
"um" at what?
-
One request is enough. It'll be a while before the next update unless something significant is found to be wrong. I've got some substantial modifications going on. This post has the strings file. It doesn't contain the tooltips, as I don't want to completely overwhelm anyone with all of it at once. Anyway, if either of you finish, just post it here or forum PM me with a link. The help is very much appreciated, and credit will be given where appropriate. Edit: As a note, if you're going to do the translations, please make them look as proper as possible. Punctuation, spelling, that kind of thing. Edit2: Also, red707, you might want to converse with Wylfred and split up the work, assuming he/she's actually doing it.
-
I know almost nothing about DEP, but I'll look into it and find out why this might be a problem. Edit: As I understand it, its sole purpose is to prevent programs from executing code in memory regions that they shouldn't be. Considering PokeGen doesn't create any executable code anywhere in memory except where the program itself is loaded, I'm not sure how this is a problem. I think there's a way to disable DEP for specific programs, but you'd have to look that up yourself. The kind of behavior needed to trigger DEP is exactly the kind of behavior I'd expect from a virus. A lot of viruses will attach themselves to any exe they can on your PC, so it's certainly possible you have one that's injected itself into PokeGen upon downloading it. I can guarantee there's nothing malicious in the download on this site. I'll send you a forum PM with an attachment that contains all of the necessary English text to translate. Edit: Maybe I won't. You aren't accepting PMs, so: these are the strings. There's more than this (tooltips), but these are the more important ones.
-
It sounds like you have all (or most) of the IVs' polarities on "=", meaning they can't change, drastically limiting the search. ...I suppose I should allow that freedom... we'll see.
-
Thanks, but I can extract all of the list information (names, items, attacks, etc) from the ROM files. It could be done, but I'm not making any promises. I try not to add to the size of dialogs unless it's something significant. I'm seeing this too, thanks.