scene_set_client_script
Adds or replaces a client-side Lua script in a save copy, enabling interactive UI, menus, and 2D games on the player's screen with variables and lifecycle callbacks.
Instructions
Put a client script (客户端脚本) into a copy of a save, or replace the one of that name: Lua 5.3 that runs on the player's own machine and drives client controls (scene_add_client_ui puts those on the screen and says which script their root carries). This is the way to an interface that moves and answers the mouse and any key, to a menu, to a whole 2D game on the screen; a node graph cannot do these. The game calls the functions OnInit(), OnStart(), OnEnable(), OnDisable(), OnDestroy() when the script defines them, and OnUpdate(dt) every frame once the script has called script:EnableUpdate(true) (not before: seen in play). variables gives the script values it reads with script:GetParam(name): any of the twenty types the editor offers (integer, float, boolean, string, vector3, the ids guid, configId, prefabId and controlId, entity, and a list of each); one marked public can be given another value by each control that carries the script (scene_add_client_ui, script: {name, values}), which is how one script serves several controls. script.object is the control the script is on; control:GetChild(name) finds a control under it. From the level a script reads custom variables (game.GetGlobalCustomVariableValue(Enum.CustomVariableEntityType.PlayerSelf | Level | AvatarSelf, name), and script:RegisterCustomVariableChangedHandler to hear a change), so a graph tells the screen something that lasts by setting a variable; a graph sends the scripts of one player a message of the moment with f.sendSignal('client:NAME', player) (a signal of scene_add_signal; the script hears it with script:RegisterServerSignalHandler("NAME", function(name, params) ... end)); to the level a script sends a signal (game.ServerSignal(name):SendSignal()). Not available in this Lua: coroutine, io, load, loadfile, dofile, package, most of os and debug (refused here). require is there: require("NAME") runs the script whose file is NAME.lua (another script of the save, put there with this tool and carried by no control) once and gives what it returns, so a level can be several files; the name is the file name without .lua, letter for letter. Color(r, g, b, a) takes 0 to 255 (fractions give black), and the fill of an image (a bar that grows, a cooldown ring: SetFillHorizontal, SetFillRadial360, fillAmount) shows only on an image whose mask is on (mask: true in scene_add_client_ui, or control.enableMask = true): the result says so when the script looks like either mistake, as it does for an OnUpdate that was never enabled and a tween that was never played. A script that does not compile is refused here at once, with line and column; names it gets wrong (a function game does not have, an Enum value, a signal or a variable the save lacks) come back as problems, each with the nearest name there is; a fault while it runs comes back in the prints of the playtest with a traceback. read_knowledge {id:"client-lua.zh-CN"} is the page on writing one, with a worked script; the whole API is the official page (search_knowledge "客户端控件API文档"). Replacing a script keeps its id: the controls that carry it need no change, so a round of work on the Lua is this call and a playtest, and that playtest takes about a minute: when the save the last playtest opened is still open and nothing but the text of the scripts differs, playtest_start writes the Lua into the files the editor keeps beside the save (the game runs those) and plays, without importing anything. Writes a new .gil in the workspace; the official save is not touched.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| name | Yes | ||
| source | No | ||
| mapPath | No | ||
| variables | No | ||
| outputName | No | ||
| sourceFile | No |