jmerry

Also of note - the way dual-classing works in the standard rules, it'll wipe out any XP past your current level so you're best off doing it immediately after leveling up. The requirements for dual-classing are defined in two 2DA tables; ABDCDSRQ defines the stats needed to dual into a class or kit, while ABDCSCRQ defines the stats needed to dual from a class or kit. (And of course, in the standard rules, you're not allowed to dual-class into a kit) So for that ranger/cleric combination, we'd look at the RANGER row in ABDCSCRQ (15 15 0 0 15 0) and the CLERIC row in ABDCDSRQ (0 0 0 0 17 0). Combine those, and the stats needed (in the standard rules) are 15 STR, 15 DEX, and 17 WIS.

After ending the CHAIN, you need a new action. You can't just have a state floating around unconnected; WeiDU doesn't know what dialogue file that's supposed to go into. From context, I think you want to add it to your already created "rqrugos" dialogue file, which would be an APPEND action.

Having looked into the details - definitely a pure SR bug. Also, fixed in the "Revised" fork.

String #7924 is "Enfeebled" in BG2/BG2EE. SR copies its resources; this looks like a failure to update that string when installing onto BGEE.

Huh. So the IESDP does say that 8-character names are treated differently than shorter names in opcode 172. Actually, it says multiple things that appear to contradict each other. Looks like an issue to bring up in that project's subforum.

Shorter resource names are just fine in opcodes that use a resource reference; the remaining bytes of that field are filled out with nulls. SPLs referenced in a kit's CLAB - the GA_ and AP_ entries - can have a resource name of up to eight characters, at least in the EE. The first entry in Wilson the bear's kit CLAB, for example, is AP_OHRBEAR1. And of course, that resource name doesn't have to be of any particular form. Entries in spell.ids encode the filename, and that filename is one of exactly four thousand possibilities (SPPR###, SPWI###, SPIN###, and SPCL###, where ### are digits). That's not just a convention; it's hardcoded in how the file works. Fortunately, you can tell scripts to use spells that don't have spell.ids labels; all of the "use a spell" actions have RES versions that take the resource name as a parameter. For example, here's a block from Aerie's script in BG2EE, to give her the right holy symbol: IF HasItem("CDHLYSYM",Myself) // No such index THEN RESPONSE #100 ApplySpellRES("CDHLYSY2",Myself) ActionOverride(Myself,TransformItem("CDHLYSYM","beltbw")) END

Reflecting between multiple characters with turning effects is dependent on game version, and specifically changed in patch 2.6. As of 2.6, a given spell can only reflect twice; if a (vanilla) elder orb casts Minor Spell Turning and then uses a ray against your character with the Shield of Balduran, that ray will reflect off the shield, reflect off the MST (and probably exhaust it), then return to hit its target despite them having the shield. So, in your example, if playing on (EE) version 2.6, you'd deplete both your and the opponent's Spell Turning effects a bit, and your Chromatic Orb would hit them after the two bounces. Unless they had another defense like a deflection or globe.

Your reasoning is operating on a completely different axis than my thought was. You're looking at how many spell-breakers it takes to bring the defense down, in which case every spell is another layer of protection unless you use something like Spell Thrust or Spellstrike that can take down multiple protections at once. My claim was about how many normal spells it takes to burn through the defenses. Four levels of deflection from Minor Spell Deflection, ten from Spell Deflection - if I toss a Polymorph Other (level 4) at that, the MSD is exhausted and the SD is down to six levels left. As for how turning and deflection effects interact, if both are present ... I'm not actually sure. Haven't tested that. Wait - I can test it right now. Text character 1 casts Minor Spell Turning (up to level 4, 4 total levels of turning) and Spell Deflection (up to level 9, 10 total levels of deflection). Test character 2 casts Spirit Armor at test character 1. Result: test character 2 is now buffed by Spirit Armor, and the graphics and portrait icon for Minor Spell Turning are gone. Follow up with Improved Haste ... Spell Ineffective. And the Spell Deflection graphics are still there. Add another Spirit Armor - ineffective, and that exhausts the Spell Deflection. OK. Spell deflection and spell turning are separate layers, which do effectively add to each other in protecting against normal spells. Also of note is how these interact with a globe of invulnerability; if I load the test character up with a Globe of Invulnerability as well and repeatedly cast Spirit Armor at it, the first one gets reflected onto the caster and exhausts the Minor Spell Turning, the next three exhaust the Spell Deflection, and any after that do nothing because of the globe. Turning applies before deflection, which applies before blanket immunity.

That is not something changed by SCS, in any versions. It's just the way spell protections work. General deflection/turning/trap effects don't block anything with the MAGICATTACK type, which includes all the spell-breakers like Spell Thrust and Secret Word. In vanilla, it also includes Breach - that's what SCS (or, at least, one important component) changes. On top of that, when you do run a normal spell into those protections? It decrements all of them at once. Stacking multiple layers of deflection and turning effects doesn't get you any more protection than the strongest one alone. Now, Spell Shield is special. It's one level of deflection, only against the MAGICATTACK type. And with SCS, also against the new type that Breach gets. So that genuinely does provide an extra layer, eating one spell-breaker. So against an enemy with Spell Shield, you want to throw one cheap spell-breaker at them first. Don't open with that Spellstrike when you see a Spell Shield in the log - use it second instead. Not really. You take down Spell Shield first, then you throw spell-breakers at the problem until there isn't anything left, then you breach. Order really doesn't matter in that intermediate stage; the only case of a protection blocking a spell you might use here is that Globe of Invulnerability (not the Minor version) blocks Spell Thrust. And then you repeat whatever's needed when the enemy mage re-ups some of their protections. That's the standard paradigm with SCS. Variations may apply. If you have a level advantage, you might aim to take down their combat protections with a dispel instead of a Breach - in which case most of the spell protections don't matter, and you can just throw out that Remove Magic first thing unless they're one of the few enemies that use abjuration immunity. Or use Spell Thrust to take down that immunity even if they still have higher-level protections up. If you're planning on killing them with AoE fire spells, all you care about taking down is their fire protection spell, and that's not something they'll ever recast once it's gone. If you're a particularly arcane-heavy party, you might task a mage with casting True Sight to deal with the enemy's invisibility instead of leaving that one to a thief or cleric.

That's very odd, since I looked at the area in NI and compared the order of elements (the stuff with offset entries in the header) to some other areas. No difference. Sure, there's one empty element at offset zero (always potential trouble, there), but that same empty element was at offset zero in every area I checked.

All right, looks like a bug with that component. Diving into the code ... Here's the function call that's supposed to delete the Robe of Vecna from the store, in v35: sto.edit[wmart2][ m.item.delete{s_resref STR_EQ wa2robe} ] New sfo2e stuff. Which I don't really understand. But I can tell that the ones for the Helm of Vhailor and Shield of Balduran are basically the same. And then I looked at another component, removing arrows of dispelling from stores ... and there was a key difference. s_resref was inclosed in %%, WeiDU's way of saying to evaluate the variable. Oh. That explains it. s_resref is an element of the structure describing this "item" element of the store, but only if the variable is actually evaluated. The current code for the items that get removed from Deidre's store apparently tests for which item to delete by comparing a resource reference (i.e wa2robe) with the literal string s_resref. Which always returns false, so nothing changes. Enclosing that s_resref in percentage signs in the m.item.delete lines from item/balduran_shield.tpa, item/vecna.tpa, and item/vhailor_helm.tpa should fix this so the items are properly removed from the stores. In each of item/balduran_shield.tpa, item/vecna.tpa, and item/vhailor_helm.tpa, there is a line including "m.item.delete{s_resref STR_EQ"; if I'm right, each of those should be modified to replace s_resref with %s_resref%.

Honestly, I don't know that much about two-dimensional arrays - I just know the one setup that I used in the snippet from my mod, with the array and two arguments. Copying a row at a time and then pulling elements of that row - not something I'm sure about. And so, I'm not surprised when the version I posted didn't work. Oh, wait. I'm pretty sure that should be PHP_EACH rather than FOR_EACH. It's an array we're working with here, not a simple list... Alternate form, using the exact structure I'm familiar with:

Oh, there's lots of broken things about that code. Copied, with tweaks to indenting and new comments. So the main thing there is the distinction between ACTION and PATCH. When you try to use an ACTION with a file loaded, you close that file. When you try to use a PATCH without a file loaded, you get a syntax error. Lots of commands, like OUTER_SET and SET for setting integer variables, have both ACTION and PATCH versions; make sure you're using the right versions for your current environment. Then there are two more issues. First, and more minor, your sanity check is basically nullified by ENDing it before you do anything else. If you want to condition your changes on the file being valid, you have to put your changes inside the IF block. Which is probably about the extra END; in retrospect, the END immediately after the IF looks like the one that shouldn't be there. Second, your fundamental structure here is O(n^2) in the number of items, when it could be O(n). There are about 3000 items in unmodified BG2EE. Making your code run a thousand times faster is absolutely worth it. What you're currently doing - or at least, trying to do - is to iterate over every item, then compare each item to the entire array of items and do stuff when they match. What you could do instead is iterate over the array and load the item file the current row corresponds to: That way, you're only making a single pass through the items, in that array loop.

Are you on a new save, or did you continue an existing run that had already seen that shop? Visited shops get copied into the save, and the version in the save (which mods don't touch) is what's used from then on in that run. For files that exist in both the BIFs and the override, Near Infinity will always display the override version, because that's what the game would use. You can change whether this file is displayed under "Override" or its filetype with the "Show Override Files" options, but you'll always see the version that actually gets used.

CHAIN is its own top-level .D action. It does not go inside an APPEND; that's where the syntax error comes from. APPEND to BELMIN, and the next thing WeiDU sees isn't a state. Also, it's good practice to impose conditions on the starting point of a CHAIN; you don't want Belmin to try to initiate that every time anyone talks to him even if your new elf isn't in the party.

A neat trick: READ_2DA_ENTRIES_NOW directly stores the data as an array, which you can continue to use after leaving the 2DA behind. Here's one of my components that reads data from a table: Hopefully, that helps with your second component. In my example, the table is pre-built; the first column is the resource ID for a given CRE, and the remaining columns are data for that CRE. I also have a header row, which is discarded by the READ_2DA_ENTRIES_NOW because it's shorter.

The duration difference on SPIN117 is intentional but inverted; the damage needs to come before the bonus HP expire. Compare to the berserker's Enrage ability. Opcodes 17 and 18 should be duration 120, opcode 12 should be duration 119.

It's certainly the obvious way to do it - just engage with the system that's already in use.. For reference, in those K_ tables, the number in the second column that identifies the kit is the number in the first column of KITLIST.2DA. Unless it's 0, in which case that's the "trueclass" option. What I'm not sure of here is the first column - do those have to be in sequence, or can those index numbers just be anything as long as they're different? Your current code will leave a gap in the indexing, so that matters...

The thing is, there's not just one cause for bad strings. For example, here's one in my tweak mod (as of now, will be fixed in the next update, which I've been working on): My component that modifies Baeloth's ring, if installed on EET, gives that ring the wrong name and description; some completely irrelevant stuff. What happened? Well, I just made the item in NI, and the component copies it to the override. These are not new strings, but the original item's name and description - so I don't change them. Except that EET changes all the string reference numbers for BG1 strings, so now the wrong strings are being referenced. Your idea of looking for the strings in the tra files wouldn't help. They're not there. And they won't be there after the fix either; I just compensate for the EET reindexing in code with some WRITE_LONG %loc% (THIS+200000) lines.

Yes, that's an obvious improvement.

*looks at my collection of ~50 tweaks, and the update I've been halfheartedly working on* Yeah, this is probably something I should include. Downloaded, and I'll see how it works with my stuff.

The Gloves of Healing (BRAC20) in BGEE and BG2EE are unusable by single-class clerics or single-class mages, but usable by cleric/mages. Reported on the Beamdog forums: https://forums.beamdog.com/discussion/88109/possible-bug-cleric-mages-can-use-gloves-of-healing

The only thing wrong with that script block that I can see, if you have it attached to a creature, is that there's no way to ensure it runs in the right area and spawns the creatures there rather than spawning them in the active area. If you're inside a house, for example, spawning all those creatures somewhere off in the impassible void won't do a bit of good. So, obviously, this script block should either be inserted into the area script or have an area check attached to it. Now, if it's not running in the area you want it to run in, that means something else is wrong with the script you have that block in - most likely, some earlier block is executing repeatedly so the script never gets there. Even if you move this script block, that's something that you need to fix.

Number of uses of the ChangeClass script action in vanilla BGEE and BG2EE: one. Marl becomes an INNOCENT if you talk him down. So, this is not normally a concern; the standard scripting style for creatures that wake up to become a threat is that they already have the appropriate class. Or they use a "replace creature" effect (i.e. doppelgangers) and the new object obviously won't have that issue. Well, there's one trouble spot I can see: the "ChangeAnimation" script action, which keeps some things in place like hit points. And does buggy things with effects on the creature; stuff like mage buffs stay in place and become impossible to remove with the likes of dispel, breach, or spellstrike. (At least, that's how it worked as of 2.5) What uses that action? For one, the doppelgangers that switch between various forms from Durlag's family. One of those forms - Durlag himself - is a high-level fighter. The others are a mage, a bard, a cleric, and the default doppelganger form. Plenty of opportunity for messy lingering effects.

A summary of what the table says, before and after that cdtweaks component: Before (vanilla) Level 1-6 7-12 13+ Prof 0-1 0 -1 (+.5) 1 2-4 -1 (+.5) 1 -2 (+1.5) 5 1 -2 (+1.5) 2 After (cdtweaks APR) Level 1-6 7-12 13+ Prof 0-1 0 0 0 2-4 -1 (+.5) -1 (+.5) -1 (+.5) 5 1 1 1 That component completely wipes out the APR gain for (warrior) levels, leaving only the gain for high proficiency levels. Because otherwise, with the changes to clswpbon.2da, all classes would gain APR as they leveled. Now, looking at the code, that component also creates new spells d5_numat and d5_numa2, which it inserts into all fighter, ranger and paladin CLABs at levels 7 and 13. Which should give warriors that are party members back their APR, but not non-party warriors as those don't apply the kit/class ability tables. So the component is already problematic, reducing APR for all higher-level warriors outside the party and also all higher-level monks that use manufactured weapons. But if it's breaking worse than that ... what does SCS do to the CLABs involved?