You are not logged in.
I've recently semi-successfully ported Polished Crystal's port of Prism's party screen's individual Pokemon palettes. It's a really nice feature, so thank you to everyone who worked on it. I gotta say it's a must-have for any hacks in progress.
Anyways, I was able to figure out most everything eventually, but there are two particular parts that've frustrated me a bit, so I'll try to detail them here. I'm also not 100% sure if this first one is a pre-existing bug or not.
1. For some reason, for about one/two frames when moving Pokemon, held items inherit the same palette as the party member:
Again I'm not sure if this is related to anything I may have missed when porting the code. It's absolutely minuscule, but hey; if anyone's got any suggestions - I'm game.
2. Custom palettes based on shiny status were something I couldn't port directly. The hack Noah and I are working on strives to be as vanilla as possible, so we've maintained a few rules to keep compatibility with the original games and things like Stadium 2. A weird goal considering the nature of romhacks, but so far everything still works fine on original hardware. One of those rules is to not modify Pokemon structure, which is the main reason I'm having trouble.
If you take a look at the previously linked commit's version of mon_icons.asm, you'll see that in four places(specifically lines 59, 92, 164 and 188), PC uses it's custom Pokemon structure to identify shiny status. TempMonShiny, MON_SHINY and SHINY_MASK are things that we don't have, and (likely) won't be able to use. In order to compile, we substituted in TempMonDVs and MON_DVS, but obviously these don't work in the same way. I've messed around with trying to farcall CheckShininess, and even tried using Prism's CheckShininessHL, but haven't had any luck. I know this is probably dead simple to someone who knows what they're doing, but I'm still learning.
Mission complete boys:
What's funny is that my methodology to fix this one happened almost accidentally. Something interesting about custom shiny palettes is that obviously, there are some shinies who's color changes don't differ that much, so the best matching icon palette is going to be exactly the same.
For example, Tentacool's normal and shiny palettes:
and it's entry in mon_icon_pals.asm
dn PAL_OW_BLUE, PAL_OW_BLUE ; TENTACOOL
(maybe teal would look good, but I haven't bothered messing with any palettes other than magnemite/swinub)
So, while I didn't check or change all of them, I knew that chances were, there would be gift/starter pokemon that people might want to reset for a shiny, and if they were going use the name screen icon to check(or wanted to,) it wouldn't work for every Pokemon. So my solution was to add the shiny icon to that screen. However, my initial solution wasn't great, and it also tricked me since I didn't properly test it.
I copied this code from stats_screen.asm and changed the hlcoords to a better spot, as well as changed <SHINY> to <SHINYB>, which was also ported from an older version of polishedcrystal, since the shiny character is not available by default in the loaded font.
And, it "worked." It would show the icon if you caught a wild shiny Pokemon, but not if you received one, and it also wouldn't show up if you took the same shiny Pokemon to the name rater. Naturally this frustrated me, as the whole reason I added it was for gift Pokemon. So I kept messing with it, but it wasn't until I stumbled upon the "GetGender" function that I was able to come up with a solution. I realized that since it was being called on the naming screen so that it could place gender, it had to be reading DVs from the proper place. So I took a look at it, and was able to quickly smash it together with the "CheckShininess" code. And it worked like a charm. Originally I had left in all of the different types of detection, but quickly realized that during battle, checking the party screen would apply shininess to all pokemon based on the enemy Pokemon's DV's, so I just deleted stuff until it worked properly. The best solution.
Anyways, here's the code:
GetShiny: ; called at nicknaming screen, party screen, move screen ; this is based off of the GetGender function below; however we only need to call the one type for the affected areas to work ld hl, PartyMon1DVs ld bc, PARTYMON_STRUCT_LENGTH ld a, [MonType] and a jr z, .PartyMon .PartyMon: ld a, [CurPartyMon] call AddNTimes .DVs: ; Attack ld a, [hl] and 1 << SHINY_ATK_BIT jr z, .NotShiny ; Defense ld a, [hli] and $f cp SHINY_DEF_VAL jr nz, .NotShiny ; Speed ld a, [hl] and $f0 cp SHINY_SPD_VAL << 4 jr nz, .NotShiny ; Special ld a, [hl] and $f cp SHINY_SPC_VAL jr nz, .NotShiny .Shiny: scf ret .NotShiny: and a ret
It would probably be a lot more efficient just to "farcall CheckShininessHL" instead of copying the entirety of the code, but this works just the same.
So, I was able to use this function like so on the naming screen:
.Pokemon: ; 1173e (4:573e) ld a, [CurPartySpecies] ld [wd265], a farcall LoadNamingScreenMonIcon ld a, [CurPartySpecies] ld [wd265], a call GetPokemonName hlcoord 5, 2 call PlaceString ld l, c ld h, b ld de, .NicknameStrings call PlaceString inc de hlcoord 5, 4 call PlaceString callba GetGender jr c, .genderless ld a, "♂" jr nz, .place_gender ld a, "♀" .place_gender hlcoord 1, 2 ld [hl], a .genderless call .StoreMonIconParams .shinyicon callba GetShiny ; works as a catch-all for determining shininess ret nc hlcoord 1, 3 ld [hl], "<SHINYB>" ret
That was the easy part. After realizing it worked, I had to go back to mon_icons.asm and try it out to see if it would work. Basically, all I had to do was comment out all of the aforementioned MON_DVs and TempMonDVs, since the places those were at were also where GetMenuMonIconPalette was called, and add this to the top of GetMenuMonIconPalette:
GetMenuMonIconPalette:: ; check shininess callba GetShiny jr nc, .not_shiny scf jr GetMenuMonIconPalette_PredeterminedShininess .not_shiny and a
And then suddenly everything worked perfectly!
Here they are working in tandem:
I'm so happy this is working, this was one of the major remaining engine-related things we needed to tackle for our hack.
Last thing I'd like to mention; testing shiny gift Pokemon. This one actually didn't bother me as much as everything else. I'd remember reading through this thread once and seeing it mentioned, so I tried the first thing I could think of:
.generateDVs ld a, [CurPartySpecies] ld [wd265], a dec a push de call CheckCaughtMon ld a, [wd265] dec a call SetSeenAndCaughtMon pop de pop hl push hl ld a, [wBattleMode] and a jr nz, .copywildmonstats ;call Random ld a, ATKDEFDV_SHINY ; very useful for testing shiny "givepoke" stuff ld b, a ;call Random ld a, SPDSPCDV_SHINY ld c, a
And it worked. Naturally, this can't be left in as is, as every gift pokemon would be shiny(any maybe other things idk where all this is called from) but just for testing purposes it was fine. I also triple checked by setting up some pixel detection AHK scripts and verified by resetting for some real shinies.
Anyways, hopefully this'll be helpful to someone, and if there's anything wrong with this stuff please let me know. I'm really glad to have this forum as well as the source from other projects available as a resource.
Nice work, looks awesome!
Definitely want to use this for my rom hack
I've been having issues with the icons, definitely need some help.
Not sure if you'd be interested
Regardless, this looks great! Can't wait to implement
I'm definitely not the greatest, but I'll do what I can, 'cause I worked pretty hard on them too. I may just need to make a full port of what I've got on a default build of pokecrystal or something. Would that be of use?
My issue mainly stems from the fact the base of my rom comes from TPPCrystal251pub
Essentially the build of the game is slightly different compared to that of pokecrystal
Certain files don't exist because they've been moved or combined into other asm files.
I actually spent a couple weeks making individual menu sprites for each and every Pokemon...and in the end only about 20 of them worked. Everything was done correctly, just ran out of room on the rom? Any attempt to fix it only resulted in more errors while building the rom. It'd be awesome if you could take a look and see what you find. If not, no worries! Not a lot of people working with tppcrystal251
So if you could implement your work into tppcrystal251pub, I'd be forever in your debt
I'll take a look at it when I can; I've got a lot of projects to work on. In the meantime, I'd love to see the sprites you've worked up if you're willing to share!
So I was able to get all the menu sprites to work
Even work for the overworld/daycare
Had some trouble porting the color scripts you used as well as from the prism github
I'll keep taking a look, but would you be interested in helping when you've got the time?
Last edited by rbroab (2017-07-26 01:13:13)
Sorry I missed this; been swamped with my own hack as well as other priorities. I haven't forgotten about you man, but I've got a lot on my plate!
First, I've gotta post a revision to the code from before; the previous code will work for almost everything...but if you have a full party and you catch a pokemon, the naming screen will inherit the shiny status of your last pokemon instead of the caught pokemon. Basically, the fix was fairly easy, but I couldn't really wrap my head around what was going on with the OG gender code so I just did things the way I know how:
GetShiny: ; wip ; MonType ;PARTYMON EQU 0 ;OTPARTYMON EQU 1 ;BOXMON EQU 2 ;TEMPMON EQU 3 ;WILDMON EQU 4 ld a, [MonType] cp PARTYMON jr z, .PartyMon cp BOXMON jr z, .BoxMon .PartyMon ld hl, PartyMon1DVs ld bc, PARTYMON_STRUCT_LENGTH ld a, [MonType] and a jr .continue .BoxMon ld hl, sBoxMon1DVs ld bc, BOXMON_STRUCT_LENGTH dec a .continue ld a, [CurPartyMon] call AddNTimes ; sBoxMon data is read directly from SRAM. ld a, [MonType] cp BOXMON ld a, 1 call z, GetSRAMBank .DVs ; Attack ld a, [hl] and 1 << SHINY_ATK_BIT jr z, .NotShiny ; Defense ld a, [hli] and $f cp SHINY_DEF_VAL jr nz, .NotShiny ; Speed ld a, [hl] and $f0 cp SHINY_SPD_VAL << 4 jr nz, .NotShiny ; Special ld a, [hl] and $f cp SHINY_SPC_VAL jr nz, .NotShiny .Shiny: ; Close SRAM if we were dealing with a sBoxMon. ld a, [MonType] cp BOXMON call z, CloseSRAM scf ; set carry flag ret .NotShiny: ; doesn't set carry ; Close SRAM if we were dealing with a sBoxMon. ld a, [MonType] cp BOXMON call z, CloseSRAM and a ret
Again, not the most efficient thing in the world, but it should work under all circumstances? I guess I'll find out eventually if it doesn't.
EDIT: Apparently right after catching a pokemon and sending it to the box, the party screen loads the wrong palettes. Argh.
Before calling GetMenuMonIconPalette in LoadPartyMenuMonIconColors, I had to update the MonType back to 0.
I struggled with a stupid bug for a while before I realized this code was okay. I had an NPC who would always use givepoke regardless of circumstance, and I noticed that if I had a full party and it was sent to the box, it wouldn't show as shiny even though I'd forced it in move_mon.asm. So just to verify, I actually looked at the pokemon that was sent to the PC, and they weren't shiny. But whether they were forced shiny or not, they all had the exact same DVs: 08 11 03 07 (and an HP DV of 07.) So, I guess the givepoke function was never intended to send pokemon directly to the PC, which is why every instance of it checks to see if your party has 6 pokemon. Things are starting to make sense now, haha.
Anyways, if it helps, here's my entire mon_icons.asm: https://paste.ee/p/x4DiO EDIT: Updated w/fix
It's basically identical to polishedcrystal's, except with the single shiny function, and the non-descriptive SPRITE_ANIM stuff.
..I still wish I could figure out that pokemon switching item color bug.
Last edited by ShockSlayer (2017-08-01 02:27:09)
No worries, you're good!
Is this the only script I need to make color menu icons work?
I've been working on using the code from Prism, but it's scripted so differently than TTPCrystal
Seems like it's structured differently as well. Plus, it has changes to files I don't even have haha.
But I'm about to try your code!
As best as I can remember it, there's a handful of places that call the icons, and then mon_icons.asm takes care of the rest. If you can still find where those places were(for example, the naming screen) then you can probably just call what's in there.
Well I appreciate the help, but I guess the setups are just too different. Going to build the rom comes up with a bunch of errors. Like depixel being an unknown symbol. Just things like that. I'm guessing the two games use the same functions, they're just under different names so it gets confused when calling for certain functions.