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.

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?

In one of the early threads, CamDawg said this: "One thing we can put on the podium alongside death and taxes, though: bugs in Jaheira's romance." I'll add shapeshifting bugs to that. 2.6 fixed many things, particularly crash bugs. It also left many other problems alone and even added new ones. I put a component for this in my tweak mod, so I'll post what I found here. Voluntary shapeshifting only, at least in this post. Also, I only have BGEE and BG2EE; I can't speak to other games. - (Not a bug, just annoying) BGEE and BG2EE use different architecture; BGEE attaches the polymorph effect to the transformation spell/ability, while BG2EE attaches it to the creature weapon. As such, any fixes will need different code for each game. The BGEE versions are technically temporary at 500 days, probably because a true permanent duration wouldn't revert after death and resurrection. - In BG2EE, the creature weapons have the "Forbid off-hand" flag set. In BGEE, they don't. They really should have it in all games; without, you can dual-wield with a manufactured weapon without penalty. - (BGEE and BG2EE) Druid wolf shapeshift doesn't match description. Description says 15 strength/18 dexterity (PLYWOLF.CRE), actual effect is 18 strength/17 dexterity (WOLFCHAR). The mage wolf polymorph is PLYWOLF with a +1 damage bonus, so that's what I went with in my version. - (BGEE and BG2EE) Many shapeshifts get +N damage bonuses, which aren't reflected in the spell/ability descriptions. Mage wolf forms (+1), mage and druid bear forms (+1), avenger wyvern form (+2), avenger fire salamander form (+3), shapeshifter werewolf form (+2), mage ogre form (+1), mage spider form (+1) - (BGEE) Shapeshifter greater werewolf form lacks the regeneration effect added in BG2EE 2.6. Not relevant in the standard rules, but the item and ability support is there. - (BG2EE) Druid "Shapeshift: Black Bear" turns you into a brown bear. "Shapeshift: Brown Bear" turns you into a black bear. This one's new in 2.6. - (BG2EE) Mage "Shapeshift: Black Bear" and Shapeshift: Brown Bear" both turn you into a black bear. - (BG2EE) Mage ogre form's weapon isn't flagged as magical (as it is in BGEE). - (BG2EE) "Shapeshift: Greater Werewolf" now grants regeneration as of 2.6 (1 per 2 seconds or 3 per round), but the description doesn't mention it. - (BG2EE) Druid high-level shapeshifts list their duration as "1 hour". They're actually permanent until dismissed, like the other druid shapeshifts. - (BG2EE) Shapechange forms that grant higher levels of weapon immunity don't include the lower immunity levels and scripting states standard on weapon immunity effects. For example, the elemental forms have weapon immunity with maximum level 2. IMMUNE3 also has weapon immunity with maximum level 1, weapon immunity to non-magical, scripting state 25, and one star in proficiency 128. Anything that keys off those effects (such as, for example, the SCS Insect Plague tweak looking for normal weapon immunity) won't react to these forms properly. - (BG2EE) Iron Golem form lacks most of the immunities its description says it has. The description says "backstab, weapons of +2 immunity or less, sleep, fear, hold, charm, paralysis, poison". Of that list, you only get backstab immunity. Some shapeshift abilities mention what their weapon hits as, some doesn't. In the component I wrote, I edited the descriptions so that all of them did. For the sheer WTF factor, it's hard to top the bear swap. Just ... how did that sneak in?

Apparently it seems if you wield a weapon in the off hand, the game will interpret it as it didn't exist as far as weapon styles go. I noticed this because the critical hit bonus from one handed style still applies even if wielding a weapon in the off hand. Not sure how that would interact with other mods that change styles such as Scales of Balance (or was it Might and Guile?). Is it fixable?

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

What's happening Start a new HoW game in IWDEE. Delete one of the existing pregen party members. In the open slot, make a trueclass cleric of evil alignment. After selecting your weapon pips, you're presented with this screen: Clicking 'cancel' crashes the game. Clicking 'level up' takes you to the appearance part of chargen, bypassing spell selection. What should be happening When you select your weapon pips, this popup should not happen and you proceed to spell selection Notes HoW uses 25stweap.2da to give default equipment to new NPCs. The default helmet for clerics is the Blessed Helm of Lathander, an item disallowed for evil clerics. This prompts the popup from (what appears to be) the dual-classing menu. Swapping in a different helmet is easy, however, all items in the table require review to avoid incidents with other kit/class/race combos.

Opcode 39 is seriously overloaded. It gets used for lots of conceptually different purposes: sleep, unconsciousness, being knocked down, and more. This means that flat immunity to opcode 39 is often overkill. This is an attempt to disentangle things (so far, only for BG2EE). (Wall of text warning!) Spells/Items that apply 39 Here's a breakdown, based on research in BG2EE: 1) Effects that are clearly labelled as 'sleep'. Examples: the Sleep spell, the (Greater) Command spell, the Wand of Sleep, the Sleep cloud created by the Wand of Air. 2) Effects that are clearly labeled as causing unconsciousness. Examples: pseudodragon claw attacks, Color Spray, Sphere of Chaos. 3) Effects that inflict a short (sub-1-round) 39 to simulate being knocked down or knocked back (actually the most common use of 39). Examples: Wing Buffet, the Staff of the Ram, the Dragon Breath spell. 4) Effects that are used in scripts (cutscenes or other) to disable the party or creatures. Examples: SURE_SLEEP, the effects that knock out trolls. 5) Miscellaneous effects that render the target unable to act. The main ones: - Stinking Cloud effects (victims are 'sent reeling and fall down') - Emotion: Hopelessness (victims 'lie down where they stand') 6) Miscellaneous effects that stop the target from moving. The main ones: - Ixil's Spike (target is 'pinned to the ground') - Earthquake (targets 'fall to the ground') 7) Effects that I think shouldn't be using 39 at all, specifically: - SPIN775 (the version of Psionic Blast used by Gith), which I think has no good reason not to use the Stun opcode like other Psionic Blasts - Bigby spells, which (as I discussed elsewhere) I think ought to be using 186. Creatures that get immunity to 39 This is pretty widespread. We can break it into three categories: 1) Creatures that are also immune to 235 (wing buffet). 2) Creatures affected by Wing Buffet, but otherwise with widespread immunities and minimum hp. (The point here is that normally these creatures are protected because they have scripted actions to perform when below a certain hit point level, so they need never to have their scripts disabled. A few seconds is tolerable, but not multiple rounds). 3) Other creatures (e.g., undead, slimes, constructs). Spells or player-usable items that grant immunity to 39 There are surprisingly few of these. Here's a breakdown: 1) Rage powers. These are described in in-game text as making the user 'immune to charm, confusion, fear, feeblemind, hold, imprisonment, level drain, maze, stun, and sleep' (or permutations thereof). 2) The Chaotic Commands spell. In-game text describes this spell as making recipients 'immune to magical commands. Suggestion, Charm, Domination, Command, Sleep, Maze, and Confusion are all spells that fit into this category.' 3) The Greenstone Amulet. In-game text says that the amulet, when activated, 'protects the wearer from all forms of mind attacks'. 4) Exaltation (the Tyr kit special power; also an IWD spell), which 'removes the effects of fear, sleep, feeblemind, unconsciousness, and intoxication, as well as berserk and confused states of mind. In addition, the recipient is protected against spells and other attacks that cause these effects for 1 turn.' In IWD there is also Impervious Sanctity of Mind, which 'steels the caster's mind against any outside influence. Charm, confusion, fear, feeblemindedness, hold, sleep, maze, berserk, and intoxication will not affect the caster as long as this spell is in effect.' Main proposal My suggestions: 1) Basically nothing should be immune to short-duration knockdown unless specifically immunized against it, i.e. 39 immunity shouldn't in any way imply knockdown immunity. That's partly on conceptual grounds (few if any of the reasons for immunity to sleep, e.g. being undead or affected by Chaotic Commands, apply to knockdown), partly on technical grounds (the knockdown sleep is often to disable a creature during wing buffet, and creatures look silly flying backwards while casting or otherwise acting). Boss creatures can cope with a couple of seconds' delay in their script firing if they happen to be knocked back at the point at which they get reduced to 0 hp. 2) Boss creatures should otherwise be immune to all 39 effects, for the usual reasons. 3) Other creatures with 39 immunity should not be immune to immobilizing effects like Earthquake and Ixil's Spike, but should be immune to both unconsciousness and sleep effects. (There is very little avaiable in-game evidence to separate these for creature immunities and doing so involves a lot more design work than I'm comfortable with in a fixpack.) 4) Player spells and abilities should only protect against 39 effects that are actually called out. So Chaotic commands and rage should protect against sleep, but not other types of unconsciousness; exaltation should protect against unconsciousness, but not against being knocked down by Earthquake. 5) The immobilizing effects of Earthquake and Ixil's spike should be blocked by Free Action, since the Free Action description pretty clearly seems to apply to them. Implementing this would require 3 spellstates: SLEEP_IMMUNITY, UNCONSCIOUS_IMMUNITY, IMMOBILIZE_IMMUNITY. Special cases I think we should treat Hopelessness as a Sleep effect. That's basically pragmatic: if you look at the effects that protect against sleep, they fairly clearly should protect against Hopelessness (it's in the general category of things that Rage ought to protect against; it's a magical command). Similarly, I think Stinking Cloud should be an unconsciousness effect. It's not a mind-affecting result, so it shouldn't be blocked by Chaotic Commands; it's not sleep, so it isn't covered by the in-game description for Rage. (There is a case for putting it in its own category - the spell description doesn't mention unconsciousness - but that gets profligate with spellstates.) Effects for mods - mod-added items/spells that give sleep immunity will grant it too broadly - but then, that's true already - mod-added items/spells that cause sleep will affect some creatures that shouldn't be affected. That's not ideal but I think is a price worth paying for fixing a lot of bugs. I have partially-coded proof-of-concept versions of this which I'll upload in due course (without prejudice as to whether we go this way or another).

I'll create a thread here for things I've seen that seem too small to deserve their own thread.

Causes an infinite loop. Apparently the originals did not, it is purportedly an EE-introduced bug.

I noticed this in my session just yesterday. BG2EE, obviously. First, Foebane +5. It directly casts SPIN104A (the payload of innate LMD SPIN104) on the target it hits, with no filter whatsoever. That's four points of magic damage, draining to the wielder's maximum health. Subject to magic resistance. The problem is that the "doesn't work on constructs and undead" 324 filter is in SPIN104. That's an important part of the spell, and really should be there in this on-hit version. The sword should either cast SPIN104, or have that 324 filter. Since the LMD effect is the last one, it's already in the right order to just slip that filter in before it. Second, Staff of the Ram +6. The description (in English) states "large creatures such as a dragons or giants will not be knocked back or stunned". The way this actually works is that when the chance procs, the staff applies a Wing Buffet (235) effect and an unconsciousness (39) effect along with an appropriate portrait icon. Wing Buffet is blocked for sufficiently large creatures, but sleep/unconsciousness isn't. You can knock out giants just fine; they merely won't be sent skidding across the room. In this case, the description (#66367) certainly needs an edit, at least in English. If nothing else, the grammatical number mismatch "a dragons or giants" should be fixed by deleting that "a". As for the unconsciousness effect, that's trickier. The animation-based large creature buffet immunity isn't any sort of stat that can easily be targeted, and race-based protection could do weird things (Yaga-Shura is a dwarf!). It might be that the best option is to simply edit the description to match the actual effect.

If you teleport from Lazarus store to Pocket Plane the "siege" will continue while you are in the pocket plane. It's pretty funny. https://www.dropbox.com/s/re8omkr054xs2vb/000000004-Quick-Save-4-TOB.zip?dl=0

jmerry's Tweak Collection has a component with the following explanation: The issue on the engine is mentioned on another thread, and is scheduled to be fixed in 2.7 once released (if ever), so I think it's worth it to have this simple fix applied to joinable NPCs.

Now that the engine can properly support them, add the remaining oIWD soundset entries (secondary sounds for leader, tired, &c.) to IWDEE.

[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

It would be good to know how severe the demands on spellstates actually are. There are 256 slots available, of which the vanilla game uses 133, leaving 123 free. My mods (mostly SCS, but also some upcoming projects) use maybe 30-40 of those. Does anyone have an impression of what other mods do? If actually the extant mods only use 50-60 in total, we could borrow a bunch for FP with impunity (which would simplify immunities); if there's real pressure on splstate.2da, of course we shouldn't. (It would be *really* nice if BD were willing to extend splstate to 2 bits in 2.7)

While working on a recent mod attempt I’ve come to some impasses due to my rather poor skills at using weidu; in fact, that would be a rather kind appraisal, as I find myself near illiterate when it comes to weidu, doing most of my work by repurposing others’ code for what I need to accomplish, otherwise the actual coding process is rather opaque to me. Let me get to what I’m stuck upon: firstly, I’m trying to create a code that will patch all quarterstaves to remove the backstab feature by toggling the “EE/Ex: Toggle critical hits (25)” feature in the itm files. So far based on previous reference, I’ve managed to bang out this code: COPY_EXISTING_REGEXP "^.+\.itm" override PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN READ_SHORT 0x31 weaprof PATCH_IF (weaprof = 102) BEGIN WRITE_[bor or Byte?] 0x1b (THIS [bor or Byte?] 0b[?]) END END BUT_ONLY_IF_IT_CHANGES But in reading the Bor/Byte tutorial I’ve found myself over my head. I can’t seem to figure out whether the [bracketed] parts should be a Bor or Byte (I think it’s Bor), and I know I need a binary to accomplish the task, but I can’t seem to grasp how I translate what I want into the proper 1s and 0s. Could anyone help me with the missing pieces? The second problem is a bit more vague. What I need to accomplish is to create a weidu code that patches the WEAPPROF file so that all 3’s within the “2Weapon” row are turned into 2’s. This is what, with some help, I’ve put together: COPY_EXISTING ~WEAPPROF.2DA~ override COUNT_2DA_COLS cols FOR (col = 3; col < cols; ++col) BEGIN READ_2DA_ENTRY 34 cols col val PATCH_IF %val% = 3 BEGIN SET_2DA_ENTRY 34 cols col 2 END END For obvious reasons (though not to me) this code does not work, and, being a poor hand at weidu, I imagine I’ve made a bunch of syntactical errors in this code that prevent it from working. Could correct the code or tell me what I did wrong? I’m immensely thankful for any help I can receive, in advance, and I hope you can be patience with me, given I lack a great deal of the Programmer’s savvy.