Jump to content

Recommended Posts

Posted

I agree, that the SMC as it is now, might not be totally S.T.E.P compatible, but the idea behind it could possibly make semi-automation of STEP reality. It is much easier for user to just download all the mods trhat are part of S.T.E.P and run an automated process, that would combine them in one installation file, in the intended order. I'm not sure if the TES5Edit -steps could be automated also at it's current version, but I do think that with co-operation, batch projects could be implemented in TES5Edit and updated with ease within a single .BAT file on STEP wiki, as the project evolves.

 

The installation order and automatically removed files can be easily kept up to date with the latest S.T.E.P specifications, as the same kind of installation order list can be used for both, the automation process and the S.T.E.P instruction wiki. Also making a switch in the combiner program, to determine if the user wants to combine a HQ or the LQ version, would be possible. A smart switch within the program could determine, that when the HQ option is enbaled, but some HQ packages are missing, LQ versions could be used instead, which adds flexibility for people, who might not be able to run the HQ version of STEP.

 

Basic functionality for a simple version of this kind of combiner could be something like this;

 

-Examine the original mod packages and extract the required folders and files into a unified folder structure. Some mods might not have the \Data folder at the root of the package, so the program needs to be able to look for the \Data folder from within the packages file strtucture.

-Only extract files that are required by the STEP configuration, exactly in the required order.

-OPTIONALLY, STEP could be updated with an updated FOMOD, that could be inserted in the combined mod package, with which the proper installation order could be managed.

 

Keeping the mods up to date coudl also be handled in a following manner;

 

-Make different profiles for the STEP mod list and the combined STEP mods. For example, the list that is meant to keep the mods updated could be called "STEP Mod List" and the STEP installation profile could be called "STEP Installation".

-STEP Mod Combiner -program keeps a list of all the extracted files - what files belong to what mod and what mods overwrite which mod's files, so the Combiner can keep track of every file's installation order, that it extracts and the final order/structure of the combined mods.

-STEP mod combiner could this way have an option to update single mods within this large package, so updating the combined mod package wouldn't take too much time. For example, the program checks from the MO's downloaded mods folder, what mods has two different versions and compares the newer one with the older one. After this, the program determines if other mods down the installation order overwrite some of the updated files and only copies the new files, that are not being overwritten by any mod, that is later installed in the list.

-OPTIONALLY the STEP mod combiner could delete the older version of the mod after combining, if the user so chooses.

 

Taking into account, that this automated process installs only the files that STEP specifications recommend, it can take less time or at least simplify the process of installing STEP precisely as intended, without requireing the user to read further instructions mod by mod basis from the STEP installation instructions.

 

This kind of software could be coded with quite much any programming language, easiest of which might be python and/or java/C Sharp. The basic structure of how this can be done is simple, but the actual coding part could be tricky - which I don't know anything about. Which is why this is only intended as brainstorming about the required processes that the automated combiner would need. I must stress, that this is only a simplified explanation of what the program must be able to do, to achieve the kind of usability and flexibility in order to not need too heavy micro managing from the STEP community.

Posted

STEP is already combining texture mods into a compilation for users to download during the STEP install process. This has so far eliminated several mods from the install process. More will be added, eventually.

  • 5 months later...
Posted

Yes, its still alive and being both maintained and developed.  Heres a video (by Chabal) on SMC for the curious: https://youtu.be/RmVDGa4sfxE

 

It seems to provide a function which may not be within the aims of STEP as one understanding would have it, but it may also provide a degree of flexibility to the guide which would represent the naturalistic side of the project.  *ahem*  sorry i hope I don't regret writing that.  What i mean is that I use STEP as a rough guide rather than a rigid guide.  This thing might help out, especially with textures, allowing a user to pick and choose a whole bunch of different things according to their whim, kind of like a semi-automated 'User's Choice' section.  maybe.  I plan to try it out.

Posted

So, Ive been 'researching' this for a few days, and some of the results are:

 

-The tool looks good, is well documented and up to date.  It offers a way to trade some control for better speed and convenience in the build process.

-Based on this, I have an idea of how I want to use this, and also how it might fit in to STEP, which is to say...

      i) an alternative build path ==Only For Textures==, and textures of a certain sort, i.e. passive, straight-up uncomplicated non-modded and uninvolved attactive window dressing -type textures.  We'll see how that rule goes.

      ii) meaning, used after STEP 2g, after SMIM, but before the Extended Multi-patcher, meaning its supposed to take a good chunk out of STEP 2f, 2g, 2h, and 2k, while adding more flexibility (vis a vis strictly following the step guide) and maintaining dependability.  Theres quite a number of "Detailed Instructions" within those margins which will hopefully be automated to satisfaction by the SMC texture-bot. There are also quite a number of SMIM patches in the texture universe, and the *main* thing Im hoping to achieve is having all applicable textures properly patched back to SMIM, without having to do it myself.

      iii) Im also putting the operation after CACO and its food and potion textures, Radiant and Unique Potions and Poisons, because Im focusing on Alchemy and want to use the CACO-STEP patch after this.  ELFX is also after this operation.

      iv)  It might make a good guide.  Ive also pm'd the mod author and the gentleman from Yamm about this.  A working guide would mean sorting the stuff from the above sections which is able to be covered by SMC from the stuff which should still be handled separately.

 

To that end:

OUT--  SMIM

          SFO

          CoT and all other weather stuff...

 

... anyways, Im still working on this, slowly.  This is just a progress report.

  • 2 weeks later...
Posted

Well, Drigger did get back to me, and he (or she) was very helpful.

 

SMC is a very basic tool. It doesn't do much. It only automates file managing, while *not* checking those files content.  For example, it won't warn you about incompatible .esp with missing masters.

 

So that means I could use it, and I would probably know if it changed anything from SMIM by the display of a conflicting file in MO; but then again, I might not.  I could include SMIM in the SMC operation, but although Drigger has choreographed the merge with the importance of this mod in mind, assigning it "a very high priority", I would still drop below the minimum control threshold I established, as I wouldn't be able to scrutinize SMIM, which is my touchstone or benchmark (in the surveying sense).

 

To continue then, that means that despite the potential here, and it looks like there is some, the number of ways I can actually use this mod are getting fewer and fewer.  I guess if I actually used it for a combination and tried to work with the output, then that envelope might start to open up a little.

 

The bottom line is the author seems to be talented or skilled or however you say it, and the installer is overpowered relative to the task.  That means its nifty to use, but its proper application is limited to the scripted install of a large selection of HD textures and other material; basically the fruit of the authors own Nexus browsing and tinkering sessions in a high-octane package.  Theres absolutely nothing wrong with that, of course.  But its so close to being something more.  A basic category and tag system would instantly make it more versatile; better documentation and tool-tip type info would be great as well.  It already recognizes mod containing scripts, and some other attributes; that's apparently from manual tagging in the .ini, but still... its really nifty, but like a sports car in a well-policed city.

 

Anyways, theres lots of good HD selections here, so thats something to start with.  Personally I have no trouble browsing and selecting mods myself, and actually kind of enjoy it.  Ive moved it much further down in my install sequence, and thats all for now.  -bc

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.