z929669

It works for me, as I have never liked reading forums via mobile ... always hard for me to find info in any version. If you never really learn an app, then changes ... meh.

Can you specify what you see that is wrong on that page? Probably certain mod pages representing 'dropped' mods still have 'IsCore' selected, so fixing means that you simply navigate to and "edit with form" the corresponding mod pages and untick 'IsCore' then save. Thanks for checking and offering to help.

If you say you bought the game, that is good enough for me ... and if you are now running under Steam, I would suggest letting everything update to latest versions. This is a config we can help with ;)

Our position on post content as it relates to piracy is in the Citizenship Guide. It is not complicated. EDIT: when the game first came out in 2011, there were a great many modders, including me, that were interested in running Skyrim without Steam. Early versions of the game did not require Steam, but we do not officially support Steam-less or other dated versions of Skyrim.

I/we would rather not support non-Steam versions, due to the config differences from what (almost?) all of the modding community uses; however, as long as nobody is advocating or supporting pirated versions of the game on these forums, there is no reason that we need to worry about that. It is interesting though when anybody configures a legit copy of their game to work in ways it was not intended to work ... isn't that a prelude to what 'modding' is all about? As long as vlog's game is legit and perceived as such by his own words, then anybody that wants to help him out is welcome to do so here, but we just don't officially support non-standard game setups lest we open the floodgates.

EDIT: s4n me, so keep in mind the following is based upon posts before his last preceding this post as s4n alluded, we can create optional HTML classes in addition to the defaults. These classes will be 'compatible' with the site but allow a bit of 'customization' within the confines of a defined 'standard'. I do like the CSS extension in today's context, because we currently have not defined any 'final' standards as is apparent by the changes I already made to headings and default text coloring; however, I agree that it is not ideal to have that extension. Better to define a final standard with some options as HTML classes defined in the CSS (I assume anyway ... s4n has more knowledge about implementation options). I definitely agree that we have way too much customization happening throughout the site, and that we are making it way too easy to deviate from any standard with that extension. With the current skin and loose 'standard' we have now, the CSS extension is acceptable, but if we redesign the skin standard 'correctly' and accommodate acceptable deviations, all will be well. My advice is to stop relying too heavily on the CSS extension, as those pages will need to be revised under a different skin that expects the Mediawiki standard CSS ... unless you want to use it to create examples for s4n and me to consider implementing in the available site CSS once the new skin is implemented. It is important that all wiki pages outside of the User namespace have a consistent look/feel, so that users know immediately if they are on a STEP wiki page or just some other wiki page. Additionally, wiki and forums will have a consistent look/feel, rendering wiki-->forum navigation (and vice versa) relatively transparent, unlike it is today. The CSS extension would break that (inline CSS would too, but that is a chore, as it should be ... a deterrent top changing the standard).

I think that it is worth mentioning that the memory patch is intended for 64-bit OS. Many users do run 32-bit architecture still, and it makes sense that the memory patch is not for them. We welcome corrections or enhancements to any of our guides.

Happy holidays everyone! May all your new gadgets boot and configure flawlessly ;)

Unrelated, but I reduced your top image to a more realistic size ... revert if you want, but it was too big IMO. As far as underlines in links, that is the standard behavior ... [http://www.nexusmods.com/oblivion/mods/44069/ Alive Waters updated]will render on the wiki as: Alive Waters updated ... not sure what you are linking to in your post

OK, that's fine then. Just wanted to make sure you knew about history and even linking to pieces of interest like diffs and anything history related that can be loaded in the browser. Appreciate the diplomatic touch though ... you are thorough ;)

@alt3rn1ty Just FYI: No need to describe changes made to any wiki page here on the forums ... what a PITA it must have been to create that post! ... all pages on the wiki have PAGE TOOLS > HISTORY link to give you a page that allows a diff compare of each edit or a series of edits. All of your changes will be shown in detail in the History page so that you don't need to explain anything again (except maybe for 'why' you changed something).

As I said before, whenever anybody takes it upon themselves to alter wiki guides or other pages, it usually results in an improvement, because it forces others invested in the guide to critique those changes and the result is almost always positive change Edit away! Guide us with your perspectives in action! EDIT: info in mod pages that relate to larger guides (like ENBoost mod page and ENB guide) is supposed to be a condensation of the most important 'setup' info from the guide (i.e., mod page is a quickstart installation/setup guide) ... if that helps.

Yes, good call alt3rn1ty. You might consider adding this to testing under Mods forum. You can use the download link for your share and this forum for the 'mod link'. Alternatively, we can upload to the STEP mod on Nexus as a Misc file in Beta until further notice.

If you are familiar with our DDSopt Guide, then you know that 'standard' = base vanilla and 'hi-res' = HRDLC vanilla. I also follow the main points that are outlined in our guide, so that is basically the description of optimization. I do know what you mean, but I just don't have time to go into all that detail in the description and maintain it all. Just test if you want and post back if you see any errors or issues. Once I determine what Tony671 did and how it may differ from what I did, I will possibly ask him to use some of the techniques I employed in an updated version of his mod. I mainly want to verify that these versions work fine and look good first.

Mod pages on our wiki ;) just click on any of the categories at right on the main page (or the "Detailed Instructions Available" and "W" links in STEP Guide mod tables). Our mod pages serve as the info source for mods in guides and elsewhere.

Correct ... also, tony971's stuff has more options and likely does not use quite the same techniques for certain textures ... for example, I convert uncompressed terrain textures to 565 format, but most would convert to DXT ... not sure what exactly tony is doing, but there are many ways to skin a cat, and i have not examined his readme's or techniques to be able to say how much differs ... his files are smaller though, so that tells me that I have more files included in mine (or that he has reduced more than I have). It would probably be a good idea for me to take a close look at his mod to determine the differences. I will do that one of these days unless someone beats me to it. @ophansologo I included the DDSopt log in the download, which provides all details as to the conversion of each texture provided.

I resized/altered images to better suit the flow of text and other elements. What you see is what I thought was the best compromise for display of text and surrounding graphic elements. Feel free to devise a better result if you can find one (note use of {{clear}} and positions of [[file:/Image:]] wiki code/syntax). Also keep in mind that browser window size will vary by user, and that whatever you derive will need to look 'good' at various browser resolutions.

Ask s4n (he created it for use on mod pages) ... I think it defines the style of the tag elements on mod pages. The tags contain (among other things) the icons for the mod attributes (e.g., Core)

OK, I see now ... :P Fixing ...

We don't use that data, because it just adds to the noise, and the GPU overclock does not add anything really noteworthy to performance.

I think that this still applies though. Note the name of the plugin was changed from "Cleaned ..." to "unmanaged: ...".

I fixed the links on the mod pages. Any #tab= needs to be changed to # wherever they exist for links to guides that have been converted from HT to TOC. If the links and the "cleaned * ESM" language were what was causing confusion, they are fixed. I had already fixed the mod-page notes concerning cleaned plugins for the DLC ... admin see this post. The issue is that the new MO update places all DLC into an 'unmanaged' plugin, so altering the plugins by cleaning them no longer places them in overwrite (I think ... defer to DY, Tannin, and GDSfan on this and the new instructions) ... we need to make sure to update this in all locations (i.e., possibly the MO guide and elsewhere)

Looks fine to me ... one thing I would like to change about this guide is to offload any info that does or could exist elsewhere: enblocal.ini settings - move into its own guide under cat INI Guide (like ENBSeries INI Guide) and reevaluate the need for the Quickstart section, because all relevant "quick" settings are already included on the mod page.enbseries.ini - Trim down substantially to only the most relevant settings to be included under the quickstart sectionEventually, all "quickstart" guide sections should be housed on the mod page and the actual guides should go into more detail, encompassing all info contained within the corresponding mod pages. When we create an ENBSeries 'mod' page, it could house all of the setings for particular packs to which they apply. For info on Packs and our Semantic Wiki implementation and goals, see the DD talk page.

That is a fair representation though, so looks good. thanks.

My head is not acclimated to this subject at the moment, and I never had much of a hand in creating the ENB Guide anyway, but I think it is perfectly reasonable to rearrange information flow in the guide like so: ENB Guide ENBoost Quickstart In-depth ENB Lighting Quickstart In-depth Please have at it! IMO, the Quickstart for ENBoost is really on the Mod Page and should stay there and should be linked from the ENB Guide > ENBoost > Quickstart section. Otherwise, we could switch that the other way (mod page notes link to ENBoost quickstart).