squattingmonk / nasher Goto Github PK

C:\Users\pstem\Documents\Custom_Content\Dark_Ages_Haks>nasher install all --nocompile --yes
Installing target da_2da
Updating cache for target da_2da
Packing files for target da_2da into da_2da.hak
Prompt: da_2da.hak already exists. Overwrite? -> [forced yes]
Error: An unknown error occurred. Please file a bug report at
... https://github.com/squattingmonk/nasher.nim/issues using the stack trace info below:
nasher.nim(96) nasher
pack.nim(109) pack
nwn.nim(196) createErf
osproc.nim(1585) execCmdEx
osproc.nim(739) startProcess
oserr.nim(94) raiseOSError
Error: unhandled exception: %1 is not a valid Win32 application.
Additional info: "C:\Users\pstem\Documents\Neverwinter Nights\utils\NIM_Nasher\nwn_erf.exe -c -f "da_2da.hak" .nasher\pack" [OSError]

C:\Users\pstem\Documents\Custom_Content\Dark_Ages_Haks>PAUSE
Press any key to continue . . .

After the changes to caching in 5a522d5, executable scripts are now always recompiled, regardless of whether the source file was changed or not. This is because the compile step does not cache the checksums of the compiled scripts, so the convert step always deletes them.

Hola there,

I'm attempting to update to 0.11.1 without much luck. Using nimble install nasher@#head resulting in an failure at Hint: wordwrap [Processing] with the following error:

Error: undeclared field: 'isEmptyOrWhitespace' for type system.string [declared in ... system.nim(49, 3)]

I updated nim to 1.2.0 and that problem was resolved. There was no dependency requirement for 1.2.0 in the install messages. Went back to update nasher and got much further, this time failing at Hint: pack [Processing] with this error following:

Error: undeclared field: 'filters' for type options.Target [declared in ... options.nim(19, 3)]

I don't know nim (at least not much of it), but could (?) be due to missing the filters* options in this section (honestly, this is a WAG):

  Target = object
    name*, file*, description*: string
    includes*, excludes*, flags*: seq[string]

Modules with DotNET often have no scripts at all--would be neat to not have to worry about having nwnsc, which isn't useful for these modules in the slightest.

nasher should run correctly out-of-the-box provided:

• nwnsc is installed and in your PATH
• NWN is installed with Steam in the default location for your OS
• Your NWN user directory is in the default location for your OS

However, new users apparently get tripped up by this a lot and it's difficult for them to figure out how to configure nasher appropriately. Documentation improvements (#53) can help with this, and nasher can do better with finding NWN in other installation paths (#40). However, a dialog that helps the user set the appropriate configuration options (similar to the one used for nasher init) would be helpful for new users.

When trying to unpack my module with my current user id + gid:

$ docker run --user "$(id -u):$(id -g)" --rm -it -v "$(pwd)":/nasher nwntools/nasher unpack --file=RoUM.mod
WARNING: IPv4 forwarding is disabled. Networking will not work.
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"nasher\": executable file not found in $PATH": unknown.

If I change to --user "0:$(id -g)" it works.

This is probably because the nasher binaries are installed only for root user (in /root/...)

The end-result problem is that without --user the files on my filesystem become all owned by root

This was requested by a user. When given a directory rather than a file as an argument, nasher should unpack from the directory. This should work for relative or absolute directories:

# Unpack the default target from a relative directory
$ nasher unpack --file:../demo

# Unpack the demo target from an absolute directory
$ nasher unpack demo ~/.local/share/Neverwinter\ Nights/modules/temp.0

Related to #23.

The user should be able to include path information in the file section of a target to allow the target to be packed to a different location. For example:

[Target]
name = "demo"
file = "modules/demo.mod"

Expected behavior for files that include path information:

1. When packing: if the file is a path, it will be relative to the project root.
2. When installing: any path portion of the file will be discarded and the file will be installed into $installDir/{erf,hak,modules,tlk}/ as appropriate.
3. When unpacking using a target: any path portion will be discarded and the file will be unpacked from $installDir/{erf,hak,modules,tlk}/ as appropriate.
4. When unpacking by explicitly passing a file: the path will be relative current working directory. Absolute paths are allowed here. This is the current behavior for the unpack command.

Using the example above, we would get the following:

# Packs to ./modules/demo.mod
$ nasher pack demo

# Installs to $installDir/modules/demo.mod
$ nasher install demo

# Unpacks from $installDir/modules/demo.mod
$ nasher unpack demo

# Unpacks from ./modules/demo.mod
$ nasher unpack demo modules/demo.mod

When updating to nitely/regex 0.14.0, nasher compile yields the following error:

nasher compile --clean
   Compiling target default
    Updating cache for target default
nasher.nim(90)           nasher
compile.nim(94)          compile
compile.nim(63)          getUpdated
regex.nim(439)           getIncludes
regex.nim(406)           find
nfamatch.nim(123)        matchImpl
nfamatch.nim(27)         submatch
nodematch.nim(134)       match
nodematch.nim(83)        isWhiteSpace
types.nim(23)            unicodeTypes
assertions.nim(29)       failedAssertImpl
assertions.nim(22)       raiseAssert
fatal.nim(49)            sysFatal
Error: unhandled exception: types.nim(23, 10) `cp.int <= 0x0010FFFF`  [AssertionError]

Current fix is to downgrade to regex 0.13.1.

Nasher is currently single-threaded. While it is still fast because of the underlying tools, multithreading would increase the speed at which large modules could be processed.

The pack command currently packs a target file and places it into the project root (unless path info is present in the target's file attribute). The install command simply copies the packed file into the NWN user directory. This is a result of the install command being added later on.

My proposal is to merge the install command into pack. This would make pack the mirror of unpack, placing the file directly into the NWN user directory.

Path handling would depend on the target's file attribute, similar to the unpack command:

1. Files with no explicit path information will be placed into $installDir/{erf,hak,tlk,modules}/
2. Files with either relative or absolute path information would be placed into that directory
3. The user can override this destination using the --file flag.

For example, given the following targets:

[Target]
name = "module"
file = "demo.mod"

[Target]
name = "erf"
file = "demo.erf"

[Target]
name = "local"
file = "local/demo.mod"

• module would be installed to $installDir/modules/demo.mod
• erf would be installed to $installDir/erf/demo.mod
• local would be installed to ./local/demo.mod
• The module target could be installed to an alternate directory using nasher pack module --file:"local/demo.mod"

Filtering .nss files is a common method for reducing file size and protecting intellectual property. The filter method deletes files from the cache before packing. However, the next time the module is packed, the .nss files are re-added to the cache and considered "new" files, therefore triggering recompiles of all scripts.

Tried to install via nim but got this

   Tip: 348 messages have been suppressed, use --verbose to show them.
 Error: Could not read package info file in /tmp/nimble_28361/githubcom_WilliamDracoNWNT_1.3.0/nwnt.nimble;
    ...   Reading as ini file failed with: 
    ...     Invalid section: .
    ...   Evaluating as NimScript file failed with: 
    ...     /tmp/nimble_28361/githubcom_WilliamDracoNWNT_1.3.0/nwnt_28361.nims(14, 1) Error: undeclared identifier: 'namedBin'
    ... printPkgInfo() failed.

This is likely an edge case, but wanted to document it. The use of relative paths in nasher is great and makes setting up nasher projects very easy. Unfortunately, nwnsc isn't as accepting of relative paths, or, if it is, it's not accepting of paths relative to the nasher project root. When compiling, is it possible to expand the paths for all binaries that are sent as part of an argument to the nwnsc process (eg nwnsc, nwn_gff, nwn_erf, nwn_tlk)?

On a side node, nasher accepts an argument like this: -gffUtil:"./bin/nwn_gff.exe" and this will pass nasher's binary location test and return a message to the user stating that nwn_gff.exe was found. However, when nwnsc is called, an error will be thrown because nwnsc can't find it ... I'm not sure if this is because nwnsc doesn't understand relative pathing at all or because the relative pathing provided was relative to the project root and not to where nwnsc was called from. This may take a little experimentation.

Edge case example: One user is setting up scripts to be able to run the various commands without having to set up PATHs. Here's his windows command:

%CD%/tools/win/nasher/nasher.exe install  --verbose --erfUtil:"./tools/win/neverwinter64/nwn_erf.exe" --gffUtil:"./tools/win/neverwinter64/nwn_gff.exe" --tlkUtil:"./tools/win/neverwinter64/nwn_tlk.exe" --nssCompiler:"%CD%/tools/win/nwnsc/nwnsc.exe"

This successfully runs nasher on the root folder and returns a message stating all binaries were found. When it's time for compilation, this error is thrown:

     Located erf utility at ./tools/win/neverwinter64/nwn_erf.exe
     Located gff utility at ./tools/win/neverwinter64/nwn_gff.exe
     Located tlk utility at ./tools/win/neverwinter64/nwn_tlk.exe
  Installing target mod
    Updating cache for target mod
  Converting module.ifo.json -> module.ifo
    Updating area list
    Success: area list updated --> 76 areas listed
   Compiling 291 scripts
      Error: An unknown error occurred. Please file a bug report at
         ... https://github.com/squattingmonk/nasher.nim/issues using the stack trace info below:
nasher.nim(96)           nasher
install.nim(97)          install
nwn.nim(186)             extractErf
osproc.nim(1392)         execCmdEx
osproc.nim(645)          startProcess
oserr.nim(94)            raiseOSError
Error: unhandled exception: The system cannot find the file specified.
Additional info: "Requested command not found: \'./tools/win/neverwinter64/nwn_erf.exe  -x -f \"C:\\\\Users\\\\<user>\\\\Documents\\\\Neverwinter Nights\\\\modules\\\\<modulename>.mod\"\'. OS error:" [OSError]

When all paths are changed to absolute, no errors are posted and the module compiles successfully.

In a project with a large number of scripts (over 1500), compilation can fail on Windows with the error The filename or extension is too long. This is likely because nasher executes nwnsc as a process and sends the files as arguments, hitting the 32,767 character limit.

One of my long-term goals for nasher is for authors to be able to publish nasher packages for easy discovery and inclusion in other projects. This would be especially useful for scripts. If you wanted to publish several packages that depend on a script library, you could just publish the library separately and add it as a dependency to the other projects rather than including that library in each separate package and updating all of them when the dependency changes.

The current workaround is to use a monolithic repository: nasher can allow multiple build targets, so each system could be a separate target but they could all reference the same source file. However, you might want to include someone else's code and receive updates or bugfixes they publish; this could be especially useful for module authors.

This is most likely user error, but I'm not able to set the installDir config option when using dockerimage.

It's using the default installDir of : /root/.local/share/NeverwinterNights/modules/

I tried to set with config, config --global and config --local but isn't taking. See below:

[user@ice3:~/nwn/darksun/darksun]$ docker run --rm -it -v $(pwd):/nasher squattingmonk/nasher:latest unpack
      Error: Cannot unpack /root/.local/share/Neverwinter
         ... Nights/modules/darksun_dev.mod: file does not exist
[user@ice3:~/nwn/darksun/darksun]$ docker run --rm -it -v $(pwd):/nasher squattingmonk/nasher:latest config installDir "~/nwn/darksun/"
[user@ice3:~/nwn/darksun/darksun]$ docker run --rm -it -v $(pwd):/nasher squattingmonk/nasher:latest unpack
      Error: Cannot unpack /root/.local/share/Neverwinter
         ... Nights/modules/darksun_dev.mod: file does not exist
[user@ice3:~/nwn/darksun/darksun]$ docker run --rm -it -v $(pwd):/nasher squattingmonk/nasher:latest config --global installDir "~/nwn/darksun/"
[user@ice3:~/nwn/darksun/darksun]$ docker run --rm -it -v $(pwd):/nasher squattingmonk/nasher:latest unpack
      Error: Cannot unpack /root/.local/share/Neverwinter
         ... Nights/modules/darksun_dev.mod: file does not exist
[user@ice3:~/nwn/darksun/darksun]$ docker run --rm -it -v $(pwd):/nasher squattingmonk/nasher:latest config --local installDir "~/nwn/darksun/"
[user@ice3:~/nwn/darksun/darksun]$ docker run --rm -it -v $(pwd):/nasher squattingmonk/nasher:latest unpack
      Error: Cannot unpack ~/nwn/darksun/modules/darksun_dev.mod: file
         ... does not exist

Please add function truncating of float values, like nwn-devbase does.

Hello!
Reported this over NWNX Discord last night, but I thought it'd be worthwhile to also leave an issue here just in case.

TL;DR

Current Nasher image in Dockerhub version is 0.11.0 instead of 0.11.2, I think this should need to be corrected.

Scenario

• Docker pulled latest image 0.11.2 and tried to work as usual. My previous version was 0.9.X.
• Had some issues (See figure 1 & 2 below) when doing compile, convert and any other action.

Solution Attempts

• I thought something on my local Docker was breaking up. So I deleted all the images I had and pulled again: No success
• Tried setting up a different Nasher environment (i.e: New folder, and then nasher init + nasher unpack): No success. Unpack worked normally, Convert and other operations showed error

Troubleshooting

• Attempted to run nasher --version from the Docker image, which showed 0.11.0 instead of 0.11.2 (See figure 3 below)

Solution

• In order to solve my issue, I downloaded Nasher source code to my PC and built the Docker image locally. Once I did this, when I did nasher --version I got the correct latest version 0.11.2 (See Figure 4 below)

Screenshots

Figure 1: Error when attempting using the latest Nasher image from DockerHub

_Figure 2: Docker image from DockerHub failing on Linux environment

Figure 3: Nasher version from latest Docker Image

Figure 4: Nasher running on the local Docker image with correct version. Succeeded with all operations (unpack, pack, convert, compile, etc.)

Hope this helps addressing any issue that might be happening to others as well!

Looking at the generated JSON, if it was packed by line it would be easier to grep and sed.

ie: instead of

  "IsNight": {
    "type": "byte",
    "value": 0
  },
  "LightingScheme": {
    "type": "byte",
    "value": 7
  },

having:

  "IsNight": { "type": "byte", "value": 0 },
  "LightingScheme": { "type": "byte", "value": 7 },

Can a nasher option be added to specify the Mod_MinGameVer to be put into the ifo file when it's converted (such as when the area list is updated)? minGameVersion = 1.74 or something like that in the local configuration file (no entry = whatever's already there). Possibly a prompt if the minGameVersion is lower than the minGamerVersion already in the ifo? While we're at it, can a local-only option be added to specify modName? I don't think you can set that in the toolset, but it's used by the core framework when events are run on the module object, so would be nice to set it by local option.

Most commands run solely within the nasher project folder making the standard mounted volume (-v $(pwd):/nasher) adequate for most operations. However, some commands (specifically install, play, test and any other command that installs the module into the modules folder) require access to remote folders that aren't mounted as volumes to the image. In order to access them, they need to be associated with an existing directory within the image because using flags (installDir:<path>) will not allow the creation of a directory/folder within the image. In order to allow install to work correctly, the image requires a dummy directory to use as the installDir (or the removal of the requirement to use the modules folder). Although the pack command doesn't seem to have this issue when used with pathing in the file specification -- file = "<folder>/<filename.ext>" creates the appropriate folder within the image.

Example, the following Docker command would normally work, but it throws an error because the folder cannot be created within the image (probably a permissions issues) to house the created files:
docker run --rm -it -v $(pwd):/nasher -v //c/Users/<username>/Documents/Neverwinter Nights:/nasher/install squattingmonk/nasher:latest install <target> --yes --installDir:/nasher/install. Additionally, because install specifies the use of the "modules" folder for the installDir variable (install.nim/line 61), an existing empty directory within the image does not suffice because modules still needs to be created.

The solution seems to be either to not require the modules folder when an installDir is specified or to create a empty folder within the image to handle remote folder requests. The empty folder is probably the easy solution and can be used for other cases.

If an empty folder resolves this issue, consideration should be given to creating empty folders for other required destinations such as erf, hak and tlk.

For the dummy folder, the following should suffice:
RUN mkdir -p /nasher/install/modules or the like

The compile command compiles all files that need recompilation in preparation for a pack. Although most IDEs offer way to run a task to compile a single script, this can be considered advanced usage for the general builder community and correctly setting up these tasks for an external compiler (nwnsc) may be beyond their capability or desire. Also, when compiling an entire module that may result in large numbers of errors, it would be desirable to work one file/script at a time to limit nwnsc output. Although not primarily a debugging tool, nasher supports the capability. Consider supporting single script compilation for debugging purposes that works as follows:

nasher compile ds --file:<filename> would force compile <filename> regardless of cache state, recursing through the included sources in the ds target. Without a target, it could recurse the default target or current directory. This would prevent some of the more detailed task setups in IDEs, especially with the somewhat deep directories structures that are allowed by nasher; it also allows builders that don't use an IDE (notepad++, etc.) to debug scripts outside the toolset.

Some people are trying to keep their nasher repo inside of the folder for their module:

$ tree ~/.local/share/Neverwinter\ Nights/modules/demo
/home/squattingmonk/.local/share/Neverwinter Nights/modules/demo
├── area001.are
├── area001.gic
├── area001.git
├── creaturepalcus.itp
├── doorpalcus.itp
├── encounterpalcus.itp
├── itempalcus.itp
├── module.ifo
├── nasher
│   ├── nasher.cfg
│   └── src
│       ├── area001.are.json
│       ├── area001.gic.json
│       ├── area001.git.json
│       ├── creaturepalcus.itp.json
│       ├── doorpalcus.itp.json
│       ├── encounterpalcus.itp.json
│       ├── itempalcus.itp.json
│       ├── module.ifo.json
│       ├── placeablepalcus.itp.json
│       ├── repute.fac.json
│       ├── soundpalcus.itp.json
│       ├── storepalcus.itp.json
│       ├── triggerpalcus.itp.json
│       └── waypointpalcus.itp.json
├── placeablepalcus.itp
├── repute.fac
├── soundpalcus.itp
├── storepalcus.itp
├── triggerpalcus.itp
└── waypointpalcus.itp

But module directories are deleted and recreated when installing the demo module. This destroys the nasher repo:

$ nasher install
  Installing target default
    Updating cache for target default
   Compiling 2 scripts
     Packing files for target default into demo.mod
    Success: packed demo.mod
  Installing demo.mod into /home/squattingmonk/.local/share/Neverwinter Nights
     Prompt: /home/squattingmonk/.local/share/Neverwinter Nights/modules/demo.mod already exists. Overwrite? (Y/n)
       Hint: The file to be installed is newer than the existing file
     Answer: y
oserr.nim(94)            raiseOSError
Error: unhandled exception: No such file or directory [OSError]

$ tree ~/.local/share/Neverwinter\ Nights/modules/demo
/home/squattingmonk/.local/share/Neverwinter Nights/modules/demo

0 directories, 0 files

nasher should support this use case.

The cache used to avoid re-converting and re-compiling files that have not changed will sometimes not update files that have changed.

The comparison between files during unpack is based on binary contents, but the comparison during convert (which is what caches the files), is based on last modification time of the file. So if a file was changed by unpack but is the same age or older than the cached copy, convert won't recache it. This leads to an out-of-date version being in the cache. pack then packs the out-of-date file, leading to a packed module which does not reflect the source files in the repo.

If a script includes a stock game script such as x3_inc_string that is not present in the nasher repo, the script will always be recompiled. This is because nasher does not see a .ncs file generated for the script after compilation and cannot open the script to verify it is an include script.

See Discord thread for details.

If nwnsc or any of the nwn_* binaries are not on $PATH or have been set to an incorrect location, nasher commands will fail. This includes the config command, preventing you from setting the proper binary location.

For example:

# Set nssCompiler to an incorrect location
nasher config --local nssCompiler /home/squattingmonk/foo

# Now try to set the correct location
nasher config --local nssCompiler /usr/bin/nwnsc
      Error: Could not locate script compiler: /home/squattingmonk/foo does not exist.
      Error: Could not locate required binaries. Aborting...

I have set up a GitHub action for creating binaries when a new tag is pushed, but we can do more with automation. I would like to create a test suite for nasher and have tests automatically run on PRs and commits. This will help ensure no breaking changes are introduced and help to catch bugs and blind spots.

.nss files that have a commented-out main() or StartingConditional() function are picked up as executable scripts. Since these files do not generate .ncs files on compilation, nasher believes they need to be recompiled again. In addition, scripts that include those files are also recompiled, even when no changes have been made.

Thanks to @tinygiant98 who reported on Discord.

If a script that includes an executable script (one with a main() or StartingConditional() function) does not have a matching .ncs file, it will not be recompiled unless either it or the executable script is updated.

nim version is 1.2.0

± |master ✓| → nimble install
Error: Could not read package info file in /home/darren/NWN/nim/nasher/nasher.nimble;
... Reading as ini file failed with:
... Invalid section: .
... Evaluating as NimScript file failed with:
... [Package]
... version: """0.11.0"""
... author: """Michael A. Sinclair"""
... description: """A build tool for Neverwinter Nights projects"""
... license: """MIT"""
... srcdir: """src"""
... backend: """c"""
... bin: "nasher"
... [Deps]
... requires: "nim >= 1.0.2, neverwinter >= 1.2.8, glob >= 0.9.0"
... /home/darren/NWN/nim/nasher/nasher_11612.nims(5, 22) Warning: imported and not used: 'strutils' [UnusedImport]
... printPkgInfo() failed.

When unpack finds multiple copies of a source file, it asks the user which one to replace. However, the pack loop does not, which can result in the user scratching their head trying to find out why the packed version of a module doesn't match their source tree. nasher should warn the user when duplicate files are found or (ideally) ask which one to use.

Source: Discord thread

NWN:EE now allows modules to be contained in subfolders of the modules directory. Nasher should support this feature.

How to reproduce

1. Get a demo.zip
2. Run nasher unpack --file:demo.mod
3. Run nasher compile
4. Go to .nasher/cache/default and you will see .ncs files only for _valid.nss, but there is no compiled files for valid1.nss and valid2.nss. Compilation stops after trying to compile notvalid.nss script.

I'm tried to compile not valid script inside nasher docker container and getting error as expected.

/usr/local/bin/nwnsc -n /nwn/data -o -i /nasher/.nasher/cache/default /nasher/.nasher/cache/default/notvalid.nss
Loading base game resources...

Home Path - ~/Documents/Neverwinter Nights/

Compiling: notvalid.nss
Illegal instruction

content of notvalid.nss

void main()
{
	AssignCommand(OBJECT_SELF, TRUE);
}

System: nwntools/nasher:latest under Windows 10.

I created a mod, added a custom hak then unpacked the mod with nasher. I don't see any reference to the hak in the src folder.

Additional variables for unpack rules would be useful for sorting new files in projects with more complex directory structures. Currently, the only variable used is $ext, which matches a file's extension (before it is converted to json).

For example, a variable could be used to reference the target being unpacked to:

[Rules]
"*" = "src/$target/$ext"

This rule would unpack any file into a subdirectory of src matching the name of the target, with files then being further divided into subdirectories based on extension:

# Unpacks to src/demo
$ nasher unpack demo

# Unpacks to src/hak
$ nasher unpack hak

  Error: An unknown error occurred. Please file a bug report at https://github.com/squattingmonk/nasher.nim/issues using the stack trace info below:

nasher.nim(90) nasher
json.nim(792) unpack
assertions.nim(30) failedAssertImpl
assertions.nim(23) raiseAssert
fatal.nim(49) sysFatal
Error: unhandled exception: json.nim(792, 10) node.kind == JObject : keys() can not iterate a JsonNode of kind JArray [AssertionDefect]

In some cases, builders need some source files during the conversion and compilation steps that they don't want to end up in the final packed file. For example, if you are compiling scripts and adding them to a hak file, you may want to include the compiled .ncs scripts but not the source .nss scripts.

This can currently be done with a shell script that converts and compiles the target, removes the unwanted files from the cache, and then packs with --noConvert --noCompile. However, this method may not work depending on whether the user's OS supports the script, which breaks cross-compatibility for teams.

A better way would be to add a per-target setting that allows the nasher.cfg to define files they don't want packed into the final target.

Here's the output, let me know if I can provide more info, cheers!

     Packing target default
    Updating cache for target default
    Skipping compilation: nothing to compile
     Packing files for target default into demo.mod
oserr.nim(94)            raiseOSError
Error: unhandled exception: No such file or directory
Additional info: "Could not find command: \'/bin/sh\'. OS error: Argument list too long" [OSError]

ulimit -n is 32000
getconf ARG_MAX is 2097152

$ tree -f .nasher/default/ | wc -l
$ 15562

Hi,
First off, this build tool is amazing. Well done!

I'm trying to build a small target with just two areas from my main module. And the scripts needed for them. It packs fine, but I cannot load it. The client says it can't load the module and "it must have been made with newer version of toolset". Or something like that.

Only odd thing I noticed was during pack, got some errors about missing "nwscript.nss"

Thanks for any help.

The source of this slowdown is the algorithm to detect which files needs to be recompiled; it resolves chained includes. For example:

• A includes B which includes C
• D includes C
• If B changes, A and B needs to be recompiled, but C and D do not
• If C changes, then A, B, C, and D all need to be recompiled

The current algorithm is terribly slow for large numbers of scripts. It's actually faster to just compile everything than to figure out which ones need to be recompiled.

Currently, nasher's default locations for the game and server binaries assume a Steam installation. It would be nice to support Beamdog and GOG locations out of the box.

No matter what I try, I always end up with:

  Converting impledcrpse002.utp -> impledcrpse002.utp.json
  Converting impledhead002.utp -> impledhead002.utp.json
  Converting invalid.are -> invalid.are.json
  Converting invalid.gic -> invalid.gic.json
  Converting invalid.git -> invalid.git.json
  Converting invalid_0.git -> invalid_0.git.json
      Error: Could not create src/git/invalid_0.git.json. Is the destination writeable?

My nasher.cfg :

[Package]          
name = "Ruins of Undermountain"
description = "Ruins of Undermountain"                                                   
version = "alpha1"                                                                                                    
url = "https://gitlab.com/roum/roum"                                                                                  
author = "nasher"                                                                                                     
                                                                                                                      
[Sources]                                                                                                             
include = "src/**/*.{nss,json}"                                                                                       
                                                                                                                      
[Rules]                                                                                                               
"*" = "src/$ext"
                                                                                                                      
[Target]                                                                                                              
name = "RoUM"                                                                                                         
file = "RoUM.mod"                                                                                                     
description = ""                                                                                                      

I don't have any area, nor item with blueprint 'invalid' or 'invalid_0'

Afew of us in c# land have no nss in our modules.
We can unpack without nwnsc installed, but we cannot pack without it.

Not sure if this is currently possible. We're using nasher to build up our module, but also to build haks. There are several haks and we have a target specified for each of them. Is it possible, or could it be possible to setup a target that packs/installs a list of other targets (i.e. all the .hak targets instead of building them one by one)?

Not sure if this is possible, more of a hair-brained idea and not even sure how useful it would be. Is it possible to setup a target option that would allow a specific branch to be checked out for inclusion in the build? That is, if I'm making a bunch of modifications on a branch and want to check them out, can I include a "branch" = "master" in the Target and have that branch checked out temporarily for inclusion?

If scripts have not changed since a compile was last attempted, they will not be compiled on the next compile, pack, or install. This is normally fine. However, if the last compilation was aborted, there may be missing .ncs files that will not get packed. This also happens when a script fails to compile: compilation will not be attempted again and the target will be packed and installed without warning.

The current workaround is to run with the --clean flag to force a re-compile.

The solution needs to:

• detect which files are compilable (e.g., main() or StartingConditional() functions)
• detect files that include compilable scripts (a script without a main() or StartingConditional() function can #include one that does)
• check if each of these has a compiled script in the build directory
• ensure the compiled script is the same age as the source
• recompile scripts with missing or outdated compiled scripts

When packing files with nasher, if a source file's name (not including extension) is greater than 16 characters, it is silently dropped and the module is built without the offending resource. Instead, nasher should error out or issue a warning and prompt the user to continue building without the file.