Jump to content


Photo

Automated STEP Installer - Now in Beta


  • Please log in to reply
191 replies to this topic

#166 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 25 November 2013 - 01:03 AM

[quote='z929669' pid='58723' dateline='1385090381']If you guys build a complete config for STEP:Core, I will place that and MGs latest revision of ASI-beta onto the Nexus with instructions and credit to you two ;)
[/quote]

Sure, you'll be free to go from my side (once I have finished s.th.) :-)
 
[quote name=''mothergoose729' pid='58710' dateline='1385081467'] I would be willing to do the hardest part' date=' which is the special archive mods[/quote']

This skymerge tool should come in handy for this. I'll have to check it out. Maybe it could ease the process of creating the necessary copy commands...
  • 0

#167 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 25 November 2013 - 02:05 AM

Don't think so on the skymerge. My program is "top down" sort of approach, while skymerge is a "bottom up" one. Right now, the two don't really compliment each other.
  • 0

#168 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 25 November 2013 - 03:01 AM

It's a bit frankenstein, what I do here: Oh, the heart of BCF-loading in WryeBash source? nice SkyMerge/skyrep file repository comparims. cool! Now mix some MO here and there. Add one drop of Python and three spoons of Bash and you got... Frankensteins Monster ;) Well, at least I try s.t.h like that to get a proof of concept...
  • 0

#169 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,313 posts

Posted 25 November 2013 - 03:11 AM

I'll keep watching this thread ... don't forget to check the thread you linked previously for my post over there with more info.

#170 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 25 November 2013 - 03:45 PM

Hey if you know your way around any of that you are welcome to try your hand and writing something for automated STEP yourself. Monty called it "an open source free-for-all" and I rather like that term. Feel free to go whatever direction suites you.
  • 0

#171 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 25 November 2013 - 04:45 PM

Hey if you know your way around any of that you are welcome to try your hand and writing something for automated STEP yourself. Monty called it "an open source free-for-all" and I rather like that term. Feel free to go whatever direction suites you.


well, then...

I just went from this
q]qŠ5U"a…Rq….€(Xq (...)



to this:
(3093275702L, (570578229L, u'Docs\\HQ3DMap\\After 1.png'), u'00 CORE\\Docs\\HQ3DMap\\After 1.png'),
(1563707087, (570578229L, u'Docs\\HQ3DMap\\After 2.png'), u'00 CORE\\Docs\\HQ3DMap\\After 2.png'),
(1135995451, (570578229L, u'Docs\\HQ3DMap\\Before 1.png'), u'00 CORE\\Docs\\HQ3DMap\\Before 1.png'),
(1198962732, (570578229L, u'Docs\\HQ3DMap\\Before 2.png'), u'00 CORE\\Docs\\HQ3DMap\\Before 2.png'),



3 hours of exessive fiddling... not wasted, phew ;)
Anyway, .bcf files are to ready to use/read 8)

That's probably also usable as Mod Organizer plugin-code (did it in python).

Basically it's a mini-tool that does the same .bcf reading as wryebash, but comes in 10 kb:)

I must admit it's just a blunt ripoff from Wrye Bashs source code, but it works independently! And going through 1,5 MB pure code - THAT was "fun" :wallbash::wacko:
  • 0

#172 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,313 posts

Posted 25 November 2013 - 05:40 PM

So this fits into MG's code or Monty's code? Glad you were able to use the WB source. That is a lot of code to muddle through ...

#173 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 25 November 2013 - 08:13 PM

It works with MGs ASI and practically replaces Montys attempts: It means we can use Wrye Bash to create all copy commands necessary e.g. for all packages with install routines. You just - move the files with windows explorer/install the mod with MO/WryeBash (following the STEP guide to the letter), - create a BCF with Wrye Bash (it automatically stores the file movements) - and with a script (I still have to finish) we get configs's for MGs ASI :) It will extremly simplify the work for all more complex core-packages. Now, with the right documentation, anyone who can create a BCF could commit to the ASI project.
  • 0

#174 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 25 November 2013 - 08:46 PM

I don't want to discourage you at all, so don't take it that way, but what you are describing is serious overkill, in the magnitude of firing a nuclear missile to kill a mosquito. Generating a long list of copy commands for 1 mod at a time would be every bit as time consuming, if not more so, then just writing four or five copy commands to move entire folders at at time within my program. The value of monty's approach is that a config would not be necessary at all to automate step, at least to automate exactly 1 specific configuration of STEP at at time. If you can get as far as to create a list of copy commands for each file of 1 mod, the holy grail is to create a list of copy commands for every file from all the mods. My program would be unnecessary at that point. If I misinterpreted you lease correct me. Again, don't let me discourage you from whatever you are doing, only trying to offer some helpful input. Btw in that scheme, the most helpful command would be a file level extraction from archives with 7z command line. Something like "7z e archive.zip -o_outputdir [file]". Keep us informed, really like curious to see what you come up with.
  • 0

#175 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,313 posts

Posted 25 November 2013 - 09:40 PM

I am reserving any comment until I see exactly what MT's solution entails. The only think that I don't like is that it sounds like it is reliant on bash.py (i.e., Wrye Bash), and the solution would best be a single plugin for MO (somebody needs to create a 'Bash' patcher plugin for MO so that users are not required to use WB at all, given that the WB Bashed Patch has limited functionality anyway ... using WB for this is indeed overkill from an MO-user standpoint).

Anyway, I couldn't care less if there is programmatic overkill at this point ... just want to avoid 'human'-rogammatic overkill.

EDIT: See link in this post.

#176 torminater

torminater

    Dragon Prince

  • Contributors
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2,222 posts

Posted 26 November 2013 - 02:55 AM

Actually I like the file by file version better, but if it could be combined with the folder move that would be awesome. 1) This way modding Skyrim on a very detailed scale will be possible in split-seconds (At least the installation of a pre-made config). File by file will require that a specific version of a mod is chosen and the exact same package as was installed by the config generator downloaded and used with the installer. 2) If the user wants to implement a newer version of the mod, when first setting up his Skyrim install, he could tell the program to install the "unidentified package" on a folder move base via one mouse-click, or if the UI permits choose his own files from the package to install.
  • 0

#177 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 26 November 2013 - 12:01 PM

Actually I like the file by file version better, but if it could be combined with the folder move that would be awesome.
1) (..) File by file will require that a specific version of a mod is chosen and the exact same package as was installed by the config generator downloaded and used with the installer.

I see two approaches for a ASI (EDIT: talking about STEP CORE only! ;) ) :
- FullAutoInstall - Creates one big 7z mod file, which could also include bashed patch actions. Advantage would be a One-Click install. This DEFINITELY needs CRC-Checks for every file.
Problem arises if the user wants to update their mods. With MO this might be not such a big problem as you could just switch back to a "vanilla"profile of skyrim and start over. And of course it's always a bad idea if you change mods midgame...
This method would be a good solution for beginners, who just want to "update" their skyrim game, or want to create a one-playthrough game with a stable modbase.
- AdvancedInstall - Leaves the file-separation untouched. Changes filenames (and internal structure, if necessary). more flexibility but less quit install.
more on that one later
  • 0

#178 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 26 November 2013 - 01:34 PM

Actually I like the file by file version better, but if it could be combined with the folder move that would be awesome.

1) This way modding Skyrim on a very detailed scale will be possible in split-seconds (At least the installation of a pre-made config). File by file will require that a specific version of a mod is chosen and the exact same package as was installed by the config generator downloaded and used with the installer.
2) If the user wants to implement a newer version of the mod, when first setting up his Skyrim install, he could tell the program to install the "unidentified package" on a folder move base via one mouse-click, or if the UI permits choose his own files from the package to install.


This is already possible in ASI but the problem isn't giving the STEP team more control, the problem is that the automated installer needs to take essentially zero maintenance. If you are curious have a look at the beta, all the file operations you want are there, in the simplest and most direct forms. 

The ability to add an unspecified mod to the install order is possible but I question the need for it. Automated STEP is for people who want the quickest modded skyrim possible. A high level of flexibility and user control is for people who would follow the original guide. It is possible to include some subtle variation in install order though, such as the user can leave out mods they don't want, and the the config can be made flexible enough to include different versions of the same mod, such as DLC support, ect. Again, maintenance is the problem, not the level of control or the sophistication of the installation procedure. 

Actually I like the file by file version better, but if it could be combined with the folder move that would be awesome.
1) (..) File by file will require that a specific version of a mod is chosen and the exact same package as was installed by the config generator downloaded and used with the installer.

I see two approaches for a ASI (EDIT: talking about STEP CORE only! ;) ) :
- FullAutoInstall - Creates one big 7z mod file, which could also include bashed patch actions. Advantage would be a One-Click install. This DEFINITELY needs CRC-Checks for every file.
Problem arises if the user wants to update their mods. With MO this might be not such a big problem as you could just switch back to a "vanilla"profile of skyrim and start over. And of course it's always a bad idea if you change mods midgame...
This method would be a good solution for beginners, who just want to "update" their skyrim game, or want to create a one-playthrough game with a stable modbase.
- AdvancedInstall - Leaves the file-separation untouched. Changes filenames (and internal structure, if necessary). more flexibility but less quit install.
more on that one later

I plan on adding MO integration to ASI as soon as I have time. I think it might be possible to add mods into MO exactly as MO does it using the meta files. This would allow the users to have the same level of control and features they would have if they did the installation through MO themselves. ASI, in its current form, however, cannot be updated and individual components cannot be removed, that is true. 

The idea of editing the archives and letting them install each component themselves is an interesting one. It would take some tweaks to my program, but it is certainly possible. Would have to meditate on it. My biggest aversion to that scheme is that I question who would that kind of setup appeal to? Its not a once click and be done kind of approach, and its not the full level of control of a manual installation either, so I question if its worth doing that way. Don't know just yet. 

At any rate, some great ideas. Again don't let me discourage you from any projects you want to pursue, just offering my opinions. 
  • 0

#179 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 26 November 2013 - 02:20 PM

I think it might be possible to add mods into MO exactly as MO does it using the meta files. This would allow the users to have the same level of control and features they would have if they did the installation through MO themselves.

we're talking the same language here :) The meta files are very easy to edit (simple ini structure), ASI will "install" the mods in the same way MO does it: extracting the archives and editing the meta and project files. This way MO won't tell the difference and it can treat the mods like usual. I've already used the MO meta files to read out the nexus titles of each individual core file... It's actually extremely easy in python to handle INIs, so that should'nt be a problem at all. I really think that should be the next priority after setting the core configs.

I'm still thinking about a proper way to handle complex archives. The easiest should be:
- Install a mod (wrye bash, MO, manual, doesn't matter),
- let a tool (similiar to skyre) compare changed file structures with the original archive
- and write those changes to a (config) file, ready to use for ASI

This would minimize maintenance.

That's the reason why I'm so interested in BCF files. Wrye Bash has a very solid way of keeping track of those filemovements etc. While I'm not sure if the code should be used for ASI, the similiarities are striking:

it's just a small step from
(1563707087, (570578229L, u'someSetupDir\\file.esp'), u'destinationDir\\file.esp'),
to
supercopy "someSetupDir\\file.esp" "destinationDir\\file.esp"

  • 0

#180 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 26 November 2013 - 03:18 PM

They way I would handle it is to create a data file for each and every mod. Right now my program creates 1 data file, it could be made to make any number of data folders. The meta files could either be included in the download and moved where they need to go, or could be generated by the program if they are simple enough, either way should work. But yeah, I think we are talking about the same things.
  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users