Yes you will want live realoding. You will go crazy if you need to restart client/server all the time when you save file. Script live reloading is the best feature Tundra has for devs :)
This other approach that simpleavatar.js uses gives you the same kind of " this.me" == entity the script is attached to feeling (you need to assign this.me as youll see in simpleavatar.js ctor). Without running huge number of script engines. So really, its how you like to program. I like to make more these separate apps that run in their own entities and keep their data component (EC_DynamicComponent) in the script entity. Then internal logic modifies/creates/removes entities/component how it needs. So I'm used to going "me.something" only for my data component, and for that I always make getter inside the app this.DataComponent(); :P Another neat thing if you want "real object" in your scripts is class.js that ships with Tundra. I basically use this in all my scripts. I haven't used it in the example scenes I've made as they should be kept simple. But the browser ui js I made shows this quite well. This also has some advanced UI stuff if you want to learn that :) Defining class https://github.com/realXtend/naali/blob/tundra2/bin/jsmodules/browserui/LoginBrowser.js#L26. You define init: function() that gets called when the class is new'ed, its little bit like python __init__. Main intance owns other objects https://github.com/realXtend/naali/blob/tundra2/bin/jsmodules/browserui/LoginBrowser.js#L36. Booting up the app https://github.com/realXtend/naali/blob/tundra2/bin/jsmodules/browserui/LoginBrowser.js#L1956 Best regards, Jonne Nauha Adminotech developer On Fri, Mar 30, 2012 at 9:02 AM, Toni Alatalo <[email protected]> wrote: > 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 > -- http://groups.google.com/group/realxtend http://www.realxtend.org
