z929669

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.

Yes, was just testing out some options. Fixed now. I also edited the default CSS to meet in the middle with regard to the custom looks Tech created to override default site CSS. I agree with some of his changes, but just a bit toned down. elements should go more across the page as originally intended. That is the site look, so I removed much of the custom CSS for the ENB INI Guide (example) ... and altered the default a bit as a compromised between s4n's original format and Tech's preference. I increased the left and bottom margins and let them inherit the rest. Total width decreased to 90%. I also darkened the background and lightened the text just a tad. elements were given a bit more padding and darkened background/lightened text a bit. They just did not stand out enough before. Heading 2-6 margins were increased a bit, bc they were too small, particularly on top. The result is that there is no need for any custom CSS overrides anywhere within the main wiki other than to define new properties that we currently do not cover in the site CSS. Do as you like on User namespace, but we want the rest of the site to use the defaults. S4n will not want too many changes to his original defaults. Next, I want to tackle the layout of the ENB INI Guide. It should take on TOC format and categorization hierarchy like in this example. The example shows the settings for the Environment section of the ENBSeries INI ... notice how much easier it is to get at specific info, which is more like an index and better suited to retrieving info. The categorization would be like so: Guides > INI Guides > INI Settings I am putting together some HeaderTabs vs TOC compares in the new Category:Example which in turn will house subcategories related to specific examples. I will mock up the ENBseries INI guide in here as well.

Fixed spelling in thread title ...

@Smitty Play the vanilla game at least until level 30. By vanilla I mean pure vanilla. Then come back and install STEP:Core and start over with same character and then tell us what you think. STEP does not postulate that it changes anything substantive. We are primarily focused on 'fixing' and 'correcting' and showing our users how to go about it in as simple a way as possible. We provide a relatively simple guide to modding Skyrim with all the resources and./or references you need to do it. It is actively maintained. Go try to mod Skyrim without referring to this site and let us know what we don't provide that we could provide ... or that others are doing a better job of providing --within the purview of the STEP Mandate. There just aren't any alternatives for modding Skyrim or any other game compared to what this site has to offer (+ other user guides like Skyrim Revisited) More XP needed, or you just expect more than what we can manage. Complaining about the hassle of installing a bunch of mods indicates to me that you are not really into the game enough to care much about its shortcomings (or the challenges of overcoming them) ... most likely because you are not experienced enough with the vanilla game to notice the differences. If you have played the vanilla game and STEP:Core each through level 30-ish, then you have a unique perspective that deserves mention within the annals of the critical literature of the entire Bethesda modding paradigm. If you are convinced that you are experienced enough to supply a truly definitive critique, then there is really not much STEP or modding has to offer you at this time. ~ Strength & Honor ... (name the movie)

Not so. Indeed, converting the *_msn.dds body textures from 888 uncompressed to 565 uncompressed makes the textures look borked, but that is only because most texture file viewers do not normalize un-normalized normals by default. DDSopt is an exception in that the Prieviewer automatically re-normalizes any normal maps that are not normalized. You will notice only a very minute difference if you look at the DDSopt Preview of the texture post conversion (use diffx2). The DDSopt Previewer has a built in diff and normalizer to compare source/processed. Looking at each version independently (also available in the Previewer), you will not see any diff. These 565-converted textures will appear correctly in-game, because they are normalized by the game engine when loaded. (you can normalize and re -save using Gimp or Photoshop, but it is only semantics to do so.) It is conceivable that neck/wrist seams could pop out, but not that I have seen (this will definitely happen if you compress, but we are only reducing the info in the uncompressed format from 888 to 565 using Ethatron's own custom algorithm, which is the most economical, near lossless normal-map conversion that I am aware of.) Also, seams may be moot anyway with Better Males, since it combines the body meshes (IIRC). Anyways, I don't see any issues at all in game with the vanilla body msn when converted to 565 uncompressed from 888 uncompressed.

I would again suggest going with R5G6B5 for any of the model space normals (*_msn.dds). This will result in 2/3 size of the originals without any detectable diffs in game and no loss in resolution (but the texture itself will look borked in any texture file preview other than DDSopt, because the converted result is not re-normalized in most texture viewers by default --normalizing the texture itself is not a requirement though, because the shader engine takes care of that in game when the texture is rendered on the model). For Better males, i would reduce all to 2k res and 565 uncompressed format (this is an approx. 83% reduction from the original) . We will eventually provide these conversions via the STEP 'mod' on the Nexus. WIP, no ETA, all TBD ;)

It should go away once we update IPB to 4.0 ... ETA TBD ;)