Thank you Jonne for your comments - they are really helpful.
For example, I never thought to put sturtup() at the end of the file
- for me it was more clearly put in front :) Also lot of unnecessary
GetComponent("EC_Name")...
About parameter --run and AddRigidBody. This is due to the fact that I
have exported scene from some works in a blender. This export do not
add RigidBody, so I decided to add it for some element at startup in
JavaScript. Another reason - this script will change the scene on the
server, and thus, the client should not know about this JS. If I added
it to the scene, as you say, I have to give it to the client as well.
But I want to put some validation for UserConnection (check username
and password). I did this already in Python (as well using command
line option --python filename.py). But in the latest version, Python
has been temporarily removed, and I thought about validating users in
the same JS script through qt.webkit as Tony pointed me in another
thread.
About --storage options - I use it, and I have a question about this.
When I start Tundra server in the remote real server machine, I run
the client with option --storage src=http://someserver.com/webdav. In
this case, I need to replace all assets references 'local://somefile'
with simple 'somefile', if not, this 'somefile' refuse to the auto-
download from server ... I have other solutions for the local://
thing?
Regards,
Vik.
On Mar 30, 6:33 pm, Jonne Nauha <[email protected]> wrote:
> Hi, good looking scripts you have there. I can give you some tips, i'll do
> it via pastebin with code comments, this might be most clear way of doing
> it. But first:
>
> Adding 10x10 fish is ok by two method. But adding 20x20 fish with
>
> > Fish.js (many instance of javascript) will fail with error "Could not
> > allocate register file N" where N is different 2, 33.
> > I would like to know what this mean?
>
> I have seen this couple of times myself. I am 99% sure its due to out of
> memory. 20x20 script engines = 400, lets say one takes up 2 megs of memory
> (I don't know the actual figures, might even take more) would be 800 megs
> of mem. I usually see "catastrofic failure" on Tundra.exe at around 1,3
> gigs of memory usage for the process, and out of memory exceptions start to
> pop from Tundra or from Ogre. Basically you will dump. Did you btw get a
> dump dialog or did it continue to run happily?
>
> I think Jukka is referring to the same engine register file issue
> herehttps://github.com/realXtend/naali/issues/444"often inside QScriptEngine
> register file allocation code", this would also indicate out of memory
> situation. So as we knew and see here clearly this amount of script engines
> is a very bad approach for your problem and the single engine is excellent.
> The less engines you have the better. But id say in a moderately heavy
> scene you can still have 10-15 engines doing their own things, but 400 (or
> 50x50=2500) is clearly too much.
>
> I have also question about how to know when scene is ready for
>
> > manipulation. I used some sort of tentative every 1 sec... It is
> > correct or i can use more clean approach?
>
> I will go over this and some other stuff that popped to me while reading
> you scripts. I prefer paste.pocoo.org for code pastes, easier to read than
> pastebin because its wider.
>
> - *add_dyn.js*http://paste.pocoo.org/show/573825/(see the original
> AddRigidBodyToEntities() implementation, i added some useful info)
> - The other scripts look fine to me. You got the idea how to do it with
> both ways :) Looks good to me. You are correctly only doing the rotation on
> the server which is important so client and server wont do it. And if you
> would manipulate rigidbody like avatar app does, it has to be done on the
> server as only it has the authority to do it.
>
> One this is that you might want to move away from --run parameter. Its fine
> for you to test out things of couse if you prefer it that way. But for you
> app here, I would make a txml that has only add_dyn.js as a server side
> script + avatar application ready to go, here is a example of it (you can
> copy this to your data/assets or where you'd like as a txml).
>
> Scenehttp://paste.pocoo.org/show/573829/*Save this as
> /bin/data/assets/fishes.txml*
> add_dyn.js for this kind of usagehttp://paste.pocoo.org/show/573834/this
> is short and cleaned version of you script, same outcome. *Save this as
> /bin/data/assets/add_dyn.js*
>
> No open cmd prompt to and run these:
>
> Tundra.exe --server --headless --console --file data/assets/fishes.txml
> Tundra.exe --config viewer.xml --login tundra://localhost/?username=Vik
>
> Ask if you have any questions. I don't know if I went a bit overboard here
> :P
>
> Best regards,
> Jonne Nauha
> Adminotech developer
>
>
>
>
>
>
>
> On Fri, Mar 30, 2012 at 11:00 PM, Vik <[email protected]> wrote:
> > Thanks for all your comments,
> > I made some test for compare single vs. multiple.
>
> > This test add some hundreds of fishes to Avatar's scene, using two
> > techniques discussed here.
> > add_dyn.js (http://pastebin.com/knpit5H3), Fish.js (
> >http://pastebin.com/8AnFdB9p), and GlobalFish.js (
> >http://pastebin.com/RhNB9jLe
> > )
> > You can change technique in line 3 of add_dyn.js. Change How many
> > fiches add by line 2 (n*n fish will be added) . Using scene.txml from
> > Avatar examlple, some fiche will fall (need to make bigger floor).
> > Added second avatar for demo purposes.
> > Start Tundra in command line with param --run add_dyn.js. Or use
> > console...
>
> > Some observation:
> > Adding 10x10 fish is ok by two method. But adding 20x20 fish with
> > Fish.js (many instance of javascript) will fail with error "Could not
> > allocate register file N" where N is different 2, 33.
> > I would like to know what this mean?
> > Using GlobalFish.js - we add single js, but instantiate many instance
> > by EC_SCRIPT, as Jonne explained. This method permit add as many as
> > 50x50 fish without problems...
>
> > I have also question about how to know when scene is ready for
> > manipulation. I used some sort of tentative every 1 sec... It is
> > correct or i can use more clean approach?
>
> > Thanks.
> > Vik
> > Vik
>
> > On Mar 30, 2:18 am, Jonne Nauha <[email protected]> wrote:
> > > 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 classhttps://
> > 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 objectshttps://
> > github.com/realXtend/naali/blob/tundra2/bin/jsmodules/browser....
> > > Booting up the apphttps://
> > 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 <[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.)
>
> ...
>
> read more »
--
http://groups.google.com/group/realxtend
http://www.realxtend.org
