The Layonara Trap Limiter v. 0.5 (alpha)

[darkstorme]

The reasons given for limiting trap use through ridiculous crafting requirements are all very much valid.  Spamming traps is a cheap way to win a fight, and it's reprehensible to hide behind the "in real life, my character would set ten thousand traps, because he believes in having the upper hand!" excuse.  It takes 5 seconds (or so) RL to set a trap.  If it were real, it'd probably take a few minutes of careful work.  Odds are, when laying traps, your rogue/ranger/whatever does not have a few days to properly prepare a region.  (If they did, this could surely be managed through DM intervention.)

But, of course, at this point, you're saying "But Darkstorme!  You wouldn't start a new thread just to rehash a dead topic!"  Ahhh, you're a clever one.  No, I wouldn't.  Ladies, gentlemen, and unearthly beings of indeterminate gender, allow me to introduce the Darkstorme trapcount limiter version 0.5!  (It's in the zip file attached to this post.)

What the trap limiter (demo module) does:
- In the demo, you can only set three traps.
- Upon setting the fourth, the trap vanishes, and you receive the trap kit back.
- Uses no heartbeat scripts
- DOES use a large switch statement, but that runs in O(1) - or as close as one can get to O(1) in NWScript.

What it does not do:
- Decrement the trap count on an individual, upon the disarmnament/triggering of a set trap.

And herein lies the problem/challenge to those wiser in the use of the Toolset than I.

I have an easy solution for triggering, but that leaves disabling... which would, I presume, be used almost as frequently.  So, the options are as follows:  (a) implement a decrement counter in the trap scripts (minimal cycles used, I believe, with the structure defined as in "traptriggered" (in the module)) or (b) someone can tell me how to configure the 2da to replace the traps set by the trap kits with near-identical duplicates which have their onTriggered and onDisabled script slots full.  That would make this a trivial implementation.

Now, what is my goal with all this?  The same as I stated in the above-referenced thread - the lowering of the materiel cost for trap kits.  With the trap limiter in place, the trap-spam abuse becomes a thing of the past, and traps can resume their RP and tactical role.

I await your adulation - throw True, not flowers, please...  (Or, if you hate the idea, flame me.  Either way, I'd like to know opinions - but do try the module first.)

[Leanthar]

How do we put this in an RP light? By that I mean, what is the reason that they can only have three traps ever set at one time (an in-game RP reason). Any ideas on that sort of thing?

[steverimmer]

I suppose one of the things that a 'three trap' limit would represent is the time and preparation to actually prepare the area for the trap, assemble and arm it.  Its something that isn't represented at all in NWN whereas in actuality it would take probably a considerable period of time to actually set three traps.

As we can't actually increase the time it takes for a rogue to set a trap to reflect this, then this would seem to be another valid way for this limitation to manifest itself in the game.  (ie: convert the time taken to set a number of traps to the amount that can be set within a reasonable period of time)

To illustrate this look at what would have to be done to set a basic 'Spike Trap'.

1.  Find a suitable area to set the trap - This I suppose is obvious, the ground/wall/ceiling would have to be firm enough to support the completed trap.  Not only that but it'd have to also keep it steady when the trap 'fires' as well, to ensure that the spikes all travel in the desired direction, at the velocity required to penetrate armour and flesh.  If the trap was buried in loose sand for instance, then when the spikes fire they might fly out all over the place as the sand liquefies due to the shock waves travelling through it.  Perhaps missing the creature completely or even hitting party members.  Also the spikes may not have enough force to penetrate armour due to the sand absorbing some of the kenetic energy of the spikes.

2. Prepare the area - The area would then have to be prepared.  You'd need a clean flat surface to actually assemble the trap and to make sure you never lost that inevitable small vital componant that ony seems to exist in order to get lost.  You'd need to drill holes for spikes, darts, flasks of chemicals etc.  You'd need to string up any wires you needed and conceal them as well.

3.  Assemble the trap - The trap would than have to be assembled from the already prepared componant parts.  I've always seen traps on a PC as being carried 'Flat Pack' style for ease of carrying.  So you'd have to get all the bits out, making sure they're not damaged and if they are replacing them.  Then actually assembling the trap itself, which would take time, especially if you need to test parts of it as you go.  Hopefully you won't lose parts of the trap but don't forget it could be a dark dank dungeon with many powerful creatures just around the corner, so you'll be tense and stressed, consequently mistakes are almost certain to happen.

4.  Conceal the trap - Obviously the trap must be hidden otherwise no one will go near it (unless they're a dwarf ).  This means scouring the area for debris that can be used for concealment, something you couldn't  really prepare  for beforehand as the items used would  have to fit in with the area.

All this would take time.  Multiply all that by three and suddenly you have a lot of time.  So a three trap limit doesn't seem like a bad suggestion to me

[Faldred]

Leanthar - 10/13/2006  7:35 AM

How do we put this in an RP light? By that I mean, what is the reason that they can only have three traps ever set at one time (an in-game RP reason). Any ideas on that sort of thing?

Think of it as the maximum number of traps that can be set, camoflauged, and maintained at once.  (What's the point of setting the "Uber-trap of Doom" if a mouse scurries over it and sets it off prematurely?)  Any more traps than that, and keeping an eye on all of them at once becomes untenable.

What would be even better, though this becomes a "heartbeat" action, is to set a maximum time a player-set trap can be active, which will prevent unsprung and unrecovered traps from littering the grounds.  Once expired, it turns into a normal "dropped" item, subject to the next cleanup script unless recovered.

[Dorganath]

I'm not yet ready to make any comments one way or the other on the need or utility of this system, whether it will address the issue at hand, along with a corresponding balancing of CNR recipes for traps.
  However, I will point out something rather annoying about traps in general that I learned when doing the respawing locked/trapped door and chest system. The OnTrapTriggered doesn't work as one would hope, in that it completely overrides the trap's triggering mechanism. The good news is, this allows for custom trap effects. The bad news is that if you attach a script to this event, that script needs to handle he trap effects as well, or the trap itself will do nothing. Of course, what I am referencing there is the actual placed trap itself, not the trap inventory object, which I have not worked with as yet. For my own purposes, I think it was the OnUsed event of the trap that did what I needed in relation to the trap being triggered.
  I don't know if that helps you or not, and perhaps you were already aware of it, but I thought I'd mention just in case.

[laurabunny]

I have absolutely no idea if this would be possible... but rather than the last trap disappearing and being returned to your inventory, is there any way to do this: Upon setting a fourth trap, the first trap set is either activated, or becomes a dropped item? That way, rather than it being impossible to ~set~ more than three traps, it's actually impossible to ~maintain~ more than three traps (fitting in with what Faldred said).  Of course, I've never even looked at the Toolset, so I'm totally clueless as to what you can actually do with it.  I'm just an ideas woman. ^_^

[darkstorme]

In reverse order, then:

@laurabunny - yes, that'd be quite possible.  It'd involve a little bit of local-variable shuffling, but it's quite straightforward to allow a character to keep a digital "eye" on the traps they've set, and disable/disarm/render hostile the first trap in the list, in the event that they set a fourth.  My current conservative setup was mechanics-based only - the cost of a trap being what it is, I imagined that the character setting it would be pissed to lose a potentially recoverable trap.

@Dorg - I gathered that, (the OnTrapTriggered, that is) through my experimentation.  If this is going to be implemented, I'd simply override the default trap scripts with a low-weight include and a quick check to see if it's a PC-set or GM/designer-set trap.  The problem I have is overriding the traps (as set by the trap kits).  There's no space in the 2da for a default "onDisarm" script.  If onUsed covers the onDisarm case and can be set in an override 2da... well, I'll PM you about that, because that would make the whole thing perfectly implementable.

@ Faldred, Steverimmer - Those are all excellent suggestions - and prompts me to make an addendum of my own.  A given rogue/ranger/person with cross-class trap-setting skills might be more capable of monitoring a "trap line" than others.  Ergo, the limit could easily be made stat-dependant.  Intelligence, or Wisdom-based, perhaps.  It would indicate having the patience to monitor/maintain however many traps you're allowed.  Something like the language limit, but more mechanics-based.

@ L - I actually *blush* hadn't thought of an RP light for it, so I credit Faldred and steverimmer with lovely insight.  I thought of it as a mechanical fix to improve a different fix which was non-RP - the inflated cost of trap construction, as defined earlier.  A minor tangle trap, for instance, would essentially be a snare - which doesn't take that much to build.  Likewise, a simple spike trap is essentially a sharpened mousetrap.  And with the prevalance of alchemist's fire and beetles who spit acid, those traps would be similarly easy to construct kits for - for the trivial ones, anyway.  As the traps get more lethal, naturally they'd become more difficult to build.  But right now, building traps of any sort is prohibitively expensive, and I thought this might obviate that bar to craft-related and in-quest RP.

Regardless, good feedback, and I'll improve the system a smidge further before I post it up again.  The one thing still bugging me is the lack of a disarm event being fired, but if the onUsed tag trigger could work, I'll look into it.  Keep the comments coming, people!

[Faldred]

darkstorme - 10/13/2006  12:40 PM  A given rogue/ranger/person with cross-class trap-setting skills might be more capable of monitoring a "trap line" than others.  Ergo, the limit could easily be made stat-dependant.  Intelligence, or Wisdom-based, perhaps.  It would indicate having the patience to monitor/maintain however many traps you're allowed.  Something like the language limit, but more mechanics-based.

 It might need to be a combination of Set Trap skill, ability score(s) (I can see arguments for either INT or WIS, or both) vs. the combined trap DCs to be "monitored"; i.e., it's not so much the sheer number, but also the complexity of the traps that matter.  If you're going to re-do the trap system, might as well go "whole hog", right?  Continuing down the road of devious game balancing, trap setting may need to have increased chances or consequences of failue and/or spectactular failure, up to and including (if possible) eliminating "take 20" on trap setting ("take 10" may be acceptable if the conditions warrant).  By consequences, I mean something like:

Normal failure (fails the DC or rolls a "1" on a "certain" success) - trap is not set
Significant failure (fails the DC by X or more) - trap is broken, removed from inventory
Spectacular faiilure (fails the DC by 2X or more) - trap goes off, all within range potentially subject to full trap effects
[/list]

[steverimmer]

up to and including (if possible) eliminating "take 20" on trap setting ("take 10" may be acceptable if the conditions warrant).  

I'd be against this...don't forget those rogues who take the Rogues Feat 'Skill Mastery' specifically to get an automatic 'take 20'.

[Faldred]

steverimmer - 10/13/2006  1:38 PM

up to and including (if possible) eliminating "take 20" on trap setting ("take 10" may be acceptable if the conditions warrant).  

I'd be against this...don't forget those rogues who take the Rogues Feat 'Skill Mastery' specifically to get an automatic 'take 20'.

Then "Skill Mastery" would finally be a feat worth taking.  

[darkstorme]

Well, since I've got a check going on when the trap is set anyway, redefining failures (spectacular and otherwise) would actually be fairly trivial.  You'd still get the artifact of the trap appearing briefly, but you could subsequently do whatever you wanted.  The only problem is that it would be a second roll.

Eliminating "Take 20" is a bit trickier, as it's a part of the engine/game mechanics.

Regardless, until the "disable trap" problem is obviated, it would be impractical to implement this.

However, these are all good suggestions, and I'll look into how expensive incorporating them would be.

(Expensive computationally.  Cycles are important in a PW setting.  It doesn't COST anything. *laughs*)

[J-ser]

Faldred - 10/13/2006  1:54 PM

steverimmer - 10/13/2006  1:38 PM

up to and including (if possible) eliminating "take 20" on trap setting ("take 10" may be acceptable if the conditions warrant).  

I'd be against this...don't forget those rogues who take the Rogues Feat 'Skill Mastery' specifically to get an automatic 'take 20'.

Then "Skill Mastery" would finally be a feat worth taking.  

Right now its worthless. When are you trying to open a door or set a trap in combat? Love the idea, though I haven't had time to try the module.

[steverimmer]

Right now its worthless. When are you trying to open a door or set a trap in combat? Love the idea, though I haven't had time to try the module.

Oh Buppi has...In fact the reason she originally took it was because of a quest were most of the party died and she couldn't unlock a door because of all the combat

[Nehetsrev]

I'd be against it simply for the fact that I already stumble across too many traps set right on transition points in the town of Hlint and other high-traffic areas.  Unless if course, you can have the traps start displaying the name of the character that set the trap when they're triggered so I and others can report violations of the server rules regarding PvP.  Thankfully such abusively placed traps I've stumbled onto have mainly been of the slowing variety rather than those that do physical damage, but I've encountered a couple of those too.

[darkstorme]

Nehetsrev - 10/13/2006  7:00 PM

I'd be against it simply for the fact that I already stumble across too many traps set right on transition points in the town of Hlint and other high-traffic areas.  Unless if course, you can have the traps start displaying the name of the character that set the trap when they're triggered so I and others can report violations of the server rules regarding PvP.  Thankfully such abusively placed traps I've stumbled onto have mainly been of the slowing variety rather than those that do physical damage, but I've encountered a couple of those too.

Actually, having the trap call out the name of the person who set it is quite straightforward, so that could indeed be done - though if it's a slowing trap, it may be set with mischief in mind, and be placed in a high-traffic area deliberately.  *chuckles*

[Serissa]

Ferrit has it, too, and would love to have traps worth setting

[Nehetsrev]

darkstorme - 10/13/2006  6:08 PM

Nehetsrev - 10/13/2006  7:00 PM

I'd be against it simply for the fact that I already stumble across too many traps set right on transition points in the town of Hlint and other high-traffic areas.  Unless if course, you can have the traps start displaying the name of the character that set the trap when they're triggered so I and others can report violations of the server rules regarding PvP.  Thankfully such abusively placed traps I've stumbled onto have mainly been of the slowing variety rather than those that do physical damage, but I've encountered a couple of those too.

Actually, having the trap call out the name of the person who set it is quite straightforward, so that could indeed be done - though if it's a slowing trap, it may be set with mischief in mind, and be placed in a high-traffic area deliberately.  *chuckles*

I'm sure the traps I've stumbled across have indeed been placed with mishief in mind, however, it's still a violation of PvP rules if you ask me.  For instance, my character couldn't get away with throwing a bag of choking powder at some other PC even if my character had good reason to do so, yet choking powder doesn't do any permanent damage either, does it?  My point being that PC's who can set traps should not be setting them against other PC's without good RP reason -AND- DM/GM supervision.  Lastly, traps should not -ever- be placed on the spot where a PC comes out of an area transition because it does not afford that PC even the slightest opportunity to spot and avoid/disarm the trap before it is triggered, and placing a trap in such a place is simply an ABUSE of the game engine.  Get my points now?

[Acacea]

Nehetsrev - 10/16/2006  5:12 PM
For instance, my character couldn't get away with throwing a bag of choking powder at some other PC even if my character had good reason to do so

Sure could. It's harmless. Acacea is usually armed with a few for mischief reasons. Not that that seems quite topic relevant.

For clarification, I agree completely about traps on transitions, and damaging traps anywhere in high traffic areas. I simply see no comparison between transition traps and spells like stinking cloud, grease, or darkness. Pretty large jump.

[Dorganath]

The legality and problems with setting traps, tossing choking powder or whatever is beyond the scope of this thread, really. The issue at hand here is a system that would limit trap-setting as an effort to re-balance trap crafting.  
  As things stand now, the primary complaint about trap crafting is that they take a lot of materials to craft, and part of that reason is to balance traps in general so that they're not mass-produced, spammed and used as an "I win" button.
  The question in my mind is whether this really addresses the overall concern, whether some other method would work better and with fewer possible problems. For example, I see persistence being an issue with this proposal, as server resets tend to muck up things like this unless we force the traps to recreate themselves upon reset, which in itself may cause other issues.
  One other suggestion that has been made (by Pen N Popper) was to base trap crafting on traps themselves, where the more powerful traps would require less powerful traps as an ingredient, which would make trap crafting be more like trap upgrading.
  At this point, I don't have any strong opinions one way or the other, and the final balancing decisions will likely not be mine. However, I would want whatever solution that gets green-lighted for implementation to make sense, both for the problem it is intended to address and also within the context of Layonara as a PW.

[steverimmer]

I actually like the suggestion were more complex traps require less complex ones in their manufacture.  It does seem to have a logic to it.  However I just want to note that when I used to play Buppi she did use a lot of traps, usually in quests, but even when she used more than one at a time she never actually managed to kill a monster with them.

You've got to realise that a pure rogue is a fairly weak character by his/herself.  Buppi is nearly level 15 and going down the red light mines alone will kill her.  My druid could manage it easily at level 4.  Yes a rogue has a great sneak attack but they get one chance at that, after which they are at a great disadvantage.  

When you consider a wizard at the same level as Buppi can easily wipe out a spawn of creatures, if she attempted anything like that she would usually die.  Traps are a way to balance this to some degree and if the amount of traps that could be set at one time where restricted, then it would be hard to abuse them.