Trap/door feature branch

[Ingwe Ingweron]

Nick, here is a savefile for the "Kill Boss, But Don't See Stairs" bug. Basher.zip

Basher, the very lucky Half Troll Warrior, wielding both The One Ring and Ringil, has just killed Morgoth. Look around, you see no stairs. Immediately to @'s left is a ring. Pick it up and there are the stairs. As suspected, somehow items are being created on top of the newly created stairs. I also suspect something similar to this bug is why some pass-wall monster drops are occurring inside walls.

This is in the Nightlies version Oct 15 revision 76734a1

[Ingwe Ingweron]

Okay, here's a really strange bug, or maybe it is a new feature? Play testing the latest nightly and using connected stairs to scum for situations that might produce the pass through walls monsters dropping treasure inside walls. Suddenly, deep in the dungeon, connected stairs are no longer generated. I'm into competition mode with disconnected stairs. Since it's a birth option, how did this bit get flipped?

By the way, the kill Sauron, but don't get stairs bug is, I think, related to the treasure drops inside walls bug. A stack of treasure is also sometimes dropping ontop of the newly created stairs. Since player sees the stack and not the stairs on the map, it looks like stairs were not generated.

[Pete Mack]

It allows call by name, so for an effect in a spell table, you can just map the associated function directly without creating a jump table by hand (or by include file, which is another approach.) It also lets you assemble a call stack by hand, so you can include the correct arguments in a .txt file . It's not that important a feature in any case, just a slightly cool trick.

[Nick]

As an aside, here is a clean way to bind the event handler functions to the values in the edit files.

http://www.dyncall.org/

effects.c is the last remaining giant case block. (And in a somewhat more modern language, it would by a dynamic call by name. That's what lua used to be for.)

So, Pete, I assume you are saying that we can replace a lot of our C preprocessor shenanigans with this dyncall stuff. Can you explain how that would work? I've had a quick look at the documentation and it seems largely to do with calling C functions from other languages.

[Nick]

Rubble effect uses the wrong template (EFINFO_QUAKE requires 1 variable parameter, but the description has none).

Arriving on a level via recall or stairs doesn't detect adjacent traps or secret doors: you have to press '5' to reveal them.

Both fixed in development now. I am going through clearing up bugs posted in the last couple of months; please let me know if I haven't fixed your favourite.

[Bogatyr]

Experience gain for disarming has been changed from a flat 5xp to (cave->depth / 5), so you won't gain xp until you disarm traps below 250ft.

This has a rather significant detrimental effect on (at least some of us)'s start of game quick level gain strategies. Maybe give early game disarming xp gains back to rogues?

One thing about the new trap system is that it really gives rogues a significant benefit for early 100% disarming, which is very nice.

[PowerWyrm]

I don't know if this part of the plan for the new trap system or a bug, but my Gnome Rogue is not getting any experience for disarming traps. I am playing the latest overnight (04 Sep 2016 at 20:47 UTC, revision 2cd83cd).

Thanks
Rick

Experience gain for disarming has been changed from a flat 5xp to (cave->depth / 5), so you won't gain xp until you disarm traps below 250ft.

[Nikodemos]

No Experience

I don't know if this part of the plan for the new trap system or a bug, but my Gnome Rogue is not getting any experience for disarming traps. I am playing the latest overnight (04 Sep 2016 at 20:47 UTC, revision 2cd83cd).

Thanks
Rick

[Bogatyr]

I'm still getting a feel for it.

Having a trap that affects both player and monster creates interesting tactical opportunities for the (temporary) disable traps magic.

Maybe less trap spam in vaults, but maybe the traps are more severe and more targeted, and maybe unavoidable (no disable/disarm possible, except perhaps rogues have a chance), like just surrounding the central key object/squares or the key pathway square between vault rooms

Have some trap-filled vaults perhaps.

One thing about frequent intersection traps is that is makes the digging attribute much more important, as well as 100% disarming ability of rogues.

Maybe a "trap of wonder" for protecting extremely valuable objects, but where one of the side effects is teleport level.

edit: maybe a delayed reaction trap disarmer for those most difficult traps: like a spray-on glue that takes time to set, that over time decreases the percentage chance that a trap will trigger, eventually gumming it up completely.

[Nick]

General observation: the trap/door changes really slow down movement through the dungeon. These changes elevate facing and avoiding traps to be a major, frequent part of the game. While the new traps are interesting, I'm not sure "trap-band" is such a great game. I'd make them much less frequent, or put them in much less important places than corridor intersections.

I haven't experimented enough to know, but I'd hope that something that is so intrusive on the player experience would have an equal effect on monsters. What's the point of having a "disable"-only spell if once the trap re-enables, it doesn't impede monster progress by at least a few turns? If vaults are going to remain absolutely stuffed to the gills with traps, I'd think that monsters within the vaults would be practically immobilized...

Thanks for the feedback. I agree that too many traps is a bad idea.

Maybe the plan with vaults should be to remove fixed trap positions, and have (fewer) traps appear at random locations? As for corridor intersections, I think there can certainly be fewer there too.

Variants have (player-settable) monster traps. I'm thinking maybe it would be good to have some traps affect the player, some affect monsters (or some types of monster) and some affect both player and monsters.

[Bogatyr]

General observation: the trap/door changes really slow down movement through the dungeon. These changes elevate facing and avoiding traps to be a major, frequent part of the game. While the new traps are interesting, I'm not sure "trap-band" is such a great game. I'd make them much less frequent, or put them in much less important places than corridor intersections.

I haven't experimented enough to know, but I'd hope that something that is so intrusive on the player experience would have an equal effect on monsters. What's the point of having a "disable"-only spell if once the trap re-enables, it doesn't impede monster progress by at least a few turns? If vaults are going to remain absolutely stuffed to the gills with traps, I'd think that monsters within the vaults would be practically immobilized...

[Pete Mack]

Amusing minor (non)-exploit:
Use unbarring ways, then disable traps with 'D' command. Traps still won't fire, but they are permanently gone. (It's not really an exploit, since you can just cast the spell again instead.)
Note: for warrior class, this would be brutal. I finally found first Rod of Disable Traps in a vault at level 70...well protected behind a row of 6 otherwise nasty-looking traps.

[PowerWyrm]

Arriving on a level via recall or stairs doesn't detect adjacent traps or secret doors: you have to press '5' to reveal them.

[PowerWyrm]

Rubble effect uses the wrong template (EFINFO_QUAKE requires 1 variable parameter, but the description has none).

[Pete Mack]

I am having memory corruption errors. In one, gcc detected a write to freed memory. In another, the program crashed during monster death when it tried to drop a hopelessly corrupt object. Has anyone done a Sanitize run lately? I am running MinGW, which has a very old version of gcc. (Don't know how well it works on Windows anyway.)