Trap/door feature branch

[Mars]

[bc=black]
     #####     
     #...#     
     #...#     
######[color=cyan]^^^[/color]######
#....[color=cyan]^[/color]###[color=cyan]^[/color]....#
#....[color=cyan]^[/color]#[color=red]*[/color]#[color=cyan]^[/color]....#
#....[color=cyan]^[/color]#[color=#804000]+[/color]#[color=cyan]^[/color]....#
######[color=cyan]^^^[/color]######
     #...#     
     #...#     
     #####     [/bc]

I don't know how complicated this would be, but I had the following thought after seeing this: maybe you should consider separating the trap from the trigger. A single trap can have multiple 'trigger tiles'. Trigger tiles are probably grouped logically.

You trigger a trap by stepping on (or phasing onto) any of its trigger tiles. Whether or not this will permanently 'disable' the trap is a matter of its properties. A boulder dropping from the ceiling would be a 1 time thing, but a dart or magic trap might be loaded for multiple shots.

(Something that might tie into this: a dart (or other projectile) trap could be given a point of origin, from which an actual projectile is fired. Lucky you if a monster just happened to stand in the trajectory of the dart. Spelunky much? )

Anyway, in the example dungeon snippet above, instead of the ^s being 12 individual traps, they would be 4 traps (one along each of the walls).

This could also be applied to (for example) the 'line' or 'room' traps earlier mentioned by Nomad. I think room traps would be especially cool, like filling a room with poison clouds, summoning a horde of trolls, or even collapsing the room in its entirety.

[Pete Mack]

Don't add the detection line on Detect Monsters. I do it MUCH more often than the other two. Detect Doors&Stairs/Magic Mapping is OK. Actually, I suspect I will still try to use Detect Traps as it's the best way to discover Greater Vaults for non-Priest casters.

[Ingwe Ingweron]

I can see the point of having a reminder to the player.... But with trap detection becoming fairly unimportant...

• ...make it player-configurable which detection options to include...

...What have I missed?

Flexibility and choice for the player, where possible, i think are always great and in keeping with Angband's philosophy of people playing in their own way. Personally, I detect monsters more often, but for traps, doors, stairs, I find a reminder helpful, especially since I center the @ and I don't want to waste mana, scrolls, or charges over-lapping that detection.

I do question the idea of trap detection becoming unimportant. I love that traps have and are becoming more interesting. I don't find it unimportant to know where they are. My half-troll warrior might not care much, but my weakling mage really cares quite a bit about being able to detect traps in advance.

Some other general observations on this branch...

- secret doors within rooms/vaults not being detectable. I guess this was done to make exploring the room somehow more interesting, but I've just found it to be artificially tedious. Also, at least I have enough experience to recognize lot's of room types and can usually figure out where doors are, but I think it may unduly burden newer players.

- I guess this is part of the "trap detection unimportant" thing, wherein each trap is known immediately upon stepping next to it and the only danger they pose is in a failure to disarm. I'm still on the fence as to whether this is a good thing. Yes, it removes some of the "gotcha" factor of traps and yes, it makes trap detection less necessary, but I also think something has been lost in the feel of the game. I'm trying to imagine Indiana Jones if just anyone knew and could overcome the traps he faced.

[Ingwe Ingweron]

Getting the message "The (nothing) disappears." When killing some monsters. There is plenty of floor-space, so I don't know if it is a treasure dropping that is ignored, or for some reason things aren't stacking. (Note: this @ has ignored all monies since he's diving ironman. Maybe it is money drops causing the message?)

[Nomad]

Something strange with the chest next to @ in the attached save file - I can see it, select it with the 'l' command and even pick it up and carry it, but it doesn't have the usual "(locked)" tag you get on a - presumably - untrapped chest, and it can't be selected with the Disarm or open commands.

Other minor bugs:

• I've also experienced Ingwe's "The (nothing) disappears." message, in my case while opening a chest in a tight space without room for objects to drop. (I didn't have money squelched, though it could have been some other kind of squelched item.)

• Trying to squelch shop-bought equipment always brings up the "All excellent but not splendid" option rather than the appropriate average/good option. (And if you set the correct level manually from the options menu, the shop-bought items don't squelch.)

• Amulets and rings of searching (and search bonuses in general) still exist in the game, despite the search skill having been removed.

Will write up some longer general thoughts on this branch and the new traps in a little while - I have been playtesting, it's just taken me forever to get a character down to a depth to encounter the deeper-occurring traps. (Not sure whether that's a sign the changes to traps are making the early game harder, or just the RNG being out to get me after my recent winner.)

[Nomad]

Something strange with the chest next to @ in the attached save file - I can see it, select it with the 'l' command and even pick it up and carry it, but it doesn't have the usual "(locked)" tag you get on a - presumably - untrapped chest, and it can't be selected with the Disarm or open commands.

Follow-up thought - it occurs to me I only noticed this problem with the chest after loading a saved file to resume play, so it's possible whatever went wrong happened when the level was reloaded rather than when the chest was generated.

(I feel like there might have been times when I've lost knowledge of floor objects after reloading a save file - i.e. items I've previously encountered no longer being shown on the map until I 'rediscover' them by detecting or walking back into LoS - in several of the 4.1 feature branches, but since I'm usually reloading the game several hours since I was last playing it's hard to be certain. Possibly connected to the player knowledge changes?)

[Nomad]

And now a crash bug. Killed some black puddings in a checkerboard room, stepped onto the subsequent pile of objects, and got the "Assertion failed!" message:

File: obj-identify.c, Line 579
Expression: obj->known

[Nomad]

Okay, finally made it down to 2500' with a character, so, some general observations:

• I don't know whether it's due to increased frequency of traps or the new two-tier disarming skill, but I definitely feel like I'm setting off a lot more traps on disarm attempts than I used to, which does help compensate for not stumbling into unseen ones any more.

• Vault traps are much more interesting/challenging when you don't know where or what they're going to be until you step next to them. Trap detection definitely ought to go. I've been squelching it from the start and haven't missed it.

• I feel like disarming skill rises too quickly, making traps a trivial obstacle too soon. Playing a half-orc rogue I had over 90% disarm success for both types by clevel 25; even as a warrior, by clevel 35 I was on about 85%/60% success. While it makes sense for rogues to escape the trap game sooner than other classes, I feel like disarming should take longer to build to such high success rates, and I'm not convinced classes other than rogues should ever get 100% disarm. (I had a hard time really testing the deeper new traps, because by the time I was actually encountering them I only rarely set traps off.)

More specific thoughts on the new trap types:

• Alarm traps are a great and logical addition. (Seems weird that we didn't have these years ago, really.)
• Rock fall traps are a bit boring, since they're just straight damage. Would it be feasible to have the trap create a pile of rubble when you set it off?
• Earthquake traps are fine, but I never actually set one off by accident, only ever by walking on them deliberately. (See above re: deep traps and disarming skill.)
• Also, "dungeon alteration trap" feels rather clunky as a category name; maybe call them "quake", "cave-in" or "destruction" traps?
• Mine traps are okay, but the "floor explodes around you" message led me to expect it to do some damage to the dungeon floor. Maybe stepping on a mine could transform it into a pit?
• Blast traps are awesome! There should definitely be more traps like this that whack you with multiple effects at once and throw you around the dungeon a bit. Much more interesting.
• Not sure having a saving throw against the mind blast type traps really works. They appear relatively deep, so your saving throw is pretty good by then and the odds of both failing to disarm and failing your saving throw suffer any effects are pretty low.
• Also, the basic mind blast trap doesn't feel very distinct from standard confusion gas. Maybe it could stun rather than (just) confuse?
• Not sure I ever actually encountered the brain smashing variant - I guess being the deepest trap type affects the odds of generation? Maybe it's worth considering a maximum depth on traps as well as a minimum, so things like pits, discoloured spots and basic darts give way to the more interesting types as you get deeper.

And now I'm off to have a go at designing some trap types...

[Nick]

Okay, finally made it down to 2500' with a character, so, some general observations

Thanks very much for all these. My current plan is to tidy up the rune-based ID branch, which will take a bit of time. Then that will come into the master branch, and I'll do a re-issue of the traps branch including rune-based ID, which should make it better to test. Then I'll actually get back to working on the traps branch, which is still fairly sketchy.

• I don't know whether it's due to increased frequency of traps or the new two-tier disarming skill, but I definitely feel like I'm setting off a lot more traps on disarm attempts than I used to, which does help compensate for not stumbling into unseen ones any more.

• Vault traps are much more interesting/challenging when you don't know where or what they're going to be until you step next to them. Trap detection definitely ought to go. I've been squelching it from the start and haven't missed it.

Excellent - this is exactly what I'd hoped.

I feel like disarming skill rises too quickly, making traps a trivial obstacle too soon. Playing a half-orc rogue I had over 90% disarm success for both types by clevel 25; even as a warrior, by clevel 35 I was on about 85%/60% success. While it makes sense for rogues to escape the trap game sooner than other classes, I feel like disarming should take longer to build to such high success rates, and I'm not convinced classes other than rogues should ever get 100% disarm. (I had a hard time really testing the deeper new traps, because by the time I was actually encountering them I only rarely set traps off.)

I don't know - those numbers sound OK to me. Given the increased need to disarm, even 90% disarm success means a non-trivial decision, especially as traps get more interesting.

More specific thoughts on the new trap types

Thanks, that's a really good analysis. These were fairly hastily done, and could do with considerable improvement - although I was pretty pleased with the blast trap

takkaria has done a version of the rock fall trap which does distribute rubble, but I haven't pulled that in yet.

And now I'm off to have a go at designing some trap types...

Excellent. Feel free to redesign the entire list.

The devteam has also been discussing obstacles which aren't traps in the usual sense (like spider webs) too, so any thoughts on those are welcome.

[Nick]

New builds are up for Windows and OS X, which break savefiles and include all changes in the current master branch, including rune-based ID.

The rest of the changes consist of a bunch of cool new traps by takkaria, and the code to support them. There are no new bugfixes.

Please play and give opinions. Suggested new traps and improvements to existing ones are most welcome.

[Mars]

New builds are up for Windows and OS X, which break savefiles and include all changes in the current master branch, including rune-based ID.

The rest of the changes consist of a bunch of cool new traps by takkaria, and the code to support them. There are no new bugfixes.

Please play and give opinions. Suggested new traps and improvements to existing ones are most welcome.

I'm playing on this build (Windows) and I'm getting errors while throwing stuff from the ground (Assertion failed - obj-pile.c line 134). In the supplied savefile, my char is standing on a stack of iron shots. You can reproduce the crash by repeatedly throwing these iron shots in a general direction.

[Nick]

I'm playing on this build (Windows) and I'm getting errors while throwing stuff from the ground (Assertion failed - obj-pile.c line 134). In the supplied savefile, my char is standing on a stack of iron shots. You can reproduce the crash by repeatedly throwing these iron shots in a general direction.

Excellent, thank you - that bug is fixed, and I suspect it has probably fixed a number of reported crashes (any time an object went from the ground to somewhere else on the ground and then broke).

There are new builds for Windows and OS X up with this latest fix and a new trap.

[Nick]

...and new builds again, Windows and OS X, with a fix to the "the (nothing) disappears" bug from master, plus a rework of chests so they're much rarer and much more valuable.

This branch will probably be pulled into master soon.

[Nomad]

Repeatable crash whenever I take one step to the right in this save file. (If you use the debug commands to light up the room, you can see there's a chest there - stepping next to it while the room is dark and you only have radius 1 light triggers the crash, but if you use debug commands to either illuminate the room or give yourself a lantern, you can see and approach the chest without a crash.)

[Nick]

Repeatable crash whenever I take one step to the right in this save file. (If you use the debug commands to light up the room, you can see there's a chest there - stepping next to it while the room is dark and you only have radius 1 light triggers the crash, but if you use debug commands to either illuminate the room or give yourself a lantern, you can see and approach the chest without a crash.)

Excellent, thank you - bug found and fixed. The problem was essentially that after moving the player was searching for chest traps before looking around and seeing the chest.