Hi Toni, Am 09.09.2013 03:36, schrieb toni at playsign.net: > When I started to work on the DynamicComponent thing the idea was not > actually to implement dynamically added&removed attributes, but a way > for define *static* i.e. normal component types from what were we > calling dynamic languages (javascript, python, lua and such). I had a > first test thing for that running when the Ludo guys also worked on it > and implemented the dynamic components thing. I found it a bit weird as > was working on a different thing, but it did work also for my purpose -- > it does enable defining and working with your own component data from JS > -- so I just started using it too. We’ve discussed this often since then > and at one point I learned that the guys had found it a useful mechanism > to be able to just add some data easily, IIRC Ludocraft was using it > from c++ modules too really early on and told that found it handy sometimes. > > But for network efficiency reasons, and I think also for robustness > (defined sets of attributes for the component type) to avoid bugs in the > programming, being able to declare EC types from scripts would be nice > still. A big bonus I’ve thought would be that they’d work right in the > graphical EC GUI editor used for authoring - adding your component would > have the attributes pre-populated, now we often just add them by hand > there (a script can ofc populate them too - and often they are > completely only handled by scripts and not touched manually. but there > can be nice for manual use too, like some nice camera and light setups > perhaps, or door functionality .. you just add the Door EC to the object > you want to work as a door, it can be a simple script and doesn’t need > an UI even if just setting some parameter in the editor suffices). > > I’ve been calling it CustomComponent support now. Jonne has been calling > it ‘the thing that Toni wants’ 😊 Thanks this kind of meta information is very valuable. And it confirms what I had in mind, so thanks a lot! > Defining network messages would be good too, like you can with c++ with > kNet and with many languages using something like Protobufs -- so yes > KIARA can be really nice for us, as I understand it has that too.. > right? In scripts, we now use these text string based entity actions - > sometimes being able to specify real optimized normal network messages > would be good I suppose .. for example a custom movement message for > your movement system perhaps? This is what we are putting together. >> This definitely makes sense. I still think that moving the relevant >> field into a single component can simplify things even more. The two are >> orthogonal. > > This is an interesting point - also Placeable can be used to move > objects, by setting position. RigidBody features the nice movement sync. > But not all moving objects need the RigidBody otherwise, I mean the > Bullet physics things. > > I wonder whether the RigidBody movement sync in Tundra is not only about > velocity based intra- & extrapolation .. Jukka at least tested falling > to client side physics upon network probs etc. iirc. I consider dead reckoning a very general method that does not just work based on velocity. In certain situation the application has additional knowledge that can be used to fill in if data from the server is missing. Physics is one such approach but there are others as well. I general I do not expect that we will a unique optimal answer, there are always trade-offs because such data is use for multiple purposes. > The 1st Annual Opensimulator Community Conference #OSCC13 was great - > Intel DSG guys etc. were there too and many nice VW dev folks. And Grady > Booch even 😊 . There was healthy interest for realXtend too and we were > talking about these web client efforts related to that, some knew xml3d > from before which was very cool. That virtual conference running on > opensimulator itself was quite an achievement by those folks -- a > landmark really, very well organized and on a completely open source > stack. They had a nice simple customized client app for it (just a > preconfigured slviewer basically but good). I kind of like the idea of virtual conferences with some form of "presence" in general but I have been a bit skeptical about it also. Mainly because there is so much communication in our body language that not only gets lost but is replaced by an artificial "body language" that does no correspond to the users state of mind. So it communicates something that might even be very much in conflict to what you are really saying. A like a new type of "uncanny valley". But I think there are many things that can be done to improve the situation. So I am not against it at all. In the contrary, building a Web-based client where you can just enter with the click of a mouse without having to install some software first seems like a very good target for us as well. Best, Philipp >> Philipp > ~Toni > > >> Yes, again this is very generic. The Tundra SDK does not decide what >> security model you have. It provides signals to application logic (C++ >> or script) to tell it if a scene change should be allowed. This has >> proven to be enough in Meshmoon as we use it to determine who can make >> client side scene changes. If the Meshmoon user has "basic" permission >> on the scene we will reject any changes it tries to do to the scene >> model on the client side. These users can still interact with the scene >> via the scripts in that scene, whatever the apps there might be. >> >> You can send custom messages via EntityActions (not yet documented on >> the wiki). Basically its a way for the client to send messages with >> custom data variables and the server side logic can act on it. With this >> mechanism you can move the scene manipulation to the server side and >> thus the change is allowed also for "basic" users. >> >> The change requests can be catched in server side app logic >> from > http://doc.meshmoon.com/doxygen/class_scene_sync_state.html#signals. At >> some point we will need to extend this to provide information what >> component and attribute the change was targeted to. Currently it will >> tell what entity the client tried to manipulate. >> >> >> >> >> Best, >> >> Philipp >> >> >> Lasse: Please step in if I made an factual errors :) >> >> Best regards, >> Jonne Nauha >> Meshmoon developer at Adminotech Ltd. >> www.meshmoon.com <http://www.meshmoon.com/> > > > -- > > ------------------------------------------------------------------------- > Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH > Trippstadter Strasse 122, D-67663 Kaiserslautern > > Geschäftsführung: > Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > > Sitz der Gesellschaft: Kaiserslautern (HRB 2313) > USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 > --------------------------------------------------------------------------- > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: slusallek.vcf Type: text/x-vcard Size: 456 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130909/9f010986/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy