z929669

Seems like a good improvement ... once all have been covered and pass muster (which they should, if all will be covered analogous to the current coverage)

Nice test run ;) I cannot attest to any of the m-thread settings, but I will check out EnableCompression enblocal setting, because I know there are variable results with that one. Agree with keith though that most of the skyrim.ini settings should be left at default unless there is some reason to change them (i.e., testing). We should continue to recommend what we always have, remaining cognizant of said changes above just in case for testing behind the scenes.

@Greg Sounds like you are familiar with wiki maintenance. Feel free to contribute to our wiki in any way you wish. We can always use more help ;) PS: We do use some extensions that allow custom CSS and the like. HTML generally works in the wiki, and we use it to some extent (complex lists are a good example). Our wiki is largely powered by Semantic MediaWiki.

Thanks for the feedback ... can you confirm what settings are key? You can do this by commenting individual changes you made to the INIs and testing on same sequence in game.

This. Thanks for finding that.

DoubleYou's work I would guess.

As a general rule, avoid using H1 tags ... they are not ideal in most situations, particularly when mixed with H2 (H1 are used for page titles I think). Just use those for HeaderTabs pages. The H2 underscores are better for main headings. We could make a change to that, but it would break way too much on the wiki. s4n set it up how he wants it, and I don't want to make such a significant change without his buy in and support for all of the changes that would need to come after. EDIT: I went ahead and increased the H1 top margin, but no underline. I also increased the font size of H2 a bit. I think the result works quite well without changing much that currently exists. Unlike most other pages, the overhauled DDSopt guide uses H1 headings simply because that guide uses so many heading hierarchies due to the need to handle all of the DDSopt UI elements that need to be addressed ... I wanted an additional layer of headings to get it to work out right. Other guides just don't drill down that much, so H2 works well as a top heading. Let me know if this is better. EDIT2: I reverted the ENB Guide edits to headings you made ... no offense intended. The real issue left is the H1 underline I think. s4n had a reason for not using it, and I will trust that his reasoning is sound.

My guess is that s4n does not like that behavior (I don't prefer it either ... glitchy and PITA most of the time IMXP.

It seems to me like SKSE is not installed correctly or that there is an issue relating to SKSE initialization. Even if one of the files exists in the wrong location, it will not work. With MO, you need to install SKSE EXE and DLL into ./Skyrim and then install the scripts and INI using MO. Check that SKSE is running by looking at the logs inside %USERPROFILE%\Documents\My Games\Skyrim (I think that's right for Win 7 systems) ... it is evident at Skyrim startup if SKSE is not running properly (or try opening an MCM menu in game).

Please do create any INI guide you want and use the same structure if you know how to do it. I will eventually go in and change what you don't get right, so just worry about the content and basic layout if you want. PS: The DDSopt INI is not nearly as well understood as the ENB INIs, and the users of this one only want to copy/paste the entire INI anyways, so it is purely utilitarian and not meant to be pretty at all.

Tech ... see my previous post please :/

All INI guides should follow the same format as we have now for DDSopt INI and ENBseries INI (see the category page). Notice that the ENBseries INI guide uses subpages for each section. This is a big guide and Tech et al are willing to go to the lengths to document most every setting I think along with screenshots. Editing in this format is much simpler, less prone to loss of edit (happens rarely on big pages), and load time is reduced greatly. On the other hand, the DDSopt INI guide is very small and has not subpages inside INI Settings category. It itself is categorized under both INI Guides and INI Settings (ENBseries INI Guide is only categorized under INI Guides, but its subpages are all under INI Settings). EDIT: Tech I get it ... take a look at the page now ... no underlined links, problem resolved. The actual INI uses all caps and brackets around each section, which is pretty standard for INI files. I would rather use lower case and keep the brackets if there is still an issue with the way it looks now without underscored links. Besides, you removed the brackets from a heading, whch was never underscored. EDIT2: Tech, it is ultimately your call, since you are the one doing most of the work on this guide. I am just trying to help you understand one user's perspective ;)

I am glad you mentioned that ;) We are having a discussion about that on another thread EDIT: ... and Category pages are not necessarily pretty, but they DO follow a very simple layout and are very easy to navigate. Try clicking on the category at the bottom of any guide page, mod page or pack page ... it is really one of the easiest ways to get at info around the wiki. Note that we also have subcategories and that the ENBseries INI guide is sub-categorized under INI Guides and that Settings pages are each sub-sub-categorized under that as INI Settings.

The brackets tell us: "yes, this is a list of the enbseries.ini sections, and we are talking about those ... all of them." I don't think readability is any issue at all. My eyes are not that good, but I can see those ini sections just fine. Information comes first before appearance for a guide like this, IMO.

Brackets were intended to indicate that we are referring to actual INI sections as they exist by default and in the same order. This is tremendously helpful to anyone editing that INI (which I have done a lot). Visually, the guide sections and settings should parallel the enbseries.ini that ships with the latest release. @Tech Have a look at this discussion, where I mention the same in regards to your edit. Unless we get repeated complaints, I think it is pretty useful this way.

There is no 'standard' use of User namespace. As long as what is created there is not offensive, then people just use this space as a sandbox for whatever. Lots of people use it for testing wiki-related code as well as for personal stuff. Rather than our users spending too much time delving into and elaborating their User space, it is more useful for people to contribute to the main areas of the wiki, so encouraging focus on the main namespace is essential. I think it might even be warranted to create a namespace for user-contributed guides or just move these guides into the main namespace. People are just wary of using the main namespace for some reason. There are lots of guides that need reorganization and content updates. The Hardware and Troubleshooting guides need work. We encourage completely new guides or even somewhat redundant guides. New general articles of interest relating to modding in general are also welcome. A wiki is intended for collaboration and sharing rather than personal 'site' development in User namespace.

I think tech is right ... you need to tell PHP let JS run on the site (assuming you ex is javascript and not java proper). it seems like a config issue. s4n would know ... PM him

OK, good location to have placed that (duh). User namespace is good for all sandbox stuff, but pages for all should be created within the '(main)' namespace, which is the default namespace if none is specified: http://wiki.step-project.com/New_PageSystem specs are stored by user and should be entered via the STEP Portal link on the Main Page. My sig links to my specs on the wiki.

Yes, I am taking care of that as well ... agree it is not needed. Where is that quote from? I assume I wrote it but forget where ...

I use the R5G6B5 conversion for all of my MSN, and it looks and works great. No issues at all in-game that I can see. Since BM does not include the body normals but only head and hands (Nevermind, it does include MSN for hands, body and head ... was thinking about the meshes I guess), I will need to check how 565 optimization of BM against vanilla pans out with attention to neck and wrist seams. Changing the vanilla and or BM normals can both potentially exacerbate seams, so this would entail looking at the following under different lighting conditions in a STEP:Core setup: Better Males unoptimized, vanilla unoptimizedBetter Males optimized*, vanilla unoptimizedBetter Males unoptimized, vanilla optimized*Better Males optimized*, vanilla optimized** optimized = 565 conversion for MSN and DXT optimization for the other textures.

Creating new post so that this won't be missed .... I added language to take care of the LOOT Meta Rules for a few other mods in STEP:Core that are associated with STEP:Extended: AOS --> (SBD&S, W&C) SkyFalls & SkyMills --> (SDD) Realistic Water Two --> (B&F, PTW) Book of Silence --> (EBQO) There are probably some more, so let these set the precedent, and we can apply wherever necessary. NOTE: I don't want to just reciprocate all LOOT Meta Rules ... too much maintenance overhead ... only those that apply to STEP mods that are associated with other STEP mods not yet installed according to the linear Guide instructions.

.. there are likely several other cases where STEP:Extended mods are associated with STEP:Core mod LOOT Meta Rules, so we will need to tackle those likewise.

When I installed 2.2.9, I had no issue implementing the meta rules according to the instructions, so not sure what the problem is. I think they work fine on the mod page, and they are associated with a specific mod and upstream Core mods. The problem with aMidianBorn_ContentAddon.esp is that it should load after a mod that has not been installed yet (Even Better Quest Objectives). Even so, we need to inform users that install Book of Silence that its plugin should load after whatever it should load after ... this is a mod-specific attribute. What we ought to do is modify mod-specific LOOT Meta Rules instructions in cases like this to mention that the rule can only be created later in the installation process. Then we can add Meta Rules pertaining to the downstream mod (in this case, EBQO) on its mod page for those installing (in this case) STEP:Extended. In other words, we need to have the same Meta Rule on both the aMidianborn mod page and the EBQO mod page. I am changing it now to reflect what I mean, so take a look at both mod pages. EDIT: also, the plugins do drag & drop in LOOT, but only if "Show only conflicting plugins" box is checked.

Is this fixed?

Glad you like it! Let me know if you find any strange effects that cannot be fixed by removing some custom CSS or other tweak. Templates included ... but my changes should not affect any of the templates (difficult to say though) I am working on mocking up what I have in mind for the ENBSeries INI guide. I am leaving your guide alone for now, but want to mock up for a bit before changing anything. What I have in mind will utilize subpages as subcategories and behave more like an index ... emphasis on ease of accessing information, which should be more useful for this rather complex index-like guide.