One thing I like to do is push limits, and pushing the length of the Vizzy script has turned up a few thoughts on an improvement to help with larger scripts during editing, and make code cloning a bit less frustrating 🤣
Suggestion 1:
When you click on the code and drag, instead of animating all of the other however many blocks there are, just animate the top few and then outline the shape of the rest.
What happened when the script got long:
You click to drag some code, and instead of getting the code block you clicked and tried to drag, you either have something from another place pulled out nearby, or you have nothing grabbed at all.
Bug (cause and effect I believe from rendering the blocks to be dragged, or panning the code quickly while zoomed out): (On Windows 10 PC)
The nose pan function suddenly flips from just one button click to pan, you have to click both right and left mouse buttons together to pan and it pans at double speed. Sometimes you can be zoomed out some to scroll the code faster, and it will also case this to switch. Just as it switches it switches back. Band aid for it is to save to craft and reopen the script.
Suggestion 2:
The copy function needs a few more options. It reacts differently when you're trying to copy parts or sections and these are nested. You can grab just that section, but cloning has varied results. Sometimes you get the frame, sometimes you get what you want plus the whole rest of everything below it 🙈. Maybe copy block or frame( just that one) copy section ( the pieces that would normally come out if grabbed normally) or copy rest to copy that and everything below it.
I believe the outlining optimization for edits would really improve performance and cause much fewer errors moving something too far out of a nest or from where it supposed to be, and because it was a randome grab now you have to hunt down where it came from 🙈 that one got me a lot on my algorithm.
Extra thought:
Maybe even carry the outlining over to the panning as well. Like for example, only render every other Nth section or every few lines with and outline the rest, and then when pan stops (not mouse click stopped, just pan speed below a small amount), then call a full render to display it back. Keep the click in there so we can save a step looking or scrolling slow but grab and snap like going from bottom to top fast, outline a good bit of it so it doesn't hang or cause you to alter your code by accident because of a frame skip waiting for renders.
Need a switch/case type statement too. Same effort to make the structure as using a bunch of ifs, but would greatly increase the speed at which it executes (it's looking for one specific case, not testing 100 if statements individually for a single condition, which takes a lot more processing time...)
Example:
My in-flight tutorial uses about 30 some odd ifs and because of the way it works it has to be nested, and it sometimes will be testing if this then that but no if this, then test again if that and this is over that but not this and less that, and maybe yes but then something is still missing that's not tested but display in case it isn't, and then it's caught with another test, another display is used and the process continues.... to determine 3-4 things every .5 seconds. If I had switch case, I could test maybe 4 levels, get a number, pass that to a function or another switch case to make 5 and display 1 message one time based on case and only use processing to look for specific case one two or so on. Without I'm having to test, retest, and use fall through messages stuck up ahead of time to account for a few simple case situations. 🧐 Maybe I can set it up that way with ifs, but for some reason trying it like that before I got a lot of wrong things out of it, usually backwards of what was expected (despite rearranging the order in the flow) 🙈. Small structure like this seems to be ok despite doing about 30 tests a second, but I would think something of a greater scale, testing for more conditions at once may be taxing to processing power 👍