As a good jumping off point I was planning on Screen and Global scripts, or "Objects," first then going from there. The first script system I wrote was over-engineered and as a result was crap to work with and use; the second time I learned my lesson and it was much simpler. Forcing scripters to use objects (read: classes, member ptrs, virtual, inheritance, etc.) for everything is not a good start I don't think. Tell me if you think I'm wrong here, but whenever we can do a simple procedural style interop I'd go with that.
The simplest things to add (and immediately support) right now are global callbacks--Link is just a namespace so he falls into that category as well--everything else object related needs a bit of integration into ZC, and npcs need a slight refactoring first. Also doing the bindings and all that junk for them so I'll call that phase 2.
The way I'm doing it right now is this: If a script object defines an instance callback then it gets called, if not then the engine will ignore it. For example:
In this example maybe the scripter doesn't care about it being updated, or drawn, or anything else besides what happens when it is destroyed, so that is fine. It still exists and other scripts can access it the same, or whatever else. Did you have something better in mind?Code:class MyGlobalScript { int myTime = 420; void OnDestroy() { //this callback is defined, so it gets called by the engine. //last call for alcohol } }
I don't like the idea that any object can have any number of scripts though, that sounds very complicated and bad. Can you give an example?
Also Waitframes(), contexts, and callbacks are already working. I do need to implement an intermediate pass over preprocessed script code (hopefully without any major lexing) as a next thing I do though. Modifying angelscript is not so easy for certain things, and I wasted a bunch of time in that when I should of just done it separate... :/