Bugs and issues in 4.1.0

[Philip]

If we want to make feather falling useful, make it block trap doors entirely. If you can float over a pit trap, you can float over a trap door.

[Pondlife]

How would vastly nastier trap doors make the game more fun?

They would make feather falling slightly more useful than it currently is.

[Derakon]

If that fall of 50 ft were treated with the least bit of realism, you 'd simply be dead in most cases.

Impact velocity is given as v = sqrt(2 * g * h) where g is gravity and h is height. Assuming gravity is similar to reality and h is exactly 50', impact velocity would be ~17m/s or about 39MPH. That's pretty nasty for your bog-standard level-1 human, but is still potentially survivable. The kinds of demigods we casually sling around in Angband -- people who are gearing up with loads of magical artifacts and implausible statistical enhancements -- should easily be able to survive such a fall. All they need do is straighten their legs, land feet first, and then dig themselves out of the impact crater.

In general I would caution against applying realism too liberally. Angband is a game, so we should apply realism where we think it will make the game more fun, not just for the sake of realism. How would vastly nastier trap doors make the game more fun?

[dreembeard]

Traps are such a minor nuisance in this game that I don't see a point of putting something complex behind them. The worst that can happen is triggering a trap door on a good level, but that's even a non issue, as you can explore an infinite amount of levels in this game.

I guess that's a defensible opinion for vanilla in its present state.

But that is partly because the game is still absurdly easy in many respects. For instance with respect to the consequences of falling through a trapdoor without feather fall. If that fall of 50 ft were treated with the least bit of realism, you 'd simply be dead in most cases.
Letting the character die would be too much of a YASD, I think, but I do find that @ should be badly hurt, heavily stunned, and losing part of its inventory. Most definitely, some potions should break in the fall, and some books, scrolls, ammo, and devices (if any) spread out across the floor. Also, nearby monsters should wake up, irrespective of player stealth.

With such modifications, awareness of the infinite amount of levels out there may prove scant comfort for that particular @....

[PowerWyrm]

Traps are such a minor nuisance in this game that I don't see a point of putting something complex behind them. The worst that can happen is triggering a trap door on a good level, but that's even a non issue, as you can explore an infinite amount of levels in this game.

[dreembeard]

Not quite: in this case, the the odds of seeing the trap would go up the further away you are when it first comes into LOS. This is a stand-in for repeated save checks as happened with searching. (The same could be done for light intensity.)

My later point is something I care more about, actually. The initial gains for detection as things currently stand are painfully slow for certain classes. (...)

I came home from a trip and read the dialogue between you and Derakon of the past few days. I think that the kind of system you propose has potential, in that it can get rid of the awkward feat of the current system of spotting hidden traps at the far end of a long corridor. But I also see a complication with what you refer to as "a stand-in for repeated save checks" in the old framework with search. I think that this may be a bit too good a stand-in, in that it leads to similar "self-inflicted player tedium" as search.

The present system (4.1.0) uses a trap discovery criterion of the form

P >= s_t ?

Here, P symbolizes @'s perception skill (listed as "Searching" on the C sheet), and s_t the stealth of trap t (listed in a "visibility:" line in gamedata/trap.txt).
Ignoring, for the sake of simplicity, the impact of ambient light and nearby awake monsters, a simple criterion formula that would "satisfy" the ruleset you propose is

P/d >= s_t * F^D ?

Here, P and s_t are as above, d is the distance from @ to the trap, F is a real number just below 1, and D is the distance of @ from the trap when it first gets into LoS. In other words, the factor F^D takes care of what you described as "the odds of seeing the trap would go up the further away you are when it first comes into LOS".

This criterion would be applied whenever @ moves with t in LoS after the move.
Because of the divisor d, spotting hidden traps at large distances would be rare. As long as F is close to 1, that is. (A value of F=0.5 would essentially divide the trap's stealth by 2 for every step needed for @ to reach t, so that the effect of the divisor d would be nullified for traps that come into view when they are far away.)

To show where the refinement embodied in the factor F^D causes problems, consider the situation in the diagram below.

                                               #.#
                                               #?#
                                               #.#
                                        ########.#########                      #.#
					#................#                      #/#
					#.##############.#                      #.#
					#.#............#@#                      #.#
					#.#....###.....#.########################.#
					#.#....#!#.....+.+.....................~..#
					#.#....###.....#.##########################
					#.#............#.#
                                        #.##############.#
					#................#
                                        ##################

@, coming from the north, is interested in that ! in the closet. If the person behind @ is a relaxed player, @ will just open the door that leads into the room, and enter the room, accepting the risk of hitting a trap.
However, if the player is a homo ludens economicus, an obsessive-compulsive optimizer, then @ will open both doors, and then go back to the ? in the north, and try to find a detour to the whip (/) and the lantern (~) in the far east, so that he can approach the room with the closet from there. Grace to the factor F^D, that will give him a much better chance to spot traps in the part of the room between the entrance and the closet.
I think that this is the kind of player behavior that is referred to as "tedium" (after you've done it a few times).
And I don't see how you can prevent it, if you stick to the rule that

(...) the odds of seeing the trap would go up the further away you are when it first comes into LOS

Besides, I don't really see how this addition improves the mechanism in any way.

One last point: do you agree that, once the addition is removed, it would not matter a whole lot if attempts to perceive hidden traps were limited to traps within 50 ft or so (ie, 5 tiles)? That would make the mechanism more efficient, and to spot a hidden rune from 180 ft, you'd need the eyesight (and viewpoint) of an eagle. I myself am unable to see a freshly painted No Parking sign from that distance (or less...).

---
(The second part of your post refers to an issue that I was already preparing a post of my own for. Which is forthcoming...)

[Pete Mack]

Not quite what I meant, though I'm not actually sure how it works now. I don't mind if a CL 1 character has a zero percent chance of detection.
Assume that a CL 1 character has a @100% fail chance at DL 2, and a CL 50 character has a 1% chance at DL 100. Then assume character has native depth = 2*DL (for continuity), then solve the equation
(P1-50)* Pow(x)^50 = P50.
Then every character level, decrease the native fail rate by another power of x. If the character is expected to reach zero-fail detection at some level, then use 0.5% at that level and round off to zero. Getting those last few percentage points is hard, obviously. But initially, you gain relatively fast.

That would be easy to implement without changes to the process of detection, just add a global maximum fail chance similar to spell failure.

[PowerWyrm]

Since commit a7d0cfe, you get spammed by "You have found a trap" messages each time you move when a trap is visible. In update_one(), you should only reveal traps if there's a secret trap in the square...

[Estie]

Not quite: in this case, the the odds of seeing the trap would go up the further away you are when it first comes into LOS. This is a stand-in for repeated save checks as happened with searching. (The same could be done for light intensity.)

My later point is something I care more about, actually. The initial gains for detection as things currently stand are painfully slow for certain classes. As a CL 25 HE warrior, I'm STILL stepping on half the traps. But by CL 50, I'll be stepping on less than 10%. I'd like to front-load the improvement so that relative failure rate changes more steadily.

That would be easy to implement without changes to the process of detection, just add a global maximum fail chance similar to spell failure.

[Pete Mack]

Not quite: in this case, the the odds of seeing the trap would go up the further away you are when it first comes into LOS. This is a stand-in for repeated save checks as happened with searching. (The same could be done for light intensity.)

My later point is something I care more about, actually. The initial gains for detection as things currently stand are painfully slow for certain classes. As a CL 25 HE warrior, I'm STILL stepping on half the traps. But by CL 50, I'll be stepping on less than 10%. I'd like to front-load the improvement so that relative failure rate changes more steadily.

[Nick]

I think the same effect can be had (i.e. equal chance to detect a trap when at a given distance to it) with static trap "hiddenness scores" and a search power that scales with distance to trap, if the scaling of the values is exponential somehow.

If I'm reading this correctly, this means the chance of not noticing a trap before stepping on it is then a fixed check of perception vs trap power - which is the current situation. The only difference is that currently the player notices the trap immediately on seeing its grid, whereas with this idea that point may be closer to the trap (but still before they hit it).

[Pete Mack]

Yeah, that'd work. Increase the player's detection power depending on how far he is away when he gains illuminated LOS, the further the better. Obviously, you'd have to do the proper psum based on the distance-dependent probability function.
The reason I proposed this was to give some parallel to the 's' command without actually having to search.

I also think probability of failed detection should be the basic unit, not probability of detdction. Basically 99% detection rate is twice as good as 98%, while the difference between 2% and 1% is negligible. In the latter case, you're hitting essentially every trap.
So make detection work like stealth: the probability of failure goes down as a power law with level. Both power law and initial probability can be class dependent.
The current state is a big change from the old days, at last for certain classes. Instead of hitting essentially no traps (after the first few levels) you hit essentially all the traps. I tend to find this tedious, and end up playing Mage or Rogue even more than I used to.

[Derakon]

Hm, wouldn't that encourage the player to walk everywhere to get the maximum number of chances to detect traps? E.g. if they phase door closer to a trap, then they've just lost a few chances to detect it. That feels a little odd to me.

I think the same effect can be had (i.e. equal chance to detect a trap when at a given distance to it) with static trap "hiddenness scores" and a search power that scales with distance to trap, if the scaling of the values is exponential somehow. For example, let's say no traps are noticed at 20 tiles out. If the player has a 50% chance of noticing a particular trap at any range, and they walk 10 tiles towards a trap, then they have a 1 in 1024 (2^10) chance of failing to see the trap. Conversely, if the player has a search power that is given as 1024 / 2^(distance to trap), then their search power would be 1 at a distance of 10 tiles (and 2 at 9 tiles, 4 at 8, etc.). So long as only 1 in 1024 traps is invisible with that search power, you have the same odds of seeing the trap at that distance, without the requirement that the player make multiple trap detection attempts.

Obviously these numbers are made up for the sake of making the math easier, and I may well have still screwed it up somehow. But I think it could be made to work without encouraging odd behaviors to improve odds of detecting traps.

[Pete Mack]

@Derakon--not quite. I suggested you get a chance to detect via a saving check at every distance (in strictly decreasing order.) That gives a finite number of search attempts depending on initial sight distance. There's no way to do usefully with the existing mechanic of variable trap detection difficulties that is currently implemented. You CAN do it with variable brightness, by increasing the detection level based on light intensity.

[Derakon]

Wait, I'm confused. You seem to be arguing against varying detection chance with distance now, whereas your initial post had "Instead of the flag value for "failed", I propose turning it into an integer representing distance. You get another check at each nearer distance."

I also don't understand why light matters if trap detection is only important when you're 1 tile away, since all players are always going to have at least a radius-1 light source, so they should always get a "maximal" chance to see the illuminated trap before they step on it.