Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
realXtend
Home
+ new post
About this group
Join this group
Message from discussion Javascript. What is better 'global action' or hundred small 'actions'?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Jonne Nauha  
View profile  
 More options Mar 30 2012, 2:18 am
From: Jonne Nauha <jo...@adminotech.com>
Date: Fri, 30 Mar 2012 09:18:27 +0300
Local: Fri, Mar 30 2012 2:18 am
Subject: Re: [realXtend] Re: Javascript. What is better 'global action' or hundred small 'actions'?
Print | View thread | Show original | Report this message | Find messages by this author

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/browser....
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/browser....
Booting up the app
https://github.com/realXtend/naali/blob/tundra2/bin/jsmodules/browser...

Best regards,
Jonne Nauha
Adminotech developer

On Fri, Mar 30, 2012 at 9:02 AM, Toni Alatalo <t...@playsign.net> 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 <t...@playsign.net> 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


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google