Luke

As I've already said, it might be problematic to tell if an op39 effect is, say, Unconsciousness or Knockdown, especially considering mod-added assets... Anyway, we now have an alternative method which is mods friendly... Yes, I think that for the time being we should rely on this bug... Just note that the various "Cure" opcodes only consider EFF files applied by op177, so in case the effect needs to be cured (CLERIC_FALSE_DAWN...?), you need to use op321 targeting the resref applying the op182 effect... Something like a 3-second unconsciousness each time the Damage opcode triggers...? That is: immediately after the spell is cast after 12 seconds after 24 seconds Also, I would do the same with Shake Screen (it's currently applied via op272, and that means it's subjected to Haste / Slow... It does not make any sense to me... I'd apply 3 separate op269 effects...) and Play Sound (for some reason they are applied one second before the Damage opcodes...) Finally, if it's gonna work on sleep immune creatures, then flying creatures and magically levitating creatures (Demilich, Mordenkainen's Sword, etc...) should definitely be immune to it (just add a 324 RACE check to all relevant SPL/ITM files...)

A quick test shows the trick works fine, so we can proceed me thinks...

Apparently, it works fine on EEs too... Also these two values will be inherited from the feature block of the spell, you can safely leave them at 0... Yeah, that would be a problem... Maybe @kjeron knows a workaround...? I'm not positive... It'd be much much easier if EE mods adapted to the new splstate system, there would be lots of benefits...

Yes, sure, mods will need to adapt to the new system, otherwise it's a mess... Also, having such a tweak last in the mod install order might be a problem (it might be problematic to tell if an op39 effect is, say, Unconsciousness or Knockdown, especially considering mod-added assets...) This is interesting, I did not know it, and it can indeed solve this issue... What do you mean exactly by "short duration"...? I mean, EFF files applied through op177/283 ignore the Duration field (i.e., they use whatever Duration you set on the op177/283...) Could you please attach here how you would code, say, SPIN695.SPL to force the creature to fall down...? Also, the fact that op283 can be removed by op26 (Remove Curse) is a problem, right...? So maybe we should also add an immunity to op26...? For @Bubb: apparently, EFF files applied by op283 can bypass / ignore op101. Bug or Feature...? Something else to know about it...?

(also calling @DavidW) What if I told you this is actually a problem and should be removed on EE games...? That is to say: what if certain creatures should be immune to, say, all confusion effects except if coming from a specific spell/attack (or from some specific spells/attacks)? As you all know, we have two Panic opcodes, two Hold opcodes, two Charm opcodes, etc... but we don't have two Confusion opcodes! Additionally, op337 does not work with a limited timing mode (the two Bigby spells use this trick to force the targeted creature to fall down, but the problem is that the immunity is not restored)... plus it cannot remove effects applied with timing mode 9... Having said that, thanks to the new (splstate) method, we no longer need to rely upon op101 (and its accompanying effects op267, op296, op169, etc...) Real case study: CLERIC_FALSE_DAWN ("sppr609.spl") is supposed to confuse GENERAL=UNDEAD creatures (as per its description). Now, since most (all?) undead are immune to Confusion (plus icon, visual effects, etc...), this spell is not working as expected. But you see...? If undead were not immune to Confusion (plus its accompanying effects) and CLERIC_FALSE_DAWN did not check for CONFUSION_IMMUNITY, they would be immune to all Confusion sources but this one (as intended). To sum up: if an undead is immune to Confusion, @DavidW's code should remove op101 along with all its associated effects (again, op169, op267, op296, etc...) flag it as CONFUSION_IMMUNITY (via op328) add the 324 check for CONFUSION_IMMUNITY to all spl/itm files that apply Confusion (op128), while skipping special cases like the aforementioned one As already said, you might want to do that for all opcodes that are not in pairs... On reflection, you might want to do that for all opcodes indiscriminately... I mean, if I used op241 (Charm 2) to bypass immunity (op101) to op5 (Charm 1), the targeted creature would certainly be charmed (since nobody is supposed to be immune to the alternate opcode), but the Charm Icon / Visual effect / sound / etc... would still be blocked... Thoughts...? Addendum: getting rid of op101 would also allow Earthquake-like, knockdown (Dragon Wing Buffet – "spin695.spl") spells/attacks to bypass / ignore Chaotic Commands and the like (these spells are supposed to block only true Sleep / Unconsciousness effects, not also Earthquake and knockdown attacks...)

Why are you suggesting the main file should use `projectile=1|None` and the shell file should instead use the real projectile...? I mean, CLERIC_HOLD_PERSON ("sppr208.spl") also requires you to target a specific creature (`ability_target=1|Living actor`) while using an AoE projectile ("hold.pro")... On reflection, I don't think it really matters (since we're not using op146*p2=2, op326, op333 + the spl in question is supposed to bypass all MR checks)... just wanted to know whether I'm missing something or not... Moreover, I think the AoE projectile should be coded as a cone projectile rather than a traditional AoE projectile (only targets facing the dragon should be affected, not also those staying behind...)

Well, guess we should also ask @argent77, @Wisp Which of the following code snippets is supposed to take less time? In my case it is the first one, whereas on DavidW's computer is the second one... My computer runs macOS and is quite ancient (mid 2012, sigh), whereas DavidW's computer runs Windows (if I recall correctly) and it is probably not that ancient... I'm not sure if it can make a difference, but just so that you know it...

OK, but then why does it (the no PATCH_WITH_SCOPE variant) take more time in my case...? I tried running it several times and it always took more time (~ 1 second) than the one with all those PATCH_WITH_SCOPEs...

Fair enough... Just to clarify: is this the code without all those PATCH_WITH_SCOPEs...? Also, why is PATCH_WITH_SCOPE supposed to be so relevant...? I mean, it's basically a function that takes no argument and returns nothing...

Yes, it might be useful to know this trick... Yes, WeiDU’s low-level functionality should only be used when COPY_EXISTING_REGEXP a large amount of files... If you're dealing with just a bunch of files, then you'd be better off using WeiDU's built-in functions (which are certainly easier to read...) Guess you could also opt for WeiDU ADD_SPELL|ITEM_EFFECT (it takes roughly 9 seconds on my computer...) Are you sure about this...? Asking because it takes roughly 1 second more than before for me (as far WeiDU Timings are concerned, the most relevant difference between having all those PATCH_WITH_SCOPEs and not having them is `process_patch2` => 2.199 with PATCH_WITH_SCOPEs vs. 3.057 without PATCH_WITH_SCOPEs...)

As far as "Adding and subtracting headers" (page 59) is concerned: as far as subtracting is concerned, you showed us a handy way to achieve it (the 999 trick): As far as adding is concerned, it might be convenient to use WeiDU’s low-level functionality instead of WeiDU's built-in functions (mainly for efficiency – the following piece of code should take less than 5 seconds to patch 3083 files (unmodded IWD:EE)...)

@Ardanis, @Mike1072 Sorry for the necro, but This mostly works, the only issue is that it does not take into account the order of characters. That is to say, if my separator is "ab", then also "ba" is valid... Unless I'm missing something, nothing changes when reordering the capture groups... Do you have any other idea...? I mean, it is certainly possible to build a parser (function) that scans the input string character-by-character (byte-by-byte) and remembers when quotation is open... However, in case of multiple separators (i.e., if multiple separators are valid), how should I use it? Guess I should check them one by one, i.e.: You see, it is a bit inelegant, but it should work... Having said that, I still did not understand whether it is possible to use a regexp or not ...

Guess you meant ...? The former is, whereas the latter is not (since it's not coded as a dragon...) Now that I think of it, the former should not be coded as a dragon while in human form...

Done. Thoughts...? I think the tweak can be safely extended to classic bg2 / bgt... However, since I can only test EE games, I'll leave that part to you...

This is interesting, I can work on it... Also, what about expanding it so as to include other relevant creatures...? For instance: Drows, Duergars -2 Dexterity, -2 saves, -2 THAC0 Kobolds, Tasloi, Goblins, Kuo-toa -1 THAC0 Orcs, Orogs -1 THAC0, -1 morale Sahuagin not sure here... 3E speaks of blindness, 2E is a bit vague ("They dislike light, and bright light [...] is harmful to their eyes.") Spectral Trolls insta-death, though it's not actually insta-death ("Spectral trolls vanish in direct sunlight. They do not take damage from sunlight, they merely fade from view and reappear at the same spot at nightfall.") this does sound too complicated or even impossible to implement... Feyrs insta-death ("Common feyrs are slain by the morning light...") Wraiths cannot attack, though it's not that simple ("Sunlight cannot destroy the wraith, but the undead creature cannot attack in sunlight. It shuns bright (e.g., continual) light sources in general, but will occasionally attack if the compulsion to do so is strong.") Thoughts...?

@kjeron Interesting, that would certainly explain my in-game tests... Did you perhaps round up .75 to 1...? I mean, technically speaking (and unless I'm missing something), 8 should be 7.75 (7.5/2 + 4 = 7.75)... Having said that, if we consider again the BG(2) version of Summon Insects ("sppr319.spl"), we have (in case the targeted creature is hasted): As you can see, the total number of triggers is 63. To be precise, I got 62... But I guess that's due to some rounding issues, right...? Now, in order to get 42 damage, we would need to block one effect at each interval... So for instance, when the one at 1 triggers, the next one at 1.5 should not fire (i.e., we would need a 0.5 second immunity...) I tried the following setup and everything seems to work fine Moreover, sometimes everything seems to be fine even in case of Slow (i.e., a slowed creature takes 11 piercing damage... Though I'm not sure how to consistently replicate it...) But since we do not know how the multiplier scales with Slow, I'm not sure why it is so... As far as Creeping Doom is concerned, it should be fine as is since its default frequency is already once per second (i.e., the multiplier is a direct 2x in this case)... To be precise, the subspell is still needed to support "7eyes.2da" (which cannot block EFF files)... However, the trailing op206 effect can hopefully be omitted... Anyway, just out of curiosity: would you or @Bubb be able to determine the multiplier in case of Slow...? How would you proceed...?

@Bubb Yeah, it's a real mess... Ideally (and unless I'm missing something), since Summon Insects triggers once per 2 seconds for 42 seconds, it should deal: 21 piercing damage if the targeted creature is not Hasted/Slowed 42 piercing damage if the targeted creature is Hasted 10 piercing damage if the targeted creature is Slowed However, I got the following (I never manually paused the game and disabled/turned off all auto-pause game options): 21 piercing damage if the targeted creature is not Hasted/Slowed 62 piercing damage if the targeted creature is Hasted Wut??? 21 piercing damage if the targeted creature is Slowed Wut??? As you can see, there is something wrong with Hasted/Slowed targets ... Do you have an explanation for that...?

@Bubb So, here is another possible engine bug... Could you please look into op272 mechanics and report here how it really works? As you surely know, this opcode might trigger under intended circumstances, and that's certainly bad... This odd behavior is easily reproducible with spells such as Summon Insects ("sppr319.spl"): this spell (op272 - once per 2 seconds for 42 seconds => "ipdam1.eff") might deal more damage than intended, especially if the targeted creature is hasted (since the opcode is subjected to Haste/Slow)... Is there a way to prevent it from triggering under unintended circumstances...? I mean, if we're dealing with a removable (limited) effect, then the following setup should be enough to bypass this issue But what about this particular case (Summon Insects)...? I mean, op12 (Damage) does not leave behind a removable effect, so op321 would not work in this case... Is there a workaround...?

Another FYI: as you can see, my work is largely based on two functions (which in turn are based on DavidW's code) that automatically make subspells (including dealing with `power`, `primary_type`, `secondary_type`, dice values, etc...) / reorder effects... They are launched relatively early so that I can just open NearInfinity and look at unmodded effect indices to determine the files that need to be patched... Any further patch (if needed) is done later on in the main file (i.e., "iwdee.tph"...) In so doing, it should be easier to patch the relevant files...

Fair enough. In any event, I would use 0 (instead of 255) to blank the CLASS value of Shambling Mounds...

Yes, this would be the main reason... I mean, it's not really a bug, but they're certainly kinda misleading, aren't they...? As I said (and unless I'm missing something), they are not referenced in any scripts/dialogues/op318/324/326, so why are there in the first place? According to the IESDP, the old bg1/bg2/iwd list them as well... Though I doubt they are actually used in scripts/dialogs (cannot check...) So my question is: is it possible that whoever added them did not know that 0 already stands for 'any RACE/CLASS'...? Otherwise why calling them NO_RACE / NO_CLASS...?

The key point is that it should be the other way round, i.e.: 255 => 0 (I fixed my previous post based on kjeron's comment...)

Yeah, you're definitely right, me dumb... I had completely forgotten about that... And for that specific reason, unlike "splstate.ids", valid values range from 1 to 255 (instead of 0 to 255...) Yeah, makes sense, I'll "fix" my other thread...

Just a FYI: I have just committed something similar for IWDEE to make sure "7eyes.2da" works properly. I also started to include some BG(2)EE resources (for later compatibility with IWDification, which is supposed to ship the Seven Eyes spell), but then just stopped because I think we are doing the exact same thing... Let me know if you're fine with my work on IWDEE...

As I said here, all 0 should be 255. As you can see by looking at "class.ids", unlike class #255, class #0 does not exist (what NearInfinity labels as `0|None` is just the default value, not an actual/existing "class.ids" identifier... Even the default value for dialogue at CRE offset 0x2CC is labeled as `None`, but that does not imply that a "None.DLG" file does exist as a game resource...) If a modder wanted to add a brand new class value, he should be able to use index #0 (i.e., the first available unused index)... And that's why all existing 0s should be changed to 255...