• Hi Guest!

    We are extremely excited to announce the release of our first Beta1.1 and the first release of our Public AddonKit!
    To participate in the Beta, a subscription to the Entertainer or Creator Tier is required. For access to the Public AddonKit you must be a Creator tier member. Once subscribed, download instructions can be found here.

    Click here for information and guides regarding the VaM2 beta. Join our Discord server for more announcements and community discussion about VaM2.
  • Hi Guest!

    VaM2 Resource Categories have now been added to the Hub! For information on posting VaM2 resources and details about VaM2 related changes to our Community Forums, please see our official announcement here.
Tripple Barrel BJ

Scenes Tripple Barrel BJ

Download [<1 MB]

Altt

Member
Joined
Mar 8, 2025
Messages
9
Reactions
32
Altt submitted a new resource:

Tripple Barrel BJ - Tiny redhead takes on 3 big cocks

View attachment 563139

she may be small... but she can take a lot of big cock! watch as she downs 3 cocks and takes load after load in this triple barrel blowjob scene with 28 separate animations that flow fluidly. simply load the scene and enjoy!

View attachment 563138






SPECIAL CREDIT AND THANKS TO THE FOLLOWING CREATORS!

QDARO FOR THE AMAZING LENKA LOOK, VERRY STUNNING I HAD FUN BUILDING APON HER!

GIOVNIYA FOR THE AWESOME LIVING ROOM ENVIREMENT...

Read more about this resource...
 
I'm sorry to say, but 179 dependencies for a scene like this is completely out of control. The Sub-dependency list is as long as the direct dependency list. This means you pulled in one thing from somebody else's scene and it pulled in the whole scene. This is called dependency hell. In game, the app only knows how to download everything. Using resources that are not on the hub also means you don't get the benefit of that Hub hosted tag. I'd recommend you look more closely at the resources you use before putting them in a package. The hub has way too many duplicate resources to just click on the first thing you see that looks good. Using a resource that has a lot of dependencies itself causes some of this.
 
I'm sorry to say, but 179 dependencies for a scene like this is completely out of control. The Sub-dependency list is as long as the direct dependency list. This means you pulled in one thing from somebody else's scene and it pulled in the whole scene. This is called dependency hell. In game, the app only knows how to download everything. Using resources that are not on the hub also means you don't get the benefit of that Hub hosted tag. I'd recommend you look more closely at the resources you use before putting them in a package. The hub has way too many duplicate resources to just click on the first thing you see that looks good. Using a resource that has a lot of dependencies itself causes some of this.
ok ill look into that, wasn't sure why mine were so big compared to others and assumed removing referenced dependency's would change or alter the scene. negligent on my part for not trying, appreciate the feedback I'll get that sorted out!
 
Yeah, one of my scenes had a similar problem where the plugin used to make a fireplace flicker was from another scene, not the original author of the plugin. It added about 30 extra dependencies from that other scene till I sorted that out. Good luck!
 
ok ill look into that, wasn't sure why mine were so big compared to others and assumed removing referenced dependency's would change or alter the scene. negligent on my part for not trying, appreciate the feedback I'll get that sorted out!

Please do that - I came here to say the same thing as @SlimerJSpud: This looks very interesting, and I'd be happy to give it a positive review, but ~180 dependencies ... that's the bad old days of "cascading dependencies", when people got together to build the guide Spud already showed you. The first rule is that you need to package on a clean installation - every time the packagemanager tells you it's missing a resource, you copy that resource over to your clean installation. Rinse, repeat. There's other things to learn & pay attention to (in the guide!), but everything follows from that first step.

(Take care that you remove ANY references to packages from wolverine333, cgomes etc - those really badly packaged old stuff that tends to hang around like dustbunnies from hell)



P.S.: (OPTIONAL!) If you know how hardlinks work, additional installations hardly cost any diskspace - about 99% of the size of a VaM installation is from the assets in [VaM_ROOT]\Virt-A-Mate Big\VaM_Data\StreamingAssets\... Those can't be changed except by MeshedVR (and afaics, they haven't been changed in years). That means you can use hardlinks to use the assets from one installation for ALL your installations! So what you do is:
0) Get Link Shell Extension & read the manual (https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html). Congrats! Now you can create softlinks and hardlinks from your context menu!
1) Create a new VaM installation.
2) Go to [NEW_VaM_ROOT]\Virt-A-Mate Big\VaM_Data\StreamingAssets\ and delete everything there.
3) Go to [ORIGINAL_VaM_ROOT]\Virt-A-Mate Big\VaM_Data\StreamingAssets\ and mark everthing there.
4) Right-click, select "Pick Link Source"
5) Go back to [NEW_VaM_ROOT]\Virt-A-Mate Big\VaM_Data\StreamingAssets\, Right-Click, select "Insert as >" > "Hard Link", left-click.

Congrats! Now you have two VaM installations for the prize (ie size) of one!
 
Last edited:
ok ill look into that, wasn't sure why mine were so big compared to others and assumed removing referenced dependency's would change or alter the scene. negligent on my part for not trying, appreciate the feedback I'll get that sorted out!

Yeah, you have TWO old wolverine packages on your installation:
{
"uid": "Wolverine333.maria2_0_2.latest:/Custom/Atom/Person/Morphs/female/AUTO/Nipple Length.vmi",
"name": "Nipple Length",
"value": "0.1172476"
},
{
"uid": "Wolverine333.MIA.latest:/Custom/Atom/Person/Morphs/female/AUTO/Nipple Length.vmi",
"name": "Nipple Length",
"value": "0.5914176"
},

You see how badly those are packaged? Not only is "Nipple Length" a duplicate of a built in morph, it's referenced TWICE, to two different packages. Move both packages (Wolverine333.MIA .... and Wolverine333.maria ...) from your installation, load the look/scene and save again. If memory serves, all the morphs contained in those wolverine looks should also be contained in other hub-hosted morph packages - if Vam doesn't find them in the wolverine333 packages, it will look in other packages & automatically load from there. Then you save again, and the new references get saved.

If there are any morphs you can't find in other packages, send me a PM.
 
Last edited:
Duplicate morphs, hair and clothes are a huge problem. Always try to get the OG version rather than somebody else's repackaged one.
 
Yeah, you have TWO old wolverine packages on your installation:


You see how badly those are packaged? Not only is "Nipple Length" a duplicate of a built in morph, it's referenced TWICE, to two different packages. Move both packages (Wolverine333.MIA .... and Wolverine333.maria ...) from your installation, load the look/scene and save again. If memory serves, all the morphs contained in those wolverine looks should also be contained in other hub-hosted morph packages - if Vam doesn't find them in the wolverine333 packages, it will look in other packages & automatically load from there. Then you save again, and the new references get saved.

If there are any morphs you can't find in other packages, send me a PM.
yeah... I been working on this since spud let me know last night looks like its a lot of what you're saying, morphs within morphs and its pretty much dependency hell, ive created 2 other Vam installs to help with future posts... I'd like to revise and fix the scene above I'm currently working on that now, I also want to further extend my appreciation to you both for the help i may have questions but im hoping to have it solved soon and future posts to be cleaner from the fresh install
 
Yeah, you have TWO old wolverine packages on your installation:


You see how badly those are packaged? Not only is "Nipple Length" a duplicate of a built in morph, it's referenced TWICE, to two different packages. Move both packages (Wolverine333.MIA .... and Wolverine333.maria ...) from your installation, load the look/scene and save again. If memory serves, all the morphs contained in those wolverine looks should also be contained in other hub-hosted morph packages - if Vam doesn't find them in the wolverine333 packages, it will look in other packages & automatically load from there. Then you save again, and the new references get saved.

If there are any morphs you can't find in other packages, send me a PM.
what would yall say a appropriate amount of dependencies for a scene like this should be?
 
what would yall say a appropriate amount of dependencies for a scene like this should be?

Depends on how much stuff you load into the scene - but there are plenty of creators with very complicated scenes, elaborate clothing, dozens of CUAs etcetc that make do with 30-45 deps. 60 at most.

Look at the Dependencies tab of your scene here on the Hub: Scroll way down until you see "sub dependencies" - half of your dependencies are such sub dependencies. That's stuff your scene doesn't need, but it gets loaded anyway, because something in your scene references something from a package (most likely some morph you forgot to zero out), and then all the dependencies of that package get referenced, too. You have like nine WeebUR looks referenced in your sub dependencies - again: SUB dependencies. Stuff your scene doesn't actually need.

WeebU.AltFuta-Aimi.latest
WeebU.AltFuta-Barbie.latest
WeebU.AltFuta-Gigi.latest
WeebU.AltFuta-gina.latest
WeebU.AltFuta-Keya.latest
WeebU.AltFuta-Mira.latest
WeebU.AltFuta-Samantha.latest
WeebU.AltFuta-Tasha.latest
WeebU.AltFuta_Victoria.latest

This is what happens when you package from a dirty installation. Sorry if that sounds harsh, but you have to use a clean installation for packaging, and then disentangle the references step by step. Every time you see stuff where you go "WTF? Why is this in my scene?", you open the scene, go to morphs tab/clothing tab/wherever and check out why this is referenced. Once you've found the origin, you decide "Can I set this morph to zero? Or do I look for an alternative source?". I bet you that 99% of the morphs from those nine WeebUR looks are also contained in the morphpackage WeebUR published. You can use that morphpack an alternative source, for example. That's why people publish morphpacks - so others don't have to reference the presentation scenes from the looks.
 
Last edited:
Depends on how much stuff you load into the scene - but there are plenty of creators with very complicated scenes, elaborate clothing, dozens of CUAs etcetc that make do with 30-45 deps. 60 at most.

Look at the Dependencies tab of your scene here on the Hub: Scroll way down until you see "sub dependencies" - half of your dependencies are such sub dependencies. That's stuff your scene doesn't need, but it gets loaded anyway, because something in your scene references something from a package (most likely some morph you forgot to zero out), and then all the dependencies of that package get referenced, too. You have like nine WeebUR looks referenced in your sub dependencies - again: SUB dependencies. Stuff your scene doesn't actually need.

WeebU.AltFuta-Aimi.latest
WeebU.AltFuta-Barbie.latest
WeebU.AltFuta-Gigi.latest
WeebU.AltFuta-gina.latest
WeebU.AltFuta-Keya.latest
WeebU.AltFuta-Mira.latest
WeebU.AltFuta-Samantha.latest
WeebU.AltFuta-Tasha.latest
WeebU.AltFuta_Victoria.latest

Then there's loads of stuff that isn't even on the Hub - some of it paid-for stuff (like the CuddleMocap package). You can't use that in a free scene.

This is what happens when you package from a dirty installation. Sorry if that sounds harsh, but you have to use a clean installation for packaging, and then disentangle the references step by step. Every time you see stuff where you go "WTF? Why is this in my scene?", you open the scene, go to morphs tab/clothing tab/wherever and check out why this is referenced. Once you've found the origin, you decide "Can I set this morph to zero? Or do I look for an alternative source?". I bet you that 99% of the morphs from those nine WeebUR looks are also contained in the morphpackage WeebUR published. You can use that as an alternative, for example. That's why people publish morphpacks - so others don't have to reference the presentation scenes from the looks.
yea funny u mentioned those i just scrapped those a few minutes ago lol, ive zeroed every morph that isn't actively being used and one package at a time removing most of the sub referenced stuff and dropping everything in a outside folder then deleting it from the vam folder. Then periodically loading the scene back up and making sure nothings breaking. definitely will be using the clean install from now on, lesson learned this is verry tedious lol.
 
Depends on how much stuff you load into the scene - but there are plenty of creators with very complicated scenes, elaborate clothing, dozens of CUAs etcetc that make do with 30-45 deps. 60 at most.

Look at the Dependencies tab of your scene here on the Hub: Scroll way down until you see "sub dependencies" - half of your dependencies are such sub dependencies. That's stuff your scene doesn't need, but it gets loaded anyway, because something in your scene references something from a package (most likely some morph you forgot to zero out), and then all the dependencies of that package get referenced, too. You have like nine WeebUR looks referenced in your sub dependencies - again: SUB dependencies. Stuff your scene doesn't actually need.

WeebU.AltFuta-Aimi.latest
WeebU.AltFuta-Barbie.latest
WeebU.AltFuta-Gigi.latest
WeebU.AltFuta-gina.latest
WeebU.AltFuta-Keya.latest
WeebU.AltFuta-Mira.latest
WeebU.AltFuta-Samantha.latest
WeebU.AltFuta-Tasha.latest
WeebU.AltFuta_Victoria.latest

This is what happens when you package from a dirty installation. Sorry if that sounds harsh, but you have to use a clean installation for packaging, and then disentangle the references step by step. Every time you see stuff where you go "WTF? Why is this in my scene?", you open the scene, go to morphs tab/clothing tab/wherever and check out why this is referenced. Once you've found the origin, you decide "Can I set this morph to zero? Or do I look for an alternative source?". I bet you that 99% of the morphs from those nine WeebUR looks are also contained in the morphpackage WeebUR published. You can use that morphpack an alternative source, for example. That's why people publish morphpacks - so others don't have to reference the presentation scenes from the looks.
what im not understanding is even though ive removed these from my vam folder they are still popping up when i drop the updated version on the hub even though they no longer exist in my save or vam folder, if i drop this var in my fresh install then build the package would that fix this or just bring the problems over?
 
what im not understanding is even though ive removed these from my vam folder they are still popping up when i drop the updated version on the hub even though they no longer exist in my save or vam folder, if i drop this var in my fresh install then build the package would that fix this or just bring the problems over?


Maybe try dnGrep https://dngrep.github.io/ - with that, you can search your whole installation for every reference to a particular morph. And get a good editor: Notepad++ or VSCode are good. In DnGrep, go to Settings > Options > Custom Editor > enter Path to your Editor. Now you can double-click on lines in the search results and your text editor will open the file in question at just that line.

Point dnGrep at the folder you want to search, then search for one package (like eg "WeebU.AltFuta-gina."). (Fiddle a bit with the options - like eg. set search depth to 10 or so, allow it search archives etcectc.)
It'll show you all files where it finds "WeebU.AltFuta-gina.", and it'll show you the line where it finds "WeebU.AltFuta-gina." (Might have to "uncollapse/unfold" the search results if you just see the filenames). Now double click that line. You'll see something like "WeebU.AltFuta-gina.latest:/Custom/Atom/Person/Morphs/blablabla/BiggusDickus.vmi". Then you know that "BiggusDickus" is the morph your scene is using - that is the reason that package is being referenced. Now you can look for an alternative source for "BiggusDickus" - most likely source is WeebUR's morphpacks (here on the Hub somewhere). Or you decide that BiggusDickus can go f**k himself, and you zero out that morph.

Why look for an alternative source/morphpack? Because what your scene is most likely referencing is a presentation scene - a scene with another 20 dependencies of its own. Scenes are bad as sources. What you want is a morphpack - morphpacks mostly have zero dependencies.

Or maybe it's a humdrum ordinary morph like "Nipple Length" or something - loads of people have packages with duplicates from built-in morphs, or morphs contained in common-, Hub-hosted morphpacks like "Spacedog.Import_Reloaded_Lite." or "AshAuryn.Sexpression". Why? Because people are idiots - they unzip morphpacks into their install, forget about them, make some look or scene, and then the unzipped morph gets packed into that scene. Back before the .var system, that was common, so lots of older packages (wolverine333 etc) are built like that. Other possibility is that their scene is referencing such an old, messy, package full of duplicates.

The important thing is that you likely have a (good) duplicate of those ordinary morphs somewhere on your installation - so you can try just removing the offending package and checking whether VaM finds an alternative. One quick way to check that is to point DnGrep to "[VaM_ROOT]\Cache\PackageJSON\" and search for the morph in question - that's where VaM keeps a list of all the morphs it knows about.

It's not an exact science, you have to look a bit. And read the guide posted above. I don't build scenes, I'm just handy with an editor and search tool.

TL;DR:
1) Morphpacks as sources instead of scenes -> that way you get the damn sub dependencies down. Scenes = BAD, Morphpacks = GOOD
2) Get an editor and DnGrep - makes searching much faster, and you can search ALL files in your installation simultaneously.
3) Read the guide.
 
Last edited:
Also check clothes and hair. Many times, a scene creator will package an item with their scene just for their own convenience, and to avoid having the scene break if the resource gets pulled down. This makes for a ton of duplicates. For every item of hair and clothing, verify that it comes from the bare resource, not somebody's scene that also references it. There's also a Python script to list all dependencies. I made an update to it. I use this almost daily...
 
Back
Top Bottom