So, Requests on Scripting!
Takhisis
Member Posts: 6
It is nominally possible that any amount of this may have been suggested already, but it's not presently on the front page. I'm also not aware to what it is that's in the new nwnscript.nss as stands; but I have a laundry-list of things that'd potentially have use.
1. SetCutsceneShaders (object oTarget, object oArea) - The introduction to shaders in NWN has a lot of potential in a lot of areas in the same way that lighting used to (still does, really...); and in my mind, the shaders -- given a lot of coder-end control -- would open up their full potential. This is one of them, and -- as you might guess if you're familiar with CutsceneMode -- the concept is essentially that it would adjust the shaders as viewed from the perspective of a single player object. This actually has a lot of uses outside of turning all of your Cutscenes into lens-flare filled Spielberg movies, like allowing changes to the UI relative to the player's current health; similar to what some modern games do! This is all assuming, of course, I understand shaders correctly.
2. AdjustAreaShadows (object oArea)- Not to be confused with adjusting the area 'lighting', this is adjusting an area's shadows -- the presence or lacking of shadows, as given off by objects when they are lit, and how strong/large those shadows are. This would be something that would need to be called to change from the default, ideally; so all areas would ordinarily display light as normal -- but if I wanted (for example) a few Faerie Fires spread throughout an Underdark city; as they are all weak sources of lighting enough that Drow can use them without discomfort characteristically, them giving off shadows would be decidedly uncharacteristic. On the other hand, if I wanted the hot, desert sun beating down on you anytime it was noon in an area; and the entire land being flat or lightly rolling plains; it might suit me to adjust the size of the shadows to be somewhat larger.
3. AdjustTileShadows (vector vLoc, object oArea(?)) - As above, but on a by-tile basis. Provide vector closest to tile location.
4. CopyObjectVariables (object oParam, object oInput) - It strikes me as weird that nobody has ever suggested or even thought of this. Simply put, scan all of the variables on an object and apply them to an object provided in the parameter. The practical use of this is primarily for systems using pseudo-persistence through storing many variables on an item; allowing them to call a single function as opposed to multiple with string-match checks in order to transplant them to an updated system.
5. PrintObjectVariablesToLog (oInput) - Similar to the above, but with the versatile function of creating the information in an external file, along with its type, as associated to the object's HexID. The use of this is actually twofold -- it can be hooked, on a practical level, to allow for the transfer of local systems to NWNX-based ones (Probably, anyway. Given some wizardry I don't understand...) or, by the server owner who knows what they're doing and uses these stored INTs as a big part of important systems for a player's progression or power on the server, it can be used to track down breaks in the system (or cheats) through the existence of either impossible or incorrect values; which is useful for troubleshooting.
6. SetLocalEffect(object oObject, effect eEffect) - Self-expository. Not even NWNX can get the remaining duration of an effect, to my knowledge; which means it's only the turf of the core game code. The biggest use of this is probably in the ability to determine the effects that an object should have because of feats -- either custom or standard with homebrew secondary effects -- but it has no shortage of practical uses as well. Since almost anything else can either be directly stored or indirectly converted and stored, currently effects are the only thing that can 'not' be stored using the base game's code.
7. SetTile(int iTileID, vector vEditCenter) - I've heard of CreateArea (and virtually all the rest of NWNX areas) being added to the new game, but setting tiles still seems to be really unexplored through ingame means. At the risk of virtually replacing the toolset, the ability to set tiles -- accompanied with a function to save the settings for an area -- would be a game-changer in random dungeon generation and in player-interactive change in the module. If this doesn't exist yet, it should probably hit the roadmap somewhere. NOTE: edit 'center' is inserted instead of the id of the tile, because of tile groups -- which cannot be added one-by-one, and shouldn't be in the first place.
8. UnloadOverride(string sFilename) - Stop loading the assets of a certain file. Something that should probably only be used for bug-testing -- due to the consequences naturally created by unloading a file once the game is already running -- for models that behave oddly.
9. LoadOverrideFolder(string sFolder, int bServerEnd) - Recognize an additional file as the user-end override with the specified name. File should be in the Override directory anyway -- which won't cause any weird interraction, since the game typically ignores files in the override folder that aren't simply spilled out into it. If bServerEnd is TRUE, then it will use this to load the file as a server-end override only, and not attempt to locate that filename on any other system. Practical uses of this are for archiving specific override packages, allowing for versioning (yes, I used that word -- of all people) of an Override between new instances; and to tell the game which file to prioritize of two otherwise identical filenames. The only caveat I can see is, of course, I'm not sure; can this be handled as a script function?
10. SetBaseAbilityScore(int iAbility, int iAmount, object oCreature) - Set the base ability score of a creature. This function has previously only existed through Letoscript implementations in NWNX; and if absolutely none of the rest of this list happens, this as a native function really should've happened before the game released to begin with. >:C My subraces are not complete without proper stats, nopers!
1. SetCutsceneShaders (object oTarget, object oArea) - The introduction to shaders in NWN has a lot of potential in a lot of areas in the same way that lighting used to (still does, really...); and in my mind, the shaders -- given a lot of coder-end control -- would open up their full potential. This is one of them, and -- as you might guess if you're familiar with CutsceneMode -- the concept is essentially that it would adjust the shaders as viewed from the perspective of a single player object. This actually has a lot of uses outside of turning all of your Cutscenes into lens-flare filled Spielberg movies, like allowing changes to the UI relative to the player's current health; similar to what some modern games do! This is all assuming, of course, I understand shaders correctly.
2. AdjustAreaShadows (object oArea)- Not to be confused with adjusting the area 'lighting', this is adjusting an area's shadows -- the presence or lacking of shadows, as given off by objects when they are lit, and how strong/large those shadows are. This would be something that would need to be called to change from the default, ideally; so all areas would ordinarily display light as normal -- but if I wanted (for example) a few Faerie Fires spread throughout an Underdark city; as they are all weak sources of lighting enough that Drow can use them without discomfort characteristically, them giving off shadows would be decidedly uncharacteristic. On the other hand, if I wanted the hot, desert sun beating down on you anytime it was noon in an area; and the entire land being flat or lightly rolling plains; it might suit me to adjust the size of the shadows to be somewhat larger.
3. AdjustTileShadows (vector vLoc, object oArea(?)) - As above, but on a by-tile basis. Provide vector closest to tile location.
4. CopyObjectVariables (object oParam, object oInput) - It strikes me as weird that nobody has ever suggested or even thought of this. Simply put, scan all of the variables on an object and apply them to an object provided in the parameter. The practical use of this is primarily for systems using pseudo-persistence through storing many variables on an item; allowing them to call a single function as opposed to multiple with string-match checks in order to transplant them to an updated system.
5. PrintObjectVariablesToLog (oInput) - Similar to the above, but with the versatile function of creating the information in an external file, along with its type, as associated to the object's HexID. The use of this is actually twofold -- it can be hooked, on a practical level, to allow for the transfer of local systems to NWNX-based ones (Probably, anyway. Given some wizardry I don't understand...) or, by the server owner who knows what they're doing and uses these stored INTs as a big part of important systems for a player's progression or power on the server, it can be used to track down breaks in the system (or cheats) through the existence of either impossible or incorrect values; which is useful for troubleshooting.
6. SetLocalEffect(object oObject, effect eEffect) - Self-expository. Not even NWNX can get the remaining duration of an effect, to my knowledge; which means it's only the turf of the core game code. The biggest use of this is probably in the ability to determine the effects that an object should have because of feats -- either custom or standard with homebrew secondary effects -- but it has no shortage of practical uses as well. Since almost anything else can either be directly stored or indirectly converted and stored, currently effects are the only thing that can 'not' be stored using the base game's code.
7. SetTile(int iTileID, vector vEditCenter) - I've heard of CreateArea (and virtually all the rest of NWNX areas) being added to the new game, but setting tiles still seems to be really unexplored through ingame means. At the risk of virtually replacing the toolset, the ability to set tiles -- accompanied with a function to save the settings for an area -- would be a game-changer in random dungeon generation and in player-interactive change in the module. If this doesn't exist yet, it should probably hit the roadmap somewhere. NOTE: edit 'center' is inserted instead of the id of the tile, because of tile groups -- which cannot be added one-by-one, and shouldn't be in the first place.
8. UnloadOverride(string sFilename) - Stop loading the assets of a certain file. Something that should probably only be used for bug-testing -- due to the consequences naturally created by unloading a file once the game is already running -- for models that behave oddly.
9. LoadOverrideFolder(string sFolder, int bServerEnd) - Recognize an additional file as the user-end override with the specified name. File should be in the Override directory anyway -- which won't cause any weird interraction, since the game typically ignores files in the override folder that aren't simply spilled out into it. If bServerEnd is TRUE, then it will use this to load the file as a server-end override only, and not attempt to locate that filename on any other system. Practical uses of this are for archiving specific override packages, allowing for versioning (yes, I used that word -- of all people) of an Override between new instances; and to tell the game which file to prioritize of two otherwise identical filenames. The only caveat I can see is, of course, I'm not sure; can this be handled as a script function?
10. SetBaseAbilityScore(int iAbility, int iAmount, object oCreature) - Set the base ability score of a creature. This function has previously only existed through Letoscript implementations in NWNX; and if absolutely none of the rest of this list happens, this as a native function really should've happened before the game released to begin with. >:C My subraces are not complete without proper stats, nopers!
3
Comments
4. NWNX can do this using nwnx_funcs. You can do a while loop and just copy all the local variables off one object on to another.
6. NWNX can pull and modify the remaining duration of an effect. As for storing effects... I honestly never considered a use for that. Usually I just set a switch and apply the effect when it should be applied. NWNX is capable of hooking the OnApply and OnRemove for effects so you can 100% control how that is handled.
7. Areas are literally pre-loaded(this is why you get a loading screen) when you enter the map. This is why adjusting tiles isn't a very ideal thing to do. A tile isn't just visual... It's a representation of multiple data that is preloaded to allow many aspects of the game to function at all. For instance a tile explains: How AI should pathfind in that spot, what the xyz coordinates of objects on it are, how AoEs interact in that space, Line of Sight checks, the sounds made by footsteps on that surface, whether parts of that tile can be trasversed, and whether spell targeting on the ground applies and probably some other things.