Random crashes, stability and reliability of the game.

[GenioMaestro]

 

I have thought for days whether I should respond to the messages and I think I should do it because it seems that some people have a totally incorrect concept of the game and are saying nonsense and giving bad advice.
In my opinion, that persons are harming the game, the users and the community.

 

If someone says that the game has a problem I do the corresponding tests to verify it. You should do the same.

It is impossible for some people to say that the same game works in one way while others say the opposite. Someone has to be wrong. If the game has a problem, everyone should have it. If some people have problems and others do not have them, it is evident that something is not right. And it can only be the configuration of the game, the mods or the computer.

To all those people who have random CTD and who say that you can not put many mods or many scripts because the game is overloaded, I recommend that you review their configuration.

To solve 99% of the CTD just install SKSE Plugin Preloader and put OsAlocators = 1 in CrashFix.ini

 

If you still have problems, delete the INI files from the game and launch it to create new INI files. Optimize your INI files with BethIni. If the CTD persists begin to deactivate mods. I have seen many CTDs caused by a bad DynDoLod or a BashedPatch or a requiem reqtificator or a bad merge.

 

The game does not have any problem, is practically stable at 99% and perfectly supports 250 plugings without any problem. And they can be armor mods or replacers or quest mods with dialogs or mods with special functions that run scripts every second. There is no difference.

 

That does not mean that the game can not do CTD. I have one or two CTD each week and I play every day for hours with more than 200 plugings. What it means is that it is not normal to have CTD every day and that it is not normal to have CTD if you overload the game. Simply the overload game will work more slowly but nothing more.

[GenioMaestro]

On 4/4/2019 at 5:42 AM, 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.  When that limit is exceeded then some scripts will NOT get run and those scripts may not even be in a mod that uses cloak spells but instead another mod that just happened to also be triggered at a point when the maximum number of scripts are already running.  Thus a mod using a cloak spell can induce bugs in other mods because scripts that mods expected to be run DO NOT GET RUN potentially leaving those mod in an unexpected state.

 

Stating as you did that stack dumps do not cause problems is a failure to understand the mechanism of the game.

multi_cloak.rar

 

This simple mod executes 16 cloacks in each npc. In a cell with 10 npc's it runs 160 cloaks and if there are 20 npc's it executes 320 cloaks. I have generated 100 npc's with the console and the mod runs 1600 cloaks without problems.
Each one of you get your own conclusions.

I do not know what knowledge you will have in programming but any programmer knows that all that does not make any sense.
The Script Engine has almost no limits and can accumulate near all the scripts that you want and never stops running a script and never loses a pending call.

Papyrus is a programming language and as such has a guarantee and absolute security. If millions of lines of code have been written in papyrus, it will be because it works.

That is why we rely on computers, programs and mods, because we know they always do the same and it does not depend on whether the CPU or the gpu or the hdd or the game are overloaded or not. The only difference will be the performance and the time but they will always do the same.

And on the stacks dumps I affirm again that they are totally harmless and I simply refer to what I have already written.

[GenioMaestro]

On 4/4/2019 at 1:45 PM, Lupine00 said:

...

 

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.

 

 

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.

 

...

You are explaining a lot of problems that do not really exist. The game does not have any problem either with the dialogs or with the scripts or with the mods or with the cell changes.

It seems that you have all these problems and as you do not know why you have them or how to solve them made to blame the mods and the game. When they are not at fault

I do not know what you do by touching the parameters of the memory blocks in the last part of CrashFix.ini but doing that will never solve your problems.

What you have to do is follow my recommendations.
Install SKSE Pluging Preloader and put OsAlocator = 1 and you will see how you solve 99% of your problems.

Because the problem is in memory management. By changing the parameters of the memory blocks you can reduce the problems but you will never solve them. Because the system of memory blocks is very slow and fragments the memory a lot and the only real solution is to eliminate them completely and that is done by setting OsAlocatos = 1

[GenioMaestro]

On 4/4/2019 at 8:41 PM, Nazzzgul666 said:

 

He wrote a lengthy guide about how stack dumps aren't a problem at all and a second that states the "too many animations" crash on start is entirely MOs fault and impossible to get with NMM because when he run FNIS in MO it was throwing countless errors and then - surprise - it didn't load.

Now complaining that his game is unstable with any mod, well... i'm not surprised. Honestly i'm not sure if every single post of his is just trolling or if he really thinks his "tests" where he leaves out half of the necessary stuff or fucks it up other ways would produce relevant results.

 

Usually i'm all up for explaining things to people who really want to know it but sorry, if somebody states he is a computer expert and made serious tests but is unable to run FNIS in MO without getting errors AND STILL CONSIDERS THIS A SERIOUS TEST then i'm at the point where a ignore list is very handy, regardless of intentions.

 

Please, when reading a message, read it in its entirety and do not take only the parts you want.

That message shows that the CTD caused by excessive animations has no relationship with mods or scripts.
If you can prove otherwise, I do not know what you are waiting for, DEMONSTRATE IT.

That message also says that MO has many problems with FNIS and that is public domain and everyone knows it.

The message does not say that animations or mods DO NOT work with MO. Nor does it say that the CTD caused by excessive animations has any relationship with MO.

It clearly says that the game works perfectly with NMM and with MO when it has 13k animations and 13.3 gigs of new mods.

I do not know why you intend to change what is written when anyone can read my original message.

 

 

I have bothered to do a detailed analysis on how the scripts and stacks dumps work and I have published it. Anyone can read it and verify that what I say is true.

If you think I'm wrong, I do not know why you do not say it on the blog or in the ScriptTest forum.

The stacks dumps are totally harmless and if you can prove otherwise, I do not know what you are waiting for, DEMONSTRATE IT.

[GenioMaestro]

On 4/4/2019 at 10:54 PM, Nazzzgul666 said:

SE doesn't really improve anything afaik, so it's more likely your profile than anything else. No, crashes aren't normal, regardless where. Well, not on a regular basis that is, that Skyrim crashes now and then even happens with vanilla, but it shouldn't happen often or at specific places. If that happens in small shops it definitly sounds like a problem, could be a lot of things, though.

First guess would be 2 conflicting mods, or specific lighting that usually happens in smaller places but i'm not really an expert on the CTD front, it's been years i had serious problems with these in my games. Stupidity excluded like installing an update and forgetting to remove the old version, that happened two days ago.^^

 

For 99.9% of all mods CTDs are never the fault of a single mod. Main reasons, i'd say in this order:

1. Conflicting mods, especially when editing the same cell, but other conflicts are possible.

 

2. Wrong install order. Usually because XPMSE is overwritten

 

3. Wrong load order. I hardly do anything else than run Loot, there are few expections where it fucks it up that i know and probably some more i don't know, but still a small minority.

 

4. Just too much. I currently have 4 mods doing stuff during sexlab animations, additionally to sexlab, something like 7 mods doing updates every few seconds and some more doing updates every few minutes. It's slow as fuck, but still stable so far. But when then a quest mod comes and teleports me away immediatly after (or even during, because slow) sex, it crashed once in 15-20 hours playing. I still consider that stable, although i can see on how slow responses are it's already way too much for my potato computer to handle.

99% of CTDs are caused by memory problems and very rarely have a relationship with mods.
Skyrim SE has much less CTD because it is a 64 bit game and has no memory problems and that is why it is more stable.
If a mod generates CTD it is because it is badly installed, it lacks dependencies or has some incompatibility.

 

The game does not have any problem for mixing the information of the cells. Any mod can put anything in any cell and the game will simply put them on top of each other. The only possibility that this causes CTD is due to memory problems.

 

Normally, a bad load order only generates visual problems in lights or weather. It can cause you to have gray faces and misplaced things but it is very strange that it causes CTD.

And I just said that it's "very strange" and that does not mean it's impossible, do not change my words again.

It is perfectly true that some ESP's placed in a specific order generate CTD with 100% absolute security, but that does not mean that CTDs are normally caused by an incorrect load order.

I repeat that it may happen but is "very strange" that it happens.

 

An incorrect load order can cause some mods not to work correctly because of problems in the keywords or in the equipment because they are changing the same things and that is called incompatibility and must be solved with a compatibility patch.

 

It seems that he has a bad LOOT concept but I will make another message for that.

[GenioMaestro]

On 4/7/2019 at 3:04 AM, Lupine00 said:

It's a common pattern that NMM users get breakages that result from some weird mix of old and new script files, and lingering script files from mods which are supposed to have been uninstalled, and have no ESP - which in many cases can cause big problems. Though people might imagine an orphan script file is harmless, if a mod that soft deps on them checks for them in an unsafe way, things get in a big mess.

 

It's also a common pattern that MO users get breakages in their FNIS or Bodyslide outputs.

 

Users of all mod managers can have issues with incorrect override order, but it's a lot easier to fix in MO.

 

It's also quite possible that core Skyrim files will get damaged from time to time, or installed incorrectly to start with. Sometimes you really need to do a clean install of them, to fix damage that can sometimes occur through no fault of the user.

 

Finally, regardless of manager, users who take LOOT as gospel are going to have issues with LL mods, sooner or later. LOOT sorts LL mods badly, demonstrably incorrectly. When people say you should sort with LOOT ... um ... sure ... as a starting position ... then you will probably have to fix most of your LL mods. While different updates of the LOOT data are better or worse at this, none are actually good.

 

...

I do not know how long you have used NMM but I have used it from 2014 to January of this year and I assure you that it does not have the problems that you say.
Of course I had them years ago. Versions 0.4 and earlier had those problems but after 0.5 they disappeared.
Do not say that NMM works today exactly as it did 4 or 5 years ago.

Nor do I know why you say that it is "quite possible" that the game files get damaged over time. It is something that has never happened to me. That can happen in other games but not in Skyrim.

And of course when you download a file it is practically impossible to download it badly and unless it is installed badly.
The likelihood that the game will work with a damaged file and that it will simply do weird things is ridiculous.

It also seems that you have problems with LOOT and it is another thing that I can not understand. LOOT orders the plugings as we want. I'm going to post another message to explain how LOOT works and how they should use it.

[Grey Cloud]

Lupine00 said:

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

Illogical, Captain. SLR puts a lot of NPCs in and around Whiterun. Each of those NPCs and their armour and equipment have textures which add to the VRAM requirements for the cell. In other words, 'there is a huge amount of memory allocation'.

Scripts can run and be gone in milliseconds but textures are with us always.

[WaxenFigure]

22 minutes ago, GenioMaestro said:

multi_cloak.rar 9.62 kB · 0 downloads

 

This simple mod executes 16 cloacks in each npc. In a cell with 10 npc's it runs 160 cloaks and if there are 20 npc's it executes 320 cloaks. I have generated 100 npc's with the console and the mod runs 1600 cloaks without problems.
Each one of you get your own conclusions.

I do not know what knowledge you will have in programming but any programmer knows that all that does not make any sense.
The Script Engine has almost no limits and can accumulate near all the scripts that you want and never stops running a script and never loses a pending call.

Papyrus is a programming language and as such has a guarantee and absolute security. If millions of lines of code have been written in papyrus, it will be because it works.

That is why we rely on computers, programs and mods, because we know they always do the same and it does not depend on whether the CPU or the gpu or the hdd or the game are overloaded or not. The only difference will be the performance and the time but they will always do the same.

And on the stacks dumps I affirm again that they are totally harmless and I simply refer to what I have already written.

 

Stack dumps ARE NOT HARMLESS.  So much of what you just said is a complete misunderstanding of what is going on.

 

First there IS A LIMIT on how many scripts can run at once.  There are ALWAYS limits, saying there are no limits is ridiculous as many of the problems encountered with the game are in fact cause by people running into the various limits in the game.

 

For scripts the limit is the size of the "stack".  In this case the "stack" is the memory table set aside to keep track of all of the actively running scripts.  When the "stack" gets full it means the resource for running scripts is full and no more scripts can be run until an already running script finishes running.  When another script attempts to start while the "stack" is full a "stack dump" is triggered which because it writes out the full contents of the "stack" happens to greatly increase the processing overhead at exactly the moment when it's the worst thing that can happen since during that process no scripts are allowed to run since the script engine has to be frozen while the stack dump is created.

 

And this is the point ("stack dump") where you completely misunderstand what does and does not happen.

 

There is no additional queuing mechanism for scripts, if a script does not get started because there's no room for it to be added to the stack then it is NEVER run.  That's the whole point of the "stack dump" being written to the papyrus log, it's so there's a record of all the scripts that have filled the "stack" so that the offending script or scripts that are filling the stack can be identified and the poor coding practices causing the problem can be changed.

 

As I have stated repeatedly since I first researched this problem, this is the type of problem which can induce problems in otherwise perfectly functioning and completely unrelated code.  Because if MOD A fills the stack at a moment when MOD B also needs to run a script then the script for MOD B does not get run and if MOD B expected that script to change something critical to MOD B you now have MOD B in a state the mod may not recognize and be able to recover from.  This can also happen to vanilla game scripts as well.

 

Just so you understand that I am not a neophyte or an occasional dabbler, I have written programs in dozens of different programming languages many of which I doubt most of the people in the industry have ever heard of because I have written programs for dozens of different platforms.  I have worked on operating systems and systems utilities, networks and networking, hardware microcode and even entered programs into computers via switch banks and consoles.  I am a highly experienced programmer who has always had the habit of learning the environment and limitations of the systems I program for and that includes the Papyrus scripting language as used by the Skyrim.exe code. 

 

 

Your demonstration scripts prove nothing, especially since you have the scripts that should be run multiple times as EMPTY scripts that the game doesn't even bother to start.  In short you don't get stack dumps with that "demonstration" mod, something you would have been able to tell if you had bothered to look at the papyrus log files which you obviously didn't.  All you really showed is that you failed to recreate the problem and then failed to detect the failure to recreate the problem and then came to the WRONG conclusion based on those failures.

 

 

[davisev5225]

I'm curious what the point of this thread is?  Memory allocations aren't a magic bullet for fixing all the crashes in Skyrim, that is (to borrow a poorly-used phrase) "public domain" knowledge.  To try and claim otherwise is just naive.  In fact, there's a good reason why it's no longer a default option in the SKSE mod "Crash Fixes" - it messes with other parts of the engine that expect memory to be allocated a certain way.  Example: graphics code.  People who like to use ENB end up having to make all sorts of configuration changes all over the place in order to keep the UseOSAllocators=1 config from crashing their game or causing other unwanted effects.

 

All I'm seeing here is someone who is desperate to sound like an authority claiming that there is a magic solution to (nearly) every problem in the game.  The very fact that you seem to think there is a one-size-fits-all solution demonstrates how little you know about programming faults.

 

Also, why split the discussions?  You clearly had ongoing discussions in other threads, why'd you make your own additional thread to re-hash all these points?  Why not continue the discussions where they were actually relevant?

[Grey Cloud]

6 minutes ago, davisev5225 said:

People who like to use ENB end up having to make all sorts of configuration changes all over the place in order to keep the UseOSAllocators=1 config from crashing their game or causing other unwanted effects

No I don't. You are committing the usual logical fallacy of assuming that because you do then so must everyone else.

 

8 minutes ago, davisev5225 said:

Why not continue the discussions where they were actually relevant?

Because it was derailling the original thread?

[GenioMaestro]

1 hour ago, WaxenFigure said:

 

Stack dumps ARE NOT HARMLESS.  So much of what you just said is a complete misunderstanding of what is going on.

 

First there IS A LIMIT on how many scripts can run at once.  There are ALWAYS limits, saying there are no limits is ridiculous as many of the problems encountered with the game are in fact cause by people running into the various limits in the game.

 

For scripts the limit is the size of the "stack".  In this case the "stack" is the memory table set aside to keep track of all of the actively running scripts.  When the "stack" gets full it means the resource for running scripts is full and no more scripts can be run until an already running script finishes running.  When another script attempts to start while the "stack" is full a "stack dump" is triggered which because it writes out the full contents of the "stack" happens to greatly increase the processing overhead at exactly the moment when it's the worst thing that can happen since during that process no scripts are allowed to run since the script engine has to be frozen while the stack dump is created.

 

And this is the point ("stack dump") where you completely misunderstand what does and does not happen.

 

There is no additional queuing mechanism for scripts, if a script does not get started because there's no room for it to be added to the stack then it is NEVER run.  That's the whole point of the "stack dump" being written to the papyrus log, it's so there's a record of all the scripts that have filled the "stack" so that the offending script or scripts that are filling the stack can be identified and the poor coding practices causing the problem can be changed.

 

As I have stated repeatedly since I first researched this problem, this is the type of problem which can induce problems in otherwise perfectly functioning and completely unrelated code.  Because if MOD A fills the stack at a moment when MOD B also needs to run a script then the script for MOD B does not get run and if MOD B expected that script to change something critical to MOD B you now have MOD B in a state the mod may not recognize and be able to recover from.  This can also happen to vanilla game scripts as well.

 

Just so you understand that I am not a neophyte or an occasional dabbler, I have written programs in dozens of different programming languages many of which I doubt most of the people in the industry have ever heard of because I have written programs for dozens of different platforms.  I have worked on operating systems and systems utilities, networks and networking, hardware microcode and even entered programs into computers via switch banks and consoles.  I am a highly experienced programmer who has always had the habit of learning the environment and limitations of the systems I program for and that includes the Papyrus scripting language as used by the Skyrim.exe code. 

 

 

Your demonstration scripts prove nothing, especially since you have the scripts that should be run multiple times as EMPTY scripts that the game doesn't even bother to start.  In short you don't get stack dumps with that "demonstration" mod, something you would have been able to tell if you had bothered to look at the papyrus log files which you obviously didn't.  All you really showed is that you failed to recreate the problem and then failed to detect the failure to recreate the problem and then came to the WRONG conclusion based on those failures.

 

I have not doubted about your capacity or your knowledge at any time. I just said that "I do not know what knowledge you will have about programming" and I thank you for telling me that you are an expert programmer. That will make things easier.

 

It is clear that we have different opinions and I am sure that years ago you did all those tests and you came to those conclusions because when you did the tests the game worked that way.

 

But how long have you not repeated your tests?
Because the game had these problems in 2012 and 2013. I assure you that today the game do not have any of those problems.

 

Are you telling me that every time there is a stack dump, the scripting engine does not execute the scripts? Are you really telling me that? Do you have a technical document that supports your ideas? Can you demostrate it somehow?

 

Because my ScriptTest shows the opposite. You just have to start 3200 type 1 events and look at the log to verify that what you are saying does not make any sense.

My ScriptTest launches an event that is multiplied by 3200 and normally generates a stack dump, but each and every one of my functions receives the event. The same happens when the stop event is sent, which is also multiplied by 3200 and all my functions are stopped.
The game NEVER loses an event and NEVER stops executing a single line of code. And of course the rest of the mods execute each and every one of their scripts.

 

The stack dumps do not spoil the game, nor the scripts nor the saved games. If they did, we would have corrupt games continuously.

Because you say very well that "if MOD B expected the script to change something critical to MOD B, now I have MOD B in a state where the mod may not recognize and be able to recover."

You know very well that if a script is not executed, it can trigger a series of serious problems and that is why the game NEVER stops executing a script and NEVER fails an event. If it did, the mod would explode and stop working and the programmer would go crazy and users would start reporting strange problems.

It would be completely impossible to develop mods in those circumstances because that would mean that a stack dump could break everything.

 

A normal user can not know when a stack dump is generated because the log is disabled by default.

If the stack dump can cause problems, the user should be able to know it.

A programmer can not know when a stack dump is generated.

If the stack dump can cause problems to the mod, programmers should have a way to detect it.

If the stack dump really were a problem, the web would be full of pages that would say it and we would have many tools to detect the stack dump and control it.

I urge you to think as a programmer and repeat your tests.

Because I apologize for telling you that everything you say does not make any sense as a user or as a programmer.

 

For your information I will tell you that I am also an expert programmer with more than 30 years of experience in a lot of languajes and I know very well what I say and why I say it.

And as far as I know there is no EMPTY script in my ScripTest.

[GenioMaestro]

1 hour ago, davisev5225 said:

I'm curious what the point of this thread is?  Memory allocations aren't a magic bullet for fixing all the crashes in Skyrim, that is (to borrow a poorly-used phrase) "public domain" knowledge.  To try and claim otherwise is just naive.  In fact, there's a good reason why it's no longer a default option in the SKSE mod "Crash Fixes" - it messes with other parts of the engine that expect memory to be allocated a certain way.  Example: graphics code.  People who like to use ENB end up having to make all sorts of configuration changes all over the place in order to keep the UseOSAllocators=1 config from crashing their game or causing other unwanted effects.

 

All I'm seeing here is someone who is desperate to sound like an authority claiming that there is a magic solution to (nearly) every problem in the game.  The very fact that you seem to think there is a one-size-fits-all solution demonstrates how little you know about programming faults.

 

Also, why split the discussions?  You clearly had ongoing discussions in other threads, why'd you make your own additional thread to re-hash all these points?  Why not continue the discussions where they were actually relevant?

Skyrim always have memory problems and that problems continue today. Some tools has been developed expecifically for solve the memory problems of the game like ENB, SSME and Crash Fixes. Whit that tools correctly configured the game is stable at 99% and must not made CTD.

 

Seems that the "public domain" knowledge is exactly the oposite. The game is unstable and can made CTD in any moment. You must look with detail what mods install and you can not run some groups of mods because that generate instability and CTD.

 

99% of the CTD are caused by the weird memory block system used by the skyrim engine because is very fragile and when is full the game made CTD. For that when you install a lot of mod the game made CTD, because the memory blocks are full. And for that the game made CTD when you overcharge the game with a lot of scripts because the scripts need small amounts of memory that increase the framentation and when the game need a big blog of memory the game made CTD because not have a big block free.

 

For years ENB and SSME try solve the problems but the only real solution is remove the memory block system and the only tool that made that is Crash Fixes when enable OsAlocators=1

 

As i know OsAlocators=1 not give any problem and not have any incompatiblity. You only need follow the instructions in the web page and configure the rest of the parameters in the recomended values.

 

90% of the users of Skyrim think the same as you. Is imposible apply a magic solution to all the problems of the game but we have it from 28 August 2016 whit the relase of Crash Fixes 12 but only the 10% of the players are ussing it.

 

For that a lot of players and the "public domain" knowledge say that is imposible.

But I say is real. Test it and see it with yours own eyes.

 

 

This discusion start in the forum of DCUR and is not directly related to DCUR.

I must make a new post in the technical section because this is a pure tecnical problem.

[WaxenFigure]

1 hour ago, GenioMaestro said:

 

I have not doubted about your capacity or your knowledge at any time. I just said that "I do not know what knowledge you will have about programming" and I thank you for telling me that you are an expert programmer. That will make things easier.

 

It is clear that we have different opinions and I am sure that years ago you did all those tests and you came to those conclusions because when you did the tests the game worked that way.

 

But how long have you not repeated your tests?
Because the game had these problems in 2012 and 2013. I assure you that today the game do not have any of those problems.

 

Are you telling me that every time there is a stack dump, the scripting engine does not execute the scripts? Are you really telling me that? Do you have a technical document that supports your ideas? Can you demostrate it somehow?

 

Because my ScriptTest shows the opposite. You just have to start 3200 type 1 events and look at the log to verify that what you are saying does not make any sense.

My ScriptTest launches an event that is multiplied by 3200 and normally generates a stack dump, but each and every one of my functions receives the event. The same happens when the stop event is sent, which is also multiplied by 3200 and all my functions are stopped.
The game NEVER loses an event and NEVER stops executing a single line of code. And of course the rest of the mods execute each and every one of their scripts.

 

The stack dumps do not spoil the game, nor the scripts nor the saved games. If they did, we would have corrupt games continuously.

Because you say very well that "if MOD B expected the script to change something critical to MOD B, now I have MOD B in a state where the mod may not recognize and be able to recover."

You know very well that if a script is not executed, it can trigger a series of serious problems and that is why the game NEVER stops executing a script and NEVER fails an event. If it did, the mod would explode and stop working and the programmer would go crazy and users would start reporting strange problems.

It would be completely impossible to develop mods in those circumstances because that would mean that a stack dump could break everything.

 

A normal user can not know when a stack dump is generated because the log is disabled by default.

If the stack dump can cause problems, the user should be able to know it.

A programmer can not know when a stack dump is generated.

If the stack dump can cause problems to the mod, programmers should have a way to detect it.

If the stack dump really were a problem, the web would be full of pages that would say it and we would have many tools to detect the stack dump and control it.

I urge you to think as a programmer and repeat your tests.

Because I apologize for telling you that everything you say does not make any sense as a user or as a programmer.

 

For your information I will tell you that I am also an expert programmer with more than 30 years of experience in a lot of languajes and I know very well what I say and why I say it.

And as far as I know there is no EMPTY script in my ScripTest.

You don't count the number of times the "3200" scripts get started neither are counting the number of times each script is run. Your claim that all scripts are always run HAS NO PROOF.

 

Add a global counter for each time the cloak is started and a global counter for each time an instance of the script is applied.  Run the cloak for a bit, end the cloak wait for the system to catch up and look at the results.  If the counter of scripts that ran is 3200 times the count of times the base cloak was cast then you can say that, until then you are reporting results you have not actually produced.

[Nazzzgul666]

4 hours ago, GenioMaestro said:

If you can prove otherwise, I do not know what you are waiting for, DEMONSTRATE IT.

That message also says that MO has many problems with FNIS and that is public domain and everyone knows it.

 

I don't owe you anything. As far as i can tell, that MO has problems with FNIS is rather spread by people who are unable to use MO than anything else, i never had any problems. Which doesn't mean there are any, but if FNIS shows errors than it's no doubt that you don't fucking do it right, there is no excuse whatsoever than "you're doing it wrong." Even fore can at least agree to this.

You stated that there is no such thing as an animation limit using NMM, and there is one using MO, which is just false and your tests ridiculous.

 

Same for stack dumps, your tests are entirely useless. The assumption that scripts restart themselves is utterly wrong, a lot of them don't, and that's why your entire test setup is completly out of reality. Which is the problem with pretty much anything you "test". You just look at one thing, and unable to imagine that other ways to solve something exist you assume it's always the way you'd like it to work. Here's a hint: that's not how programs work, that's not how anything in this world works.

 

And that something works for you is far from a prove that there are no problems, that's not how programs work and not how science in general works.

 

And at this point i honestly don't see why i'm even answering somebody who doesn't know how programs, or science, or anything in the world works but still claims his "tests" right and everybody else wrong.

[Lupine00]

I believe a number of posters have carelessly misread my precise wording regarding problems with mod managers.

 

I never suggested that the mod-manager software itself exhibited functional defects that produce the problematic effects.

 

Nevertheless, the combination of the way those managers operate (by design), the processes that must be followed to operate them correctly, and the typical use patterns (and mistakes) of users, result in the exact reports I describe - which you can trivially verify by examination of the voluminous DCL forum.

 

 

The problems almost certainly originate with user error, yet the problems are also correlated with the manager that user chooses. Each manager presents a user with particular challenges and benefits.

[Lupine00]

As for damage to Skyrim files, that would an artifact of the host computer, not Skyrim itself. It is idiocy, or deliberate mandacity that leads to claims that Skyrim files cannot become corrupted. Of course they can, if the host filesystem is damaged.

 

Furthermore, installations from DVD are more than trivially prone to errors that can be detected and repaired by checking against the online version.

 

Case in point, I installed LE from a DVD, and with zero mods other than USLEEP installed, it exhibited serious and consistent problems. After repairing that "clean" DVD installation from Steam, the problems were resolved. 

 

But of course GenioMaestro is going to tell me I'm wrong because he says so, then spout some more nonsense about stack dumps being harmless.

 

And Grey Cloud ... please read my posts properly.

I discussed memory allocation as part of the problem, dialog fragmentation won't cause crashes without other (large) allocations. But large allocations are essentially inevitable. They are not special.

 

You mischaracterised and mis-represented what I said, and don't understand memory allocation as well as you think. You're not helping, you're just spreading confusion.

[Nazzzgul666]

1 hour ago, Lupine00 said:

I believe a number of posters have carelessly misread my precise wording regarding problems with mod managers.

 

I never suggested that the mod-manager software itself exhibited functional defects that produce the problematic effects.

 

In case you're refering to me: that's true, you didn't and my statement was rather refering to another topic by this Genio where he stated that. I couldn't find anything wrong with your posts, though. But for different reasons than reducing misunderstandings, i don't see a point in repeating others and saying "yeah, you're totally right". Might be nice sometimes, but feels too much as applauding myself.

[davisev5225]

On 4/9/2019 at 10:38 AM, Grey Cloud said:

No I don't. You are committing the usual logical fallacy of assuming that because you do then so must everyone else.

You are committing the usual logical fallacy of assuming that I use ENB.  I do not.  I can, however, quote the bare minimum recommendations to fix known issues straight from Crash Fixes' page:

Quote

Common issues:

UseOSAllocators=1 and crashing when touching sliders in character creation or otherwise.
Set AlignHeapAllocate=1 in CrashFixPlugin.ini, downside is increased load time and increased memory usage.

UseOSAllocators=1 and crashing on game startup or loading save or shortly after.
Set ExpandSystemMemoryX64=false in enblocal.ini

Game says message box "running out of memory" and crashes.
Set ReduceSystemMemoryUsage=true in enblocal.ini

Ground textures flickering weird.
Set ExpandSystemMemoryX64=false in enblocal.ini

That's just the tip of the iceberg...

[GenioMaestro]

22 hours ago, WaxenFigure said:

You don't count the number of times the "3200" scripts get started neither are counting the number of times each script is run. Your claim that all scripts are always run HAS NO PROOF.

 

Add a global counter for each time the cloak is started and a global counter for each time an instance of the script is applied.  Run the cloak for a bit, end the cloak wait for the system to catch up and look at the results.  If the counter of scripts that ran is 3200 times the count of times the base cloak was cast then you can say that, until then you are reporting results you have not actually produced.

Well, I have to admit that you know how to give problems to the game and I am very happy that you asked me to make a system with counters for the cloaks. I've done it but it has not been easy.

 

Multi_Cloak_Counter.rar

Here you have a 16 cloaks system with counters in global variables. It's a first version and I think it works pretty well, even with Stacks Dumps, but it's not perfect and sometimes it fails. I will continue working to perfect it.

 

Papyrus.0.rar

In this 7 minute log you can see 6 stacks dumps while running 16 simultaneous cloaks over 25 npc's while I overload the game with my ScriptTest and run sexlab animations.
And the mathematical counter at the end of the log is accurate.

 

If you want to do tests you have to know that the mathematical formula requires a fixed and constant number of npc's because I multiply the number of npc's by the number of cloaks to know exactly how many spells have to be applied.
That means that you can not make test in outside cells because the number of npc's can change very easily. And it is not advisable to make tests in the inns because the npc's come and go when they want and spoil the formula.

 

I've done my tests in an empty cell like Shoal's Rest Farm with npc's generated with the console. In this way we know how many npc's we have and we can predict a mathematical result.

 

I beg you to take a look and give me your opinion.

[Grey Cloud]

On ‎4‎/‎9‎/‎2019 at 6:29 PM, davisev5225 said:

People who like to use ENB end up having to make all sorts of configuration changes all over the place in order to keep the UseOSAllocators=1 config from crashing their game or causing other unwanted effects.

 

43 minutes ago, davisev5225 said:

Common issues:

UseOSAllocators=1 and crashing when touching sliders in character creation or otherwise.
Set AlignHeapAllocate=1 in CrashFixPlugin.ini, downside is increased load time and increased memory usage.

UseOSAllocators=1 and crashing on game startup or loading save or shortly after.
Set ExpandSystemMemoryX64=false in enblocal.ini

Game says message box "running out of memory" and crashes.
Set ReduceSystemMemoryUsage=true in enblocal.ini

Ground textures flickering weird.
Set ExpandSystemMemoryX64=false in enblocal.ini

That's two different files so hardly 'all over the place'. The first two of those 'Common issues' only apply if Set AlignHeapAllocation is set to 1.

 

From S.T.E.P.

ReduceSystemMemoryUsage

This parameter will enable the ENBoost features to dramatically reduce CTDs and other issues caused from reaching Skyrim's memory limit. It does this by launching the enbhost.exe process to handle dynamic memory allocations. It is highly recommended to enable and keep this feature enabled! For this feature to work properly, users should have a minimum of 4GB system RAM. ENBoost is able to initialize multiple instances of the enbhost process, each able to use up to 4GB of system RAM up to a maximum of 128GB (capped by the kilobyte value set in VideoMemorySizeMb below. Set to true if ExpandSystemMemoryX64 is enabled (see above).

So this applies even if you are not using an ENB. I cannot recall ever seeing the "running out of memory" message as I used the S.T.E.P. guide when I used ENBoost and again when I upped to an ENB.

 

As for "Set ExpandSystemMemoryX64=false in enblocal.ini"

S.T.E.P. says "Therefore, if using the Sheson Memory Patch fix (either standalone or with SKSE), it is recommended to set ExpandSystemMemoryX64 to false."

So it still applies even if one is not using CF.

 

In any case, altering maybe a dozen or so ini settings hardly qualifies as a labour of Herakles.

 

"That's just the tip of the iceberg... "What 'iceberg' would that be?

[GenioMaestro]

On 4/9/2019 at 10:27 PM, Nazzzgul666 said:

I don't owe you anything. As far as i can tell, that MO has problems with FNIS is rather spread by people who are unable to use MO than anything else, i never had any problems. Which doesn't mean there are any, but if FNIS shows errors than it's no doubt that you don't fucking do it right, there is no excuse whatsoever than "you're doing it wrong." Even fore can at least agree to this.

I only can say YES => YOU HAVE TRUE.... But not forget that i know it and i know WHY show that problems.

But in 4 months nobody have the decency of say it. I see it patetic but is the reality.

 

For years MO have a lot of problems with FNIS and the only way for solve it use the redirection incorporated in the last version of FNIS. The error that i report in that message has been caused for not use the redirection in FNIS but nobody say it.

On 4/9/2019 at 10:27 PM, Nazzzgul666 said:

You stated that there is no such thing as an animation limit using NMM, and there is one using MO, which is just false and your tests ridiculous.

Can you paste the paragraph in which I say that? Please??

 

On 4/9/2019 at 10:27 PM, Nazzzgul666 said:

Same for stack dumps, your tests are entirely useless. The assumption that scripts restart themselves is utterly wrong, a lot of them don't, and that's why your entire test setup is completly out of reality. Which is the problem with pretty much anything you "test". You just look at one thing, and unable to imagine that other ways to solve something exist you assume it's always the way you'd like it to work. Here's a hint: that's not how programs work, that's not how anything in this world works.

 

And that something works for you is far from a prove that there are no problems, that's not how programs work and not how science in general works.

 

And at this point i honestly don't see why i'm even answering somebody who doesn't know how programs, or science, or anything in the world works but still claims his "tests" right and everybody else wrong.

Again, excuse me, but if you can not understand the results of the tests, it does not mean that the tests or the results are not valid. I have very good reasons to say those things.

Make your own test for try demostrate that things. If you and other people bothered to do real tests you would find out.

 

As I understand it, programs, computers and science are based on tests and results.
We use computers and programs because we have the absolute guarantee that they work perfectly and always do the same. I do not think anyone dares to doubt that.

A game is a program that works on a computer and must ALWAYS do the same on all computers in the world. That is undeniable.

The only difference is in the configuration of the program and the computer because depending on the configuration it can do different things. But if we have the same configuration we have the absolute guarantee that it will do the same.

Even with different configurations it will do the same in the 99% of the situations because precisely the computers, operating systems and programs are prepared for make that, so that they ALWAYS do the same and work perfectly in most configurations.

A game is a program and as such it must ALWAYS do the same. If the game shows this drawing on my computer it will show the same drawing on your computer.
If the Stacks Dumps are harmless in my game they must be harmless in your game .
If the Stacks Dumps are dangerous in your game and damage the game the same thing would must happen to me.

Use your head a little. If my game does not have any problems because of the stack dumps, your game can not have any problem. It is a program and ALWAYS does the same.

 

It is impossible for stacks dumps to be a real problem.

How many reports have you seen of games spoiled by a stack dump ???
NO ONE

How many websites say that stacks dumps are dangerous and can break the game ???
NO ONE

How many utilities do we have to control and monitor the Stacks Dumps ???
NO ONE

It will be for something. Think a little, please, because I am already getting tired of talking with walls without ears.

[GenioMaestro]

On 4/9/2019 at 10:08 PM, WaxenFigure said:

You don't count the number of times the "3200" scripts get started neither are counting the number of times each script is run. Your claim that all scripts are always run HAS NO PROOF.

 

Add a global counter for each time the cloak is started and a global counter for each time an instance of the script is applied.  Run the cloak for a bit, end the cloak wait for the system to catch up and look at the results.  If the counter of scripts that ran is 3200 times the count of times the base cloak was cast then you can say that, until then you are reporting results you have not actually produced.

Do you have any interest in this matter? Because I have bothered to make a test mod following your instructions and you have not even seen it.

[WaxenFigure]

3 hours ago, GenioMaestro said:

Do you have any interest in this matter? Because I have bothered to make a test mod following your instructions and you have not even seen it.

I have it. Patience.

[yatol]

On 4/9/2019 at 5:22 PM, GenioMaestro said:

And on the stacks dumps I affirm again that they are totally harmless and I simply refer to what I have already written.

 

On 4/9/2019 at 5:20 PM, GenioMaestro said:

 

it seems that some people have a totally incorrect concept of the game and are saying nonsense and giving bad advice.
In my opinion, that persons are harming the game, the users and the community.

 

same exemple as usual

 

whiterun siege, you charge the gate, auto unequip ammo load on those npc, with defeat, autoloot, wet&cold, and all the rest of that crap

you end up with 2000 scripts running, that's over the limit, maybe (check with 1500,1600,1700,1800.... if you feel like finding out)

you can give conditions to that stuff, bow equipped for auto unequip ammo, weather snow tempest for wet&cold, is humanoid if defeat is load on chickens, to not load that stuff on stuff it can't do anything too, go tell that to those modders

 

anyway, you get a stack dump, and you will have problems because

-the script that set global value x to y was dump, x wasn't set to y, and it have to y for the npc to give you the next quest

-script had the time to setstage to x, to end the siege, but it was dump before it put an end to the siege, npc will keep coming and coming and coming and coming and coming, you are stuck again

-script that was supposed to spawn the jarl was dump, you can't defeat the jarl that isn't there, you are stuck (if you mess around with the setstage because you can only do the civil war like that, the ctd is because of the jarl scene that is load without the jarl being there, game can't load something? game suicide itself)

-etc etc

 

create spell stack dump, that put 1 iron armor in coffer1, that have a script that put 2 iron armors in coffer2, that have a script that put 2 iron armors in coffer1

cast that spell in game if you think stack dump are harmless

 

wet&wold damage your health if you aren't wearing clothe in snow, what happen when that script is dump fast travelling to whiterun, and isn't unload

requiem use scripts for some bullshit, some find the mod hard, maybe because debuff was dump, so it wasn't unload, you now have -170% fire resist, you get destroyed by magic (if you can't damage anything, check if your weapon damage aren't negative)

defeat proc on you, idle down (or whatever it is) is load on you, you can no longer move, and stack dump, npc stay hostile, and finish you off instead of teleporting near you for defeat to do its stuff

 

 

 

[yatol]

On 4/9/2019 at 8:56 PM, GenioMaestro said:

 

 

Are you telling me that every time there is a stack dump, the scripting engine does not execute the scripts? Are you really telling me that? Do you have a technical document that supports your ideas? Can you demostrate it somehow?

 

so much for the one that create a topic because he know things better than others

 

https://www.loverslab.com/topic/119363-random-cdt/

 

[04/02/2019 - 05:30:48PM] Suspended stack count is over our warning threshold, dumping stacks:
[04/02/2019 - 05:30:48PM] VM is freezing...
[04/02/2019 - 05:30:48PM] VM is frozen
[04/02/2019 - 05:30:48PM] Dumping stack 872172:
[04/02/2019 - 05:30:48PM]     Frame count: 1 (Page count: 1)
[04/02/2019 - 05:30:48PM]     State: Waiting on other stack for call (Freeze state: Freezing)
[04/02/2019 - 05:30:48PM]     Type: Normal
[04/02/2019 - 05:30:48PM]     Return register: False
[04/02/2019 - 05:30:48PM]     Has stack callback: No
[04/02/2019 - 05:30:48PM]     Stack trace:
[04/02/2019 - 05:30:48PM]         [PlayerBarefootQuest (8700183C)].playerbarefootquestscript.OnUpdate() - "PlayerBarefootQuestScript.psc" Line 375
[04/02/2019 - 05:30:48PM]             IP: 2566    Instruction: 54    Line: 375
[04/02/2019 - 05:30:48PM]             [::temp72]: None
[04/02/2019 - 05:30:48PM]             [::temp73]: False
[04/02/2019 - 05:30:48PM]             [::temp81]: [Armor < (7D000D64)>]
[04/02/2019 - 05:30:48PM]             [::temp82]: ""
[04/02/2019 - 05:30:48PM]             [::temp83]: 0.000000

 

isn't that clear?

number of active script above x (what is x? don't know and don't care)

dumping stacks, or... unloading all active scripts

first one is playerbarefootquestscriptt.OnUpdate() -

 

and the script that suck is in that list, it's easier to find it in savegamecleaner than in there (you save during the dump, you check where there is in active scripts, the one that come the most is the problem

[04/02/2019 - 05:30:48PM]         [PlayerBarefootTerrainDetectionQuest (8700DAC6)].PBFTerrainDetectionQuestScript.OnUpdate() - "PBFTerrainDetectionQuestScript.psc" Line 84

ctrl f the papyrus log, 418 results (didn't bother deleting stuff above and under the dump, don't care it's not my mess)

[04/02/2019 - 05:30:48PM]         [DeviousTraining (63000D62)].dt2tools.getIsWalking() - "DT2Tools.psc" Line 189

ctrl f, 954 results

 

the 2 scripts the come a lot in that dump are a lot of active scripts, why? because they are broken, or they suck

 

[04/02/2019 - 05:30:48PM] Dumping stack 872152:
[04/02/2019 - 05:30:48PM]     Frame count: 2 (Page count: 2)
[04/02/2019 - 05:30:48PM]     State: Waiting on other stack for call (Freeze state: Freezing)
[04/02/2019 - 05:30:48PM]     Type: Normal
[04/02/2019 - 05:30:48PM]     Return register: True
[04/02/2019 - 05:30:48PM]     Has stack callback: No
[04/02/2019 - 05:30:48PM]     Stack trace:
[04/02/2019 - 05:30:48PM]         [DeviousTraining (63000D62)].dt2tools.getIsSprinting() - "DT2Tools.psc" Line 225
[04/02/2019 - 05:30:48PM]             IP: 93    Instruction: 3    Line: 225
[04/02/2019 - 05:30:48PM]             [acActor]: [Actor < (00000014)>]
[04/02/2019 - 05:30:48PM]             [::temp37]: True
[04/02/2019 - 05:30:48PM]             [::temp38]: False
[04/02/2019 - 05:30:48PM]         [None].DT2WatchdogMain.OnAnimationEvent() - "DT2WatchdogMain.psc" Line 80
[04/02/2019 - 05:30:48PM]             IP: 1620    Instruction: 53    Line: 80
[04/02/2019 - 05:30:48PM]             [akSource]: [Actor < (00000014)>]
[04/02/2019 - 05:30:48PM]             [asEventName]: "FootRight"
[04/02/2019 - 05:30:48PM]             [::temp11]: True
[04/02/2019 - 05:30:48PM]             [::temp12]: True
[04/02/2019 - 05:30:48PM]             [::NoneVar]: None
[04/02/2019 - 05:30:48PM]             [::temp13]: [167, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[04/02/2019 - 05:30:48PM]             [::temp14]: 156
[04/02/2019 - 05:30:48PM]             [::temp15]: 156
[04/02/2019 - 05:30:48PM] VM is thawing...
[04/02/2019 - 05:30:49PM] DT: EVENT - FootLeft
[04/02/2019 - 05:30:50PM] DT: EVENT - FootLeft
[04/02/2019 - 05:30:50PM] DT: EVENT - FootRight
[04/02/2019 - 05:30:50PM] DT: EVENT - FootLeft
[04/02/2019 - 05:30:51PM] DT: EVENT - FootRight
[04/02/2019 - 05:30:51PM] DT: 1- Summary: Aly - Armbinder-1.000000
[04/02/2019 - 05:30:51PM] DT: EVENT - FootLeft
[04/02/2019 - 05:30:51PM] DT: EVENT - FootRight
[04/02/2019 - 05:30:52PM] DT: EVENT - FootRight
[04/02/2019 - 05:30:52PM] Error: Cannot call HasKeyword() on a None object, aborting function call
stack:
    [aygasCore (9000182B)].aygascorescript.IsPlayerHouse() - "aygascorescript.psc" Line 1076
    [alias Player on quest aygasCore (9000182B)].aygasPlayerScript.OnLocationChange() - "aygasplayerscript.psc" Line 17
[04/02/2019 - 05:30:52PM] warning: Assigning None to a non-object variable named "::temp250"
stack:
    [aygasCore (9000182B)].aygascorescript.IsPlayerHouse() - "aygascorescript.psc" Line 1076
    [alias Player on quest aygasCore (9000182B)].aygasPlayerScript.OnLocationChange() - "aygasplayerscript.psc" Line 17
[04/02/2019 - 05:30:52PM] Error: Ca

 

last script dump in that stack dump, game reload those active scripts, and....

 

[04/02/2019 - 05:31:48PM] DT: EVENT - FootRight
[04/02/2019 - 05:31:48PM] DT: EVENT - FootLeft
[04/02/2019 - 05:31:48PM] DT: EVENT - FootRight
[04/02/2019 - 05:31:49PM] Suspended stack count is over our warning threshold, dumping stacks:
[04/02/2019 - 05:31:49PM] VM is freezing...
[04/02/2019 - 05:31:49PM] VM is frozen
[04/02/2019 - 05:31:49PM] Dumping stack 874468:
[04/02/2019 - 05:31:49PM]     Frame count: 5 (Page count: 5)
[04/02/2019 - 05:31:49PM]     State: Waiting on other stack for call (Freeze state: Freezing)
[04/02/2019 - 05:31:49PM]     Type: Normal
[04/02/2019 - 05:31:49PM]     Return register: False
[04/02/2019 - 05:31:49PM]     Has stack callback: No
[04/02/2019 - 05:31:49PM]     Stack trace:
[04/02/2019 - 05:31:49PM]         [SexLabQuestFramework (10000D62)].sslactorlibrary.GetGender() - "sslActorLibrary.psc" Line 494
[04/02/2019 - 05:31:49PM]             IP: 764    Instruction: 21    Line: 494
[04/02/2019 - 05

 

another stack dump since it's the same mess as earlier

 

[04/02/2019 - 05:32:47PM] DT: EVENT - FootRight
[04/02/2019 - 05:32:47PM] DT: EVENT - FootLeft
[04/02/2019 - 05:32:48PM] DT: EVENT - FootLeft
[04/02/2019 - 05:32:48PM] DT: EVENT - JumpDown
[04/02/2019 - 05:32:49PM] Suspended stack count is over our warning threshold, dumping stacks:
[04/02/2019 - 05:32:49PM] VM is freezing...
[04/02/2019 - 05:32:49PM] VM is frozen
[04/02/2019 - 05:32:49PM] Dumping stack 876401:
[04/02/2019 - 05:32:49PM]     Frame count: 2 (Page count: 2)
[04/02/2019 - 05:32:49PM]     State: Waiting on other stack for call (Freeze state: Freezing)
[04/02/2019 - 05:32:49PM]     Type: Normal
[04/02/2019 - 05:32:49PM]     Return register: None
[04/02/2019 - 05:32:49PM]     Has stack callback: No
[04/02/2019 - 05:32:49PM]     Stack trace:

 

and another one

until he finally ctd (since his scripts are such a mess, you can expect a few skeleton ctd in his load order, empty leveled list, broken npc, or whatever his ctd is)