Kesta

So, I reinstalled SR:LE this weekend (lot of improvements since the last version I used, some month ago, good jobj!), and made a quick review of the guide just now, to see if I didn't miss any cool stuffs. Aaand I noticed the "need" of manual cleaning and custom LOOT rule for GDO. Question is : Why is it advised to load GDO after IA after deleting conflicting records with WAF, instead of patching INFOs like other conflicting records ? Just to go on the flow like "since we're here to remove the quest edit, let's keep removing stuffs" ? or is there something special about INFOs that I'm unaware of ?

Actually there is a lot of request/remarks over various forums that it should be called USLP. On an other subject, I believe UESP (Unofficial Elder Scrolls Pages) haven't been added yet. (https://www.uesp.net/)

So, I'm not exactly into necro-stuffs but... I'd like to bump this thread. Because that's probably my favorite mod with SoS (kidding for SoS :p) Reason : I'm still kinda new here and have no idea how was STEP late 2013, but I believe that today's modding/patching capabilities could help bring this mod in a future version of STEP:Extended... While as pointed more than 2 years ago, some weapons might not be suitable for a STEP install, removing the new path to the new meshes in the STEP Patch, and / or using the hide functionnality of MO, it's easy to deal with those "weird" red eagle's weapons, while keeping some serious improvements (Dragonbane, longhammer, fang...)

What GrantSP said + EFF automatically cast invisibility on followers when you're sneaking IIRC. The feature is toggleable from the MCM.

All the USKPs (USKP, UDGP, UHFP, and UDBP) will be merged after the next release (2.1.3, which should be up in a few weeks, will be the last one offering distincts plugins for each dlcs). Codename : USLEEP (Unofficial Skyrim LEgendary Edition Patch) Official announcement : https://www.afkmods.com/index.php?/topic/4226-unofficial-skyrim-legendary-edition-patch-usleep/&do=findComment&comment=156272 Release planned for november.

Here is a video comparison : https://youtu.be/PtAGL_08FTY?t=2m52s (not by me) The difference is essentially noticeable on the skull. Shooted with 4K version. Edit : And here is hodilton's vid as well

Shooting star : The one I saw seemed fine. Maybe he added more varitey ? Haven't checked the changelog nor dissected the mod yet. Rain drops : Yeah, I can confirm that I get a drop about 5-6 FPS whenever its raining. Though I didn't compare to a potential fps drop with the non-merged version of raindrops.

No, as Zilav explained it's fushia because it's an injected record. I just edited to stroke the lines in my post because it was related to the part "I've never seen one for myself", but I'm the one who've been misinterpreting the fushia background color as being red ^^ If you look at the form ID of one of those records, you'll notice that it begin with "01" instead of "17" (as it should, since 17 is the index of WAF in your load order). This technique, used with keywords, allow differents mods to check for the same keywords without having a direct dependancy. The record is allowed to use a formID which is "outside" the range of numbers it's supposed to be in. Mator recently gave some nice explainations on this here : https://forum.step-project.com/topic/8213-looking-for-documentation-behind-the-concepts-of-xedit/?p=129949 The reason it's marked in fushia in xEdit is that the records with the specific formID stored in WAF is different than the one in the STEP Extended Patch. In this case, it's fine, because even if the two records are differents, they serve the same purpose. However, an other mod reliying on injected records could have injected a totally different record with this formID (since formID of injected records arent bound to start with the mod index), with a totally different purpose (maybe even not a keyword !), which would have be a major issue. So if two injected records have the same formID but aren't exactly alike, they're highlighted in fushia in xEdit.

Can you give an example of such conflicts ? If the font is purple, it just mean that the record in this plugin is a master, which is overriden by another plugin. For instance, every records from Skyrim.esm which is overriden have a purple font. Usually, there is no issues with purple font, since it's absolutely normal that a plugin edit some of its master records. Though it's worth a look sometimes, just to make sure it's not a wild edit. The background color is related to the whole load order, i.e. the record/field have the same background color in every plugins it is edited : If it's white, there is no conflict (only one instance of this record in the whole load order), If it's green there is no conflicts (usually means ITM at the record level. In the View panel, fields with green background means there is no conflicts, they're the fields hidden if you select "hide non-conflicting rows). If it's Yellow, then there is override, but without conflicts (it just means that a plugin edit some of its master fields, but as I said previously, it's normal for a plugin to do so in order to make changes tot he game). If it's red, then there is conflict. You either need to make a choice between the two, or create a patch. If it's fushia... well, I've never seen any purple, and it's not listed in every documentation, but it's supposed to mean "critical conflict". What's a critical conflict ? No idea... My guess is just that you have a red background with a purple font, which make the red background look kinda like purple. If you're looking at the STEP load order, keywords in WAF are displayed as such. Edit : Nevermind, Zilav answered here https://forum.step-project.com/topic/1327-tes5edit-by-elminsterau/?p=134041

@TechAngel : Thx for the answer. At least now I know it might not just be me failing at something ^^ Maybe, thought I've been toying with some enbseries.ini quality settings as well without probant results. What do you mean by "Enboost's data migration" ?

Some ENBs come with absolutely 0 stuttering, even on mid-end computers (which aren't even supposed to be able to run them). FPS can drop as low as possible, still ZERO suttering. Aaand.. I think it's amazing. Two examples of ENB which have this "feature" : Vividan ENB and Tamriel Reloaded ENB. (Didn't use Vividian for a while though, I'm just assuming it's still similar to what it was some months ago). My question is : Could this come from something else than enblocal.ini settings ? I've been tweaking mine a lot for various ENB (Grim and Somber, Bleak, Unbleak, ...), but never reached the 0 stuttering as I experienced with the two examples I gave above. Even with presets supposed to be less performance-heavy. Like, other settings in skyrim.ini or skyrimprefs.ini, some things to take care of in enbseries.ini (Maybe there is a specific effect which is known for causing stuttering ?) I recently installed Skylight for my STEP profile and like it a lot, I'm getting about 45 FPS... but I still have some stuttering here and there, and I really would love to get rid of it, even if it cost me 4-5 more FPS.

Have anyone made extensive test regarding modified NearGridToLoad / FarGridToLoad ? Both for stability/performances, and for the final result in game ? FarGridToLoad seems allright to me, you can't see further anyway while in game (except from atop of a mountain, but since everyone is using skimpy outfits, they don't look at the landscape from there, because it's too cold... :p), but does an increase of NearGridToLoad make things even smoother ?

You can quickly check for moss rock.esp and paralysis.esp as well. Haven't tried manually nor with merge script, but WB 306 can merge them without any issues, and considering what's in, it should do just fine with any of the above methods. Edit : sooo... look like I just forgot to get rid of paralysis.esp which was already merged into the STEP Patch :facepalm: Just checked for Moss rock (both classic and dragonborn), it's just a mater of copy as override -> STEP Patch -> Done. Of course you still have to keep the ressources. Edit 2 : Just how much am I using the word "just" ? Probably just too much...

This won't work, because records from your new plugin, even if you add the old one as master, won't be considered as "override", they'll belong to your plugin, not the original. So you'll just have everything duplicated, thus overlapping and probably causing a big lot of z-fighting (if it doesn't just crash your game). As for the rest of your question, I don't have enough knowledge to provide a decent answer just like this, and not enough time to validate some hypothesis and idea I have on the subject, so I'd rather keep quiet instead of sayin' ******** ^^ Best places to ask about modding right now are probably bethsoft forum or /r/skyrimmods Edit : Oh, so their IS auto-censorship here... sorry ^^

Ah, I didn't think about that top bar Now that you say it, it make sense. I guess there is nothing to do about it. Thx both for the heads up.

Currently, when using an anchor like [[#mySection|Click Here to go to mySection]], the view is moved just below the title of the section. I don't know if it's just me, but I have the feeling that modifying it so the view would be moved above the title instead of below would be much more intuitive for navigation. So you can make sure you start reading the right section, right at its begining, instead of a quick scroll-up to check if there was no mistakes in the link. That said, it's a minor issue, so if it need hardcore edits to the backend, just ignore this ^^

WIP - Work in Progress ?

Yeah, but it's marked as beta for the reason I explained earlier. At least that's what expired explained some month ago, when RaceMenu 3.0 first came out and required skse 1.7.2 (which was the "beta" version back then). The post have been edited since, so I can't quote it exactly, but it was something like "The latest version of SKSE is always Beta, but you can upgrade safely, it's just a convention to consider the latest release as beta" Edit : I think EssArrBee just explained it way better than I did ^^

Just anticipating potntial question from worried users : The last release of SKSE is always considered "Beta", but it's actually the latest up-to-date release. Its just a caution from the team, so if anyone run into a problem with the latest release, they can go back to using the previous one. As for SkyUI 5, while I'm super happy about it, I'm a little bit disappointed by the "classic" crafting menu, not as good and convenient as I expected.But enchanting and alchemy menus are really awesomes and perfects !!

Actually XPMSE (aka Groovtama's XPMS Extended) let you reposition the quiver position in x / y / z, as well as rotating it around those axis, so wether the "default" position is closer or not compared to vanilla / XPMS, there is no point talking about it since the player can adjust it at his will. BTW, I know it's not the topic, but since we talked about XPMS : have the "backpack-friendly quiver position" ever been considered for STEP Extended ? Since it include Wet & Cold, which include backpacks, it kinda make sens to me to use it. Might be easier to give clear instruction once Extended is a pack (because the fomod instructions would change). And to get back to the subject, about dawnbreaker's sheath : After a quick check, I couldn't find any relevant information about Meridia being closer to the dwemers or an other race (except the ayleids), so the choice should probably just be based on aesthetic (or set to none, and replaced by an other mod, I believe there is some of those in the nexus which are dawnbreaker-specific).

It's perfectly normal, the USKP is an "esmifyed" esp. To put it simply : It's an .esm, but with an .esp extension. Source : FAQ USKP (AFKMods forum) So, just let loot handle the position of the USKP as he want ;) Edit : Whoops, complete misread of the topic... sorry >_

IIRC, the pre-packaged ones in the link have "some" issues with LOD textures (at least the version I downloaded some months ago, late april or so I think). I mean, those available under this link : https://www.nexusmods.com/skyrim/mods/57353/? Honestly, the best thing to do is to use DDSOpt to optimize your textures yourself. This is a great know-how to learn, as you'll be able to optimize other mods you install if needed. Plus, you'll probably understand a lot more about textures once you're done, and thus be able to easier trooubleshot your future performances/glitchs issues. (Yes, you'll have issues, even if you are carefull and following guides exactly, that's what modding is all about ) Edit : Why does this topic show up with a fallout tag in the index ? oO

I was actually thinking about the very specific HasKeywordString (String s) function (available for every Forms): https://ck.uesp.net/wiki/HasKeywordString_-_Form Edit : btw, the problem is actually way more trivial than I thought. I was certain a similar function that allowed to check for only a part of the edid of the keyword was available. Like a function you'd call with a "_KRY" parameter to check if a form had any keywords with "_KRY" in it. I was pretty sure I already used one once, but I must be mistaken since I can't find it anywehre on the CK wiki nor in my scripts :O_o:

While I always considered this to be true (at least, it is when the keywords is used as reference in other records), I think it'd need further testing regarding scripts. Since in script you use their Edid to refer to Keywords, I wouldn't be 100% sure that the compiler associate the keywords with its formID (especially since you can run the compiler outside the CK). And that's probably even worst with SKSE functions since IIRC they work with the string representation of the edid.

IIRC, if the box isn't greyed-out, it means that the plugin isn't ticked in the loa dorder either. (with a default configuration at least).