I would very much like it if the screenshots taken by the game came out in a format that most programs could read. They currently come out in .tga format, which I have to send to an online conversion service to have changed into some format my computer knows how to read. This is a real pain in the butt just to get a screenshot of the game! Really, change it to something else, like .bmp, .png, or .jpg. It is fine if the game likes to use the .tga format for more advanced tasks like custom content or whatnot, but just to get a simple screenshot should not be such a pain...
I would very much like it if the screenshots taken by the game came out in a format that most programs could read.
Of this I talked about in another post created by me and I think .. the .tga format must be changed for the screanshot in such a way that everyone can open it without problems.
I've always used sagethumbs but I've read that it has probs with png in win 10. (disclosure: I, myself, have had no troubles thus far,, YMMV) It basically lets you see thumbnails of most images and you can simply r/click on them for instant tga-jpg, among many other options.
Can we get an .ini for combat to not automatically hit on a 20. Similar to the saving throws one. With everyone up-scaling levels. This will give option to builders if they want number of attack builds to trump high attack bonus builds. I know this is kinda controversial and that why it be an option.
Expand the maximum space that server descriptions and module descriptions can have in the server browser. They've always been woefully short because they get truncated if its too long. There's a scroll bar in the server/module description window in the server browser; use it!
I'm not sure if this is where a request like this should go, but since it probably has something to do with ServerDesc.txt, I thought it should go here.
Changing the hardcoded Race Selection Screen to a dynamic List-like selection (like classes, feats... work) so custom player races are possible without the need of nwnx/leto.
Fix the game client so it will run both .bik and .wbm file formats. As it stands right now, it only runs .wbm which breaks compatibility with earlier modules.
Two new server ini options due to in part with the new server vault structure making it easier to reveal your alt accounts. Anonymity and separation of OOC and IC is very important on PWs:
HideLogin=0; 0 Is how it works now. 1 will hide the logout/login message for DMS (no so and so has joined/left game as a gamemaster). 2 will hide logout/login message for players or alternatively will say has joined game. PortraitTell=0; 0 is how it works now. 1 changes it so instead of sending a tell to the player account on portrait click, it sends a tell to the character.
Well, usual disclaimer about not knowing if this is the right place for this suggestion, but here goes:
It would be so nice if the game could pre-load the linked areas to the current area. If a PC is in Area4, with three transitions to Area1, Area2, and Area7, the engine would load all those areas. Then when the PC moves through transition to Area7, which has 2 transitions (to Area4 and Area3), once Area7 is fully loaded, Area4 and Area3 would begin loading in background.
This would make transitions so much nicer and faster. Pie in the sky, maybe. But I love pie.
Nice suggestion for the linked areas pre-loading: add a minimum delay of loading time (3 or 4 seconds) for make sure that player have read the area name. Sometimes my PC load too much fast loading and I can't get aware what area I am...
Nice suggestion for the linked areas pre-loading: add a minimum delay of loading time (3 or 4 seconds) for make sure that player have read the area name. Sometimes my PC load too much fast loading and I can't get aware what area I am...
I think better than an artificial delay would be for builders to be able to allow scripted display of the load screen at any time. Separate request, maybe?
Well, usual disclaimer about not knowing if this is the right place for this suggestion, but here goes:
It would be so nice if the game could pre-load the linked areas to the current area. If a PC is in Area4, with three transitions to Area1, Area2, and Area7, the engine would load all those areas. Then when the PC moves through transition to Area7, which has 2 transitions (to Area4 and Area3), once Area7 is fully loaded, Area4 and Area3 would begin loading in background.
This would make transitions so much nicer and faster. Pie in the sky, maybe. But I love pie.
Change soundset.2da loading to better support soundset overrides, i.e soundsets without a STRREF entry should fall back to display the name in LABEL column.
In the toolset, most 2das like appearance.2da or placeables.2da already display the name in the LABEL column if STRREF is missing.
However if I add soundsets to the soundset.2da without adding a STRREF (= ****) I get BADSTRRREF entries in the character creation screen. It'd be useful to have it fall back to the LABEL entry as it would eliminate the need for a tlk, improving compatibility to other custom content and allowing easier creation of soundset overrides (especially useful for steam workshop)
Change soundset.2da loading to better support soundset overrides, i.e soundsets without a STRREF entry should fall back to display the name in LABEL column.
In the toolset, most 2das like appearance.2da or placeables.2da already display the name in the LABEL column if STRREF is missing.
However if I add soundsets to the soundset.2da without adding a STRREF (= ****) I get BADSTRRREF entries in the character creation screen. It'd be useful to have it fall back to the LABEL entry as it would eliminate the need for a tlk, improving compatibility to other custom content and allowing easier creation of soundset overrides (especially useful for steam workshop)
1. Override Hak Manager - like the mod manager for more modern games such as skyrim. This would allow us to use our custom class / custom race mods without having to edit all the modules before they're "playable". This would also make premium modules more appealing, as those can't be edited, so if you don't want to play vanilla classes, you can't play the premium modules without making a custom "patch". 2. Access to change hardcoded class features, spells, and feats. 3. Access to the scripts to change the hardcoded combat engine.
As I read through this thread I have noticed a lot of good comments on the hardcodedness of some scripting and geme engine assests, but I interpret this thread as about "Structural (file formats, references, "hardcodedness", configuration)", so I'll stick it to that here:
Structural (file formats): Move ERF/mdl/hak to ZIP
Right now ERF uses a rather special, proprietary binary container format. All modern systems use ZIP as the container to bundle their modules.
Pro: It can be opened and accessed with standard tools. Would allow for easier build system integration. The switch would be simple since it only involves the unpacking layer of the container loader. One could easily extend it to support both, the old and the ZIP format.
Structural (file formats): Move GFF/JRL/... to a textual format
Luckily, most module files are already in the generic GFF format. This can easily be converted forth and back into a textual representation. I've been doing this ever since in my GFF/JRL Compiler and Disassembler in the AuroraExt software: https://sourceforge.net/p/auroraext/wiki/AuroraExt/ Some comments before suggested XML, but I find it too much overhead, so I used a simple property style textual representation, which can be parsed by line-based tools. Pro: These text files can be edited with your preferred text-editor, pre-and post processed with standard tools or script and, most importatnly, can be put under source control (SVN, GIT, you name it).
Structural (file formats): Move DLG to a textual format that can be easily edited
While there is of course a way to find a technical representation of a dlg structure in textual form for the above mentioned benefits, the way DLG is structured makes it hard to edit for the common texter. Hence I strongly suggest to create a text based way to descibe dialogs.
Not wanting to pat myself on the head, but one of the first things I did when I started NWN modding ten years ago is to create exactly that: the dlgsrc Dilog Compiler (https://sourceforge.net/p/auroraext/wiki/AuroraExt/#dialog-compiler)... and it has been working well ever since. It works like this: . Merchant: Hello, what can I do for you?
>> PlayerOption: Show me your wares, please
... Merchant: !open_store Here we go...
>> PlayerOption: Never mind.
... Merchant: Bye.
Pro: Write dialog in a natural way with your preferred text editor. Allows for community people to write dialog without having the Toolset. Process it automatically, add it to source control. Use standard tools for spelling correction.
Hardcodedness: Externalize compiler tools and the build process
Currently, you need the Aurora Toolset to build a mod... and everyone is tweaking around to get rid of its shortcomings. All compiler tools (nss, gff, dlg) should be external to the toolset so that they a) can be executed separately and independently and b) can be integrated into other, more involed IDEs. Pro: Use modern build tools (MAKE, ant, gradle, you name it). Allows for the community to extend the capabilities of the compilers with new features themselves.
Hardcodedness: Give animations Names
Currently, there are only about 20 slots for custom animation. This is due to the limitation that only 20 ANIMATION_LOOPING_CUSTOM* constants exist that appear to be hardcoded to th animation's names in the basemodels. Animations already be given a speaking name in the mdl, but ActionPlayAnimation requires and INT to identify the animation, so there has to be some (hardcoded) mapping table. My suggestion:
add 100eds of new constants or
(preferred and simple) add a naming scheme like "every number above 200 will be interpreted as CUSTOMnnn", or
(probably not so simple) allow to provide the string name of the animation in *PlayAnimation
Hardcodedness: Start the game like the Toolset does
To my knowledge there is currently no commandline parameter to start nwn with a given module and a given character, like the toolset does when "F9" is pressed. Probably there already exists such a thing, but I haven't found a documentation about it.
Pro: one could start NWN from different IDEs without having to step through the menu.
Can we get the mdl to support bounce lower than 1 (like .8) seem to to default to 0 if below 1. Can we get splat property support too, I thought I remember this working before. If I wrong someone here will update me. Thanks.
Structural (file formats): Move ERF/mdl/hak to ZIP
I'm assuming you mean without compression? I'm not sure how well JIT decompression would work when demanding a resource.. We get stutters here as is.
By the way, you should be able to associate the official nim erf tool as an archiver (possibly with a wrapper script), so you get it in the context menus like zip.
Structural (file formats): Move GFF/JRL/... to a textual format
The text based formats are much more resource intensive. If the engine needs to compile them on the fly, that means a lot of stutter. If you mean as an intermediary format before deployed to the game.. we already have tools for that. Though it would be nice if the toolset could read them as e.g. JSON directly.
Structural (file formats): Move DLG to a textual format that can be easily edited
I will pat you on the back - the dialog compiler is great. IIRC, it works perfectly. And it is external, so it is easily hooked into the build system. I'm not sure what you are suggesting BD should do?
I'm all for this, Linu's AI as an example, is horrible. I'd be surrounded by undead and she'd be off fighting one and user her turn undead to take down one, rather than come to where I was and take out five.
I'm also working on a story/campaign where there will be 11 companions, and the player will play a pre-made main character and at a couple (or few) junctures in the game 3 parties of Four (characters will be set) will go different directions taking on different tasks, I'd like the player to be able to pick which task they want to take on and also which party member they want to play as for that juncture rather than being forced to remain as the main (PC)
How feasible would it be to add a new camera/character control scheme, where the camera is turned by the middle mouse button (as it is now) and the character turns to always face the camera orientation (yaw)? Combined with WASD movement, this would give a control scheme very much like most other third-person games.
I second this, I liked NwN 2's camera control where your cursor hit the top/bottom/sides and it would rotate the camera. I could play NwN2 with the camera view like I do most MMO's
Well, usual disclaimer about not knowing if this is the right place for this suggestion, but here goes:
It would be so nice if the game could pre-load the linked areas to the current area. If a PC is in Area4, with three transitions to Area1, Area2, and Area7, the engine would load all those areas. Then when the PC moves through transition to Area7, which has 2 transitions (to Area4 and Area3), once Area7 is fully loaded, Area4 and Area3 would begin loading in background.
This would make transitions so much nicer and faster. Pie in the sky, maybe. But I love pie.
@prwo Mostly agree with your suggestions, but several of these we've had for a while now. I'm not sure what you are suggesting BD change?
I'm suggesting that the Aurora Toolset is made more open to this fact. It shouldn't spend effort on reinventing the wheel. It should focus on doing NWN-specific stuff.
E.g. text editing should be externalized to tools that are way better at it than the Toolset can ever be. That's why I suggest to move the formats of text-intensive matter (esp. dlg) to text based forms.
Every IDE I know has some kind of preferences page (or a config file) where you can customize these aspects (what is my compiler, what is the build/packaging tool, which pre- and post-production scrips to be called, which editor to be used for this and that format, etc.).
Structural (file formats): Move ERF/mdl/hak to ZIP
I'm assuming you mean without compression? I'm not sure how well JIT decompression would work when demanding a resource.. We get stutters here as is.
Compression should not be a problem in my opinion. ZIP uses an index as well, so you can fetch and decompress files within on demand. The overhead of compression is minimal. I've measured this one time: NWN spends at least ten times the time on IO access that rather transferring data. My recommendation: load all data (erf or ZIP) into RAM and access it from there. This is WAY faster.
By the way, you should be able to associate the official nim erf tool as an archiver (possibly with a wrapper script), so you get it in the context menus like zip.
I'm not saying that there are no solutions or workarounds to these problems already today. The community has already solved most of them somehow. My point is that a) no workarounds would be necessary and b) further tools that are established far beyond the NWN community could be reused to do the deed for us if NWN was build on standardized, well-established tools and formats rather than on customized ones.
Structural (file formats): Move GFF/JRL/... to a textual format
The text based formats are much more resource intensive. If the engine needs to compile them on the fly, that means a lot of stutter.
While there is an overhead of transforming text to binary (and then to your internal data model, which you have to do in any case), I am convinced that it is so minimal that it can be neglected at all. This overhead will only add up if you transform from text to binary on every access. Without knowing the NWN's source code, I'm pretty sure that they load all necessary data into the data model during the module load screen. It wouldn't matter if module loading took 2 nano seconds longer if they were converting from text to binary first.
If you mean as an intermediary format before deployed to the game.. we already have tools for that. Though it would be nice if the toolset could read them as e.g. JSON directly.
Exactly. Furthermore, this way other (e.g. JSON) tools, well established outside of the NWN community, could be used to access and manipulate these files. The NWN community shouldn't have to reinvent the wheel either.
Structural (file formats): Move DLG to a textual format that can be easily edited
I will pat you on the back - the dialog compiler is great. IIRC, it works perfectly. And it is external, so it is easily hooked into the build system. I'm not sure what you are suggesting BD should do?
In a nutshell: open up the Aurora Toolset. Now it's a closed IDE that does everything by itself. "easily hooked" is relative. Modern IDEs are basically (text) editors with a lot of convenience features, but let everything else to be externalized and adapted to the need be.
However: an all-in-one Toolset has one big advantage: it is easy to install and runs out of the box. So, the newbie modder just needs a double click and can already start working.
Hardcodedness: Externalize compiler tools and the build process
The community compilers are already miles better than the stock toolset one, and they work like you say they should. Let's improve those further.
Yes, there is probably a tool for everything somewhere if you can find it. But the obstacle in going from using just the toolset out of the box to using fancy extension stuff is still higher than it needs to be.
I've been thinking a lot about how to make changes to the game (new classes, feats, spells etc.) be more self-contained, with the goal of just being able to download a hak, attach it to your module and it work with minimal (ideally no) changes. One of the big obstacles to this are 2das/tlks.
Currently if you make any changes/additions to them you have to worry about other people using the same IDs as you. Currently, the only way around it is to unofficially reserve a range of numbers you might need and hope everyone else gets the memo. On top of all this, if two haks modify the same 2da you have to manually merge them yourself which is awful.
I would love it if we could have something like namespacing for 2da and tlk entries. Effectively you have your own self-contained set of entries for 2da files. Instead of referencing feat id 312, reference feat ID 1 in namespace "my_namespace".
You could easily support it in script by adding an optional extra parameter for the namespace to everything that handles getting 2da entries. Instead of using:
int FEAT_MY_FEAT = 9001;
GetHasFeat(FEAT_MY_FEAT, pc); Use:
int FEAT_MY_FEAT = 1;
GetHasFeat(FEAT_MY_FEAT,pc,"my_namespace");
Under the hood the NWN can just auto-assign any namespaced entries to whatever IDs it wants and keep a seperate table for namespaces in memory. Scripts that don't have/care about the particular 2da/tlk entries in the namespace can just use the auto-generated ID. Unfortunately, you would still have to be careful about storing data that depends on the 2da entries (e.g. save files, character files) and make them store the namespace and the entry id wherever this is the case.
I'm not actually sure what a Token System is. The only thing I can think of for the phrase is a positive reinforcement thing in Behavioural Psycology... which I somehow suspect is not what you're getting at.
Namespacing is a programming construct to deal with conflicting names. If you include someone elses code into your program and both your code and its code define a "Print" function, which one should the program use in any given circumstances? The obvious answer is your code uses yours and their code uses theirs. But what happens if, for some reason, you want to use their Print function in your code in some circumstance instead of your own? That's the thing namespacing deals with. In this case it would be to handle conflicting IDs rather than names.
I'll explain the problem I think it will solve in more detail:
As far as I'm aware, you can't append to a 2da, only write the whole thing at once. This means that if you have 2 haks that both edit a 2da you get the changes from one hak or the other but not both. How you currently have to get around this is you have to manually merge them by painstakingly going through and copying over every change from one to the other.
If any of the changes have the same rows then you're in for a world of pain because you now have to move one of them to a different row number and then find and change every other 2da entry and script that uses that particular row number as a reference. This is awful, boring, slow and really prone to errors. Currently, the community gets around this by reserving ranges in 2da files for popular haks/mods, but it still means you have to manually merge things.
If you could append data to 2das that would solve both those problems. However, that comes with its own problems. You wouldn't be able to explicitly reference anything you appended in your scripts/other 2das because the IDs/row numbers won't always be in the same place. You could append today and get row 4236 and then tomorrow someone adds a new hak file that gets loaded before yours and your row is now 4452.
So there needs to be a way to explicitly access your data when you don't know what its row/id is going to be. That's where namespacing comes in. It's saying "I'd like to access MY fifth row" (or that guy's fifth row) instead of THE fifth row.
Comments
It basically lets you see thumbnails of most images and you can simply r/click on them for instant tga-jpg, among many other options.
-JFK
This card would appear to be a duplication of a card that already existed in the Engine input board
https://trello.com/c/wRfOhP9o/107-optionally-preload-adjacent-areas-in-background-to-prevent-area-transition-loading-times
http://www.d20srd.org/srd/combat/combatStatistics.htm#armorClass
http://www.d20srd.org/srd/theBasics.htm#shieldBonus
And more control whether it stacks or not. I'm not sure the latest patch has finally softcoded the caps UPWARDS.
In the toolset, most 2das like appearance.2da or placeables.2da already display the name in the LABEL column if STRREF is missing.
However if I add soundsets to the soundset.2da without adding a STRREF (= ****) I get BADSTRRREF entries in the character creation screen.
It'd be useful to have it fall back to the LABEL entry as it would eliminate the need for a tlk, improving compatibility to other custom content and allowing easier creation of soundset overrides (especially useful for steam workshop)
EDIT: Actually this card covers it. Didn't see it at first.
2. Access to change hardcoded class features, spells, and feats.
3. Access to the scripts to change the hardcoded combat engine.
Structural (file formats): Move ERF/mdl/hak to ZIP
Right now ERF uses a rather special, proprietary binary container format.All modern systems use ZIP as the container to bundle their modules.
Pro: It can be opened and accessed with standard tools. Would allow for easier build system integration.
The switch would be simple since it only involves the unpacking layer of the container loader. One could easily extend it to support both, the old and the ZIP format.
Structural (file formats): Move GFF/JRL/... to a textual format
Luckily, most module files are already in the generic GFF format. This can easily be converted forth and back into a textual representation. I've been doing this ever since in my GFF/JRL Compiler and Disassembler in the AuroraExt software: https://sourceforge.net/p/auroraext/wiki/AuroraExt/Some comments before suggested XML, but I find it too much overhead, so I used a simple property style textual representation, which can be parsed by line-based tools.
Pro: These text files can be edited with your preferred text-editor, pre-and post processed with standard tools or script and, most importatnly, can be put under source control (SVN, GIT, you name it).
Structural (file formats): Move DLG to a textual format that can be easily edited
While there is of course a way to find a technical representation of a dlg structure in textual form for the above mentioned benefits, the way DLG is structured makes it hard to edit for the common texter.Hence I strongly suggest to create a text based way to descibe dialogs.
Not wanting to pat myself on the head, but one of the first things I did when I started NWN modding ten years ago is to create exactly that: the dlgsrc Dilog Compiler (https://sourceforge.net/p/auroraext/wiki/AuroraExt/#dialog-compiler)... and it has been working well ever since. It works like this:
. Merchant: Hello, what can I do for you? >> PlayerOption: Show me your wares, please ... Merchant: !open_store Here we go... >> PlayerOption: Never mind. ... Merchant: Bye.Pro: Write dialog in a natural way with your preferred text editor. Allows for community people to write dialog without having the Toolset. Process it automatically, add it to source control. Use standard tools for spelling correction.
Hardcodedness: Externalize compiler tools and the build process
Currently, you need the Aurora Toolset to build a mod... and everyone is tweaking around to get rid of its shortcomings.All compiler tools (nss, gff, dlg) should be external to the toolset so that they a) can be executed separately and independently and b) can be integrated into other, more involed IDEs.
Pro: Use modern build tools (MAKE, ant, gradle, you name it). Allows for the community to extend the capabilities of the compilers with new features themselves.
Hardcodedness: Give animations Names
Currently, there are only about 20 slots for custom animation. This is due to the limitation that only 20 ANIMATION_LOOPING_CUSTOM* constants exist that appear to be hardcoded to th animation's names in the basemodels. Animations already be given a speaking name in the mdl, but ActionPlayAnimation requires and INT to identify the animation, so there has to be some (hardcoded) mapping table.My suggestion:
Hardcodedness: Start the game like the Toolset does
To my knowledge there is currently no commandline parameter to start nwn with a given module and a given character, like the toolset does when "F9" is pressed. Probably there already exists such a thing, but I haven't found a documentation about it.Pro: one could start NWN from different IDEs without having to step through the menu.
By the way, you should be able to associate the official nim erf tool as an archiver (possibly with a wrapper script), so you get it in the context menus like zip. The text based formats are much more resource intensive. If the engine needs to compile them on the fly, that means a lot of stutter.
If you mean as an intermediary format before deployed to the game.. we already have tools for that. Though it would be nice if the toolset could read them as e.g. JSON directly. I will pat you on the back - the dialog compiler is great. IIRC, it works perfectly. And it is external, so it is easily hooked into the build system. I'm not sure what you are suggesting BD should do? The community compilers are already miles better than the stock toolset one, and they work like you say they should. Let's improve those further.
I'm also working on a story/campaign where there will be 11 companions, and the player will play a pre-made main character and at a couple (or few) junctures in the game 3 parties of Four (characters will be set) will go different directions taking on different tasks, I'd like the player to be able to pick which task they want to take on and also which party member they want to play as for that juncture rather than being forced to remain as the main (PC)
E.g. text editing should be externalized to tools that are way better at it than the Toolset can ever be.
That's why I suggest to move the formats of text-intensive matter (esp. dlg) to text based forms.
Every IDE I know has some kind of preferences page (or a config file) where you can customize these aspects (what is my compiler, what is the build/packaging tool, which pre- and post-production scrips to be called, which editor to be used for this and that format, etc.).
Compression should not be a problem in my opinion. ZIP uses an index as well, so you can fetch and decompress files within on demand. The overhead of compression is minimal.
I've measured this one time: NWN spends at least ten times the time on IO access that rather transferring data. My recommendation: load all data (erf or ZIP) into RAM and access it from there. This is WAY faster.
I'm not saying that there are no solutions or workarounds to these problems already today. The community has already solved most of them somehow.
My point is that
a) no workarounds would be necessary and
b) further tools that are established far beyond the NWN community could be reused to do the deed for us
if NWN was build on standardized, well-established tools and formats rather than on customized ones.
While there is an overhead of transforming text to binary (and then to your internal data model, which you have to do in any case), I am convinced that it is so minimal that it can be neglected at all. This overhead will only add up if you transform from text to binary on every access. Without knowing the NWN's source code, I'm pretty sure that they load all necessary data into the data model during the module load screen. It wouldn't matter if module loading took 2 nano seconds longer if they were converting from text to binary first.
Exactly.
Furthermore, this way other (e.g. JSON) tools, well established outside of the NWN community, could be used to access and manipulate these files. The NWN community shouldn't have to reinvent the wheel either.
In a nutshell: open up the Aurora Toolset.
Now it's a closed IDE that does everything by itself. "easily hooked" is relative. Modern IDEs are basically (text) editors with a lot of convenience features, but let everything else to be externalized and adapted to the need be.
However: an all-in-one Toolset has one big advantage: it is easy to install and runs out of the box. So, the newbie modder just needs a double click and can already start working.
Yes, there is probably a tool for everything somewhere if you can find it. But the obstacle in going from using just the toolset out of the box to using fancy extension stuff is still higher than it needs to be.
Currently if you make any changes/additions to them you have to worry about other people using the same IDs as you. Currently, the only way around it is to unofficially reserve a range of numbers you might need and hope everyone else gets the memo. On top of all this, if two haks modify the same 2da you have to manually merge them yourself which is awful.
I would love it if we could have something like namespacing for 2da and tlk entries. Effectively you have your own self-contained set of entries for 2da files. Instead of referencing feat id 312, reference feat ID 1 in namespace "my_namespace".
You could easily support it in script by adding an optional extra parameter for the namespace to everything that handles getting 2da entries. Instead of using:
int FEAT_MY_FEAT = 9001; GetHasFeat(FEAT_MY_FEAT, pc);Use:
int FEAT_MY_FEAT = 1; GetHasFeat(FEAT_MY_FEAT,pc,"my_namespace");Under the hood the NWN can just auto-assign any namespaced entries to whatever IDs it wants and keep a seperate table for namespaces in memory. Scripts that don't have/care about the particular 2da/tlk entries in the namespace can just use the auto-generated ID. Unfortunately, you would still have to be careful about storing data that depends on the 2da entries (e.g. save files, character files) and make them store the namespace and the entry id wherever this is the case.
Namespacing is a programming construct to deal with conflicting names. If you include someone elses code into your program and both your code and its code define a "Print" function, which one should the program use in any given circumstances? The obvious answer is your code uses yours and their code uses theirs. But what happens if, for some reason, you want to use their Print function in your code in some circumstance instead of your own? That's the thing namespacing deals with. In this case it would be to handle conflicting IDs rather than names.
I'll explain the problem I think it will solve in more detail:
As far as I'm aware, you can't append to a 2da, only write the whole thing at once. This means that if you have 2 haks that both edit a 2da you get the changes from one hak or the other but not both. How you currently have to get around this is you have to manually merge them by painstakingly going through and copying over every change from one to the other.
If any of the changes have the same rows then you're in for a world of pain because you now have to move one of them to a different row number and then find and change every other 2da entry and script that uses that particular row number as a reference. This is awful, boring, slow and really prone to errors. Currently, the community gets around this by reserving ranges in 2da files for popular haks/mods, but it still means you have to manually merge things.
If you could append data to 2das that would solve both those problems. However, that comes with its own problems. You wouldn't be able to explicitly reference anything you appended in your scripts/other 2das because the IDs/row numbers won't always be in the same place. You could append today and get row 4236 and then tomorrow someone adds a new hak file that gets loaded before yours and your row is now 4452.
So there needs to be a way to explicitly access your data when you don't know what its row/id is going to be. That's where namespacing comes in. It's saying "I'd like to access MY fifth row" (or that guy's fifth row) instead of THE fifth row.