17. February 2013, 14:21:04

#5

ShinobiQuote

I'm thinking something along the lines of what the FMSelect does. But for mods. Would this suffice?

19. February 2013, 00:25:53

#6

❓ VF2013Quote

So what should the application change in install.cfg, precisely?  If I'm reading you right, the proposed system would deviate from installing all mods on top of one another in the DataPerm/TempMods folders, yes?  If so, then should this application write the array to all the lines that reference those folders within install.cfg?

19. February 2013, 00:33:17

#7

VF2013Quote

In fact, scratch that, since the install.cfg options reference different things entirely.  I'm just trying to figure out how it would elegantly adapt to the other options.  I guess adding "\res" for resname_base for each mod folder (and so on) would be one way.  Just seems.. messy.. but then I suppose it's less messy than heaping file upon file in one folder.

19. February 2013, 01:02:38

#8

KolyaQuote

The idea is that you would have one MODS folder and inside it the various mods, each in a folder of their own.

MODS
|_A
|_B
|_C

When the user activates mod "A" the following gets added to install.cfg:
load_path .+.\MODS\A+.\DataTempMods+.\DataPermMods+.\misdml+.\Data

When the user also selects mod "B" but places it after mod "A", the line looks like this:
load_path .+.\MODS\A+.\MODS\B+.\DataTempMods+.\DataPermMods+.\misdml+.\Data

19. February 2013, 01:31:22

#9

ZylonBaneQuote

Is that safe? I thought there was a hard limit on load_path lengths.