PALFX ISSUES
there is some palfx not working correctly when chars played at mugen and define palfx as black color it would be black but when chars add on IKEMEN the colors turn into white,, maybe that would be issues about RGB algorithm for Palfx
please, always provide links to problematic content and repro steps what has to be done for the issue to show up in game. Report like this is not enough to reproduce problem locally (we're not gonna test all kinds of palfx settings blindly to get the result you've mentioned)
uhh Okayy my bad... here is the code... in my opinion maybe its because "InvertAll" Contoller did'nt works or something missing logic with RGB color
[State 0,PalFXWiz] type=PalFX TriggerALL=1 trigger1=IsHelper(011) trigger2=IsHelper(012) trigger3=IsHelper(013) Time=99999 add=0,0,0 mul=256,256,256 color=0 InvertAll=1
its should be become black color in Mugen but when its Run by Ikemen Go it become white color which mean color not inverted
"SS from Mugen 1.1 Engine OpenGL"

"This SS from IKEMEN engine"

Link chars "just in case needed " https://bit.ly/3c8isSZ
tested this character in mugen 1.0 (after changing mugenversion and removing zoom sctrls to be able to load it) and the result in that engine is exactly the same as ikemen go:
https://user-images.githubusercontent.com/8928195/125634822-6f231f17-9aea-42ce-a477-f4d7a99aad29.mp4
From this I suspect it's likely that it's mugen 1.1 being bugged, not the other way around. But more investigation is needed to be sure.
the problem turns out to be in chanaged InvertAll behaviour. It seems like mugen 1.1's interpretation of invertall is to also invert the alpha (so add becomes sub and other way around), while in winmugen/mugen 1.0/ikemen go this doesn't happen. In this case implementing compatibility code that differentiate the outcome of invertall depending on character mugenversion may be needed.
Even knowing this, I'm still not sure how to implement it in source code to get the exact outcome. If someone would like to try to do it, here are modified character files that can be used for testing (state 0 with assigned 331 animation, applying PalFX) (All-Stars) Katsuki_Bakugo.zip
Ahh i see... for the sake of engine behavior, in my opinion, mugen 1.1 for palfx behavior its better than 1.0 .. outside of those there is so many chars who implemented palfx from mugen 1.1 behavior but back to developer ,, if ikemen dev prefer for 1.0 behavior so be it.. in this case maybe make coders recode their chars who implemented palfx from 1.1 to ikemen GO and adapt to it..
"mugen 1.1 for palfx behavior its better than 1.0"
I have to disagree with this. The way invertall works in 1.1 is broken, because it should affect only the colors, not the alpha. If you see the documentation, you will find there is no mention to alpha http://www.elecbyte.com/mugendocs/sctrls.html#palfx
So Ikemen is acting right on this one.
"mugen 1.1 for palfx behavior its better than 1.0"
I have to disagree with this. The way invertall works in 1.1 is broken, because it should affect only the colors, not the alpha. If you see the documentation, you will find there is no mention to alpha http://www.elecbyte.com/mugendocs/sctrls.html#palfx
So Ikemen is acting right on this one.
This thread is old but since this issue has become relevant again I just wanted to say that this is also how I feel. If invertblend is to be a separate parameter, then I think invertall should just do what it says it does. For Ikemen/future characters I mean. For Mugen characters it could default to however that specific Mugen version worked.