On Thu, 2012-03-29 at 11:57 -0700, Vik wrote: > 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
No the point was that using the Script *Application* mechanism with multiple EC_Scripts is performant -- then you again only get a single engine. The same thing that Jonne mentioned and indeed the reference Avatar app uses. But yep I think a single EC_Script can still be nice. > And I don't think in this case live reloading will be useful... I think it's always useful when developing :) And you do get that with a single Script component too, it just resets the whole app then. > Vik. ~Toni > 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
