On Fri, Mar 30, 2012 at 9:02 AM, Toni Alatalo <t...
> 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
> 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.
> > On Mar 29, 1:49 pm, Toni Alatalo <t...@playsign.net> wrote:
> > > On Thu, 2012-03-29 at 09:41 -0700, Vik wrote:
> > > > (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
> > > One cool upside of using several EC_Scripts can perhaps be that the
> > > 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
> > > 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
> > > 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
> > > 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
> > > DynamicComponent, that stays too.)
> > > > Vik.
> > > ~Toni