The Witcher wiki now has a light themed alternative for the wiki skin. To check it out, go to Special:Preferences, then choose the "Appearance" tab and click on the radio button next to "Hydra".
This article is too short to provide more than rudimentary information about the subject. You can help Witcher Wiki by expanding it.
Witcher Script (.ws) is the primary scripting language for The Witcher 3: Wild Hunt. A very large chunk of the game's logic is written in Witcher Script. Mods can override scripts and thus can drastically change game behavior. Witcher Script is either based on or identical to ActionScript 3 (and very similar to UnrealScript).
The specification for ActionScript 3, which is also used in the Shockwave Flash file format and can be described as a dialect of ECMAScript, can be found in its official language reference (unofficially also here, here and here).
Technically, Witcher Script is a strongly-typed, class-based object-oriented programming language, though it supports functions declared outside of the scope of classes. It uses C-like control flow with a single global namespace. Functions use pass-by-value by default for native datatypes and structs, with the keyword
out indicating pass-by-reference. Pass-by-reference is used for objects. Like C, Witcher Script is free form, with semi-colons serving as statement terminators and curly brackets pairs defining groups of statements as well as scope. It is pre-compiled prior to runtime though it supports line-by-line debugging.
Witcher Script doesn't appear to have function references, though it is possible to pass function names for callbacks, though this seems limited to the engine (see implementation of Initialize in W3Class CPlayerInput for example of this).
- 1 Editors
- 2 Native Datatypes
- 3 Novel Features
- 4 Keywords
- 4.1 Access Limitations
- 4.2 Control Flow
- 4.3 Inheritance
- 4.4 Boolean
- 4.5 Nullability
- 4.6 Declarations
- 4.7 Memory Management
- 4.8 Access Limitations
- 4.9 Control Flow
- 4.10 Inheritance
- 4.11 Boolean
- 4.12 Nullability
- 4.13 Declarations
- 4.14 Memory Management
Some of the following information is speculation based on information in the scripts as well as information from other game engines. CDPR has been fairly mum about the inner workings of REDengine. If you know something, please edit the wiki so that the correct information is available!
Timer functions are functions that are periodically called on a timer while that timer is active. They are started with the functions
AddTimer and stopped with the function
RemoveTimer, both member functions of W3Class CEntity. It is likely that these start and stop timer functions only work if the script is "hooked" on to a native W3Class CEntity. Timer functions always take the parameters:
deltaTime : float, id : int
deltaTime is probably the time since the last activation of the timer, while
id is likely the id of the timer.
Latent functions are functions that execute over more than one game tick. They use either the global functions
SleepOneTick, or call other latent functions (including native ones!) that do. These functions can only be called from inside another latent function or from a state's
Global functions declared with one of these modifiers will be available to different portions of the game to execute. Generally speaking, only exec functions are interesting to modders, as it allows modders to add console commands to the game.
- exec functions are available to the debug console
- storyscene functions are likely accessible to cutscenes
- quest functions are likely accessible to quests
This declares a default value for a class field.
Likely, this means that this class field is available for editing in the REDkit 2 editor.
Classes defined with the
statemachine keyword are able to take on states, which are special kinds of classes that override behavior (i.e. functions/events) in their parent while the
statemachine class in in the child
statemachine class transitions between states and keeps a running stack. All
statemachine classes must eventually inherit from W3Class IScriptable and that class contains applicable functions.
Functions within a
state can be declared as
entry functions are also
latent, though it isn't clear what else this denotes.
In states, there is some distinction between