Play Force Effects in Order?

Simple question - is it possible to play force effect wavs in order?

I know the fett button system has some quite sophisticated features related to this, but many of my customers are new to sabers and so want a super-simple button setup (sorry Fernando, hope you don’t mind). So I ws just wondering if there’s a simple line in the OS somewhere that will play effects in order rather than randomly.

I found this in saber_base. Am I right in saying that if I remove the ‘R’ just before (EFFECT_FORCE) that it will stop playing them randomly and play them in order? Or would that just play the first wav in the folder every time you hit the button?

  static void DoEffectR(EffectType e) { DoEffect(e, (200 + random(700))/1000.0f); }
  static void DoBlast() { DoEffectR(EFFECT_BLAST); }
  static void DoForce() { DoEffectR(EFFECT_FORCE); }
  static void DoBoot() { DoEffect(EFFECT_BOOT, 0); }
  static void DoPreOn() { DoEffect(EFFECT_PREON, 0); }
  static void DoBeginLockup() { DoEffectR(EFFECT_LOCKUP_BEGIN); }
  static void DoEndLockup() { DoEffect(EFFECT_LOCKUP_END, 0); }
  static void DoChange() { DoEffect(EFFECT_CHANGE, 0); }
  static void DoNewFont() { DoEffect(EFFECT_NEWFONT, 0); }
  static void DoLowBatt() { DoEffect(EFFECT_LOW_BATTERY, 0); }

Is there any other simple way of achieving this?

Thanks in advance.

I made my prop super customizable in OS7 via defines, you can enable or disable features pretty easily with the config helper tool. :wink:
You can get down to a pretty standard set up but still support advanced features if needed and the tool will provide a custom Button/Control List based on the selected features which you can provide to your customers. Just watch the video and read through the options.

No, the ‘R’ is random for effect position not sound. All sounds are still randomly selected for EFFECT.

Why is it you want them to play sequentially? My prop plays quotes sequentially, you can set the quote player to default on with this define if that’s what you are after.


I hear you Fernando, and your config generator is indeed incredibly comprehensive. But the kind of things I wrestle with are features where, for instance, doing something with the hilt pointing down does one thing and pointing up does another. I’ve watched new users struggling with even simple button combinations and gesture controls, hence I like to pair things right down. Your systems are amazing and so incredibly full-featured that in some ways I think new users need to upgrade to them when they’re ready. Of course more experienced buyers often specifically request your setup which I obviously build in for them. But for first-time buyers, I like to start from a point of simplicity.

I also tweak my prop so there is one rule for things, and hence less to remember. For instance, with the prop I use, a double click of main ALWAYs plays something - with blade off it’s a music track, with blade on it’s a character quote (force effect). One rule. Equally a single click of main ALWAYS lights the blade - short click lights it with sound, long click lights it mute. One rule.

But of course the trade-off is I can only squeeze so many features into that style of operation, so I recognise it is a balance.

As for wanting to play wavs sequentially, I’ve just had someone request some fonts that come with a huge number of wavs broken down into episodes, and since the guy is heavily into saber quotes, it occurred to me he could almost watch the relevant episodes and play the quotes from his saber at the same time. :smiley:

I mean that’s pretty much how my prop runs, similar controls when on or off (within reason) to keep it intuitive, support for sequential quotes, etc. Kinda seems like you’re trying to re-invent the wheel from where I’m sitting, but to each his own.
I designed the OS7 prop based on a lot of feedback from both users and installers on wanting more simplification but still supporting the features that make users pick a Proffieboard in the first place and I added support for controls from the other props like sa22c and bc so that users could keep controls they were familiar with and still get the features in OS7 to run.

But if you want to continue to reinvent the wheel have a look through my prop for how I run quotes as I already built and handle the exact scenario you’re asking about :wink:

I don’t really see it as re-inventing the wheel, but I can see why you might view it that way.

And yeh, I did look through your prop and I thought I’d found the bit that handled it, but my coding knowledge is far too limited to be able to stitch it into mine and make it work (I did try but to no avail).

Thanks for your thoughts on it anyway. Appreciated as always.

I still think you could still just use my prop with necessary defines easier, especially if your customers want to use OS7 functionality in their styles but this is what you’re after, you need to call it before you trigger EFFECT_QUOTE.

1 Like

I don’t mean to knock Fett’s prop (Truly, I agree he has some of the coolest bleeding edge features in sabers), but I personally am a fan of SA22C’s prop if intuitiveness is the goal. It lacks a lot of Fett’s features, but I prefer using it for the controls, maybe test it out and see how you like it?

Somewhat unrelated, but I thought I would throw it out there since you asked. (Trying other prop files in general might be a good idea, they all have their own take on UX)

I merged sa22c’s controls into mine in OS6 as sa22c was no longer able to update, maybe have a look again. As I noted earlier I made my prop extremely customizable in OS7 based on feedback from many sources. It can be as simple or feature-filled as you desire just by using defines, the config tool walks you through all of the options you can enable or disable as well as control swaps from sa22c or bc’s props.

My goal in OS7 was to let users get access to the new features that only run in my prop but keep familiar controls from the other props if they wanted. The config tool was built to make facilitating all of the customization easier AND it will generate a custom Button/Control List based on the selections made :wink:

I’ve looked through all your defines when creating my configuration tool, I know it has options to change some of me controls to the way they work in other props, but at its core the controls are still yours, not the same as the way the other ones work.

I think part of that might be just how much you have in your prop. You’d have to have the option to completely disable features to actually change the way it functions to mimmick, for example, sa22c’s, which it can’t do, or if it can it’s not well documented.

Examples? I went through most of the controls, there were very few I couldn’t make work. If you have specifics I can explain or consider, everything that was brought up prior to OS7 was handled plus I reviewed the other props on my own to see what might need to be handled.

In a few cases, the ways something was done in older OS versions no longer made sense with the new capabilities, but by and large I tried to fit everything in that was asked or that I came across that wasn’t some “hacky” way to accomplish things built specifically into OS7 to handle. Plus, a large portion of sa22c’s prop in OS5 was just using code from straight from my prop.

No offense intended, but considering I’m still actively building out functionality for OS7 I don’t think you actually understand everything in my prop or how it’s intended to interact with the new style capabilities to enable controls inside of styles. There’s still a lot yet to be released, it’s probably better to ask the guy who made the prop than just guess and assume you know it all, don’t ya think?

I’m saying I don’t like sa22c’s prop because it has lots of features and customizations, I like it because it doesn’t have a lot of features.

Is there a way to outright disable the need to be pointing a certain direction for controls and things like that?

My suggestion would be a way to scale everything back. Your prop has a lot of cool features, but I feel like it suffers from feature creep, just too much going on to be intuitive.

Everything’s intuitive to the person who made it is kinda my point…

You can disable a lot, be helpful if you give examples. I spent months implementing a lot of ways to customize the prop based on feedback, both to simplify and add support for all of the new capabilities we added.

If you have examples I can direct you, otherwise it just sounds like you’d just like to guess what is and isn’t in my prop.

I also poured months into the config tool to make it easy for users to generate the specific controls they enabled via those customizations because there’s so many possibilities now, so I already considered it’s more intuitive to me since I made it and I built a tool, that I don’t need or use, to help users.

Point is, I actually do know everything in my prop and how to do it, so if you give me specifics I can answer I don’t have to guess and make broad generalizations that aren’t entirely accurate…

My example is to make it function how SA22C’s does. SA22C’s prop doesn’t rely on, as the original poster stated was a UX issue for his particular client initially, orientation of blade for any of the commands.

I’m trying to directly address an issue which Sabersense brought up…

I’m not attacking you, I’m not saying you should do more, I’m in the same boat as far as trying to create what I did to help others, I’m simply offering an alternative, that’s it.

If you want an example, how would I remove the dependence on orientation for commands?

I am just observing here, not sure how I can help if at all.
As a 3rd party, it sounds like this is what @ryryog25 could use as an actual example.
Such as:

Next Preset = Long Click PWR (parallel or up)
Previous Preset = Long Click PWR (pointing down)

becoming something else like

Next Preset = Long Click PWR
Previous Preset = Double Click PWR

Which would cause an obvious conflict with

Start / Stop Tracks = Double Click PWR (pointing straight up)
Track Player = Double Click PWR (parallel or down)

so the issue here is @ryryog25 is talking about remapping a bunch of controls, which may be not possible due to a feature that is supported, but possibly not desired.

He’s proposing something like if there’s a define to not use Track Player, then it would remap the Prev/Next preset controls as above.

Which is a ton of work, if even possible, and sort of why having options to use other props exists in the first place.

1 Like

Depends on 1 button or 2 button, but sa22c’s prop certainly uses up or down in some instances, just read the controls.

I didn’t say you were attacking me, I said you were making mis-statements about what my prop can do, you brought up sa22c’s prop as an alternative but I merged many of those controls already into my prop.

Will depend WHICH control you’re referring to. If you didn’t want to use pointing down to Toggle Force/Quote controls I already handled.

Add this define:


this will remove the pointing down toggle and make the Force control act on it’s own

Then add this define:


this will open up customizable control slots to put Quotes into.

Then go to my OS7 library and generate styles with “Next Quote” on whichever of the Special Abilties you want to have the quotes triggered from and it will handle playing quotes sequentially for that preset without interfering in other presets.

Look, I get that some users say they want a very specific way to control their saber BUT in my experience except for a handful of advanced users, many users start out one way and then want to add new features and especially in OS7 a custom built prop will most likely be missing support for many of the new features, but mine isn’t. I realized this during development and took in a bunch of feedback to make my prop able to fit many (not all) needs of users. If a user is given a custom prop and then tries to switch to my prop it is harder on them in my experience so then they have to choose to forego new features, learn more intensive programming or relearn ALL of the controls. I wanted to give an alternative and provide a prop that you learn on that can expand with the user’s desire to add features.

In the end, if you want to build your own prop and reinvent the wheel that’s the beauty of Proffie. What I’m trying to do is educate you and others on what is actually possible in my prop instead of having people put out misleading information based on incomplete or out dated knowledge. I want to make Proffie and EVERYTHING it can do accessible to users but when users have completely different starting points it makes it harder to build onto, my prop was designed to “grow” and evolve with current and not yet released features.

This is exactly what I mean, yeah, you hit the nail right on the head.

1 Like

I’m not saying my prop can do EVERY feasible control, I’m saying I tried to make accommodations for simplifying and using other specific popular controls from existing props to help users ease into OS7.

There are so many new features that will only run in my prop for OS7 I can’t list them all, so yes there are other props and users can build their own with all the specific controls they want but they will also most likely not be able to take advantage of many of the new features without having to do a ton of additional programming. I’m simply saying, I made it so my prop can be simplified and/or adopt many of the controls from other props like sa22c and bc, WHILE still supporting OS7s new features and abilities, which was no small feat.

But sure, if someone has a hard time figuring out up vs. down when trying to control their saber then I wouldn’t tell them to use the more advanced stuff anyways :roll_eyes:

For the record, Track Player disables itself when there’s no /tracks folder in the active fonts or only one track is in the folder :wink:, so if users don’t want Track Player just update the font, there’s no need for a define to disable it.

Just use Scroll Presets control, then the user can simply turn forward or back through all of their presets, even simpler than remembering separate controls :wink:.