I completly agree with you that it can be done this way.
One of the things I want to avoid is to have mappers (which will script their NPC maps as well) to get lost into scripting. Truth is Im not
aiming to implement game code in a scripted language, but to give mappers a way to easy put more life into their maps through scripting.
In the final implementation , the scripter should not even care what interpreter the underlieing scripting engine uses, nor make any assumptions
about what are its abilites. He should stick to the interface offered , and if he needs another script command he must ask us to implement it.
Keeping this in mind, I am aiming to implement event handling INSIDE the scripting engine code, and only allow a very narrow set of events
to be processed by a script thread (for example , a "thread" (function, method) whatever ) to be called on NPC spawning , take pain, hurt 50% , etc). In rest , he should not care about an event such as "finished moving to new vector", he should not even know that such a event is processed inside the scripting engine.
Anyway, even such a method as yours can be looked as a a very particular case of a thread dispatcher. We have here "pseudo-threads" (methods to be called ) which are dispatched by scripting engine core on very specific events.
However, your post made me think that a paper talking about using Lua in games, or in general any other interpretor in a game , should talk
about different scripting engine designs for games as well. In fact I think is much more important to talk about designs and designs caveats
then about calling C++ from scripts.
----- Original Message -----