From faa0c65af4da5f465d0a96b609378d6c7c8eab3f Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Mon, 21 Dec 2020 00:42:52 +0000 Subject: [PATCH] Merge docs for 'Note about callin inside the game tick.' --- docs/scarpet/Full.md | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/docs/scarpet/Full.md b/docs/scarpet/Full.md index 035c4560..b5aec1b9 100644 --- a/docs/scarpet/Full.md +++ b/docs/scarpet/Full.md @@ -4860,9 +4860,24 @@ averaging. ### `game_tick(mstime?)` -Causes game to run for one tick. By default runs it and returns control to the program, but can optionally -accept expected tick length, in milliseconds. You can't use it to permanently change the game speed, but setting -longer commands with custom tick speeds can be interrupted via `/script stop` command +Causes game to run for one tick. By default, it runs it and returns control to the program, but can optionally +accept expected tick length, in milliseconds, waits that extra remaining time and then returns the control to the program. +You can't use it to permanently change the game speed, but setting +longer commands with custom tick speeds can be interrupted via `/script stop` command - if you can get access to the +command terminal. + +Running `game_tick()` as part of the code that runs within the game tick itself is generally a bad idea, +unless you know what this entails. Triggering the `game_tick()` will cause the current (shoulder) tick to pause, then run the internal tick, +then run the rest of the shoulder tick, which may lead to artifacts in between regular code execution and your game simulation code. +If you need to break +up your execution into chunks, you could queue the rest of the work into the next task using `schedule`, or perform your actions +defining `__on_tick()` event handler, but in case you need to take a full control over the game loop and run some simulations using +`game_tick()` as the way to advance the game progress, that might be the simplest way to do it, +and triggering the script in a 'proper' way (there is not 'proper' way, but via commmand line, or server chat is the most 'proper'), +would be the safest way to do it. For instance, running `game_tick()` from a command block triggered with a button, or in an entity + event triggered in an entity tick, may technically +cause the game to run and encounter that call again, causing stack to overflow. Thankfully it doesn't happen in vanilla running +carpet, but may happen with other modified (modded) versions of the game. 
 loop(1000,game_tick())  // runs the game as fast as it can for 1000 ticks