What do you mean by the asset being blank? What are the exact repro steps, this is a bit too vague for me to test anything. Can you share the scene+subscene?
Hello, author.
Yep I'd need more exact steps to reproduce this, since it works fine for me when I test it. Images would be ideal. I created a sub-scene with one character and one dildo, saved it, a new blank scene, added subscene to it, loaded my previously saved subscene, everything works as expected. So you must be using different workflow/steps when either creating the subscene, or when adding it to a new scene.
Hello, author~
Do not try to modify the demo scene. It's using a custom script that expects objects to be named in a certain way.
hi sorry for the late reply, I just use the default settings for dildolanguage and I make my own scenes and animations including penetration using timeline, i dont know if youre suppose to use it in timeline.
Personally I never use timeline for penetration, also I never turn off soft physics, so it's hard to tell. It should work no different from the builtin dildo, in the end it's just a bunch of capsule colliders connected by joints. Does the builtin dildo not cause issues if you turn off soft body physics or move it fast balls-deep, when you resize it to similar girth? I don't really see what could be different. Timeline more-or-less moves objects to the target positions forcibly, so I can see this causing issues with when it forces multiple colliders into each other. Unless it has certain hacks for the builtin dildo to make it behave better...
I just had a language issue, and I apologize for that.
The errors on the screenshot are from the demo scene plugin, they are not related to the subscene problem and were most likely cause by renaming the scene, or making other changes to it.
Unfortunately, I don't think I can do anything about that. It seems to be a VAM problem, not DildoLanguage problem.
Thank you for your response~
That's something I'd like to do, but not now. It would certainly not be a "micro" tutorial. Setting up the colliders and joints is just one of several steps required to make dildo CUA compatible with the plugin. I believe I described the situation in more detail near the beginning of this thread, but in short: the bones need to be setup and named certain way, same for the rigidbodies and colliders, the toys need two UV maps (one traditional unwrap, another for detail/pattern textures), the CUA must use my own custom shader (I'd have to share the sources), and few smaller things.
I wasn't initially, looking to make cua's that are plugin compatible, but was mainly interested in the CUA their physics settings in general.
The plugin tweaks few properties of the dildo when it's attached to it, for example the joint between the dildo's root and the CUA atom's object. And few less important settings that can't be directly adjusted in the Unity editor. So the behavior is not exactly this same with and without the plugin. But the basic setup should work if you copy my settings. Not sure which assetbundle ripper did you use, maybe it did not export everything correctly.
Trying to get an understanding, why certain CUA spring values, do what they do.
Like how your dildo CUA's behave, when no plugin is loaded onto said atom.
Getting plugin compatibility would only be something to look at in later steps once the creator understand how the hinges/spring are "suppposed" to be set up in the CUA, imo. not something you'd start off with right from the bat as it overcomplicates the entire learning process for an outsider.
As it stands I have never seen a tutorial for vam specifically that outlines what is considered default spring values etc. for physics related objects.
Which makes currently, experimenting with this a very time consuming process, rather then having a kind of "template" or an example project to work off.
I'll keep my eyes out on your project, though I would love to start sooner then later with CUA creation, even if it's just for the sake of taking the time to learn the exact mechanics by following examples.
That's the plan, soon(tm), once the core implementation matures. I don't want to spend time updating two separate plugins while I am still working on the core shaders and behavior.
