Already possible, try something like:
Already possible, try something like:
“Audio Level Bar Graph” and “VU Meter” are also available in the library under Crystal Chamber, Accent LED or Build a Sequence as custom ON or OFF styles.
I’m not sure if this is discussed but I did notice that 6.7 doesn’t allow you to edit the secondary colour so my Feature Request is an additional menu if there’s a secondary colour to be able to edit it.
ALT_COLOR_ARG is editable in the menu already, if the style uses it. OS7 will include 2 additional ALT_COLOR2_ARG and ALT_COLOR3_ARG.
disable all edit mode features in idle. Copy preset works in idle, and it shouldnt. I really hate global color change, the cc in edit mode is better, because you can specify which blade.
I think building some standard bladestyles with shortcut code could be good for beginners.
Really dont care for any new features, my proffies already do what I want them to do.
IDLE_OFF_TIME only applies to LEDs, not button presses.
OS7 has multiple defines to disable features, partial list here more in the queue to be merged.
ColorChange is different then Color Editing. Don’t use Color Change mode if you don’t like it . Color Editing only works in Edit Mode, it requires the submenu system to select blade and effect. ColorChange is a carryover from OS3.9 and can only change base color for all blades at once.
Then don’t enable the new features, assuming you’re referring to new stuff in my prop or new styles I have planned for the library, just don’t use the defines that enable or use the styles that contain new features.
most installers are still on 5.9. I have been installing on os6. Some of the things i reccomended would preven5 newbies from inadvertantly changing my programming. Some odf the features which you stated there are disables for will help tremendously. I love os6, but the common person cant handle some of these features.
Try this tool, even if you don’t need “help” on building configs, if you select your define options and use the “Generate CONFIG_TOP” button at bottom you’ll get two Blue buttons, one to generate a custom “Buttons/Control List” and one to generate “Supported Sounds” list. These are intended to be printed and provided to users so they know exactly what controls and sounds are enabled on their saber based on the defines selected in the tools. It also obviously generates the CONFIG_TOP section which you can paste into the config (or build a full config if you wanted).
This tool will be even more helpful in OS7 as my prop will allow for a ton more customization of the controls via the defines already in place and those still waiting to be merged. It is intended to allow both installers and users to get an accurate control list to go with each saber.
If you build a full config using the tool it will also allow you to print the “Style Options” list as well which converts the library comment code into a printable list for use during Edit Mode
I’m pretty sure most are on 6.7. The only time I see people stuck on 5.x is old stock LGT etc or people that just don’t know how to update.
*One could always pull their preferred prop-file versions from OS5.9 and use it in 6.7 like I do for some people with specific wants. I have two hilts in house that are like this so the kids get their setups and I get EditMode, etc. The OS overall operates better and it’s an easy thing to do.
*One could always pull their preferred prop-file versions from OS5.9 and use it in 6.7 like I do for some people with specific wants. I have two hilts in house that are like this so the kids get their setups and I get EditMode, etc. The OS overall operates better and it’s an easy thing to do. I’ll likely try the same with OS7 once it clears beta phase.
I would NOT recommend using previous version of my prop with new OS, especially OS7. There are a fair amount of changes between my prop in each version and certain things may not work correctly with an old prop.
My prop in OS7 will have a ton of customization to enable or disable features that users want or don’t want via defines so it will be very easy to customize the prop as needed. There are also a lot of new style capabilities that will require prop support to function properly, old versions of props will not work with these capabilities.
A prop from previous ProffieOS version should work just fine in newer OS versions, no?
New EFFECTS wouldn’t work as they wouldn’t have controls in older props. Maybe “work as expected” is better way to put it.
For users who aren’t modifying a prop, or who aren’t well versed in the OS, I would definitely not recommend using older prop in new OS as things may not have controls or controls may be different than what is described in the OS. This leads newer users to think things are “broken” or they did something wrong which leads to unnecessary troubleshooting.
Particularly for OS7, I have taken quite a bit of time introducing defines to handle all of the customization users have requested and added a lot of support for new features that simply don’t exist in old versions. Telling users to grab an old prop is not what I would recommend, especially with everything coming in OS7.
Copy Gold Leader, just making sure I didn’t miss something about non-backward compatibility.
I’ve been short on playtime a lot lately.
In general props are not really “backward or forward compatible”, there are also often changes to supporting functions in the OS that will cause old props to not be able to even compile without errors, i.e. changes to SaberBase or PropBase (OS5 couldn’t use OS4 props because of several function changes) You also can’t use a new prop in an old OS as there are often supporting functions or EFFECTs that don’t exist in old OS. I think you’re thinking of configs or styles, those are backwards compatible, but prop files aren’t intended to be from my experience (and my prop in particular is not meant to be).
Unless the user is customizing the prop, or really knowledgeable in fixing/updating the prop I would not mix prop and OS versions.
i want to add for the record here: i am not opposed to evolution of features or proffie os. My post was taken out of context, and published on AI page. Im all for advancement and innovation, but Im also understanding that many saber buyers need simplification, because proffie can be overwhelming when people dont read directions. That was my context, as an installer…
I made a saber as an x-mas present, but because the intended user is not going to be fiddling with it a lot, I stuck with the standard “saber” prop and turned off all state saving.
There is a LOT of options for how to configure sabers with different props and features that can be enabled or disabled. Installers may need to be prepared for different levels of users. Some may want all the options, while others will want fewer, or none of the options.
That all said, feature requests are always welcome. I find the idea of disabling certain features “in idle” interesting, but I’m not entirely certain how it should work, because if you press a button, then the saber isn’t actually idle anymore…
In general; no
However, most changes in proffieOS are backwards-compatible, so there is a fairly good chance that it does work. Also, when it doesn’t work, the changes required are often simple.
tl;dr; YMMV, AAA* FTW
Much appreciated feedback. I totally get that and should have clarified better.
@MegtoothSith I keep a running copy of 5.9 handy for those types of situations and just tell or show the person the differences is all. Either way progress is good.
A sonic screwdriver PROP feat were turning/twisting like you do for the edit mode or twist on.
in this case it increase/decrease the pitch of the hum with a slower twist. and a lock up mode where you hold the button down and twist vers a clash… I am not sure if this can be accomplished with just a prop file. Lock up mode would be angry screwdriver setting vers a lock up. I dont know exactly how I would like the set up for the prop. but I do know the twist to increase pitch would be something to be added.