z929669

Call to volunteers to help update the WB guide to account for LOOT and WB updates for Skyrim. Most of the info I included in the current guide pertains to WB setup and mod package org and Installers Tab (my favorite aspect of WB, contrary to popular opinion about Bashed patching ... which is also great, but not as great, IMO ... especially for Skyrim). I just need content editors to add content. i will continue to manage look/feel/flow of this and other site guides. just no time to delve into WB changes and changes to other related tools in order to update the guide. Likewise, the coverage of the Mods, INIs and Saves Tabs are slim to nonexistent. Anyone/everyone: EDIT AWAY PLEASE!

Thanks to alt3rn1ty and Sharlikran for responding to the WB support questions. We appreciate the expertise, as I and other local WB aficionados have been out of the loop for months now. EDIT: Now, if I could just get some help updating the WB guide ... ;)

Py errors via WB are most often caused by lack of proper Windows registry entries for Skyrim (LOOT requires, and WB may or may not). Try launching Skyrim via the Steam launcher ... no necessary to "play game" ... just run the launcher directly from Steam (not SKSE or via MO) once and let it set reg entries and produce the INIs in the default location. see if that resolves. EDIT: Carnage's error above is different and discussed in adjacent forum.

Did you ever edit your Bash.ini? I would check there first for that string. Also, you might check the WB files under %USERPROFILE%\Documents\My Games\Skyrim\ ... similarly, check under %APPDATA%\Skyrim (I think) ... I am not on my home box, so all of these paths are from memory. What I do know, is that when launching WB via MO, WB thinks it sees /Data/. ... but I have never investigated where it gets its own meta info when run under MO (I assume the MO profiles contain this).

Nobody around here (that I know of) is accomplished with Py code ... I know a bit and even have some reference manuals, but although I have wanted to learn Python for a long time, I never got further along than the basics. The Wrye Bash code is very complicated and has a lot of code contributed by different programmers, so it is really tough to peruse even for an accomplished Py programmer. The only really accomplished Py programmer I know is Tannin, and he is not interested in working on WB for obvious reasons. stoppingby4now is an accomplished Perl programmer, which means he can do some Python, but he has little time to spare outside of what he does around here (he is our Unix guru and site developer). I will happily test though as I can spare the time (long-time WB user here) and post on your thread if I get into the mix. I encourage others to do the same. EDIT: for now, I pinned your dev thread to give it a bit more exposure ;)

@Sharlikran Feel free to post your links to Wrye Flash (or whatever you can't host on the Nexus) on this thread or PM them to me, and we can add these as "mod pages" within our system, which will provide basic metadata about the mod(s), including download links (to your assets on DropBox or OneDrive or whatever). I know DropBox provide a public link (in Public folder only) that allows seamless download of the file directly, but some other services only provide a link to the web page and then another click to download the file ... not sure what OneDrive does.

You are using a wiki-type link here ... is this a typo? Trying to trace where you are passing the URL EDIT: Nevermind, I see what you are doing now ... I tried to experiment with square brackets called via template, but that was useless. Then I tried using the HTML char codes, which is closer, but it does not get parsed correctly as wiki markup. The answer lies along these paths though, I suppose (if solvable). You may want to try either using the template forms of L/R square brackets that I just created or the char codes in your template or try magic words. ...s4n? Anyway, I see a question mark in the URL. This can be problematic (along with other special characters when passed as HTML ... I think). Anyway, I am not privy to correct terminology as to what/why certain chars do not work in certain situations (s4n can explain it), but I have learned to resolve using magic words on an ad-hoc basis. Look at magic words help and see in particular the section on URL data. This has helped me to resolve certain URL issues when passed through templates in our implementation.

That template was created by Farlo and copied from the GuildWars wiki ... He was the only one of us that really had experience as a wiki editor before we launched this site. Much of what he developed, he grabbed from GW or MW, and he was the first person interested in SMW. S4n built most of our current SMW, since he picked it up faster than the rest of us, but Farlo's wiki skills were good enough to help him figure out how to use s4n's stuff to build the current beta Pack structure. I am still only an apprentice to these journeymen ;)

@hishutup Actually, I don't want to drive a wedge into your creativity ... just had scary thoughts that we would have some guide downtime or other funky stuff going on that would require one of us going in and running maintenance tasks to fix stuff. Your work probably is not going to adversely affect anything else as long as you don't accidentally use any Properties that we already have in place (you can see what is currently in use in SpecialPages). Just keep learning as you see fit. It is not easy to work with and debugging SMW, since there are lots of moving parts (especially on the prod wiki). @s4n Yeah, a dev wiki at least would provide a clean slate and debugging SMW code would probably be much simpler. The dev wiki would probably also be more responsive Semantically speaking. Maybe you could throw up a dev wiki env with latest MW/SMW software when you do the site update? I can flesh out a Portal with some "getting started" info if you do.

Again ... I REALLY think we should be setting up a separate dev wiki entirely before hishutup experiments too much more ... Too much to break and interfere with. It whould be OK if done in such a way as to not cross-contaminate existing SMW structures, but that is always a possibility when one is developing on the live wiki and using existing SMW structures as a starting point. @hishutup You can always install MW inside a VM on your local machine and practice in that sandbox. This is what s4n and I have been doing for awhile now. At least until we get a dev wiki instance up.

For those installing STEP and following the instructions, all meta rules will have been established. Adding rules on their own page creates a sync task that can easily be overlooked. The wiki has search, so try that. We will be updating how this is all handled in next release (no ETA) @hishutup The LOOT template is not connected to any Semantic Property, but we will hook it to SMW in some way once we update.

Forgot we could set that. Best answer is separate dev wiki. Having to rebuild the SMW data frequently is a bad thing on the prod site, and that along with your con above is all the reason we need.

Then moving Templates related to SMW doesn't seem necessary if related Form and Properties still reside in their own namespaces. Makes sense to let the relevant Templates reside in the native namespace in relation to all constructs other than pages that are built using them ... those could more neatly reside under Dev namespace. However, these dev 'source' and 'sink' pages cannot really be quarantined effectively unless they all can reside under the Dev: namespace. Makes more sense to launch an entirely different dev wiki under its own subdomain, which we really should do anyway so that users like hishutup (and us) can go crazy without any worry about breaking or confounding anything.

@s4n I agree with you ... just thinking of how to implement more quickly, since I was not sure about an ETA on a Pack/patch beta implementation (maybe use Dev namespace for testing once you have a working solution in your VM?). Like Patch-specific mod attributes, IsCore and Merged should also move to their respective parent objects. I would much rather define IsCore in one list than have to load up each mod page for those edits. Furthermore, we now have a situation where it is easy to forget to untick IsCore if we remove a mod from the guide, leaving a mess that will 'dirty' the data. Much better to define the mod list at the Pack/patch levels by coupling to the ModTableList Template (or likewise), especially since we are moving all non Core mods out of the main Guide in 2.3.0

So {{User:MyTemplate}} calls a template I set up on [[user:MyTemplate]]? Is same true for Forms and properties?

After editing the guide or any SMW-dependent page, it is always a good idea to use the REFRESH option under PAGE TOOLS ... intuitively, saving should do the same, but saving does not invoke refresh of SMW data, IIRC.

To use Dev: , simply move all of your dev pages from, say, "MyPage" to, "Dev:MyPage". Forms/Templates/Properties will need to stay in their own namespace, but all of the content created using them can land in Dev:. namespace

The ENB guide is not supposed to be 100% consistent with the STEP guide ... it just provides more info. Follow STEP, and use the other guide info to tweak your game and experiment after verifying a 'good' STEP build.

First off ... @s4n we have a Dev namespace, so why are we not using that? Secondly ... @hushutup You are trying to implement something fairly complex using several properties and functions (e.g., debugging your #switch function is only one small piece ... there seems to be a redundant pipe at the end). As I stated previously, it is much, much, much simpler to begin with something very, very simple and build upon that. First, clearly define your ultimate goal and what you want the SMW structure to accomplish. This will help us to determine first if what you want to do is even feasible, and it will allow us to help more if we see where you are trying to go. Consistent with what you envision, pick one property that you want to actually use. Then create a stupid-simple template that uses that property (nothing fancy, just a very simple template). Then create a stupid-simple form to feed that template. Then you verify that it works and debug as necessary (which will be pretty easy and instructive). This sets up the base structure you will be working with ... Property page, Template page, Form page. Then begin adding in components one at a time, debugging each in turn before adding another layer of complexity. (components = any changes made by adding in elements like parserfunctions, new properties/fields, styles, etc.) The way you seem to be going about it is by scavenging examples that you think apply to what you are trying to accomplish (which is not all that clear yet and why I mentioned that it would be helpful if you corrected your template to conform to standards ... which in turn may not be applicable, since it is a SMW template). Nevertheless, I think you are trying to jump into calculus before learning anything about algebra and trigonometry. Start small and build up, debugging along the way. You will learn loads of things this way, and the help you will require will be more easily framed and addressed ... and you will require less help I think. The process takes time though, but if you are willing, we need more SMW developers. EDIT: RE you last post: You are getting back exactly what you asked for ... a link and a title (with an extra square bracket, bc you have one too many on the outside).

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.