@prwo I found your post in the forum's spam filter. I have returned it here and verified you so this should not happen again. I will delete your shorter post.
@prwo I found your post in the forum's spam filter. I have returned it here and verified you so this should not happen again. I will delete your shorter post.
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.
So your concern is more about 2DAs than actually namespaces in the scripting language, right?
A namespace in NWNscript would be something like this: namespace myNamespace1
{
const int SOMETHING = 34;
int myFunction (string x) { ... }
}
namespace myNamespace2
{
const int SOMETHING = 22;
void myFunction (int z) { ... }
}
void main ()
{
int x = myNamespace1.SOMETHING;
int y = myNamespace2.SOMETHING;
int z = myNamespace1.myFunction("xxx");
myNamespace2.myFunction(x);
}
As for 2DA merging: The game engine relies on having identifier lists for each type of game object. E.g. one big list of all body part models. You can only override this list in a hak / mdl, but not extend it.
This simplifies the definition of all other game objects that depend on such lists. E.g. a PLC only stores the int reference into the one master list, but not the e.g. mdl file name itself.
Since the one big list contains not only the model itself, but most likely additional information about that object, which is nowhere else to be stored and which should not be stored in the target file itself for reasons of reusability, you will always have to deal with such a list.
In my opinion the solution requires two things to be done:
Allow for multiple 2DAs of the same domain (body parts, armor, ...) to coexist. The "one big list" is formed of all such 2DAs
Rem: A namespace in the reference alone would not totally solve the issue, because two HAKs produced by two different people may use the same namespace and then the problem starts all over again.
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.
So your concern is more about 2DAs than actually namespaces in the scripting language, right?
A namespace in NWNscript would be something like this: namespace myNamespace1
{
const int SOMETHING = 34;
int myFunction (string x) { ... }
}
namespace myNamespace2
{
const int SOMETHING = 22;
void myFunction (int z) { ... }
}
void main ()
{
int x = myNamespace1.SOMETHING;
int y = myNamespace2.SOMETHING;
int z = myNamespace1.myFunction("xxx");
myNamespace2.myFunction(x);
}
As for 2DA merging: The game engine relies on having identifier lists for each type of game object. E.g. one big list of all body part models. You can only override this list in a hak / mdl, but not extend it.
This simplifies the definition of all other game objects that depend on such lists. E.g. a PLC only stores the int reference into the one master list, but not the e.g. mdl file name itself.
Since the one big list contains not only the model itself, but most likely additional information about that object, which is nowhere else to be stored and which should not be stored in the target file itself for reasons of reusability, you will always have to deal with such a list.
In my opinion the solution requires two things to be done:
Allow for multiple 2DAs of the same domain (body parts, armor, ...) to coexist. The "one big list" is formed of all such 2DAs
Rem: A namespace in the reference alone would not totally solve the issue, because two HAKs produced by two different people may use the same namespace and then the problem starts all over again.
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.
So your concern is more about 2DAs than actually namespaces in the scripting language, right?
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".
I was talking about it in terms of programming namespaces but really XML namespaces would be a more apt comparison given that 2das are data. I just avoided using those as an example because XML is an awful, verbose footgun and no-one actually uses XML namespaces (except for big web-apis from the days before JSON).
NWN doesn't really need namespacing for scripting because it's so easy to make your own pseudo-namespace via prefixing function names. You can't go "using foo.bar as bar" and have to explicitly call out your namespace on every use, but it works.
As for 2DA merging: The game engine relies on having identifier lists for each type of game object. E.g. one big list of all body part models. You can only override this list in a hak / mdl, but not extend it.
This simplifies the definition of all other game objects that depend on such lists. E.g. a PLC only stores the int reference into the one master list, but not the e.g. mdl file name itself.
Since the one big list contains not only the model itself, but most likely additional information about that object, which is nowhere else to be stored and which should not be stored in the target file itself for reasons of reusability, you will always have to deal with such a list.
In my opinion the solution requires two things to be done:
Allow for multiple 2DAs of the same domain (body parts, armor, ...) to coexist. The "one big list" is formed of all such 2DAs
That's exactly what I'm implying, although now I read back I didn't explicitly say as such. Where I was saying "append to 2das" I was basically saying "the ability to have seperate copies of 2da files and have NWN auto-merge them".
Rem: A namespace in the reference alone would not totally solve the issue, because two HAKs produced by two different people may use the same namespace and then the problem starts all over again.
I'm glad you made this point. I considered bringing it up but rejected doing so for brevity's sake.
You're absolutely correct that it's just moving the potential for a conflict up a level, but most other suggestions will have the same drawback. My point with namespacing is that it's a heck of a lot easier to find and replace on a string than on a bunch of numbers. In practice, namespace conflicts would be very rare because it would imply you're using 2 haks that do the exact same thing.
The solution that doesn't have this problem, as you pointed out, is UUIDs (technically you can still get conflicts but there's very, very long odds). I considered them but decided against them.
Full disclaimer; I really, really don't like UUIDs. They're slow, large, cumbersome and cache/prediction unfriendly. The only time I ever use them is either when they're forced on me or if I have some situation where there's multiple parralel writes happening with no atomics/locks (e.g. database clusters with more than 1 master).
I think they're entirely inappropriate for NWN's use case. They are just overkill. Here's a personal anecdote on UUIDs that will explain why I think this better than any technical assertion:
Civilization 6 uses UUIDs in its mods as a unique identifier for any given mod - each mod has one UUID. If two mods have the same UUID they are assumed to be different versions of the same mod.
When I'm messing around with Civ 6 modding, do you know what I do when I need to fill in a UUID? I copy and paste one from another mod and change a digit. This completely removes any of the randomness guarantees of UUIDs and makes conflicts actually reasonably likely (it won't just be me doing this). Even knowing this I still do it because it's a pain to do it properly.
Sure, you could type UUID generator into google and either use a online generator or download a program, but even that involves a bunch alt-tab + copy and paste. Also to actually use these UUIDS you've already generated you need to be constantly searching for them to copy and paste across. I can keep "24012" in my head while I'm working with it. I can't do that for "5d23901-7e8d-4614-8014-f6a902e8a253".
I do the above - knowing full well it's a terrible thing to do - for one UUID. How many people are going use them properly for the potentially hundreds you'd need in a hak file? Absolutely no-one. Not if they don't have to. Which they won't have to because of backwards compatibility.
TLDR; UUID's are a pain. You can't memorise them, you need external programs to generate them and they are really complicated. I think most people wouldn't use them if they were an option.
Can we get a tag/item property/feat whatever on creatures that allow them to ignore non-walkable walkmesh areas. This would be great for flying creatures/ swimming creatures in underwater zones.
Here another one and this one I pretty sure is doable. Can we get the ability to set the grass height per area. This will give us areas a little bit different look even though using the same tileset.
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
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
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.
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...
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.
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.
Has anyone requested override subfolders yet, to tidy up what can sometimes be thousands of individual files? If so, forget it.
Not that it's not a great request (in fact, should be extended to hak/ folder as well), but hopefully there's no more need for overrides. Since haks are loaded at character creation now, and you can preload patch haks for your own mods, there's very little use for the override folder.
Any server or community mod that is asking you to put files in the override didn't do their homework very well.
@Sherincall No offense, but it'd be tedious as all hell to put a hak into every module I go to play just so I can use my overrided animal companions or a simple spell modification. Overrides aren't just used for module making, and it definitely wasn't their intended purpose. Being able to organize them would be a great boon, though.
@Sherincall No offense, but it'd be tedious as all hell to put a hak into every module I go to play just so I can use my overrided animal companions or a simple spell modification. Overrides aren't just used for module making, and it definitely wasn't their intended purpose. Being able to organize them would be a great boon, though.
@DerpCity You're not supposed to put them in every module. You're supposed to edit your userpatch.ini (nwnpatch.ini in 1.69) and list the haks you want there. Then, they apply to all modules. That way your files are still organized in haks as logical groups, and you can quickly enable/disable haks you want, without deleting anything. Even with subfolders in override, if you want to disable a certain group, you need to remove it from that folder. This way, you just comment out a single line.
@Sherincall That's pretty cool, I didn't even know that kind of functionality existed. I suppose it'll be easier to organize my animals if they were in one easily modifiable hak. I might try it out some time, so thanks for the info.
Can we get a tag/item property/feat whatever on creatures that allow them to ignore non-walkable walkmesh areas. This would be great for flying creatures/ swimming creatures in underwater zones.
Here another one and this one I pretty sure is doable. Can we get the ability to set the grass height per area. This will give us areas a little bit different look even though using the same tileset.
Ability To Add New Working Range Weapons The relationship between rangeweapons and ammotypes.2da is broken or hard coded in some way. It is currently impossible to add new range weapons (New Rows, Overriding Works) into the game because they will not be able to utilize either existing ammo (bolts, bullets, arrows) or any new ammo you might add to the ammotypes 2da. (You can get range weapons into the game but they constantly say "No Ammo" even if you have the correct ammo required)
Do two things: Allow us to add new range weapons AND allow us to add new ammo types and make sure those things both function. (Strip out any hardcoding)
Would the following requests: exposing default data instances (quest updated sound, for instance) and improving toolset functionality for missing ability scores fit here?
I noticed that when moving to different areas, even if the background music is the same (ie, different levels of same dungeon), the music is still restarted. I was wondering whether it could be possible to have the music keep playing seamlessly, if it is the same, considering that playback continues during the load screen. Is this the relevant thread, @JuliusBorisov ?
Ability To Add New Working Range Weapons The relationship between rangeweapons and ammotypes.2da is broken or hard coded in some way. It is currently impossible to add new range weapons (New Rows, Overriding Works) into the game because they will not be able to utilize either existing ammo (bolts, bullets, arrows) or any new ammo you might add to the ammotypes 2da. (You can get range weapons into the game but they constantly say "No Ammo" even if you have the correct ammo required)
Do two things: Allow us to add new range weapons AND allow us to add new ammo types and make sure those things both function. (Strip out any hardcoding)
I noticed that when moving to different areas, even if the background music is the same (ie, different levels of same dungeon), the music is still restarted. I was wondering whether it could be possible to have the music keep playing seamlessly, if it is the same, considering that playback continues during the load screen. Is this the relevant thread, @JuliusBorisov ?
I noticed that when moving to different areas, even if the background music is the same (ie, different levels of same dungeon), the music is still restarted. I was wondering whether it could be possible to have the music keep playing seamlessly, if it is the same, considering that playback continues during the load screen. Is this the relevant thread, @JuliusBorisov ?
One special request from me. right now you cant have more then 15 letters for your textures but sometimes i need way more. I have a pretty special naming convention for everything i create so i know what is what within my 1000 plus texture folder...
One special request from me. right now you cant have more then 15 letters for your textures but sometimes i need way more. I have a pretty special naming convention for everything i create so i know what is what within my 1000 plus texture folder...
So please...raise it up to at least 25!
@NWN_Töml Sorry to disappoint, but that's not at all easy. NWN expects 16.3 names everywhere, and changing that is a lot of work. Changing that in a way that keeps backwards compatibility is even more so.
One special request from me. right now you cant have more then 15 letters for your textures but sometimes i need way more. I have a pretty special naming convention for everything i create so i know what is what within my 1000 plus texture folder...
So please...raise it up to at least 25!
@NWN_Töml Sorry to disappoint, but that's not at all easy. NWN expects 16.3 names everywhere, and changing that is a lot of work. Changing that in a way that keeps backwards compatibility is even more so.
Comments
A namespace in NWNscript would be something like this:
namespace myNamespace1 { const int SOMETHING = 34; int myFunction (string x) { ... } } namespace myNamespace2 { const int SOMETHING = 22; void myFunction (int z) { ... } } void main () { int x = myNamespace1.SOMETHING; int y = myNamespace2.SOMETHING; int z = myNamespace1.myFunction("xxx"); myNamespace2.myFunction(x); }As for 2DA merging:
The game engine relies on having identifier lists for each type of game object. E.g. one big list of all body part models. You can only override this list in a hak / mdl, but not extend it.
This simplifies the definition of all other game objects that depend on such lists. E.g. a PLC only stores the int reference into the one master list, but not the e.g. mdl file name itself.
Since the one big list contains not only the model itself, but most likely additional information about that object, which is nowhere else to be stored and which should not be stored in the target file itself for reasons of reusability, you will always have to deal with such a list.
In my opinion the solution requires two things to be done:
- Allow for multiple 2DAs of the same domain (body parts, armor, ...) to coexist. The "one big list" is formed of all such 2DAs
- Move from the int "pointer" into that list (the row number) to a universally unique identifier (https://en.wikipedia.org/wiki/Universally_unique_identifier)
Rem: A namespace in the reference alone would not totally solve the issue, because two HAKs produced by two different people may use the same namespace and then the problem starts all over again.NWN doesn't really need namespacing for scripting because it's so easy to make your own pseudo-namespace via prefixing function names. You can't go "using foo.bar as bar" and have to explicitly call out your namespace on every use, but it works. That's exactly what I'm implying, although now I read back I didn't explicitly say as such. Where I was saying "append to 2das" I was basically saying "the ability to have seperate copies of 2da files and have NWN auto-merge them". I'm glad you made this point. I considered bringing it up but rejected doing so for brevity's sake.
You're absolutely correct that it's just moving the potential for a conflict up a level, but most other suggestions will have the same drawback. My point with namespacing is that it's a heck of a lot easier to find and replace on a string than on a bunch of numbers. In practice, namespace conflicts would be very rare because it would imply you're using 2 haks that do the exact same thing.
The solution that doesn't have this problem, as you pointed out, is UUIDs (technically you can still get conflicts but there's very, very long odds). I considered them but decided against them.
Full disclaimer; I really, really don't like UUIDs. They're slow, large, cumbersome and cache/prediction unfriendly. The only time I ever use them is either when they're forced on me or if I have some situation where there's multiple parralel writes happening with no atomics/locks (e.g. database clusters with more than 1 master).
I think they're entirely inappropriate for NWN's use case. They are just overkill. Here's a personal anecdote on UUIDs that will explain why I think this better than any technical assertion:
When I'm messing around with Civ 6 modding, do you know what I do when I need to fill in a UUID? I copy and paste one from another mod and change a digit. This completely removes any of the randomness guarantees of UUIDs and makes conflicts actually reasonably likely (it won't just be me doing this). Even knowing this I still do it because it's a pain to do it properly.
Sure, you could type UUID generator into google and either use a online generator or download a program, but even that involves a bunch alt-tab + copy and paste. Also to actually use these UUIDS you've already generated you need to be constantly searching for them to copy and paste across. I can keep "24012" in my head while I'm working with it. I can't do that for "5d23901-7e8d-4614-8014-f6a902e8a253".
I do the above - knowing full well it's a terrible thing to do - for one UUID. How many people are going use them properly for the potentially hundreds you'd need in a hak file? Absolutely no-one. Not if they don't have to. Which they won't have to because of backwards compatibility.
TLDR; UUID's are a pain. You can't memorise them, you need external programs to generate them and they are really complicated. I think most people wouldn't use them if they were an option.
https://trello.com/c/lMiLEGsr/69-expose-combat-events-for-scripting-custom-item-properties
Any server or community mod that is asking you to put files in the override didn't do their homework very well.
-JFK
Even with subfolders in override, if you want to disable a certain group, you need to remove it from that folder. This way, you just comment out a single line.
This project includes a how-to use these patch-haks to preload haks that apply to all modules: https://neverwintervault.org/project/nwn1/hakpak/neverwinter-nights-facelift-haks
EDIT: And like I said, I agree the request is valid. It'd very useful to be able to organize all the folders.
Ability To Add New Working Range Weapons
The relationship between rangeweapons and ammotypes.2da is broken or hard coded in some way. It is currently impossible to add new range weapons (New Rows, Overriding Works) into the game because they will not be able to utilize either existing ammo (bolts, bullets, arrows) or any new ammo you might add to the ammotypes 2da. (You can get range weapons into the game but they constantly say "No Ammo" even if you have the correct ammo required)
Do two things: Allow us to add new range weapons AND allow us to add new ammo types and make sure those things both function. (Strip out any hardcoding)
But yea I can think of a lot of Ability Score weirdness that belongs here..
But TBH, I'm not sure it fits in the Trello board - unless it becomes part of the "preload other areas" card...
So please...raise it up to at least 25!
https://forums.beamdog.com/discussion/comment/960748#Comment_960748
Request to have the ability to manipulate water flow via Toolset and scripting. Some discussion also in the above thread.
Thanks!
-JFK