void CharacterEvents(object o, CharEventArgs e)
{
SuperController.LogError(DateTime.Now +" PluginState CharacterEvent " + e.eventName);
switch (e.eventName)
{
case "GpuTextureData":
//texture data for character has been stored
Data.InitRenderers(CharacterState);
break;
case "_isMale":
PluginSettings.IsMale = e._isMale;
break;
case "_uvSetName":
PluginSettings.UVSetName = e._uvSetName;
break;
}
} this.request = request;
loaded = true;
SuperController.LogError("Decal Maker assetbundle loaded and ready " +DateTime.Now);
} public void Destroy()
{
AssetLoader.DoneWithAssetBundleFromFile(path);
//request = null;
loaded = false;
SuperController.LogError("Decal Maker assetbundle unloaded " + DateTime.Now);
foreach (GameObject obj in InstancedObjects)
{
GameObject.Destroy(obj);
}
InstancedObjects = new List<GameObject>();
} void CharacterEvents(object o, CharEventArgs e)
{
SuperController.LogError(DateTime.Now + " BaseREnderer CharacterEvent " + e.eventName);
switch (e.eventName)
{
case "GpuTextureData":
//texture data for character has been stored
//Debug.LogError(DateTime.Now+" BaseRender GpuTextureData " + e.daskin?.name + " " + e.dAZCharacter?.name);
IsDirty = true;
break;
case "_uvSetName":
SetClipAction();
break;
}
} public void Update()
{
SuperController.LogError("OnLateUpdate()");
if (IsDirty)
{
SuperController.LogError("IS DIRTY!" + _MaterialSlot + " " + _TextureSlot);
if (!Processing)
{
dirtyTimeStart = dirtyTime;
Processing = true;
StartCoroutine(ApplyChanges());
}
}
}Im not sure what you are asking?
Not active in Beta 2.5Thank you for your response. I think these would make more sense in an info-level log rather than an error log. In fact, aside from errors caused by the failure of a specific operation or function, it might be worth considering moving most error logs to info logs, as people who truly care about this information usually know how to find and interpret it. For most casual users, error logs only cause unnecessary alarm.
JSON:void CharacterEvents(object o, CharEventArgs e) { SuperController.LogError(DateTime.Now +" PluginState CharacterEvent " + e.eventName); switch (e.eventName) { case "GpuTextureData": //texture data for character has been stored Data.InitRenderers(CharacterState); break; case "_isMale": PluginSettings.IsMale = e._isMale; break; case "_uvSetName": PluginSettings.UVSetName = e._uvSetName; break; } }
These asset load/unloads were using SuperController log by mistake and will be fixed next release.
Also not active in Beta2.5
Hi Chokaphi, thanks again for your hard work and the effort you put into this plugin, it cannot be overrated for the potential if brings to VaM!
I am currently updating the links in my plugins (Realistic Foreskin & Erection) to use your new version and noticed that on alt futa (with Stopper's plugin), DM loads female settings (of course, because they are females). I think the female base is correct for altfuta too in terms of all other slots, but we would need the male genitals slot instead of the female one. Sounds easy, but I am sure there are complications... However, would you consider it possible to add a special detection rule for alt futa, to load the male genitals slot? I think there would be a small community you made very happy
Detection of altfuta "gender" can be done quite easily on plugin load (however, with some delay to await Stoppers plugin) based on being female and having penis colliders: isFemale = geometry.gender == DAZCharacterSelector.Gender.Female; and e.g. detecting "AutoColliderGen3bHard".
I know you have lots of other stuff to do, and do not feed pushed, just allow me to ask please. Thanks and keep up your fantastic work!!
I will have to look at what the textureID used for AltFutas are using. VAM renders using mesh regions rather than 1 mesh per texture. Example the Face texture has 3 ID's, one renders the face, one the lips, and one inside the nostrils. ID 2, 5, 11 and these ID's are not the same between Male and Female characters, they differ on the Torso, limbs and Genitals.Hi Chokaphi, thanks again for your hard work and the effort you put into this plugin, it cannot be overrated for the potential if brings to VaM!
I am currently updating the links in my plugins (Realistic Foreskin & Erection) to use your new version and noticed that on alt futa (with Stopper's plugin), DM loads female settings (of course, because they are females). I think the female base is correct for altfuta too in terms of all other slots, but we would need the male genitals slot instead of the female one. Sounds easy, but I am sure there are complications... However, would you consider it possible to add a special detection rule for alt futa, to load the male genitals slot? I think there would be a small community you made very happy
Detection of altfuta "gender" can be done quite easily on plugin load (however, with some delay to await Stoppers plugin) based on being female and having penis colliders: isFemale = geometry.gender == DAZCharacterSelector.Gender.Female; and e.g. detecting "AutoColliderGen3bHard".
I know you have lots of other stuff to do, and do not feed pushed, just allow me to ask please. Thanks and keep up your fantastic work!!
Thanks! I would expect the identical textureIDs from the male system to work on the (female) alt futas, because Stopper just adds male geometry. Just a guess though!
that would be a really benefit for some 3 Dimensional decals. To place manually all the three layers exactly above each other is a little bit tricky. I thought something like grouping/linking together across the layers, like the actually already existing grouping method inside each layer, but even with the movement and scaling etc.
It is not hard to implement on the backend, just remove the region filter that generate the list of selectable textures and add monitoring for the move, translate scale events in the Link Observer. Making the UI will be more effort because you do not want the same events for cross texture types links.that would be a really benefit for some 3 Dimensional decals. To place manually all the three layers exactly above each other is a little bit tricky. I thought something like grouping/linking together across the layers, like the actually already existing grouping method inside each layer, but even with the movement and scaling etc.
Actually i am backing such items, if i want to use it more that one time, as clothing. And even if i have to move the decal with all the textures, then i can move it at the dirty way in the clothing textures tab. At least I have everything on one page there, but i dont want to bake for every decal an own clothing item.
But anyway, decal maker 2 is a big step forward to the next level. I am happy about it, that you started the development for decal maker 2. Right now, it seems that the already existing features works as designed and you already fixed the bugs.
The slider currently maxes at one but you can enter higher values in the entry box. I may go back with the normal sliders having a -10 to +10 range or mimic VAM witha multiplier
Please add this again, because you currently cannot trigger from externally more than -1/+1 (even if you can enter more inside your plugin!
