Summon Resists and Fire Golem

[Ruvanal]

Do you know what the overflow point is?  Assuming the golem life total is stored in an integer, 8 bits would get you 127 (signed) or 255 (unsigned) life, which is clearly too small.  16 bits would get you 32,767 or 65,535 life, which seems quite large, even with OS and BO factored in.  From a programming perspective, I don't really see any reason to use anything except a 16 bit (or 32 bit) unsigned integer if it is available.  No one is so desperate to save space as to manipulate individual bits on a game like this anymore.

The Tao of Poison on diabloii.net makes reference to 'bite damage' - a reference to the fact that there is apparently 1 byte = 256 subdivisions of a hit point.  This suggests to me that life would be stored in a separate 16 bit unsigned int or the whole thing would be stored in a 32 bit int and the low order byte shifted off to find the 'bite' total leaving 24 bits (probably unsigned).  But that's back to manipulating individual bits, and I don't know why they would be doing that.

Baajikiil has the wrong amounts for the HP variable. Life (and a few of the other stats) is stored as a signed DWORD, with lowest byte for the fractional part of a hit point. The signed part is because the same varible is what is used at for anything in the game that pertains to the life varible, even an item that could have a negative life value. The game will just total all of these factors up from the different sources to get the final value.

The overflow point is actually being hit at an intermediate step in the calculations. See my replys in these threads for where it is happening.
http://www.lurkerlounge.com/forums/index.p...t=ST&f=9&t=1061

http://www.theamazonbasin.com/d2/forums/in...ST&f=53&t=27336

Just be careful if playing in high player count games with a druid or barb. BO/Oak can easily push your golem to the point that its life overflows.

As I said in the AB thread,

Ease up some on the Barbs and Druids, they may be providing the "straw that breaks the back", but it is the summoner that did the overloading in the first place.

Vornzoq:

In most of the stuff I do, an integer overflow is the stupidest, easiest, most untraceable mistake you can make. This is one Blizzard should have checked.

They did do this in some spot, but not enough. There is a check for this overflow at the time of teh monsters creation when the player scaling factor is done, but there is not a check when the game applies the MAXHP_PERCENT property as it can be changing at later points in the game (as of version 1.09). Isolde had posted some at the Phrozen Keep that he had been adding some additional 'sanity checks' for things like this for the v1.10 game, but it is not known if he managed to get one put in for this step in the game calculations. Considering some of the things that I have seen that he did address, I would guess that it did get fixed though.

Not listed in the other threads is the Hp scaling factor for the number of players in the game. It is not a straight linear factor as many seem to think.


PlayersX_____HP______EXP
1____________100_____100
2____________200_____175
3____________300_____250
4____________375_____325
5____________450_____375
6____________525_____400
7____________575_____425
8____________625_____450

edit: fixed a badly parsed url.