z929669

should be resolved now. Once we begin using the new Pack wiki setup for 2.3.0 (defer to s4n on ETA), I will add mod categories to tags.

I'll fix when I have some time Thanks for pointing it out

I have not looked at the new combined version of SP's mods yet, but I am hoping that he included a FOMOD with all options addressing each of the individual mods (some of those would have sub-options). If that is the case, just install the main options as if they were the stand-alone mods and hide individual files accordingly. STEP does not use all of SP's mods, so you will need to be selective for STEP. It could be easy, and it could be painful. Tough to say until we assess. (no ETA)

Just to close the loop on DDF (to use or not to use), begin reading the thread on this very topic right here ... several subsequent posts establish that the issue is with vanilla and not DDF. DDF simply applied the decal fix without fixing other mesh problems related to vanilla lighting. USKP decal fixes apply both fixes (we assume). DDF fixes are still a "step up" from the originals, and since USKP will never address the 20 meshes in question, DDF remains a relevant fix. Evidence as to relevance of DDF is in this post if Tech would re-source his image links (assets hosted by Imgur expire after a month or so, so don't use Imgur!)

I thought CQLA was created: to fix the "floating quiver problem" - Does this mod also resolve this issue?to be compatible with "Proper Length Arrows" mod, because drawing vanilla arrows pulled the arrow head into the notch/hand area (i.e., too short) - Does this mod fix that issue?I always thought many of the vanilla meshes were too 'fat' and 'short' and generally cumbersome (aside from floating in the air behind the body), and CQLA fixed those issues for me. I also like the lower-riding quivers of CQLA, and long arrows are more accurate, IMO. They look too long because some quivers are too short. That said, the textures work better on the BSW meshes, and BSW is closer to vanilla. Last question: Does one or the other of these contenders work better with other mods like DSR, or are they both completely independent of such mods? If no difference in terms of clipping and mod compat, BSW is better for STEP.

Thanks for taking care of that ;)

Just making the note for posterity and not intending that you provide those details. This subject has come up over and over though, and I am hoping that the issue with DDF can be resolved with the help of onlookers ;)

I would need to change the 'anonymous' template calls to 'named' template calls. See this post for details on how to fix. I will look at implementing a fix when I have time if DY or one of you guys does not beat me to it. The easy part is fixing the template, but the hard part is updating all of the template calls. Alternatively, you might be able to figure out a way to get a short URL that is permanent.

@hishutup You seem technically proficient ... setting up a VM is really very simple. Create a VM with VirtualBox and install CentOS. It is configuring the server that is more challenging. As s4n says though, there should be many images fully configured with Mediawiki on Linux that you can use. It does not really matter what Linux flavor and stack you use, as you are interested in MW dev, which will not care. If you were testing primarily for software compatibility, that would be different, but s4n has that covered (and I as his backup). On the other hand, getting the dev wiki up and running would be a big win in the short term, and it should be relatively simple to implement ... unless s4n is wanting to implement memcached and other software upgrades first, which is probably the case.

DDF includes about 20 assets not covered by the USKP (I think), whether or not this is a noticeable difference in game depends on the person, I suppose. Since these really are fixes, it makes sense that they be included, regardless of the technically 'incorrect' statement made in the USKP release notes. If anyone can demonstrate that any of these 20 or so DDF fixes botch downstream compatibility in terms of the USP or other well-known mods, that is another story. However, I think it is pertinent that the USP team modifies their notes to reflect reality, whatever it may be, as if their statement about DDF being obsolete (implies 100% redundancy), then the statement is misinformation and should be elaborated upon (e.g., "DDF is largely redundant", "not recommended for ", etc.). I remember a PM I had going with Arthmoor where he mentioned something about mesh issues that DDF did not address properly (or that it was not implemented in accordance with the Quarn standard), but I sensed more that the USP team was playing it safe rather than providing evidence to confirm that DDF implemented the fixes in a non-standard fashion. If you would care to provide the needed details, i would be happy to revise our recommendations and drop that mod. In the meantime, I will add a note about the install order. ... no disrespect to the USP team, of course; however, regardless of reputation, I think that they would agree that taking the word of any source as fact without evidence (when there is factual contention already present) is not advisable ... same goes for STEP. We recommend using DDF, USKP recommends not, and neither of us are providing the facts needed to come to a consensus on this one

1. both 2. last one (or the first if it is more intuitive) You did corectly by using the "what links here" speacial link, but you should also be able to find references to all pages with loot rules using a search term for the template text to prove to yourself that this is complete: {{Loot Rule| This all assumes that we have correctly added all pertinent loot rules already, which may need to be verified if any rules were missed or if LOOT updated their rules in the interim of our adding them. I edited your user page with a note. Also, I am not sure why we are not using the LOOT rule template on the BP page. Maybe I am missing something about limitations of the template though ... but I would use it if possible, so that all references to LOOT rules are visually distinctive and consistent (and they would also all point to the loot instructions).

Normals are normally done with lossless, yes, but most (except really smooth ones at char level that you can get very close to in game), but 565 is Ethatron's custom algorithm that reduces size by one third with no detectable quality loss and technically retaining the uncompressed format. IMO, all uncompressed normals (with few exceptions) should be treated with 565.

I am finally getting good at using the combat system, which is highly complex. Add in the effects of crafting add-ons, passive skills, and accessories, and it gets super-duper complex. Lots of stacking/optimization options that are difficult to manage. I spend 4 hours last night just re-assigning skills and equipment for all characters interspersed with performing actions in the War Room. I have still barely scratched the surface of the game and plotlines. I have little knowledge of the historic lore, as well, so not really sure about the meaning/significance/context of 'Warden'.

He will say, yes' I'm sure, but best to wait. Is City Bump in that? Have you had a chance to install it? First thing I would want to do is convert all uncompressed to 565 'conservative' lossy uncompressed format, if it was created same way as Terrain Bump (i.e., standard uncompressed format).

Good call, thanks for keeping on this ;)

I only use a 1k upper-limit cap (Performance version only) and did not reduce anything under that ... only compression and mip-map opt. There is no major decrease in VRAM with my versions either. The Standard version actually does not reduce VRAM at all in many situations in-game. It's more about optimization for quality (mip-maps) as much as performance (resolution caps and reduced uncompressed formats [R5G6B5/A4R4G4B4] wherever possible).

It's about time this topic was pinned since alt3rn1ty has put so much time into supporting this project and has also been kind enough to update this thread consistently. THANK YOU

Use a Droplet on DigitalOcean?

No problem! I don't doubt you ;)

Good point. I just bumped you to Step/Pack-author groups, which should give you access to most of what has been barred from you recently.

I never played any of the DA series, but I have read that the 3rd ed is more like the gameplay of the 1st, if that helps to convince. I will easily get 200 hours of gameplay out of it the way I play RPGs (uncover every little thing and follow all the little shinnies). Witcher 3 will be next for me.

Keep it up and I will make you a wiki admin very soon (just as long as you know what dials not to touch ;) ). Fixed that last one.

I think a script has the potential to flag exceptions that can then be addressed by hand ... to add missing handlers to the script for improving the script ;) I would never do anything by hand unless I would never-ever have to repeat the task and unless it would not require significantly more time than writing up a scripted routine to handle it.

I am updating with those and other corrections now. For future reference, we edit the source code from STEP:Main and propagate to the Nexus from there. EDIT: Propagated 2.2.9.1 Nexus source and email (please don't re-propagate ... just edit the 2.2.9.1 soucre using the main links rather than the "edit/create" links. Source is completely synced with Nexus, including corrections to typos

I agree with the hotfixes. Uploading those files was a PITA, and downloading is as well, I'm sure. We can add a plugin loader with any hotfixes. Also, no need to even use TESEdit to make the dummy ... just rename a copy of Mopy\templates\Skyrim\Blank, Skyrim.esp ... also agree on placement in list order.