Sam.

I have done some initial research into the current state of the item (inventory) icons in the Baldur's Gate series of games: oBG1 (AKA TotSC v1.3.5521), oBG2 (AKA ToB v2.5.26498), SoD v2.6.6.0, and BG2EE v2.6.6.0. I have attempted to capture all item icons, regardless of whether or not they are explicitly used by any item files. If you find any I have missed, please bring it to my attention. It is also likely a few BAMs which are not item icons have slipped through my filtering into this list. Included are a list of warnings given by PS BAM for each item icon, along with a separate estimation of the primary palette index used for the shadow (which is assumed to exist) on the large item icon. Here is the comparison. Exactly how a BAM is rendered depends on the game engine and engine version, game configuration settings, context of usage within the game, computer hardware, and also sometimes graphics settings at the OS level. After more than a decade of studying BAMs and how they are rendered, the following are some general rules to follow to ensure the optimal display of a BAM under all possible scenarios. The transparent color should be pure green RGBA(0,255,0,0) at palette index 0. No other palette entry should be this color; therefore, no pixel that should not be transparent should use this color. The shadow color should be pure black RGBA(0,0,0,0) at palette index 1. This color at this palette entry is generally rendered as ~50% transparent. No other palette entry should be this color; therefore, no pixel that should not be rendered as a semi-transparent shadow should be this color. Outside of the IE, an alpha value of 0 in 32-bit images indicates that color is completely transparent and an alpha value of 255 indicates that color is completely opaque. However, for backwards compatibility purposes in a BAM's palette, an alpha value of 0 is treated as completely opaque whereas an alpha value of 1 is almost completely transparent. As a result, any program intending to render a BAM must scan the alpha values in the palette. If any alpha value is non-zero, the BAM is rendered as 32-bit (and any alpha values of 0 are made 255). However, if all alpha values in the BAM's palette are 0, then it can be directly rendered as a 24-bit image. The takeaway is that there is no functional difference between a BAM palette using alpha values of 0 and 255, but using 0 can result in more efficient rendering at no cost and with no functionality sacrificed. This is relevant only for EE games. Additionally, the following best practices specifically apply to item icon BAMs. For reference, traditionally an item icon consists of two frames. Sequence 0 contains the large item icon (with a shadow) that is displayed when the item is picked up in the inventory. Sequence 1 contains the small item icon (without a shadow) that is displayed when the item is placed in an inventory (including backpack) slot. The large item icon (Sequence 0) must be no larger than 64x64 px. The X and Y offsets of this frame are calculated according to the following rules: CenterX=Width//2 CenterY=Height//2 In the classic engines, the small item icon (Sequence 1) must be no larger than 32x32 px. The X and Y offsets of this frame are calculated according to the following rules: CenterX=(Width-32)//2 CenterY=(Height-32)//2 In the EEs, the "small" item icon (Frame 1 in Sequence 0) must be no larger than 64x64 px. I suspect (can't verify as offsets are ignored) the X and Y offsets of this frame should be calculated according to the following rules: CenterX=(Width-64)//2 CenterY=(Height-64)//2 In the above, // is a floor divide (drop the remainder) The EEs do not use the small item icon and BG2EE has, in general, dropped this frame from the BAMs entirely. Instead, the EEs use the large item icon (with the shadow) for both when the item is picked up and when it is placed in an inventory slot. However, the classic item icon behavior can be restored by adding the small item icon as a second frame to Sequence 0. Doing so is backwards compatible with the classic engines. In oBG1 and oBG2, the small icons filled the inventory slot and would become bigger than the slot when picked up. In the Enhanced Editions, the inventory slots are larger (doubled in size). As a result, the smaller frame from the original icons is too small, even when used. The EEs use the larger frame in order to fill the larger slots, which are now sized to fit an image up to 64x64 px (used to be 32x32 px). Issues to consider At the engine level: IIRC, the EEs used to (pre v2?) calculate the inventory icon offsets as follows. If the X and Y offsets were 0, then the frame would be centered automatically based on the width and height of the frames. If the X and Y offsets were non-zero, those values would be respected and used to center the frame. See above for details on how they should be calculated. The current EE behavior (from v2 onwards?) does not seem to behave this way. Instead, any frame offsets are completely ignored, and are instead centered based solely on the frame width and height. The EEs (particularly SoD) seem to have made an effort to center the large item icon based on the primary image (excluding the shadow). This places the shadow down and/or to the right of the center of the inventory slot. For obvious reasons, this can't be done when the large frame is approaching or at the maximum dimensions (64x64 px). If the frame dimensions were respected by the engine, this modified centering could be done simply by adjusting the frame X and Y offsets by the number of columns and rows of pixels made up exclusively of shadow. With a well-formatted shadow, this would be easy to do programmatically. Since the frame offsets are not currently respected, however, this modified centering has been performed by adding rows and columns of transparent colored pixels to the frame to artificially adjust the width and height (which are then used to center the frame). Many of the item icon BAMs (both original and new) have been done this way in SoD. To me, this seems like a major regression of engine behavior. It has no conceivable benefit (other than masking the laziness of having not made appropriately sized "small" item icon frames), and comes at the cost of requiring extravagant and byte-consuming manipulations of the frame images themselves in order to reproduce the old behavior. At the BAM level: (in no particular order) At some point, a few of the item icon frames used in the EEs got hosed compared to the originals. Examples include imisc1j and IMISC5N in SoD and BG2EE, IMISC61 and IMISC61 in SoD, ISW2H22 in BG2EE, etc. No shadow at all on the large icon. A few examples include IBOLTS01, IMISC13 in SoD, and IMISC17, IMISC18, and IMISC19 in BG2EE, and IAX1H44, IMISC72 and IMISC73 in all games. Clearly bad shadow color (noticeably not black). See IBRAC26, IGLBGRE1, IMISC40, IMISC43, etc. Beamdog has generally inserted a mid-level grey color, RGBA(128,128,128,255), into the palette entry 1 (the shadow color) of item icons. Not only is this (IMHO) a poor choice of shadow color, but this palette entry is rarely (if ever) even used for the actual shadow in the frame. Shadows using pure black, RGBA(0,0,0,0), but not located at palette entry 1. Shadows using an off-black color (e.g. RGBA(1,1,1,255) in imisc3n), sometimes located at palette entry 1 but more often not. Use of an alpha value of 255 in an otherwise non-semi-transparent BAM. While not strictly wrong, I feel it is sub-optimal for reasons explained above. This is trivial to correct with PS BAM. Noticeable differences in icon sizes between items of the same type. See IRING01 vs IRING02. While you wouldn't want to upscale ALL icons to the max 64x64 px (i.e. a sling bullet shouldn't be the same size as a two-handed sword), there is some room for improvement. See also https://forums.beamdog.com/discussion/81852/bg-ee-sod-bgii-ee-inconsistent-icon-size/p1 Transparent color that is not pure green (usually BAMWorkshop's colors). See ISW1H58 etc. This is trivial to correct with PS BAM. Inconsistencies between games for the same item icon. See IXBOW06 and ICHAN01. Personally, I generally prefer the oBG1 style over the oBG2 style where applicable. Where BD has done the best job of updating/improving the icons (IMO) are the scrolls and spell icons. See SPPR417A as an example. They have also improved the shadows of some item icons. See ICHAN01. Inconsistency in the function of scrolls between SoD and BG2EE, and within the same game. Specifically, whether the scroll gets rolled up when picked up. See SPWI101A vs SPPR732A etc. Inconsistency in shadow offset direction (sometimes down, sometimes right, sometimes both) and offset amount (see IBLUN06 vs IBLUN07). Inconsistency in magnitude of shadow offset. See IBZPLO01. Inconsistency in shadow size (a handful of shadows are considerably smaller than the original item). For example, see IBLUN09. Some of Beamdog's new item icons are larger than 64x64 px. Depending on game configuration settings (like Scale User Interface) and possibly OS level display settings (like DPI settings), these icons can overflow their bounding box in the user interface (inventory screen, store screen, etc.). They should be trimmed, and if still too large, scaled down. Anything else I haven't thought of or noticed? The way I see it, the most thorough (and effort intensive) method of resolving these issues would be this: For each item icon, pick the best one available between all games, preferably one with a "small" item icon (with no shadow). Correct the transparent color if needed. Set all alpha values in the palette from 255 to 0. Remove any existing shadow from the large frame Resize frames up or down as necessary, leaving enough space (within the 64x64 px limit) to re-add the shadow back later. Replace any remaining pure black pixels with a slightly off-black color. Trim all frames. Create the small item icon if necessary Create a pure black shadow at consistent offsets on the large icon, and save this as a third frame. Optional alternative: Either recreate or upscale the original small item icon to be twice the original size. This will become the "large" item icon with no shadow. Rebuild the item icon BAM with the proper transparent and shadow colors at the proper palette entries, and with 3 frames. Sequence 0 Frame 0 is the large item icon frame with the shadow Sequence 0 Frame 1 is the large item icon frame without the shadow Sequence 1 Frame 0 is the small item icon Calculate the proper frame offsets as described above. Optionally, adjust the offsets to account for the rows/columns taken up by only the shadow. Compress the BAM. Use this new BAM in all the EEs, and backport them to the classic games via a mod, to be installed very early in the install order. Modify the Enhanced Edition game engines to respect the item icon frame offsets if they are non-zero, but calculate them automatically if they are 0. Between PS BAM and Imagemagick, I think I can mostly automate 2, 3, part of 4, part of 5, 6, 7, 8, 9 with some guidance, possibly some of 10 with some guidance, 11, 12, 13, and the mod part of 14. What I'd need significant help on would be 1, 4 simply for the amount of time and effort involved, 5 if we want to scale any of them to be a consistent size within family, deciding the offset of the shadow for 9 (doesn't necessarily have to be the same amount for all item types), probably some instances of 10 since I'm no artist, the native EE usage of 14, and of course 15 is out of my hands. Number 4 is significantly more complicated than you might expect, and I know of no straightforward way to do 5 that gives universally optimal results, so some trial and error is in order. Considering the scale of what I'm proposing, this quickly becomes a significant time sink. Does this all seem like a reasonable assessment of the current situation? Worth the effort, or should the scope be scaled back to only those item icons that are obviously and visibly broken in-game? I fully recognize that not everything in this list constitutes a "bug" in the context of EEFP, but a good number of them may. I'm looking for feedback on what, if anything, we may want to address here. For example, some shadows are clearly the wrong color while others are a bit off but hard to distinguish in-game. Where to draw the line?

The large and medium wyvern animations do not have shadows, while the small and tiny wyvern animations do, which seems like an oversight. I have attempted to generate some. While they're not perfect, I'm of the opinion they are significantly better than none at all. Two variants each are attached for the large and medium wyvern. Take your pick of which you prefer. If any true artist wants to tweak then, I can provide the component parts or help facilitate converting images into BAMs. MWYV_Shadow_Sizes.zip Edit: However, due to this engine quirk, the large wyvern animation will not display a shadow in game even when one is added. I have yet to test if adding "extend_direction_test=8" to the INI file is enough, or whether an engine edit is necessary. Edit2: It appears an engine edit is needed. Vampire animations in the Baldur's Gate games have shadows. While the developers clearly made them this way, it isn't D&D cannon. I have made versions of the male vampire, female vampire, and Bodhi animations without shadows, cleaning up many bad shadow pixels in the process. This may be more of a tweak than a fix, but here they are: VampireNoShadow.rar

[Bug] Multi-part area BAM animations show visible lines between the sections What is currently happening Multi-part area animations show visible lines between the sections What should be happening Multi-part area animations should not show visible lines between the sections Steps to reproduce the bug Start a new IWDEE game with default characters Using the console, move to area AR1105 Click through the dialogue until the cutscene plays and the portal animation is activated Notice the visible lines between the sections of the portal animation, particularly the left and right portions of the top half. If available, a fix Place the attached BAMs in the override folder, as appropriate for each game See that the visible lines are gone Notes Because the EEs allow BAM frame dimensions larger than 255x255 px, this issue can be fixed by recombining the split animations into the top left section's BAM and blanking the BAM frames for the other sections. Fixing the issue in that way does not require an engine fix or modifying the area files. This should cover all of BGEE, SoD, BG2EE, and PSTEE except for AM3017[A-D] and AM6200[A-D]. Those are the Lum the Mad (which I don't think should be combined) and Melissan replenish (I don't understand the mechanisms of how/when these are played). Note that these have received minimal testing. Let me know if I've missed anything. SplitAnimationsCombined_20210501.zip

[Bug] Multi-part creature animations show visible lines between the sections What is currently happening Multi-part creature animations show visible lines between the sections What should be happening Multi-part creature animations should not show visible lines between the sections Steps to reproduce the bug Start a new BGEE game with a default character CLUA in a large wyvern: C:CreateCreature("wyvern") Zoom in Notice the visible lines between the sections of the creature animation If available, a fix Place the attached BAMs in the override folder See that the visible lines are gone Notes Because the EEs allow BAM frame dimensions larger than 255x255 px, this issue can be fixed by recombining the split animations into the top left section's BAM and blanking the BAM frames for the other sections. Fixing the issue in that way does not require an engine fix or modifying the animations' INI files. This also fixed bad frame offsets on 5 frames of the large wyvern animation. Before: After: This should cover BGEE, SoD, and BG2EE. If I've missed anything (PSTEE?), please let me know. I'm also happy to convert mod-added animations if they are brought to my attention. Archive too big to attach here: http://classicadventuresmod.com/temp/MultiPartCreatureAnimationsRework_20220402.rar

[Bug] The EEs do not support a compressed color index (offset 0xb) separate from the transparent color index in BAM files, as the classic engines did. What is currently happening The EE engine treats the compressed color index AS the transparent color and therefore does not support a compressed color index (offset 0xb) separate from the transparent color index. What should be happening The EE engine should support a compressed color index (offset 0xb) separate from the transparent color index. Steps to reproduce the bug Save the attached BAM file to the override folder of a BGEE/SoD/BG2EE game. Start a new game with a default character. If the character does not start off with a quarterstaff, CLUA one in (STAF01). Observe the rendering of the staff's new bam (what should be a rectangular scroll). Compare how this BAM is rendered to how it is rendered in oBG2, which properly supports a compressed color index (offset 0xb) separate from the transparent color index. This is a regression compared to the original engine behavior*, which is described in the IESDP. If available, a fix This must be fixed at the engine level. Notes While the effect in-game is minimal, a handful of BAMs in the BGEE, SoD, BG2EE, and possibly PSTEE do use a compressed color index that differs from the transparent index. This may also affect mod added item icons. For example, in BGEE, there is: EXPLODE.BAM = 127 (This one does happen to correspond to the transparent color index, but only in oBG1) FIRE.BAM = 128 (This one does happen to correspond to the transparent color index, but only in oBG1) MOVES.BAM = 224 OPTIONS.BAM = 222 PORTBTTS.BAM = 195 PORTBUTT.BAM = 195 NearInfinity and BAMWorkshop II render the attached BAM correctly, but BAMWorkshop does not. * When I originally submitted this bug on the old Beamdog Redmine, I provided a very similar BAM. At the time, I tested in oBG2 and it rendered correctly, but did not in the EEs. When I remade the BAM for this post and tested again, it did not render correctly in oBG2 either. It appears this may be one of the odd cases where hardware/graphics card settings/game settings affect how the BAM is rendered. Unfortunately, the original Redmine report (and thus the original BAM) is no longer available. istaf01.bam

I once briefly looked into whether it was possible to have the engine give my PC both the good and bad Bhaal powers. Upon realizing how much of the mechanics were hardcoded, I quickly determined adding the spells myself with NI would be quicker and easier. I'd still be interested in such a mod.

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

All of these look really great. A few minor observations for consideration:

Maybe I'm missing something, but to me it seems to be an issue with ambiguous terminology. "Negate" can mean: nullify; make ineffective; cancel out to make negative. e.g. an integer (in this case, negating a [negative] penalty produces a bonus) To me, the intent is clearly meaning 1, whereas a select few may interpret as 2.

Why? ... Didn't you agree about petrification? Moreover, I'd say that any "magic" in the engine that awards experience for making a CRE "dead" (STATE_FROZEN_DEATH, STATE_STONE_DEATH, STATE_EXPLODING_DEATH, STATE_FLAME_DEATH, STATE_ACID_DEATH, STATE_DEAD, STATE_REALLY_DEAD), plus imprisonment (seems like there should have been a state for that?), should count as... dead. Vis-à-vis: death magic.

If a particular change either: Makes modding a particular facet of the the game substantially easier or more straightforward (eyeing low to mid skill modders) without a) applying further restrictions to what can be done and b) requiring mods that want to do this check if EEFP is installed and if not do the same thing EEFP would have done (making EEFP's code superfluous). Significantly reduces the opportunity for bugs to arise in mods installed downstream, with no drawbacks Then IMO it is worth considering.

With basically no BAM frame size limit in the EEs, you could just scale the existing animations larger for the biggest creatures, if you wanted to go that route.

Need any help with that?

Personally, I would find it helpful to have a list of somewhat distinct categories into which justifiably true bugs might fall. Is there such a list based on previous community fixpacks, and/or are there suggestions for what these categories might be? E.g. Structural bugs (this file is corrupt) vs. content bugs (typos, this graphic/animation doesn't look like it should) vs. implementation bugs (this spell/item doesn't do what it says it does, this cutscene doesn't operate/flow as intended)? Tho hopefully more extensive and elaborate.

The EEs turn a whole bunch of generic quest items into unique ones.

@Bubb It appears that there are some engine shenanigans going on with the large wyvern animation that prevents a shadow from being rendered, even if the BAMs are modified to add one. Can you confirm/locate what might be causing this? Tested on BGEE, BG2EE, and IWDEE. You may have been asked this question before, but I'm interested in the answer.

I have a vague tickle in the back of my mind that says for some animation types (perhaps only on some engines), the walking speed is primarily determined by the number of frames in the walking sequences. Thus e.g. IWD style animations may move at a different speed than BG style animations within the same engine, simply because by default they have a different number of frames in the sequence. Does this ring a bell with anyone?

Try jumping to the "master/parent" area (e.g. AR3900) first, and then to the "interior/child" area (e.g. AR3901). A beer says the camera will work as expected.

I feel this is likely a common theme dating back to the dawn of BG modding. I certainly feel this way. A while back, @CamDawg posted a link to an interview with one of the early-er (1st or 2nd generation?) modders (or hexers IIRC?), but a 30 second search didn't turn it up. I found it entertaining and insightful. Maybe he can link to it here.

Foot circle size, no. Personal space, yes (depending on the flags set in the projectile). But small glitches have been known to happen in conjunction with search paths, personal space, and bumping people out of the way.

Shameless pitch, but PS BAM can do all this, and much more.

Look up the associated StrRef listed in the LUA file for each quest? And when the title StrRef changes for the same quest ID, you know you have a morphing name.

You can check in e.g. BGEE.LUA for the buildQuestsTable() function and the "quests_old" section, and you could also search all DLG files for "AddJournalEntry" and "SetQuestDone", but all of this will only give you the "official" quests, not the "hidden" ones (those that do not come with a journal entry).

Searching through every CRE to find which ones use the gnoll animation and listing what weapon they have equipped is fairly straightforward. Searching through every area and area script do determine how many gnolls are spawned based on difficulty slider position, party level, etc. is considerably less straightforward. Edit: See Creature Lister

A significant time sink is actually posting all the "Copying and patching 1 file ..." (and similar lines that don't actually tell you anything) to the console (in my experience on Windows at any rate). Using SILENT can speed things up considerably under some/many circumstances.