Law corruption format variations

[LordCarve]

About the PR

In the past (read: now), corrupted laws were always ALL CAPS.
Community spoke out that this is a feature, so I embraced this view, and took it to a new extreme.
Now it's a fully grown-up feature.

Say hello to:
Corrupted law format variations!

Why / Balance

A deep dive into why the community likes and insists on keeping the all-caps corrupted laws revealed a very interesting point:
How the law string is presented to the user - its formatting - has meaningful impact on its interpretation.
I found this interaction particularly interesting, because laws are RP rules, but at the same time they are subject to interpretation, and as long as they adhere to the wording they are fine.
Keyword: wording. So if we were to change something that's not wording, for example format....

Add personal subjectivity to the mix and you have a flavorful niche that exists entirely in the realm of subjective interpretation.
THIS IS GREAT (see what I did there with the all caps?) so I decided to expand on this to make it more robust and flavorful.

The text of the law remains the same. But other aspects of text's presentation can now be different. Does this change the meaning? You decide!

Would you interpret an orange-colored law differently?

Maybe! But you must still strictly adhere to its meaning (per rules).

What does it mean for your law to be cyan?

Is this a code yellow alert?

And don't forget that-

This creates flavor where none existed, and meaninfully expands the "laws are subject to interpretation" without rule-breaking. I absolutely love that.

Technical details

Corrupted silicon laws (ion storm & salvaged cyborgs) now on top of their randomized wording (unchanged) additionally have randomized format corruption. This can be:

• all-capitals - this is the OG variation. It is still there as before, but won't always be there;
• not corrupted - property capitalized, just like factory lawset laws;
• colorized - the law string as seen in the state laws UI is colored a random color (from a yaml-defined pool).

Nitty-gritty technical details

• refactored SiliconLaw to support format corruption;
• added (abstract) prototype type LawFormatCorruptionPrototype with three variations: OG all-caps, no corruption, and proof-of-concept random-color;
• took extra effort to make everything fully extensible both in terms of exposing everything to yaml (weights, color pool) and in code;
• cleaned up and optimized Laws UI (which in retrospect I regret doing because of how long it took for how tiny of a gain it ended up being - should have settled on just optimizing frame update and calling it a day)

Related systems testing

• works for both IonStorm and StartIonStormed silicons
• setting laws via Admin Edit Laws UI works (that UI needs a revisit badly, but it's outside the scope of this PR so I just "made it work" for now)

Accessibility

For our colorblind friends I am pleased to note that the main focus of this feature is 100% subjective and thus fully opt-in. If you cannot tell that a law is a different color - nothing is lost! Your interpretation of said law is still 100% your subjective take on it, and that remains unchanged regardless of how differently you perceive its color.

I do have a small worry regarding accessibility and that is the possibility for the colored text to blend-in with the background in some types of color blindness. The colors in this PR were selected from a high-contract pool, but I cannot verify if this is sufficient. If there is an issue please let me know

On a small note - this feature initally included a "readout mode" toggle that allowed the player to view the raw text of laws, stripped of flavor formatting. It was removed due to popular demand. It can be re-add it if needed. That would completely solve all accessibility problems this feature might have.

Future additional content to this feature?

1. Multiple format corruptions applying to the same law (i.e. colored and all caps) - this is currently not possible, but may be extended in the future.
2. Adds the possibility of a future feature of soft laws corruption (no wording changes) - if you hit a borg on its shiny little robot head a bit too hard it may have its laws soft-corrupted (just flavor formatting - no change in meaning).
3. SNEAK PEAK - accented laws!

(sneak peak only - NOT part of this PR - was planned but got cut down due to rigidity of how accents are currently implemented)

Requirements

• I have read and am following the Pull Request and Changelog Guidelines.
• I have added media to this PR or it does not require an ingame showcase.

PS

This space reserved to remind cyborgs that

and to never forget that

Changelog

🆑 Carve

• add: Corrupted silicon laws now come in various flavor formats.

[LordCarve]

I don't know how to make linter happy. I have not found any examples of a top-level abstract prototypes anyhere else in the code.

[iaada]

I love the idea, but I think the prototype implementation needs work.

[iaada]

This isn't the way to implement these prototypes. EntityTablePrototype is a good example. It's serves as a simple container for EntityTableSelector which is an abstract class and implements the actual code.

Suggested change

	- !type:NoFormatCorruptionPrototype
	type: lawFormatCorruption
	id: NoFormatCorruption
	- type: lawFormatCorruption
	id: NoFormatCorruption
	format: !type:NoFormatCorruption

[LordCarve]

Disappointing because this is the cleanest use of prototype type polymorphism and it works in game flawlessly.
The only problem that seems to block native support for abstract prototype types is that they get: (a) registered as regular prototypes for testing due to [Prototype] and (b) omitted for prototype type registration due to [Virtual].

Unfortunate because as I said it works perfectly well in-game, and it's just a matter of connecting some dots. Sadly adding to ignore in EntryPoint.cs solves only problem (a), so (b) is still an engine-level blocker.

Time to make that workaround sigh

[iaada]

This isn't necessary if law corruptions get moves to shared. Moving them to shared would have additional benefits such as allow for SiliconLaws to contain the corruption prototype directly instead of an altered string.

[iaada]

I think this should be marked as a TODO add format corruption support instead of an outright denial of it.

[iaada]

I'm not sure I like this implementation. It forces you to recreate the string every time you want to change it, which leaves you vulnerable to arbitrary changes and makes multiple corruptions messy. If this was a List<ProtoId<LawFormatCorruptionPrototype>> you could stack corruptions easily, and it would be much easier to "pre-corrupt" laws through yml.