Luke

Nevermind, It turned out to be and engine bug... As a result, It should remain in this thread...

@jastey Could you please move the last posts about CreateItemGlobal() into a separate thread in the modding Q&A subsection? Thanks.

It seems it does not work the very first time it triggers... Weird... I fear I'm still missing something... Tested with "FIREB1.CRE"... The first time the inn is visited the script runs fine, but when I CTRL-Q him in the party, he has nothing in his inventory... However, if I exit the inn and renter, then when I CTRL-Q him in the party, he has the specified amount of arrows...

OK, so how do I fix it...? I want it to run every time the game is loaded / the area in which the actor is present is visited (that is why the OnCreation() trigger...)

Indeed. It seems it cannot handle stackable items... Needs fix... Could you please provide a minimal working example...? Using the script block I put above nothing happens ...

@Bubb Can you confirm the following two script actions are bugged? SetItemFlags() The I:Flags*Invitem parameter appears to be broken... CreateItemGlobal() Completely broken...? Example script below

Fine, I'll try implementing them in EEex...

OK, but this is true in any case, even if you are not STATE_IMPROVEDINVISIBILITY... Are you saying the AI is not supposed to "track" the Player if he/she is STATE_IMPROVEDINVISIBILITY...? That is to say: since on one hand the Player cannot escape an AoE spell cast by the AI, then on the other hand the AI should not be able target STATE_IMPROVEDINVISIBILITY creatures...? If that is the case, I wonder if a new family of script actions, say "SpellOffset(O:Target*,P:Offset*), might help...

Shouldn't all AoE spells, say Symbol (any type), Bless, Entangle, Fireball, Web, Grease, Haste, Slow, ... be flagged as BIT24|Can target invisible (SPL header, offset 0x18)? That is to say: shouldn't all those spells that use ability_target=4 (any point within range) and projectile_type=3 (AoE) be flagged as Can target invisible? Such a change should mean nothing for the player... However, it will allow the AI (in particular script actions "Spell()" / "SpellRES()" / "SpellNoDec()" / "SpellNoDecRES()") to target STATE_IMPROVEDINVISIBILITY creatures as intended... I mean, unlike the player, the AI cannot target a location / point, so it cannot target STATE_IMPROVEDINVISIBILITY creatures with AoE spells (which is unintended...) Am I missing something...?

Done.

Are you saying that, say, FIRE should be used for Fire Salamander, Fire Elementals, Fire Mephits, Fire Beetles, etc...? Could you provide an example...? I mean, op178/179/344 cannot target a STAT... But I suspect I'm missing something...

What do you mean exactly...? Unlike op344, op178/179 affect all attacks, not just the weapon they're on...

Indeed, there is no way to filter them by type. What about adding MEPHIT_ICE, MEPHIT_MAGMA, MEPHIT_DUST, etc. to CLASS.IDS? I mean, should be reasonable since we already have ELEMENTAL_EARTH, ELEMENTAL_WATER, ELEMENTAL_FIRE, ELEMENTAL_AIR... As far as Salamander are concerned, I suggest borrowing SALAMANDER_FROST / SALAMANDER_FIRE from IWD:EE CLASS.IDS... What about adding a GOLEM_ICE class to CLASS.IDS...? As far as blizzard trolls are concerned, I suggest borrowing SNOW_TROLL from IWD:EE RACE.IDS (speaking of this, it should probably be a CLASS.IDS value rather than a RACE.IDS one...) Polar bears are supposed to use the BEAR_POLAR class...

Yes, sounds good. Alternatively, if you do not want to touch the engine, I can share a WeiDU function that completely gets rid of op101 and relies solely upon splstates to determine what goes throught what. Since it completely removes op101, this function is supposed to be run as a "last mod", so as to ensure mods that still use op101 are compatible with the new system. However: As already said, people would be "forced" to install it It's kinda difficult to automatically handle op39 and its different uses

Speaking of this, do you think that list should be updated / expanded...? I mean: instead of checking for RACE=MYCONID, it should probably check for GENERAL=PLANT (so as to include all plants, not just Myconids...?) there are certainly other non-breathing creatures besides Undead / Golems / Plants... See f.i. Slimes, unnatural creatures (demons and the like?), Weapons (only relevant for the Mordenkainen's Sword), Green Dragons (?), others...? The same holds for Earthquake-like spells / abilities. They check for Wyverns, Beholders and Harpies, but there are other creatures that can fly / levitate or "cannot fall to the ground"... see f.i. Weapons (again, Mordenkainen's Sword), Imps, Mephits, Dragons, Demiliches, incorporeal undead (shadows, spectres, wraiths, etc...), mists, will-o-wisps, oozes, others...? Yes, it tries to be more accurate than BG (see those crude checks for non-breathing / flying creatures...) However, there is still the issue that Chaotic Commands blocks Earthquake... As I said in the other thread, if we do not want to break compatibility with existing mods, we should come up with either A new (alternate) Sleep opcode A tweaked op101 I'm trying implementing the second one in EEex (which is probably the easiest of the two), but I kinda got stucked ... I know engine-related stuff is not ideal for a fixpack (since only Windows users would benefit from it), but it's something you may want to consider for an official patch...

Good to know. However it cannot remove effects applied with `timing=9`. "7eyes.2da" cannot interact with EFFs applied by op177/283 (bug).

Before I forget (quoting your own thread): Opcode 337 (remove effects by opcode) would falter against these Opcode 198 (reflect specified effect) would falter against these I know this opcode is (partially) bugged and rarely used (if we do not consider mods), but still worth mentioning...

Yes, it does...? I mean, you can abuse Remove Curse to remove effects that are not supposed to be removed ...

What if immunities are defined as CRE effects...? Yes, most immunities are attached to special undroppable gear (see f.i. "ring95.itm"), but there might be cases (mods) where they are attached as CRE effects... op183 would not work in this case... Moreover, this solution sounds a bit hacky to me... Having said that, you might opt for op182 (since in this case you can check specifically for "ring95" instead of any ring). However: This opcode is bugged (see IESDP; fwiw, I've already fixed it in EEex) there is still the issue of immunities directly attached to the CRE file So to sum up, I think replicating op24 feature is a more elegant solution... Am I missing something? Yes, sure, that would mean that only Windows players would benefit from it, but at least it's something robust (hopefully)...

@Galactygon I'm working on EEex and trying extending the op24 feature of bypassing / ignoring op101 to some other opcode (notably op39 and op128). I'm talking about the fact that op24 can bypass op101 if param2 is set to non-zero (this is relevant for IWD:EE Chill Touch, which is supposed to cause fear in undead, but undead are normally immune to op24...). In so doing: special spells such as CLERIC_FALSE_DAWN can properly confuse Undead (that are normally immune to Confusion) in addition, there is no need to update existing .spls / .itms that provide immunity to Confusion Knockdown / Nausea can properly bypass / ignore Chaotic Commands and the like In this case however the centralized spl file ("#cureslp") should not blindly use op2 (Cure sleep), since you are not supposed to cure / dispel neither Nausea nor Knockdown (unless I'm missing something...) Instead, it should apply a list of op321 effects targeting only Sleep / Unconsciousness (can be automated by checking for op39 whose param1 is 0...) Can this be of some help...?

@Galactygon Did you perhaps manage to have a look at this issue? If so, what is your opinion?

@Galactygon Did you perhaps manage to have a look at this issue? If so, what is your opinion?

In BG1 Bassilus is flagged as CLASS=CLERIC. As a result, he should not be able to cast Entangle...

Thanks for sharing! However, I must admit it's much more complicated than I originally thought... That is to say: how would you actually use those 2 functions...? Suppose you want to alter the ratio of main- to-offhand attacks so that you get an offhand attack per each mainhand attack (ratio=50%). What should you do?

As already stated somewhere else, op182 is bugged (see the IESDP for further details...) This is a problem for items such as "blun38.itm" (Night Club +1). In this particular example, the thac0 bonus it grants during the night is not immediately removed upon unequipping the club (but will instead persist for some time...) It is possible to partially mitigate this issue by using op183... In so doing, the thac0 bonus will be immediately removed upon switching to any other weapon not flagged as "17|Maces" (offset 0x1C)... However, if the character equips another club (or mace), the effect will still persist for some time... As a result, op182 would be the perfect solution for this kind of items... But unfortunately, it is bugged...