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

[koolgty]

Bug: in the captured princess LAL addon start, when the quest marker is supposed to point to the slaver's hideout it points to broken fang cave. The hideout is identical to broken fang cave, which is probably the reason. I think it was copied but some tags were left.

[crudo]

Trying to install version 8.0 and NMM (v 0.63.5) aborts the mod at 50%.  I went through the requirements and I appear to be up to snuff on all of them.  I even downloaded the mod a second time and tried fresh.  Is there some troubleshooting I could try to sort this out.

 

Thanks.

[Taki17]

1 minute ago, crudo said:

Trying to install version 8.0 and NMM (v 0.63.5) aborts the mod at 50%.  I went through the requirements and I appear to be up to snuff on all of them.  I even downloaded the mod a second time and tried fresh.  Is there some troubleshooting I could try to sort this out.

 

Thanks.

It's NMM. It does not play nice with large archives. You should switch to MO or Vortex, or if you insist on NMM, see if the community maintained version serves you better.

[thenesredep]

I have a little problem, I was playing with a femal Khajit when the trap activated. It puts a rubber hood on my character but now the head is missing.

[Gräfin Zeppelin]

Thats a nasty rubber hood.

[Inte]

On 3/26/2019 at 2:59 PM, Kimy said:

I said multiple times that I will add back the POP integration people are asking for the moment Inte OFFICIALLY declares his mods compatible and tested with DD4, because it makes no sense to hand over the character to a mod that's uncertain to work with mine. Whether or not that will ever happen is 100% his choice and his call, because he has a right to call shots for his mods as much as do.

 

Supporting POP via DCL would even solve any other compatibility issue between POP and DCL, because DCL could make sure to hand the player to POP only when POP wouldn't clash with any DD items worn by the player (I do the same with my own prison). But it's STILL his choice.

Ok. 

Where would I get the latest versions of DDi/DDx? Are the ones in the download page the latest versions? 

 

BTW, POP + DDe do not clash with any DD items as POP should not start any conflicting scenarios.

[Zaflis]

I was playing with Sasha one point and realized something awkward. Because of key stealing there are some restraints you truly can't get out of. Basically those that require DCL keys, and no NPC from this or other mods can help with them. These items include black and transparent full rubber sets, one which includes closed hood, full headgear (The Veil etc), slave gag (almost completely disables talking), the chastity belt that takes many keys to open... and not sure if i forgot others. But thought of being doomed to be blindfolded, gagged and permanent chastity for the rest of playthrough? You're stuck with them until you escape. They definitely can interfere with all quests from DCL itself, and this all sadly makes Sasha domination not actually playable at least in longer term. Sasha's collar should prevent many of the quests from starting though.

 

So... Sasha would actually have the release keys, she's just not letting you have them. I suppose she could open them for you after a certain time. I just don't think that using every opportunity to escape should be the intended way to play with her. I think the gold controlling (you are reduced to ~400g periodically) also makes escaping from high security restraints hard. The defaults were pretty high, i forgot... 150-200g per level on blacksmith?

[mkess]

On 3/30/2019 at 6:27 PM, Kimy said:

It's not intentional, but like most creative people, I can't work on my creations when I am not in the mood. I had CK opened 2-3 times last week, and couldn't get a single line of code written because my heart wasn't there.

 

Don't take this to heart. Think about it this way: 50% of humankind has an IQ under 100. If you try to take everybody serious, you get nothing done at all. Let this morons vent their anger. But don't you ever take it personal. I was myself a developer and a modder, I know that where are some ungrateful asshats. You work your ass off, giving away something free, because you are proud of their work and they are only capable of complaining and contempt. You are trying to get your mod to near perfection to work for yourself. That is all that YOU can do.

 

But it is impossible to please everybody. It does not work that way. You have to be content with the results of your work. And don't you ever implement things you don't want to. It has to work for YOU ... and only you. That is how I made my mods. I made them basicly for myself. And I stopped publishing them, because they added due the pressure from outside to my normal workload to an unreal level.

 

------------

 

Now to my real problem. Your mod causes indirect heavy script load CTD's near whiterun. It's the main culprit. The 8.0 version is even worse than the 7.5.7 mod.  It was impossible to avoid them, after I tried to exit the Whiterun meadery in the cloe quest, after I spoke with the imperial officer. I rolled back to version 7.5.7. But occasionaly CTD's still around Whiterun happen. To avoid them, I had to deactivate quests and traps in script heavy outdoors skyrim regions. It works just fine in dungeons. Like I said, I am an EX-Dev, and versed in bug hunting. I can guarantee you your mod is the main culprit. Deactivating other script heavy mods did not stop the CTD's. You should look out for loops. It seems one of them is out of control, pushing the script engine over the edge.

 

At the moment I try to get a more stable Skyrim. Last week I broke my Skyrim installation complete in half, and had to reinstall it complete anew. What a pain in the ass. I use over 200 mods, many of them are heavy scripted.  So at the moment I am bug hunting, trying to find out who are the culprits of random crashes. If you need any help, just ask.

 

P.S. I love your mod, and consider it as one of the essential ones. That's the reason I post here, in hope you can make a fix. One workaround/hotfix I thougt about would be to activate your mod only in indoor regions. I can activate your mod only indoors now or in unpopulated regions, because of the heavy scriptlload outdoors in regions araond Whiterun, Solitude and Riften. It could be a permanent option for weaker gaming PC, too, you know?

 

But it would be much better if you could find the culprit, that cause the heavy script load. Keep up your good work.

 

P.P.S. Your tavern whore wants 100.000 gold .... I find that a bit expensive.

[Lupine00]

20 hours ago, UnEvenSteven said:

Tavern Whore:

This is pretty much what I had in mind when I proposed the Whore Collar concept.

 

At the time, I believe I suggested that Whore Collar be something you can get when you are ported to an inn by DCL Combat Defeat.

This would be a way for the inn-keeper to make you pay him back for the rescue.

 

Also, that you could explicitly ask inn-keepers about work (at any time), and get given the collar, and get "free" food and lodging while you're wearing it.

 

 

The Whore Collar as implemented - in itself - if fine, and does very much what I hoped for.

 

However, the circumstances for getting one are not what I had hoped - in that they were random in 7.X, and I'm not sure about 8.0, but probably based on defeat and definitely still not based on dialog. Possibly based on crime now?

 

 

Initially, I had hoped that the inn-keeper would get put in a special alias for dialog if you get a collar put on you in his inn, and he would be able to talk about how your debt it going, and provide suitably humiliating advice on what you can do to clear it.

 

 

The suggestion for increasing bondage stages in the inn - if you're not careful - is awesome. I love it!

 

The whore collar would function nicely as the initial item - light bondage - and things could get worse from there.

Presumably, if things go very wrong for you, the collar would keep getting refreshed, and you'd be paying off an endless debt.

Lovely!

[Lupine00]

8 minutes ago, mkess said:

causes indirect heavy script load CTD's near whiterun

Usually, when scripts cause CTD, it's script that runs because of dialog condition checks. These get performed en-masse when you enter new cells, and seem to use some memory resource that can be exhausted - possibly it's simply small memory chunks being churned at a high rate, and causing fragmentation, to the point that consequent large chunk requests cannot be fulfilled.

 

It's definitely the case that using the custom memory block system in CrashFixes, with well tuned values, really does reduce the rate of these.

This suggests the fragmentation explanation, because it puts the small blocks in their own pool.

[Lupine00]

If there's one thing that does bug me a bit about DCL, it's these random men who seem capable of trivially overpowering you, and locking stuff on you, even when you have no meaningfully debilitating restraints, and could easily resist. Especially when it's some weak peon.

 

I mean, sure, if you're in boots and an armbinder, they can pretty much do whatever they like, and you can't stop them - but these guys - solicitation customers, or just random people you talk to, who slap restraints on you ... it seems not very immersive. I turn as much of it off as I can.

 

 

In my mind it would work more like this:

 

You could always refuse a request for bondage in solicitation. In ME, you could. In fact, usually, you would be offering it, rather than having it pushed on you - because it earned more money. I think it may already earn more money in DCL, but no actual amount is ever discussed, and it's not optional.

The bonus of this, is that if you have "tavern whore" mechanics, the inn-keeper would pressure you to do it, and possibly punish you if you don't, and possibly take advantage if a generous customers leaves you bound - one way you could sink deeper in the trap.

 

The NPC actions feature would be nicer if it had an option to only fire on genuinely debilitating events (rather, or as well as, only visible ones).

 

With whoring consequences, rather than wham, bam,  and guards, simply put restraints on you, it could be determined via a dialogue choice, like other crime stuff:

 

Guard: "Young lady, you can't go around naked. I'm going to punish you by putting you in approved restraints."

> "No way. I'd rather die. (Fight guards)."

> "You'll have to arrest me first. (Get arrested instead)." (Chance of prison, chance of fine).

> "Alright. I submit. (Accept restraints).

 

 

As for random tavern dudes somehow slapping a collar on you because they don't like your whoring, I believe I can already turn that off.

 

 

Also, not sure how many times this came up already ... could Dragonar be a percentage chance vs regular prison, rather than simply an on/off tickbox?

 

Would be nice if you had (say) a 25% chance of Dragonar vs regular, and you could gamble on it.

Would make Dragonar feel more special too.

[mkess]

Just now, Lupine00 said:

Usually, when scripts cause CTD, it's script that runs because of dialog condition checks. These get performed en-masse when you enter new cells, and seem to use some memory resource that can be exhausted - possibly it's simply small memory chunks being churned at a high rate, and causing fragmentation, to the point that consequent large chunk requests cannot be fulfilled.

 

It's definitely the case that using the custom memory block system in CrashFixes, with well tuned values, really does reduce the rate of these.

This suggests the fragmentation explanation, because it puts the small blocks in their own pool.

I already use all crash fixes possible. Believe me, I played other 3000 hours in Skyrim so far.

 

But thank you very much for the hint.  It's a new thing to look out for in bug hunting. Immersive wenches is the next thing to look at for me then ... My possible problem in Whiterun region are the random spawns that occour around here, combined with the regular ones. There are over 10+, because of OBIS, bandit patrols, immersive creatures, immersive wenches and the like. If I combine that with your dialog theory, it's highly possible that is one reason for it.  Hell, I even had to deactivate the KSHairdo mod, because it was not able to load it in time around Whiterun. It's a pain in the ass to find these things, because the grandmasters of incompetence from BUGthesda don't know the meaning of error routines and error logs ...

 

I agree with your load theory , because It seems to me Skyrim is choking at some point at heaps of data they load. They crashes occur on cell loads. That is for sure. At that time there is not enough time for the cursed loot scripts, and it CTD's.  if I deactivate it, it's just enough to get other with it. Like I said before, cursed loot is only indirect resonsible. That does not change the fact that it works, after I deactivated the quest and traps. I have to find the reason for the choking on load.

 

"Give me a bigger sword!" aka a better PC would solve my problems, too. But for now I have to stick to my medium gaming PC.

 

 

[Zaflis]

1 hour ago, mkess said:

One workaround/hotfix I thougt about would be to activate your mod only in indoor regions. I can activate your mod only indoors now or in unpopulated regions, because of the heavy scriptlload outdoors in regions araond Whiterun, Solitude and Riften. It could be a permanent option for weaker gaming PC, too, you know?

While i cannot say if DCL has high script load or not, there actually is a toggle for "Low performance mode" on debug tab for weaker PC's.

 

There was something odd with Chloe quest that's for sure, i still remember it as the most unstable Skyrim experience i had. I know it consisted of using the harmful HDT restraints, but even when not wearing them it seemed to CTD more often. Because all of this is so random it's difficult to draw any certain conclusions. You crash one point, load game and repeat the same step without crashing... it's hard to test something like that reliably.

 

And then there are other mods in the mix that add their events, even the creature framework uses a cloak periodically by default. It's a standard procedure for me to disable CF's arousal integration and the cloak entirely from MCM. Another cloak in XPMSE.esp, use realistic_ragdolls instead. And so on.

[Lupine00]

1 hour ago, GenioMaestro said:

Excuse me but that is not true. The game verify the conditions of dialog when you press the action key and not before. Is imposible that the game process all the posible dialogs from all the mods with all the posible combinations when you enter in the cell because the processing time and memory need for compute that is tremendous.

You can verify that the game generate the dialog when press the action key creating a dialog that show when activate a variable with other dialog. Or you can activate the variable with a spell and the dialog line show when you talk to the npc whitout change the cell. The game have a simple example like that when you try access the mage college.

It's more complex than that.

 

I believe that game pre-calculates some dialog information, some functions are statically true or false, others must be evaluated at the point the topic become eligible to open.

I think CK documentation alludes to this.

So, if you wire a dialog to a particular actor ID, it will perform much better than running a piece of script that checks the actor ID.

Firstly, it's a native function, not a script at all, and secondly, it can be evaluated before you open any dialog.

The same applies to any function, is it statically true, or dynamically? And is it native or script?

In some cases infos can be excluded entirely for many NPCs.

The same with quest dialog, and alias dialog. Determining basic eligibility for that dialog doesn't run a single line of papyrus script. Checks done in the native code system are entirely orthogonal to ones done in papyrus.

Papyrus checks require a VMAD, and schedule as any other papyrus execution. Built-in native function-based dialog functionality does not require these things. Because of that, it uses different memory - entirely different memory pools.

In some cases, state changes on actors result in recomputation - this is like the optimisations done for GLOBAL values, which also have special processing.

 

I definitely get more crashes with DCL in the mix. Especially around the rift. But I'm told that can't be true. I can demonstrate it easily. DCL is large, adds many dialogs that are on all NPCs, adds animations, assets, scripts. It adds load. In some places it seems to add more than that, and you get those crashes. However, without a doubt the custom memory block system reduces the frequency.

[Zaflis]

Since i hadn't tried Chloe quest during 8.0, here's current report:

Quote

CTD 1 - bandit cave boss room (overlooks whiterun)
CTD 2 - entering whiterun
(Nazeem gives chains => speedmult=25!) => modav speedmult 50 to make it 75
(Chloe starts appearing invisible sometimes and chains are spazzing out from her like tentacles, on me they appear just fine)
CTD 3 - exiting whiterun
CTD 4 - entering whiterun (with mountain flower and nirnroot)
(Many steps later quest complete)

CTD 5 - entering whiterun with Chloe, neither wearing any restraints

So yeah, i don't have that many CTD's in a row when playing normally in cities or other areas.  CTD 1, 2 and 5 there was no HDT around. I don't have a clue, i blame black magic. And i specifically used my lightweight mod profile with just about DCL installed, no heavy mods or anything. With the heavier profile i could play for hours with all sorts of DD events with no crashes.

[Kimy]

10 hours ago, Inte said:

Ok. 

Where would I get the latest versions of DDi/DDx? Are the ones in the download page the latest versions? 

Links to all of my mods are in my signature, including DD.

Quote

BTW, POP + DDe do not clash with any DD items as POP should not start any conflicting scenarios.

I haven't looked at your code, but I would expect DD Equip's handling of heavy bondage to fail with DD4, because that's the major backwards-compatibility breaking thing I did in DD4. Any heavy bondage item implemented by DD Equip would need their device keywords updated, e.g. from zad_DeviousArmbinder to zad_DeviousHeavyBondage. You will need to make sure that ALL wrist bindings use zad_DeviousHeavyBondage as device keyword in the script properties. Otherwise, other DD4 mods will not recognize your armbinder and yokes etc. as such.

 

You will need to look for calls to zadlibs.equipDevice() and zadlibs.RemoveDevice() and any other API function taking device keywords as parameter as well, and update the keywords, e.g.

 

zadlibs.EquipDevice(Player, MyArmbinder_Inventory, MyArmbinder_Rendered, zadlibs.zad_DeviousArmbinder)

 

would become 

 

zadlibs.EquipDevice(Player, MyArmbinder_Inventory, MyArmbinder_Rendered, zadlibs.zad_DeviousHeavyBondage)

 

Dialogue conditions MIGHT still work, depending on what you're doing with then, but better check them just to make sure.

 

You NEED to leave the old armbinder and yoke keywords on the rendered device, so it's still possible to determine the exact sub-type of your wrist restraint, so e.g. an armbinder would be tagged with both zad_DeviousArmbinder and zad_DeviousHeavyBondage. That's how the framework will determine which AA set to use.

 

Please note that the entire implementation for wrist restraints has changed and needs to be updated. Wrist restraints now use the -standard- DD device script (zad_EquipScript). The old implementation is obsolete in DD4 and can no longer be used for wrist restraints. You'd need to make your wrist devices use or inherit zad_EquipScript and add any custom code there, if needed. The new system is highly configurable via script properties, and should make most custom code unnecessary. You can find documentation in the code of zad_EquipScript. For all wrist devices, you also need to replace the enchantment on the rendered device with zad_EnchHeavyBondage.

 

Also (and I know you're aware of that, because we had a fight over THAT, too), keep in mind that DD4 no longer checks for ZAP devices or supplies ZAP keywords, so you can NOT use ZAP keywords to check for DD devices. Any such code or condition would need to be updated (not that it wouldn't have been bad practice for a DD mod even prior to DD4).

 

Last but not least, make sure that DD Equip's device remove function respects the zad_QuestItem keyword. Before you ask, yes, I do consider mods not doing so incompatible with DD4 (it's mentioned in the framework conventions).

 

When you performed all these changes, DD Equip should be a proper DD4 mod. If you have any questions feel free to post them here.

 

As far as I know, POP isn't aware of DD items without DD Equip, so I'd assume that no changes have to be made to it.

 

Let me know when you made the necessary changes and updated your download thread instructions. I will re-add POP integration with the first DCL update after completion of these steps, together with a new slider that lets users set a % chance whether to use my prison or yours when the player is getting jailed. I will make sure not to send players wearing incompatible/quest devices to either your or my prison, so that will solve a great many possible clashes right there!

[crudo]

19 hours ago, Taki17 said:

It's NMM. It does not play nice with large archives. You should switch to MO or Vortex, or if you insist on NMM, see if the community maintained version serves you better.

Thanks for the tip but it was a different issue.  I got DCL 8.0 to load through my version of NMM.  My problem was disk space, once I cleared some stuff out it loaded just fine.  Just sharing in case anybody else runs into this problem.

[Kimy]

7 minutes ago, crudo said:

Thanks for the tip but it was a different issue.  I got DCL 8.0 to load through my version of NMM.  My problem was disk space, once I cleared some stuff out it loaded just fine.  Just sharing in case anybody else runs into this problem.

Yeah, NMM works just fine with DCL. It's the only manager I ever test it with, even. Haha!

[Srende]

24 minutes ago, Kimy said:

Yeah, NMM works just fine with DCL. It's the only manager I ever test it with, even. Haha!

Glad to see there are others stuck in their ways with NMM

[WaxenFigure]

3 hours ago, Lupine00 said:

It's more complex than that.

 

I believe that game pre-calculates some dialog information, some functions are statically true or false, others must be evaluated at the point the topic become eligible to open.

I think CK documentation alludes to this.

So, if you wire a dialog to a particular actor ID, it will perform much better than running a piece of script that checks the actor ID.

Firstly, it's a native function, not a script at all, and secondly, it can be evaluated before you open any dialog.

The same applies to any function, is it statically true, or dynamically? And is it native or script?

In some cases infos can be excluded entirely for many NPCs.

The same with quest dialog, and alias dialog. Determining basic eligibility for that dialog doesn't run a single line of papyrus script. Checks done in the native code system are entirely orthogonal to ones done in papyrus.

Papyrus checks require a VMAD, and schedule as any other papyrus execution. Built-in native function-based dialog functionality does not require these things. Because of that, it uses different memory - entirely different memory pools.

In some cases, state changes on actors result in recomputation - this is like the optimisations done for GLOBAL values, which also have special processing.

 

I definitely get more crashes with DCL in the mix. Especially around the rift. But I'm told that can't be true. I can demonstrate it easily. DCL is large, adds many dialogs that are on all NPCs, adds animations, assets, scripts. It adds load. In some places it seems to add more than that, and you get those crashes. However, without a doubt the custom memory block system reduces the frequency.

You get more CTDs by adding ANY large mod.  Skyrim.exe is not a paragon of stability, it's much more like a termite mound.

 

DCL uses cell scan loops to find actors instead of the more often used Cloaking Spell and that means LOWER overhead.  I suggest you examine your mod load for mods that perform cloaking spells since those are the genuine killer mods.  Cloaking spells initiate an entire new script for every object selected by the cloak which massively increases the overhead especially on a location change.

 

Cell scans have the obvious defect of course that they will completely ignore something or someone you can reach out and touch simply because they are on the other side of a cell boundary while selecting someone around the corner or in a completely different room simply because they are in the same cell but it's still a whole lot less overhead than a cloaking spell.

 

Once again there is a way to get the exact same results as a cloaking spell but only have one added script instance and that is the Quest Aliases method.  It's how Sexlab Aroused Redux does it's scans (it still has the cloak spell from the original mod but doesn't use it, not sure why it was never deleted).  Basically you set up a repeatable quest with aliases (optional flag on each should be set) and use the same selection conditions on the alias that you would in the cloaking spell.  From another script you start that quest which lets it fill it's table of aliases with whatever you have selected.  You add a script to the alias quest which provides a function that iterates through all the aliases in the quest and builds a table of the "found" and then returns that table to the caller.  The script that started the quest then calls the function and processes the results in a simple loop instead of a mass of new scripts.   

One major mistake in both Quest Aliases or Cloaking spells is to weed out "found" items using scripts when there are Conditions you can apply to the alias or the magic effect to weed them out first.  The perfect example of that mistake is the old Sexlab Submit mod which performs a cloaking spell to find ALL NPCs in an area then in the script instance triggered for each NPC it looks at the NPC and checks if it is a guard, if not a guard it exits.  Then in an incredible display of "I got that backwards" it checks to see if the option the mod has for involving guards is actually set so you ended up with all the overhead for that option even it you didn't use it. 

[mkess]

Ok, I'm back. I think i finally found the culprit that causes the heavy load. It's the new version of HornyCreatures V10 and MoreNastyCritters V11_4E. The HornyCreatures V8 and MoreNastyCritters V11_4C work. They changed the model of the schlongs to a flexible one. That seems to be the problem here.

 

If the mod spawns more than 3 horses at a time, and some other critters, too, my engine has not enough time to run your script.. or ANY other heavy script parallel. Instant CTD. I tried it wth Sexlab More Creatures. I got a crash near Riverwood. 3 horses were spawned at once. I downgraded the routine above, and the crashes were gone for good. The new versions of HornyCreatures and MoreNastyCritters are not stable on my PC: It's a combination of both on mediocre gaming PC that causes this annoying crashes.

 

So don't be mad, I only try to find the CTD on my machine, and give the information about what I found out to you.

 

P.S. I already use all possible SKSE dll fixes. Don't discuss that further. I know, what I am doing. I really do. I only try to find these crash for 6 days now. Before these crashes started over a week ago I could play for hours without a crash.  I installed too many new mods at a time, without a mod manager, and my backup did not work as intended. I really, really hate backup programs that do not work. Did I mention that? So it wrecked my Skyrim installation beyond any repair. At the moment I try to get back my stable version of the game.

[mkess]

4 hours ago, WaxenFigure said:

You get more CTDs by adding ANY large mod.  Skyrim.exe is not a paragon of stability, it's much more like a termite mound.

 

DCL uses cell scan loops to find actors instead of the more often used Cloaking Spell and that means LOWER overhead.  I suggest you examine your mod load for mods that perform cloaking spells since those are the genuine killer mods.  Cloaking spells initiate an entire new script for every object selected by the cloak which massively increases the overhead especially on a location change.

 

Cell scans have the obvious defect of course that they will completely ignore something or someone you can reach out and touch simply because they are on the other side of a cell boundary while selecting someone around the corner or in a completely different room simply because they are in the same cell but it's still a whole lot less overhead than a cloaking spell.

 

Once again there is a way to get the exact same results as a cloaking spell but only have one added script instance and that is the Quest Aliases method.  It's how Sexlab Aroused Redux does it's scans (it still has the cloak spell from the original mod but doesn't use it, not sure why it was never deleted).  Basically you set up a repeatable quest with aliases (optional flag on each should be set) and use the same selection conditions on the alias that you would in the cloaking spell.  From another script you start that quest which lets it fill it's table of aliases with whatever you have selected.  You add a script to the alias quest which provides a function that iterates through all the aliases in the quest and builds a table of the "found" and then returns that table to the caller.  The script that started the quest then calls the function and processes the results in a simple loop instead of a mass of new scripts.   

One major mistake in both Quest Aliases or Cloaking spells is to weed out "found" items using scripts when there are Conditions you can apply to the alias or the magic effect to weed them out first.  The perfect example of that mistake is the old Sexlab Submit mod which performs a cloaking spell to find ALL NPCs in an area then in the script instance triggered for each NPC it looks at the NPC and checks if it is a guard, if not a guard it exits.  Then in an incredible display of "I got that backwards" it checks to see if the option the mod has for involving guards is actually set so you ended up with all the overhead for that option even it you didn't use it. 

My solution for these kind of mods is to run them in an interval of more than 45 -60 seconds. I do this with all of these kind of mods, to lower the overall script load. So that the chance that they collide is much less. than with their default config. Autoloot all 0.3 seconds is a killer as example. It scans the small area around you constantly for objects. I do it once all 0.9 seconds and even reduced the range to a realistic one (arm length) That is enough, and lowers the load. If I wnat to loot a whole room, I have to wait patiently before it collects all things. I can do that.

 

I put much thought in my script configuration, believe me. I do not like stuttering, you know?

[twsnider1138]

On 3/31/2019 at 10:55 AM, Tron91 said:

Are, you sure you are meeting the rape conditions set in the MCM?

I have the same issue as the OP. I can be raped by the bandits, have many times in fact, but I’ve always had “Player Is Not Vulnerable To Rape” displayed on my debug menu. While I’m not sure if any other mod is conflicting with DCL, this has been an issue across at least three versions of DCL for me. Not a deal breaker, just irritating.

Oh and I have a glitch for the guards in the prison. I get the option to proposition them but, unless I use the pickpocket a key choice, they agree to sex and then blank out, never actually triggering the scene.

[Lupine00]

20 hours ago, GenioMaestro said:

NOT, the game not compute any related to dialog when enter cell because the activation message (press E to talk) are computed in real time when the crosshair is over the actor and the dialog are computed when you press the key. The game not waste time computing things that can not be need.

You really aren't following this at all. Have you ever written a game engine? Have you ever optimised a game? You talk like you're an expert.

In any case, it's the CK documentation that alludes to pre-processing of dialog conditions - many, many dialog conditions are STATIC, they do not require processing dynamically.

 

And YES, I'm well aware that dialogs that need it recompute dynamically. The existence of this dynamic behaviour in no way proves that there isn't any static pre-processing - which clearly isn't in the ESP, so would have to be done on load, if it exists, and we have the CK documentation telling us that it does. Nevertheless, linkup of dialogs to loaded NPCs would still be performed. It's not work in the sense you think you understand, but it requires memory allocations.

 

Then there's that bug where if you load a new quest mod, none of its dialog works right until you re-load a save... Hmmm... I wonder why?

 

In fact, it's likely there are other things in load that perform memory allocations, but it's no coincidence that Slaverun Reloaded, 3DNPC, and DCL - three of the most dialog-heavy mods around all dramatically increase the chance of crashing. SLR consists of very little but scenes and dialog. 3DNPC consists almost entirely of dialog, though its NPCs are evenly distributed, not concentrated like SLR, and DCL hits just about every character in the game.

 

That SLR has the worst issues with crashes around Dragonsreach, when the only thing that could be run is dialog processing is a huge clue here. SLR has very few actual scripts in motion because of the extremely linear, stage-driven nature of its quests. When you enter or leave Dragonsreach, there is a huge amount of memory allocation or deallocation, and this leads to fragmentation, that leads to crashes. 

 

Swapping from regular allocation to the custom allocator producing a dramatic improvement is another clue that fragmentation is the core issue in those weird random CTD, not cloaks. But you'd have to have actually written a few allocators, grappled with the MMU, and written allocators for physical memory scenarios before you'd have a keen eye for this kind of problem.

 

Still, I have no proof of static optimisation of any dialog conditions, but it would be so brain-dead not to pre-process the static conditions, like Actor ID, in some way, I suspect even Bethesda managed it. Even if there isn't any, setting up the condition chains and other stuff requires many, many, tiny allocations, and that's going to be enough to cause problems by itself. 

 

Dialog really does cause crashes on load and unload; there's a ton of reports of it, and its been highlighted by alleged Skyrim-engine experts.

 

 

8 hours ago, WaxenFigure said:

No you CANNOT run all the Cloak spells you want.    There is a limit to how many scripts the game will run at one time and when too many cloak spells are triggered at the same time that limit is all too easily exceeded.

Sure this is true, in a sort of "technically correct is the best kind of correct" way, but I guess he didn't really mean limitless cloaks.

 

While there are definitely mods that cause stack dumps with cloaks, and used to be many more, cloaks are not the huge bogeyman Waxen is suggesting. Sure, they require delicate handling. They need restrictive conditions, reasonable ranges, and they should do almost nothing in the added script, certainly as little as possible.

 

It's correct to say that sloppy cloaks have caused many problems in the past, but they're not the only cause of Skyrim woes or stack-dumps. There are many cloak-based mods that run fine out of the box, and others that will let you set the performance parameters up so they are OK. CreatureFramework falls under this category.

 

OTOH, cell traversals are not ideal in various respects, and there are mods that perform script-intensive, high-load, traversals in a way that adds perhaps as much load, or more, than a well-tuned cloak, to deliver the same intent correctly.

 

I'd say that ill-considered event handlers are right up there in the cause-of-stack-dumps stakes. Looking at mods like Barefoot Realism, SD+, or anything that handles on-hit ... I've seen these mods generate stack-dumps due to event-handlers on numerous occasions. Actually seen, for sure. Not just a theory.

 

 

Back to @GenioMaestro and his grumbles about DCL load.

 

Here's the question: what do you expect Kimy, or anyone else to do about this?

 

You don't really make any kind of proposal on how DCL could stop crashing your game - if we are to believe your suggestions that it was to blame - which now seem to have been seriously back-pedalled. Instead it seems like a vague grumble about load and mod size.

 

The load in the main DCL update handler is something Kimy pays attention to. Because this is well managed, any load that causes problems typically comes out of left-field, like dialog condition processing, or event handlers that fire a bit more often than expected.

 

If you use DCL to replace all the things its intended to replace (particularly DAymoyl + Defeat) but also things like FHU, RP, DC, DH, etc. then you'll have dramatically less load, and a much lighter LO.

 

If you use DCL as well as those mods, you better have a good PC. That's your choice. DCL has reasonably light load for what it does, but it does a lot. Expect some load.

 

 

Also, if you're going to complain it crashes your game, not just ask others if they share your crash experience, or report a situation and make clear that you're speculating ... but actually solidly claim DCL is the cause of crashes, flat out. Some decent evidence would be nice, and perhaps constructive suggestions on exactly how to mitigate those issues. Simply kicking an issue that you, and you alone, have, onto the mod developer and using an outraged tone, doesn't do much to help them fix your problem - if they even have any hand in causing it, which seems quite uncertain in this case.

[Kimy]

If someone finds a -concrete- bug or inefficient implementation that consumes significantly more CPU cycles than it should, I am all ears. Otherwise I consider this discussion to be both off topic and not very helpful. DCL is certainly not a small mod. Guess what? I knew THAT already! And so do its users. You can't just install 100 large scale mods on an engine that's not exactly known as overly resilient to load to begin with. I am not aware of ONE single issue in DCL that can singlehandedly crash people's game. Person with very little technical expertise tend to use anecdotal evidence such as "If I uninstall DCL, I don't experience crashes anymore!" as proof that it must be DCL's fault. But as I explained a while ago, that doesn't prove ANYTHING, except that SOMETHING in our load order caused too much engine load in a particular moment. Same goes for a last log entry before a crash being from DCL. That doesn't prove that it was DCL's fault either, as the actual culprit might not even create log entries.

 

TL/DR: "Your mod is big!" isn't a bug report. It's trolling.