Skeetendo

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.

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?

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!

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)

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.