1.1.0

1.1.0: March 30, 2024

Skip compilation of broken files #118

Added the new directive skipCompile to [package.sources] and [target.sources] sections. This directive can be specified multiple times like filter. The value should be a glob pattern matching script(s) that should not be compiled by nasher. Like filter, the pattern should match the script name only (i.e., no path information should be included). If a target does not have its own skipCompile values, they will be inherited from the parent or package.

The --skipCompile option has also been added to allow skipping a broken file from the command-line rather than editing the nasher.cfg. This option takes a semicolon-delimited list of globs matching the scripts to skip. This option can be specified multiple times and can be set with nasher config.

This feature is useful for skipping compilation of broken scripts while still keeping them in the sources.

Fixes

• nasher now gives a helpful error message when an incorrect flag is passed to nwn_script_comp through --nssFlags. Previously, compilation would fail silently.

---

Details: 1.0.0...1.1.0

1.0.0

1.0.0: March 15, 2024

BREAKING CHANGE: use nwn_script_comp as the default script compiler

neverwinter.nim's nwn_script_comp is now the default script compiler. Users who want to continue using nwnsc must set the nssCompiler and nssFlags configuration values as noted in the readme.

Thanks so much to @tinygiant98, who did all the work on this feature.

---

Details: 0.22.0...1.0.0

0.22.0

0.22.0: March 3, 2024

Allow automatically overwriting files

Added two new flags, --overwritePackedFile and --overwriteInstalledFile,
which can be used to automatically answer the "Are you sure you wish to
overwrite?" prompt when an existing packed or installed file of the same name is
found. Valid values include "ask", "default", "always", and "never". Like other
nasher flags, these can be set with nasher config so you don't have to pass
them every time.

Automatically handle multiple source files during unpack

The unpack operation now supports the --onMultipleSources flag just like the
pack operation. The options are:

• choose: manually choose the file to update (this is the default)
• default: automatically accept the first file found
• error: fail if multiple source files are found

Bug fixes

• --abortOnCompileError no longer answers other prompts
• --packUnchanged no longer consumes other args.
• --{yes,no,default} no longer override --onMultipleSources.

---

Details: 0.21.0...0.22.0

0.21.0

Release

0.20.1

Release

0.20.0

Release

0.19.0

Release

0.18.2

Release

0.18.1

Release

0.18.0

Added subsections to nasher.cfg

nasher.cfg now supports subsections to allow better organization. The current subsections allowed are [*.sources], [*.rules], and [*.variables]. These can either be context-aware or explicitly set:

# Context aware subsections
[package]
  [sources]
[target]
  [sources]

# Explicit (preferred)
[package]
  [package.sources]
[target]
  [target.sources]

Indentation is optional, but encouraged.

The parser should be backwards compatible with existing nasher.cfg files, and there are tests to check some known packages.

Added support for user-defined variables

You can now define variables that can be referenced in any target field except for name. You can set variables in the [package.variables] section (to apply to all targets) or the [target.variables] section (to apply to a single target). The key is the variable name, while the value is what it should resolve to. The target variables table is merged with the package variables table to allow missing keys to be inherited.

If a variable referenced is not found, nasher will also check the environment variables. If a variable is not found in the table or the environment, an error is thrown.

Variables can be referenced using the syntax $variable or ${variable}. The latter syntax allows variables to include non-alphanumeric characters or to be adjacent to alphanumeric characters that are not part of the variable name (e.g., ${foo}bar).

One variable is available by default: $target resolves to the name of the current target. This allows some neat things:

# This package has two targets, "foo" and "bar", that yield a file
# named "foo.hak" and "bar.hak", respectively using the source files
# in "src/foo" and "src/bar" respectively.
[package]
file = "$target.hak"

  [package.sources]
  include = "src/$target/*"

[target]
name = "foo"

[target]
name = "bar"

This feature can also be used to easily reference out-of-tree projects:

[package]

  [package.variables]
  sm-utils = "../sm-utils/src" # Can be used by any target or rule

  [package.sources]
  include = "${sm-utils}/*.{nss,json}" # include files in sm-utils
  include = "src/**/*.{nss,json}"

  [package.rules]
  "util_*" = "${sm-utils}" # Unpack util files to sm-utils
  "*" = "src/$target" # Unpack unknown file to target's source dir

[target]
name = "demo"
file = "core_framework.mod"

[target]
name = "utils"
file = "sm_utils.erf"

  [target.sources]
  include = "${sm-utils}/*.{nss,json}" # include only files in sm-utils

Since nasher checks environment variables, you can place user-specific information in an environment variable. For example, if you want to include a file in a target using an absolute path, you could place it directly in the nasher.cfg, but this would not be useful for other users of your project:

[target]
name = "mymodule"
file = "my_module.mod"

  [target.sources]
  include = "src/*.{nss,json}"
  include = "/home/squattingmonk/.local/src/nwscript/utils/util_i_color.nss"

This makes collaboration difficult, since other users of this project would have to edit the nasher.cfg to change the location of the file to where it is on their system. Instead, you can use an environment variable:

[target]
name = "mymodule"
file = "my_module.mod"

  [target.sources]
  include = "src/*.{nss,json}"
  include = "${SM_UTILS}/util_i_color.nss"

export SM_UTILS=/home/squattingmonk/.local/src/nwscript/utils

Other users can then set the environment variable to the location of their choice without changing the nasher.cfg.

Added user-defined target groups

You can now group targets into aliases that are expanded when a command is run. Groups are defined with the repeatable group directive
in nasher.cfg. This makes it easy to, say, pack all haks in a project:

# To pack all targets: nasher pack all
# To pack only haks: nasher pack haks
[target]
name = "demo"
file = "demo.mod"

[target]
name = "hak1"
group = "haks"
file = "hak1.hak"

[target]
name = "hak2"
group = "haks"
file = "hak2.hak"

nasher list can now list specific targets

nasher list can now limit its output to the named targets (e.g., nasher list demo). The default behavior is to list all targets for backwards compatibility. To list only the first target, use nasher list "". Also supports target groups.

Other

• Fixed relative paths not working in exclude directories (#90)
• Updated help text for all commands to show all available options
• nasher commands now support the -- operator, which causes all arguments that come after it to be treated as positional arguments even if they look like options. For example: nasher config -- nssFlags "-n /opt/nwn" prevents the -n from being treated as an option with the value /opt/nwn.
• --noInstall is now correctly treated as a flag that does not require a value

---

Details: 0.17.4...0.18.0