z929669

You could set it all up under Linux (pick a distro you prefer, or try something like Ubuntu or Linux Mint or Fedora. Alternatively, you could set up the wiki under Windows. The main thing for you is establishing a functional dev wiki as a playground, so you don't really need to set up a server per se. All of the installation and setup instructions should be documented on MediaWiki with even more info on other sites. You may just want to wait for the dedicated dev wiki though, as that will spare you a lot of time on a whole other project. It should be up in the next couple of weeks or so.

looks like it helps to manage assets amongst all kinds of hosting services ... interesting enough to try out ...

Maybe the symlink tweaks you made are haunting you with this issue ... ?

Yes, it could be drivers themselves. There are so many things it could be. Try updating to latest drivers or even previous versions. You may need to go over all of your settings again though, because certain settings may not have same impact with your new card. you should probably post your system specs so that others with like setup or hardware knowledge can help. Tech has had a lot of XP with AA stuff.

Using this site for image hosting for more than limited wiki use would not be good, as we are limited on disk space. This would be the ideal solution though. the main concern regarding these image-hosting services has become more about longevity of the assets on the hosting site. Many delete all of your files after a relatively short expiration date. Better to use Google Drive, DropBox or other services that do not have asset expiration. Does ShareX have any doc expiration? I would assume so, but one never knows without reading the fine print.

Wierd AA stuff is likely due to basic setting issues. Ensure that you have all (no more, no less) INI/launcher/driver settings as explained in the guide. Main areas of interest are ENBoost INI settings, skyrimprefs.ini and NVIDIA/AMD driver settings. Others may have more specific answers, as i have never had cause to investigate AA issues. Also, you got some kudos on your vids ;)

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).