projectinfinity Sorting Order feature - how to share you PI install order

[AL|EN]

Hi,

First, I would like to say that it is not a discussion about defining correct install order for mods, it's for creating a system which can define such install order and be applied to already selected mod list.

Recently, I'm dealing with Install Order/Install Sorting for my tool and notice few things:

Naturally, the first source of the install order is Weidu.log. But it never worked, it must be a reason why nobody created a nice community 'install order' list which use weidu.log data. I think that is very ineffective when it comes to Install Order/Install Sorting because it contains exact numbers of the components - any mod change/update will make such list obsolete. Also for the case when mod will have completely new components, old weidu.log won't have it.

The second source is the BWS installorder.ini file. It is also not a good source because this file is not only the install order. At the same time is also a 'list of mods which user can install'. Players cannot simply change it because any 'online update' made by BWS maintainers will overwrite player changes. If he won't update, he will miss new mods//changed components. Such design works only if you have 24/7 maintainer of the mods/components and the exact order which they are installed.

The more I think about how many things are affected by the fact that mod components are actual 'mods which can change the ID several times a day' the more dealing with it becomes scary.

So I was thinking how to make something which will be effective, easy to use and will avoid unnecessary edits. This is an idea which I want to discuss with you:

1. Part of BWS installorder.ini file, definitely outdated, posted as example: https://pastebin.com/PkjTkyxB - you can see how big such list can be when you need to deal with exact component numbers.

2. Definition of the custom file format:

- you can use spaces or commas to separate components, doesn't matter

- mod example: ModA components numbers are 1, 2, 100 and 200 (just an example, they can be any amount of numbers)

3. Definitions:

 - ModB, component 1 and 2 and 100 and 200 will be placed before ModB component 11, 22 and 33

ModA 1 2 100 200
ModB 11 22 33

- all components of ModA will be placed before all components of ModB. Mod updates, changes to index/designated or even adding new components won't break sorting.

ModA *
ModB *

ModB, component 1 will be placed before all components from ModC, ModB component 2 will be placed after all components from ModC. Mod updates will affect such entry but not every time, updates/changes to the components of ModC won't break sorting.

ModB 1
ModC *
ModB 2

- ModA, components 1 and 2 will be sorted. Even if the definition has '*', there are explicitly defined component at the end of the list, so those will be not sorted now
- ModB, component 1 will be sorted
- ModC, all mod components will be sorted
- ModB, component 2 will be sorted
- ModA, components 100 and 200 will be sorted because those are explicitly defined

ModA * 
ModB 1
ModC *
ModB 2
ModA 100, 200

 

3.Examples

Example 1: the same BWS Install Order/Install Sorting List as posted above, defined using custom format:

jimfix 0, 1, 100 # component 0, 1, 100 will be placed into install order list because those are explicitly defined
npc_tweak * # all components will be placed into install order list because there isn't any explicitly defined component
stratagems 1000 5900 6000 6010 6020 6021 6022 6023 6024 6030 6031 6032 6033 6034 6040 6041 6042 6043 6044
celestials *
spell_rev *
Faiths_and_Powers *
TomeAndBlood *
iwdification  *
wildmage *
iwdification 60 # component 60 will be placed into install order list because it's explicitly defined
hammers *
UnofficialItemPack
item_rev *
Divine_Remix * # components 10,11,100,103,106,107,109,112,115,118,121,124,127,130,200,203,403,406,409,412,415 will be placed into install order list
DR8_hotfix *
song_and_silence *
RR 0, 1, 2, 3, 4 ,5 ,6 ,7, 8 # components 0,1,2,3,4,5,6,7,8 will be placed into install order list because those are explicitly defined
A7-GolemConstruction *
A7-ChaosSorcerer *
might_and_guile *
IHateUndead *
willowisp *
cdtweaks * # all cdtweaks components will be placed into install order list because there isn't any explicitly defined component
Divine_Remix 1000 # component 1000 will be placed into install order list because those are explicitly defined
AnimalCompanions *
shadowadept *
sword_and_fist *
refinements *
scales_of_balance *
stratagems * # all remaining SCS components will be placed into install order list
jimfix 2,3,4,5, 400
RR 9, 10, 11, 12, 999
atweaks *
scales_of_balance 180 # SoB 180 after SCS and aTweaks PnP fiends
klatu *
jimfix 201,202,203, 204, 205, 300 

Notice that for eg: Divine_Remix has component 1000 nicely defined as explicit while all other components aren't defined by exact number. In case of adding new kits, such install order definitions will be unaffected and it won't require 24/7 maintainer.

Example 2: more general install order for EET:

[Language]
bg2eetrans *
bg2eePL *

[Fixes]
BWFixpack *

[Enhanced Edition Trilogy]
EET *

[Quests]
bgqe *

[NPC]
Sirene *

[NPC-Related]
BG1NPC *

[Items]
item_rev *

[Spells]
spell_rev *

[Kits]
Divine_Remix *
Faiths_and_Powers *
TomeAndBlood *
might_and_guile *

[Tweaks]
cdTweaks *
scales_of_balance *
Refinements *

[AI]
stratagems *

[aTweaks]
aTweaks *

[Worldmap]
Worldmap *

[Enhanced Edition Trilogy End]
EET_End *

[Sounds]
HQ_SoundClips_BG2EE *

[Portrait]
PPE *
thepicturestandard *

[UI]
recoloredbuttons *
LeUI *
EEUITweaks *

Using such general install order as a base/foundation, player or modder can easy discover proper(but not ideal) install order for new mods.

So install order list can be compressed from over 700 lines to 36 and it for most cases, it's unaffected by changes to component numbers/designated so it won't require 24/7 maintainer.

Such definitions also fits very well for online Excel or Google Docs where you can put comments at the specific lines.

 

Converting weidu.log, BWS install order or even BWP PDF to such list is very easy and offers much less work for updating it. Install Order/Install Sorting lists for smaller amount of mods can use '*' for all mods and be pretty much unaffected all the time.

 

Player would simply choose their mods/mod components, add them to the 'mod installation list' and then load from file and apply 'install order' which will sort know mods. The mods which wasn't included inside install order list would simply be mover at the end, for review.

 

4. Possible improvements:

• ability to define component ranges: [0..100] = components from 0 to 100 will be placed into install order list, the [x..y] construct is the same as for defining array ranges

• ability to define component ranges with only starting point:

Quote

ModA [0..*] = components from 0 to "first explicit component number" (100) will be placed into install order list

ModB *
ModA [100..*] = components from 100 to "first explicit component number" will be placed into install order list, if the definition is the last one for specific mod, it practically means "from 100 to all remaining mod components"

 

• instead of explicit component number (DESIGNATED), such list can support using LABELS (but modders are allowed to change those without complainants from others) or GUIDS (not implemented yet) and be even more protected from mod changes, but only if there is one explicitly added for sorting order, example:
  the AI components of SCS (5900,6000,6010,6020,6021,6022,6023,6024,6030,6031,6032,6033,6034,6040,6041,6042,6043,6044) could have additional "InstallOrder-AI" LABEL/GUID so it could be used for sorting order. But not without cooperation from the mod author itself.

 

5. Weak points:

• it's still based on DESIGNATED numbers for important parts (SoB 180 after SCS and aTweaks PnP fiends)
• the '*' definition covers all future new mod components which could require different install order

Any feedback is welcomed.

Edited December 24, 2019 by AL|EN

[DavidW]

It's not clear to me that this is much of an improvement on the weidu.log. It doesn't seem to address the problems with weidu.log you identify; the only advantages I can see are

 

1) * catches new components, but that's a mixed blessing at best since who knows if you wanted to include the new components in your install anyway, or even if you did, where they would go?

 

2) It's somewhat more compressed than weidu.log - but I don't see that's particularly helpful in practice. This is a file to be consumed by an autoinstaller, after all, not human-readable, and 700 lines is still trivial in terms of overall install space.

 

Against that, a weidu.log file is a guarantee that the particular install actually worked.

[AL|EN]

It's not clear to me that this is much of an improvement on the weidu.log. It doesn't seem to address the problems with weidu.log you identify; the only advantages I can see are

 

1) * catches new components, but that's a mixed blessing at best since who knows if you wanted to include the new components in your install anyway, or even if you did, where they would go?

My 'install order list" will never add or remove mods. So the only weakness is when a player wanted to install new mod components but those components suddenly are required to be installed "after worldmap" etc. But it is no different from manual mod installation when player face new mod components (because mod was updated) and decide to install them anyway. If such extra components will require separate position at the install order list, maintainer of such list can simply add "modX x y x" at the correct place/position. If the "spells mod" will add new components with extra spells, or "item mod" will add new components with new items, there won't be a problem with '*'.

At any given time, install order list can switch to "explicitly defined components" like 1, 2, 100 so when new mod components are found, those will be placed at the end of the install order and require player to move them where he think they fit best/read readme.

2) It's somewhat more compressed than weidu.log - but I don't see that's particularly helpful in practice. This is a file to be consumed by an autoinstaller, after all, not human-readable, and 700 lines is still trivial in terms of overall install space.

 

On the contrary, the intention is to be human-readable so anyone could prepare such list for general usage. It's an attempt to define install order recommendations like "Install kit mods before SCS", "install Fixpack as first mod", "install UI mods at the end" with a possibility to also take into consideration all exceptions like "RR components from 0 to 8 before SCS and components from 9 to 12 after SCS". Also for all "NPC cross-banter install recommendations" - mod Readme are full of "install NPC X before NPC Y if you want to have cross-banters" instructions. Weidu.log data can't be effectively used for such definitions.

In order to be even more human-readable, ini sections can be introduced for the purpose of collapsing whole group of mods/components types like [NPC], [items], [spells], [uI] etc

Against that, a weidu.log file is a guarantee that the particular install actually worked.

 

Only if those conditions are fulfill:

- it's for the same game

- mod versions are the same

- selected mods are exactly the ones from wiedu.log

So weidu log is not only install order it also list of components of specific version, for one game, bound to such order. If any of those elements will be altered, installation might fail. One failed installation attempt is not a big deal and it can bring new feedback for modder regarding the components, which needs to be installed 'after/before mod x or else something is broken".

Edited November 8, 2018 by ALIENQuake

[DavidW]

Okay, I think we have different conceptions of what's good design here.

 

2) It's somewhat more compressed than weidu.log - but I don't see that's particularly helpful in practice. This is a file to be consumed by an autoinstaller, after all, not human-readable, and 700 lines is still trivial in terms of overall install space.

On the contrary, the intention is to be human-readable so anyone could prepare such list for general usage. It's an attempt to define install order recommendations like "Install kit mods before SCS", "install Fixpack as first mod", "install UI mods at the end" with a possibility to also take into consideration all exceptions like "RR components from 0 to 8 before SCS and components from 9 to 12 after SCS". Also for all "NPC cross-banter install recommendations" - mod Readme are full of "install NPC X before NPC Y if you want to have cross-banters" instructions. Weidu.log data can't be effectively used for such definitions.

 

I think this is a bad idea: if a list is distributed, I want some reassurance that the distributor has actually tested it and it works. That's doubly true if the list looks very specific, i.e. not just "quests, then kits, then tweaks" or whatever, but a component-by-component ordering.

 

 

Against that, a weidu.log file is a guarantee that the particular install actually worked.

 

Only if those conditions are fulfill:

- it's for the same game

- mod versions are the same

- selected mods are exactly the ones from wiedu.log

 

So weidu log is not only install order it also list of components of specific version, for one game, bound to such order. If any of those elements will be altered, installation might fail.

 

Sure, but this is vastly better than no test at all. Obviously I don't test every permutation of SCS components (there are thousands of permutations) but I wouldn't dream of releasing it into the wild without at least having checked that everything installs, and doing so on every game I claim to support.

 

One failed installation attempt is not a big deal and it can bring new feedback for modder regarding the components, which needs to be installed 'after/before mod x or else something is broken".

I think it's a seriously big deal. If you release a project - and I count a specific, machine-readable installation list as a product - there's some implied guarantee that you've checked that it works. "My specific list doesn't install? Oh well, thanks for the feedback" is a pretty irresponsible thing to say to an end user.

[subtledoctor]

Honestly I think weidu.log would work fine here; it needs to be machine-readable more than it needs to be human-readable. Humans don't need to read it; all they need to do is say "this install worked for Subtledoctor, and he provided this .log document so I can reproduce it. Here it is, mod installer app."

 

As to the fact that it wasn't happening before: I think it's very simply because BWS didn't have honking big buttons that say "Export Install Log" and "Import Install Log."

 

If this tool has buttons like that, I think people will use them. And the player never needs to read the document. They only need to feed it to the installer app's "Import" button, and then the app would show them which mods are selected in the weidu.log, and in which order. And *that* will be human-readable in the app's UI, and the human can then modify the selection as they see fit.

 

Honestly I think that might take the burden of figuring out ideal install order off of the app - it will instead be crowd-sourced via the export/sharing of logs.

Edited November 9, 2018 by subtledoctor

[Jarno Mikkola]

: I think it's very simply because BWS didn't have honking big buttons that say "Export Install Log" and "Import Install Log."

Well, you have never used the BWS, so you can't know that it has been there FOR A VERY LONG TIME !!!!

The reason why it doesn't really work is that the mods get updated so very often that it's useless.

[AL|EN]

Okay, I think we have different conceptions of what's good design here.

 

Not really, you are pointing at weidu.log rock-solid consistency as an example of 'good design' because of things like 'proved to be installed' etc. I'm fully agree with this but It's not only good design, it's perfect. At the given point in time, weidu.log always represents a combinations of the components which was installed without terminating errors. It's impossible to produce 'weidu.log' which won't install (unless you malformed it manually). But this comes with great cost and for the purpose of 'install order', weidu.log limitations are making it almost worthless for the long term. BWS proves it so I have to explore new ideas, which can't offer everything which 'weidu.log' offer. I'm trying to find 'which features will be useful at the cost of not being perfect'.

 

Lucky, my app already allows to use "wiedu.log-like modID:componentNumber" list if anyone want to install only those mod/components, using defined install order. If someone only accept 'wiedu.log' rock-solid consistency, this is the way to go.

 

Against that, a weidu.log file is a guarantee that the particular install actually worked.

Only if those conditions are fulfill:

- it's for the same game

- mod versions are the same

- selected mods are exactly the ones from wiedu.log

So weidu log is not only install order it also list of components of specific version, for one game, bound to such order. If any of those elements will be altered, installation might fail.

Sure, but this is vastly better than no test at all. Obviously I don't test every permutation of SCS components (there are thousands of permutations) but I wouldn't dream of releasing it into the wild without at least having checked that everything installs, and doing so on every game I claim to support.

 

This is nothing else that standard testing case, for single mod. You are installing all SCS components, for specific game, to test if those components are installed ('does it actually do what it's intent to do' is another story). It's just a way to test if the weidu code produces no errors/warring's. I know that you posted this an a example of how good 'weidu.log' is when it comes to 'test if mods will install at all, if not then don't post install sequence at all, if yes then post only weidu.log because it guarantees that everything went smoothly' but it only works when you are dealing with minimum amount of mods. The 'weidu.log-way' can't be used when you are dealing with more than 4800 components (unless somebody has "Time Stop' spell and predict future), thus the idea of 'sorting order' feature come.

 

 

2) It's somewhat more compressed than weidu.log - but I don't see that's particularly helpful in practice. This is a file to be consumed by an autoinstaller, after all, not human-readable, and 700 lines is still trivial in terms of overall install space.

On the contrary, the intention is to be human-readable so anyone could prepare such list for general usage. It's an attempt to define install order recommendations like "Install kit mods before SCS", "install Fixpack as first mod", "install UI mods at the end" with a possibility to also take into consideration all exceptions like "RR components from 0 to 8 before SCS and components from 9 to 12 after SCS". Also for all "NPC cross-banter install recommendations" - mod Readme are full of "install NPC X before NPC Y if you want to have cross-banters" instructions. Weidu.log data can't be effectively used for such definitions.

I think this is a bad idea: if a list is distributed, I want some reassurance that the distributor has actually tested it and it works. That's doubly true if the list looks very specific, i.e. not just "quests, then kits, then tweaks" or whatever, but a component-by-component ordering.

 

I think we can agree that the there is only one, 100% reliable confirmation of successful installation. An installation of specific mod combination of specific version for specific game, using specific install order. It's 'weidu.log' and I can't think about anything else if you want reassurance of actual testing of successful installation. There is no problem to provide such weidu.log from the installation defined by more general install order or my 'sorting order' feature. But first, you need to have such 'public list' and history shows that all previous attempts failed, mainly because of how ugly the weidu.log format is and how sensitive it is when one piece of the puzzle is changed.

 

One failed installation attempt is not a big deal and it can bring new feedback for modder regarding the components, which needs to be installed 'after/before mod x or else something is broken".

I think it's a seriously big deal. If you release a project - and I count a specific, machine-readable installation list as a product - there's some implied guarantee that you've checked that it works. "My specific list doesn't install? Oh well, thanks for the feedback" is a pretty irresponsible thing to say to an end user.

 

First of all, let me explain how 'sorting order' feature works:

 

-first step for user is to select manually mods and components list from the treeview via checkbox and press "Add-SelectedMods" button

-then, a list is generated, which look like this:

ajantisbg2:0:Sir Ajantis NPC for BGII
ajantisbg2:1:Install the unique BG(II):EE BAM for Ajantis' Family Shield
Ascension:0:Ascension
Ascension:1:Tougher Abazigal
Ascension:2:Tougher Demogorgon ( Original Bioware Design )
Ascension:3:Tougher Gromnir
Ascension:4:Tougher Illasera
Ascension:5:Tougher Yaga-Shura 

- then, user need to manually re-arrange such list into proper install order, using copy-paste so it will look like this:

Ascension:0:Ascension
Ascension:1:Tougher Abazigal
Ascension:2:Tougher Demogorgon ( Original Bioware Design )
Ascension:3:Tougher Gromnir
Ascension:4:Tougher Illasera
Ascension:5:Tougher Yaga-Shura
ajantisbg2:0:Sir Ajantis NPC for BGII
ajantisbg2:1:Install the unique BG(II):EE BAM for Ajantis' Family Shield 

- but instead of doing it manually, user can load 'SortingOrder.ini" file (which he previously created) which contains:

Ascension *
ajantisbg2 *

so he doesn't have to do it by hand. Think about it as a Notepad++/Excel macro. Such definition will never add or remove mods which user didn't selected in the first place and all mods which doesn't have "sorting order entry's" will be putted at the end of the sorting list for manual adjusting.

So my app doesn't provide install order (BWS tried and it failed), it gives a features which can be used. Now, going back to you concerns: please define what 'it works' mean to you, in the context of such macro/function which I described?

I can only think about things like ensuring that the 'SortingOrder' file will be properly interpret, sorting will occur and that's it. I'm not even willing to think about a system/feature which can guarantee 'proper install order for every possible mod combination, regardless of the mod internal changes' because I think it's impossible. Keep in mind that I can only use the data which mods will give me, through weidu. So mod tp2 names, DESIGNATED, hopefully LABELS if mod provide it. This is the best which I can think of, If you have ideas how to improve consistency such 'Sorting Order' feature, I'm all ears.

Lastly, I'm open for discussion about adding a way for mods to include their desired install order definitions (BEFORE/AFTER) as metadata.

Edited November 9, 2018 by ALIENQuake

[AL|EN]

: I think it's very simply because BWS didn't have honking big buttons that say "Export Install Log" and "Import Install Log."

Well, you have never used the BWS, so you can't know that it has been there FOR A VERY LONG TIME !!!!

The reason why it doesn't really work is that the mods get updated so very often that it's useless.

Even if you have point, it's not a reason to bash anyone only because he didn't spend last 3 years to deal with those kind of issues. You could inform him in a more subtle way...

Honestly I think weidu.log would work fine here; it needs to be machine-readable more than it needs to be human-readable. Humans don't need to read it; all they need to do is say "this install worked for Subtledoctor, and he provided this .log document so I can reproduce it. Here it is, mod installer app."

 

As to the fact that it wasn't happening before: I think it's very simply because BWS didn't have honking big buttons that say "Export Install Log" and "Import Install Log."

 

If this tool has buttons like that, I think people will use them. And the player never needs to read the document. They only need to feed it to the installer app's "Import" button, and then the app would show them which mods are selected in the weidu.log, and in which order. And *that* will be human-readable in the app's UI, and the human can then modify the selection as they see fit.

 

Honestly I think that might take the burden of figuring out ideal install order off of the app - it will instead be crowd-sourced via the export/sharing of logs.

The 'weidu.log-way' for defining install order can already be used for my app. Also it allow for exporting modID:componentNumber list with the description of those mod/components. Such list is no different from 'weidu.log' but the format is much nicer. This is one of the way of providing 'install order' to the app.

Let me assure you that taking the burden of figuring out ideal install order at the shoulder of an app was never intended in the first place. BWS did it and it failed. Mostly because it was based on weidu.log where you have to deal with exact component numbers. Nothing stops anyone to repeat BWS/BWP mistakes. But now at least I can warn you about them.

I saw that you already posted you weidu.log and there is nothing wrong with it (I'm actually happy to try it). But there are consequences of using weidu.log for the purpose of install order without treating such list also as "only those mods and components, only specific version, only for one particular game"-list. If you do the first one, the list will fail after one single mod change which you have no knowledge or control. If you do a former, it limits players from adding 'one tiny NPC mod' or "one tiny UI tweak" to such list without risk of breaking it. You might already see that in the upcoming weeks, it will be obsolete because one of the important mod will receive major update. And then other mod, and another. It will never end.

So I want to give players and modders a second way of defining install order, with a nice GUI. The way I see it, combination of mod component list and 'sorting order' list looks very promising. To give you an example:

Lets say that somebody is testing install order of 4 mods: TnB, FnP, MnG, SoB

and all of those mods are under heavy development: components are adder/removed, designated numbers are changing, it's to early to define labels etc. Weidu.log will be useless but using my feature, you can simply select desired mod components, define:

TomeAndBlood *
Faiths_and_Powers *
might_and_guile *
scales_of_balance *

and it give you desired sorting order, unaffected by mod changes. Even tp2 renaming is easy to deal with. Then, it's possible to install all user-selected components (one, two or twenty) using single click. It's huge improvement over what's currently available.

Edited November 9, 2018 by ALIENQuake

[subtledoctor]

You keep saying stuff like "can't rely on DESIGNATED numbers" but can you actually point to a mod where someone has been changing DESIGNATED numbers?

 

I don't think Weidu.log is as limited as you say. Someone can play through a game, export the log if they find no errors, and I can import tbe log into a hypothetical mod installer. Now, this is the important bit: the mod installer should not proceed to recreate that game. It need only open up its GUI and show the mods from that .log as selected, and in the appropriate order. Now it is human-readable, just when it needs to be, i.e. when the human is selecting mods and getting ready to press the "install" button.

 

At that point, let the player deselect mods if they want to. The result should be exactly as bug-free as the game with the supplied .log.

 

And allow the player to add more mods to the selection as well. They can do their due diligence and try to find the best place to insert it. The result will introduce the chance of bugs, but that's the player's responsibility which I think is fine.

 

Anyway this is all very hypothetical to me. I think manually installing mods is fine. Way easier than, say, dealing with something like Wrye Bash.

[lynx]

Just an observation. This is more about making the component choices actually get installed. If the interaction with weidu was similar to interactive, it would only be about mod install order and component order would be automatically taken care of.

So maybe there are other ways to communicate them.

[AL|EN]

You keep saying stuff like "can't rely on DESIGNATED numbers" but can you actually point to a mod where someone has been changing DESIGNATED numbers?

Huh? The cdtweaks, SCS, UI mods, to name a few. You can go through BWS git commit logs to see more detailed examples. In the context of 'install order sequence defined by tp2 name and DESIGNATED' it has the same flaws as anything which is based on them.Unfortunately, 'weidu.log-based install sequence' can't have LABELS. But my 'sorting order list' can so install sequence is protected (to some degree) from DESIGNATED changes.

I don't think Weidu.log is as limited as you say. Someone can play through a game, export the log if they find no errors, and I can import tbe log into a hypothetical mod installer. Now, this is the important bit: the mod installer should not proceed to recreate that game. It need only open up its GUI and show the mods from that .log as selected, and in the appropriate order. Now it is human-readable, just when it needs to be, i.e. when the human is selecting mods and getting ready to press the "install" button.

 

At that point, let the player deselect mods if they want to. The result should be exactly as bug-free as the game with the supplied .log.

 

And allow the player to add more mods to the selection as well. They can do their due diligence and try to find the best place to insert it. The result will introduce the chance of bugs, but that's the player's responsibility which I think is fine.

Anyway this is all very hypothetical to me. I think manually installing mods is fine. Way easier than, say, dealing with something like Wrye Bash.

Importing 'weidu.log' is partially possible, what you really want is importing 'weidu.log', recreating install sequence and apply checkboxes at treeview. So importing will produce two things: component list and sequence order. This will have to wait a while but it is also planned.

Edited November 10, 2018 by ALIENQuake

[subtledoctor]

 

You keep saying stuff like "can't rely on DESIGNATED numbers" but can you actually point to a mod where someone has been changing DESIGNATED numbers?

Huh? The cdtweaks, SCS, UI mods, to name a few.

 

Well, those people should be told to stop changing DESIGNATED numbers! There's no need, ever, to change them. Just number them like 100, 200, 300, etc. and then if you need to add components you can add 120, 140, 160, etc. The occasional major shakeup of a mod (like SCS being updated after 5 years) is a different story, and likely involves enough changes that the rest of us can adjust to the new numbering.

 

what you really want is importing 'weidu.log', recreating install sequence and apply checkboxes at treeview. So importing will produce two things: component list and sequence order. This will have to wait a while but it is also planned.

Exactly! Sorry if I wasn't clear.

[AL|EN]

You keep saying stuff like "can't rely on DESIGNATED numbers" but can you actually point to a mod where someone has been changing DESIGNATED numbers?

Huh? The cdtweaks, SCS, UI mods, to name a few.

Well, those people should be told to stop changing DESIGNATED numbers! There's no need, ever, to change them. Just number them like 100, 200, 300, etc. and then if you need to add components you can add 120, 140, 160, etc. The occasional major shakeup of a mod (like SCS being updated after 5 years) is a different story, and likely involves enough changes that the rest of us can adjust to the new numbering.

I can bet that other modders will find good reasons to change them (organizing components, GROUP etc) Even if such request could be accepted (I doubt), there is much better thing to do: just add unique LABEL for every component and then you can change DESIGNATED as much as you want Ofc there is still a possibility that someone will change LABEL, but there are zero technical reasons to change them so I can accept such magnitude of the failure.

Edited November 10, 2018 by ALIENQuake