hishutup

Wrye bash may have lock load order enabled.

It may be flagged because it is in an owned cell. I'd check the REFR first. There may even be a flag to disallow ownership. Edit: check the XOWN field. That's ownership.

I give the directions in each page, it's really simple. All we're doing is utilizing the UPF module

Fine, fine, next patcher is dsr. I'm really trying to get rid of skyproc because of all the stupid issues it has with memory. Plus I like the one click build that avoids all the wrye nonsense. I refuse to convert the great equalizer for many reasons, but are there any others that can be converted? I was thinking the no animals report crimes can be one. I just need to find an elegant way to define an animal.

well, I released those 4 UPF patchers on the nexus which should provide some benefit. These will work for both SSE and oldrim. UPF No Dragon LODs Patcher UPF Cell Encounter Level in Name Patcher UPF NPC Enchant Fix Patcher UPF Khajiit Ears Show Patcher

No, you either "optimized" them or you have the imipmapskip set to something other than 0.

Scripts pretty much never cause crashes if done properly. When I was developing some dynamic stuff, I really wasn't able to cause the game to crash unless I was doing some pretty stupid things. Script heavy can vary with skyrim. A bunch of small(execution time) scripts execute pretty fast, but there is a point where when a script becomes too long(execution time) to execute it appears that it pauses a cycle and then resumes after some other scripts finish.

https://forum.step-project.com/topic/12648-what-should-my-v-sync-settings-be/

I never said anything about stuttering, except the detail that it may be a side effects of vsync when limiting the framerate to something that isn't a direct factor of 60. I made one correlation with the data above. Reducing havok.fMaxTime seems to allow a higher in game framerate by alleviating the physics issues that are related to a framerate in excess of 60. I've been seeing stutter once more on my system, I had it completely gone by messing with some settings(windows. enboost, skyrim), but it never seems to be consistent across reboots.

With the history of oldrim, it was never in the inis by defualt and everyone had accepted that there is no way. When SSE was released it was there by default and people became curious. Looking back onto oldrim, that ini tweak exists in the engine, test it and it behaves as expected. Vsync just locks the frames that leaves the buffer to every frame that the monitor is expecting, is there some other side effect(like 60fps lock) from skyrim's version, that is something that I do not know. I leave all forms of vsync on because I was gsync to be active. This is where we get into theoretical and where my knowledge lessens... What I'd expect from decreasing the sleep time is overall higher havok thread activity. From what I've seen, if the absurd cabbage test doesn't max that thread, I don't know what will, that is so many physics calculation happening very quickly. I highly doubt that the havok processing it attached to something like the papyrus thread or the file I/O thread. Its still part of skyrim's process but it may run on a different core as it is somewhat asynchronous to how the render thread works, it seems they sync before or after the frame starts or is finished. As for decreased stability, I wouldn't expect this unless system resources are really limited(single core) or an object has poor or broken physics nodes attached to it.

I would highly suggest getting a 144Hz monitor with some form of adaptive sync, you'll never be disappointed.

For starters limiting the framerate can cause some pretty stupid microstutter just by how fps limiting and Vsync work. So you can get around the physics thing by adjusting how often it updates them. Basically, reducing the maxTime seems to allow higher framerates. I was playing with this quite a bit for ***** and giggles and yes, it correlates and causes the physics issue when a frame happens before an update, meaning more updates has the downside of more CPU load on those havok threads. I doubt people have hit the limit for the havok threads though. I have a gsync monitor, two actually. When I adjust the max time to update more often then the framerate of the monitor, the physics behave as expected. The highest refresh monitor I have a 200Hz panel and it did fine. Here is the tweak. [HAVOK] fMaxTime=0.009 The value is basically the reciprocal(1/X) of the maximum refresh rate of the monitor. I'd pad the refresh rate by a little because the only downside that I can imagine is a higher CPU load for those threads. If people want the method I used I basically left vsync on(gsync FTW), I tested various refresh rates(15, 30, 45, 60, 100, 200) and I played with the value to make a truth table, but the values I used were (0.066, 0.033, 0.022, 0.016, 0.01, 0.005).If the delay time between updates was too long, I got the whole flickering water/sun/swimming, flying animals, constant jump thing.I suggest you try it out yourself and draw your own conclusions from this.Havok is pretty much just in the runtime so I doubt any damage to a save can happen. Although, the position of any objects will be added and recorded of course. Also removing or increasing the framerate of the loading screens definitely helps with load times. For some reason bethsoft ties loading to framerate, I wonder why this is...

Is this what you're looking for?

If anyone cares or not, I uploaded a no dragon lods script. I got bored so I wrote one for sh*ts and giggles. I would've done this in zEdit but the docs are still not there :/ EDIT: Thats an interesting filter...

Scripts are a possibility and packing a python script into an exe isn't hard. One thing I would like to do is to convert skyproc patchers into zedit patchers. The scripting in zedit hasn't clicked with me yet and documentation isnt there yet.

I feel that the script additions will be a nice addition and something like frostfall can use them to potentially provide a higher quality product.

OCS patching is easy and pretty straight forward. I may revisit the script in the future but no promises. Generally speaking, an OCS patch is moving all the refs in the city worldspace into the tamriel worldspace. Of course, there is a bit more to it than that. OCS doesn't create instability, Skyrim just runs like **** with so many refs on screen.

I remember messing with that and there was no change. That was the first theory I had though.

Something that I had observed with SSE is that the LOD works fine but as you creep closer, the LOD will disappear for some distance and then re-appear. I forget what mod I was trying out but its was pretty weird, it was specific to SSE, the issue was not in oldrim. Not sure if this is 100% relevant but there you go.

Ditch the CPU, get a modern i5 quad core because these games are affected by single core performance fairly proportionally. I like Ryzen but the single core is not quite with Intel, sorry. I may pick up a threadripper even though I have no real world use for that number of cores, but I like the big "f you" to Intel. If you like the dx9 games you'll maybe want something higher than 8GB RAM, 16 should be more than enough. The reason is because dx9 game mirror the texture cache in RAM. You may also think about having games stored on an NVMe SSD rather than a mechanical HDD or SATA SSD. The reason is because the bandwidth of PCIe x4 is much greater than that of SATA 6Gb. Even my low-end NVMe drive out performs the theoretical maximum for SATA3. I'd say leave this one for last, the effect is there but not obvious.

Parallax does not exist in SSE. Well, it kind of does but it is pretty much non functional. Typically, when a mesh is flagged to have parallax, the diffuse will be glitched to this weird grey color.

I know there is an issue with v44, but I dont use the tool anymore, the last version I used was probably v40. File handling is a pain especially because authors use symbols that are not valid in the encoding that is used.

whoo, i just bought them all, no more CD and no more steam BS DRM.

I have been unable to load the wiki at all today, yesterday was hit and miss. You can download an html version through the browser and then use that as a sort that of snapshot.

What you described is not scripts, its packages. I have pretty limited knowledge in this area.