Site changes

Author: github-actions[bot]

llms-full.txt

@@ -89,7 +89,7 @@ Minimum supported version of Chrome. Cannot be less than 32. For more informatio
 YAML field name: **`initialMemory`**
 Default value: **33554432**
 
-The size of memory that allocated for web application. If ALLOW_MEMORY_GROWTH=0, this is the total amount of memory that web application can use. for more information look [link](https://emscripten.org/docs/tools_reference/settings_reference.html?highlight=environment#initial-memory). Value in bytes. Note that value must be a multiple of WebAssembly page size (64KiB).
+The size of memory that allocated for web application. If `ALLOW_MEMORY_GROWTH=0`, this is the total amount of memory that web application can use. for more information look [link](https://emscripten.org/docs/tools_reference/settings_reference.html?highlight=environment#initial-memory). Value in bytes. Note that value must be a multiple of WebAssembly page size (64KiB).
 That options relates to `html5.heap_size` in *game.project* [link](https://defold.com/llms/manuals/html5.md). Option that configured via application manifest is set during compilation and used as default value for `INITIAL_MEMORY` option. Value from *game.project* overrides value from application manifest and used in runtime.
 
 ## Stack size (wasm-web only)

llms-manuals.txt

@@ -64,7 +64,7 @@ end
 
 ## Update Loop
 
-The Update Loop runs through a specific sequence once per frame. This sequence can be defined by 5 main phases:
+The `Update Loop` runs through a specific sequence once per frame. This sequence can be defined by 5 main phases:
 
 1. Input (processing and handling)
 2. Update (including Fixed, Regular, Late and engine components’ updates)
@@ -80,7 +80,7 @@ Any game object that has acquired input focus and contains collection proxy comp
 
 ### Update Phase
 
-The `Update` phase is a part of the Update Loop. It is started once for the root collection, and then runs recursively for each enabled collection proxy.
+The `Update` phase is a part of the `Update Loop`. It is started once for the root collection, and then runs recursively for each enabled collection proxy.
 
 Within a collection, Defold processes callbacks by component type: it iterates over all instances of a component type that implements the relevant stage, calls the Lua callback for each instance, flushes messages, then moves on to the next component type.
 

llms/manuals/app-manifest.md

@@ -45,13 +45,13 @@ Orthographic Mode
 
 ## Using the camera
 
-All cameras are automatically enabled and updated during a frame, and the lua `camera` module is available in all script contexts. Since Defold 1.8.1 there is no longer a need to explicitly enable a camera via sending an `acquire_camera_focus` message to the camera component. The old acquire and release messages are still available, but it is recommended to instead use the "enable" and "disable" messages like for any other component that you wish to enable or disable:
+All cameras are automatically enabled and updated during a frame, and the lua `camera` module is available in all script contexts. Since Defold 1.8.1 there is no longer a need to explicitly enable a camera via sending an `acquire_camera_focus` message to the camera component. The old acquire and release messages are still available, but it is recommended to instead use the `enable` and `disable` messages like for any other component that you wish to enable or disable:
 ```lua
 msg.post("#camera", "disable")
 msg.post("#camera", "enable")
 ```
 
-To list all currently available cameras, you can use camera.get_cameras():
+To list all currently available cameras, you can use `camera.get_cameras()`:
 ```lua
 -- Note: The render calls are only available in a render script.
 --       The camera.get_cameras() function can be used anywhere,
@@ -95,7 +95,7 @@ camera.get_fov("main:/go#camera")
 render.set_camera("main:/go#camera")
 ```
 
-Each frame, the camera component that currently has camera focus will send a `set_view_projection` message to the "@render" socket:
+Each frame, the camera component that currently has camera focus will send a `set_view_projection` message to the `@render` socket:
 ```lua
 -- builtins/render/default.render_script
 --

llms/manuals/application-lifecycle.md

@@ -89,7 +89,7 @@ render.dispatch_compute(32, 32, 32, {constants = constants})
 
 Currently, generating any type of output from a compute program can only be done via `storage textures`. A storage texture is similar to a "regular texture" except that they support more functionality and configurability. Storage textures, as the name implies, can be used as a generic buffer that you can read and write data to from a compute program. You can then bind the same buffer to a different shader program for reading.
 
-To create a storage texture in Defold, you need to do this from a regular .script file. Render scripts does not have this functionality as dynamic textures need to be created via the resource API which is only available in regular .script files.
+To create a storage texture in Defold, you need to do this from a regular .script file. Render scripts does not have this functionality as dynamic textures need to be created via the `resource` API which is only available in regular .script files.
 ```lua
 -- In a .script file:
 function init(self)

llms/manuals/camera.md

@@ -73,7 +73,7 @@ It is important that you match the correct engine with the callstack, otherwise
 * Windows - the `dmengine.pdb` file in `build/x86_64-win32` contains the debug symbols for Windows builds.
 * HTML5 - the `dmengine.js.symbols` file in `build/wasm-web` contains the debug symbols for HTML5 builds.
 
-It is very important that your save the debug symbols somewhere for each public release you make of your game and that you know which release the debug symbols belong to. You will not be able to debug any native crashes if you do not have the debug symbols! Also, you should keep an unstripped version of the engine. This allows for the best symbolication of the callstack.
+It is very important that your save the debug symbols somewhere for each public release you make of your game and that you know which release the debug symbols belong to. You will not be able to debug any native crashes if you do not have the debug symbols! Also, you should keep an `unstripped` version of the engine. This allows for the best symbolication of the callstack.
 
 ### Uploading symbols to Google Play
 You can [upload the debug symbols to Google Play](https://developer.android.com/studio/build/shrink-code#android_gradle_plugin_version_40_or_earlier_and_other_build_systems) so that any crashes logged in Google Play will show symbolicated call stacks. Zip the contents of the `projecttitle.apk.symbols/lib/` bundle output folder. The folder includes one or more sub folders with architecture names such as `arm64-v8a` and `armeabi-v7a`.

llms/manuals/compute.md

@@ -4,7 +4,7 @@ You can create custom menu items and editor lifecycle hooks using Lua files with
 
 ## Editor script runtime
 
-Editor scripts run inside an editor, in a Lua VM emulated by Java VM. All scripts share the same single environment, which means they can interact with each other. You can require Lua modules, just as with `.script` files, but Lua version that is running inside the editor is different, so make sure your shared code is compatible. Editor uses Lua version 5.2.x, more specifically [luaj](https://github.com/luaj/luaj) runtime, which is currently the only viable solution to run Lua on JVM. Besides that, there are some restrictions:
+Editor scripts run inside an editor, in a Lua VM emulated by Java VM. All scripts share the same single environment, which means they can interact with each other. You can `require` Lua modules, just as with `.script` files, but Lua version that is running inside the editor is different, so make sure your shared code is compatible. Editor uses Lua version 5.2.x, more specifically [luaj](https://github.com/luaj/luaj) runtime, which is currently the only viable solution to run Lua on JVM. Besides that, there are some restrictions:
 - there is no `debug` package;
 - there is no `os.execute`, though we provide a similar `editor.execute()`;
 - there is no `os.tmpname` and `io.tmpfile` — currently editor scripts can access files only inside the project directory;

llms/manuals/debugging-native-code.md

@@ -81,7 +81,7 @@ where *profile* can be:
 * **metrics** - runs VictoriaMetrics + Grafana as metrics backend and tool for visualization
 For more information about `docker compose` arguments see https://docs.docker.com/reference/cli/docker/compose/.
 
-When docker compose is up you can use **http://localhost:9000** as Build server address in Editor's preference or as `--build-server` value if you use Bob to build the project.
+When docker compose is up you can use **http://localhost:9000** as `Build server address` in Editor's preference or as `--build-server` value if you use Bob to build the project.
 
 Several profiles can be passed to command line. For example:
 ```sh

llms/manuals/editor-scripts.md

@@ -97,7 +97,7 @@ Motion tweens allow the animation of various properties of an object, including
 
 ## Defold—property animation
 
-Defold works with pixel images as opposed to vector graphics, thus it does not have an equivalent for shape tweening. However, motion tweening has a powerful equivalent in [property animation](https://defold.com/ref/go/#go.animate). This is accomplished via script, using the `go.animate()` function. The go.animate() function tweens a property (such as color, scale, rotation or position) from the starting value to the desired end value, using one of many available easing functions (including custom ones). Where Flash required user implementation of more advanced easing functions, Defold includes [many easing functions](https://defold.com/llms/manuals/animation.md) built-into the engine.
+Defold works with pixel images as opposed to vector graphics, thus it does not have an equivalent for shape tweening. However, motion tweening has a powerful equivalent in [property animation](https://defold.com/ref/go/#go.animate). This is accomplished via script, using the `go.animate()` function. The `go.animate()` function tweens a property (such as color, scale, rotation or position) from the starting value to the desired end value, using one of many available easing functions (including custom ones). Where Flash required user implementation of more advanced easing functions, Defold includes [many easing functions](https://defold.com/llms/manuals/animation.md) built-into the engine.
 
 Where Flash makes use of keyframes of graphics on a timeline for animation, one of the main methods of graphic animation in Defold is by flipbook animation of imported image sequences. Animations are organized in a game object component known as an atlas. In this instance we have an atlas for a game character with an animation sequence called "run". This consists of a series of png files:
 
@@ -166,7 +166,7 @@ Defold includes a modified version of the Box2D physics engine, which can simula
 
 The collision object includes the following properties:
 
-A box shape has been used as this was most appropriate for the bullet graphic. The other shape used for 2D collisions, sphere, will be used for the target. Setting the type to Kinematic means resolving collisions is done by your script as opposed to the built-in physics engine (for more information on the other types, please refer to the [physics manual](https://defold.com/llms/manuals/physics.md)). The group and mask properties determine what collision group the object belongs to and what collision group it should be checked against, respectively. The current setup means a "bullet" can only collide with a "target". Imagine the setup was changed to the below:
+A box shape has been used as this was most appropriate for the bullet graphic. The other shape used for 2D collisions, sphere, will be used for the target. Setting the type to Kinematic means resolving collisions is done by your script as opposed to the built-in physics engine (for more information on the other types, please refer to the [physics manual](https://defold.com/llms/manuals/physics.md)). The *Group* and *Mask* properties determine what collision group the object belongs to and what collision group it should be checked against, respectively. The current setup means a "bullet" can only collide with a "target". Imagine the setup was changed to the below:
 
 Now, bullets can collide with targets and other bullets. For reference, we have set up a collision object for the target that looks as follows:
 
@@ -204,7 +204,7 @@ on_reload
 
 The callback functions listed above are all optional and can be removed if not used. For details on how to set up input, please refer to the [input manual](https://defold.com/llms/manuals/input.md). A common pitfall occurs when working with collection proxies - please refer to [this section](https://defold.com/llms/manuals/input.md) of the input manual for more information.
 
-As discussed in the collision detection section, collision events are dealt with through the sending of messages to the game objects involved. Their respective script components receive the message in their on_message callback functions.
+As discussed in the collision detection section, collision events are dealt with through the sending of messages to the game objects involved. Their respective script components receive the message in their `on_message` callback functions.
 
 ## Flash—button symbols