File format changes in 2.6

[Galactygon]

OPCODES

#12 (0xC) HP: Damage

The flags defined in the "Special" field have received an update:

• Bit 0 ⟶ Drain HP to caster (cumulative)
• Bit 1 ⟶ As bit 0 but caster and target are reversed (cumulative)
• Bit 3 ⟶ Drain HP to caster (non-cumulative)
• Bit 4 ⟶ As bit 3 but caster and target are reversed (non-cumulative)
• Bit 6 ⟶ Damage inflicted is limited to amount available by target (checks stat MINHITPOINTS and works in reverse if bits 1 or 4 are set)
• Bit 7 ⟶ Damage inflicted is limited to the caster's MAXHITPOINTS minus CURRENTHP (works in reverse if bits 1 or 4 are set)
• rest of the bits not mentioned here are unchanged
• NOTE: Bits 0, 1, 3, and 4 are mutually exclusive, while bits 6 and 7 do not require any of the HP drain bits to be set to function. 

In all cases, HP drain now only increases maximum HP if the character is at full health and there are extra HP remaining from the drain, which can happen even during the drain. Current HP gained is always cumulative (bits 0,1,3,4) if the caster is injured. Extra HP gained by non-cumulative HP drain (bits 3,4) may still coexist on the same creature. This means that the caster can still benefit from lower HP drain if the effect expires later than the higher HP drain effect.

Example: The caster at 3/4 HP can increase his/her HP to 7/7 with one casting of Larloch's Minor Drain (if 4 is rolled) and 8/8 with another casting if 4 is rolled again, otherwise nothing seems to happen despite the damage inflicted. The caster may further benefit with additional castings if injured, but cannot go beyond 8/8 hp. This all assumes there is sufficient HP to drain (since bit 6 is now set in SPWI119.spl).

Extra maximum HP effects carried on the .cre now have their mschool, msectype, resource, resist dispel, dispel level etc properly set (fixed in 2.6). See below for how non-cumulative HP gain is stored.

#18 (0x12) HP: Maximum HP Modifier

• To differentiate non-cumulative HP gain from other forms of HP gain, parameter2 is set internally to 6. As mentioned previously, multiple effects of param2=6 can be carried by the creature at the same time and only the largest value is used when calculating extra HP. Hence the term "noncumulative coexisting". This functionality doesn't interact with other forms (param2 != 6) of HP gain, and cumulative HP drain doesn't use param2=6. 
• The issue where Dice values generate extra HP has now been fixed.

#61 (0x3D) Creature RGB color fade

This opcode has been fixed to behave as it did in original IWD. The creature will instantly be covered by a color overlay which then fades out. The color overlay will not fade back in. It's otherwise similar to opcode 50, where the color overlay fades onto the creature and then fades back out.

#243 (0xF3) Item: Drain Item Charges

You can drain charges of a particular item if the resource field is used.

#324 (0x144) Protection: Immunity to Resource and Message

The name of the correct resource is displayed instead of the name of the resource the effect instance is located in. It now works as intended in 2.6.

New smart feature: It will attempt to identify the name of the parent spell if this effect is located in a child spell with no valid name. It does in the following manner: if the effect is used within a spell that has no name but there is a spell in the game who's resname is one character shorter with a valid name, then it will display that name. This feature is used by Sunfire (SPWI523D.spl) in IWD:EE to check for thief evasion.

This feature will also attempt to look for an identical resname.itm and display that (identified/unidentified) if the .spl the effect is in doesn't have a valid name.

PROJECTILE FILE FORMAT

DWORD at 0x02c (Extended flags - Bit 1 ⟶ Pass target)

Fixed an issue where projectile would target the same creatures several times. The projectile targets each creature only once unless Bit 0 is set (bounce from walls) at which point during the bounce, the targets are cleared and the projectile can target previously hit creatures once more (as expected).

DWORD at 0x200 (Area of effect flags - Bit 11 ⟶ Cone Area of Effect) & WORD at 0x202 (Ray Count)

When the Ray Count (WORD at 0x202) is nonzero, the explosion is suppressed and rays are generated instead. Setting the "Cone Area of Effect" bit will cause the rays to spawn at the location of the caster. If this bit is not set and the Ray Count is nonzero, then the rays will spawn at the location of the explosion of the projectile.

The direction of the first ray is no longer fixed towards the southeast but is determined as follows: 1.) if the cone bit is disabled the first ray will continue in the same direction as the parent projectile using a vector of the caster's location to the explosion point 2.) if the cone bit is enabled the first ray will travel from the caster's position towards the destination/casting point. Further rays as generated based on how cone angle/angle between rays (WORD at 0x224) is set, see below.

In 2.6, you may nest rays in one another to construct complex-shaped areas of effect. In terms of nesting multiple rays, the point of origin of the ray one higher up the "chain" is treated as the caster's position.

WORD at 0x206 (Explosion size)

The function of this is unchanged in 2.6 when Ray Count is nonzero. This explanation is nonetheless informative to understanding the Ray feature:

The distance defined in the explosion defines how far the ray travels. For lightning bolt-type projectiles, this distance is used up, even as the bolt bounces (see LIGHTB.pro in BG1/2:EE and IDPRO40.pro in IWD:EE as examples). For single,-target projectiles, they simply travel that distance before disappearing. For area-of-effect projectiles (i.e. FIREBALL.pro), they explode normally when reaching that distance. And as mentioned earlier, area-of-effect child projectiles can also use the ray feature themselves to generate additional rays with the direction vector determined as mentioned above.

WORD at 0x224 (cone angle/angle between rays)

When the Ray Count is nonzero, this will generate additional rays relative to the initial direction of the first ray. They will be generated on alternating sides of the first ray at angle increments set by this field. For example, if "Ray Count" is set to 5 and this field is set to 45, then rays will be generated at angles -90,-45,0,45,90 degrees relative to the direction vector as described above. Note that if Ray Count is an even number, the ray group will be asymmetrical unless you rotate them, see below. In Spiritual Wrath's case (IDPRO312.pro in IWD:EE), there are 4 rays at 90 degree angles from one another, making them appear symmetrical.

WORD at 0x226 (rotate rays clockwise)

Setting this field (0-359) will rotate the entire ray group clockwise. Note: it's been mentioned erroneously that it's counterclockwise but it's actually clockwise, sorry for the mistake!

No projectile in the unmodded game uses this field.

Edited April 25, 2021 by Galactygon

[Luke]

@Galactygon

Thanks for sharing!

OK, this is not strictly related to v2.6, but still somewhat obscure (at least for me).

Could you please provide additional details about opcodes #245 (0xF5) Check For Berserk and #246 (0xF6) Spell Effect: Berserking ?

What do they do exactly aside from setting STATs CHECKFORBERSERK and BERSERKSTAGE1?

Edited April 23, 2021 by Luke

[Galactygon]

Edited the first post for clarity (jumbled opcode "special" bits 3,4,6,7, sorry!). Bits 6 and 7 function independently of any drain bits (0,1,3,4) but are often used together to achieve desired HP drain behavior. Bit7 in conjunction with bit1 is used in IWD:EE/SoD's "Shadow Pact" ability for shadows to prevent them from inflicting more damage on reverse HP drain than necessary to heal them to normal max HP.

@Luke

It appears as though opcode 245 is meant to apply BERSERKSTAGE1 on a hardcoded 1% chance on each hit for a certain duration but I'm unable to reproduce this behavior after hundreds of hits. Maybe there's a mistake in the code or I've been unlucky with the random number generator? Let me check with the programming team next week.

[kjeron]

Not necessarily new to v2.6, but became relevant with v2.6:

Opcode 111 cannot utilize timing mode 4096, treating it as timing mode 0 or 10 instead (didn't determine which, but it doesn't really matter).

Presently, in order to replicate timing mode 4096, set opcode 111 to use timing mode 1, and apply opcode 112 (for the same item) with timing mode 7, for the same duration you would have used with timing mode 4096.

Edited May 12, 2021 by kjeron

[Luke]

On 4/25/2021 at 6:33 PM, Galactygon said:

Let me check with the programming team next week.

You might want to check opcode #293 (0x125) Script: Enable Offscreen AI too.

It is attached to a lot of CRE files (in particular SoD CRE files), but its functionality is unknown.

I mean, creatures run scripts as long as they are in the current area, opcode #293 does not alter this, nor allow their scripts to run while they are in different areas...

[argent77]

1 hour ago, Luke said:

You might want to check opcode #293 (0x125) Script: Enable Offscreen AI too.

It is attached to a lot of CRE files (in particular SoD CRE files), but its functionality is unknown.

I mean, creatures run scripts as long as they are in the current area, opcode #293 does not alter this, nor allow their scripts to run while they are in different areas...

The name is a bit misleading. It's true that creature will always run scripts even if off-screen (at least in the EE games). However, creatures without this opcode attached will run scripts at a considerably slower rate (about 1/3rd or 1/4th rate).

Moreover, it looks like off-screen creatures move only at halved speed (which might be true for other actions as well). With this opcode creatures seem to move and act at the same speed as on-screen.

[Luke]

23 hours ago, argent77 said:

With this opcode creatures seem to move and act at the same speed as on-screen.

That's interesting, thanks for pointing it out.

I can now see why it is attached to almost all NPCs (only SoD though, probably because the AI has been rewritten from scratch there...)

Edited May 1, 2021 by Luke

[lynx]

Thanks to Luke, this is now on IESDP (as soon as the build finishes).

[Luke]

@Galactygon

Forgot to mention there's an issue with the new human-friendly identifiers (1PP_*) in "MISSILE.IDS".

Further details are available here.

Since it's unclear if WeiDU's IDS lexer is ever able to parse the "+" character, you might want to either contact @Wisp or remove that character from future releases...

Edited June 5, 2021 by Luke

[Galactygon]

Thanks, reported in PP even if he already knows.