I was saving that for OS9, OS8 is the TV remote option. 
No hostility, although calling all of the time, effort and work I put into my prop a “hack” isn’t a good way to endear yourself to someone, just saying…
I get you built a tool and are proud of it (which you should be) but I’ve been building tools and videos and documentation to help support the ideas I brought to the OS since OS2.6CC. I already planned out all of my tools for all users and I made them all to work together to help users get the most out of the OS. I already put the time into my tools and am continuing to update them, I’m not looking to duplicate or redo my efforts in someone else’s tool.
Back to the original topic, if you can specify what about my prop isn’t working or users don’t like I can probably elaborate a bit. As I’ve said, ad nauseum, I made my prop super customizable already based on the feedback I got from OS6, some of the controls I introduced in OS6 didn’t go over as I thought, so I made a bunch of new defines and other changes to address everything that I could in OS7.
There’s a tiny handful of things some users wanted that either majorly conflicted with other important controls/features or that would severely limit what the prop could do (we do have a finite amount of controls to do almost infinite things with). I take user feedback into account whenever possible, but I also weigh if it’s something one person wants versus something many people could use. I also know I spent a ton of time mapping out how everything could work together while keeping it intuitive for the masses.
I also proactively looked into controls in sa22c’s prop and bc’s prop and migrated them into mine via defines because I knew those props wouldn’t be able to support the new features and I didn’t want to isolate users who were using other props, I wanted my prop to be as “all encompassing” as possible. But there are limits, in which case, there’s a small handful of controls that are different. If those are gating items for a particular user they have the option to learn the new control (I provide support, custom print outs, etc to help) or learn to code their own prop (which is what I did). I feel like some people think making a prop is “easy”, it’s one of the hardest things to do, you have to account for how everything inter-relates and make sure one control doesn’t interfere with something else and it requires a ton of planning and testing. Then when you add defines and customization into the mix it compounds the complexity exponentially. And the more features I added the more complex things got, so finding the balance was already a ton of work.
So if you have specifics on why you’re so opposed to using my prop I’ll have another look at it, or explain the reasoning and alternatives (there’s a lot of custom combinations for controls in the prop now). But without specifics I can’t really give guidance and I can’t look at anything. All of the feedback on my prop I was aware of in OS6 was already addressed in OS7.
In addition, already spent months planning out and building the Config Tool to make it easier for users to understand the laundry list of defines and options in OS7 (as well as to cut out all of the common syntax errors I saw users run into when they edit their config). I knew that adding so much customization and new defines would make it harder for users to figure things out so I built out the Config Tool to make it much easier to select things and build a config.
I also made it so the tool produces customized printable Button/Control Lists and other documentation because in a lot of cases users don’t know all of the controls and end up fumbling through things. And since the controls in my prop can vary dramatically now with all of the defines, it’s a key piece. There’s also a lot of controls that are now style based and that require additional support and set up in the font so I spent months writing the logic into the library to keep track and provide all necessary information on implementation, editing and controlling the new features. This information is also very important for users to be able to use their saber so this information is necessary in the config and it can also be printed from my config tool via the “Preset/Style Options List”. And since the supported sounds also vary by define and styles the config tool also produces a “Supported Sounds List” so users can properly set up their fonts for the new features.
Finally, my config tool has a bunch of optimization techniques built into it to work hand-in-hand with optimization capabilities in my library, since many users want to fit more and more into their sabers. The config tool makes setting up using functions, style arguments and copying presets to maximize memory all very easy and intuitive and it allows them to save up to 6 configs to come back to anytime for updates or edits. It’s also designed to move into future OS versions and support new features as they release.
So when users are trying to get the most out of the OS, I direct them to my tools because I already had planned out everything and understood what was coming down the pipe during development of OS7. All of the tools I built are designed to work together > “How to Update” > “Style Library” > “Config Tool” > “Fett263 Prop” pages are all a package to make things as easy as possible for all users regardless of knowledge to be able use what I build and it all took a lot of my time to build, so I don’t see the need nor have the time to do it all over again because someone else wants to have their own way of doing things.