Scroll DC[]
When calculating the saving throw DC for scroll spells, what ability modifier is assumed? Is there a standard for each scroll or each innate spell level or is it related to the relevant ability score of the scroll user? I think a note to clarify this (here and/or on the DC page) might be useful. MrZork 11:41, December 19, 2009 (UTC)
- Its 13 + Initiate spell level --ILKAY 19:24, December 21, 2009 (UTC)
- Thanks. I have a feeling I've seen that before, but I don't know where. I will add an addition to the notes mentioning that. Something like
- The saving throw difficulty class for a spell cast from a scroll depends only on the spell's Innate level.
- difficulty class = 13 + innate level
- --MrZork 23:04, December 21, 2009 (UTC)
Multiclassed Spellcasters with UMD?[]
I haven't played a cleric character before, but I just had my cleric 14 / rogue 2 (with UMD = 3) try to use a scroll of Lesser Restoration, only to have it fail with the message Use Magic Device: *success not possible*:(4 + 3 = 7 vs. DC:27). I was assuming there would be no UMD check since my cleric can cast that spell anyway. Is this some sort of bug in the way scrolls are used or in the UMD code? (BTW, this is an ordinary lesser restoration scroll, listing clerics among the classes that can use it.) Is there a fix? It may be worth a note in this article that there is some buggy/unexpected behavior here and a link to a fix, if there is one. - MrZork 15:21, October 12, 2010 (UTC)
Okay, just saw this thread on the recenly old Bioware forums. It looks like there may be a scripted fix, though I haven't tested it out. I think a note about this in the article would be appropriate. Something like
- A bug in the use magic device (UMD) script causes non-arcane spellcasters with ranks in UMD to pass a skill check before casting a scroll spell, even if it is one they would normally be able to cast due to spellcasting ability. Thus, a cleric 3 / rogue 1 skill ranks in UMD would not be able to use a scroll of lesser restoration, because its UMD DC is 27. A fix is available at LINK.
Perhaps someone more familiar with this issue could post a note with a link to a tested fix. - MrZork 15:21, October 12, 2010 (UTC)
- Info copied from use magic device. I did not call it a bug nor mention a fix because it is not a bug. Take a look at Georg Zoeller's post on page 1 of the thread you linked to -- BioWare intentionally chose this implementation. (The algorithm is also specifically spelled out in the comments at the top of
x2_pc_umdcheck.nss. It is intentional and working as designed.) --The Krit 16:19, October 12, 2010 (UTC)
- I'm not sure that Bioware chosing to use code that it knew had problems redifines those problems as non-bugs. The key fact is that a thirty-ninth level cleric who takes a level of rogue or bard may suddenly find that he now can't use previously usable cleric spells from scrolls. That is definitely problematic. (Meanwhile, discussion later in that thread implies that the difference in computational overhead between the BW implementation and the proposed solutions may be marginal, which seems reasonable after a quick peak at the two code sets.)
Anyway, I wish there were an erf/hak available that we could point to as a way to address the issue, because I think the behavior as it stands would be a problem to most players considering a multiclassed cleric with rogue or bard levels. I certainly know that I will be tinkering with the x2_pc_umdcheck code and dropping a fixed version in my override. It seems a shame that others checking the wiki article about this problem won't get any help. - MrZork 17:17, October 12, 2010 (UTC)
- I'm not sure that Bioware chosing to use code that it knew had problems redifines those problems as non-bugs. The key fact is that a thirty-ninth level cleric who takes a level of rogue or bard may suddenly find that he now can't use previously usable cleric spells from scrolls. That is definitely problematic. (Meanwhile, discussion later in that thread implies that the difference in computational overhead between the BW implementation and the proposed solutions may be marginal, which seems reasonable after a quick peak at the two code sets.)
- BioWare choosing something most certainly makes those deficiencies non-bugs. BioWare is the only entity that can define what is intended, correct, and expected for NWN, so once they choose a certain approach, that approach is by definition correct. In order for a deliberate decision by BioWare to be a bug, it would have to contradict another of their decisions. You cannot go by what players expect, because there are some players who expect to be told what paladin spells they can cast during level-up (and that is not a bug).
- That's not to say the decision makes a lot of in-game sense -- after all, shadowdancers are listed a class that forces a UMD check even though shadowdancers lack access to UMD -- but that by concrete, objective criteria, the end result is not a bug. (And it does work well enough in the vast majority of cases.) What objective criteria could make this different than any of the other aspects of the game that one can tailor to one's personal tastes? --The Krit 18:44, October 12, 2010 (UTC)
- Avoiding the issue of who ultimately defines "correct" and "expected" behavior for software, it remains that behavior can be deliberately chosen but not desired, even by the developer. I don't see any indication that this clerics-can't-read-cleric-scrolls behavior is what Bioware wanted, though Mr. Zoeller mentioned (in his post, there's nothing acknowledging it in the code comments) that they knew it was there. It was a compromise they made due to concern that providing the rules-conforming behavior would be too computationally expensive. Meanwhile, I suppose "developer-known, user-unexpected, undesired, undocumented behavior" may be a more accurate term than "bug", though not as pithy ;-).
- At any rate, having played with it a bit, I am thus far pretty happy with the updated version of
x2_pc_umdcheck.nssat http://nwn.bioware.com/forums/viewcodepost.html?post=4047700. - MrZork 23:03, October 12, 2010 (UTC)
- A lot of programming is compromise (especially in games programming). The speed-vs-space trade-off is a longstanding example. A short term for such things would be "known shortcoming" or (by the PR department) "feature". ;) --The Krit 03:13, October 13, 2010 (UTC)
- Lol, of course, nothing is bugged everything is intended :) :) :). 77.92.213.119 02:14, February 9, 2011 (UTC)
- Do you ever get tired of acting like an idiot, ShaDoOoW? I already pointed out Georg Zoeller's post in the above-linked topic in the BioWare forums.[1] When a game's senior technical designer says that the currently implemented solution was chosen, then the current implementation is the intended design. A bug is when the game does not operate as designed, so this is not a bug by definition. --The Krit 21:21, February 12, 2011 (UTC)
Combat scroll casting[]
I noticed under round there is no clear discussion of how long it takes to read a scroll, drink a potion, cast from a wand, use a healing kit, etc. Are these all full round activities or can a quickened spell be cast and a scroll read or can one shot be taken from a bow then a scroll read? Are wands, potions or scrolls faster than any other? Can scroll be interrupted by an attack? Does scroll reading provoke attacks of opportunity? Does a scroll reading require a concentration check? (it does in PnP). 97.85.168.22 02:41, July 29, 2012 (UTC)
- The time for using items is more or less the time for the associated animation, which is somewhere in the neighborhood of six seconds (as is the time allocated for one combat round). If you want to time it exactly, it might be a good idea to queue up 10 or more scroll readings (or whichever item you are timing), time that, then divide by 10 (to reduce the error in timing). Unless there is a built-in delay between using items? (I don't recall queuing up scrolls like that.) In any event, I would not call anything in NWN a "full round" activity because the term "full-round action" has a special meaning in D&D, and using such a similar term could end up confusing those familiar with the PnP rules (since that concept was never translated into NWN). Anecdotal reports say that using a wand is faster than using a scroll or potion (at least in the context of run-use-run), but as far as I know, no one has been interested enough to do precise trials. A scroll can be interrupted by an attack that kills the scroll reader, but otherwise, no (see concentration; using an item is not "casting a spell"). This article does not mention attacks of opportunity because there is no reason to. Compare with potion, which does mention attacks of opportunity, and attack of opportunity, which lists the situations that provoke an attack of opportunity. There is no mention of a skill check (other than UMD) because there is no reason to, as there are no skill checks intrinsic to scroll use in NWN. (Nor is there a concentration check associated with reading a scroll in PnP. Maybe you were thinking spellcraft?) --The Krit (talk) 00:56, August 21, 2012 (UTC)
Scrolls and SR[]
This always bugged me, i don't believe there is a specific explanation out there, unless it's too obvious to point out and i'm silly, but...
What would be the caster level for purposes of beating Spell Resistance, when casting a spell from a scroll?
I can only speculate myself, as i can't think of a way of testing this:
1. d20 + innate level -vs- SR?
2. d20 + scroll spell level -vs- SR? Like, "Level Drain (17)" would be d20 + 17 vs SR?
3. ...Spell Penetration feats included in either?
Aeqvinox (talk) 18:08, September 4, 2012 (UTC)
- Is there a reason to think the caster level varies depending on what is being checked? I do not recall anyone specifically testing this, so I would just go with the assumption that caster level is caster level. --The Krit (talk) 21:02, September 4, 2012 (UTC)
- I forgot the penetration question. I would guess that spell penetration does not apply to spells cast from items, but again I do not recall anyone specifically testing this.
By the way, the "17" in "Level Drain (17)" is not a spell level (for one thing, spell levels top out at 10) -- it's the caster level for that item property, affecting the strength of the spell (and presumably the spell resistance check, as I already mentioned). --The Krit (talk) 05:50, September 5, 2012 (UTC)
- Right, caster level indeed, i derped there. Thanks for your insight on the matter Krit, cleared out the fog for me it did. Aeqvinox (talk) 14:07, September 5, 2012 (UTC)
Caster level for spell from scroll[]
How caster level for spell casted from scroll is calculated? Szafirmag (talk) 16:04, August 31, 2016 (UTC)
- It's specified, not calculated. See caster level: "For spells cast from items, the caster level is given in parentheses after the relevant item property." --The Krit (talk) 03:44, September 1, 2016 (UTC)