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

[ThePopato]

I'm still using the outdated NMM, maybe that is the reason I cannot install the mod. If not, where would I find the other DDi?

 

My load order only contains Devious Devices- Integration.esm(I have DDa and DDe installed as well, and they are in the right order.).

 

The problem is that when I attempt to install the mod, the unpacking process stops at 50% and the error message simply reads "File devious devices-ıntegration.esm is not Active.".

[Labsink]

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

If you are interested in how I made the pex file, see this post: https://www.loverslab.com/topic/33986-deviously-cursed-loot-v83-2019-05-07/?do=findComment&comment=2861693

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

[John Calumnus]

Here's a quick note to anyone with a similar problem as me. I searched forums here and elsewhere for a solution to very specific, limited problem that only seems to happen in DCL's Alternate Start. Light sources that flicker or turn on and off as you look around. Appears to be caused by a limitation of Skyrim's engine when handling shadows from multiple light sources in the same area. I've found that if you install a simple 2012 mod called "Colorful Lights No Shadows" it gets rid of the problem completely. Couldn't notice any real effect on the lighting in other areas, but I don't know what the overall result will be for basically turning off shadows for all of Skyrim's light source meshes. Use with caution, and maybe disable once you get out of the DCL dungeon and outside Helgen proper.

[Dojo_dude]

Where's the MCM options to disable the Walk of Shame?! I had to steal a horse to literally escape death, and my 50 gold bounty ALWAYS leads to a Walk of Shame!!!

WTF@! Why not add a feature to disable this? It interferes with PoP also.

[Zaflis]

1 hour ago, Dojo_dude said:

Where's the MCM options to disable the Walk of Shame?! I had to steal a horse to literally escape death, and my 50 gold bounty ALWAYS leads to a Walk of Shame!!!

That is some biased luck you have. I don't even remember when i last got it, maybe once or twice in the whole history of playing this mod have I seen it. Maybe it's time to look deeper into the script? ?  And no you can't config that in MCM at least yet.

[Dojo_dude]

3 hours ago, Zaflis said:

That is some biased luck you have. I don't even remember when i last got it, maybe once or twice in the whole history of playing this mod have I seen it. Maybe it's time to look deeper into the script? ?  And no you can't config that in MCM at least yet.

looks like if I talk to guard, I get options, if they talk to to me 'force greet' then I get DCL outcomes.

Possible to alter the DCL prison outcomes by removing some options in 'Consequences'?

[Zaflis]

So previously i managed to compile DD files, now DCL worked too (still from MO2 and Notepad++ Papyrus plugin). Had to add sources from Aradia and SkoomaWhore. But there was one script error @Kimy

dcur_mcmconfig.psc, line 2608 (missing 3rd parameter. It's about cuminflation so i assume you mean waist bone) :

- cts.SetMorphValue(libs.playerref, 0.0)

+ cts.SetMorphValue(libs.playerref, 0.0, "Waist")

 

What i was actually looking for is how to disable player controls between Dagonar prison display-model stages, because it's just not fun that i can walk all the way to other guard while one is finishing his chat and "equipping player". I know the commands are Game.DisablePlayerControls() and Game.EnablePlayerControls(), and those stages are set in dcur_prisonQuestScript, but it's also propably related to Creation Kit side quest things. If the quest is more responsible of controlling the flow of things and calling scripts. Learning bit by bit...

[shadowwolf2k7]

On 12/27/2019 at 12:14 PM, ThePopato said:

I'm still using the outdated NMM, maybe that is the reason I cannot install the mod. If not, where would I find the other DDi?

 

My load order only contains Devious Devices- Integration.esm(I have DDa and DDe installed as well, and they are in the right order.).

 

The problem is that when I attempt to install the mod, the unpacking process stops at 50% and the error message simply reads "File devious devices-ıntegration.esm is not Active.".

you need DDa, DDi and DDx to make DCL work. DDe isnt part of the framework.

 

http://www.loverslab.com/files/file/269-devious-devices-assets/  is DDa

http://www.loverslab.com/files/file/371-devious-devices-integration-12092014/  is DDi

http://www.loverslab.com/files/file/1305-devious-devices-expansion-v116/  is DDx

[ThePopato]

On 12/30/2019 at 5:04 AM, shadowwolf2k7 said:

you need DDa, DDi and DDx to make DCL work. DDe isnt part of the framework.

 

http://www.loverslab.com/files/file/269-devious-devices-assets/  is DDa

http://www.loverslab.com/files/file/371-devious-devices-integration-12092014/  is DDi

http://www.loverslab.com/files/file/1305-devious-devices-expansion-v116/  is DDx

That was a typo, I meant I had Assets, Expansion and Integration in the correct order. My bad.

[thedarkone1234]

1 hour ago, ThePopato said:

That was a typo, I meant I had Assets, Expansion and Integration in the correct order. My bad.

Are you absolutely certain? the correct order is assets, integration and then expansion

 

I can verify that NMM works great with the latest versions of these mods, which brings me to the next question: are all 3 DD mods up to date? DCL currently requires assets 3.0e and integration+expansion 4.2+

[DeWired]

On 9/11/2019 at 7:38 PM, freeroal said:

Hi, thanks for your great mod! I really enjoy it but I find that when I use dollmaker sword and hit female human enemy, nothing happens except they become blue. Is that something wrong? What should I do ? Does anyone have the same issue?

@Kimy

BUG

Dollmaker sword uses for cooldown real time from game start, which becomes 0 at every game load. So, sword works when first acquired, then, when game is saved, time from session start to last hit is saved too. Then, on next game load, sword doesn't work until that saved time passes. So, if it was used in two-hour game, next session it will not work for two hours.

Proposed patch:DCL dollmaker sword patch 31122019.zip

tested, works for me.

Spoiler

--- dcur_restraintsonhitEff.psc.orig	2019-12-31 14:51:45.872894800 +0300
+++ dcur_restraintsonhitEff.psc	2019-12-31 15:41:02.951978400 +0300
@@ -14,9 +14,19 @@
 		return
 	EndIf				
 	; we got a valid target, check if the cooldown is expired.	
-	if (Utility.GetCurrentRealTime() > dcur_dollmakerweapon_cooldown.GetValue())		
-		dcur_dollmakerweapon_cooldown.SetValue(Utility.GetCurrentRealTime() + 10)
-	else
+	Float currentRealTime = Utility.GetCurrentRealTime()
+	Float cooldownTime = dcur_dollmakerweapon_cooldown.GetValue()
+	if ( currentRealTime > cooldownTime)	
+		; cooldown expired, reset and continue 
+		dcur_dollmakerweapon_cooldown.SetValue(currentRealTime + 10.0)
+	elseif currentRealTime < 10.0
+		; game freshly loaded, reset cooldown from previous game and continue
+		dcur_dollmakerweapon_cooldown.SetValue(currentRealTime + 10.0)
+	elseif cooldownTime - currentRealTime > 11.0 
+		; game loaded from previous save, reset cooldown and continue
+		dcur_dollmakerweapon_cooldown.SetValue(currentRealTime + 10.0)
+	else 
+		; cooldown not expired
 		return
 	endif
 	debug.trace("[DCUR] Dollmaker weapon spell triggered on " + t.GetLeveledActorBase().GetName())		

 

P.S. On a more curious note, when I noticed the issue, I had sword cooldown variable around 59000.

[jaberwocky]

While walking around naked due to the slave collar, I thought of a nice addition.

Lowering the disposition of female NPC's towards the (female) Dragonborn by something between 1 and 3 points. This gives an additional downside to walking around naked, but not a heavy one. Yet it will be constant and you can hear it as well.

 

This could be placed in a a separate mod, but to the best of my knowledge such a mod does not exists. If it does, can someone point me to it?

[darkfender666]

Hi i have few small problems with latest update.

 

1) missing some textures: for example in dragonare many dd stuff like warden dress, leah boots... also LEON face is purple.

 I also updated the 3 Devious devices mods so i wonder if i forgot anything else..

 

2) any way to disable prison dialogue and let PO take control? if i put the chance to 100? the guard dialogue  is different and they often also ends attacking even if they shouldn't.

 

3) PO Bounty hunters can reach you in dragonar prison messing up everything.

 

4) how do i start leah service without repeating the quest again?

 

5) time in dragonar is silly... you have to sleep 2 days to actually make a work day start despite. That is you have to sleep a Whole day after the message you cannot sleep anymore. May i suggest to simply use the bed as a trigger without actually sleeping like captured dreamshop used to do?

 

Ty

 

P.S: everything tested on a brand new game with everything clean.

 

 

[Lupine00]

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

[Lupine00]

While on the topic of yokes, the DCL "cover animation" overrides DD yoke animations.

 

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