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

[Loki15kun]

I also used the destroy key option, with high drop chance. It is something really interesting.

But unfortunately it fucked with all quest keys, really easily.

Hopefully a good way for it to work can be created some day, without requiring tons of workarounds for modders.

For now the slave sets and the unique restraints from DCL can simulate it

 

[Slagblah]

3 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.

 

Probably what you need then is a "UniqueKey" keyword, which can be applied to any key that should be excluded from the consumable keys function.

[Rogwar002]

Great. Now I feel bad, because I replied to a post. I feel like having blamed Lupine00. I didn´t meant to.

I´ll keep my blabbermouth more shut in future.

 

Sorry

Rogwar

[Kimy]

10 minutes ago, Slagblah said:

Probably what you need then is a "UniqueKey" keyword, which can be applied to any key that should be excluded from the consumable keys function.

*nod nod* That's how I will implement it, except that I will use a keyword for keys that CAN be consumed, so I don't break backwards compatibility!

[WaxenFigure]

14 minutes ago, Kimy said:

*nod nod* That's how I will implement it, except that I will use a keyword for keys that CAN be consumed, so I don't break backwards compatibility!

Call it a key that when used to unlock a device cannot be removed from the device unless it is reequipped.  If you have only one key of the type you can remove anything the key fits but only one of them at a time.

 

This might be a bit hard to code though since you'd need to keep track of which unequipped items held keys unless you simply assume that any device not locked on someone has the key in it to start with.

 

 

[Finallywon]

So I am pretty bad at this, I can't get a few of the outfits to appear, they just make my character invisible. Any idea how I can fix this, I am 100% sure it's my fault, but I don't know how to fix this. I have everything up to date with the most recent version, I tried redownloading everything, but should I allow Cursed Loot to override the Devious device integrations? Any solutions would be greatly appreciated!  

[fred200]

1 minute ago, Finallywon said:

So I am pretty bad at this, I can't get a few of the outfits to appear, they just make my character invisible. Any idea how I can fix this, I am 100% sure it's my fault, but I don't know how to fix this. I have everything up to date with the most recent version, I tried redownloading everything, but should I allow Cursed Loot to override the Devious device integrations? Any solutions would be greatly appreciated!  

Quick question: Did you run Bodyslide and select all the outfits?  Bodyslide is pretty much required for mods these days - much like FNIS.

[Finallywon]

5 minutes ago, fred200 said:

Quick question: Did you run Bodyslide and select all the outfits?  Bodyslide is pretty much required for mods these days - much like FNIS.

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...

[Finallywon]

Pretty sure it is something broken with UUNP, but I have no idea how to fix it

[fred200]

3 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...

Start Bodyslide, select Filter by Group dropdown. Choose Groups. Then it is safe to choose everything. Finally, click Batch Build and let it do it's thing.

Batch Build will present a more specific list of outfits. Choose what seems appropriate. Click Build button in Batch Build dialog. Done.

[larrylaile]

Hi! I'm having similar issues as well! It all occurs when I equip some of the "Devious Devices" items (for example, the hand bindings would have my hands go invisible, vice versa for the leg bindings and full body harness). I'm not sure if it's because of something I did during the installation process. For example, I'm presently using the Nexus Mod Manager to install my mods; and for some mods, there would be "pop-ups" coming out during the installation process where I would have to select an option(s) (check-boxes beside an item I would have to select in order to proceed with the installation), and I would not know what I should be selecting since I am fairly new to modding. Thus, I was wondering if I selected the wrong check-boxes across all the mods which led to my character's body turning invisible.

 

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), 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. I have been trying to install this mod properly for a few days now, reinstalling a total of 6 times and looking up ways to fix the problems online but to no avail (which clearly shows that I am really unskilled and new at modding). Cheers.

[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?