I wonder if it is at all possible to use the 3rd Aux button for a second main blade, Like for a dual blade setup. I have seen others online using a whole 2 proffie boards in one hilt for dual blades and I am kind of picky when I build my stuff. I have an issue with turning on both boards just to hear either off or not quite synced boot sounds. I would also like if somehow I could just code in the 3rd Auxiliary button like pow and aux are already in the config, To effect just the second blade and not the other. I couldn’t find much information anywhere about this topic.
Config code(Third Aux button for dual blade) so both blades have individual effects with clash/blast
1 Like
Not specific to 3rd button but the abilities needed for controlling 2 blades with one board is in OS7 already via my prop. I’m hoping to get time to set up the interfaces and code in Phase 3 of my Style Library.
1 Like
I feel like independent blade control is one of the must under-talked-about features from OS7.
2 Likes
Because I haven’t had time to really roll it out yet and setting it up is a tad complex so the interface needs to take a lot of guesswork out of it for most users. It’s on the list of things to do it’s just got a lot of pieces to make it all work together. Once the library and config helper are able to support it, it will get a lot more attention. The biggest hurdle with OS7 is we added SO MUCH, most users aren’t aware of a fraction of the potential now, hence the work to get it into the library where it’s visible and easier to implement. I feel like I have well over a year’s worth of stuff still waiting to get added, this OS almost feels like 4 full fledged versions released as one with what we fit into it…
1 Like
You guys are working too hard!
2 Likes
Thank you fett263! You are a really big help to the saber community.
Darth Maul is exactly how I would do it. The concept secondary blade igni/retract is perfect, Maybe in the future the 3rd aux button can be just for blast only on secondary blade effect.
1 Like
The issue is “secondary” blade isn’t actually something a button can “see”. The buttons (prop) doesn’t know what is wired to the board or what you call your first blade, second blade, crystal, etc. The buttons (prop) just activates effects or functions. How those are translated to what you see and where you see it is handled by the style code. So you couldn’t set a button to do Blast on a specific blade, it would do EFFECT_BLAST and whatever blade has style code for EFFECT_BLAST will show. That’s why we developed the “conditional” effects. The blades all receive EFFECT_BLAST but it only shows on blades that meet the condition, like pointing up. If you really wanted a 3rd button you could write a custom effect but it would be specific to your saber and you’d have to figure out how to style accordingly so that only the blade you want shows it. Its possible but a lot of extra work for no real gain. I developed everything to work on 1 or 2 buttons since that encompasses 99.9% of all builds, a 3rd button is rare so there isn’t a need or much support IMHO.
1 Like
Ok that makes a lot of sense. It does sound like it would be complicated now that you have explained it all. Conditional effects do the job well enough thank you for helping a fellow out.
MTFBWY
1 Like
I like guesswork and dabbling.
1 Like
You’d be the exception in my experience, this one took a LOT of trial and error, as Yoda would say “failure is the best teacher” there were many failures before I got it working…
1 Like
Just want to be sure… this is functionally being built into the OS so it’s extensible by any prop file, right?
It’s just blade style code really, so yes. In the prop you can make it control the blade and play ignition and retraction sounds.
The way I did it :
I built a style for the second blade that alternates 2 base colors; black for when off and the main blade’s base when on. This is triggered by EFFECT_USER4, which you’d tie to your button event in the prop file with something like:
// Turn Alt blade on/off using Aux2 button
case EVENTID(BUTTON_AUX2, EVENT_FIRST_HELD, MODE_ON):
SaberBase::DoEffect(EFFECT_USER4, 0);
return true;
Another toggle using EffectSequence<EFFECT_USER4 contains the pseudo ignition and retraction by having TransitionEffectL layers, each doing a TrWipe and TrWipeIn respectively, each triggered by USER4.
Then in the prop I set a bool called alt_blade_on_ to false at start.
This then toggles with each USER4 trigger and plays either out.wav or in.wav accordingly, which coincides with the Wipe animations in the blade style.
Effects on both the main blade and the second blade are set to have Scaled BladeAngle<> limits so that only the blade above the horizon will show clash, blast etc…
There’s a bit more to it covering scenarios like what if the main power button is used (should retract both blades if ignited) and such, but this is the general idea.
To play with this blade style:
Power on button won’t show anything because that’s when the main blade is turned on. Choose USER4 from the “Select More Effects” drop down menu, then the “Do Selected Effect” button to trigger what would be your button event in the prop (3rd button or whatever).
Secondary ignition and retraction will require my prop, the other props do not have proper support.
Ok, cool! Seems like there’s a good base there then. Would be neat to see this built in more proper in ProffieOS (an EFFECT_DUALBLADE and that kind of stuff?), and perhaps respective wrappers for bladestyles so it makes it all a bit cleaner, and easier to implement.
Maybe someday I’ll get a chance to look at the actual ProffieOS code so I can be more than just a good idea fairy 
That bladestyle you linked doesn’t seem to work for me… the link just ends up resolving to a Black bladestyle
That wasn’t my question. My inquiry was regarding whether or not such functionality was being properly built into ProffieOS to support the feature, rather than it being a set of hacks inside your prop only. Whether or not other props support it is irrelevant, it’s a matter of whether or not the framework has been built to make implementation by other props easy and consistent.
Many of the new features for OS7 are supported via my prop per discussions with profezzorn during development, they are not “hacks”.
Still not sure where this hostility towards my prop comes from but it’s growing tiresome, I’ve poured countless months of work into making my prop both feature rich and highly customizable.
The support for the features is built into the OS but during development, it was decided they were best implemented in my prop. Other props are free to add support but it is up to the individual prop creator to do so. In consideration of this I purposefully made my prop able to be highly customized and to utilize control options from the various other popular props at the time; sa22c and bc. I also built the config helper tool to make it easier for all users to convert to my prop if they wanted to take advantage of the new features that were specific to my prop. Now if someone wants to implement any of those features in other props I leave that to them.
So OS7 fully supports the features, however, they are only implemented in my prop.
I don’t think there’s any hostility. I read it as curiosity whether functionality was accessible in the OS itself or if it was only a feature of your prop file.
Which you answered above with “Other props are free to add support but it is up to the individual prop creator to do so.”
I understand from the point of view of not necessarily needing to use the Style Library site to build styles.
For example, if I just want a blade style with hard-coded colors and no need for future editability via Edit Mode or the workbench, but would like to take advantage of OS available features like Alt Sounds, or using tr sounds etc… the current option for a tool to build that would be Style Editor. However it’s up to the user to learn how the features work, how they can interplay with one another and so on since there’s no plug-and-play style assembly tool like the Library to do that.
The answer is, yes, the functionality is in the OS itself.
Accessing and utilizing it is going to require some homework.
That said, @Fett263 would you be open to someday having an option on the Library site to toggle whether the style gets built for use with Edit Mode, or for using just standard colors and non-dynamic elements but still retaining transition features and chained effects etc …?
Already built into the Color Selection, just choose “Fixed Color” in place of a Color argument for any style or effect 
By and large all tools for OS7 are being developed to provide as much flexibility and customization as possible to allow the widest range of users to be able to utilize.
It’s not hostility towards your prop, it comes from a place of concern in that building features into a prop file wouldn’t be sustainable or in line with the design philosophy ProffieOS seems to be trying to achieve. If you’re pouring work into all these features wouldn’t it be better to make sure the tools are there to make them easy to implement for props in general? That’d not only clean up your prop file (I’m not implying it’s “dirty”… follow my logic simply for the purpose of exemplification), but also encourage others to contribute with their own props, lowering the burden on you to have a prop file that does everything, as that seems to miss the mark of the point of having the option to switch prop files.
I also propose the idea of, given how much you’re throwing into your prop, maybe having multiple fett263 prop files? I’ve helped people who prefer your 5.9 prop due to it’s layout, but that’s not possible with your current prop.
I take issue with tools for ProffieOS really being tools for ProffieOS w/ the fett263 prop, as it limits the scope of the customizability which makes ProffieOS so powerful. IMO it should be the goal to, as much as possible, intentionally focus on techniques of abstraction and repurposability.
Basically, any new features that would impact memory are handled in my prop so as not to affect other props. Also, a lot of these features can’t work in combination with other features or require additional changes to controls in the other props, and in some cases, like bc’s prop, they co-opted features that were set up for other uses so there’s conflicts.
In addition, the style driven controls require the prop “gets out of the way” when the style is trying to change a control’s behavior. This was not easily implemented in other props for various reasons. Each feature would require the other props to make changes to other things they are doing, it was quite time-consuming to handle just in my prop - I’m not taking on other people’s props. Instead I made it so my prop could act like those other props while keeping the functionality wherever possible, so rather than trying to make multiple props act like mine, I made my one prop act like many others via defines.
I kinda feel like a broken record, I made my prop as customizable as possible in OS7 via defines, including changing and disabling features to take it back to OS5.9 (as much as feasible while still supporting the new capabilities) or to change button controls to work like the other props where possible or any other combination that was feasible to handle. I also built the config tool make it easy to both customize the prop but then to actually get the real buttons/control list you’re enabling via the defines and selections.
I propose that if there’s questions on how to change something in my prop you maybe ask the source instead of “guessing”?
You’re free to develop what you want, all of my tools work together to leverage what I’m designing. I can’t account for other props that do things vastly different or that don’t support things that I’ve designed or that haven’t been updated since OS5. The code is all there if someone else wants to take on the lift but I’ve been designing my stuff to make it easier for any level of user and to handle as much customization as feasible without impacting the overall usefulness of the tools.