• Happy Holidays Guest!

    We want to announce that we will be working at reduced staffing for the holidays. Specifically Monday the 23rd until Jan 2nd.

    This will affect approval queue times and responses to support tickets. Please adjust your plans accordingly and enjoy yourselves this holiday season!

  • Hi Guest!

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

    Details about the security patch can be found here.
Fluids 101

Plugins Fluids 101

Love this plugin but i've got a q! Is there a way to not only have random spray duration, but random number of times? I want there to be a random chance of a squirt upon orgasm, rather than it always happening.


I would use Logic Bricks for that. "Random Choice" should do the trick:

 
Love this plugin! Super appeciate that you've kept something as great as this free for all to access!

I did also have a question regarding the particles sticking in the air, I looked to see if there were any person colliders interfering but that wasnt the case.

It seems like the particles bounced off the body and then got stuck for some reason?
1703726106615.png
 
Hey, total noob here. I had some scenes with dependencies named as
hazmhox.fluids101.7 hazmhox.fluids101.9 hazmhox.fluids101.10 hazmhox.fluids101.11

So I was wondering if keeping "11" one would work for all scenes or do I have to keep them all?
 
Hey, total noob here. I had some scenes with dependencies named as
hazmhox.fluids101.7 hazmhox.fluids101.9 hazmhox.fluids101.10 hazmhox.fluids101.11

So I was wondering if keeping "11" one would work for all scenes or do I have to keep them all?
You can delete all others and only keeping 11 should be fine. (y)
That should be the case for all downloaded packages. But if anything goes wrong, you can always download older versions from the history page which you can find on all the hub hosted resource pages.
 
You can delete all others and only keeping 11 should be fine. (y)
That should be the case for all downloaded packages. But if anything goes wrong, you can always download older versions from the history page which you can find on all the hub hosted resource pages.
Thanks a lot. I was a bit confused as VAM downloaded newer version without removing older one.
 
Yup it does not handle versioning. Thank you @Femcore for helping!

@Krikit I work very carefully and try to keep legacy compatibility, so you're safe to keep only the last version, especially in the case of Fluids101 : )
 
@hazmhox, I notice the particles are always additively blended into the scene, regardless of the shading setting (lit or unlit). Any chance you could make the blending mode configurable as well? 'Emissive' particles look a bit odd, especially in darker scenes, or when colored.

Appreciate the effort you put in!
 
@hazmhox, I notice the particles are always additively blended into the scene, regardless of the shading setting (lit or unlit). Any chance you could make the blending mode configurable as well? 'Emissive' particles look a bit odd, especially in darker scenes, or when colored.

Appreciate the effort you put in!

They're are sremi-transparent yup.
I'm not sure I'm gonna dive back into that before a while tho, I have a lot of things to do for VAM :(
 
I used this in Get Her Pregnant for Milk Squirting...

I noticed when I set the fluid to be white they come out a bit yellow. Which I guess raw fresh breast milk can be slightly yellow. :)

Do you know of any possible way to get it to be more white like organic store bought grocery store milk? Thanks. :)
 
Last edited:
Hi hazmhox, I'm having a problem with personfluids (person plugin on its own) not saving changes to the scene. Whenever I load a scene, the plugin resets to its default.
 
Little changes to allow AlternativeFuta person fluids switching to male one
Open your scene depending fluid101 var by 7zip or something, and substitute Custom\Scripts\Fluids101\Person_Fluids.cs by the following attachment.
and restart vam, load your scene, select your bebe, reload the PersonFluid plugin and goto it's settings, Check the "Penis Cum" option, now she finally shoots jizz!
Hopes that helping somebody.
 

Attachments

  • Person_Fluids.cs
    35.2 KB · Views: 0
Hi hazmhox, I'm having a problem with personfluids (person plugin on its own) not saving changes to the scene. Whenever I load a scene, the plugin resets to its default.

I missed that! (there are some issues with notifications :/)
Can you give me more details?


Little changes to allow AlternativeFuta person fluids switching to male one
Open your scene depending fluid101 var by 7zip or something, and substitute Custom\Scripts\Fluids101\Person_Fluids.cs by the following attachment.
and restart vam, load your scene, select your bebe, reload the PersonFluid plugin and goto it's settings, Check the "Penis Cum" option, now she finally shoots jizz!
Hopes that helping somebody.

I'll check this out! Maybe I can handle it into the plugin release itself : )
 
Hey there! First off this plugin is fantastic, thanks for going through the effort of developing and maintaining it over all the years (and not even paywalled!)

I have noticed the behavior mentioned earlier in this thread, and I have a suggestion for how you might be able to make it more natural, if you would be open to that?

I do know a bit about 3D math and game dev, though I don't work with Unity a lot (and I have no idea how much VAM actually exposes to the plugin system), but I could take a look at the code and help troubleshoot any problems you run into if that would be useful. (Or I could even take a shot at the initial implementation if you're interested.)

The basic idea is:
- Detect when particles hit a collider
- Find the transform root of that collider
- Depending on the "stickyness" parameter, manually adjust the position of the colliding particle by taking into account the collider transform's motion between frames

If the colliders have some sort of "velocity" property, that would make things easier, otherwise you would have to manually compute it by storing a reference to the relevant colliders and taking the difference of their current position from their position on the previous frame (or physics tick, if applicable).

You may also need to transform the collider's current/previous positions into world-space if they're only given in local space (ie multiply each by the inverse of the world-space transform before taking the difference). Once you have the world-space collider position delta, just add that to the particle's world-space position each frame (or physics tick) as long as the particle is still "attached" to the collider.
 
Hey there! First off this plugin is fantastic, thanks for going through the effort of developing and maintaining it over all the years (and not even paywalled!)

[...]

Thank you!

Not a problem at all if you want to experiment, I could then include the suggested code into it sure (but with like a "high quality mode" flag option).

One note tho: the particles behave that way because Unity's particle system is very optimized to ensure proper performances. And even then, the more particles you have, the heavier it is on the scene. For instance, the current particle system in Unity cannot handle more than 255 colliders at the same time... which is why at some point, some particles ignore collisions if the other ones haven't reached the end of their lifetime.

On top of that, I haven't dived into the particle computation itself. I don't know if you can access the current particles and update them on the fly. Two years ago I experimented several things on spawing particles at specific vertices of a model, and the performances were extremely bad compared to the native system who allows you to spawn from a mesh. Either they're doing a very specific caching method on their end or I did use a technic that was ultra bad for perfs. I'm not sure how it would behave if you'd update a particle list every frame.

But you know... you can try! Even tho I see the appeal of it, most of the time an accuracy like that is not needed and I think not much people have seen that side-effect. But I'd be happy to include the feature if you'd come up with something at least a bit ok on the performance side : )
 
So I have looked into a little bit and ran into a couple of challenges.

To update the particles, you need to get the entire particle array from the ParticleSystem component as a copy (it's a ParticleSystem.Particle[], and Particle is a struct). Then if you want to update anything, you have to send the whole array back to the component with ParticleSystem.SetParticles(...). It's not as slow as you would think, but it's not fast either.

The bigger problem is that there's no reliable way to determine which particles are actually colliding with a collider. You can attach a listener for particle system collision events to a game object, but the event doesn't give you a reference to the particle (or an ID or handle or anything like that). I might have some luck searching the array for the particle closest to the collision intersection point. So far I haven't even hooked up to the event system, just looping over all sphere and cylinder colliders attached to Person atoms and looking for a particle that's about the right distance from the collider to be probably colliding. (Not very effective, and pretty slow because of all the iterations and distance checks, but sort of promising as a proof of concept.)

I'll keep messing around and let you know if I can find a way to make it work. Thanks for being open to it!
 
Yea! From what I recall, interaction with particles up until Unity 202x was quite limited sadly :/
 
Back
Top Bottom