VAMStory

Plugins VAMStory

Download [26.61 MB]
Support me at...
Overview Updates (34) Reviews (58) History Discussion Dependency Usage (488)
After playing with actions a bit, I have a couple suggestions:

1. Allow an "Empty" action type, so that we can create grids with empty spaces. Useful for grids where each row has buttons that start a variation of a common animation, but not all rows have the same number of variations. Currently I have to create a separate atom for each row.

2. Column span option for each action so that some elements like sliders can span multiple columns.

3. Opacity option for each action. Good for main starting menu that should have one main "START" button with opacity 1, and a couple secondary buttons like "Clothes reset", or "Skip story" buttons with opacity 0.5.

4. Give all appearance styles a distinctive default click color. Currently all have a click color that matches hover color.
 
Last edited:
@thiciathy
  1. I absolutely did not understand your explaination about animation variations (because I have zero context), but it does not really matter, spacers are planned.
  2. Span is unlikely to ever happen due to the lack of native way to handle the UI this way in Unity. I would need to create my own calculation system to size every single element of the UI... and honestly? I don't have the motivation for just a couple of people who are gonna benefit from this.
    I have an action grouping system planned, this could help by creating several action group with different sizes. That'll be the best alternative to that.
  3. Color overrides per items are planned at some point
Note: planned means "something I'd like in the future". No ETA, no promise, no guarantee ;)
 
Rule of thumb: don't ever (ever) assume what a new feature / fix implies in term of modifications and or (more specifically) time. Especially if you're not a coder (and I'm assuming you're not because coders don't estimate "time" on others people code without knowing it).

If you understand VAMStory, I'm gonna assume that you are smart enough to realize that appearance schemes are driven on a global scale on the plugin. Simply allowing overrides means duplicating the whole appearance system on a per item basis. Due to the sheer amount of customization possibilities, there's at least 2 to 4 hours of work just implementing a proper UI. This, is without counting the optimization, stability, debug and data integrity tests.

And I didn't forget about 4 :p
That said, I apologize, I've used "Color" in my answer for 3, I should have said "Appearance". Which implies that 3 and 4 will be possible with the override system.
 
hazmhox said:
don't ever (ever) assume ...
Click to expand...

I don't understand where this aggression is coming from, I'm always trying to be polite and have no assumptions or expectation, since I understand open source development very well (been doing it for 20 years myself now).

The only explanation is that you probably misunderstood what I've meant with my 4th point. I was just pointing out that in current "Appearance options", the default value of click color is the same as hover color, so it has no effect by default, which to me seems like a bug:

hover_click_same.jpg


But I don't work with unity or C#, so if changing these default values truly takes orders of magnitude longer than 30 seconds, I apologize for my insultingly low estimate there. ?‍♂️
 
Don't let Poe's law drive your interpretation of my answer (even when I put a word in bold). I don't see where there is an agression, I'm just stating a fact : )
Don't estimate the workload or duration needed when asking for a feature. That's pretty much all there is to my sentence here : D
If you have been in the open source dev for 20 years, then you exactly know what I mean haha.

This is something that is recurrent in gamers / people in either game community (Steam forum for instance) or on Nexus mod. People have absolutely zero idea how a game is made, yet, 25 minutes after release they drop on the forum and go "hey this does not work like I'd like, change it, it should take 3 minutes".

I exactly understood what you meant, and I kind of took a shortcut to the answer because with (like I recently explained to Timbo recently) the huge number of people asking me stuff for all sorts of reason, I tend to not always slap comment with a perfect contextualization because... well, I would spend more time answering to people than actually being able to fix or improve the plugins based on suggestions (or work on my projects).

So, since you are indeed a cool and understanding person, I'm gonna reframe the situation:

My plugins are coded with a design in mind. When I'm happy, I'm stopping at a certain stage, and releasing a first version. From there, I spend a tremendous amount of time ensuring that every version supports legacy content. Which implies two things :
  • Old content has to work exactly as it was made with version X or Y if you only keep the last version
  • Old content should not to be influenced in any way (in terms of behavior or appearance) by new features.
Which leads us to the over/click feature.
This is a feature that dropped after several versions of VAMS. Which means I had to keep the original default values of the over and click colors to stay "in line" with the original values used when it did not existed.
This is a voluntary decision simply just to preserve the way people made their scene with the old version :]

Hence! Saying that it is going to be fixed due to the override, because I can make default values different since it's a whole new feature only active if you check a box.

It's really hard to contextualize a feature/setting/option without knowing the history or at least trying to reframe why something exists : D
 
hazmhox updated VAMStory with a new update entry:

Features & QoL

VAMStory ( just for @Spacedog and @PetaZwega ;) )
  • Added groups ordering buttons (move up and down)
  • Added dialogs ordering buttons (move up and down)

VAMStoryActions
  • Added a Spacer type action (you can use this to make a space between two actions)
  • Added Reset Action Panel trigger (this will reset the whole panel and all actions to their default state)
  • Added...
Click to expand...

Read the rest of this update entry...
 
Sliders are incredibly hard to use due to how thin they are. Would it be possible to make the whole button a sliding hitbox? Or did I miss some appearance setting that fixes this issue/makes sliders thicker?
 
thiciathy said:
Sliders are incredibly hard to use due to how thin they are. Would it be possible to make the whole button a sliding hitbox? Or did I miss some appearance setting that fixes this issue/makes sliders thicker?
Click to expand...

I'm gonna check if I can boost the handle a bit wider to ease the grab.

And I was on the fence about making an appearance selection, I might do that in the future. A bunch of people told me they liked that slider 'coz it was more discreet and still usable. I guess it depends on people with VR interactions : )
 
I couple more requests ?:

1. Is it possible to not make the UI always on top of everything else, so it doesn't occlude the scene? I want to have the UI always available in the background, and it's a bit annoying to always have to turn it off because the scene is occluded by it.

2. Display the spacer's label text without button background, that way we could also use it as a dividing title for proceeding action groups. Though for readability it'd probably require text border.
 
thiciathy said:
I couple more requests ?:
...
Click to expand...

1. Nope. I've changed through the dev to the way it is now, because people asked me for it to behave like VaM's UI (a real world UI occluded by surroundings). I suppose I could find a way to have an option for that. But that won't be on my priorities list anytime soon : )

2. So not a spacer, but a text. Funny enough, when I was doing the update after adding the spacer I was unable to recall what other components I had in mind (my bad for not writing that down this time)... and this was it : )
So yeah, at some point I'm gonna add a "Label" type.


Just to tease you a bit... any chance we're ever gonna see those story of yours one day after all these requests and features idea? :p
( which for some are great ideas! don't get me wrong ;) )
 
hazmhox said:
1. Nope.
Click to expand...

That's a bummer. Means I have to drop Actions and re-do the UI in built-in atoms :(. I understand how always on top makes sense for dialogue, but I can't have a scene controlling UI occlude the scene.

hazmhox said:
.. any chance we're ever gonna see those story of yours one day after all these requests and features idea? :p
Click to expand...

I'm working on 2 scenes right now. A simple character creation room, and one story scene. But I think I'll make a different account to publish them under (don't like this one's name, it's an unpronounceable result of mashing a keyboard a couple years ago).
 
thiciathy said:
That's a bummer. Means I have to drop Actions and re-do the UI in built-in atoms :(. I understand how always on top makes sense for dialogue, but I can't have a scene controlling UI occlude the scene.
Click to expand...

Sorry, since pretty much everyone feels ok with (and requested) that behavior, I have way too much project at the moment to make this a priority.
 
hey there!
first: your plugin is awesome and im really into it!

my Questionnow isthat i have a problem/bug:
i saved the positions of the story plugin in different groups and yes the position changes when i change the group dialogs.

- but now the UI is locked and not following the camera movement anymore. furthermore all of the settings in global/text/apperance options dont work anymore.

- am i missing a check/button/somethingelse or is this a common bug?

thanks for help :)
Cheers
 
woodnic said:
- but now the UI is locked and not following the camera movement anymore. furthermore all of the settings in global/text/apperance options dont work anymore.

- am i missing a check/button/somethingelse or is this a common bug?

thanks for help :)
Cheers
Click to expand...

Hey! Can you send me a scene with a reproduction?
I can't try to see if it's a bug : )
 
OMG never mind... i fixed it... like you described in the update thread... ALL atoms with a story plugin had to be ON... i did it.. and now everything is fine...

Thank you very much and again Thanks for this brilliant plugin! :)
 
Yup!
You should control their state with the triggers I added if you need them to be hidden!
 
@hazmhox Hello!
I am trying this out of the first time, I created some VamActions and VamDirector triggers.
It seems like the VAM Actions Toggle Buttons fire triggers automatically on scene load? Is that intentional?
I have a few actions that are Toggle Buttons to play animations, and on scene load they seem to be firing the triggers.
 
bill_prime said:
@hazmhox Hello!
It seems like the VAM Actions Toggle Buttons fire triggers automatically on scene load? Is that intentional?
Click to expand...

Hellow Bill! ?

They do not "seem" to be firing... they do fire at scene load :p

It is intentional. Using toggles allow two different states. If you save the scene and forget to reset the state of the target atom in the triggers, that way, the atom is properly resetted or "activated" the way it should be based on your default state of your toggles (on or off).

Technically (from my perspective, and my way of seeing these toggles), I would see them more as a way to "on/off" things. And mostly only use the off state by default and allow the user to turn on something.
But you could indeed use it in a case like this :
  • On = AnimA
  • Off = AnimB
In this case, yes, you will have one of both firing at start.

This is an interesting specific case, I'm torn between "yup this seems to be a legit feature" and "umhh, not that useful".
Based on my code, this is extremely easy to fix, but I need to add a specific option for toggles to force them not firing at load.

I'll add this to my list, but I have a bunch of other plugins to finish, so this is at the bottom of my priorities ;)
 
hazmhox said:
Hellow Bill! ?

They do not "seem" to be firing... they do fire at scene load :p

It is intentional. Using toggles allow two different states. If you save the scene and forget to reset the state of the target atom in the triggers, that way, the atom is properly resetted or "activated" the way it should be based on your default state of your toggles (on or off).

Technically (from my perspective, and my way of seeing these toggles), I would see them more as a way to "on/off" things. And mostly only use the off state by default and allow the user to turn on something.
But you could indeed use it in a case like this :
  • On = AnimA
  • Off = AnimB
In this case, yes, you will have one of both firing at start.

This is an interesting specific case, I'm torn between "yup this seems to be a legit feature" and "umhh, not that useful".
Based on my code, this is extremely easy to fix, but I need to add a specific option for toggles to force them not firing at load.

I'll add this to my list, but I have a bunch of other plugins to finish, so this is at the bottom of my priorities ;)
Click to expand...

Yeah I see what you mean, both cases could be useful and you don't want to break/change existing logic.
In my case the Animations in the toggle button are "Turn backwards" and "Turn forwards" so I don't need them to play right away.
What if the button is disabled on scene load, and does it fire when the button is then enabled? I guess that is two questions lol.
 
bill_prime said:
What if the button is disabled on scene load, and does it fire when the button is then enabled? I guess that is two questions lol.
Click to expand...

The button disabled/hidden only changes the actual visibility and the way it flows in the panel. It's functionality stays the same (and will fire on load atm).
I had a bit of time this mornin', so I actually made the feature, I need to test a bit more to ensure I broke nothing as usual, but it'll be up today :)
 
You must log in or register to reply here.
Back
Top Bottom