A way to add tracks?

[niston]

I tested the combo in game:

Spoiler

Glowmap somewhat works now. I'm not sure why it glows white, but at least it doesn't light up the whole TriShape anymore.

Collision of power button is clearly visible in workshop outline 
It works better for selecting now, and I blame any remaining imperfection squarely on Todd.

Quote

What's the point of using them separately?

UI system already built for separate elements.
Consider for example: When power generator is turned OFF but amplifier button is still ON, power light must turn OFF nonetheless.
Script already handles all of that. ¯\_(ツ)_/¯

Another benefit is, we can easily reuse these very nice controls and indicators for other projects if they're separate.

Yet another benefit is, generic controls let me write generic scripts. "Generic push switch" plus "generic indicator light", instead of less generic "push switch and indicator with specific functionality". Generic scripts can be reused for various implementations of these controls then (like, I made one generic script to use for all 3 types of rotary controls: selector, volume and balance ). This, in the end, saves me lots of work and I don't have to write specialised code over and over again for every single little thing.

Quote

 I asked, is there an absolute need for these buttons?

In terms of absolutes, I can do with one extra button: Momentary, non-latching push button.
There must be some way to bring up a configuration menu.
I thought it to be more intuitive if there were separate buttons for the various aspects of configuration, but I can of course nest all menus into one. So it can all be hidden behind one button.

And if you don't want MUTE function, then we won't do MUTE function.

My personal taste is just that, I don't like non-functional controls. I like to make them work and do something useful instead.
¯\_(ツ)_/¯

[worm82075]

[South8028]

12 minutes ago, niston said:

I tested the combo in game:

  Reveal hidden contents

Glowmap somewhat works now. I'm not sure why it glows white, but at least it doesn't light up the whole TriShape anymore.

Collision of power button is clearly visible in workshop outline 
It works better for selecting now, and I blame any remaining imperfection squarely on Todd.

UI system built for separate elements.
Consider for example: When power generator is turned OFF but amplifier button is still ON, power light must turn OFF nonetheless.
Script already handles all of that. ¯\_(ツ)_/¯

Another benefit is, we can easily reuse these very nice controls and indicators for other projects if they're separate.

In terms of absolutes, I can do with one extra button: Momentary, non-latching push button.
There must be some way to bring up a configuration menu.
I thought it to be more intuitive if there were separate buttons for the various aspects of configuration, but I can of course nest all menus into one. So it can all be hidden behind one button.

And if you don't want MUTE function, then we won't do MUTE function.

My personal taste is just that, I don't like non-functional controls. I like to make them work and do something useful instead.
¯\_(ツ)_/¯

I'm not sure, but in the workshop.hkx circuit itself the indicator does not work after turning off the power. IN In the activator you need to set parameters. I don’t remember them all from memory... But the power turns off - the activator turns off. Workshop.hkx has a bunch of sequences even for animating the shutdown process. You can, for example, animate how the capacitor is discharged and the indicator slowly goes out. The indicator lights up white because white is used + the brightness is raised to 8. This can be easily adjusted in the nifscope if this is unnecessary. Set the brightness to 2, select the color red. I don't know about the buttons. I'm sure lots of buttons will irritate most people.

[niston]

Behavior graph has many drawbacks and makes life very complicated for me. I already mentioned in earlier posts.
I never use elements with graphs in my scripted UI stuff, because it's repeatedly turned out to be a major hassle.



 

[South8028]

Just now, niston said:

Behavior graph has many drawbacks and makes life very complicated for me. I already mentioned in earlier posts.



 

I see. I'm tired of this button and indicator. Still, the design, when all the elements are separate, greatly complicates the process. I'll redo the indicator and remake the button. Hopefully for the last time.

I just don't understand how addOnNode will work if we don't have vanilla scripts. And if we still have to use vanilla for addOnNode, then why not combine the indicator with the button.

[niston]

We don't have to use vanilla for the light object.
I can easily place a light object from script and attach it to regular NiNode instead of an Add-On Node.

In fact, I will add this capability to the "IndicatorLight" script now.

[ChuckYufarley]

My goodness, there's a lot to digest here since the last time I checked in. I apologize for being absent, as per usual, I keep finding things with my other project to tweak, break, fix and re-implement. It looks as though you two have a handle on the project. At this point, I guess I can offer suggestions if needed, but beyond that I'm not sure if there's anything else you need me to do. 

Niston, I assume you've got a handle on any or all of the scripting that needs to be done.

South, I agree with Niston when it comes to using the  workshop.hkx. All the functionality the behavior graph gives can be replicated via script, and implementing the behavior graph does limit the open ended flexibility a simple collection of animation sequences allows. I've never worked extensively with the workshop.hkx, but my understanding is that it's mostly used to automatically detect when a power source is connected. Looking at the PowerButtonAndIndicator.nif now, and instead of using the workshop.hkx, I would recommend using the GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx behavior instead. 

I've edited the PowerButtonAndIndicator.nif to implement the GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx behavior, renamed the animation sequences accordingly and changed a few of the keys within the second and fourth sequence NiTextKeyExtraData blocks to work with the new behavior. https://drive.google.com/file/d/1jvEAld-AHdgjj7cXJ8GA5HRnHfm-7Fw9/view?usp=sharing

This should give you an idea of how to implement the GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx behavior in the future. Although the name implies there are no loops, what it does in fact is make the sequences repeatable (essentially creating a loop) depending on how the NiTextKeyExtraData keys are set up. This is the one type of asset in this project where a behavior graph is useful. I have to admit though, as I've been out of the loop, I don't know where you're at with how all the various assets should function.

[South8028]

35 minutes ago, niston said:

We don't have to use vanilla for the light object.
I can easily place a light object from script and attach it to regular NiNode instead of an Add-On Node.

In fact, I will add this capability to the "IndicatorLight" script now.

Hold the button and indicator. I checked. Works. I hope there won't be any problems.Giant collisions will help us.

https://disk.yandex.ru/d/m2TgIqYexG7SIw

https://disk.yandex.ru/d/4SgRD5-Nxx9MGA

[South8028]

7 minutes ago, ChuckYufarley said:

My goodness, there's a lot to digest here since the last time I checked in. I apologize for being absent, as per usual, I keep finding things with my other project to tweak, break, fix and re-implement. It looks as though you two have a handle on the project. At this point, I guess I can offer suggestions if needed, but beyond that I'm not sure if there's anything else you need me to do. 

Niston, I assume you've got a handle on any or all of the scripting that needs to be done.

South, I agree with Niston when it comes to using the  workshop.hkx. All the functionality the behavior graph gives can be replicated via script, and implementing the behavior graph does limit the open ended flexibility a simple collection of animation sequences allows. I've never worked extensively with the workshop.hkx, but my understanding is that it's mostly used to automatically detect when a power source is connected. Looking at the PowerButtonAndIndicator.nif now, and instead of using the workshop.hkx, I would recommend using the GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx behavior instead. 

I've edited the PowerButtonAndIndicator.nif to implement the GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx behavior, renamed the animation sequences accordingly and changed a few of the keys within the second and fourth sequence NiTextKeyExtraData blocks to work with the new behavior. https://drive.google.com/file/d/1jvEAld-AHdgjj7cXJ8GA5HRnHfm-7Fw9/view?usp=sharing

This should give you an idea of how to implement the GenericBehaviors\StagesNoLoops\StagesNoLoops.hkx behavior in the future. Although the name implies there are no loops, what it does in fact is make the sequences repeatable (essentially creating a loop) depending on how the NiTextKeyExtraData keys are set up. This is the one type of asset in this project where a behavior graph is useful. I have to admit though, as I've been out of the loop, I don't know where you're at with how all the various assets should function.

Well, I just do what I'm told.

[ChuckYufarley]

South, in the PowerButtonAndIndicator.nif, is it safe to assume the ButtonPower:0 BSTriShape represents the object collision, or rather is the same size and shape of the actual collision? If there are other buttons or switches closely situated to the power button, I would suggest limiting the collision size so that it's not wider than the button itself. If there's no other selectable element with a collision that might overlap the power button, then it's not important.  If possible, I would probably make it taller and deeper, however, to make it more easily selectable. Since I'm only seeing the button and indicator, I don't have any idea as to scale as it appears in game. Like I mentioned in a previous post, I make the button collisions for my second jukebox roughly a quarter to a third the size of a vanilla cigarette pack, and those are (relatively) easily selectable.