z929669

AV may conflate with audio/vidio, and OBiS seems best for the third option. ... added last three

This discussion has been moved to an administrative forum that is not publicly accessible.

gray are files existing only in the destination ... review the DDSopt Guide. It is organized by tab, so it is easy to find all the info you need to run the program. That's the browser tab, so all you want to know about the info you see on that tab is located in the guide. I would advise you to abort using the batch files if you want to understand what is happening. the guide is descriptive and simple to reference (use the TOC). I have even gone through the pain of indicating uncertainties and spurious functionality (in yellow)

We will happily add the 20 meshes to our compilation, and you can remove it. Seems like an efficient means to an end of that one if you like the idea.

What is the reasoning for removal of DLC options? I think it is better if they are there, since it is informative at a quick glance. There is the advantage of reducing vertical space though. I also prefer the more wordy intro. People that don't want to read it don't have to, but those that do can gather more context. No reason to cater to the lazy in this regard. I also prefer the sitetable class for the requirements. Go ahead and keep mocking up your ideal though, because there may be some merit to making certain changes, especially where maintenance efficiency is concerned.

Yes, and it should be : USLP ... and UHFP makes sense, since we have UDBP and UDGP, which are otherwise ambiguous. (but the UP team is not so efficient with patch nomenclature: USkP, UDgP, UHfP, UDbP, USLP are the most efficient ... collectively called the "USPs") UESP conflates further with the USPs though

Yes, it is a mediawiki thing that cannot be easily accounted for in the skin without js. Not impossible to deal with, but far down on the list of priorities.

adding to Neo's last: ... or after XBone (and masterchief collection). Big companies constantly fail to learn from the past though in favor of going to market to beat out the competition. Short-term gains ... everything is always short-term wins in our global economy. Future be damned. Win 10 may be interesting to me in a couple of years once all the typical MS attempts at redefining 'standards' within their own proprietary context have either failed or faded into obsolescence. (Bing/Google, Silverlight/Flash, MS HTML/open HTML, Communicator/Lync/Skype, blah, blah).

Please use spoiler tags for giant walls of text lists ... fixed.

ENBoost is essential for a highly modded game with lots of demanding textures. You probably won't notice any performance increase, but you should see a reduction in load times and CTDs. It certainly should not hurt performance. I also would not run without vsync enabled (via GPU). Best way to judge for yourself is to run with and without for each of them. You be the judge ... but we recommend them for a reason ;) 30+ FPS is pretty reasonable. There is no need ever to want or have > 60 though. You will notice gfx anomalies at those rates (well, anything over your monitor refresh rate). We actually have doc and links on the wiki regarding both of these methods/tools. Have a read.

There are plenty of 'critical' updates to ignore. Two of them were posted on this thread by alt3rn1ty, and they were those updates that facilitated pushing Win 10 on all of us :P Other 'updates' have been incompatible with my external devices as well. Need the ability to ignore and choose.

You should know the style guide ... you made some good edits to it a couple of days ago. It's the STEP Wiki Editing guide (link on MP). Feel free to make other edits to that as you see fit, adding things we have not yet covered. Right now, it is a place where we (mostly me) jot things down so that we can begin some semblance of editing standards. The principles in there are what we want, but much is still lacking, and org could be better. That guide itself does not adhere to the writing style it posits, which is one of the biggest problems with our wiki in general ... writing style is kind of all over the place. I have made many revisions to correct, but only piecemeal ... lots left to do :/ We need more proactive wiki editors! (I will add you to that forum group, BTW).

If that is ever the case, then we can create that variant of this template by simply copying for that purpose. I wanted to name it according to the purpose it serves now. We should create other templates to aid editors in adhering to standards (take a look at Template:Fc now, fe). Proton had created v1, and I modified it just a bit. Proton also created templates for our Changelog formatted text. (see Template:Moved, fe). We should be implementing more of this stuff ... also see Template:Tl

I updated this template and the OP to reflect. It's a good template, and I just wanted to incorporate some minor embellishments to aid with look and usage. Also updated Skyrim INI guides to use. Will do the same for ENB INI guides next.

That's why we have the changelog listing "interim release" changes. People will need to be familiar with their own particular setup to understand whether or not they are in sync with the latest. Most people don't vigilantly monitor the changelog. Furthermore, most people also customize STEP to their own needs. Finally, we also make mistakes that must be corrected ... going live drastically increases the effective testing pool that uncovers those mistakes. It's just a 'guide.' each user constructs it independently, and we have limited ability to test everything outside of our own unique setups. We also don't have the time to optimize for user convenience (branching, versioning, hotfix notifications, alerts, announcements, etc.). At any given time, if one follows the live guide, they should be good to go. We don't commit to resolving all diffs for each of our users, nor do we want to. I would be surprised if more than 5% of our user base has STEP and supporting elements installed exactly as specified in the guide. I would be just as surprised if any two of those 5% had an identical setup. Our current process is as simple to maintain for our staff as possible, and first priority is convenience of the maintainers. Given our limited time, user convenience is necessarily the second priority. Much of our work goes into simplifying maintenance, which is limited due to the instability of the hundreds of independently-maintained dependencies. We often get opinions from people with good ideas, but at the end of the day, the ideas of the people actually committed to ongoing maintenance rule things. There are only 5 of us handling most aspects of the workload (mod testing, guide building, community outreach, infrastructure maintenance). We get invaluable assistance from other staff and the community, but only we 5 have been around consistently long enough to shape the mechanics and maintain consistency. The best way to understand is to become active in mod testing and guide(s) administration. You will quickly see that handling STEP as 'software' is impractical. The STEP guide is really very much like a wiki. Stasis can never be achieved, and volatility rules each moment. It works quite well, actually, given so few are administrating. It would take on the order of 100 full-time employees to administrate STEP to the degree stated in the OP. We encourage anyone to jump in and help out, but we won't adopt any new methods unless they are no-brainers that ease maintenance for us within the current paradigm. On the other hand, we will adopt new ideas/paradigms if the bearer of those ideas is as committed to long-term supporting the project as us 5 ;)

The dev wiki is necessary for Semantic wiki dev and generally good for novice wiki editors to practice. It is also a better place for things like Template:Heading, which, when implemented, is a real PITA to undo without reverting changes. Reverting is fine unless there are several 'good' edits interleaved with those changes. If a bunch of templates that we don't want get used a lot, undoing is an inconvenience.

@Tech Thanks for clarifying that the 'desktop' will be the default in Win10. That is at lease something positive. I would also like to not only disable, but uninstall mobile apps from the OS in favor of the standard, non-portable, more feature-rich versions.

Exactly. This is why I want to explore the limits of our ability to use site styes over templates, templates over HTML markup styles. Style sheets should provide everything look/feel as a first priority, and then templates can handle things more having to do with content and layout and whatever else impractical for style sheets.

Your mobile user dictionary needs a lot of help! Agree, templates are the way to go, but probably best to determine exactly what kinds of templates we really can use and make accessible to the public (because they serve a site-wide purpose) versus those that are experimental. I think that we would be better off fine tuning our existing templates rather than developing a bunch of new ones ... unless the new ones are flagged as 'experimental' and use discouraged outside of testing grounds. In other words, we need to bring a dev wiki online for 'experimental' development. This way, our creativity creates less chaos, and the general public won't have an opportunity to run rampant with something that is not necessarily needed or finalized. I also want to see what we can accomplish using behind the scenes style sheets before we go building look/feel templates that could either become obsolete or incompatible with any future skin alterations.

Not sure specifically what you mean. Nexus uses IPB as we do, and "My Content" is available from the forums under your user profile menu just as it is here. I also still see the mod tracker is active. I guess I am not familiar with the functionality of which you speak.

The desktop interface in Win 7 is probably still the most prominently used desktop OS. Win 10 cannot be the default, since it has not yet been released to the general market. Win 8.1 is MS's 'default', but I doubt it is more prevalent in the market, particularly in business. What MS wants, MS doesn't necessarily determine and definitely not for me. Easy for you to say if you are indeed new to computer use. Try using a desktop platform and workflow for twenty years and have all of your methods squished by an interface-layout overhaul that masks all of the most important administrative doorways into your OS. It is all still there, but accessing it is more cumbersome for those of us that have developed very efficient workflows within a traditional desktop env (Linux, mac, and Windows all have had a similar desktop interface for the past 20+ years). Change is good, but only when it is better. Metro is a marketing/branding change and is largely useless to many/most PC users, albeit convenient for MS. Actually, it is a pure branding move as well as an attempt to make their mobile OS/apps more relevant. It has the secondary, serendipitous effect of creating consistency across platforms. I would say that a huge chunk (?most?) of traditional windows users hate the new move. Even Googling Metro "love' brings up this Reddit.

Wiki is definitely more flexible, since anyone can edit, and crafty people can subvert certain standards. What we can do is protect pages and discourage certain behaviors, but there is always a degree of flexibility that cannot be constrained. We are just making it very easy to maintain these deviations by having the CSS extension and creating certain templates.

Try to grasp the idea of a 'flexible' standard. This confers a degree of freedom with constraint. See your own examples on the Nexus ... they all have same layout and fonts and styles. Only color theme and backgroud images differ, and those differences are the 'allowable' differences dictated by the flexible standard. (and as you say, this is not a problem, because Nexus main site is not a wiki, and ONLY the design team can edit and thereby dictate color themes and background images). The entire Nexus site conforms to a common look/feel standard. The Nexus main site has the one you refer to, the Nexus wiki has another, and the Nexus forums yet another. None of them change based on supported game (aside from color and background image). All elements have identical spatial parameters, widgets, buttons, etc. All behavior is consistent. That is what we want for this site. It requires definition of the flexible standard (which we have yet to finalize).

On user pages, that is fine, but not on pages supported by the site (e.g., user-created guides that we support in the forums). We need to define a flexible standard for those. Customizing any of the elements above subverts the site look/feel. The only exception would be Neo's guide. That one is grandfathered in, as Neo has been with us from the beginning, as has his guide, essentially. All other user guides are relatively recent. We'll be open to input regarding the flexible standards though. We just need to set a baseline for consistency and discourage gross deviation from that.

I can see that ... I did not examine this one closely ... what about adding code to remove underlines from links within these cols as we do in the INI Settings entry pages?