eb22a81088
Note: Original change is from xNetHack by copperwater <aosdict@gmail.com>, but this commit comes from HACKEM-MUCHE by Erik Lunna, with some minor code formatting. From xNetHack commit a0a6103bea: 'The original goal: nerf item destruction using a method I initially proposed for SpliceHack, in which the number of items subject to damage from any single source is limited by the amount of damage the effect caused. The intent was to be more fair all around and prevent aggravating situations where, for instance, a chest shock trap zaps you for 4 damage and immediately ten of your rings and wands blow up. Problem 1: no easy way to limit the items destroyed without biasing heavily towards the start of the invent chain. The old code was able to get away without bias by just indiscriminately destroying everything eligible with a 1/3 chance. Here, I had to introduce reservoir sampling in a somewhat more complex form than I've applied it elsewhere, since there are a pool of potential items. Problem 2: destroy_item no longer worked remotely like destroy_mitem, which still destroyed 1/3 of items indiscriminately. Commence the process of squishing them into one function that handles both the player and monsters. (Which required making a lot of adjustments to destroy_one_item, now named maybe_destroy_item, on nits such as messaging and when to negate damage. An annoying consequence of the merge is that in the player case, their HP is deducted and they can be killed directly, but for monsters they need to add up the destruction damage and return it.) Unifying destroy_item and destroy_mitem has some advantages: in addition to the obvious code duplication removal, it ensures monsters now take the same damage as players for destruction (previously they took a piddly 1 damage per destroyed item). Now when you hit something with Mjollnir and their coveted wand of death breaks apart and explodes, you at least get the satisfaction of knowing they took the standard amount of damage from it. Monsters also now get symmetry with players in having extrinsic elemental resistance protect them from item destruction, and damage negation from item destruction if they were appropriately resistant. Problem 3: a lot of callers didn't preserve the "amount of incoming damage" that this refactor relies on. E.g. if the defender resisted that element, the local dmg variable would be set to 0. So I had to do some wrangling with callers to save that original damage value. The rule of thumb is: all *incoming* damage counts. So that includes the player's spellcasting bonus if applicable, but not things like half damage, negation due to resistance, or extra damage due to being vulnerable to cold/fire. Then I figured, while I'm here let's get rid of all those silly cases where destroy_items is called multiple times for various different object classes, and cut the object class parameter out of it. This has a few minor effects: - Places where different object classes previously rolled independently for destruction to happen at all now roll once. (Which, by my calculation, generally means less incidences of destruction - a fire attack now won't have three separate chances to hit your scrolls, potions, and spellbooks. On the flip side, a lucky roll will no longer save an entire object class in your inventory.) - Callers can no longer specify different probabilities for destroying different object classes. The only place this was really used was to call destroy_item with a slightly lower probability on SPBOOK_CLASS. With the nerf in this commit, less of them ought to be destroyed anyway. - A very edge case of where explosion-vs-monster damage was totted up differently for golems, which could result in differences of a hit point here or there. - All object classes being processed in one go means that less items are destroyed than would be if they were still processed independently. This is not really visible compared to the old baseline of just destroying 33% of everything, but would be a marked difference versus a copy of the game that still called destroy_items separately for different object classes. To compensate, I adjusted my planned damage-to-destruction-limit scaling factor down from 8 to 5. Not done: merging in ignite_items(), though that would probably be really easy now.' Notes from porting from xNetHack: - It might be necessary to reexamine at all the conditional checks for calling destroy_items. Because item destruction is much more restrained and uses the actual damage from an effect, we might now need to check 'if (!rn2(3))' and similar in all the places item destruction occurs.
162 KiB
162 KiB