Organic scripts do not appear to be indexed

[tinygiant98]

While nwscript.nss is indexed through a lib-def build, the organic scripts (such as nw_i0_spells and such) that are available via #include "<scriptname>" are not indexed, likely because they typically only exist in the game's .bif files unless there's a custom override in the module. Is there a way to index the organic scripts if they're included? These are the same .bif files that nwnsc uses for compilation of organic scripts.

[Liareth]

+1. This would be an excellent feature. I've noticed this regularly when coding Nui.

[Liareth]

FYI, I had some success from extracing all of the scripts then adding a symlink to my workspace. Then I get syntax highlighting for most scripts - some (like nw_inc_nui) causes errors in the plugin though, see #31.

[PhilippeChab]

This would indeed be a good addition.

I think what would be best is to generate the complex tokens for those files, juste like we do for nwscript.nss. We could read the json file here - I would ouput the tokens for these files in an other single file - and then use them in the CompletionItemsProvider and in the HoverProvider.

What do you guys think?

[Liareth]

What happens if users edit the base script (thus bringing it into their module)? I think we'd need to make certain that we only use the offline generated tokens for these files if a script matching that name isn't found in the workspace. In a similar vein, the tokens from base_scripts.bif would need to be overriden by scripts in the ovr folder.

[tinygiant98]

This is going to be a complex issue. Base scripts can be overridden by scripts of the same name in a module, or a script in the development folder, or by scripts in the ovr folder, or even scripts in a hak file. We'd likely have to determine a priority for these. I don't know if selectively ignoring a previously indexed file is possible, but re-running indexing on all of the organic scripts because one file had been added is probably a huge waste of time and resources.

If it's possible, it's likely best to investigate selective ignoring first. There might be something here as I've noticed that, in some cases that I have files of the same name in different folders, the file I want to use isn't always the one that is used. This would also aid in a feature that only uses indexed files from the current project instead of every .nss file found.

I know this isn't much help. I'll see if I can dive into indexing at some point.

[PhilippeChab]

What happens if users edit the base script (thus bringing it into their module)? I think we'd need to make certain that we only use the offline generated tokens for these files if a script matching that name isn't found in the workspace.

This is not an issue as the LSP always look for tokens in the indexed files before looking at the static ones.

In a similar vein, the tokens from base_scripts.bif would need to be overriden by scripts in the ovr folder.

This is going to be a complex issue. Base scripts can be overridden by scripts of the same name in a module, or a script in the development folder, or by scripts in the ovr folder, or even scripts in a hak file. We'd likely have to determine a priority for these. I don't know if selectively ignoring a previously indexed file is possible, but re-running indexing on all of the organic scripts because one file had been added is probably a huge waste of time and resources.

I am not really sure what is the best solution for this yet, but I really think LSP files management should be kept for files inside the project. The LSP has good control over those files because of the event notifications sent by the client, it will be really hard however to handle correctly files in other locations.

I will have to think about this and you are welcome to participate to the process and even implement it ultimately if you want to.

[Liareth]

Personally, I don't think the LSP should try to resolve priorities here. I think it's enough to collapse all of the scripts offline (starting with base_scripts.bif, blitting ovr on top of it) and generate a database, nwscript.nss-style. If someone has a script in development or override or any number of places, they should add those places to their workspace IMO. The only thing we need to be careful about is when a user overrides the script with one in their workspace - for example if they have a local copy of x3_inc_string, the symbols from the offline database for that file should no longer show up in autocomplete, they should instead be sourced from the script in the workspace.

[tinygiant98]

That sounds like a great start. If local definitions from the workspace override those in the json/database for the base scripts and nwscript, the appropriate behavior should automatically resolve itself. Now, we'll just have to work out finding and indexing those files with, if course, being sure not to include any old nwscript.nss that might be hanging around.

[PhilippeChab]

Just giving a little status update on this; I am still not sure when it will be done, but it's the next thing on my list for the project.