Bugs and issues in 4.1.0

[Pete Mack]

Re: detecting traps.
Intuition suggests trap detection should be logarithmic with time and distance.
The cheapest way to do this is to do a trap check every turn, but reduce efficiency by 1/distance.
If you're within 1 or two squares of an awake monster, add 10 to the denominator: fleeing/fighting players should have a significant degradation for detection.
If you want to add a 'search' action, make it sneaky. Reduce movement by 2x, and add an extra trap check per move. At the same time, increase stealth by 6 (i.e 2x, when you factor in the slower movement). At the same time, make all 'wandering monsters' (i.e., spawned after dungeon creation( awake. This adds significant risk to just leaving search permanently enabled-- especially with the new pathfinding code.

[Estie]

Re: detecting traps.
Intuition suggests trap detection should be logarithmic with time and distance.
The cheapest way to do this is to do a trap check every turn, but reduce efficiency by 1/distance.
If you're within 1 or two squares of an awake monster, add 10 to the denominator: fleeing/fighting players should have a significant degradation for detection.
If you want to add a 'search' action, make it sneaky. Reduce movement by 2x, and add an extra trap check per move. At the same time, increase stealth by 6 (i.e 2x, when you factor in the slower movement). At the same time, make all 'wandering monsters' (i.e., spawned after dungeon creation( awake. This adds significant risk to just leaving search permanently enabled-- especially with the new pathfinding code.

That doesnt solve the issue that you either want to search everywhere you go or nowhere. Dreembeard wanted to place traps in player-recognizable places before re-introducing search, more so than they already are.
Turning on search before every crossing and turning it off after you passed it doesnt sound like machanic that would improve the situation.

[kandrc]

@Sideways

No, the panther is not on rubble.

@PowerWyrm

Yes, I am targeting it correctly.

      #.#
      #<#
      #.#
      #.#
      #.+
      #f#
      #@#
      ###

[dreembeard]

(...) Dreembeard wanted to place traps in player-recognizable places before re-introducing search, more so than they already are. (...)

Right.
Estie's post - and that of Pete Mack who he replied to - made me realize that I criticized the ideas behind no-search trap perception in current vanilla, without saying much about the alternative that I have in mind for my own (very future) angband variant. Which differs from what Pete Mack proposed in the way pointed out by Estie, but is very similar in some other ways (eg, an 'S' command that boosts both perception and stealth, at the cost of speed). Another difference is that I envisioned search for and perception of traps to be limited to the character's current light radius (or to adjacent visible tiles if you have no light).
But I am reluctant to go into more detail in this thread, because that feels as off-topic: the details of what I have in mind for my own variant are something I'd really like other forummers to shoot at, and some details may well be relevant for vanilla, but it's not stuff that I propose for 4.1.x or even 4.x. So I'll open a separate thread for it (soon).

Pete also brought up player stealth (in connection to search).

(...) At the same time, increase stealth by 6 (i.e 2x, when you factor in the slower movement). At the same time, make all 'wandering monsters' (i.e., spawned after dungeon creation( awake.

Ah, yes. All those sleepy monsters! That is something I do consider an issue of 4.1.0. See my next post in this thread.

[dreembeard]

sleepy monsters in 4.1.0

I may be misperceiving things, but I have the impression that monsters in 4.1.0 wake up much more slowly than in previous versions. So much that it feels boring at times.
At first, I thought that it was due to my h-elf rogue having very good stealth. However, the same thing now happens with a h-troll paladin whose stealth is labelled as BAD. Yet he is able to approach a kobold shaman from far away and kill him in his sleep. That should not happen, I'd say.
I saw no complaints about this from other players yet, but I guess complaints usually come pouring in about where the game is too hard; not where it is too easy.
And I did notice some mumbling in Changes.txt about a new way of dealing with player stealth and monster wakeup. Could that explain my impression of excessive monster drowsiness?

A related issue is that of the sound asleep newcomers.
In previous versions, the frequent appearance of wide awake newcomers (that started to spawn immediately after you entered a level) often annoyed me. Especially in case of hounds showing up at the far end of a very large room with me half-way the center, while detection just before entering had revealed that there were none. So I 'm glad that this was changed.
However, finding all newcomers sound asleep (except for the always vigilant races) is the other extreme. How about the happy medium:
If monster race r has sleep counter S, then give individuals generated during level generation that value, but use 1dS - 1 for newcomers with S>0.
Or better still, something like 1d(S-K) - 1, where K is the number of kilo-gameturns you spent on the present level.

Another great idea (IMCO):
if the game thinks it's time for a new monster when the player happens to be close (<200 ft) to a stairway (but not on it), let the monster appear on the stairway now and then. Of course, in that case the newcomer is awake. Do let the player hear "something coming up/down a stairway" if it is not in LoS. Unless he is deaf (stunned?), or has low perception skill, of course.
That would give angbandians a better understanding of the concept of stairway. It's not there just for you, you know...

[Nick]

I've got a young @ mage with his back to the wall in a corridor and a panther pounding on him from the north. My frost bolts miss it, whether I target it explicitly or simply fire north; it's as if it isn't there. Any tips where I should set a breakpoint to debug this?

Frost bolts are handled through effect_handler_BOLT(), project_aimed() (effects.c), project() (project.c), project_m(), project_monster_handler_COLD(), project_monster_hurt_immune() (all project-mon.c).

I have no idea what's going on.

[Estie]

Frost bolts are handled through effect_handler_BOLT(), project_aimed() (effects.c), project() (project.c), project_m(), project_monster_handler_COLD(), project_monster_hurt_immune() (all project-mon.c).

I have no idea what's going on.

I suspect either the panther or @ are standing on brush, or possibly in rubble that got created in the spot of a creature.

I had it happen to me once that some melee monster was walking around me and dint attack, exactly like Morgoth when your rune is active, and after killing it and making a move I saw that I was standing on : . This cant normally happen, so I suspect it must have been placed by a trap in my spot.

[kandrc]

I've confirmed that neither the @ nor the f are on rubble. @ is, in fact, on down stairs. I've also observed frost bolts and magic missiles beam through and past f, without hitting it. Wands in @'s possession can't hit it, either (MM, TO, I forget what else). Pretty sure I haven't tried stinking cloud.

I'd already located and traced execution through project(). Didn't see anything there. The game is running on another machine that I don't have access to now, but I'll look into the other functions tomorrow.

[Pete Mack]

More on traps: right now the trap detection is a simple state model: failed detection, unknown, or known. When it first comes into LOS it moves from unknown to one of the two other states. It moves from failed to known when you either trigger it or cast the mage detection spell.
Instead of the flag value for "failed", I propose turning it into an integer representing distance. You get another check at each nearer distance. That prevents the whole "searching" dilemma, while still rewarding players with bright light or who use rods of light. Further, make detection probability go down with distance. You can use 1/d (giving logarithmic behavior) or a sum of fractional powers, with a fixed upper limit on detection probability. ( E.g. 1+.5+.25+... <= 2.)
The other issue is that detection probability for certain classes (*cough* Paladin) is simply too low given the unavailability of a spell. It's no fun to be triggering essentially every single trap.

[Derakon]

More on traps: right now the trap detection is a simple state model: failed detection, unknown, or known. When it first comes into LOS it moves from unknown to one of the two other states. It moves from failed to known when you either trigger it or cast the mage detection spell.

If I understand it correctly (Nick, please correct as needed), there's already an analog value; if the trap has not been seen, then your search power is compared against the trap's "hiddenness" power or whatever, and if search power is greater, then the trap is permanently revealed. In other words, there's no "failed to detect" state, just traps that haven't been detected yet --
and won't be, unless you improve your search power somehow. Search power varies with race/class/equipment; I see no particular reason why it couldn't vary with light level and distance to trap as well.

[Pete Mack]

Varying with distance doesn't help with this method, as distance can only reduce detection probability, not increase it. Light level would work, I agree, though casting a light spell at every intersection would get old fast.

[Derakon]

Varying with distance doesn't help with this method, as distance can only reduce detection probability, not increase it. Light level would work, I agree, though casting a light spell at every intersection would get old fast.

"Decreasing detection probability when you're far away" is equivalent to "increasing detection probability when you're close". Isn't that what you were proposing?

Not sure why you'd need to cast a light spell at intersections; your carried light would suffice. I don't think there should be a bonus for trap spotting just because the illumination is permanent in nature; more that carrying a large-radius light would give you a better chance of spotting traps from several tiles away.

[Pete Mack]

@Derakon--increasing the detection probability when you are close is the same as increasing the detection probability without qualification. Detection really only matters when you are a single step away. The light effect is different: it's the difference between light radius+1 and distance from trap (+1 if there's illumination). So the spell would make a difference, especially if all you have is a torch. Of course a light rod is better, but using light rods in hallways (pre-ESP) is a good idea in any case.

[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.

[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.