Talking about the affects system on IMC triggered a side discussion about traps because they currently use one of the object values to set flags for them. Ugly in and of itself, but it led to a short examination of the trap system as a whole. It is freakishly complex, at least in how setting and creating them comes about. Even with the updated FUSS reset system helping out. So it looks as though there's now motivation from someone ( dunno who yet ) to gut the existing trap support and replace it with a much simpler system. It doesn't help any that most of the trap system is not even implemented properly.

What I'm proposing is a simple system that uses the existing objects + rooms. Yes, you're supposed to be able to trap a room too but it doesn't appear the code even exists to make that work. Go figure. Setting a trap would be reduced to something like this:

1. Create a normal object/room as usual. Container, doorway, weapon, whatever.
2. Instead of hacking in a trap reset, simply set the ITEM_TRAPPED flag.
3. Set data on the trap itself, either with a separate command or with added options in oset/redit.

No more fussing with silly resets that generate bogus objects that may or may not work.

Trap triggers that exist currently in mud.h can stay, and in theory it should be much simpler to actually check something for a trap. So if you try to unlock a chest, have the unlock command check the container for ITEM_TRAPPED. If it's there, spring the trap appropriately. Seems simple enough, yes?

Just out of curiosity, I checked Alsherok to see if we ever used traps. A total of 6 show up, and most of them don't function at all. Kayle guessed people may not even use traps because they're a bitch to setup. Well, I'm guessing that even if they did, most don't work

Samson said:

Kayle guessed people may not even use traps because they're a bitch to setup.

Tbh, I never even noticed there were traps in Smaug. So I looked it up, there's a couple of good help files that explain everything you need to know, pretty straightforward except for one thing.

The trapsetting help file says this;

Parameters:    

Ok, but what's the command/syntax? Or is this the problem you're trying to resolve to make it easier? I'd use them if I knew how

It's quite a bit more than just bogus helpfiles really.

The trapsetting one you found for instance. There is no command. It all has to be done through resets. Even then, once made, a great deal more than half of the triggers don't function. There's no direct object or anything like that. The entire system really looks like it was only half finished, and what's here is needlessly complex. But that seems par for the course with Smaug

I like the idea of revising the way traps are handled, but I'm going to need to sit down and flesh out a real plan before I make a real suggestion.

K. So I got around to this a lot sooner than I thought.

Traps in D&D have the following information normally.

Type - Tends to be Mechanical or Magical
Disarm Difficulty - How hard it is to disarm the trap.
Search Difficulty - How hard it is to detect that a trap is present.
Damage - Amount of damage dealt. We could recycle the same dice formula stuff for this as we use with spells.
Type of Damage - Spike, Pit, Arrow, Spear, spiked pit, etc.
If it's a pit trap or the like, it generally has a depth which only adds to the damage that individual trap does.
If it's a magic trap, it tracks the spell that the trap casts

For our purposes, we'll need to also keep track of the following.
Some form of ID - so that traps aren't exclusive the the obj/room they're made for and there's some form of reusability.
Triggers - What makes the trap fire.
Flags - I dunno, It has these currently, maybe we don't need them?

Things that should be trappable:
Rooms, Objects, Doors/Exits

Rooms you could apply things like pits in the floor, arrows shooting from the walls, etc.
Objects could be locked and they shoot a fireball out when you try and unlock them, etc.
Doors/Exits could be locked, or the trap could fire when the door is opened or closed, etc.

We'll need a command to create, and set values on the traps, and the ability to either apply the traps to things with this command, or additions to oset/redit for applying traps to things.

And I think that's enough outta me for now.

Well although I didn't test the reset part of it.

I did take an object and set it to type trap

v0 - Charges
v1 - Trap Types
v2 - Level
v3 - Trap Flags

Trap Types:
  ------------------------------------------------------
 | Num. | Description     | Num. | Description          |
  ------------------------------------------------------
 |   1  | Poison gas      |   7  | Sleeping gas         |
 |   2  | Poison dart     |   8  | Flame                |
 |   3  | Poison needle   |   9  | Explosion            |
 |   4  | Poison dagger   |  10  | Acid Spray           |
 |   5  | Poison arrow    |  11  | Electric Shock       |
 |   6  | Blindness gas   |  12  | Blade                |
  ------------------------------------------------------

Trap Flag | Description
-------------------------------------------------------
      ROOM | Trap is in a room
       OBJ | Trap is on an object
     ENTER | Trap is triggered by entering the room
     LEAVE | Trap is triggered by leaving the room
      OPEN | Trap is triggered by opening
     CLOSE | Trap is triggered by closing
       GET | Trap is triggered by getting the object
       PUT | Trap is triggered by putting the object
   EXAMINE | Trap is triggered by examining the object
      PICK | Trap is triggered by picking the object
    UNLOCK | Trap is triggered by unlocking the object
     NORTH | Trap is triggered by moving north
     SOUTH | Trap is triggered by moving south
      EAST | Trap is triggered by moving east
      WEST | Trap is triggered by moving west
        UP | Trap is triggered by moving up
      DOWN | Trap is triggered by moving down
        NE | Trap is triggered by moving northeast
        NW | Trap is triggered by moving northwest
        SE | Trap is triggered by moving southeast
        SW | Trap is triggered by moving southwest

Following that the trap did go off as expected, I flagged it as ROOM and LEAVE so v3 got set to 9. v1 I set to 1. v0 I set to 1 and v2 I set to 100. Then I dropped the object in a room and left the room and the trap hit me with poison gas lol.

Yeah, I think the room enter/leave triggers are about all that does work right.

I like Kayle's idea of making traps into separate entities. So you can create a set of generic traps and be able to assign them to various rooms and/or objects without having to keep setting the same data on them all over and over again. Something I always found terribly boring. The system should obviously retain the freedom to pick and choose what types you can make and what affects can be added. The existing set of data you listed from the helps is still applicable.

Leaving death traps aside for a moment, in the old ROM based mud I played the traps were indeed entities unto themselves (i.e.; dwarven trap, spring trap). Players could find them randomly by killing NPC's and looting off their corpses. The only ones that could use them however was a certain class with a 'set trap' skill (or maybe it was 'arm trap', I forget). They could set the trap, place it in a room or on an exit and typically wait for an NPC to walk into it (using them against real players was a no no). The same class also had the skill to 'disarm trap'.

If that's what you're thinking I like it. Let the players play with them rather than builders adding them in, well, except as objects. It would require additional fields to oset (or a new tset?) in order to add the additional parameters above. IMHO, I don't think Level is required.

One thing I haven't seen any information about is how much damage is dealt per trap type. Perhaps 'trap dam' could also be an additional data parameter rather than it being a set amount.

I flagged it as ROOM and LEAVE so v3 got set to 9.

Huh? I'm missing something, or the help files are missing something, how does ROOM and LEAVE = 9?? Small point here, make sure to write explicit help files for the builders

Huh? I'm missing something, or the help files are missing something, how does ROOM and LEAVE = 9?? Small point here, make sure to write explicit help files for the builders

These are used as BV which means that for each one you take the last one and * 2 for the current one so

ROOM = 1
OBJ = 2
ENTER = 4
LEAVE = 8

So if you want it to be room and leave you have to add the values together so 8+1 = 9

oi !

How about that gets simplified? lol

There's no reason the flags have to be left to binary arithmetic; the only reason it is that way is because values are stored in the object values section and people were lazy about introducing special handling for this object type. It might as well work the same way as normal flags, where you add/remove named flags.

I'm pretty sure the random type for smaug traps worked. I played a smaug based mud where a builder had set a couple room exits with a random and they seem to work pretty well. Everytime the area updated the exits would be all mixed up.

(Woah, signature image overload.)

I didn't quite grasp the size of them when I put them in, sorry. there gone now:p

Randomized exits isn't a part of the trap system, that's actually just a standard building tool. Most people use it for mazes, or for shifting deserts and the like.

You know, in the stock areas (dwarven daycare, if memory serves) there's an exploding package that seems to have always worked just fine when you touch it.

Conner said:

You know, in the stock areas (dwarven daycare, if memory serves) there's an exploding package that seems to have always worked just fine when you touch it.

Undoubtedly there are several trap types that *do* work in the existing implementation, our main qualm with it, is the difficulty for builders to interact with the traps, and the seemingly half-implemented approach to making traps.

While several trap types are in fact in place in the code, many of the defined options for them, are not implemented. So we can either rewrite the entire system in a more simple fashion, or we can rig the existing one to work. I'm personally in favor of making it simpler and easier to use then hacking up the existing one to work. I think hacking things together and making them work is the main reason why this project needed to exist in the first place.

Kayle said:

Conner said:

You know, in the stock areas (dwarven daycare, if memory serves) there's an exploding package that seems to have always worked just fine when you touch it.

Undoubtedly there are several trap types that *do* work in the existing implementation, our main qualm with it, is the difficulty for builders to interact with the traps, and the seemingly half-implemented approach to making traps.

I wasn't arguing anything, Kayle. Personally, I'm in favor of rewriting the trap system so that it fully works with more flexibility and simplicity, especially for the sake of builders. What I was responding to was that Samson had said:

Samson said:

Yeah, I think the room enter/leave triggers are about all that does work right.

So I was pointing out that there's at least one other trap trigger that does definitely work.

If the rewrite could allow players to set certain predefined trap types and for the skill remove traps to finally be usable those would be major added bonuses in my opinion too.

Any progress been made on this one?

Not that I'm aware of.