Hi Rick, just a quick note:
when you use:
[SerializeField] Color32 hasPackageColor = new Color32(1, 1, 1, 1);
the editor displays a “transparent” black color because the arguments of Color32 must be provided as byte values not as 0...1 values.
So in your case, to get a white color, you should write this statement:
[SerializeField] Color32 hasPackageColor = new Color32(255, 255, 255, 255);
Thanks.
Building on that, what was the use of Color32 (versus just Color)? I mean, I understand that in some cases it can be easier to work/do calculations with byte-values versus normalized floats; but in this particular case where we just assign the color to the spriteRenderer I didn’t have the impression that it really mattered. “It’s not quite as nifty” but maybe I missed his explanation of why it’s not quite as nifty?
Also, to make things a little more readable in this case, we can go with [SerializeField] private Color hasPackageColor = Color.white; (no rocket science, but still, may be a little nicer to read)
I actually found that Color32 didn’t work at all for me but using Color worked perfectly (I used Color.white like jelsayeh). Not sure why Color32 didn’t work but it seemed like the assign just didn’t work as I had Red as my hasPackageColour with alpha 255 (ie opaque red) but while I was getting the Debug.Log confirming package pickup the Sprite Renderer color remained white. Doing the exact same with Color worked though. I’m using Unity 2021.3.8f1.
I think it’s because Color32 values range from 0-255, while Color values range from 0-1. So when it’s Color32(1,1,1,1), it only raised the values up by 1 out of a max of 255.
If you want to make white with Color32 for example, you’d do Color32(255,255,255,255).
But white with Color would just be Color(1,1,1,1).
Here’s another quick example of both set as green:
Color32(0,255,0,255)
Color(0,1,0,1)