z929669

OK, will do ... thanks for this!

"Argonian tail twist fix" used to be a mod, but I think the USKP fixes the issue, so this goes back to proper setup of Steam/Skyrim/MO and proper installation of mods.

Video is great for some, but I prefer instructions in words ... is there a mod page for this or some other source for implementing with text instructions? If not, I will labor through the video ...

That is what I thought ... it seems like this one needs to develop further so that all windows are affected for the sake of consistency. There are also the transparency issues and other tweaks that the user community will invoke as the mod develops (if it even develops to completion)

How does this affect Visible Windows? Since this is only farmhouses, it seems premature. It might be best to see what all of the conflicts will entail to avoid complexities or evolving incompatibilities.

Fixed links in OP

All mountains get those normals, so you can look at the mountain just behind Windhelm while you are standing on the bridge if you want.

They were hidden because they were too bumpy ;) The icicles should be totally fixed and no zebra striping (that was the bumpiness effect). My bet is that they are totally fine now. Icicle replaces the vanilla HR normal, and mountains replace the Vanilla Mountains normals, which are probably better, since they should be uncompressed (the new TB mountains and icicle are DXT format now and are the only compressed textures in the package). I just don't have a solid block of time right now to test and get the screens.

I just ran it, and it has bugs with the mouse. It mostly works, but I lost my mouse momentarily when testing with Alt+Enter and Alt+Tab, but then I got it back. When I clicked inside my Skyrim window, the windows mouse changed to the two-headed resize Windows cursor overlaying my Skyrim crosshair. Alt+Tabbing a few times to refocus Skyrim back and forth with the windows mouse cursor reproduced this issue about 50% of the time. The Windows mouse cursor is definitely a little flickery and does not dependably transition. Finally, upon recapturing Skyrim and attempting to quit the game from windowed mode, I lost my cursor totally as Skyrim was closing and could not get it back. The windows mouse cursor was active but invisible. It would pop up on certain parts of my screen, but Windows locked up when I tried to restart using my invisible mouse cursor. Then my session froze and I had to force a restart. I rebooted from the 'dirty' reset and ran the original version after to be sure I wasn't imagining things (I wasn't). Note also that I did run both instances using their separate resources, and I noticed that the new version has an extra DLL. In other words, I am certain that I installed the correct files into their correct location for both versions without any conflicts (i.e., I did not muck it up ... there is some issue with the latest 'beta').

True. I did look at the textures though, and they are much reduced in the bumpiness area. It is true that they should first be tested, so I will make sure the wiki remains status quo. Can anybody look at the diffs in 2.2.9?

FYI (all contributors on this thread) We host a Murmur voice coms server here on STEP (Google Mumble client). It seems like some of you might benefit by jumping on and talking over --in real time-- some of what has been discussed on this thread (e.g., modular fx format ... great idea, BTW ... I love standardization!). This way, you all can arrive at a consensus much faster and clear up any previous miscommunications. The voice server is always up, and we use it occasionally, but there is plenty of room to host up to 20 connections at any given time. If any of you want to jump on and discuss some things and avoid typing, yada, yada, Tech or one of the STEP Staff or admins can provide connection details via PM (standard connection, Tech et al, no password please, as this is associated with elevated permissions). Our voice chat is standing by for these purposes. We have found it to be much more efficient than posting or text chatting ... and it is always nice to 'meet' people you know in the modding scene for the first time, as it enhances the collaborative spirit ;) I have done a lot of work with enbseries.ini as well, and I wish I could contribute more, but my time is way too scattered right now with site maintenance and RL to commit right now.

Sparrow may have removed it in his latest update. I will need to check against the versions I first uploaded. EDIT: No, all the files are there, including icicle_n.dds; however, the path was wrong ... fixed: textures\landscape\roads\icicle_n.dds to: textures\landscape\icicle_n.dds UPDATE: v1.4d actually has 'fixed' mountain and icicle normals (Sparrow must have noticed we were excluding them in STEP and understood that they were too bumpy). Therefore, the whole mod can be used now. Mod page updated on the wiki.

We are planning on doing just that ... yes, it is officially legal now to publicly share any altered Beth assets as long as credit is given to Beth. each mod author would need to authorize though

Please use the "marke solved" button when support questions are answered.

Thanks for providing this tool

that is my other problem with Headertabs. It forces large edits, and it is more tedious to navigate back to the point of interest after saving

I do really big edits in TextPad, otherwise, I try to edit pages by heading.

It certainly blocks the edit saver (me) from navigating the wiki though, even in another browser tab, and I would wager even a whole other browser. Try it. Just refresh the guide and try to navigate the wiki. EDIT: I just tried it, and it was way too fast for me to test anything It must be the time of day (night). It is never that fast in peak hours.

Packs? No, the STEP Guide. I don't even help with Packs. We are far too consumed with maintaining the site and testing mods for STEP (when I can). Most conflicts are texture conflicts, so nothing serious can happen with that other than a borked game asset. Then you just use Mfg Console to determine the source. You are a mod author and are looking to run a bunch of mods together in a single go it sounds like. I do it more slowly and repetitively I guess, one mod at a time. Just knowing the mod you are installing tells you most of what you need to look out for and what you don't want to be overridden. I am not saying the functionality you want is not reasonable ... I would really like to see it, actually. I am just saying that it is by no means essential, since we (I?) have been getting by without it since 2003 or so.

This is not an issue. It is unfortunately the expected behavior. You must go into the FULL editor and set everything from there. The quick editor does not hook to the tagging plugin we are using. It is annoying, but it ... is. Just get used to drilling all the way into the full editor when updating the tags of a topic with a prefix. Incidentally, this could actually be a caching issue though. s4n might know. It could be that the page is re-cached with the change immediately after making the change, but the tagging software does not get in on the action until we rebuild the tags cache. I will edit the tags of this topic and rebuild the tag cache to see if that is what is happening, so please leave the OP and topic alone for tonight and tomorrow until I get back (getting off now)

I disagree with that last post (but I admit not having read through this thread from the beginning) ... I don't even look at those flags! (previous Wrye Bash user here). All I do is install STEP according to the instructions (even though I helped create many of them). I look at the order of installation, and all of the mod notes and install the mods. Somebody else has done the work of determining differential conflicts from redundancies, so I don't have to ... The people that could really use the true conflict res you speak of are the people creating the guide BUT, I don't spend time checking the work of others' testing the before/after effects of the mod. I have to trust that they know what overwrites what and the actual in-game effect is accurate and judge based on the screens. I might only do this for one or two mods in a release, but some people do several, which is a big job. MO tells us what overwrites what, and we specifically test this against that, so there is just no real issue with knowing if the assets of two mods are all actually different in some way, because we go by info (including visual) passed on by those before us, and we need to look at the in-game effects of the thing anyway. It would be nice to know when you don't need to review a particular texture (most conflicts are textures), but who has that kind of time anyway? We look at the high-level effects and a few random specifics and don't focus in on every single change in-game. The added conflict resolution functionality would be useful for deeper analysis at times though or for plugins, scripts and other things you can't really 'see' in the game. ... and I just want to extract --via text copy-- the text information of any list in MO. The mod list, the plugin list ... the conflicts lists. This is useful for the specialized task of sharing information when cooperatively troubleshooting or testing a mod.

Your wish list is desirable, but idealistic. I do see there being a big problem though with processing time, MO side. Again, I have no good knowledge of how deeply Wrye Bash delves into BSAs beyond extracting path information, but my guess is that it does not. That application does to a real CRC check, but again, it still only lists the path in the conflicts tab. Other tabs do hold more information though about a particular file (inside BSAs?, I thought not). I would like to see this kind of functionality too as an option, but I also can see why it would be burdensome to implement when the main goal of MO (I am supposing) is to make it as simple as possible for people to install mods (for many fast-switching profiles) using guide instructions (nothing more). MO would be a more attractive modder's resource if it had some of the conflict resolution functionality you speak of, definitely. I just have to assume that is not the primary audience and functionality. Therefore, it really would be nice if other developers were willing to create some much-wanted plugins for MO to handle these things.

That would be true of the wiki. If you edit the main guide for example (or if you use PAGE TOOLS > REFRESH), it can take up to a minute or more to finally complete the transaction. During this time, the wiki is pretty much frozen for everyone. At this time, though, the forums can be navigated without issue in my experience, which makes sense if Mediawiki is using all available key resources it has to complete the task. The forums have a separate resource allocation to a large extent in my understanding.

I need to get the old forums up in my VM in order to find that thread ID. Will need some time yet.

I never get 504 (or only once or twice in the past). The buggy editor render is what irks me.