I'm back from a break. Another excellent update: some tasty screenshots, and good news on progress toward straight gameplay feature/content coding.
After reading the scripting part of this update, though, I have a story to share, and a question.
This story concerns niceness, responsibility, and knowledge.
My coding career started on Motorola's 6809 processor-based Radio Shack Color Computer and IBM's mainframe running MVS. These systems were very different in power, but the experience of programming on them was similar in an important way: every program could be written as though it was the only thing running.
In the case of the CoCo, this was essentially true. Its OS was a single-tasking (albeit interrupt-driven) system. Once your code was given control of the CPU, it kept control until it was done (barring high-priority interrupts or I/O calls). As a programmer, you didn't have to worry about ceding CPU to other applications; there weren't any. So your code could just do whatever you wanted.
This was also true for code on IBM's System/370 mainframe... but a mainframe supported this "I believe I'm the only program running" perspective for multiple applications semi-simultaneously. It did this through "preemptive hardware multitasking." The OS would start your code and watch its behavior. After a certain amount of time, or if your code started an action that involved waiting -- like doing an I/O operation, which is very slow compared to straight CPU usage -- the OS itself would "preempt" your code. It would save all your state -- registers, stacks, the works -- then give the CPU to another process. Eventually the OS, according to its scheduling algorithms, would restore your program's state, and your code would get the CPU again until it completed (or the next preemption).
The important point here is that, in both of these cases, you as a programmer never needed to think about adding special breakpoints at appropriate locations in your code to explicitly yield control back to the CPU. You didn't need to know how to be nice to other applications. You just wrote your code as though the CPU was exclusively yours. Simple.
Then came Windows. It was a multitasking OS, but unlike a mainframe OS it didn't know how to do preemption all on its own. So now, in addition to making sure your code was correct, you also had to know how to structure your code so that you could explicitly yield control of the CPU back to Windows at appropriate places. Some programmers did this well. Some didn't. But everyone had to try, regardless of how this complicated the normal logic of what their code was trying to accomplish.
Then Windows and compilers and scripting languages got smarter, and once again programmers could write their code as though it's the only thing running, letting the OS take care of preemption for maximal efficiency.
And now there's the new LT scripting language, which again expects programmers to alter the natural structure of their code so that sleep(x) statements can be inserted in efficient places. This presumes that the people who want to mod LT with scripts will know how/where/when/why to inject a sleep(x) call.
None of this is intended in a critical tone. It would not be wise for me to criticize any technical solution Josh produces.
If the best route to LT scripting that is powerful, performant, and relatively simple to support is to have scripters figure out where in their code they need to temporarily yield control back to the CPU, then that's just how it is.
I guess I'm wondering: would it be a good idea, if People Who Are Not Josh will be expected to shoulder that responsibility, to help them out by describing the rules for knowing where to put sleep(x) calls?