Known Networks ChatZilla error Connected Networks <none>
URL irc://foo/bar Not Connected Lag <unknown>
URL irc://efnet/opensim-osgrid Mode +tn Users 17, 0@, 0%, 0+
Topic <none>
URL irc://foo/bar Connected via <none>
<none>
<none>
<none> Connected to <none>
File Progress <unknown>
#opensim-osgrid
<Neas Bade>: :)
<Neas Bade>: great tleiades
<Neas Bade>: danx0r what kind of help do you need on the physics front?
<Wright Juran>: Charles, opinion on mono? I think the others are in a better position to say, as they use mono more than me
<Tleiades Hax>: I think it is safe to move mono requirements up to 1.2.4, now gutsy has been released
<Neas Bade>: also, some of the other folks here on IBM are looking at helping to fill out the LSL implementation. No promisses on speed, as it is all free time stuff, but hopefuly more patches from folks like Illumious coming
<Tleiades Hax>: I remember we discussed the fact that ubuntu was stuck on 1.2.3
<Charles Krinkeb>: If no one objects, I will begin heading in the direction of updating OSGrid from mono-1.2.3.1 to mono-1.2.4 over the next week or so.
<Neas Bade>: yeh, 1.2.4 is probably recommended new version
<Charles Krinkeb>: If no one objects, I will begin heading in the direction of updating OSGrid from mono-1.2.3.1 to mono-1.2.4 over the next week or so.
<Nebadon Izumi>: very good
<Neas Bade>: sounds good cfk
<Wright Juran>: sounds good
<Nebadon Izumi>: i think thats great charles
<lmmz> sounds good!
<Neas Bade>: danx0r you still in world?
<Nebadon Izumi>: also since Rookiie is here we should acknowledge his really amazing Grid Web Interface
<Neas Bade>: oh, another thing, MW posted a great glossary explanation on the mailing list
<Nebadon Izumi>: he really did a great job
<Charles Krinkeb>: Does the top 10 bug list on the wiki make sense to everyone? Add to it as appropriate. But, only 10 on the list max.
<Nebadon Izumi>: http://www.sourceforge.net/projects/opensimwi
<lmmz> Great job, Rookiie!
<Neas Bade>: is there a volunteer to build a glossary in the wiki based on that post?
<Neas Bade>: yes, great job on opensimwi
<Tleiades Hax>: I love the top 10 bug list
<Charles Krinkeb>: sdague, mw. I would like to adopt this, but have some issues with modifying the users table. I dont want to make it incompatible with OpenSim on OSGrid.
<Wright Juran>: of course though I am for 0.5 being a big release, the problem with big releases in a open source project are that when there are busy months for the developers (on non project releated things) it does effect the release more than if it was a small feature release
<Neas Bade>: I think the top 10 bug list is definitely a good thing
<Sakai openlifegrid>: perhaps an intermediate release is more appropriate?
<Sakai openlifegrid>: drawing on ur 0.4.x idea
<Nebadon Izumi>: Does anyone think that adding fields to the user table have any adverse effects on grid mode functionality?
<Neas Bade>: Charles, I think perhaps it would be good to email out the top 10 bug list to the mailing list o na weekly basis
<danx danx0r>: are we agreed that ODE goal is no more ugly crashes?
<Tleiades Hax>: cfk... if you can send me the table defs, I can have a look at updating the table layout
<Neas Bade>: danx0r I agreed
<Nebadon Izumi>: i personally dont see how it could effect it but would like others opinions
<danx danx0r>: as opposed to focusing on niceties like not bouncing 500 meters
<Tleiades Hax>: yes
<paulie Femto>: yep
<Sakai openlifegrid>: :)
<danx danx0r>: ok I may put in hax to basically reset physics if I get that exception
<Tleiades Hax>: crashing is worse than things not working right
<Nebadon Izumi>: Tleiades maybe you can just download the opensimwi
<Charles Krinkeb>: done, Neas. Next subject, I will put my concerns about adopting opensimwi on the mailing list also. I need some technical guidance before I modify the users table.
<danx danx0r>: so instead of crashing it will just zero velocities and make positions sane
<Nebadon Izumi>: and have a look
<Sakai openlifegrid>: def
<Neas Bade>: I think the problem with 0.4.x releases is "what have we done that provides incremental benefit to 0.4 that's as reliable as the features in 0.4"
<Tleiades Hax>: ok
<danx danx0r>: I remember why I didn't do it before: this is a C++ hack
<Neas Bade>: 0.4 was very solid for what it supported
<Sakai openlifegrid>: well what would be your targets for a 0.4.x?
<Sakai openlifegrid>: over a 0.5?
<Neas Bade>: danx0r how can I help on the physics debug front?
<Wright Juran>: yeah true, if we did 0.4.X releases they really would be peacemeal 0.5 releases rather than mantiance releases on 0,4
<Sakai openlifegrid>: ie. stable ODE etc =0.4.x then 0.5 inv assets grid?>
<Neas Bade>: let's not worry about releases per say over the next month and just push on hard on the grid and physics stability fronts
<Tleiades Hax>: yes, I think we agreed not to invest too heavily in branching in svn
<Wright Juran>: agreed
<Neas Bade>: sakai, I don't think you could back port what we have really
<Sakai openlifegrid>: ok
<Neas Bade>: face, it, I'm the one that beat everyone up a lot to get 0.4 out the door :)
<danx danx0r>: neas - issue is this means we are forking ODE
<Neas Bade>: so if I see everyone getting complacient, I'll start beating up again :)
<Sakai openlifegrid>: ;)
<Nebadon Izumi>: hehe
<Wright Juran>: I think most people still run from svn version anyway so releases aren't so much a issue just yet, and we have the nightly builds
<danx danx0r>: since we need to change ODE's exception handling logic
<Neas Bade>: ok
<Sakai openlifegrid>: true we only use ur svn;s
<danx danx0r>: I'm OK with that, I think it's enevitable whichever engine is used
<Neas Bade>: well, do you think that is more or less sensible than digging on bullet?
<danx danx0r>: just means have to merge if we want new ODE versions
<Wright Juran>: how far is Bullet from being up to ODE level ?
<danx danx0r>: neas -- I think it's sensible to get ODE stable, then move to bullet after 0.5
<Wright Juran>: ah ok
<danx danx0r>: Wright -- it needs quite a bit of work
<Nebadon Izumi>: i dont think its even close
<Nebadon Izumi>: bullet is very unstable
<danx danx0r>: and we need to detangle some things from the ODE plugin
<Neas Bade>: ok, so probably we'll want to create a sepereate opensim-ode repo
<danx danx0r>: I've also seen bullet eat up ALOT of cpu
<Sakai openlifegrid>: /me shudders
<danx danx0r>: and ODE so far has seemed surprisingly light on CPU from what I've heard
<Neas Bade>: ok, fair enough
<Sakai openlifegrid>: I could do some comparisons if you like
<Neas Bade>: /me considers danx0r the physics master
<danx danx0r>: I agree long-term bullet looks good, but it's new -- almost no docs
<danx danx0r>: and despite our issues, I suspect ODE is more stable due to maturity
<Sakai openlifegrid>: (physical)
<Wright Juran>: are we still going with c# bullet or as I saw danx suggest before, a wrapper on c/c++ Bullet?
<danx danx0r>: and BTW there is still active ODE developers -- note they moved from 0.8 to 0.9 in a few months
<Neas Bade>: ok, good to knwo
<danx danx0r>: and finally, it's simply the case that I'm very familiar with ODE and not with Bullet
<Neas Bade>: so presumably we'd start with 0.9, and modify the exception handling?
<danx danx0r>: and so far new physics coders have not stepped up to fulltime involvement
<danx danx0r>: tho gerard is doing excellent work on meshing prims
<Wright Juran>: yeah so sticking with ODE seems the best (as you are doing most of the work, think we should stick with whatever you think)
<danx danx0r>: neas - yes, since ODE is now in opensim-libs, I feel comfy hacking on it
<Neas Bade>: ok, sounds good
<Tleiades Hax>: /me has confidence in danx0r's work
<danx danx0r>: only thing is when it gets hacked, we have to update binaries in opensim/bin
<danx danx0r>: agreed then. I may be quiet for a bit, stressful workday
<Neas Bade>: I'll probably bug you a bit more on IRC about getting up to speed on physics so I can help there
<danx danx0r>: neas -- great, later this aft will be better
<danx danx0r>: boss is right here, wondering why I'm complaining he blocks UDP ports
<Nebadon Izumi>: lol
<danx danx0r>: btw corporate firewalls -- opensim shuld be better than LL
<Neas Bade>: yep, probably tomorrow actually, as I have municipal wireless meeting in RL after this
<danx danx0r>: we should have TCP connect, check for UDP/ports
-->| Tedd (~tedd@c85-196-75-106.static.sdsl.no) has joined #opensim-osgrid
<danx danx0r>: like video streamers do
<Wright Juran>: tell him that opensim is a great robot simulator enviorment (or will be)
<danx danx0r>: maybe a TCP backstop?
<Neas Bade>: 4 SL meetings and 1 RL meeting in one day makes for little real work :)
<danx danx0r>: well it does help me with physics, which I use on the job
<danx danx0r>: but it's a tentative argument at best
<danx danx0r>: any comments from you net wizards on TCP/firewalls?
<Tleiades Hax>: I think we are limited by the viewer
<Neas Bade>: danx0r I think that we'll get a bunch of that as the Linden environment evolves
<Sakai openlifegrid>: we haven't run into any issues with the opensim
<Neas Bade>: yeh, it's view issues right now
<Tleiades Hax>: I think all opensim code uses tcp
<danx danx0r>: d'oh of course it's a client-side issue
<danx danx0r>: 'nother reason for our own client...
<Neas Bade>: from all the Linden talk that I've heard, the viewer will be able to opperate in TCP mode in a years time
<Tleiades Hax>: though I have been thinking that the current inter region protocol is in efficient
<Wright Juran>: yeah, custom client ++. Think sooner or later someone will start work on one (even if we don't)
<Sakai openlifegrid>: I've opnly seen small hacks on the LL Client
<Neas Bade>: I've always been -- on custom client, as I think we gain a lot from compatibility :)
<Tleiades Hax>: ++ on sean's comment
<Tleiades Hax>: we live on the ll viewer
<Neas Bade>: at least until we're a bit further on the back end implementation
<Wright Juran>: Tleiades, I think all our inter-X protocols are inefficient, thats what I mean by thinking we need to do major work on the protocols
<Neas Bade>: that would be a good ML discussion
<Wright Juran>: yeah but there are a lot of things that the LL viewer is no right for, a lot of things don't need all the bloat in it for example
<Neas Bade>: silly flying people
<Nebadon Izumi>: hey tedd
<Neas Bade>: ah, it's tedd
<Neas Bade>: hey tedd
<Sakai openlifegrid>: is hipihi based on the LL client?
<Nebadon Izumi>: ted
<Nebadon Izumi>: carefull man
<Neas Bade>: hwo is the script engine coming?
<Nebadon Izumi>: your gonna crash the server
<Wright Juran>: so while yes I don't think we should stop being compatiable with the SL viewer, I do think having a custom client that uses the same protocol would be good
<Nebadon Izumi>: just leave it tedd
<Tedd Maa>: just checking ;)
<Nebadon Izumi>: not during meetings please
<Neas Bade>: yeh, we had one crash earlier, so trying to not upset things too much :)
<Tedd Maa>: server crashes when you move object?
<Tedd Maa>: hmm... I didn't know that :)
<Charles Krinkeb>: Tedd, sometimes.
<Nebadon Izumi>: ode collisons
<Wright Juran>: yeah Tedd, just get on with your excersises, if you come to gym class, you have to work
<Neas Bade>: hehehe
<Tedd Maa>: ok, so I admit it, I'm the master SL griefer
<Neas Bade>: so, Tedd, how goes the script engine work?
<Charles Krinkeb>: Ref: 333Mbyte, 67% CPU, 13 avatars
<Sakai openlifegrid>: ouch
<Nebadon Izumi>: nice charles
<Neas Bade>: sakai, remember, there is like 0 optimization yet
<Nebadon Izumi>: 67% seems high
<Charles Krinkeb>: I suspect the 67% has more to do with locks then anything else.
<Sakai openlifegrid>: yes it dows
<Sakai openlifegrid>: does
<Tedd Maa>: well, it kinda stopped last week again ... temporarily. The good news is that I'm able to participate on IRC and write some code now and then
<Nahona Nakamori>: mmm... about scripting... somebody heavy in lsl scripting already thinked to attempt to make a prims rezzer for LL grid using xml export from opensim? could be fun to can use opensim in sandbox for offline building...
<Tedd Maa>: as compared to a few weeks/a month ago when I only had time to do some scetch-book planning
<Sakai openlifegrid>: true
<Charles Krinkeb>: Nahona: Mantis feature request would be best for this, I believe.
<Neas Bade>: cool
<Sakai openlifegrid>: I know someone I can ask
<Neas Bade>: does anyone know how I can get mantis to send me email on changes to anything, like it says it is doing?
<Neas Bade>: but isn't
<Tedd Maa>: Current status is: I have implemented TCP server/client. I am designing a binary protocol and have sort of started implementing what I call the "Packet factory" (the class that makes the binary packets)
<lmmz> nice
<Tedd Maa>: I have created a separate stand-alone for script engine called script server and moved (copied) ScriptEngine to it.
<Neas Bade>: cool
<Wright Juran>: Neas, it used to send updates if a issue was assigned to you, but don't think it has done that for months now
<Tedd Maa>: But because ScriptEngine needs scene and the comm is not operational yet it will not compile
<Neas Bade>: any best guess on when it might go into tree?
<Tedd Maa>: in fact there are a lot of things that will not compile
<Tedd Maa>: its at least 2-3 weeks depending on my spare time
<Neas Bade>: Wright: that's sort of problematic
<Tedd Maa>: OpenSim has first priority on my spare time activites
<Neas Bade>: cfk, any chance you can beat up openmv folks on that front?
<Neas Bade>: cool :)
<Charles Krinkeb>: Huh? What front, sorry
<Neas Bade>: mantis not sending email
<Tedd Maa>: I have started talking to Babbage, he seems interested in the new Script Engine approach
<Charles Krinkeb>: Sure. CPrior is my contact, I will see what I can do
<Neas Bade>: nifty
<Tedd Maa>: he also says we should not attempt implementing microthreading
<Tedd Maa>: and I have been thinking a lot about it and I agree ... there are so many problems that we should not start it, it is just dead wrong from a design perspecitve
<Tleiades Hax>: Tedd.. I have a question, are you using interpreted code or CIL?
<danx0r> is my av still there? battery died
<Neas Bade>: that's definitely progress
<Wright Juran>: haven't they implemented microthreading in their mono implementation?
<Charles Krinkeb>: Cprior-gram sent re Mantis-non-mail.
<antont> danx0r: nope i dont see your avatar anymore
<Tedd Maa>: right now I am using C# for everything, I was using CIL on the LSL ByteCode
<Tleiades Hax>: well... two things
<Tedd Maa>: If I can speak on a purely personal level.. I think we'll find that LL will not implement C# ...
<Tleiades Hax>: 1) won't injecting thread.sleep and threadpools be just as good as microthreading?
<Neas Bade>: right, I think we'll still need the LSL implementation
<Tleiades Hax>: and .. what about security, CAS doesn't work on mono
<Neas Bade>: I think there was confusion over them adding Mono
<Neas Bade>: vs. C#
<Charles Krinkeb>: I might have to boogie, but will do the chat log onto the wiki later.
<Sakai openlifegrid>: Ciao Charles
<Tleiades Hax>: bye cfk
<Neas Bade>: Tedd, presumably the new script engine doesn't preclude using LSL like the current model?
<lmmz> cya
<Wright Juran>: yeah I'm going to have to go too, will stay logged in , but not really here
<Neas Bade>: later cfk
<Tedd Maa>: Answers: 1) Then we can not move running scripts between servers or pack them into inventory. BUT, with new ScriptServer we can at least have script moved between regions... then next problem is that you can only have a few hundred threads per operating system
<Tedd Maa>: or, per computer
<Charles Krinkeb>: 14 avs, 68% CPU, 340Mbyte
<Tedd Maa>: Security is a big problem... it is THE reason why I think we will not see C# and Mono in SL for a long time
<danx0r> why is it so hard to sandbox mono code?
<danx0r> isn't that the whole point of a managed bytecode?
<Tedd Maa>: The technical side with microthreading can be solved with a lot of work, although its one of those "its possible in theory but nobody would ever be so mad as to actually ytry it" implementations
<Tleiades Hax>: danx0r it gets jitted
<Tleiades Hax>: but what about mint?
<Tedd Maa>: It would be easier to implement a virtual machine with a minimal OS that can run Mono and run scripts inside it instead with 1 thread per OS
<danx0r> so tedd -- you have a thread for every script now? Doesn't LL do some sort of smart sleep() injection
<Tedd Maa>: *1 thread per script
<danx0r> ahh, frakkin JIT
<danx0r> well it must be hard, because Guido punted on it in Python, and he doesn't even use JIT
<danx0r> he just pulled the module and said you're all on your own, I absolve myself of any and all liability for security problems
<Tedd Maa>: one can in theory microthread Mono, and it might be that LL already has done that ... but the security aspect of it is just impossible
<antont> there are interesting microthread-like things for cpython though, like the greenlets(?) or something like that .. so i guess it is not all just theory?
<danx0r> 1 thread per script is not scalable, ne?
<danx0r> there's microthreads for python sorta, but I'm talking about trusted execution
<Tedd Maa>: no, 1 script per thread won't work... operating systems have a big overhead for each thread
<danx0r> I guess these issues intersect
<Sakai openlifegrid>: it's kill a bit of hardware
<danx0r> I remember something from LL about smart yield() injection
<Tedd Maa>: I'm thinking of looking into JavaScript
<Neas Bade>: I wonder how many mono threads you can have on linux before things get wonky
<danx0r> which is a form of microthreading, morally speaking
<Neas Bade>: tedd, do you have a good test case to test practical limits?
<Tedd Maa>: Babbage tested that, a few hundred on Linux and close to a hundred on Win
<antont> yah afaik the cpython greenlets etc yield. dunno if microthreading is interconnected with sandboxing or a separate issue
<Tedd Maa>: but Windows NT has something called "fibres", but I think maybe the app has to support it somehow
<Tleiades Hax>: threads have almost the same overhead as processes
<Neas Bade>: not on linux
<Tedd Maa>: I've been looking at yield, but I'm not sure if we should go down that path at all
<danx0r> yield() seems like the right thing
<danx0r> I did something on Python where I just inserted a yield after every line of code
<danx0r> wasn't scaled up, but it could have been I think
<antont> heh
<danx0r> the idea is to insert a yield anywhere you have a CPU capture
<Neas Bade>: yield actually causes some interesting issues with the os schedulars from my previous experience
<danx0r> it's part of the theory of continuations
<danx0r> neas -- it doesn't have to be an OS yield
<Neas Bade>: anyway, I've got to run to this wireless meeting
<Neas Bade>: see you all later
* antont notices his words are not relayed to wright plaza (danx0r's speech does show there)
<Neas Bade>: thanks for so many people showing u
<Neas Bade>: up
<danx0r> sorry I need to be more specific. Yield() in python is a python thing, it returns control to the VM
<Sakai openlifegrid>: Ciao Neas thanx
<lmmz> cya!
<Tedd Maa>: well, IF Linux can support say 500 threads ... this means we can have 500 scripts with loops in them. or we could have 499 scripts with loops and 10.000 scripts without loops
<danx0r> antont: that sucks -- wonder why
<Tedd Maa>: if you see my point
<Neas Bade>: well, that might be a fine place to start
<danx0r> so mono doesn't have a microthreading capability or python-like yield() next() ??
<Neas Bade>: its 500x better than where we are now :)
<Tedd Maa>: and with remote script server we can cluster multiple script servers to serve one region, meaning we can without any big problem run 10k's of scripts
<danx0r> if so that's too bad. I guess python is strictly runtime interpreted so it's easier
<Tedd Maa>: mono has yield(), but there are problems ...
<Neas Bade>: and 20x slower
* sdague goes poof
<--| sdague has left #opensim-osgrid (Client exiting)
<Tedd Maa>: 01 41 43 54 49 4F 4E 20 73 61 79 73 20 73 6F 6D .ACTION says som
<Tedd Maa>: wow
<Tedd Maa>: what happened there? :P
<Nebadon Izumi>: lol
* antont goes to eat
<Sakai openlifegrid>: Mono microthreading only works with the subset of CIL > assembler opcodes that the LSL to CIL compiler emits
<Tleiades Hax>: tedd.. wouldn't threadpooling work?
<Tedd Maa>: point is that there are a lot of small obstacles to overcome to implement Mono microthreading, some are of those that can be overcome, while others are not
<Blue Mouse>: couple questions about other topics???
<Tedd Maa>: "open up everything, allow anyone to run any .Net app on my computer. Now try to restrict the application." <- its just the wrong way to go
<Nebadon Izumi>: whats your questions blue?
<Blue Mouse>: what needs to be done to make animations work?
<Tedd Maa>: threadpooling can work to some degree now that we have script server as stand alone, but when its integrated into OpenSim its very dangerous
<Tleiades Hax>: why not have it as a standalone server?
<Sakai openlifegrid>: well that would def be a good point from a hardware pool side
<Tedd Maa>: it will be, but threadpool works as "if you are kind enough to lend me back my thread so I can continue execution"
<Gareth> ooh, Wright Plaza is back up?
<lmmz> Blue: the last thing I heard was that we need someone to make opensource versions of the LL animations? Is that wrong?
<Tedd Maa>: that is not so cool :)
<Nebadon Izumi>: yes gareth it was only down for about 1 minute
<Gareth> i picked the wrong minute
<Tleiades Hax>: which is where emitting thread.slepp(0) comes into play
<Blue Mouse>: there were a bunch of animations packaged with avimator
<Gareth> heh
<Nebadon Izumi>: ah thats not so hard
<Gareth> i'll hop on
<Tleiades Hax>: similar to the yield()
<lmmz> Blue: someone was looking into the "sit" today.
<Blue Mouse>: can't remember what the license was...
<Blue Mouse>: sit would be a good starting point
<Sakai openlifegrid>: yeah i've got afew bucket fulls of animations too
<Nebadon Izumi>: chillken was working on sit
<Tleiades Hax>: BSD license is important
<lmmz> I recall reading in backscroll on #opensim-dev that sit was being looked into.
<Nebadon Izumi>: yea lmmz it was chi11ken
<Sakai openlifegrid>: hehe irc delat
<Sakai openlifegrid>: delay
<lmmz> I dont know if the animations are part of the client or are downloaded from LL.
<Tedd Maa>: in initial implementation of script engine we will have thread based execution of scripts. It is not a 1:1 ratio between thread and script. If the script is not working then no thread is assigned to it.
<Nebadon Izumi>: they are an asset
<Nebadon Izumi>: i beleive
<Tedd Maa>: so if you have 10.000 scripts waiting for an event then no threads are in use.
<Nebadon Izumi>: not in client
<Blue Mouse>: asset yes, but i thought they were executed on the client
<lmmz> the client contains an xml file with keys to LL animations, but I imagine we dont want to use LL's animations. :)
<Blue Mouse>: haven't looked into it too deeply thought
<Blue Mouse>: are the animations on the client? can we just send the right keys?
<Blue Mouse>: isn't that how walk works now?
<Nebadon Izumi>: no
<Nebadon Izumi>: its a animation
<Nebadon Izumi>: an asset
<lmmz> I dont think they're on the client unless youve downloaded em from LL grid.
<Nebadon Izumi>: animations are not in the client
<Gareth Nelson>: where abouts are you all?
<Nebadon Izumi>: upstairs in the building Gareth
<lmmz> I've seen some custom animations play locally in OpenSim, but they dont play inworld, yet.
<Tleiades Hax>: upstairs
<Gareth Nelson>: this looks like a crazy cult meeting
<Tleiades Hax>: one more thing to put on the list :)
<Gareth Nelson>: it's like smith in the matrix, but ruth
<lmmz> hopefully, chillken (?) will make som eprogress on it, today. :)
<Blue Mouse>: correct... there are three animations in opensim right now... hard coded case statement for walk, fly and something else
<Blue Mouse>: ok
<lmmz> walk, fly and gym class?
<Blue Mouse>: something like stop flying but i can't remember
<Nebadon Izumi>: yea in the Data folder
<Nebadon Izumi>: there is an xml file
<Nebadon Izumi>: that defines the animations
<Nebadon Izumi>: and their asset UUID
<lmmz> Blue, chi11ken is probably the one to work with on animations.
<Blue Mouse>: will do
<Tleiades Hax>: great .. I'd love to see more animations
<Gareth Nelson>: are people seeing my shape changes?
<Tleiades Hax>: dsaf
<Tleiades Hax>: great .. I'd love to see more animations
<Sakai openlifegrid>: a busty woman?
<lmmz> Gareth, yes. Nice headlights.
<Nebadon Izumi>: rofl
<Nebadon Izumi>: i got a screenshot
<Nebadon Izumi>: thats going on the wiki
<Gareth Nelson>: my sexy av?
<Nebadon Izumi>: lol
<Sakai openlifegrid>: u can currently accept animations direct from avimator?
<Gareth Nelson>: amongst you mere mortal ruths
<Gareth Nelson>: why are animations hardcoded?
<Nebadon Izumi>: yea one problem is animations in your inventory
<Nebadon Izumi>: only you can see them
<Nebadon Izumi>: it doesnt animate to world
<Blue Mouse>: i can put animations in my library (from avimator)
<Blue Mouse>: i can even play them locally
<Blue Mouse>: can't play them in world though
<Nebadon Izumi>: yea only works locally
<lmmz> Sakai, I think so, yes. But without an asset system, they would not stay in inventory. And they only play locally.
<Nebadon Izumi>: yea
<Tleiades Hax>: assets isn't implemented fully and completely
<Sakai openlifegrid>: lol - so true
<Nebadon Izumi>: yea that should be done 1st
<Nebadon Izumi>: before doing to much with animations
<Sakai openlifegrid>: I think I'll contact ch11ken then I have a ton he can have straight up
<Tleiades Hax>: first the infrastructure for assets and inventory needs to be set up
<lmmz> Sakai, nice.
<Sakai openlifegrid>: my borther has made 100's for SL
<Nebadon Izumi>: but you should talk with him
<Nebadon Izumi>: as assets is not far off
<Nebadon Izumi>: few weeks
<Sakai openlifegrid>: well that's exciting
<lmmz> I suppose we get to decide how assets are persisted between grids, after that. :)
<Blue Mouse>: speaking of assets... any idea when i can put textures in a prim? (looking to build a projector for biz meetings)
<Gareth Nelson>: the viewer fetches assets over HTTP now - does anyone know how to provide them?
<Tedd Maa>: ok, I'll be on IRC .. need to do some more work :)
<lmmz> Cya, tedd!
<Tedd Maa>: you all have a nice workout
<Sakai openlifegrid>: yes persistent between grids would be impressive but could really dig the bandwidth
<Sakai openlifegrid>: Gareth going for hot nurse?
<Tleiades Hax>: well, I have been thinking about writing a client side asset and inventory storage engine
<Tleiades Hax>: that way, the inventory and assets could follow the user between grids
<Sakai openlifegrid>: but
<lmmz> I Gotta run! Great meeting! The IRC bridge is the shiz!
<Sakai openlifegrid>: how would you get around duplicate asset entries?
<Tleiades Hax>: I wouldn't and I wouldn't care, as long as they have the same I'd :-)
<Sakai openlifegrid>: hehe
<Stefan Andersson>: I'd suggest we look into URI instead of LLUUID for resources
<Gareth Nelson>: i now pwn all you ruths!
<Nebadon Izumi>: lol
<Gareth Nelson>: so..... HTTP textures at the very least works direct to viewer
<Gareth Nelson>: anyone know the details on that?
<Gareth Nelson>: and can the sim FORCE the viewer to take them?
<Sakai openlifegrid>: well that would be aboon
<Tleiades Hax>: Stefan .. that is the obvious choice.. but it won't fit with the viewer
<Tleiades Hax>: but ...
<Tleiades Hax>: Stefan .. that is the obvious choice.. but it won't fit with the viewer
<Tleiades Hax>: I have been thinking
<Tleiades Hax>: since the asset server will be rest
<Stefan Andersson>: No, but rather than rewriting a whole client-side asset system, I'd say the effort would be better spent trying to hax URI
<Tleiades Hax>: and lsl supports http
<Tleiades Hax>: we could implement some extensions
<Sakai openlifegrid>: this may be easier
<Tleiades Hax>: which could be accessed using lsl
<Tleiades Hax>: url's for assets really is the obvious choice
<Tleiades Hax>: we know the internet is a scalable storage device :)
<Sakai openlifegrid>: most certainly...
<Sakai openlifegrid>: could you possiblly translate a uuid to a url and pass it through
<Sakai openlifegrid>: ?
<Stefan Andersson>: I'm pretty sure it would be possible to create a asset guid-to-uri conversion scheme.
<Tleiades Hax>: now if only we could get some people who understood grid computing to look at simulator code
<Tleiades Hax>: yes
<antont> there are already uuid uris
<Tleiades Hax>: and the mapping could be tweaked by lsl using a rest interface
<Testc User>: there are existing uuid uri schemes (well i know one)
<Stefan Andersson>: Also, you have this thing with the assets going thru the simulator, which is authenticated
<Tleiades Hax>: I'm not too hot on the concept of "authenticated users" for the final release
<Stefan Andersson>: If every object had a 'namespace' uri attached to it, you'd just attech the asset guid to that
<Sakai openlifegrid>: rfc4122
<Sakai openlifegrid>: (uuid to uri)
<Gareth Nelson>: The concept of authenticated users is a must Tleiades: i am hot on the idea of authenticating users or allowing guests
<Gareth Nelson>: i'm VERY hot on guests
<Tleiades Hax>: I think the HTTP approach is better
<Gareth Nelson>: i'm also hotter than all of you!
<Tleiades Hax>: lols
<Gareth Nelson>: Tleiades: were you referring to authenticating users for asset downloading?
<Gareth Nelson>: or for login and authentication against a DB for standalone mode?
<Tleiades Hax>: yes, and accessing regions
<Blue Mouse>: if the client grabs the asset using a URL and HTTP then authentication could bypass the simulator altogether
<Tleiades Hax>: anonymous access is important I think
<Gareth> heh, you can't see it but my avatar there is the sexiest one
<Blue Mouse>: that could be good (simulator doesn't have to proxy client credentials)
<lbsa71> Well, if we wanted distributed assets, we could do them quite easy today, I guess;
<Blue Mouse>: and bad (what if you aren't allowed to get an asset you need)
<Gareth Nelson>: authentication for assets should be done using either CAPs direct to viewer or proxied via the sim
<Tleiades Hax>: I worry about the asset server
<Tleiades Hax>: I don't think a single central asset server is going to cut it
<Nahona Nakamori>: are you sure Gareth?
<Nahona Nakamori>: lol
<Gareth Nelson>: question - why not do it the way it's being proposed on the SL wiki for the AW Groupies?
<lbsa71> If all users had an 'home root url' then all assets could be funneled to that.
<Gareth Nelson>: in fact, are any other groupies here?
<Stefan Andersson>: Ok, gotta go.
<Tleiades Hax>: I gave up on the AWG
<Stefan Andersson>: Cheers
<Gareth Nelson>: ok, Nahona has a mildly better face....
<Gareth Nelson>: Tleiades: the AWG is getting too beuracratic for my liking
|<-- lbsa71 has left efnet ()
<Sakai openlifegrid>: i would agree on the single asset server
<Nahona Nakamori>: Nahona uploaded her personal realistic skin *lol*
<Tleiades Hax>: yeah .. should get coding on the rest client
<Gareth Nelson>: but some good ideas have been generated
<Gareth Nelson>: i'll discuss the details on IRC rather than here (laggy as a laggy lagfest)
<Tleiades Hax>: yes.. I just think that most of the talk was too high level, and of very little practical use
<Sakai openlifegrid>: I have to say thank you to everyone for your warm welcome
<Sakai openlifegrid>: I must sleep
<Tleiades Hax>: and opensim is very much about pratical approaches
<Gareth Nelson>: but basically the agent domain stores all an agent's belongings, region domain stores all the rez'ed objects
<Gareth Nelson>: Tleiades: agile :)
<Gareth Nelson>: and inventory can come from an aggreator
<Nahona Nakamori>: night Sakai
<Tleiades Hax>: nite
<Sakai openlifegrid>: nite
<Gareth Nelson>: at login the user gets a big list of inventory sources, every asset is a link to where the asset can be downloaded
<Tleiades Hax>: Gareth .. we have to live with the viewer .. as it is today
<Tleiades Hax>: but I think cap's can be used to distribute load
<Gareth Nelson>: hmm yeah - not an option to alter anything viewer side in opensim
<Gareth Nelson>: the sim can still act as a proxy and do most of the new architecture though
<Tleiades Hax>: yes.. that is my thinking
<Tleiades Hax>: my thinking is like this
<Gareth Nelson>: brb - keep talking
<Gareth Nelson>: and stop staring at my breasts Nahona ;)
<Tleiades Hax>: the viewer is directed to the url of the assets
<Rookiie Roux>: lol
<Nahona Nakamori>: arf
<Rookiie Roux>: gareth
<Tleiades Hax>: and is basically told to look at 127.0.0.1
<Tleiades Hax>: where we have a client side component, transfer the asset
<Blue Mouse>: umm... how about just running a sim on every client that represents "home" territory
<Blue Mouse>: then proxy other requests through that sim
<Tleiades Hax>: if the asset isn't found at the clientside asset server, the client side asset server goes to the network at dl it
<Nahona Nakamori>: not my fault Gareth if all ruth breasts are not so much hot *lol*
<Nebadon Izumi>: lol
<Tedd> I'm kinda glad animations haven't been implemented yet or you'd be having an orgie right about now
<Tedd> but hey, words can be just as exciting, right? ;)
<Tleiades Hax>: does anybody have the full log of the meeting?
<Nebadon Izumi>: IRC does
<Tedd> I came late, but I do log
<Nebadon Izumi>: we can remove all the nonsense