Random crashes, stability and reliability of the game.

[Grey Cloud]

I'm talking about actual playability you muppet, not what will physically fit into memory.

[GenioMaestro]

On 4/17/2019 at 3:47 AM, WaxenFigure said:

Been busy, tried it a bit and it does raise some interesting questions so I'm working up some tests but it's going to take me a while.  Just so you know I'm not ignoring this.

A week has elapsed. Is enough time for you?

Have you made some test??? Have you got any conclusion??

[GenioMaestro]

1 hour ago, Lupine00 said:

You see that this was on the FO4 forum? A different engine, two generations later.

 

If you inspect a save game before and after, you can see what happened. It's not actually made up.

Those scripts never run again after suspension, they bloat your save, and unless the mod has a mechanism to restart its scripts, it will be broken.

 

That's one reason why mods like SexLab have that ability.

 

If you saw what happened to SD+ saves, you wouldn't be doing some second hand research that itself is based on non-conclusive speculations and second-hand whispers from a developer talking about a different game.

 

 

As for what SmkViper is saying, it has nothing meaningful to do with any of your assertions, and that you don't see that is an indicator you probably shouldn't be telling everyone how stuff works based on something you read somewhere once, and some incorrectly executed experiments.

 

 

That you're quoting absolutely irrelevant wikipedia articles and putting words into my mouth - telling me what I'm talking about - when I wasn't. I'm done here. Believe what you want. You can't be helped, but you can cause trouble for others.

https://www.loverslab.com/topic/114982-sexlab-approach-redux-by-bakafactory/?do=findComment&comment=2593405

 

1 hour ago, Lupine00 said:

You see that this was on the FO4 forum? A different engine, two generations later.

You see the word "Papyrus"??? The two web pages talk about the same programing languaje called "Papyrus"

 

1 hour ago, Lupine00 said:

If you inspect a save game before and after, you can see what happened. It's not actually made up.

Can you paste screenshots of your savegames and show us what happend???

 

1 hour ago, Lupine00 said:

Those scripts never run again after suspension, they bloat your save,

Can you justify your words in any way???

 

1 hour ago, Lupine00 said:

and unless the mod has a mechanism to restart its scripts, it will be broken.

 

That's one reason why mods like SexLab have that ability.

Can you explain HOW a mod can know WHEN a script is broken and HOW can restart it???

Can you paste the source code of SexLab that make that?

 

1 hour ago, Lupine00 said:

If you saw what happened to SD+ saves, you wouldn't be doing some second hand research that itself is based on non-conclusive speculations and second-hand whispers from a developer talking about a different game.

https://www.loverslab.com/search/?q=stack dump&type=forums_topic&item=24042&search_and_or=and

Excuse me, but the search "Stack Dump" in the 662 pages of the SD+ forum only show 10 messages and nobody certify that the problems are directly related with the Stack Dumps.

 

 

I only try find a explanations to yours words because have none fundament.

Is evident that a lot of people had problems with the game for years and a lot of them think that theirs problems has been caused by the stack dump because they think that the stack dumps break the game when that is totally false. 

 

1 hour ago, Lupine00 said:

some incorrectly executed experiments.

Can you explain WHY my "experiment" are incorrect. Have you downloaded it and try it???

[Tiress]

Another interesting quote from SmkViper, it's from a FO4 FAQ though:

Quote

The only thing "overloading" the script system will ever do will be to slow down all
script processing. You could theoretically run your system out of memory at some point
but the game would be unplayable long before then.

This one is from an old Bethesda forum:

Quote

Q: Do you know if it's possible for Papyrus to get so overloaded that it just 'drops' scripts, failing to fire them entirely? I get sparse reports from certain people that various scripts in my mod just 100% never go off for them. The entire rest of the mod is fine (quest stages, events, NPCs, etc.) but that one script doesn't fire and it breaks everything. I have them look into their papyrus logs and they're usually pretty messy.
 
Do you think they have a lot of other mods with update blocks or something? (Or any suggestions I could give them?)

 

A: No, it will not "drop" function call requests or running threads. If it is overloaded things will take a while to process, but it should never lose anything. (Ruling out any bugs I'm unaware of, of course)

What CAN happen, however, is a script could get locked down for a long length of time, preventing any function calls to said script from running because they cannot obtain the lock. For example, if a quest script went into a loop with no latent function and no outside calls it would prevent anyone from calling SetStage on that quest until it exited the loop (assuming the loop isn't infinite).

If you're getting reports like that, I suggest asking your users to type in "DPS" in the console to dump everything running to the log, and ask for that log. It should tell you everything that is running and it should be clear if something is stuck (though admittedly it might be hard to know for sure if the thing that is stuck is a script you don't have the source to)

 

[GenioMaestro]

25 minutes ago, Tiress said:

Another interesting quote from SmkViper, it's from a FO4 FAQ though:

The Papyrus Script Engine of Fallout 4 is based in the Papyrus Script Engine of Skyrim.

Near the 90% of the things are exactly equal. The Fallout 4 Papyrus Script Engine only have some aditional functions for solve some of the problems of Skyrim and have some interesting compilation options.

https://www.creationkit.com/fallout4/index.php?title=Differences_from_Skyrim_to_Fallout_4

https://www.creationkit.com/fallout4/index.php?title=Papyrus_Compiler

https://www.creationkit.com/fallout4/index.php?title=RegisterForMagicEffectApplyEvent_-_ScriptObject

 

In Skyrim, the OnMagicEffectApply event can be called each 10 miliseconds equal to 100 times per second when ussing concentration spells like Flames or Life Steal from vampires. Is one of the most expensive events and a lot of games are broken by mods that use the OnMagicEffectApply event. That problem has been solved in Fallout 4.

[GenioMaestro]

1 hour ago, Tiress said:

Another interesting quote from SmkViper, it's from a FO4 FAQ though:

This one is from an old Bethesda forum:

A lot of thanks. REALLY. I read that post years ago and lost the link. I search it for months and i can not find it.

Said very clearly that the game NEVER drop a script and never lost a function call.

Because precisely the DPS console command GENERATE a Stack Dump for know what are making the Papyrus Engine.

[yatol]

4 hours ago, GenioMaestro said:

 

 

Can you explain WHY my "experiment" are incorrect. Have you downloaded it and try it???

there's no need to, your test is useless since you have no idea what the problem is

 

coc qasmoke and cast your stack dump spell, you were expecting something?

many are using alternate start, that's because stack dumps aren't harmless (dumping scripts, when some stuff is running, now there can be problems)

 

click on new game, helgen script put npc in carriage, start moving the carriage, make npc x say something, the one on the horse start following....

 

- mods start initialising themself once the game start running, a mod like halo poser with highter priority than helgen quest that have a lot of stuff to load, you can expect problems

- mods start initialising themself, but for now you are just a moving camera above that carriage that look at the npc that talk, some scripts will keep trying until they can do whatever, but if you have too many... stack dump

 

horse get where it have to turn, helgen script make it turn, so far so good

carriage was supposed to turn after a wait(2) or something, but you had a stack dump

the wait is no longer waiting, the stack dump is dumping all scripts, to reload them, to get another stack dump, and it's all about luck

 

carriage keep going that way, horse go another, carriage and horse are attached, collision do the rest, it's crazy carriage time

you get to helgen like that (didn't got stuck in a tree or whatever), blabla open the door, script is dump before opening the door, horse keep going in the door (you are stuck, carriage won't pass the door)

oh, you got lucky next time, door open

you are close to the end, but horse don't stop and crash into the wall, carriage can't go in that wall, collision cut the horse in 2, one part in the wall, another part with the carriage that is send flying to space

after a few more fail, you see npc losing his head, oh, a dragon, npc start running around, you too, you climb the stairs, dragon don't break the wall, you are stuck again

 

because of that stack dumps aren't harmless, and many have problems with the civil war (if you can't do it, turn off some mods that can be turn off and try again, instead of relying on console commands)

[GenioMaestro]

14 hours ago, Lupine00 said:

Similarly, you can learn the hard way that games that have a log full of stack dumps is highly correlated with games that are full of "broken" mods that aren't doing what they're supposed to, and exhibiting odd bugs, frequent CTD, or frequent failures to load. (Not the little traces that you get when a SKSE function fails, or when a None is used where a None should not be, but genuine stack dumps or suspensions).

 

You can learn these things through repeated experience, or you can just read that many, many others have that same experience. Later, when you get a better handle on how VMADs work, and how modified properties update (or don't) into modified scripts, it becomes obvious why some of these issues arise. Examination of data in problematic, bloated, save games helps you understand these problems too.

 

I'm not sure, but it seems to be the case, that there are some improvements in memory handling and script resilience in SE and FO4, but LE was written in a memory poor context, and it imposes strict limits on the size of Papyrus stacks. Stacks are simplistic fixed size allocations in LE, and do not appear to be extensible in the way a native Windows stack is (for example). So, once you hit that limit, that stack is screwed.

You are acusing the game of have a problem that not have. But, again, you need see it with your own eyes.

 

I beg you donwnload and run my ScriptTest, install it, launch 3200 events of type 1=Cell Scan. Let it run one minute and stop it. Open your log and see how the game have processed ALL the 3200 events whitout lossing one of them while generate the Stack Dumps.

If you preffer my second test you can download Multi_Cloack, install it, generate 200 npc's and look in your log how the globals varibles always match while the game generate Stack Dumps.

 

That two simple test demostrate whitout any posible doubt that the Stack Dumps are totally harmles.

Please, run it and see it with your own eyes for convince yourself.

 

The memory managent in Skyrim always be patetic because the stupid memory blocks give a lot of problems and the limit of 3.1 gb of the 32 bits executable make the things more bad. The only way for have a stable game is have the utilities correctly installed. When you have that the game is solid as a rock. I can play with 220 mods for 4 consecutive hours with any problem. If you can not made that read my post and revise your configuration.