Rigidbody rb = rigidbody ?? gameObject.AddComponent<Rigidbody>();

Why? For some reason, these built-in properties (such as rigidbody, collider, and so on), actual return an object of the appropriate type that evaluates to null, rather than an actual null reference, even when the component does not exist. For example, on an object with no rigidbody, this line will log true:

Debug.Log(rigidbody.Equals(null));

On the other hand, this example will throw a NullReferenceException, as expected:

Rigidbody rb = GetComponent<Rigidbody>();
Debug.Log(rb.Equals(null));

As such, you can rewrite the first example in the following way and it should work:

Rigidbody rb = GetComponent<Rigidbody>() ?? gameObject.AddComponent<Rigidbody>();

I’m working on some revisions to the Biped Editor, and am seriously considering committing some cardinal sins in the interest of making the code much easier for me to maintain and extend for future use. I’m looking at some technical changes that wouldn’t necessitate your updating in the middle of a project in production, but I wouldn’t want to prevent you from doing so if you wanted to take advantage of some new features. The main things I need to know right now are:

• Are there any public APIs on which your pipeline currently relies, apart from the automated setup and GetUp() methods? Considering how much coupling was in place already, I sincerely doubt it, but I also don’t want to push the big red button with little more than an assumption behind it.
• How seriously would it inconvenience you to have to fix a couple of compiler errors if you got a new update? (e.g., de-nested nested classes, changing method signatures that use bools to use enums, etc.)
• How seriously would it inconvenience you to have to redo automated setup?
• How seriously would it inconvenience you to have to re-link your get up animations?

Please feel free to contact me directly or to post here. Thanks!

Unfortunately, for a not insignificant portion of the population, the same GUI looks like this:

While much about this GUI looks really nice and is laid out well, those of you out there with colorblindness are seeing the same image twice, and are unfortunately missing some of the most important information these GUIs convey about the state of the character definition at a glance. It’s nice to have the detail text in the corner, but not really ideal.

It’s easy for us to get wrapped up in technical/architectural pedantry or in details of layout and workflow, so it’s important to also keep accessibility in mind when we design tools for others to use.