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

[tragix]

On 12/27/2019 at 8:02 PM, Hermangk said:

@Kimy Multiple people seem to have had issues with the surrender mechanic and animals.

I found no solutions, so I tried to figure what is wrong and from logs I saw this - I am using Deviously cursed loot 8.3

[12/27/2019 - 10:44:43PM] [DCUR] - Found: wolf
[12/27/2019 - 10:44:43PM] [DCUR] - Processing: wolf. Is Animal.
[12/27/2019 - 10:44:43PM] [DCUR] - Rejected: wolf. Reason: Actor is humanoid creature, disabled in MCM.

It says that Wolf is an animal, but then wolf is rejected because it is a humanoid creature. I had animals and humanoid creatures enabled in MCM.

I took a bit of time today and from code found that Cursed Loot has a bug in it that causes animals to be counted as creatures in the code that prints the rejection message above.

 

The creature check in dcur_library.psc (search "Is Creature") will check if the actor has type creature and does not have type animal.

However the creature check for rejection in the same file (search "humanoid creature") will only check if the actor has type creature and does not check for the animal type.

Basically for animals the code goes to creature code and fails since its executing wrong code.

 

In the main post I read "- You can NOT post or share any patches against this mod without my express permission, unless their sole purpose is fixing bugs."

So to fix the bug here are the changes needed (remove the line starting with - and add the line starting with +), it just adds the animal check:

dcur_library.psc

- if currenttest.HasKeyword(dcumenu.ActorTypeCreature) && (!dcumenu.dcur_humanoidcreaturessexlist.HasForm(currenttest.GetLeveledActorBase().GetRace()) || !dcumenu.sexAllowHumanoids)
+ if (currenttest.HasKeyword(dcumenu.ActorTypeCreature) && !currenttest.HasKeyword(dcumenu.ActorTypeAnimal)) && (!dcumenu.dcur_humanoidcreaturessexlist.HasForm(currenttest.GetLeveledActorBase().GetRace()) || !dcumenu.sexAllowHumanoids)

 

I have included the fixed pex as a hotfix patch in attachment (I have no idea how to compile scripts and failed miserably when trying, so I just fixed it directly to the pex/pas file. Its my first time looking into skyrim files, but I think I fixed it ok). People can replace the pex file that DCL uses with this one to fix the issue.

I also have included as attachment the psc file that has the line change already applied from the above code block.

Would be great to have the issue fixed in the actual mod also.

 

Here are some key phrases for people to find this issue and fix:

Deviously cursed loot 8.3

Rejected: wolf. Reason: Actor is humanoid creature, disabled in MCM.

Allow Animal Creatures

Your attackers seemed to have lost interest in you. Maybe run as long as you still can!

 

dcur_library.pex 317.92 kB · 6 downloads dcur_library.psc 335 kB · 5 downloads

How did you make the fix to the pex file without recompiling?

I ran into this on my own and tried to fix it on my side unsuccessfully. I made the same change along with some log changes for sanity checking, compiled it, dumped the pex in a new mod in MO2, and noted that the old script still ran. Dropping your pex in the same mod folder overrode the original script as expected, so I am clearly misunderstanding how compiled scripts work.

 

Edit:

For anyone finding this in a search, it seems there is some key difference between compiling with the creation kit and compiling with a third party compiler such as Papyrus Compiler Plus. The latter successfully compiles, but there is something missing somehow that (i think) causes the game to load the default script instead of the patched script. 

I'm guessing it might have something to do with esp quests/items/etc referencing the script - maybe there is a script reference ID that is lost when compiling outside CK?

Anyone have some clarification?

[Tenri]

2 hours ago, tragix said:

How did you make the fix to the pex file without recompiling?

I ran into this on my own and tried to fix it on my side unsuccessfully. I made the same change along with some log changes for sanity checking, compiled it, dumped the pex in a new mod in MO2, and noted that the old script still ran. Dropping your pex in the same mod folder overrode the original script as expected, so I am clearly misunderstanding how compiled scripts work.

 

Edit:

For anyone finding this in a search, it seems there is some key difference between compiling with the creation kit and compiling with a third party compiler such as Papyrus Compiler Plus. The latter successfully compiles, but there is something missing somehow that (i think) causes the game to load the default script instead of the patched script. 

I'm guessing it might have something to do with esp quests/items/etc referencing the script - maybe there is a script reference ID that is lost when compiling outside CK?

Anyone have some clarification?

Script properties are applied to an instance of a script in the CK but the compiling of the script wouldn't matter I think.

 

For example the zadEquipScript from DDI is applied to dozens of DD items, and in each device's instance of the script you have to define the properties such as, escape difficulties, messages for each action, the ID's of the inventory and render devices, etc. but even with all those differences you only have 1 zadEquipScript.pex

 

If you want to add, remove, or change the name of, any properties you need to set the changed properties in the CK for each instance of the script, or it won't work.

 

Another Interesting note you can compile with the CK without loading any esm or esp files into it.

[DeWired]

18 hours ago, Lupine00 said:

@Kimy

Found an oddity in yokes added by DCUR: tested extensively with the "Heavy Yoke" 0x26031620

 

This is set/keyworded "BlockGeneric" though I believe it can be removed by the PC with a pair of standard restraint keys - if they can get lucky and reach the locks - which seems a little anomalous. I'd have expected something a little stronger for an item tagged BlockGeneric.

 

While not definitively wrong, this caused some unexpected behaviour in Devious Followers yoke removal scripts.

 

The number of yokes in DCL that are marked BlockGeneric is somewhat crippling the device removal mechanic in DF, which (when working as intended) ultimately leads to you getting in debt and ending up wearing lots of devices. I've yet to trigger a trap and not get a yoke that didn't have BlockGeneric on it. This possible overuse creates a temptation to play ... fast and loose ... with the BlockGeneric keyword. I'm not making any changes in that direction yet; will see what players think about it.

 

Are these blocking devices really intended to be so obstructive?

 

 

Also noticed that the regular DD "Iron yoke" has a steel yoke message and uses fancy steel yoke model, not rusty iron as I was expecting.

Hm. First, there are only two yokes in DCUR, that can be in traps and has blockGeneric keyword - xx031620 "Heavy Yoke" and "High Security Yoke". First have "dedicated" quest to remove "Courier in chains", and second is stated to only be removed by blacksmith. All other blockGeneric yokes are unique, and quest-related (and their removal is handled by quests). One exception is "Imperial guard yoke" from Chloe quest, which has unique key, and can be used after said quest.

Second - as far as I understand it, blockGeneric isn't there to prevent removal by PC - it is there to prevent generic removal by other mods. Which is a problem for you, yes. But right now, it can't be helped: there are some items in DCUR which are definitely quest-related, but without QuestItem keyword.... Oh, and at least one item without even blockGeneric. So, playing loose with this keyword not "can", but will have quest-breaking consequences. Also, some blockGeneric but not QuestItem things are in other mods - namely, Laura's Bondage Shop have one quest-related yoke (that isn't QuestItem) and one unique yoke (with unique key). SLUTS_redux have yokes that are blockGeneric - and their removal outside of quest is also not intended.

Third - fun facts  - "Heavy Yoke" 0xXX031620 can also be removed through dialogue option... using 1 hand restraint key ? Also, quest "Courier in chains", while starting for simple DCUR yoke and heavy yoke, doesn't remove heavy yoke (without patch). And, as I see it, this quest can also be started for XDFF Timed Yoke too... So, I think, all that is a work in progress.

P.S. I believe, that if your implementation of blockGeneric device removal work a) with different and sufficiently bigger consequences then generic, and b) actually check for device identity, not for keywords - it has rights to be. But it's just my opinion.

[Lupine00]

5 hours ago, DeWired said:

Hm. First, there are only two yokes in DCUR, that can be in traps and has blockGeneric keyword - xx031620 "Heavy Yoke" and "High Security Yoke". First have "dedicated" quest to remove "Courier in chains", and second is stated to only be removed by blacksmith.

Quest is pointless then, as it can be removed with standard keys, as I pointed out.

 

I don't question the High Security Yoke. That's supposed to be a big deal.

 

I have in actual play, received the heavy yoke *many* times, and never performed a quest to remove it. Simple repeated attempts with keys will eventually remove it. I replicated that in testing DF about a half-dozen times yesterday.

 

My point here is that if BlockGeneric becomes devalued by over-use, it no longer serves its intended purpose, and people will set everything Quest, which is worse, as it causes impossible to resolve scenario-breaking conflicts.

 

The long list of mods that have mis-configured devices isn't really a rationale for continuing to leave these things unpatched in DCUR or LBS, or wherever, though I'd argue that SLUTS has used the keyword correctly, exactly as intended.

 

If LBS has quest items that are marked as BlockGeneric, it needs to cope with those items being removed, and possibly never replaced.

A player could be ported off to a Things in the Dark scenario that they play for real weeks before returning to continue the LBS scenario.

 

At least LBS didn't use Quest though...

 

I'd argue that best practice suggests that Quest should effectively never be used, or if used at all, only in a narrowly constrained setting where it's firmly believed the player cannot leave the area or the scenario - Dragonar for example - without legitimately removing the item.

 

BlockGeneric should serve as sufficient deterrence for other mods, and the owning quest needs to handle the situation...

 

Cursed Collar? Can only be removed by a god? Removed by a random quest ... never mind ... collar magically gets reapplied the moment the PC gets free of whatever conflicting item they were wearing. That would be Cursed Collar's problem to solve, and not a hard one - periodically check for Quest keyword, see if it's missing, replace item if possible. Maybe pop up a box explaining the collar's magic (excuse).

 

That's not the only way to handle it, but the point is that making assumptions about items being impossible to remove is ALWAYS flawed, will always be flawed, and is a source of impossible-to-resolve conflicts. Mods would get away with it when there were around three DD scenarios, and one of them was built into DD itself. Times have changed.

[DeWired]

51 minutes ago, Lupine00 said:

My point here is that if BlockGeneric becomes devalued by over-use, it no longer serves its intended purpose, and people will set everything Quest, which is worse, as it causes impossible to resolve scenario-breaking conflicts.

 

The long list of mods that have mis-configured devices isn't really a rationale for continuing to leave these things unpatched in DCUR or LBS, or wherever, though I'd argue that SLUTS has used the keyword correctly, exactly as intended.

 

I'd argue that best practice suggests that Quest should effectively never be used, or if used at all, only in a narrowly constrained setting where it's firmly believed the player cannot leave the area or the scenario - Dragonar for example - without legitimately removing the item.

 

BlockGeneric should serve as sufficient deterrence for other mods, and the owning quest needs to handle the situation...

 

That's not the only way to handle it, but the point is that making assumptions about items being impossible to remove is ALWAYS flawed, will always be flawed, and is a source of impossible-to-resolve conflicts. Mods would get away with it when there were around three DD scenarios, and one of them was built into DD itself. Times have changed.

Problem is... what are those "intended purposes"? Please, point me at some doc where they are explained, because so far I am only guessing about those keywords. As such while I was writing this post, I changed my opinion about 3 times arguing with myself... Last edition - 1. using "safe to manipulate with generic functions" as guideline, 2. "Courier in chains" can't work with blockGeneric - 2 points for Heavy Yoke to drop blockGeneric. And possibly switch to using hand restraint key.

 

[Tenri]

4 hours ago, Lupine00 said:

Quest is pointless then, as it can be removed with standard keys, as I pointed out.

 

I don't question the High Security Yoke. That's supposed to be a big deal.

 

I have in actual play, received the heavy yoke *many* times, and never performed a quest to remove it. Simple repeated attempts with keys will eventually remove it. I replicated that in testing DF about a half-dozen times yesterday.

 

My point here is that if BlockGeneric becomes devalued by over-use, it no longer serves its intended purpose, and people will set everything Quest, which is worse, as it causes impossible to resolve scenario-breaking conflicts.

 

The long list of mods that have mis-configured devices isn't really a rationale for continuing to leave these things unpatched in DCUR or LBS, or wherever, though I'd argue that SLUTS has used the keyword correctly, exactly as intended.

 

If LBS has quest items that are marked as BlockGeneric, it needs to cope with those items being removed, and possibly never replaced.

A player could be ported off to a Things in the Dark scenario that they play for real weeks before returning to continue the LBS scenario.

 

At least LBS didn't use Quest though...

 

I'd argue that best practice suggests that Quest should effectively never be used, or if used at all, only in a narrowly constrained setting where it's firmly believed the player cannot leave the area or the scenario - Dragonar for example - without legitimately removing the item.

 

BlockGeneric should serve as sufficient deterrence for other mods, and the owning quest needs to handle the situation...

 

Cursed Collar? Can only be removed by a god? Removed by a random quest ... never mind ... collar magically gets reapplied the moment the PC gets free of whatever conflicting item they were wearing. That would be Cursed Collar's problem to solve, and not a hard one - periodically check for Quest keyword, see if it's missing, replace item if possible. Maybe pop up a box explaining the collar's magic (excuse).

 

That's not the only way to handle it, but the point is that making assumptions about items being impossible to remove is ALWAYS flawed, will always be flawed, and is a source of impossible-to-resolve conflicts. Mods would get away with it when there were around three DD scenarios, and one of them was built into DD itself. Times have changed.

This makes a lot of sense.

 

If you are restricted to specific cells I would be more worried about mods taking the player from the area, than removing my custom devices (if I already control the NPCs, having very high priority AI packages and Blocking Dialogues should hopefully prevent most mods interfering).

LL mods that can move the player out of any location, even if they aren't DD mods specifically, should at least be aware of DDs and not move a player wearing a Quest keyworded item. That would be a reasonable use I can think of for the keyword, as a sign to say the player needs to be where they are or you will break what I am doing.

 

While block generic would be best for Quests that are in the main worldspaces and running into a situation where non removable devices break things is far to easy.

 

In either situation if your quest requires you to wear specific items having an MCM with a debug requip quest devices, Like DF has for slavery devices should those be lost, should be a thing you consider over making the items completely unremovable by any means outside the quest.

 

I think what is more important than controlling devices honestly is controlling scenes and controlling the teleportation of the player.

A lot of things use ... I forgot the name something to do with defeat, to know when not to run, but not enough mods that could benefit from it activate it, and not enough that should be watching for it watch for it.

 

 

Back on the topic of the yokes from dcl loot, I had a similar issue with them.

The issue isn't necessarily that the yokes have the block generic keyword but that block generic yokes are in the generic device lists, meaning you can get them easily when you are not in a situation to jump through the hoops needed to remove it. Sure you can get high security items from traps too, but you set high security items chance separately from generic items.

[Lupine00]

1 hour ago, Tenri said:

A lot of things use ... I forgot the name something to do with defeat, to know when not to run, but not enough mods that could benefit from it activate it, and not enough that should be watching for it watch for it.

I'm guessing you mean dhlp-Suspend and Enable?

Also the In Scene dialog condition.

 

 

  

1 hour ago, Tenri said:

The issue isn't necessarily that the yokes have the block generic keyword but that block generic yokes are in the generic device lists, meaning you can get them easily when you are not in a situation to jump through the hoops needed to remove it.

That's a well observed issue. It's wrong either way. The yoke can be removed with regular keys (depending on whether your base-DD settings let you easily access locks or not). There is thus no reason a follower can't simply remove the yoke. Devious Helpers posits that exact scenario. Devious Followers is another case. The presence of a BlockGeneric item in the generic list is another issue. In both cases the flag looks incorrectly applied.

 

I suggest it is that simple, and the flags is a left-over from some other plan or intended use of the yoke in question.

Presumably, the quest should use a BlockGeneric yoke that doesn't respond to a key, and the yoke in the trap items list should not have the BlockGeneric flag?

[Tenri]

36 minutes ago, Lupine00 said:

I'm guessing you mean dhlp-Suspend and Enable?

Also the In Scene dialog condition.

Sounds right to me.

36 minutes ago, Lupine00 said:

That's a well observed issue. It's wrong either way. The yoke can be removed with regular keys (depending on whether your base-DD settings let you easily access locks or not). There is thus no reason a follower can't simply remove the yoke. Devious Helpers posits that exact scenario. Devious Followers is another case. The presence of a BlockGeneric item in the generic list is another issue. In both cases the flag looks incorrectly applied.

 

I suggest it is that simple, and the flags is a left-over from some other plan or intended use of the yoke in question.

Presumably, the quest should use a BlockGeneric yoke that doesn't respond to a key, and the yoke in the trap items list should not have the BlockGeneric flag?

I was simplifying to just the issue with the looting part, but yes. A separate yoke for generic loot and courier would be likely the best solution, having a separate event for the courier in chans yoke so you can define the drop chance like you do for the special collars and multi keyed devices.

 

My specific interaction when I got fed up with yokes from DCL and basically removed the chance to get any yoke as a drop for the rest of my playthroughs, got equipped with the heavy yoke spent like 30 mins real time struggling to get out of it, less than a min later the self bondage timer trips and I requip it (and throw away my keys for good measure). Then the follower (who still has keys cause DCL keeps spawning them on her) says they don't want to mess with it, I'm like you just watched me spend hours(ingame) struggling to get the thing off and nothing happened to me, why are you so scared of it. Make matters worse this is in the middle of the sightless pit, you know the dungeon where the only way out is to clear it.

[legraf]

2 hours ago, DeWired said:

Problem is... what are those "intended purposes"? Please, point me at some doc where they are explained, because so far I am only guessing about those keywords. As such while I was writing this post, I changed my opinion about 3 times arguing with myself... Last edition - 1. using "safe to manipulate with generic functions" as guideline, 2. "Courier in chains" can't work with blockGeneric - 2 points for Heavy Yoke to drop blockGeneric. And possibly switch to using hand restraint key.

There's this, from DDi's zadLibs.psc: 

 

6. Items marked with zad_BlockGeneric should NOT be removed by third party mods via trivial means of escape (e.g. blacksmith dialogues) or without compelling reason. They can be removed -when necessary-, to be replaced with quest items (and these only!), or temporarily, if required to run a scene etc. In the latter case, the removing mod is expected to equip back the item after completing the scene.
7. Items tagged with zad_QuestItem mark essential items that are not to be removed for ANY reason by any content mod other than the mod that equipped them and the framework itself. Modders are asked to use this tag sparingly and only when warranted, as this might prevent other mods' quests or scenes from getting started. Live and let live!
 

[Lupine00]

21 minutes ago, legraf said:

6. Items marked with zad_BlockGeneric should NOT be removed by third party mods via trivial means of escape (e.g. blacksmith dialogues) or without compelling reason. They can be removed -when necessary-, to be replaced with quest items (and these only!), or temporarily, if required to run a scene etc. In the latter case, the removing mod is expected to equip back the item after completing the scene.

I imagine DeWired was well aware of this. But that guideline simply states how mods should interact with BlockGeneric, not why you would add it.

 

I know it seems that the rule implies the reason (do not remove this item) but then when can the item be removed? And by what?

 

OK, the rule says we can replace it with a quest item, or take it off for a sex scene then put it back.

This doesn't answer when the item may be removed...

Clearly, if it's your mod's quest item, then the quest removes it. But there could be other ways?

 

i.e. Can you replace one block generic with another block generic?

Not according to the rules, but you can replace it with a quest item... This seems arbitrary.

 

 

When should a mod need to set BlockGeneric? Why?

 

 

I guess the cases you might want some kind of behaviour like this are something like:

• SLUTS yoke
• SD+ collar
• Any other quest item that handles removal cleanly

SLUTS yokes and SD+ collars clearly are quest items of a sort.

Thus BlockGeneric looks a lot a kind of Quest item where there's a promise to handle removal cleanly.

Any new mod (or new content in old mods) should probably be doing this by now.

 

And Quest items as currently used are an item that says "you will break the save if you remove this".

This latter approach is ... not so ideal ... I don't think there's a need for this except as a legacy behaviour for old mods written before we knew better.

 

Thus BlockGeneric probably isn't appropriate for anything except an item we really don't want to be removed because it will at least temporarily block a quest.

Removing the item should either abort/fail the quest, or pause it and provide a recovery path.

 

Using BlockGeneric on a regular trap item is probably not correct.

And BlockGeneric items can probably be replaced with other BlockGeneric items, if it seems like the player would want that.

Possibly, players should be given some warning of the consequences before the item is swapped.

I don't think that adding a Quest item should have any more privilege, but we know that Quest items come from old content that thinks it can do as it pleases, and will, so we have to assume that it can happen.

 

 

I've used "probably" here, because I accept there's room for other arguments, but I'm not sure what those arguments are yet.

[Laura]

3 hours ago, Tenri said:

I think what is more important than controlling devices honestly is controlling scenes and controlling the teleportation of the player.

A lot of things use ... I forgot the name something to do with defeat, to know when not to run, but not enough mods that could benefit from it activate it, and not enough that should be watching for it watch for it.

You're right. I don't think the issue is how the keywords are used. Both BlockGeneric and QuestItem have essentially the same function. They tell other mods to leave the device alone.

The bigger problem in my eyes are mods that mess with other mods by taking too much control of the player.

 

3 hours ago, Tenri said:

Back on the topic of the yokes from dcl loot, I had a similar issue with them.

The issue isn't necessarily that the yokes have the block generic keyword but that block generic yokes are in the generic device lists, meaning you can get them easily when you are not in a situation to jump through the hoops needed to remove it. Sure you can get high security items from traps too, but you set high security items chance separately from generic items.

I understand why she did it though. It's a nonstandard yoke with a specific way to escape and the keyword makes sure that other mods don't touch it. I don't think it's weird to want control over your own content.

I know it can be annoying to suddenly get trapped in a restraint that's much tougher than normal, but that's that nature of DCL and it's why it's so highly customisable.

[Zaflis]

3 hours ago, Laura 'Lokomootje' said:

I know it can be annoying to suddenly get trapped in a restraint that's much tougher than normal, but that's that nature of DCL and it's why it's so highly customisable.

I have been trying something else lately; timed restraints. Recompiling zadEquipScript with DeWired's fix + new defaults for Devious Devices i could make nearly all restraints default to being timed, unless its script properties override those values. Quest items are still not timed so no worries, the Laura's shop questlines worked fine (they weren't timed except for the red leather set reward etc). The things i changed in source are:

Spoiler

Float Property LockShieldTimerMin = 72.0 Auto ; Can't use keys for 3 days.

Float Property LockShieldTimerMax = 72.0 Auto ; You could set these lower if you want possibility for earlier release.

 

Bool Property TimedUnlock = True Auto ; After the time it will unlock without needing a key.

 

Float Property LockTimerMin = 12.0 Auto ; Random time for device to unlock after 12h to 3 days.

Float Property LockTimerMax = 72.0 Auto

With these there's no chance to get them off early. You can use the normal Skyrim wait feature if you really want them off now, but if you play with realistic needs, Dragonborn in Distress or Body Alteration they should accumulate their debuffs and addictions anyway as the time passes by. As intended.

 

Do you guys think i should upload this script to some thread or is there no interest? I really had fun playing with it. You can save most keys for freeing those bound girls at inns and towns, with its chance to get em passed on to you (timed)   But if it was made into alteration mod, i wouldn't know how to make MCM etc. to change values without recompiling. So anyone feel free to take over idea. With this it's ok if DCL trusses you up in every slot. You get to have your fun for few ingame days but you already know you won't get stuck with them, although when they release you one by one, encountering NPC's while wearing any might give you more. You can make stricter MCM settings for Cursed Loot too, increasing the chance that they add devices and reducing chance of removing them.

 

I guess it also fits the lore, now they are more like cursed devices.

[Labsink]

On 1/4/2020 at 6:02 AM, tragix said:

How did you make the fix to the pex file without recompiling?

I followed this video: https://youtu.be/x86MmzURI2M
It shows how you decompile a pex file, change it and recompile it.
You get the tools from installing creation kit.
I simply replaced the pex file in my skyrim installation folder and then Vortex asked if I wanted to update the change to the actual mod I have installed and I pressed yes so next time Vortex deploys mods it will not remove the changed pex file.

 

I attached below the changes I did to the PAS file to fix the bug for me.

Note that all of the tags like _label1675 and temp1079 should be the same as in the code just above the added part. The only tag that should be different is temp1063c which is something I added.

Also note that it seems to me that disassemblies are always a bit different, so labels, line numbers and so do not match.

 

dcur_library.pas.diff

[Tenri]

7 hours ago, Laura 'Lokomootje' said:

I understand why she did it though. It's a nonstandard yoke with a specific way to escape and the keyword makes sure that other mods don't touch it. I don't think it's weird to want control over your own content.

I know it can be annoying to suddenly get trapped in a restraint that's much tougher than normal, but that's that nature of DCL and it's why it's so highly customisable.

I agree that having that yoke as a possible event if fine, in fact I enjoy trying to get NPCs in town to remove it, but as per my example, if I know I am going somewhere where an item like that will basically end with me being unable to progress without cheating I disable the non standard events by setting the min level for them above my current level, but that yoke is in a 'standard event' so I have to disable cursed looting entirely to avoid potentially seeing it, or completely disable yokes which I end up doing during initial configurations now, meaning it (and any other yokes) might as well not exist in my game, not the solution I prefer but it is what is available to me.

[DeWired]

10 hours ago, Lupine00 said:

I know it seems that the rule implies the reason (do not remove this item) but then when can the item be removed? And by what?

As I understand those guidelines (and DDi code with item removal), blockGeneric doesn't mean that other mods can't remove item - it means "Stop, and think about it". So, you can examine item more thoroughly, check it's FormID against some known forms, and then perhaps remove it, while adding something else - in case of DF, debt bigger then normal ("generic") seems appropriate. This way, you aren't providing PC with a way to escape intended item consequences, but rather provide alternative set of consequences. Yes, if you do it for Heavy Yoke when "CiC" is already running, it will break at least immersion. I don't think it will break the quest itself. Theoretically, quest needs to be patched to provide failure path - PC deliver the message but without starting restraint that provided secrecy, so PC clearly did something bad.

This way, you can circumvent this discussion about "proper keyword assignation" and return to work ? Because, clearly, this can be debated for days and weeks - and don't go anywhere because keyword changes are clearly not matter of patches and totally belong to Kimy.

 

P.S. Same argument can be made for removing Laura's Bondage Shop "Seeking the Curse" items - they can be unequipped by DF with bigger then normal debt addition, but then it needs to be changed on LBS end, to accept items not worn for quest completion.

 

 

[Shion11]

so i was having a issue where i couldn't talk to innkeepers, and it tuns out devious followers was havng a event going on with the innkeeper, but after it got it's recent update, i don't have this issue.

[Lupine00]

21 hours ago, Laura 'Lokomootje' said:

I understand why she did it though. It's a nonstandard yoke with a specific way to escape

The point I am making is that the only thing non-standard about it is that keyword. You can unlock it with regular keys.

 

If it had:

 

a) not worked with keys

b) always triggered the quest ... DUM DUM ... Quest status message appears "Escape from the Heavy Yoke ... Talk to vendors until one of them offers to remove the yoke in return for completing a little task."

 

...it would make a lot of sense to be BlockGeneric.

 

As it is, coming from the "authority" on what these things mean, it creates some confusion over the appropriate use of BlockGeneric.

 

But instead, you can get it without any fanfare, rather often, from traps. Then remove it, yourself, with DCL restraint keys.

At least, that's what I found in two different installs, one a 250+ LO with around 650 mods merged into it in MO, and another with a very minimal setup in NMM.

 

 

But as the consensus seems to be removing BlockGeneric is OK as long as it's not a gift to the player...

 

I will update DF so that the follower will remove items while BlockGeneric is present (could be the BlockGeneric item, or a different one), but only while the location is a dwelling, and while the follower has max lives, and the player will need to take a new deal with no debt relief for each item removed.

 

If the BlockGeneric item is a trivial one that DF doesn't remove anyway, they won't be able to get rid of it, but they will still be able to remove crippling items that aren't BlockGeneric, at the aforementioned cost, and then they can pursue removal of the BlockGeneric by whatever means they please.

 

 

i.e. they must pay a deal per item removed, and they can't do it in a dungeon or with a tired follower.

If the first item removed is the BlockGeneric, then good for the player. If not ... deals are fun.

[twsnider1138]

Hi, I have a quick question regarding combat surrender and NPC sex sequences not engaging properly. So I have convinced a female opponent to surrender and the DCUR options menu pops up saying I can loot her, kill her, or tie her up. After I choose tie her up, the option appears to rape her but the cutscene never starts. Now the rape scene works just fine on a male opponent but not a female one, she just stands there instead. Now according to my papyrus log, segment of which is included below, it can't find any bound animations. I have run FNIS and it says there's over 600 from the DD family alone, not to mention the PC getting raped in bondage gear quite a few times.Can anybody help me out with what's wrong? Thank you as always.

 

[01/06/2020 - 03:48:30AM] [DCUR] - Sex with player:
[01/06/2020 - 03:48:30AM] [Zad]: Selecting DD-aware animations.
[01/06/2020 - 03:48:31AM] [Zad]: Actor(s) are bound. Trying to set up bound animation.
[01/06/2020 - 03:48:31AM] [Zad]: Error: no valid bound animations could be found.
[01/06/2020 - 03:48:31AM] Error: Cannot cast from None to sslBaseAnimation[]
stack:
    [zadQuest (0F00F624)].zadbq00.SelectValidDDAnimations() - "zadBQ00.psc" Line 551
    [zadQuest (0F00F624)].zadlibs.SelectValidDDAnimations() - "zadLibs.psc" Line 706
    [dcur_mainlib (31024495)].dcur_library.SexWithPlayer() - "dcur_library.psc" Line 5110
    .dcur_npcsurrender_rape.Fragment_0() - "dcur_npcsurrender_rape.psc" Line 9
[01/06/2020 - 03:48:31AM] [DCUR] Sex Scene aborted. No valid animations found.

[twsnider1138]

And thanks to Chloe’s maniacal refusal to back down in the face of overwhelming superiority, I have suffered no less than three combat surrenders, repeated rapes, and ended up in pretty much every DD device in the inventory. Somebody finally had the brilliant idea to TIE UP the crazy bitch with the greatsword before dumping us off near Morthal so they can lick their wounds. ?

[M1g17]

Hi. Had a question about the Damsel in Distress quest. So I started the quest, my character was hogtied in a cage. Got out of the hogtie. Got out of the armbinder. Got out of the cage, but then I'm not sure what to do. There's a camp nearby, but if I go over to it, a Hagraven attacks and my character still has her wrists tied by iron shackles and cannot fight back. I tried avoiding the little camp and walking down to a nearby farm, and some of the NPCs are able to remove a piece of the gear, but inevitably, they become very unhelpful. Am I supposed to have my character just walk around all day, asking for help out of the bindings, or did I miss something?

[darktej]

50 minutes ago, M1g17 said:

Hi. Had a question about the Damsel in Distress quest. So I started the quest, my character was hogtied in a cage. Got out of the hogtie. Got out of the armbinder. Got out of the cage, but then I'm not sure what to do. There's a camp nearby, but if I go over to it, a Hagraven attacks and my character still has her wrists tied by iron shackles and cannot fight back. I tried avoiding the little camp and walking down to a nearby farm, and some of the NPCs are able to remove a piece of the gear, but inevitably, they become very unhelpful. Am I supposed to have my character just walk around all day, asking for help out of the bindings, or did I miss something?

as far as I remember you need to loot chests, barrels or any containers (even plants) for keys. and these are not regular keys. keys such as Hand, Body, Leg and Head restraint keys. and with that you can unlock the restraints. 

[qoop272]

Hello, I try to use this mod with other mod (like Be a cow or slave reloaded)
but It seems that this mod has compatibility issue with Zaz Animation 8 or 8+, which make player using wrong animation or ignoring bondage restraint

 

I'm not quite sure how to fix it, so in the end I just disabled this mod when I trying other mod

[Tenri]

3 hours ago, qoop272 said:

Hello, I try to use this mod with other mod (like Be a cow or slave reloaded)
but It seems that this mod has compatibility issue with Zaz Animation 8 or 8+, which make player using wrong animation or ignoring bondage restraint

 

I'm not quite sure how to fix it, so in the end I just disabled this mod when I trying other mod

the breaking animations is actually coming from Slaverun Reloaded, there is a fix for it posted in the thread there, I posted a link to it recently.

[DeWired]

On 5/30/2019 at 4:27 PM, Zaflis said:

I can't remove Yoke of Shame, when clicking on inventory i only get "Carry on" option. I had a message that it can now be removed and it's been even some days more. I tried

player.removeitem 490aec4e 1

and

player.removeitem 490aec4d 1

in both orders. Removing script first makes the visual disappear but item is still on me. Removing the item brings both script and the item back on. Removing item first doesn't do anything. So is there some quest involved, and is that the case with all timed items? Using "Free Me" would be problematic considering i have PetProject quest items on.

 

Checking TES5Edit, deviceQuest refers to zadQuest "Chastity Belt" [QUST:0500F624]. Am i on the right track here, yoke and chastity belt share a quest?

Edit: Actually Free Me was a fine solution, and that didn't remove the other mod quest items.

@Kimy

BUG detected. Yoke of shame device message link to DeviousYoke, but yoke itself is DeviousYokeBB.  As such, unlock option doesn't work.

Spoiler

In TES5Edit, Message \ xx0D9312 <dcur_yokeofshameDeviceMSG> before:

After:

 

[xkira1995]

Having trouble with installation of these mods with a mod manager. My esm files aren't inserted automatically from each folder with the mod manager tries putting everything where it thinks it belongs. It sticks the 00Base, 00Core, and other folders all into the data folder. How do I resolve this please?