While I don't have the original code, it's something along the lines of this:

    // for each palette entry:
    pal.r = pal.b = pal.g = (byte) (0.299 * pal.r + 0.587 * pal.b + 0.114 * pal.b)

So I was able to create all the bits necessary to introduce the palette change in a similar manner (3x256 changes) on the triggerz and at the moment of truth instead of grey I got a GREEN and PURPLE fadeout (I wasnt sure if you meant rbg or rgb for the ratios so i tried both).

I also tried 128 across the board for grey, and it just made a dull fade which may be the best I can do with my method.

I think it may simply be because rather than have palletes controlled by rgb, I load predrawn sprites using sfml's sprite and texture classes. So the default rgba is 255,255,255,255 - so I have a sidequest to figure out the RIGHT WAY of applying rgb changes to predrawn sprites.

It may very well be a simple matter of "sfml does it differently" or perhaps having grey variants of all sprites and toggling. I feel there has to be a way to accomplish the fade to grey programmatically. Fun little dive tho! I'll have to post an update when I figure it out.

From my recollection of doing fun palette stuff back in the DOS VGA days, I'm betting it was more like:

    pal.r = pal.g = pal.b = (77 * pal.r + 150 * pal.g + 29 * pal.b) >> 8;

I havent gotten behind the console, but thats like, exactly what I was gonna do, except precompute like 5 or 6 tween values for r,g,b between 255 and the target for greyscale.

But rather than do that and cache them for timing triggers, I kind of like the scaling down by multiplication approach.

Edit: manipulate the rgb values that is - I wouldnt have converged on those hard values on my own.