Jump to content

Search the Community

Showing results for tags 'Install'.

  • 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
  • Modding Discussion
    • IESDP Updates and Info
    • Modding How-Tos and Tutorials
    • Modding Q&A
  • Mods and Tools
    • Tools
    • NPC Mods
    • Tweaks and Fixes
    • Item, Kit, and Spell Mods
    • Quest Mods and Other Mods
    • Miscellaneous Released Mods
    • Unreleased Projects


  • Community Calendar


  • 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 4 results

  1. The EE Mod Setup Tool (for windows) Overwiew EET installs get more complex now that more and diverse mods are available to enhance the basic game. K4thos, the EET author recommended BWS for save installs when he started the project. However, original BWS has lost the supporters it had in the past and slowly decayed. This tool is aiming to provide similar functionality to mod EE games in large scale. The BWS-EE is a fork from Big World Setup (BWS old) which was originally created by dabus. BWS-EE is streamlined to serve EE game installations in a way that is up-to-date and maintainable still. While the tool was mainly intended to support EET, it also can be used to mod other EE games as listed below. Features: - assistance for creating your own customized game with any number of mods - downloading current versions of selected mods - easy mod installation for EET - correct install order of mods/components - merges SoD DLC with BGEE if needed - handle mod and components conflicts and dependencies - apply interim fixes when needed. - use players' tested compilations - save your own compilations for re-use or sharing Supported games: - Baldur's Gate: Enhanced Edition (standalone game) - Baldur's Gate II: Enhanced Edition (standalone game) - Enhanced Edition Trilogy EET( BG1:EE + SoD + BG2:EE ) - Planescape: Torment Enhanced Edition - Icewind Dale: Enhanced Edition Supported mods - All actively maintained or properly completed ones! (make a pull request if there is a mod you want added) DOWNLOAD Mod requests : Create a pull request https://github.com/EE-Mod-Setup/EE-Mod-Setup or post a request at: Support https://baldursextendedworld.com/Install-Tool/ Changelog https://github.com/EE-Mod-Setup/EE-Mod-Setup/commits/master
  2. The Tweaks Anthology used to work for me it no longer does no matter if I completely uninstall it, Baldaur's Gate II Enhanced Edition, and Steam the result is always the same... But is there anything else before I go to these extreme measures? (I have to get a new OS reinstall disk for one and I don't know how to format my only working SSD (my HHD broke). I posted this already but I am doing it again because I really don't want to reinstall Windows (or format).
  3. I would like to get your feedback, thoughts, and experience regarding the installation routine of WeiDU mods. Assume that we have a mod called "MurphyLaw" , version "1.1.1" with the description of "Anything that can possibly go wrong, does." Most players have this mod installed with version "1.1.1". After a long time, there was an update to "v2.0.0". Players want to update the mod. For every possible case that might exist, what would be the safest and least error-prone workflow in order to have a successful mod update? Case A - Single mod or the mod that was installed as the last one A1 - What players do: Extract new 'MurphyLaw v2.0.0' version into the game directory, overwriting old 'MurphyLaw' files Re-install the same components by launching Setup-MurphyLaw and selecting "Re-install" for every component (WeiDU will then reinstall updated MurphyLaw) A2 - Proposed workflow: Keep the names of the currently installed components Uninstall the old version of the 'MurphyLaw' by launching Setup-MurphyLaw --uninstall Remove old 'MurphyLaw v1.1.1' directory from the game directory Extract 'MurphyLaw v2.0.0' version into the game directory Install the same components again by their names Case B - Updating and reinstalling mod that was installed between other mods: B1 - What players do: Extract new mod version into game directory overwriting old 'MurphyLaw' files Re-install the same components by launching Setup-MurphyLaw and selecting "Re-install" for every component (WeiDU will then reinstall updated MurphyLaw and all mods installed after) B2 - Proposed workflow: Keep the names of the currently installed components for the 'MurphyLaw v1.1.1' and for all other mods installed after Uninstall all mods after the updated mod by launching Setup-MyMod --uninstall in reverse order from WeiDU.log Uninstall the 'MurphyLaw v1.1.1' by launching Setup-MurphyLaw --uninstall Remove 'MurphyLaw v1.1.1' mod directory from the game directory Extract 'MurphyLaw v2.0.0' into the game directory Install 'MurphyLaw v2.0.0' using the same components Install all remaining mods that were installed after updated mod Explanation: Why uninstallation and removal is required instead of simply overwriting the mod files? The first reason would the way how WeiDU handles reinstalling mod components. WeiDU keeps 'uninstall information' inside sub-folder name of component index number or mod DESIGNATED number if exist. "MurphyLaw v1.1.1" comes with 3 components: "Weapons", "Armors", "Shields". WeiDU.log contains the following: ~MURPHYLAW/MURPHYLAW.TP2~ #0 #0 // Weapons: v1.1.1 ~MURPHYLAW/MURPHYLAW.TP2~ #0 #1 // Armors: v1.1.1 ~MURPHYLAW/MURPHYLAW.TP2~ #0 #2 // Shields: v1.1.1 "MurphyLaw v2.0.0" comes with 6 components components: "Armors: Mail", "Armors: Plate", "Shields: Large", "Shields: Medium", "Weapons: Sling", "Weapons: Spear". The indexes of those components are 0,1,2,3,4,5. So If you do 'Extract> Overwrite and Reinstall' you would actually install completely different components of "MurphyLaw v2.0.0": "Armors: Leather", "Armors: Plate", "Shields: Large" The next thing would be the code loops. Mods often contain code that has some sort of loops: for (every file inside MurphyLaw/ITM directory) COPY file TO override directory. If the author of "MurphyLaw v2.0.0" removes some files from the MurphyLaw/ITM directory and the user simply extract the new version into game folder, the old files won't be removed. Mod re-installation via weidu will still copy old files that should no longer exist. This also can lead to problems and false bug reports. Questions: Assuming that even if I A2 and B2 workflows are complicated and manually preforming those steps require multiple actions and is time consuming: Do you think that those are correct or there are some missing steps that I should include? Do you think such A2 and B2 workflows should be the default and forced when the players re-install mods to achieve safest and least error-prone mod updates? @Wisp Could you provide insights?
  4. 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.
  • Create New...