Should be:

There are eight bytes between this offset and the next one, and if you parse fields sequentially and set this as a size 4 dword, you will end up with an alignment error. Changing it allowed me to reproduce the original IWD2 SPL resources exactly.

And yes, it allows you to change two mechanisms:
- Backstabs no longer require the creature to be invisible.
- Sneak Attacks (and Backstabs) no longer require the creature to be flanking their target.

But, since EE (I think), it also allows you to set slightly more detailed parameters:
- 0 ⟶ deactivate effect
- Bit 0 ⟶ see above
- Bit 1 ⟶ Backstabs no longer require the creature to be invisible.
- Bit 2 ⟶ Sneak Attacks (and Backstabs) no longer require the creature to be flanking their target.

This opens up some exciting new possibilities.

But, be careful. It can quickly become too overkill in spite of everything.
1. Not GOODCUTOFF creature don't have to be flanking their target, regardless of the value. So, if the bit2 is active, the creature can backstab with every hit (hello CHARMED_PC).
2. Sneak attack don't require the creature to be invisible. So, if the bit3 is active, the creature can sneak attack with every hit.

edit : misleading bit value

https://gibberlings3.github.io/iesdp/file_formats/ie_formats/ini_anim.htm#formINI_type_4000

ISSUE:

Available orientations (sequence → direction):
- 0 → S, 1 → S, 2 → SW, 3 → SW, 4 → W, 5 → W, 6 → NW, 7 → NW, 8 → N, 9 → N
- 10 → NE, 11 → NE, 12 → E, 13 → E, 14 → SE, 15 → SE
 

The sum of the 16 orientations is correct, but some of the names are possibly incorrect.

EXAMPLE: 

• SSIMC.BAM (BG2EE)

Assuming based on this example(SSIMC.BAM) and type 1000 (monster_multi) it should be:

Available orientations (sequence → direction):
- 0 → S, 1 → SSW, 2 → SW, 3 → WSW, 4 → W, 5 → WNW, 6 → NW, 7 → NNW, 8 → N

- 9 → NNE, 10 → NE, 11 → ENE, 12 → E, 13 → ESE, 14 → SE, 15 → SSE

Review needed!

NOTE: IWD2 doesn't use the specialist restriction flags on SPLs, which is why I tested changing the Primary school instead. Unfortunately, this means there isn't a great way to remove/adjust specialist restrictions.

Basically this seems to just be a dummy file, unless I'm missing something. For reference, this is the file I'm talking about:

As a test case, this mod adds 3 items: testamul, testhamm, testwand.
- "testamul" is a clone of Amulet +1 with an op206 at the top that prevents elves from gaining any of the bonuses.
- "testhamm" is a clone of Warhammer +2. It uses op206 to prevent allies from taking the bonus electrical damage.
- "testwand" is a clone of Wand of Fire. It uses op206 to protect allies from the fireball (not the scorcher).

The items are automatically added to Player1's inventory. (note: as stated, this does not work reliably for IWD1, it's installable on it for testing purposes)

BACKUP ~weidu_external/backup/iwd2op206test~
AUTHOR ~~
VERSION ~0.1~

BEGIN ~testmod~


//prep
ACTION_IF (GAME_IS ~iwd how totlm~) BEGIN
  OUTER_TEXT_SPRINT amul ~AMUL14~
  OUTER_TEXT_SPRINT hamm ~HAMM03~
  OUTER_TEXT_SPRINT wand ~WAND05~
END
ACTION_IF (GAME_IS ~iwd2~) BEGIN
  OUTER_TEXT_SPRINT amul ~00AMUL13~
  OUTER_TEXT_SPRINT hamm ~00HAMM04~
  OUTER_TEXT_SPRINT wand ~00WAND04~
END

OUTER_SET elf = 15
OUTER_SET allies = 49
OUTER_SET lore = 0
DEFINE_PATCH_FUNCTION prep BEGIN
  WRITE_SHORT 0x42 lore
  WRITE_LONG 0x1e 0 WRITE_BYTE 0x29 0 WRITE_BYTE 0x2b 0 WRITE_BYTE 0x2d 0 WRITE_BYTE 0x2f 0
  LPF ALTER_EFFECT INT_VAR silent=1 STR_VAR match_resource=EVAL ~%SOURCE_RES%~ resource=EVAL ~%DEST_RES%~ END
END


//makes items
COPY_EXISTING ~%amul%.itm~  ~override/testamul.itm~
  LPF prep END
  LPF CLONE_EFFECT INT_VAR multi_match=1 opcode=206 parameter2=elf STR_VAR resource=testamul END
IF_EXISTS

COPY_EXISTING ~%hamm%.itm~  ~override/testhamm.itm~
  LPF prep END
  LPF ADD_ITEM_EFFECT INT_VAR type=99 opcode=206 target=2 parameter2=allies insert_point=0 STR_VAR resource=testhamm END
IF_EXISTS

COPY_EXISTING ~%wand%.itm~  ~override/testwand.itm~
  LPF prep END
  LPF ADD_ITEM_EFFECT INT_VAR type=99 opcode=206 target=2 parameter2=allies insert_point=0 STR_VAR resource=testwand END
IF_EXISTS


//script
<<<<<<<< .../temp/testing
IF
    !Global("iwd2op206test","GLOBAL",1)
THEN
    RESPONSE #100
        SetGlobal("iwd2op206test","GLOBAL",1)
        stuff
END
>>>>>>>>

COPY - ~.../temp/testing~  ~inlined/testing.baf~
  REPLACE_TEXTUALLY ~stuff~  ~GiveItemCreate("testamul",Player1,1,0,0) stuff~
  REPLACE_TEXTUALLY ~stuff~  ~GiveItemCreate("testhamm",Player1,1,0,0) stuff~
  REPLACE_TEXTUALLY ~stuff~  ~GiveItemCreate("testwand",Player1,20,20,0) stuff~
  REPLACE_TEXTUALLY ~stuff~  ~Continue()~

EXTEND_BOTTOM ~BALDUR.BCS~  ~inlined/testing.baf~


//
//

additional notes for IWD1:
- the amulet usually will give the bonuses to elves, bypassing the op206 effect. However, if you equip and unequip it multiple times, it will eventually not give the effects, so the effect is applied, but doesn't reliably block the other effects.
- fireball from the wand. Sometimes it ignores allies. Sometimes it hits 1-2 PCs. Sometimes, it hits anyone. It's not clear what it's based on. Reloading a save can sometimes make it work or not work (if it was not working or working before).

Current description:

Quote

#105 (0x69) Stat: Gold Variants: BG1
Parameter #1: Statistic Modifier
Parameter #2: Type

Description:

Applies the modifier value specified by the Statistic Modifier field in the style specified by the Type field.
Known values for Type are:

• 0 ⟶ Cumulative Modifier: Gold = Gold - 'Statistic Modifier' value
• 1 ⟶ Flat Value Modifier: Gold = 'Statistic Modifier' value
• 2 ⟶ Percentage Modifier: Gold = (Gold * 'Statistic Modifier' value) / 100

The effect modifies party gold or GOLD for everyone else.

Note: Type=0 can only remove gold. Gold amount has a lower bound of 0.

The misleading part? In mode 0, affecting a non-party creature, the effect adds gold. I just ran a quick test in BGEE ... modify +2 arrows to apply op105 with a value of 10 as an on-hit effect, take an archer for a spin against a Blacktalon Elite (20 gold base, no random drops). Killed on the third arrow, 40 gold dropped. Not zero, as that description would have you believe.

This has been noted before (I found an archived thread from 2023), but the sign inversion never actually made it to the public IESDP.

Quote

 

• 3 ⟶ Simulacrum — Image is created with the targeted creature(s) Current Hit Points and the following (in order)
  • Allegiance set to ALLY, NEUTRAL, or ENEMY, depending on target allegiance
  • Gender set to ILLUSIONARY
  • All AI scripts and Dialogues are set to "" (empty string, i.e. they will be cleared)
  • Script Name (Death Variable) set to "COPY"
  • Opcode #68 based on effect duration
  • Opcode #216
  • Opcode #237*p2=3: Puppet Stats, Simulacrum
  • Applies "SIMULACR.SPL"

As of the current patch, this is no longer entirely correct. The clone does not have the ILLUSIONARY gender. In fact, I have a copy of patch 2.5 around as well; the clone does not change gender in either patch 2.5 or patch 2.6. Anyone have older versions they can look at to pin down when the change happened?

It's an easy test; start a fresh mage or sorcerer in ToB with Simulacrum. Cast it. Save. Open up that .SAV and its copy of AR4000, examine the clone. What's its gender?

With Type 3, the saving throw is modified as Type 0 moreover the instant saving throw is also modified.
The "normal" ST is correct but the "instant" ST modifies the save vs. Wands instead of save vs. Death.

A few tests can show this :

1. A character with all ST at 20
2. A spell with two effects

1. First effect is one opcode (between 33 and 37) with type 3 and value to -20.
2. Second effect can be negate by one ST.

The character will have a only one ST at 0 (thanks to the first effect). He can only success against one specific ST and fails all other.

It's pretty simple :

1. If the first effect works and protect against the ST of the second effect, the ST succeeds.
2. Otherwise, the ST fails.

• A simple case : no help : all ST at 20

- Only one effect : no opcode 33-37
- Effect with negate Breath ST

⇒ Expected result : the ST fails
⇒ Result obtained : the ST fails

• A basic case : opcode 36 is adding and protect against the second effect

- Opcode 36 (Breath) : type 3, value -20
- Effect with negate Breath ST

⇒ Expected result : the ST succeeds
⇒ Result obtained : the ST succeeds

• Buggy case : same case but with opcode 33 and Death ST

Now, I change the ST opcode (36 (Breath) ⇒ 33 (Death)).

And I change the ST of the second effect (Breath ⇒ Death).

- Opcode 33 (Death) : type 3, value -20
- Effect with negate Death ST

⇒ Expected result : the ST succeeds
⇒ Result obtained : the ST fails

• WTF case : same case but with Wands ST

Now, I change the ST of the second effect (Death ⇒ Wands).
The opcode 33 (Death) does not change.

- Opcode 33 (Death) : type 3, value -20
- Effect with negate Wands ST

⇒ Expected result : the ST fails
⇒ Result obtained : the ST succeeds

Note : This bug ONLY affects the immediate bonus so it is not visible on the character's screen.

;;;;;	32-bit Windows 5.x BMP	;;;;;
http://www.fileformat.info/format/bmp/egff.htm
https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/ns-wingdi-bitmapv5header
BMP Version 5 (Microsoft Windows 5.x)

Offset	Type	Size	Data	Description	Typical Example From EE
0	WORD	2	FileType	File type, always 4D42h ("BM")	BM
2	DWORD	4	FileSize	Size of the file in bytes	120458
6	WORD	2	Reserved1	Always 0	0
8	WORD	2	Reserved2	Always 0	0
10	DWORD	4	BitmapOffset	Starting position of image data in bytes	138
14	DWORD	4	Size	Size of this header in bytes	124
18	LONG	4	Width	Image width in pixels	160
22	LONG	4	Height	Image height in pixels	188
26	WORD	2	Planes	Number of color planes	1
28	WORD	2	BitsPerPixel	Number of bits per pixel	32
30	DWORD	4	Compression	Compression methods used	3
34	DWORD	4	SizeOfBitmap	Size of bitmap in bytes	120320
38	LONG	4	HorzResolution	Horizontal resolution in pixels per meter	2834
42	LONG	4	VertResolution	Vertical resolution in pixels per meter	2834
46	DWORD	4	ColorsUsed	Number of colors in the image	0
50	DWORD	4	ColorsImportant	Minimum number of important colors	0
54	DWORD	4	RedMask	Mask identifying bits of red component	0x00FF0000
58	DWORD	4	GreenMask	Mask identifying bits of green component	0x0000FF00
62	DWORD	4	BlueMask	Mask identifying bits of blue component	0x000000FF
66	DWORD	4	AlphaMask	Mask identifying bits of alpha component	0xFF000000
70	DWORD	4	CSType	Color space type	1934772034 (sRGB)
74	LONG	4	RedX	X coordinate of red endpoint	0
78	LONG	4	RedY	Y coordinate of red endpoint	0
82	LONG	4	RedZ	Z coordinate of red endpoint	0
86	LONG	4	GreenX	X coordinate of green endpoint	0
90	LONG	4	GreenY	Y coordinate of green endpoint	0
94	LONG	4	GreenZ	Z coordinate of green endpoint	0
98	LONG	4	BlueX	X coordinate of blue endpoint	0
102	LONG	4	BlueY	Y coordinate of blue endpoint	0
106	LONG	4	BlueZ	Z coordinate of blue endpoint	0
110	DWORD	4	GammaRed	Gamma red coordinate scale value	0
114	DWORD	4	GammaGreen	Gamma green coordinate scale value	0
118	DWORD	4	GammaBlue	Gamma blue coordinate scale value	0
122	DWORD	4	Intent	Rendering intent for bitmap	0
126	DWORD	4	ProfileData	Offset to profile data	0
130	DWORD	4	ProfileSize	Size of embedded profile data	0
134	DWORD	4	Reserved3	Always 0	0

It seems that the IESDP could use an improvement to descriptions of Player1-6 and Player1-6Fill. Currently at the top of the page for OBJECT.IDS (EE, BG2, BG1) it says "Static objects (e.g. Player1, Myself) are always bound (and in fact, they always return the same creature)". Down the pages, for Player1 it says either nothing or "Returns the player in the first portrait slot.", and for Player1Fill it's also "Returns the player in the first portrait slot." (no mention in BG1, I suppose it doesn't exist there).

I think it's the "down the pages" descriptions that need a change. From limited tests, PlayerX and PlayerXFill appear to have nothing to do with portraits, they're just references to party members independently from their portrait's position. The PlayerX references point to nothing until a character joins the party and refs with a lower X have already been assigned. Said differently, the character who joins gets the empty PlayerX reference with the lowest value, and keeps it until he leaves. Then whoever joins next takes the spot, unless a lower one has been freed as well.

PlayerXFill is reassigned every time the party changes. It takes the PlayerX list and basically compacts it to the left so there's no hole, i.e. if you have a party of 6 and kick out Player2, Player4 and Player5, then besides the unmovable Player1 remain Player3 and Player6. Player3 will be Player2Fill and Player6 will be Player3Fill.

When one new character joins, he'll get the Player2 reference since it's the lowest empty PlayerX, and the PlayerXFill will be recomputed: He'll be Player2Fill, and now Player3 will be Player3Fill and Player6 will be Player4Fill.

So yeah, it seems that these object references have nothing to do with portraits. Now how to word that in a concise and clear way for the IESDP... ^^

In fact, the minimum maximum hp is fixed: minimum 1hp per level (lvl 6 -> minimum 6, lvl 20 -> minium 20).

Tested on oBG2

Quote

Returns true if the specified object has the specified item in one of its quicklots if it is a weapon, or has it equipped if it is a piece of armour or an amulet etc. This trigger does not work for Melf's Minute Meteors.

If I have an item in a quickslot like a potion or wand, will this check it and return true? The way it is described above makes it seem like quickslots are only detected if it is a weapon.

UseItemAbility(S:Object*,O:Target*,I:Slot*SLOTS,I:Ability*)

The description for UseItem() states:

Quote

This action instructs the active creature to use the specified item (object) on the specified target (target). The ability number (i.e. extended header index) to use may be specified. This action is most often used to allow use of potions and wands. The item to be used must exist in the active creature’s inventory (not in a container within the inventory) - though it need not be equipped.

Is UseItemAbility still applicable, or how do I state the ability number within UseItem()?

I'm not sure if this is worth noting, but... while you can pickpocket items out of the weapon slots, you cannot steal the target's currently selected weapon. E.g. if the target has a sword and bow, and the bow is currently in use, you can steal the sword but not the bow.

I'm running into an interesting issue with the enhanced powergaming scripts where it appears having a response of SetGlobal() will actually cancel out a player queued action. Should setting a global do this? Is there a way to set a global and not have it cancel the player action?

Thank you!

• Parameter2 (Wake on damage?) == 1 -> Maintains splstate DOESNT_AWAKEN_ON_DAMAGE.
• Special (Icon) != 0 -> Maintains splstate PRONE.
• Special == 0 -> Moves creature to the backlist while in effect; this makes the creature invisible to most things that search the area. For example, any sort of Nearest object, object selectors (like [ENEMY]), and some projectiles, (like chain lightning's secondary strikes). This mode is applied when op12 knocks a creature out with STUNNING damage.
• And a minor nitpick: Always maintains STATE_SLEEPING and STATE_HELPLESS, (this is noted at the bottom for certain timing modes, though it does this for all timing modes and all parameter configurations).

There are some oddities in IEDSP found by Rivvers and Selphira...

Quote

- Opcode 1, Type 3 :
IESDP : Only functions when using Timing Modes 2/5/8 (even in SPLs).
... True but...
Its effect is the one of type 1 if from an EFF file (opcode 177, 283) or if timing is 1
Type 3 is not cumulative, if an effect of this type is already in progress, the next one will have no effect...

- Opcode 18, Type 6
IESDP : 6 ⟶ Non-cumulative Modifier: HP = HP + 'Statistic Modifier' value (affects current and max HP) (EE only)
...Observed...
Cumulative, incompatibilities are eventually made with opcode 12, but used directly, its effect is strictly identical to that of type 0, thus cumulative

- For Opcode 42 and 62, Spell Level 512 is missing
It allows to double the number of spell slots exclusively for the spell level specified in Slot Amount Modify

Quote

Opcode 100: Protection: from Creature Type
9 ⟶ KIT.IDS (EE only)
Not configured, no effect

---

Opcode 105: Stat: Gold
0 ⟶ Cumulative Modifier: Gold = Gold + 'Statistic Modifier' value (not for the members of the group)
0 ⟶ Cumulative Modifier: Gold = Gold - 'Statistic Modifier' value (for the members of the group)
Note: Type= 1 0 can only remove gold. Gold amount has a lower bound of 0. (for the members of the group)
The effect modifies GOLD.  =>Only for not the members of the group (otherwise directly modifies the total amount of gold of the group)

---

Opcode 108: Stat: Reputation
4 ⟶ Reset Party Reputation to 100 (only in EEs) Party Reputation = 'Statistic Modifier' value, cannot lower reputation below 100, will raise reputation to 100 if already less (only in EEs)
5 ⟶ ????? (Party Reputation * 'Statistic Modifier' value) / 100, cannot lower reputation below 100, will raise reputation to 100 if already less (only in EEs)

---

Opcode 112: Item: Remove Item
Parameter #1: Irrelevant
If the item is removed from the inventory :
0 ⟶ Play EFF_M02.WAV
1 ⟶ Play AMB_D02B.WAV
2 ⟶ Play Resource2 .WAV
3+ ⟶ No sound

---

Opcodes 153-154-156-157-158
Parameter #2: Mode
Known values for Mode are:
    0 ⟶ Default overlay, "XX.BAM"
    1 ⟶ Custom overlay, Resource field: Animation file (VVC or BAM)
Important: Both parameters should be 0 (zero).

---

Opcode 79: Cure: Disease
Cure feeblemind too, like opcode 77

---

Opcode 178 Spell Effect: THAC0 vs. Creature Type Modifier
Opcode 179 Spell Effect: Damage vs. Creature Type Modifier
9 ⟶ KIT.IDS (EE only)
Not configured, the bonus will affect all creatures regardless of their kit

---

Opcode 213 Spell Effect: Maze
Parameter #1:    Type Irrelevant
Parameter #2:    Irrelevant Type

---

Opcode 217 Spell Effect: Unconsciousness 20HP
Parameter #2:    Irrelevant     Wake on Damage?
Special: ? ? ? Icon
When calling opcode 39, parameters 2 and special are copied. These two parameters have the same function as opcode 39.

If you have any questions or comments, I will pass them on to Selphira and Rivvers, the modders who spotted these issues...

In my testing, a character with PfMW active was able to block opcode 341 and not be dispelled despite what the descriptions above state.