no-artifact creation bug in 3.1.1.1626

[bron]

So I'm playing a game with birth-no-artifacts as is my wont, and just now I killed Eol, and he dropped ... nothing. Zip. Nada. Since he is hardwired to drop at least a couple of good objects, I wondered how this was possible. Looking at the code, I see at least one problem: in obj-make.c, routine make_object we see:

...
/* Try to make a special artifact */
if (one_in_(good ? 10 : 1000))
return make_artifact_special(j_ptr, lev);
...

and of course the first executable line of make_artifact_special is:

...
if (OPT(adult_no_artifacts)) return (FALSE);
...

All of which means that if the RNG smiles upon me and would have tried to create a special artifact in a normal game, in a no-artifacts game I get squat.

The simple remedy is to test before calling make_artifact_special (well, actually I guess the simple remedy is to do nothing, but aside from that):
...
if (one_in_(good ? 10 : 1000) && (!(OPT(adult_no_artifacts)))) {
return make_artifact_special(j_ptr, lev);
}
...

Personally, I think that if no-artifacts is set, then as a consolation prize one should have a chance at a great object, maybe something like:

...
if (one_in_(good ? 10 : 1000)) {
if (OPT(adult_no_artifacts)) {
if (one_in_(10)) good = great = TRUE;
}
else {
return make_artifact_special(j_ptr, lev);
}
}
...


But then again, it seems that this whole thing is a bit unfair even in a normal artifacts game, since even there if make_artifact_special fails, you get nothing. So I guess what I really think this should be is:

...
if (one_in_(good ? 10 : 1000)) {
if (make_artifact_special(j_ptr, lev)) return TRUE;
/* else possible consolation prize */
if (one_in_(10)) good = great = TRUE;
}
...

i.e. only return early if in fact you make a special artifact, otherwise go ahead and make the (normal/good/great) object that you tried to turn into a special artifact.

[Magnate]

Thank you - I always wondered why I very occasionally get no drop from uniques who are guaranteed to drop GOOD or better. It must be trying to create a special artifact and failing. I'll try and implement your consolation prize idea.

[Psi]

Does that explain why wormy sometimes drops nothing in a normal game?

[Magnate]

Does that explain why wormy sometimes drops nothing in a normal game?

Yes. The Phial now has rarity 3, so two-thirds of the time he would drop it, he drops nothing. In the old 2.9.x days it had rarity one, so this never happened.

[ChodTheWacko]

Yea, if make_artifact_special returns FALSE, you get nothing at all right now.
You should still continue, and try to make an object.

I don't know if you necessarily want to add the:
'if (one_in_(10)) good = great = TRUE;'
part, since that is already done in apply_magic()

As far as wormtongue goes, he has DROP_GOOD/DROP_GREAT flags, so the good/great flags are already true to begin with.

- Frank

[bron]

that is already done in apply_magic()

My thought was that if you passed the "attempt to make a special artifact" test, that you should get some residual goodness out of that in case you didn't get the special artifact. But my main beef is with items not being generated at all: it looks like 1 out of 10 good items go down this path and disappear, except for the very few that are actually turned into special artifacts. Which is zero in a no-artifacts game. So only changing:
...
return make_artifact_special(j_ptr, lev);
...
to instead be:
...
if (make_artifact_special(j_ptr, lev)) return TRUE;
...

without the other stuff, would be ok.

[Magnate]

My thought was that if you passed the "attempt to make a special artifact" test, that you should get some residual goodness out of that in case you didn't get the special artifact. But my main beef is with items not being generated at all: it looks like 1 out of 10 good items go down this path and disappear, except for the very few that are actually turned into special artifacts. Which is zero in a no-artifacts game. So only changing:
...
return make_artifact_special(j_ptr, lev);
...
to instead be:
...
if (make_artifact_special(j_ptr, lev)) return TRUE;
...

without the other stuff, would be ok.

This was fixed in r1721, so is fixed in the nightly builds.