Jump to content


Photo

Core Mods Definition


  • Please log in to reply
38 replies to this topic

#16 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 28 November 2013 - 02:10 PM

Yes there is actually. My config generator tool for ASI beta does just that. You would have to download each mod archive and place it in the same directory, but it will spit out the names. There might be a better way, I designed it for something much simpler. I plan on just using a mod manager to keep track of updates, and then download it and updating whatever from it. Both MO and NMM have this functionality. I know with NMM you don't have in install the mod but it will still keep track of updates for them anyway, which is what I am using now for that reason. I am thinking about putting my efforts into automated optimizations, skyrproc patching, ect. It something I can start, finish, and debug in the short term. I am thinking I will make that functionality part of a separate executable, so that if and when another program comes around, it can just create a process and make a system call to it.
  • 0

#17 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,249 posts

Posted 28 November 2013 - 10:19 PM

Different priorities sure. The CRC implemenation for automating STEP is much more important, but its also much more difficult to do. Lets pick the low hanging fruit first.

I do want to state unequivocally, just to bring it up early, that current baseline STEP is not well suited for mid range or low end system. Its just two heavy on the VRAM, I have tested this out a great deal myself. Texture optimization and resizing is essential for creating a high functioning and stable STEP installation, and its also time consuming and technical, so it definitely needs to be automated. In my mind its essential, and an automated STEP would be rather incomplete without it. I also want to look into automating FNIS and the skyproc patching too, because that is likewise essential to a properly functioning STEP.

The design goal for ASI is a one click, fully functioning, bug free, high performing, and stable STEP installation that require little or no additional actions on the part of the user after it has finished running. With this design goal in mind, the extra features are equal parts to the puzzle as anything else.

Current Baseline STEP:Core should be fine for mid-low end systems if SRO Optimal is used (or omitted). Agree that eventually, we want to assist with texture optimization; however, that is not necessary if the source is already optimized (see my previous posts). Again, STEP:Core does not suffer the issues of STEP:Extended and Packs, so it is an ideal candidate to get barebones ASI going.

This discussion is too early. Where the project will be headed is still open and it shouldn't matter that much at all:
low, base and high will be  supported sometime later on. (that'll be actually pretty easy to manage)

@mothergoose729: I have by no means any reason to stop you pursuing what you like! :) Low hanging fruits are all perfectly fine. The milestones I've written are mostly for personal management of the project. It keeps track of what needs to be achieved to get a basic "barebone" installer. As I'm still in a pre-alpha stage with this thing, any addition/ideas are a bonus and welcome!

Nothing is set in stone yet. And from what I can tell, that's ok: Once we are in beta (and this will take a while..) it'll become extremely easy to manage custom packages (be it other cores, or extensions). You are free to discuss the final, official Auto-STEP release in a seperate thread, but IMHO that's just a waste of time anyway (too early). This is about a "TEST"-install of a PROOF OF CONCEPT. I'm not going to push STEP in any direction at all. Simply because it's current standard I'll just use that for now.

What SHOULD be discussed here (and would be far more productive) are installing options where the current STEP guide (including the recommendations) leaves the choice open to the reader - that's just not working for a test install (there won't be any GUI or options for a while). We need to list them all, make a (very short) discussion for each one on what's the easiest choice development wise, and then move on. Enough talk about AutoSTEP, let's just do it!

I'll assemble a baseline config file. But no one is going to stop anyone in creating alternatives. I will publish all meta data, as soon as I can manage to collect them all.

Which brings me to my current short term goal: I need a list of all STEP (core) mod archive filenames!. The only thing that's stopping me from starting this (dull) work is the question: "Can't we automate this list?"
If there's a clear "No" to that question I'm fine with it and move on. But in the long run a script might help a lot keeping it up-to-date.
I've tried to look into some files released here (+a look inside MO and NMM) but didn't have any luck to get it working.
ANY help with this would be highly appreciated.

No offense to anyone. That's just my point of view and how I'll want to move on here :)

Totally agree. See this post to acquire a working list of Nexus IDs that can in turn be used to capture those needed file names using the MO method. I think that using these unique IDs is our best bet for getting the current, valid archive names from the Nexus. The only kink is being able to pick the correct file where many archives are associated with a particular ID (perhaps a regex could work, but we need a good algorithm for the starting guess for the handfull of mods that fall into this category. We may just have to manually handle this piece, but it is worth an attempt to capture what we can and assess).

Yes there is actually. My config generator tool for ASI beta does just that. You would have to download each mod archive and place it in the same directory, but it will spit out the names. There might be a better way, I designed it for something much simpler.

I plan on just using a mod manager to keep track of updates, and then download it and updating whatever from it. Both MO and NMM have this functionality. I know with NMM you don't have in install the mod but it will still keep track of updates for them anyway, which is what I am using now for that reason.

I am thinking about putting my efforts into automated optimizations, skyrproc patching, ect. It something I can start, finish, and debug in the short term. I am thinking I will make that functionality part of a separate executable, so that if and when another program comes around, it can just create a process and make a system call to it.

Yes, this is definitely another way to do it without any hangups. One of our team will always need to keep an accurate and relevant Current-release install, so that could easily define the mod package list (an MO export in text, XML or JSON would be nice though).

#18 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 29 November 2013 - 02:38 AM

While we have brought it up, we need to discuss SRO and automated STEP. There are at least three different versions floating around, and STEP does not point the user to any particular torrent. This, simply put, is a big problem with automization. There either needs to be source we direct the user too, or automated STEP should not included SRO at all. I was thinking about this the other day, and I think the best solution would be to build automated STEP without it, and then provide instructions in the wiki with how to use SRO and automated STEP together if they want to.
 

What SHOULD be discussed here (and would be far more productive) are installing options where the current STEP guide (including the recommendations) leaves the choice open to the reader - that's just not working for a test install (there won't be any GUI or options for a while). We need to list them all, make a (very short) discussion for each one on what's the easiest choice development wise, and then move on. Enough talk about AutoSTEP, let's just do it!


Great point. I will just throw some ideas out there. For mods that provide multiple downloads for different configurations, for example the "spinning emblem" mod in the interface section, I think its pretty easy and straightforward to provide multiple configurations for that mod. I did that in my example config, it includes instructions for installing all four versions. There are some mods where the user can choose between different quality options so obviously automated STEP should accommodate those too. One of many examples, better beast races has a 1k and 2k download option, and ASI should be able to do both. For mods that have a FOMOD installation it becomes more complicated. I think it is best with mods of this structure to have one recommended configuration. This would be a problem with people who don't have certain DLCs, specifically with mods like "even better quest objectives" and "WATER" (although WATER is getting dropped, need to look into the replacement mod). The user can manually disable the plugins, and for the cases where the master esp relies on a particular DLC, we can either instruct the user who doesn't have the dlc not to donwload that mod, or work with the mod author where possible to provide a vanilla only version. 

Perhaps tomorrow I will go through the STEP mods and try and provide a list of mods that provide multiple download options and we can discuss which ones STEP should try and accommodate. 
  • 0

#19 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 29 November 2013 - 07:33 AM

Great ! Sounds good!
  • 0

#20 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,249 posts

Posted 29 November 2013 - 03:01 PM

If we want to automate, then SRO (optimal version) can be linked. We have not done so explicitly up to this point, but since SRO does not appear on the Nexus or anywhere else, then STEP can condone acquiring it this way ... we dust don't want to steal links/users away from legitimate download sources. Since SRO is not on the Nexus or any other source, torrents are legit.

Again, in terms of the current pre-alpha, I vote to adhere strictly to STEP:Core Baseline. Wherever there is ambiguity, let's provide an explicit recommendation (so let me know what mod notes leave any decision making to the end user, and we can create an explicit recommendation.

Remember, STEP:Core are only mods that have the greenish Core mark in the leftmost column of the guide (or just use the query I have been linking to all over the place)

PS, let's not create any more new threads relating to this topic. Info is getting unnecessarily spread out and redundancies are cropping up.

#21 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 29 November 2013 - 04:18 PM

That all makes sense. Think you can provide the link to the SRO version we plan to include? If we are sticking to one definition of core STEP for the time being, I think all of the options explicitly recommended or proscribed in the STEP 2.2.7 guide is a good place to start. Is there an ETA on the 2.2.8 guide? Obviously that is coming out soon, so if there are changes we wouldn't want to waste time building for a soon out dated version. Also, to be explicit, we are building for a full DLC version correct? At least to begin with? I want to raise some objections to the core baseline STEP here. For performance reasons vanilla hD improved mountains, terrain bump, and trees HD are not suitable for cards with 1gb VRAM or below. Terrain bump uses 2048 HD normal maps for distant LODs, which looks great but its a terrible waste of resources. Vanilla improved mountains HD has only a 2k version, which is also not suitable for 1gb cards because of VRAM issues. The recommended version for trees HD is the 2k version, which is too much, but the 1k version should be ok. These are issues related to stability more than anything, they can and will cause crashes due to VRAM issues, not to mention the performance is pretty much unbearable in the outdoors. So there is ambiguity in the following STEP mods, and here is my proposed resolution for said ambiguities: Weapons and armor fixes -> use the dragonborn + dawnguard version Skill interface retexture -> use HDR nebula - immsersive starts, default perk lines, default perk lines color, enhanced default constellations, enhanced default perk stars HRDLC optimize -> hybrid + vanilla normal maps (some objection to this one. It seems an uneccessary optimization because it has very little impact on performance but a huge impact on quality. Mostly because of face normal maps and distant LODs) bellyaches creature pack -> use the default re placer optional file instead of the FOMOD installer superior lore friendly hair -> recently include FOMOD. I think the less shiny normal maps version,1k, with rough hair optional version would be best cover khajits -> the lower res version has female khajit in an optional folder, for no particular reason. So that has to be manually moved in MO or wherever dawngaurd rewritten - aravak -> use soul cairn version. Performance textures? I think high res, but not extreme, would be fine for almost everybody xenuis character enhancement isn't in baseline STEP? It is high res, but the pixels seem well spent. Just a thought book of silence armors -> elven gold, hide cabal's cut?, iron vanilla cut, steel no fur, scaled brighter, orcish brighter, wolf grey, glass default variant (grey I think?), ebony black book of silence uniques -> savior hide brown fur, ebony mail black book of silence creatures -> not including this pack? Its great stuff, and true to vanilla book of silence weapons -> use all of them book of silence dragonborn -> nordic carved brown, do not include ash spawn and ash gaurdian? book of silence hotfixes -> include all of them right diverse priests -> bring out your dead is not a part of baseline STEP. So the ESP for bring out your dead compatibility needs to be removed
  • 0

#22 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,249 posts

Posted 29 November 2013 - 09:58 PM

[quote name=''mothergoose729' pid='59637' dateline='1385759921']That all makes sense. Think you can provide the link to the SRO version we plan to include? If we are sticking to one definition of core STEP for the time being' date=' I think all of the options explicitly recommended or proscribed in the STEP 2.2.7 guide is a good place to start. Is there an ETA on the 2.2.8 guide? Obviously that is coming out soon, so if there are changes we wouldn't want to waste time building for a soon out dated version. Also, to be explicit, we are building for a full DLC version correct? At least to begin with?[/quote']
SRO Optimal is the best source for the purposes of ASI, IMO. This is optimized for quality/performance on all systems (I use it and am very happy with it ... Skyrim Revisited also links to this version). We can also link to the full 2k version, but that is too much for low-mid systems with less than 2 GB VRAM.
[quote]I want to raise some objections to the core baseline STEP here. For performance reasons vanilla hD improved mountains, terrain bump, and trees HD are not suitable for cards with 1gb VRAM or below. Terrain bump uses 2048 HD normal maps for distant LODs, which looks great but its a terrible waste of resources. Vanilla improved mountains HD has only a 2k version, which is also not suitable for 1gb cards because of VRAM issues. The recommended version for trees HD is the 2k version, which is too much, but the 1k version should be ok. These are issues related to stability more than anything, they can and will cause crashes due to VRAM issues, not to mention the performance is pretty much unbearable in the outdoors.[/quote]
I had a 1 GB card until recently, and I object to these assertions as uninformed ... Vanilla HD Mountains and Terrain Bump do not noticeably affect performance at all (the latter also has a performance version, which absolutely does not in any way impact VRAM to any noticeable degree, and no, TB does not use 2k textures anywhere at all IIRC). TreesHD might affect performance just a little in some cases, but not worth mentioning. The biggest killers (In STEP:Core) are SRO and SFO, period. These are accounted for with Optimal SRO and Basic SFO versions. As I have said, much testing has been done, so unless you are willing to put up numbers, real numbers to back your claims and refute work already done, please stop fighting this one.

Baseline STEP:Core is the primary version of STEP, and any automated installer that is put up on the Nexus will address this specifically. Do what you want for your own ASI, but Baseline STEP will not be changing without actual compelling data points to back it. Now let's get back on topic ... again.
[quote]So there is ambiguity in the following STEP mods, and here is my proposed resolution for said ambiguities:
Weapons and armor fixes -> use the dragonborn + dawnguard version
Skill interface retexture -> use HDR nebula - immsersive starts, default perk lines, default perk lines color, enhanced default constellations, enhanced default perk stars
HRDLC optimize -> hybrid + vanilla normal maps (some objection to this one. It seems an uneccessary optimization because it has very little impact on performance but a huge impact on quality. Mostly because of face normal maps and distant LODs)
bellyaches creature pack -> use the default re placer optional file instead of the FOMOD installer
superior lore friendly hair -> recently include FOMOD. I think the less shiny normal maps version,1k, with rough hair optional version would be best
cover khajits -> the lower res version has female khajit in an optional folder, for no particular reason. So that has to be manually moved in MO or wherever
dawngaurd rewritten - aravak -> use soul cairn version. Performance textures? I think high res, but not extreme, would be fine for almost everybody
xenuis character enhancement isn't in baseline STEP? It is high res, but the pixels seem well spent. Just a thought
book of silence armors -> elven gold, hide cabal's cut?, iron vanilla cut, steel no fur, scaled brighter, orcish brighter, wolf grey, glass default variant (grey I think?), ebony black
book of silence uniques -> savior hide brown fur, ebony mail black
book of silence creatures -> not including this pack? Its great stuff, and true to vanilla
book of silence weapons -> use all of them
book of silence dragonborn -> nordic carved brown, do not include ash spawn and ash gaurdian?
book of silence hotfixes -> include all of them right
diverse priests -> bring out your dead is not a part of baseline STEP. So the ESP for bring out your dead compatibility needs to be removed[/quote]
Thanks for the input here ... however, We should be addressing each specific case on each specific mod thread so that mod testers and all contributors and team members can communicate about this. I specifically want input from Tech et al on these proposed changes, as I don't know most of the diffs well enough to make an informed call.

Would you mind posting your opinions on each of those threads to get those conversations started?
TIA

#23 TechAngel85

TechAngel85

    Akatosh

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 11,935 posts

Posted 30 November 2013 - 01:11 AM

snip...

I want to raise some objections to the core baseline STEP here. For performance reasons vanilla hD improved mountains, terrain bump, and trees HD are not suitable for cards with 1gb VRAM or below. Terrain bump uses 2048 HD normal maps for distant LODs, which looks great but its a terrible waste of resources. Vanilla improved mountains HD has only a 2k version, which is also not suitable for 1gb cards because of VRAM issues. The recommended version for trees HD is the 2k version, which is too much, but the 1k version should be ok. These are issues related to stability more than anything, they can and will cause crashes due to VRAM issues, not to mention the performance is pretty much unbearable in the outdoors.

I had a 1 GB card until recently, and I object to these assertions as uninformed ... Vanilla HD Mountains and Terrain Bump do not noticeably affect performance at all (the latter also has a performance version, which absolutely does not in any way impact VRAM to any noticeable degree, and no, TB does not use 2k textures anywhere at all IIRC). TreesHD might affect performance just a little in some cases, but not worth mentioning. The biggest killers (In STEP:Core) are SRO and SFO, period. These are accounted for with Optimal SRO and Basic SFO versions. As I have said, much testing has been done, so unless you are willing to put up numbers, real numbers to back your claims and refute work already done, please stop fighting this one.

Baseline STEP:Core is the primary version of STEP, and any automated installer that is put up on the Nexus will address this specifically. Do what you want for your own ASI, but Baseline STEP will not be changing without actual compelling data points to back it. Now let's get back on topic ... again.

I have to agree with Z on this one. I currently have only 1GB VRAM and only have some stuttering in heavily wooded areas. This is most likely SFO, but I've not done the testing to confirm this. I know that the 1K version of Trees HD has quite of bit of noticeable quality loss from the 2K version. Z was the one that first pointed this out to me.

So there is ambiguity in the following STEP mods, and here is my proposed resolution for said ambiguities:
Weapons and armor fixes -> use the dragonborn + dawnguard version
Skill interface retexture -> use HDR nebula - immsersive starts, default perk lines, default perk lines color, enhanced default constellations, enhanced default perk stars
HRDLC optimize -> hybrid + vanilla normal maps (some objection to this one. It seems an uneccessary optimization because it has very little impact on performance but a huge impact on quality. Mostly because of face normal maps and distant LODs)
bellyaches creature pack -> use the default re placer optional file instead of the FOMOD installer
superior lore friendly hair -> recently include FOMOD. I think the less shiny normal maps version,1k, with rough hair optional version would be best
cover khajits -> the lower res version has female khajit in an optional folder, for no particular reason. So that has to be manually moved in MO or wherever
dawngaurd rewritten - aravak -> use soul cairn version. Performance textures? I think high res, but not extreme, would be fine for almost everybody
xenuis character enhancement isn't in baseline STEP? It is high res, but the pixels seem well spent. Just a thought
book of silence armors -> elven gold, hide cabal's cut?, iron vanilla cut, steel no fur, scaled brighter, orcish brighter, wolf grey, glass default variant (grey I think?), ebony black
book of silence uniques -> savior hide brown fur, ebony mail black
book of silence creatures -> not including this pack? Its great stuff, and true to vanilla
book of silence weapons -> use all of them
book of silence dragonborn -> nordic carved brown, do not include ash spawn and ash gaurdian?
book of silence hotfixes -> include all of them right
diverse priests -> bring out your dead is not a part of baseline STEP. So the ESP for bring out your dead compatibility needs to be removed

Thanks for the input here ... however, We should be addressing each specific case on each specific mod thread so that mod testers and all contributors and team members can communicate about this. I specifically want input from Tech et al on these proposed changes, as I don't know most of the diffs well enough to make an informed call.

Would you mind posting your opinions on each of those threads to get those conversations started?
TIA

How recent is this list? I think some of this has already been addressed (changelog for 2.2.8 and live now on the wiki). I'll check over them; however, I know some of the mods we intentionally left some choices up to the user; thus, didn't provide specific choices. If we're now needing to do this for the packs, then some mods might need some input for consensus. I'll address all the Core mods in the next day or two. If anything needs a consensus, I'll post choices in that mod's thread. It would be help for me to know if STEP is now officially requiring all DLCs or not. 



#24 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 30 November 2013 - 02:45 AM

[color=#ffda00]How recent is this list? I think some of this has already been addressed (changelog for 2.2.8 and live now on the wiki). I'll check over them; however' date=' I know some of the mods we intentionally left some choices up to the user; thus, didn't provide specific choices. If we're now needing to do this for the packs, then some mods might need some input for consensus. I'll address all the Core mods in the next day or two. If anything needs a consensus, I'll post choices in that mod's thread. It would be help for me to know if STEP is now officially requiring all DLCs or not.  [/color']

it's just mothergoose729s summary of mods that need some attention for the automisation-tool!
If some of this has been adressed that's alright! I'll check out the 2.2.8 changelog and update some of my scripting accordingly.

disclaimer:
(can't seem to stress that enough :D)
The current state of the available "Semi-Automatic STEP"-tools is pre-alpha! There isn't any working installer yet (altough mothergoose729 did some great work getting there).
As we are in a proof of concept phase, we just need to decide on some packages what options we choose for a first scripted test-install with no user interaction at all.

The current plan (proof of concept)
Create a one-click script that installs all STEP Core mods. We concentrate on a baseline install and assume the test user has all DLCs. Later there'll be options/profiles for high/low/vanilla installs - just not for our first scripting draft.
That'll simplify things a lot development wise (easier to reach goals). I think adressing too much problems at once doesn't help. We need to set small goals in order to some progress. So basic install support first, options later.

The Core definition we need to make are just done via "rule of thumb" yet. Final decisions on what options a full one-click installer should pick will be made in the relevant mod threads (early dev stage, so no rush here!). We are still assembling a list of all mods that need attention for this - any help with this is highly appreciated of course :)!
And if the STEP team will get to a consensus on the options I will change the script accordingly of course. But then again getting SOMETHING done has a much higher priority than such decisions imho for now! While giving the user the most basic choises (quality setting and DLC support) neither in the design philosophy of a semi-auto installer nor realistic in terms of programming effort (at least for the next months)
  • 0

#25 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 30 November 2013 - 04:39 AM

[quote='z929669' pid='59665' dateline='1385780336']
[quote name=''mothergoose729' pid='59637' dateline='1385759921']That all makes sense. Think you can provide the link to the SRO version we plan to include? If we are sticking to one definition of core STEP for the time being' date=' I think all of the options explicitly recommended or proscribed in the STEP 2.2.7 guide is a good place to start. Is there an ETA on the 2.2.8 guide? Obviously that is coming out soon, so if there are changes we wouldn't want to waste time building for a soon out dated version. Also, to be explicit, we are building for a full DLC version correct? At least to begin with?[/quote']
SRO Optimal is the best source for the purposes of ASI, IMO. This is optimized for quality/performance on all systems (I use it and am very happy with it ... Skyrim Revisited also links to this version). We can also link to the full 2k version, but that is too much for low-mid systems with less than 2 GB VRAM.
[quote]I want to raise some objections to the core baseline STEP here. For performance reasons vanilla hD improved mountains, terrain bump, and trees HD are not suitable for cards with 1gb VRAM or below. Terrain bump uses 2048 HD normal maps for distant LODs, which looks great but its a terrible waste of resources. Vanilla improved mountains HD has only a 2k version, which is also not suitable for 1gb cards because of VRAM issues. The recommended version for trees HD is the 2k version, which is too much, but the 1k version should be ok. These are issues related to stability more than anything, they can and will cause crashes due to VRAM issues, not to mention the performance is pretty much unbearable in the outdoors.[/quote]
I had a 1 GB card until recently, and I object to these assertions as uninformed ... Vanilla HD Mountains and Terrain Bump do not noticeably affect performance at all (the latter also has a performance version, which absolutely does not in any way impact VRAM to any noticeable degree, and no, TB does not use 2k textures anywhere at all IIRC). TreesHD might affect performance just a little in some cases, but not worth mentioning. The biggest killers (In STEP:Core) are SRO and SFO, period. These are accounted for with Optimal SRO and Basic SFO versions. As I have said, much testing has been done, so unless you are willing to put up numbers, real numbers to back your claims and refute work already done, please stop fighting this one.

Baseline STEP:Core is the primary version of STEP, and any automated installer that is put up on the Nexus will address this specifically. Do what you want for your own ASI, but Baseline STEP will not be changing without actual compelling data points to back it. Now let's get back on topic ... again.
[quote]So there is ambiguity in the following STEP mods, and here is my proposed resolution for said ambiguities:
Weapons and armor fixes -> use the dragonborn + dawnguard version
Skill interface retexture -> use HDR nebula - immsersive starts, default perk lines, default perk lines color, enhanced default constellations, enhanced default perk stars
HRDLC optimize -> hybrid + vanilla normal maps (some objection to this one. It seems an uneccessary optimization because it has very little impact on performance but a huge impact on quality. Mostly because of face normal maps and distant LODs)
bellyaches creature pack -> use the default re placer optional file instead of the FOMOD installer
superior lore friendly hair -> recently include FOMOD. I think the less shiny normal maps version,1k, with rough hair optional version would be best
cover khajits -> the lower res version has female khajit in an optional folder, for no particular reason. So that has to be manually moved in MO or wherever
dawngaurd rewritten - aravak -> use soul cairn version. Performance textures? I think high res, but not extreme, would be fine for almost everybody
xenuis character enhancement isn't in baseline STEP? It is high res, but the pixels seem well spent. Just a thought
book of silence armors -> elven gold, hide cabal's cut?, iron vanilla cut, steel no fur, scaled brighter, orcish brighter, wolf grey, glass default variant (grey I think?), ebony black
book of silence uniques -> savior hide brown fur, ebony mail black
book of silence creatures -> not including this pack? Its great stuff, and true to vanilla
book of silence weapons -> use all of them
book of silence dragonborn -> nordic carved brown, do not include ash spawn and ash gaurdian?
book of silence hotfixes -> include all of them right
diverse priests -> bring out your dead is not a part of baseline STEP. So the ESP for bring out your dead compatibility needs to be removed[/quote]
Thanks for the input here ... however, We should be addressing each specific case on each specific mod thread so that mod testers and all contributors and team members can communicate about this. I specifically want input from Tech et al on these proposed changes, as I don't know most of the diffs well enough to make an informed call.

Would you mind posting your opinions on each of those threads to get those conversations started?
TIA[/quote]
1 point: Sounds great. That part was easy. 

2nd point: Where would be a more appropriate forum for this? 

3rd point: I think it makes much more sense to discuss these specific here don't you think? Debating each mod specifically in a different thread would hopelessly fragment the discussion. I don't relish the thought of looking through a dozen or more threads when it comes time to actually build a STEP installer, and I can't imagine Miles does either!
  • 0

#26 TechAngel85

TechAngel85

    Akatosh

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 11,935 posts

Posted 30 November 2013 - 11:24 AM

While it might be convenient to handle all the discussion here, we still be to record our decisions for the purpose of having a record for the public as well as ourselves. Doing this individually in the Anthology threads is the best way to handle this so that everything stays organized to where it's suppose to be. It's not hard to make cliff notes on a notepad (I used notepad++) to keep the sources gathered and then post the final results from all evaluations in one post here. In any case, this is something for the STEP team to do as a whole, if any consensus needs to be made on any one choice. If not or I know the choices that STEP has made, then I'll just simple make that change. Any changes will be both in my notes and on the changelog. Doing all the evaluations in this thread is convenient for Automatic STEP but is not practical when it comes to the rest of the team and what we do or for public knowledge and record of our choices. EDIT: Please keep in mind that things have been done a certain way here for a very long time. New team members sometimes have difficulty adjusting and learning these ways. Most things are done in a certain way for a certain purpose. We're not "stuck in our ways" but "if it's not broken don't fix it" applies most of the time. I don't have an elegant way with words like Z, but know that you're being heard and understood because most of us have been there. It may just take some time to adjust.

#27 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,249 posts

Posted 30 November 2013 - 11:56 AM

2nd point: Where would be a more appropriate forum for this? 

3rd point: I think it makes much more sense to discuss these specific here don't you think? Debating each mod specifically in a different thread would hopelessly fragment the discussion. I don't relish the thought of looking through a dozen or more threads when it comes time to actually build a STEP installer, and I can't imagine Miles does either!

Points 2 and 3 should take place within the Anthology mod threads just as Tech stated and for those reasons. Any decisions regarding Core mods and options (including Baseline def) belong on the mod threads ... many of those threads already have rationale as to why certain choices were made ... backed with real data.

So ... it looks like we need to wrap up this OP based upon decisions that will take place in the Anthology forums. It would be good if MTeg or other staff could update the OP accordingly as to the mods in question and their answers ... linking to each Anthology thread/post(s) of interest with regard to each mod in that list. I started editing the OP accordingly, but will defer to Tech on Core mods that actually belong in that list.

#28 TechAngel85

TechAngel85

    Akatosh

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 11,935 posts

Posted 30 November 2013 - 01:05 PM

Something I need answered before I can continue. Is STEP now officially only supporting all the DLCs or not? This needs to be determine as many mods have many options according the the DLC the user has. This will affect the work these two are doing here as well. WAF for example currently has the following recommendations:

Download the version according to your DLC selection. Users of no supported DLC should use the "Vanilla" version, and users who use both Dawnguard and Dragonborn should use the "Complete" version.

If using the aMidianBorn Skyforge Weapons component of Book of Silence and/or Improved Closefaced Helmets, use and install the patch for each mod directly below its corresponding mod.

For example:
Mod---> Improved Closefaced Helmets
Patch---> Improved Closefaced Helmets -- WAF Compatible Versions

If using Guard Dialogue Overhaul, get the corresponding patch for it. Despite this mod being installed before Guard Dialog Overhaul, the patch is needed so that Guard Dialog Overhaul does not overwrite the changes from this mod.


That is probably too much for these guys to handle. I vote we move in the direction of officially supporting all DLCs now and narrow our recommendations to reflect.

#29 Aiyen

Aiyen

    Dragon King

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3,536 posts

Posted 30 November 2013 - 01:26 PM

I support full DLC support only from now on. There is not going to be any more official expansions, so by that argument alone I think its okay. Add that its on sale these days, and is going to be on sale for at least two days during the christmas season at 75% off then there is just no serious arguments for not getting it if you want to mod. All the DLC are worth the asking price when at -75%...

#30 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 30 November 2013 - 01:31 PM

I think initially it makes sense to narrow the specifications for design and testing purposes. I think a design goal for ASI should be able to accommodate as much as possible, within what is reasonable to maintain and possible with the technology. But that might be a debate best saved for another time, further on down the road.
  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users