z929669

Yes, we suggest disabling AF in ENB (for AMD cards only) and using the AMD CCC driver to implement. If anyone would not mind testing using driver AF versus ENB AF (mutually exclusively) and post back if you see (or do not see) a marginal FPS increase either way, that would be much appreciated ;)

Nope, keep going, just consider the image issue at some point ;) ... back on track: did you try the keyboard shortcut I mentioned to give you the HTML/CSS element properties of interest?

Copy does not work, because it lacks file-type identifiers in its links. DropBox works fine ... just place your images into your 'Public' folder. Use the local application downloaded from their site via Windows Explorer context menu and copy link from that. Google Drive also works fine as Tech tells it.

Hmm, that should be corrected. The image is wrong and I will update it this week sometime. It doesn't matter much though. I got 1-2 FPS boost in several trials under both settings. AMD drivers delivered identical quality with a slight gain in performance on my setup. That is only suggestive in relation to other setups.

Well, it is arguably a Pack-specific Mod attribute that naturally fits at the mod level with respect to its applications like IsCore and Merged. More importantly, these attributes relate to STEP, so there is relevance in creating these as mod attributes. The alternative would be to include mod flags using a mod list name query that would also need to be manually maintained using some other attribute or by explicitly defining the mod list at the Patch/Pack level. I can see the performance/logic rationale for using the relatively small Patch/Pack 'table' to store this info than the much larger Mod 'table'. It just seems more intuitive and simple to implement this as a mod attribute, else we can just move all three of those properties to the upcoming Pack/(Plugin?) revised template(s). A fast solution is to just use the current structure ... your call though if you want to develop that real quick ;) Main question is how to store the info at the mod level ... two binary or one text property(s)?

If you were so kind as to add the necessary info, I'll mess with it .. and create your flags (you can query using the Booleans or the strings the same way, so I guess I would rather use one property to hold the 'requirement' info). I'll give s4n a chance to respond first though, as he may have ideas about all of this.

Very good point that I hadn't even considered ... That is problematic for 100% of users rather than a mere 1% of users.

If you are posting in a manner that is difficult to follow, I will call you and anybody on it in the open forums. It is instructive to others that might do the same. The key is: don't 'try' reading your own posts ... 'succeed' at it That said, I will be more careful about that if you do the same ;) puu.sh is fine for you guys to use if you really like it, but it is blacklisted for a reason, and you should be aware that some users will never see your content unless they know how to fix it by editing their hosts file (if they even want to 'fix' it). I don't see how it is any more convenient than DropBox, Google Drive, Imgur or any number of alternatives though, but just an 'FYI' ... ... oh, and I think you are "worth the time", so that is why I spend much of my time responding to your posts and answering your questions when I understand them. You have a lot of drive and we need more like you, so please try not to let me offend you ;)

What yellow and green text??? I have no clue as to the context. If you go into edit any page on the wiki, it will link to any template pages used by that page (see bottom of the edit page). This way you can navigate to the pages that describe the elements of interest. Could you stop using https://puu.sh for hosting images? That site is blacklisted by many anti-maleware services that provide hosts file. Many using a configured hosts file will never see your images. Use Dropbox, or any number of other 'safer' services for that. Doesn't Puush offer this domain name instead? Also, please stop using your mobile for any serious posting. The typos and autocorrections are very obvious, and many of your posts are difficult to follow because of that. Alternatively, be very careful and dilligent when posting from your mobile ... no convenience posting please ... it is inconvenient for everyone else and should be addressed within our Citizenship guide ... grrr (will add NOW)

I would suggest a string tag like: "STEPPatchReq" With arguments like: "Extended", "Core", "All" and "None" Alternatively, we could use two properties as you suggest. Let's see what s4n prefers. Also, keep in mind that there is a "IsMerged" attribute for all mod pages ... are you using that (see this example)?

... too much cactus juice?

Class# are templates because they are dependent upon the Form with same name, so actually calling then Form# would also have been confusing, so Class# is actually more generic and appropriate. Forms and associated Templates need not use the same nomenclature, but it is good practice to do so, because it provides a visual association. I actually like the "Create a Class" tool, because it does create the Property pages and formats for you, which is much simpler than doing the same by navigation. It works nicely for setting up a basic SMW 'class' structure. What it does not do is format the Form nicely or give you other SMW structures that you may need, and you would still need to go in and edit everything to your liking ... good for initial creation if you know exactly what you want and it is simple. What image? You can look at the HTML element names by hitting Ctrl+Shift+i in your web browser to bring up Inspector (Chrome and Firefox), or you can use Stylish plugin for Firefox. What about forum pages? I though we were discussing wiki pages? You are not ready for deletion rights until you have a good understanding of how our current relationships work ... only s4n and I and Farlo can do that.

... also, it would be good to distinguish actual patch-required mods from mods that are implemented fully by the patches. Secondly, we should state something about not all STEP mods being requirements for the STEP patches and just list those that are required and that the others are not necessary for the patches (but some mods may have interdependencies unrelated to the patches, which should be conveyed explicitly on the respective mods' pages as I have done for the LOOT recommendations for certain mods)

Agree, we don't want to support modular patches and all of the maintenance required to keep them relevant. One patch for STEP:Core and another for STEP:Extended is all that is needed, since that is all we officially support here. If SRB wants to maintain any "Combined Plugin" patches that do not expect a strict STEP installation, then that is fine; however, we only officially support Legendary Ed and STEP:Core/Extended, so the combined options are above and beyond our mandate, and I would consider dropping them entirely and asking Pack authors to maintain their own versions. I would rather not support use of WB instructions as part of our guide for installing variations of STEP. We should continue providing only STEP:Core/Extended patches exclusively for strict STEP and provide an ancillary guide as part of the WB Guide (or the TESEdit Guide) to allow users and Pack authors to create and maintain their own custom patches if they so desire.

I have to admit that "Choosing the Correct Plugin" section on the mod page instructions does pretty explicitly describe how to use the patches ... so any advice on how that might be unclear and how to fix would be helpful. @SRB There is another recent example relating to this that should be addressed, too.

Actually, creating the "Semantic Class" using the Special Page is instructive and 'correct' for creating a basic SMW structure associating, say, Authors/books or composers/music and the like (including publisher info, locations, and other relevant metadata); however, as s4n said, there are more sophisticated ways to go about it ... it is important to remember that he built our structure somewhat outside of the 'box', and our implementation is not typical or simple and arguably deviates somewhat from the intended use of SMW. Take my advice and learn the intended methodology using the tools SMW provides out of the box. This is very instructive in teaching the basics through example. ... BTW, Form:Classx probably should have been renamed to Form:Formx for clarity and consistency. Changing an SMW structure after the fact IS challenging (and that is one of the lessons you will learn by going through the exercise using the built-in tools and related methods).

The instructions and description needs more than just that. That would have saved you trouble, but others will surely be uncertain how to use the "Combined Plugins" without more generalized and explicit instructions. You made a good point, but I just did not like the way you made it in the other thread and an surprised you did not post before you completed the guide setup ;) EDIT: ... @SRB, that sounds great ... if you also include more explicit instructions on the mod page itself (or here on this thread), I will assist.

Discussion thread: Bashed Patch by EVERYONE! Wiki Link Finally creating a thread for this topic as it relates to STEP

Discussion of the STEP Patches need sto take place on the relevant thread.

The STEP Patches documentation could use improvement, particularly with regard to the STEP Combined Plugins The doc needs to inform users of the purpose and requirements of each plugin distinctly right up front. This seems to have been done for the main plugin: ... but why not for the HF version? Admittedly, it takes a bit of effort to determine how to use these plugins, and there is definitely uncertainty remaining after reading the doc. Detailed change log is great for those that understand that level of detail, but there is nothing describing (in explicit terms) the main points of how to use the plugins. Although annoying, this user does have a minor point. EDIT: The STEP Patches are distinct from the STEP Compat Plugins in both form and function, so the latter either deserve their own mod page, or they should be very obviously called out as having a different purpose than the STEP Patches and are to be used by more advanced modders.

Wow ... why are you assuming to understand what the STEP Patches do at the very beginning of the guide unless you have read through their doc? We created the guide for users to install STEP:Core, so that is the blatant requirement. The guide details how to install either STEP:Core or STEP:Extended with detailed instructions from start to finish. If you fail to install all of STEP:Core or STEP:Extended, then obviously you are deviating from expectations, and it is on YOU to look ahead and investigate the requirements of the STEP Patches, which are well documented. Each mod down the list also includes links to detailed instructions for every mod that does not have 'simple' instructions. Each mod page lists any particular dependencies and LOOT instructions, and assumes that users are following the guide start to finish. The STEP Patches are described in great detail if you follow the links and read.What is the "Combined HF patch" ... if you mean "STEP Combined PluginHF.esp", then it is described in the STEP Patches pages. Perhaps EssArrBee could upgrade the instructions to include more explicit detail, but if you do not understand something, then post about it so that we can correct it rather than continue on with your 'assumptions'. I agree that more explicit description is needed for "STEP Combined PluginHF.esp", especially since "STEP Combined Plugin.esp" is explicitly detailed. If you are having trouble, it's because you did not actually read through and follow the guide start to finish. We make it relatively simple for newbies to mod Skyrim, and those that do not follow the guide strictly ought to know what they are doing, else they are going to run into trouble. Follow the guide ... read. Otherwise, just scrap STEP and try modding your own game yourself (and get even more frustrated). We have brought all of the info necessary to mod Skyrim all in one place, so you only have yourself to blame if you fail to follow the instructions.

Yes, do create your own Category. Or you can use whatever Categories are associated with the examples above ... without looking, my guess is "Category1" and "Category2" are safe bets ;) Also, have you begun digging into the documentation at SMW? If not, you should read up on all of that, but particularly SMW base and SMW Forms. You can find the links to relevant doc in Special:Version

Even if only you will use it, we have the standard set so that others can follow along and understand how to use any template with confidence that they are all created and documented in a manner that is easy to predict. Consistency is good. Also, if you are the only person that plans on using it, that will no longer be the case since you did create this thread, which advertizes it somewhat, so expect that others will be interested. If you want a very basic rundown of how it all works, take a look at all Properties, Templates and Forms associated with Class1 and Class2, which are simple examples that I created when learning for myself how it was all supposed to work. This will be much simpler than trying to understand what s4n developed and all of our production SMW examples. https://wiki.step-project.com/Form:Class1https://wiki.step-project.com/Form:Class2https://wiki.step-project.com/Template:Class1https://wiki.step-project.com/Template:Class1https://wiki.step-project.com/Property:Property1https://wiki.step-project.com/Property:Property2https://wiki.step-project.com/Property:Property3https://wiki.step-project.com/Property:Property4Go ahead and create any pages you want using these forms, as they are only for mockup and learning purposes (just give your pages names that will not get confused with legit stuff (e.g., https://wiki.step-project.com/HishutupTest1 ... etc.).

Seems rather complex ... is using the template any harder than doing it by hand? It would help to assess if you followed the standard we have set for templates.

Correct