Good points, Ben. I'd like the OptoScript editor to have a "spell check" button for comments, and a "fix all this code to do what I meant rather than what I coded" button. Alas, our PAC Control wizard programmers are limited not only by practical restrictions, but also by the fact that the editor we use for OptoScript is a third-party package that Opto bought from another company (which hasn't updated their code in a while). heavy sigh
In any case, we can't do much about "other people's code" but we can do something about our own! On this concept of "Every chart, just OptoScript blocks," I say: "Don't do it!" First of all, that's not possible--quick, before looking at my answer for why, who can tell me the reason?
I'm sure Ben meant "...except the required Block 0" Action Block that I'm guessing our OptoScript-only friend leaves empty. I'm also guessing that our strictly-script friend uses more than one OptoScript block, at least? Because this is unappealing for multiple reasons:
I would not want to have to troubleshoot that block, especially if it has more than a page or two of script in it. (One rule of thumb for programmers is to break functions up into one- or two-pages or screen's worth of code. If it's more than that long, it's hard to take in all at once and is probably missing an opportunity for modularizing further.)
Also, a flow chart (again, I'd want to keep it to about a page or screen's worth) can help the next guy, even if it's you, figure out at a glance what's going on. Sometimes in our documents we call this "self documenting." But what we really mean is, this visual description (as in, a flow-chart) is handy for understanding a process!
Here's one I've been working on, which has plenty of OptoScript blocks in it (although the contents of each are not bigger than my screen):
Of course I could have used some if-then statements or a switch to replace those four condition blocks in an OptoScript block, but I like a "good-looking flow chart" (to quote my friend on the left in the little movie that started this thread). However, since I never write a perfect chart on the first try, I did have to do some troubleshooting. And when the part of the code that processes the users' guess wasn't working, it was easy for me to quickly set a breakpoint and narrow down my bug with it laid out like this.
Note: see the "delay" block in there, can't emphasize the importance of that enough. Should be required somehow, just like Block 0. It's always nice to put this where it's clearly what all roads lead to, like I tried to do here. You can see at a glance that it will get hit every time through this main loop.
Also note the one block I DIDN'T use, and you're unlikely to EVER see me use: the Continue block. If I were a fan of the Continue block, I might've put one just below that bottom "Loser?" Condition block instead of having my False arrow be so long. Why don't I like it? Something against the lavender color? No.
For one thing, if you use a Condition block, you miss out on that visual clue I mentioned above, showing the looping clearly and that a delay is in there. Also, from when I first learned to program in BASIC back in 19-eighty-nevermind, the GOTO was a no-no. A Continue block seems like cheating/hacking to me. Like you're magically being beamed up to some other location through a fictional teleporter.
But that's just my unfair bias. I'm also not crazy about driving off-road in a four-wheel drive so what do I know?
Thoughts? Other preferences? Do share!