Neverwinter Nights Forum News (Feb. 03, 06)

Remove all ads!

Here are today's Neverwinter Nights 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.

Georg Zoeller, Designer

1.67 Beta 1

---

Quote: Maybe someone should start a petition for them?

---

By now you should know that petitions don't work for us, a well written overall statement on why some specific feature might be useful has a better, through obviously not guaranteed, chance of success

More:

---

I've reported a bug: all bracers, gloves and gauntlets in store inventories have become unuseable (turn red, can't be equipped if purchased) for all characters except those with an APPEARANCE_TYPE_HALFLING.

Actual race, class, feats, abilities, skills, whatever, make no difference. It's the appearance type that's critical.

---

Thanks for reporting it, Craig said it will be fixed in the next beta.

How to override or extend NWN core scripting function

---

---

However, it will slow your module down significantly as well, as you are overriding all the scripts in the game resources

---

Could you explain this remark/flesh it out a bit please? I'm running a mod in which one of the former builderrs replaced some default includes over a year ago, and I've been letting the sleeping dragon lie, so to speak, since I didn't want to shuffle through all the code to figure out what they changed and why, as long as nothing was broken, even though I wasn't benefitting from Bioware changes to the include. But knowing that there may be speed implications as well makes me rethink this decision. Are the speed implications just a result of the fact that bioware includes are automatically in memory, while others aren't unless placed in the cache?
Thanks,
Funky

---

The speed remark was aimed at putting files into the override directory. Having a few (like a few dozend or even a hundred) script files in there won't really do any harm to performance, but once we're talking about putting a couple of hundred or thousand scripts in there, you will see an impact to performance. The override directory is primarily designed for ease of development, allowing us to test resources and changes to resources immediately, without having them packaged into .bif files. For that reason files in override usually don't end up in the cache as we need the ability to change those files and see the effect of the changes right away, without having to reboot the game whole game. (Note that this is not 100% true anymore after 1.64, i.e. making changes to .2da files in override won't take effect once these have been accessed once, as they are cached for performance reasons. This might be true for other filetypes as well).

Overriding standard resources in your module instead (not in the override directory) is preferable in most cases, as those files will end up being cached in memory most likely anyway.

More:

---

Georg,

This seems to imply that I can dump the 167b1 nwscript.nss into my 166 mod along with some of the other udpated scripts from BW and everything should be forward compatible. The caveat is that new functions won't do anything until I actually do migrate to 167, but I can still begin patching and testing preemptively a bit more effectively, given careful configuration management.

Does that sound accurate to you?
-Dave

---

It would work ... however, the new functions won't just do nothing ... they will crash the running script as the game will cause an unrecognized command id error for those functions (obviously, the compiler will generate instructions in the bytecode referencing to a command that doesn't exist in the engine for 1.66).

However, if you did put one core include into every script, as suggest in the article, you could preimplement those functions in the include and later just point them to the implemented nwscript.nss, which is really helpful.

Allow resting but diabling scribe scroll help
There is a variable you can set on players or the area to disable item creation feats as far as I remember. Don't have a working toolset right now, so I can't tell you the name. Maybe check x2_inc_craft, it should be commented in there.

Craig Welburn, Live Team Programmer

CreateTrapAtLocation and SetTrapDetectDC

---

I just looked at nwscript.nss, and yeah, CreateTrapOnObject is a void function. Really weird that they did that; only thing I can think of is that they thought that one would get quite a few delayed reset attempts.

---

Traps on objects aren't stored as objects in the game engine. They are stored as properties of the object that they are placed on (i.e. properties of the placeable/door), so trying to return the trap itself doesn't make sense in this context.

Craig.

More:

---

---

I just looked at nwscript.nss, and yeah, CreateTrapOnObject is a void function. Really weird that they did that; only thing I can think of is that they thought that one would get quite a few delayed reset attempts.

---

Traps on objects aren't stored as objects in the game engine. They are stored as properties of the object that they are placed on (i.e. properties of the placeable/door), so trying to return the trap itself doesn't make sense in this context.

Craig.

---

May be I should clarify this a bit more.
Since the trap information is stored as properties of the object it was created on, if you want to change the properties of the trap after it has been created by a call to CreateTrapOnObject() you need to apply the trap changes to the object the trap is on (not the trap object itself).

So the most efficient way to do that would be to do something like:

object oChest = GetObjectByTag("CHEST1");
CreateTrapOnObject( TRAP_BASE_TYPE_MINOR_FIRE, oChest);
SetTrapDisarmable(oChest,FALSE);

More:

---

Yes, it does. I changed my code to reflect this, but I was still able to consistently reproduce that bug I sent in.

---

We received your bug report and I managed to fix the problem, so the fix will be in the upcoming beta 2 patch.

1.67 patch discussion (cont.)

---

An old issue:

When targeting items in inventories with unique power/activated items, the DM avatar runs off toward the corner of the area.

This old issue that was brought up in:
Click Here

as possibly being fixed for 1.67. Is this still expected for 1.67? I didn't see any mention of it in 1.67 beta 1.

---

You mean this part of the 1.67 beta patch notes:

"Fixed an issue with using an item on another item causing the player to run to the corner of the area. The player will now run to get within range of the targetted item instead. "

If you are concerned about an issue that affects you, you may want to try out the beta patch and verify yourself whether or not the issue is fixed (and submit a bug report if it isn't).

1.68 Function Suggestions
We don't discuss game exploits on our forums.
Fixes to game cheating/exploits/hacking are never published in the patch notes either, other than a comment such as:

"Made some fixes to prevent game/character hacking. Sorry, but we will never publicly discuss specific changes to the game with regards to hacking the game. "

If you know of some aspect of the game that people are exploiting to cheat, please retest it in the 1.67 beta to determine whether or not it still exists (and if it does still exist please submit a bug to nwexploits@bioware.com with detailed step by step instructions on how to reproduce the problem).

Complaining about bugs when you haven't even taken the time to verify whether or not they are fixed in the beta patch is at best unproductive, amd can be counter productive and a waste of people's time.

Thanks,
Craig.

More:

---

I appologize, I had'nt read through all of the notes and realize now that it does state that you dont discuss fixed exploits so it could well be fixed.

---

No problem.
Sorry if I came across as harsh (now that I re-read what I posted after getting some sleep).
I basicaly wanted to point out that the best way to try and get an issue that you are concerned about resolved is to:

1) Retest the issue in the 1.67 beta to verify that it still exists (some issues that have been addressed may not make it into the patch notes for a few different reasons). If you want to verify you findings with other forum members by posting on the forums, please feel free to do that.

2) Submit a bug report about the issue to either nwbugs@bioware.comnwexploits@bioware.com or nwtoolsetbugs@biowar.e.com The bug report should include step by step instuctions on how to reproduce the problem (in the 1.67 beta). If the information that you supply in your bug report isn't sufficient to allow us to reproduce the problem, the chances of the issue being fixed aren't very good. The better the information is that you supply, the better the chances are that the problem will get fixed. Very few people actually take the time to send in bug reports, and fewer still actually supply enough information about the bug for us to know what it is, or how to reproduce it. It is very easy for us to remove duplicate reports (or combine information from multiple bug reports on the same issue), so we don't mind getting duplicate reports on the same issue.

If the issue is with one of the BioWare default scripts, including the name of the script (and including the part of the script that you believe is causing the problem) helps us tremendously to quickly locate the cause of scripting errors.

If you can demonstrate a bug easily in a small test module (i.e. typically a 2x2 area with all the necessary objects/scripts all set up to reproduce the problem in a easy manner) that can help a lot too. Frequently the challenge of trying to describe how to reproduce an issue in words causes the description to lose the essense of what actually makes the issue happen and a demo module can sometimes avoid that issue.

People in the community want certain issues addressed, we want to address issues and make NWN a better game. It is not always obvious what the best way is for us to help each other achieve our common goals, but hopefully this helps a bit.

1.67 Beta 1

---

If you want to set something to use resref instead of ID, you need to clear the ID by setting it to PORTRAIT_INVALID (65535). This then means it will "fall through" to the resref instead.

If you want to change the PCs portrait temporarilly, you can use this mechanism to your advantage. Rather than having to store their old portrait to restore it later, you can give them the ID of the new portrait and leave their portrait resref untouched. When you want to go back later, you set the portrait ID to POTRAIT_INVALID and it will fall through to the resref again.

---

I don't believe that was the intended behavior. Could you please send in a bug report on this to nwbugs@bioware.com

Setting the portrait by resref through scripting, probably should be automatically clearing the portrait ID for you internally so that you don't have to do it manually through scripting. I believe that would be more intuitive for end users and since you can get the resref before setting it to something new, you could just store that information and restore it later when you want to revert the portrait back to the original one.

missing cep.tlk file error

---

before my motherboard fried , I fixed this issue.. kinda. I moved cep up a folder, and it worked perfectly. oddly enough, it fixed it perfctly when I get the comp back up, ill check where I moved the .tlk file to see where i moved it to. however, I may have just forgotten to delete one/NWN that mgiht have been left from uninstalling the cep but not deleting the folder it puts in your NEverWinter Nights folder. we'll see

---

So what you are saying is that you moved the cep.tlk file from say:

c:nwntlkcep.tlk

to

c:nwncep.tlk

and that fixed the issue for you?

If that's the case, some one having this issue could try changing their ini setting from a relative path such as:

[Alias]
TLK=.tlk

to a hardcode path such as:

[Alias]
TLK=c:nwntlk

to see if that fixes the issue for them. Although you'll have to use the full path to location of the tlk folder on your system (the above path is just an example). Please post back whether or not this helped the issue.

Custom textures for server

---

Hi,
if I use custom textures in my module, and upload this module to the server, do the players need to download this texture or it will be visible by them without any downloads?

---

The custom texture will need to be added to a hack pak that is associated with the module. All players will then need to download and place the hack pak in their "hak" directory in order to see the textures.

Platinum to Diamond Upgrade

---

Ok I have a question. I just got Diamond Edition and have had the origional NWN's since release and downloaded ALL THOSE LONG PATCHES and am up to 1.66. So, tell me what happens now when I install the Diamond edition am I going to have to go through that patch download process again???
I just want SOJ and HOTU and the KM expansion. I don't want this to mess up my mods that I have downloaded an installed either. So it this possible?

---

The diamond edition installs version 1.66, which is the latest version until our upcoming 1.67 update (which should become available in the next month or so).

Stanley Woo, Quality Assurance

01 Feb 2006 - Xbox Giveaway Finished

---

lol am glad am not the winner i just have no clue why i entered i hate xbox lol

---

Free stuff is good, even if it's not the brand you prefer. If I won a Technic stereo system, I wouldn't look that gift horse in the mouth just because I'm a Sony man. It's still a stereo just like the XBox360 is still a console. Perhaps, if you'd won, you'd eventually find a game you liked or you'd send it as a gift or donate it to some worthwhile organization.

It'd be really hard for me to say that I'm glad I didn't win. So much good can be done with any contest prize, even if it's just to say that you won something.