Sam.

I'm uncertain in what context you mean this, but at face value I find it to be troubling. There are items and spells in the game that specifically state that they protect from psionic attacks, the gaze of umber hulks, the gaze of basilisks, etc. Just because an effect comes from a creature itself and not a cast spell or divine prayer doesn't necessarily mean it should pierce through all magical protections. Having protection from level drain (whether from an item, spell, innate ability, etc.) should protect you from having your levels drained, regardless of whether the attack came in the form of a creature's bite, an enemy spell, or an enchanted mechanism like a trap or the Machine of Lum the Mad. If you have magical immunity to hold and paralysis, you shouldn't be affected by that ability of carrion crawlers just because the effect came from a creature and not a spell. Further, at a minimum I would argue that creatures with innate magic resistance (think Viconia for being Drow) should have an innate resistance to magical effects, not just magical spells. I can see where people may argue magic resistance artificially boosted by an arcane spell would be more suited to resisting arcane magic, but I don't necessarily agree and I don't think that would be reasonably possible in the engine anyway.

If you wanted to take a crack at the classic chapter and dream screens or the classic movies (I could export the frames for you), I'd be very interested in the results.

With the TIS V1 format, you'd only be keeping about 1 of of every 16 colors, unless the engine can actually use tiles less than 64x64 px (which the file format does support). If it can't, the results wouldn't be this good.

I'm aware of this, but for most item types, people expect to only see the large icon because the slots themselves have been made larger in the EEs, and the small icons took distinctively tiny by comparison. The current state of item icons is wildly inconsistent. Apart from spell scrolls and generic scrolls, I count only about 42 item icons (used or unused) in BG2EE which actually make use of a small icon in Sequence_0000_Frame_0001. If you exclude the amulets which are pretty much the same size in the large and small icons, you're left with only 11. These plus the large icons the engine shrinks to make smaller because they're padded in transparent pixels tend to stand out.

Here's another one: ISHLD17. The icon is corrupt in the classic games (large icon only has right half, small icon only has bottom left quarter), but in the EEs it suffers from significant posterization. Anyone care to clean it up?

But that is the "large icon" - it has 31x29 px and I didn't see any greater version of that icon. Not in EE, at least, and I don't have the old TotSC anymore. You must have a different version of the game than I analyzed. For future reference, you can just snatch them from here instead of extracting them yourself if that's easier.

Thanks, but that looks like the small icon, which supposedly didn't have a shadow to begin with. What I was trying to ask for was the shadow removed from the large icon so that it matches (comparatively speaking) the small icon. I played around with it myself again today until I had something I'm happy with. I'll keep plodding along, but I'm sure there will be more that give me trouble. IMISC70 is an interesting case. It's the only item icon I've processed so far where the small icon distinctively and undeniably has a shadow. Keep it or remove it? I'm inclined to call it an oversight and remove it, but decided to poll the audience.

That isn't necessarily the plan for EEFP, but it'll probably be an option in a mod. After some internal debate, I figured to hell with trying to draw fuzzy lines between what did and didn't count as an issue and just do them all, going in chronological order with the game's releases as later games often included large portions of the item icon BAMs from the previous games verbatim. I guarantee no timeline on completion. I've been slowed down by a particularly couple of weeks IRL. I'm keeping this in mind, but haven't gotten that far yet. Do you have an exhaustive list? These are fantastic and exactly what I was hoping for, thank you! I'm also struggling with removing the shadow form IMISC59 (TotSC) if you're willing to continue helping?

Polymorph Other and the squirrel paw moves the weapon out from the equipped weapon slot, so this one can be circumvented. See also SLTSTEAL.2DA and mods like Epic Thieving. Not that I'm suggesting any of this equipment be made undroppable or removed. It's a cool feature not a flaw that there are ways to tease out powerful items or XP from unexpected sources for the non-roleplaying power users. I enjoy getting the Helm of Opposite Alignment from the demonknight (before BD ducked that up) and the third ring of wizardry from Winski Perorate every playthrough, to name a couple.

+1

Sam's point that the copy in Candlekeep might have been added in error is convincing, so I would think it wins out if the imagined intent of the game designer is of paramount importance. That said, I found the comment that replacing Batalista's Passport with a Ring of Fire Resistance in the Gibberling Mountains "would significantly impact the early game" to be incredibly surprising - so much so that I wonder if it was made in the belief that there would be no magic ring in AR5500? Something about the original wording of the proposal led me to believe the suggestion was to "remove" the ring from the Gibberling Mountains. The post has since been edited, so I can't be sure if my initial interpretation was warranted or in error. Regardless, I still feel this is the correct place for the canonical item. The description from TotSC is: I would say the description itself indicates that there are multiples of this ring and/or very similar ones (eyeing the original BG2 variant), all having the same origin. I see no reason to swap any of these with a more generic version. Also, I'm against messing with the original game developer's easter eggs.

I've been updating PS BAM, creating scripts, and building toolchains to help automate this as much as possible while still allowing human inspection for quality control. Some BAMs are one and done, while others require pixel by pixel level edits in the vein of 1pp (which have been integrated into the EEs). I'm over 100 item icon BAMs in of oBG1 (TotSC), but the going is slow, as predicted. I'm willing to continue on this trek (which will likely take months), but I could use some help. So far in particular I could use some help removing the shadows from the mage robes. Specifically iclck10, iclck11, iclck12, iclck14, iclck15, and iclck17 (but all of them really). Theo goal is to keep the original graphics as original as possible while resolving the stated inconsistencies/issues. @Lava are you interested?

The PVRz format for area animations and doors has resulted in graphical glitches (usually described as seams or black lines between the tiles). Some have been reported and fixed, but I doubt all of them have. Here is an example of one such report. Is there a list of any such issues that remain in the current builds? I can describe how I have gone about fixing it for mods, but the process is currently a bit tedious. More to the point, is this something EEFP is interested in addressing?

On this one I disagree. It is general opinion (if not fact) that the later chapters of oBG1 were made in a bit of a rush. My belief is that the Ring of Fire Resistance was purposefully and thoughtfully put in that hidden crack (before the container highlighting button was added to the engine) in the Gibberling Mountains first, and was added to the Candlekeep catacombs (perhaps without considering that the item should have been unique) well after the fact. Moreover, that ring is one of the more defining features of that area, and I believe taking it away would significantly impact the early game, IMO in a negative manor. A bit off point, but I have never personally been bothered by finding multiple copies of fairly generic but technically "unique" items in a playthrough. With that being said, I respect that some people feel strongly to the contrary.

I agree, but I could be considered biased based on where I live, so didn't want to weigh in unless someone else brought it up. To me, the originals seemed to strongly favor American spellings.

I can't recall ever seeing this happen. Guess I slaughter everything in sight too quickly for it to matter... After killing every monster, bandit, thug, and animal on the Sword Coast, I began to wonder who the real monster is...

It has been suggested once or twice over the years, and to date I'm not aware of anyone with the skills to make it happen taking it seriously enough to do it. It could have a place in a mod, but I'm not sure it should be in this mod.

I have a multi-lingual oBG2+ToB on DVD that had an install option of like 6 or so languages. Was such a thing ever made for IWD?

Personally, I interpret it as this one.

As promised, here it is. You can select whatever background color you want, and hover the mouse over each image to view it with transparency enabled. The shadows are only made 50% transparent if they are RGBA(0,0,0,0) at palette entry 1. If there is a real desire to also do this for RGBA(0,0,0,255) at palette entry 1, I can accommodate.

Like I said, I'm unfamiliar with the language and didn't spend all that long trying to decipher it. All I can say is that from personal experience, I am not happy with how it handles palettes. You assume you have an existent and appropriate palette to pull from, and that all frames use the same palette. Unless you have taken extreme and meticulous care to ensure this is the case, it won't be. Could bammer be improved? Absolutely and that would be great. Better tools available to modders and developers is never a bad thing. Will bammer be improved? Maybe... but I won't hold my breathe. If bammer is improved, will it be a magic fix for all the issues there are with item icons? I think not. Regardless of the above, you are of course welcome to take on fixing/improving anything you like in whatever manner you deem best. If the community agrees it's a solid improvement or correctly fixes a genuine bug, it'll end up in a fixpack or tweakpack.

http://iesdp.gibberlings3.net/ and https://iesdp.gibberlings3.net/ no longer redirect to https://gibberlings3.github.io/iesdp/ Can we get that back? My browser history autofill keeps putting the old link at the top of the stack, and without careful scrutiny I tend to click the wrong one.

And so it begins...

This will also fix this bug. Preview:

The images in my table essentially have the alpha channel turned off. Looking through the item icon BAMs from BGEE, SoD, and BG2EE, none of them are BAM V2, and there are only a handful of BAMs that have alpha values in the palette other than 0 or 255 (both values render as completely opaque). They are IAX1H19, IBLUN40, ISTAF25, ISW2H22, OHRICLK3, and SPWI920A all in BG2EE. I'll see about re-exporting them with alpha enabled for comparison. BAM V2 isn't supported in all applications, and I'm unsure if they can be used for item icons. Even if they could, no modding tool I'm aware of can currently perform the bin packing across multiple files, so you'd end up with 1 PVRz page for each BAM, which would be a non-starter. Presumably, they would be storing the offsets in the BAMD file, not in an extra chunk in the PNG itself. However, they don't even seem to be doing that. Instead, they are leaving the offsets in the compiled BAMs at 0 and letting the engine calculate the offsets on-the-fly based solely on the dimensions of the frame. Beyond that, how deep down the rabbit hole do you want to go? I played around with bammer (Beamdog's BAM building tool) a few years back, and while I'm not familiar with the Go programming language, I have poked around the source code just a bit. It appears to reserve pure green in palette index 0 for the transparent color, and then quantize the image down to 255 colors, which of course also includes the green of the background which may or may not get mixed with other colors in the process. Then the original image is mapped back to the combined palette. The result is either a duplicate of the transparent color in the palette, or an off-green palette entry that probably isn't used. Furthermore, bammer often hardcodes a non-shadow color (not pure black) in the shadow index of the palette in addition to two additional hard-coded palette entries. This false shadow color palette index is rarely even used, as the actual shadows in the image don't use this color. This is the source of many of the warnings issued by PS BAM in the comparison table. The end result is that each BAM may use up to 4 fewer colors in the EEs than they did in the classic games. Furthermore, looking at the quantizer, it does not appear that the alpha channel is even being fed into the quantizer to generate the palette. If this is really the case, then trying to map the original RGBA colors to the palette generated is going to result in huge errors if the original image had semi-transparent pixels. I haven't studied the code extensively, but I get the feeling this is a straight median cut quantizer. A modified median cut algorithm would produce much better results, tho with very small images like these, it might not be that noticeable.