On pe, 2010-10-22 at 16:09 +0300, Jonne Nauha wrote: > If you want to do this properly with Naali with compatibility to Taiga > and upcoming Tundra you should use javascript. In naali we have a > entity component called EC_Script that you can give url to your > javascript in web somewhere. Write that js file with Naali js API and > you can then toggle for example the material/texture/particlescript on > your mesh to make it blink with some interval. At least this is how I > would do it, forget about legacy server scripts :P
I wouldn't quite say this at this point -- the old server side scripting (the rexscript ironpython thing) works and is mature, and what is out there shipped in the releases etc. so people can actually use it. Is perfectly fine for doing server side logic like occasionally blinking a light, change materials, move objects etc. And for things that you want synchronized similarily for the different users, like you usually do with such scene manipulations, you probably want to run them on the server anyway. The new Naali scripting stuff was made first for client side needs, like doing custom mouse hover handlers and other UI things that are about immediate reactions to local state, not networked centralized scene manipulation things, and which were impossible before Naali. You can nowadays do basically anything with the scene too, though, like create new entities and add/remove components etc.. also 'cause the Naali editing tools are implemented using the same API (from Python). But yes, with Tundra, where the same Naali codebase is used as the server too, the Naali API is also the server scripting API and the old rexscript opensim+modrex stuff can't work out of the box (because there is no opensim nor modrex). This is one of the main reasons for writing Tundra in the first place -- to get the same API to the client and server, like often in networked games and in e.g. the Syntensity VW system where same code runs partially on both sides. If someone has invested a lot in old rexscripts, like written a game or some other complex application using it, and wants to switch to Tundra at some point for some reason, it is probably easy enough to port the app code though to the Naali py api. But I'm guessing that at least in the near future (6 months) many people need OpenSim features and the relative maturity of Taiga so stick with opensim+modrex anyway, where can keep using and developing rexscript py stuff. By then we'll also know if the EC-centric Tundra techs can be used more with OpenSim/Taiga too, and whether having the same API, Tundra style, on the both sides is possible even with OpenSim(*). Is quite possible that many use cases are better off with OpenSim in the long run too, so can just keep using the current rexscript system. Tundra remaining and becoming useful for more complex interactive and custom apps. (* we are now exploring that in WebNaali, the websockets+webgl client, which can't use the C++ EC implementation from Naali, seeing whether it makes any sense to make a JS API there that could run same JS code that Naali can .. or whether it would be better to e.g. come up with a new simpler scene API and write a compatibility layer for that for Naali, if compatibility with the c++ ogre+qt client and the browser+webgl+js client makes sense at all) > Others can comment if I went wrong somewhere there, at least I have > gotten the impression that EC_Script will download a url ref and > execute it in the client. Toni already did some door example with this > style, to open/close a "door" prim. He didnt do it with ec script but > I think that steared how ec script on js side at least should behave. The earlier pre-EC_Script implementation I made, using DynamicComponent, works so that if a DC has an attribute called js_src, Naali downloads that code from the web and executes it in a (supposedly) secure sandbox .. where the code can only manipulate the own component (in that case the door data) and access a few selected other components (touchable for getting mouse hover & clicks, placeable for moving the door object). This is for untrusted JS from the net -- alternatively you can add trusted Python handlers by writing a class (in this case DoorHandler) which automatically handle DCs with a specific name (here: "door"), and can do anything with the scene and your operating system etc. (is quite similar to the ServerScriptClass rexscript thing). The later EC_Script thing by Ali and Jonne V. is currently for local trusted code, also the JS in that impl has full access to the scene. Code for those can AFAIK currently be loaded from local files in the client only. It uses the same Py and Js engines as the earlier things, but with a bit different execution mechanism. > Ali: did we have some js examples up already and some wiki how to > implement these? There are some EC_Script js examples in http://github.com/realXtend/naali/tree/develop/bin/jsmodules/apitest/ . Also the older door thing is there. One big limitation with the js system now is the lack of qt there currently. Ironically, it is made using qtscript, but doesn't currently expose qt :) Jonne V. had some trouble with adding the qt bindings from qt (made with qtscriptgenerator). So adding new menu entries and custom ui windows etc. is only possible from py still, like this: http://github.com/realXtend/naali/blob/develop/bin/pymodules/apitest/pythonqt_gui.py But the Naali scene stuff is exposed with the same mechanism to both Python and Javascript, so powerful scene manipulation should be possible now .. in this sprint I finished the removal of the old PyEntity wrapper and other py specific scene things that allowed creating new entities, removing components etc., so those should work now from js too. Also things like getting all entities with placeable or presence (i.e. avatars) components etc. have been there for a couple of sprints now. Plan is to integrate those examples to the doxygen documentation from git, instead of putting to wiki. Code in git is easier to edit and especially execute (I hope we can make it so that the script code examples are executed too as a part of the test suite so that we don't get outdated/broken examples in the docs .. Erno actually already made test cases for many of the py ones). Jukka already prepared the place for these, but we haven't put anything there yet: http://www.realxtend.org/doxygen/scriptsamples.html > Jonne Nauha ~Toni > > On Thu, Oct 21, 2010 at 9:16 PM, MasterJ <[email protected]> wrote: > hmmm i'm thinking about that if it's can be possible to use a > python > script for have a blinking neon for example and play with this > script. > it's give me idea and i actually search for that .... problem > is .. > can we use them on Naali after? and if yes how to made them > working? > > exemple: i have a light as a mesh (a neon tube a cylinder in > this > exmple hehe) and i have this famous python script (i still > search for > it ) > how i can tell Naali (or it's server side?) to use this script > on this > famous mesh? > > can be a good idea to made nice lights with glow and neon no? > > MassterJ > > > On 15 oct, 18:54, pedro <[email protected]> wrote: > > I just was watching nMechanics > demo:http://www.youtube.com/watch?v=FUZT1KJJvuQ > > - is it possible to have this sorts of reflections in naali > too or is > > it too early ? Also is there a possibility available to > simulate neon > > lights and glow around lightsources or is it best to try > simulating > > these effects with materials and textures? > > > > Cheers > > Pedro > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > > > > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
