Question about unlocking chests

[BlueFish]

Based on my reading of the code, a chest's "defense" versus being opened is the following:

(level chest was generated on / 4) + 6

"level chest was generated on" can be increased by up to about 4 depending if it's a special chest in a vault or special room.

This is a standard skill check, meaning player rolls D10, adds his Perception, and compares to chest's D10 + its defense, which is the above formula (based on what I see in the code).

So I did the math a bit and found that it seems like I'm having way more trouble than I should be. The chest's defense would have to be 9 greater than my Perception for it to be impossible. I just did a wizard mode game where I created a ridiculous melee character with mediocre perception and dove till I found a chest. It was in a special room so let's say it was +4 levels. I found it at level 6 (300'), so let's say it was level 10. (In the code I take it this is its "pval".)

so its defense should have been 10/4 + 6 which is 9 max, depending on rounding.

let's say it was 9. My perception was 4. I failed opening it 500 straight times, which means the skill check was actually impossible. Then I added one to my Perception, bringing it to 5. I finally succeeded in opening it after over 100 tries. About what I would expect if its defense exceeded my Perception by 8, which gives a 1% chance of opening. (I rolled a 10, chest rolled a 1.) Which would put its defense at 13.

How does a chest found at 300' get a defense of 13 based on the above formula? What am I missing? I guess it would all make sense if there was no "divided by four", but that's in the code.

[BlueFish]

Oh, it would be really helpful to put chest opening attempts in the combat rolls window. It's very opaque whether you're just getting unlucky or whether it's futile to even try.

[locus]

I'd be in favor of displaying all rolls instead of just combat rolls, honestly. Or at least all rolls that result from deliberate action, you wouldn't want to display e.g. Perception to notice traps or invisible monsters.

[BlueFish]

Based on my reading of the code, this is a bug. It unintentionally adds 5 difficulty to the following actions (since sil 1.0 presumably)

Finding a secret door
Opening a locked door
Finding a trap
Disarming a trap
Opening a locked chest

The common thread is the call to "no_light()", which calls the macro "player_can_see_bold(y, x)", which works but for one case: when it's called for the player's current square. Throughout the code, only no_light() cares whether player_can_see_bold works for the player's current square.

To fix this, you'd change the following in cave.c:

void update_view(void)
{
...
/* Assume viewable */
info |= (CAVE_VIEW | CAVE_FIRE);
...
}

To add in the "CAVE_SEEN" flag, which is what player_can_see_bold checks for.

I can't verify this since I can't compile the code, but based on my reading of it, that's the bug.

I hope I'm not the only one to have ever had the subjective impression that it's absurdly difficult to disarm traps and open chests and find secret doors...

[Patashu]

Ouch! Well spotted

[bron]

I'll have to check the code about what you say, but I do know that there is a (I assume deliberate) +5 in the code: if you have not identified the lock (and/or trap) on the chest, you get a +5 difficulty. It used to be that LoreMastery would identify the lock just like it identified anything else, but that got removed at some point. Now, you need to use the "secret tech" method of using a Staff of Understanding to identify the chest (and its lock/traps). Once you can see the lock/trap, you no longer have the extra +5 penalty.

At least, that's the way I remember it.

The part that annoys me is that I never seem to be able to spot the lock/trap on a chest no matter how many times I search for it. It seems that the Staff is the only way to find them. (?)

[As long as I'm bitching .. I'd also like it if there was an explicit "search" command key, even if it doesn't actually do anything different than waiting with a '5'. The documentation refers to searching, and it would be nice if the command actually existed]

[BlueFish]

It's definitely a bug. Being blind or hallucinating have no effect on the skill check currently, because they're both "or"ed in with the no_light() check. The deliberate +5 is included in the +6 I referenced in the original equation. no_light() is broken.

I accidentally discovered a work-around though, if the player has something that produces light while on the floor, such as a lesser jewel or feanorean lamp. Drop it under you or next to you, and no_light() works (finally returns false). It's an effective +5 to the skill check. Glowing weapons... amulet of blessed realm... Too bad starting characters are a bit out of luck. And lesser jewels cost a forge charge.

The way I discovered the workaround was by removing all light sources so I was in total darkness, and verifying that my skill at opening chests did not reduce as compared to having light. (I verified this.) But while I was verifying, an Ururauko came at me and lit my square. All of a sudden I was able to open the chest.

[BlueFish]

Oddly enough, rooms with natural light don't seem to have any bearing on this. You have to have a "temporary" light source. Song of trees probably works, staff of light probably works.

The insidious part is that there is no viable workaround for detecting traps, since you can't very well walk around with temporary light sources following you around on the floor every move. This is something that makes especially false floors way more prevalent than they're intended to be. -5 to find traps is huge. Up to 40% difference, depending.

[BlueFish]

I'm not actually 100% sure that my fix is appropriate. It may cause no_light to always return false, rather than almost always returning true, as is the current case. no_light is presumably meant to check whether the object being searched/interacted with is lit and visible to the player. no_light may just have to be re-written. As it is, the player's square is theoretically being checked for light, which seems theoretically broken even if it worked as intended.

[BlueFish]

I think it's only fair that until this gets fixed, all characters start with a lesser jewel in place of torches. Change the second number in the Torches line in Race.txt for your race to 2, if you want to. And the last two numbers to 1.