Bug Fixes

Each syntax now has an individual test designed to check that expected behaviour is met.
This should improve parse-time stability.

Full Changelog: 1.0.25...1.0.26

Fix Config Closing

This release corrects the closing order for configuration expressions when used as a section header.

Full Changelog: 1.0.23...1.0.25

Type Correction

This draft contains an adjustment to how the type expression parses. Type names will be checked more rigorously to see whether they conform to practical standards.
Although this does limit some edge cases of unusual unicode types being used, it will also cut down on the number of expressions being erroneously matched to types.

As we progress towards a stable 1.1 release, the focus will be on improving user experience, warnings and error messages for library developers and correcting bugs.

Fix Nested Sections

This version fixes an issue in nested loops that all exit at the same time:

if 1 is 1:
    if 1 is 1:
        if 1 is 2:
// ends here

This also fixes an issue for matching zero-length strings.

Full Changelog: 1.0.20...1.0.22

None

This release adds a special none type name for occasional void functions.

Specifying this explicitly is not typically necessary - the bootstrap compiler handles the return process in most cases. It is the first step in allowing for libraries that need to interact with a Java program (e.g. implementing an interface with a void return method.)

function my_func:
    return: none
    trigger:
        print "hello"

Future releases will have a new entry for specifying exact parameters to make sure the signature conforms.

Full Changelog: 1.0.19...1.0.20

Type Converters

This draft adds the potential to convert between types, using pre-registered converters (e.g. text -> number.)

The syntax is %Object% [parsed] as a[n] %Type%. Example: "10" as an integer or 10.5 as a number.
When converting, a direct match is attempted first, after which the first valid conversion will be chosen. This means that when converting a number to a string, ByteSkript will first look for a number -> string converter, after which it will fall back to any that allows the input (finding object -> string.)

Any syntax library may register converters.

Extending Types

This draft contains a small adjustment to allow types to extend other types.

This is included only for operating with Java libraries, and is not designed for regular scripts. Type constructors are not currently supported at a language level.

Full Changelog: 1.0.17...1.0.18

Skript Configuration

This draft contains a schema for Skript configuration .csk files.
In-memory readers/writers are included, as well as syntax for interacting with these from within Skript files.

The .csk file uses a raw key: value structure. Currently it supports only single-line string values, though in future more complex types (lists, sub-keys, etc.) should be supported.

key: value
my key: my value
another key: another value :)

Both line // and block /**/ comments are supported.
These are supported at a schema level and correctly attached to the following node.

// this comment belongs to 'key'
key: value

/*
this comment
belongs to 'my key'
*/
my key: my value

// this key
// has two comments attached!
another key: another value :)

Comments survive the loading/editing/saving process.

To use .csk files in Skript code, they can be referenced by literal path.

set {conf} to path/to/config.csk // this loads the data into memory
add "key: value" to {conf} // add pattern, for convenience
set "key" from {conf} to "value" // set pattern
// setting to 'null' is equivalent to deleting
save config {conf} // saves the in-memory version to its source file
delete path/to/config.csk // deletes the file

For utility, the file may also be used as a section header, which will automatically save it at the end of the section.

set {conf} to path/to/config.csk:
    add "key: value" to {conf}
    add "hello: there" to {conf}
// config is saved here

Debug and Compiler Efficiency

This release adds the bsk debug command to the CLI. Running this will generate a post-parse tree of all scripts.
The output debug.txt file is useful for bug reports (or for advanced users tracing parse errors.)

The stream-based compiler has also been made significantly more efficient: rather than reading the entire file into memory, it will be read line-by-line and each line will be discarded once it has passed through the compiler.
This will make parsing large scripts significantly more efficient.

Jupiter has been added as a new dependency, for its lazy-iterable capabilities.

Full Changelog: 1.0.15...1.0.16

Every %Duration%

This release adds the every %duration% scheduler member.

This can be used to set up repeating tasks.

every 10 seconds:
    trigger:
        print "hello"

These tasks are cancelled when their owning script is unloaded. They also contain a transitive reference to a script, so it will not be automatically unloaded while a task from it is running.