Galactygon

LOL we happened to test the same group of wallpolys! Here's another unrelated issue and it's quite a nuissance: SPLPROT.2da doesn't recognize signed stat values. For example, STAT(RESISTFIRE)>=100 will return true if the creature has negative fire resistance. You'd basically have to use STAT(RESISTFIRE)>=100 && STAT(RESISTFIRE)<127 for the fire resistance check, which is 2 extra lines.

(Really)(Force)SpellPointCreature(NoDec)(RES)() or (Really)(Force)SpellPointCreatureOffset(NoDec)(RES)() would make sense, yes.

There's a regression issue for wallpolys that appeared in 2.6 in that they do not work as well as they did in earlier patches. See attached image. The horns of the statue do not cover the character to the same extent as they used to.

Yes exactly, all EFF files using opcode 232 should be patched. Those instances of opcode 232 (cast spell on condition) should have that flag special = bit2 enabled for this behavior to take hold. Equipped items do not outsource their 232s into EFFs so the effect instances of opcode 232 on the items should be patched. The reason those spells outsource 232s into external EFFs is because of the hardcoded behavior that adds a protection from spell to itself which prevents those spells from being refreshable (via an opcode 321 placed in front of the effects list).

This has been my pet peeve since the early days of BGo. Even if the casting graphics and sound of the child spell is blank, the launched spell still disrupts other ongoing sounds i.e. spellcasting. It turns out the EE engine does have a fix for this! There's a flag in the special field that removes this disruption completely, even if the child spell has casting graphics and sound enabled so it should be an easy fix to go through those external .effects, preferrably with a REGEXP GLOB. For those external effects, you want to WRITE_LONG 0x48 (THIS BOR BIT2) You also might want to patch all items as well (i.e. Keldorn's NPSW03.itm).

If that behavior is desired then you could do the following: - Add a dummy item on SKELBLST.cre, say SKELBLST.itm that does nothing and acts as a marker - Modify Snilloc's Snowball Swarm (SPWI204.spl) by adding an effect targeting that item (opcode 182) that casts another spell (SKELBLST.spl) which kills that skeleton (use damage crushing, set to 0 hp). You need to use an external SKELBLST.eff for that to use the resource2 field.

TookDamage() is preferrable since OnHit() triggers for non-damaging spells with the hostile flag enabled.

Really nice!

This is an even more elegant solution. Row 140 of SPLPROT is the STATE_INVISIBLE check. You should apply the spell which plays EFF_M10 one second before the end of invisibility for it work. I'd also add a protection against that child spell inside every invisibility-type spell minus 2 seconds. So it would be: Invisibility & Invisibility 10-foot: Invisibility duration 7200, apply the shared spell with the expiration sound at a delay of 7199 via checking row 140 of SPLPROT, and have a an effect that protects against this expiration sound spell for a duration of 7198. Improved Invisibility, Shadow Door, etc. could use this method as well just without the invisibility check (use row 0 instead) since you will be partially invisible on expiration anyways. With this method you don't have to worry about self-dispel own and other forms of invisibility to prevent the sound from going off prematurely when multiple forms/instances of invisibility are active at the same time.

It's possible to self-remove those effects in the current engine via a repeating !(STATE_INVISIBLE) check that fires a child spell. Would prefer that the invisibility opcode applied the child spell directly though, much like the new spell deflection/turning/trap opcodes which can self-terminate the entire spell if I had it my way. This behavior would also be desireable for other effects that expire when a certain condition is met i.e. Sanctuary, Stoneskin.

Alternatively, you can also use the resist/dispel field? At least in eff v2, there's a bit there which signals that the effect bypasses deflection/reflection/trap opcodes though this bit is not present in eff v1 (& effects applied via spl or itm) formats. Somebody like @Bubb or @kjeron might have a better idea. On an unrelated note, I wonder why "self-targeting" MR behavior is so complicated.

A lot of these changes make sense and I think it's best to discuss standardizing immunities in a new thread. Or implement a flag to "bypass opcode 101" in the saving throw field (as bit23?) in the feature block? It would make the most sense to have this type of behavior there, among other things such as mirror image behavior. Then you hit several birds with one stone since you can seperate any opcode basically.

Nausea and poison immunity are two seperate things. If we really want to be specific then think of poison immunity as immunity to poisons injected into the bloodstream whereas nausea immunity would represent immunity to poison via breathing. In some cases, there would be overlap (i.e. Cloudkill) but not in most cases. Note that Cloudkill in IWD:EE does check for non.breathing creatures as well as if resistpoison>=100. It would be the least controversial to follow the rules IWD:EE uses. A fix to Bigby's Hand spells to not use opc39 was submitted internally but didn't make it to the last patch. I generally agree with David's comment about handling unconsciousness. Handling of opcode39 and feeblemind immunity should be split up imho because these opcodes are used for different effects. The reason opc39 got the sleep status icon in v2.6+ was simply to preserve the original behavior (the unconsciousness icon was unused and opc39 internally applies the sleep icon in BG2o). Any additional status icons were applied as accompanying status icons to "sleep" in BG2o rather than replacing "sleep" which is how it was changed to in 2.6. Nonetheless, I agree that splitting up opc39 to use the unconsciousness icon is appropriate. Tagging @CamDawg since we had an internal discussion about it. In IWD:EE it's much more clear cut, since the sleep status icon is only used for awaken-on-hit form of unconsciousness whereas BG1/2 do not have that form of sleep.

@Weigo In many of the BG1 (interior) areas there's a bug where closed door tiles are of a slightly different color than the surrounding tiles. You can see examples of this bug in the first basement of Durlag's Tower but it's quite widespread especially among secret doors. Do you know about this bug? Tagging @Sam. as well since we had an ongoing DM about this.

You don't need EEx for any of that. You can use opcode 183 to bypass undead resistance for Chill Touch (just found out!). Set parm2 to 0x10 to look for a ring, since undead have RING95.itm equipped. This and similar undead-centric effects should be possible to do for Fixpack. Knockdown that bypasses 101 is trickier since you need to look for many item types (i.e. 0x1c, and other weapon types).

What I'm referring to is how opcodes 220, 221, and 321 do not "look inside" driven EFFs and selectively remove them if the EFF's msectype, mschool, and parent resource fields are set. Whereas any immunity/bounce opcodes (i.e. 202-7, 223, 226-8, 318, 324), can selectively target and block or even bounce those EFFs without affecting other effects in the extended header not called via opcodes 177/283.

You are correct, my bad. I have remembered wrongly. Msectypes, mschools, and parent resource fields in the .effs are ignored for selective effect removal effects (opcodes 220, 221, 321). Perhaps @Bubb has investigated this before?

I should've read this thread earlier, was busy with RL throughout 2022. Hopefully I'm not too late to the party. The general principle of standardizing and externalizing opcode behavior is preferrable to how things used to be. I was unwilling to code this alone because of the potential to break a large number of mods. This should ideally be a community effort, supported by a critical number of mods. Also, there are several different methods as to how this could be done with their advantages and disadvantages and it's best to agree on a common way of doing things. The method discussed here previously is replacing some item and spell status effects and their associated secondary effects i.e. status icon display, sounds, etc. with child spells and then using child spells for status removal which then goes through the list of status child spells with 321s. I think this is an improvement over the status quo since you can control opcode interaction more efficiently using child status and removal spells in a standard manner. This wasn't really viable in BG2o because child spells were not properly cast if the caster wasn't an active creature - i.e. if caster was a trap or if the caster was DestroySelf()-d or unsummoned(?) though this isn't an issue for on-hit effects. Also, you can't really remove these spells in BG2o selectively unless you use msectypes which then prevents these child status spells to have a second "main msectype" used by the parent spell. Though this isn't a big issue since msectype interaction is restricted to 10-OFFENSIVEDAMAGE reflection and removal of 1-SPELLPROTECTIONS & 3-ILLUSIONARYPROTECTIONS. A slight disadvantage as mentioned above is that you need to attune all 321 effects to all child status spells, spell by spell which can be a hassle when duplicating spells i.e. PnP Celestials duplicating spells to create at-will casting time 1 variants. There's a different method not yet mentioned in this thread of using external child status .effs using a commonly-agreed list of msectypes instead of child status .spls which might even be viable in BG2o (non-EE). It would be less clutter-intensive for sure since you only need to create a number of .effs for different graphical effects (i.e. #hold01.eff, #hold02.eff, etc), rather than one child spell per spell. Also, you might not even need to farm out status removal into child removal spells since you can use opcode 221 instead - though I guess it wouldn't hurt to externalize them to child removal spells anyway for the sake of standardization. In BG2o you could selectively block and remove msectypes of external .effs and still use a "main" msectype for the parent spell so it interacts with other effects normally i.e. have 10-OFFENSIVEDAMAGE used for the parent spell and something else for the .effs bundled in that spell. In the EEs, you can also use the parent resource field (0x94) of .effs and 318 to selectively block these effects i.e. use #hold for #hold01.eff, #hold02.eff, etc. Perhaps it's possible to selectively block them in BG2o with 206s as well? Too bad opcode 321 doesn't (iirc) selectively dispel external .effs that have matching parent resource field (0x94) set - perhaps this can be changed in the future? @Bubb might be able to give a better answer whether it's easy to implement or not. What are the disadvantages of this method? The main disadvantage I can think of is using slots from the msectype.2da of which there are no more than 255. Minor disadvantages are hardcoded behaviors that come with msectypes: 1. strings are displayed when the msectype is removed so something suitable needs to be used in msectype.2da and 2. msectype protection plays the SPMAGGLO.vvc by the carrier of the effect. Though no.2 can be mitigated by using the parent resource trick possibly even in BG2o if 206 can be made to selectively block .effs based on that field. I think the second method of using external .effs rather than .spls is the better and more robust method for the following reasons: Less clutter among .spls in general. The child spell needs to have the same spell type (i.e. 1-Wizard) set as the parent spell so i.e. a priest uses CASTINGLEVELCLERIC not WIZARD if a child spell is nested inside the 7th level cleric Confusion spell. You avoid this completely with .effs which are located directly within the parent spell and do not have to account for different duration scenarios since .effs used in a .spl inherit their durations from the parent .spl. You can have mods add additional effects i.e. some mod can create a #hold69.eff that uses the HOLD msectype and parent resource #hold without having to update the child removal spell. splstates aren't necessary to selectively block external .effs since you use 206s targeted at some parent resource. Though it might still be a good idea to use splstates for the sake of scripting. This method works in BG2o which means mods can be easily updated without having to consider two different scenarios (EE or not EE?), especially if 206 (as per the IESDP) can selectively block .effs based on parent resource. In that case you don't worry about SPMAGGLO.vvc playing at all. Also, you don't need to worry about nonactive casters i.e .traps being bugged by not applying those effects. I think this is the strongest argument for this method. Whatever method is decided, I think the states should be differentiated even more i.e. Feeblemindedness and Spiritual Lock or the ever-lasting debate of Sleep vs. Unconsciousness. Then you can agree on more types of states that aren't bound to particular opcodes.

This one has been around since the original game as well: You're unable to cast (Limited) Wish after you reached the summoning limit even though the genies you summon do not have GENDER=SUMMONED set. The summoning opcodes seem to prevent new creatures from appearing once the limit is reached without checking for GENDER.

Some more which persisted since the original game: Personal space and foot circle size of the source isn't taken into account when calculating range as well as LOS. This can be best repro'd as follows: - Store a touch-range spell in a sequencer i.e. Vampiric Touch or Cure Wounds. Walk next to a target and fire the sequencer at a close range. The stored touch spells will fail to launch because their range is calculated from the caster's center x,y to the target (center x,y?) - Cause blindness in a creature with large personal space such as a dragon and it will never react to melee attacks.

Here's one, this time for projectiles: The ray-based projectiles use the caster and explosion coordinates to calculate subsequent ray orientation. Not an issue for 95% of the cases because the launch point of the parent projectile roughly coincides with the caster's x,y position. For the remaining 5% of the cases (i.e. traps or caster moves during Time Stop or large dragons) where the launch point doesn't coincide with the caster's x,y the rays' directions appear to be calculated in a seemingly odd manner. An example where this can be reliably repro-d is any of the innermost ground traps in the room at x1970 y2300 in AR9714 of IWD:EE which cast Lightning Bolt. Normally, the Lightning Bolt projectile starts as a normal projectile that creates an explosion of a single ray that then continues onwards in the same direction for a set time/distance. To the player this appears to be a projectile that transforms itself from a honing single-target non-bouncy projectile into a hit-all-in-path bouncy projectile when reaching the initial destination, continuing onward in the same direction. In this repro case in IWD:EE, the Lightning Bolt changes direction upon hitting the initial target. The reason being is that the trap's x,y position is the center of the bounding box of the trap area which is different from the launch point of projectiles launched by the trap. So the PC's x,y position relative to the center of the trap is used to determine the direction of the ray which is incorrect. The issue is that the rays should be calculated based on the launch point of the parent projectile rather than the caster's (in this repro case trap's) x,y position. A different and easy way to repro this is to cast Lightning Bolt during a Time Stop and move your caster to a different position relative to the target. The Bolt will continue onwards relative to the updated x,y position of the caster rather than the launch point of the original projectile.

If it were me, I would do the following: 1. All components apply a REPEAT.spl via an equipped 272. Inside REPEAT.spl you have a 206 at the end of the effects list with a timing mode 10 (duration frames) and duration value of something slightly less than 30, say 25. Rest of the effects have a duration value of 30, which is equivalent to 2 seconds in real time. You need this because of the bug how the frequency for 272 varies with haste/slow. You can also nest other spells inside REPEAT.spl via a knockout spell first paired with another spell that has the actual effects. Inside the knockout spell you'd have a 0-duration 206 that protects against the other spell with the effects. 2. You can then use another item with a while-equipped 206 against the knockout spell that unlocks the spell with the effects. 3. If you want to be even more complicated with more than 3 equipped items for an effect, nest another pair of knockout-spell + spell with actual effects into the first level spell with actual effects that in turn is knocked out if the second item isn't equipped. Result: you've got a way to apply these linked effects without using scripting or using up spellstates that is also backwards compatible with oBG. Doing this for more than a pair of items is very complicated since you have to account for all the combinations in which the items can be worn/equipped. You can use WeiDU to generate all your spells for these scenarios, however.

I saw these posts on Reddit and thought it would be fun to share them here. Could this be a way to add voiced lines to NPCs' unvoiced lines in the future? This one is NSFW, listener discretion advised:

One of the ways to test this bug in 2.6 is to cast a Vampiric Touch onto yourself. Without autopause or pausing the game, nothing should occour. When autopause spell cast is enabled, the caster takes damage and is healed at once.

Neither PIs and Simulacra should be able to pick pockets. Both should be able to hide in shadows, however (if we're realistic, PIs might even need to have their move silently stat buffed). Button 1 should be disabled instead of 0.