OS7 Color Change Menu - fett263_buttons

ProffieOS
1

Hopefully this thread is created in the right spot…
I can’t seem to get the New Color Change menu to work properly. When I revert the color, it goes to the correct default blade color, some other color, or what was saved previously (I’m using the same blade style that has been customized in Edit Mode).

I’ve been playing with modifying the prop file. What I’m aiming to achieve, is having the REVERT button always go back to what is set in the config or Edit Mode, and not being able to save or overwrite that. It would then be nice to have the SAVE button either save or NOT save the custom selected color, based on a define (like how the previous color menu worked).

Does anyone have tips on what to code in the prop file to achieve this?

Thanks,
~Jeff

2

Revert is built into Edit Mode already, it returns to the last saved value prior to entering the Editing.

In any editing clicking Aux will revert or cancel the edit.

3

Ah okay. By default, when you save a new color in the Color Change menu, does that overwrite the value originally setup in Edit Mode (via WebUSB for example), or is the color saved to a new location so you can revert to your original value later in the future? Hope that makes sense.

4

If you have editable styles Color Change actually uses Color Editing (just all blades at once), so revert in either mode can only revert to the last saved colors. So if you edited in either and then went to the other to change, you can only revert to what was saved prior to entering that editing session.
If you want to completely return to original config value you would use “Reset Colors” in Edit Mode. This clears all “editing” done to colors in either mode.

5

Thanks for the help. I believe I modified the prop to achieve what I was looking for:

  1. I added code to use the previous Color Change mode - “ToggleColorChangeMode();” - since I prefer this because it’s much quicker to find a color and less twisting is involved.
  2. I simply disabled “current_preset_.Save();” on line 3216 so reset doesn’t save.

Now, I can change the color in the menu and it “saves” when I turn off the saber, go to new presets and back, etc… Then, if I want to revert to the original color setup in Edit Mode (webUSB), the AUX Revert Color in the Color Change Menu functions to call that back up and overwrites the custom color.

6

Ok, just be mindful

ToggleColorChangeMode()

This is altering Variation, not BASE_COLOR_ARG, so you may get odd color behavior depending on the style. Variation and color arguments don’t always “play nice” which is why my prop disables Variation if a style uses color arguments.

Pretty sure Variation is going to save itself regardless of the Save() for current preset. If it works for you, great but if your colors start getting wonky it’s probably because of trying to mix Variation and color arguments, they are very different mechanisms and not intended to be used together.

FWIW you can edit the ColorList to change the order or remove colors you don’t want :wink: Simply update the entries in ColorList here:

Combining Color List with ColorZoom you should technically be able to get to a specific color faster than the standard ColorWheel, the Color List is the main colors, it allows you to jump to exact colors instead of trying to “finesse” the ColorWheel to specific colors like Red, then ColorZoom lets you dial from the exact colors to variations of that color. This gives more control than the standard ColorWheel for getting to exact colors.
You can also put different colors into the ColorList if you wanted, they just wouldn’t work with Spoken Color List sounds.

7

Oh interesting - I never knew what variation did. That makes more sense now. Everything seems to be working correctly by altering that from what I can see. If there’s another way to achieve the “revert to set color value that’s unchangeable” I’m open to it as well.

I’ll give editing the ColorList a try too. My main issue was the amount of twisting involved to jump from one color to another to another; I felt like I was turning the saber over and over. Is there a way to just make it more sensitive, so fewer degrees of a turn to initiate the next color?

I’ll try playing with the list as well and ColorZoom as well :slight_smile:

8

I don’t know what this means, how can something editable be unchangeable?

The Color List uses the default twist_menu_ value for detection, this is a “goldilocks” number that took me a lot of trial and error to get working properly, you’re welcome to try adjusting it but it also changes values in certain sub menus and then needs to be reset so you’d have to modify all instances where it’s resetting to default throughout the menu but this isn’t the only value that impacts “sensitivity”.

In addition to the twist_menu_ value, the menu also intentionally ignores turns while the menu prompts play to avoid missed steps or having prompts play over each other and become impossible to decipher, so the “sensitivity” is a combination of the sound used to designate a turn and the angle that it’s detected at. Technically, if you try to turn while a prompt sound is still playing you actually need to turn the saber further than if you wait for the prompt to finish, because the turns are “ignored” during the sounds playing. If you have Spoken Colors, the time between turns is increased as the name of the color is a longer sound, typically, than the ccchange.wav, if you wanted it to be a little faster you can use a very short sound for ccchange.wav and that would “speed up” the delay and then if you wait for that sound to finish before each step you wouldn’t need to turn nearly as much.
And if you rearrange or trim down the Color List to colors you want to use you can further “speed it up” as getting through the list wouldn’t take as long, of course, editing the Color List applies to all Color Editing menus, not just Color Change.
The default twist_menu_ value is initialized here (but as noted above you also have to update all of the default resets throughout the menu as well): https://github.com/profezzorn/ProffieOS/blob/620d047b4bbe468cb10b234faa89938a344f5ead/props/saber_fett263_buttons.h#L6464

1 Like
9

Very comprehensive answer, thank you so much for taking the time to explain so well! That makes total sense on the menu and how it functions with the sound to not cause overlap - I am in fact using custom voice packs by NoSloppy, which are great.

For clarification on what I meant, I was saying the color originally set in EditMode would be unchangeable in Color Change Menu, to always allow the user to “revert” back to it - BUT - still having the functionality to change the blade color to something new in Color Change Mode, and storing that new color value in an alternate place, for example.

COLOR CHANGE MENU:
PWR - select new color (changeable)
AUX - revert to EditMode Color (unchangeable)

If I’m understanding correctly, my current method kind of does this - I’m not re-writing the color set in EditMode by disabling saving to it, and I change the color by modifying the variation (which you said may have unpredictable results based on the blade style). So I was curious if there’s a more elegant solution.

Thank you again for all that you do! Loving playing with the new beta OS

10

If you just want a temporary color change during normal operation build a Kyber Select (color options) or Multi-Phase Blade style in the library. There are several options, including those that use ColorChange with COLOR_CHANGE_DIRECT define for simple implementation. Those blade styles will temporarily change the color while the preset is active and allow separate editing via Edit Mode or ProffieOS Workbench of the selected Color Arguments.