Community support ideas - Revision history

Ashhawk: BSN link flagged for maintenance - using AWB

2022-02-01T15:57:44Z

BSN link flagged for maintenance - using AWB

Sunjammer: Given the first paragraph it appears this page should be in the "community features" category.

2010-02-22T22:41:04Z

Given the first paragraph it appears this page should be in the "community features" category.

Craig Graff at 18:55, 7 February 2010

2010-02-07T18:55:13Z

BryanDerksen: Category:Feature requests

2010-01-15T22:11:42Z

Category:Feature requests

BryanDerksen: local variables could be another thing that helper applications could be written for, if they prove troublesome

2009-10-07T16:19:33Z

local variables could be another thing that helper applications could be written for, if they prove troublesome

BryanDerksen: fix a misspelling, add an "other text tools" entry

2009-10-02T21:26:18Z

fix a misspelling, add an "other text tools" entry

BryanDerksen at 17:09, 2 October 2009

2009-10-02T17:09:03Z

BryanDerksen: thrown in a conflict detector idea

2009-10-02T16:58:16Z

thrown in a conflict detector idea

BryanDerksen: starting this page with a list of useful ideas that we likely won't have the resources to get to

2009-10-02T16:21:36Z

starting this page with a list of useful ideas that we likely won't have the resources to get to

New page

Unfortunately the team at BioWare that prepared the toolset for public use doesn't have enough resources to address every request or suggestion for improvement. The following is a collection of ideas for improvements that BioWare couldn't get to but that could quite possibly be done by community contributions instead.

;Better, more consistent camera control settings: At BioWare the various different editors of the toolset are used by various different specialists, each focused on their own area of expertise. This has led to different camera controls schemes being used in the area and level editors, for example. The [[camera control]] schemes are set in the [[DefaultSettings.xml]] file. Community-contributed versions of DefaultSettings with more consistent control schemes would be most welcome, or perhaps even a third-party application to make it easier to edit camera controls without XML expertise.

; Voice over management tools : BioWare was unable to release their [[voice over]] and [[localization]] software. The information needed for managing voice over work can be extracted from module [[talk table]]s; it would likely be very useful if there were some sort of application available to make recording VO for dialogue lines easier.

; String ID migration tools : One of the knottier problems that the toolset has with [[builder to builder]] export and import is keeping [[string ID]] numbers from colliding. It frequently has to renumber string IDs as a result. The toolset is able to find and correct all of the string ID references used internally when it does this, but it is unable to automatically find and correct the filenames of voice over wav files and [[FaceFX]] files (these files include the string ID number in their filenames as a way of assocating them with their respective lines). A log file is generated during the builder to builder process that records what string ID changes were done, an application that uses this log to rename files could be quite useful.

; Model import tools : Due to legal constraints BioWare was unable to release the export scripts they used to turn 3DSMax models into the format the game uses. Third-party converters and plugins for 3DSMax or for other 3D modeling programs will be essential for full-blown content creation.

@@ Line 1: / Line 1: @@
 Unfortunately the team at BioWare that prepared the toolset for public use doesn't have enough resources to address every request or suggestion for improvement. The following is a collection of ideas for improvements that BioWare couldn't get to but that could quite possibly be done by community contributions instead.
@@ Line 15: / Line 17: @@
 ; Variable 2DA management : One of the major differences in how scripting functions between NWN and DA is that you need to pre-define [[local variable]]s in a variable [[2DA]] before they can be used. Changing this would require a major overhaul of how the engine works and so isn't really an option, but perhaps applications could be written to ease local variable management if it proves to be a long-term hassle. In theory one could perhaps scan through all the scripts in a module looking for local variable assignment functions and then try to automatically add the local variables used to local variable 2DAs.(One alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.)
-[[Category:Community_feature_suggestions]]
+[[Category:Community feature suggestions]]

@@ Line 1: / Line 1: @@
 Unfortunately the team at BioWare that prepared the toolset for public use doesn't have enough resources to address every request or suggestion for improvement. The following is a collection of ideas for improvements that BioWare couldn't get to but that could quite possibly be done by community contributions instead.
-;Better, more consistent camera control settings: At BioWare the various different editors of the toolset are used by various different specialists, each focused on their own area of expertise. This has led to different camera controls schemes being used in the area and level editors, for example. The [[camera control]] schemes are set in the [[DefaultSettings.xml]] file. Community-contributed versions of DefaultSettings with more consistent control schemes would be most welcome, or perhaps even a third-party application to make it easier to edit camera controls without XML expertise.
+; Better, more consistent camera control settings: At BioWare the various different editors of the toolset are used by various different specialists, each focused on their own area of expertise. This has led to different camera controls schemes being used in the area and level editors, for example. The [[camera control]] schemes are set in the [[DefaultSettings.xml]] file. Community-contributed versions of DefaultSettings with more consistent control schemes would be most welcome, or perhaps even a third-party application to make it easier to edit camera controls without XML expertise.
 ; Voice over management tools : BioWare was unable to release their [[voice over]] and [[localization]] software. The information needed for managing voice over work can be extracted from module [[talk table]]s; it would likely be very useful if there were some sort of application available to make recording VO for dialogue lines easier.
@@ Line 15: / Line 15: @@
 ; Variable 2DA management : One of the major differences in how scripting functions between NWN and DA is that you need to pre-define [[local variable]]s in a variable [[2DA]] before they can be used. Changing this would require a major overhaul of how the engine works and so isn't really an option, but perhaps applications could be written to ease local variable management if it proves to be a long-term hassle. In theory one could perhaps scan through all the scripts in a module looking for local variable assignment functions and then try to automatically add the local variables used to local variable 2DAs.(One alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.)
-[[Category:Feature requests]]
+[[Category:Community_feature_suggestions]]

@@ Line 13: / Line 13: @@
 ; Conflict detector : It should be relatively straightforward to extract a list of all the string IDs and [[resref]]s used by any given module. Given that, it should be possible to create an application to automatically compare a set of modules and determine if there are any conflicts between them.
-; Variable 2DA management : One of the major differences in how scripting functions between NWN and DA is that you need to pre-define [[local variable]]s in a variable [[2DA]] before they can be used. Changing this would require a major overhaul of how the engine works and so isn't really an option, but perhaps applications could be written to ease local variable management if it proves to be a long-term hassle. In theory one could perhaps scan through all the scripts in a module looking for local variable assignment functions and then try to automatically add the local variables used to local variable 2DAs.
+; Variable 2DA management : One of the major differences in how scripting functions between NWN and DA is that you need to pre-define [[local variable]]s in a variable [[2DA]] before they can be used. Changing this would require a major overhaul of how the engine works and so isn't really an option, but perhaps applications could be written to ease local variable management if it proves to be a long-term hassle. In theory one could perhaps scan through all the scripts in a module looking for local variable assignment functions and then try to automatically add the local variables used to local variable 2DAs.(One alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.)
 [[Category:Feature requests]]

← Older revision		Revision as of 22:11, 15 January 2010
Line 14:		Line 14:

	; Variable 2DA management : One of the major differences in how scripting functions between NWN and DA is that you need to pre-define [[local variable]]s in a variable [[2DA]] before they can be used. Changing this would require a major overhaul of how the engine works and so isn't really an option, but perhaps applications could be written to ease local variable management if it proves to be a long-term hassle. In theory one could perhaps scan through all the scripts in a module looking for local variable assignment functions and then try to automatically add the local variables used to local variable 2DAs.		; Variable 2DA management : One of the major differences in how scripting functions between NWN and DA is that you need to pre-define [[local variable]]s in a variable [[2DA]] before they can be used. Changing this would require a major overhaul of how the engine works and so isn't really an option, but perhaps applications could be written to ease local variable management if it proves to be a long-term hassle. In theory one could perhaps scan through all the scripts in a module looking for local variable assignment functions and then try to automatically add the local variables used to local variable 2DAs.
		+
		+	[[Category:Feature requests]]

← Older revision		Revision as of 16:19, 7 October 2009
Line 12:		Line 12:

	; Conflict detector : It should be relatively straightforward to extract a list of all the string IDs and [[resref]]s used by any given module. Given that, it should be possible to create an application to automatically compare a set of modules and determine if there are any conflicts between them.		; Conflict detector : It should be relatively straightforward to extract a list of all the string IDs and [[resref]]s used by any given module. Given that, it should be possible to create an application to automatically compare a set of modules and determine if there are any conflicts between them.
		+
		+	; Variable 2DA management : One of the major differences in how scripting functions between NWN and DA is that you need to pre-define [[local variable]]s in a variable [[2DA]] before they can be used. Changing this would require a major overhaul of how the engine works and so isn't really an option, but perhaps applications could be written to ease local variable management if it proves to be a long-term hassle. In theory one could perhaps scan through all the scripts in a module looking for local variable assignment functions and then try to automatically add the local variables used to local variable 2DAs.

@@ Line 5: / Line 5: @@
 ; Voice over management tools : BioWare was unable to release their [[voice over]] and [[localization]] software. The information needed for managing voice over work can be extracted from module [[talk table]]s; it would likely be very useful if there were some sort of application available to make recording VO for dialogue lines easier.
-; String ID migration tools : One of the knottier problems that the toolset has with [[builder to builder]] export and import is keeping [[string ID]] numbers from colliding. It frequently has to renumber string IDs as a result. The toolset is able to find and correct all of the string ID references used internally when it does this, but it is unable to automatically find and correct the filenames of voice over wav files and [[FaceFX]] files (these files include the string ID number in their filenames as a way of assocating them with their respective lines). A log file is generated during the builder to builder process that records what string ID changes were done, an application that uses this log to rename files could be quite useful.
+; String ID migration tools : One of the knottier problems that the toolset has with [[builder to builder]] export and import is keeping [[string ID]] numbers from colliding. It frequently has to renumber string IDs as a result. The toolset is able to find and correct all of the string ID references used internally when it does this, but it is unable to automatically find and correct the filenames of voice over wav files and [[FaceFX]] files (these files include the string ID number in their filenames as a way of associating them with their respective lines). A log file is generated during the builder to builder process that records what string ID changes were done, an application that uses this log to rename files could be quite useful.
 ; Model import tools : Due to legal constraints BioWare was unable to release the export scripts they used to turn 3DSMax models into the format the game uses. Third-party converters and plugins for 3DSMax or for other 3D modeling programs will be essential for full-blown content creation. See [[MMH]] and [[MSH]] for model file specifications.
-; Conflict detector : It should be relatively straightforward to extract a list of all the string IDs and resrefs used by any given module. Given that, it should be possible to create an application to automatically compare a set of modules and determine if there are any conflicts between them.
+; Conflict detector : It should be relatively straightforward to extract a list of all the string IDs and [[resref]]s used by any given module. Given that, it should be possible to create an application to automatically compare a set of modules and determine if there are any conflicts between them.

← Older revision		Revision as of 16:58, 2 October 2009
Line 8:		Line 8:

	; Model import tools : Due to legal constraints BioWare was unable to release the export scripts they used to turn 3DSMax models into the format the game uses. Third-party converters and plugins for 3DSMax or for other 3D modeling programs will be essential for full-blown content creation.		; Model import tools : Due to legal constraints BioWare was unable to release the export scripts they used to turn 3DSMax models into the format the game uses. Third-party converters and plugins for 3DSMax or for other 3D modeling programs will be essential for full-blown content creation.
		+
		+	; Conflict detector : It should be relatively straightforward to extract a list of all the string IDs and resrefs used by any given module. Given that, it should be possible to create an application to automatically compare a set of modules and determine if there are any conflicts between them.