Search the Community

Thought it might be good to have a thread of stuff that's broken but requires fixes in the engine itself. This is stuff that, generally, EEFP won't be able to fix. I'll start with an oldie but goodie: using the auto-pause for 'spell cast' causes all sorts of issues. To replicate, start an IWDEE game with a druid and at least one other character. Memorize some Sunscorch spells on your druid, rest your party, and enable 'Spell Cast' on the auto-pause menu. Cast Sunscorch on the other party member. Pausing on the moment the spell is cast causes each individual effect in the spell to be rolled separately for saves and probability. In the attached screenshot, the target has made their save against the actual blind effect, but failed the save for the blind icon, 'blinded' message, and damage. These effects should all roll one save collectively and either all be blocked or succeed.

@yota13 asked about translations in the intro thread, so I thought I'd expand a little more on this and give it some visibility, as I've tried to set up the mod to be super-friendly to translators. If you look in the repo, everything's already tra-ified. Here's what each of these files are for: weidu.tra - [required] This file contains text that will appear only in the installer: things like component names, warning messages, and the like. You can also add the special strings for language-specific WeiDU prompts here as well. bgee/bg2ee/iwdee/pstee.tra - [required] These are for new strings that are needed to fix a bug. At present the only new string is for BGEE to fix the Advanced AI scripting that references a missing string. fixes_bgee/fixes_bgee_sod/fixes_bg2ee/fixes_iwdee/fixes_pstee.tra - [optional, should probably be translated] These are meant to update game strings directly for factual errors in strings, e.g. correcting a spell duration or an item weight. Any entry of the form @xxx will be used to update string #xxx automatically, and this will be done independently of what's done in the English translation. So if there's some fix that needs to be done in Russian and not English, you simply add it to the Russian tra file and it'll be picked up automatically. This also means that if there's an update in the English tra file and it's not needed in Russian, you can skip it. gtu_bgee/gtu_bgee_sod/gtu_bg2ee/gtu_iwdee/gtu_pstee.tra - [optional, language-independent] These form the basis of the Game Text Update (GTU), which is meant to correct language-specific errors like typos or grammar. Like the fixes_ series of tra files, these will use @xxx entries to update string #xxx automatically, and this will be done independently of what's done in the English translation. In other words, the language-specific GTU can be done entirely by your communities in the tra files, without intervention from the rest of the EEFP team. infinty.tph - [optional, language-independent] To cut down on work for the translation teams, Beamdog consolidated about 750 common strings for the UI/help into a LUA file, which was handled by the 'Infinity Strings' section on their translation tool. Because these are stored in a plaintext LUA file and not the tlk, they need a slightly different approach for updating; see this auto-generated example for Polish. The idea is simple: the name of the string from the LUA goes on the left, the next text on the right. These updates will be applied to BGEE/SoD, BG2EE, and IWDEE games through the Game Text Update. Like the gtu_ and fixes_, this will be done independently of what's done in the English translation. Other Notes There's a tool that can generate a basic GTU and/or infinity.tph by comparing the current strings in the Beamdog translation tool against the current game release (3.1.4 for PsTEE, 2.6 for the others). Ask Cam and he can run the tool and generate these in your language. Note that some of the fixes_ and gtu_ tra files are prefixed with an underscore, "_". This just means there's no strings needed there yet and the installer will ignore the file. However if there is a string needed in your language, just add it to the file and then rename the file without the underscore and the installer will pick it up automatically.

The Enhanced Edition Fixpack (EEFP) is a community project aimed at fixing bugs in the Enhanced Editions of Baldur's Gate, Baldur's Gate II, Icewind Dale, and Planescape: Torment. Since these games are still being actively supported, the plan is to provide fixes for issues on the latest patch of these games with the goal of getting them into a future official patch. There is no current release but the first beta is being coded. To that end, we've had a discussion about what we're trying to fix (tl;dr primarily developer intent), maintaining a list of issues that would have to be fixed by Beamdog at the code level, examples of an idealized bug report, and a FAQ to get started. Like the BG2 and IWD Fixpacks, we're also committed to being transparent--there are no hidden workrooms and the project is on Github. One of the goals of the forum is having robust discussions about what to fix and the best way to fix it, and player input on these issues is critically important. That's the main takeaway for players: you can help! The easy one is providing bug reports--no, you don't have to write up something as formal as the idealized bug report, but it would be helpful--and discussing issues in the forum.

I thought this would be a good place to discuss and lay down some guidelines for what we, collectively, consider something that needs to be fixed. BG2FP and IWDFP adhered, fairly rigidly, to a standard of developer intent: if something was working contrary to how we thought the developers intended, we fixed it. This could range from a rules table having an incorrect entry, a spell's effects not matching what its description claims, NPCs who had armor equipped in quick slots, and even basic syntax errors in scripts and dialogues. I think it's a good standard, but one that also requires a good group to discuss proposed changes. At least, that's the proposal. Thoughts?

I've just spent a couple of hours trying to understand the intended uses of opcodes 109 ('Paralyzation'), 175 ('Hold Creature'), and 185 ('Hold Creature 2'), all of which are pretty much functionally identical afaict - they all impose immobility and script-stopping, gated by an IDS check. Mostly I was looking at unmodded, unfixpacked, vanilla BG1 and BG2, where the original intention is clearer. (IWD is another matter and I haven't really looked at it yet.) Here I think is the underlying logic. (Summary: 109 represents innate paralyzing effects, though it also unnecessarily doubles up representing Web; 175 represents Hold spells; 185 represents things that fix you in place through some external mechanism.) 109 is used almost exclusively by items that cause paralysis, such as the undroppable weapons used by ghouls and carrion crawlers. The IDS check is rarely functional: you're affected by a 109 unless you have explicit protection from it. It is almost always associated with the 'Paralyzed' string. Many classes of monster - dragons and undead, for instance - are immune to it; you also get immunity to it from Free Action, Chaotic Commands, et al. Complicating matters, though, 109 is *also* used by Web spells, both in BG1 and BG2 (the 'mimic glue' effect in BG2 also uses it). This is actually unnecessary, at least in EE: the web effect (opcode 157) is invariably associated with Web, and it imposes the paralyzation condition all by itself. However, it's clear that Bioware *didn't know that* and thought 157 was cosmetic (and they may have been right: I'm not sure whether this is EE behavior). There are quite a number of places in BG1 and BG2 where it is fairly clear that creatures are given 109 immunity because they are supposed to be unaffected by webs. (It's fairly clear for wyverns, which have no obvious lore reason not to be affected by paralysis (and are big enough to look stupid when Web Effect Overlay plays over them) and have an item that blocks 109, 157, and Entanglement effects; it's equally clear for Kuo-Toa, who get similar immunities to implement their PnP slipperiness trait; it's probably true for Beholders, who can presumably float above webs but have no obvious canon reason to get paralysis immunity.) 175 is used pretty much exclusively by paralyzing spells, almost always labelled 'Hold' (Tanar'ri paralysis is an exception) and is almost always associated with the 'Held' string. Creature immunity doesn't normally affect it: you get immunity to it through situational things like Free Action. 185 is used *very* rarely, and very few things are immune to it. In vanilla BG1, *nothing* is immune to it, and the *only* spell or item which uses it is Otiluke's Resilient Sphere. I think the underlying idea is that 185 represents things that physically prevent you from moving, but through some external barrier rather than directly slowing or freezing you. (On this basis, players should never be immune to 185, and probably only minhp1 items should grant it, to avoid the usual scripting problems. In BG2, however, I think the logic of this breaks down quite badly: boss monsters get immunity to 185, but it gets granted by some items/spells that really shouldn't grant it (some but not all fixed in FP or EE). I think the designers kind of lost track of what they'd intended. They also use 185 to double up as a cutscene can't-be-blocked effect (e.g. HELL_HOLD), but that is (or should be!) harmless since players shouldn't be protected from 185 anyway. I think the designers lose track of this general scheme a bit in BG2, and slightly more in the Enhanced Editions, but I think it's probably what we should be running with. I'm going to post a bunch of suggested bugfixes that rely on this architecture.

I've spent the last couple of days wading through the forum, trying to make sure bug reports don't get missed. As such, I've started using the tagging system to track topics and settled on the following tags: open - A bug report for which no action has been taken yet, or needs investigation. need-info - A bug report we can't replicate and we're waiting on the original bug reporter for more information. closed - A bug report that we're not taking action on for a variety of reasons: could be a duplicate, not a bug, fix is worse than the bug, &c. committed - A bug report that has been fixed and added to the repo. ongoing - One of a handful of threads where folks keep reporting bugs and the fixes are a running process. meta - For tagging threads (like this one) where the content is informational or a discussion. The six tags above are meant to be exclusive--e.g nothing should get an 'ongoing' and 'committed' tag. code - Used to denote issues we can't make to the engine or codebase or where a code change would result in a better bugfix. bgee, bg2ee, iwdee, pstee - When a bug is moved to committed, the game gets tagged to help documentation. These tags are nonexclusive, though I generally wait until a bug has been committed to add the game tags. Don't worry about tagging posts; one of the devs will handle it. Suggestions for the existing tags or for new ones are welcome!

I've been spending the last week on documentation, woo! Available off the main project page, you'll now find: An EEFP gallery BGEE/SoD fixes BG2EE fixes IWDEE fixes PsTEE fixes edit: now current as of November 8, 2022. If you spot typos or grammar mistakes, let me know. For the devs, specifically @Luke, @argent77, and @DavidW: the goal is to write the docs to be accessible to players, so I end up glossing over some of the finer details. Please review the stuff I've written for your fixes and make sure I haven't done a too much glossing--or rewrite them to your heart's content if you so desire. Feel free to post here with corrections or submit pull requests for changes (the pages are sourced from the HTML files in the repo's docs folder). If you have an image and/or descript update for the gallery, unfortunately that has to go through me.

How important is the EE Fixpack and how does it relate to the EET Fixpack? Thankee!

The EE Fixpack (EEFP) is a community-created unofficial collection of fixes for BGEE, BG2EE, IWDEE, and PsTEE. The goal is to supplement the latest releases while we wait for the next official patch, as well as provide a forum where we can discuss bugs and fixes as a community. Is this endorsed or supported by Beamdog? No. Any bugs we identify will be filed with Beamdog's bug tracker in the hopes of making it into future patches, but there's no formal relationship. Which version of the game does the EE Fixpack support? The EEFP supports the current version of the games, which (at present) is v3.1.4 for PsTEE and 2.6.6 for the other games. As new patches get released, EEFP will be updated to work with the new versions. Support will not be provided for older versions. Can I install this on a game in progress? The EEFP, at the end of the day, is just another mod. (First time modding the game? We've got a tutorial for that.) As such all of the usual caveats of mod installation apply: installing it on a game in progress will probably result in issues. In terms of install order, it should be installed first with the sole exception of BGEE+SoD games from Steam or GOG that require DLC Merger first. What about EET? Ideally you'd install EEFP on both of your BGEE and BG2EE games before merging them. However, at present the EET installer will reject a BGEE installation if a mod is installed that it doesn't recognize. Until EET updates, the current recommendation is to use EEFP only on the BG2EE game. Can I get these fixes for other platforms, such as mobile (Android/iOS) or console (PS4, Switch, Xbox)? The tool we use, WeiDU, is easily deployed for Windows, macOS, and Linux. Unfortunately while there are some workarounds for getting mods to install on other platforms, it's not something we can easily test and therefore the EEFP will only be actively supported on desktop. How do you define a bug? The short answer is that a bug is anything the developers didn't intend. There's also a longer answer. In some cases we can identify a bug, but there may be multiple ways to go about fixing it. There's a natural tendency to want to 'fix' things because it'll make for a better game, so having robust discussions on issues is critical to keeping the EEFP high-quality and to prevent feature creep. As such feedback and suggestions are welcome in both the identification of bugs and how to fix them. What about exploits? Are those considered bugs? In general we'll take the same approach that the BG2 Fixpack did: if it's an exploit a player can reasonably run into and is not intended by the devs, we'll close it. We want the game to be as bug-free as possible for players, but we're not going to close some obscure exploit just because. I'm a player. How can I help? There are two ways to contribute: if you encounter a bug, report it with as much information as you can provide. (If you're on a modded game and aren't sure if the bug is due to the game or one of the mods, report it anyway.) Also, feel free to discuss bugs and fixes within the forum; one of the things that made BG2FP successful was having robust discussions about what to fix, and how to fix it. More feedback leads to better solutions. I'm a modder. How can I help? All the things that players can do, above, plus contribute your own code. The EEFP is meant to be a community project in the truest sense--there are no closed workrooms and the project has been on Github from the beginning. You're welcome to contribute fixes (read this first) or other improvements via pull request.

Doing spell/item immunities properly requires some rearranging of the order of effects in spell/item headers, and some extraction of effects into subspells. I wrote a generalized framework to do this, which might be useful for some other bugs. It's controlled by the rearrange_itm_spl function, in %MOD_FOLDER%/files/tph/dw/rearrange_itm_spl.tph. That function runs at the beginning of the dw_fixes section of the FP (though it could easily be moved elsewhere). It looks at the (hand-generated data) in this folder: %MOD_FOLDER%/data/rearrange/[game]. ([game] is bg2, bg1, iwd, sod - as appropriate). That folder contains 3 files. reorderings.txt defines permutations of effects, and looks like this (all examples are from bg2): object ability permutation ax1h10.itm -1 1,0,2 blun12.itm -1 1,2,0 blun25.itm -1 1,2,0 hamm10.itm -1 1,2,0 hamm11.itm 0 1,2,0 dwfpdeva.spl -1 2,1,0 dwfpohdv.spl -1 2,1,0 In each row, the first entry is the object (an itm or spl file) that needs its blocks rearranging. The second is the header that gets rearranged (-1 if all should be). The third entry is a permutation: a comma-separated list of the first N nonnegative integers. So the permutation '1,0,2' says: put block 0 in location 1; put block 1 in location 0; put block 2 in location 2. (In all cases, these entries are to organize an undead-disrupting weapon's effect stack so that damage comes first, then the death effect, then the 'you die' message.) item_subspells.txt looks like this: itm ability subspell extract deva 0 dwfpdeva 4,5,6 ohbdeva 0 dwfpohdv 0,1,2 spermel 0 dwfpsmst 11,12,13 spermel 0 dwfpsmsl 1,10 wand12 0 dwfpwwfs 5,15 wand12 0 dwfpwwhs 3,4,14 note the interweaving of the last two In each row, the first entry is the resref of the item to be patched. The second says which ability block is to be patched. The third is a new spell (and so needs to be unique, with a modder prefix - and in my case a modder subprefix so I don't worry about overwriting SCS!). The fourth is a comma-separated list of effects. All those effects (counting from 0) are extracted from the item and placed in a new subspell that the item casts. Probabilities and saving throws remain on the parent item; everything else gets moved to the subspell. (So all the extracted blocks need the same probabilities and saving throw data, and it doesn't make sense to extract a damage-doing effect that uses save-for-half.) (Incidentally, you can reuse a subspell if you're 100% confident that the contents will be exactly the same.) spell_subspells.txt looks like this: spl track_levels subspell extract insanity 0 dwfpdgfb 6,7 insanity 0 dwfpdgcn 0,1,2,3,4,5 It works basically the same way, for spells rather than abilities. The main difference is that all headers get the rows extracted (so this shouldn't be used with spells that have different effect structures at different levels). By default the code assumes that the effects are exactly the same at each level; if not (e.g. a varying duration) set the second column to 1. (In the example above, note the order - we need to extract the later effects first, because extracting the earlier ones will renumber the later ones.) rearrange_itm_spl first does the subspell extractions, then the permutations (so you can permute a subspell). It then does a small number of rearrangements that are too complicated for this automated structure (currently, only 3 White Doves). You can also do permutations and extractions on a per-item basis, using the underlying functions that these tables rely on (located in dw_functions.tph, currently loaded in the ALWAYS block). I'll put them in a separate post.

This just came up in another thread so I thought it might be worth writing general instructions. There's a function in EEFP ('get_strings_from_game') that will collect a set of specified strings from the tlk files of any IE game. (For instance, if a spell description is more accurate in IWDEE, we might want to get the IWDEE line and bring it over.) The advantage of automating this is that we can get the strings from all languages at once, without worrying about having to have the line translated. The function runs offline - i.e. it shouldn't appear in live code. To use it: 1) Install the fixpack in the game you want to copy from. (I tend to put directory junctions from my master copy to all the games, but you can just copy it.) 2) Add a temporary component to the tp2 that looks like this: INCLUDE "%MOD_FOLDER%/files/tph/dw/get_strings_from_game.tph" OUTER_SPRINT $strings("35786") "" // 35786 is the strref of the string you want // add any other strings you want in the same format LAF get_strings_from_game END 3) Run that component. The string(s) will be added to a tra file in the %LANGUAGE% subdirectory for every language in which the game is installed. (For instance, if you copied from IWDEE, it will be entered in %MOD_FOLDER%/lang/%LANGUAGE%/copy_from_iwdee.tra.) The tra ref is the same as the original strref: in the example above, @35786 will be set to the string at strref 35786. 4) Uninstall the component. (The edit is permanent: it won't be wiped on uninstall.) 5) Remove the temporary component, and make sure your master copy of eefixpack is updated with the contents of the local copy you've been working with.

I've written two functions for the FP, both in %MOD_FOLDER%/lib/dw_functions.tph. permute_effects is a patch function: here's its documentation. extract_effects_as_subspell is an action function: Please use freely (and let me know if you find bugs; one of the reasons I code this way is so that the nastier bugs stay in central places and can be fixed centrally).

i have seen a number of discussions around here that have included, or even concluded with, a statement along the lines of "that can just be an optional component." I want to make the case that this is a mistake, and the ease of saying "eh, toss it in the optional bin" makes it a bit too easy for this mistake to be multiplied. First, as a conceptual matter, this is blatant scope creep. The purpose of this project is, avowedly, to fix bugs and problems and inconsistencies such that the state of the resulting files better reflects developer intent. What that precisely means is subject to discussion and even debate, but it has the benefit of being very simple, and it doesn't really admit options. Either a fix falls into that category or it doesn't. I know that deciding that may make winners and losers at times, but it is still worth deciding. The term "optional but cool" has been bandied around, but honestly, you know what is optional but cool? Every mod on this site. There are any number of mods floating around that advertise "fixes" and "restorations" and making game files more consistent and making the games hew more closely to the PnP rules. All of those are very good mods, but they are not The FixPack. The Fixpack is designed to have special status among mods. This was stated outright in the early discussions about this project. It was suggested that 1) this mod would always be suggested to be first in the install order; and 2) this mod would always suggested to be installed. And I guess 3) the hope is that the contents of this mod might be adopted by Beamdog and included as the default game state in a future patch. This suggests there is a secondary purpose of this project: that it will provide a stable and predictable state of the game, on top of which all other mods should be installed. You just can't ignore the fact that this is being created in the context of a stable of many other mods that have existed for many years. That is the environment into which this is being born. Looking at the older FixPacks, it is fairly uniformly suggested to players that they be installed, and installed first. This means that other mods come to rely on the FixPack'ed game, and its presence even figures into troubleshooting problems sometimes. Optional components undermine the pride of place this is intended to have among mods. They undermine the FixPack's ability to provide a stable foundation for other mods. To be clear, I am not arguing that compatibility with other mods should factor into whether something is deemed worthy to include here. That's a different argument. My point is that having multiple optional components can lead to compatibility and troubleshooting difficulties - when a player says "yes, I installed the EEFixPack" a modder will not know what that means as far as the state of the game files and how to replicate problems. And, it risks this for no reason - a putative optional component will not advance that stated goal of this project, which is to fix things that are errors going against dev intent. "Optional but cool" sounds nice... but it sounds nice as a distinct project. It would be totally worthwhile making an "Optional But Cool Fixes and Tweaks" mod and it's a great idea to collect ideas for that here. But the variable contents of such a mod should not have to be assumed when someone says "I installed the FixPack," and the contents of such a mod should not have to be shoehorned into position #1 in the install order just because it gets tied to the hip of the real Fixpack without due consideration. I think that's me case. Feel free to argue, nitpick, curse my family for generations, whatever. But think about it, at least.

First, what's this about? That "hostile" flag does two things that I'm aware of: anything with it that hits a creature activates the "attacked by" script trigger, and anything without it bypasses level/school/sectype protections when applied to the caster. This lack of a "hostile" flag is why there are specific spell protections on stuff that provides protection to a class of spells. Demiliches get specific protection against Incendiary Cloud on their item which already provides immunity to level 8 spells, because otherwise a cloud they cast themselves could hurt them. Change the spell to be hostile, and that effect isn't needed anymore. A lack of a "hostile" flag can also allow for some very cheesy tricks based on the other effect here. For example, the Wand of Paralyzation's ability isn't currently flagged hostile. In my speedrun, I had my character's ferret familiar equip such a wand, walk into Sarevok's sight, and start using the wand. He saves? No need to do anything, that wasn't an attack. He fails his save? That was an attack, so now he goes hostile ... but he's also stunned, so the summoned monsters beat him to death in complete safety. As a general rule here, I'd say that if the primary effect would register as an attack and cause neutral NPCs to go hostile immediately, the spell/ability should be flagged as hostile. Magic Missile should be considered a hostile spell, even if a mage with Shield up absorbs it completely. Single-target spells and effects that you want to hit enemies with should also be considered hostile, even if their effect wouldn''t do it on its own. Spells with party-friendly projectiles don't really matter here; the issues we care about only come up when the spell hits the caster or a neutral/friendly NPC. They might still be worth changing for consistency; I don't think it hurts to have just about anything that only targets enemies flagged as hostile. One specific thing to note: charm spells/abilities need to lack the "hostile" flag. With the flag, they break themselves immediately. I've gone through the level 1 through 5 mage spells available to players in BGEE comprehensively. Spells that aren't hostile but should be: Mage 1: Burning Hands, Larloch's Minor Drain, Magic Missile. Note that the "drain to caster" effect of LMD is handled with a flag on the damage effect; it doesn't need to bypass caster protections. Mage 2: Aganazzar's Scorcher, Melf's Acid Arrow. Mage 3: Flame Arrow, Skull Trap, Vampiric Touch. Skull Trap is the first spell that gets exceptions written into spell protections. Mage 5: Cloudkill, Cone of Cold, Sunfire subspell There are also some optional changes for consistency on party-friendly spells: Horror, Hold Undead, Slow, Confusion, Teleport Field, and Hold Monster could/should be flagged as hostile. After all, Hold Person already is.

I'd like to split the discussion of item duplication into two, since it's getting fairly confused. In the other thread, we can discuss whether de-duplicating items is a bug at all, and whether it should be included in the main EE fixpack, or made an optional component, or gated by an ini check, or just left out entirely for another mod. This thread is for discussing how to do item deduplication, on the assumptions that 1) we want to build a component that removes either all, or all but one, of each duplicated unique item and replaces it with a generic item 2) as much as possible that component wants to be guided by developer intent, but recognizing that a certain amount of intelligent guesswork may be required to discern that intent. Where that component goes can be separated out from how to design it. (If it absolutely shouldn't go in FP it can always go in SCS or Tweaks.)

Since FP uses SCS's weidu_external folder to manage some external file generation and to do backups, I thought it might be useful to put a copy of the file conventions for weidu_external here for reference: In particular, if you just want to make something on the fly and need a temporary file, just put it into weidu_external/workspace - no need for a bespoke folder with a modder prefix, because the convention for workspace is that it's used and forgotten about component-by-component.

I'd like to split the discussion of item duplication into two, since it's getting fairly confused. In this thread, we can discuss whether de-duplicating items is a bug at all, and whether it should be included in the main EE fixpack, or made an optional component, or gated by an ini check, or just left out entirely for another mod. The other thread is for discussion of the details of how to do item deduplication.

There are fewer reused unique items in BGEE and BG2EE than meet the eye (many are undroppable, or copies where you can only see one on a given playthrough), but there are still some. In almost all cases, the reason is obvious: the item has a generic name (Bracers of Defense AC 6, Ring of Protection +2, Scimitar +2, etc) even though the description makes it unique, and it's easy to see how developers in a hurry gave an apparently-generic item to a monster and forgot that it wasn't generic after all. (It's notable that duplicates normally occur off the critical path, or in stores, or in expansions.) The dialog.tlk changes made by BGEE and BG2EE make this less obvious (for instance, the unique Bracers of Defense AC 6 are now called 'Bracers to the Death') but those changes happened quite late in the development cycle. (I also think they're ill-judged, but that's another matter.) I think it is pretty clear that developer intent was not to have duplicates and so, if possible, we should fix this. I propose that in general the simplest plan is to replace most occurrences of a unique item with a generic version. Normally that would require new description text, which is generally a no-no in a fixpack, but fortunately most of the items already have a generic version either in oBG2 or in Siege of Dragonspear, so it's easy enough to produce it. There is a question as to how to allocate the actual unique item, but usually it's fairly clear. In the next few posts I'll list the various duplicates in BG1 and BG2, along with some edge cases and some problems I'm not sure how to resolve.

As I understand, this mod should be installed first before anything else, right? I was wondering, are any of the fixes likely to cause an incompatibility because some other mods rely on some bug or inconsistency of the base game? Just wondering, I don't know much about Infinity Engine modding. Speaking of which, is a release coming anytime soon? I'd love to use it in my next playthrough.

I've just fixed a UI bug (this one) and I thought it might be a good time to consider generally how we might fix UI bugs in the FP. I can think of four options: (1) Distribute a new version of ui.menu Advantages: extremely simple, takes advantage of being first in install stack. Disadvantages: ui.menu is 25,000 lines long. Distributing a modified version is a maintenance nightmare; the code isn't even faintly self-documenting (you'd have to look using grep or something to find the changes). (2) Do a carefully-chosen REPLACE_TEXTUALLY on ui.menu Advantages: simple, reasonably self-documenting. Disadvantages: you're doing a global search-and-replace on 25,000 lines of live code. I think that's intolerably dangerous. (3) Replace ui.menu functions via a new .lua file (probably m_cd_fix.lua). Advantages: safe, fairly clear, fairly self-documenting. Disadvantages: it's awkward to override functions that are still in code via later code; it's not a good mesh with a possible BD adoption. Most importantly, it only works for function updates; it won't work for all fixes. (4) Use a function library that lets you do targeted edits on ui.menu - e.g. SCS's lib_ui, which is self-contained(!) and has documentation(!!) Advantages: clear, powerful, save, self-documenting. Disadvantages: steeper learning curve/more abstract, theoretical risk of bugs in the functions (though I think these are fairly safe). It's probably obvious that I prefer (4), and indeed I've fixed the above bug that way, and uploaded lib_ui and its documentation to the beta. But there are certainly counter-cases to be made.

In addressing the unique items bug, I needed code that would take a string from one IE game and make it available in another. It was convenient to address this generally, and it might be useful elsewhere. The relevant function is get_strings_from_game, in eefixpack/files/tph/dw/get_strings_from_game.tph. You call it like this: LAF get_strings_from_game STR_VAR strings=[whatever] END Set 'strings' to the name of an array that stores the strings you want in the format [strref]=>[discard]. It collects the strings at those strrefs from every language installed on the game, and saves them in eefixpack/languages/[language]/copy_from_[game], where game is either 'sod' or the value of the 'game' variable. This is all done idempotently and doesn't get rolled back if you uninstall a component. (Obviously you shouldn't use this in live code; it's to be used in advance to get all the strings without tedious copy-paste.)

... account for checks becoming unnecessary? LSS: is there something I can do now writing a mod that will help its transition to the next patch? And remember, I am an idiot.

Now that I've finished my minor side project, it's back to the salt mines Fixpacking. I'd like to get the repo open so we can everyone involved--how does Wednesday sound for an announcement?

I guess the right time to talk about the architecture of the code is at the beginning. I don't want to get too picky about this, but some suggestions: (1) Put each discrete fix or closely-associated group of fixes in its own file, with a memorable name, e.g. "some_spells_should_use_opcode_185.tpc" (2) Put each file in a directory called 'fixes' (we can also have a 'resources' directory for game files, a 'lib' directory for function libraries, etc). Then the tp2 component just needs to be ACTION_BASH_FOR "%MOD_FOLDER%/fixes" ".*\.tpc" BEGIN WITH_SCOPE BEGIN INCLUDE "%BASH_FOR_FILESPEC%" END END I think that architecture is fairly easy for people to contribute to, is properly encapsulated, doesn't end up with people working on the same file unnecessarily, and is easier to test and read. Given modern WEIDU I'd strongly prefer not to just have an enormous list of patches directly in the tp2 (no criticism of fixpack intended, WEIDU has evolved out of recognition since its architecture was developed). You could separate the fixes section into BGEE, BG2EE, IWDEE, PSTEE, shared if you wanted (and indeed could pretty easily rearrange like that later in the project - that sort of change is also easier if every fix is in its own file). (3) Use AUTO_EVAL_STRINGS. It makes for much cleaner and more readable code, but there are very rarely incompatibility issues with code not written under AUTO_EVAL_STRINGS and so it makes sense to have a definite decision to use it. (Or a definite decision not to use it, but in that case I probably won't contribute code because I'm very used to it by now.) (4) Follow SFO's protocol of defining every spell.ids entry in the preamble as a variable, i.e. WIZARD_FIREBALL is spwi304. I think it makes code much easier to read and catches a lot of bugs. (And no-one actually has to use it!) (5) (Possibly) use my slightly-extended versions of your *_EFFECT libraries (in, e.g., SFO) which define a bunch of bit variables and, probably more usefully, let you match on a function and patch with a function. (6) Make the whole fixpack depend on a very large number of libraries which are all mutually dependent and which contain hundreds of idiosyncratic functions that are largely undocumented. I'm willing to compromise on (6).

Are the "old" BeamDog Redmine (http://redmine.beamdog.com/) bug reports still available somewhere?