Jump to content

Search the Community

Showing results for tags 'projectinfinity'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General Discussion
    • G3 News and Announcements
    • Infinity Engine Modding News
    • General Mod Discussion
    • Fan Fiction
    • Noobermeet
  • Tools & Resources
    • DLTCEP
    • GemRB
    • The Gibberlings Three Debugging Suite for BG2
    • IESDP Updates and Info
    • Modding How-Tos and Tutorials
    • Modding Q&A
    • Multi-Install Tool
    • Widescreen Mod
  • Released Projects
    • Miscellaneous Released Mods
    • Ajantis
    • Alternatives
    • Amber
    • Angelo
    • Ascension
    • Auren Aseph
    • BG1 NPC Project
    • Baldur's Gate Mini Quests and Encounters
    • The Beaurin Legacy
    • BG2 Fixpack - General Discussion
    • Calin
    • The Calling
    • Cirerrek's AI Scripts
    • Coran's Friendship Mod
    • Crossmod Banter Pack
    • Crossmod Banter Pack (IWD)
    • Divine Remix
    • Enhanced Edition Trilogy
    • Evandra
    • Full Plate & Packing Steel
    • Garrick's Infatuation
    • Gavin
    • The Gibberlings Three Anniversary Mod
    • Grey the Dog
    • Glam's NPC Pack
    • Icewind Dale Mod Roundup
    • Icewind Dale in Baldur's Gate II
    • Imoen 4 Ever
    • Item Randomiser
    • Item Revisions
    • IWD2 NPC Project
    • IWDification
    • Keeping Yoshimo
    • Kivan and Deheriana Companions for BG2
    • Level One NPCs
    • Mur'Neth
    • NPC Kitpack
    • NPC Strongholds
    • NPC Tweak for BG2
    • Oversight
    • Romantic Encounters (BG)
    • Romantic Encounters (BG2)
    • Sarah
    • SoD to BG2EE Item Upgrade
    • Song and Silence
    • Spell Revisions
    • Sword and Fist
    • Sword Coast Stratagems
    • Tweaks Anthology Forum
    • Tyris Flare
    • Wheels of Prophecy
    • Yoshimo's Remorse
  • Unreleased Projects
    • Aklon
    • Balduran's Seatower
    • Baldur's Gate: Shadow Hand TC
    • Aran Whitehand
    • Delainy
    • IWD Tutu
    • Kit Revisions
    • Inactive Projects
  • NWN2 Modding
  • Mod Workrooms


  • NPCs
  • Quests and Others
  • Tweaks & Fixes
  • Items/Kits/Spells
  • Portrait Packs
  • Mini Mods
  • Tools
  • In Progress


  • Fixes
  • Items
  • Kits
  • NPCs
  • Quests
  • Spells
  • Tweaks
  • Other
  • Tools

Product Groups

There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start




Website URL









Mods Worked On

Found 10 results

  1. Hi all, I've been a lurker here for some time, and played a fair bit of BG2 since release, with a smattering of IWD and BG1. Today I finally have something to contribute. In working toward some multi-mod installs, and perhaps eventually an EET run, I started a list of mods with some info to help me work through compatibility issues. I shared this elsewhere, and @Cahir has been good enough to contribute, bringing it to a state where I suspect it may have some value to others. The goal is to create a compatibility guide and "cheat sheet" for multi-mod installs. The focus is on EE games as I mostly care about BG2EE & Cahir EET. Link: https://drive.google.com/open?id=1vislrHkbvsqlN0m5jtDxDcSzlnA5D6ABSZy5TG1O8FQ Please comment in any additional info or suggested changes, this will only improve with collaborative effort. Any and all feedback appreciated. 4udr4n
  2. Let's try an alternative look at how modders/maintainers can take care of the install order: Dynamic Install Order - 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 met/fulfill. Goals: - by no means a perfect install order for unlimited amount of mods - 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: - covering every possible mods and future mods - replacement for using install order list for huge amount of mods Features: - 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 relationship between you mods and other mods, it doesn't allow to alter install order rules from other mods - works globally, mean it will check mods already installed, currently being installed and it also 'will be fired' when someone will install mods later - 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 - each single rule change it's background color only when it's fulfilled - if the mod has multiple rules, the background color will change only when all of the mod rules are fulfilled - the installation will be possible only when all rules for all mods will be fulfilled 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: BEFORE = B Mod A should be installed before Mod B, this is only single 'rule/requirement', it doesn't mean that Mod A require Mod B to be present. AFTER = B Mod A should be installed after Mod B, this is only single 'rule/requirement', it doesn't mean that Mod A require Mod B to be present. Example: Mod description: This mod adds new items into every game shop. 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. REQUIRE FORMER/Pre-Install = B Mod A require Mod B to be installed before in order for Mod A to work. This is actually two rules: "REQUIRE B" and "BEFORE B". Due to how IE/WeiDU mods works, both rules are implied. Gamers however can interpret this only as 'two mods must be installed, that's it, I fulfill the requirements' which is not sufficient. Example: "SCS: Smarter Abazigal" require "Ascension: Tougher Abazigal" REQUIRE LATER/Post-Install = B Mod A require Mod B to be installed after in order for Mod A to work. Again two rules: "REQUIRE B" and "BEFORE B", both are implied. Example: The Drizzt Saga Main component > Worldmap variant Installing this component means that player is required to install Worldmap later. The Worldmap MUST be installed after. Example of rules definition for Deities Of Faerun mod, using mod ID as tp2 filename without extension and 'setup-' prefix: [Metadata] Name = Deities Of Faerun BEFORE = IHateUndead, MyMod AFTER = AllThingsMazzy, OtherMod This is an example of how such a system would work: Record_2020_03_04_21_38_32_448.mp4 Assuming that the system works, I'm interested in hearing if Is this is something which you would like to use for your mods. If you have any questions, or feedback regarding details of the above system, feel free to ask.
  3. It's a good time to discuss install order online list which is maintained by the modders or current mod maintainers. There are currently 3 people who are trying to create publicly available optimal install order for many mods: Leonardo Watson - it's only for classic BGT but it can be partialy used for BG2EE Roxanne - separate lists for BG1EE, BG2EE, EET, IWD1EE, PSTEE Subtledoctor - combined list for BG1EE, BG2EE, EET, IWD1EE General remarks: - 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 service is the best way to go - history of changes is important so we know who change what - Github is used by similar initiatives, with good results - contributing into a Github-based solution can be done without storing mods there The overall goal of such 'online list' is to be included by any mod manager into some automated install routine, as a default one. The main benefit is that modder/maintainer can include all of his mods and fulfill all needs of his mods like kit/class dependence, NPC cross-mod banters etc. The format is: - the mod ID is tp2 filename without extension and 'setup-' prefix - uses designated numbers of the components - * means all components of the particular mod, except any explicitly defined component from the same mod ID This is an example of how it look like: # WARRING: This list is only an example for ongoing discussion, don't use it to define you install order! #UI-Overwrite DragonspearUI++ * jimfix 0 1 100 stratagems 1000 5900 6000 6010 6030 6040 spell_rev * iwdification * stratagems 1500 1510 wildmage * iwdification 60 hammers * UnofficialItemPack * item_rev * Divine_Remix * song_and_silence * RR 0 1 2 3 4 5 6 7 8 Faiths_and_Powers * TomeAndBlood * A7-GolemConstruction * A7-ChaosSorcerer * might_and_guile * IHateUndead * willowisp * cdtweaks * Divine_Remix 1000 AnimalCompanions * shadowadept * sword_and_fist * refinements * scales_of_balance * stratagems * jimfix 2 3 4 5 400 RR * atweaks * scales_of_balance 180 klatu * jimfix * # it will install remaing 201 202 203 204 205 300 components #Portiats ppe * thepicturestandard * #UI-Patching EEUITweaks * Goals: - by no means a perfect install order for unlimited amount of mods - main game quests aren't broken - 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 tweak mods can correctly patch other UI-overwrite mods Workflow: - list is read from top to the bottom - modders/maintainers are added to the repository as collaborators - modders/maintainers can make changes to the repository - modders/maintainers are adding/changing only their own mods - minimum amount of collaboration and caution is required Features: - easy and straightforward solution for players (read) and mod managers (download and apply) - easy way to contribute via web interface: you simply choose file, click edit and that's it - it has history of changes, everyone will know who change what - placing NPC mods in order to fulfill all cross-mod banters/etc is very easy - for certain games like IWD1EE, PSTEE, it will be very small Disadvantages: - having to manage separate lists for different games - for certain games like BG2EE or EET, it will be still a big one - placing UI/Portiat/Sounds mods is not straightforward because there are no 'sections/groups' at such list I've added sections as comments I don't want to assume that such list could be easy maintained by modder/maintainer so I would like to hear from you about: 1. As a modder/maintainer, how do feel about contributing into such list? 2. Which things makes you don't want to contribute to such list? Please share you feedback, I agree that there are many difficult aspect of the install order but "done is better than perfect".
  4. What does this tool do? It automatically generates Infinity Engine mod packages and adds them to release when you publish it. What are Infinity Engine mod packages? They are standardized, universal and cross-platform Infinity Engine Mod Packages .zip package It contains the latest WeiDU executable for Windows and macOS (for Linux is impossible) and .command file for macOS. .iemod package Only for mod managers. Offers a "double-click at file>extract>install" feature. General info the tool is serverless aka it will work as long GitHub Actions will exist in any form packages always have latest WeiDU version, at the time when they were created the package version is taken directly from tp2 file Example: (from https://github.com/ALIENQuake/InfinityAutoPackager-Example) How to do the one-time installation inside your mod repository? - by adding to the repository Download Infinity Auto Packager repository, extract InfinityAutoPackager-master.zip file Copy '.github' folder into you top-level folder of the mod repository Commit and push changes to the remote repository How to use it? Publish release After a few moments, the .iemod and .zip packages will be automatically created and added to the published release. How long it takes depends on how big the mod is. If you have additional questions, feel free to ask
  5. I've finally take some time to talk about this topic. When I take look at the amount of the BWS 'custom extraction rules' and 'custom code' which was written only because modder made simple packaging mistake and then went MIA, i decided that there won't be any kind of 'extraction' feature for PI unless there will be a well-defined standard for all IE mods. Having a well-defined, universal and cross-platform Infinity Engine Mod Package and the cross-platform tool for creation of such package would be wonderful. Definitely there are advantages for players and for mod managers. This general idea was originally posted by wisp at PPG boards. Key points: - the era of caring about package size on disk or download times are long gone - there is no point for offering two separate zip packages for macOS and Linux if the only differences are weidu and few OS-specific tools resulting ~1MB of file difference - macOS/Linux users offter are asked to download weidu, extract it, copy & rename and set executable bit. Example: http://www.shsforums.net/files/file/949-atweaks-platform-independent/ - just look at the 'Installation instructions' - it's horrible idea to require preforming all of those actions by macOS/Linux users. Those things must go away, thus the simple requirements for new package: it needs to have everything which is needed for mod installation. Advantages: standardization, no more rar, tar etc, all community created tools can support it without worrying about edge-cases players will no longer need to install 3-rd party tools in order to extract mod, mod manager will do it such mod packages can be double-clicked inside OS and associated program will be open and offer extraction (and possible installation) it will allow to introduce 'infinity mod package protocol link' similar like Steam steam:// or Nexus Mod Manager nmm:// protocol links The Infinity Engine Mod Package:// protocol link: Those are special links on the web page, they look like this: steam://run:<AppId> - if the user click at this link, his local Steam application will be executed and the game will launch or the user will be asked if the game should be downloaded. nmm://ModID - if the user click at this link, his local NMM application will be executed and the mod will be automatically downloaded and added to mod list. If you never have used them, please try via Steam or NMM/Vortex - it is a pleasure to see how everything works with one click. I want this to happen. So Infinity Engine Mod Package:// protocol could be defined like this: iemod://github.com/Gibberlings3/Tweaks-Anthology player click at such link associated application will open mod will be downloaded and extracted (no overwrite) additional option would be to offer installation after extraction but i'm not sure about this and how it will play Support for such 'protocol' can't be established if there is no package definition because associated app must know ahead what's at the other side. If someone will point to the non-standard package either download/extraction will fail or extraction into game directory won't be correct so the installation cannot be started properly. 1. File format: ZIP Quoting wisp: I agree that zip is very good choice, every OS has build-in support for it. 2. File extension: .iemod - Infinity Engine Mod Package Different extension allows for custom file association for double-click action and extra actions for eg: Right-Click Menu: Install to> Game Folder. Besides, it's not only zip file, it's a zip contains IE mod with specific content/rules. Zipping mod files won't prevent package mistakes, modders need to use special mod packager utility. The .iemod file extension is not the good choice, it's "Infinity Engine Mod Package", not "Infinity Engine Mod" source file. So how about .iemp as file extension? If the 4-letter extension looks odd, how about .iep (but it's already used by other programs) or .iex (no application use such extension) ? 3. Filename: Simple format: ModName-version.iemp, nothing fancy about it, mod name can be taken from metadata Name. Question: should spaces be allowed? Filename doesn't mater at all under the condition that it doesn't contains forbidden special characters/folders: Absolute minimum set of forbidden special characters: < > : " / \ | ? * '\0' (NUL) Absolute minimum of forbidden special filenames: CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 cross-platform package simply cannot contain such special characters and cannot use such special filenames because those are reserved. 4. The content of the package: Across all those years, people put crazy things inside their mod packages: executable's inside zip, double compressed files like zip inside rar, override & backup folders, Windows 'thumbs.db' cache files and macOS '.DS_Store' folders etc. So let's exclude some files and folders: $RECYCLE.BIN/ __macosx backup/ temp/ tmp/ .* !/.gitattributes !/.gitconfig !/.github !/.gitignore *.bak *.bat *.iemod *.lnk *.rar *.tar* *.tmp *.zip Thumbs.db all of those files/folders can be easy excluded at the creation time and should not be part of the final package. 5. WeiDU executable: I would much prefer a solution where modder explicitly defines the weidu version which he used in order to create and install the mod. But until we get to this point, there is a simple solution: - weidu windows: .exe - weidu macOS: no extension - weidu Linux: .bin (please don't tell me that 'Linux don't have executable file extension', it doesn't matter) this way modder can include all necessary files in order for mod to be installed. I will post universal '.command' file later. 6. Mod structure: We need to eliminate possibility of double and tipple extra top-level directories, for mods: player should be able to extract such package into game directory and everything should work correctly. The way how to do it is to check the level of the tp2/tp3 mod definition file and fail if it's more that one-level. 7. Tools: I've created packaging utility which is very similar to 'G3 ModPackage' tool but it's cross-platform and can produce .iemod packages and optionally pure .zip files, it's using ModID-version.iemod filename schema. It doesn't have validation yet but it's easy to implement. I will post it latter when I will do final touch. That's all for now, please share you feedback.
  6. Hi, let me start from make clear statement that NOTHING IS REQUIRED. Did I say that nothing is required? Yes, that's true, nothing is required. You don't have to do anything. My proposition/design also aims for be "less selfish as possible" aka "don't require anything and if, require minimal amount". I hope that's clear now. The main idea behind this is to give back the control of mod metadata in the hands of modders. Who else know the current and most up to date mod name, description or the working link to the place where players could receive support? That's right, the modder itself. The first idea was to have a website where modders could provide mod metadata. Creation of such website is very simple and can be done in one day. But then there is a problem when some other people will provide 'malformed' info about other people mods. Trolling is an art. It's impossible to counter without some sophistic login/verification method. And ofc "yet another website" will be instantly boycotted, even if it would be offer a Genie in a bottle. So without website, similar to "mod configuration file", a mod could provide few important metadata like: - Full name of the mod itself, without version number - Mod description - a direct download link to the latest version of the mod (which is intend to be used by players so no ALPHA/BETA/DEV) VERSION is dynamically read from tp2. All other missing info I can read from tp2: AUTHOR/README, but if they are inside INI, INI will have preference over tp2. This is my take on this matter: 0. File encoding: It can be ANSI if it won't offer to write Unicode strings. UTF8 no BOM, if it does. 1. File format of such file must be 'industry standard', one for all mods. And please forget about xml I can't write a custom parser for each mod only because it's author like to put spaces before and after '=' character. Or use TAB to separate key and values. Or include weidu commands which the tool can't understand. It would be too much work and errors. So let's choose one, modern 'industry standard' file format. I vote would be for INI as a first choice and HJSON/JSON5/JSON (JSON doesn't' allow comments) for more advanced modders who understand benefits of such modern format. 2. File extension of 'mod metadata file': Almost irrelevant, follow the file format definition associated extension. Those files shouldn't be modified by players anyway. 3. Filename of such 'mod metadata file'. There is one, very simple solution: <modTp2name>.ini/HJSON/JSON5/JSON. This is what is currently implemented. - it doesn't require file header / ini sections added [Mod] [Metadata] to avoid false detection - it prevents people from making multiple, outdated version of this file Other solutions require file headers/scanning mod directory and parsing files etc. 4. File content: nothing is required, you can even put one, single line Key=value pair with only mod full name. One single line. INI: Name = NPCs Enhanced for Everyone Author = Argent77 Description = This is intended to be a successor to the fantastic "Level 1 NPCs" mod. L1NPCs was never updated for the EE games, and its author is no longer active, and it is an incredible, complicated piece of work that is difficult for someone else to update. So I made this. Download = http://lynxlynx.info/ie/modhub.php?UnearthedArcana/NPC_EE Remarks: For some modders, tool could use industry standard JSON file or JSON5/HJSON, it has very strict rules, only for modders who wan't to benefit from the advantages of the JSON file format itself. Order of the preference: JSON > JSON5/HJSON > INI . It means that if you provide only INI, everything works. Later, if someone wan't to switch to more advanced metadata format, mod metadata will be read from them. I think that INI would be enough but I don't want to limit modders. 5. Presentation to user - mod metadata will be displayed inside "Mod info textbox" - in addition, mod name will be displayed at treeview/mod list - mod downoad link would be used to download new mod version (if it is supported) Example of partial INI and tp2 combination: https://github.com/ALIENQuake/ProjectInfinity/wiki/Adding-metadata-for-mod
  7. Okay, so I'm going to do a new install and I'll try to do an install order list. If possible I'd like to get some feed back before I start the installation (if anybody is able to spot glaring mistakes). Note please: I haven't figured yet out how to export an install order list properly, other than copy&pasting it. (If AL|EN doesn't want this kind of discussion in this thread, please jsut remove it or move it somewhere else) My current WIP list:
  8. Hi, I'm ready to have discussion about biggest issue when it comes to deal with mod installation without pausing for user input: READLN. I can offer modders existing solution which can overcome such problem and new solution which will fits modders needs. But no matter how good a solution might be, it requires effort over modders side or accepting contributions for their mods (but only once!) Lucky, some modders already declared the will to remove ACTION_READLN like AstroBryGuy for bg1npc (many thanks!). My wish would be that other modders will follow but they must know about the ACTION_READLN issue. First, let me demonstrate an example: Mod: Worldmap, currently as TOP1 at SHS downloads, summary of bad READLN things: impossible to present ACTION_READLN choices (input and description) for GUI installation will be paused and wait for manual user input impossible to save such mod configuration so every installation, user need to repeat providing manual input, can't use weidu commandline player choices are also not included inside weidu installation log so debbug information is lost impossible to use weidu LABEL and other functions Example of player complains: "I cannot select Worldmap mod choices and the installation is paused!" I'm bringing this topic again because after the release of my install tool, you can be pretty sure that complaints like this will occur. And when they do: Q1. What's modder answer regarding feedback, to the the one who send such complains? Q2. What should be MY answer if any player will come to me and report such complaints as a BUG of the install tool? How to solve above problems? There are 3 solutions currently available. Please keep in mind that none of the proposed solution are "BWS-Exclusive" etc: 1. Instead of using READLN, use SUBCOMPONENT functionality in WeiDU This is the best solution for such problem but it doesn't cover every cases. It require rewrite mod component logic. Using SUBCOMPONENTS is always the best and preferred way to handle removal of ACTION_READLN because unlike to INI file with settings, it can interact with other mods/components and be a foundation for internal/external dependence and conflicts. 2. READLN sometimes is used to read for eg: "Familiar Name" so SUBCOMPONENT can't be used For such cases, using config-default.ini + config.ini approach should solve the problem. Good adoption of Solution 2 can provide both ways of providing value: from user input or from actual configuration made by player itself. You can even display additional info during console installation: "The config.ini file not detected, read config-default.ini to change default configuration" - player will be aware how to use ini files even if he won't use any install tool at all. Any more thoughts? 3. Custom ini file, this one need feedback from modders who don't want to change weidu tp2 code Forget about BWS and it's cryptic @0?0_1. I think I make new format much more clear and understandable. For Worldmap mod, it looks like this: File name schema: bp-bgt-worldmap-action_readln=0.ini the '=' character acts as separator for modname and component number for the ACTION_READLN extra Input-Description data File Location: inside mod itself, side by side with mod tp2 Only one language entry is required, all missing ones will be show as the default one, so if mod have Englsh and German and you put only English section, English will be displayed at treeview [ACTION_READLN] # declaration of the first question possible input values and descriptions, section declaration without language is used as default for no language, English of for missing other entry's [Q1] # the number is the user input which will be send to console window, the description will be displayed as subnodes of the treeview 1 = Original Travel Times and Area Visibility 2 = Revised Travel Times and Area Visibility [Q2] 1 = Large Worldmap 4900x3500 2 = Huge Worldmap 8000x4600 [German:Q1] 1 = Originale Reisezeiten und Aufdeckung der Gebiete 2 = Überarbeitete Reisezeiten und Aufdeckung der Gebiete [German:Q2] 1 = Große Weltkarte 4900x3500 2 = Riesige Weltkarte 8000x4600 advantage is: it doesn't require weidu code modification disadvantage: require custom ini file for each component which has ACTION_READLN, modder needs to understand it, needs to be updated when ACTION_READLN actions/description changes I'm open to discuss anything related to the format/definition/usage of such ini file. Selected Modders who have used ACTION_READLN: @Tash @wisp @Pecca @argent77 @jastey @berelinde @Ulb @LavaDelVortel Any chance to remove READLN from you mods, using proposed solutions? @wisp, can you mark READLN as "DEPRECATED" and display warring?
  9. Hi, One of the most missed features for all past years was the ability to click one button in order to update my all local mods. Lucky, with the Github API, Project infinity can offer a possibility to update mods, which is very easy to add via one single line inside mod metadata file. Because it's github-based, it offers stability and consistency. It is impossible to download mod with malformed files, you either download it correctly or don't download it all (git feature). And for the first time, there is a possibility for so called "delta updates"! As a sidenote: Github.com now offers private repositories for free! Right now, this system is opt-in and it's based on the mod metadata "Download" keyword: Download=https://github.com/Gibberlings3/SwordCoastStratagems Wanted features: easy to integrate simple and understandable rules for modders about when mod will be updated and how Assumptions: Mod use Github hosting (or the site which provide API) Mod has metadata file and filled 'Download=' keyword the update process don't touch mods inside game directory, only the mods from the directory where user has placed all mods General Flow: Phase 1: Read Mod Metadata "Download" keyword > Check if update exist > Present 'Update Available' for specific mod > do nothing until player hit "Update Mod" button Phase 2: the "Update Mod" button was clicked > Download update > extract and overwrite all mod folders and files / preform delta update and also overwrite all mod folders and files How it would work: Checking if there is a updated version of the mod is done automatically (but not the update itself) Notification about the update will be presented to the player ('Update Available' next to the mod name, "Update mod" button enabled") The update itself can be only accepted/started by player himself (in order to not break existing mod/components setup) Leave user-created files inside mod data folder intact for eg: mymod\mymod-config-user.ini Which update channels would be offered for players: if mod has releases, offer to update only if there is a new release if mod has only prereleases, offer the update for prereleases if mod has both releases and prereleases, offer the update for releases only, do not offer the update for prereleases unless there is a global option "Allow for prereleases" enabled if mod doesn't have any releases or prereleses, the assumption is made (mentioned at 'Download=' keyword documentation ) that the modder use master branch. For many modders, simply committing to master branch seems to be enough and I don't want' to force them to make releases. Modders can simply create Release in order to switch update chanel. When player decides to update the mod, there are two ways of updating locally extracted mod files: downloading release/prerelease, extract and overwrite all mod folders and files preform delta update, also overwrite all mod folders and files My main concerns are: Should I offer "Prereleses" for normal users, who aren't interested testing BETA versions and reporting bugs? (opt-in option?) Should I offer "download last commit" aka "experimental" for mods which do have releases/prereleases? (undocumented option?) Should I offer "download last commit" from specified branch like "devel" (undocumented option?) @argent77 AFAIK, you alone use different branches. What to do with files which were available in older version (let's say MYMod\Items\SWORD.itm) but the new one doesn't have them anymore? Removing old mod version directory entirely could potentially remove also user-generated config (only two mods have them but it's still important). If such problem occur, any kind of solution for is doable at this stage. No worries, files non-present inside new mod version are removed. That's everything for now, any feedback will be appreciated. @K4thos Enabling this for EET will allow for EET delta update without re-downloading 250+ MB, what do you think?
  10. 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.
  • Create New...