Trap/door feature branch

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

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

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

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

[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

[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

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

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.

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

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

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

[Ingwe Ingweron]

Sorry, actually it doesn't.

As for the trap detection line, it has really lost it's chief purpose; also I think that trap detection will probably end up only in Detection and Clairvoyance.

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?

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?

[Nick]

Nick--I still recommend checking out NPP traps! They are much more effective since they do ranged damage.

It depends on what purpose you want traps to serve. The current intent with the traps on this branch is for them to be obstacles to be overcome if the player wants to get past them - it's presenting a particular type of choice to the player. A trap that is firing from a distance represents a different type of challenge, more like a sentry or a gun-turret. Introducing something like that isn't completely out of the question, but I don't think I'd call it a trap, and I think that particular niche in the dungeon ecology is fairly well covered by monsters.

[Nick]

Should I assume this change breaks savefile compatabilty?

Sorry, actually it doesn't.

As for the trap detection line, it has really lost it's chief purpose; also I think that trap detection will probably end up only in Detection and Clairvoyance.

[Nick]

Doesn't look like these are being generated correctly - I'm still seeing randomly positioned traps in the special rooms.

Yeah, that would be me forgetting to pull the random trap code out. Oops.