Neverwinter Nights Forum News

Remove all ads!

(Originally posted by chevalier)

Here are today's Neverwinter Nights forum highlights. Please take into account that these are only single parts of various threads and should not be taken out of context. Bear in mind also that the posts presented here are copied as-is, and that any bad spelling and grammar does not get corrected on our end.

Georg Zoeller, Designer

Patch 1.63:

From the 1.63 internal buildnotes

- Added support for 8 new custom animation types:
ANIMATION_LOOPING_CUSTOM3
ANIMATION_LOOPING_CUSTOM4
ANIMATION_LOOPING_CUSTOM5
ANIMATION_LOOPING_CUSTOM6
ANIMATION_LOOPING_CUSTOM7
ANIMATION_LOOPING_CUSTOM8
ANIMATION_LOOPING_CUSTOM9
ANIMATION_LOOPING_CUSTOM10

Module size:

Quote: Well i got a question what would be a safe mod size ? and why are the dragons and balors turnning and facing away from me every time they cast a spell?

That depends on your hardware, but I would say that you should avoid growing your module above 50-60 MB. The largest module of the official campaigns has around 32 Megs.

Scripting 2DAs: The des_* .2da's are all used by the scripting language only, they are not used by the game engine itself - and as far as I know, those .2da's are only read by the server, as the script is executed on the server as well.

Script cache: a) The existence of the script cache says about nothing about the execution cost of any specific script - yes, ExecuteScript can be potentially expensive - if you execute a very large script - of course (like one you get when you are running a single huge OnActivate script....). Also the "cost" of "scheduling" (there's nothing scheduled here, ExecuteScript works in-line and synchronous with the calling script) another script operation is not unknown, you can easily profile it either using a debug executable or a tool like NWNX2 - And while there is a management overhead in ExecuteScript, it's neglegible, especially in OnActivation script - the HotU default AI is calling ExecuteScript in every single EventHandler, plus a potential number of times inside the combat AI. The script cache is there to reserve memory for larger scripts - so they don't have to be loaded from disk into memory for each execution, it's not there "because scripts are slow" or because "executescript is slow".

b) Have you heard of things like binary search? or Hashtables? There are better methods to find a certain object than searching through "a potential number of scripts". I.e. to locate a unique string in a list of 10.000 strings using simple binary search you need around 13-14 compare operations - I'm sure most modules with 10.000 items would have a lot more than 13 useable items, probably more than 100.
There's a reason we have tags and resrefs in Aurora, if NWN would use sequential string compares in it's resource management system to locate resources when they are demanded, the game wouldn't have finished starting after 5 minutes.

c) While you are free to assume that NWSCript is appallingly inefficient, you are also free to be wrong. NWScript is quite efficient (thats why a lot of the game, including the AI, is done in scripting, as opposed to "in the engine). Not to say that there is no room for performance enhancements to the engine, as one is being investigated right now, but we are really happy with the performance of our scripting language.

d) To come back to the subject - a "slow" OnItemActivate script is not going to "lag" your server, regardless what method you use - You could see a hickup any time someone uses an item, but that doesn't qualify as lag - lag is generated by a fairly constant overload of your system. If you are looking for lag, search for scripts with a higher execution frequency - creature AI, AoE spells, recursive spells (I.e. acid arrow) and expensive module/placeable/creature heartbeats or DelayCommand chains.

So, once again, using tagbased execution to manage OnActivate scripts in your module is definitly much better than having one huge OnItemActivate script plus it's more beautiful and manageable. "Tagbased scripts cause lag" is about as precise "DelayCommand is better than Heartbeat".

DM features: To give you some feedback, I've discussed a few ideas from this thread with Craig and he says that DM reserved slots and optional mandantory masterserver response are things that he "would like to put in the game when he finds time to do it". Of course that's no promise and it certainly doesn't mean those features will be in 1.63 or 1.64, as "when he finds time for it" is not really something you can plan for

Jonathan Epp, Quality Assurance

Tileset limit: There's a good chance that this will be fixed in the 1.63 patch. I can't guarantee that just yet, but it's looking hopeful. If the fix works and makes it in, there will still be a limit, but a higher one (probably 50 or something). There is a memory usage concern when using lots of different tilesets in the same module. A programmer would be able to explain this better, but basically the game needs to load up the tile data for all areas of the game. If you use the same tile in many areas, that data only needs to be loaded once. But when you use many different tilesets the game needs to load data for a lot more tiles. I'm not sure if that's 100% technically correct, but that's the gist of it anyway. If, as a builder, you never ran into the old limit then you needn't worry about this memory concern. If you plan on going above the old limit (assuming the fix works and makes it in), then it's probably good to be aware of this issue - though I'm guessing most builders in that category don't really think too much about people with min-spec machines anyway.

Craig Welburn, Live Team Programmer

Hak Paks: The problem is that hack packs have to be associated with a module. So in single player, you select the module to play first (which in turn loads up the hack pack), then you create your character. In multiplayer, you connect to a server which may or may not have a module loaded at that time, and thus you can create a character before you know what module you are going to be playing (and thus there is no way to know yet what hack packs your up coming game session will be requiring). I doubt that at this point we will be making any significant changes to the way the multiplayer connection system works to address this issue, but less likely things have been know to happen.

2DA Files:

Quote: Will we get a list of the new animation names? As this extends the custom anims added in HOTU,
I assume it will be...

...
custom3start
custom3lp
custom3end
...
custom9start
custom9lp
custom9end
...

I was wondering if the custom10 aninations would be called 'custom10' or 'custom0'?

Yep, that's pretty much right. They are named:

Custom3start
Custom4start
...
Custom10start

Custom3end
Custom4end
...
Custom10end

Custom3lp
Custom4lp
...
Custom10lp