ZDoom

It's trickier. The blood translation needs to carry a color along for colorizing decals and particle blood.

Considering translation is also a translation and it's not readonly and it can be transferred between actors through a direct assignment, I don't see why the same can't be done with bloodtranslation / bloodcolor.

I currently have to do some hacks to pass it around.

Since blood color is a translation, IMO it makes sense to add the same editing features available for regular actor translations. An A_SetBloodTranslation function would pair well with trnslate.txt, and making the bloodtranslation property writable will enable copying blood translations between actors.

That sounds like a good reason!

Now that I think about it what I'm trying to do could probably be better done by using a custom blood actor that changes its own translation (or sprite) depending on what spawned it.


[s]That said... [i]is[/i] there any way for a blood actor spawned by a regular hitscan or ripper (not A_SpawnItemEx) to point to the actor that bled it?[/s] Nevermind, found it on the flags wiki page:
[quote][+PUFFGETSOWNER] can also be used on Blood: in that case the actor that is bleeding will be considered the Blood actor's target (by default player is considered any non-friendly actor's target). If A_FaceTarget function is added, the Blood actor will face the bleeding actor.[/quote]

Bloodcolor is locked because it isn't a color, it's a translation. Simply setting it won't do any good.
Bloodtype is a class property (i.e. cannot be set per actor), otherwise they'd inflate the actor structure by another 24 bytes (there's 3 class pointers here) for a feature that at the time of implementation was not seen as something potentially changeable.

Why are these even locked?