Bugs and complaints on current master

[Pete Mack]

Not a bug, but just out of curiousity, when did the Arkenstone's activation get converted to full Enlightenment, rather than partial?
Edit: this can't be right. ID'ed a set of Elvenkind boots (with no pvals) from across the dungeon with the Arkenstone. That's too powerful. It's OK with *Enlightenment*, but not things that are relatively common like ordinary Enlightenment and Arkenstone. This is too godlike.

[Pete Mack]

Diggers have no intrinsic pval. (Only ~ of Earthquakes gets tunneling.)

[kandrc]

Remove curse gives no message when attempting to remove a permanent curse.

[Pete Mack]

Thanks much!

[Nick]

@Nick---
How did you fix that crash from bad trap data? I hit it again. Apparently forgot to recompile after updating :/ Now I have a promising character lost, unless I can fix it.

I ran in gdb, put a break in rd_trap() in load.c at these lines:

	rd_string(buf, sizeof(buf));
	if (buf[0]) {

and then set buf="pit" (for every trap on the level...).

[Pete Mack]

@Nick---
How did you fix that crash from bad trap data? I hit it again. Apparently forgot to recompile after updating :/ Now I have a promising character lost, unless I can fix it.

[Nick]

New traps don't have tile mappings in the graf-XXX.prf files. I think this leaves them as a small ASCII symbol within a big black square.

Indeed, and one of the things I needed to do in the lead up to 4.1 was talk to the currently available tile artists about producing new tiles. Old ones could probably be re-purposed for traps, but it's possible there will be some new monsters

[PowerWyrm]

New traps don't have tile mappings in the graf-XXX.prf files. I think this leaves them as a small ASCII symbol within a big black square.

[StMicah]

thanks, Nick. Much appreciated!

[Nick]

obj->ego = &e_info[lookup_ego_item(buf, obj->tval, obj->sval)];

If lookup_ego_item() fails for any reason, it returns -1, which would do a memory access error. Would be better for lookup_ego_item() to return a struct ego_item * directly (NULL if the function fails).

Same goes for lookup_artifact_name().

That's a really good idea.

[PowerWyrm]

OK. Looks like time for some memory checking.

obj->ego = &e_info[lookup_ego_item(buf, obj->tval, obj->sval)];

If lookup_ego_item() fails for any reason, it returns -1, which would do a memory access error. Would be better for lookup_ego_item() to return a struct ego_item * directly (NULL if the function fails).

Same goes for lookup_artifact_name().

[Pete Mack]

You can detect these errors by running in verbose mode with -g -O2 compiler flags. This forces the debug memory management and allows good stack traces, but it still runs plenty fast. I hit crashes about every 5 levels playing this way...and that's a good thing. Thanks for fixing the nightmarish trap bug on restore. Lost a save file completely to that.

[Nick]

OK. Looks like time for some memory checking.

[Pete Mack]

@Nick -- I'm 99% sure it was an Ogre.

[Pete Mack]

Uh oh. Mystery free memory access:

warning: HEAP: Free Heap block 07B47D00 modified at 07B47D28 after it was freed

where
#0 0x778d06f8 in ?? ()
#1 0x77835c95 in ?? ()
#2 0x77835b32 in ?? ()
#3 0x778cf136 in ?? ()
#4 0x778381c6 in ?? ()
#5 0x77835c95 in ?? ()
#6 0x77835b32 in ?? ()
#7 0x74bc79b0 in msvcrt!malloc () from C:\WINDOWS\SysWoW64\msvcrt.dll
#8 0x004b554b in mem_alloc (len=len@entry=196) at z-virt.c:41
#9 0x004b55b1 in mem_zalloc (len=196) at z-virt.c:54
#10 0x0049380d in display_map (cy=cy@entry=0x0, cx=cx@entry=0x0)
at ui-map.c:656
#11 0x00487b8c in update_minimap_subwindow (type=EVENT_END, data=0x0,
user=0x5313d0 <minimap_data+48>) at ui-display.c:1683
#12 0x00414469 in game_event_dispatch (data=0x0, type=EVENT_END)
at game-event.c:43
#13 event_signal (type=EVENT_END) at game-event.c:142
#14 0x0046ad17 in redraw_stuff (p=0x37) at player-calcs.c:2463
#15 0x004149a4 in process_player_cleanup () at game-world.c:597