z929669

Hmmm, what's the point then??

For what it's worth, I am going to devote some time to Wrye Bash devel to help solve some of these issues going forward. This is the kind of thing that a Bashed Patch should be able to handle, but there is so much that needs to be updated yet to apply to Skyrim, that I fear will never be resolved by Tes5Edit alone (as has been the case in the past). I encourage the lot of you to contribute to the project if you are willing. First step is to become deeply familiar with WB devel. I'll post links soon: https://wiki.step-project.com/Project:Wrye_Bash

Decent concept, but this would not work for core STEP. Maybe a Pack in the future. ...if one falls into a pit, can one get out if they don't die? Tying some kind of mechanism and story to getting trapped in a pit would integrate better maybe.

So I can completely drop the rest of the files, I don't need /armor/draugr folders? I can just pretty much have nordarmorfix/meshes/nordfix.nif ? Other mods, for example, the female body mods, say to put the file in data/mesh/character/female/etc, so, wrye bash doesnt need all that?:o_O: There is one file in the mod. It is under meshes/armor/draugr/ If you don't include the directory hierarchy, then no mod installation utility can install the mod correctly. I suggest that you go into skyrim/Data/meshes/ (and ./textures/ and ./*/) and look at the folder structure.

The principle of this mod is perfect for STEP. Let's bring in Neovalen's recommendations for the mod to this thread for context. Once we have some recommendations on optimizing for STEP, I think that this can be accepted.

If you study figs 4-5 on the Guide, it pretty clearly depicts and explains the proper structure in the examples using various file/folder types (including meshes as in the Nord Armor Fix). Note the middle box under fig 5: Ex 4. Standard files & folders (3 levels). This is exactly the same as Ex 3, but the Data directory is now beneath yet another parent directory. Unfortunately, WB stops looking for anything more than 2 folders deep at this time. Many mods come packed this way, and were not created by modders that are thoughtful of BAIN. This will need to be extracted and repack according to Ex 1 or Ex 3. The Nord Armor fix mod fits within this example. Its "meshes" folder is 3 directories deep, ... ROOT/1/2/3/: Ancient_Nord_Armor_Fix-2808-1.rar(ROOT)/Ancient Nord Armor 1st Person Fix(1)/Data(2)/meshes(3)/ ... so it must be moved up at least one directory. I personally always treat package ROOT as equivalent to Skyrim/Data/ to resolve: ROOT/1/: D_Ancient Nord Armor Fix_BAIN-v1-2808(ROOT)/meshes(1)/ [ skyrim/Data(ROOT)/meshes(1)/ ] HTH

Saw that, thanks

:@

It should not matter, since CoT is not included in STEP.

FYI guys. I suspect that neither of you have given the WBG a fair read. All of the gritty details of using WB are in the guide. Carefully read the following sections: Package RestructureBAIN InstallersInstalling modsPlease post questions about WB in the WBG thread. Thanks PS: although Neovalen is a great modder himself, he is nonetheless biased in his favor of MO, as I don't believe that he has ever given WB a fair shot (ask Farlo ... he used to be another heavy MO preacher, but after giving WB a fair try, that is the tool he uses now ;) ). If you want to really learn how modding works, WB is a better training ground, as there is much more hands-on work required in maintaining mod packages. Don't get me wrong, we highly recommend MO too, but keep an open mind and judge what is best based on your own experience. (for each of Neo's MO "strengths" listed above, there is also a weakness, so it is a tradeoff) EDIT: Almost forgot ... STEP is best for those new to modding, as it requires much less work and does not change much of the gameplay aspects ... in other words, it is MUCH simpler to get STEP to work "out of the box" than Skyrim Revisited (although SR works well, given that the instructions are very carefully followed ... takes a LOT longer to build though). In fact, using MO for STEP is probably the safest bet for anyone that wants to just get it done and be finished with it

If sufficient testing has been done, could either of you create the mod page and provide suggested installation notes? We will tentatively accept given the advocates ;)

Let's keep each separate. Bout time we see these again!

Please read the posting guidelines. OP/Thread name updated.

I updated the "Working With BCFs" section of the WB Guide for clarity. Also added more consistent markup where necessary to match the standard of the rest of the site.

I updated the "Working With BCFs" section of the WB Guide for clarity.

Jaysus has been responsive to me in the past, so he should respond ... unless he has become disillusioned with the community.

I agree with tech on this one. It makes absolutely no sense to force many disparate texture mods into a single, unparsed package ... unless they truly are not already addressed by the major overhauls or the HRDLCs (and it sounds like these are already addressed for the most part). Much better to either provide all as separate mods altogether or as separate downloads under the same mod. Next best alternative is to create a BAIN as a single download, but this is still a big potential waste of bandwidth. I think that each of these mods should be compared separately on their own threads if they will remain available as separate mods.

I started out as a hard-liner like tech on this, but have setled more into a position similar to roots now. the way I see it is that mod suggestions can be made by anyone at any time. All we ask is that they: search the MS forum before postingpost title as {Nexus mod name} {(by author)} (which is often NOT done )include a Nexus link to mod in the OPinclude a description of the mod in the OPIf anything more can be posted in the OP, that is a bonus, but the idea is that other posters and mod testers will eventually flesh this out if the mod gets enough attention. If not ... it will never make it into STEP. This methodology is self-maintaining and allows STEP to be driven by consensus (and/or by the tenacity of a few). RE overhauls: If the mod in question is packed like XCE, but is composed of disparate items as in Skyrim Redesigned, this would not be ideal, and I would prefer separation either under a single dir structure or as separate downloads. If it addresses a particular theme though, then it makes sense to treat as a single overhaul. I do agree with tech though that there is a difference between an overhaul and a bundle. The former usually focuses on one theme and may or may not be parsed into subs. The latter can address many disparate themes and are always parsed into subs (e.g., Skyrim Redesigned). Some are hybrids of the two, but are more overhauls IMO (e.g., XCE, aMBoS).

@Pymous PM me on the Nexus if you'd like to confirm your status as the mod author. We recognize authors around here with a special username tag ;)

I personally prefer "without" as well, especially since these are not quest related or functional in any way. Thanks both for getting the mod page up ;)

I'm still not sure what you mean by manual rollback.The user can use either SkyTweak or console commands to set actor values back to whatever they were. So long as he remembers or can figure out what they should be rolled back to. By "manual rollback," I mean that one needs to use the console to manually roll back any sticky changes not automatically rolled back upon uninstalling SkyTweak. It seems that if a user uninstalls SkyTweak, then any changes that user made via SkyTweak will automatically be rolled back if it is ever uninstalled ... accept for those that are 'sticky', shich will need to be manually rolled back via console. One concern is that any STEP mod can be cleanly uninstalled, and thus, it is not *dangerous* to use. I also like the idea of flagging the 'sticky' settings as well as any changes from vanilla GMSTs. For that matter, it would be optimal to flag SkyTweak settings differently than other non-vanilla settings. The attractiveness of this tool is that it could apply to any Pack against any flavor of STEP. We would just need to define presets for each context. It would also allow us to force otherwise GMST-incompatible mods to coexist within the same setup.