There's no way GFF fields get removed. That'd break everything. At most they'd add more validation, such that some values that are invalid but were swallowed by the old game throw an error in the new one.
@Omnipsi Those are valid requests. Some (OnSpawn, OnHourChange, customizable heartbeats) can be done in nwscript currently, though not as elegantly. Door/trigger painting and changing scripts can be done in NWNX. I know people are getting tired of me saying this, and I know NWNX is no good for single-player modules, but I'm just mentioning it in case it solves someone's use case. Item layering is "doable" but would get really messy. Anyone is free to PM me if they need help implementing any of the above.
@Sherincall Yep! Almost all of those suggestions arise from what I've scripted in the past in, indeed, quite clunkier ways than integration into the base game would facilitate.
That said, the in-game painting of doors and triggers, and the rebinding of event scripts in particular (especially for the player characters events, to avoid the flaws and limitations of the "default" script) are actually ones I've wanted for singleplayer module building for a long time.
You're definitely right though! My main motivator is just avoiding/reducing the practice of recursive delay loops as much as possible...
Change .mod Module archive format to contain .erf capsules within:
Module resource limitations are no fun! Using haks to segregate resources isn't very fun either! Allow .mod archives to contain .erf archives (and/or other .mod archives?), and to load & unload those dependent resources when needed -- in Toolset, and in game (nwscript)!
A la, dynamic resource loading; just for erf capsules within self-contained modules, instead of any external manipulation or resource-by-resource management. (NWNX:EE can still do all of that, probably much more efficaciously with a capsule loading backend to hook into and abuse lol.)
To facilitate: nwscript functions to LoadCapsule and UnloadCapsule in real-time, operating on the preexisting capsules within the self-contained .mod archive! SP modules could load the capsule of areas (and their dependent content) currently needed, unloading that capsule when the PC moves to the next capsule of areas/content. Servers could more easily separate "geographical" and other demarcated batches of areas/content (as opposed to haks), unloading and loading content as its needed in real-time, improving server and client performance (if/when decently implemented by the mod builder, that is).
Within the Toolset this would necessitate being able to drag resources from the "module palette" to an opened "capsule palette" and back and forth, easily relocating the corresponding files to the corresponding .erf within the .mod (temp0) archive. Resources saved to capsules would be manipulable as normal in the Toolset, when the capsule is opened alongside the module. The root of the .mod archive would still contain all the core module-specific resources (events, settings, start point, whatnot) along with universal resources the builder leaves there, ie scripts, items, and other core blueprints, that would be loaded with the mod and not be unloadable in real-time.
This last suggestion would likely break compatibility. I fail to understand why the need for retro compatibility is so strong.
NWN has been used to create modules and PWs for more than 15 years now. Making it so NWN can't run those modules would be insulting to the people that a) kept the game going even after it was abandoned by BioWare and b) are the most likely to purchase and support NWN:EE.
This last suggestion would likely break compatibility. I fail to understand why the need for retro compatibility is so strong.
NWN has been used to create modules and PWs for more than 15 years now. Making it so NWN can't run those modules would be insulting to the people that a) kept the game going even after it was abandoned by BioWare and b) are the most likely to purchase and support NWN:EE.
Think of NWN as Windows, one of the reasons over the years people have choose it is because of the vast library of titles available. But with every new version of windows there comes new features that sometimes break compatibility. In the end people did not stop buying windows because many new titles were available (and you can always install an old version of windows on a separate hard disk if you really want to play the old classics).
The real questions here should be "is said feature really worth breaking compatibility?" and "it is just a feature that will no longer be available or will it really break down modules?". If the new features are worth it no doubt people will buy NWN:EE and update the modules to work in it and write even more custom content, NWN:EE needs to be exciting and for that it needs new features the creator community wants.
Change .mod Module archive format to contain .erf capsules within: [snip] unloading and loading content as its needed in real-time, improving server and client performance (if/when decently implemented by the mod builder, that is).
@Omnipsi Can you explain how this will improve performance? The server (and client, but that's a different story) already unload unused resources. It would be extremely difficult for you to manually manage these in nwscript better than the server does already - and the overhead of such scripts would likely render it pointless anyway. Grouping them into capsules makes it easier to add and remove whole systems when building a module - maybe moving an entire section between modules - but it only makes life easier for the dev. It doesn't affect performance.
As a "let us do this so we can build things easier" request, this makes perfect sense. As a "let us do this to get better runtime performance", I don't think so.
@Sherincall Completely understandable! If that's the case, then my bad for misunderstanding. My assumption was:
I'm assuming a system like ResMan/DynRes, where for example a persistent world may have hundreds of areas and thousands of scripts -- including heartbeats and whatnot -- and if many of those areas can be unloaded from the server at runtime it wouldn't have to process any of the scripts or other game systems in those unused areas unless a player wishes to go to those areas.
Basically, what Sinfar does with it's "ERFs" / web interface.
Sorry, I might have misunderstood. That's active (i.e. spawned) objects, a wholly different beast. Areas are a bit weird in that they are always spawned. If you have an area with a creature in it, both the area and the creature will run the HB scripts.
You can despawn the creature, and even the area in some cases with the new functions. If you're requesting functions to make it easier to despawn/respawn the already active object instances, then I totally misunderstood the request - but I still don't see why the recursive ERF unpacking is needed. The ERF (and MOD) contain the templates which are used to create the instances. Unloading the templates is done automatically. Again, areas are a bit weird in that the template is also an instance.
FWIW, unless you literally have 10000+ areas in the module, simply despawning all the objects and bailing early in the HB script if no PCs are around will be enough. The overhead of starting and immediately ending the 10k scripts every 6 seconds isn't a big deal at all.
Yeah I was referring to the instances. I was under the impression nwscript HB events were more onerous than that, though, whoops. So yeah that's not actually a useful feature, hah.
For the "recursive ERF" thing, that's to make it easier to build with the 16k resource limitation, directly within the Toolset (no external muckery). Automatically segmenting the module into (optional) sub-modules/erfs within the larger module archive, instead of manually removing resource files to separate .hak files.
In that case, I just want modules to cope with resource limitations efficiently while still being self-contained; each sub-module/erf also facilitates/necessitates separate palette groupings, and the ERF export/import feature could export/import the erf archive (instead of selecting individual files as now) out of the module erf, making it much easier to share and collaborate on module building (without having to resort to using git or complex organizational hierarchies or any other bureaucracy).
Worth noting that the 16k resources limit is a bug that should be fixed regardless of recursive ERF implementation. The format supports much more resources. Agreed that managing the mod resources could use a lot of love.
OMG I forgot this one, How about a custom effect/way to make models into statues in game, there was glitch with pc perception that cause the creature models to mover or reset. So if you fix that we can make creatures turned to statues in-game with scripting and with creature scaling(giant statues).
A module switch to toggle custom content would be very helpful.
Suggested settings 0 = load all custom content 1 = load module-specific custom content only
The reason for this is to prevent conflict (technical and especially interpersonal) between module builders and global modders. Don't understand? Bear with me!
Like most moddable games, nwn allows two sorts of custom content, global and module-specific. Global changes impact every module (including the OC, PWs etc) e.g. overrides, patch haks or unofficial patches. Module-specific changes (e.g. module haks) only affect one module.
There are broadly two types of modder, those who make modules, and those who make global content. Since the makers are generally amateurs, understanding of the compatibility issues is often weak, so when technical conflicts arise, they often descend into personal abuse, which no one wants.
Historically, NWN has been fortunate. As it happens, most custom content makers have been happy to make materials for module-specific haks, so no conflict. With some exceptions, there has been a culture of discouraging overrides. Also, the load hierarchy ensures that if an object is in both the global and module-specific resource pool, the latter prevails.
However, conflict is possible, especially with scripts, but also with models, animations etc. This can happen when the module is expecting OC resource X but receives a global mod X' which behaves differently. More complicated issues can happen. If, for example, OC resources X and Y are coupled, module change X' may be broken by global change Y', even if (X' Y) and (X Y') both work.
In the future, this could be a very much bigger issue. Hopefully, EE will generate a resurgence in modding. Other gaming cultures are often about global modding, as it is a quick win & reputation builder for the modder, and modules (custom adventures) are not so important. So we can predict that global modding will surge in popularity, with little regard for the module culture, which feels like an accident waiting to happen.
If we could eliminate the conflict between global and module changes, then there would be no reason why modders should not feel entitled to make global changes.
In the past, we have tried to manage this by encourging players to remove global mods before playing custom modules. This has met with limited success - some players understand the game better than the modders, but others don't.
Hence the request. I appreciate that it may be that global resources are loaded before the module settings are interrogated, so it may be necessary for the loader to undo global changes if the module says it doesn't want them.
@Proleric This is an interesting idea, one I'd thought of a few times. Currently a way to prevent module players from using overrides/patch haks to change the default NWN resources used in the module (that come from the default installation), if module designers don't want them to, is to include the whole game's stock resources in their module haks! Which is kind of silly.
Meanwhile, there's also likely an adverse reaction from players being told that they can't use their favorite sky/tile/head overrides by a module creator, so it is of course difficult to take sides, much like the issues I raised in the Area Rendering Customization discussion.
Ultimately, however, the real issue is that if Beamdog changes the way that haks/overrides are stored/downloaded/loaded, which is something they feel strongly about changing, it may emphasize or de-emphasize the need for a setting like this to be present.
With the current way that hak contents are validated (they aren't), however, losing overrides/patches (which are still loaded on client launch) wouldn't be foolproof, the haks on my computer for servers I am looking at/helping are often modified when I change their contents to audition fixes/upgrades before sending them to the server/module authors/admins for consideration.
Something needs to be done with the localization system.
The original version of NWN had a colossal mountain of text. Every localizable string was stored in a single file called "dialog.tlk". The total number strings in it was 112009, and they were randomly mixed, by which I mean there was no way to isolate strings that related to general content (such as UI, spells, standard items, etc), from those that related specifically to the campaigns. There was also no logic to how the strings were ordered in the file, so you could expect to see 10 class names, followed by 5 dialogue options, followed by 9 item descriptions, followed by another 7 class names, and so on. This turned any localization effort into a madness-inducing punishment, because one couldn't divide the text into manageable chunks to set milestones.
For example, let's say we want to make it possible to build modules and play them in my language. For that, we would (logically) only need to translate the interface, and wouldn't have to bother with the official campaigns. Alas, it's impossible with the current setup — for the reasons explained above. It's even worse with custom modules, since those usually don't have any localizable TLK-files at all, so we'd have to manually edit the modules themselves, possibly breaking them, and making updates incompatible (since they'd overwrite the translated text).
Thus, my suggestions:
Split the "dialog.tlk" into several smaller files with clusters of categorized strings: campaign A, campaign B, campaign C, interface, spells, feats, skills, standard items, standard NPCs, etc.
Streamline the process of converting the TLK-files into common formats, such as XLS, XML, or plain text, so we could use localization tools to accurately measure the text and manage the translation process.
Add a feature to the Toolset, or make an external utility, that would parse the module and export all localizable strings into custom TLK-files, while replacing the text in the module with references to the strings from the newly created TLK-files.
Curiously, the original version of NWN's Toolset had a feature that allowed to store localizable strings in different languages, and to display a different version of a string depending on PC's gender. Also, at least one language (I was able to confirm Polish) had special tokens in "dialog.tlk" that accommodated the use of vocative case, effectively solving the problem translators face when localizing RPGs in Slavic languages.
The issue with the current system is that the list of supported languages and those special tokens seem to be hardcoded into the game, or at least I wasn't able to find the way to modify them. In any case, my suggestions:
Make language-specific tokens modifiable.
Store localizable strings outside the module's file (preferably as categorized TLK-files).
CNWSMessage::SendServerToPlayerGuiTimingEvent() has a BYTE to specify which event we're timing. Valid values are 1-8 and they translate into string refs hardcoded on the client:
Could we get values above e.g. 127 to instead index into a custom 2DA for the text? This will let us schedule custom events like "Reloading..." or "Equipping..." and so on.
I know this wont be all that popular a suggestion however, as a builder I think having more options are always better. I would like to see an easier way to disable multiclassing, currently I think the only way to do this is a work around through scripting by deleveling a character and letting them know multiclassing is not allowed unless I missed something somewhere. I would like to see the option to somehow bypass the whole multiclassing thing all together.
I would love a custom GUI screen that lets DM see a players Journal entries and edit/add journal entries of PC/party in-game and hit update and player journal flashes. I'm sure DMs would love this feature
While it's not possible for DMs to view player journals, it is already possible for DMs to create in-game dynamic journals that are updated and will have the player journal button flash when added/updated through the use of custom tokens. The Thay PW relies heavily on this for our DM scheduled events, rather than posting them on a forum site somewhere. Right now we have it setup to affect all players in the PW, but it could certainly be modified to apply only to a party or individual PC, if desired.
While it's not possible for DMs to view player journals, it is already possible for DMs to create in-game dynamic journals that are updated and will have the player journal button flash when added/updated through the use of custom tokens. The Thay PW relies heavily on this for our DM scheduled events, rather than posting them on a forum site somewhere. Right now we have it setup to affect all players in the PW, but it could certainly be modified to apply only to a party or individual PC, if desired.
I know, I have already done this in my base. I confused this is suggestion board and it is possible if they make the programing changes and add a custom UI. Imagine how much easier it would be to have a journal list of the selected player where you could just copy paste update a journal entry and/or click an add/delete button and to expanded to endless adventures. It just what we have taken to the next level, plus this would be out of the box no scripts needed and new people who dm would have a easier time.
In mine opinion NWN EE or original lives mostly from its modding community so gradual softcoding of game (non UI) would be best option. I always thought of NWN as mine divine playground building and destroying worlds at whim.
Can we get a new module event, called feat intercept. This would allow us to intercepting activating feat call into a script so we can add scripted requirement and function. Example You should not be able to activate furry of blows with a shield. With module event you can intercept it activation with a script requirement. This would save hassle with custom 2da work and ugly workarounds. Some custom function would be int GetlastFeatActivated() object GetlastfeatActivatedby
From the perspective of an NWN model maker/tweaker, the method by which the game composes and animates player characters is archaic and has long limited content creation. I couldn't guess if each of these could be done, but I would do the following to best enable your own development team and modelers like myself to make high-quality, flexible content.
The robe and cloak emitters support skinmesh, transparency (cloak only) and can track multiple bones. Please extend this functionality to all emitters that comprise player characters. This is essential for being able to create more modern player models that flex, bend and flow through their motions rather than looking like a set of play-doh balls that've been gobbed together for a stop-motion project. Transparency in conjunction with these more flexible emitters will allow layering of parts to create the illusion of more complex geometries without having to waste modeling time and processing power. Parts that don't take advantage of this new feature would still be backwards-compatible but it opens up new avenues for us to develop in.
If possible, it would be wonderful if we could skin parts on players and NPCs with animated textures. As with the above, lets the community create some cool things and cheat on our geometry a bit. I think the basic functionality of this has been explored with NWShader.
NWN does character heads like a game from its time; that is to say it does them badly. Heads and hair are a single piece and helmets replace the head entirely. Ideally I would like to see heads broken up into bald heads and separate hair models like any modern sensible game does for flexibility and file size. I would additionally like hair to be able to skin to bones and support animation, it would be a massive improvement over danglymesh. I'd like helmets to not be hardcoded to modeltype 1. I'd like them instead to default to modeltype 2, the same modeltype as used by weapons. Weapons are gorgeous- they respect bones, support independent animations, skinning, transparency, everything. Extending this functionality to the helm slot in conjunction with modernizing the head composition will do absolute wonders for those of us out there prettifying this old workhorse of a game.
Practically, however, I don't think it's developmentally feasible to redo how heads are composed. Helmets supporting modeltype 2 would be more than enough to allow new development in avenues impossible before while maintaining compatibility with existing content. Of course, please add the ability to call the helmet nodes for a modeltype 2 helmet as well- scripters will doubtless want to play with helmets that can be modified like weapons.
I would like the armor of a dynamic player character to no longer control the appearance of the shin and foot emitters. I would like this responsibility shifted to the boot slot and have boots made modeltype 2 like with helmets above. Upper = kneecap, middle = shin, lower = foot. I'd like the same thing done for forearms/hands, having their appearance controlled by the bracer slot. By breaking up which parts control which emitters a bit you'll enable better and more flexible customization of dynamic characters.
If possible, it would also be beneficial to change how NWN creates its races. Rather than having separate models for each race, the game should instead scale a single male or female dynamic character's individual nodes to a set of presets for that race/phenotype. This means I've only got to create two models instead of twenty-four if I want to support every base race, gender and phenotype. It also means that if, say, a new race is modded in, I don't have to create new models for it. Instead, the new race scales my existing model by its own presets- i.e. this makes our work waaaaaay more compatible and drastically reduces the overall workload on the modelers and disk footprint on your computer. Struck through, this is probably impractical.
Finally, I'd like to encourage the development of a robust set of updated content creation tools so that the community can take advantage of all these lovely new toys.
Not sure if it's been suggested yet, but I'd like to see a significant increase in the number of includes/functions that the compiler can hold to avoid the IDENTIFIER LIST FULL error.
The more integrated and complex our scripting systems become with new enhancements, we need to make sure that we're not limited by the old ceilings in the compiler.
Comments
@Omnipsi Those are valid requests. Some (OnSpawn, OnHourChange, customizable heartbeats) can be done in nwscript currently, though not as elegantly. Door/trigger painting and changing scripts can be done in NWNX. I know people are getting tired of me saying this, and I know NWNX is no good for single-player modules, but I'm just mentioning it in case it solves someone's use case. Item layering is "doable" but would get really messy.
Anyone is free to PM me if they need help implementing any of the above.
That said, the in-game painting of doors and triggers, and the rebinding of event scripts in particular (especially for the player characters events, to avoid the flaws and limitations of the "default" script) are actually ones I've wanted for singleplayer module building for a long time.
You're definitely right though! My main motivator is just avoiding/reducing the practice of recursive delay loops as much as possible...
Module resource limitations are no fun! Using haks to segregate resources isn't very fun either! Allow .mod archives to contain .erf archives (and/or other .mod archives?), and to load & unload those dependent resources when needed -- in Toolset, and in game (nwscript)!
A la, dynamic resource loading; just for erf capsules within self-contained modules, instead of any external manipulation or resource-by-resource management. (NWNX:EE can still do all of that, probably much more efficaciously with a capsule loading backend to hook into and abuse lol.)
To facilitate: nwscript functions to LoadCapsule and UnloadCapsule in real-time, operating on the preexisting capsules within the self-contained .mod archive! SP modules could load the capsule of areas (and their dependent content) currently needed, unloading that capsule when the PC moves to the next capsule of areas/content. Servers could more easily separate "geographical" and other demarcated batches of areas/content (as opposed to haks), unloading and loading content as its needed in real-time, improving server and client performance (if/when decently implemented by the mod builder, that is).
Within the Toolset this would necessitate being able to drag resources from the "module palette" to an opened "capsule palette" and back and forth, easily relocating the corresponding files to the corresponding .erf within the .mod (temp0) archive. Resources saved to capsules would be manipulable as normal in the Toolset, when the capsule is opened alongside the module. The root of the .mod archive would still contain all the core module-specific resources (events, settings, start point, whatnot) along with universal resources the builder leaves there, ie scripts, items, and other core blueprints, that would be loaded with the mod and not be unloadable in real-time.
The real questions here should be "is said feature really worth breaking compatibility?" and "it is just a feature that will no longer be available or will it really break down modules?". If the new features are worth it no doubt people will buy NWN:EE and update the modules to work in it and write even more custom content, NWN:EE needs to be exciting and for that it needs new features the creator community wants.
Grouping them into capsules makes it easier to add and remove whole systems when building a module - maybe moving an entire section between modules - but it only makes life easier for the dev. It doesn't affect performance.
As a "let us do this so we can build things easier" request, this makes perfect sense. As a "let us do this to get better runtime performance", I don't think so.
I'm assuming a system like ResMan/DynRes, where for example a persistent world may have hundreds of areas and thousands of scripts -- including heartbeats and whatnot -- and if many of those areas can be unloaded from the server at runtime it wouldn't have to process any of the scripts or other game systems in those unused areas unless a player wishes to go to those areas.
Basically, what Sinfar does with it's "ERFs" / web interface.
You can despawn the creature, and even the area in some cases with the new functions. If you're requesting functions to make it easier to despawn/respawn the already active object instances, then I totally misunderstood the request - but I still don't see why the recursive ERF unpacking is needed. The ERF (and MOD) contain the templates which are used to create the instances. Unloading the templates is done automatically. Again, areas are a bit weird in that the template is also an instance.
FWIW, unless you literally have 10000+ areas in the module, simply despawning all the objects and bailing early in the HB script if no PCs are around will be enough. The overhead of starting and immediately ending the 10k scripts every 6 seconds isn't a big deal at all.
For the "recursive ERF" thing, that's to make it easier to build with the 16k resource limitation, directly within the Toolset (no external muckery). Automatically segmenting the module into (optional) sub-modules/erfs within the larger module archive, instead of manually removing resource files to separate .hak files.
In that case, I just want modules to cope with resource limitations efficiently while still being self-contained; each sub-module/erf also facilitates/necessitates separate palette groupings, and the ERF export/import feature could export/import the erf archive (instead of selecting individual files as now) out of the module erf, making it much easier to share and collaborate on module building (without having to resort to using git or complex organizational hierarchies or any other bureaucracy).
Suggested settings
0 = load all custom content
1 = load module-specific custom content only
The reason for this is to prevent conflict (technical and especially interpersonal) between module builders and global modders. Don't understand? Bear with me!
Like most moddable games, nwn allows two sorts of custom content, global and module-specific. Global changes impact every module (including the OC, PWs etc) e.g. overrides, patch haks or unofficial patches. Module-specific changes (e.g. module haks) only affect one module.
There are broadly two types of modder, those who make modules, and those who make global content. Since the makers are generally amateurs, understanding of the compatibility issues is often weak, so when technical conflicts arise, they often descend into personal abuse, which no one wants.
Historically, NWN has been fortunate. As it happens, most custom content makers have been happy to make materials for module-specific haks, so no conflict. With some exceptions, there has been a culture of discouraging overrides. Also, the load hierarchy ensures that if an object is in both the global and module-specific resource pool, the latter prevails.
However, conflict is possible, especially with scripts, but also with models, animations etc. This can happen when the module is expecting OC resource X but receives a global mod X' which behaves differently. More complicated issues can happen. If, for example, OC resources X and Y are coupled, module change X' may be broken by global change Y', even if (X' Y) and (X Y') both work.
In the future, this could be a very much bigger issue. Hopefully, EE will generate a resurgence in modding. Other gaming cultures are often about global modding, as it is a quick win & reputation builder for the modder, and modules (custom adventures) are not so important. So we can predict that global modding will surge in popularity, with little regard for the module culture, which feels like an accident waiting to happen.
If we could eliminate the conflict between global and module changes, then there would be no reason why modders should not feel entitled to make global changes.
In the past, we have tried to manage this by encourging players to remove global mods before playing custom modules. This has met with limited success - some players understand the game better than the modders, but others don't.
Hence the request. I appreciate that it may be that global resources are loaded before the module settings are interrogated, so it may be necessary for the loader to undo global changes if the module says it doesn't want them.
-JFK
Meanwhile, there's also likely an adverse reaction from players being told that they can't use their favorite sky/tile/head overrides by a module creator, so it is of course difficult to take sides, much like the issues I raised in the Area Rendering Customization discussion.
Ultimately, however, the real issue is that if Beamdog changes the way that haks/overrides are stored/downloaded/loaded, which is something they feel strongly about changing, it may emphasize or de-emphasize the need for a setting like this to be present.
With the current way that hak contents are validated (they aren't), however, losing overrides/patches (which are still loaded on client launch) wouldn't be foolproof, the haks on my computer for servers I am looking at/helping are often modified when I change their contents to audition fixes/upgrades before sending them to the server/module authors/admins for consideration.
Please allow support for Wav 32bit PCM, as opposed to the vvurrent 16bit PCM limit.
I hope the new sound subsystem can accommodate this.
The original version of NWN had a colossal mountain of text. Every localizable string was stored in a single file called "dialog.tlk". The total number strings in it was 112009, and they were randomly mixed, by which I mean there was no way to isolate strings that related to general content (such as UI, spells, standard items, etc), from those that related specifically to the campaigns. There was also no logic to how the strings were ordered in the file, so you could expect to see 10 class names, followed by 5 dialogue options, followed by 9 item descriptions, followed by another 7 class names, and so on. This turned any localization effort into a madness-inducing punishment, because one couldn't divide the text into manageable chunks to set milestones.
For example, let's say we want to make it possible to build modules and play them in my language. For that, we would (logically) only need to translate the interface, and wouldn't have to bother with the official campaigns. Alas, it's impossible with the current setup — for the reasons explained above. It's even worse with custom modules, since those usually don't have any localizable TLK-files at all, so we'd have to manually edit the modules themselves, possibly breaking them, and making updates incompatible (since they'd overwrite the translated text).
Thus, my suggestions:
- Split the "dialog.tlk" into several smaller files with clusters of categorized strings: campaign A, campaign B, campaign C, interface, spells, feats, skills, standard items, standard NPCs, etc.
- Streamline the process of converting the TLK-files into common formats, such as XLS, XML, or plain text, so we could use localization tools to accurately measure the text and manage the translation process.
- Add a feature to the Toolset, or make an external utility, that would parse the module and export all localizable strings into custom TLK-files, while replacing the text in the module with references to the strings from the newly created TLK-files.
Curiously, the original version of NWN's Toolset had a feature that allowed to store localizable strings in different languages, and to display a different version of a string depending on PC's gender. Also, at least one language (I was able to confirm Polish) had special tokens in "dialog.tlk" that accommodated the use of vocative case, effectively solving the problem translators face when localizing RPGs in Slavic languages.The issue with the current system is that the list of supported languages and those special tokens seem to be hardcoded into the game, or at least I wasn't able to find the way to modify them. In any case, my suggestions:
Sorry if this is not the right place to post this
Some custom function would be int GetlastFeatActivated() object GetlastfeatActivatedby
The robe and cloak emitters support skinmesh, transparency (cloak only) and can track multiple bones. Please extend this functionality to all emitters that comprise player characters. This is essential for being able to create more modern player models that flex, bend and flow through their motions rather than looking like a set of play-doh balls that've been gobbed together for a stop-motion project. Transparency in conjunction with these more flexible emitters will allow layering of parts to create the illusion of more complex geometries without having to waste modeling time and processing power. Parts that don't take advantage of this new feature would still be backwards-compatible but it opens up new avenues for us to develop in.
If possible, it would be wonderful if we could skin parts on players and NPCs with animated textures. As with the above, lets the community create some cool things and cheat on our geometry a bit. I think the basic functionality of this has been explored with NWShader.
NWN does character heads like a game from its time; that is to say it does them badly. Heads and hair are a single piece and helmets replace the head entirely. Ideally I would like to see heads broken up into bald heads and separate hair models like any modern sensible game does for flexibility and file size. I would additionally like hair to be able to skin to bones and support animation, it would be a massive improvement over danglymesh. I'd like helmets to not be hardcoded to modeltype 1. I'd like them instead to default to modeltype 2, the same modeltype as used by weapons. Weapons are gorgeous- they respect bones, support independent animations, skinning, transparency, everything. Extending this functionality to the helm slot in conjunction with modernizing the head composition will do absolute wonders for those of us out there prettifying this old workhorse of a game.
Practically, however, I don't think it's developmentally feasible to redo how heads are composed. Helmets supporting modeltype 2 would be more than enough to allow new development in avenues impossible before while maintaining compatibility with existing content. Of course, please add the ability to call the helmet nodes for a modeltype 2 helmet as well- scripters will doubtless want to play with helmets that can be modified like weapons.
I would like the armor of a dynamic player character to no longer control the appearance of the shin and foot emitters. I would like this responsibility shifted to the boot slot and have boots made modeltype 2 like with helmets above. Upper = kneecap, middle = shin, lower = foot. I'd like the same thing done for forearms/hands, having their appearance controlled by the bracer slot. By breaking up which parts control which emitters a bit you'll enable better and more flexible customization of dynamic characters.
Struck through, this is probably impractical.If possible, it would also be beneficial to change how NWN creates its races. Rather than having separate models for each race, the game should instead scale a single male or female dynamic character's individual nodes to a set of presets for that race/phenotype. This means I've only got to create two models instead of twenty-four if I want to support every base race, gender and phenotype. It also means that if, say, a new race is modded in, I don't have to create new models for it. Instead, the new race scales my existing model by its own presets- i.e. this makes our work waaaaaay more compatible and drastically reduces the overall workload on the modelers and disk footprint on your computer.
Finally, I'd like to encourage the development of a robust set of updated content creation tools so that the community can take advantage of all these lovely new toys.
The more integrated and complex our scripting systems become with new enhancements, we need to make sure that we're not limited by the old ceilings in the compiler.