kjeron

Helmet maybe? Critical Hit protection also blocks extra effects from opcode 341. Because Balor's are clearly wearing them and not just given undeserved immunities to make them arbitrarily harder.

0x10c would be used in SPLPROT, where the checks are defined, but there is already an entry for it by default in SPLPROT: RACE 0x10c -1 1It happens to be row# 104. The row number for the check is the value used for Parameter2 in opcode 326. The first column is just an irrelevant label with no function(RACE), the second row is the stat/IDS to check (0x10c = RACE.IDS), the third is the value (-1 = use Parameter1), the last is the relation (1 is 'equal') Critical Hit effects no longer bypass Weapon Immunity in the most recent beta version (v2.5b), which may be why it's not working on some demons, balor's require +3 or better to hit.

The "This Weapon Only" option of opcode 341 doesn't work when used in an EFF, it has to be directly on the weapon, so you will need to go through two subspells to filter the race of both the user and the target. On item(global/equipping effect): Critical Hit Effect (341), Self(1), "This Weapon Only" (1), While Equipped(2), (resource) (resource).SPL: Apply Effects List (326), Self(1), RACE(104)/TIEFLING(153), (resource2) (resource2).SPL: Slay (55), Preset Target(2), RACE(4)/DEMONIC(121)

The only duration this opcode can carry is a delay. The effect itself is always instantaneous. The 8 character distinction is still the issue here. If the spell is not 8 characters, it will be removed from the spellbook and all memorized copies will be removed. If the spell is 8 characters, it will be removed from the spellbook, but memorized copies will remain intact.

Parameter2 = 1 with an empty resource field, at least in EE's.

You can simplify some of this: The projectile can restrict it's targets to only enemies with normal but without improved invisibility. Opcode 136 (Force Visible) already removes only normal invisibility without touching improved invisibility, instead of opcode 337. Depending on what Beamdog does with Sanctuary, you could clone all normal invisibility effects to also apply sanctuary for the same duration. Opcode 136 will remove normal invisibility, while leaving sanctuary intact, rendering them visible while enabling only those with opcode 193 to target them until they take a hostile action.

That looks like my fault, but CamDawg has the right answer. Looking it now, I'm surprised it wasn't causing me any problems, unless all vanilla store files just happen to have item types listed last.

Set the ability to zero maximum charges.

When using Opcode 148 and Parameter2=1 (Instant), it is limited by the casting range of the spell to be cast. It's the same limitation as sequencer activation being out of range for the spells it will cast. Extend the range of the spell at least +3 over the range of the wand. Activating an item and casting a spell normally are given an extra ~2 feet of range, which is not given when range is checked by these opcodes, which will result in you being out of range if you attempt to use it at maximum range of the wand.

Apologies ... I was thinking of it's other function - parameter2 controls two separate aspects of opcode 32: If zero, the animation is NOT reset, and the effect only works if the target is dead (specifically, STATE_DEAD). If non-zero, the animation IS reset, and the effect works whether the target is dead or alive. The priest's raise dead and resurrection spells have it set to zero. bdresurr.spl has parameter2 of its opcode 32 set to one.

Raise dead resets the creatures animation in the same manner it is determined at character generation. It is how the game restores the animation to someone who has been chunked. Normally, the creature must be dead for Raise Dead to have any effect, but this restriction can be bypassed by setting Parameter2=1, which bdresurr.spl uses. Changing it's parameter2=0 will stop it from altering the dog's animation, but only if the dog is alive. You might be better off giving the dog a scripted check in its override script to set a variable when dead, and re-apply whatever spell sets the Dog animation when that variable is set and it is alive.

Parameter5 is at least set (to 1) when using opcode 177.I don't know if it's actually used, as changing it zero and two had no noticeable effect. But, the game did always reset it back to 1 after loading and saving the game.

No, it doesn't stack, most recent overrides old, and equipped is always suppressed by spells. But, the monk and kensai are the only vanilla sources of the effect. It was given directly to a few bosses, only to arbitrary increase their difficultly, so that shouldn't be an issue, even if they did use a launcher. SoD adds an Ioun Stone with it, but that's it. Kensai cannot use launchers anyway, so no issue with them. Monks are restricted to slings, but I find it curious that monks have this bonus anyway - I could find no basis for it in either 2e or 3e, and it only affects their weapons, as all fists already have speed 0. Now, I'm sure several mods would have conflict with it. For EE, if the Launcher and ammo cannot be fixed internally to use a cumulative speed, maybe the opcode could be changed so that it has cumulative/set/setifbetter options as opcode 189 does.

For vanilla(or both), couldn't you just add an equipped Increase Attack Speed Factor(190) effect to launchers, a negative amount matching their proper speed factor, while leaving all ammo at 0. Ammo-less Launcher's would need their own Speed set to 0, so they don't double up when used without ammo.

That's a great table. Thank you very much! And I still may need help in two issues: 1. You mentioned "Spellstates 6240+ are dependent on the game campaign/version, read directly from specific offsets of the EXE. Pattern is 32(set) - 160(emtpy) - 32(set), and repeats semi-consistently up to the max (32767)". If I skip 6240-6271, use 6272-6431, then skip 6432-6463 ...etc, will function as expected? 2. Can I use splprot.2da to check them in script ? And how? The semi-consistent part is that it occasionally has an extra multiple of 160 empty SPLSTATES between sets. For example, BGSOD v2.3.67.3, starting from 6240, has: 3x(32 - 160 - 32) - 160 - 7x(32 - 160 - 32) - 1600 - (32 - 160 - 32) - (32 - 160 - 32) etc... But I don't know if every game version has the same pattern off extra space or not. I didn't go very far with it, other than to check from the other end (32767) to see if it was still in effect. The second 32 of each such set has always had the exact same value though, 0x0000000a, using only bits 1 and 3. SPLPROT only works in spells/items/projectiles, and comes with an entry for checking SPLSTATES, entry 110, using Parameter1 to specifcy the spellstate. Scripts still have to use CheckSpellState().

There are two gaps of 32 splstates that I haven't been able to map, one at 1664-1695 and one at 4224-4255, and then several semi-random gaps beyond 6240(where it starts pulling from the EXE). SPLSTATE 500, for example, is set by BIT4 of the RESISTFIRE stat. 496 is set by BIT0 of RESISTFIRE, 497 of BIT1, 498 by BIT2, 499 by BIT3, 501 by BIT5 502 by BIT6, 503 by BIT7, 504 by BIT 8, 510 by BIT14, 511 by BIT15, then 512 is BIT0 of RESISTCOLD, and it continues on. There are some usable SPLSTATE ranges within the stats, as some stats cannot carry values other than zero or one (BIT0), leaving the other 15 bits open, such as HELD (1409-1439), PLYMORPHED (1441-1471), ENTANGLE (1473-1503), SANCTUARY (1505-1535), MINORGLOBE (1537-1567), SHIELDGLOBE (1569-1599), GREASE (1601-1631), and WEB (1633-1663). I made a table of all this here, excluding the values above 6240, as it varies depending on game version.

SPLSTATE values 256+ are set by the engine for other purposes. (STATS, Bardsong, Backstab, New Opcodes, some pulled straight from the EXE). Setting them manually has no effect(mostly), but checking them is not reliable.

Opcodes 182/183 have been documented, they just haven't been updated in IEDSP. 183 is "Use EFF file if/while item type equipped". (If or While) depends on the opcode used in the external EFF. 182 would be "Use EFF file if/while item resource equipped", except that its resource field does not work, so it cannot restrict itself to a specific item, and its EFF resource is specified in Resource2, so it must be used in V2 effects. Free action removes Opcode 126's that SET VALUE less than normal(normal = INI move_scale). Free action suppresses(~1 Round) Opcode 176's that SET VALUE less than normal. 312 has worked for some time in the EE's, just not updated in IESDP. 112, 274, 313, 338, and 360 are all correctly documented in the IESDP, despite any difference you see in their code. My understanding is that 322 was abandoned in favor of 324, it does not work in-game.

COPY_EXISTING ~7EYES.2DA~ override COUNT_2DA_COLS cols READ_2DA_ENTRIES_NOW ~READ_7EYES~ 1 FOR (i = 3; i < READ_7EYES; ++i) BEGIN // i = first row of data FOR (j = 0; j < cols; ++j) BEGIN PATCH_IF !VARIABLE_IS_SET EVAL ~READ_7EYES_%i%_%j%~ BEGIN SET j = cols READ_2DA_ENTRY_FORMER ~READ_7EYES~ i 0 newrow FOR (k = 1; k < cols; ++k) BEGIN PATCH_IF VARIABLE_IS_SET EVAL ~READ_7EYES_%i%_%k%~ BEGIN READ_2DA_ENTRY_FORMER ~READ_7EYES~ i k text TEXT_SPRINT newrow ~%newrow% %text%~ END ELSE BEGIN TEXT_SPRINT newrow ~%newrow% *~ END END REMOVE_2DA_ROW i 1 INSERT_2DA_ROW i 1 ~%newrow%~ END END END PRETTY_PRINT_2DA BUT_ONLY It requires that you know how many header rows the file has, so that it can skip them, but that number should never change per file. Use different ~READ_~ variable for every file.

Desired behavior would depend on the weapon. For the given example, Melf's Minute Meteor's, you would want the entire stack prevented, because just one effect getting through will waste spell deflection/reflection charges. While the axe you mention would be a case of: It works for both melee and ranged weapons. I would stick to subspell(s), instead of subEFF(s) and opcode 248/249, since those cannot restrict themselves to just "one" weapon when dual-wielding.

The items resref: "MELFMET". The EE protection/removal opcodes work for both item and spell resrefs: 318, 321, 324, 363.

Why a subspell? Just put 324 as the first effect in the item header. You would only need subspell(s) when there are multiple types of effects that need different immunity conditions.

It's not limited to party members, but all creatures with humanoid creatures animations (xxx_LOW animations are restored as non-LOW animations). Monster animations appear to be restored as human clerics though. Looks like its controlled the same waya as CharGen. The creature gets an animation assigned based on its Race/Class/Gender, with Human/Cleric being the default. Changing the race/class/gender of the creature before chunking them changes the animation they come back with.

Chunking itself causes a permanent animation change (to one of the EXPLODING_ARM/FOOT/LEG/TORSO animations) and a (hair/skin/major/minor) color change (all to a red color). It has to reset the animation of the creature. Odd though that party members return to their proper animation(though still recolored), while others revert to the Human Cleric.

All chunking goes through Opcode 13. You can use the Seven Eyes Effect+7eyes.2da(13*0x8, 13*0x40, 13*0x80) to stop just the chunking deaths, and to stop the hard-coded chunking effects. Known con: Whenever the creature would die a "chunking" death, no death occurs(no exp, limited effects not removed), and the creature is restored to full health.