Jump to content

0xc Damage - 0xb3 Damage vs. Type


Demivrgvs

Recommended Posts

After some tests it seems that Dice Size and Dice Thrown are ignored. The only damage correctly applied is the fixed damage in the parameter 3. Could someone confirm it? If it so weapons like Daystar, Dragonslayer, MoD, etc. has to be fixed/changed.

Daystar uses the effect EVILDAM2.EFF to do the +2 damage to evil creatures.

Why would that need to change?

 

Now, changing it to do DOUBLE damage to evil... an additional 1d8+2...

And to make the situation clear, we'l set it normal damage to 1d1.

OK, properly does 4 damage (1+2 +1 str) vs Gnoll, nuetral.

Yes, against a Chaotic Evil Mage (_Sakul) it improperly does only 6 damage.

 

Dragonslayer, which is supposed to do 1d8+2 extra vs. dragons, would be affected.

Mace of Disruption, which is supposed to do 1d6+2 extra vs. undead, would be affected.

 

Quick fix: change the effet to do the average of the dice+ bonus, and call it a day. So, 7 for dragon slayer, 6 for MACEDISR.EFF

Link to comment
Daystar uses the effect EVILDAM2.EFF to do the +2 damage to evil creatures.

Why would that need to change?

That effect don't need to be changed indeed, effects that adds fixed damage values work as they should.

 

Azuredge, Daystar, Dragonslayer, MoD have effects that are supposed to add damage via dice rolls and they don't work in my tests.

Link to comment

Only long enough to verify that items with correctly targeted .effs do bonus damage ;)

 

I'll look into it again though. Bear in mind that staggered probabilities do not work at all well in general, so it might not be the best of ideas to fix-to-description if it turns out that only constants work here.

 

Usually when the dice fields are used while calling external effects they control level limits - is that what you're seeing, or something else?

Link to comment

Adventure with us in the wastepaper basket!

COPY_EXISTING daystar1.eff override
 WRITE_LONG 0x1c 0x00
 WRITE_LONG 0x20 0x02
 WRITE_LONG 0x38 0x14
 WRITE_LONG 0x3c 0x14
COPY_EXISTING sw1h31.itm override
 READ_LONG   0x64 ho
 READ_SHORT  0x68 hc
 READ_LONG   0x6a eo
 READ_SHORT  0x70 gc
 WRITE_SHORT 0x70 gc + 0x10
 FOR (i = 0x00; i < gc * 0x30; i += 0x30) BEGIN
READ_ASCII eo + i + 0x14 r
PATCH_IF ~%r%~ STRING_EQUAL_CASE ~daystar1~ THEN BEGIN
  READ_ASCII eo + i e (0x30)
  SET i = gc * 0x30
END
 END
 INSERT_BYTES eo + 0x30 * gc 0x300
 FOR (i = gc * 0x30; i < gc * 0x30 + 0x300; i += 0x30) BEGIN
WRITE_ASCIIE eo + i ~%e%~
 END
 FOR (i = 0x00; i < hc * 0x38; i += 0x38) BEGIN
READ_SHORT  ho + i + 0x20 ei
WRITE_SHORT ho + i + 0x20 ei + 0x10
 END

 

It's still +4.

Link to comment
Demivrgvs, the next thing you discover? Please make it cool, or something that never seemed to work that magically does. It's difficult to even get irritated with this rubbish anymore ;)
Sorry i don't understand if this means i'm stupid and there's no such bug or else you are irritaded because you can confirm what i've (unfortunately) discovered. ;)
Link to comment

It means your discovery is just one more on the pile of things that are hopelessly broken with the engine. Understandably, we're not too thrilled to discover that yet another piece of shit behavior exists.

 

You're in the clear, as long as you don't discover that, like, EFF files don't work at all or something. ;)

Link to comment
It means your discovery is just one more on the pile of things that are hopelessly broken with the engine. Understandably, we're not too thrilled to discover that yet another piece of shit behavior exists.
I'm ;) too...it's incredible how this bug managed to survive multiple game releases and patches!!
Link to comment

Archived

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

×
×
  • Create New...