reimplement: SHC_3BB0A8C1_0x00479B70 100%

[TheRedDaemon]

I tested the bitfield theory once again and was able to achive the 100% with it, while still having somewhat readable code.
I am now rather certain that they used a bitfield for this. Managing this by bit-operators would appear to be too much of a hassle to be worthwhile, in my eyes.

[gynt]

Great find! Ghidra has improved bitfield support and I think you tested this too. Can you confirm Ghidra's decompilations work out all right, or does the code get uglier?

Internally I will have to provide an exception to overwriting your customised .hpp file.

[TheRedDaemon]

When I tried creating one, everything that was not straight forward became uglier, sadly. No idea if I did it properly, though.
One check and one direct assign was less ugly, but stuff like setting one value to 0, which is implemented by value & 0x7fffffff for example, all used Ghidra support functions.

[gynt]

Wht is your opinion on a split situation in which we don't update Ghidra upstream but do use the bitfield in this repo? In essence, it means ghidra exports will never override the bitfield .hpp file ever again. The annoying thing is to remember that this exception exists so when looking at Ghidra code you should translate it into (the much easier) bitfield access logic.

[TheRedDaemon]

I think that would be fine. We could change the header in the file accordingly and when trying to reimplement, stuff will break, so we will notice rather quick.

If they improve it further, one day we might be able to add it to the export again.

[gynt]

Resolved in a1971f3