Posted Friday, July 23, 2004 - 1:46 CET by chevalier
Here are today's BioWare 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
Can I turn off buff spell graphics?
actually the easiest way would be to blank out the annoying effects in visualeffects.2da However, both methods (modifying scripts / changing the .2da) have the potential to break your game, because some spells use visual effects to track their remaining duration...
More:
Are you saying that some spells actually use the graphic animation and not some integer so it knows when to go away? Could you please give an example spell please?
All spells that have a reoccuring spell effect over multiple rounds (i.e. melfs acid arrow, some bigby spells, firebrand, etc) and that are not area of effect spells use this as it is far less cpu intensive than the way those spells were implemented before HotU.
More:
So instead of removing the visual effect then replacing it with something harmless, like the tiny sparks protection from evil give, would be a safe bet? I am going to bug a server admin to get rid of the Epic Mage armor visual as soon as pick the spell.
The VFX_CESSEATE_* visual effects are usually good for such things because they don't show up until the spell duration expires. One more note: changing the .2da is client side which would allow people to disable the effects just on their low end machine. If you change the spellscripts instead, everyone on the server will be affected.
Crafting System Info
At a guess, it seems the x2_p_craftskills conversation has something to do with it. Any more info?
There are two conversations, one for modifying armor and one for crafting new items. The major functionality is in x2_inc_craft.nss (include file). Most of the stuff is 2da driven and comes from the des_crft_* 2da files. hope that helps
More:
What're these two conversations? I assume one of them is the x2_p_craftskills. I'll do my best to document the crafting system. Perhaps mod scripters can move away from ATS and CNR if needed functionality can be added to the Bioware crafting system.
x2_p_craftskills
x0_ something (not sure about the name, but there are not many x0 files in the global dialog resources)
Need a patch now.
The "high number addresses" you are talking about are probably taken from a "unable tor read/write from ..." error messge in the toolset.
These "addresses" are not set anywhere, are not programming mistakes or bug, it's an issue where the toolset trying to read memory outside it's memory space or at a non existant location, caused by a corrupted module. If your module gets corrupted, which can happen due to power failure during saves, hardware or software failure during save or write processes, it will most likely cause problems like this - nothing we can fix, it's something that can also happen to your word documents or files written by any other application when the write process is terminated prematurely due to a crash.
Bottomline: The problem has nothing to do with high numbers, because those "high" numbers are memory addresses and the problem is that some data in the corrupted module is making the toolset trying to access memory addresses outside the current application space or at invalid locations such as NULL (FFFFFFF). It's not a problem with NWN or the toolset, it's a problem with the module.
And no, 1.63 will not fix that, because we can't magically fix data not written correctly to disk due to an external failure - nobody can. To repair your module I would suggest exporting it area by area and reimporting it into a empty module, that will likely remove the corrupted files from it. There are no direct references to memory locations in your module (computers don't work that way), those errors occur when the toolset/game are trying to read damaged files/objects inside the module into memory. Whether or not data in a file is illegal can not be determined on the fly, unfortunately. Does your module use a hakpak or do you have files in your nwn\override directory?
More:
Thanks for the information and if you have any suggestions on how I can export the quest that I have in the corrupted mod please let me know.
while the mod is open in the toolset, all files inside it are in the modules\temp0 directory. Yyou can grab the journal (*.jrnl) file from there ( I assume you mean journal by quest) and copy it to a save location. Then you open the new mod and copy the file into the temp0 directory, change something in the module and save.
Well it finally happened
Hey. If you want to discuss the SecuRom copy protection which is required by our publisher Atari, I suggest you do this in Atari's very own community forums at http://www.ataricommunity.com and please contact Atari Support about your problem.
The reason for this is that if you do not contact Support, the numbers on which business decisions are made will not match the situation out there. "Everyone knows ..." doesn't work when it's "Support Says only X people complained about problem Y", so it is important that you contact Support and post it in their forum instead of here where it is not likely that it gets read by people involved making these decisions.
BioWare is aware that some people have issues with SecuRom on NWN, but we can't do anything about it at this point it - is not our call. I will leave this thread open so the original poster can get further suggestions on how his problem might be solved, but if it continues down the predictable road from "copy protection" to "downloadable solutions", etc, I will close it. Thank you for your understanding.