Feature: ColorPicker

[benloh]

This adds a color picker to the wizard.

This is implemented via three additions:

1. GVar Numbers now have a setToColor method.
2. The Costume Feature now has a color featProp.
3. The Wizard view now shows a color swatch for the color value in both the line and slot editor views.

To Set a Color

1. Make sure your character has addFeature Costume
2. Set the color via a featProp call using the setToColor method, e.g. featProp character.Costume.color setToColor.
3. Click on the color slot to enable color picking.
4. Click on the colors watch to select a new color.
5. Use the sliders or click on a color to set the color -- the color will be immediately set and the numerical color value will also be immediately set.
6. Save the line, and Save to Server.
7. In Main, the character will have a color overlay.

setToColor method

Colors are implemented as GVar numbers. We added a new method to explicitly set the color. Under the hood, you could use setTo or setToColor to set a color, but with setTo you would have to enter a number, while with setToColor you would be able to use a color picker.

Implementing setToColor as a method for GVar Numbers allows us to keep the simulation and script engines fairly simple, with color setting added purely as a visual editor tool, similar to the way Comment Styles are implemented -- the simulation and script engines do not need to be modified to accommodate colors because they are operating as pure numbers.

color Costume Feature

There are many ways to set character colors (see all the featCall methods and featProps for Costume), each of which may override others. In general, we recommend using the featProp character.Costume.color setToColor approach.

Priority Order During each Costume update loop, colors are applied in this order:

• ColorScaleIndex -- if a ColorScaleIndex value is set, it will override any color featProp (used for Moths to set a graduated scale of white to black moths).
• color featProp -- If the color featProp is set, it will override other color featCall methods and featProps
• HSV values from featProp or featCalls -- Otherwise, the character will use the HSV values previously set by any featCall or featProps.

Note that you should NOT use agent.prop.color to set color as agent.prop.color is overwritten by the Costume Feature with each update loop.

Colors in Wizard View

Colors set by the setToColor method will now show swatches in the Script Editor Line vie as well as the Script Editor Slot Editor view.

Addresses #779

TO DO

• [x] Remove color from expert props/methods in slot editor
• [x] Update wiki/script reference

[benloh]

@jdanish This went quicker than I thought. Please give it a whirl to see if it does what you want.

We probably want to revise/refine/pare down all of the color-related methods.

[jdanish]

Looks great! It also appears that Graphing.meterColor can use setToColor and that also works. Awesome!

Edited: I was seeing some funny things that I think are user error and either way I can re-establish colors with this method and all is well.

[benloh]

I was a little worried about being able to differentiate decimal color values with hue/saturation/value values and whether we needed to add explicit naming (e.g. colorDecimal or colorHex) but I figured that'd be even more confusing for users.

Our colorization technique will result in some color shifting -- if the base graphic has a strong color it'll "bleed" through. Basically the coloring technique is to desaturate and set the color to 50% opacity and then overlay the intended color on top -- this way we retain some of the value (dark/light) characteristics of the image. Without that you'd be left with a silhouette with no discernible features inside.

[jdanish]

Yeah, this works and I think we are good to go once you finish that to-do :)

[benloh]

@jdanish So this is actually a little complicated and I could use your thoughts on what you would prefer.

Currently color is treated as an "Expert" prop that is translucent to discourage students from using it.

In fact prop character.color should not be used at all if Costumes are active because Costume calls/props will override character.color.

We can turn color into a normal prop so that it appears solid like costumeName. BUT because we have a fairly simple approach to determining whether a prop is expert or normal, if we enable color for featProp character.Costume.color, it would also be enabled for prop character.color, which is something we don't want.

The proper solution is probably to figure out how to add more sophisticated filtering (e.g. hide color from prop character.color calls, but NOT from featProp character.Costume.color calls). But this quickly gets hairy as we introduce a bunch of conditional coding.

So I'm thinking we have the choice to either: a) leave things as-is, assuming that for the most part students will be interacting with a pre-built line where character.Costume.color has already been selected and they won't even notice that it's an "expert" prop, or b) spend the time to build a more sophisticated way of determining what is and is not an expert

(We actually have a third "hidden" props list too that removes props from lists).

What do you think?

[jdanish]

Is it fair to assume that another option is to make it always solid, and the concern is that that encourages uses of character.color instead of character.Costume.color? I'd lean toward that for now as that'd mean that if they accidentally use it, no big deal, but the color will be solid in costume?

Of the two I'd rather it always be visible, and then not visible is a fine backup.

And then let's log an issue for making a more robust show / hide system for the next grant?

[benloh]

Thanks. True, we could also just leave it solid. Let me see if I can figure out a quick solution. If not, then we'll log it for the future.