Thank you, Tony I will go with single EC_Script ( normal programming :) ) Even if ScriptEngine is performant, load hundreds of EC_Script may be painful ( as Jukka said in issue 439 https://github.com/realXtend/naali/issues/439 ) And I don't think in this case live reloading will be useful... Vik.
On Mar 29, 1:49 pm, Toni Alatalo <[email protected]> wrote: > On Thu, 2012-03-29 at 09:41 -0700, Vik wrote: > > 001,...door.099), i can attach to each object javascript for actions > > (say "OpenDoor"). Or I can attach one script to scene and in this > > script distinguish door by name at run time. > > Which solution is better. I mean 'better" from architectural point > > of view of Tundra in terms of performance and memory consumption. > > I tend to make with one master JS and one EC_Script for the whole > application. I like normal programming, and also that used to be way to > make it efficiently (minimal mem use as there's only one ScriptEngine). > Have that in an invisible entity called MyGame or so. > > The system is however made so that using a Script component in each > scripted entity can be nice. For example for a non-programming level > designer to put a script to an object. And nowadays there's the > ScriptApplication system, which basically allows you to make several > script components to be executed with a single engine, so you get the > same optimally minimal memory usage. I think it's well suited for > instanciating several entities that use the same script, basically > declaring a class in JS and then marking entities in the scene as > instances of that. Similar to the RexScript IronPython system in old > realXtend with Linden based viewer and Opensim which is there in ModRex. > > One cool upside of using several EC_Scripts can perhaps be that the live > reloading may work less instrusively as only one script engine is > reseted and not the whole app. For example if you make AI for a predator > and it's prey, can modify either code, just save the file so it gets > reloaded in Tundra, and at least the other animal keeps working cleanly > from the old state as it was untouched. It's possible to make a main app > support restart too, quite easy perhaps even if keep the data in EC > attributes (script's can create their own so-called DynamicComponents > for custom data). The attribute values are ofc untouched when the script > engine is reseted, so that state can always stay (position of the > objects etc., but if you put e.g. some AI mode or tracking target in own > DynamicComponent, that stays too.) > > > Vik. > > ~Toni -- http://groups.google.com/group/realxtend http://www.realxtend.org
