z929669

OK, sounds good ... I trust you know best how to make SMW dev on the dev wiki as painless as possible, since you must be very familiar with the issue ;)

@Tech Pleasure! @Kelmych Glad you noticed ... I tried to make it pretty obvious and provide info to rectifying. @all I have finished these template updates and (I think) I fixed all outstanding issues of 'bad' template calls. We might consider likewise modifying any templates that could ever hold an '=' symbol Example (see second 'Notice') as text or in a URL. I tackled these templates, since they are used commonly.

My thinking was that if the default enblocal.ini sets the following as default: [ENGINE] ForceAnisotropicFiltering=true MaxAnisotropy=16... then any guide that mentions using driver-side for AF, will need to mention reverting those two edits ... perhaps it is just the ATI CCC guide?

Caching is a problem because it is a real barrier to getting immediate feedback to SMW tweaks ... so you can develop on top of a mistake before realizing it or even perform a bogus 'fix' before realizing it ... either way, you are hard-pressed to develop or debug efficiently unless you never make any mistakes. I am an intuitive thinker, so I develop everything (in SMW and other syntactical languages) with a great deal of "tweak > view" iterations, attenuating on the correct solution, given the feedback of such a process. I am sure everybody does this to more or lesser degree.

FYI to all wiki editors: I am in the process of tweaking our notification templates to be more accepting of '=' signs within the template custom text. Some may have noticed that certain URLs or INI setting calls would break these templates (uncommon, but very annoying). This was due to these templates relying on "anonymous" parameter calls. I altered them to use "named" parameter calls and also added some better handling for border calls and defaults as well as error notifications when the params are called incorrectly. (see second note) What this means is that all of the affected pages need to be updated accordingly. I am taking care of it, but I could always miss something. Just keep in mind that these templates need to be called in a slightly different manner ... those of you that forget this, will be presented with an obvious visual cue and a link to the new usage examples. I finished with the 'Small' versions and will tackle the bigger ones in the days ahead.

This will also impact the ENB guides (all of them I think), so I will take a look more carefully when I have some time. @s4n Thanks for clarifying that PAGE TOOLS > REFRESH should be used sparingly, and only when updating SMW components of the STEP Guide and Packs for the most part.

Trust me when I tell you that even the person that writes it will forget much of what they did a month later and thereby have to relearn it all again ;) ... it will come back to that person more quickly though. Writing SMW this way is definitely convoluted and testing the limits of the intended scope of SMW. Caching does not make dev any easier either! @s4n Once we set up the dev wiki, I think in the config, we should DISABLE caching of all kinds ... grrr. ... and set up some simple scripts that can be executed to keep things clean and facilitate dev/debugging.

Precisely because of the question posed just now ... if we provide only the settings we are asking users to change, then we need to define the INI that is expected (the default for a given release). This is the problem with only referencing certain tweaks ... we need to at least have some baseline. Doh! Sorry, was looking at wrong section ... [ANTIALIASING] :facepalm:

As I said in my last note, I just checked the archive for 265, and it is disabled. The archive looks just like it does in the link I provided above

Not true. The default INI ships just like the extended enblocal INI guide > shows

Speaking of which ... @Tech It would be great to get those boilerplate images replaced with something relevant ... are you doing this work yourself still or are you taking any volunteers? If the latter, you may want to fish for volunteers with specifications on testing parameters.

I think he is talking about Property:TES4Mod_Guide and using ... {{#ask: [[PropertyName::PropertyValue]]}}... to call the list rather than Template calls. I have not been following along with your work so this is just a hunch based on a 15-minute review ... and I don't follow really, but you have something functional.

@s4n What's the status of the wiki update and the dev wiki implementation?

totally agree :P

"Current relationships" meaning "understand the Data Dictionary" and the relationships among the SMW components implemented on our wiki. Even I do not fully understand it all, but I do understand the relationships and what actions could break the structure. Actually, only s4n and me have the ability to delete pages from the wiki, Step Staff may also be able to delete pages, but they can't delete protected pages (I don't think) ... i am not in a position to look at the configuration right now, and I forget the specifics.

Yes, nothing is ever permanently deleted unless wiped from the DB tables. Glad hard refresh did the trick. If you have the options, try PAGE TOOLS > REFRESH to do the same for anything related to SMW ... it is like a hard refresh + a SMW refresh.

... or perceive new entities welcome to all newcomers

Glad you guys got this figured out :) Just to get one last word in on the OT bit I rudely started previously ... All true, but with more than five or so decent records for a given issue, a rough pattern could emerge ... not to mention other interesting things coming from tying certain issues to certain hardware. As the sample of records increases for a given issue, we are likely to learn something interesting. One thing that is certain: we won't learn anything without capturing the relationship (well, those of us without "total recall" anyway ;) ) I would love a database on GPU:issue data relating to some specific issues relevant on these forums ... probably a bit of a lofty goal, but .......

I would prefer maintaining a minimum of 30 FPS and bumping all of my shadows and detail settings to max (which is what I do). 30+ FPS runs nicely, IMO.

I am finished with my edits to the guide: Removed redundant information that already exists elsewhere on the wiki:Offloaded ENBoost quickstart to the mod page and replaced with brief description and link to mod pageOffloaded all enblocal.ini section/parameter descriptions into their own subguide (same as ENBseries INI subguide)Removed most of the INI-section/parameter descriptions due to redundancy with ENBseries INI subguideReorganized some of the chapter hierarcies and headingsReformatted applicable path strings to use HTML tagsResized a few images and removed others that seemed totally redundant.Regarding redundant info duplicated throughout the wiki: It is best to either link to a single source from ancillary doc or create a template to hold information that we think should be reproduced in more than a single location. The problem is that one location will be updated, but the other will not, which leads to conflicting info (=bad). Better to manage in a single place, as it reduces potential for error and significantly reduces the maintenance burden. Some existing elements are already reproduced in various locations (e.g., Skyrim INI settings, GPU driver settings, others). EDIT: There may be an extension to handle centralizing text snippets from normal pages to be transcluded into other pages for reuse: Labeled Section Transclusion

Sounds like a caching issue ... did you hard refresh? What is the page location for the source image and the page location where you are trying to call it?

STEP does not recommend ENB, so any shadow-striping issues will need to be addressed without ENB. I am installing STEP:Core for the thousandth time now, so I will see if I get striping or not and come up with a solution if Tech et al do not have a solution already.

Nevertheless, that really looks like the FloatPointRenderTarget issue ... Are you running MO? If so, are you editing the right ini (i.e., in Profile rather than the main INIs)?

Yes, we will use this. Thanks for the notification ... I have not touched that guide yet, so it will be awhile before I get to it ;)

We could also start looking at the user system specs and recording the info that way ... or we could even associate "known bugs" toggles with video cards and capture Semantically once the member enters their system specs into the wiki.