Search the Community
Showing results for tags 'order'.
Let's try an alternative look at how modders/maintainers can take care of the install order: Dynamic Install Order It's a rule-based order of the mods which use BEFORE/AFTER 'rules' in order to determine the relationship between source mod and destination mods. Generally, it is a recreation of the install order recommendations from mods 'ReadMe' files, but in 'machine-readable' format, which mod manager can use, apply and react when rules are not fulfilled. Goals: you care only about install order/dependencies of you own mods or mods which you maintain sufficient for low to medium installation, for huge mega-installation of 100+ mods, a big install order list will be better choice Non-goals: to handle every possible type of future mods a perfect install order for unlimited amount of mods replacement for using install order list for huge amount of mods Features: rules cannot be disabled by players, you can be sure that you mods will be installed using provided install order using mod ID as tp2 filename without extension and 'setup-' prefix everything is evaluated before installation even starts so the player won't ever face 'you must install x before y' after hours-long installation allows only to set rules for your own mods relating to other mods, it doesn't allow to alter install order rules of other mods all rules are loaded dynamically, according to whenever the mod is selected for installation and the mod to which the rule applies is also selected all rules are evaluated dynamically, according to whenever the mod is selected for installation and the mod to which the rule applies is also selected the installation will be possible only when all rules for all mods will be fulfilled works globally, mean it will check mods already installed, currently being installed and it also 'will be fired' when someone will install mods later Covered use cases: The idea for this topic is regarding install order/installation dependencies only, not mod conflicts. So in order to clarify scope of this discussion let's limit it only to this cases: Assuming 'ModA' is the source of the rules: Implemented: BEFORE = ModB Mod A should be installed before Mod B, this is only single 'rule/requirement', it doesn't mean that ModA require ModB to be installed. AFTER = ModC Project Infinity feature status: Implemented Mod A should be installed after ModC, this is only single 'rule/requirement', it doesn't mean that ModA require ModC to be installed. Example: AFTER = BobShop, Caravan, TeamBG-Armors The mod will add new items into the every game shop regardless whenever BobShop, Caravan, TeamBG-Armors mods are installed or not. Not yet implemented: please don't use those until there will be working implementation as things might be changed Example of rules definition for Deities Of Faerun mod: Project Infinity feature status: Implemented mod ID as tp2 filename without extension and 'setup-' prefix ID's are separated by commas DeitiesOfFaerun.ini [Metadata] Name = Deities Of Faerun BEFORE = IHateUndead, MyMod AFTER = AllThingsMazzy, OtherMod Example of defining install order rules directly inside mod components by using WeiDU 'METADATA' keyword in order to provide data for PI's Dynamic Install Order feature: Project Infinity feature status: Implemented mod ID as tp2 filename without extension and 'setup-' prefix ID's are separated by comas the format stays the same as for global rules with the addition of usual WeiDU keyword syntax you can't put BEFORE/AFTER into single METADATA occurrence you can have multiple METADATA keyword statement you can put global rules inside ini and a different ones directly inside components - local rules will override (instead of combining) global rules from global ini LocalRules.tp2 BEGIN "Local Rules Main" LABEL "LocalRules-Main" METADATA "AFTER = Ascension, DSotSC" METADATA "BEFORE = X, Y" BEGIN "Local Rules Extra" LABEL "LocalRules-Extra" METADATA "AFTER = C, D" METADATA "BEFORE = FaithsAndPowers, TomeAndBlood" Visual representation: Record_2020_03_04_21_38_32_448.mp4 If you have any questions, or feedback regarding details of the above system, feel free to ask.
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: 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.