Roggvir's DD Items Manager

[slvsaris]

On 8/3/2018 at 12:42 AM, Roggvir said:

I do not use MO, so i cannot help you, hopefully someone else will know what to do.

You can start by formatting the archive correctly.  Remove the Fomod folder, and copy everything from the data folder to top level like it is supposed to be.  Bashing MO is not doing you any favors.

[Roggvir]

3 hours ago, slvsaris said:

You can start by formatting the archive correctly.  Remove the Fomod folder, and copy everything from the data folder to top level like it is supposed to be.  Bashing MO is not doing you any favors.

You have obviously a different idea of what correctly formated archive means and how it is supposed to be.

I format the archive according to what i got used to from NMM, and later adopted as a standard for my own mod manager, so the way i do it, is actually correct for me and anybody possibly still using NMM.
 

Btw. i dont see me "bashing MO" anywhere, where did you get that silly idea? i mean, of course i think MO is an utter piece of crap, but until now i never mentioned it ?

I thought MO was supposed to be "superior", so i am surprised to hear its got such silly problems - i take it as a reason not to even bother with it.

 

I might consider changing the format to conform to the new Vortex if a change would be neccessary, but only after it gets out of Beta and only if i deem it not be a piece of garbage (which i very much doubt).

[reikiri]

Thanks for the great mod, helps a lot to be able to manage the list of usable DDs.

 

A couple of suggestions:

 

- If I'm understanding the scripting right, setting f.ex. chain harness to 98% and strap harnesses to 99%, will effectively give 99% chance to get strap harness, and 0.98% (98% out of remaining 1%) chance for chain harness.  With both set to 99%, it'll still give 99% for strap harness and 0.99% for chain harness.  Current model favors heavily (beyond their set percentages) the higher probability items.

 

- It would be useful to be able to set a limit to number of devices you'll acquire on one "roll" - possibly both minimum and maximum limits.  This would make a sort of "progressive" use possible.  I realize it's an option to put the limit on the mod utilizing the RGG by simply only equiping a subset of the items, but having the limits on RGG would allow more user control - and also give the option to set the minimum number.

 

Probably the easiest way to prevent the first issue, would be to use weighed probability in picking the device categories - with active categories of 80%, 40% and 10%, the first one would have 80/130 chance, second 40/130 chance and third would have 10/130 chance.  There is a fairly simple algorithm to do the picking on single pass of array.  With that, it would also be possible to implement the second suggestion by just picking a random number of devices beforehand (between the limits), and then randomizing each one from the categories.  Sorting the categories (by probability) would no longer be necessary, and leaving out mutually exclusive devices could be done on the same loop by simply not giving them a chance.

 

An example.. lets say we have category probabilities 1:20, 2*:50, 3:30, 4*:80, 5:30 - and set the number of items to min 1 and max 3

random 1-3 yields 2, so we're trying to pick 2 items.  Each item is picked separately.  The 2* and 4* groups are mutually exclusive (for the sake of example, although this can be per-item limit instead of per category)

 

1st item:

- total probability of categories "so far" is prob = 0

1:

- add prob += 20 (total 20)

- 1: has 20/20 chance to be picked, 100%  chance - it gets picked (item = items[1])

2:

- add prob += 50 (total 70)

- 2: has 50/70 chance to be picked - lets say it gets picked (item = items[2})

3:

- add prob += 30 (total 100)

- 3: has 30/100 chance - lets say it fails (item is still items[2])

4:

- add prob += 80 (total 180)

- 4: has 80/180 chance - say it gets picked (item = items[4])

5:

- add prob += 30 (total 210)

- 5: has 30/210 chance - say it fails (item is still items[4])

 

1st item is then from category 4*

 

2nd item:

- prob = 0

1: prob += 20 (=20), 20/20 chance - success, item = items[1]

2: testing previous items, 1st item is exclusive, so group 2 is skipped

3: prob += 30 (=50), 30/50 chance - fail, item still items[1]

4: testing previous items, 4th item has already been picked, so group 4 is skipped

5: prob += 30 (=80), 30/80 chance - success, item = items[5]

 

2nd item is then from category 5

 

For per-item exclusions, probably the items would need to be picked with all groups included (except the groups that already got item selected from), and if it's incompatible, it should be discarded - and that group's probability value substracted from 'prob' value (for example, if 1st group item was incompatible with previously picked item, the group 2 would start with 50/50, thus giving it an initial 100% chance).  The exclusion could be handled with one "sufficiently large" formlist - when picking item, checking first if that item is on the exclusion list, and if so, it would be discarded.  If not.. then checking through all the "mutually exclusive lists", and if it's on one of those lists, adding all forms from that list into the exclusion list.  Or alternately, instead of large form list, a smaller list-of-formlists, and adding any "triggered" exclusion lists into that list (and looping through them instead of one large formlist).  The advantage in either case would be reduction of recursive search - since you wouldn't need to search every picked item, from every possible list, per every other picked item.

 

And of course it would still be possible to end up with "less than minimum" devices, if there just aren't enough (compatible) categories to pick items from - or if randomizer ends up picking exclusive items from within the categories.

 

-- edit --

To clarify: each item in the loop, has a probability of getting picked, equal to their initial chance, times the initial likelihood of each following item NOT getting picked - which ultimately adds up to their weighed probability on the overall list (20/50/30/80/30):

 

1: 100% * (1 - 0.714) * (1 - 0.3) * (1 - 0.444) * (1 - 0.143) = 10%    ( = 20 / 210 )

2: 71.4% * (1 - 0.3) * (1 - 0.444) * (1 - 0.143) = 23.8%    ( = 50 / 210 )

3: 30% * (1 - 0.444) * (1 - 0.143) = 14.3%    ( = 30 / 210 )

4: 44.4% * (1 - 0.143) = 38.1%    ( = 80 / 210 )

5: 14.3% * (100% - 0%) = 14.3%    ( = 30 / 210 )

 

The probabilities sum up to 100.5%, with the 0.5 coming from some rounding inaccuracies.

 

[Roggvir]

On 1/1/2019 at 2:39 AM, reikiri said:

- If I'm understanding the scripting right, setting f.ex. chain harness to 98% and strap harnesses to 99%, will effectively give 99% chance to get strap harness, and 0.98% (98% out of remaining 1%) chance for chain harness.  With both set to 99%, it'll still give 99% for strap harness and 0.99% for chain harness.  Current model favors heavily (beyond their set percentages) the higher probability items.

Each category has some probability assigned, and the picking attempts will go from highest probability category to the lowest probability category.

So if you set Chain Harness category to 90%, and Strap Harness category to 80%, then it will start with the Chain Harness category.

It will generate random number N in range 0-100:

- If N is lower or equal to 90 (90% probability), it will pick random item from the Chain Harness category, and then move to pick items from next highest probability category, skipping Strap Harness or any other conficting item categories.

- If N is greater than 90, it will move onto the next highest probability category, which will be Strap Harness with 80% (no conficting item was picked yet) and "rolls the dice" for that category with winning score between 0 and 80 (80% probability).

 

 

[reikiri]

29 minutes ago, Roggvir said:

Each category has some probability assigned, and the picking attempts will go from highest probability category to the lowest probability category.

So if you set Chain Harness category to 90%, and Strap Harness category to 80%, then it will start with the Chain Harness category.

It will generate random number N in range 0-100:

- If N is lower or equal to 90 (90% probability), it will pick random item from the Chain Harness category, and then move to pick items from next highest probability category, skipping Strap Harness or any other conficting item categories.

- If N is greater than 90, it will move onto the next highest probability category, which will be Strap Harness with 80% (no conficting item was picked yet) and "rolls the dice" for that category with winning score between 0 and 80 (80% probability).

 

 

Yes, that's kind of my point.  90% of time it will skip strap harness, which means out of all the times of picking random items, only 10% of times the strap harness has a chance to even be considered as a possibility (and same applies to all other conflicting categories), even though with setting chain to 90 and strap to 80, you'd intuitively assume they have almost equal chance to be picked - just with slight bias to chain.  Even with both set to 90, it will -still- give one category only 10% chance to even be considered.. so out of all attempts one "90" category gets picked on 90% of time, and another "90" category gets picked 9% of time.  If there are 4 conflicting categories each set to 50 (default) the chances are:

1st category: picked 50% of tests

2nd category: picked 25% of tests

3rd category: picked 12.5% of tests

4th category: picked 6.25% of tests

..even though they're all set to "50" and should have equal probability to get picked.

 

I did try rewriting the code to use different algorithm, but while it technically works fine, the formlist lookups are insanely slow, so picking half a dozen items takes about half a minute or so - which is terrible when setting up items before or after starting a scene.  Overall if exclusions are based on simple item slot masking, a much faster way would be to assign each item a binary mask with slots it occupies, and then just doing a quick loop for already picked items, doing a binary AND with each of them..and any non-zero result would mean the item can't be equiped.

 

Even with lists it should be possible to assign each list a number, and use those much like equipment slots - e.g. each item would get a binary mask defining which lists it occupies, and again a simple binary AND would check if two compared items occupy same list.

[Roggvir]

2 hours ago, reikiri said:

90% of time it will skip strap harness, which means out of all the times of picking random items, only 10% of times the strap harness has a chance to even be considered as a possibility

Yes, because that is how you set it. If you want higher chance of getting the Strap Harness, then set it higher on the expense of Chain Harness which you set a bit lower, try both at 60%.

There is no "right" way, not without knowing some context - no matter what percentages you set, or which picking algorithm you devise, it will always be something artificial that doesn't really make sense anyway.

Whatever you propose, does not have more logical sense than anything else that exists or anybody can think of (again, without context).

Any sensible logic can be devised only based on knowing the situation, and what is the goal, but there is no way knowing that without making a mod that provides certain situation.

This is about picking RANDOM devices - the word "random" doesn't allow for any situational logic (then it wouldn't be random, right).

 

I am not against what you want, but to me it doesn't make any more sense that current implementation, and therefore i dont see the point of it.

 

The "10% chance" you keep repeating is not really a thing.

If you set first category to 90, and second to 80, that doesn't mean the second category will be used in 8%, not in reality.

All the "probability" settings are just to give a hint, some number ppl can lean onto, nothing more.

Just set both categories to 50-60, or whatever is needed to achieve a more balanced outcome that suits you - no need to inject any more calculations (again, they cannot even make sense without knowing context and goal).

 

Yes, those lists are slow, it was just a lazy workaround to make the stuff work, and i never got to change it since.

It was simpler from user perspective - filling and maintaining few lists is way more comfortable than filling sctructures with item forms and asociated mask (relying on item slots is not enough with how the devices were setup).

If (when?) a new version of DD gets released, then i will make new version too, but imo there is no point doing anything before new DD is out.

 

You seem to know what you want, so, just make your own alternative version of this thing, or make a patch for it, whatever suits you best.

But i am sorry, it feels pointles to updating this until a new DD (hopefully with many changes) is out, or unless there is a bug that needs fixing.

[reikiri]

On 1/2/2019 at 8:50 AM, Roggvir said:

The "10% chance" you keep repeating is not really a thing.

If you set first category to 90, and second to 80, that doesn't mean the second category will be used in 8%, not in reality.

It does, in reality.  IF those categories are exclusive, such as the two harness categories.  The "90" category will get picked 90% and will always win if it gets picked.  The 80 category can only appear if the 90 category did not get picked (because the conflict removal always favors the 90 category).  That means, in reality, 10% chance at most, and the 80 setting will lower it to 8%.  You can try it with the test button, that's how it will work.  The most simple fix I can think of (in terms of least changes), would be to randomize the order of conflict removal, instead of always favoring the highest probability.  Giving each picked item an equal chance to win (IF they got rolled in the first place) would balance the probabilities according to their set values (the probabilities of being picked in the first place already handle the difference in their likelihood of appearing).

On 1/2/2019 at 8:50 AM, Roggvir said:

Whatever you propose, does not have more logical sense than anything else that exists or anybody can think of (again, without context).

Ok, instead of doing more calculations, I'll give an example goal - lets say I'd want to have 35% of time wristcuffs, 30% wrist & arm bindings, 25% of times an armbinder, (I think those three were mutually exclusive categories), and the remaining 10% of times none of those.  In other words, on average, 100 random pickings would result in -roughly- 25 times a pick from armbinder category, 35 times wristcuffs category, about 30 times wrist & arms cuffs category, and about 10 times arms would be free.

 

A setup like that would currently be impossible to arrange.  You couldn't even get anywhere close to it - or I've understood something wrong.
 

On 1/2/2019 at 8:50 AM, Roggvir said:

You seem to know what you want, so, just make your own alternative version of this thing, or make a patch for it, whatever suits you best.

But i am sorry, it feels pointles to updating this until a new DD (hopefully with many changes) is out, or unless there is a bug that needs fixing.

Yes, I pretty much agree here - although I do think it has a bug in it's randomizer logic (unless, again, I've gotten something wrong - that happens too). I'm not going to pester you about rewriting the script, but if you don't mind, and I come up with a solution to what I'm talking about, I'll at least drop the source on this thread.  I mean I do have it working already, but it's working too slowly, so I'd need to find a way to optimize it.

 

On 1/2/2019 at 8:50 AM, Roggvir said:

Yes, those lists are slow, it was just a lazy workaround to make the stuff work, and i never got to change it since.

It was simpler from user perspective - filling and maintaining few lists is way more comfortable than filling sctructures with item forms and asociated mask (relying on item slots is not enough with how the devices were setup).

Yes, it would need to be automatic.  Basically something that caches the exclusion lists into faster format.  Ideally it would build the cache once, and never need to update it unless the lists themselves are modified.  What I'm looking into is a compromise - adding a device into cache the first time it's checked.

[reikiri]

Here, this seems to work pretty well.

 

- changed probabilities to relative values - now two categories set to 50 have same probability, and a category set to 25 will have half the probability of one set to 50, etc.

- created cache for mutual exclusion lists, it's populated when first opening MCM menu or first picking a set of items - uses bitwise AND logic, which makes it pretty fast

- set minimum and maximum limits for number of items to pick.  they are hardcoded (3-to-6, didn't want to mess up MCM) but should be MCM options really

 

Ideally cache would be populated when the mod is loaded up, but it only takes about 10 seconds to populate the whole item array so it's not terribly slow.  Afterwards each item takes about 1-2 seconds to pick, which includes passing the exclusive options, so that's not too bad either.  If the script encounters a device that isn't in cache, it'll assume something has changed - and will reset the cache.  I left in an empty sorting function to avoid breaking the MCM that likes to call it.

 

This is only source code, so it's not intended to be a "patch" as such, but if you like the changes, feel free to include it into the mod, or use as you like - if not, that's fine.. it was useful for me anyway. ?

 

 

DDManager.zip

[GoldenRain]

@Roggvir  First!  I love this mod.   It makes it sooo easy to use and to test out what looks like what and what works with what.  Side note the strap harness interferes with the DD nipple piercings. 
Second it would be nice to see the armor slots used by the items when selecting them.  With the 'no strip items manager', allowing me to keep certain items equipped during aaf scenes certain DD items can't be equipped because the no strip overrules DD.  I'll have the DD item/s in my inventory, but it wont equip even when I try to manually(through pip-boy not through console).   I currently use a piece of paper with the armor slots for the DD items that I want to use.  I just think that we would benifit from seeing that info when in game.  If anyone wants I can post the info to save someone else the time it takes to look this info up through FO4edit.

[Roggvir]

1 hour ago, GoldenRain said:

Side note the strap harness interferes with the DD nipple piercings.

Do you mean the manager doesnt allow both strap harness and nipple piercings equipped? (that would be an error in the manager)

Or you mean that the strap harness cannot be worn with the nipple piercings? (which would be an error in DD, as it should be possible to wear both items together)

 

1 hour ago, GoldenRain said:

Second it would be nice to see the armor slots used by the items when selecting them.

Yes, that could be usefull.

That being said, i dont think i will be adding this into current version, as i dont feel its worth the hassle (i may change my mind, but no promises), but i will definitely add it into a new version (which i will make when/if DD itself gets updated).

 

1 hour ago, GoldenRain said:

With the 'no strip items manager', allowing me to keep certain items equipped during aaf scenes certain DD items can't be equipped because the no strip overrules DD.  I'll have the DD item/s in my inventory, but it wont equip even when I try to manually(through pip-boy not through console).

I am not sure i understand correctly, but if i do, i think the problem simply is that some of the worn items, left equipped because of "no strip manager", prevent the new items equipped due to a slot conflict - the new items cannt be worn together with some currently equipped item protected by the "no strip manager".

I dont think there is a way to change this behavior.

When the items are getting unequipped (at which point the "no strip manager" may prevent some from getting unequipped), the "no strip manager" has no way knowing which items might some other mod/system try to equip afterwards.

The "no strip manager" cannot make an exception, allowing any of its protected items to get unequipped due to the item being in conflict with some other item that another mod/system will later try to equip - it doesn't have any knowledge of these "future" items, and there is no way to get that knowledge (if anybody says they see the future, they are lying ).

The only way to do something about this, would be to integrate all these mods into one.

That means the "DD manager", the "no strip manager", AAF, and any other mod that would be normally using these (like "AAF Violate" or some RSE Element mod, or whatever), would have to be joined into ONE with changed implementation where the uncertainty about future items is removed.

That, or the implementation of almost all these mods would have to be changed, not just the "no strip manager" or the "DD items manager".

I will think about it again when working on the new version of any of my mods, but i dont think there is anything i will be able to do about this.

 

BTW. isn't the "no strip manager" kind of obsolete, since you can define protected items in AAF?

 

[reikiri]

On 1/17/2019 at 4:17 AM, Roggvir said:

BTW. isn't the "no strip manager" kind of obsolete, since you can define protected items in AAF?

Thanks for mentioning that, it's probably going to be useful - I keep having my ears and tail getting stripped. ?

However there's kind of long hop into using xml file to define form IDs of keywords - and possibly installing those keywords into items - if all you ever do is just install mods.  The protected items xml may, for many users, be too 'technical' as an option.

[far_kas]

The operator is great. Only the problems aren't... because the program often tries to do things that are incompatible. Sometimes what's on it doesn't even show up... the only thing that tells us is behavior.

[JustModding39]

It might sound stupid, because I haven't found any answer but, I'm using the AAF Violate with the Devious Devices. I don't seem to be able to remove the Devices at all. Any help?

[Roggvir]

5 hours ago, JustModding39 said:

I'm using the AAF Violate with the Devious Devices. I don't seem to be able to remove the Devices at all.

I think you are being mislead by the name of this mod. This mod isn't really "managing" devices in full sense of that word, so it cannot help you unequip devices once they are equipped.
It only provides means to choose which devices are allowed to be put on by other mods that utilize it.

But if you can't get rid of some devices, isn't there some option in DD's MCM (i dont really remember if DD has an MCM) to remove all devices? (or is that only in DD for Skyrim?).
Hmm... sorru, i recall having similar problem with mittens once - couldn't get rid of them, and i believe that was the reason i created this mod, to make sure i will never have that problem again after setting the mittens to "not allowed".
 

I cannot run Fallout 4 right now, so i can't test it, but maybe you can use some console command like "player.unequipAll" ?

[JustModding39]

17 hours ago, Roggvir said:

I think you are being mislead by the name of this mod. This mod isn't really "managing" devices in full sense of that word, so it cannot help you unequip devices once they are equipped.
It only provides means to choose which devices are allowed to be put on by other mods that utilize it.

But if you can't get rid of some devices, isn't there some option in DD's MCM (i dont really remember if DD has an MCM) to remove all devices? (or is that only in DD for Skyrim?).
Hmm... sorru, i recall having similar problem with mittens once - couldn't get rid of them, and i believe that was the reason i created this mod, to make sure i will never have that problem again after setting the mittens to "not allowed".
 

I cannot run Fallout 4 right now, so i can't test it, but maybe you can use some console command like "player.unequipAll" ?

Yeah, I managed to get rid of them after awhile with player.unequipall, however on Skyrim you could ask the one who placed them to get rid of them, paying that "who", on Fallout 4 you don't seem able to, so it kinda screws me up in combat xd.

[darkon74slayer]

I was wondering does this mod control the number of devices added when another mod calls on it to apply the devices?

If it does are you willing to add an option to control that number per call?

[Roggvir]

9 hours ago, darkon74slayer said:

I was wondering does this mod control the number of devices added when another mod calls on it to apply the devices?

If it does are you willing to add an option to control that number per call?

This mod only provides a function to pick random devices from each of device categories (wrist cuffs, leg cuffs, gags, corsets, etc.).
You can limit the devices picked by this function by assigning each individual item a probability of being selected, and/or setting the category or item as forbidden.
It doesn't limit the number of devices to any specific number, the only limiting factors are the item probabilities and whether the items are allowed or forbidden.

I could add an option to control the number of returned items, but i am not sure if it is a good idea to do that on a global scale via some MCM setting - if that is what you mean?
How about adding alternative function (or adding one more input parameter to the existign function), and leave it to the modders utilizing this function, how many items they want?)
On the other hand, why not do both.

 

I will add two new MCM options.
- One to set the minimum number of devices returned per call (set to specific number, or -1 to keep it random).
- And another to limit the maximum number of devices returned per call (set to specific number, or -1 to keep it random).

 

And i will also add a new optional function argument to set the number of items the function should return (with the user MCM settings having a higher priority).

But while i am at it, i will also drop the message-based configuration and leave on the MCM (i dont think there is anybody NOT using MCM at this point), and i also want to look at the lists of mutually exclusive items and see if i can implement it in a better, faster way (it is slow as hell).
So, it will take some time (i dont have much time, and i was away from Fallout 4, so i need to check whats new first - maybe new DD? no? well... will see).
Meanwhile, if anybody has anything to add, don't hold back.

 

(pinging @EgoBallistic in case he may have anything to add to this discussion)

[mashup47]

2 hours ago, Roggvir said:

This mod only provides a function to pick random devices from each of device categories (wrist cuffs, leg cuffs, gags, corsets, etc.).
You can limit the devices picked by this function by assigning each individual item a probability of being selected, and/or setting the category or item as forbidden.
It doesn't limit the number of devices to any specific number, the only limiting factors are the item probabilities and whether the items are allowed or forbidden.

I could add an option to control the number of returned items, but i am not sure if it is a good idea to do that on a global scale via some MCM setting - if that is what you mean?
How about adding alternative function (or adding one more input parameter to the existign function), and leave it to the modders utilizing this function, how many items they want?)
On the other hand, why not do both.

 

I will add two new MCM options.
- One to set the minimum number of devices returned per call (set to specific number, or -1 to keep it random).
- And another to limit the maximum number of devices returned per call (set to specific number, or -1 to keep it random).

 

And i will also add a new optional function argument to set the number of items the function should return (with the user MCM settings having a higher priority).

But while i am at it, i will also drop the message-based configuration and leave on the MCM (i dont think there is anybody NOT using MCM at this point), and i also want to look at the lists of mutually exclusive items and see if i can implement it in a better, faster way (it is slow as hell).
So, it will take some time (i dont have much time, and i was away from Fallout 4, so i need to check whats new first - maybe new DD? no? well... will see).
Meanwhile, if anybody has anything to add, don't hold back.

 

(pinging @EgoBallistic in case he may have anything to add to this discussion)

Me personally I think it's a bit OTT and mite cause problems with other mods.

[EgoBallistic]

12 hours ago, Roggvir said:

And i will also add a new optional function argument to set the number of items the function should return (with the user MCM settings having a higher priority).

If you do this, please make it a new function -- CallFunction() requires all parameters to be specified, even optional ones, and mods that call the function directly will also need to be recompiled (because optional parameters aren't really optional; if the caller omits them, they are set to the default value when the calling script is compiled).  So existing mods that use this one would need to be updated.

 

As far as the min/max options, a maximum makes sense and should be easy enough to implement, although it can also be done by the caller.  On the other hand, a minimum devices setting sounds like a real headache.  You have to adjust it down if the probability settings make it impossible to return that many items; you have to keep track of which categories were added so that you can pick from the remaining available ones if the number of items picked is below the minimum; etc.

 

And unfortunately there isn't a new FO4 DD, it's still the same 2.0 version.

 

Edit: I thought about it and since it can be done in like 5 lines of code, I'm going to add a max DD devices option to Violate.  It seems like a popular request.

[bstylez]

can you make the exact same thing for skyrim se? Devious capture doesn't seem to like spawning the type of DD I like on my character such as steel shackles and arm shackles

[Roggvir]

On 3/6/2020 at 1:55 PM, bstylez said:

can you make the exact same thing for skyrim se? Devious capture doesn't seem to like spawning the type of DD I like on my character such as steel shackles and arm shackles

Technically, yes, i could make the same thing for SSE, but i am now incredibly busy.
It would be best not to wait for me, and ask other modders to do it (anybody is free to take this and port it if they want, but i recommend rewriting at least the functions related to filtering mutually exclusive items, to make it faster - as i plan to do, but ...busy).

[stas2503]

If I remove the MCM folder from the mod, will this somehow affect the operation of the mod?

MCM of this mod causing severe freezes of the my game up to a CTD.

[mashup47]

9 minutes ago, stas2503 said:

If I remove the MCM folder from the mod, will this somehow affect the operation of the mod?

MCM of this mod causing severe freezes of the game up to a CTD.

I think your issue may lay elsewhere with the mods you have installed? There is no point removing parts/half a mod's install, You must remove all of it else this will cause issues.

[stas2503]

1 hour ago, mashup47 said:

I think your issue may lay elsewhere with the mods you have installed? There is no point removing parts/half a mod's install, You must remove all of it else this will cause issues.

Oddly enough, deleting the folder helped ... MСM opened quickly and CTD stopped. The mod’s work did not break ... I configured the mod through the item in the inventory.

[zer012121]

So for me its not working saying there is a missing .esp file that i don't know how to fix can i plz get help.