derpy's script loader - Script Collections

A script collection (sometimes shortened to collection) is, as the name suggests, a collection of scripts. All scripts that DSL load are contained within a collection, even if they are the only script in said collection. This grouping is useful for being able to start and stop multiple related scripts at once, and for simplifying what counts as a single "mod". In general, each script collection can be considered a different mod.


Types

DSL4 Support for zip files is only supported in version 4 and beyond.

A script collection simply represents one of the things placed in DSL's scripts folder. There are 3 ways to define a script collection.
Placing other file types in the scripts folder is valid and they will be ignored, but having other folders not representing a script collection will raise errors.

Zipped Collections

If you decide to zip your collection up for release, it can be installed by simply putting the zip archive in the scripts folder. The structure of your zip archive is very important, your files (such as your config and main script unless changed in the config) must appear in the root of the zip.

For example, if you have a normal collection as a folder (say Some Mod) and want to make Some Mod.zip then it is important you do not add the folder to the zip. Instead, the contents of the folder are what should be in the root of the zip. Basically put, make sure your config file can be found in the zip at config.txt rather than Some Mod/config.txt.


Config

DSL4 This feature was introduced in version 4. Older versions used "main.lua" as the name for main scripts, and the concepts of init & pre-init scripts were not yet a thing.

Collections that are not standalone are able to have a config.txt file that determines when the collection should run, what requirements are needed (such as DSL version and the presence of other collections), and allows extra functionality not possible without a config file. This config can also be accessed by scripts for any reason, so custom values can be put in if desired by the author. If a config does not exist in a normal collection, a default one will be generated.

All values are optional, and only main_script will get a default value (except on the server version where there can be zero main scripts). Standalone collections obviously use their own name for the main script, and other collections will default to using "main.lua". Since the file generated is self-explanatory and there are no hidden options, it will not be discussed here.


Startup

DSL4 A second starting point is supported using a init_script.
DSL5 A third starting point is supported using a pre_init_script.

There are three distinct points that collections can be automatically started *if* they have at least one relevant script defined. If a collection does not start automatically, it will have to be started by a command or loaded as a dependency of another collection. In between each of these stages, DSL is reset and all collections are instantly killed (without ever calling MissionCleanup).

As for actual scripts, there are only 2 ways that one can be started.

Collections are only automatically started if DSL's global config doesn't have dont_auto_start set to true *or* the collection's config has an auto_start override set to true. If a collection's config defines auto_start, then this preference will be overridden. If however DSL's global config has force_auto_start_pref set to true, then the collection's auto_start is completely ignored. To put it a little more simply, the auto-start behavior is checked like this.

  1. Does DSL's config have force_auto_start_pref enabled? Then only auto-start if DSL's dont_auto_start is false.
  2. Does the collection have auto_start defined? Then only auto-start if it says to.
  3. Fallback to only auto-starting if DSL's dont_auto_start is false.

Commands

DSL4 Although all of these commands were available since version 1, the * option is only available in version 4 and beyond.

All known collections can be shown using the /list command. All collections are shown with the names that other collection commands expect. More specific information can be shown using the /check collection command, where collection is some collection name.

Starting (or restarting) a collection can be done using /start collection, or /start * to start / restart all collections. Restarting can also be done using /restart collection, and /restart * restarts all collections that were already running.

Stopping a collection is done using /stop collection or /stop * for all collections. This will not instantly kill scripts completely. Instead it starts the graceful shutdown process by killing all active threads and creating the cleanup thread (meaning MissionCleanup). The shutdown process will not be considered finished until all cleanup threads are dead.