Simulator User Group/Transcripts/2012.06.01

From Second Life Wiki
< Simulator User Group
Revision as of 18:22, 1 June 2012 by Andrew Linden (talk | contribs) (Created page with "Simulator_User_Group {| | Prev 2012.05.29 | Next 2012.06.05 |} == List of Spe…")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Simulator_User_Group

Prev 2012.05.29 Next 2012.06.05

List of Speakers

Andrew Linden Ashiri Sands Baker Linden
Baxter Aubin DrFran Babcock Jonathan Yap
Kelly Linden Motor Loon Moundsa Mayo
Nalates Urriah Qie Niangao Rex Cronon
Sniper Siemens TankMaster Finesmith Vincent Nacon

Transcript

[16:05] Motor Loon: Ah baker... Andrew... figured you had gone on weekend already

[16:05] Ashiri Sands: hi Andrew

[16:05] Ashiri Sands: hi Baker

[16:05] Baker Linden: not yet. Soon.

[16:05] Sniper Siemens: Hi Andrew

[16:05] Baker Linden: Howdy

[16:06] Andrew Linden: Heh. No I was in a code review

[16:06] Baxter Aubin: hiya

[16:06] Andrew Linden: and lost track of time

[16:06] Rex Cronon: hi andrew, baker

[16:06] Motor Loon: we hear ya

[16:06] Andrew Linden: Looks like Simon is out of the office for part of today

[16:06] DrFran Babcock: lucky Simon

[16:06] Kelly Linden: It took me about 3 minutes to realize it was not possible to do what I wanted to do in LSL so it will be a really boring class as I'm already back to mucking in the sim code.

[16:06] Motor Loon: Good, we'll call the strippers afterall then

[16:07] Nalates Urriah: yay male dancers

[16:07] Motor Loon: arh...male... yeah... right... not what I had in mind...

[16:07] Andrew Linden: The news I've got is:

[16:07] Nalates Urriah: :p

[16:08] Andrew Linden: I fixed PATHBUG-136 llSetRot() and friends broken

[16:08] Rex Cronon: what were u trying to do kelly?

[16:08] Andrew Linden: which was a frustrating bug on the "Second Life RC PF" channel

[16:08] Motor Loon: excellent... that was a real bad one

[16:08] Andrew Linden: I think the fix for that was deployed yesterday.

[16:08] Motor Loon: "The super breaker"

[16:08] Kelly Linden: I need to set a custom header in an llhttprequest

[16:08] Andrew Linden: right

[16:09] Andrew Linden: I'm currently tracking down some Keyframe bugs in pathfinding.

[16:09] Andrew Linden: Baker definitely has more interesting news. Kelly probably does.

[16:09] Vincent Nacon: hmm

[16:10] DrFran Babcock: Baker just jumped right in

[16:11] Motor Loon: well, lets have it then...

[16:11] Baker Linden: I suppose so. I managed to fix STORM-1840

[16:11] JIRA-helper: http://jira.secondlife.com/browse/STORM-1840

[#STORM-1840] Searching legacy names in the "Choose Resident" floater with a period returns no result

[16:11] Baker Linden: oh, well, I sort-of fixed that one

[16:11] Baker Linden: it's half-fixed

[16:12] Motor Loon: sighs.... nice cubes Vince

[16:12] Vincent Nacon: :P

[16:12] Jonathan Yap: Which half is fixed, processing the "." and no lower/upper case issues?

[16:12] Moundsa Mayo: So now it works half-fast? B^)

[16:12] Nalates Urriah: So we use a comma in place of a period...

[16:12] Baker Linden: If you have display names turned on, it won't work

[16:13] Vincent Nacon: I'll spin ya

[16:13] Nalates Urriah: Thx

[16:13] Rex Cronon: can we already search "?ox resident"?

[16:14] Jonathan Yap: It's too bad there are 2 code paths for that search

[16:14] Baker Linden: yeah

[16:14] Motor Loon: oh be still Oliver, you already had one bowl of soup

[16:14] Moundsa Mayo: But it was such a THIN soup ...

[16:14] Baker Linden: and I haven't been able to figure out what the other path hits and where it hits

[16:15] Jonathan Yap: Baker look at my comment in vwr-28027

[16:15] JIRA-helper: http://jira.secondlife.com/browse/VWR-28027

[#VWR-28027] an attempt to ban an FAILED due to SL's FAILURE to link to avatar name

[16:15] Jonathan Yap: The one dated 13/Feb/12 3:50 PM

[16:16] Andrew Linden: we'll fix the display names version eventually. we were having technical difficulties fixing/deploying the web service code

[16:16] Baker Linden: Yeah. that's sort of another bug it would seem, but it's in the way the db query happens

[16:16] Andrew Linden: so we put it on a backburner for a day or two until we revisit

[16:17] Baker Linden: it's not really a bug. If you supply two names, the query selects on a first and last name. If you supply only one name, it selects only on a single name -- perhaps username?

[16:18] Andrew Linden: I got this announcement via email: JIRA will be down for maintanance between 22:00 and 23:00 PACIFIC tonight.

[16:18] Jonathan Yap: searching for a.last, a.Resident, a.RESIDENT, etc. should return a valid result

[16:18] Andrew Linden: where 'username' is the name of the column in the db (avatar first name)

[16:19] Baker Linden: that should, yes. I mean, it will once it goes live

[16:19] Baker Linden: and only when "View Display Names" is turned off, until I get the web service side fixed

[16:19] Jonathan Yap: I started to fix it at the viewer end but would have had to do funny things to handle upper vs lower case issue

[16:20] Baker Linden: I think server side, it converts it to a standard format anyway

[16:20] Jonathan Yap: Maybe you should move that storm issue to another project (in which case I can delete my work in progress)

[16:21] Baker Linden: if you were to search for "a last", "a Resident", "a RESIDENT" it should work now.

[16:21] Jonathan Yap: nice :)

[16:21] Andrew Linden: STORM-1840 is being fixed server-side

[16:21] Jonathan Yap: but the "." format needs to work, too, as some names are displayed in the viewer that way, and people will want to copy and paste

[16:21] Baker Linden: I think when legacy names got changed to the current system, people just removed the period as a string splitter

[16:21] Baker Linden: so they changed all splits from a space to a period

[16:22] Jonathan Yap: Andrew, should storm-1840 be closed then?

[16:22] Andrew Linden: not yet, lets leave it open until the fix is actually deployed

[16:22] Andrew Linden: but Baker, you should comment on that STORM issue and mention that it is being fixed server-side

[16:23] Jonathan Yap: and maybe link to the relevant server issue

[16:23] Jonathan Yap: fun with jifa

[16:24] Andrew Linden: Ok, I guess the table is open.

[16:24] Motor Loon: VWR-14674 - mabye I broke it... or someone did... regardless I cant access it anymore

[16:25] Jonathan Yap: vwr-14764

[16:25] JIRA-helper: http://jira.secondlife.com/browse/VWR-14764

[#VWR-14764] Offline when online is checked. Chat not coming across

[16:25] Jonathan Yap: It is there

[16:25] Andrew Linden: Motor, someone imported VWR-14764 to an internal bug

[16:25] Motor Loon: no

[16:25] Motor Loon: aj

[16:25] Motor Loon: ah ok... you mistyped Jonathan but ok

[16:25] Andrew Linden: was titled: "Object Return Fucnction of Region/Estate Menu does not work"

[16:25] Jonathan Yap: oups :)

[16:25] Motor Loon: and now we shouldnt be able to see it?

[16:26] Motor Loon: yeah its the one you had a fix for baker

[16:26] Andrew Linden: Hrm... I guess it should have been cloned to an internal bug rather than moved.

[16:26] Motor Loon: I like that better than "Motor broke it"

[16:27] Moundsa Mayo: If you broke it, Motor that's a good thing to know, too!

[16:27] Motor Loon: well, nobody saw me - you cant prove a thing!

[16:28] Andrew Linden: Ah, VWR-14764 is now SVC-7813

[16:28] JIRA-helper: http://jira.secondlife.com/browse/SVC-7813

[#SVC-7813] [PUBLIC]Object Return Function of Region/Estate Menu does not work

[16:28] Andrew Linden: er... it was cloned there

[16:28] Motor Loon: oh... updating my list

[16:29] Motor Loon: comments arent the same though

[16:29] Motor Loon: it was cleared out?

[16:29] Rex Cronon: missplaced jiras? the bugs got lost:)

[16:29] Andrew Linden: uh... maybe I made a jira number mistake.... VWR-14764 appears to exist and has a different title. hrm...

[16:30] Motor Loon: I just get the ER-1811 page when I try to access it

[16:30] Motor Loon: perms violation

[16:30] Andrew Linden: oh... VWR-14764 is not what we're talking about. We're talking about VWR-14674

[16:30] Meeter: Timecheck : User Group is half over

[16:30] Motor Loon: yes

[16:31] Baker Linden: Yeah, I moved that to ER, and it's a clone of SVC-7813

[16:31] Andrew Linden: right, and that now lives at SVC-7813

[16:31] Andrew Linden: and is fixed (but waiting for QA and deploy)

[16:32] Motor Loon: says unresolved and unassigned on my screen

[16:32] Motor Loon: but ah well, aslong as it's comming

[16:32] Baker Linden: Andrew is assigning it to WorkingOnIt

[16:32] Rex Cronon: wouldn't be better to reate new jira that points to previous one, rather tha have jiras with new nrs?

[16:32] Baker Linden: I'm a n00b when it comes to the system. I just moved it, rather than cloned it

[16:32] Rex Cronon: better to create*

[16:33] Motor Loon: nevermind... it everything was easy - it wouldn't be fun

[16:33] Jonathan Yap: If you clone something you need(?) to link back to the original, so someone later can close it

[16:34] Andrew Linden: If the clone is done via the jira tools then the linkage is automatic.

[16:35] TankMaster Finesmith: sorry im late, what topics have been discussed?

[16:36] Rex Cronon: how to handle jiras:0

[16:36] Baker Linden: and how I'm bad at it

[16:36] Rex Cronon: :)

[16:36] Motor Loon: haha

[16:36] Jonathan Yap: storm-1840 is partially done server side

[16:36] Jonathan Yap: https://jira.secondlife.com/browse/STORM-1840

[16:36] JIRA-helper: [#STORM-1840] Searching legacy names in the "Choose Resident" floater with a period returns no result

[16:36] Motor Loon: for every fix'd bug you do in the server code you're allowed one messup on the jira

[16:37] Rex Cronon: as long as somebody doesn't crash the server they r not bad

[16:37] Andrew Linden: A bit of viewer rumor/news: Merov was showing me this morning that he had fixed the bug that keeps some textures blurry unless you zoom in and look very closely.

[16:37] Baker Linden: awesome. I got a stockpile of "whoops" then

[16:37] TankMaster Finesmith: lol

[16:37] Vincent Nacon: where's Donald Trump when you need him?

[16:37] Jonathan Yap: Baker, at least you have the power to "unwhoops" yourself

[16:37] Vincent Nacon: "you're fired"

[16:38] Baker Linden: yeah, that's true

[16:38] Andrew Linden: Turns out if the texture was scaled very asymmetrically (much wider than tall for example) then it would typically not reach full clarity

[16:38] Vincent Nacon: you can unwhoop but it's better not to make whoopies at all

[16:38] Vincent Nacon: :P

[16:38] Baker Linden: indeed

[16:39] Motor Loon: ah I think I've seen that Andrew

[16:39] Jonathan Yap: Andrew, I wonder if that also fixes the issue of some animated textures freezing at certain camera positions

[16:39] Baker Linden: I've been working on some permission-related stuff as well. I'm currently working on SVC-4444

[16:39] JIRA-helper: http://jira.secondlife.com/browse/SVC-4444

[#SVC-4444] Objects become fully permissive when rezzed under certain conditions. - with Repro

[16:39] Motor Loon: really?

[16:40] Jonathan Yap: vwr-27836

[16:40] JIRA-helper: http://jira.secondlife.com/browse/VWR-27836

[#VWR-27836] Texture animation stops when zoomed in, restarts when zoomed out.

[16:40] Andrew Linden: good question Jonathan, dunno.

[16:41] Andrew Linden: I'll forward to Merov just in case.

[16:41] Jonathan Yap: Thank you

[16:41] Rex Cronon: 4444 is a bad one

[16:42] Motor Loon: real bad

[16:42] Andrew Linden: Merov does not know but says he'll check.

[16:42] Motor Loon: potential entire-business-breaking-bad

[16:42] Baker Linden: actually, do TPV's have the same issue?

[16:43] Motor Loon: I'd not even heard of that before

[16:43] TankMaster Finesmith: which ussue?

[16:43] Baker Linden: because from what I'm seeing, it's viewer side code that's causing the issue.

[16:43] Baker Linden: SVC-4444

[16:43] Motor Loon: I'm deff. going home to see if it happens with Firestorm

[16:43] Andrew Linden: right, I expect SVC-4444 to be server-side

[16:43] TankMaster Finesmith: the viewer can dictate the default permissions for newly created objects

[16:44] Motor Loon: err... so baker says viewer side... Andrew says server-side ?

[16:44] Vincent Nacon: I think it just doesn't understand how or when to apply permission that was in content of

[16:44] TankMaster Finesmith: in phoenic I added the ability to over ride the viewer server default with the user's preferences

[16:44] TankMaster Finesmith: the server defaults*

[16:44] Baker Linden: Andrew's probably correct.

[16:44] Vincent Nacon: but it still work when you apply the permission yourself before putting in anything

[16:44] Jonathan Yap: There is a patch attached

[16:44] Baker Linden: I just assume that now

[16:45] Baker Linden: I did the steps Maestro Linden posted on 4444 (21/Jun/11 1:01 PM)

[16:45] Motor Loon: oh yeah... there is a patch

[16:45] Vincent Nacon: I never saw this issue as "broken" just unintended logic flaw

[16:45] Jonathan Yap: but a viewer patch is not a good solution--some nefarious person might not be using it

[16:46] Rex Cronon: i think jonathan is right. with the "right" viewer...

[16:46] Motor Loon: wait a minute... viewers cant change permissions on an object you're given?!

[16:47] Motor Loon: if it's no mod, it bloodly well better stay no mod despite what viewer you're on

[16:47] TankMaster Finesmith: ^

[16:47] Baker Linden: I think the fix should be server-side as well; I just need to find where it happens

[16:48] Vincent Nacon: I don't think it's giving itself full permission, I think it just wasn't applied

[16:49] Motor Loon: but according to the repro, you can check the permissions after seting them to verify...

[16:49] Motor Loon: and yet they are supposed to change

[16:49] Rex Cronon: this seems similar to that bug where if u changed persm in inventory, on rez the changes didn't show. u had to rez it change perms, save it.

[16:49] Vincent Nacon: right

[16:50] Vincent Nacon: I think it's only applying to root of the prim but not its content

[16:50] Motor Loon: on the repo the edit is going on inworld aint it?

[16:50] Motor Loon: yeah, it'll apply to what prim you have selected in the linkset, not the entire linkset

[16:50] Rex Cronon: maybe this should be sec jira? seeing how is to reproduce it right now

[16:51] Rex Cronon: how easy is to*

[16:51] Motor Loon: is the repro verified?

[16:51] Motor Loon: if it is... I'd certaily think it was a SEC jira... and one to fix real quick too

[16:52] TankMaster Finesmith: ive seen packet loss cause permissions not to be set on an object, particularly when updating multiple objects at once

[16:52] Qie Niangao: yeah, it's at least *similar* to the slam bit effect, as it would arise with bulk permissions, but not sure. To me, it's not really that scary inasmuch as it would be evident when the seller tests with an alt.

[16:52] Motor Loon: ...but if you rightclick the object after to check it...and it shows as set as you wanted... it shouldnt change under any circumstances....

[16:52] Vincent Nacon: yeah, lag can happen

[16:52] Motor Loon: or?

[16:53] TankMaster Finesmith: in SL, lag is the constant

[16:53] TankMaster Finesmith: :D

[16:53] Moundsa Mayo: Lag just means the processor is DOING something.

[16:53] Motor Loon: well, I'm checking it after the meeting... it I can repro it...I'll do a SEC on it

[16:53] Ashiri Sands: Is the required fix a technical one or an educational one?

[16:54] Andrew Linden: The bug is 3 years old. I don't think it needs an SEC issue.

[16:55] Andrew Linden: there are probably other ways to create items for sale that don't have bugged perms

[16:55] Meeter: Timecheck : User Group is almost over

[16:56] Andrew Linden: but this recipe doesn't appear to do what the content seller expects

[16:56] Ashiri Sands: That is the real issue, it doesn't work as we naiivley expect

[16:57] Motor Loon: so... where in the repro are they doing something "wrong" ?

[16:58] Qie Niangao: well, I think they'd be wise to pull it into inventory after changing the perms, then setting it out again.

[16:58] Baker Linden: if you read the steps in the description of 4444, the way around it would seem to just remove the perms from "ItemForSale" before putting it in the container

[16:58] Motor Loon: "Now Customer comes along and he acquires "Boxed item for sale" from Shop Owner. It does not really matter how this happens, but for the sake of simplicity we say that Shop Owner gives "Boxed item for sale" to Customer (same thing would happen with llGiveInventory() from object, etc). Now customer proceeds to unpack his new item:"

[16:58] Rex Cronon: i find it kind of weird that there r no more comments since last year

[16:58] Motor Loon: that would mean they had taken it into inventory right?

[16:59] Qie Niangao: the buyer did, not the seller. but... the nestedness of the contents confuses me, too.

[16:59] Motor Loon: In order for me to give you something... I need it in my inventory...

[16:59] Motor Loon: otherwise you're buying it inworld

[16:59] Baker Linden: I think the jira figures when removing an item from the container, it should inherit the container's properties

[16:59] Andrew Linden: well, they probably aren't doing anything wrong, but the way we propagate perms change requests to the items inside box may be incorrect

[17:00] Baker Linden: when instead it retains its own perms

[17:00] Meeter: Thank you for coming to the Server User Group

[17:01] Baker Linden: I just pick bugs that are important to fix and then I figure out if it makes sense.

[17:01] Ashiri Sands: How are boxed assets handled by the server anyway?

[17:02] Andrew Linden: yeah, nested perms for inv items and items in contents are tricky

[17:03] Andrew Linden: when ObjectCreatort makes something and takes to asset, then modifies the next-owner perms in their inventory and gives to ObjectSeller... the perms deep inside the original asset are not changed.

[17:03] Andrew Linden: That is, the asset in ObjectCreator's inv is the same as the asset in ObjectSeller's inv, but the wrapping perms are different.

[17:03] Motor Loon: well, if you have a modifiable BOX... which inside has 2 scripts which both are set to no-modify... those scripts shouldnt become modifiable for the next owner just because the box is... right?

[17:03] Kelly Linden: Have a good weekend all.

[17:04] Moundsa Mayo: Kelly, thanks for your time and hard work!

[17:04] DrFran Babcock: thanks.

[17:04] Nalates Urriah: bye

[17:04] Rex Cronon: tc kelly

[17:04] TankMaster Finesmith: Take care kelly

[17:04] Nalates Urriah: I g2g

[17:04] Vincent Nacon: take care all

[17:04] DrFran Babcock: moi, aussi

[17:05] DrFran Babcock: thanks for all the info

[17:05] DrFran Babcock: and have a great weekend

[17:05] Rex Cronon: tc vincet

[17:05] Vincent Nacon: you too

[17:05] Motor Loon: Alrighty... until next time...ciao!

[17:05] Rex Cronon: vincent*

[17:05] Rex Cronon: tc all those leaving

[17:05] Andrew Linden: So when ObjectSeller puts in object contents... the asset is still the same. When ObjectSeller modifies the item's wrapping perms... they don't take affect until someone buys it.... but then it is the wrapper perms that result in ObjectBuyer's inv that are changed... the asset is still unchanged because it hasn't been rezzed in that chain yet.

[17:05] Andrew Linden: There are plenty of opportunities for things to be done incorrectly.

[17:06] TankMaster Finesmith: sounds fun...

[17:06] Ashiri Sands: what a nightmare for you

[17:06] TankMaster Finesmith: oh quick question andrew

[17:06] TankMaster Finesmith: any word on a physics stub for phath finding?

[17:06] Andrew Linden: Yeah, I don't think Baker has fully realized the labrynth that is a permission bug.

[17:06] Vincent Nacon: muhaha!

[17:06] Baker Linden: Looks like I gotta bust out Plan B

[17:06] Ashiri Sands: hmm?

[17:06] Vincent Nacon: or plan Z

[17:06] TankMaster Finesmith: B for braking things :P

[17:07] Rex Cronon: that is why when exploring the unknown is good to do it as a team:)

[17:07] Vincent Nacon: Z for zombie, which make great excuse for not getting things done

[17:07] Baker Linden: Where Plan B is: Cry, regroup, Cry again, Roll my face on the keyboard and hope I fix it

[17:07] Andrew Linden: TankMaster, Falcon says that it is slightly closer than it was two days ago, but we're still trying to figure out how to do it.

[17:07] Ashiri Sands: hah

[17:07] Moundsa Mayo: You must have an error signal to know what correction to make, how much, and in which direction.

[17:07] TankMaster Finesmith: ah ok, thx

[17:07] Vincent Nacon: now I have me a new Linden's quote, thanks Baker!

[17:08] Ashiri Sands: Plan B doesn't sound much fun

[17:08] Andrew Linden: Thanks for coming everyone.

[17:08] Baker Linden: lol

[17:08] Baker Linden: Plan B isn't fun at all.

[17:08] Moundsa Mayo: Andrew, Baker, thanks for your time and hard work!

[17:08] Ashiri Sands: Thanks Andrew and Baker

[17:08] TankMaster Finesmith: Thanks for your time and info, baker and andrew

[17:08] TankMaster Finesmith: have a grate weekend

[17:08] Qie Niangao: Thanks all... have fun!

[17:08] Baker Linden: Thanks for coming everyone. Enjoy your weekend!

[17:08] Vincent Nacon: aye

[17:08] Rex Cronon: tc andrew, baker and everybody. have a nice day all:)

[17:09] Rex Cronon: u 2



Simulator_User_Group

Prev 2012.05.29 Next 2012.06.05