Fotomac

Snore and Sleep Talk would be interesting to code their effects. I'm assuming you've already copied over the change that lets you select a move while asleep, since waking up doesn't use your whole turn.

As I said on Github, that was a typo. I fixed it in the next commit.

Other than the bugfixes already on github, I was going to fix a few TM compatibility flags and maybe one or two minor skill set changes. But thats about it. Only reason 2.4.1 exists at all is that trainer bug.

I really don't know. I'm pulling my hair out over a seemingly impossible bug that slipped past everyone who helped test and I have no idea what would cause it. Apparently, sometimes, at random, a trainer just... won't take their turn at all. They won't attack, won't use an item, won't switch, etc. You attack, and it just goes back to the move selection menu and the opponent doesn't do anything. So no offense, but I'm WAY more worried about figuring out wtf is going on with that right now.

You probably did something wrong when adding text for the new Lass.

Not sure. I'll check it out tomorrow, gonna be going to bed soon.

Glad you got it sorted.

I'd have to look around at what you did and see if I can figure out what you should've done instead.

I haven't really had a chance to play much of the demo you sent yet. Partially I've been busy and partially just been distracted with real life stuff. So I don't know yet.

I think the issue with Transgender Nidorans comes from an oversight on my part, forgot to explain something. In Red++, ID Numbers match Pokedex Numbers, so when it looks up the Pokemon in the gender ratio table, it just jumps to an entry corresponding to its ID. In Red++, this means the table being sorted by Pokedex number works. In your case, it will probably load the wrong entry. You'd need to use the IndexToPokedex predef to get their 'dex number instead of their ID number and call it with that. That's why you're getting transgender nidoran, they're looking up an entry that was intended for a different Pokemon.

As for hidden items, it is a bit confusing. The data is in: https://github.com/pret/pokered/blob/master/data/hidden_objects.asm AND https://github.com/pret/pokered/blob/master/data/hidden_item_coords.asm

Once again, if you did it right, that shouldn't be possible, because comparing it against a DV range never happens, which is the same way the 1/256 glitch was fixed. I'll see if I can find out what is causing that for you. I've never seen it, and with the way I coded it, it shouldn't be possible.

That shouldn't be possible, since they are set to all male or all female, and gender is calculated the same as in GSC. If it reads their byte as NO_GENDER, MALE_ONLY or FEMALE_ONLY, it skips the DV checks entirely and jumps straight to returning their gender.

Change this:


To this:


That should move the box over against the side like you want it.

I'll take a look at it in a bit. Did you copy the way I did it? If so, I'm guessing maybe you made a typo or something?

Considering TMs and HMs call the same routine, and HMs are already infinite use, you just need to look at what makes it conditionally act like an HM and change it to always do that. I'm on my phone so I can't be much help at the moment, but yeah it should be as simple as changing or removing a couple of lines.

Will do.

Not in the near future, but eventually. Before I do that, I'll be doing things like merging pokered-gbc, merging crysaudio, splitting Special into two stats, adding held items, redoing stats to use IVs instead of DVs and all that junk. Abilities are not a priority for me. And none of that is a priority until v2.4 is really stable and released.

From what I can tell, you'd need to not only add contest stats to Pokemon and moves, you'd basically need to write an entire "contest engine" from scratch, since the way contests are handled is visually similar to battles, but functionally unique from anything in Gen 1 or 2. This isn't something you're going to slap together over night. In other words, you need to have a really, really, really good understanding of how contests work and how z80 assembly works, and at best, you currently have 1 of those. Not trying to be rude, but that feature is way above your skill level right now, and probably above mine honestly.

Assuming you mean the Contests that RSE had, I have no idea how they work internally at all. I think they would be a cool thing to add at some point, but I have done absolutely zero research into actually doing it.

If you mean something like the Bug Catching Contest, I haven't done that yet either, but it would be a lot simpler to add. You'd basically just like...

- Make sure the player only has one Pokemon in their party, by just checking the party count RAM address.
- Come up with an extra battle menu, that is the same as the normal battle menu, but has the Safari Ball option instead of the Pack option. Haven't looked into the specifics of this yet.
- The lazy way is to end the contest if the steps run out OR if the Player has 2 Pokemon in their party (meaning they caught one). If you want to make it so they can swap out, that might get trickier. Probably need to come up with a routine that checks to see if they have 3 Pokemon, and asks if they want to swap their New Pokemon for the one they had. If they don't, it just decreases the party count back to 2. If they do want to swap, it would copy the Mon3 data over top of the Mon2 data, then decrease the party count.
- Make up a routine to judge the contest results. This would probably be the most complex part, depending on how you want scoring to work. I've looked into the way Gen 2 does it and the way Pokemon Gaia does it (though Gaia is a Gen 3 hack, and the code is written in C, its still an example of how the logic works).

EDIT: For the logic I described to work with swapping out the new one for the previous one, the player would have to be forbidden from rearranging their party during the Bug Catching Contest, so I'll probably want to come up with a better way to do it before I actually implement it. But that's my initial brainstorming/notes on it, anyway.



Also, did a bit more looking, and it looks like the problem with EXP on Capture was that wWhichPokemon gets used during the GainExperience routine (naturally) but the RemoveItemFromInventory routine expects that value to be the number of the item slot to remove. That's why it was removing a seemingly random item from your pack. So you could do something like this.

Go here and add this:



Then go right above this line and add this label:


And see if that works. That *should* make sure you don't lose your place in the bag menu, so it removes the proper item at the end of the routine, and then properly give EXP to the Pokemon that fought (and all of them if you have the EXP ALL). I haven't actually tested that yet, but it looks like it should work. Let me know if it works for you or not.

Again, I haven't done it yet, but theoretically. I need to look a bit more into the way it reads the amount of shakes to play the animation. I know that it come up with a value that determines that stuff, and the code for playing the animation deciphers it. So you'd need to like... change that so that instead of saying "You missed the Pokemon!" (which was the infuriating Gen 1 equivalent to breaking out with zero shakes) it would do the Gen 2 thing instead. It's on my list of things to upgrade, but again, I haven't given it priority yet. Sorry.

I haven't actually looked into it again yet. The issue I was having before was that it wasn't removing the right item from your pack when you used a ball, but was otherwise working correctly. That means the issue has to be that a value was being overwritten during the EXP-Gain process, causing later parts of the routine to fail. I need to look over it again in more detail, but just haven't gotten around to it yet. Given how buggy it was last time I tried to add it, I wanted to hold off on adding it again so that I don't delay 2.4 even further than I already keep doing for testing of existing features.