Content Creation/Scripting User Group/Transcripts/2012 01 09

List of Speakers

Faust Vollmar

Leonel Iceghost

Liisa Runo

Vincent Nacon

Transcript

[09:00] Leonel Iceghost: its all Kelly's fault

[09:00] tehKellz (kelly.linden): always

[09:00] Kaluura (kaluura.boa): Here comes the messiah! :P

[09:00] Leonel Iceghost: hey Kelly

[09:00] Vincent Nacon: hardly messiah...

[09:00] tehKellz (kelly.linden): I think I like Leonel's better

[09:01] Vincent Nacon: :P

[09:01] Leonel Iceghost: they are saying that it is all your fault

[09:01] Vincent Nacon: he's too boney for that

[09:01] Kallista Arliss (kallista.destiny): Ave Kelly

[09:01] tehKellz (kelly.linden): I hope everyone has had a good weekend, and a good new year if I didn't see you at any of the other groups last week.

[09:02] Vincent Nacon: yeah, you saw most of us from friday anyway

[09:02] Vincent Nacon: :P

[09:02] Kaluura (kaluura.boa): We're all UG addicts...

[09:02] Vincent Nacon: UG?

[09:02] Kaluura (kaluura.boa): User Group...

[09:02] Kaluura (kaluura.boa): The new name or OH

[09:03] Kaluura (kaluura.boa): for*

[09:03] Leonel Iceghost: we are addict to a break from our real jobs

[09:03] Vincent Nacon: oh ok, scared me into thinking you meant "underground"

[09:03] tehKellz (kelly.linden): :)

[09:03] Vincent Nacon: not that it's implied

[09:03] tehKellz (kelly.linden): Lets see what I have on the news front.

[09:04] Vincent Nacon: I suspects news on Falcon's progress

[09:04] tehKellz (kelly.linden): We should get the new server-maintenance up on RC this week. For scripting this means llSetRegionPos and "region_idle" for llGetEnv and some llSetKeyframedMotion bug fixes

[09:05] Kaluura (kaluura.boa): Region_idle?

[09:05] Nal (nalates.urriah): ?

[09:05] Kaluura (kaluura.boa): Never heard of this one!

[09:05] tehKellz (kelly.linden): typo

[09:05] tehKellz (kelly.linden): "frame_number"

[09:05] tehKellz (kelly.linden): sorry

[09:05] Vincent Nacon: that's a big typo

[09:05] tehKellz (kelly.linden): haha

[09:05] Kaluura (kaluura.boa): Yeah! hehehe

[09:05] Jonathan (jonathan.yap): region_idle = false

[09:06] Ã„lveKatt (davido.chrome): And that's that?

[09:06] Kaluura (kaluura.boa): No PRIM_POS_REGION?

[09:06] Vincent Nacon: what for?

[09:06] tehKellz (kelly.linden): Sorry I was thinking about sim stats. There is a back-end feature in this release that relates to scripting but will require new viewers to see - I've added

[09:07] tehKellz (kelly.linden): I've added a % scripts run stat

[09:07] Kaluura (kaluura.boa): To do the same thing that llSetRegionPos() but with llSLPPF()

[09:07] tehKellz (kelly.linden): There is no PRIM_POS_REGION at this time.

[09:07] Vincent Nacon: gotch ya.... you can't use it in linkset

[09:08] Kaluura (kaluura.boa): Yes, you can... llSLPPF(LINK_THIS or LINK_ROOT...

[09:08] Nal (nalates.urriah): Kekkz, which viweer would we see it in?

[09:08] Jonathan (jonathan.yap): This was discussed at Andrew's meeting -- there is a good reason for not being able to pack too much into 1 call

[09:08] Kaluura (kaluura.boa): Well, you could.

[09:08] Vincent Nacon: well... hmm

[09:08] Nal (nalates.urriah): Kellz^ sorry

[09:08] Kallista Arliss (kallista.destiny): Could you pass me the change to the stats structure so I can pass it on to the firestorm devs.

[09:08] tehKellz (kelly.linden): Nal, none yet. It hasn't made it through the pipeline yet.

[09:08] Leonel Iceghost: ROOT_REGION_POS? would take any link number

[09:08] Liisa Runo: what is the good reason?

[09:08] Nal (nalates.urriah): k

[09:08] Vincent Nacon: could but might be problematic before it can be safely avoid the call

[09:09] Vincent Nacon: if otherwise

[09:09] Vincent Nacon: wait... nevermind... carry on

[09:09] Kallista Arliss (kallista.destiny): The more you put into a call the longer it takes...

[09:10] tehKellz (kelly.linden): Kallista: New stat number 35 is the average % of scripts run during a frame. 100% means that all scripts are getting a chance to run every frame, and less than that means that fewer scripts are.

[09:10] Kallista Arliss (kallista.destiny): Thanks.

[09:11] Ã„lveKatt (davido.chrome): The compiler removes all the things that makes it readable anyway? So putting a separate llSetRP wouldn't be any difference?

[09:11] Jonathan (jonathan.yap): Kelly, will you write a little note about this on opensource-dev, so people can make necessary changes?

[09:11] Faust Vollmar: A curious drop point you chose there Kelly. =p

[09:11] tehKellz (kelly.linden): We can not split up an llSPPF call across multiple frames, so if you do enough to use up more than the time slice (which isn't that hard) then you can impact performance perhaps significantly. This is something we need to addres really but have not.

[09:11] Faust Vollmar: Can someone IM me what I've missed?

[09:11] Vincent Nacon: figured

[09:12] Ã„lveKatt (davido.chrome): Has someone ever compiled a wiki page with tips and tricks of optimizing scripts?

[09:12] Kaluura (kaluura.boa): Hmmm... PRIM_LINK_TARGET should be use very cautiously then...

[09:12] Kaluura (kaluura.boa): used*

[09:13] tehKellz (kelly.linden): Yes, it should.

[09:13] Liisa Runo: just like walking agents, should not walk too much, better to ride NPV :P

[09:13] Faust Vollmar: Thanks, got the backlog now

[09:13] tehKellz (kelly.linden): Especially since changing child prim positions or shapes are some of the most expensive things LSL can do.

[09:13] Ã„lveKatt (davido.chrome): Hum, mind if a rez something?

[09:13] Kaluura (kaluura.boa): I've optimlized a few scripts to use only 1 llSLPPF() call instead of several... Hmmm... Maybe I should undo it...

[09:14] Vincent Nacon: naa just wait bit longer

[09:14] Ã„lveKatt (davido.chrome): Kaluura; http://lslwiki.net/lslwiki/wakka.php?wakka=boolean

[09:14] Vincent Nacon: ;)

[09:14] tehKellz (kelly.linden): It is a balancing act, fewer calls is a bit better for the individual script but reduces the simulator's ability to manage script times.

[09:15] Ã„lveKatt (davido.chrome): I think nesting a lot is one way. As the number of possible results for many integers rise exponentially with every new individual integer.

[09:15] tehKellz (kelly.linden): In this specific case setting the region wide position for the entire object is a significant act that we don't really want happening dozens of times in a single call. The way updates are applied it is actually difficult to reduce it down to the single effective action

[09:15] Tiger (levio.serenity): yea i just redid all the meeroo animations to pack everytyhing into a single call every chance it could

[09:16] Ã„lveKatt (davido.chrome): Am I off topic?

[09:16] tehKellz (kelly.linden): IF we were to add an llSPPF constant for it, we would probably need to add extra restrictions - like failing the call if used twice.

[09:16] Vincent Nacon: naa David, you just blew their mind

[09:17] Kaluura (kaluura.boa): No problem with me... It would be stupid to do several region pos in one line...

[09:17] Kallista Arliss (kallista.destiny): so the llSPPF can't be "interrupted"?

[09:17] Faust Vollmar: I cant see a legitimate use for regionpos being used more than once in a single frame like that

[09:17] Liisa Runo: most of the people who i have been talking to, have said that they will not edit theri scripts to use llSetRegionPos, but instead they are waiting for the llSPPF call

[09:18] tehKellz (kelly.linden): Liisa: that is their choice. No such functionality has been promised though.

[09:18] Vincent Nacon: oh there are few, Fasut

[09:18] Vincent Nacon: Faust*

[09:18] Jonathan (jonathan.yap): Why would they wait?

[09:18] Vincent Nacon: weapons jumping across the grids

[09:18] Liisa Runo: to sync the movement with rotation, for example

[09:18] tehKellz (kelly.linden): Kallista: Correctish. We can interrupt it and stop processing any more rules - ie break out of it. We can't currently continue where we left off.

[09:19] Kallista Arliss (kallista.destiny): nods

[09:19] Kallista Arliss (kallista.destiny): Stop != interrupt

[09:19] tehKellz (kelly.linden): If you need to sync movement with rotation to the point that a single frame matters - do you really need the region-wide position set?

[09:19] Faust Vollmar: It's just OCDin

[09:20] Vincent Nacon: maybe for some fast bullets

[09:20] Vincent Nacon: muhaha!

[09:20] Liisa Runo: it is either that, one 5 lines of code to determine if we need to use long range or short range movement

[09:20] Liisa Runo: or 5lines *

[09:20] Leonel Iceghost: say you teleport, you don't want to see you moving and rotating in different frames

[09:20] tehKellz (kelly.linden): Do the current hacks that llSetRegionPos replaces work inside lists of other changes in llSPPF?

[09:20] Kaluura (kaluura.boa): Exactly...

[09:20] Ã„lveKatt (davido.chrome): Doesn't llSetRegioPos bypass the place inbewteen?

[09:20] Faust Vollmar: Yep they do

[09:20] tehKellz (kelly.linden): Alve: it does.

[09:21] Liisa Runo: also posJump ignore the space inbetween, but LL broke it

[09:21] Faust Vollmar: WarpPos however strains memory pretty hard so not sure exactly how much more you can do in a single call

[09:21] Ã„lveKatt (davido.chrome): Then I can only see it as a viable weapon in Space opera sims where they have hyperspace mines and stuff.

[09:21] Vincent Nacon: broke? more like fixed!

[09:21] Vincent Nacon: muhaha!

[09:21] Kaluura (kaluura.boa): WarpPos is obsolete... JumpPos replaced it.

[09:22] Faust Vollmar: I stuck to Warp because of how often Jump's cornerstone bug was fixed and reverted.

[09:22] Faust Vollmar: Figured I could just wait for the official

[09:23] Ã„lveKatt (davido.chrome): Can llTargetOmega be used in llSetLinkPrimFast?

[09:23] tehKellz (kelly.linden): Alve: PRIM_OMEGA

[09:23] Faust Vollmar: Ah yeah, a -reason- for failure would be nice.

[09:24] Jonathan (jonathan.yap): Some failures are permanent, others are more transitory

[09:24] tehKellz (kelly.linden): Sorry, it is only success or failure.

[09:24] tehKellz (kelly.linden): What failures are transitory?

[09:24] Ã„lveKatt (davido.chrome): Nice. Would it be better to take the wheel spin scripts out of the tires and put PRIM_OMEGA in the main script instead?

[09:24] Jonathan (jonathan.yap): Failure to cross into a new region

[09:24] Jonathan (jonathan.yap): Less likely: failure to enter a parcel

[09:24] tehKellz (kelly.linden): Alve: yes

[09:25] Ã„lveKatt (davido.chrome): Thanks!

[09:25] tehKellz (kelly.linden): All right so next on news

[09:26] Vincent Nacon: oy... kept more news from us, eh?

[09:26] tehKellz (kelly.linden): We are always building the next sever maint project, even as one enters QA. I do have something from the one coming up after the one going to RC tomorrow that I'd like to share.

[09:27] Nal (nalates.urriah): :)

[09:27] tehKellz (kelly.linden): I went though some of the more expensive list and string operation library calls to improve their performance for mono scripts.

[09:27] Kaluura (kaluura.boa): Wow!!!

[09:27] Liisa Runo: yay

[09:27] Faust Vollmar: <3 (Platonic ofcourse)

[09:27] tehKellz (kelly.linden): Specifically: llList2List, llDeleteSubList, llGetListEntryType, llListInsertList, llListFindList, llDumpList2String, llListReplaceList

[09:27] tehKellz (kelly.linden): And llVecMag, llVecNorm, llVecDist, llDeleteSubString, llStringLength, llInsertString, llSubStringIndex

[09:27] Tiger (levio.serenity): sweet

[09:27] Vincent Nacon: sounds like a fun job there, Kelly

[09:28] tehKellz (kelly.linden): Most are at least 2x faster, except llDumpList2String which isn't much faster at all - maybe 40%.

[09:28] Jonathan (jonathan.yap): What amount of improvement were you able to wring out of them?

[09:28] Kallista Arliss (kallista.destiny): I'm impressed

[09:28] tehKellz (kelly.linden): The biggest wins are llList2List at ~100x better, llGetListEntryType at ~150x

[09:28] Jonathan (jonathan.yap): !

[09:28] Leonel Iceghost: sdlkjafl

[09:29] Faust Vollmar: Wow. Gonna have to get ready to replace some llGetSubString with llDeleteSubString ins a number of places.... And holy hell on that List2List

[09:29] tehKellz (kelly.linden): llDeleteSubString is about 20x, llStringLength ~50x

[09:29] Ã„lveKatt (davido.chrome): I think some heads exploded...

[09:29] Liisa Runo: sounds good, next the complex string operations to the tuning table?

[09:29] FooBar (data.landau): nice

[09:29] tehKellz (kelly.linden): llInsertString ~20x

[09:29] Kaluura (kaluura.boa): My head exploded...

[09:29] tehKellz (kelly.linden): llDeleteSubList also about 20x

[09:29] Jonathan (jonathan.yap): Kelly, could you publish this data somewhere?

[09:30] tehKellz (kelly.linden): For most of these the performance improvement is more significant the larger the list or string being worked on?

[09:30] Vincent Nacon: not really surprised by the speed since Mono is mostly made up of those speed anyway.. just some minor polishing

[09:30] tehKellz (kelly.linden): er no ? needed.

[09:30] Faust Vollmar: Considering noone has even posted Kelly's transcripts since last April... I figured all this stuff was a "if you arent here to see it, you miss it."

[09:30] Faust Vollmar: =p

[09:30] Ã„lveKatt (davido.chrome): Honestly, could we get a wikipage that is all about optimizing? Saying things like "this solution is better than this solution" and stuff like that?

[09:30] Leonel Iceghost: are you compiling to more direct arrays?

[09:30] Vincent Nacon: I think we do have a page about that

[09:30] Vincent Nacon: maybe not with Mono counterpart

[09:31] Faust Vollmar: Yeah the page is all old LSO stuff

[09:31] tehKellz (kelly.linden): Alve: there have been some, I'm not quite yet to open discussion.

[09:31] Ã„lveKatt (davido.chrome): Do you mean about that topic or that we are still on the news part of the meeting?

[09:32] tehKellz (kelly.linden): still in the news part.

[09:32] Ã„lveKatt (davido.chrome): Aah.

[09:32] Ã„lveKatt (davido.chrome): Sorry

[09:32] Ã„lveKatt (davido.chrome): First time here.

[09:32] Vincent Nacon: np

[09:32] tehKellz (kelly.linden): For these numbers I was counting number of calls I could do in 5 seconds on two dataset sizes 100 chars or list items and 1000 chars or list items and averaged the two.

[09:33] Leonel Iceghost: when lists grow they seem to become really slow, is it still true?

[09:33] tehKellz (kelly.linden): I was happy with the results.

[09:33] tehKellz (kelly.linden): Leonel: for these functions now it is much less true.

[09:34] tehKellz (kelly.linden): Or will be when this is released.

[09:34] Jonathan (jonathan.yap): Kelly, do you have a "busy" test region you can try these changes on, to see how much overall performance is affected?

[09:34] Faust Vollmar: Somewhat surprised theres no change on the llList2 set at all.

[09:34] tehKellz (kelly.linden): Even when I have a busy region to test it rarely matches the load characteristics of a region actually in use.

[09:35] tehKellz (kelly.linden): The llList2 set is alreayd optimized.

[09:35] Jonathan (jonathan.yap): Too bad you do not have some way to record and playback data from a "in use" region

[09:36] tehKellz (kelly.linden): We have in the past tried products that promise such features at the network level. They have historically been unable to cope with our data set.

[09:37] tehKellz (kelly.linden): Okay, that is all the news I have. The currently outstanding topic is a community effort to document script optimizations.

[09:37] tehKellz (kelly.linden): I know there have been efforts for this in the past, but I'd believe they are out dated.

[09:38] tehKellz (kelly.linden): And many (<cough>strife</cough>) sacrifice readability so much many probably end up writing worse scripts trying to use the optimizations.

[09:38] Nal (nalates.urriah): Its kinda nice that LL is fixing and improving things so fast the docs can't keep up.

[09:38] Kaluura (kaluura.boa): I prefer readability to 2ms optimizations...

[09:39] tehKellz (kelly.linden): If anyone wants to start a page, gather some tricks, I'd be happy to comment and edit and discuss at one of these meetings.

[09:39] Ã„lveKatt (davido.chrome): I would love such information. Wouldn't it be in LL interest to actually do such a project themselves? Lag is a big issue that i think turn new users away.

[09:39] Leonel Iceghost: those 2ms optimizations should be kept for those that make automated preprocesors

[09:39] Kallista Arliss (kallista.destiny): The junction set of people who write good clean code and the set of people who write good clear English is NULL

[09:39] tehKellz (kelly.linden): There are relatively few things scripts can do that will cause sim lag. Most of what scripts do will only effect script performance.

[09:39] Nal (nalates.urriah): ?

[09:40] Tiger (levio.serenity): finally a linden i can quote saying that, cuz noone believes me when i say it

[09:40] Kaluura (kaluura.boa): I'm adding this in quotes ofthe century...

[09:40] tehKellz (kelly.linden): The exceptions being llSPPF and rezing objects - mostly. There are exceptions.

[09:40] Ã„lveKatt (davido.chrome): But, from a user viewpoint, a badly Ã¥performing vehicle script is the same thing as sim lag.

[09:41] tehKellz (kelly.linden): Essentially the lag comes from what the script causes the simulator to do, not from running the script itself.

[09:41] Leonel Iceghost: also any shape change lags the physics

[09:41] tehKellz (kelly.linden): Optimizing your list initialization isn't going to effect the sim's lag.

[09:41] Ã„lveKatt (davido.chrome): Does this include ojects that are phantom?`Or completely inclosed in a collision prim?

[09:42] Leonel Iceghost: phantom shape doesn't matter

[09:42] Kallista Arliss (kallista.destiny): It's so hard to convince people of that (scripts qua scripts, don't cause lag)

[09:43] tehKellz (kelly.linden): It all boils down to what the script causes the sim to do. If the script causes computationally expensive things then it will cause sim lag. In fact if you optimize the rest of your script to be super fast it is possible you could be calling 'expensive' functions quicker or more frequently and cause more lag! (though I expect that would be very rare)

[09:43] Leonel Iceghost: but they do, you have to see people playing something in a sim without scripts, and a sim with scripts and they naturally start to shout "LAAAGGGG"

[09:44] Faust Vollmar: The physics stuff is why I moved toward being one of the people pushing llCastRay for certain things, heh.

[09:44] Faust Vollmar: shame about that accounting bug right now though

[09:45] Kaluura (kaluura.boa): Yeah... And its inability to cross border...

[09:45] Ã„lveKatt (davido.chrome): Ok, so things like Vendors don't really cause any lag at all?

[09:46] Leonel Iceghost: they cause a lot of lag

[09:46] Liisa Runo: vendors can cause lag, especially if they do rapid off-world communications

[09:46] Faust Vollmar: I dont think it would even be possible for llCastRay to cross borders without handing off a request to the target sim, which becomes a resource accounting nightmare.

[09:46] Kallista Arliss (kallista.destiny): Oh vendors, not likley. Now the fact that vendors tend to be very texture rich,and change textures a lot... now that can cause viewers to bogg down.

[09:47] Ã„lveKatt (davido.chrome): Why the semantic distinction that it isn'y scripts that cause lag, it's the calls they do?

[09:47] Leonel Iceghost: vendors cause lag even if you are in a skybox 3000 meters away

[09:47] Tiger (levio.serenity): speaking of vendors, any chance of ever seeing a llTransferInventory() function with getting an event back with the results along the lines of llTransferLindenDollars() with the event of the direct delivery project?

[09:48] Kallista Arliss (kallista.destiny): There are some script events that can cause lag.. Creating objects and making objects move are the biggies

[09:48] tehKellz (kelly.linden): I'm sure there is some chance Tiger. But not near term. llTransferLindenDollars was made possible by some back end changes. Until a similar thing happens to the back end of inventory transfers we won't be seeing llTransferInventory.

[09:49] Kaluura (kaluura.boa): We holding our breath... :P

[09:49] Ã„lveKatt (davido.chrome): Doesn't all lines in a script call for a computation?

[09:50] tehKellz (kelly.linden): Alve: if you have a script that just sits there computing all the digits of PI it won't lag the sim. In fact you should be able to have hundreds of those without lagging anything except maybe how fast other scripts run. But if you have a single script constantly rezzing bullets you can effect the overall simulator's performance.

[09:50] tehKellz (kelly.linden): Effecting the general simulation causes the simulator to do work outside of the script's time box, which is how general lag can be caused.

[09:50] Jonathan (jonathan.yap): Alive, the sim schedules scripts to run, it's when other parts of the simulator code are activated that you might get lag

[09:51] Ã„lveKatt (davido.chrome): Ah. So LLtargetOmega for instance, isn't that calculated viewerside?

[09:51] Tiger (levio.serenity): well if you could put the idea in the heads of whoever is doing the backend changes for direct delivery, perhaps they can sneak it in

[09:51] Leonel Iceghost: can vendor's textures traffic to other viewers lag you even if you are 3000 meters away?

[09:51] tehKellz (kelly.linden): Correct, target omega is a paramer on a box (like it's name or description) and the effect is viewer side.

[09:51] tehKellz (kelly.linden): Leonel: I'm not up to date on the viewer's handling of texture requests.

[09:52] Kaluura (kaluura.boa): The distance doesn't matter if you're in the same sim...

[09:52] Jonathan (jonathan.yap): the sim has to fetch and send textures to agents wanting to see them, but I don't see how a vendor's operations are any different than an avatar walking around seeing new things

[09:52] Leonel Iceghost: yes Kaluura but maybe there is plenty of traffic to use, and it won't lag

[09:52] tehKellz (kelly.linden): Tiger: When direct delivery is complete (and probably after it has been out for a while so the bugs have been found/fixed) then we may revisit the llTransferInventory feature to see how or what is possible.

[09:53] Ã„lveKatt (davido.chrome): Would that mean that if I make a mesh wheel and then have a not round collision box, with mor detail on the underside, I would get a less laggy bike because it's ground contacts have a les complex surface shape, all the while the wheels spin using llTargetOmega?

[09:53] Tiger (levio.serenity): also on my vendors i would love to be able to view/set the default left click action from a script

[09:53] tehKellz (kelly.linden): Alve: Yes.

[09:53] Jonathan (jonathan.yap): Kelly, it was announced publically on Friday roughly when DD is going to be released

[09:53] Jonathan (jonathan.yap): "not before St. Valentine's Day"

[09:53] tehKellz (kelly.linden): Jonathan: oh, cool. I didn't see that.

[09:53] Nal (nalates.urriah): Do the built-in AO in viewers reduce lag by unlosing scripts or does the viewer to server communication for animation runing cause ore Lag?

[09:54] Leonel Iceghost: you can do that already Tiger

[09:54] Nal (nalates.urriah): unlosing=unloading

[09:54] Ã„lveKatt (davido.chrome): I.e., the collision box won't spin. ?

[09:54] tehKellz (kelly.linden): I have not inspected the various viewer-side AO implementations Nal. I can imagine ways they could be better and ways they could be worse. Though probably they are better than the LSL based solutions.

[09:54] Ã„lveKatt (davido.chrome): Just making sure I understand you correctly.

[09:54] Nal (nalates.urriah): thx

[09:55] Liisa Runo: you are correct Davido

[09:55] Kaluura (kaluura.boa): The collision box of objects only rotates if they are physical

[09:55] Kaluura (kaluura.boa): (That was for Alve)

[09:56] Liisa Runo: ... but BB does not rotate if the rotating prim is a child on a physical linkset

[09:56] Martin RJ (martinrj.fayray): DD?

[09:56] Jonathan (jonathan.yap): DD=Direct Delivery

[09:56] Liisa Runo: or DrawDistance

[09:56] Liisa Runo: :P

[09:56] Martin RJ (martinrj.fayray): ty

[09:58] Vincent Nacon: as for AO in TPVs they're all shared the same library source

[09:58] Kaluura (kaluura.boa): Talking about AOs, there was discussions a long time ago about functions to simply replace the default anims...

[09:58] Leonel Iceghost: do you like Kelly the future of LSL? or do you think you have to take LSO off in orther to improve

[09:58] tehKellz (kelly.linden): That is an interesting idea Leonel.

[09:59] Martin RJ (martinrj.fayray): just found the Direct Delivery FAQ: http://goo.gl/ahsal

[09:59] Faust Vollmar: I think its been said before that LSO holds -alot- back.

[09:59] Vincent Nacon: LSO should be illegal by now

[09:59] Vincent Nacon: muhaha!

[09:59] tehKellz (kelly.linden): It does, but it is probably a topic that deservs more than the 30 seconds left in this meeting.

[09:59] Kaluura (kaluura.boa): LSO will be killed eventually, some day... We can't keep the compatibilty ball-and-chain forever....

[10:00] Leonel Iceghost: maybe we should create a movement to take LSO down once for all

[10:00] Vincent Nacon: yeah, too many outdated scripts all over the SL

[10:00] Leonel Iceghost: so new features can be created for MONO

[10:00] Jonathan (jonathan.yap): One thing you could do is force all scripts to be saved as LSL

[10:00] Ã„lveKatt (davido.chrome): Isn't it better to pull tghe plug as soon as possible?

[10:00] tehKellz (kelly.linden): All right meeting is over! I have another I must jump to.

[10:00] Jonathan (jonathan.yap): *MONO

[10:01] Ã„lveKatt (davido.chrome): The longer you wait, the more content you're gonna break.

[10:01] Vincent Nacon: yup take care

[10:01] Jonathan (jonathan.yap): Thanks Kelly

[10:01] tehKellz (kelly.linden): Thank you everyone. Great discussion today.

[10:01] Leonel Iceghost: bye Kelly, thanks a lot

[10:01] Faust Vollmar: Most people have a thing in thier head about the whole Mono Bug thing

[10:01] Liisa Runo: thanks everyone

[10:01] Vincent Nacon: gonna need more coffee for Mesh's meeting

[10:01] Ã„lveKatt (davido.chrome): Thanks Kelly!

[10:01] Kaluura (kaluura.boa): TC

[10:01] Faust Vollmar: That conception isnt going away

[10:01] Mumbles (charlar.linden): vincent, me too

Content Creation/Scripting User Group/Transcripts/2012 01 09

List of Speakers

Transcript

Navigation menu

Search