Specifying Blade Style Variations...?

ProffieOS
1

I have a simple blade preset question that I suspect may only have a complicated solution, in which case it’s not worth it, but I’ll ask just for my own interest if nothing else…

Suppose I have this simple bladestyle which has 12 user-selectable colours in it:

StylePtr<InOutHelper<SimpleClash<Lockup<Blast<ColorChange<TrInstant,Cyan,DodgerBlue,Green,Rgb<28,255,28>,Red,Magenta,Rgb<255,80,154>,Yellow,Orange,Azure,DeepSkyBlue,Blue>,White>,AudioFlicker<Blue,White>>,White>,300,800>>()

With this style there are 12 colour variations. However what I really want is that bladestyle to be added to various different fonts, but to have a different starting colour (variation) depending on the font it’s used with.

The most obvious way to do it is like this:

Cyan Default:
StylePtr<InOutHelper<SimpleClash<Lockup<Blast<ColorChange<TrInstant,Cyan,DodgerBlue,Green,Rgb<28,255,28>,Red,Magenta,Rgb<255,80,154>,Yellow,Orange,Azure,DeepSkyBlue,Blue>,White>,AudioFlicker<Blue,White>>,White>,300,800>>()

Red Default:
StylePtr<InOutHelper<SimpleClash<Lockup<Blast<ColorChange<TrInstant,Red,Magenta,Rgb<255,80,154>,Yellow,Orange,Azure,DeepSkyBlue,Blue,Cyan,DodgerBlue,Green,Rgb<28,255,28>>,White>,AudioFlicker<Blue,White>>,White>,300,800>>()

DeepSkyBlue Default:
StylePtr<InOutHelper<SimpleClash<Lockup<Blast<ColorChange<TrInstant,DeepSkyBlue,Blue,Cyan,DodgerBlue,Green,Rgb<28,255,28>,Red,Magenta,Rgb<255,80,154>,Yellow,Orange,Azure>,White>,AudioFlicker<Blue,White>>,White>,300,800>>()

etc. etc.

But that feels a bit clunky. It also gets tricky if I want to add 12 colours to effects to avoid things like a yellow clash on a yellow blade.

So I was wondering if there’s some whizzo parameter I can add to each blade preset telling it which colour variation to use as its default until the user switches away from it on the buttons, at which point the change would be stored in the presets.ini as normal.

As I say I suspect any solution would involve mountains of work so isn’t really viable, but I thought I’d ask on the off chance.

:slight_smile:

1 Like
2

I mean, that’s what Color Editing and Style Arguments were added for, but they don’t have limits on number of colors. If you use Editable Styles with Edit Mode or Workbench you can adjust the colors individually for ALL effects and not have to worry about trying to synch up changes across multiple effects via multiple large ColorChange<> options. On top of specific colors in the Color List for my prop users can access ALL colors for ALL effects individually with one of the editing options or by simply applying the Style Arguments via the Config Helper Tool.

And with my Config Helper you can apply different starting colors to the same style in multiple presets via Style Arguments for any and all effects, see here (video demos how it works): ProffieOS Config Helper Tool v3.0 Introduction (OS7 Feature Support and Config Optimization)

3
4

Yes, that’s what I’m referring to, but to clarify style arguments only work with Edit Mode (Color Argument) styles, they do not work with Variation. So the styles he original refers to can not do this.

The arguments also have to match the style used, so my config tool reads the style to see which arguments exist to ensure they are correct :wink:.

5

This exists for style arguments, but not for variation unfortunately, although I suppose they could be combined by using something like:

ColorSelect<Sum<Variation, IntArg<1, 0>>, TrFade<100>, color, color, color>>

Then you can use StylePtr<> arguments to specify the IntArg<> in question, like:

StylePtr<....>("1")
StylePtr<....>("2")
StylePtr<....>("3")
6

Although it might be better to use an argument that is normally numerical, like 3 (STYLE_OPTION_ARG)

IntArg<STYLE_OPTION_ARG, 0>

and

StylePtr<....>("~ ~ 1")
StylePtr<....>("~ ~ 2")
StylePtr<....>("~ ~ 3")
7

Sweet. That works fine, but with the offset, first color = 0, right?

So…

StylePtr<ColorSelect<Sum<Variation,IntArg<STYLE_OPTION_ARG, 0>>, TrFade<100>, Red, Green, Blue>>>("~ ~ 2")

Result: Blue

8

Yes, that is correct.

9

:open_mouth: :open_mouth: :open_mouth: :open_mouth: :open_mouth: :open_mouth: :open_mouth:

Guys this is absolutely incredible! Thanks so much. I won’t pretend I fully understand how it works - I’m going to need to sit down in a very quiet room with no distractions to go through it a few hundred times - but it seems you’ve absolutely nailed it!

:muscle: :pray: :clap:

Thank you so much - I’m in all of your debt as always. :pray:

10

Is it significant how many of these symbols are inside the brackets that specify the variation? (Sorry, I don’t know their proper name).

11

~ (tilde) is used as a placeholder for un-specified parameters.

Let’s say you had three parameters, and you wanted to set them to 5, 10 and 20, then you would just do: “5 10 20”. If you wanted to leave the last parameter unset, you could just skip it: “5 10”. However, if you wanted to leave the first parameter unset you can’t just skip, as “10 20” would set the first parameter to 10 and the second to 20. However, you can use tilde (~) in it’s place: “~ 10 20”. Now the first parameter is unset, the second is set to 10 and the third is set to 20.

1 Like
12

Many thanks Prof. That makes perfect sense. Thanks for clarifying. :slight_smile:

The bad news is I tried loading the setup onto a hilt today and although it works perfectly on the style editor, the colour change feature seems wrong somewhere.

This video shows how it is. It just flashes and bangs in various colours when you try to enter colour change. I’ve tried making the TrFade 1000 instead of 100, but it makes no difference. The second version on the video is how I thought/would like it to work.

Any thoughts on a fix gratefully received, though I realise this whole concept is kind of going round the houses so if we’ve reached an impasse then c’est la vie. :slight_smile:

This is the bladestyle:

StylePtr<Layers<
ColorSelect<Sum<Variation,IntArg<STYLE_OPTION_ARG, 0>>, TrFade<1000>, Cyan,DodgerBlue,Green,Rgb<28,255,28>,Red,Magenta,Rgb<255,80,154>,Yellow,Orange,Azure,DeepSkyBlue,Blue>,BlastL<White>,LockupL<AudioFlicker<Blue,White>>,SimpleClashL<White>,InOutTrL<TrWipe<300>,TrWipeIn<800>>>>("~ ~ 2")
13

DId you delete any existing presets.ini file?

14

ColorSelect<Variation,...

is a HandledFeature, you’ll probably need to mod so you can trigger ColorChange.

1 Like
15

Good point.
We can work around that like this though:

StylePtr<Layers<
ColorSelect<Sum<Variation,IntArg<STYLE_OPTION_ARG, 0>>, TrFade<1000>, ColorChange<TrInstant,Cyan>,DodgerBlue,Green,Rgb<28,255,28>,Red,Magenta,Rgb<255,80,154>,Yellow,Orange,Azure,DeepSkyBlue,Blue>,BlastL<White>,LockupL<AudioFlicker<Blue,White>>,SimpleClashL<White>,InOutTrL<TrWipe<300>,TrWipeIn<800>>>>("~ ~ 2")

Basically, we use a ColorChange with a single color somewhere, this makes variation stepped instead of 0-32768, and it should work.

1 Like
16

So which parameters are omitted here?
Are we going by this list, and they’re always designated in this order?

BASE_COLOR_ARG = 1, // Primary Base Color
ALT_COLOR_ARG = 2, // Alternate or Force Color (free-use)
STYLE_OPTION_ARG = 3, // Style Option
IGNITION_OPTION_ARG = 4, // Ignition Options
IGNITION_TIME_ARG = 5, // used in IgnitionTime alias
IGNITION_DELAY_ARG = 6, // Ignition Delay Time
IGNITION_COLOR_ARG = 7, // Ignition "Power Up" Color

and therefore a designated Red base color, an omitted Alt Color, and designated Style option be something like
("65535,0,0 ~ 2") ?

17

Arguments can be used in any order you choose.
However, the convention is to follow the list, and doing so will make it work properly with Edit Mode.

Correct.

1 Like
18

You guys absolutely, totally and completely rock!
:tada: :sparkler: :fire: :muscle: :clap: :pray: :ok_hand: :smiley:
That has indeed nailed it! It’s working perfectly and is going to make certain processes for me so much quicker and easier. Incredible work! Thank you all again so much! I’m forever in your debt!
:pray: :pray: :pray:

2 Likes