I have been testing this for several hours and have not been able to reproduce this bug.
For the purity of the experiment, I connected via a new direct connection and used a new client without scripts installed on it (no scripts).
Test command:
//inc %ttest | var %tt 600 | /echo -st 00,04 test %ttest start: 04.timer -o 1 %tt | .timer -o 1 %tt /echo -st 00,03 test %ttest end: 03.timer -o 1 %tt
Test screenshot:
![[Linked Image from i.ibb.co]](https://i.ibb.co/25nwTTQ/test-timer.png)
As you can see from the screenshot, testing did not reveal any failures in the timer using the
-o switch.
Possible reasons that can cause this timer behavior:
1.You may have some scripts running that can automatically stop a running timer or reassign its running time. As long as the timer does not have its own name, it can be common to all scripts. It is recommended that each new timer assign its own individual name so that they are all different and could not affect each other. For example: "
/timerTEST 1 600 /your command" - where the name for the timer would be "
TEST".
2.If you use services for remote connection to chat such as "
BNC/ZNC", then, if they are not working correctly or configured incorrectly, they may display incorrect times in the responses in your message, which will differ from the start times of the timers and may lag behind or, conversely, go beyond the expected expiration of the started timer.
