Issues on current master

[takkaria]

Another minor issue: monsters break from "hold" effect when hit, but not from various other situations.

- hurt by earthquake
- summoned via "calling out"
- healed via "heal monster"

I think I'm OK with this. I'll fix the other issues though, and also turn on saving throws for the unresistable effects soon.

[PowerWyrm]

Another minor issue: monsters break from "hold" effect when hit, but not from various other situations.

- hurt by earthquake
- summoned via "calling out"
- healed via "heal monster"

[t4nk]

That's what the code does everywhere. The main reason is to put zero as index in the savefiles where there is nothing to save, while keeping a trivial loading routine: read index, assign struct = structs[index]. Otherwise, you would have to check the index, see if it's zero, assign null in that case, assign struct = structs[index-1] in other cases.

Ah, so that's how it was (angband now saves artefact names as strings instead).

[PowerWyrm]

Are traps still appearing only 25% of the time in vaults? I think the number of traps should be increased again, otherwise many vaults are very empty...

[PowerWyrm]

Minor issue: in commit e9458fa, many flags have been added to monster.txt, but some of them are already present in monster_base.txt (for example: NO_CONF on vortices).

[PowerWyrm]

Looking at master for implementing the latest stuff in PWMAngband. In commit a970eb7:

+
+	/* Uniques are doubly hard to affect */
+	if (rf_has(mon->race->flags, RF_UNIQUE)) {
+		resist_chance /= 2;
+	}

Well I think that makes uniques easier to affect no?

Best thing is to leave the double check in saving_throw(). Doing a *2 would make all level 50+ monsters completely immune to effects instead of giving them double resistance (double check at resist = 50 --> 75% vs single check at resist = 100 --> 100%).

if (rf_has(mon->race->flags, RF_UNIQUE) && (randint0(100) < resist_chance)) return true;

[PowerWyrm]

come to think of it, why does obj-init.c do that? and why does it start assigning from a_max, leaving zeroed out struct at the beginning?

That's what the code does everywhere. The main reason is to put zero as index in the savefiles where there is nothing to save, while keeping a trivial loading routine: read index, assign struct = structs[index]. Otherwise, you would have to check the index, see if it's zero, assign null in that case, assign struct = structs[index-1] in other cases.

Note that in PWMAngband, I do the latter. It makes loading savefiles more complex, but simplifies all the rest (in particular, the init/parsing code).

[Nick]

Nick, I got a crash from asan at obj-randart.c:2518:

while (strstr(art->name, "The One Ring") ||
	kf_has(kind->kind_flags, KF_QUEST_ART)) {
	(*aidx)++;
	art = &a_info[*aidx];
	art_level = art->level;
	if ((*aidx) >= z_info->a_max) {
		return;
	}
}

obj-init.c allocates z_info->a_max + 1 structs (line 2700), but note that it then increments a_max (line 2715). So accessing art->level when *aidx == a_max is illegal (perhaps that's the cause of Nomad's crash?)

Thank you, yes - I should be testing before incrementing.

(come to think of it, why does obj-init.c do that? and why does it start assigning from a_max, leaving zeroed out struct at the beginning?)

I don't actually remember. Each artifact in artifact.txt used to have an index, and they started at 1, and there was some code or other that relied on that fact, but I'm not at all sure it's necessary any more. I'll check at some point and change it if it's not needed, because it's a bit silly to do it for no reason.

[t4nk]

Nick, I got a crash from asan at obj-randart.c:2518:

while (strstr(art->name, "The One Ring") ||
	kf_has(kind->kind_flags, KF_QUEST_ART)) {
	(*aidx)++;
	art = &a_info[*aidx];
	art_level = art->level;
	if ((*aidx) >= z_info->a_max) {
		return;
	}
}

obj-init.c allocates z_info->a_max + 1 structs (line 2700), but note that it then increments a_max (line 2715). So accessing art->level when *aidx == a_max is illegal (perhaps that's the cause of Nomad's crash?)
(come to think of it, why does obj-init.c do that? and why does it start assigning from a_max, leaving zeroed out struct at the beginning?)

[PowerWyrm]

The big change is a new randart generation algorithm, which is much more efficient (no more waiting forever for randart generation to finish). There are some significant changes, the biggest of which is that randarts are no longer "based on" standard artifacts; for the most part, though, the actual creation of individual new randarts is the same. Given that the chief relationship between the randart and the standart it was based on was the power - there was no influence on actual properties - I don't think this will cause any problems. Do please report any concerns with the new randarts as used; there is a lot of scope for adjustment of the new algorithm.

I'll have to look up at this for PWMAngband. The constraint when you have a multiplayer base is that you need to base your randart set from something that all players have in common, and the only thing was the standard artifact set. So no fancy rerolling base items till now. If the new algorithm in V takes freedom from the actual arts, then it's something to consider.

[PowerWyrm]

@Nick, mob pathing looks much better now, maybe .. too good? I've more than once TO some unique, only to find them coming back before i finished resting.

That is indeed a marvelous improvement.

[Nick]

https://www.dropbox.com/s/7zyyskbx7b...57135.rar?dl=0

here u go.

Thanks.

It seems the DL99->DL100 crashes are because of a memory bug, which I haven't been quite able to track down yet. I found another potential bug while experimenting, too.

[Nomad]

The first time I tried to start a new randart game in the latest build it crashed at generation. Second attempt there was no problem.

[Sky]

There is not a fix for the crash on descending to DL100, as I could not replicate it. If this still seems to be occurring with the latest build, a savefile (and randart file if playing with randarts) would help.

https://www.dropbox.com/s/7zyyskbx7bsmlnp/angband-4.0.3-720-gb057135.rar?dl=0

here u go.

[Pete Mack]

Nick--
Estie is probably correct, statistically. The trouble with randarts used to be that you'd get very powerful artifacts in slots that were not usually powerful. (This is independent of issues around off-weapon blows and brands, and crazy powerful bows.)
However, the standard artifacts are carefully designed to mesh with each other--things like CON in the shield slot, and excellent damage+stats in the glove slot, CON in the amulet slot, because there are no alternate objects or ego items. If you randomize the benefits, but keep the nominal values the same, you will lose synergy without making up for the lost "holistic" power in some other way. So it's reasonable that randarts be somewhat more powerful than similar standarts. But making randarts of a different order of power than the corresponding standarts is potentially a bigger mistake.