User:Ama Omega/archive/Office Hours/2010-10-25

From Second Life Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

List of Attendees

Transcript

[09:00] Kelly Linden: Hello
[09:01] JayR Cela: hi there Kelly :_)
[09:01] Hank Sopwith: Hi Kelly
[09:01] Meeting Calculator: Meeting over. This meeting cost roughly $17384.620000
[09:02] Kelly Linden: give it a couple more minutes for people to show up.
[09:02] Kelly Linden: Hope everyone is doing well.
[09:02] JS Uralia waves, "Good morning!"
[09:02] Sheryl Mimulus: Hello :)
[09:03] JayR Cela: I'm still a lil sleepy from a long weekend of working 12 hour days :_)
[09:03] Ann Otoole: alive. sore head to toe after necronomicon this weekend. odd. i'm not the only one complaining. must have caught a deadly zombie necronomicon bug.
[09:04] JS Uralia: Ann I think it's only deadly until Haloween, so you have to figure out some way to survive that long
[09:04] Ann Otoole: lol
[09:04] Ann Otoole: eat all the halloween candy before the kids get it at the door?
[09:05] Kelly Linden: Okay, well, lets get started then. :) I collect general topics here: https://wiki.secondlife.com/wiki/User:Kelly_Linden/office_hour_topics and since I missed last week, we will start there.
[09:05] Kelly Linden: It is pretty short so we should be able to jump to triage pretty quickly
[09:05] Hank Sopwith: Kelly... there are at lest 2 of us here for the first time... could you give a short introduction to what happens at this time?
[09:06] Ann Otoole: is script limits status worth a mention for status?
[09:06] Kelly Linden: Welcome! :) https://wiki.secondlife.com/wiki/User:Kelly_Linden #Office_Hours
[09:06] Kelly Linden: That is the base page, I am trying out doing alternating general discussion and script triage.
[09:07] Talarus Luan: Script Triage day today? :D
[09:07] Kelly Linden: However I missed last week, so will try and get some of each in today.
[09:07] JS Uralia: is it too late to ask that http://3.ly/LSLimprovements and http://3.ly/LSLquaternionImprovements be adgendized?
[09:07] Kelly Linden: Not a whole lot of general topics.
[09:07] Kelly Linden: JS: Add em to the end of the appropriate page - discussion or triage - and we will see where we get to.
[09:07] JS Uralia: a/k/a http://wiki.secondlife.com/wiki/Talk:LSL_Useful_Function_WishList#backwards-compatible_ways_to_save_typing_or_be_more_like_C_or_Javascript and http://wiki.secondlife.com/wiki/Talk:Rotation #Useful_snippets
[09:07] JS Uralia: will do
[09:08] Kelly Linden: Updates on current projects quickly: llCastRay is due for another iteration for test "Soon", up on aditi. However falcon is very busy with Mesh support right now so I dunno when that will hit.
[09:09] Haravikk Mistral: Cool, I've some concerns over the currently proposed implementation though, is there a way to discuss with Falcon?
[09:09] JS Uralia updated https://wiki.secondlife.com/wiki/User:Kelly_Linden/office_hour_topics
[09:10] Kelly Linden: I think he attends Andrew's office hours, and watches / talks on the discussion page on the wiki
[09:10] Haravikk Mistral: Ah, Andrew's office hours are very late for me, I'll hope he looks in on the talk pages then, thanks!
[09:11] Kelly Linden: He Does.
[09:11] Kelly Linden: Andrew's PRIM_ROT_LOCAL is currently released on the main grid.
[09:11] Kelly Linden: woot!
[09:11] Haravikk Mistral: Yay!
[09:11] Talarus Luan: Oh? Gotta test that :D
[09:12] JS Uralia: great! is that SVC-93?
[09:12] flexi campfire: https://jira.secondlife.com/browse/svc-93?
[09:12] Talarus Luan: with some of my code
[09:12] Kelly Linden: Yes it is some piece of that at least.
[09:12] Sheryl Mimulus: nice :) I'll be testing that
[09:14] Hank Sopwith: Kelly... are you famliar with work being done to control avatar movement externally?
[09:14] Kelly Linden: Another related upate is Andrew has drastically improved the link calculations by a few orders of magnitude which should address problems where llSetLinkPrimitiveParamsFast isn't actually that fast. This is currently in a pre-testing phase, so it is at least a few weeks away
[09:14] Lares Carter: Heya everyone :) sorry, i am a bit late
[09:14] Kelly Linden: Hank: I'm not sure I'm aware of what you are specifically referring to.
[09:15] Hank Sopwith: Ok, thanks Kelly.
[09:15] Sheryl Mimulus: Lares, hi!!
[09:15] Kelly Linden: The last update I want to give is on the upgrade to Mono 2.6, it is in internal testing and finding and fixing bugs as we speak.
[09:16] Kelly Linden: Hank: If you could find some relavent links and put them on the discussion page it would help, but probably not until next week.
[09:16] Hank Sopwith: OK, Kelly...
[09:17] Kelly Linden: Moving on to Suggested Topics.
[09:17] Lares Carter: could someone pass me a notecard with the log of the first 15 minutes, please?
[09:17] Kelly Linden: Nathan Zetkin who I don't see here asked about LSL calls for Mesh.
[09:17] Haravikk Mistral: /A PRIM_TYPE_* definition and clarification of how llGetObjectPrimCount() and llGetNumberOfPrims() will behave is all that's needed I think. The latter two because meshes will count as multiple prims, which is what llGetObjectPrimCount() is supposed to track, but that won't work well with existing scripts that compare the result to llGetNumberOfPrims to detect avatars.
[09:18] Lares Carter: thanks JS.
[09:19] Kelly Linden: The answer (to the mesh question) is that they won't be available at first. There are some architectural reasons that we need to be really careful about how often we let shapes change their mesh.
[09:19] Kelly Linden: And a big part of that answer will depend on evaluating the real world usage and behavior of both the server and viewers with mesh.
[09:20] Kelly Linden: So, it isn't ideal - I'd love to just add a PRIM_TYPE_MESH and be done but it is going to take some more design and thought to do it right.
[09:20] Kelly Linden: I still want to get to some triage, so I'm gonna move on pretty quickly
[09:21] Haravikk Mistral: Surely implementation wise the sim could just silently drop overly frequent requests, and you just tweak the exact values later?
[09:21] Kelly Linden: JS: Your topics are huge, so here is your choice - ~5mins each right now or more time if you wait a couple of weeks.
[09:22] Kelly Linden: Haravikk: ug the behavior and resident response when we do that kind of thing is generally horrible.
[09:22] Kelly Linden: People rapidly build content that relies on the exact behavior.
[09:22] JS Uralia: okay I pick more time if I wait a couple week
[09:22] JS Uralia: s
[09:22] Haravikk Mistral: I think for JS' first topic there's not much point adding to LSL, as eventually C# will add all of these I think?
[09:22] Kelly Linden: JS: All right, they will be first on the list for the next discussion meeting.
[09:23] Kelly Linden: In very short, and just as something to think about - I think those requests are a lot of work and I'd rather see us work on the-next-language if we are going to spend a lot of time. We will discuss more later.
[09:23] JS Uralia: Haravikk: I want to note for the record that I object to the insult to everyone who has struggled to learn LSL that putting LSL improvements off for an eventual C# represents
[09:23] Kelly Linden: So. Triage time!
[09:23] Kelly Linden: Before this derails.
[09:23] Kelly Linden: :p
[09:24] Talarus Luan: It's not intended as an insult, just a practical observation. :)
[09:24] JS Uralia: I strongly object
[09:24] Talarus Luan: LL doesn't have the manpower it used to have.
[09:24] Kelly Linden: https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[09:24] JS Uralia: I think the attitude of backwards incompatibility is abominable
[09:24] Kelly Linden: As someone who has been programming in LSL since 2002 I can certainly see your point JS which is why I want to give it more discussion time. Later.
[09:24] JS Uralia: I beg that you please respect your customers, the tens of thousands who learned LSL as a first language and would be unlikely to progress to C#
[09:25] Kelly Linden: JS. Later. :)
[09:25] Kelly Linden: I want to give the topic the time it deserves. So now: TRIAGE: https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[09:26] Kelly Linden: First up SVC-5335[c] - llGetSubString can produce results that crash Mono scripts - 1 vote - Tano Toll (Cerise Sorbet)
[09:26] flexi campfire: https://jira.secondlife.com/browse/svc-5335
[09:27] Kelly Linden: Ok, I've grabbed that one. I will take a look. The problem is that llGetSubString is byte level not character level so you can grab bad UTF-8 with it. That won't change.
[09:28] Kelly Linden: However we probably shouldn't crash scripts when you do it, since it can be a fair bit of work to tell in LSL if you've mangled the string when you do it.
[09:28] Talarus Luan: Yup
[09:28] Talarus Luan: All string functions in LSL are not necessarily unicode-safe. ;)
[09:28] Talarus Luan: ..yet
[09:29] Kelly Linden: . NEXT. :)
[09:29] Kelly Linden: # SVC-3455[c] - llMapDestination ignores look_at parameter - 1 vote - Doran Zemlja
[09:29] flexi campfire: https://jira.secondlife.com/browse/svc-3455
[09:29] JS Uralia: is there a character offset substring?
[09:29] Talarus Luan: Isn't that one due to the broken llPointAt functionality?
[09:30] Couples MultiAnimator v2d (wear)copy- no transfer- whispers: * Abranimations Couples Animator Ready...
[09:30] Talarus Luan: IE, llMapDestination likely uses the same code path for pointing the avatar as llPointAt?
[09:30] Haravikk Mistral: Either way it's an oldish one that'd be nice if it could be fixed eventually =)
[09:30] Talarus Luan: Well, just saying, if one is fixed, likely both might be fixed.
[09:31] Talarus Luan: or the reasons one is broken could be related to the other.
[09:31] Kelly Linden: llPointAt is basically a no-op I think
[09:31] Kelly Linden: not just broken
[09:31] Talarus Luan: Didn't it used to work?
[09:31] Kelly Linden: Not for years.
[09:31] Talarus Luan: 'According to Kelly Linden, llPointAt and llStopPointAt have been deprecated since mid-beta, but remain without a replacement to this day. (SL version 1.6)'
[09:32] Talarus Luan: From the old wiki :)
[09:32] Kelly Linden: yeah llPointAt is just no op.
[09:32] Haravikk Mistral: Well are they both broken intentionally? It seems wrong for llMapDestination to not work
[09:32] Haravikk Mistral: Since it's just specifying a rotation for the avvy to arrive at really
[09:32] Kelly Linden: I think it is a bug, but I think it is minor and I'm trying to follow the comments which indicate it may be viewer? Or am I misreading it?
[09:33] Talarus Luan: Dunno.. the avatar facing parameter has never worked.
[09:33] JS Uralia: avatar orientation rotation is set on the server after a teleport, isn't it?
[09:34] Talarus Luan: Either that, or the viewer just maintains the facing
[09:34] JS Uralia: if it was a sit-style teleport it would be one of the sit position parameters
[09:35] JS Uralia: llSitTarget has a vector offset and a rotation orientation
[09:35] JS Uralia: "rot affects the position of the sit-target in a buggy way way" -- http://wiki.secondlife.com/wiki/LlSitTarget
[09:36] Kelly Linden: All that llMapDestination does is open the map, and send all the data to the viewer
[09:36] Kelly Linden: It is up to the viewer to do the teleport
[09:36] Haravikk Mistral: Hmm, should this be reclassified for Snowstorm or whomever to deal with then?
[09:36] Talarus Luan: Yeah, but it has a look_at parameter which is documented as which way the avatar is supposed to face *if* the avatar teleports
[09:36] Kelly Linden: The server doesn't initiate the teleport at all, just tells the viewer to open the map. Since it looks like (from the code) we are sendign the right look at to the viewer, I think so.
[09:37] JS Uralia: there is no way to pre-load a desired map location with an orientation rotation unless you add such a thing; probably in lots of places: LSL, the map UI (where it would probably be hidden) and the teleport request
[09:37] Kelly Linden: Yeah, it may require architectural changes to how the map does teleports, I'm not entirely sure.
[09:37] Kelly Linden: I'm gonna move it to viewer and take off the scripting tag(s) if any.
[09:37] JS Uralia: then after the teleport the server would have to update the viewer's orientation
[09:38] Kelly Linden: (because they will just throw it back at me otherwise)
[09:38] Haravikk Mistral: It already exists on the LSL side JS in the llMapDestination function, it's likely the viewer is getting the look_at value and just ignoring it
[09:38] Talarus Luan: Well, I would presume that the viewer would have to request the orientation from the destination sim in the TP request.
[09:38] Kelly Linden: Yes, what Talarus is saying.
[09:38] Talarus Luan: There is another related issue with landmarks
[09:39] Kelly Linden: yup, and that should stay related.
[09:39] Talarus Luan: They don't store orientation data either
[09:41] Kelly Linden: ok I've moved that one and updated the description
[09:41] Talarus Luan: coo. next? :D
[09:41] Melchizedek Blauvelt: heya Babs ?
[09:41] Doc Boffin: hi everyone
[09:41] Kelly Linden: NEXT
[09:42] Kelly Linden: # SVC-6357[c] - llGetUnixTimeNanos() - greater precision timing mechanism - 1 vote - Haravikk Mistral
[09:42] flexi campfire: https://jira.secondlife.com/browse/svc-6357
[09:42] Kelly Linden: Ah we touched on this one last time, briefly
[09:42] Talarus Luan: yup, was at the end
[09:43] Haravikk Mistral: Ah yeah, I'd still like this, having to parse llGetTimestamp() into numeric data is a pain ^^
[09:43] Kelly Linden: I don't like the idea of returning a list, I think it just makes it harder to work with in the end.
[09:43] Kelly Linden: Does llGetTimeStamp return nanosecond precision?
[09:43] Haravikk Mistral: It's the only way under LSL, two separate functions would risk delays
[09:43] Haravikk Mistral: Yeah
[09:43] Talarus Luan: microsecond
[09:43] Talarus Luan: 6 digits
[09:43] Doc Boffin: yes
[09:43] Doc Boffin: same as used for scheduling
[09:43] Doc Boffin: which is us
[09:44] JS Uralia: I would like to take this opportunity to point out that a timestamp based on the unix epoch will not fit in a single precision floating point at fractional-second precision
[09:44] Doc Boffin guesses
[09:44] Haravikk Mistral: Please read the issue JS, it's an integer + a float
[09:44] Talarus Luan: Of course it won't ;)
[09:44] Talarus Luan: But that isn't in the feature request
[09:45] JS Uralia: the reason I bring it up is in support of non-default double precision floats
[09:45] Talarus Luan: I'd prefer just keeping it integer number of nanoseconds, personally.
[09:45] JS Uralia: which would be able to hold a unix epoc timestamp at nanosecond precision
[09:45] Talarus Luan: floats are so - imprecise
[09:45] Haravikk Mistral: Well I don't see that being much use under LSL, as you'd just end up converting into a float anyway (Talarus)
[09:45] Haravikk Mistral: But either way would be nice
[09:45] Talarus Luan: Well, if the whole point is precision, keep the precision.
[09:46] Aargle Zymurgy dislikes floating point
[09:46] Doc Boffin guesses again
[09:46] Doc Boffin: mono uses doubles
[09:46] Talarus Luan: Yeah, but LSL isn't going to change to doubles anytime soon. :P
[09:46] Doc Boffin: you should expose the doubles to C# where it makes sense, kelly
[09:46] Haravikk Mistral: This is getting off topic =)
[09:47] JS Uralia: it is the underlying issue
[09:47] Aargle Zymurgy: sorry I was late, but what IS the topic?
[09:47] JS Uralia: in javascript the default float is a double. I'm not recommending that
[09:47] JS Uralia: Aargle: https://jira.secondlife.com/browse/SVC-6357
[09:48] Sheryl Mimulus: topic is getting current time accurate to the nanosecond
[09:48] Kelly Linden: For those arriving late, we are working through https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage and on SVC-6357 right now
[09:48] flexi campfire: https://jira.secondlife.com/browse/svc-6357
[09:48] Aargle Zymurgy scratches his head over that one
[09:49] JS Uralia: I have no idea how difficult it would be to add a new declared double type, but I know that all the operators with promotion rules would be involved.
[09:49] Kelly Linden: If this is really a Minor issue, it isn't going to get addressed in any form soon. So we should make sure we agree on that first. :)
[09:49] Kelly Linden: Haravikk?
[09:49] Doc Boffin thinks that relying on nanoseconds would be a bad idea
[09:49] Sheryl Mimulus: JS, it probably falls under the same category as any suggestion to modify LSL
[09:49] Aargle Zymurgy: I can maybe see why someone wants nanoseconds for timestamps, but for controlling scripts and timing?
[09:50] Haravikk Mistral: Well I'm fine with either two ints or an int and a float, either is a big improvement over parsing llGetTimestamp as you're essentially converting a long into gregorian text, then back into useful data as things stand right now
[09:50] Talarus Luan: Yeah, I can't think of any particular use cases where something like llGetTime/llResetTime couldn't suffice
[09:50] JS Uralia: it is minor in that everyone I know works around by keeping a set of multiple variables for precision timestamps, or using a single precision float and subtracting, e.g., a more recent epoch or the time the script started
[09:50] Latif Khalifa: Does't reset time/get time functions provide the resolution you need for those sort of things?
[09:50] Doc Boffin guesses that script scheduling shouldn't use nanoseconds in the future and so shouldn't be exposed now
[09:50] Kelly Linden: I'm inclined to acknowledge, leave it as Minor and note that I don't quite like the proposed implementation, and move on.
[09:51] Sheryl Mimulus: I've rarely needed nanosecond precision even in rl programs, except when profiling or directly dealing with hardware
[09:51] Haravikk Mistral: There aren't any other possible implementations besides snapshot + two function calls or shoe-horning in wider data types
[09:51] Aargle Zymurgy: yeah, about the only time I needed that was for doing MIDI in a RL app
[09:51] JS Uralia: if you think of it in terms of the LSL scripter time tradeoff with the amount of time it would take to fix the underlying issue, maybe a lot of beginning scripters wouldn't consider it minor
[09:52] Kelly Linden: Haravikk, lets get those thoughts into the comments and move on to another issue for this triage.
[09:52] Latif Khalifa: Doc, do you know if Environment.TickCount uses syscall in mono?
[09:53] Kelly Linden: NEXT - # SVC-5742[c] - Unbundle PRIM_* rules for llSetPrimitiveParams and similar functions to allow for individual parameter settings for all possible parameters. - 10 votes - Talarus Luan
[09:53] flexi campfire: https://jira.secondlife.com/browse/svc-5742
[09:53] Talarus Luan: wootage :)
[09:54] Talarus Luan: got more votes since then. ;)
[09:55] Kelly Linden: Unfortunately I disagree with the creator about "This /should/ be a trivial change to accomplish," This sort of cuts to the core of our shape code AND has a very wide surface area for QA.
[09:55] Sheryl Mimulus: and if its synchronization between scripts, I would suggest adding a way to trigger an LSL event at an exact time rather than try to manage time to the nanosec
[09:55] Talarus Luan: Is it?
[09:55] Kelly Linden: However it does seem like a solid improvement.
[09:55] Talarus Luan: How is the list parsing done at the moment?
[09:55] Kelly Linden: In the most over-engineered and convoluted way possible
[09:55] Doc Boffin is glad to hear kelly talking about surface area
[09:56] Talarus Luan: So, nothing like a switch statement, eh?
[09:56] JS Uralia: "face 3 may not be the same face after a PRIM_TYPE_* change" is meaningless: if the prim changes shape, how can any of the faces be the same
[09:56] JS Uralia: ?
[09:56] Kelly Linden: we have a list of 'rules' that get applied to 'link' objects and accumulated to be applied either at the end of the call or sometimes when other similar calls happen.
[09:56] Talarus Luan: Well, face data is retained after a shape change
[09:56] Kelly Linden: and add a layer for side specific params (but these aren't)
[09:57] JS Uralia: sure, but if you change a cube into a sphere, what happens to 5 of the faces?
[09:57] Talarus Luan: If the sphere is cut, hollowed, etc, it will have more than one face, JS
[09:57] JS Uralia: this bug is wishful thinking shrouded in a lot of otherwise admirable research
[09:57] Talarus Luan: It's not a bug, it is a feature request.
[09:57] Talarus Luan: and you've obviously not done much with full-prim avatars.
[09:58] Sheryl Mimulus: I agree, it needs refinement
[09:58] JS Uralia: I'm not even sure it's a coherent feature request
[09:58] Talarus Luan: O.o
[09:58] Kelly Linden: So every new function requires a rule for setting and rules for applying, changes to setters, changes to getters - and all of it needs unit tests, integration tests and standard QA.
[09:58] Kelly Linden: It is a large project.
[09:58] Talarus Luan: Well, I really would like to get my av down under 2.0ms script time, but I can't until I can get/set some of these params directly without affecting the others.
[09:59] Talarus Luan: In some cases, we simply can not get the existing params (textures, for example, due to permission issues).
[10:00] JS Uralia: Talarus: I'd recommend thinking this one through. Making pseudocode which does what you think you want. I predict that if you try, you will realize that there's no way around the bookkeeping problem that you want LSL to solve for you
[10:00] Kelly Linden: Ok, I'm gonna acknowledge, I'll even leave it as major. But it is a big project so I wouldn't expect it to get prioritized soon.
[10:00] Talarus Luan: JS, I have alredy iterated through that, thanks. It has value.
[10:00] Latif Khalifa: I think a lot of load comes from sim applying these params one by one. Would it be posible to queue a bunch at the time in some fashion?
[10:00] Aargle Zymurgy: if I may ask a question, is there a circumstance under which touch_start can be passed a 0 for the count of touches?
[10:00] Talarus Luan: and it is not a bookkeeping issue
[10:01] Latif Khalifa: Some sort of begin/end update
[10:01] Kelly Linden: All right, that is all the time I have today. :)
[10:01] Doc Boffin: thanks kelly!
[10:01] Talarus Luan: Aargle, there's an agenda in the wiki to add stuff to
[10:01] Kelly Linden: Last minute announcements: I have 2 more office hours before I go on leave.
[10:01] JS Uralia: Talarus: could you paste the "after" pseudocode you came up with in the bug along with a "before" LSL script which it shortens so we can get a better idea of the problem you want to solve?
[10:01] Aargle Zymurgy: well, I'm just wondering because it's happened to me for the first time and in connection with the RC server software
[10:01] Latif Khalifa: Leave? For how long?
[10:02] JS Uralia: !!
[10:02] Jonathan Yap: Wow. How long is your leave for?
[10:02] Aargle Zymurgy: I'm trying to find out if it's something that's always existed, or something new.
[10:02] Kelly Linden: I'd suggest bugging Andrew's office hours, or Oskars while I'm gone.
[10:02] Kelly Linden: I'm going to be on leave for 3 months. So back in Feb.
[10:02] Talarus Luan: I can, JS, but it will be a bit.
[10:02] Jonathan Yap: I hope you enjoy your new baby or your world cruise :)
[10:02] JS Uralia: Perhaps it would have been helpful to start with that example so I could have made a more informed decision on the five minute or two weeks question
[10:02] Doc Boffin: have fun kelly
[10:02] Kelly Linden: Thanks Doc.
[10:02] JS Uralia: to start with that announcerment*, Kelly
[10:03] Doc Boffin: good luck too
[10:03] Kelly Linden: Hehe JS. :)
[10:03] JS Uralia: :-(
[10:03] JS Uralia: excuse me
[10:03] Kelly Linden: Thank you all for coming.
[10:04] Latif Khalifa: Thanks for you time Kelly
[10:04] Melchizedek Blauvelt: thanks for having us, as always
[10:04] Aargle Zymurgy: thanks Kelly
[10:04] JS Uralia is very unhappy
[10:04] Sheryl Mimulus: Take care, Kelly
[10:04] Talarus Luan: I don't have time or space in the wiki to give exacting detail that every single person requests to sate their own quest for knowledge, JS. If you spend an hour trying out some of the examples I did give in the text (and ones from other, related JIRAs), you can easily see the problem the feature is trying to seolve.
[10:04] Pause Oller: Thanks! =>
[10:04] Talarus Luan: Other people don't seem to have a problem understanding it (14 votes so far).
[10:05] JS Uralia: When is C# expected to be ready? Another two or three years?
[10:05] Sheryl Mimulus: I understand the problem Talarus, I suffer from it too :P
[10:05] JS Uralia: serious question
[10:05] Kelly Linden: JS: Maybe. Maybe next year.
[10:05] Talarus Luan: Besides, don'y you think it would be best to learn what the problem is before poopooing it?
[10:05] JS Uralia: shame!
[10:05] Doc Boffin: o/

Generated with SLog Wikifier

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Ama_Omega/archive/Office_Hours/2010-10-25&oldid=1142497"