tecs.files

Where a game reads its shipped content from.

nupp.io.files owns every filesystem operation and every writable root: reading, writing, atomic commits, directory streams, temporaries, metadata, and the platform's own configuration, data and cache directories for one named application. This module keeps the one thing Nupp cannot supply, because it is a property of the product rather than of the platform: where this build's content was installed.

const disk = require("nupp.io.files")

disk.setApplicationIdentity("Ex Nihilo", "Starfarer")
const saves = assert(disk.dataPath()):join("saves")
disk.writeAtomic(saves:join("slot1.json"), bytes)

const level = disk.read(tecs.files.assetPath("levels/one.json"))

The asset root#

assetRoot is where shipped content lives and is never a place a build may write. TECS_ASSETS wins, which is how a development run reads straight out of a build tree instead of a staged copy. Then the __tecsContent global, since a host knows the layout it installed and this is not something to sniff for. Then the directory the running executable was loaded from, which is where a single-directory build puts everything. assetPath joins against it without checking existence, because a path that is about to be read is as valid a request as one that is already there.

Writable roots#

A game names itself through nupp.io.files.setApplicationIdentity and then asks nupp.io.files for configurationPath, dataPath or cachePath, each of which is a distinct directory that is created before it is answered. Saves and settings belong under dataPath, and anything the game can rebuild belongs under cachePath, which the operating system may empty between any two runs. tecs.application.newApplication names the identity "tecs", "tecs" when a game named none, so an engine test and an unnamed tool write somewhere stable.

function assetPath(relative: string): string

function assetRoot(): string

function reset(): nil

function setAssetRoot(root: string): nil

const ASSET_ROOT_VARIABLE

const CONTENT_GLOBAL