NWNWiki
NWNWiki
3,718
pages
(→‎Rogue only?: Still not emulation & looking at the specialist)
(→‎Flagging vs. Detecting: tested and party is not related to flagging)
 
(2 intermediate revisions by one other user not shown)
Line 84: Line 84:
   
 
:* I'm not sure if this is party dependent. The notes for GetTrappedFlagged() are as follows:
 
:* I'm not sure if this is party dependent. The notes for GetTrappedFlagged() are as follows:
<blockquote>// - oTrapObject: a placeable, door or trigger
+
::: <code>// - oTrapObject: a placeable, door or trigger<br /><!--
// * Returns TRUE if oTrapObject has been flagged as visible to all creatures.</blockquote>
+
-->// * Returns TRUE if oTrapObject has been flagged as visible to all creatures.</code>
 
::Also BioWare doesn't use the flagging system in creature AI in SP (as there is no SetTrappedFlagged(), and the AI does not use the disable skill for flagging). My guess is that flagging a trap would make it visible to everybody, as parties of multiple PCs, like OHS, would have been a later development. [[User:WhiZard|WhiZard]] 16:54, December 23, 2011 (UTC)
 
::Also BioWare doesn't use the flagging system in creature AI in SP (as there is no SetTrappedFlagged(), and the AI does not use the disable skill for flagging). My guess is that flagging a trap would make it visible to everybody, as parties of multiple PCs, like OHS, would have been a later development. [[User:WhiZard|WhiZard]] 16:54, December 23, 2011 (UTC)
   
 
::* Testing different script functions and the default one in SP where party members relay trap visibility to other party members (e.g. the familiars detects the trap, and then its master sees the trap) is by setting the trap as detected by the other party members (exactly the same as, and possibly could be using SetTrapDetectedBy()). What is not passed to the other party members is GetLastTrapDetected() (this only updates its value when the creature naturally detects the trap). The trap is never flagged. What I found to be interesting is that the Lexicon attributes SetTrapDetectedBy() as being 1.67 patch, when NWNexplorer shows it to be from the beginning, NWN:OC. So there could possibly be scripted use of SetTrapDetectedBy() that I am missing. [[User:WhiZard|WhiZard]] 01:13, December 24, 2011 (UTC)
 
::* Testing different script functions and the default one in SP where party members relay trap visibility to other party members (e.g. the familiars detects the trap, and then its master sees the trap) is by setting the trap as detected by the other party members (exactly the same as, and possibly could be using SetTrapDetectedBy()). What is not passed to the other party members is GetLastTrapDetected() (this only updates its value when the creature naturally detects the trap). The trap is never flagged. What I found to be interesting is that the Lexicon attributes SetTrapDetectedBy() as being 1.67 patch, when NWNexplorer shows it to be from the beginning, NWN:OC. So there could possibly be scripted use of SetTrapDetectedBy() that I am missing. [[User:WhiZard|WhiZard]] 01:13, December 24, 2011 (UTC)
  +
  +
::* Yes, that comment ("visible to all creatures") and the lack of a creature parameter to that command does suggest that being in the same party does not matter. So Iconclast's test could be rather easy to pull off without assistance. Just start the dedicated server, log in with the rogue who will detect and flag the trap, log out, then log in with the non-rogue who will try to recover it. Piece of cake. ... Now I'm hungry.... --[[User:The Krit|The Krit]] 00:39, January 13, 2012 (UTC)
  +
  +
:::* Ran said test on my own dedicated server. The rogue set and flagged an epic sonic trap from a trap kit and then logged off. A non-rogue logged on and could see the set trap. "One party only" was not checked. [[User:WhiZard|WhiZard]] 06:20, January 13, 2012 (UTC)

Latest revision as of 06:20, 13 January 2012

Recover DC[]

As posted and confirmed on the forum that

recovering trap DC = 10 + disarming DC

In this the Grimoire is wrong too, do we need another confirmation? I havent added this info yet cause I don't really understand it. -- Chrominium 09:27, 27 Oct 2005 (PDT)

  • I'll confirm and change. (I've played enough Rogues to know that it is much more difficult to recover a trap than to disable it.) --The Krit 12:48, 19 Nov 2005 (PST)

Synergy[]

Regarding the disable trap and set trap synergy, does this depend on base ranks or modified ranks? Harleyquin 11:25, 7 Dec 2005 (PST)

  • Base ranks. Your modified skill is called "skill", not "ranks". (And I have checked this in game.) --The Krit 20:19, 21 Dec 2005 (PST)

Non-rogues[]

Regarding the special comment, would a wizard with high intelligence and enough points in disable trap be able to disarm traps with DCs over 35? Harleyquin 11:21, 5 January 2006 (PST)

  • There is a special factor in disabling a trap with a DC of over 35 that makes it impossible to disable if you don't have at least 1 Rogue level regardless of one's Disable Traps skill. --Countess Terra 13:02, 5 January 2006 (PST)

spectacular failure, find traps spell[]

As far as I know a spectacular failure can happen only if you're in combat. The Find Trap spell will remove traps regardless of the DC (perhaps worth a note). --Kamiryn 01:06, 6 January 2006 (PST)

Disable trap buffs?[]

Do any buffs help the disable trap ability? Intelligence? Dexterity? Does this vary from PW to PW? Worth a comment?

  • The page does say Intelligence. GhostNWN 09:43, 26 April 2006 (PDT)

Rogue only?[]

Someone added the following:

Any character with a high enough skill can Recover any trap, even if the DC to Disable the trap is 35+.

Is that true? I thought only rogues could handle traps with DC 35+. -- Alec Usticke 21:34, 3 August 2006 (PDT)

  • I ran some tests. Apparently the "disarm" and "handle" are not interchangable. I wonder if that's a bug or design? I'll submit a bug report on it and let BioWare decide. --The Krit 07:32, 23 August 2006 (PDT)
  • I have these findings
Some traps can be marked not disarmable. If this is the case, these traps cannot be disabled or recovered by the character but can be flagged and examined provided the search DC is met.

Some traps are marked disarmable. If this is the case a non-rogue can see the trap only if the search DC is 35 or less. If he detects it and the disable DC is 36 or above they cannot be disabled, but can be flagged, examined, and recovered.
WhiZard 20:56, 4 April 2009 (UTC)
  • True, the ability to mark traps as not disarmable is not mentioned in the article. I'll add that. --The Krit 17:15, 20 April 2009 (UTC)

The barrier preventing a wiz (or sorc) from recovering traps with DCs over 35 is the rogue-detection limitation. However, possessing the pixie to detect and flag one of these will allow the wiz to recover it once the possession is halted (with ample Disable trap skill level and a pixie of high enough Search level to detect it). Not a particularly remarkable exception but these 2 classes do have an innate ability to handle high DC traps beyond all other classes than rogue by emulating one. The vanilla Find traps spell makes this all unnecessary, however, for any class with the ability to cast the spell or use an item that contains it... unless the goal is to recover them for later use. --Iconclast 02:30, December 23, 2011 (UTC)

  • By "DCs over 35" you mean "both detection and disabling DCs over 35"? (For example, a strong fire trap with detection DC 22 and disarm DC 36 can be detected and recovered by any class.) Also, possessing a pixie familiar is not "emulating" a rogue, as there is no emulation -- the pixie has rogue levels; the pixie is a rogue. Otherwise, sure, the pixie familiar is often chosen for its trap- and lock- handling abilities (which are on par with a traditional rogue of the master's level, up to level 30). --The Krit 07:51, December 23, 2011 (UTC)
  • I was referring specifically to the detection DCs, primarily the epic ones, (re: DC 43) which would preclude all non-rogue class builds from recovering them. Not so with the use of pixie possession. Disarming all traps, including epic ones is not an issue with the Find traps spell so neither detection nor disarming is an issue. Recovering them to use later is.
Should trap detection DCs of non-epic traps be customized by a designer, they could also fall into this same category... undetectable... and therefore unrecoverable by all classes except rogue, wiz & sorc.
And yes, the pixie familiar is a rogue, as is the panther. However, the toon itself borrows, or emulates (or whatever term you prefer) the class attributes of a summon to temporarily gain the benefits, in this case, to detect traps that the toon itself could not and then flagging it for further disposition of the wiz. The inference of the current rogue detection/disarm restriction is that unless rogue levels are elected in a build, epic traps cannot be detected and therefore not accessible. This is simply not so. That's the only point I was making. Just as a toon that polymorphs into an iron golem isn't actually an iron golem, just emulating one temporarily. The character itself still remains whatever class (or classes) its innate build dictates.
A wiz or sorc can be be designed to be an epic trap specialist without rogue levels. Detection DCs over 35 need not prevent ALL non-rogue characters (meaning "builds" within this context) from recovering epic traps (or custom high-detection DC ones). For the non-rogue classes except wiz & sorc, handling epic traps, in any way, shape or form is beyond the scope of their ability. --Iconclast 16:40, December 23, 2011 (UTC)
  • I still do not see the character borrowing nor emulating the class attributes of a summon. The character does not become the familiar; the character merely tells the familiar what to do through mental commands (implemented by the player controlling the pixie rogue instead of controlling the human/elf/whatever mage for the duration of the possession). It is still the pixie, not the mage, who handles the traps. This is not that much different than using a rogue henchman to detect traps, and rogue henchmen can be used by any class (if the module provides such a henchman). There is just finer control with the familiar, and you know in advance that this particular rogue associate is (probably) going to be available.
Unless a character has rogue levels, that character cannot detect (standard) epic traps. That implication is true. The inference that a player will be unable to deal with epic traps is false, as the pixie familiar is one option, multiplayer is another, and the module may provide yet other options. (It might be a little cheap to rely on the module providing options, but on the other hand, it is the module that places the epic traps in the first place.) A good builder should be aware of what can be used to augment the character being built, and this includes choosing a familiar that will fill a needed role. In that respect, you are correct — mages have innate access to other classes and races via their familiars, and good builders should consider that when designing a character build. --The Krit 00:26, January 13, 2012 (UTC)
  • Now thinking about this hypothetical wizard/sorcerer epic trap specialist. Yes, it is possible, but it is a fairly esoteric possibility. The DC for recovering a standard epic trap is 68, requiring a skill of 48. Without rogue or assassin levels, and disregarding bonuses from (module-specific) items, your specialist can have 21 disable trap ranks, plus 13 from feats and 2 from synergy, leaving 12 needed from the intelligence modifier (making sorcerer look like a bad choice). Furthermore, this character is not going to be recovering epic traps until rather late in its career (level 39, when epic skill focus would first be available). Not a problem if you start at level 40, but could be a deal-breaker for those wanting to play lower epic levels. (Unless bard song could be used? Seems like a weak class split, though, if you take enough bard levels to get a significant skill bonus, and enough mage levels to get a pixie capable of detecting those traps.)
Of course, I did add a "no assassin" clause. You could make a wizard/assassin with a highish death attack DC (thus justifying assassin over rogue) who would then be able to advance disable trap as a class skill. Or maybe choose assassin to get sneak attack damage without a multiclass XP penalty? In any event, if you want to recover epic traps by the mid-epics, you are going to need rogue or assassin levels or pretty hefty skill-boosting items. (And having rogue levels brings the convenience of being able to (on your own) detect the traps you plan to recover.) --The Krit 00:26, January 13, 2012 (UTC)

Examane traps[]

What info do you get when you examane traps? Is it just bare bones info? Do you get better info the better your roll vs the DC? Should this info be put into the article? Grom56 03:49, 25 July 2009 (UTC)

  • You are told the type of trap (frost, holy, etc.) and the strength (minor, average, etc.) and are given some nice flavor text describing the mechanism. (Just try it in the game to see what the text is. Maybe grab a screenshot while you're at it.) How much your die roll beats the DC does not matter. --The Krit 16:27, 25 July 2009 (UTC)
  • Thanks TK. I'll do that next time I'm in game with a Rogue. Grom56 02:53, 26 July 2009 (UTC)

Flagging vs. Detecting[]

If a rogue detects an epic trap and then flags it, can a non-rogue member of his party recover the flagged epic trap assuming that member has achieved an adequate Disable trap skill level by some means? This eventuality/scenario is virtually impossible for me to test without assistance. --Iconclast 10:40, December 4, 2011 (UTC)

  • First, not impossible to test. There are two unrelated DCs involved; the DC to detect the trap has no relation to the DC to disable it. So you could give an epic trap a detection DC of, say, 1, which should have the same result as having it be flagged by a rogue. Leave the disable DC alone, and you have the scenario you want. Second, any class can recover any trap: "The special prohibition involving rogues only applies to disarming a trap. Any class can successfully examine, flag, or recover any trap, provided the skill check is passed." So, sure, the non-rogue could recover it. --The Krit 11:23, December 4, 2011 (UTC)
So... the way you've described this, Flagged=Visible=Detected. Though I've flagged traps before I have never been in a party where someone else has, so would be unaware if there is a difference between flagged and detected. That would mean that a flagged trap can be assessed or recovered by any of the non-rogue members of the party, right? Like I stated, it is impossible for me to simulate encountering a trap flagged by a member of my party to notice any difference (unless I could get some help via LAN or MP elsewhere). But if they (flagged/visible/detected) are all terms for the identical trap status, then there is no issue for me any longer, TK.--Iconclast 17:57, December 5, 2011 (UTC)
  • Well, transitivity might fail somewhere in that equation (does flagged=detected? I forget what happens if the flagger leaves the party), but roughly that is the gist. If a trap is detected by the search skill, that trap becomes visible. If a trap is flagged by a party member, that trap becomes visible. If a script decides to mark a trap as visible, that trap becomes visible. If you turn on DebugMode, all traps become visible. In all of these scenarios, the trap becomes visible, and being visible is one of the two requirements for the trap-handling radial menu to be enabled. (The other is having skill in disabling locks.)
    In fact, "being visible" seems to be a stronger requirement than one might initially think. Sometimes, a floor trap ends up partially under the surface of the floor, resulting in only part of the trap showing up as red (or green) to the player. Well, it is only that red (or green) portion that can be used to access the trap-handling radial menu. You can click elsewhere within the trap's boundary (i.e. the part hidden under the floor/ground), but you don't get the trap menu even though there is a known trap there -- the trap is nominally visible, but with something (the floor) between it and your viewpoint, it cannot be seen. (It can still be triggered at that position though.) Eh, there are some other screwy, uncommon factors involved, but basically, if you (the player) can see it, then you (through your PC) can try to disarm it, but only where you (the player) see it. --The Krit 20:20, December 5, 2011 (UTC)
  • I had a stray thought, related to this but not pressing enough for me to want to try it out right now. Suppose someone were to run the dedicated server with the "one party only" option. That person then logs in with a rogue who flags a trap (detect DC over 35 so rogue levels are required) then logs out. Next, without shutting down the server, the person logs in with a different character (no rogue levels so the trap is undetectable with the search skill). In one sense, the two PCs are in the same party because of the server setting, even though they were never logged in at the same time. Would this be enough for the second PC to benefit from the first one flagging the trap? Don't know. --The Krit 22:53, December 20, 2011 (UTC)
  • I'm not sure if this is party dependent. The notes for GetTrappedFlagged() are as follows:
// - oTrapObject: a placeable, door or trigger
// * Returns TRUE if oTrapObject has been flagged as visible to all creatures.
Also BioWare doesn't use the flagging system in creature AI in SP (as there is no SetTrappedFlagged(), and the AI does not use the disable skill for flagging). My guess is that flagging a trap would make it visible to everybody, as parties of multiple PCs, like OHS, would have been a later development. WhiZard 16:54, December 23, 2011 (UTC)
  • Testing different script functions and the default one in SP where party members relay trap visibility to other party members (e.g. the familiars detects the trap, and then its master sees the trap) is by setting the trap as detected by the other party members (exactly the same as, and possibly could be using SetTrapDetectedBy()). What is not passed to the other party members is GetLastTrapDetected() (this only updates its value when the creature naturally detects the trap). The trap is never flagged. What I found to be interesting is that the Lexicon attributes SetTrapDetectedBy() as being 1.67 patch, when NWNexplorer shows it to be from the beginning, NWN:OC. So there could possibly be scripted use of SetTrapDetectedBy() that I am missing. WhiZard 01:13, December 24, 2011 (UTC)
  • Yes, that comment ("visible to all creatures") and the lack of a creature parameter to that command does suggest that being in the same party does not matter. So Iconclast's test could be rather easy to pull off without assistance. Just start the dedicated server, log in with the rogue who will detect and flag the trap, log out, then log in with the non-rogue who will try to recover it. Piece of cake. ... Now I'm hungry.... --The Krit 00:39, January 13, 2012 (UTC)
  • Ran said test on my own dedicated server. The rogue set and flagged an epic sonic trap from a trap kit and then logged off. A non-rogue logged on and could see the set trap. "One party only" was not checked. WhiZard 06:20, January 13, 2012 (UTC)