Jump to content

IWDEE: File format changes


CamDawg

Recommended Posts

Additional item flags:

 

Header flags at 0x18

  • BIT13 - item disables the off-hand weapon, but not a shield
  • BIT24 - item cannot be dispelled when it's in the magical weapon slot

Extension header flags 0x26

  • BIT2 - apply strength bonus to damage only
  • BIT3 - apply strength bonus to THAC0 only

Feature block flags at 0x24

  • BIT10 - ignore primary (IWDEE Agannazar's Scorcher)
  • BIT11 - ignore secondary (IWDEE Agannazar's Scorcher)
  • BIT24 - bypass mirror image (opcode 12 only)
  • BIT25 - ignore damage reduction/increase caused by the game difficulty level (opcode 12 only)

Additional spell flags

 

Header flags at 0x18

  • BIT14 - disable wild surges and miscast magic from affecting the spell
  • BIT15 - disable only wild surges from affecting the spell
  • BIT25 - spell can be cast even when the caster is silenced

Feature block flags at 0x24

  • BIT10 - ignore primary (IWDEE Agannazar's Scorcher)
  • BIT11 - ignore secondary (IWDEE Agannazar's Scorcher)
  • BIT24 - bypass mirror image (opcode 12 only)
  • BIT25 - ignore damage reduction/increase caused by the game difficulty level (opcode 12 only)

Additional store flags

 

Header flags at 0x10

  • BIT13 - store prices are not affected by bonuses/penalties from reputation
  • BIT15 - store will buy items marked as plot critical

Projectiles

Projectiles definitely had the most work to bring in all of IWD's spell goodness. What follow is essentially a data dump from Avenger:

 

0x2c - extended flags

  • 1 - implemented, example lightb.pro - projectile bounces from walls
  • 2 - implemented, example lightnb.pro - projectile continues through target until hits wall
  • 4 - implemented - draws center vvc only once
  • 8 - implemented, example cgabjura.pro - projectile immediately hits (pillars, spellhits, casting glow, AOE without travel, etc)
  • 16 - implemented, example womoon.pro - trail puff and central VVC parts face target
  • 32 - implemented, example mfmiss2.pro - curved path, like force projectiles, magic missile, etc
  • 64 - implemented - projectile starts from random frame (also AOE parts)
  • 128 - implemented, example fstrikh.pro - pillar type projectile (like flame strike center)
  • 256 - not implemented yet - trail puff VEF parts have the half-transparent flag set (when created from BAM)
  • 512 - not implemented yet - trail puff VEF parts are tinted (when created from BAM)
  • 1024 - implemented, example mfmiss2.pro - create multiple projectiles (like magic missiles or lightning chains)
  • 2048 - not implemented yet - applies the default spell on missed targets
  • 4096 - not implemented yet - falling path, like cow and comet
  • 8192 - not implemented yet - set for comet (m_sideMove)
  • 0x4000 - implemented, example idpro109.pro - line (Scorcher) area of effect
  • 0x8000 - implemented, example womoon.pro - wall/rectangle area of effect
  • 0x10000 - not implemented yet - draw behind target, but not on vertlistback (VEF part has a -1 Z pos)
  • 0x20000 - implemented, example cgabjura.pro - used for Casting Glow POP in / HOLD / OUT sequencing
  • 0x40000 - not implemented yet - used for TravelDoor (Draw only the shadow now, then switch back, but set normal anim to reverse play
  • 0x80000 - not implemented yet - After hit, stop moving, fade out slowly
  • 0x100000 - implemented, example idpro282 - Display m_strRef on hit (beetle cloud)
  • 0x200000 - implemented, example whirlw.pro - random path, IWD WhirlWind projectile
  • 0x400000 - implemented - projectile (and fireball temporals) start at random Sequence
  • 0x800000 - implemented - use the rgb color fields to create a pulse effect on hit
  • 0x1000000 - not implemented - touch projectile (needs a successful hit)
  • 0x2000000 - implemented - negate IDS1
  • 0x4000000 - implemented - negate IDS2
  • 0x8000000 - implemented - both IDS matching should succeed, otherwise one is enough
  • 0x10000000 - not implemented - payload is delayed (meaningful only for BAM projectiles that didn't support this feature)
  • 0x20000000 - implemented - pathcount is limited (m_bDuration set true)
  • 0x40000000 - implemented, example idmold - use IWD style spell protection check (IDS fields)
  • 0x80000000 - implemented, example idpro299.pro - the original caster should be affected multiple times (soul eater)

0x30 - m_strRef - the string to be printed if 0x100000 was set in extended flags
0x34 - m_color - the rgb color value for 0x800000
0x38 - m_colorSpeed - the color speed value for 0x800000
0x3a - m_shake - the screen shake parameter, if non zero, it shakes the screen by the amount
0x3c - ids1 value
0x3e - ids1 type
0x40 - ids2 value
0x42 - ids2 type
0x44 - default/fail spell, add it to non matching ids)
0x4c - success spell (add it to all normally affected target)

0x228 - spread animation
0x230 - ring animation
0x238 - area sound
0x240 - area extended flags

  • 1 - paletted ring animation
  • 2 - random speed
  • 4 - start scattered
  • 8 - paletted center
  • 16 - repeated scattering (at every explosion)
  • 32 - paletted area animation
  • 0x200 - oriented fireball puffs (used by cone projectiles to orient the ring sprites in their traveling direction)
  • 0x400 - hd count use hit dice lookup table instead of simple target counting
  • 0x2000 - blend flag for area/ring animations
  • 0x4000 - glow flag for area/ring animations

0x244 - dice count for multiple targets
0x246 - dice size for multiple targets
0x248 - area animation granularity (large numbers mean fewer animations)
0x24a - area animation granularity divider


Link to post

The changes, especially to the PRO resource format, are impressive. I've got a question to the IDS entries in the PRO resource type though.

 

In contrast to effect opcodes, they're only using 2 bytes for each IDS types and values. Are they encoded the same way as their effect opcode counterpart (i.e. IDS type: 2=EA.IDS, 3=GENERAL.IDS, 4=RACE.IDS, 5=CLASS.IDS, 6=SPECIFIC.IDS, 7=GENDER.IDS, 8=ALIGN.IDS)? From a quick glance in NI I have found a couple of IDS types that aren't compatible with the afore-mentioned order (for example: HOLDNECR.PRO uses type=1, value=0 for IDS1).

Link to post

The changes, especially to the PRO resource format, are impressive. I've got a question to the IDS entries in the PRO resource type though.

 

In contrast to effect opcodes, they're only using 2 bytes for each IDS types and values. Are they encoded the same way as their effect opcode counterpart (i.e. IDS type: 2=EA.IDS, 3=GENERAL.IDS, 4=RACE.IDS, 5=CLASS.IDS, 6=SPECIFIC.IDS, 7=GENDER.IDS, 8=ALIGN.IDS)? From a quick glance in NI I have found a couple of IDS types that aren't compatible with the afore-mentioned order (for example: HOLDNECR.PRO uses type=1, value=0 for IDS1).

 

 

This depends on:

0x40000000 - use IWD style spell protection check (IDS fields)

If the bit is unchecked, we use the old IDS targeting. If it is set, we go full IWD style. (which itself can simulate the old ids targeting, actually). HoldNecr surely has the abovementioned bit set.

Link to post

I've seen many CRE resources in IWD:EE containing data at offsets 0x76 to 0x7e (e.g. APSEL.CRE, ARUNDEL.CRE and many more). IESDP describes them as unknown proficiencies in the old BG1 style. But that information may be outdated since BGEE already uses some of the fields differently (maybe leftover data from original IWD1?). Does anyone know more about it?

Link to post

Those are unused fields remaining from the original data files.

 

 

 

 

006eh BG1 Weapon 00
006fh BG1 Weapon 00
0070h BG1 Weapon 00
0071h BG1 Weapon 00
0072h BG1 Weapon 00
0073h BG1 Weapon 00
0074h BG1 Weapon 00
0075h BG1 Weapon 00
0076h UNKNOWN 00
0077h UNKNOWN 01
0078h UNKNOWN 00
0079h UNKNOWN 01
007ah UNKNOWN 01
007bh UNKNOWN 01
007ch UNKNOWN 00
007dh Nightmare 00
007eh Translucent 00
007fh Kill rep. 00
0080h Join rep. 00
0081h Kick rep. 00
0082h UndeadLevel 00
0083h Tracking 00

 

 

Link to post

I've also noticed that region structures in ARE resources are storing data at offsets 0x88 and 0x8c. From what I've seen, they're always the same values as the operating points at offsets 0x84 and 0x86. Is this also a result of the resource conversion between IWD1 and IWDEE, as IWD1 uses override points and alternate points at the same offsets (although they usually don't use identical values), or is it something else entirely?

Link to post

Yes, IWD uses that offset for the very same function (Use point). The converter didn't wipe out the original value, just copied it a few bytes away. I don't know why they wouldn't be the same values, though.

Ar5302:

 

 

055ch Region #1
055ch Label To5301
057ch Type 0002
057eh Left 0151
0580h Top 0384
0582h Right 023c
0584h Bottom 0427
0586h Vertex count 000b
0588h Vertex index 00000000
058ch UNKNOWN 00000000
0590h Cursor type 0000001c
0594h Dest. area AR5301
059ch Dest. entrance FR5302
05bch Info flags 00000404
05c0h Strref ffffffff
05c4h Trap detection 0000
05c6h Trap removal 0000
05c8h Trapped 0000
05cah Detected 0000
05cch Launch point [01cb.03ef]
05d0h Key
05d8h Script
05e0h Use point [01cb.03f4]
05e4h UNKNOWN 000001cb
05e8h UNKNOWN 000003f4

 

 

 

[edit] ahh, you also said, they are the same values :)

Link to post

I've been playing around with the new .pro format and noticed some things:

 

I wasn't able to get the repeated scattering flag at 0x240 to work. Even with that set and multiple explosions, the ring only appears once in the beginning. The delayed explosions still happen and the spell effects are still applied several times.

 

It seems IWD(non-EE) uses a more random value at random scattering (equivalent to the EE's "2 - random speed" flag at 0x240) for projectiles such as cone of cold or prismatic spray. Either that, or they have multiple delayed explosion rings which when combined with the random scattering flag can give projectiles a more cone-like shape. See attached image highlighting the difference between original IWD and EE.

 

Seems as though the only way I could get this to work is to use a repeating explosion combined with a secondary projectile which has the downsides that spell effects are applied repeatedly rather than once and involves two projectiles added to the projectl.ids. See bottommost screenshot in the image.

post-90-0-81311000-1419151787_thumb.jpg

Link to post

PRO resources contain a word-sized field at offset 0x2a, which is labeled as "Lance width" in DLTCEP's GemRB extension for PRO resources. Is this field supported in IWD:EE as well? I've seen SWAVE.PRO using a non-zero value at this offset.

Link to post

Update on extended flags in the .pro file:

 

bit10 of 0x240 marked as "Use hit dice lookup" uses a points system when determining which creatures are affected by the area of effect. IDPRO267.pro in IWDEE is the only projectile that uses this bit. The points system functions like AD&D's death spell (see description here). The points are as follows: level0/1 creatures are assigned 1 point, levels 2-4 are assigned 2 points, levels 5-6 are assigned 10 points, levels 7-8 are assigned 20 points, and levels 9+ are never targeted. This behavior is hardcoded regardless of what die values are given in fields 0x244 and 0x246. IDPRO267.pro has these values set to 4 and 20, so 4d20 points are rolled to determine who is affected, which matches AD&D's/IWDEE's Death Spell.

 

Also note that using this bit will prevent the following fields from functioning:

 


0x3c - ids1 value

0x3e - ids1 type
0x40 - ids2 value
0x42 - ids2 type

 

This means that you cannot exclude certain creatures from being counted in the area of effect (i.e. Undead) or use SPLPROT.2da for the points limit rolled for the area of effect.

 

EDIT: My bad, SPLPROT.2da can be used in conjunction with hit dice limits.

Link to post

"note that using this bit will prevent the following fields from functioning"

 

Well, it is not supposed to ignore the ids targeting fields. When i look at the code, it seems the ids checks are before the hd checks. Are you sure this is true ?

Link to post

Update on this: I was able to exclude Undead from being counted by using row 1 from SPLPROT.2da (which is the "affects only undead" row). However excluding normal ids values instead of SPLPROT.2da (i.e. using 3-General and 4-Undead) does not work when I set the "Use Hit Dice" bit. So I have to resort purely to using SPLPROT.2da which is fine I guess, since you can do the same plus more with SPLPROT.2da.

 

It's somewhat counterintuitive that the IDS/SPLPROT fields in the .pro are negative (i.e. to exclude Undead, use row 1 "undead only" of SPLPROT.2da) so I was thrown off a bit.

Link to post

Yes that is true. What I was implying is that in order to prevent undead from being counted in the area of effect one either has to do the following for SPLPROT.2da:

  • Use row 2 (undead only) while setting bit30 (use SPLPROT.2da) at 0x2c. .pro explosions handle values in a negative manner so this results in "undead only" from being excluded.
  • Use row 1 (not undead) while setting BOTH bit30 (use SPLPROT.2da) and bit25 (negate field1). This becomes a double negative (i.e. "not undead" are not not affected = not undead are affected).

This becomes even trickier when one uses both SPLPROT/IDS fields and sets bit27 of 0x2c (both checks must pass). In that case both SPLPROT/IDS fields are independently evaluated - one of them or both of them can be double negatives depending on whether bit25 for field1 and bit26 for field2 are set. Both of those results must then be able to affect the target creature for it to be counted in the area of effect

Link to post

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...