Sansar will use industry standard tools, animation, and programming language.
which lead to interesting discussions about what the ‘industry standard’ programming language would be, a bit all over the place, and, of course, nobody really knows — because those who know are NDA’d to secrecy. The rest is allowed to speculate, although Sansar’s registration form for potential parties interested in previewing their technology asks if the person has knowledge of programming in ‘C#, Java, LSL’, which certainly allows one to conjecture that these languages — or one closely related to them — are the best likely candidates. The truth is that everybody who experimented Sansar so far talk about its builds, not about its programming… but, anyway, we can safely assume that whatever LL picked for Sansar as a programming language, it will not be LSL (Linden Scripting Language), and whatever it will be, it will be utterly incompatible with what is being currently scripted for Second Life.
In other words… LL has been quite clear in the past that, although they have considered the possibility to allow certain content to be migrated from SL to some of the Sansar worlds, in practice that would tie their new software too much to ‘legacy’ support, and that, of course, has a huge cost — of development, of maintenance, of having much more limited options to allow Sansar to do the amazing things it is supposed to be able to do. So, no, this will hardly happen — ever. It’s not just about prim-based objects. You could theoretically export all prim-based objects as meshes (this is what happens inside the SL viewer anyway, and it’s been that way pretty much forever) in an automatic way, but except for unscripted objects, this will just solve half the problem. Even a simple pose ball dropped on a chair would not work in Sansar.| ← Previous | | | Next → |