Jump to content


Photo

Core Mods Definition


  • Please log in to reply
38 replies to this topic

#1 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 27 November 2013 - 02:07 PM

summary for pre-alpha-release:
*core mods only (the one marked green in the step guide)
*all possible core mod files will be indexed

*always follow STEP guide exactly!
*follow the main STEP guide till STEP 2.D
*baseline only (no low or high)
*choose "recommended" where stated
*all DLCs are required

 STEP:Core Mods - list of filenames
A list of the downloaded files, necessary for a STEP Core install:
http://wiki.step-pro...f_all_core_mods
(currently only fixes, interface, graphics)

a new spreadsheet up with more meta-infos: https://docs.google....YlE&usp=sharing

 
For testing purposes, we need to define a precise setup instruction for the STEP installation we want to achieve.

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).
Some tools might come in handy in terms of extended package management for STEP 2.3+, but no promises yet ;)


If there are choices in a mod setup please post them here.
We will discuss which option we use (if there isn't already any preference mentioned STEP guide).
For our first proof of concept we'll go with an "easier" option that won't put any unnessesary stones in the way.

reminder: stay cool, this is for testing porpuses only. Things will certainly change along the road.
personal comment: I have a good feeling that we can pull this off. No way can I guarantee some full fledged installer! I'm actually quite happy if anything constructive comes out of this. My hopes are that we'll get the basic tools done so others can build upon that.


 STEP:Core Mods that need clarification for POC ASI:

* I'll be adding to the list as I get to them. ~Tech

installer details (MilesTeg):
  • We will just add ALL main-options available where there is still no exact recommendation. e.g. DeadBody fix gets both: spell and no-spell-version.
  • Nitpick will be included for WryeBash etc. compatibility
  • the current list of files (see spreadsheet) uses the wiki and MO for meta information.
  • current file order: 1st sort by name, 2nd sort by nexus fileID, 3rd sort by STEP mod-order

  • 0

#2 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,250 posts

Posted 27 November 2013 - 02:46 PM

As I mentioned on the other thread, the following source is a method to obtain only the currently-applicable Core mods for the current STEP Guide. The method you linked above will pull all Core mods (even those that were Core in previous releases but are no longer). http://wiki.step-pro...by4now/CoreList I vote that you define your POC around all STEP:Core mods from the Current STEP Guide (2.2.7 as of now), and use the query (or its gist) linked above. Use the recommended versions as defined in the mod notes and prefer the Baseline indicated. Where mod notes do not explicitly indicate a recommendation, use your won good judgement ... as long as the final product states explicit choices not evident in the Guide and the corresponding mod notes. I agree with all "aspects" defined above ... assume that you propose to use through STEP 2D as a limited subset for POC?

#3 Kelmych

Kelmych

    Dragon King

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3,808 posts

Posted 27 November 2013 - 03:09 PM

With the introduction of version 2 of the Unofficial Skyrim Patch which includes changes to soul trapping, should the core mods still include ASG and Enhanced Projectile Soul Trap (vs. just the USKP and Smart Souls)?

#4 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,250 posts

Posted 27 November 2013 - 03:16 PM

[quote name=''Kelmych' pid='59334' dateline='1385582999']With the introduction of version 2 of the Unofficial Skyrim Patch which includes changes to soul trapping' date=' should the core mods still include ASG and Enhanced Projectile Soul Trap (vs. just the USKP and Smart Souls)?[/quote']
Not sure. I would ask WilliamImm

#5 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 27 November 2013 - 03:45 PM

I have been thinking more about what an automated STEP should do, and I think we should default in most instances not the the baseline STEP, but to the high end STEP. I think 2048 resolution texture options where available, and never above. I want to look into using command line scripts with DDSOpt to dynamically size the textures in a STEP install to to match what the user can support with their hardware. For example, before a STEP install begins the user will be prompted to enter how much video memory their graphics has. For 2gb, we might leave everything sized at 2048 resolution, for 1gb we might size everything to 1024, and for >1gb maybe we downsize to 512 or selective particular mods textures, ect. In my opinion, texture optimizing is essential to a higher performance and stable version of STEP no matter the hardware or configuration (especially if we are talking about memory limits), and the tool already exist to automate that. Lets put that in ASI.
  • 0

#6 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 27 November 2013 - 04:15 PM

Ah, thx for spotlighting the error :) Was in a bit of a hurry and didn't notice it. Of course there should've been the mods listed from the current STEP guide. And sorry, but customizing that template/ Ask query is beyond me...:confused: Isn't there some property tag like "STEPVersion" ?? I would like the results in the same order as seen in the STEP guide and maybe add some more columns as meta info. And yes, my approach will be close to original STEP.
  • 0

#7 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 27 November 2013 - 04:34 PM

I have been thinking more about what an automated STEP should do, and I think we should default in most instances not the the baseline STEP, but to the high end STEP. I think 2048 resolution texture options where available, and never above.

As much as I would want the best of the best, I don't think most of our target audience has 2 gigs of vram.
e.g.: I only have 1 gb vram and it a high quality default for a proof of concept would be a bit counterproductive if some of us developers would be unable to test it.

btw: From what I have read it is also scraping the memory limits of 2 gig if you only use the high quality textures. And how does stability increase if you use higher resolution textures?

I actually first thought about using the low quality settings as they are much better in quality:performance ratio. But then again, I think there are some who will try this alpha even if it's in an infant state and the best compromise seems to be baseline.

All that said, yes, we will have an option/profile for high quality. It's probably just as inevitable as a DLC/vanilla version. And if someone writes such a config, all power to him! But it just won't fit in this testing environment.
  • 0

#8 Kelmych

Kelmych

    Dragon King

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3,808 posts

Posted 27 November 2013 - 05:13 PM

I have been thinking more about what an automated STEP should do, and I think we should default in most instances not the the baseline STEP, but to the high end STEP. I think 2048 resolution texture options where available, and never above. I want to look into using command line scripts with DDSOpt to dynamically size the textures in a STEP install to to match what the user can support with their hardware. For example, before a STEP install begins the user will be prompted to enter how much video memory their graphics has. For 2gb, we might leave everything sized at 2048 resolution, for 1gb we might size everything to 1024, and for >1gb maybe we downsize to 512 or selective particular mods textures, ect.

In my opinion, texture optimizing is essential to a higher performance and stable version of STEP no matter the hardware or configuration (especially if we are talking about memory limits), and the tool already exist to automate that. Lets put that in ASI.

I agree that texture optimization would be useful, and I've been building batch files to do a lot of the processing for this with both vanilla textures and, more recently, those from mods. For a number of reasons, I suggest not including automated optimization in at least the initial automated STEP installer:
* the command line version of DDSopt is fairly limited and doesn't currently support use of a lot of the options and parameter settings needed in optimization; it would require changes to DDSopt code to support this.
* existing command line usable BSA tools that I'm aware of can't be used to extract Skyrim BSAs (adding this to BSAopt, for example, would require code additions).
* limiting the optimization to a single choice based on VRAM seems attractive, but there are other factors that affect the best optimization resolution choices including the characteristics of other mods being used in addition to the STEP mods. Moreover, with some mods the version of the mod being used depends on resolution desired; in a fully automated optimization system the user might then need to include all versions of the mod in the installation process.
* properly handling uncompressed textures to preserve their quality isn't currently straightforward, although availability of some new code that could extract some important texture file parameters on the fly would allow straightforward processing of these.

I've been testing the batch files, which can work with large sets of mods in each processing run, for optimization with the core STEP mods that have textures and that are appropriate to optimize (i.e., some mods are already sufficiently optimized). The entire set of these STEP core mods can be optimized in a single process in well under an hour even when using an HDD. I haven't measured the time for rearchiving all the mods with 7zip yet; this is done in a single process with no user interaction once started.

#9 Barthanes

Barthanes

    Prisoner

  • Members
  • 42 posts

Posted 27 November 2013 - 06:13 PM

Has anyone spoken with Drigger182 from SKyrim Texture Pack Combiner? http://code.google.com/p/skyrim-tpc/ This is a windows based app & he may be willing to share the code to make some sort of automated extraction system for doing the texture mods at least. I'm not a programmer but this GUI app does in a very user friendly way list the mods needed, extracts them, optimizes with DDSOPT, (not sure how at what resolution though) & repacks as either loose or BSA into a 7zip file. I'm guessing with some tweaking it could be converted into a STEP system for doing the textures or maybe more. If there was a way to choose the system resolution you want (video card memory of course being the key factor), the STEP version (core, core/extended) and maybe even some Packs, run the program & viola your done. It cant be to hard to have the program archive it for use with MO. I know the guys over at ASI are working hard on something kinda similar, but maybe this GUI would give them some ideas or help in some way. Big fan of SkyrimTPC even though I only use it for testing because it's not part of STEP. Just wanted to throw that out there in case it might help.
  • 0

#10 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 27 November 2013 - 06:27 PM

I have been thinking more about what an automated STEP should do, and I think we should default in most instances not the the baseline STEP, but to the high end STEP. I think 2048 resolution texture options where available, and never above. I want to look into using command line scripts with DDSOpt to dynamically size the textures in a STEP install to to match what the user can support with their hardware. For example, before a STEP install begins the user will be prompted to enter how much video memory their graphics has. For 2gb, we might leave everything sized at 2048 resolution, for 1gb we might size everything to 1024, and for >1gb maybe we downsize to 512 or selective particular mods textures, ect.

In my opinion, texture optimizing is essential to a higher performance and stable version of STEP no matter the hardware or configuration (especially if we are talking about memory limits), and the tool already exist to automate that. Lets put that in ASI.

I agree that texture optimization would be useful, and I've been building batch files to do a lot of the processing for this with both vanilla textures and, more recently, those from mods. For a number of reasons, I suggest not including automated optimization in at least the initial automated STEP installer:
* the command line version of DDSopt is fairly limited and doesn't currently support use of a lot of the options and parameter settings needed in optimization; it would require changes to DDSopt code to support this.
* existing command line usable BSA tools that I'm aware of can't be used to extract Skyrim BSAs (adding this to BSAopt, for example, would require code additions).
* limiting the optimization to a single choice based on VRAM seems attractive, but there are other factors that affect the best optimization resolution choices including the characteristics of other mods being used in addition to the STEP mods. Moreover, with some mods the version of the mod being used depends on resolution desired; in a fully automated optimization system the user might then need to include all versions of the mod in the installation process.
* properly handling uncompressed textures to preserve their quality isn't currently straightforward, although availability of some new code that could extract some important texture file parameters on the fly would allow straightforward processing of these.

I've been testing the batch files, which can work with large sets of mods in each processing run, for optimization with the core STEP mods that have textures and that are appropriate to optimize (i.e., some mods are already sufficiently optimized). The entire set of these STEP core mods can be optimized in a single process in well under an hour even when using an HDD. I haven't measured the time for rearchiving all the mods with 7zip yet; this is done in a single process with no user interaction once started.

What exactly are the limitations in the DDSOpt command line? At some point do you think I could have a look at your batch file just to get an idea of how it works? 

Also, isn't the author of DDSOpt working on BSA optimization, similar to what is already in place with optimizer textures? At any rate, I can't see the harm in optimizing loose file texture, as that is nearly all of the STEP textures anyway. The optimization scheme doesn't have to be sophisticated; basically the equivalent of "optimize the entire mods folder and all sub folders with texture upper bound 1024" would be great. The desired state of an automated STEP is usable and error free, not necessarily optimal or even of the highest quality. 

We could argue about what the details for optimization could be; maybe some mods get the DDSOpt treatment and some don't, and maybe some are downsized based on hardware specifications and some aren't, ect. My main point is if we can incorporate DDSopt, lets do it, and if we are going to do texture re sizing, lets direct the user to download one set of texture and use DDSopt to fit the size of the texture to the user, instead of restricting people with higher end graphics to lower res textures or people with lower end graphics to higher res textures, ect. 

Barthanes, I haven't looked at the TPC source code, but it is my understanding that it uses a scripting algorithm similar to the one I used for the current ASI beta. We are trying to move away from this approach because of the limitations of that kind of algorithm.
  • 0

#11 Kelmych

Kelmych

    Dragon King

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3,808 posts

Posted 27 November 2013 - 07:28 PM

What exactly are the limitations in the DDSOpt command line?
It's been a while since I looked; I found it using a Google search. I think it was on his Github pages. I remember that there are only a few switches and they are shared with BSAopt. None of the menu-selected DDSopt parameters is available for setting via command line.

At some point do you think I could have a look at your batch file just to get an idea of how it works? 
The archive file that includes the batch files for vanilla and mod optimization is posted in the DDSopt guide near the top of the page; the pointer is updated when the file is updated. The mod optimization batch file is still evolving as I determine how best to handle uncompressed textures in mods.

Also, isn't the author of DDSOpt working on BSA optimization, similar to what is already in place with optimizer textures?
Ethatron hasn't been able to do much this year at all because of work, but he seemed to primarily be working on better optimization of difficult textures and not on anything like Optimizer Textures. He was also working on allowing BSAopt and DDSopt to accept 7zip archives as input. His most recent work involved GUI improvements.

At any rate, I can't see the harm in optimizing loose file texture, as that is nearly all of the STEP textures anyway. The optimization scheme doesn't have to be sophisticated; basically the equivalent of "optimize the entire mods folder and all sub folders with texture upper bound 1024" would be great. The desired state of an automated STEP is usable and error free, not necessarily optimal or even of the highest quality. 
I'm not sure everyone using STEP would agree with these comments on lack of need for quality; that's one of the disagreements z and I have with your comments when you are recommending Optimizer Textures.

We could argue about what the details for optimization could be; maybe some mods get the DDSOpt treatment and some don't, and maybe some are downsized based on hardware specifications and some aren't, ect. My main point is if we can incorporate DDSopt, lets do it, and if we are going to do texture re sizing, lets direct the user to download one set of texture and use DDSopt to fit the size of the texture to the user, instead of restricting people with higher end graphics to lower res textures or people with lower end graphics to higher res textures, ect. 
If a tool were available that allowed on-the-fly configurable high quality optimization it would probably make sense to use it in an automated installation scheme. DDSopt isn't there and it will be a while before it is there since that isn't its primary design goal. I also feel it's hard enough to get a good automated installation tool developed, and adding texture optimization at the initial stages (vs. later) is feature creep.


Barthanes, I haven't looked at the TPC source code, but it is my understanding that it uses a scripting algorithm similar to the one I used for the current ASI beta. We are trying to move away from this approach because of the limitations of that kind of algorithm.



#12 TechAngel85

TechAngel85

    Akatosh

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 11,936 posts

Posted 27 November 2013 - 08:22 PM

[quote='z929669' pid='59336' dateline='1385583417']
[quote name=''Kelmych' pid='59334' dateline='1385582999']With the introduction of version 2 of the Unofficial Skyrim Patch which includes changes to soul trapping' date=' should the core mods still include ASG and Enhanced Projectile Soul Trap (vs. just the USKP and Smart Souls)?[/quote']
Not sure. I would ask WilliamImm[/quote]
This has already been brought up in the this thread: http://forum.step-pr...=55489#pid55489

William now uses Smart Souls and I'm thinking we might do this same for 2.2.8. I will be putting Smart Souls into testing.

#13 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,250 posts

Posted 28 November 2013 - 12:53 AM

[quote='Barthanes' pid='59378' dateline='1385594019']Has anyone spoken with Drigger182 from SKyrim Texture Pack Combiner? http://code.google.com/p/skyrim-tpc/

This is a windows based app & he may be willing to share the code to make some sort of automated extraction system for doing the texture mods at least. I'm not a programmer but this GUI app does in a very user friendly way list the mods needed, extracts them, optimizes with DDSOPT, (not sure how at what resolution though) & repacks as either loose or BSA into a 7zip file. I'm guessing with some tweaking it could be converted into a STEP system for doing the textures or maybe more. If there was a way to choose the system resolution you want (video card memory of course being the key factor), the STEP version (core, core/extended) and maybe even some Packs, run the program & viola your done. It cant be to hard to have the program archive it for use with MO. I know the guys over at ASI are working hard on something kinda similar, but maybe this GUI would give them some ideas or help in some way.

Big fan of SkyrimTPC even though I only use it for testing because it's not part of STEP. Just wanted to throw that out there in case it might help.[/quote]
This is a bit OT here and should be addressed in the Semi-Automated STEP thread. Let's continue that discussion there if anyone is inclined to follow Drigger's solution devel. I am inclined to think that it could provide some useful ideas, but the current progress of MTeg and MGoose seems to be worthy of pursuit right now.
[quote='techangel85' pid='59397' dateline='1385601721']
[quote='z929669' pid='59336' dateline='1385583417']
[quote name=''Kelmych' pid='59334' dateline='1385582999']With the introduction of version 2 of the Unofficial Skyrim Patch which includes changes to soul trapping' date=' should the core mods still include ASG and Enhanced Projectile Soul Trap (vs. just the USKP and Smart Souls)?[/quote']
Not sure. I would ask WilliamImm[/quote]
This has already been brought up in the this thread: http://forum.step-pr...=55489#pid55489

William now uses Smart Souls and I'm thinking we might do this same for 2.2.8. I will be putting Smart Souls into testing.[/quote]
Sounds like a plan. Thanks 

Finally RE the "aspects" in the OP and MGoose's ideas about not using Baseline STEP:
The STEP ASI solution will need to address Baseline STEP, without deviation. Baseline STEP:Core is the culmination of the result of a lot of testing and input from the STEP team and some community members. It represents a "safe baseline" for any system, and given what we have learned about texture optimization, the 4 GB memory threshold, scripting burden, etc., it would be counterintuitive not to adhere absolutely to the STEP Baseline whenever it is defined. Everyone's system is addressed, and STEP caters to persons with mid-end systems and entry-level modders. Wherever there is any question about the Baseline definition of any Mod on STEP, it would be better to address on that mods wiki Discussion page or the corresponding mod page in the STEP Mod Anthology forums.

I agree with everything Kelmych states above in relation to texture optimization. This will be a manual process that is best handled by the batch scripts that we devised, and I defer to Kelmych on that evolution. Mod-specific texture opt is currently in development and slated for inclusion into SMW at some point, but that is too big to tackle in the near future.

The preferable approach that STEP staff and several community members have traditionally taken is to reach out to the mod authors on the Nexus, invite them here for reference and discussion, and ask them to produce "corrected" or "modified" versions of their mods in order to obviate any special instructions on our side and reduce the burden to the end user. If we have knowledge, it is best to share it and work towards fixing the source (this includes texture optimization and mod variations of any kind). Some of our team actually help several mod authors maintain their mod pages towards this goal, myself included (e.g., Soul Gems Differ, Terrain Bump, SFO). Where authors are not responsive, it is often possible to re-upload corrected versions of mods ourselves (Farlo redid Dragon Glyphs, and WilliamImm has revised, re-uploaded and contributed to a whole slew of Nexus mods for this project and the modding community at large ... which is essentially the purpose of STEP).

Anyone that is willing to politely approach authors on behalf of STEP is welcome to do so. Feel free to direct them to Techangel, z929669, Kelmych and/or WilliamImm at any time to improve their product or get them involved in the conversation on this site.

#14 mothergoose729

mothergoose729

    Thane

  • Members
  • PipPipPipPipPipPip
  • 462 posts

Posted 28 November 2013 - 03:27 AM

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.
  • 0

#15 MilesTeg

MilesTeg

    Citizen

  • Members
  • Pip
  • 91 posts

Posted 28 November 2013 - 09:47 AM

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 :)
  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users