CamDawg Posted October 30, 2014 Share Posted October 30, 2014 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 flags0x34 - m_color - the rgb color value for 0x8000000x38 - m_colorSpeed - the color speed value for 0x8000000x3a - m_shake - the screen shake parameter, if non zero, it shakes the screen by the amount0x3c - ids1 value0x3e - ids1 type0x40 - ids2 value0x42 - ids2 type0x44 - default/fail spell, add it to non matching ids)0x4c - success spell (add it to all normally affected target) 0x228 - spread animation0x230 - ring animation0x238 - area sound0x240 - 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 targets0x246 - dice size for multiple targets0x248 - area animation granularity (large numbers mean fewer animations)0x24a - area animation granularity divider Link to comment
argent77 Posted October 31, 2014 Share Posted October 31, 2014 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 comment
Avenger Posted October 31, 2014 Share Posted October 31, 2014 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 comment
argent77 Posted November 14, 2014 Share Posted November 14, 2014 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 comment
Avenger Posted November 14, 2014 Share Posted November 14, 2014 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 comment
argent77 Posted November 15, 2014 Share Posted November 15, 2014 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 comment
Avenger Posted November 16, 2014 Share Posted November 16, 2014 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 comment
Galactygon Posted December 21, 2014 Share Posted December 21, 2014 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. Link to comment
argent77 Posted October 9, 2015 Share Posted October 9, 2015 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 comment
Avenger Posted October 10, 2015 Share Posted October 10, 2015 Yes, it is the width of the path of swave. Link to comment
Galactygon Posted December 21, 2016 Share Posted December 21, 2016 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 type0x40 - ids2 value0x42 - 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 comment
Avenger Posted December 22, 2016 Share Posted December 22, 2016 "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 comment
Galactygon Posted December 23, 2016 Share Posted December 23, 2016 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 comment
Avenger Posted December 24, 2016 Share Posted December 24, 2016 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. Link to comment
Galactygon Posted December 25, 2016 Share Posted December 25, 2016 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 comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.