pStun on randarts?

[AnonymousHero]

Having done quite a lot of experiments, it seems to be the case that pStun cannot be generated on randarts that are not body armor. Is this intentional or a bug?

In any case, it seems rather strange considering that the only standart which has pStun is a crown.

EDIT: Oh, yeah, this is current 'master' if it matters.

[Magnate]

Having done quite a lot of experiments, it seems to be the case that pStun cannot be generated on randarts that are not body armor. Is this intentional or a bug?

In any case, it seems rather strange considering that the only standart which has pStun is a crown.

EDIT: Oh, yeah, this is current 'master' if it matters.

What sort of experiments? Do you just mean generating a lot of randart sets, or something else?

AFAIK there's no reason that pStun wouldn't occur on other types of item - it's rare, but not unheard of.

[AnonymousHero]

What sort of experiments? Do you just mean generating a lot of randart sets, or something else?

AFAIK there's no reason that pStun wouldn't occur on other types of item - it's rare, but not unheard of.

Oh, I've generated several hundred sets of randarts. It never appears on non-body armor.

I've observed off-weapon extra blows and shots quite a few times and those are also very rare, so I don't think it's just a rarity issue.

Looking at the code, I think I can guess at the reason. AFAICT the only code which can potentially add pStun is:

		case ART_IDX_ARMOR_HRES:
			add_high_resist(a_ptr);
			break;

(This is the only call to add_high_resist.)

The only other place that ART_IDX_ARMOR_HRES is being referenced non-trivially is in the block

	if (a_ptr->tval == TV_SOFT_ARMOR ||
			a_ptr->tval == TV_HARD_ARMOR || a_ptr->tval == TV_DRAG_ARMOR)
		{
			temp = 0;
			if (of_has(a_ptr->flags, OF_RES_POIS)) temp++;
			if (of_has(a_ptr->flags, OF_RES_FEAR)) temp++;
                       (... snip a few almost identical lines...)
			if (of_has(a_ptr->flags, OF_RES_DISEN)) temp++;
			if (of_has(a_ptr->flags, OF_RES_STUN)) temp++;
			file_putf(log_file, "Adding %d for high resists on body armor.\n", temp);

			(artprobs[ART_IDX_ARMOR_HRES]) += temp;
		}

Am I on the right track?

[scud]

Looking at the three winners I've posted, all 3.3.2, none of them wore pStun nor a source of pStun in their closets, though that's not to say I didn't find and discard a pStun randart. There was a ridiculous Bladeturner variant in one of them which had pStun (and p/r just about everything else, too) but I failed to find it.

I'll wear/carry a crown of Serenity for much of the time but eventually it gives way to a Helm of Badassness. It means I have to be 'watchful' around Grand Master Mystics – although that's probably advisable anyway – and I guess that if I were hugely unlucky I could get completely plasma-hounded on a teleport, but it hasn't happened to me yet. By the time I discard Serenity I've got speed/actions to spare.

pStun: there's not a lot of it about.

[Magnate]

Am I on the right track?

Turns out you were. There's nothing wrong with it being where it is - but what's missing is a stanza that says

case ART_IDX_GEN_PSTUN:
            add_flag(a_ptr, OF_RES_STUN);
            break;

at around line 2548 in the current master's randart.c

The absence of that code is why it's not getting added except as a high resist on body armour.

Well done.

[AnonymousHero]

Thanks, I tried adding that, but it doesn't seem to be helping. (Btw, I've cranked pStun up to 5 in adjust_freqs() just to be able to reliably generate pStun while testing.)

One further little observation is that pStun is the last entry in both art_idx_gen and art_idx_high_resist, so it might be that there's an off-by-one somewhere that's still preventing it from working.

Out of interest, I added a printf() to the code you suggested, but it never triggers, so it appears that the "r" parameter never hits the required value to generate pStun. choose_ability() must be "avoiding" the value somehow.

Of note is also that ART_IDX_GEN_PSTUN = 86 which is the last ability (ART_IDX_TOTAL = 87).

[Magnate]

Yes, I'm guessing it's an off-by-one as well then.

[AnonymousHero]

Did a little further digging, and I think I've found the underlying reason, but I'm unsure how to fix it. Perhaps you have some ideas?

randart.log says:

...
Cumulative frequency of ability 84 is: 766
Cumulative frequency of ability 85 is: 766
Cumulative frequency of ability 86 is: 766

and the code in choose_ability() says

	r = randint1(freq_table[ART_IDX_TOTAL-1]);

	/* Find the entry in the table that this number represents. */
	ability = 0;
	while (r > freq_table[ability])
		ability++;

which, if I'm reading correctly, means that it will always choose the first of 84, 85, 86 if r hits the value 766. A little empirical testing with a printf for all ability >= 84 confirms this.

So, it'll always choose

#define ART_IDX_NONWEAPON_SHOTS 84

over

#define ART_IDX_GEN_AC_SUPER 85
#define ART_IDX_GEN_PSTUN 86

[AnonymousHero]

Just to confirm: Added the following code to choose_ability():

	if ((freq_table[ART_IDX_NONWEAPON_SHOTS] != freq_table[ART_IDX_GEN_AC_SUPER]) ||
	    (freq_table[ART_IDX_GEN_AC_SUPER] != freq_table[ART_IDX_GEN_PSTUN]) ||
	    (freq_table[ART_IDX_NONWEAPON_SHOTS] != freq_table[ART_IDX_GEN_PSTUN])) {
		printf("GOT DIFFERENT VALUES!\n!");
	}

It never triggers the printf() so the cumulative frequency seems to always be identical for all the mentioned abilities. (Which surely can't be right if the code indeed forces a per-ability minimum frequency so that randarts can choose abilities that aren't in the set of abilities in the standart set.)

[Magnate]

Well I notice that ART_IDX_GEN_COUNT is 31 when it should be 32, but I'm not sure that alone will solve the problem. This is proof that there are way too many constants in the randart code, and not nearly enough use of N_ELEMENTS and other macros.

[PowerWyrm]

Well I notice that ART_IDX_GEN_COUNT is 31 when it should be 32, but I'm not sure that alone will solve the problem. This is proof that there are way too many constants in the randart code, and not nearly enough use of N_ELEMENTS and other macros.

The problem is exactly this. Frequency for pStun is not set, so it won't ever appear as a general property. For body armor, art probability is directly used, so it works... though it should not, because pStun is not a high resist anymore.

[AnonymousHero]

Yup, that was the last missing piece.

I've submitted a pull request. Of course credit goes to Magnate for the actual fix, just thought I'd help out with creating a pull req.

[Magnate]

Yup, that was the last missing piece.

I've submitted a pull request. Of course credit goes to Magnate for the actual fix, just thought I'd help out with creating a pull req.

Many thanks for doing that - I don't have the capacity to do pullreqs nowadays.

[PowerWyrm]

For body armor, art probability is directly used, so it works... though it should not, because pStun is not a high resist anymore.

In fact, pFear/pConf/pBlind are also listed as "high resists" for randart body armor, so nevermind...