I think the primary use case for color screens would be tricorders actually. 
2 Likes
I don’t know! It was just a funky thing to answer with.
Although, maybe it could trigger retraction if the saber leaves the hand?
Blaster stuff! Color screens for scope displays. OLED’s reflect trigger pulls.
What to add next?
- Color screens
- scope graphics
- Fingerprint scanner
- individual blade ignition
- proximity detector?
0 voters
With all of what has been done on previous os editions this latest one will add more shiny bits to an already impressive array of capabilities, now add it to a new v3 board and yet again you have a world leading piece of kit.
We all bow down to your remarkable achievement with this.
I only started with my own boy hood dream of creating a light sabre and so far with the v2.2 board and a whole host of extra little goodies I’m very happy with what I have been able to creat. All thanx to your ingenuity!
Picking up what I ready earlier it would be great to have a rotary dial to control the volume. I have a 40mm driver in my hilt and it can be a bit much in the house😁
1 Like
Volume control is actually one of the things I don’t have added support for yet.
Should be easy to fix though.
Maybe something for the pot on v3 board? Maybe utilizing one of the free pads as an add on?
Or maybe a nice little mod for v2.2 boards?
No, I meant that I have support for rotary decoders. I don’t have a pre-made way for rotary controllers to control the volume yet.
Ah sorry my bad
I’d like to see a voice/sound based battery level indicator if there isn’t something already (aside from the low battery). This would be useful for those times when I don’t have the blade installed and therefore can’t see the nifty battery indicator. This could even be something as simple as a series of beeps - 1 for 25% or less, 2 for 26-50%, 3 for 51-75% and 4 for above 75%.
There is already code in there for speaking the voltage.
Some of the props have code for triggering it, some do not.
I’m team blaster right now. Your Saber stuff is already awesome!
1 Like
I would like to see an audio effect trigger a clash delay. Currently some of the bassier fonts by the biggest font makers, especially Kyberphonic cause false clashes severely.
I guess what I’m hoping for to be standardized in the OS is that if you trigger a blaster, force sound, lockup, etc. for there to be a brief delay after the sound finishes playing so that we don’t have to play the volume/clash balancing game as much.
I have insulated the board mounts, and tried a gazillion different things to keep the wires from translating vibrations to the board. I can always play the volume/clash balancing game and eventually get sabers fine tuned; however, it seems to me that OS6 could adapt some official coding within the OS to reduce/eliminate false clashes induced by speaker vibrations. That is my number 1 wish for the new OS…besides all the cool features I see Fernando working on within his prop file.
1 Like
Might not be that simple, especially since many sound effect actually has their crescendo a small amount of time after the beginning of the sound. However, maybe it would be possible to simply check the current sound volume and use that as a dampener on clash detection. I already use the swing speed to dampen clash detection, and that seems to work fairly well.
I’ve been meaning to do some fiddling with the clash detection code anyways…
2 Likes
How differently is OS6 is going to treat audio?
Currently, the answer is: Not at all.
Why do you ask?
I don’t remember why I asked that, sorry. Something about Wavlen, pstoff, etc…
New subject instead.
In making some blade styles lately, I had to work around something I couldn’t see how to do.
Is there a way, or could there be in the future, for Trigger to have the “time to stay” value take an Effect event?
Example. Trigger something with EFFECT_PREON, but then stay triggered UNTIL the specified event, like a clash or retraction or something like that?
That field currently takes a function.
Sorry if that’s not clear, but I was basically looking for it to hold until something else happened, instead of just for a time.
1 Like
That sounds more like a type of lockup to me.
In general, I tend to think of events as not having a length, or possibly a fixed length, while lockups have separate beginnings and end with the possibility of showing/playing something different in between.
I can try to word the application .
I have a bump that grows in size by Trigger by EFFECT_PREON. It sits in an AlphaL whose transparency is Ifon.
I just wanted to have that bump hold dormantly hidden at its full size until retraction, then release the Trigger so it shrinks again.
So the length of the preon determines the size of the bump or something?
I still don’t know if I understand what you’re trying to make it look like?