Neverwinter Nights 2 Forum News (Apr. 14, 06)

Remove all ads!

Here are today's Neverwinter Nights 2 forum highlights, collected by NWVault. 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.

Anthony Davis, Programmer

Bobble heads!

---

Yes. The animation technology of that era is long gone and there is full lipsynch now.

---

I'll (re)confirm that. Yes, that includes facial expressions.

Rich Taylor, NWN2 Programmer

NWN2 GUI - Script Interaction
This is a post to update you all on where the GUI/Script interaction is at currently. There are some minor Script/GUI interactions in the default UI, which allowed for me to take some time to get the first pass at this stuff in the game.

I'm going to just touch upon the abilities that are in the engine at the moment. More details can come later when I have time to talk about them. =)

GUI callbacks can be put on UIObjects that fire off scripts on the server. What this means is you could have a button in the GUI that fires a script every time it is clicked. Or you could make it so that every time a certain window is brought up, a script is executed on the server.

Scripts can only be executed if they are named:
"gui_*"

If they do not start with gui_ in the name, the server will reject the request to fire the script. This will help prevent clients from firing off whatever script they want to just by knowing the name of it. It will be up to the script writers themselves to make sure that the gui_ scripts are written in such a way that clients can't abuse them by calling them whenever they want.

A few script functions exist to give some basic control over the GUI.

**Bring up a GUI on the client. In order for a GUI to be accessible in script, it has to be defined in a certain way in an .ini file (more details later)
DisplayGuiScreen( oPlayer, sScreenID, bModal );

**Display a message box. Allows you to define the message text, the text for the 'okay' button, the text for the 'cancel' button, whether or not cancel is displayed, and the scripts to execute if the user clicks okay or cancel. Scripts must again be named with "gui_"
DisplayMessageBox( oPlayer, nMessageStrRef
sMessage, sOkCallback,
sCancelCB, bShowCancel,
sScreenID,
nOkStrRef, sOkString,
nCancelStrRef, sCancelString );

**Determines if a specific object on a UI on that client is visible or not. This gives script some limited control on altering the appearance of a GUI window by toggling things visible or invisible. This has the same restrictions as 'DisplayGUIScreen', in that there are some restrictions on which GUIs you can affect with this function.
SetGUIObjectHidden( oPlayer, sScreenID, sUIObjectName,
bHidden );

**Close the screen on the client. Again, there are restrictions on which GUIs you can affect with this.
CloseGUIScreen( oPlayer, sScreenID );

**This function is a bit more advanced in its use. But briefly, there is a set of 'local variables' on every GUI window. The GUI layer interacts with these variables at times. And with this script function, scripts can as well. This script function can be used in combination with certain GUI callback functions.

For example, there is a GUI callback for 'OnUpdate' that will display the contents of a local variable. So you can pipe strings across from the server that you want to appear in the player's GUI in a custom window you've made or something.

Or there is a GUI callback that will set a UI Object as 'disabled' if a local variable contains a certain value. So you can disable a certain button on your custom screen if the local GUI variable on that screen has a certain value.
And so forth.
SetLocalGUIVariable( oPlayer, sScreenID, nVarIndex, sVarValue );


These are the basics right now. It isn't as robust a system as I've thought about (Where you could create full screens completely in script), but it does give you enough control over custom GUI screens to do some interesting stuff, I think.

The one area I hope to improve on is some way for the client to send GUI local variables along as script parameters to a gui_ script. That will enable the client to provide some information back the other way, since right now variable data can pretty much only go from server --> client, except when it comes to clicking on buttons on the client.

Anyway, figured I'd give people a heads up on where things are at for now.

-Akari

J.E. Sawyer, NWN2 Lead Designer

ATTN: PW people RE: module sizes
Hello, my friends. This is mostly a cautionary message for PW builders based on some questions that were asked in the chat last night. Of specific note was a question asking if we had run a module with 300 areas in it.

The answer is not only "no," but "not even in our dreams". It's true that the average gaming rig is a lot beefier today than it was when the original NWN was released. But the complexity of our areas -- both interior and exterior -- is dramatically greater. One consequence is that a NWN2 area tends to have a hefty memory footprint. This is especially true on exteriors, where super texture-layered height-mapped terrain is stuffed full of trees, bushes, and high-detail buildings. We are still in the process of optimizing our data and beautifying areas intelligently, but we're typically looking at 6-9 megs for a mid-sized NWN2 exterior. On the extreme end, big areas run upwards of 20 megs.

This might not seem like that big of a deal on machines that often have 1 or 2 gigs of RAM, but when you throw in ten of these suckers and a bunch of interiors that are all part of the same module, you are on a highway to the proverbial danger zone. Combined with the game's overhead for doing everything else, it's a lot for a server to deal with.

For people playing our "OC" and building adventure modules, none of this should be a big concern. You can chop up your modules into whatever size you want and people can just deal with lugging the party around. For PW builders this may cause logistical problems for how large your modules can be. If you were planning to have a series of areas running continuously from Baldur's Gate to Lathtarl's Lantern (a personal favorite), you will need to have a server forged by the hand of Bane himself. Or maybe twelve 30th level arcanists. Either way, it's a big deal.

I know this is probably less encouraging news than, "Yeah, we're running 500 areas in a single module!" but I figure that letting everyone know now is better than letting you figure it out through trial and error after the game comes out. Lest this come off as a tepid, eye-roll-inducing "temper your expectations" message, let me end with clarity:

NWN2 areas take up a lot of memory. The exteriors take up even more memory. If you are planning to have huge chains (10+) of large exteriors and interiors linked in a single module, it's not going to run smoothly on current hardware.

More: We would lose far more potential interest in the game by limiting our graphical capabilities in the interest of allowing huge PW modules. The average (or even above-average) person doesn't look at a low-quality screenshot and think, "I'm glad they kept the level geometry and textures simple so we can have huge persistent worlds!" They look at it and say, "This looks nowhere near as good as Game X*, it sux lol."

Realistically, it's going to take even very talented modding/PW teams six to nine months to develop persistent worlds. It will probably take three months after that for those PWs to reach a significant volume of traffic. Hardware nine to twelve months from our release date may mitigate a lot of these concerns.

Looking at it that way (which I pretty much have to), it's better to have our OC look fantastic and run well now and let affordable consumer hardware catch up with the more ambitious modders.

* Probably Oblivion.

More: No, you're right: for a dedicated server, those particular elements aren't a big deal. However, modders still do need to be aware that many aspects of the modules (like walk meshes and individual objects placed in the world) have become larger in NWN2. Time permitting, I'll get more detailed breakdowns of where memory is being consumed. We're doing a lot of profiling right now though, so any figures I throw out are only estimates.

More: I have appealed to more informed folks (programmers) to contribute if they have the time. Hopefully they will be able to answer your more specific questions.

More: Here are some answers "from programming":

"* Now I don’t know for a fact that our game consumes WAY more bandwidth than NWN1, but I do know that we are sending more data over the pipe than NWN1 did (Details like creature HP for the target bar, for example, whereas NWN1 only sent vague states like ‘Healthy, wounded, very wounded’, etc). There’s probably some other more bandwidth consuming updates that we’re doing as well."

"* Someone asked if they will need more upstream to support 64 players over a cable modem than they need right now. The answer is ‘maybe, but not by much.’ While we are sending more data over the pipe in NWN2, it should be of small enough quantity that a cable-modem pipe won’t see too big of a difference. The guy cited 64 players, at worst he might need to cut it down to 62 players."

"* Also brought up was the question of a LINUX server. There is no plans/schedule for a LINUX server at this time. I’m sure I could port/fix up the old nwserver.exe to work on Linux, but there is no scheduling for that before release. It might need to be a post-release patch type of download."

"* Someone asked if the client would need to have a ton more memory if the server does. I’m not 100% sure what they are asking there, but basically, having 1 or 500 areas on the server has zero impact on how much memory the client needs in order to play the game. The client only needs to be able to handle 1 area at a time. Will clients need more memory than NWN1 required?" Yes.

"* Someone brought up the question about being able to communicate across separate modules being hosted by separate computers. There’s nothing we have in there at this time that can help them with that. There might be a way to solve the problem with the help of the NWN2x (Neverwinter Nights 2 Extender), but I haven’t had much time to give the NWNx author much support so far. Hopefully I can squeeze in some more time to give him some of the functionality that he has asked for that will allow him to help plug some of the gaps NWN2 has in it with regards to solving some of these problems."

More: The times I'm talking about are based on how much more involved area creation is. You can slap together a very basic exterior in a few minutes, but it will look very bland. Making an exterior look really nice requires a lot of time and tweaking. Because interiors allow a lot more flexibility as well, you will also see an increase in their development time.

More:

---

This is supposed to be a sequel to NWN, but if you guys can't streamline your game to be more resource efficient for a server, what does it offer the multi-player? If you can't do with it what could be done in NWN1 multi-player, by at least half, why even bother having multi-player at all? Just make another morrowind and be done with it.

---

I think "Huge PWs immediately or what's the point?" is an extreme stance to take. I do not believe that NWN2 will prevent people from making very fun multiplayer modules or persistent worlds.

I'm not presenting this information to tell all the PW people to forget about making PWs. I'm doing this so you will be better able to plan how your PWs are built.

Database support in NWN2
Hello again. Today, I'm trying to address the bigger concerns that came up in our IRC session last night. Easily the most-asked question was about our database support. After speaking with Darren and other fancy people, I have some information.

NWN2's database support will be identical to database support in the original NWN. It will use Codebase http://www.codebase.com/ . As with module sizes, this of great interest to PW folks. I know that a lot of people were hoping for something more robust, but we simply don't have the time (a few weeks of programmer attention) required.

Sorry if this is very disappointing to some, but again, we figured it was better to let you know now.

NWN2 GUI - Script Interaction

---

P.S. weird question... there seems to be a flood of information lately (not that I mind) is there some special reason for the massive amount of posts by Devs?

---

I think we just collectively realized that we're at a realtively safe point in development for telling the fans what's up. That is to say that we're pretty much past the "risk" phase on most topics, so we can talk with certainty about more things.

IMS is still in...
Yes, those spells are in, but apparently there were changes to Isaac's greater missile storm. I haven't seen it in action yet, though the maximum number of missiles appears to be capped at 10.

Animal companions = tanks!
Familiars and animal companions are being re-implemented right now. Familiars are fairly close to their tabletop counterparts. They are not particularly tough, they are small, and they grant bonuses to their masters. If they get killed, the master suffers some penalties and cannot re-summon their familiar until after resting.

Animal companions are tanks. They start out being kind of tough and only get tougher. They have the potential to wreck a lot of stuff. When they die, the master suffers no penalties but cannot summon it again until after resting.

To be honest, I am uncertain of how testing will feel about these implementations so I am interested in their feedback on this matter.

EDIT: For clarification, familiars are not "lil' rogues". They are more like buff totems for the wizard or sorcerer master.

More: Actually what I meant is that druids will be able to pick from the Panzer and Koenigstiger.

I thought you guys liked panthers and tigers.

Nathaniel Chapman, NWN2 Q&A

Sky Box
They are in fact quite extensive.

...sorry buddy. A little too much info there...especially when there's competition that's about to relase around the same time as us.

They'll find out soon enough exactly what ALL of those paremeters are...when they buy the game.