Home Artists Posts Import Register

Content

Hello!

New update is ready for download over here: https://www.patreon.com/posts/59323869


Whats New

- More Music for Boombox

Added around 30 more tracks as a result of the music poll. Inspired by GTA I ordered them into "Radio Stations". The music is off by default. To turn it on you have to choose a "Radio Station" first: https://imgur.com/Pm25oE0 

Since you are mostly doomed to my music taste I really hope you will like the tracks!


Fixes/Changes

- Most SFX converted to Audiobundles

This one is pretty big, since it improves loading time and performance. Once again big thanks for this great tip CaseEP!

- Slight adjustments to the choking collision sphere

Made it a bit smaller and moved it more downwards to avoid the choking effects on touching girls face. Its not perfect yet, but I am working on it.



This is all regarding this update. I might put some more time into the music part in the next days, adding more tracks and maybe more "Radio Stations". I kinda wanted to release this update quick, because of the overall improvements.

Also I bugged Emma Fielder regarding the voice commission and fingers crossed I get the audios in around a week from now! I am really pumped to get my hands on them and finally add more voice lines to the scene!

Comments

Mirko James

The scene keeps getting better and better. However i cant start it in vr anymore. My vam just crashes. In Desktop it works fine and other scenes also work fine. Anyone got some tipps?

TGC69

Hey thanks! Regarding the crashes it could be that the scene became more unstable, because I packed the audiobundle files into the scene VAR, to keep everything in one place. I had some crashes aswell, but I thought its more on my side. I will run some more test tonight then and see if it gets more stable, when I put the audiobundle files into a separate VAR or leave them unpacked in a folder. If it is better this way I release an update tomorrow.

CaseEP

"Most SFX converted to Audiobundles - This one is pretty big, since it improves loading time and performance" Cool! Glad the audiobundles are working as intended. But to be perfectly honest, the idea came from MacGruber. SlamT told me about noticable performance drops when he included sound into his scenes - that struck me as odd, since most discussions wrt performance focus on the physics engine, or lighting etc. So I pestered Mac & he recommended packaging large collections of small soundfiles into assetbundles ;)

CaseEP

Oh! Please keep me posted on that one. It could (!) be related to triggers not popolating bcs the triggers are loaded before the audiobundle is finished loading. In fact, this is one part of the reason why I'm trying to update the RandonSoundFromAB.cs plugin to work with text-triggers instead of a stringchooser - not only to make the individual plugin instance more flexible, so you need less instances of the plugin, but also to make the triggers less vulnerable to breaking on load. P.S.: Though, on second thought ... trigger breaking shouldn't lead to crashes? How bg is the audiobundle?

CaseEP

@MirkoJames: Had a qucik look in VR and saw no immediate problems related to the loading of the audiobundles (the CG anims wouldn't activate when loading through the Intro & going to the 'Bed' part, but that's probably smth else). (Though, admittedly 'no problems' is a relative statement in a scene this complex) One thought: The prompt to give "permission to load plugins from a new package might" easily mess with the correct population of triggers on the first load (personally, I use a VarManager that has an option to automatically set that flag for new packs even before firing up VaM) Maybe simply try again?

CaseEP

@TGC: I have some thoughts about how you structure assetbundles and also how you package scripts & the colorcorrect bundle. a) MacGruber said it's not necessary - and possibly counterproductive - to split the audio into too many sub-bundles. The loading-time & performance advantage comes from the assetbundles being loaded once & remaining in memory thereafter. Also, all instances of the RandomSoundFromAB plugin share the same audiobundle in memory - you don't need to be afraid that it's loaded N times if you have N instances of the plugin loading the same bundle. b) Really NOT a friend of having assetbundles/plugins etc in the /Scenes/... pathway (rather than in /Custom/... , where they belong. Or simply referenced from a .var package - afaics, all the scripts you have in /Scenes/... have long been available on the Hub?). Really, really not, just saying. Messes with all kinds of things, not the least with autumatically generated packaging references, either for stuff explicitely derived from your packs, or when VaM auto-generates a reference to them due to [REASONS] only known to itself (Gods, I hate that package manager ...). You should never do that with the audiobundles, please (yes, I know you haven't - just really, DON'T!) - the RandomSoundFromAB has a custom routine for scanning & organizing filepaths that looks specifically for an /assets/ folder and uses that as a breakpoint to create filenames/relative filepaths to populate the playlists with (the audiobundle is itself a package with an internal, virtual folderstructure. On top of that come VaM's relative filepath (relative to [VaM_Root] and the .var's internal structure - maybe I'm overcautious, but I would strongly recommend sticking to the standard folderstructure wherever possible)). c) I think you really want to sit down and have a think about your audiofiles' naming conventions. I've already seen a 'sfx' (or moans?) playlist that turned out to have spoken audio. You're going to hate yourself when you come back in a couple months and "nothing does what's on the tin". Group effects (slaps, wet sounds etc) separately from spoken audio (and music ofc). Group 'mouth audio' separate from everything else and divide them up into effects (sucking etc), moans and spoken audio. Then think of an acronym prefix system for those groups - VaM's stringchoosers have advanced search, you can save yourself tons of time when you create playlists if you have all the moans grouped with different prefix from slaps and naughty spoken lines. As an example, you might want to grab SlamT's Call Girl Bound forPleasure REDUX scene (https://hub.virtamate.com/resources/the-call-girl-%E2%80%93-bound-for-pleasure-teaser-desktop-vr-version.22439/), open it in NotePad++ and search for "Sounds" (those are the 'playlists') - all soundsfiles broken down into groups with custom prefix-code labels. He doesn't need to listen through a 1000 audio file to find the one he wants - simply type the prefix code into the textchooser & only the respective group's files are listed. d Bunch of other, unrelated thoughts - not so enamored with the VRinputThrust as a mover for animations - it doesn't play nice with DiviningRod plugin & int's way worse than DiviningRod at ... errrrh .... "threading the needle". It's also janking the controlnodes around a lot - the easing functions don't seem to 'ease' a whole lot. You might also want to add another softphysics button for tonguecollisions - structure is the same as with boobies (atom: Person, receiver: TongueControl, Value: TongueCollisions ON). You can save some performance by turning this on only during BJs. Also, there's a brandnew BJ morphpack on the Hub that looks WAY better than the old stuff (https://hub.virtamate.com/resources/bj-deluxe.23492/)

TGC69

a) Oh ok thats definitely good to know! I made separate audiobundles just to keep order and track for different audio files. And also for easier adding to the single RNGaudiofromAB plugin instances. I will merge them into a single bundle then, since it should decrease the load this way. b) Hmm ok when it could mess something up I will move the files into the scripts and assets folder. Shouldn't be that hard :) Are you sure that RandomSoundFromAB scans custom/assets folder first and not the custom/sounds folder? Cause I have been about to move the audiobundles into the latter one, cause its the first folder which opens in VAM when I am about to choose the audiobundle from inside the plugin. c) I switched to VRInput's thrust plugin mostly because of "aimbot" so I could make the Anal/Vaginal switch. Been testing SexHelper with DiviningRod and the results were not that great eather. I will see if I can fiddle more with physic settings of the "Rod" so it does not bend too much. I will do that after the audiobundle update though. And I also add the tongue collision toggle then (hopefully I find a place for it somewhere xD) and check the BJ morphs, which looks pretty good judging from pics! Thanks for that one ;D

TGC69

@Mirko James Will need couple more hours for the update. Want to switch to single audiobundle file, since it should decrease the load and make a comparison test between loading from scene VAR and separate VAR.

CaseEP

b) Yeaaaah, just not a friend of it. It'll probably not mess up YOUR scenes, but rather lead to problems further down the line, when other packages refer to files in your packs - it's a bad practise that causes some of the duplication we're seeing. About RandomSoundFromAB: I was specifically concerned bcs your .var has an 'assets' subfolder both in /Custom/ and in '/Scenes/' - Note I'm not sure whether that can mess smth up (it notably didn't cause problems so far). The thing is that there's a class 'Sound' in the plugin that handles filepaths, creates a list of files etc and supports several other functions - and this class treats filepaths differently depending on whether they contain a folder '/Assets/' or not. So I wouldn't confuse it with having several /Assets/ folders. I'm probably worrying too much, though. Not sure what moving the audiobundle to /Sounds/ would do - afaics, when it finds an /assets/ folder in the filepath, the class mentioned above shortens the internally used filepaths, so that /Assets/ appears as root folder. At a guess, moving the bundle from /Assets/ to /Sounds/ might lead to the displayed filenames in the 'playlists' changing - instead of just the sound files' filenames, they might suddenly contain the full path relative to VaM_Root. With the basic version of RandomSoundFromAB, that shouldn't break anything - but with the modded version I'm planning, that could break triggers. That's totally speculation & a bit 'angsting' on my part, admittedly - I just like everything neat & tidy, is all.

CaseEP

c) About tonguecollision: You could simply leave it deactivated by default & trigger it automatically - eg by some event that happens only when the player is running the BJ substation? Eg when 'kneel' button is triggered, or when the AnimationPattern than handles 'Insertion' is started, or when the model's 'mouth' collision trigger is activated? Something like that. Same goes for the 'butt' - trigger. You only really need the lowerphysicsmesh to be active during penetration. So personally, I'd look for a way to trigger activation automatically and keep it off otherwise (not sure whether I'd couple it to the vag collision triggers, though - the 'DeeperVagina' collision trigger seems to activate randomly without insertion for some reason).

CaseEP

Again c) IDK if you have noticed, but the 'aimbot' aiming the PenisBase - controlnode goes crazy wobbly during insertion (and much of the animation). Position is stable, but it's orientation wobbles around a lot. I suspect the reason is that it tries to aim the PenisBase node at the "Labia" - trigger. But since the PenisBase node is moving on a path a bit ABOVE the Labia, that aimbot is starting to have difficulty the deeper the penetration gets, since it's having to point almost straight 'down' - or even a little 'behind'.

TGC69

b) Well imho the one who packs the VAR should look that the whole scene is not used as reference xD But I also agree that it would be better from my side to drop the habit of putting scripts and assets into a scene VAR. I do it out of reasons though (some of which might be a bit stupid xD) I prefer to have everything in one place, which makes working on the scene and VARing it afterwards easier (I have slight fear of forgetting some folder or file while VARing). I don't like VARing stuff from other creators. Thatswhy the loose pubes folder since forever xD (I like these pubes tho ahaha) and some of the scripts. But these are also modded a bit for the scene. Stuff like enviro is inside the VAR is because I am still adjusting it now and then. These are all which come to mind :D Moving the audiobundle file into different folders and making it a separate VAR did not bring any changes (at least I did not notice anything) Been stopping time how long the scene needs to load and how much RAM/CPU load rises and results were pretty much the same. So I left it inside the "assets" folder and packed it into the scene VAR again. Only merged all the bundles into a single file. MacG did it in his life plugin that way, so it must be the right path :) c) Making a trigger to turn it on during BJs would be ezpz. I probably make a toggle and the trigger. Need to make some tests tho if the tongue is not in the way on the "Possession mode" part (so I make the switch if it is) Also I need to check how much it would affect frames. Don't want to autotrigger buttphysics though. It kills frames like crazy (especially in VR). DeeperVag trigger gets activated on doggy positions for buttclaps and turns off on other positions. Hmm not sure what exactly causes the wobblyness. Was a while ago when I did that and I adjusted there a lot. There are timed plugins (blends/delays) which change the positional and rotational nodes on penis base, mid and tip and also several physic settings. So some of these could also cause the bending. Or do you mean insertion on the CG-Part?

CaseEP

Everything except c): Ok, I just wanted you to be aware of my "concerns". I see now that's the case & will stop pestering you about it now. --- Point taken on the vag/butt autotriggering idea - I'd personally prefer not having to fiddle with that as a user, but you're right that coupling the lowerphysicsmesh to the person atom's vag triggers is probably not a good idea, given their tendency to fire randomly. Alternative would be to activate/deactivate lowerphysicsmesh whenever a animation that involves penetration is about to commence ... but that'd involve a lot of editing on your part. --- About c) No, with what I wrote about "the aimbot" I was referring very specifically to the "table" animations (the latest ones you added) I think it was "Missi 1" and possibly "Missi 3" of the table anims. You'd have to select the PenisBase node (so the "handle" becomes active & you have a visual clue where the node is pointing), and play a bit with the inserting slider and/or let the animation play - then you'll see the "wobblyness". Reason is IMO as I stated above - the path of the controlnode lies some 10cm ABOVE the path of the peen (the physical nodes) - as a consequence, the further penetration progresses, the more the aimbot is trying to point the penisbase CONTROL node downwards (at the "LabiaTrigger"), while the actual physical node should be pointing FORWARD, or even a bit UP. At least that's what I concluded from my brief look at it - I might be misremembering and/or make wrong infereences based on my understanding of how the "aimbot" works. My conjecture is mostly based on the understanding that there's only four possible targetson a Person atom for an aimbot to aim at - the Labia Trigger and the three Vagina Triggers.

TGC69

"Alternative would be to activate/deactivate lowerphysicsmesh whenever a animation that involves penetration is about to commence ... but that'd involve a lot of editing on your part" Nah it would be just two more commands in the relays which are linked to the "InsertionOn/Off" buttons. It really is only that I don't want to interfere with players preferences. There are people with more powerful rigs who probably can play with enabled butt soft physics, so stuff like skirts does not clip through the buttcheeks for example. Another group of players prefers to play with buttphysics off all the time for better performance. And lets say there is a third group who likes to activate buttphysics only on penetration. If I do the triggers I would only please the 3rd group. But! what currently comes to mind is that I actually could add a relay, which is linked to triggering the softphysics and let it deactivated on default and make another toggle for it, so if you activate it you would have the softphysics enabled on penetration :) c) Hmm ok I will keep that in mind. Gonna focus on this next then and try to adjust posepresets/physics to reduce the wobbling