ZizzoTheInfinite: Okay, follow along with me here: the damage for walking on certain terrain types like lava is applied in function apply_effect() in src/dungeon.c, specifically lines 1122-1124: 

                                /* Apply damage */
                                project( -100, 0, y, x, dam, f_ptr->d_type[i],
                                         PROJECT_KILL | PROJECT_HIDE);

project() calls project_p() in src/spells1.c to affect the player, passing through the -100 argument as who. This in turn takes to lines 7288-7298 in project_p(): 

        /* Did the dungeon do it? */
        if (who == -100)
        {
                sprintf(killer, "%s",
                        d_name + d_info[dungeon_type].name);
        }
        if (who == -101)
        {
                sprintf(killer, "%s",
                        f_name + f_info[cave[p_ptr->py][p_ptr->px].feat].name);
        }

killer is passed on through take_hit() as the string that, in the event of death, is used in the "killed by" line of the character dump. As we see here, a -100 value of who uses the dungeon name, leading to death messages like "killed by Barrow-Downs on level 1 of Barrow-Downs". I think we want to use a value of -101 for who in apply_effect(), yielding AFAICT "killed by deep lava on level 1 of Barrow-Downs"; indeed, that seems to be the entire raison d'être for the -101 value in the first place.

As a related smallish suggestion, for the who == -100 case (damage by dungeon), it'd be neat to have a bit more verbose cause of death than just the dungeon name. It could be added, for instance, as an extra argument to the E: line in the dungeon definition in lib/edit/d_info.txt; for Cirith Ungol, for instance, we might have: 

N:9:Cirith Ungol
[...]
E:4d4:20:POISON:the deadly vapors of Cirith Ungol

MayLith: I like it!!

This is vaguely akin to the suggestion I made here about expanded item histories.

ZizzoTheInfinite: Okay, I've put up a patch that fixes the bug and adds the described feature. It's against 2.2.6, but should apply cleanly to 2.2.7. If you just want to fix the bug and not add the feature, there should be enough context between the patch and the above details to see how and where to fix the bug (it should be a one-line change, I believe).

MayLith: Great! :) Hmm.... do we need a Patch section for the wiki? And if so, where should it go? (Otherwise, only the folks who read this bug report are going to see your link....)

NeilStevens: Only the ToME developers need patches, and we have two who read the bug section. Third party ToME development should go into modules, not into the C sources, so I do not want this wiki to encourage that.

MayLith: Ah, okay.

Bandobras: Hello! What do you mean by "Only the ToME developers need patches"? I'm not one and I need pathes badly. (For example the patch to the dark arena bug that killed DeafLeaf II. The patch saved DeafLeaf III many times.)

Bandobras: And have I understood right that you do not want to encourage people to produce patches to known bugs? No, really? Or did you only mean you discourage patches that improve the game, not correct it --- mods? (The second half of the patch on this page seems to be, arguably, of this modding kind, indeed.)

NeilStevens: I do mean only to discourage patches with the intent of changing the way the game works, instead of just fixing things that don't work.

Bandobras: Then what do you think about marking bug reports that contain fixes with the {fix included} annotation? Or about advising people on the front page to mark them so? Or about a separate section for bug reports with fixes? Or about a separate section for fixes only, perhaps linking to the bugs being fixed? I would really like to help, you know, not only to make noise. :) And, by the way, could you comment on the spoilers in bug reports thing?

NeilStevens: What do you hope to achieve by marking bug reports as having a patch included?

As for spoilers, try not to put spoilers in bug reports unless the spoiler is necessary to describe the bug. If that happens, just mark it as a spoiler on the main page.

Clarification: Patches that change the game's behavior in a non-bugfix aren't exactly unwelcome, but they should be filed as new ideas in the IdeaArchive.

ZizzoTheInfinite: If you prefer, I also have a smaller patch that just fixes the described bug, without the extra feature.

NeilStevens: Massimiliano used to be the guy who collected and applied all these patches, but I don't know where he's gotten to.

BugReport67 (last edited 2005-09-06 02:35:59 by ZizzoTheInfinite)