Luke

OK then, so be it... Now that I think of it, Item Revision takes care of this inconsistency, so that's fine I guess...

Related: as far as STO files are concerned (including the various Bags of Holding), those that buy / sell "Large swords" should also buy / sell "Small swords", so that's hopefully not an issue...

OK, but the issue is still there...? I mean, why are they consistently coded as "s1/large swords" and described as "short, ideal for subterfuge, and more suited to fighting in closed places"...? IMHO, this is an inconsistency and should be fixed... Yes, you're right, those CRE files would need to be edited to account for the new weapon category... Shouldn't be too hard...

Yeah, this one uses op53, probably because someone realized that op135 is bugged when it comes to shapechanging between two different non-natural forms... I mean, unless I'm missing something, there should be no difference between "op135, p2=1" and "op53, p2=0" (they're both cosmetic changes)... Anyway, I'd use either one or the other... Separately, WIZARD_POLYMORPH_OTHER probably needs further tweaks. In particular, "squirp.itm" should also block Item usage (BUTTON_USEITEM, BUTTON_QUICKITEM[1-3]), otherwise nothing prevents you from activating something like the Cloak of the Wolf to bypass/overwrite the squirrel form... And that's clearly not intended... Now that I think of it, it should also block BUTTON_INNATEBUTTON (or grant 100% innate spell failure), otherwise druids can polymorph into, say, bears and bypass/overwrite the squirrel form... I mean, while in squirrel form, you should be able to do literally nothing (except from walking and attacking as 3-STR squirrel with 5 HP) until character death / a Dispel Magic is cast successfully upon the affected creature... I know this does sound quite OP for a 4-th level spell, but the spell also seems to be intended to work in this way...?

I'd also make sure that all ninjatōs use "SS" (short sword) and are coded as "Small swords" (Header @ 0x1C). They're described as "... short with a straight blade, making it ideal for subterfuge...". However, they are currently coded as "S1" (Long sword) and "Large swords" (Header @ 0x1C), and that does sound to be incorrect...

same here.

So true... At this point I'd simply wait for David's 109/175/185 changes and take them as a reference...

Right... So, what about attaching a SPLSTATE (f.i. DROW_CHANGE, or whatever) to "spin825.spl" (DROW_CHANGE)...? In so doing all polymorph abilities (the SPL files!) will apply an op321 effect conditionally (op326) to SPLSTATE = DROW_CHANGE (or whatever) as a result of the previous point, the attached op135 effect on the poly weapons will now work as expected (since we've just removed the Drow animation) all "Return to Natural Form" abilities will apply "spin825.spl" (DROW_CHANGE) conditionally (op326) to SPLSTATE = DROW_CHANGE (or whatever) all "Resurrection" files will apply "spin825.spl" (DROW_CHANGE) conditionally (op326) to SPLSTATE = DROW_CHANGE (or whatever) Am I missing something...? Yes, this would be another good change (i.e., all those op135 effect should use "parameter2 = 1|Appearance only"). I'd like to recall that "op135, parameter2 = 0|Change into" is bugged when you shapechange between two different non-natural forms. In particular: All your equipment will be considered as "unequipped" (in particular, you will lose passive bonuses/maluses granted by your Rings, Amulet, Helmet and the like). This is particularly relevant for personal (unremovable) gear such Nalia's ring, Edwin's Amulet, etc... In all such cases, you'll be forced to save & reload your game (since “Equipping” also occurs when game loads). Using "parameter2 = 1|Appearance only" will bypass this issue. One final note about "parameter2 = 0|Change into" vs. "parameter2 = 1|Appearance only": the former sets the 59|POLYMORPHED stat to 1, the latter does not. Is it important...? I don't think so, but I'm not 100% sure...

IMHO, all games should follow the BG2EE architecture (i.e., everything should be attached to the poly weapon as an equipped effect). In so doing, druid forms (and notably WIZARD_POLYMORPH_OTHER!) will indeed have a permanent duration (until manually reverted / dispelled / character death).

I'd like to add the following issue affecting WIZARD_POLYMORPH_SELF ("spwi416.spl") and WIZARD_SHAPECHANGE ("spwi916.spl"). We should probably add 2 SPLSTATEs, one for Shapechange and another one for Polymorph Self, so that when the delayed op146 effect triggers for removal, it will revert the caster to its natural form only if it's actually in one of those forms! Here's an example: Suppose you're polymorphed into a mustard jelly (as per WIZARD_POLYMORPH_MUSTARD_JELLY) and WIZARD_POLYMORPH_SELF is about to expire. Use Relair's Mistake ("clck04.itm") to turn into a Wolf. When the delayed op146 from WIZARD_POLYMORPH_SELF triggers, it will cancel your Wolf form (from Relair's Mistake) and that would be incorrect. Alternatively, if you don't want to waste 2 SPLSTATEs just for this task, then I suggest adding two op206 effects (resource="spwi489", resource="spin150") to all relevant polymorph weapons, i.e.: all but the ones granted by WIZARD_POLYMORPH_FLIND, WIZARD_POLYMORPH_OGRE, WIZARD_POLYMORPH_SPIDER, WIZARD_POLYMORPH_MUSTARD_JELLY, WIZARD_POLYMORPH_BROWN_BEAR, WIZARD_POLYMORPH_BLACK_BEAR, WIZARD_POLYMORPH_WOLF, WIZARD_POLYMORPH_BORING_BEETLE, WIZARD_POLYMORPH_POLAR_BEAR, WIZARD_POLYMORPH_WINTER_WOLF SHAPECHANGE_MIND_FLAYER, SHAPECHANGE_IRON_GOLEM, SHAPECHANGE_GIANT_TROLL, SHAPECHANGE_GREATER_WEREWOLF, SHAPECHANGE_FIRE_ELEMENTAL, SHAPECHANGE_EARTH_ELEMENTAL, SHAPECHANGE_WATER_ELEMENTAL As far as WIZARD_POLYMORPH_FLIND, WIZARD_POLYMORPH_OGRE, WIZARD_POLYMORPH_SPIDER, WIZARD_POLYMORPH_MUSTARD_JELLY, WIZARD_POLYMORPH_BROWN_BEAR, WIZARD_POLYMORPH_BLACK_BEAR, WIZARD_POLYMORPH_WOLF, WIZARD_POLYMORPH_BORING_BEETLE, WIZARD_POLYMORPH_POLAR_BEAR, WIZARD_POLYMORPH_WINTER_WOLF are concerned, only add 206 immunity to "spin150" (the one related to WIZARD_SHAPECHANGE). As far as SHAPECHANGE_MIND_FLAYER, SHAPECHANGE_IRON_GOLEM, SHAPECHANGE_GIANT_TROLL, SHAPECHANGE_GREATER_WEREWOLF, SHAPECHANGE_FIRE_ELEMENTAL, SHAPECHANGE_EARTH_ELEMENTAL, SHAPECHANGE_WATER_ELEMENTAL are concerned, only add 206 immunity to "spwi489" (the one related to WIZARD_POLYMORPH_SELF).

OK, I see now. I used 26818 because 0xF00080 - 0xF00000 = 0x80 => row 128 => STRREF_FEEDBACK_IMMUNE_RESOURCE I did not understand that the value needs to be exactly 0xF00080 (or 0xF00074), thanks for clarifying!

I talked about Fireball because on IWDEE it is not flagged as hostile, so that's why is 206d in MGI spell effects... Probably because they apply the Damage opcode, which in turn triggers `AttackedBy()`... In particular, note that `AttackedBy()` will always trigger because these op12 effects are coded as "Save for Half", so they'll always hit (and civilians and the like will turn hostile if not immediately killed...) However, those effects are also flagged as "Do not bypass MR", so those spells should probably be flagged as "Hostile" (otherwise `AttackedBy()` will not trigger in case of "Magic Resistance"... Unless that is intended of course...) Yes, this is an interesting case. I think that @Bubb and @kjeron know the answer... Anyway, upon closer examination, Melf's Acid Arrow is 206d in MGI spell effects on BG(2)EE, but not on IWDEE ...

I'll be certainly happy to test EEFP on iPadOS... And I guess the same holds for @subtledoctor... Also, neither here nor there, but someone managed to run WeiDU directly on his Android device... Anyway, shouldn't we actually code something (and test it) before going public...?

I'm sorry, but it's not working for me (I cast WIZARD_EYE via its scroll "scrla1.itm"...) I tested it on all the 3 games and still nothing... I'm attaching my IWDEE files to this post for inspection... Could it be something related to the macOS version of the games...? Seems quite odd though... SCRLA1.ITM SPWI425.SPL

Correct. Opcode #12 acts as "Hostile". This is hopefully not an issue. Quoting the IESDP: Opcode #102 CANNOT block non-hostile effects from self. So basically it cannot block Melf's Acid Arrow and the like if you cast it at yourself (but why should you do that to begin with...?) The only things that should be manually 206d in MGI are spells such as "spwi304.spl" (Fireball), i.e.: non-hostile AoE spells. In so doing, creatures protected by MGI can safely cast such spells at their feet without taking damage (and hopefully hit nearby enemies).

On EE games, only "demmau01.itm" is coded like that (unless I'm missing something...) Anyway, as @DavidW said, it's now pretty simple to include all PC races except elves (again, op318/324 on all ghoul attacks, including WIZARD_GHOUL_TOUCH...)

Are you sure about this one...? I tried with both 0xF00074 => row 116 => STRREF_FEEDBACK_EVADE_RESOURCE and 0xF00080 => row 128 => STRREF_FEEDBACK_IMMUNE_RESOURCE, still nothing ...

Cheers, I'll keep that in mind for the next time Interesting, good to know... Expand As kjeron says Thank you both!

Why is 101 instead of 100...? I see. Good to know. On reflection, it should not be an issue since you can set up the op232 effect to always fire and then put op318/324 effects on the subspell checking for the desired TimeOfDay (or whatever)... OK, I see now. Technically speaking, it's row 250 since we need to take into account the header rows, but I got the overall point... Could you provide a concrete example where this is relevant? I mean, the op232 effect is usually attached to the creature casting the specified SPL file(s), so they're usually the same creature ... Could you also provide a concrete example of this? Thank you!

OK, thanks for clarifying. So if I enable "Game Option: 3E Sneak Attack", the whole thing does not apply...?

Interesting. That post would also explain why "bdbonbat.itm" (Bonebats) has an op318 effect targeting RACE=ELF (i.e., elves, having great positive energy, cannot be paralyzed)...? If that's indeed the case, then we should extend it to all ghoul/ghast/lich attacks (for consistency)... along with updating the Elf description (Character Creation...) I agree. As @suy said, we just need to decide what to do with the Cure Stun opcode... IMHO, it should be removed because it has nothing to with Free Action (hindrances to movement...) I agree. Again, I agree. Paladins items such as "bdhelmca.itm" should of course receive the same treatment (also note that in this particular case, unlike Undead Hunters, the description uses the word "paralysis"...) As far as the Inquisitor is concerned, it should be the other way round, i.e.: immune to op175 and vulnerable to op109... Yes, makes sense. However, IWDEE description specifically lists Hold (along with Stun – this also seems to be out of place)... Seriously, it is a mess ... What about letting it to protect against all mind-affecting effects (Charm, Sleep, Power Word: Sleep, Panic, Confusion, Feeblemindedness, Hold, Stun, Power Word: Stun)?

@Graion Dilach You already took care of this, right...?

Any relevant differences with respect to "Range()"...? When you say [Extra | 1], do you mean BIT0=2^0=1 set to 1, right... ? And similarly [Extra | 2] => BIT1=2^1=2 set to 1 [Extra | 4] => BIT2=2^2=4 set to 1 [Extra | 8] => BIT3=2^3=8 set to 1 ...? So for instance, if you change Night Club +1 ("blun38.itm") to THAC0: +1, +2 at night dusk (i.e., set [Condition = 13] && [Extra = 1]), then you'll see "A contingency spell has been triggered" and the op232 effect will be removed (i.e., it'll trigger just once, even if I'm still equipping the club...). How can I avoid this issue...? I tried applying it via op177 and I got mixed results, i.e.: the op232 effect does not terminate after first trigger but will also display "A contingency spell has been triggered" every time it triggers (but it shouldn't since "parameter3=0" ...) Are you talking about STRREF_GUI_FEEDBACK_CONTINGENCY_TRIGGER...? If so, then how can strref be 0xF000F6...? According to BG2EE "enginest.2da", that should be strref 36936 (0x9048)... Could you clarify effect source vs. effect host...? To clarify: casting glow => Header @ 0x22...? string => Header @ 0x8...? To clarify: range => Extended Header @ 0xE...?

I think that's true for any mod that introduces new enemy encounters and the like... Anyway, I'm definitely in favor of this approach

Could you confirm that it's not restricted to thieves but to any CLASS/KIT listed in "backstab.2da" / "sneakatt.2da" the attacker's weapon does not need to be suitable for backstabs / sneak attacks (i.e., not necessarily usable by thieves)