And yes - clear case of senior moment - rtfm does miracles and in the worst case just run start-server.bat
http://www.realxtend.org/doxygen/runningnaali.html shows it all Cheers and happy weekend Pedro On Fri, Feb 11, 2011 at 6:05 PM, Peter Steinlechner <[email protected] > wrote: > Hi Toni > > thanks for the answers. It looks like Tundra will be the way to go! > > Just another question came up, of which I think you allready thought about. > > > How will the scenes be stored persistent on the tundra server, so in case > of a crash or restart the right scenes start up again? > I thought maybe there could be a way to store the datas referencing the > assets in a database or a folder with set of scene files and their positions > and have them loading on start of the tundra server. (I wouldn't be > surprised if it allready is there and I just need to go through the > documentation....) > > Cheers and a happy weekend to all > Pedro > > > > > On Fri, Feb 11, 2011 at 4:48 PM, Toni Alatalo <[email protected]> wrote: > >> Hi all, >> >> we talked about Tundra with Peter/Pedro, he tested the demos and sent in >> some comments and questions. We agreed to continue here -- I'll quote enough >> so that you see the nice comments too: >> >> On Feb 10, 2011, at 11:02 PM, Peter Steinlechner wrote: >> >> this is brilliant and I start to grasp and embrace the whole tundra idea. >> Certainly I have to tinker around with it a bit more, but I think this >> will >> really become the firefox and apache for virtual worlds! To make the >> GUI a part of the application, rather then having it in the viewer is a >> rock solid feature that opens some new horizons. >> >> >> Yep, and not only the GUI but basically all functionality .. like whether >> a client connection gets an avatar or something else etc. >> >> There is not much missing to make the opensim based taiga server very >> soon obsolete :-) >> >> >> We'll see, Opensim has nice aspects too, I'm not surprised if both stay >> around and develop for different purposes. But it seems to be that many >> applications don't need the Opensim featureset (like grids), and indeed that >> we can easily enough port the basics like chat and avatars to Tundra as >> application level scripts. >> >> One point I'd like to clarify: the customizability of the client, loading >> code from the net as a part of the service for custom GUIs etc., is there >> always in Naali. It doesn't basically matter if you use a Tundra or Taiga >> server, the EC system and the API for adding keybindings and menu entries >> from e.g. EC_Script Javascripts loaded with http can work similarily. So you >> can make also opensim+modrex worlds so that the service/app there defines >> the GUI. >> >> The difference currently is that Naali releases have the default UiModule >> always enabled, whereas in the builds from the Tundra branch it is disabled. >> But we could for example make it so that for Taiga worlds the default UI is >> shown only if modrex tells so (and when logging to vanilla opensim have it >> automatically on). Also, the new Asset API and the current EC_Script >> implementation that handles code loaded from the net are in the Tundra >> branch only so not in the 0.4 release. We may later get the things merged so >> that have the current things for all usages, discussed it in the meeting >> today, but that's to be seen and also depends on what people actually need. >> >> But there sure are unique points in Tundra usage, like: 1) ease of >> authoring of e.g. meshes on a local standalone app, which automatically >> updates textures in the 3d view when they change on disk and 2) network game >> dev where it makes sense to run same code partially both in the server & >> client 3) custom messaging for advanced feats. >> >> Just to note that the ECs and client side Javascript works against Taiga >> as well, can be useful if someone has made e.g. a complex app as an Opensim >> region module and wants a custom GUI for it. >> >> - Would it be possible to attach an alternative collision mesh to objects? >> This might be helpfull in case of adding ramps to stair meshes for >> example. >> Similar it was in rexviewer 0.42 >> >> >> Yes I think that already works, EC_RigidBody (which is how we communicate >> things to Bullet) supports putting a collision mesh ref IIRC. I think we >> should make the dotscene pipeline support that (or did someone do that >> already?) so that you can define the collisions meshes in your modelling app >> too. >> >> - Poking around a bit in the ogre website I stumbled over hydrax water, >> which >> looks quite neat - but didnt got further into the details and wonder if >> this >> would be very difficult to add or if you folks allready have something >> more >> stunning in mind ? >> >> >> Ali tested SkyX and Hydrax already a year ago or so, was it so that either >> is even in somehow as a compile time option? He's been waiting for the guy >> to make a release so could look at using them again. I think with Hydrax >> there was problems with using it for large waters, was too heavy? >> >> - The terrains resemble about the same size like in opensim but could I >> asume that >> it would allow easy for bigger spaces or loading a few terrain tiles, >> without using >> meshes ? I could think of more then just a few use cases where >> possibility of >> using bigger, real world elevation data based terrains would be welcome. >> >> >> >> Yes the EC_Terrains can be of any size and you can add as many as you >> want. For the client side that works even against Taiga, we had an extra >> terrain on world.realxtend.org:9000 earlier as a test, flying on the sky >> :) >> >> But on the Tundra server it really works for collisions, EC_Terrain just >> has a EC_RigidBody of type Heightmap. >> >> Indeed a good demo would be to make a large area with real world elevation >> data. I think should work ok 'cause Ogre does decent visibility culling, so >> rendering shouldn't be too heavy. Otherwise people have for long made >> advanced scene managers and terrain systems with Ogre for large worlds, >> someone was making a spherical system for earth scale planet etc., but I >> think with the current simple EC_Terrain system we can already do a lot. >> >> Pedro >> >> >> ~Toni >> >> 2011/2/9 Toni Alatalo <[email protected]> >> >>> part 2/2 >>> >>> note: in bird game you fly with arrow keys, but in fishgame currently >>> the same rightclick-drag to rotate as in av movement (i should remove >>> the need for that mousepressing and just use mousemove directly) >>> >>> >>> ---------- Forwarded message ---------- >>> From: Toni Alatalo <[email protected]> >>> To: [email protected] >>> Date: Wed, 19 Jan 2011 19:33:37 +0200 >>> Subject: Re: tundra demo scene with minigames >>> On Jan 19, 2011, at 1:13 PM, Toni Alatalo wrote: >>> >>> http://dl.dropbox.com/u/3589640/Tundra-1.0-demo.exe has a recent build >>> from the Tundra branch of Naali, with >>> >>> (...) >>> >>> I will send another mail later this afternoon with a link to a bundle of >>> the demo content and instructions on how to get it started locally. >>> >>> >>> Ok it's now up at http://www.realxtend.org/download/lvm_20110119.zip >>> >>> The basic instructions for Tundra usage are at >>> http://www.realxtend.org/doxygen/tundradocumentfiles.html . All that >>> applies for this document/scene as well. >>> >>> So after installing that Tundra demo, which is just a new version of the >>> Naali with the server included, you can open the demo scenes just by >>> clicking on them in windows explorer. This opens the scene in a server, >>> which is basically Naali running in standalone mode. It has a free camera >>> script loaded by default, so you can move around in the scene etc. To get >>> more things, you need to load the so-called plugins to the server. This is >>> best done now by using the scene structure window which you can open from >>> the menu. You can either drag&drop e.g. plugins/animals_LVM.txml and >>> optionally the fish and osprey games to that window, or do right-click -> >>> import scene in scenestruct. If you drag&drop to the 3d view, it places the >>> sceneparts in the place of the drop, which can be confusing with these >>> plugins. The other plugins like day&night are included already by default in >>> the main lvm.txml. >>> >>> When you load the animals plugin, you should immediately get some deers >>> running (or floating due to a bug) near the small river. This you see on the >>> server as well. >>> >>> To get to move as an avatar, and to play the work-in-progress crude >>> minigames, you need to connect with a client. You do this by running >>> viewer.exe, but it needs to be configured so that it knows where you have >>> your local copy of the demo assets. This is easiest done by right-clicking >>> in windows explorer in the LVM scene folder, the one where you have >>> lvm.txml, and choosing 'open tundra viewer in this directory'. There is a >>> screenshot of this in the doc linked above. By default a minimal little >>> connecting form is used now, there type: localhost (defaults to port 2345 >>> like the server too) and put any *single word* as username, password is not >>> needed. If you put "firstname lastname" it tries to connect with LLUDP to >>> opensim, and "something@something" would be using a reX account. >>> >>> Once connected you should get an avatar. This demo scene actually has an >>> old version of the avatar application which doesn't have flying and such -- >>> the current version is included in the tundra installer itself. >>> >>> Then on a client, after you have loaded the Osprey game, a statue of that >>> eagle like bird should appear by the beach near where the avatar first >>> landed. If you click that statue, it starts the game where you fly as such a >>> bird, and can try catching some red bass from the bay to bring to the two >>> nests. If you load the fish game, a table appears floating over the air :) >>> and you can click that to get to swim as an tiny anchovy fish .. which must >>> eat some plankton and avoid a big bass fish that eats the anchovy. The fish >>> game has no GUI graphics for info screens yet (apart from a work-in-progress >>> radar for which the image ref is broken for you now so it shows as an empty >>> white box), it just prints score in the console when you succeed in eating. >>> And ands when you get eaten by the big fish, when you return to your avatar. >>> >>> Hopefully you get somewhere with this info! >>> >>> Some basic Tundra info for authoring, from a discussion with a modelling >>> & texturing artist :) >>> 18:30 <antont> and the awesome thing for authoring is >>> 18:30 <antont> that you can just edit the content, and it updates >>> automagically >>> 18:30 <antont> for example if you open a scene like that with some object >>> that has a texture >>> 18:31 <antont> you can then paint that texture in photoshop >>> 18:31 <antont> and just save the file >>> 18:31 <antont> and it immediately refreshes in the naali/tundra view >>> automatically >>> 18:31 <borisrrrr> great! >>> 18:31 <borisrrrr> that's brilliant! >>> 18:31 <antont> same for materials and qt ui files and js game logic code >>> etc >>> 18:32 <antont> and you can just drag&drop a .mesh or .scene file from >>> your desktop and it shows >>> 18:36 <antont> this article i've written explains the EC idea etc >>> >>> https://github.com/realXtend/doc/raw/master/arch_article/simple.pdf >>> 18:36 <antont> also documents one of the examples, the avatar >>> application, in some detail >>> >>> on behalf of the realXtend project, >>> Toni Alatalo (+358407198759) >>> Playsign Oy >>> >>> >>> same. >>> >>> >>> >> >> -- >> http://groups.google.com/group/realxtend >> http://www.realxtend.org > > > -- http://groups.google.com/group/realxtend http://www.realxtend.org
