Momentary buttons, like the kind you might find on keyboard or mouse. Press once, let go. The button doesn't change state, it only reacts to the pressing while you're pressing it. It's not "sticky" in the sense that it stays on until you press it again, nor does it change the state of any other button on the HUD..
It's "just a button".
I added those today. Two different kinds. The simple momentary, or as I like to call it "a button".. you click it, and it spits out whatever description it has, as a command to the object. The second was a bit more complicated, but it goes something like this.
In the past, I've used a fictitious product to describe some of my controls. In one memorable case, it was a penis with 5 stages of arousal. In that example, we used a set of "radio buttons" to control arousal.. because like an old-style radio you might find in a car, pressing the channel preset buttons will change the channel (or state), but you can only use one button at a time. We talked about the "grouped toggles".. which controlled whether something was visible or not, like a piercing or a set of cock rings. Something that you could choose to show or hide, but if you wanted to show it, you'd want it to "follow" the penis's current arousal state.
Passthrough controls were envisioned for the most part, as particle controls. While they can be used for more than just particles, I noticed a problem with the idea of using a momentary control for particles.. that being that you'd need to know which arousal state was currently visible.. so that whatever simulated fluids were being generated by the particle system.. you'd want them to be generated in the proper position in relation to the current arousal state.
Since we use radio buttons to define the arousal state, I had to build a modified version of the grouped toggles in momentary passthrough form, to get the value from the radio set when the momentary button was pressed.
Bottom line: that's also done.
My hud is happily generating messages with each press, and the object is receiving them, and reacting properly to each.. passing the passthroughs, acting on the ones it's programmed to act on. It's good progress, and I'm pleased with the results so far, even if I am burdened by depression.
With this, the number of controls that need to be added has become very small.
- resizer buttons and a built in resizer.
- HUD rotation controls.
I'm winning the battle, one skirmish at a time.
I'm envisioning one other weird case where I might want to build a passthrough toggle, but to be honest, it's such a weird case that I'm not sure it's worth bothering about, and it would require adding a ganged toggle to that control type as well.
With the current passthrough controls, I can control when a particle generator starts, but if the mode "moves on" away from the generator, that generator might keep going. The simple solution is that all particles should self-terminate.. and if you want to 'pee longer' for example, you press the 'pee' button again. That approach has certainly worked in the past.
The alternative is to have a sort of toggle control that can "turn on" a certain particle, and update it's data should the arousal state move while it's on. There are downsides to this approach, in that the more items I gang on to a radio set, the slower updates get as it has to parse through ALL of the prims in the object one time for each command in the message.
It's probably better, and simpler.. to just use the momentary controls for particles.. and if I want to do anything fancy like that, simply do it on the plugin level, and skip the "visible state tracking" on the HUD.. opting for a "start particles" button alongside a "stop particles" button.
No comments:
Post a Comment