Summon Resists and Fire Golem

[Vornzog]

'Lo Lurkers,

I am in the process of creating a golem/poison/bone-type necromancer, who will probably end up using a fire golem as a tank, curses for monster herding and P&B spells for a bit of direct damage. This seems like a common enough build, but I have found a number of conflicting opinions on one point - Summon Resists.

One school of thought says points here give your golem a better chance of tanking against elemental attackers. The other says that the fire golem will absorb fire damage to heal itself, and pumping resists will inhibit its ability to do this.

Suggestions? Hard evidence from the code? Empirical evidence from playing with a fire golem?

Thanks in advance,
Vornzog

[Baajikiil]

AFAIK, for players at least, % absorb is applied after resistances. Assuming its the same for golems, then higher resists will lower the amount of damage healed for fire damage.

As a player having used firegolems, I've noticed that it is very uncommon to need to to recast the golem while it was fighting fire using enemies, even with points in summon resist.

It seems to need help much more often when fighting LEBs or very powerful melee monsters/act bosses.
The benefit of absorbing more health from fire seems limited vs taking the extra damage from all other elements.

[Vornzog]

'Lo Baajikill,

This is what I was guessing the answer might be. Can anyone confirm that resists/absorbs work in the same order on a golem as they do on players?

Assuming this is the case, what level Summon Resist am I going to need in order to get my golem to tank a standard LEB in nightmare or hell? I don't mind a recast after the battle to refresh golem life, but I don't want a boss to chew through my golem and come for me before I have time to do something about it.

Anyone know what sort of resists a fire golem has by default in each difficulty? Is 1 point in resists and +skill adders going to be enough? Don't assume godly equipment - most of it is out of my reach. It'd only be a few points from +skill adders.

Thanks in advance,
-V-

[Ruvanal]

Anyone know what sort of resists a fire golem has by default in each difficulty?

Fire Golems have a base zero resistance across the board in all difficulties.

[Baajikiil]

Assuming this is the case, what level Summon Resist am I going to need in order to get my golem to tank a standard LEB in nightmare or hell? I don't mind a recast after the battle to refresh golem life, but I don't want a boss to chew through my golem and come for me before I have time to do something about it.

Due to the heavy diminishing returns from summon resist, a standard necro setup with decent + summoning skill should be fine with only a few points in it. Actually even more than LEBs, powerful physical guys seem to be the most dangerous for the golem(minotaurs/any fanat boss/ect...). Also, the LEBs tend to not be so dangerous, because after the tanks that were hitting it(golem/merc/revives) die from the bolts, it doesn't make more bolts till you hit it again. Just watch the life on your golem, and recast *before* it dies, not after.

As for golem durability, golem mastery(more life) will help more than resists usually anyway. Another important factor is the number of players in the game. A necro with only 1 in golem/mastery/resist, will have a tank that lasts a very long time in hell/8 player games.

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.

[Vornzog]

'Lo Baajikill,

First off, thanks Ruvanal - that helps quite a bit.

BO/Oak can easily push your golem to the point that its life overflows.

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.

So what the heck did the programmers do? Are my estimates off? Is the golem life going to be pushed over at least the 32,000 mark in players 8/ hell / BO/ Oak Sage situations? Is there some lower, hard coded cap imposed by a silly programmer somewhere along the line?

Thanks again - this has all been quite helpful.
-V-

[Baajikiil]

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.

Well, you seem to have a pretty good grasp of the concepts, and yes the limit is 16 bit, or 32,767 life on the golem. Anything over that and the life overflows, golems life bar shoots across whole top of screen, and golem dies the next time it gets hit.

Is the golem life going to be pushed over at least the 32,000 mark in players 8/ hell / BO/ Oak Sage situations?

I've personally seen it in as small as a 4 player hell game with both BO and Oak. I understand that in testing this bug others have gotten it in just a 2 player game with very high BO/ golem mastery(must have been really high skill lvls though).

I think it has to do with how the % life increases stack. In hell a fire golem has ~1000 base life. Lvl 25 golem mastery ups this by 500% so now it has ~6000. Then multiply it by the # of players. Finally add BO/Oak and it and it can get rather high.

I'm not sure if my order of operations is exactly correct, but I'm pretty sure that the golem mastery is applied to the base, so all other multiples will work off of the ~6000 life number, not the ~1000 base. You can easily reach 32K with a high lvl golem mastery.

[kandrathe]

Yes. It is a very poor programming practice. I'm a huge stickler for maintaining domain integrity within software. The way that Blizzard should code it is to check for overflow or underflow before the calculation, and if the result is outside the acceptable domain of values, then set the value equal to the max value or min value appropriately. That goes for all stats, skills, etc.

As they add more options for manipulating the values, the opportunity for untested, and unexpected results skyrockets. So if you enforce your domain boundaries, then you should never overflow, and also never get unexpected results from pushing the values beyond the tested ranges.

This is why universities teach programmers courses on numerical methods, yet it is unfortunate that not many programmers paid much attention to them. The only tricky part is to determine whether the overflow or underflow would occur without having to perform the offending calculation. All this stuff is very available in open C++ libraries.

[Vornzog]

'Lo kandrathe and Baajikill

Once again, thanks. That pretty well clears up the whole golem thing for me. No further questions.

As for the mini-rant on domain boundary checks, I agree. I am actually a chemist, but I've had extensive training in math, numerical analysis, programming scientific applications, and a good bit of other disciplines within the realm of computer science, including a bit of game programming and graphics.

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. If Baajikill's formulas are correct, a lvl 25 golem mastery and a 6 player hell game would already push the golem's life to ~36k, well past the 32k limit. And that's before BO/OS bonuses are applied. Even if you don't do explicit checking of domain boundaries, you should at least try a rough min/max calculation by hand to see if your numbers will be reasonable. That applies to any calculation you ever do with a computer, and two minutes with a calculator can save most headaches like this from ever starting.

Thanks all,
-V-

[Vornzog]

'Lo Baajikill,

Just watch the life on your golem, and recast *before* it dies, not after.

I know this - I am talking about the occasional boss pack that is so big and ugly that your fire golem wets itself, extinguishing its own fires, cowers, gets beheaded in 1-2 hits, fails to muster its normal death explosion because it is no longer burning, and leaves a pile of soggy ashes which the boss pack steps in and tracks straight toward your current position, all before you can get of more than a single bone spirit off. *That* is what I want to avoid.

For those packs, I would be happy if my golem could buy me a few seconds - long enough for me to wet myself, turn tail and get the hell out of the way.

<Shivers>

-V-

Edit: Fixed my overly complicated sentence. Maybe I should just copy it over to that contest thread...

[Baajikiil]

I know this - I am talking about the occasional boss pack that is so big and ugly that your fire golem wets itself, extinguishing its own fires, cowers, gets beheaded in 1-2 hits, fails to muster its normal death explosion because it is no longer burning, and leave a pile of soggy ashes which the boss pack steps in and tracks straight toward your current position, all before you can get of more than a single bone spirit off. *That* is what I want to avoid.

Really I think the only times this will happen is when running into a fanat boss pack, or MSLEB. Normal circumstances will leave you plenty of time.

Unfortunately, when the fanat pack also has extra fast, well, you're up the creek without a paddle. I've found that my HC necros have perhaps the easiest time in hell diff do to their standoffish type of play- they rarely are in the thick of things, and rarely in danger. The biggest killer for me has be a second or 2 of desync, while leading my minions around. It has lead to the death of more than one of my necros. Also, act bosses(well diablo and Baal) in hell are often a big pain.

[gekko]

I am talking about the occasional boss pack that is so big and ugly that your fire golem wets itself, extinguishing its own fires, cowers, gets beheaded in 1-2 hits, fails to muster its normal death explosion because it is no longer burning, and leave a pile of soggy ashes which the boss pack steps in and tracks straight toward your current position, all before you can get of more than a single bone spirit off.

My last necromancer had a fire golem with high level golem mastery (~slvl 28 or so, IIRC). I virtually never had problems with my golem dying. True, you're worried about the super nasty boss combos, but with max mastery you'll normally be ok. If you're not planning on using any revives/mages/skells, I would put no points in summon resist. That's the route I took. While your fire golem will be weaker against LEB's and a few of the elemental attackers, the worst elemental attacks usually are fire based; and it's so much fun watching your golem bathe in Diablo's flame river and have his life skyrocket back to full :).

For emergency situations, consider a point in bone wall. Sure, if a boss can chew through your goem in one hit, a bone wall ain't gonna do much better. However, you can rapidly put up a half dozen or so between you and the danger and run the other way. On the few occasions my golem has been slain too quickly for me to recast, this has saved my butt.

In short, points are better spent on golem mastery than in summon resist, particularly if you have only a fire golem (merc doesn't count). As was mentioned before, it's usually not the LEB's or the other elemental attacks that hurt: it's the souped up physical damage boss packs. Summon resist is good in some situations, bad in others; more life for your golem is never a plus (barring the overflow, of course).

gekko

[Occhidiangela]

Dim Vision and Attract do a great deal to slow down the assault of the crazed, extra fast Minotaur packs. Dim Vision first, then pick who you want to Attract and the mob spends some time in a scrum.

Desynch the problem? Ah, aint it the truth! :o

[Baajikiil]

Desynch the problem? Ah, aint it the truth!&nbsp;

I think I still have the screenshot of the minotaurs(2) that killed my last necro standing half a screen away from my corpse. Oh well, so much for leading my minions around.

That necro did so well vs diablo and hell ancients(teamed up with a shock bear for both) that I got too overconfident when lvling him in the ancients way.

[Vornzog]

'Lo gekko,

The bonewall is a good idea - it's already got 1 point + skill adders, but your suggestion may get it moved to a nicer hotkey.

Thanks,
-V-

[Vornzog]

'Lo Occhidiangela,

Dim Vision has indeed saved me a few times, and Attract would be a nice addition. The dim vision wouldn't do much to the unique monster, but an attract might keep it busy with the rest of its pack. Good curse strat suggestion - thanks!

As for desynch - yea, it's a problem - who doesn't have at least one horror story involving it. However, it is less of a problem with this character than it is with say, my current whirly-barb. Whirl into middle of pack of nasty monsters, desynch, recover body, wash-rinse-repeat. Doesn't happen that often, but often enough that I won't play hardcore on bnet. :(

-V-

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

[Baajikiil]

Baajikiil has the wrong amounts for the HP variable.

Heh, I've got to stop trying to say specific things, I'm always wrong :) I had read that this bug involved a 32 bit integer on a forum(not sure where), but I guess that the conclusions were based on speculation, not facts.

Thanks for explaining it.