• 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.
VAMMoan 2 (teaser)

Plugins + Scripts VAMMoan 2 (teaser)

Umhhh! Really?

Reactions should work, you're using specific triggers?
And for spanking, do you have the soft body enabled?
I ran some additional tests and it seems spanking works if and only if, all of these are enabled:
  • Soft Body Physics
  • Advanced Colliders
  • Glute Soft Physics (which I had disabled)
The question is, why doesn't it work without soft glutes? With my limited understanding of the code I don't see a reason.
The collision handler is attached to a rigidbody, that is the same in both cases.

Code:
            lGluteTrig = containingAtom.rigidbodies.First(rb => rb.name == "AutoColliderFemaleAutoCollidersLGlute1Joint");       
            rGluteTrig = containingAtom.rigidbodies.First(rb => rb.name == "AutoColliderFemaleAutoCollidersRGlute1Joint");
            rbHipAS = containingAtom.rigidbodies.First(rb => rb.name == "hip");

            lGluteTrig.gameObject.AddComponent<SexTriggerCollide>().OnCollide += GluteTrigObserver;
            rGluteTrig.gameObject.AddComponent<SexTriggerCollide>().OnCollide += GluteTrigObserver;

The plugin I used in my sample clip added its collision handler behaviour to the very same rigidbody and it didn't require soft glutes to function.
 
Omfg... I know why. Check this out
Code:
protected void initSpankHandler(){
...

            var left = containingAtom.GetComponentsInChildren<Collider>().FirstOrDefault(c => c.name == "AutoColliderFemaleAutoCollidersLGlute1Joint");
            lGluteTrig = containingAtom.rigidbodies.First(rb => rb.name == "AutoColliderFemaleAutoCollidersLGlute1Joint");

            SuperController.LogMessage(left.attachedRigidbody.name);
            SuperController.LogMessage(lGluteTrig.name);
            SuperController.LogMessage((lGluteTrig == left.attachedRigidbody).ToString());

...
}

this prints:
Code:
AutoColliderFemaleAutoCollidersLGlute1Joint
AutoColliderFemaleAutoCollidersLGlute1Joint
False

They're different rigidbodies with the same name.
 
In other words, changing the code like this:
Code:
            var colliders = containingAtom.GetComponentsInChildren<Collider>();
            lGluteTrig = colliders.First(c => c.name == "AutoColliderFemaleAutoCollidersLGlute1Joint").attachedRigidbody;
            rGluteTrig = colliders.First(c => c.name == "AutoColliderFemaleAutoCollidersRGlute1Joint").attachedRigidbody;

results in:

 
alternatively:
Code:
lGluteTrig = containingAtom.rigidbodies.First(rb => rb.gameObject.activeInHierarchy && rb.name == "AutoColliderFemaleAutoCollidersLGlute1Joint");
rGluteTrig = containingAtom.rigidbodies.First(rb => rb.gameObject.activeInHierarchy && rb.name == "AutoColliderFemaleAutoCollidersRGlute1Joint");
 
Last edited:
You'll have to re-initialize the spank handler when soft glutes are toggled, though.
Or attach handlers to both gameObjects and let vam enable/disable them for you.
 
Yup, that does it. I just implemented the same thing in Version 4 of Triggers: Inputs and Collisions
VAM maintains two separate rigidbodies for soft glutes on/off and sets one of them to active.
The solution is to add collision handlers to both, which then get enabled/disabled with their parent gameobject.

A notable pitfall is that 'attachedRigidbody' of colliders on inactive rigidbodies returns null.
 
Last edited:
I went ahead and fixed it.
Spank sounds are more intense with soft glutes off than on but that's a separate issue.
 

Attachments

  • vamm_sfxs.cs
    46.5 KB · Views: 0
This is very nice of you @TBD !
I'll merge it with the next update, I'm doing some updates atm : )
Thanks, that's great. I'd appreciate if you could give me a quick ping once you release the vammoan2 patch. I'm about to update a scene, which I'll postpone to include the fix.
 
Thanks, that's great. I'd appreciate if you could give me a quick ping once you release the vammoan2 patch. I'm about to update a scene, which I'll postpone to include the fix.

I always ping for bug reports or contributions. You'll be added in the code contributions/credits for the plugin : )
 
I always ping for bug reports or contributions. You'll be added in the code contributions/credits for the plugin : )
That's also very much appreciated but I was just asking for a notification. I suppose I can simply click "watch" on vammoan2 and let the hub software do that, though. 😄
 
Is it correct to start the timeout routine before checking the minimum impact velocity?
Code:
protected void GluteTrigObserver(object sender, CollideEventArgs e)
{
...
        // Preventing any other sounds to be played
        StartCoroutine("spankTimeout");
        
        float colMagnitude = e.collision.relativeVelocity.magnitude;

        // If the velocity isn't enough, then we ignore this (to prevent the timeout)
        if( colMagnitude < 0.6f ) return;
...
            PlayAudioSpank(spkclip,0.85f,1.15f);
...
}
 
It seems like spank reaction sounds also prevent the "ask for more" one liners to be played. Maybe one liners should take precedence over further spank reactions?
 
> No. They both play.
I don't get any one liners when spanking repeatedly in short intervals. I need to pause or she won't speak. Already playing one liners are cancelled by further spank reactions, too.
Some of the sounds should probably be excluded during blow jobs, as well.

Short interval:


longer interval:
 
You have two approaches when it comes to a discussion around a plugin:
  • Either you feedback/ask with a video (just like you did) and I can answer you.
  • Or you look at the code (like you did above) and you don't half ass the look up and try to understand it :p

When a reaction is triggered it's using the "Immediate" behavior. ANY sound, will be stopped.
Then behind that a oneliner is buffered. If anything is trying to do an "Immediate" while the oneliner gets picked from the pool, it will be stopped too.
This is how I imagined it, this is how I played with it and how I feel it's working best "out of the box".

At this stage, it's not a bug, it's a design choice. And the moment I'd consider changing the system, It's a 50/50 chance to get someone go "I liked the old one better" ( trust me, I had the case often enough around here to know it :p ).

For blowjobs, consider the "auto-system" like a "noob convenience". We were discussing about that yesterday with a friend from the community... and VAMM2 is not going to become an automated behavioral system.

If you plan on making advanced implementations of VAMM2, you are expected to script the behavior manually. Because I will never be able to please everyone with a behavior system. Everyone will have a specific case and would want it to work in VAMM2, and I'm not gonna go down this rabbit hole.

On the other hand, if you need potential flags/controls that could be helping for manual scripting, I'm not against improving that! Suggestions are always welcome.
 
Edit: btw, you made me realize that there's a potential bug with the super fast slap where one liners could get buffered too fast and the girl would speak a bunch after you stop slapping. I need to investigate that.
 
Or you look at the code (like you did above) and you don't half ass the look up and try to understand it
Maybe I'd have a better understanding of the code if it wasn't one humongous class with 4500 lines of code ;). I'm not blaming you or going to argue about it, though. I'm nothing but a visitor to your castle and it's up to you to take or disregard any feedback. Your plugins are a cornerstone for the community and all I want is to give something back.

I understand the design in regards to immediate playback and queued reactions. However, it seems quirky behaviour to interrupt a voice line in the middle of a word to play a reaction sound.

Regardless of whether the BJ state is handled by the "noob" convenience feature or through manual control, it would be a cool addition to the plugin if there were muffled sounds or at least a system that prevents playback of sounds, which require the mouth to be free.
As of now, there's no way to trigger moans or reactions with a distinction between "mouth full" or "mouth free" states, if that makes sense.
 
However, it seems quirky behaviour to interrupt a voice line in the middle of a word to play a reaction sound.
To iterate on this, I agree that there are arguments for both approaches.
Imagining how it would play out in reality when someone's spanked while speaking, it would probably create a short hesitation before the next word and a change in volume.
Modeling such a beviour isn't easy. Volume modulation could be experimented with but the results may disappoint.
 
However, it seems quirky behaviour to interrupt a voice line in the middle of a word to play a reaction sound.

Not really. That feature actually brought several of us to tears (laughing of course) when we were playing with it during playtests while I was developing it. The sheer laugh you get from slapping the character mid sentence and her reacting immediately is very nice.

And if you combine that with the "hyper realism" of the slap sound, it's only logical that she could go "please gimme mo...OUCH!". This is my aproach as a sound designer and I think it works perfectly fine and makes me laugh (and apparently not only me ^^).

Also it was out of the question to potentially have "acted" sentences that would work with that, the work involved would be insane, and you do speak about that in your subsequent answer.

Yeah volume automation is a no-go. It always sounds weird. Also since there's only one way to control the volume in Unity sadly... it could counter-act automations made by the creator which could result in an even weirder behavior.


As of now, there's no way to trigger moans or reactions with a distinction between "mouth full" or "mouth free" states, if that makes sense.

You mean "sound wise" ? Like a library of "full" sounds?
Or scripting wise?

For the library aspect, not gonna happen. The level of quality we get with Meshed for VAM 2 is expensive. Extending it to anything else will bump up the price. Also, very intensive sounds (straining on the voice) cost even more. We will most certainly stay at that level of detail.

For the scripting aspect, you could. You have mouth/throat triggers. You could build a whole logic handling what a creator would wanna do. Probably not "VAM vanilla" (it would require coding)... but probably doable.

The thing is, again, diving into that is a rabbit hole. So, since 98% of scenes, don't even use VAMM to it's full capabilities (even just, using it properly with details and scripted randomization), this is something I would leave to someone dedicated enough to create a plugin that handles that aspect and drives VAMM/VAMM2... for the probably ultra niche, 3 scenes meant to handle "dynamic mouth full situations" or whatever you can imagine.

In a normal situation (ie: scripted/arbitrary), VAMM2 offers pretty much everything you need to control a coherent state even for that situation as long as you're in a controlled animation.

Unless I'm missing what you are expecting. ^^
 
Yes, adding a full set of muffled sound variations would be quite extensive and add cost.
The current bundle already has sounds, which work fine with a stuffed mouth but many don't.
In terms of scripting, tagging these and preventing playback when vamm is set to the BJ state is feasible. It would have to be a feature of vamm since you wouldn't want the external script or trigger logic in a scene to decide which exact clip vamm should play.

In a normal situation (ie: scripted/arbitrary), VAMM2 offers pretty much everything you need to control a coherent state even for that situation as long as you're in a controlled animation.
To some degree. You could prevent moans and voice lines from playing altogether while there's something in her mouth but you couldn't, let's say, make it play "mmmm" sounds but prevent "aaaahhhh"s or gasps.
 
In terms of scripting, tagging these and preventing playback when vamm is set to the BJ state is feasible. It would have to be a feature of vamm since you wouldn't want the external script or trigger logic in a scene to decide which exact clip vamm should play.

So you're saying that, more or less, you put the girl in BJ state and something else tries to trigger/schedule let's say "moans"... and you'd want the state to prevent this.

But this goes against my initial idea/design philosophy. Which is "freedom to the creator". There's a priority to scheduling that "overrides" the state so that you can do whatever you want even in a specific state. It's the opposite of what you're saying. Because I exactly knows where it's going... if I decide to lock some freedom, someone else will ask for exceptions because his/her situation requires so.

So the best I could do if I did find that situation very critical beause a ton of people requested it... is a flag to behave like this, but opted-out to preserve legacy behavior.


You could prevent moans and voice lines from playing altogether while there's something in her mouth but you couldn't, let's say, make it play "mmmm" sounds but prevent "aaaahhhh"s or gasps.

You can also use the lip/mouth/throat trigger in the character, add state changes to VAMM2 this way and playback whatever you want :p
Again: freedom.

There's a feature coming soon with groups system through VA. You could script a lot of stuffs with this.
 
So you're saying that, more or less, you put the girl in BJ state and something else tries to trigger/schedule let's say "moans"... and you'd want the state to prevent this.
Not exactly, I wouldn't want to prevent moans from playing but limit clip selection to those, which make sense with a stuffed mouth.

I'm fine with external control but unless I'm missing something essential, there isn't a way to trigger playback of specific clips.
Yes, I can use collision triggers or known pose changes as a control mechanism but how would I go about limiting the moaning sounds to a subset?
 
Back
Top Bottom