How can i turn this off
you can't because it's locked on purpose, it's necessary for plugin functionalityHow can i turn this off View attachment 568491
sorry i worded it wrong...i meant to say only the bulge doesn't work after a while. I dont toggle the plugin on or off before the bulge stops working. Ive updated to v25 and its still the same. Anyone else ?this is likely because of a bug that occurs if you toggle the plugin off & on, it is fixed in the upcoming v24 update. soon to be posted
i couldn't recreate the problem, can you send me the scene file you're having problems with?sorry i worded it wrong...i meant to say only the bulge doesn't work after a while. I dont toggle the plugin on or off before the bulge stops working. Ive updated to v25 and its still the same. Anyone else ?
-- Fixes & Improvements:
- Optimized heap memory usage to 0.1MB/s~ down from previous 0.2MB/s~.
- Fixed Optimized Mass & Friction from getting applied to male atoms via detecting male hands or tongue, should only apply through detecting gens.
- Refined Collision filter list in deep penetration (Restored normal collision with some Thigh colliders to prevent clipping for CUA penetrators)
- Optimized performance to 0.2ms ~ down from previous 0.5ms ~ in frame time.
** Not directly backwards compatible, needs .cs to .cslist rename in scene save .json file. **
-- New Features & Improvements:
- Re-Designed plugin UI with collapsible header menus, their state can be saved & restored with presets.
- Added tooltips system to all UI elements for a cleaner UI look, now the info texts only show on hovering upon UI elements. (can disable in advanced tab)
- Split visual...
Skynet, its a bit awkward but you can use the original .cs file and a stub/loader for your new .cslist to allow old save files to still load without user modification.Skynet updated Orifice Dynamics with a new update entry:
update v27
Read the rest of this update entry...
hmm interesting, i didn't know this work around existed. i might look into it for future updatesSkynet, its a bit awkward but you can use the original .cs file and a stub/loader for your new .cslist to allow old save files to still load without user modification.
I had to do this with VAM_Decal_Maker.cs
- The stub CS file stores the old save json
- Checks if the cslist version has been loaded
- Adds the cslist addon version
- Sends savedata to the cslist version
- Removes the *.CS stub file from the addons list
-- Small Addition & Fix:
- Added custom "Mouth Open Wide 1 Custom" morph to fix lip sync / jaw drive from sound, plugin will now drive it's own unique custom morph without conflicts with other plugins like vammoan or bodylanguage that use the vam native "Mouth Open Wide" morph for example.
you're welcome, here you go:hello @Skynet do you mind sharing your in game settings about the physics . thanks.. Best plugin ever
It's not possible for now as it is important for the plugin to work correctly, in future updates this will no longer be the case thoughCan you unlock these two options, especially the second one? Some people have poor computer performance and need to turn off software physics to get more frames per second
View attachment 576550
Since this update impacts several scenes I've released, I looked into what is being suggested and got the following (hopefully it helps) - — Preserve the slot numberInstead of removing the stub and adding the cslist as a new slot, have the stub replace itself in-place by writing directly to the same plugin slot index it currently occupies. This keeps the slot number stable. - the stub should overwrite its own slot entry rather than delete + append. In VAM's plugin system, if you can get a reference to the MVRPluginManager and directly set the plugin at the existing index, you avoid the slot number churn entirely.hmm interesting, i didn't know this work around existed. i might look into it for future updates
Edit: i just tried your method to migrate and it worked, but i noticed it removes the plugin slot it was originally loaded in and creates a new plugin slot. i can see this potentially causing problems for timeline triggers or animation targets or triggers in general that depend on the exact plugin slot number to work, unless i'm doing something wrong?
yes i have tried to do that but with no luck, the method in MVRPluginManager that can add plugins with a defined slot ID is unfortunately protected and can't be called from plugins.Since this update impacts several scenes I've released, I looked into what is being suggested and got the following (hopefully it helps) - — Preserve the slot numberInstead of removing the stub and adding the cslist as a new slot, have the stub replace itself in-place by writing directly to the same plugin slot index it currently occupies. This keeps the slot number stable. - the stub should overwrite its own slot entry rather than delete + append. In VAM's plugin system, if you can get a reference to the MVRPluginManager and directly set the plugin at the existing index, you avoid the slot number churn entirely.
not really as there hasn't been any considerable change to the plugin functionalities, i think most can handle a .cs to .cslist rename in notepad just fineI'm wondering if this new iteration should be like a Orifice Dynamics 2 with it's own page, and then put this one back to the last version before the break. This way older scenes work still and new ones can use the new version?