z929669

Problem is that mod pages are associated with the main guide and we don't want to have any information on them that is not maintained by us. If pack authors begin adding their own specific notes to this, then it gets very cluttered and confusing ... and potentially will not be maintained by pack authors (and we don't want to have the added burden of maintaining and servicing Pack-specific questions) The best solution is to have ancillary mod pages that are associated with specific Packs. Definitely worth developing and implementing, but not as a hack to current mod-page format as a short-term solution. As I said, it might be best to devise a form linked to mod pages that creates the associated Pack-specific mod pages that produces a link to that page on a special Pack section of each mod page. The list of links (probably using Pack PAGENAME would be updated automatically via SMW). The form could be invoked from the mod tables dev form. Would need to ask s4n how best to design though. I will add it to the Packs 'wish' list on the Data Dictionary project talk page. EDIT: dev note added to the Dictionary page (scroll down on the Mods tab). Anyone fel free to add any additional wanted features to the notes on this wiki page under the appropriate tab.

see previous ... anyone?

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?