[00:00] In this lesson, we'll take a look at timer scripts. Timer scripts execute periodically at some configurable rate and are well suited for repetitive tasks. Timer scripts can be set up in gateway or client events, but I'll focus on client timer scripts for this video. I already have a timer script, so I'll double click it to open up the settings. It's currently disabled, so I'll go ahead and click the checkbox to enable it for testing. The delay setting is the interval for the script, and that along with the delay type determines when the script will be executed. The default is fixed delay, and this means that it will wait for the given delay before executing the script again. This also means that the rate will actually be the time it takes to execute the script plus the delay. If my timer script took 500 milliseconds to execute and the delay was set to 1000 milliseconds, the next script would actually execute one and a half seconds after the previous one started its execution. Fixed rate, on the other hand, will attempt to run the script at the rate relative to the first execution. However, because it doesn't take the execution time of the script into consideration, it is possible that an execution could be missed with a sufficiently long execution time.

[01:08] Threading determines which thread this script will run in. When it's set to shared, all other timer scripts on shared will be run in the same thread. This is preferable as it's not creating lots of unnecessary threads and less resources are used. However, if any of the scripts take a long time to run, it could block the other timer tasks that are set to run on the shared thread. Alternatively, setting this to dedicated means that a separate thread will be created specifically for the timer script to use. This would be the preferred option if script executions need to be as consistent as possible, or if this is a long running script. This way, it won't affect any other scripts and they won't affect it. A good general rule for threading would be to place quick executing scripts on shared and longer executing scripts on their own dedicated threads. I'll click Okay to enable the script, and then the script itself is just a simple print statement. I'll make sure my project is saved and open up the client to test it. These print statements will be sent to the client console, which can be found in the diagnostics window.

[02:04] Once I open that tab, I'll start seeing my print statements fire at the rate I specified for the timer script. I'll head back to the script and modify it to show what happens when there's an error. Now if I go back to the client console, I'll see the error message. It also tells me that any future messages regarding this error will be thrown as debug messages, so by default, this error won't continue to fill the console logs unless I were to modify that logger's logging levels. If I had any long running scripts, I could also open up the scripts tab here and see those scripts listed. I'd also get the option to terminate them if I wanted. That's an overview of how to configure and troubleshoot client event scripts. As a reminder, these are scripts that execute on every client and only if there are open clients scripts that need to run, regardless of whether a client is open or scripts that might only need to run once, like some sort of database action, might be better suited for gateway event scripts.