Devious Followers - Continued

[Lupine00]

18 minutes ago, KyLeeKu said:

Not sure if incorrect texture size cause same CTD issues in LE.

It doesn't. SE has a limitation in this respect. It's not an "incorrect" texture size, just a silly one that isn't supported by SE.

[audhol]

I thought I understood the LDC but no, I deleted things I didn't want in the .json and saved, loaded game changed cell plenty of times etc then asked for a new deal which was for cuffs. I get a message saying rebuilding device list followed by a delay of 30 seconds after which another message saying device list rebuilt and cuffs in a colour that I had deleted. Now if I check the LDC.json its back to its original state. I looked a bit at the _LDC.psc

 

 

 

"Basic use... for Users
If you delete a device in ../Lozeak Device Controller/Device Settings.json it will never be used.
If you delete a set in ../Lozeak Device Controller/Device Settings.json it will never be used.
If you delete Delete This To Rebuild Item List in Delete This To Rebuild Item List in ../Lozeak Device Controller/Device Settings.json the next time init() is used it will rebuild this list (AKA start a new game and wait! if the modder has used init() correctly"
 

 

Maybe it only works on a new game? Maybe because the script refers to dd 4.2 it gets confused? Maybe it's me being a plonker? My understanding is the only time you need to start a new game is if you delete "delete this to rebuild"

There also seems to be an option to create sets 

Sorry for being a nuisance but the randomness bugs me. I will try a new game with everything deleted except 1 item to test.

 

EDIT

 

A new game is indeed required also the sets option works a treat, just delete the sets that you don't want. I changed the dd 4.2 to 4.3 dont know if that has any effect. I think its possible to add custom items into the game by adding to the _ldc script maybe i'm gonna have a play with it.

[Lupine00]

6 hours ago, audhol said:

Maybe it only works on a new game?

No, that's not how it works.

 

Some people think they need to "Delete This To Rebuild Item List in ../Lozeak Device Controller/Device Settings.json"

after editing.

 

That will tend to destroy their edits. DO NOT REBUILD THE LIST.

Do not rebuild the list from the MCM, or via removing that text item that forces a rebuild.

Rebuilding means "reset list, erase all edits".

 

I'm going to guess you didn't delete that item, and your list rebuilt anyway?

I'd say that the most likely cause of that is ... malformed JSON ... did you syntax check?

 

Check your log file ... I think you'll probably see the JSON was rebuilt because it couldn't be loaded, or something like that.

 

 

I'm not in love with how LDC adds devices ... via manual editing of the script ... it feels like that defeats the idea of making it all user accessible.

[A Little Kitten]

Dear Lupine,

please force follower to first tell me, what my new deal is, and give me a moment redress.

i was solving this by lowering punishment to 25s and added myself through console those 25s everytime i received punishment before i managed to redress in first place.

after new patches, it took me an hour to figure our that Siera is giving me somewhere around bloody 3k dept per second instead of original 25 (it could be directly a 0 so i can disable this problem). really just a minute, in game hour, would be good enough.

[Lupine00]

1 hour ago, A Little Kitten said:

Dear Lupine,

please force follower to first tell me, what my new deal is, and give me a moment redress.

i was solving this by lowering punishment to 25s and added myself through console those 25s everytime i received punishment before i managed to redress in first place.

after new patches, it took me an hour to figure our that Siera is giving me somewhere around bloody 3k dept per second instead of original 25 (it could be directly a 0 so i can disable this problem). really just a minute, in game hour, would be good enough.

 

This is a little hard to follow, but I think the problem is that the follower doesn't give you time to work out what deal you have just made and comply with it.

 

I see this problem myself, but only in the situations where you get multiple deals at once, such as a big debt followed by "work it out", or deal enslavement from Simple Slavery.

 

If you're only getting one deal at a time, it's usually not a problem.

 

However, I have said before there should be a cooldown between making a deal and the enforcement, and there isn't, so sometimes it can feel unfair.

 

It's possible to implement such a cooldown, and I've put it on the list for 2.13

 

 

I'm still not sure about the slut deal's "Follower puts a hand on your shoulder..."

 

Should it be limited to ONE repeat only?

Should it be REMOVED entirely.

 

 

The new pattern I'm using for mechanics is that the player is always the instigator, and any events triggered only happen because the player encouraged them.

 

So, for slut deal, if I were making it fresh, the way I've done spanking and sex deals in my dev version, it would be a regular player dialog option, not a blocking dialog.

 

e.g.

• Player clicks on innkeeper
• Topics appear:
  • What have you got for sale?
  • I'm looking for work, any ideas?
  • Have you seen any strange looking people around?
  • I'm a filthy slut...
  • I'd like to rent a room. [200 gold]
  • I'd like to rent a room for my friend. [50 gold]
  • Can you fill these bottles? [10 gold]

And if the player purposely chooses the slut option, then the innkeeper reacts, exactly as before...

"You're playing some dare game? Very funny." or

"I'll be sure to let my friends know..." (for example) or

"You want me to fuck you? No problem." (etc)

 

To fulfill the deal, the player has to select the option at least three times a day, or between sleeps, whichever is shorter.

They can choose when, and who they use it with, but they have to use it at least three times a day.

If they don't, they get punished...

 

"You promised to tell people you're a slut at least three times a day. If you won't play I get to add more debt. Thanks for the cash."

Punishment debt added.

 

And the punishment is only ever possible once per day or sleep.

 

 

That's how spanking and beg for sex deals will work, but instead of "I'm a filthy slut", the existing spank dialogs are used, or some new, similar dialogs for sex.

e.g. For sex deal with willpower < 3

"Master, please would you like to make use of this slave?"

And then sex happens...

Of if you don't ever pick it, you can be punished, at most once per day (or sleep).

 

A reworked slut option would be different in that it would be present on most NPCs, not just the DF, but otherwise like those mechanics.

 

 

Is that a concrete improvement over the old slut deal mechanic?

Or is the "hand on your shoulder" part immersive, but may need turning down even further?

 

In (current) 2.12.2, if your PC is in chastity devices, slut deal will never cause sex, and it's not certain, even if unbelted and low willpower.

[Darkwing241]

1 hour ago, Lupine00 said:

Is that a concrete improvement over the old slut deal mechanic?

Or is the "hand on your shoulder" part immersive, but may need turning down even further?

It's an improvement in enough ways that I would like it

 

Blocking dialogue doesn't exactly 'work' well.  It has some undesirable characteristics like closing the dialogue after and then briefly blocking reentering dialogue with the npc.

 

Just putting it in the dialogue list with no "hand on shoulder prompt" and asking for the player to check for it all seems like a problem though.

[Lupine00]

1 hour ago, Darkwing241 said:

asking for the player to check for it all seems like a problem though.

Could you elaborate?

 

Conceptually, it's in the DF tradition of "enslave yourself" ... you may end up clicking on it more than three times if you don't keep proper count ... that's your problem.

Or you could forget to do it, and get punished ... is that so terrible?

 

 

Arguments like this were made about items you must or must not wear that the follower only enforces through debt. It's very similar.

Mods that fine you for carrying weapons or wearing armor have a similar mechanic.

 

It's not perfect, but it's at least under the player's control, and less unfair than crossing a cell boundary and getting punished before you even have time to remove your armor, which currently happens, and which I complained about long ago and haven't fixed yet.

 

One thing that could happen with sex, spanks and sluttery, is that the follower could remind you sometimes...

 

"Don't forget your promises."

or with high arousal,

"The way you're acting, you should have admitted what a slut you are."

[Darkwing241]

9 minutes ago, Lupine00 said:

Could you elaborate?

 

Conceptually, it's in the DF tradition of "enslave yourself" ... you may end up clicking on it more than three times if you don't keep proper count ... that's your problem.

Or you could forget to do it, and get punished ... is that so terrible?

 

 

Arguments like this were made about items you must or must not wear that the follower only enforces through debt. It's very similar.

Mods that fine you for carrying weapons or wearing armor have a similar mechanic.

 

It's not perfect, but it's at least under the player's control, and less unfair than crossing a cell boundary and getting punished before you even have time to remove your armor, which currently happens, and which I complained about long ago and haven't fixed yet.

 

One thing that could happen with sex, spanks and sluttery, is that the follower could remind you sometimes...

 

"Don't forget your promises."

or with high arousal,

"The way you're acting, you should have admitted what a slut you are."

I guess in my mind it would be a problem when you have a big list of options that you have to actually scroll through.  The act of scrolling through that list is not particularly interesting.

 

You make a good counter point though, forgetting and getting punished is definitely not really a problem.  It is kind of the whole point.  Maybe even this is the best way to go about making the player forget.  I can however imagine many players finding this.

 

I think the key will be to use dialogue to make it clear that things are working as intended.

 

For instance if I miss the dialogue and then 30 seconds later there is a non-immersive "your follower fines you x gold" pop up in the corner of the screen, that would be annoying.  Instead the DF could deliver an immersive line that communicates what's happening.

 

"Oh you weren't paying attention to my queue? You know you really should have your mind on me and what I want at all times!"

 

I don't think  "don't forget your promises" would be sufficient in this case, as many things would run through my head when I saw that prompt the loudest thought would likely be "wtf is this bugged!" and that's about as far from sexy as you can get.

 

Ambiguity between bugs and features I guess has always been the weakness of this deal.  I think the root of the early repetition problem was the same thing, but if the dialogue read just slightly differently each time acknowledging that repetition was happening than it could have actually been fun.

[Roggvir]

I think i found a logical flaw that should be addressed:

At least 4 times within a minute or two, the follower repeated the following message:
"Interesting. You got out that jacket all by yourself. Luckily, it's enchanted to re-equip when I say "slut" ... oops."

 

...it looked strange, getting repeated like that, so i went to investigate what is it about.
It is from a quest called _DflowGames and its supposed to force player into a straitjacket and nipple piercings.
The piercings do get added and equipped, but not the straitjacket, because the script fragment (TIF_Dflow_0A014177 on TopicInfo 09014177) does not add it if player doesn't have it.

I think at some point there was a straitjacket in my inventory, but i dropped it (or sold it) - but that was at least 30 minutes before i even saw that message for the first time, so i doubt that jacket was for this script (but if it was, this should still be looked into, because the player shouldn't be able to drop/sell it, or it should be re-added if player doesn't have it anymore, as are the piercings).


And related to the above...
Is that quest part of the deals? or where does it fit in the DF scenario?
I am a bit confused, because Stats in MCM shows all deals as inactive, so... is the MCM not working correctly in my game, or is this not part of the "deals"?
And if it isn't part of the deals, then... why is it happening?

 

[Lupine00]

19 minutes ago, Roggvir said:

The piercings do get added and equipped, but the not the straitjacket, because the script fragment (TIF_Dflow_0A014177 on TopicInfo 09014177) does not add it if player doesn't have it.

It sounds like some kind of bug.

 

I'll put the rest in a spoiler, for people that don't want it spoilered, but if possible I'd like some more information, and you may need to do some things to fix your game.

 

Spoiler

 

It's related to a game: the name of the quest is a clue there  

 

It's not a deal, and it shouldn't be firing unless the game started, which you should have noticed.

 

If it's the quest I'm thinking of, it's triggered by being in a blindfold. The follower puts the jacket on you while claiming to be giving you some armor.

It's purposely a bit implausible, for comic effect.

 

They then require you to return to civilization.

 

Once there, they demand that you perform sex, or oral sex (I forget exactly which) a number of times before they will remove the jacket.

 

Because games change the main quest stage, your DF install is effectively frozen until the stage is reset.

 

I suggest that you check your current main quest stage in the console:

 

getstage _DFlow

 

It would be helpful for confirming my theory about the problem if you let me know what it says.

If it says 200+, it's what I expect, though the exact value is still of interest.

 

Also, it seems like the quest is not progressing, and you broke it by discarding the jacket, which is now not being properly re-fitted due to a bug.

Likely DD failed to fit the jacket for some reason.

 

Perhaps some device was in the way?

Or perhaps DD just failed, as it sometimes does?

Again, any additional information would be useful here.

 

Didn't you see the dialog about the follower adding the jacket?

It might be that some other event caused it to be cleared before you could read it. Checking the quest stage will help clarify this.

 

You might experiment with consoling a jacket with the correct FormID and putting it on, while in an inn, to see if you can make the quest progress.

Or, you could use setstage _DFlow 10 to kill off the game. I'm not 100% sure that's everything you'd need to do to properly clean up. I'd have to check.

 

 

[Lupine00]

3 hours ago, Darkwing241 said:

For instance if I miss the dialogue and then 30 seconds later there is a non-immersive "your follower fines you x gold" pop up in the corner of the screen, that would be annoying.  Instead the DF could deliver an immersive line that communicates what's happening.

All punishment scenarios are associated with dialog, and in the majority of cases it's clear about what you did wrong - though sometimes it's not explicit.

 

"You're not wearing your pretty [ornaments|outfit|cuffs], so..." What are the ornaments? What outfit? Which cuffs? Ankle? Wrist? Arm? Leg?

You know you should be wearing something. Check your deals in the MCM and find out if you don't know.

But not all players know to do this.

 

It's a fine line between tedious and labored dialogue and confusing.

The lines are limited to a single line of dialog, because they are hellos, not force greets. But I don't think we want forcegreets if we can avoid it. They are prone to cause problems.

 

In many cases, over the last few releases, I've made changes to dialog to make it more explicit, but less fun.

 

 

I agree with what I think you're getting at: lack of clarity, or confusing behavior can lead to the player starting to distrust the mod, and feeling that it isn't playing fair, or working as it should. In that case, the player loses all immersion, even if the mod was working properly and the player misunderstood what should happen.

[audhol]

10 hours ago, Lupine00 said:

Check your log file ... I think you'll probably see the JSON was rebuilt because it couldn't be loaded, or something like that.

I give up, been playing around to get this to work with no success. If I delete items from the LDC but leave use sets to on it rebuilds the list each time. If I set use sets to no it doesnt rebuild the list but then gives me nothing to equip nor does it punish me for not equipping. So I deleted all sets except black ebonite and reset use sets to yes, this time no rebuild but the first item was a red ebonite corset. I can see no reference to the LDC in my log, only resistance change and registering the anims with fnis.

 

Dont worry if you dont know the problem, its no big deal.

Papyrus.0.log

[Roggvir]

1 hour ago, Lupine00 said:

getstage _DFlow

 

It would be helpful for confirming my theory about the problem if you let me know what it says.

If it says 200+, it's what I expect, though the exact value is still of interest.

It says 200.

 

1 hour ago, Lupine00 said:

Perhaps some device was in the way?

Or perhaps DD just failed, as it sometimes does?

Again, any additional information would be useful here.

I am using my personal rewrite of DD, so i could have even added some bugs in there, but in any case, that may render any additional info useless to you.
I do think that some other device was in conflict - i think armbinder.

 

1 hour ago, Lupine00 said:

Didn't you see the dialog about the follower adding the jacket?

It might be that some other event caused it to be cleared before you could read it. Checking the quest stage will help clarify this.

If i did, i do not remember. I was also running other mods (DCL and DD Helpers), so maybe i thought the convo is from one of those and just skipped it, because i was in a hurry with some quest at that time.
I loaded save from that time, before i ended up with the jacket in my inventory, and trying to reproduce it again (do you have some tips on how to improve the chance of reproducing whatever you think my happened?)

[Lupine00]

1 hour ago, audhol said:

Dont worry if you dont know the problem, its no big deal.

Did you syntax check your JSON edits?

[Lupine00]

  

59 minutes ago, Roggvir said:

I do think that some other device was in conflict - i think armbinder.

The game can't start if you're wearing a block generic item, or heavy bondage, or a suit, or a jacket (which is redundant).

 

Possibly a race condition?

 

When I look at the script in the specific dialog that was bothering you, it uses ForceEquipDevice.

It doesn't require you to be carrying the device at all - unless you changed your DD so it does.

It also won't fire if you already have HeavyBondage, so I can't find a solid bug here.

 

Problems occurring lie with your game, and almost certainly revolve around DD failing to equip a device and becoming stuck.

DD does this for everyone. DCL quests see it a lot.

 

I notice these calls have UseMutex = False, which I consider a poor choice.

That is probably asking for problems, but it would only matter if you had something else adding devices around the same time.

I'm not convinced DD mutexes "work" as intended, so it probably makes no meaningful difference.

 

Also, any DD jacket should serve to make the quest work, it doesn't have to be the one the follower puts on you.

 

Repro notes in spoiler:

Spoiler

  

59 minutes ago, Roggvir said:

I loaded save from that time, before i ended up with the jacket in my inventory, and trying to reproduce it again (do you have some tips on how to improve the chance of reproducing whatever you think my happened?)

Be just outside a dungeon.

Put on a locking blindfold.

Make sure you aren't wearing any other devices that might interfere or block (no heavy bondage, no jacket, no block generic).

Set _DFEventTimer to 0

Set _DWill to 5

Make sure you don't have any other things the follower needs to punish or react to.

Enter the dungeon through the load door.

The follower should hello you almost right away and start the quest.

Failing that, walk away from the follower, then back up to them until they hello.

 

[audhol]

24 minutes ago, Lupine00 said:

Did you syntax check your JSON edits?

GRRRRRRR I had left a comma in, showed up straight away on json checker what a plonker! Thank you for your help and patience.

 

BTW I triggered the jarl easter egg. Superb, excellent work lupine.

[Lupine00]

33 minutes ago, audhol said:

Superb, excellent work lupine.

Lozeak must take all the credit for that.

As far as that goes, I've done nothing but tweak the dialog and clean up a few scripts.

 

[Roggvir]

15 minutes ago, Lupine00 said:

it uses ForceEquipDevice.

It doesn't require you to be carrying the device at all - unless you changed your DD so it does.

Is it possible you are mistaken? - what i see is , you don't need to carry the Nipple Piercings, they will get added, but the jacket is handled differently.
The script fragment calls ForceEquipDevice with arguments like so:

Quote

libs.ForceequipDevice(
    akActor = PlayerRef,
    deviceInventory = 08014929:zadx_piercingNShockSoulInventory,
    deviceRendered = 08014928:zadx_piercingNShockSoul_scriptInstance,
    zad_DeviousDevice = libs.zad_DeviousStraitJacket (= 0A060A46:zad_DeviousStraitJacket),
    skipevents = false,
    skipmutex = true
)

...and inside the function the deviceInventory is indeed added.
But the jacket is equipped via ReEquipExistingDevice(akActor, zad_DeviousDevice) which is using the following condition to equip items:

Quote

if akActor.GetItemCount(zad_DeviousDevice) > 0 && !akActor.WornHasKeyword(zad_DeviousDevice)
    ...akActor.EquipItem(f, false, true)
endIf

So, if you do not have zad_DeviousDevice in your inventory, it won't get equipped/added.

Unless... maybe there was a new version of DD for Oldrim where they changed it???
I did not change WHAT things do in my rewrite, i only optimized it and changed HOW are things done - so i replaced hundreds of external functions and property calls with local functions and internal script variables, moved inventory<->render item relationship and all related device settings to JContainers (so no more PlaceAtMe crap), added support for morphable gags, etc. but no existing "feature" has been changed in what it does and all conditions for everything are stil lthe same.

[Roggvir]

2 hours ago, Roggvir said:

So, if you do not have zad_DeviousDevice in your inventory, it won't get equipped/added.

Just a tiny correction, so nobody gets confused:
it is a keyword, so the proper wording should be "So, if you do not have any item having zad_DeviousDevice keyword on itself, it won't get equipped/added."

[Lupine00]

2 hours ago, Roggvir said:

Is it possible you are mistaken?

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.

 

 

Originally, I lazily inferred the intended semantics of ForceEquipDevice from its consistent use throughout DF and DCL.

In DF either EquipDevice (which is pretty similar) or ForceEquipDevice are sometimes used to add devices the player doesn't have in their inventory.

And by and large, they get added, and it works fine, because it does do what I say, which I think I can demonstrate.

In certain conditions.

 

It used to be used absolutely everywhere in DF, but LDC replaced many of those calls. The properties to inject the devices still persist as evidence however.

And we know that in the past, DF often managed to add devices successfully to the player. It's not its most common pattern, but it does do it.

 

Looking at the code for FED, it takes pains to ensure your inventory contains at least one copy of the object being added.

It does this before equipping the device of course. NO. Not all ... that would be way too obvious ... and this possibly threw you off.

It doesn't check and add the device to inventory until after calling ReEquipExistingDevice.

 

It seems like DD has it backwards. What is the logic of ensuring the device is added AFTER calling ReEquipDevice?

Had it worked the other way around, and assuming it didn't blindly add an item you already had again, it would obviate the need for the entire rest of the function.

I can't even begin to figure out why it would be done afterwards and not before, but there could be a sensible reason for it.

I suspect that there was a sensible reason once, and it got erased by successive edits, finally resulting in weird code.

 

ReEquipExistingDevice is just a "first try" at equipping the device. It only calls EquipDevice if you have something with the correct keyword in your inventory.

If you have an item in your inventory, then it will be equipped from the inventory.

 

So that won't equip the jacket when called by DF, unless (no don't think that thought).

 

But... Check out the code in the spoiler below...

Further down we have: deviceInventory getting equipped no matter what.

And EquipDevice does not require you to have the device for it to succeed.

That's just how Skyrim works.

So, the inventory device is equipped, and if skipEvents is True, then renderedDevice also gets equipped too.

 

So, as it turns out, the fault in the DF code is not that the device is not in inventory, it's that skipEvents must be set to True to cause an non-pre-owned device to be added. So skipEvents doesn't do what it implies... It does a lot more... and personally I consider unexpected and undocumented behavior of this order a highly undesirable pattern. Or put less equivocally, it's a bug. Either the device should be reliably equipped, or not, one, or the other, pick one and stick with it. Setting skipEvents - a seemingly unrelated detail - shouldn't alter that fundamental behavior.

 

But it does ... and there's more to puzzle over here ...

 

Spoiler

; Force equips an item on an actor even when a (generic) device of that type is already worn. This will NOT work on quest/custom devices. 
; Returns true if the item was equipped successfully, otherwise false.
Bool Function ForceEquipDevice(actor akActor, armor deviceInventory, armor deviceRendered, keyword zad_DeviousDevice, bool skipEvents=false, bool skipMutex = True)
    if !skipMutex
        Log("ForceEquipDevice called for " + deviceInventory.GetName())
        AcquireAndSpinlock()
        Log("Acquired mutex, equipping " + deviceInventory.GetName())    
    EndIf
    ReEquipExistingDevice(akActor, zad_DeviousDevice)
    if WearingConflictingDevice(akActor, deviceRendered, zad_DeviousDevice)
        Log("ForceEquipDevice() called for one device, while already wearing a device of the same type:" + zad_DeviousDevice)
        If ManipulateGenericDeviceByKeyword(akActor, zad_DeviousDevice, equipOrUnequip = False, skipEvents = skipEvents, skipMutex = skipMutex)
            Log("Force equip: Conflicting item removed successfully!")
        Else
            Log("Force equip: Failed to remove worn item. Aborting.")
            if !skipMutex
                DeviceMutex = false
            EndIf
            return False
        EndIf
    EndIf
    if akActor.GetItemCount(deviceInventory) <=0
        akActor.AddItem(deviceInventory, 1, true)
    EndIf    
    if skipEvents
        akActor.EquipItem(deviceInventory, false, true)
        akActor.EquipItem(deviceRendered, true, true)
        if !skipMutex
            DeviceMutex = false
        EndIf
    else
        akActor.EquipItemEx(deviceInventory, 0, false, true)
    Endif
    return True
EndFunction

 

 

Function ReEquipExistingDevice(actor akActor, keyword zad_DeviousDevice)
    int i = akActor.GetNumItems()
    if akActor.GetItemCount(zad_DeviousDevice)>0 && !akActor.WornHasKeyword(zad_DeviousDevice)
        Log("ReEquipExistingDevices() is working:" + akActor.GetItemCount(zad_DeviousDevice))
        Form f = FindMatchingDevice(akActor, zad_DeviousDevice)
        if f
            akActor.EquipItem(f, false, true)
        EndIf
    Endif
EndFunction

 

bool Function WearingConflictingDevice(actor akActor, armor deviceRendered, keyword zad_DeviousDevice)
    if akActor == none
        Error("WearingConflictingDevice received none argument.")
    EndIf
    if akActor.GetItemCount(deviceRendered)==0 && akActor.WornHasKeyword(zad_DeviousDevice)
        return true
    Endif
    return false
EndFunction

 

It turns out if we really want to understand the intent of ForceEquipDevice, we need to look at its sibling, EquipDevice.

Here we get an explanation of the intent of skipEvents, and clearly, it's a toxic parameter. It doesn't do what it's intended to, and it does do something else!

At least, if we believe the comments.

 

Spoiler

; Equip device on actor.
;;; Function EquipDevice(actor akActor, ; The actor that this should operate on.
;;;                      armor deviceInventory ; The inventory device (See above explanation)
;;;                      armor deviceRendered ; The rendered device (See above explanation)
;;;                      keyword zad_DeviousDevice ; The keyword for this class of objects (See above explanation)
;;;                      bool skipEvents ; Skip onequipped event for this call. Useful for swapping items of the same type (Switching plugs, belts, collars, etc)
;;;                      bool skipMutex ; Internal use parameter only. Used for speedily recovering from remove-all, and similar effects. Don't use this.
;;;                      )
Function EquipDevice(actor akActor, armor deviceInventory, armor deviceRendered, keyword zad_DeviousDevice, bool skipEvents=false, bool skipMutex=false)
    if !skipMutex
        Log("EquipDevice called for " + deviceInventory.GetName())
        AcquireAndSpinlock()
        Log("Acquired mutex, equipping " + deviceInventory.GetName())
    else
        ;Log("Not waiting for mutex. Proceed.")
    EndIf
    ReEquipExistingDevice(akActor, zad_DeviousDevice)
    if WearingConflictingDevice(akActor, deviceRendered, zad_DeviousDevice)
        Log("EquipDevice() called for one device, while already wearing another:" + zad_DeviousDevice)
        if !skipMutex
            DeviceMutex = false
        EndIf
        return
    EndIf
    if akActor.GetItemCount(deviceInventory) <=0
        akActor.AddItem(deviceInventory, 1, true)
    EndIf
    ; skse version calls OnEquipped events. Fucking papyrus, lol.
    ; Ugly design due to not realizing limitation of papyrus. Might refactor this later.
    if skipEvents
        akActor.EquipItem(deviceInventory, false, true)
        akActor.EquipItem(deviceRendered, true, true)
        if !skipMutex
            DeviceMutex = false
        EndIf
    else
        akActor.EquipItemEx(deviceInventory, 0, false, true)
    Endif
EndFunction

 

However, my biggest problems with this code lie somewhere else entirely.

 

Let's return to the intent of this function. It is (apparently) designed to equip an explicitly passed item pair: those exact ObjectReferences and no others.

 

But it doesn't do that.

It does something completely different.

 

If you already have a device with the right keyword in your inventory, it will find ANY device that has that keyword and equip it.

You might even have the exact correct device, but that will not necessarily be the one equipped!

FindMatchingDevice is just looking for a keyword; it doesn't know the actual device you really want out of multiple valid candidates; it can't know, the value isn't available to it.

 

It will then check to see if you have a different device to the one you asked for equipped, and if that device is equipped it logs an error, then removes the "conflicting" device.

 

Now you'd think that if it found a different device by keyword and equipped it, it will possibly get a conflict when it checks WearingConflictingDevice, even though it just equipped that item... But no, because this is DD code, and WearingConflictingDevice doesn't do what it says on the tin either (nothing does here) at least, not in a meaningful sense. It just checks you have a device with the right keyword, and that you have the expected device in your inventory at all, whether it's equipped or not.

 

You might say that this defective behavior of WCD dodges a bullet because otherwise we would see even more nastiness where the fitted item was yanked, then attempted to be replaced with the correct item, while the add was (probably) still running its events. Or not. Because this is Papyrus, you might have time to go to the shops between these two things executing, or they may be instant. If it's instant, the device would still be equipping.

 

As it is, because WCD has a faulty definition of conflict, that bullet is dodged, and the only problem is that you end up wearing the wrong device. That's fine ... right?

Alas. No.

Remember our little friend skipEvents from before?

If that's true, we're going to equip the correct device anyway. Again. Even though it was possibly already equipped, or something else was just equipped.

And if it's false, it's worse, because we end up equipping a mismatched inventory device.

This is probably the cause of most seriously broken item fittings in DD?

 

And for the finisher - and I think we've all seen this - if you do not have the device, and skipEvents is true, and the device is added, it triggers a little Skyrim bug:

 

To quote from the CK documentation for EquipItem:

• If the calling actor does not have akItem, they will be given one. It is best, however, to add the item with AddItem (), then equip it as the item might not otherwise register as equipped.

Does that sort of glitchy behavior sound familiar?

 

I hesitate to the count the exact number of bugs here; I haven't even got into the mutex issues.

I guess there at least three significant issues, and a glance at EquipDevice shows that it has some issues too. Five bugs? Seven? I don't know, depends how pedantic you are about what.

 

The take-away is that it's actually safer to use EquipDevice almost every time, and that all of this is messed up by the broken assumptions in ReEquipExistingDevice. Even if you carefully add the device to inventory first, which solves one problem, if there are multiple devices, some other device that the player already had could be equipped instead.

 

This is possibly why we see so many problems with quests like the Chloe quest in DCL, where numerous items that share keywords accumulate in your inventory.

 

I think @Inte should take a glance at this, as he may already have been down this path of perils, and know what is the best and safest way to avoid ReEquipDevice ever getting involved in your mod. I'm guessing that probably the best way is to implement all device add code in your own mod, from first principles using the vanilla Actor script's EquipItem()

You'll miss out on DD's mutex/locking, but that's pretty much good for nothing, as half the people that do anything disable it, and it doesn't really work, so it likely just makes things go quicker.

 

So, if you want to stay safe. Never let different items that share keywords get into your inventory, including duplicate items.

I guess the upside for @Rogvir is that in his personal DD version he can just fix this, if he even has the problem in the first place.

The puzzle for him is whether to emulate the scary side-effects of skipEvents for compatibility.

 

EquipItem is not as bad, but I believe it can still generate mismatched inventory and render devices, which is almost certainly the cause of many of the nasty broken devious we experience.

 

The decision for me is whether to fix my own DD privately, and then have it not represent what players run on, or leave it as it is and experience broken devices in my own game. I see DD as a cost sink; time I spend on it is never a benefit to others, so I should probably not fix it for myself.

 

Well, that's wasted most of my evening, but it was educational, wasn't it?

[audhol]

36 minutes ago, Lupine00 said:

Well, that's wasted most of my evening, but it was educational, wasn't it?

I know it's none of my business but since following your thread you seem to spend a lot of time chasing bugs related to DD. I still don't understand why you need to have it as part of DFC. What are you actually gaining from it apart from the meshes armbinder idles and vibe events? 

#Undeviousfollowersthethird

[Roggvir]

4 hours ago, Lupine00 said:

Spoiler

Be just outside a dungeon.

Put on a locking blindfold.

Make sure you aren't wearing any other devices that might interfere or block (no heavy bondage, no jacket, no block generic).

Set _DFEventTimer to 0

Set _DWill to 5

Make sure you don't have any other things the follower needs to punish or react to.

Enter the dungeon through the load door.

The follower should hello you almost right away and start the quest.

Failing that, walk away from the follower, then back up to them until they hello.

 

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?

[Lupine00]

8 minutes ago, audhol said:

What are you actually gaining from it apart from the meshes armbinder idles and vibe events?

• Meshes and textures (you mentioned these).
• All the armor items that go with the meshes and make them useful.
• Animations, with mostly working addition and removal of override animations relating to meshes.
• Ability to interoperate somewhat sensibly with other DD mods.
• Mods that add DD items in traps that create situations for the PC that DF exploits.
• Not having to remove and replace all the code that uses it ... ok ... it may be I need to replace the vast majority of code that interacts with DD to fix some problems.

[Lupine00]

15 minutes ago, Roggvir said:

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?

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.

 

15 minutes ago, Roggvir said:

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

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?

[Roggvir]

55 minutes ago, Lupine00 said:

Further down we have: deviceInventory getting equipped no matter what.

And EquipDevice does not require you to have the device for it to succeed.

That's just how Skyrim works.

So, the inventory device is equipped, and if skipEvents is True, then renderedDevice also gets equipped too.

I know it is a little detail now, since we strayed into "how bad DD is", but still, if i may just quickly get back to the original issue...
Yes, having multiple devices with same kwd often results in problems, 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).

My point being:
The problem with player dropping/selling the jacket, would be fixed, if the script fragment here would add the item (as it does with the piercings, which gets AddItem'd if not in inventory).
It would NOT fix other problems in all the other situations you mentioned, but it would fix this one.

Though i do see that it may seem quite pointless, as ther ewill be still dozen other issues and situations when it won't work, until DD gets a thorough rewrite.
 

DD is an incredible can of worms, no doubt about that ?

 

1 hour ago, Lupine00 said:

I guess the upside for @Rogvir is that in his personal DD version he can just fix this

Well, i wish.
Yes, you can fix it in your private version, but REALLY FIXING IT? ...in many cases, that would actually mean changing WHAT the functions do, not just HOW, and that would render almost every DD-based mod incompatible with your version, and then you would have to rewrite those mods too - who's got time for that?
I had enough of rewriting DD and DCL while keeping their features unchanged, and it was big enough task that i am not eager to repeat it.

And it has a bitter aftertaste, because the fact that nobody else can use it, makes it feel a bit pointless at times.
 

Anyway, good talk.