Simulator User Group/Transcripts/2014.02.04
| Prev 2014.01.28 | Next 2014.02.11 |
List of Speakers
| ac14 Hutson | Adamburp Adamczyk | Baker Linden |
| Ima Mechanique | Inara Pey | Jenna Felton |
| Jonathan Yap | Kallista Destiny | Kitto Flora |
| Latif Khalifa | Lexbot Sinister | Lucia Nightfire |
| Mona Eberhardt | Qie Niangao | Rex Cronon |
| Simon Linden | Tankmaster Finesmith | Theresa Tennyson |
| Will Webb |
Transcript
[12:01] Simon Linden: Hi Everyone
[12:02] Adamburp Adamczyk: yo
[12:02] Rex Cronon: hi simon
[12:02] Theresa Tennyson: Hello!
[12:02] ac14 Hutson: hello
[12:03] Simon Linden: ok, let's start with the release news ...
[12:03] Simon Linden: The forum post is here : http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2014-02-03-Updated-2014-02-04-09-50PST/td-p/2476531
[12:03] Simon Linden: This morning the main channel was updated with the code that was in RC
[12:04] Simon Linden: Tomorrow the RC servers will get another maintenance release with a crash fix
[12:05] Simon Linden: There also was a back-end voice update recently with Vivox servers, but hopefully that has no visible changes. I'm not sure what their revision did
[12:05] Simon Linden: Baker - did you have any news?
[12:06] Rex Cronon: now the nsa can listen to our chat better;)
[12:06] Simon Linden: The table's open then for questions or topics
[12:07] Baker Linden: I have somenews
[12:07] Lexbot Sinister: I'm wondering whats been wrong with the asset servers, with so many maintenances?
[12:07] Theresa Tennyson: Can you tell us anything about the asset server issues over the past few weeks?
[12:08] Kitto Flora: Is that connected to Avs never rezzing - staying as clouds?
[12:08] Baker Linden: I'm finally finished with (what I think is) the major viewer side changes, so I'll be getting everything ready this week for a deploy hopefully in the next upcoming weeks, so be ready to test the crap out of group bans on aditi soon!
[12:08] Baker Linden: that's all on my end
[12:08] Ima Mechanique: \o/
[12:09] Will Webb: ran into a link number bug this week
[12:09] Simon Linden: I'm not familiar with what was going on with the asset servers, Theresa
[12:09] Simon Linden: but it could definitely cause you to remain as a cloud if your viewer or the baking servers couldn't get the data to draw your AV
[12:10] Simon Linden: Will ... is there a BUG for that?
[12:10] Will Webb: BUG-5049
[12:10] Mona Eberhardt: Simon, I saw this as a blog comSimon, I saw a blog comment by someone who claims they lose attachments everytime they teleport. At first, I wondered if she was talking about rez fail on teleport, but she claims the items get "lost" and that this happens to her very often and that this is very widespread. This puzzled me, because, although I've had attachments fail to rez (actually, last night I even saw that certain in-world objects in a certain region failed to rez), the claim was about *loss* of attachments. Furthermore, she claimed that she can't file a JIRA, because LL will reject it on the grounds of her using Firestorm. Besides her JIRA-related claim, which I simply can't believe, the rest is really puzzling and I can't get my head around it. Any thoughts?
[12:10] Will Webb: just made it yesterday
[12:10] Will Webb: https://jira.secondlife.com/browse/BUG-5049
[12:11] Theresa Tennyson: There have been recurring issues with "Cannot create requested inventory" messages since late December. It seems to be worse for some people than others.
[12:11] Latif Khalifa: Baker, when do you expect code for the group bans viewer to be released?
[12:12] Mona Eberhardt: Yes, I've been having "Cannot create requested inventory" error messages all weekend. It was more than a bit inconvenient, forcing me to relog numerous times.
[12:12] Simon Linden: Mona - yes ... try it on the LL viewer so the bug report won't get rejected. Seriously, though, we're not hearing other reports of that so it's likely her viewer, her account, network or something she's wearing that makes the problem worse
[12:13] Kitto Flora: What I have been seeing is - on some sims - on TP in, the scenery rezzes but the avs do not. Sometimes Avs are not visible but I can talk to them, other times they stay as cloud. If I then TP to another sim Avs appear ok.
[12:13] Baker Linden: Latif, once I get everything ready to package up, I'll show up to a TPV meeting and announce it
[12:13] Baker Linden: so in the next couple TPV meetings (I don't remember if they're every two weeks or every week)
[12:13] Inara Pey: Every 2 weeks
[12:13] Inara Pey: Baker.
[12:13] Jonathan Yap: There was just one last Friday
[12:14] Inara Pey: So next one on the 14th
[12:14] Lexbot Sinister: kinda poorly chosen date :/
[12:14] Baker Linden: so I'll be at that meeting with what I hope is really good news :)
[12:14] Baker Linden: provided I didn't screw anything up too badly
[12:14] Ima Mechanique: news and chocolates
[12:15] Simon Linden: ok Will ... that will get looked at later this week. That seems like it might be something we just want to document ... is it causing problems or just odd behavior?
[12:15] Rex Cronon: its a gift of "love"lexbot:)
[12:15] Jenna Felton: i usually get some of my mesh attachments not visible for me after hours in sl and when i teleport somewhere, than i see the attachments not worn and i cant wear. after relog i can wear them again. and others see the attachments on me. Especially its my mesh head that is very complicated. I think its because of the full viewer cache. But the items are not lost just not wearable
[12:15] Will Webb: well, when you run through for loops to use llsetlinkparam with lists of linknumbers, it happens that if you request more entries than the list is long, the list will return zeroes
[12:15] Qie Niangao: Simon, I think the question is whether it's a new behavior or not. If it's always been that way, it doesn't really matter.
[12:16] Lexbot Sinister: I sometimes get my skin unworn somehow, when changing skins. or shape for that matter. it's really bothersome
[12:16] Will Webb: so if this is a newer bug, it might unwantingly be adjusting the root prim when that's not wanted
[12:16] Will Webb: in older scripts
[12:17] Simon Linden: Right Qie ... I don't recall any changes in link numbering recently. It's a balance between getting it right and the big unknown of how much existing content will break if we fix it
[12:17] Will Webb: i also noticed our link_root constant is 1, thus it doesn't work in single prims; maybe we should add another root constant with a negative value that can refer to any root dynamically?
[12:18] Will Webb: the odd part about bug 5049 is that when you run it from the root it gets discarded
[12:18] Will Webb: so the behavior is not consistent and should probably at least be looked into
[12:19] Baker Linden: that just seems like a wrong if statement in the code...
[12:20] Simon Linden: It's definitely worth a look ... with the caveat that I haven't done that yet, my initial reaction is that it's an existing quirk that is awkward but not causing problems. People may stumble on it but if they're using valid link numbers and ranges, they won't hit it
[12:20] Baker Linden: i.e. "If we get a linkset value of 0, and we don't have one, then set it to 1, since we'll probably have that"
[12:20] Baker Linden: yeah
[12:20] Will Webb: true, in that case it might probably be enough just to document it in the wiki
[12:21] Will Webb: i only ran into it because i was running a for loop on 2 lists at once, and one was shorter and thus started returning zeroes
[12:23] Simon Linden: ok, sounds good. It will get some time during this week, I think. There's an initial sorting and the status should get updated then
[12:23] Will Webb: the fact that it doesn't show up when run from root prims might hurt some scripts if someone decides to plunk them in a child prim, but that's about the worst that could happen
[12:23] Kitto Flora: If you don't know how many links are in the object, use llGetLinkNumber() before messing with the links.
[12:23] Will Webb: kitto, missing the point; you can't use llsetlinkparams with lists or arrays, so you need to use for loops
[12:24] Mona Eberhardt: I'd like to dwell a bit on the rez fail issue. On Saturday, I logged in and saw that my full-body alpha refused to rez, even though I waited for a considerably long period; in fact, even my normal skin didn't rez and my grey shape poked through my mesh avatar. So, I had to relog. And, two or three relogs later, this issue with the alpha occurred again. Is there some sort of a problem with alphas? And does it have anything to do with the materials code?
[12:24] Baker Linden: what do you use as the conditional to stop the for loop, Will?
[12:24] Will Webb: the lenght of the longest list
[12:24] Jonathan Yap: Mona, did you look in your secondlife.log file after that had happened?
[12:24] Simon Linden: It seems easy enough to code around, knowing about the behavior but I can see where it would act in unexpected ways
[12:24] Mona Eberhardt: No, Jonathan.
[12:25] Baker Linden: length of the longest list = # of links?
[12:25] Mona Eberhardt: I'll try to spot it now.
[12:25] Kitto Flora: (Sorry that should be 'use llGetNumberOfPrims() before...)
[12:25] Will Webb: that results in the shortest list returning zeroes, and yes, it's not a showstopper by any means :-)
[12:25] Baker Linden: that would make sense though, if you're iterating more times than there are objects in the list
[12:25] Will Webb: the most annoying artefact is probably that it doesnt show up when run from root prims
[12:25] Will Webb: thereby hiding from debugging really well
[12:25] Will Webb: true, i was expecting the zeroes to be discarded
[12:25] Baker Linden: I'm glad we just return 0's instead of crashing with an indexOutOfBounds exception or something
[12:26] Will Webb: which is what hpanned when testing from root
[12:26] Will Webb: *happened
[12:26] Simon Linden: I'm sure someone would have exploited a crash by now if we had a range issue there
[12:26] Baker Linden: would it be safe to discard any 0's in the list after processing it?
[12:26] Mona Eberhardt: Ugh. Too late. :(
[12:26] Will Webb: it's an annoyance that ppl probably never run into, as most would never call linknum 0 from a child prim :-)
[12:27] Baker Linden: would there be any reason to allow that?
[12:27] Baker Linden: calling linknum 0 from a child prim
[12:27] Simon Linden: Mona ... how is your network connection, generally? Do you have a lot of hops and high ping time to SL?
[12:27] Will Webb: well, there might be if ppl use the same scripts in unlinked objects
[12:27] Will Webb: it's not good practice, but honestly...
[12:27] Will Webb: cut and paste scripting happens around here
[12:28] Theresa Tennyson: Regarding Mona's issue - I fairly regularly find I have at least one avatar texture that stays gray. I tend to get a lot of "Cannot find local texture: transparent" - type messages in the debug console.
[12:28] Baker Linden: I was just thinking we could just do a check to see if you're calling that function on a child prim and ignore it if so
[12:28] Baker Linden: only allow that call on a root prim
[12:28] Theresa Tennyson: The gray textures are fixed after a relog.
[12:28] Will Webb: llsetlinkparams
[12:28] Will Webb: no, i do think that's used a lot from children
[12:28] Kitto Flora: "Zero is returned if prim (1) is not found,"
[12:28] Qie Niangao: Well, it's not just cut-and-paste scripting; linksets are dynamic things, but if a script is changing the linkset, every script in the assembly better be cognizant of that.
[12:28] Kitto Flora: Seems its expected action
[12:28] Baker Linden: :(
[12:29] Baker Linden: ok
[12:29] Mona Eberhardt: Generally, my ping time is 250-300 ms, and my router (24Mbps ADSL connection nominal) usually syncs at 12-14Mbps. So, all things considered, my provider says this is a healthy line.
[12:29] Simon Linden: yeah, that sounds pretty good and high bw
[12:29] Will Webb: we could probably just catch and ignore calls to non-existent link numbers
[12:29] Baker Linden: oh, could this be caused by having the script change around the linkset numbers, whereby it could fall into a state where we've reduced the number of links in the list and now we're trying to iterate over the original length, as opposed to the new length?
[12:30] Object: Touched.
[12:30] Object: test
[12:30] Object: Hello, Avatar!
[12:30] Will Webb: yes, apparently
[12:31] Will Webb: it happens with all non existent link numbers
[12:31] Will Webb: that was a test sent to link number 10
[12:31] Will Webb: in a 2 prim unit
[12:31] Will Webb: i'm guessing there's some code that discards these calls if they happen from root
[12:31] Will Webb: but not when they happen from children
[12:32] Object: Hello, Avatar!
[12:32] Baker Linden: hmm, if I knew anything about the scripting engine, I could have a look-see, but I don't, so I'm not going to so much as breathe on the scripting engine :)
[12:32] Object: Touched.
[12:32] Will Webb: yup
[12:32] Will Webb: discarded from root prim
[12:33] Will Webb: but all non existent linknums redirect to 1 when called from child prims
[12:33] Object: Touched.
[12:33] Simon Linden: yeah, it does seem like that call should behave the same from root or a child prim ... the link number is the link number within that object, regardless of where it's called
[12:33] Simon Linden: (I'm ignoring sitting AVs and attachments and any of those cases)
[12:33] Baker Linden: so a root would have link number 0, and a child has link number 1, right?
[12:33] Will Webb: no
[12:33] Baker Linden: oh
[12:33] Will Webb: root is 1
[12:33] Will Webb: only single prim objects have linknum 0
[12:34] Baker Linden: ahh
[12:34] Will Webb: that's also root
[12:34] Baker Linden: well that's fun
[12:34] Will Webb: root is 0 in singles, 1 in linksets
[12:34] Will Webb: yeah
[12:34] Baker Linden: so in a linked set, there should never be a 0 in the list
[12:34] Will Webb: that's also why the link_root constant breaks in single prims
[12:34] Will Webb: the constant is 1
[12:34] Will Webb: instead of a dynamic constant like -5 or such
[12:35] Baker Linden: ahh ok
[12:35] Simon Linden: it's one of those LSL oddities that's been around forever, I think
[12:35] Object: Hello, Avatar!
[12:35] Baker Linden: yeah, sounds like it
[12:35] Rex Cronon: u realize that if "fix" this u will break all existing scripts:)
[12:35] Kitto Flora: Since 2004 at least.
[12:35] Will Webb: the bugs behind the curtain :)
[12:35] Will Webb: fix what, rex?
[12:35] Will Webb: the linknum issue or link_root?
[12:36] Kallista Destiny: LSL is full of oddities, one could do a reality TV show about all the oddities in LSL
[12:36] Lucia Nightfire: what I miss, heh
[12:36] Simon Linden: Some new negative constant for the ROOT would be good, until people start using it as a basis for math
[12:36] Tankmaster Finesmith: SL 2.0!
[12:36] Will Webb: we don't have to fix link_root, but we could always add another root constant
[12:36] Rex Cronon: setting the root to 0 always
[12:36] Baker Linden: Real Scripters Of LSL County
[12:36] Rex Cronon: check the log lucy:)
[12:36] Kallista Destiny: Yeah or something like that...
[12:37] Baker Linden: yeah, something like link_root_nochild or something
[12:37] Will Webb: one that dynamically refers to the root
[12:37] Will Webb: in all circumstances
[12:37] rcdsQueChatLog: Lucia Nightfire, you can read the log here:
http://rcds.nfshost.com/ques_view_chatLog.php?queOwner=llsl:Rex+Cronon&queName=chatLog&pg=1
[12:37] Will Webb: we do it for LINK_ALL_OTHERS
[12:37] Will Webb: that constant knows how to avoid the current prim
[12:39] Baker Linden: maybe we can incprorate that into the current broken code
[12:39] Baker Linden: incorporate*
[12:41] Simon Linden: Things have gotten quiet ... were there questions I missed, or any other ideas or suggestions?
[12:41] Jenna Felton: I think since LINK_ROOT is documented as 1, changing this would be not good because scripters already rely on that. But something like LINK_ROOT_CURRENT with free negative value coud be nice, that dynamically replaced by 0 or 1 in respect of the link set
[12:41] Will Webb: true, jenna, i agree; we cannot change existing constant
[12:41] Simon Linden: we really can't change any existing ones
[12:41] Rex Cronon: i think jenna is right
[12:42] Jenna Felton: than scripters who already check the linkset would use the correct number and ho dont want ask the number of the prims would use the new one
[12:42] Jenna Felton: who*
[12:42] Will Webb: an additional constant won't hurt anyone i think, even though it's use would be limited to template scripting
[12:42] Qie Niangao: One wonders how many places the code would have to change, to use a LINK_ROOT_CURRENT... whether link-addressabiity is common across all those functions, or implemented separately.
[12:42] Aur'a Færs (inusaito.kanya): Kinda random but this morning someone reported that things are getting randomly attached to Avatar Center on login, and apparently there's a discussion of this on the SL site somewhere, but I don't have the link handy... is there any investigation of this?
[12:43] Will Webb: most link constants rarely get called in a single prim script when you write it specifically as a single prim script
[12:43] Jenna Felton: you must not replace the code that is already working .) but when you make new script you would use the new constant
[12:44] Will Webb: qie: i'm guessing here, but link_all_others manages to dynamically figure out which link it is sent from
[12:44] Ima Mechanique: why on earth would you need a constant for ROOT_PRIM in a single prim object?
[12:44] Simon Linden: Yes, a new one taht doesn't overlap any existing ones for that function is pretty easy to add
[12:44] Will Webb: wel, ima, it's just annoying that it's a constant, yet the root's linknum is not a constant
[12:44] Will Webb: thereby breaking the idea of a constant somewhat
[12:44] Ima Mechanique: technically it is, you can't be root of a linkset, if there is no set
[12:45] Qie Niangao: Ima, the problem is that single-prim objects don't stay single-prim objects -- as when sat upon.
[12:45] Rex Cronon: ima. u could have it attach prims to itself?
[12:45] Will Webb: if there is no set, the prim is its own root
[12:45] Will Webb: true qie
[12:45] Will Webb: especially then
[12:45] Will Webb: the single prim that is sat upon would change linknum
[12:45] Kallista Destiny: Ohhhh that sounds recursive
[12:45] Ima Mechanique: yes, at which point you use the correct constant
[12:45] Will Webb: as the avatar gets its own linknumber
[12:45] Jenna Felton: you can want sell a no-mode script that the user simply put into prims, or they put scripts into prims and sometimes link the prims differently and the script meant for child prim apears in the rot prim, and stil has to behave correctly
[12:45] Jenna Felton: this is reason for dynamically check
[12:46] Will Webb: a constant should not be verified dynamically
[12:46] Will Webb: that's why it's a constant
[12:46] Kallista Destiny: isn't there an event that occurs when link count changes?
[12:46] Qie Niangao: CHANGED_LINK
[12:46] Jenna Felton: LSL not knows any constant. The "constants" in LSL are variables named in upper case letters :)
[12:47] Jenna Felton: but you always can change the value of a constant you have defined
[12:47] Will Webb: adding a constant that consistantly targets the root prim, no matter what, can only be a good thing in my book
[12:47] Qie Niangao: Jenna, not the built-in constants.
[12:47] Will Webb: these are built-in lsl constants
[12:47] Will Webb: they're "constant"
[12:47] Jenna Felton: yes but that because they are made by lindens
[12:47] Kallista Destiny: You men when the value of PI is different than 3.14159...
[12:47] Ima Mechanique: Jenna, lsl doesn't have user constants at all
[12:48] Jenna Felton: who have power to change the value with risc that we must live than with the result
[12:48] Rex Cronon: we can also have a new lsl function llGetTrueLinkNr() return int
[12:48] Rex Cronon: :)
[12:48] Will Webb: :-p
[12:48] Will Webb: like the base64 iterations ;-)
[12:49] Rex Cronon: eventually we will get one that works;)
[12:49] Jenna Felton: true link number is a welcome function. i dont like to check the linkset and filter out all the sitting residents :)
[12:49] Will Webb: :-)
[12:50] Lucia Nightfire: Has anyone asked wth is up with all the login failures, inventory faults, inventory derez faults, rez faults, timeouts, etc that have been occurring like crazy over the last week?
[12:50] Jenna Felton: btw, when you have a single prim than the root is 0, but when someone sits on it, than it becomes a linkset of 2 "prims" and then the root should become 1
[12:50] Baker Linden: lucy, someone mentioned it at the beginning on the meeting.
[12:50] Jenna Felton: when i think right
[12:50] Will Webb: sifting through prim descriptions in order to collect linknumbers and properly associate them can be a hassle, true :-)
[12:50] Tankmaster Finesmith: a while ago, lucia
[12:50] Will Webb: i think the root does become 1 when you sit on a single prim
[12:50] Lexbot Sinister: we asked, and no answers so far
[12:50] Will Webb: it would be inconsistent otherwise
[12:50] Qie Niangao: it does, I just tested it.
[12:51] Simon Linden: AFAIK Lucy those are due to (hopefully) transient network or system problems
[12:51] Lucia Nightfire: I wish Whirls was here, she could mention a lot more
[12:51] Object: Hello, Avatar!
[12:51] Lexbot Sinister: unscheduled inventory maintenance due network problems??
[12:51] Kitto Flora: Another problem is regions that loose http comms for hours. Is that common?
[12:52] Lucia Nightfire: I myself, have had all those happen in higher than usual frequency
[12:52] Will Webb: could that be related to idling in any way, kitto?
[12:52] Mona Eberhardt: Same here, Lucy. Especially during the weekend.
[12:52] Kitto Flora: What is idling?
[12:53] Will Webb: the sim's fps going into idle mode and dropping to 20% of normal, iirc
[12:53] Lucia Nightfire: more liek 0.2222%, heh
[12:53] Lucia Nightfire: .0222
[12:53] Simon Linden: I don't see how that would be related to idling, since the region you're on won't idle
[12:53] Qie Niangao: I have not seen that http comms issue myself, but there's a report in the scripting forum: http://community.secondlife.com/t5/LSL-Scripting/My-llHTTPRequest-keep-getting-lost/td-p/2473883 ... maybe outbound (external to LL network) only?
[12:54] Will Webb: http comms dont require presence i think
[12:54] Kitto Flora: I dont know. This is affecting GSLR Railcars, which use HTTP comms to report position
[12:54] Jenna Felton: can not sit on a prim?
[12:54] Lucia Nightfire: we need remote linked messages, lol
[12:55] Lucia Nightfire: with pin
[12:55] Qie Niangao: Oh, hmm. It's true I haven't seen GSLR railcar positions for a while. :p
[12:55] Kitto Flora: I can't tell if a region is 'idling' when a car crosses it. But would not the region wake up when a moving object enters?
[12:55] Simon Linden: That sounds like a resource leak or limit ... the connections end up failing
[12:55] Jenna Felton: also messages for attachment worn by owner
[12:55] Lucia Nightfire: they only wake up when they acquire a child agent, main agent or an http comm
[12:56] Simon Linden: I don't think it does, Kitto ... I belive the idle code focuses on avatar presence only
[12:56] Jenna Felton: when you sit the root becomes 1
[12:56] Kitto Flora: resource leak or limit in... the sim or the object?
[12:56] Will Webb: so basically, anyone who (irrationally) dislikes idling just puts up a http relay? :-)
[12:56] Lucia Nightfire: basically, heh
[12:56] Simon Linden: ... right Lucy, http code will stop idling briefly
[12:56] Qie Niangao: As Lucy says, http comms will wake them up.
[12:57] Will Webb: or should wake them up, that's why i wondered if that might be related somehow
[12:59] Simon Linden: That forum post says it gets into that state and is stuck until a restart ... and those 499 errors are internal problems. So I'm _guessing_ it's somehow running out of resources and doesn't want to make more requests
[12:59] Ima Mechanique: gotta run, bye all. Simon, Baker thanks for the meeting
[12:59] Rex Cronon: tc ima
[12:59] Simon Linden: We're about out of time ... thanks everyone for coming this week
| Prev 2014.01.28 | Next 2014.02.11 |