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

[PrivateProfile]

I downloaded the new version and when i went to uninstall 6.4 i loaded back into my save with no cursed loot to speak of in NMM but the esp and files were still active. I realise this is most likely the fault of NMM and not cursed loot but i was wondering if there was a way to find where DCL files are in the data folder to uninstall manually. If there is another fix for this please help me.

[Teddar]

1 hour ago, LazyBoot said:

From the changelog

 

 

Thanks!

[Nazzzgul666]

1 hour ago, gearshreder220 said:

I downloaded the new version and when i went to uninstall 6.4 i loaded back into my save with no cursed loot to speak of in NMM but the esp and files were still active. I realise this is most likely the fault of NMM and not cursed loot but i was wondering if there was a way to find where DCL files are in the data folder to uninstall manually. If there is another fix for this please help me.

The changelog says you'll need a new game, so no it's not cursed loots fault nor NMMs, it's yours.

You might try to follow the procedure to make a clean save, throw one or more clean savers on it, make sure old and new version have exactly the same place in your load order and hope that it works, but... neither Kimy nor me believe in such a thing as a "clean" save, the only way that works 100% is really a new game.

[pitcherjak45]

Having an issue with Supply and Demand quest.  Completed all activities for Vekel and returned to Dollmaker, however, the quest is not completing and no further dialogue with Dollmaker.  Also, not allowing me to start any additional quests for her.  I have the rewards from completing the quest and all items have been removed, however, the biggest problem is that I have now lost any ability to Fast Travel.  Also, resetting DCL does not do anything to update this or completing the quest through console.  

 

Anyone experiencing or have any suggestions?

 

Thanks.

[Zaflis]

2 hours ago, pitcherjak45 said:

Having an issue with Supply and Demand quest.  Completed all activities for Vekel and returned to Dollmaker, however, the quest is not completing and ...

Load back to point before turn-in and make a quicksave. Complete quest until it works, is what i'd do. Not that i've seen the bug yet. Check quest journal to verify it's really in the bottom side gray area now. Might want to restart Skyrim to make sure there's no lingering scripts or other stuff interfering.

[MrEsturk]

EDIT: It has come to my attention that this method of injecting new rules is a total backwards mess. I've posted a much cleaner, easier method for adding new rules on the next page.

 

[imaster15]

Have a issue when talking to nazeem in hall of the dead, as soon as the event triggers my game just crashes, tried turning all mods off that cursed loot does not depend on and no effect, anything else i can try?

[Lupine00]

MyEstrurk ... as you may (or may not) recall, in response to your initial request for information about how to make XDFF work, I posted this guide to creating new rules (see below).

 

I guess maybe you didn't see it, because it appears from your notes that the way you are registering rules is unreliable, and not really how they were designed to register.

 

On 11/9/2018 at 6:59 PM, Lupine00 said:

 

On 11/9/2018 at 2:05 PM, MrEsturk said:

So I'm liking the XDFF system but I'm wondering how you add a new rule script to the list of possible enforced rules. I've already scripted one but for the life of me I can't find were the list of dcur_df_baserule referencealiases are stored so new ones can be added for registration or were the actual code for the "dcur_df_registerrules" event is.

There is actually some help in dcur_df_QuestScript.psc and more in the base class (which you clearly found).

 

The core to all this is dcur_df_QuestScript. If you make a quest, and add this script, you can make your own XDFF quest that has custom dialogs; anything you like.

You'll need to put the required aliases into it - like you'll find in dcur_dominantfollower quest, and that's pretty much the bare minimum config you need to get going.

 

The easy way in the CK is to replicate the aforementioned quest. You really don't want to have to fill out all those device properties again by hand!

Or you can simply change the existing dcur_dominantfollower, if your intent is also to change Leon and Leah; which will save you a bit of faffing around.

 

Kimy doesn't indicate if her expected use pattern is for you to make a new quest, or modify the existing one; there are obviously cases where you might want to do one or the other.

However, I suspect that if you make a new one, you might possibly come across a bug or two that is caused by an assumed reliance on the existing quest in some way, but I think those are bugs that should be found and fixed IF they exist, as the system would be overly restrictive if you could only have one quest and one set of rules.

 

 

You will need to map the aliases you've created on your (new) quest into the matching properties in the dcur_df_QuestScript script.

This is obviously already done if you use the existing one.

 

 

The rule scripts need to be added to the Player alias in the quest, so that they can execute on the player.

 

Also, the Register() function in dcur_df_QuestScript can be used to register rules. So, you could have some other quest add rules into the dcur_dominantfollwer quest, if you like.

 

You can have up to 125 rules (a curious number).

The registered and active rules are kept in an array - you can inspect them you wish, because they're exposed as properties.
The registered rules are kept in an array property called Registry.

The active rules are in an array property called Slots.

 

Slots and Registry are not pre-loaded with values via their properties - you'd be advised not to try and populate them that way; they are created and initialised in script by calling: 

 

StartQuest( masterActor )

 

This intialises the rules, both Registry and Slots to an empty state.

It sets a new master to the master alias

The master will be made into a potential follower, but not actually set as a follower; that's left to the player.

The player will get a collar. There are two collars built in normal and strict. You can set up the properties to use different collars if you make compatible collars of your own.

 

A mod event "dcur_df_registerrules" is sent when rules should be registered, so other scripts, possibly on other quests, can listen and register rules at this point. The base rule quest listens for this event and registers your rule, so normally you can consider them "self registering".

 

Following DRY, I believe there's a little bit of the startup that should simple be replaced with a call to the Initialize() function, and the debug check added to that function, but that's incidental. There's also a little optimisation that can be done in Register, I'm sure Kimy will spot it now I've mentioned it.

 

During startup, and periodically, if there are less slotted rules than the configured limit, a new rule may be added; there's some randomness involved.

 

 

Now, the mod event is how you get your rules set, and it should be evident that you have no idea what other mods may have rules that hear that event and react...

 

There is a small hazard here, as mods responding to the event should be sure they check the source of the event is (one of) the quest(s) they are expecting, or else rules could be added to unexpected XDFF quests, where they are not supposed to go.

 

But the main thing is that with a shared resource like dcur_dominantfollower unexpected rules may very well be added there, so be defensive.

If you use your own quest, and if listeners are well behaved and check the originator, you should be safe.

 

However... The base rule will always blindly auto-add your rule, unless you override that functionality.

The base rule implementation doesn't check the event source, because it has no way to know what sources it should listen to, so if you add rules for your mod/quest, and don't want them to be added to every single XDFF quest at startup, you must override the following:

 

Event OnRegisterRule(string eventName, string strArg, float numArg, Form sender)    
    RegisterRule()
EndEvent
 

Perhaps, before this gets set in stone, Kimy could change RegisterRule() so that it takes the sender Form as a parameter, so developers who want to register selectively can override at the RegisterRule() level instead?

 

It would be a little more flexible. If developers could override RegisterRule, they can call the base version in their override after filtering, while allowing non-breaking changes to the event in the base script if the framework wants to add its own filter system down the track. Right now, overriding it is no good, because you don't know the sender at that point.

 

Obviously, just because you have a rule registered doesn't mean it must be used automatically. You can set the ManualRule property true, which will stop it being used at random, or you can just have the EnactRule function deactivate the rule if it's not supposed to be running.

 

As I note above, the system issues a ModEvent when events should be registered, and you should register in response to that.

If you just add events in other ways, your events have the potential to be lost on quest restart, or (attempted to be) multiply added.

 

As the BASE RULE already has the registration code on it, you don't need to add it ... normally.

 

However, adding rules from a foreign quest, you might have some problems if you didn't correctly set the dfs property on your new rule prior to its first execution. That is what you must set to make things work, in that respect - but I didn't discuss base rules much above, because you had indicated you already understood them.

 

If your rules in your foreign quest are not receiving the registration ModEvent, you could write a handler that can catch that event to do your registrations.

But that's an obscure case, you shouldn't need to do that normally, and you didn't need to do it here.

 

As it's a ModEvent your quest can definitely receive it, and as I already observed, the base rule registers all rules to listen for that mod event.

 

However... The base rules rely on OnPlayerLoadGame to do this ... and perhaps this is where you had problems?

 

OnPlayerLoadGame is only sent to the player actor. If you want to see it elsewhere, you need to catch in on the player and adapt it yourself to your quests. However, aliases with the player in them will get this event. So, as long as the player is in your alias on on initialisation, it should work.

 

 

Your example spell doesn't explain this, and uses Register directly to add the rules, which is an option I mentioned, but immediately explained is for esoteric uses only, such as if you are overriding the registration in the base object to do registration filtering... You're giving a confusing/misleading impression of how rule registration lifetimes work.

 

While multiple registrations of the same rule (as your spell can easily perform) are discarded by the Register function (it returns the existing slot number if they were already present), they still aren't ... ideal, or necessary ... and are easily avoided.

 

The rules are wiped at quest start, and after that is when it fires the event to add the rules.

That event is what you should use to add rules on a particular quest startup.

 

That is why (a couple of days ago) I made such a song-and-dance about how Kimy isn't passing the sender into RegisterRule(), because that is the most logical point where rules belonging to any or all mods should be deciding to add, or not add themselves in response to a particular XDFF quest instance starting up.

 

Anyway, if guides are being offered up, that may set modders in directions that will continue for months or years to come, it will help the entire system behave dependably if we can establish the correct best-practices up-front. Once confusing information gets out, it tends to propagate; and thus years after the release of the CK, we still see new mods that create toxic cloaks with insufficient conditions and overly heavy applied scripts, and people calling heavy processing in OnHit events, and abuses of animation events like "LeftFoot" and "RightFoot".

[Nat the bat]

Been playing this mod for a while, having quite a bit of fun. However, I am currently doing the Chole quest, and cannot find any not whatsoever on any or near any of the Imperail dead guards in Helgen keep. If anyone could tell me where the note is or give me the item id, I'd be quite happy. 

[fred200]

3 minutes ago, cybermitch said:

Been playing this mod for a while, having quite a bit of fun. However, I am currently doing the Chole quest, and cannot find any not whatsoever on any or near any of the Imperail dead guards in Helgen keep. If anyone could tell me where the note is or give me the item id, I'd be quite happy. 

Keep going down the tunnel where you found Chloe. You will encounter an ash pile that just ports you about 20 feet forward (very confusing).

Keep going - check all the bodies in the cave. Hopefully this is helpful - and not spoilerish.

[LazyBoot]

11 minutes ago, cybermitch said:

Been playing this mod for a while, having quite a bit of fun. However, I am currently doing the Chole quest, and cannot find any not whatsoever on any or near any of the Imperail dead guards in Helgen keep. If anyone could tell me where the note is or give me the item id, I'd be quite happy. 

Search the bodies further into the caves.

[fred200]

I am still having a great time with the Dollmaker as my lead slave / trainer. Retaining all her dialogue except store is wonderful.

I can still buy Sasha restraints from her. Chloe is a run-of-the mill slave, since she had no unique dialog to lose, and I had to be able to park her.

Sasha - now Sasha...  She is far too valuable to enslave. She loses all her unique dialog that makes her Sasha if you do.

Been playing with all the dominant options, figuring out what happens if she dominates - and how to put her collar back on.

Still not sure what effect her disposition has, unless maybe better favors. I did figure out everything that raises and lowers it.

Seems like console is the only way to change hardcore.

Still having a good time with this mod - and Dollmaker is hot...

[LazyBoot]

7 minutes ago, fred200 said:

Keep going down the tunnel where you found Chloe. You will encounter an ash pile that just ports you about 20 feet forward (very confusing).

Keep going - check all the bodies in the cave. Hopefully this is helpful - and not spoilerish.

That teleport is there for those using LAL, so they can get past the cave-in.

[fred200]

1 minute ago, LazyBoot said:

That teleport is there for those using LAL, so they can get past the cave-in.

If you are not using LAL - it is just confusing. I spent a good hour figuring out where it dropped me - 20 feet down the path.

[Nat the bat]

I'v done all that. None of the bodies at all have anything other than random keys. I've searched everyone and around everyone. 

[fred200]

2 minutes ago, cybermitch said:

I'v done all that. None of the bodies at all have anything other than random keys. I've searched everyone and around everyone. 

I am sorry - I can't help you then. Whatever note it was is long gone to history.

I will dredge around in old saves a bit and see if I can dig something up. Hopefully someone else can help with it sooner.

[LazyBoot]

8 minutes ago, cybermitch said:

I'v done all that. None of the bodies at all have anything other than random keys. I've searched everyone and around everyone. 

I found it on one of the ones in the area with the spiders

 

Spoiler

 

[fred200]

12 minutes ago, LazyBoot said:

I found it on one of the ones in the area with the spiders

 

  Reveal hidden contents

 

Pretty much in the center of that spider room. You might have trouble finding the passage.

"Torn note", refid xx0DE977. Don't use those though unless last resort. It is more fun finding the corpse...

And people wonder why I keep hundreds of saves...

[Lupine00]

People keep asking where XDFF is in the MCM...

 

I believe some people read Kimy's words rather optimistically when she accurately described exactly what XDFF does:

Spoiler

Added: Extensible Dominant Follower Framework (XDFF): XDFF is a rule-based system for modelling Dom/sub relationships. It takes advantage of the circumstance that most aspects about such relationships are rules, e.g. "You need to kneel in my presence", or "You need to wear a blindfold when you sleep". With XDFF, these rules can be modeled in encapsulated scripts and attached to a handler that selects rules based on their type (e.g. permanent rules, random rule of the day, errand etc). The rules script contain all necessary code to evaluate compliance, hand out warnings or even punishments etc. No part of any rule code is located anywhere but its own script. Why is this cool? Because it's really easy to add rules or dialogue to a dominant follower, even from 3rd party mods. If it turns out that people don't like a certain rule, all I need to do is clicking on the rule and delete it. Or if If people want a dominant follower to behave differently, they can even write a plugin and make it happen! And the best thing is that XDFF works for arbitrary NPCs. Any character can be a dom, not just Leon or Leah.

 

Specifically, she said:

"If it turns out that people don't like a certain rule, all I need to do is clicking on the rule and delete it. Or if If people want a dominant follower to behave differently, they can even write a plugin and make it happen!"

Some people seem to have interpreted this as the player being able to click in the MCM to enable/disable a rule - probably because the old Leon/Leah MCM let you do that, but that's not actually what she said at all, she said "all I need to do" ... and then the note about writing a plugin makes it clear that you need to go in the CK to change this stuff (for now).

 

An MCM feature could find all the registered rules and let you modify the "ManualRule" property to enable/disable them from consideration, or find all the active rules and let you remove them at will, but there is no "IsEnabled" property that serves to cleanly switch rules on/off, perhaps due to reasonably fear of redundancy. The problem with using ManualRule is that if a mod sets it, it's not clear what rules with ManualRule set true are valid candidates for an MCM interface to set to false...

 

I might have mentioned it before, but a property on rules that gives them a "weight" for random activation would help with menu-driven customisation, and just generally.

Similarly, having a property that is a single point way to turn rules on/off - without removing them - and without making ManualRule do double duty, might be a good idea.

There is already a probability of enforcement, but that's an entirely different thing.

 

Also, a description property that's not for runtime use (for the player to see immersively) but instead for display in an MCM that can edit rules, would be ... forward thinking. Such a description could include warnings about risks from enabling or disabling the rule, things to watch out for, etc.

 

Also, please, could you pass the sender form into RegisterRule(), so rules can filter on the event source before choosing to register themselves.

I know I said this twice already, but its easy to miss things on the forum, especially things I write, because ... quantity.

 

I know this is an early implementation, and its still incomplete, and perhaps still evolving, which is why I'm suggesting these things now.

 

Once the system is well established, it will be more difficult to add such features without breaking a lot of things.

[Lupine00]

1 hour ago, fred200 said:

If you are not using LAL - it is just confusing. I spent a good hour figuring out where it dropped me - 20 feet down the path.

Perhaps in some future version, it could detect whether LAL is present, and if it isn't, not teleport you at all?

 

Personally, I never understood the reasoning behind LAL having the cave-in blockage, as it's not afraid to make bold edits to other parts of Helgen. You get all the way down to it, and then have to go all the way out and back in through the cave to do everything in LAL. It could at least have added a "squeeze through hole" activator, and I'm glad Kimy finally added one - though adding it as a dust pile instead of an invisible activator that lets you (appear to) click on the opening itself is a little quirky. Another way would be an auto load door that took you to a replacement for the cave section.

[MrEsturk]

In light of Lupine00's somewhat over-complicated explanation that I was setting up injecting new rules via external mods wrong I sifted through their notes, applied what I already learned with my clunky old methods and came up with a much simpler way of adding new rules to a default XDFF dom (Leon, Leah, or one that copies their quest from my mod).

 

To create a mod that injects more rules into a normal XDFF dom (Intermediate understanding of CK and Papyrus required):

 

- Create your new rule scripts (dcur_df_baserule children) as normal. Make a mod containing a blank "Start Game Enabled" Quest that contains a player alias similar to the player alias in Devious Cursed Loot's "Dominate Follower" quest. Insert all your new rule scripts there, setup similar to the way the default rules are setup in the default quest's player alias. You can leave the DFS parameter of your new rule scripts blank: it won't be setup in CK for this.

 

- All your new rule scripts need to contain the following lines of code, so they can get their DFS parameter properly setup externally without having to alter any DCL source files:

 

Spoiler

;Since this is an external mod override the default "OnRegisterRule" so we can get the DFS parameter properly setup before the rule gets registered.

Event OnRegisterRule(string eventName, string strArg, float numArg, Form sender)    

    ;Let's get that DFS parameter setup externally so we don't need to modify any DCL source files....

    ;NOTE: 0E9B75 is the FormID number of the Dominate Follower quest in Deviously Cursed Loot.esp, which is where the needed script is stored.
    dfs = Game.GetFormFromFile(0x000E9B75, "Deviously Cursed Loot.esp") as dcur_df_QuestScript

    ;Give clunky Papyrus a chance to catch its breath so its doesn't pull any of that script command skipping nonsense...
    utility.wait(0.2)

    ;And now that all the changes are setup let's register the rules as normal.
    RegisterRule()
EndEvent

 

Function EnactRule()

 

    ;Setup the DFS parameter one more time just as a failsafe

    dfs = Game.GetFormFromFile(0x000E9B75, "Deviously Cursed Loot.esp") as dcur_df_QuestScript

    ;Once again Papyrus a chance to catch its breath...
    utility.wait(0.2)

 

    #Add all your EnactRule scripts commands as normal beyond this point.
 

EndFunction

 

As long as you have added those script commands in all your new rule scripts and they have been added to a quest player alias just like the default rules all the automated registration features Lupine00 brought up should do their job and register the new rules with all the default ones when you get enslaved.

 

Keep in mind if you want to add new rules after you have already been enslaved I believe you will need to add some way to trigger the ResetRules() command from the DFS quest to get them injected in.

 

So far I've added the following new rules to my private version of the game successfully using this method:

 

- Being forced to wear specifically a blindfold, gag, bondage mittens or armbinder for a span of time.

- The master taking any alcohol you possess every rule check and consuming any they have collected every few random hours (or forcing you to drink it)

- The master always stripping you when you enter a city or other safe place (Unless you're wearing the rubber dress rule dress).

- The master trolling you if your wearing any vibrating DDs by activating them (rarely in unsafe places and relentlessly in safe places)

- The master making wear a ponygirl outfit set for 24 hours

[SleepyJim]

7 hours ago, cybermitch said:

I'v done all that. None of the bodies at all have anything other than random keys. I've searched everyone and around everyone. 

My first time playing through that quest none of the bodies added by cursed loot appeared in the caves at all. I went through the area three times (entering the keep, going through the teleport ash pile, exiting out of the cave and back in through the keep again) and the only bodies I saw were the ones you get from LAL. In the end I made a save out in the open world, quit the game, reloaded, went back in through the keep and lots of new bodies had appeared. Still don't know why.

 

That might not be what's happening to you, but if you don't see a lot of female Imperial bodies littering the place (including in the spider chamber) then save, quit, reload might work.

[Clockwinding]

Hello,

 

Just wanted to add a report : 

 

courier in chains quest (heav yoke removal) does not remove the yoke when completed.

 

 

[pyritefoolsgold]

12 hours ago, imaster15 said:

Have a issue when talking to nazeem in hall of the dead, as soon as the event triggers my game just crashes, tried turning all mods off that cursed loot does not depend on and no effect, anything else i can try?

I'm having this issue too. The crash seems to trigger right after the pink bodysuits go on.

[Lupine00]

18 minutes ago, pyritefoolsgold said:

I'm having this issue too. The crash seems to trigger right after the pink bodysuits go on.

I know you ran FNIS, but it's still probably FNIS or HDT. Most likely FNIS.