z929669

OP updated with proper compares ... keep checking the OP as updated files are added.

Good ideas. It will be interesting to see what kind of solutions may already exist in IPB-MW integration.

I agree with this concept (one mod forum to house all mods, including those in STEP). I also agree that it would be ideal to have a mechanism to generate a wiki mod page for any forum mod page created ... however, that could get very messy unless mod pages were only tied to thread creation (or edit) by an administrator that knows how to properly name the thread or complete the necessary info to generate a useful (and accurate) mod page. The other issue is categorization of forum threads. People will not do this consistently, so we'd need to manage each thread and place it into the correct category. This is simplified if we simply don't do that unless a mod is entered into the testing phase or is accepted. not sure about the included/dropped tagging system though. Ar you saying that if a mod is included, it gets a category tag, and if dropped the tag is removed? Perhaps you mean somethng else, since once a mod is assigned to a category, it should stay there and the marker should remain on the thread. This all sounds like dreaming right now. We first need to move to the new forums!

Eureka! DoubleYou was correct. The high uGrids setting was effectively snuffing my Requiem-based AI. I assume that since that mod adds a lot of added AI with higher spawn rates, these scripts were taking a back seat to the vanilla AI and resulting in the inconsistent behaviors. uGrids 11 is pretty ridiculous, so I trimmed to 5 to confirm and have gone up to 7, which also works. I will try 9 next to see if I can get away with that. Thanks for the tip, marking this as solved for the next poor sap.

Let us know if you see any change after. Have fun.

Glad you have that config working. It is viable, for sure, but not nearly as easy to set up as what we recommend. I understand you not wanting to change it ... however, you just need to tick the little box next to D3D triple buffering and watch your average frame rates increase a bit (unless you have already??) If you don't like it, just uncheck the box ... simple!

Mod pages are not tied to Packs, nor do we want them to be in the current paradigm, as this would cause a lot of redundancy. We may look at a potential solution in the future ... a possible solution would be to add a Pack reference section to existing mod pages that would house links to pack-specific mod info. We could also use mod subpages, but that is an arbitrary hierarchical org structure with only one single 'branch'. We could use sub-properties or sub-categories, but it all requires more dev, which is not something we can do at the moment. We already have a Pack dev subforum (it is more than just that though): https://forum.step-project.com/forumdisplay.php?fid=85

Assume MO users (and recommend MO in your Pack just as STEP does. Then it is a simple matter of unticking the mod in question ;) One more reason why we recommend MO now

Yep that is the one. They are different from where I am looking ... did you check the CRCs? What about the byte counts? I honestly don't know if the difference is actually functional. They may have the same code essentially, but the byte count is different. User preference applies here ;)

30 FPS is fine, BTW .... Are you using ENBoost vsync ONLY? Keep in mind that vsync will cut your frames in half unless you are getting at least 59 FPS (this is how vsync dances with your monitor refresh rate [assuming 60 Hz], and it is the way it works). If you are running your vync from your graphics drivers (contrary to the guide recommendations), then you are likely not using D3D-compatible triple buffering (unless using RadeonPro or similar), which effectively means that you can only achieve frame rates My big question (and you can help to answer) is whether or not ENBoost is behaving as if it also provides D3D-compatible triple buffering (graphics drivers' natives software does not). This will be evident if you are using ENBoost vsync (and ONLY this is active) and you notice relatively stable frame rates in the range of approx 35 to 55 FPS (rather than steps of 10/12/15/30/60). I see this in my game using only ENBoost vsync (I typically get between 30-60 FPS and several steps in between this range ... specs in my sig). Your frames have likely dropped if you recently enabled vsync (via CCC) or disabled triple buffering (unlikely; your card only supports OpenGL tri buffering, so that does nothing, be in on or off). I suspect ENBoost provides the correct tri buffering though, so give that a shot (and turn of iPresentInterval ['0'] in skyrimprefs.ini as well as vsync in CCC). It would be a great contribution if you could compare your frame rates between two similar runs using the same savegame with CCC-enabled vsync versus ENBoost-enabled vsync

Follower Trap Safety installs three scripts, while Traps Make Noise - Follower Safety Patch only installs one ... and the one is slightly different.

OK, I addressed all of these inconsistencies I think ... thanks ;)

That is why we have the Pack support thread in the support forums ;)

Not a nit ... that is a correction of an untruth! EDIT: Fixed

Ease of maintaining Packs with regard to mod updates and possible changes to STEP. Integration of Pack installation as a post-hoc event to STEP installation. STEP guide and methods supporting Pack development and maintenance.

Can you instruct me on how to get to that? This is another enigma that Google did not help me to find :/

Parallax is for ENB, but it can also be non-ENB related. I forget what this one uses.

The uGrids thing sounds plausible (I run uGrids 11), but then there is still the issue that my enemy AI --all else remaining the same-- is normal without Requiem.esp but AC (artificial catatonia) with Requiem.esp. I'll look at this though. @torm Testing a clean save is next thing on my list ... sure hope that is not it, because it takes time to get up to level 13 under hard-core Requiem, and I don't want to begin again!!

After fiddling for hours, it is 100% clear to me now that the issues lies with Requiem itself. Not Hard Times, not any of the Requiem patches. Requiem.esp itself. I basically have a complete STEP setup, and with Requiem disabled, sabre cats attack elk (and me), elk run from me, enemies always attack me and all in the world of Skyrim is as expected. With requiem enabled though, I get very strange behavior from all animals, and NPCs behave erradically, depending on the source. Vanilla NPC enemies will stand there and do nothing unless I try to talk with them (then they attack), while Interesting NPC enemies seem to attack. If I enable Requiem, all vanilla creatures and NPCs begin behaving strangely again. I am wondering if there are bits of garbage in my save files that are causing this ... some kind of corruption with Requiem.

Has anyone ever gotten the following error while launching the ASIS patcher? I can run other SkyProc patchers, but not ASIS. It has been a problem for awhile now, and Google has nothing that I can use. java.lang.ArrayIndexOutOfBoundsException:-103EDIT: I should mention that I am launching from MO.

Good points about both of those (stealth and patrols). I'll give it a shot and post back after I get some play time. I have been having this issue for awhile and am just now addressing here.

This overwrites AOS, but I am not sure that it is better ....

Should we drop this? Is it better than CaBaL's?

SOLUTION: uGrids too high with a heavily-scripted setup. Not all AI was initializing due to engine limitations. I am playing a Requiem build, but many types of enemies simply do not attack. I wander into a bandit camp and some of them attack on sight, others ignore me, and still others just stand there and let me kill them. Sabre Cats attack, but wolves do not. Elk walk right up to me. Followers sometimes fail to attack as well. Very glitchy NPC behavior. I suspect my NPC mods, but this should not be happening even with those, so maybe it is some kind of an incompatibility. Any ideas? Here is what I am loading: I could begin disabling suspect mods, but I thought that someone may have already figured this out before me.

OK, will implement and test and share results later this evening (evening for me anyway)