Issues on current master

[Nomad]

has anyone else experienced this bug? i'm starting to think it might be something on my end.

Yes, I experienced this with my last almost-winner, way back in the March 16th nightly (a016a4c), which I think was the first one with the new randart system. He's stuck sitting on the steps at dlevel 99 after killing Sauron, and descending causes a crash.

[Sky]

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

[Pondlife]

That sounds like an improvement to me. I think TO is/was too powerful: no saving throw or resist, and the monster will probably end up bottled up somewhere bashing it's head against the wall.

If better path finding changes TO into just a bit of breathing space, then I think that's a good thing.

[Philip]

Yeah, I feel like if you want to send someone away, they should be capable of getting back. Having monsters stay in the place they were teleported to makes them pretty dumb. You can always walk away from the place you teleported the monster from. That should prevent most monsters from tracking you down.

[Sky]

if that is what you want, you simply need to change how far TO teleports mobs. basically, turn it into a "Blink Other' rod. it will give you time to quaff some potions, but basically you can't just say "i dont want to fight this mob".

however, this will make the game substantially more difficult, and slower.

[Nick]

OK, new builds up on the nightlies page; these probably break savefiles.

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.

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.

[Estie]

The last few games I played felt like artifactless games. Have you nerfed the randarts substantially or was I just very unlucky ?

I dont really feel like playing atm, after my 3rd character ended up wearing ego dragon mail, MoD of slay evil, "trickery and rings of damage and speed, I got very very bored.

[Nick]

The last few games I played felt like artifactless games. Have you nerfed the randarts substantially or was I just very unlucky ?

There have been a succession of hacks to try to get the distribution right, which may have had the effect of nerfing. The latest build has removed all those hacks. I have tested a few sets of randarts with the new system, and they look reasonable to my eye, but I would like to have them tested by people with more experience.

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

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

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

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

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

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

[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?)