You are here

NWN Script University (Toolset Preview)

David Gaider, Design

Toolset Preview

by David Gaider, Design

Dec. 14th, 2001 Jay Watamaniuk - Community Manager

Scripting Q&A

Here is a bunch of code questions we have received in the last week or so. I took them to Preston Watamaniuk, Designer, and Mark Brockington, Lead Research Scientist, for the answers:

Dec 19, 2001

Q: Would it be misleading (or even plain wrong) to think of a finished and compiled NWN game to be like the main function in a C-Program?

A: If by the "game" you means a script, then yes, it is very similar.

Q: When using #include files, does the compiled game just take the code for the functions the game creator has typed into the script, or does it take the

whole include file?

A: The compiled scripts take the entire file when reading it into the compiler. Think of an include as a file to be added, in its entirety, at that point in the script. Let's say the included file (quick.nss) had the following pieces of text in it.

quick brown

fox jumped

If the main code looked like this:


#include "quick"

over the lazy dog.

The script compiler would attempt to compile:


quick brown

fox jumped

over the lazy dog.

Q: Does this impact performance in any way, and if so, should any include files be stripped so as to only include the functions your game has been coded to

potentially call?

A: The short answer is that it doesn't really impact performance. The script compiler maintains a call graph that determines which of the functions (from the include files) can actually be called by main() and removes any compiled functions that couldn't possibly be called, through any possible inputs. We have a 1200-line "design" include file that contains all sorts of nice functions that our designers use on a frequent basis. If we had to include the compiled version of all of these functions into every script, each "compiled" script would be over 20 KB in size.

Q: Is it good design (or even possible) to put a switch case on a creatures/NPC's heartbeat event?

A: Not a problem

The Switch statement in this case would look at a variable, one that is meant to represent what 'chapter' the party is in. So that in chapter 1, my recurring NPC's heartbeat would run a certain set of script commands and environment checks only, and when the party progresses to later chapters, the NPC/creatures/whatever wouldn't run the 'chapter 1' script anymore, instead it would run 'chapter 2' script, or script pertinent to whatever the current chapter is, only? There would be like a variable intChapter, and the switch statement on the heartbeat something like:

Switch (intChapter)

Case 1 : RunAllThisScript1();


Case 2 : RunAllThisScript2();

? Break;

case 50 : RunallThisScript50()

Break; etc.

My idea being to make things complex, but not have to run all the script all of the time.

Q: What scope would a variable like intChapter have to have, or asked another way, where would/should I declare this variable and increment it?

A: All variables and functions are public in the scripting language. There is no concept of Private and Public. However you can store local variables on pretty well any object within the game (Module, Area, NPC etc)

Q: How many case statements can be in one switch, in NWN?

A: Any integer value

Q: I found the following three looping structures (For, While, Do) in my book on C. Would you be able to tell me which of them is the NWN language likely to contain?

A: All three are available in scripting. They are basic programming tools common to most, if not all, scripting languages.

Q: Will I also have to have function prototypes at the top of my script like in regular C ?

A: Yes, you will. In NWScript (just as in regular C),you do not need function prototypes if the script is ordered so that the function is implemented before it is called)..

Q: Will NWN use semi-colons to terminate statements?

A: Yes

Q: Can we get any further information about placeable object properties (or even tiles) and NWScript? For instance, if we use GetNextObjectInArea() to loop thru objects around us, suppose we want to see if a chest is in the area, can we detect if it is locked/unlocked/trapped? How about a portal? Can we detect properties about the portal? Description, open/closed,etc.

A: You can check the properties on placable objects, open doors, lock them. The same goes for chests.

Q: How about tile properties - we've seen SetTileProperty(), any clues about what we can modify using that?

A: SetTileProperties is cut, you will be unable to modify tile props on the fly

Q: Here's another dangling thread from Mark B...Java-style classes (with member functions) within the scripting language are still not supported yet....are they supported -- yet? Will they be?

A: No, not at this time.

Q: It's been 6 months since we got the game-of-life example, and gathered as complete a list of constants & functions as we could from E3... any chance of a constant/function-list dump anytime soon?

A: No, this is constantly changing and fuels too much speculation. If we give a list of functions then we will be spending a week or more just answering questions about the various functions. People will try scripting before they can actually script, which will be unproductive for both content designers and our programming staff.


Toolset Run Through Hmmm. I haven't seen any lock specifications that allowed you to put SR on it. But the capacity is certainly there for something to be scripted. Let's see...I got my editor open right now. OK, I plunk down a chest. It's on a big list of containers, which is a sub-list of your place-able objects. First thing I do is go to the 'Basic' tab...there you have the following: * Name (this is what name will come up in-game) * Tag (this is what scripts refer to it as) * Plot? (this is a check-mark button, in case you want the item to be indestructable) * Useable? (if this isn't checked, the item is just the same as background)'s the stuff on the item, itself: * Hardness (hey, someone asked about this...Okay, so it's finally in) * Hit Points (until it's destroyed) * Saves (you have Fortitude, Will and Reflex, just as normal) Anyway, once I check 'Useable', the tabs for 'Lock' and 'Trap' pop up. Under 'Lock', it's pretty basic... * Locked? (you check whether or not the item starts off locked) * Can be re-locked? (self-explanatory) * Automatically remove key? (after using one) * Key required? (if there is a key item that will open will ask for the tag) * Open Lock DC * Close Lock DC That doesn't do what you need. We'll check 'Trap': * Is Trapped? (obvious) * Trap Type (there's a big pull-down list) * One Shot? (will the trap only go off once or every time?) * Disarmable? (self-explanatory) * Detection DC * Disarm DC * On Disarm (here you can insert a script) * On Trap Triggered (here's where the trap's effect script goes) * Hmmm...some other trap stuff that I don't know anything about. Looks like mods to rogues setting traps on the objects, but I'm not sure so I won't list it. Still nothing you would want there. Okay, then...if you move to the 'Events' tab, it gives you all the possible events which can trigger a script you make. This is where you'd want to do it, I imagine...and I don't think it'd be too difficult from the looks of it. Here's the triggers: * On Closed * On Damaged * On Death * On HeartBeat * On Inventory Disturbed * On Lock * On Melee Attacked * On Open * On Spell Cast At * On Unlock * On Used * On User-Defined (everything else) So...let's see. There will be, no doubt, some sytem for how SR is going to work. I'm not sure of it, myself, but you could add it in the HeartBeat so it's renewed. Maybe even on the Spell Cast At. Then again, you might want to think about what kind of magic you're protecting it from...and script according to that. At any rate, it's pretty flexible, as you can see.

Migrate Wizard: 
First Release: 
  • up
  • down