I Rewrote the code for a cyclelocked TAS Engine But It Still Messes Up randomly

i rewrote the wait {} Seconds block by making a repeat 30 / (seconds) block change a frame var by 1 then every 30 frame var change second var by one until the repeat ended then set both vars to 0

for glide i... gave up and used the twonerds glide block

https://scratch.mit.edu/projects/531031997/

i Based This Off Of My TAS Recorder And TASCreator's TAS Engine

TAS Stuff:

https://drive.google.com/drive/u/1/folders/1pK57J_kUdZiAY6W9U93_jWJcaIWEnM1T

Here Is A TAS I Made With The Engine:

it is also bad at lag crusher

Scratch lacks determinism so it will most likely consistently fail, unless we can make SA deterministic this will be a major road block, making collision deterministic will be hard though.

I had an idea a while back that using libtas on the scratch desktop app could maybe make it possible to tas scratch games, I don't know how that would work, and I've never used libtas, but might be something to consider.

determinism is a major problem

@BringUpYourPost i rewrote the game and recorded and replayed runs without lists for this reason but that is true determinism is a massive problem i don't know hot to solve. My main problem is platforms still snap upwards when turbowarp custom fps is lower than 10 because of quarter steps. Playing a TAS at 30fps the quarter steps are less laggy and more can be done in 30 frames. :because turbowarp lags the game not does math to calulate when frames should happen: I Think. i don't know how turbowarp slows the game down but it does it inaccurately.

But it going slow is not a problem, scratch's collision is not deterministic. so it will think it is colliding with something, but in the exact same situation it will stop.

This simple fact has caused me so much pain.

@BringUpYourPost The first time scratch Draws something it effects everything else. Example is the platform on scene 3 if its size is different because it was first drawn in the miniplayer it's collision will be different same as if the level was first drawn as scene 411 then scene 1 the collision would be near the same but little differences but if scratchy is in run-3 there collision would be also near the same but collision checks are different so he can run on edges there not supposed to. Example is where scratchy can "bonk" on walls and fall all the way down (killed some great runs) my guess is because he goes too much in the wall and he gets pushed out like normal but his costume is closer to the wall so it updates scratchy's X and Y and it takes 2 frames for the whole process so he goes in the falling costume and he gets updated to falling. This "bonk" can happen anywhere this combined with the fact that the first draw of a level changes the ground collision so he could be moving slower makes the game very inconsistent.

deterministic if all things work the same which is possible BUT unlikely, this isn't the biggest problem yet I still have to fix slow down breaking platforms and other problems for a 99% perfect TAS editor. this will be on my list of things that I will look out for. This will offsync TASes by a little bit but it is small.

unlike this paragraph.