Skip to content

Discussion about community install order list for mods

SystemSystem Administrator Posts: 199
in General Modding
This discussion was created from comments split from: Project Infinity Public BETA.

Comments

  • RaduzielRaduziel Member Posts: 4,714
    @ALIEN Can't the modders define a list?

    You know I'm dumb when the subject is GitHub but I thought about a file that anyone may edit, submit and accept - maybe a file located in other GitHub account that PI would just read (as it already does with our .ini if I understood correctly).

    This way this 24/7 task would be handled by the modders, not you. And I think that anyone who builds a mod knows (or have a strong idea) of install order/mutual exclusion.

    Just brainstorming and trying to sound smart for once in this thread.
  • ALIENALIEN Member Posts: 1,271
    Raduziel wrote: »
    My idea is every modder be accountable of their mods.

    Just like we need to register a signature to start modding, every time a mod is built we go to that spread sheetand update it. More than our own knowledge about our mods we are the ones who receive feedback from players so this task is easier for us than for you, I suppose.

    Of course, lots of things would happen by trial-and-error, but I think that would make the life of every mod user way easier.

    So you are thinking about "Community install order" list? You can do it, there is nothing which prevents you from starting such project. But being Devil's Advocate I need to ask: why no one has ever done such thing in the past?

    Registering modders prefix doesn't affect other people mods but placing a mod between two mods from different authors can have consequences.

    Anyway, I will support such initiative B)
  • NiewiemNiewiem Member Posts: 8
    List like that would be really great for us mod users but someone has to start it and propagate it. The problem I see is that every modder would have to update it and that list would probably prove to be gigantic.
    Also what about mods that are not supported any more? Should they be included? Who should define their install order? It is enough to look at Leonardos Big World Project (which could be a start at least for original games) to see that list would be very long and even with knowledge about your mod you might change something that other modder did.
  • RaduzielRaduziel Member Posts: 4,714
    @Niewiem That's why my idea is to pulverize this responsibility for all the modders.

    I'll see if I can put that in motion.

    My idea is start the list with the mods that are more used, like aTweaks, Tweaks Anthology, Unfinished Business, BG1 NPC Project and, of course, SCS. Using that as a core, the modders would add their mods to the list. Maybe in six or nine months everything will de done.

    @ALIEN do you suggest a tool for doing so that would have synergy with PI and be easy to be edited by anyone?
  • ALIENALIEN Member Posts: 1,271
    edited April 2019
    Raduziel wrote: »
    @Niewiem That's why my idea is to pulverize this responsibility for all the modders.

    I'll see if I can put that in motion.

    My idea is start the list with the mods that are more used, like aTweaks, Tweaks Anthology, Unfinished Business, BG1 NPC Project and, of course, SCS. Using that as a core, the modders would add their mods to the list. Maybe in six or nine months everything will de done.
    The LOOT tool uses the same approach: allows modders to participate in the process of defining correct install order for mods. But it offers modders a very nice tools for this task, and the mods themselves have a means in order to define such install order. For weidu mods, almost everything is harder to do and maintain.
    Raduziel wrote: »
    @ALIEN do you suggest a tool for doing so that would have synergy with PI and be easy to be edited by anyone?

    You need a way to know who changed what and a history of the changes. Best approach would be reusing already existing solution like LOOT and adapt it to the IE mods requirements, since there is no point of reinventing the wheel. But this would require lot of work. Much simpler solution would be to use github with markdown "Table" formatting:
    | [DLC]     |   |
|-----------|---|
| DLCMerger | * |
...

| [Fixes]    |   |
|------------|---|
| ModWithFixes | * |

    You can even include Install Sections (those are not mod "Categories" even if match the same name): 
    [DLC]
[Language]
[Fixes]
[Enhanced Edition Trilogy]
[Quests]
[NPC]
[NPC-Related]
[Items]
[Spells]
[Kits]
[Tweaks]
[AI]
[Worldmap]
[Enhanced Edition Trilogy End]
[Sounds]
[Portrait]
[UI]

    It would be a good start. I suggest you to start with you own mods, see how it is going. If you are going to cook something along with other modders, sing me up.
    Post edited by ALIEN on
  • ALIENALIEN Member Posts: 1,271
    edited April 2019
    My idea for install order would be:
    - allow modders to set metadata in order to put their mods/components into above install section list
    so for eg: LeUI would be added to [UI]

    INSTALLSECTION:UI // install section UI, not the same thing as mod "Category"

    - introduce concept of component ID + allow modders to set metadata:
    BEFORE: ID1 , ID2, ...
    AFTER: ID3 , ID3, ...
    INSTALLAFTER:RecoloredButtons" // install after Argent77 Recolored Buttons mod

    - sort PI mods according to the provided mod metadata, BEFORE & AFTER takes precedence over install section

    but I haven't give it much attention, nor testing, I need to reach some sort of stability of PI and make necessary changes to code structure in order to be more suitable for such extra features.
    Post edited by ALIEN on
  • ALIENALIEN Member Posts: 1,271
    edited April 2019
    Please note that we can combine both of the solutions: a metadata for install order + central place for it. Metadata doesn't have to be spread across several mods/mod repositories. With central place, it would be much easier for new modders to jump on the wagon and adjust the install order for their mods accordingly.
    Post edited by ALIEN on
  • ALIENALIEN Member Posts: 1,271
    edited April 2019
    Calling @lefreut @Pecca @AncientCowboy @Bubb @Kerozevok @trinit

    Is this is something which you or other UI modders would be interested and willing to try? Why focusing at the UI mods first? I find the [UI] section to be most easiest for testing and implementation, with a high chance for success.
    Post edited by ALIEN on
  • DavidWDavidW Member Posts: 823
    edited April 2019
    I don’t want to damp enthusiasm here - and I think there is at the very least a value for metadata in defining broad categories, e.g. ‘spellpack’, ‘npc’, ‘gui’, ‘early’, ‘late’, to which general principles of ordering can be applied. But two things get in the way of just crowdsourcing fine-grained order:

    1) it’s too complicated to work out just from knowing about your mod alone. Modders vary wildly in their level of understanding of how to manage compatibility and the writer of mod X may not be well placed to evaluate where mod X should be in the install order.

    2) there is no right answer. That is: there is just no reason to think that for a large list of mods there is *any* install order that makes all of the mods operate correctly, even if there are no conceptual incompatibilities. So to some extent install order depends on which mod you want to prioritize working correctly. E.g. my install order is almost always going to put SCS last or nearly last because I prioritize it working correctly, but someone else might have different priorities.
  • lefreutlefreut Member Posts: 1,462
    ALIEN wrote: »
    INSTALLAFTER:RecoloredButtons" // install after Argent77 Recolored Buttons mod

    - sort PI mods according to the provided mod metadata, BEFORE & AFTER takes precedence over install section

    This means that either UI mod authors have to know every mods that patch the UI or modders must know every UI mods to properly declare before/after relationship. I don't think that's possible.

    For the UI, there is basically two possibilities, mods that overwrite the full UI.menu file and mods that patch it. One solution could be to declare mods/components as OVERWRITE_UI or PATCH_UI. This way, you know that all OVERWRITE_UI are incompatible with each other and that PATCH_UI must come after OVERWRITE_UI.
  • ALIENALIEN Member Posts: 1,271
    edited April 2019
    DavidW wrote: »
    I don’t want to damp enthusiasm here - and I think there is at the very least a value for metadata in defining broad categories, e.g. ‘spellpack’, ‘npc’, ‘gui’, ‘early’, ‘late’, to which general principles of ordering can be applied. But two things get in the way of just crowdsourcing fine-grained order:

    1) it’s too complicated to work out just from knowing about your mod alone. Modders vary wildly in their level of understanding of how to manage compatibility and the writer of mod X may not be well placed to evaluate where mod X should be in the install order.

    2) there is no right answer. That is: there is just no reason to think that for a large list of mods there is *any* install order that makes all of the mods operate correctly, even if there are no conceptual incompatibilities. So to some extent install order depends on which mod you want to prioritize working correctly. E.g. my install order is almost always going to put SCS last or nearly last because I prioritize it working correctly, but someone else might have different priorities.

    1) It is possible to make it less complicated? Other modding communities (Skyrym, Fallout, Oblivion) have successfully created and maintained such install order lists. Take look at BWP - one guy managed to create install order for install more than 2000 components. Does having actual modders involved for such task makes things easier?

    2) So it must be limited for scope and priorities:
    - mods (or at least their main components) should install without errors
    - main quests aren't broken
    - quest mods don't destroy other quests
    - NPC mods installed correctly for their cross-banters/interactions
    - Kit mods adding kits before other NPC mods can relay on them
    - Tweaks mods actually works for all previously added mod content
    - UI mods don't overwrite themselves

    P.S. Good point about 'early and 'late'.
    Post edited by ALIEN on
  • ALIENALIEN Member Posts: 1,271
    lefreut wrote: »
    ALIEN wrote: »
    INSTALLAFTER:RecoloredButtons" // install after Argent77 Recolored Buttons mod

    - sort PI mods according to the provided mod metadata, BEFORE & AFTER takes precedence over install section

    This means that either UI mod authors have to know every mods that patch the UI or modders must know every UI mods to properly declare before/after relationship. I don't think that's possible.

    @lefreut

    I'm confused by you reply, It seems to me that you threat install order as some sort of dependency between two mods, so the first mod will do some modification and then second one changes are based on previous mod changes. What I had in mind is very simple case:
    - you care only about mods which are included inside community install order list
    - let's say that there is a "UI Tweaks" mod which works for standard GUI and 'Lefreut's enhanced UI' but doesn't require any other mod itself
    -so the "UI Tweaks" mod would simply have to include 'INSTALLAFTER:Lefreut's enhanced UI" and that's it

    How does it look now?
    lefreut wrote: »
    For the UI, there is basically two possibilities, mods that overwrite the full UI.menu file and mods that patch it. One solution could be to declare mods/components as OVERWRITE_UI or PATCH_UI. This way, you know that all OVERWRITE_UI are incompatible with each other and that PATCH_UI must come after OVERWRITE_UI.
    The solution which you proposed has much in common with GUID feature which I've proposed 2 years ago.

    I will get back to this topic when I will finish my 'homework' about this.
  • [Deleted User][Deleted User] Posts: 0
    The user and all related content has been deleted.
  • DavidWDavidW Member Posts: 823
    As much as a point about complexity as anything else: it is highly unclear to me that the EET ‘end’ mod should be installed last, despite the EET advice to that effect.
  • [Deleted User][Deleted User] Posts: 0
    The user and all related content has been deleted.
  • ALIENALIEN Member Posts: 1,271
    @subtledoctor Good idea to put UI mods first, people can install them and see how they look(and check if they are installed fine) right away. The one slight disadvantage is that when someone would like to change UI - all mods will be reinstalled. But I think that if someone is installing UI mod, he already decided to use it forever.

    The EET_End must be installed after all NPC mods, it combine their dialogs or so. @swit can you please clarify?
  • ALIENALIEN Member Posts: 1,271
    subtledoctor wrote: »
    ALIEN wrote: »
    Especially if you remove some mods whose conflicts inform Leonardo's decisions; his order assumes you install the entire BWP list. Partial lists might look very different; it's hard to say.

    AFAIK, you can skip any mod which is included inside BWP list and you still use the same install order.
  • ALIENALIEN Member Posts: 1,271
    edited May 2019
    @lefreut
    For the UI, there is basically two possibilities, mods that overwrite the full UI.menu file and mods that patch it. One solution could be to declare mods/components as OVERWRITE_UI or PATCH_UI. This way, you know that all OVERWRITE_UI are incompatible with each other and that PATCH_UI must come after OVERWRITE_UI.

    Does having two install sections: UI-OVERWRITE followed by UI-PATCH would fulfill you needs?

    Request for feedback:
    Assume that you want to put mod components from single mod, into separate install sections. What kind of syntax would be good for you and what is the best place to include such information from the modder perspective?

    Calling @subtledoctor @lefreute @Pecca
    Post edited by ALIEN on
  • lefreutlefreut Member Posts: 1,462
    ALIEN wrote: »
    @lefreut
    For the UI, there is basically two possibilities, mods that overwrite the full UI.menu file and mods that patch it. One solution could be to declare mods/components as OVERWRITE_UI or PATCH_UI. This way, you know that all OVERWRITE_UI are incompatible with each other and that PATCH_UI must come after OVERWRITE_UI.

    Does having two install sections: UI-OVERWRITE followed by UI-PATCH would fulfill you needs?

    Yes :)
  • ALIENALIEN Member Posts: 1,271
    lefreut wrote: »
    ALIEN wrote: »
    @lefreut
    For the UI, there is basically two possibilities, mods that overwrite the full UI.menu file and mods that patch it. One solution could be to declare mods/components as OVERWRITE_UI or PATCH_UI. This way, you know that all OVERWRITE_UI are incompatible with each other and that PATCH_UI must come after OVERWRITE_UI.

    Does having two install sections: UI-OVERWRITE followed by UI-PATCH would fulfill you needs?

    Yes :)

    I appreciate this very much. Regarding syntax and place, can I have you feedback also?
  • lefreutlefreut Member Posts: 1,462
    ALIEN wrote: »
    I appreciate this very much. Regarding syntax and place, can I have you feedback also?

    Well I have never used a mod manager or done a mega mod install (I usually only install a few mods manually). And I know close to nothing about modding. I'm not sure I can give you meaningful feedback.
  • ALIENALIEN Member Posts: 1,271
    lefreut wrote: »
    ALIEN wrote: »
    I appreciate this very much. Regarding syntax and place, can I have you feedback also?

    Well I have never used a mod manager or done a mega mod install (I usually only install a few mods manually). And I know close to nothing about modding. I'm not sure I can give you meaningful feedback.

    Understood, no worries :smile:
  • ALIENALIEN Member Posts: 1,271
    edited June 2019
    Project Infinity now support Install Order Groups which can be foundation for community install order list maintained online.
    Post edited by ALIEN on
  • ALIENALIEN Member Posts: 1,271
    edited July 2019
    So after doing a little bit experimentation and acquiring knowledge, some things emerge:
    - due to the dynamic nature, defining install order by using mod local files would be ineffective for it's goal and a nightmare to manage, centralized online service is the best way to go
    - the best file format for 'human to system' interaction is YAML (black dot experiment), no need to reinvent the wheel, the only unusual thing which might be problem for non-technical users is the fact that spaces are matter
    - mistakes can happen so having a history of changes is important
    - using online Excel spreadsheet wasn't produce good results: no history, no way for data validation
    - Github is used by similar initiatives, with good results
    - contributing into a Github-based solution can be done without storing mods there
Sign In or Register to comment.

2024 Overhaul Games, a division of Beamdog. © 2024 Hasbro, Inc. All Rights Reserved. Baldur's Gate, Dungeons & Dragons, D&D, Forgotten Realms, Baldur's Gate, Wizards of the Coast and their logos are trademarks of Wizards of the Coast LLC in the U.S.A. and other countries, and are used with permission. Hasbro and its logo are trademarks of Hasbro, Inc. and are used with permission. © 1998 BioWare Corp. All Rights Reserved. BioWare, the BioWare Infinity Engine and the BioWare logo are trademarks of Bioware Corp. Black Isle Studios and the Black Isle Studios logo are trademarks of Interplay Entertainment Corp. Atari and the Atari logo are trademarks owned by Atari Interactive, Inc. All other trademarks are the property of their respective owners.