Deviously Cursed Loot LE 9.0 (2021-03-09)

[LazyBoot]

1 hour ago, larrylaile said:

Furthermore, it is to note that I do run the FNISGenerator as well as the BodySlide executable each time I install a new mod (just because I do not know which of the mods truly require me to run these two),

You only really need to do this at the end, as far as I know.

 

1 hour ago, larrylaile said:

and that I would select the "BatchBuild" option in BodySlide each time. I would greatly appreciate it if anyone could guide me through the installation process.

Have you looked at this guide? (that goes for you as well @Finallywon)

https://www.loverslab.com/topic/71481-tutorial-building-dd-items-in-bodyslide-nmmmo/

[larrylaile]

1 hour ago, LazyBoot said:

You only really need to do this at the end, as far as I know.

 

Have you looked at this guide? (that goes for you as well @Finallywon)

https://www.loverslab.com/topic/71481-tutorial-building-dd-items-in-bodyslide-nmmmo/

Hi. As far as I have seen thus far, I noticed that Deviously Cursed Loot uses UUNP? If that is the case, do I select the "UNNP" option for all the preq mods that I install before installing Deviously Cursed Loot? Then, do I want"Caliente's Beautiful Bodies Edition - CBBE" or "Unified UNP"? If it's UNNP, then, how do I do it?

 

This is the part that's really confused me here as I'm more willing to bet that the reason why I'm getting "invisible bodies" is purely due to some mishaps when I was installing "BodySlide", as well as the other mods which had check-boxes options that I had to select from.

 

p.s. I uninstalled Deviously Cursed Loot during troubleshooting before and noticed that the bondage gears from Devious Assets etc. still causes my body parts to become invisible upon donning them.

[Laura]

7 hours ago, Finallywon said:

Yeah, I have bodyslide, but what do you mean by selecting the outfits? I have looked through them and they all look right? Thanks for the fast response and I kindaaa have a lot of questions...

I made this a few days ago.

It doesn't go in depth, but building it this way does resolve your issue.

 

You don't have to fiddle with the sliders, you can simple use a preset body like CBBE or UNP.

[Lupine00]

17 hours ago, Kimy said:

I removed it because it was broken, the way it was written. The function obviously assumed that there would be no keys other than the standard framework ones, ever. When enabled, this function destroyed ALL keys, no matter if it was a generic one, or one that had only one copy in the entire game world. If you check my older scripts, I had to write a LOT of workaround code to prevent this function from breaking quests left and right.

I did suspect this was the general kind of problem that had got it killed. I can follow the ethos that DD4 is trying to limit its determination of behaviours, not to mandate a single system of keys, or to make mod-unique keys second class, but it's also apparent that DD4 has not quite completed that journey. It will probably always be, in part, a working demonstration, as well as a framework for other mods. Though you could split those two functions, and split the MCM component and the pre-made items away from the code base that drives them - but Papyrus and the CK are perhaps not the ideal environment for implementing that kind of modularity.

 

From a consumer mod's perspective, fixing broken key consumption is hard to cope with, but from DD4's perspective, surely it's no more complex than checking that the key base is the vanilla restraint key embedded in the DD4 esp? Either you are directly based off that key, or you're not? And only those vanilla DD4 keys would be candidates for consumption. Which was why I alluded to the issue of rare keys being a different case. Typically rare keys get consumed anyway. I don't believe I've actually used any since I sort-of moved to DD4, but I'm guessing that hasn't changed.

 

The thing with DD3 bondage was it was fun, and you could get out of it, but with DD4, the most minor item seems to end up stuck on you for days of (real) play at a stretch, and they become tiresome. The events that were (maybe) immersive, are now sometimes so long that they become a serious annoyance. I end up turning them off, which I never did before.

 

It somewhat devalues the historically tough items, when ordinary ones cause so much bother.

[Lupine00]

Incidentally, on the topic of Bodyslide, if you want to make it "clean" in MO, you have to remove all the pre-built assets from any mod that has them, factor out the ones that bodyslide *never* builds into a static shared mod, and then when you build Bodyslide in a profile, it won't contaminate other profiles.

 

The mods were not set up for this in the first place, and the pre-build assets result in BS modifying the pre-built versions "in place", so every mod that has Bodyslide in it gets changed. Removing all the pre-built assets fixes this, but then you find some things are never built and rely entirely on the pre-builts - so you have to put them back in a clean way. The alternative is having duplicates of mods that have pre-built assets, but this becomes overwhelming eventually.

 

Just a part of the MO learning curve.

[LazyBoot]

33 minutes ago, larrylaile said:

Hi. As far as I have seen thus far, I noticed that Deviously Cursed Loot uses UUNP? If that is the case, do I select the "UNNP" option for all the preq mods that I install before installing Deviously Cursed Loot? Then, do I want"Caliente's Beautiful Bodies Edition - CBBE" or "Unified UNP"? If it's UNNP, then, how do I do it?

Cursed Loot and Devious Devices can use either bodytype. As long as you consistently choose the same one when installing, it's completely up to you what one you choose.

 

35 minutes ago, larrylaile said:

p.s. I uninstalled Deviously Cursed Loot during troubleshooting before and noticed that the bondage gears from Devious Assets etc. still causes my body parts to become invisible upon donning them.

Well, yes, this isn't an issue cursed loot causes, (batch-)building the assets is required for Devious Devices Assets and Expansion as well.

 

Also, see the post from Comrade Laura above.

[LazyBoot]

3 minutes ago, Lupine00 said:

Incidentally, on the topic of Bodyslide, if you want to make it "clean" in MO, you have to remove all the pre-built assets from any mod that has them, factor out the ones that bodyslide *never* builds into a static shared mod, and then when you build Bodyslide in a profile, it won't contaminate other profiles.

 

The mods were not set up for this in the first place, and the pre-build assets result in BS modifying the pre-built versions "in place", so every mod that has Bodyslide in it gets changed. Removing all the pre-built assets fixes this, but then you find some things are never built and rely entirely on the pre-builts - so you have to put them back in a clean way. The alternative is having duplicates of mods that have pre-built assets, but this becomes overwhelming eventually.

 

Just a part of the MO learning curve.

You can just tell bodyslide to output to a folder other than the skyrim data folder, like a "bodyslide output" mod in MO. And it'll keep clean even if a mod has pre-built assets.

As long as you keep said mod near bottom of the list.

[Tyrant99]

27 minutes ago, Lupine00 said:

I did suspect this was the general kind of problem that had got it killed. I can follow the ethos that DD4 is trying to limit its determination of behaviours, not to mandate a single system of keys, or to make mod-unique keys second class, but it's also apparent that DD4 has not quite completed that journey. It will probably always be, in part, a working demonstration, as well as a framework for other mods. Though you could split those two functions, and split the MCM component and the pre-made items away from the code base that drives them - but Papyrus and the CK are perhaps not the ideal environment for implementing that kind of modularity.

 

From a consumer mod's perspective, fixing broken key consumption is hard to cope with, but from DD4's perspective, surely it's no more complex than checking that the key base is the vanilla restraint key embedded in the DD4 esp? Either you are directly based off that key, or you're not? And only those vanilla DD4 keys would be candidates for consumption. Which was why I alluded to the issue of rare keys being a different case. Typically rare keys get consumed anyway. I don't believe I've actually used any since I sort-of moved to DD4, but I'm guessing that hasn't changed.

 

The thing with DD3 bondage was it was fun, and you could get out of it, but with DD4, the most minor item seems to end up stuck on you for days of (real) play at a stretch, and they become tiresome. The events that were (maybe) immersive, are now sometimes so long that they become a serious annoyance. I end up turning them off, which I never did before.

 

It somewhat devalues the historically tough items, when ordinary ones cause so much bother.

My understanding of DD4 is that many of the item difficulties were brought down to a per item level - so they can be configured on an itemized basis. But, if you look at them, they pretty much all extend zadEquipScript, which still has a native function for destroying keys. (A function that can currently can be set on a per item level).

 

To activate it globally so the default for all items is to have the keys get destroyed, you could switch out the Bool Property DestroyKey to True in ZadEquipScript and recompile it:

 

 

And while you're in there, you could change whatever else you want around so it fits more with the playstyle that you want, or acts more like DD3 - as most of the defaults for how the devices work can be found in there...

[Lupine00]

I used to think that maybe the Bodyslide configurations were set up better for UUNP, but it's more a case that some items work better with one body than another, probably because they were originally built for one, then converted to the other. I like the joint folding better on CBBE, but the overall shape options better in UUNP. You also need different textures, as the mappings vary from CBBE to UUNP.

 

In a CD playthrough, I swapped from UUNP to CBBE half way through (using MO) with no problems. This doesn't require a skeleton swap.

In another playthrough, I swapped from HDT, to BBP, without any issues, which does require a skeleton swap.

 

HDT/BBP has to match your skeleton install, and your body type has to match your HDT/BPP choice, but both CBBE and UUNP effectively have both.

However, I found that the UUNP body doesn't map to some BBP nodes correctly, and appears to ignore them .... maybe ... it's not like I investigated very carefully.

The clothing all worked properly though, which made the problem rather obvious - and both body and clothing were batch built together.

[Tyrant99]

18 hours ago, Kimy said:

I removed it because it was broken, the way it was written. The function obviously assumed that there would be no keys other than the standard framework ones, ever. When enabled, this function destroyed ALL keys, no matter if it was a generic one, or one that had only one copy in the entire game world. If you check my older scripts, I had to write a LOT of workaround code to prevent this function from breaking quests left and right.

 

I might bring it back one day, in a way that's safe not to break quests.

 

Seems like it could be solved with Keywords? - Toss a few keywords on different categories of keys i.e.: Zad_GenericKey, Zad_QuestKey, Zad_SpecialKey etc...

 

Then pass it through on your DestroyKey logic something like this:

 

 

Or:

 

 

 

[LazyBoot]

13 minutes ago, Tyrant99 said:

Seems like it could be solved with Keywords? - Toss a few keywords on different categories of keys i.e.: Zad_GenericKey, Zad_QuestKey, Zad_SpecialKey etc...

 

Then pass it through on your DestroyKey logic something like this:

 

I have a feeling this variant would be more likely based on what Kimy said. Though I think I would use || instead of &&, so mod authors don't need to flag their keys as generic to have them destroyed if the items calls for it. It would obviously need to check the mcm to see if a destroy generic keys option is enabled as well.

 

PS, the forum supports code blocks, so you don't need to screenshot code to have it show properly.

[Tyrant99]

10 minutes ago, LazyBoot said:

I have a feeling this variant would be more likely based on what Kimy said. Though I think I would use || instead of &&, so mod authors don't need to flag their keys as generic to have them destroyed if the items calls for it. It would obviously need to check the mcm to see if a destroy generic keys option is enabled as well.

 

PS, the forum supports code blocks, so you don't need to screenshot code to have it show properly.

Well, DestroyKey is a toggleable bool in MCM (or would be if it was brought back), so || (Or logic) would not be appropriate in that particular example as you would want both variables to be true.

 

To cast it to a non-flag, you'd probably do != QuestKey, != SpecialKey etc. so authors could flag their keys that way if they wanted them not to get destroyed, and everything else would get destroyed with no new flags needed.

 

In any case, it's just a rough sketch to point out that passing the logic through should be pretty straight forward.

[LazyBoot]

1 minute ago, Tyrant99 said:

Well, DestroyKey is a toggleable bool in MCM (or would be if it was brought back), so || (Or logic) would not be appropriate in that particular example as you would want both variables to be true.

 

In any case, it's just a rough sketch to point out that passing the logic through should be pretty straight forward.

But DestroyKey is already a property on items, so using that for the mcm value would break compatibility if someone makes a DD4 item using the current feature.

So I expect it would have to be something like

If DestroyKey || (libs.config.DestroyKey && DeviceKey.HasKeyword(zad_DeviousGenericKey))

 

[Tyrant99]

2 minutes ago, LazyBoot said:

But DestroyKey is already a property on items, so using that for the mcm value would break compatibility if someone makes a DD4 item using the current feature.

So I expect it would have to be something like

If DestroyKey || (libs.config.DestroyKey && DeviceKey.HasKeyword(zad_DeviousGenericKey))

 

It's a Boolean property with its default value currently set to False.

 

If you make it toggleable in the MCM, it breaks nothing, just makes the option available to toggle the Boolean.

 

Perhaps you should look at the scripts so you get a better understanding of how it's implemented?

 

[LazyBoot]

3 minutes ago, Tyrant99 said:

It's a Boolean property with its default value currently set to False.

 

If you make it toggleable in the MCM, it breaks nothing, just makes the option available to toggle the Boolean.

 

Perhaps you should look at the scripts so you get a better understanding of how it's implemented?

But your version would still require both DestroyKey and the key to be marked generic. Even if the device itself sets the DestroyKey property to true, it won't break the key unless the mod is updated for the new system. So devices that work now, would stop working with your suggestion.

[Tyrant99]

7 minutes ago, LazyBoot said:

But your version would still require both DestroyKey and the key to be marked generic. Even if the device itself sets the DestroyKey property to true, it won't break the key unless the mod is updated for the new system. So devices that work now, would stop working with your suggestion.

Obviously the mod would need to be updated to integrate the new Keywords etc. (As they don't exist currently) - The very reason why I mentioned it to Kimy.

 

I'm honestly not even sure what you're getting at...

 

Anyway, I've got stuff to do. Bye.

 

[LazyBoot]

18 minutes ago, Tyrant99 said:

Obviously the mod would need to be updated to integrate the new Keywords etc. (As they don't exist currently) - The very reason why I mentioned it to Kimy.

 

I'm honestly not even sure what you're getting at...

 

Anyway, I've got stuff to do. Bye.

What I mean is that currently an item in DD can set the property DestroyKey true, and then any time that item is removed the key used will be destroyed. But your example would also require that key to be tagged with the generickey keyword, therefore breaking backwards-compatibility. And that is something that probably should not be done when it's so easy to not break it.

[Kimy]

4 hours ago, Lupine00 said:

The thing with DD3 bondage was it was fun, and you could get out of it, but with DD4, the most minor item seems to end up stuck on you for days of (real) play at a stretch, and they become tiresome. The events that were (maybe) immersive, are now sometimes so long that they become a serious annoyance. I end up turning them off, which I never did before.

 

DCL quests should be exactly as hard or easy as they were pre-DD4. Nothing in DCL expects you using DD4's overhauled escape system. DCL provides a way out for each and every custom restraint it equips on you. And the standard devices you can influence with DD's built-in difficulty modifier AND DCL's key drop chance sliders. I am not sure I understand the nature of the problem?

[Kimy]

3 hours ago, Tyrant99 said:

It's a Boolean property with its default value currently set to False.

 

If you make it toggleable in the MCM, it breaks nothing, just makes the option available to toggle the Boolean.

 

Perhaps you should look at the scripts so you get a better understanding of how it's implemented?

 

If the user enables it, at a time a quest is running that needs one UNIQUE key to unlock multiple devices, the quest will break, because the feature will destroy the key after the first device, despite it's needed for more.

 

That's the exact reason why I removed the old feature. Some things may look easy on the surface, but are in fact not THAT simple.

[Finallywon]

Alright, found my issue, I had a few meshes and texture that had been remapped by another mod, it just moved where skin was being properly mapped and bodyslide wasn't able to change it. After I deleted it, and re-ran body slide it seems to all be in order. Like I said earlier, I knew it was something I did wrong, but I was looking in the wrong place, I was thinking it had to do with bodyslide or UUNP, it was just some ambiguous addon that I didn't even remember I used. Thanks for the help though everyone, I can't believe how fast people tried to help me.

[lolmods37]

I want to try to add a few items I made to the lists for my own personal amusement, but I can't seem to find the source for the scripts? Am I being blind or is it not available ?

 

Thanks

[Tyrant99]

9 minutes ago, Kimy said:

If the user enables it, at a time a quest is running that needs one UNIQUE key to unlock multiple devices, the quest will break, because the feature will destroy the key after the first device, despite it's needed for more.

 

That's the exact reason why I removed the old feature. Some things may look easy on the surface, but are in fact not THAT simple.

Would this not fix it though in your Remove Device Function?

 

Function RemoveDevice(actor akActor, bool destroyDevice=false, bool skipMutex=false)	
	libs.SendDeviceRemovalEvent(deviceName, akActor)
	libs.SendDeviceRemovedEventVerbose(deviceInventory, zad_DeviousDevice, akActor)
	if deviceInventory.HasKeyword(libs.zad_QuestItem) || deviceRendered.HasKeyword(libs.zad_QuestItem)
		if !skipMutex
			libs.AcquireAndSpinlock()
		EndIf
		libs.Log("Acquired mutex, removing " + deviceInventory.GetName())		
		StorageUtil.SetIntValue(akActor, "zad_RemovalToken" + deviceInventory, 1)
		QuestItemRemovalTokenInternal = True
		akActor.UnequipItemEx(deviceInventory, 0, false)
		akActor.RemoveItem(deviceRendered, 1, true) 
		libs.CleanupDevices(akActor, zad_DeviousDevice)
		if DestroyOnRemove
			akActor.RemoveItem(deviceInventory, 1, true)
		EndIf		
	Else
		libs.RemoveDevice(akActor, deviceInventory, deviceRendered, zad_DeviousDevice, DestroyOnRemove, skipMutex=skipMutex)
	Endif
	If akActor != Libs.PlayerRef
		return
	EndIf
	If DestroyKey && !DeviceKey.HasKeyword(zad_UniqueKey) ; Hypothetical Keyword added to Quest / Special / Unique Keys
		libs.PlayerRef.RemoveItem(DeviceKey, NumberOfKeysNeeded, False)
	EndIf	
EndFunction

 

[Kimy]

Yes, that's pretty much how I will implement it except that I will use a keyword for keys that can be safely destroyed. Otherwise I'd force modders to update the mods, or the feature will STILL break their stuff.

[Tyrant99]

47 minutes ago, Kimy said:

Yes, that's pretty much how I will implement it except that I will use a keyword for keys that can be safely destroyed. Otherwise I'd force modders to update the mods, or the feature will STILL break their stuff.

Just proof of concept. I changed bool in script to destroy keys, then made a unique key with a unique keyword, then rigged up some of my retextured Brothel Mod DD items to use special key. 

 

Tested and all the regular DD stuff the keys would break upon removal, but I was able to use my unique key repeatedly no problem on multiple pieces of gear. So it seems to work great with above script changes. The other thing that occurs to me is maybe doing something with key breaking as well the destroy key.

 

I see why you may want to implement your way, to be nicer to modders (nice of you ). Honestly though, imo it was pretty easy to setup, and I would think that most modders if they were making special / quest DD gear, they would be setting up the script properties the way they wanted for each custom item anyway? You just punch in the key and the keyword for the key - not bad - but your way would be even easier. 

 

 

 

[WaxenFigure]

32 minutes ago, Tyrant99 said:

Just proof of concept. I changed bool in script to destroy keys, then made a unique key with a unique keyword, then rigged up some of my retextured Brothel Mod DD items to use special key. 

 

Tested and all the regular DD stuff the keys would break upon removal, but I was able to use my unique key repeatedly no problem on multiple pieces of gear. So it seems to work great with above script changes. The other thing that occurs to me is maybe doing something with key breaking as well the destroy key.

 

I see why you may want to implement your way, to be nicer to modders (nice of you ). Honestly though, imo it was pretty easy to setup, and I would think that most modders if they were making special / quest DD gear, they would be setting up the script properties the way they wanted for each custom item anyway? You just punch in the key and the keyword for the key - not bad - but your way would be even easier. 

 

 

 

 

 

 

Some mods no longer have anyone working on them so requiring them to change will also require someone to fix mods that get broken.  Since it will be just as easy to implement it in a fashion that doesn't break old mods there's no real reason to use a method that will cause problems instead of fixing them.