Trap/door feature branch

[Nomad]

Maybe it's worth reconsidering the entire concept of detection boundaries, if we're aiming to get rid of the repetitive "stop to detect every X distance" playstyle. Two possible alternative schemes to kick around:

1. Once-per-level detection. Have something like Detect Doors & Stairs just find all doors and stairs on the level at once, instead of within a specific boundary. It would be more powerful than the detection effects we have now, but you could rebalance spell costs and item rarity accordingly.

2. Player-centred detection radius. Make the detection effects act like temporary ESP - while the buff is active, you become aware of treasure or doors/stairs within a certain radius around @ as you move around the level.

[Pete Mack]

I dunno why monster detection is considered boring. If you find it boring, you aren't diving fast enough. Trap detection is boring. Door/stair detection is boring. Map detection is boring for priests (and hard to come by for everyone else.)
But monster detection? Not boring at all.

[Nick]

Its main purpose? For me it was a reminder to detect for monsters, objects, as well as its actual indication, traps. It also levels the playing field for those, like me, that choose to always center the map on the @. Does this mean I need to switch that off to regain the advantage of knowing that I've moved to a new quadrant and should detect again?

It was a crutch, and I've kicked it away. You're now free - or crippled, depending on how you look at it

I'm also trying to figure out why savefile compatabity wouldn't be broken, or at least the old player is entirely screwed when it comes to traps, since the skill in the original player's race and class has been divided into two, but when rolled was only one and called under a different name. Is that not part of the savefile?

No, it isn't. Originally, the disarm skill was calculated from base race skill, base class skill, and a per-10-level class increment, plus a bonus based on INT and DEX. What I've just done is split the skill bases and increments into two, and make the physical skill have a DEX bonus and the magical one an INT bonus. In both cases, though, the skill values are derived from other properties of the player, and don't need to be saved.

[Nick]

New Windows and OS X builds to fix traps in template rooms.

There's still some work to do on this branch. I do think trap detection should be dropped from early spells and stand alone items. I also want to introduce some more non-trap obstacles - spider webs are a good example. Any suggestions as to how they should work? In FAangband they take a turn to clear (either from within or next to the web, and a single turn is all it takes), but an uncleared one holds the player.

[PowerWyrm]

New Windows and OS X builds to fix traps in template rooms.

There's still some work to do on this branch. I do think trap detection should be dropped from early spells and stand alone items. I also want to introduce some more non-trap obstacles - spider webs are a good example. Any suggestions as to how they should work? In FAangband they take a turn to clear (either from within or next to the web, and a single turn is all it takes), but an uncleared one holds the player.

Seems fine as long as "hold" doesn't mean "paralyzed", but just "enabled to move". In fact, pits should probably do the same, as @ should take a turn to climb out of the pit.

[Nick]

Seems fine as long as "hold" doesn't mean "paralyzed", but just "enabled to move". In fact, pits should probably do the same, as @ should take a turn to climb out of the pit.

Yes and yes

[Ingwe Ingweron]

It was a crutch, and I've kicked it away. You're now free - or crippled, depending on how you look at it

I don't view it as a crutch. I view it as an important graphical representation of @ knowledge. Why is this indicator somehow different than any other indicator of @ state and knowledge? If @ can detect traps, than the gui should indicate the radius. At least, please bring it back as an option. "And so, as Tiny Tim said, 'A Merry Christmas to us all; God bless us, every one!" - Charles Dickens

[Ingwe Ingweron]

Still have a crash on killing monster, monster drops objects, game crashes. Didn't get a savefile on this one. Sorry about that.

[Rydel]

I also want to introduce some more non-trap obstacles - spider webs are a good example. Any suggestions as to how they should work? In FAangband they take a turn to clear (either from within or next to the web, and a single turn is all it takes), but an uncleared one holds the player.

Perhaps they could work as an inverted Glyph of Warding. You have to break it to move off of it instead of breaking it to move on to it. This would also allow for different strengths of webs, especially if they can be created by monsters. Shelob's webs should be a lot harder to get out of than random cave spider #7's.

[Nomad]

This is a bit of a tangent, but Derakon just proposed this in the rune-based ID yea or nay thread:

IMO we should replace Acquirement with, like, a jewel-encrusted chest that generates items as if it were 20 levels deeper than where you found the chest. Then not only would there be no point in hoarding things (since chests "remember" where they were generated), but also they'd be a bit more likely to generate something interesting when used early on, which is frankly the only use case that matters.

And that got me thinking about a reworking of chests in general, which would seem to fit thematically in this branch. Currently, chests are pretty boring. The traps on them don't do much to stop you getting in, since if you fail to disarm them you can just repeatedly try again, and the contents are not particularly exciting either - the early ones just contain money, and by the time you start getting decent items out of them, you're deep enough to be swimming in good drops already.

So, I would propose that instead of the current contents, all chests should be guaranteed to contain a single OoD item, with the exact depth of the treasure dependent on the type/level of the chest (e.g. small wooden chest = 3 levels OoD, large wooden chest = 5 levels, small iron chest = 7 levels, etc.). Chest traps would also have to be correspondingly beefed up - every failed disarm attempt should have a chance of destroying the chest contents, and the more OoD the chest treasure, the nastier the trap effects should be - and perhaps chests also made rarer.

Thoughts?

[Nick]

I don't view it as a crutch. I view it as an important graphical representation of @ knowledge. Why is this indicator somehow different than any other indicator of @ state and knowledge? If @ can detect traps, than the gui should indicate the radius. At least, please bring it back as an option. "And so, as Tiny Tim said, 'A Merry Christmas to us all; God bless us, every one!" - Charles Dickens

OK, let me explain. My problem with the detect line is partly that it was emblematic of what trap detection had become, and so removing it was a joyful experience for me. So let's look at this rationally.

I can see the point of having a reminder to the player that they are passing out of their region of knowledge. But with trap detection becoming fairly unimportant, it doesn't seem very sensible to tie it to that. Here are a few options:

• Have a trap detect line exactly as before
• Same, but base it on door/stair detection
• Have a detection region based on where *any* detection has been done - traps, doors, stairs, mapping, monsters
• Same, but make it player-configurable which detection options to include

These seem to me to be in order of what makes most sense - which I guess means that I should implement the last one

Opinions? What have I missed?

[Derakon]

Opinions? What have I missed?

An option that says "interrupt me every time I travel N tiles away from the last time you interrupted me". The problem with using the trap detection line as a reminder to detect monsters is that monsters can spawn in at any time, so you were only mostly safe from unknown monsters if you relied on it.

[Nomad]

• Have a trap detect line exactly as before
• Same, but base it on door/stair detection
• Have a detection region based on where *any* detection has been done - traps, doors, stairs, mapping, monsters
• Same, but make it player-configurable which detection options to include

These seem to me to be in order of what makes most sense - which I guess means that I should implement the last one

Opinions? What have I missed?

I feel like the only type of detection that "needs" a boundary to alert you that you've wandered out of the previously detected zone is the monster detection spell - with Treasure and Doors/Stairs, you can see the positions of the ones you've found marked on the map, and so can make a rough estimate of where the detected region ends. (But I'm also unconvinced drawing a hard boundary line makes as much sense for monster detection, considering monsters can move about and it's not the "this area definitely clear" guarantee it was with traps.)

Maybe rather than reinstating the boundary line, the answer is to mark the spots where you previously detected monsters with some kind of "fuzzy detection" effect? (e.g. perhaps white asterisks for "there was a monster here last time you looked but who knows if it's still there".) That way you've got a visual reminder on the screen that will help you see when you're wandering into unknown territory without having an explicitly drawn boundary.

Another middle option is the equivalent of the "DTrap" detection status in the status bar - even if you don't explicitly mark the boundary on the screen, you can indicate in the status bar that x type of detection has been performed on this area, and perhaps make "interrupt running when leaving detected zones" a game option.

[Ed′]

So, I would propose that instead of the current contents, all chests should be guaranteed to contain a single OoD item, with the exact depth of the treasure dependent on the type/level of the chest (e.g. small wooden chest = 3 levels OoD, large wooden chest = 5 levels, small iron chest = 7 levels, etc.). Chest traps would also have to be correspondingly beefed up - every failed disarm attempt should have a chance of destroying the chest contents, and the more OoD the chest treasure, the nastier the trap effects should be - and perhaps chests also made rarer.

Thoughts?

This change would definitely make me pay more attention to both chests and @'s disarming skills.

I am curious: what was the original rationale for chests? The only thing I can think of based on how they currently work is that they keep some uncertainties about loot in play even after @ gets object detection.

[Nick]

And that got me thinking about a reworking of chests in general, which would seem to fit thematically in this branch. Currently, chests are pretty boring. The traps on them don't do much to stop you getting in, since if you fail to disarm them you can just repeatedly try again, and the contents are not particularly exciting either - the early ones just contain money, and by the time you start getting decent items out of them, you're deep enough to be swimming in good drops already.

So, I would propose that instead of the current contents, all chests should be guaranteed to contain a single OoD item, with the exact depth of the treasure dependent on the type/level of the chest (e.g. small wooden chest = 3 levels OoD, large wooden chest = 5 levels, small iron chest = 7 levels, etc.). Chest traps would also have to be correspondingly beefed up - every failed disarm attempt should have a chance of destroying the chest contents, and the more OoD the chest treasure, the nastier the trap effects should be - and perhaps chests also made rarer.

Chests are much more interesting in other variants (O, initially, followed by NPP and FA); I guess I was kind of assuming we'd do something similar at some point. I'll throw something in to this branch at some point, and we'll see how it looks.