Devious Followers - Continued

[Roggvir]

33 minutes ago, Lupine00 said:

That's not DF.

Spoiler

That's Devious Helpers. Possibly you're aware, but I'm not sure why you bring it up if you are.

Do you have anything that interferes with Hellos? To Your Face?

DH shouldn't fire in a dungeon, that's a bit odd. It should really only fire in dwellings, but maybe DH checks the cleared status?

 

I would recommend not to mix DH and DF. DH subverts the removal mechanic from DF, doubles up on stuff, and generally provides free device removal you aren't supposed to get. On top of which the follower becomes even more of a split-personality than DF makes them by itself. It shouldn't block your games, but I don't know, maybe it fires its Hellos and DF never gets a try?

 

Ooops, sorry, i keep mixing them up.
Maybe DH is actually the thing interfering with hellos from DF. I'll have a look, and try your suggestions, thanks..

[Roggvir]

MCM Stats shows "Follower Boredom" as 0.0

That is something i would expect to play a role in whether the follower will "play any games" or not - is it not?

[Lupine00]

1 hour ago, Roggvir said:

MCM Stats shows "Follower Boredom" as 0.0

That is something i would expect to play a role in whether the follower will "play any games" or not - is it not?

It has no impact on it. Playing games may reduce it though.

[Lupine00]

2 hours ago, Roggvir said:

BUT in the situation of having empty inventory, the Straitjacket is not added here - the "deviceInventory" you keep refering to, is the Nipple Piercings, not the jacket.. (we we're talking about specific usage of these functions in fragment script TIF_Dflow_0A014177).

I have no idea what you mean by that.

 

You started the thread off saying the nipple piercings work correctly and the jacket doesn't; the comment on the nipple piercings appeared to be an aside.

You noted the problem of the dialog firing repeatedly.

The bug is the failure to fit the jacket when the "when I say slut" dialog fires.

This jacket is applied by that dialog using ForceEquipDevice and fails to add it because the skipEvents parameter isn't True.

 

So, I was never referring to the piercings, or even looked into their behavior, as it didn't appear to be broken, or even relevant to that game.

I read back to see if there was a bug with the piercings you described, but I didn't see it.

 

Is there a bug with the piercings?

They're not what I was referring to at all, and wouldn't cause that dialog to fire.

ForceEquipDevice is used on the jacket, and - in my ESP - the jacket is in the properties I expect.

 

[Xiaron]

Quick DF games question, it's spoilery so;

 

Spoiler

Was unequipping a set of gloves and boots in a dungeon. Took the gloves off first, then my DF triggered the pony game before I got the boots unlocked. My question is, is that game supposed to trigger inside a dungeon? Just outside one I've had it start, but I was in Mzinchaleft and almost to Blackreach when this happened.

 

[Kimy]

3 hours ago, Lupine00 said:

Certainly possible.

 

As it turns out, this is quite an interesting little rabbit hole in DD, and we can go a long way down it.

The deeper we go, the more quirks are uncovered in DD, but they don't lead to the exact bug you are suggesting.

There is a DF bug, but it's a little more naunced than the first stab.

 

However, I believe I can see some clear causes of numerous unreliable behaviors that we see from DD in many mods, time and time again.

And this is just here ... I don't want to imagine what I could find if I went through this thing top to bottom, which is basically why I don't do that.

There's nothing I can fix here, no way for me to patch or alter or improve DD, and no way for me to suggest improvements.

If I say "I found a bug in DD, here's the patch", what will come back is either complete silence, or a sort of loud booming sound that drowns out all thought.

And weeks later, after the storm has passed, if it isn't an absolute glaring horror, the original bug won't get fixed.

Either way, it's just me wasting days so I can be abused, so I'm not going there, not doing it, that is that.

Not sure you will read this, as you blocked me anyway, but from my own experiences I can confirm that skipEvents is a parameter that shouldn't ever be used. I also agree that the code handing device equips and unequips does a few unorthodox things I wouldn't have done this way. I didn't write that particular portion of the code, though. That's still a part of what I inherited when I took over DD.

I even go as far saying that in hindsight, I don't think that implementing devices with the inventory/rendered item system was worth the hassle, given that its only true benefit is not seeing the device briefly flicker when its removed and automatically put back on in situations when it's not -actually- supposed to be removed and people click it in their inventory.

 

Thing is that at this point in DD's lifecycle and with literally dozens of mods out there using the framework, changing its core behavior or API function headers would not be a terribly good idea, don't you agree?

 

That being said, the code still works reliably as far as Papyrus can ever be considered "reliable". But yes, people really should avoid the skipEvents flag. And when mass-equipping devices, I also found it good practice to add a short delay between each item to give that silly scripting engine a chance to catch up. The mutex I personally never use either. Maybe that's all you need to do, because I can otherwise NOT confirm item equips to be "glitchy" and my mod performs that operation a lot more than any other DD mod.

 

Also, I still resent your notion that I won't fix bugs. It's just a silly thing to say when the DD and DCL changelogs clearly prove otherwise. You keep bashing me for allegedly not reacting to some of your reports, when the simplest explanation for this happening is me overlooking them. Which you apparently interpret as malice. Why you think I would do such a thing after I reacted to dozens of your postings over the years is beyond me. I do admit that I don't consider this forum to be a fun place to be (I wonder why....) and limit my presence here to a minimum, particularly in times when my life is otherwise busy anyway (and it was in the period you accused me to ignore your postings). I still try to catch up with postings, but as I said above, I am just human and my threads ARE busy.

 

And yes, I do prioritize bugs. Every developer does. A dialogue typo might indeed not make me drop everything I am currently doing to rush and fix. A critical bug, I will fix ASAP and always have. Not sure why I am getting bashed even for THAT, when its common practice in software development. Also, some bugs people report I can't fix simply because I can't reproduce them. Which happens a LOT because some people don't realize that their savegame is totally broken and happily report all the broken things as bugs when they are not. Generally, yes, if people report a bug that seems to be genuine, I try to reproduce it. If I can't reproduce it, I will wait for at least one other user to confirm it. If nobody confirms it, I close the issue and move on. Blame for not following up on each and every report if you want. I do it this way to remain sane.

 

That's about all. I will not post in your thread again, unless you really force me to. I know I am not welcome here.

 

[audhol]

Again nothing to do with me but sometimes I can't help poking my nose in, maybe thats why ive got Picard as my avatar

2 hours ago, Kimy said:

6 hours ago, Lupine00 said:

Certainly possible.

 

As it turns out, this is quite an interesting little rabbit hole in DD, and we can go a long way down it.

The deeper we go, the more quirks are uncovered in DD, but they don't lead to the exact bug you are suggesting.

There is a DF bug, but it's a little more naunced than the first stab.

 

However, I believe I can see some clear causes of numerous unreliable behaviors that we see from DD in many mods, time and time again.

And this is just here ... I don't want to imagine what I could find if I went through this thing top to bottom, which is basically why I don't do that.

There's nothing I can fix here, no way for me to patch or alter or improve DD, and no way for me to suggest improvements.

If I say "I found a bug in DD, here's the patch", what will come back is either complete silence, or a sort of loud booming sound that drowns out all thought.

And weeks later, after the storm has passed, if it isn't an absolute glaring horror, the original bug won't get fixed.

Either way, it's just me wasting days so I can be abused, so I'm not going there, not doing it, that is that.

Not sure you will read this, as you blocked me anyway, but from my own experiences I can confirm that skipEvents is a parameter that shouldn't ever be used. I also agree that the code handing device equips and unequips does a few unorthodox things I wouldn't have done this way. I didn't write that particular portion of the code, though. That's still a part of what I inherited when I took over DD.

I even go as far saying that in hindsight, I don't think that implementing devices with the inventory/rendered item system was worth the hassle, given that its only true benefit is not seeing the device briefly flicker when its removed and automatically put back on in situations when it's not -actually- supposed to be removed and people click it in their inventory.

 

Thing is that at this point in DD's lifecycle and with literally dozens of mods out there using the framework, changing its core behavior or API function headers would not be a terribly good idea, don't you agree?

 

That being said, the code still works reliably as far as Papyrus can ever be considered "reliable". But yes, people really should avoid the skipEvents flag. And when mass-equipping devices, I also found it good practice to add a short delay between each item to give that silly scripting engine a chance to catch up. The mutex I personally never use either. Maybe that's all you need to do, because I can otherwise NOT confirm item equips to be "glitchy" and my mod performs that operation a lot more than any other DD mod.

 

Also, I still resent your notion that I won't fix bugs. It's just a silly thing to say when the DD and DCL changelogs clearly prove otherwise. You keep bashing me for allegedly not reacting to some of your reports, when the simplest explanation for this happening is me overlooking them. Which you apparently interpret as malice. Why you think I would do such a thing after I reacted to dozens of your postings over the years is beyond me. I do admit that I don't consider this forum to be a fun place to be (I wonder why....) and limit my presence here to a minimum, particularly in times when my life is otherwise busy anyway (and it was in the period you accused me to ignore your postings). I still try to catch up with postings, but as I said above, I am just human and my threads ARE busy.

 

And yes, I do prioritize bugs. Every developer does. A dialogue typo might indeed not make me drop everything I am currently doing to rush and fix. A critical bug, I will fix ASAP and always have. Not sure why I am getting bashed even for THAT, when its common practice in software development. Also, some bugs people report I can't fix simply because I can't reproduce them. Which happens a LOT because some people don't realize that their savegame is totally broken and happily report all the broken things as bugs when they are not. Generally, yes, if people report a bug that seems to be genuine, I try to reproduce it. If I can't reproduce it, I will wait for at least one other user to confirm it. If nobody confirms it, I close the issue and move on. Blame for not following up on each and every report if you want. I do it this way to remain sane.

 

That's about all. I will not post in your thread again, unless you really force me to. I know I am not welcome here.

 

 

[Lupine00]

Responding to @Kimy's notes on these API issues...

 

There are many things she says there that I agree with, and then there are other things that perhaps in a better world would at least require ... further discourse ... as on the face of them they don't make sense, or are at least, unclear as to the underlying intent being communicated.

 

I don't agree that the API can't be changed at this point.

It just shouldn't be changed in a way that isn't backwards compatible.

Kimy has made changes in this area, and did make breaking changes in the 3.X to 4.X move that were not genuinely backwards compatible, but I guess that was a learning experience.

 

Adding new FitDevice and RemoveDevice functions (or some similar names) that work more reliably (only so much is possible) and lack the hazardous parameters, but also clearly mark the old functions as DEPRECATED, DO NOT USE and adding the list of known bugs in the source, would help developers get it right without having to read Kimy's mind or the entire DD source.

 

There may also be a case for fixing some of the worst problems in the old functions while retaining the core behavior.

They aren't huge, and could be changed in various ways that would probably not break any mods in catastrophic ways, and would help many others have more reliable behavior.

 

As far as the won't fix bugs thing goes; that subject is considerably more complex than the story presented above and I don't agree that it entirely represents the real events. Maybe it represents some idealized future we haven't quite arrived at yet. Steps towards acting as described there would certainly be progress.

 

DD is big enough and important enough to justify public bug tracking with an actual issue tracker, and I'm not going to agree that process is fixed until that happens. 

A public tracker would make following the process Kimy describes right there easier, more reliable, and ... public ... so people know they don't need to report a bug that's been secretly PM'd to Kimy 27 times already and reported 4 times in the dev forum then buried in spam.

 

A public process would possibly allow others to help identify what is easily reproducible and what is not too, taking some burden off her.

 

But this is exactly the sort of debate I don't want to be in any more, so I'll leave it at that.

[Roggvir]

@Lupine00 I'll put it all in a spoiler, so i don't clutter the topic for anybody not interested in this.
And please, do not take offense when i use caps and/or bold text. Ii do it to stress the importance of key information you seem to keep skipping over, no disrespect intended.

Spoiler

12 hours ago, Lupine00 said:

The bug is the failure to fit the jacket when the "when I say slut" dialog fires.

This jacket is applied by that dialog using ForceEquipDevice and fails to add it because the skipEvents parameter isn't True.

Yes, the bug is the jacket doesn't get added "when i say slut" dialog fires.
NO, the reason it doesn't get added, has NOTHING TO DO WITH skipEvents, because in the situation i described (jacket dropped/sold), the script "TIF_Dflow_0A014177" fails to add the jacket because player doesn't have the jacket anymore, and the script doesn't do anything to make sure player has the jacket.
The script does not attempt to add it, and the only line where it would get added as a side effect of EquipItem, get's called only if player has the jacket (or something with same keyword) in the inventory - so we never get there in this situation.
This is regardless of value of skipEvents - that gets to play a role when it comes to equipping the piercings (the renderDevice and inventoryDevice variables hold values related to the piercings, not the jacket).
The attempt to equip the jacket, happens ONLY via the ReEquipExistingDevice function, and that doesn't do it if player doesn't have the jacket in inventory, and it has NOTHING TO DO WITH SkipEvents.
 

12 hours ago, Lupine00 said:

So, I was never referring to the piercings, or even looked into their behavior, as it didn't appear to be broken, or even relevant to that game.

I read back to see if there was a bug with the piercings you described, but I didn't see it.

No, there is no bug with piercings (that i know of), i mentioned the piercings because the "when i say slut" topic info script fragment is equipping a jacket AND piercings.
And in the situation i am talking about (jacket removed/dropped/sold), the piercings do get equipped, while the jacket does not.
The main reason for mentioning the piercings was to point out, that they are getting added if not having them, while the jacket does not get added if not having it - i find that inconsistent and thus worth mentioning.
I also referd to the piercings when pointing out that you are wrong blaming usage of skipEvents for the jacket not getting equipped, because it was for equipping the piercings where this variable was playing role, not for when trying to equip the jacket.

12 hours ago, Lupine00 said:

Is there a bug with the piercings?

They're not what I was referring to at all, and wouldn't cause that dialog to fire.

ForceEquipDevice is used on the jacket, and - in my ESP - the jacket is in the properties I expect.

No, there is no bug with the piercings.
Correction: ForceEquipDevice is used on piercings and jacket - the piercings are passed into the function as deviceInventory and deviceRendered, and the jacket is passed in the zad_DeviousDevice argument.
That script fragment is equipping both the piercings and the jacket - only it fails to equip the jacket if not having it in the inventory.
I think maybe the sript fragment is using incorrect property values - maybe it is not supposed to do anything with piercings at all, maybe the deviceRenderd and deviceInventory were supposed to point to data related to the jacket, not the piercings?
 

[Roggvir]

@Lupine00

I thought about it again, and i think those piercings just shouldn't be there.
I do not know what the intention was, trying to use ONE function call to ForceEquipDevice() to add TWO different items, but that function clearly wasn't made with that in mind.

 

So, i think the code in TIF_Dflow_0A014177 (and/or its assigned property values in TopicInfo 09014177 on quest _DflowGames)  should be changed:

- either replace the property values pointing to piercings with values related to the jacket

- or use two subsequent function calls, one using only piercings related parameters, and second using only jacket related parameters, but do not mix them.

 

EDIT:

Actually, the TopicInfo does set properties for both render and inventory items for both the piercings and the jacket.
So, the intention probably was to add TWO items, and the mistake probably is just trying to use one function call to ForceEquipDevice() to do it.
Therefore, the script fragment should definitely be changed into having two calls, one with all piercings related parameters only, and the other with all jacket related params only.

EDIT2:

Just to be 100% clear, the original fragment

Function Fragment_10(ObjectReference akSpeakerRef)
Actor akSpeaker = akSpeakerRef as Actor
;BEGIN CODE
libs.ForceequipDevice(PlayerRef, D , DE, libs.zad_DeviousStraitJacket, skipevents = false, skipmutex = true)
;END CODE
EndFunction

...should be changed into this:

Function Fragment_10(ObjectReference akSpeakerRef)
Actor akSpeaker = akSpeakerRef as Actor
;BEGIN CODE
libs.ForceEquipDevice(PlayerRef, D,  DE,  libs.zad_DeviousPiercingsNipple, skipevents = false, skipmutex = true)
libs.ForceEquipDevice(PlayerRef, D2, DE2, libs.zad_DeviousStraitJacket,    skipevents = false, skipmutex = true)
;END CODE
EndFunction

 

[RealGesichtsfelsen]

Hello there,

 

for some reason I am unable to recruit some followers with this mod enabled. Mjoll didn't start following despite having the (vanilla) follower dialogue, Stenvar (mercenary in windhelm) didn't react at all to me recuiting him. Macruio (mage merc in Riften) did work (even with DDF dialogue). I have already removed other EFF because it'd be the obvious candidate for incompatability but the problem persisted even in a new game without it. Under which circumsances is the recuriutment "ignored"/how can I debug this issue? -- Thank you for your time!

[Lupine00]

1 hour ago, RealGesichtsfelsen said:

for some reason I am unable to recruit some followers with this mod enabled. Mjoll didn't start following despite having the (vanilla) follower dialogue, Stenvar (mercenary in windhelm) didn't react at all to me recuiting him. Macruio (mage merc in Riften) did work (even with DDF dialogue). I have already removed other EFF because it'd be the obvious candidate for incompatability but the problem persisted even in a new game without it. Under which circumsances is the recuriutment "ignored"/how can I debug this issue? -- Thank you for your time!

I don't have any simple answers. Mjoll worked for me last time I recruited her, but that was some time ago, and I can't recall if it was using NFF or not.

 

In the case of Mjoll, I'd say it's different to mercenaries, because she is a regular follower who just isn't in the PotentialFollowerFaction until you complete her sword quest.

 

Stenvar has been reported as buggy before, so he is on the list for investigation.

 

Is it just Mjoll and Stenvar that have problems?

 

 

Does the debug menu recruit dialog work for Mjoll?

She shouldn't be recruitable in a new game, or offer vanilla recruitment dialog. By the time you've done the sword quest, it's not exactly a new game.

 

When you say "new game", do you simply mean "game started without EFF?"

 

EFF is ... supposed ... to work, as is AFT and NFF.

 

 

Anyone else see a problem with Mjoll? Is that only in vanilla? What about with different follower frameworks?

[Lupine00]

16 hours ago, Xiaron said:

Quick DF games question, it's spoilery so;

Yes. dungeons are a common theme with several games.

[valcon767]

19 hours ago, Roggvir said:

Tried more than 50 times by now.

- only the blindfold in the inventory and nothing else

- with the blindfold equipped and nothing else in inventory

- with blindfold equipped and locked and nothing else in inventory
and i kept running in and out of cleared dungeon, waiting after each entry and exit, then sprinting away and letting follower get back - at which point i usually got "You notice your follower having a devious look" and got put in restraints (armbinder every single time, after complaining that i dont have anything in my inventory, but luckily she's got something).

I checked the game quest - it is running at stage 0.
The follower is in master faction, the event timer and will set as you wrote.

There must be some other prerequisite for getting that Jacket outcome - is it randomized? Maybe i should change some comparison value in some dialogue topic or script?

the last time i triggered this game i was in a dungeon, blindfold was equipped by DEC, and i was at over half debt, willpower of 5.  the dungeon was not cleared.

19 hours ago, Lupine00 said:

No. It's really pretty simple.

As long as you can get hellos, and have a DF, and _DFlow is at stage 10 to 99 (it should be 97, that's a bug, but that bug is everywhere).

The timer is the only thing that stops it "just going off" normally.

 

It's an OR test, but just to be sure, try setting your debt to over half enslavement debt, and of course, check your _DFlow stage, but if that isn't 10 it would be very odd.

 

That's not DF. That's Devious Helpers. Possibly you're aware, but I'm not sure why you bring it up if you are.

Do you have anything that interferes with Hellos? To Your Face?

DH shouldn't fire in a dungeon, that's a bit odd. It should really only fire in dwellings, but maybe DH checks the cleared status?

 

I would recommend not to mix DH and DF. DH subverts the removal mechanic from DF, doubles up on stuff, and generally provides free device removal you aren't supposed to get. On top of which the follower becomes even more of a split-personality than DF makes them by itself. It shouldn't block your games, but I don't know, maybe it fires its Hellos and DF never gets a try?

DH (Devious Helpers) can include cleared dungeons, adjustable in its MCM. and it is entirely possible for it to prevent the hello event that DF needs from firing.

16 hours ago, Xiaron said:

Quick DF games question, it's spoilery so;

 

  Reveal hidden contents

Was unequipping a set of gloves and boots in a dungeon. Took the gloves off first, then my DF triggered the pony game before I got the boots unlocked. My question is, is that game supposed to trigger inside a dungeon? Just outside one I've had it start, but I was in Mzinchaleft and almost to Blackreach when this happened.

 

yes.  (IIRC) that game only fires in dungeons (it checks by keywords), so it CAN fire in some outside cells if they have that keyword.

 

[Lupine00]

3 minutes ago, valcon767 said:

so it CAN fire in some outside cells if they have that keyword.

The areas outside of many dungeons have the dungeon location keyword. It's a little strange, as they are often an ordinary stretch of road or forest, but that's Skyrim for you.

I suspect it's related to the vanilla mechanic for follower commentary more than anything else.

[Lupine00]

5 hours ago, Roggvir said:

I thought about it again, and i think those piercings just shouldn't be there.

Indeed they shouldn't.

Sorry for not following your explanation very well, but it was not very easy to follow  

The whole ForceEquip thing sent this on a detour that was nothing to do with the basic piercings problem.

 

Clearly, at some point Lozeak copied the script so it had D and DE already set up.

So he added D2 and DE2 properties for the jacket (love those intuitive property names), but didn't update the script.

Not sure why he did that instead of changing what was in the properties. Maybe he thought it would save time if he copied the dialog for some other purpose.

The piercings have no business being in that fragment at all.

 

This two part addition is a very common pattern in DF, with an inventory item and a render item.

It all used to work this way.

 

The problem I went into detail on (rabbit hole) is that it doesn't even add ANY items correctly.

It doesn't matter whether it's piercings or a jacket, it's not being added correctly.

You only got one of the two parts added.

 

I fixed the script to use the jacket immediately on your very first post... But at the time I was also doing something else that had nothing to do with Skyrim that were actually important, and answering posts while I was waiting for deployments, and I forgot all about making that change. I also modified some other scripts and dialog conditions at that point, so it was all mushed together in my mind.

 

So when I went back and looked properly later, it already wasn't using the piercings, so it's only now I remember what the piercings part of this story is all about.

 

So to sum this all up:

 

1) Piercings fixed - it no longer equips those.

2) ForceEquipDevice is still used to equip the jacket, but skipEvents is set to true, so it will work reliably.

3) I re-ordered some dialog conditions to make sure there are no funny issues with the OR on willpower and debt.

 

Almost nobody would ever trigger this dialog anyway ... unless their jacket failed to equip in the first place ... and that was a problem I introduced a while back by changing skipEvents to false, as it appeared to be a bug, and sort of it a bug.

 

In the initial quest start, it was fine to change it to false, because the item is pre-added to the PC ... as long as the PC doesn't have any other jackets to exercise the other bug in (Force)EquipDevice. 

 

 

To get DF to work cleanly with DD, I can now see that I need to replace every single DD interaction with my own functions to add and remove items.

So ... that might not happen. Certainly not in the short term. It would also involve rewriting the LDC, which sort of needs doing too.

 

It is at least something I can probably do with global search/replace across all the scripts, along with batch rebuild of all the scripts.

 

FindMatchingDevice is seemingly benign function, which does what it's supposed to. The problem with it is that it's sometimes used in a way that generates serious problems.

 

 

I think a design that separate the act of deciding what device to equip from the act of equipping is better that mixing them into one API call.

DD itself offers nothing in the way of theme support, yet players ask for it over and over again.

That functionality should be part of the general act of selecting a device at any point.

[real_deal]

Hi, a quick question : does this mod remove lockpicks from the game? 

I just installed the mod along with Devious Devices AIO (didn't have any of them before) and now I can't seem to find any lockpicks - neither lootable or sold by merchants.

I can have my follower (who happens to be devious) pick the lock on chests for me but not the doors.

 

I am not sure if this is a bug/incompatibility OR an intended feature so I rely on my devious follower more. 

 

I mean, don't get me wrong - if it is a feature, i think it's genius, but if it is a bug, I would like to fix that before I progress further and have the game CTD on me and my saves... 

So... Anyone? ?

[valcon767]

2 hours ago, real_deal said:

Hi, a quick question : does this mod remove lockpicks from the game? 

I just installed the mod along with Devious Devices AIO (didn't have any of them before) and now I can't seem to find any lockpicks - neither lootable or sold by merchants.

I can have my follower (who happens to be devious) pick the lock on chests for me but not the doors.

 

I am not sure if this is a bug/incompatibility OR an intended feature so I rely on my devious follower more. 

 

I mean, don't get me wrong - if it is a feature, i think it's genius, but if it is a bug, I would like to fix that before I progress further and have the game CTD on me and my saves... 

So... Anyone? ?

no this mod does not remove lockpicks.

Devious Devices AIO (that is an SE mod) should not remove lockpicks either.

 

so something has changed the lockpicks on you.  sounds like something changed the leveled list entries for lockpicks.  

did you install any other mods since you can last confirm lockpicks were showing up correctly?

 

[real_deal]

9 minutes ago, valcon767 said:

no this mod does not remove lockpicks.

Devious Devices AIO (that is an SE mod) should not remove lockpicks either.

 

so something has changed the lockpicks on you.  sounds like something changed the leveled list entries for lockpicks.  

did you install any other mods since you can last confirm lockpicks were showing up correctly?

 

Thanks for getting back to me valcon767!

 

Hmm that's weird (and disheartening)...

Here is the list of mods installed (in the order installed) between lockpick-yes and lockpick-no:

 

Devious Devices SE 4.3

Devious Devices runtime 1.5.97 skse 2.0.17

Devious Followers Continued SE v2.12.2

DF Spank SLAL mini-pack SE - 20200623-0
 

As you can see, these are all pretty much DD and DF. 

Hm... If you have any insight, that'd be great.

 

In the meanwhile, let me try starting a new character and manually adding lockpick there to see if that shows up. 

[Lupine00]

3 hours ago, real_deal said:

Hi, a quick question : does this mod remove lockpicks from the game? 

It's not DF. It doesn't do anything to drops or leveled lists for any item.

 

I think SexLab Survival caused lockpicks to be re-priced (very high), and a rarer item on vendors and as a drop, but I'm not sure if it still does, or whether there's an MCM option for it.

It's not happening in my current game, but it's possible I deliberately merged it out.

 

I suspect something has happened to your setup in an override that's caused them to either not be in the leveled lists, or have an odd probability.

 

Open Tes5Edit with your entire LO, and look at the leveled lists for merchants and chests.

[real_deal]

5 hours ago, Lupine00 said:

It's not DF. It doesn't do anything to drops or leveled lists for any item.

 

I think SexLab Survival caused lockpicks to be re-priced (very high), and a rarer item on vendors and as a drop, but I'm not sure if it still does, or whether there's an MCM option for it.

It's not happening in my current game, but it's possible I deliberately merged it out.

 

I suspect something has happened to your setup in an override that's caused them to either not be in the leveled lists, or have an odd probability.

 

Open Tes5Edit with your entire LO, and look at the leveled lists for merchants and chests.

Yeah, if it was not intended, I don't see any reason why a specific item would suddenly just disappear. 

Odd, indeed. I will try and check what's going on. 

 

Thanks for letting me know, guys! 

[Trill0]

I'd like to report a few bugs. I'm using 2.12.2

Several patches old, repeatable: turning off forced potion quest doesn't turn it off: forced potion will still trigger at the set number of deals.  My only solution is to turn the required deals to max (12), and never have that many.

 

New one: after modular deals triggered, the modular deal screen went "blank?" except for the word "disabled" in one place.  I have never seen this one before.  The follower still lists a buyout price and allowed buying out of whatever deals I had (I had no idea what they were), ah also the front page did not list whatever deals I have as modular, it just said Bear Deal, and had a 0 or something where it usually describes them.

[Lupine00]

5 hours ago, Trill0 said:

Several patches old, repeatable: turning off forced potion quest doesn't turn it off: forced potion will still trigger at the set number of deals.  My only solution is to turn the required deals to max (12), and never have that many.

I'll have a look. I've never had that happen, despite having a lot of deals, but that might just be some random factor.

Reproducible on a new game?

 

5 hours ago, Trill0 said:

New one: after modular deals triggered, the modular deal screen went "blank?" except for the word "disabled" in one place.  I have never seen this one before.

Neither have I.

Probably needs some kind of way to reproduce it before spending any time looking for that.

 

 

This is all that's on my bug list ATM. If your issue isn't here, might need to remind me:

Spoiler

• Stenvar dialog broken, cannot hire. Also Mjoll?
• Follower complains about town collar when you're wearing prisoner chains.
• Tail says it's exhausting, but it isn't.
• Mittens not fitted if wearing gloves (but some dialog?)
• ResetQuests function in MCM code sets wrong value for resist and does not clear debt (the latter is probably necessary). Should also reset follower count?
• On enslave, such as SS, it should remove all follower in frameworks, devious or otherwise.
• In modular offered-as-barter deals, PC with belt and gag just fails out - should not be offered in the first place.
• Test all the games, especially jacket games.
• Check all (Force)EquipDevice calls.
• Forced potion flag does not work?

Note that this list doesn't include anything relating to the sketchy scanner, which I still plan to fix by removing the scanner entirely and making calls into SLA*, or the majority of DD issues that turn out to be caused by DD itself but which might be avoidable if I write my own equip/remove functions and don't rely on DD for that.

 

What I'm working on for the next release:

Spoiler

• New modular deals: spanking, sex, skooma, lactacid, milking, and some special new "devices" that actually aren't devices at all.
• Modular deal dialogs redone from ground up so you'll be told the deal you're going to get and can refuse it.
• Possibly replace stage one slut deal with mechanics with completely new mechanic.
• Bug list as noted above.

 

[Trill0]

New game didn't help, forced potion still triggered.

I did not alter any settings this time, just went to the inn in ricerwood, grabbed a follower and added 9 deals and waited in the inn.  The forced potion deal was off by default and the timer set to 0 by default.  It took a little while but it triggered.

 

The other bug wasn't present this time.  Yet?

[Lupine00]

3 hours ago, Trill0 said:

New game didn't help, forced potion still triggered.

Found it. Fixed it.

Dangling OR in a dialog condition.

 

If you want to disable it, I suggest you set the deals as high as possible.

If you use the console you can even set it to 100 or so.

 

e.g.

set _DFlowPotionDealEvil to 100.0