Jump to content


Photo

IWDEE: File format changes


21 replies to this topic

#1 CamDawg

CamDawg

    Seven billion ton robot monster

  • Gibberling Poobah
  • 9110 posts
  • Gender:Not Telling

Posted 30 October 2014 - 10:42 AM

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


 


I came here with a simple dream: a dream of killing all humans. And this is how it must end? Who's the real seven billion ton robot monster here? Not I. Not... I.


#2 argent77

argent77
  • Modders
  • 647 posts
  • Gender:Male

Posted 31 October 2014 - 01:40 AM

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).
 



#3 Avenger

Avenger
  • Modders
  • 3681 posts
  • Gender:Male
  • Location:Hungary

Posted 31 October 2014 - 08:01 AM

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.


Edited by Avenger, 31 October 2014 - 08:01 AM.


#4 argent77

argent77
  • Modders
  • 647 posts
  • Gender:Male

Posted 14 November 2014 - 09:01 AM

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?


Edited by argent77, 14 November 2014 - 09:22 AM.


#5 Avenger

Avenger
  • Modders
  • 3681 posts
  • Gender:Male
  • Location:Hungary

Posted 14 November 2014 - 10:42 AM

Those are unused fields remaining from the original data files.

 

Spoiler

Edited by Avenger, 14 November 2014 - 10:45 AM.


#6 argent77

argent77
  • Modders
  • 647 posts
  • Gender:Male

Posted 15 November 2014 - 12:36 PM

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?


Edited by argent77, 15 November 2014 - 12:45 PM.


#7 Avenger

Avenger
  • Modders
  • 3681 posts
  • Gender:Male
  • Location:Hungary

Posted 16 November 2014 - 04:58 AM

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:

Spoiler

 

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


Edited by Avenger, 16 November 2014 - 05:03 AM.


#8 Galactygon

Galactygon

    Nostradoctopus

  • Modders
  • 722 posts
  • Gender:Male
  • Location:Sweden

Posted 21 December 2014 - 12:45 AM

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.

Attached Thumbnails

  • prjscattering.jpg

Posted Image

Posted Image

#9 argent77

argent77
  • Modders
  • 647 posts
  • Gender:Male

Posted 09 October 2015 - 07:13 AM

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.



#10 Avenger

Avenger
  • Modders
  • 3681 posts
  • Gender:Male
  • Location:Hungary

Posted 10 October 2015 - 11:27 AM

Yes, it is the width of the path of swave.



#11 Galactygon

Galactygon

    Nostradoctopus

  • Modders
  • 722 posts
  • Gender:Male
  • Location:Sweden

Posted 21 December 2016 - 03:28 AM

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.


Edited by Galactygon, 23 December 2016 - 02:49 AM.

Posted Image

Posted Image

#12 Avenger

Avenger
  • Modders
  • 3681 posts
  • Gender:Male
  • Location:Hungary

Posted 22 December 2016 - 02:44 AM

"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 ?



#13 Galactygon

Galactygon

    Nostradoctopus

  • Modders
  • 722 posts
  • Gender:Male
  • Location:Sweden

Posted 23 December 2016 - 02:57 AM

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.


Posted Image

Posted Image

#14 Avenger

Avenger
  • Modders
  • 3681 posts
  • Gender:Male
  • Location:Hungary

Posted 24 December 2016 - 05:55 AM

Row 1 in splprot.2da excludes undead from the effects of the spell targeted by opcode 318/324.  (So, only non undead are affected)

Opcode 326 would place effects on undead.


Edited by Avenger, 24 December 2016 - 05:56 AM.


#15 Galactygon

Galactygon

    Nostradoctopus

  • Modders
  • 722 posts
  • Gender:Male
  • Location:Sweden

Posted 25 December 2016 - 06:58 AM

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


Edited by Galactygon, 25 December 2016 - 09:03 AM.

Posted Image

Posted Image



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users