• Hi Guest!

    Please be aware that we have released another critical security patch for VaM. We strongly recommend updating to version 1.22.0.12 using the VaM_Updater found in your installation folder.

    Details about the security patch can be found here.
VAMStory

Plugins + Scripts VAMStory

Screenshot 2024-12-27 090003.png
Screenshot 2024-12-27 090022.png

Take the new scene I’m currently working on as an example—this is the actual difference between in-focus and out-of-focus areas with depth of field applied. As you can see, the atom hosting VAMSTORY and the AUTOFOCUSPOINT are actually quite close in distance. So here’s the problem: where exactly am I supposed to place the UI?
 
Nope. This was changed because a lot of player/creators complained that it wasn't working / glitching with post process.
There is no option to change that.
I personally don’t quite understand why UI interaction elements need to be affected by post-processing effects—it just doesn’t make any sense. It’s like in film post-production, where you color grade and apply various effects to the footage, but would you include the subtitles in that process? Of course not.

Now it’s like applying motion blur, bloom, or color filters to subtitles during film post-production. No, the purpose of subtitles is to provide information to the audience in the most straightforward and clear way, isn’t it? The powerful and useful features provided by VAMSTORY are just as important, if not more so, because it not only needs to be straightforward and clear but also has to interact with the user.

You would never, nor should you ever, expect to rely on post-processing to make your subtitles look prettier. The same principle applies to the UI interaction interface and features provided by VAMSTORY.
 
@hazmhox Quick question.
Since disabling/enabling empty atom breaks VAMStory I thought maybe loading multiple empty atom presets might also be bad practice but it seems to work, at least in the one experiment I ran.
My hope is to use a single atom for multiple menu variations. It must also support different director triggers, possibly with same name. (I'm assuming both the Action and Director plugins are in the same Empty to be restored by the preset load.)
My question is would loading presets work for this or do you recommend creating multiple empty's for each menu? i.e. is there a potential for bad behavior from loading presets?
Thanks
 
@hazmhox Quick question.
Since disabling/enabling empty atom breaks VAMStory I thought maybe loading multiple empty atom presets might also be bad practice but it seems to work, at least in the one experiment I ran.
My hope is to use a single atom for multiple menu variations. It must also support different director triggers, possibly with same name. (I'm assuming both the Action and Director plugins are in the same Empty to be restored by the preset load.)
My question is would loading presets work for this or do you recommend creating multiple empty's for each menu? i.e. is there a potential for bad behavior from loading presets?
Thanks
I can’t speak for Hazmhox, but from my own experience, this approach doesn’t have any negative effects. I’ve used this method extensively in extremely complex scenes, and I’ve never encountered any issues.
 
For example, I have a playlist with over 50 entries, and I have 8 such playlists. Instead of having all 400+ entries exist in the scene simultaneously, I use the method of loading presets for empty atoms to replace them. This way, only 50+ entries are present at any given time.
 
For example, I have a playlist with over 50 entries, and I have 8 such playlists. Instead of having all 400+ entries exist in the scene simultaneously, I use the method of loading presets for empty atoms to replace them. This way, only 50+ entries are present at any given time.
Excellent. Sounds pretty robust then. I'll do it... And if it breaks I know who to blame 😁
BTW have you released a scene with these playlists you described? Or at least a scene that loads presets of VAMStory that I can look at just to make sure we're on the same page?
 
Excellent. Sounds pretty robust then. I'll do it... And if it breaks I know who to blame 😁
BTW have you released a scene with these playlists you described? Or at least a scene that loads presets of VAMStory that I can look at just to make sure we're on the same page?
Produce 69, this scene is not only very complex but also has a large number of users. I think that’s enough to validate the stability of this method (at least, no one has ever encountered any issues caused by it).

screenshot-2024-05-03-065005-png.362597


As shown in the image, the playlist on the left is replaced with presets. When you select a different season, it gets swapped out with the corresponding preset.
 
Last edited:
Produce 69, this scene is not only very complex but also has a large number of users. I think that’s enough to validate the stability of this method (at least, no one has ever encountered any issues caused by it).

screenshot-2024-05-03-065005-png.362597


As shown in the image, the playlist on the left is replaced with presets. When you select a different season, it gets swapped out with the corresponding preset.
Definitely!
 
@hazmhox Usability Request: Could you make the "Footer Slider" in VAMStoryAction plugin larger / easier to grab for use in VR? Or maybe make normal/big versions similar to the Action Sliders.

The tiny knob is very hard (for me at least) to select with my VR controllers (and shaky hands) unless its very close. As it is, I almost can't use the footer slider in VR mode and it has some advantages over the Action button sliders that I like.
e.g. I have a random speed adjust that I would like continuously reflected in the slider value. If I use the Action button I need to first set "Select Action ID" but if I use the footer slider this step isn't required and there's no chance of other events that might use the "Select Action ID" colliding with the slider update.
 
I'll see what I can do! Duely noted : )

Thanks @Shadow Venom for helping people <3

Side note for everyone : there is no wrong practice, if you don't detect any bad behavior on several attempt / playback. This is why I recommend playtesting (pretty much anything, not only stuffs with VAMS) with several VAM friends of yours. If you can't produce a bug/side effect, this means your approach is valid, and a valid way to use plugin X or Y.

Never be afraid to use your own tricks and eventually share them. There is no "truth" in video game dev / design. If we make the exception of more "optimal" approaches : )
 
Last edited:
Take the new scene I’m currently working on as an example—this is the actual difference between in-focus and out-of-focus areas with depth of field applied. As you can see, the atom hosting VAMSTORY and the AUTOFOCUSPOINT are actually quite close in distance. So here’s the problem: where exactly am I supposed to place the UI?

This is a valid question (and your prior posts too), but I'm referering to the most "reported" problem and mostly how "something" is handled in the game itself.

VAMStory was "in between" of the render spectrum, ie : world but not really, behind some stuffs but not really, in front of others stuffs but not really.

VAMStory is a "world UI" and should be influenced by the final frame post processing as it lives inside of that spectrum. If you post process a blur out/fade out on the frame, the UI should be treated as a world object. It's not that the prior way was good, it's the prior way that was wrong and (some) people used that as an advantage... when in truth a LOT of silent people (for you) were complaining through Discord or PM that it was annoying.

Technically, world UI should be treated differently from "menu" UI. Just like in a normal game. But the way VAM works makes this complicated or requires tricks to behave differently. I have no idea at the moment to make this work and the fact that pretty much no one complained and others are happy with the change, it's hard for me to dedicate time to this... at least, for now.

Also, DOF in VR = me cringing 😝

But, joke aside, to answer what your problem is: this is a photography problem. You use aperture settings that makes the focus point ultra narrow (less than a centimeter). This is something you will never see in real life besides with Macro lenses for either macro photography OR really stylized standard shots with macro lenses. You cannot fix that unless you change your aperture, this is normal and intended when you are in the realm of lens/focus simulation.
 
Bonus: Also as you see in your last shot @Shadow Venom the UI on top of transparent stuffs like clothes or simply the VAM shader, WITH post processing are glitchy since the first day, due to the way VAM works. This is something I can't fix.

The PP pipeline is extremely shitty in VAM.

Mostly why I have sacrificed and removed it in most of my scenes and most recently in Scary Mary. Using it and getting un-intended behaviors should be fixed on your end (by making a choice to have it or not), not all plugins creators that can't code/implement every best aspect of both worlds (with and without PP) on a base process pipeline who is unstable af ^^
 
This is a valid question (and your prior posts too), but I'm referering to the most "reported" problem and mostly how "something" is handled in the game itself.

VAMStory was "in between" of the render spectrum, ie : world but not really, behind some stuffs but not really, in front of others stuffs but not really.

VAMStory is a "world UI" and should be influenced by the final frame post processing as it lives inside of that spectrum. If you post process a blur out/fade out on the frame, the UI should be treated as a world object. It's not that the prior way was good, it's the prior way that was wrong and (some) people used that as an advantage... when in truth a LOT of silent people (for you) were complaining through Discord or PM that it was annoying.

Technically, world UI should be treated differently from "menu" UI. Just like in a normal game. But the way VAM works makes this complicated or requires tricks to behave differently. I have no idea at the moment to make this work and the fact that pretty much no one complained and others are happy with the change, it's hard for me to dedicate time to this... at least, for now.

Also, DOF in VR = me cringing 😝

But, joke aside, to answer what your problem is: this is a photography problem. You use aperture settings that makes the focus point ultra narrow (less than a centimeter). This is something you will never see in real life besides with Macro lenses for either macro photography OR really stylized standard shots with macro lenses. You cannot fix that unless you change your aperture, this is normal and intended when you are in the realm of lens/focus simulation.
True, adjusting post-processing settings—or even dynamically enabling/disabling them—can solve these issues. But that also means a lot more work… and who likes extra workload?:devilish:
 
Haha. You know WE do :p
We're the kinda guyz who loves to slap themselves with more work lol.

I'll keep your request in mind tho. If anyday, I suddenly realize I can do something that would be an easy fix, I'll do it... you know me : )
 
Sorry, I encountered such an issue while using previous versions in scene creation. However, I just tried the latest version and couldn't replicate it, so please disregard the previous feedback. Thank you for your response!

View attachment 363965
BTW, I reported a bug a long time ago. When I tried to reproduce it later, it seemed like it didn’t exist in the newer versions. However, I recently discovered that it has actually been there all along.

In short: When a spacer object is present in the UI, attempting to execute a reset action panel operation will interrupt the reset process for all items listed after it, causing them to fail to reset.

This bug is hard to notice or reproduce because it does not occur when the UI is first created. However, after reloading the scene, the bug starts taking effect.
 
I use spacers extensively to create UI layouts, and since I also rely heavily on dynamic updates to change the UI content, I’ve unfortunately been troubled by this bug quite a lot.

One workaround to bypass this issue is to avoid using spacers altogether and instead replace them with text items, then hide the unnecessary text items when they’re not needed.

But I think fixing this bug would be a much more convenient solution.

Additionally, this bug seems to have a chain reaction effect. For example, if I have five different UI elements (A, B, C, D, E) and A contains a spacer, then when I try to reset all five UI elements at the same time, B, C, D, and E will all fail to reset.

Even worse, it seems that some plugins unrelated to VAMStory can also be interrupted by this spacer... :oops:
 
One example could be:

Let’s say I have a series of triggers, including resetting a specific action panel, and the final trigger is VAM Overlay's Fade In. However, if the reset action panel process is interrupted by a spacer, then all subsequent triggers—including Fade In—fail to execute correctly.

The issue is that VAM’s error log doesn’t show any errors, making it even harder to diagnose. But once the spacer is removed, everything works as expected.
 
I'll see what I can do! Duely noted : )

Thanks @Shadow Venom for helping people <3

Side note for everyone : there is no wrong practice, if you don't detect any bad behavior on several attempt / playback. This is why I recommend playtesting (pretty much anything, not only stuffs with VAMS) with several VAM friends of yours. If you can produce a bug/side effect, this means your approach is valid, and a valid way to use plugin X or Y.

Never be afraid to use your own tricks and eventually share them. There is no "truth" in video game dev / design. If we make the exception of more "optimal" approaches : )
Thanks.
And on the just try and see what happens front, that's my approach 99/100 times but in this case I thought loading a preset was too similar to off/on-ing the containing atom (which as we all know is verboten) so before going down that rabbit hole I thought I'd ask. Thanks for the response and thanks to @Shadow Venom for answering (and making those crazy complex, boundary pushing scenes).
 
Thanks.
And on the just try and see what happens front, that's my approach 99/100 times but in this case I thought loading a preset was too similar to off/on-ing the containing atom (which as we all know is verboten) so before going down that rabbit hole I thought I'd ask. Thanks for the response and thanks to @Shadow Venom for answering (and making those crazy complex, boundary pushing scenes).

I obviously meant "If you can't produce a bug/side effect" but I suspect you understood it was a typo :p
 
Thanks.
And on the just try and see what happens front, that's my approach 99/100 times but in this case I thought loading a preset was too similar to off/on-ing the containing atom (which as we all know is verboten) so before going down that rabbit hole I thought I'd ask. Thanks for the response and thanks to @Shadow Venom for answering (and making those crazy complex, boundary pushing scenes).
A way to completely turn off a no-duty UI without making hazmhox mad… by replacing it with an empty atom preset! 🤯

In fact, I’ve already started using this method in the scene I’m working on. The new version of VAMSTORY pops up a warning when you try to turn off its atom, but some UI elements are really just one-time-use. So… 😏
 
I obviously meant "If you can't produce a bug/side effect" but I suspect you understood it was a typo :p
Oh, since you're online, I’d like to take the chance to ask about two long-standing issues that have been bothering me:

  1. In earlier versions, you mentioned that the number of entries in VAMStory’s dialogue panel could impact performance. Is that still the case in the current version?
  2. Following that logic, does having too many UI entries in the Action Panel also affect performance?
Would love to hear your answers on this!
 
Oh, since you're online, I’d like to take the chance to ask about two long-standing issues that have been bothering me:

  1. In earlier versions, you mentioned that the number of entries in VAMStory’s dialogue panel could impact performance. Is that still the case in the current version?
  2. Following that logic, does having too many UI entries in the Action Panel also affect performance?
Would love to hear your answers on this!

Performances IN THE VAM UI. Which is why I completely revamped the UI and made it dynamic with a single "main UI" that gets update when you swap from entry to entry.

Ingame, it should not have a huge impact from what I tested, I have several scenes with dozens of actions and so on. That said, far from your main big scene :)

Why ? Did you notice performances issues recently?
 
A way to completely turn off a no-duty UI without making hazmhox mad… by replacing it with an empty atom preset! 🤯

In fact, I’ve already started using this method in the scene I’m working on. The new version of VAMSTORY pops up a warning when you try to turn off its atom, but some UI elements are really just one-time-use. So… 😏

The warning only pops in edit mode. You could technically off them if you know what you're doing. As long as you DO NOT save while they are off.
My hands are tied behind my back on that one, as Unity cannot execute code when an object is in off state, which is why it breaks VAMS if you off them.

But let's say you'd off them during playthrough. Ensure you have like a debug UI somewhere, to reset their state prior to saving the scene.
 
A way to completely turn off a no-duty UI without making hazmhox mad… by replacing it with an empty atom preset! 🤯

In fact, I’ve already started using this method in the scene I’m working on. The new version of VAMSTORY pops up a warning when you try to turn off its atom, but some UI elements are really just one-time-use. So… 😏
Yes. I'm a recent convert to the church of the preset. Much easier to keep track of, and I'm sure better performance, than loading everything at startup. If nothing else it helps with initial load time.

Interesting that VAMStory atoms can actually be turned on/off as long as I don't save. But I've gotten burned by that before so I think I'll keep it simple and continue to believe that's not an option.
 
Back
Top Bottom