DAAD VS for Visual Code Studio released

Map preview, compiler-parity diagnostics and language support for DAAD text adventure sources.

Features

Map preview

Renders your adventure as a map laid out on a compass grid, so north is up. Run "DAAD: Show Map" or use the title bar button on any DSF or SCE file.

The map draws more than the connection table. Movement written as a conditional GOTO in a process table is drawn as a dashed edge, with the condition shown on hover.

UP, DOWN, IN and OUT are drawn as dashed green lines. Hover one for its direction and destination: the line tells you the connection exists, not which way it points, because those directions have no place on a compass grid.

Objects show where they start, and optionally where PLACE and SWAP can move them. Shift-drag a location to pin it; pins are saved beside your source so a team shares one map.

Scroll to zoom, drag to pan. Reset view refits the whole map, as does double-clicking empty canvas. Key describes every line, box and badge. The toolbar also carries a target selector, a location filter, and toggles for potential objects and for freezing updates.

Authoring checks

Problems with the adventure itself, as opposed to things the compiler would reject: one-way exits, exits whose return is not the opposite direction, exits to locations that do not exist, unreachable locations, locations with no exits, and movement that cannot be drawn.

A location with no exits is not reported as unreachable. DAAD has no container object, so a spare location is often used as the inside of a box; if any condact names it, or an object starts there, it is in use.

Language support

Syntax highlighting, plus semantic colouring that tells locations, objects and flags apart by how they are used rather than by naming convention.

Hover shows a location's description, an object's text and attributes, a system flag's meaning, and a condact's arity and behaviour. Go to definition, find all references, and an outline of sections and process

tables.

Compiler checks

DRC, the DAAD compiler, rejects far more than most editors will tell you about. This extension reproduces 30 of its checks so you see them while writing rather than at build time:

• Ranges. A condact naming a location, object, message or system message the file does not define. CHANCE outside 1-99, WINDOW outside 0-7, any argument that will not fit in a byte.
• Vocabulary. The verb and noun columns of a process entry, the noun and adjective columns of an object row, and arguments to ADJECT1, PREP, NOUN2 and SYNONYM, all checked against /VOC. - Object rows. Start locations that do not exist, weights above 63. - Table structure. Gaps and repeats in message, location and object numbering; tables over DRC's limit; over-long extended messages; duplicate connections; direction words of the wrong type.
• Process tables. SKIP targets that are undefined, in another process, or beyond the 128-entry jump limit; duplicate labels; @ indirection outside the first argument. - Preprocessor. Duplicate #define, out-of-range #userptr, #db and #dw, odd-length #hex, unquoted #ifdef labels.

They appear as warnings. Set daad.diagnostics.drcSeverity to error if you would rather have the compiler's strictness while editing. Each check can be turned off on its own.

Three are off by default, because a normal DRC compile accepts them: deprecated-condact and xpicture-target apply only when compiling with -replace-xcondacts, and duplicate-process flags splitting a process table across two headers, which is a legitimate technique.

Dialects

Works with hand-written DSF and decompiled SCE sources, English and Spanish vocabularies, and both marked and unmarked process entry formats.

A text table entry may put its id and its text on separate lines, quoted or unquoted, as decompilers emit. All three layouts are read, so a decompiled SCE shows real location descriptions, messages and object names rather than bare numbers.

Encoding

DSF and SCE sources are Windows-1252, not UTF-8. This extension sets files.encoding to windows1252 for the DAAD DSF language by default. Opening these files as UTF-8 corrupts accented characters, and saving then writes that corruption to disk.

Build targets

Sources using #ifdef can define different locations per platform. The map toolbar chooses the active target; content belonging to other targets is ghosted rather than hidden.

The selector opens on `(none)` - no target defined, which is what DRC compiles when given no defines, and so the build that ships. Choosing a target from the list is the same as passing that define. A file whose only conditional is `#ifdef "DEBUG"` therefore shows its release build first.

Settings

Under DAAD DSF in Settings: five for the map and language, one toggle per diagnostic, and daad.diagnostics.drcSeverity.

Turning a diagnostic off changes only what the Problems panel shows. The map never goes stale as a result.

Colours

Colouring comes from your theme. The grammar emits conventional TextMate scopes, so a DSF file is coloured the way your theme colours every other language, on any theme, light or dark, with no command to run and nothing written to your settings.

The grammar knows every condact and tells conditions from actions: AT, CHANCE and NOTZERO colour as control keywords, MESSAGE, GOTO and DONE as plain keywords. Numeric arguments are numbers, quoted and unquoted text are strings, comments are comments. Section headers such as /PRO, entry numbers, vocabulary words, @flag indirection, #n text escapes and preprocessor directives each carry their own scope. A condact is only coloured as a condact inside a process table; GET in /VOC is a vocabulary word.

A second, semantic layer types the things the grammar cannot: in DSF a bare argument could be anything, and only analysis can tell that AT 5 names a location, PRESENT 5 an object, SET 5 a flag and MES 5 a message. The same analysis colours #defined names by how they are used, so GOTO lCellar reads as a location wherever lCellar appears. Each kind reaches the theme through a standard scope it already styles:

kind	token type	coloured as
location	daadLocation	a type name
object	daadObject	a constant
flag	daadFlag	a parameter
message	daadMessage	a string
system message	daadSysMessage	a regular expression
process	daadProcess	a function name
vocabulary word	daadWord	a language variable

Changing the colours

Your own editor.semanticTokenColorCustomizations rules win over the fallbacks above. The token types are daadLocation, daadObject, daadFlag, daadMessage, daadSysMessage, daadProcess and daadWord, with modifiers system, reserved, declaration and the word classes (verb, noun, adjective, adverb, preposition, pronoun, conjugation). Modifiers ship unstyled, so they are there to build on. For example, to give flags a fixed colour and mark #define sites bold:

jsonc { "editor.semanticTokenColorCustomizations": { "rules": { "daadFlag": "#8CC2FF", "*.declaration": { "bold": true } } } }

The grammar's scopes all end in .daad-dsf and can be restyled through editor.tokenColorCustomizations, for example keyword.control.condition.daad-dsf for condition condacts and keyword.other.action.daad-dsf for actions.

If your theme shows fewer colours

The semantic layer needs the theme to opt into semantic highlighting, which almost every theme does - among those built into VS Code, only Light High Contrast does not. Without it the grammar still colours condacts, numbers, strings and comments, but bare arguments stay plain numbers and `#define`d names stay uncoloured. Turn it on with:

jsonc { "editor.semanticTokenColorCustomizations": { "enabled": true } }