Bug triage/2007-10-22/Transcript

[14:50] Multi Gadget: v1.52.0: Lunar Schertzinger, Sky Takakura
[14:50] Connecting to: in-world Voice Chat...
[14:50] Connected undefined:
[14:51] Multi Gadget: v1.52.0: Gigs Taggart, Daedalus Young
[14:51] Alexa Linden: Hey guys :D
[14:52] Daedalus Young: hi Alexa
[14:52] Multi Gadget: v1.52.0: Angel Fluffy
[14:53] Multi Gadget: v1.52.0: Soft Linden
[14:54] Daedalus Young: hi Soft
[14:54] Soft Linden: Hey hey!
[14:55] Alexa Linden: Hi Soft :)
[14:55] Soft Linden: Gigs delivers on the agenda :>
[14:55] Alexa Linden: yup
[14:55] Soft Linden: Y2K+38 bug
[14:55] Alexa Linden: as always
[14:55] Alexa Linden: thanks Gigs
[14:55] Gigs Taggart: :)
[14:55] Alexa Linden: Hi Angel
[14:55] Multi Gadget: v1.52.0: Harleen Gretzky
[14:55] Soft Linden: Oh hey, Angel!
[14:56] Angel Fluffy: howdy Soft, all :)
[14:56] Angel Fluffy: howdy Gigs :)
[14:58] Multi Gadget: v1.52.0: Squirrel Wood
[14:58] Gigs Taggart: Soft: here's a weird one for you, someone took a snapshot and got someone else's snapshot entirely. I'm thinking some rare UUID collision?
[14:58] Multi Gadget: v1.52.0: Boroondas Gupte
[14:58] Alexa Linden: I imported that one this morning
[14:58] Soft Linden: Yeah, someone reported a similar one with another texture...
[14:58] Alexa Linden: very odd one
[14:58] Soft Linden: Cool - what's the JIRA on that one? I'll link it to the other I saw
[14:58] Gigs Taggart: oh so it's more widespread then
[14:58] Gigs Taggart: I thought it was a weird UUID collision fluke
[14:58] Soft Linden: Well, at least twice between the two
[14:59] Boroondas Gupte: hi all, brb
[14:59] Alexa Linden: well the one I imported had 8 votes already
[14:59] Multi Gadget: v1.52.0: WarKirby Magojiro
[14:59] Alexa Linden: let me see... brb
[14:59] Multi Gadget: v1.52.0: Marshall Outlander
[14:59] Multi Gadget: v1.52.0: Rob Linden
[14:59] Squirrel Wood: missing images? [1]
[14:59] Multi Gadget: v1.52.0: Able Jameson
[14:59] Soft Linden: If the snapshot is the same one I saw referenced in a blog, it was another picture taken on the same island, which makes me think there might be something with the wrong texture being saved once a UUID is assigned.
[14:59] WarKirby Magojiro: Am I late
[15:00] Soft Linden: Ack, two internally on DEV-3985
[15:00] Rob Linden: / brb
[15:01] WarKirby Magojiro: a few interesting issues in here
[15:02] WarKirby Magojiro: Agenda says web-`79 first
[15:02] Daedalus Young: yep
[15:02] WarKirby Magojiro: 179*
[15:03] Gigs Taggart: web-179 really needs to be fixed, it's embarassing that the web site is never updated when things change.
[15:03] WarKirby Magojiro: Fast Track import
[15:03] WarKirby Magojiro: is this something that even needs to be discussed, then?
[15:04] WarKirby Magojiro: looks around at everyone...
[15:04] Gigs Taggart: no, it's obviously broken and would be a 5 minute change
[15:04] Squirrel Wood: A clear case of 404 ^^
[15:05] WarKirby Magojiro: import and move on, then?
[15:05] Boroondas Gupte: I'd say so
[15:05] Soft Linden: Sure, that can go right in.
[15:05] Soft Linden: I just checked - it's still wrong.
[15:05] Alexa Linden: noted
[15:05] WarKirby Magojiro: Vwr 786 is next
[15:05] WarKirby Magojiro: this does warrant some discussion
[15:06] Boroondas Gupte: expected behaviour, unexpected side effects :-/
[15:06] Gigs Taggart: I don't know, I'm against this whole "hiding online status" thing entirely, so I don't know what else I can say.
[15:06] WarKirby Magojiro: I'm with Gigs, personally
[15:06] WarKirby Magojiro: I don't think this would be much help in any case
[15:06] Soft Linden: 16 votes in 5 months on a feature request isn't a lot.
[15:07] WarKirby Magojiro: there are always friendship offers
[15:07] WarKirby Magojiro: inventory offers
[15:07] WarKirby Magojiro: scripted online detectors
[15:07] WarKirby Magojiro: etc, etc
[15:07] Boroondas Gupte: I'm for hiding status if possible, but don't pretend to be hiding if we actually can't
[15:07] WarKirby Magojiro: Truly hiding online status is not possible
[15:07] WarKirby Magojiro: and it would require a lot of change to make it so
[15:07] Soft Linden: You can use a friendship offer, use several different LSL functions, send inventory... changing this would have minimal impact. We'd have to decide hiding as a larger project was worthwhile.
[15:08] Daedalus Young: I think if you don't want people to know you're online, just create an alt
[15:08] Alexa Linden: lol
[15:08] Squirrel Wood: Right now you cannot hide at all.
[15:08] WarKirby Magojiro: precisely
[15:08] Mick Linden: Hi folks
[15:08] Squirrel Wood: except to maybe a newbie or someone who doesn't know the tricks
[15:08] WarKirby Magojiro: secret alts are the best way
[15:08] Boroondas Gupte: hi Mick
[15:08] Daedalus Young: hi
[15:08] Alexa Linden: hey Mick
[15:08] WarKirby Magojiro: most workable, at any rate
[15:08] Soft Linden: Anyway, my vote is I'd leave this alone - if it got a ton of votes, that would be different.
[15:08] Alexa Linden: leave as-is for now?
[15:08] Daedalus Young: on the Linden seats? :P
[15:09] WarKirby Magojiro: I would say so Alexa, yes
[15:09] Alexa Linden: k
[15:09] Daedalus Young: hi Aric
[15:09] Multi Gadget: v1.52.0: Dirk Talamasca
[15:09] Aric Linden: heya Daedalus
[15:09] Daedalus Young: 331
[15:09] Aric Linden: Sorry I'm late folks
[15:09] Angel Fluffy: More generally, it seems to me that most privacy functions in SL essentially depend on getting an alt. I mean, you can't hide groups in your profile without the owner's consent, you can't hide your online status, you can't set a 'busy' mode that blocks peoples' IMs with a message like "for support, please go to [2] and file a ticket". Privacy in SL seems to be based around the idea of "if you want privacy, get an alt". While it would be very nice to change that, it would be a huge pile of work, too.
[15:09] Squirrel Wood: seems to be clear enough to warrant an import?
[15:10] WarKirby Magojiro: resolved
[15:10] Multi Gadget: v1.52.0: Tess Linden
[15:10] WarKirby Magojiro: oh
[15:11] WarKirby Magojiro: this is annoying
[15:11] Aric Linden: What's that?
[15:11] Soft Linden: Is there any good reason for clamping Z below the buildable altitude?
[15:11] WarKirby Magojiro: Altitude on teleports in general has always been a bit messed up
[15:11] Aric Linden: I think that with havok1 there may've been reasons
[15:11] Daedalus Young: but you ususally can tp higher than 128
[15:11] WarKirby Magojiro: I really don't think there is, soft. And It's causing a lot of problems for at least one person I know
[15:11] Daedalus Young: I often tp at 256m height
[15:11] Aric Linden: But I think havok 4 has none of those restrictions
[15:12] Soft Linden: Sure, an awful lot of clubs are in the 500-700 range.
[15:12] Alexa Linden: yup
[15:12] WarKirby Magojiro: She has a store high up,. and it's impossible to SLURL to it
[15:12] WarKirby Magojiro: causing lost sales from people haviong trouble finding the place
[15:12] Soft Linden: I believe teleport points are also forced below ~200m.
[15:12] Daedalus Young: so whatever is the highest possible in Havok1 should be possible in SLurls
[15:12] Aric Linden: Let's take it and if havok4 resolves it, we can mark it as such
[15:12] Alexa Linden: noted at import
[15:12] Alexa Linden: as*
[15:13] Soft Linden: teleport point = landoing point. The default TP location for a parcel.
[15:13] Multi Gadget: v1.52.0: Squirrel Wood
[15:13] Entered chat: range: Squirrel Wood
[15:13] WarKirby Magojiro: If it's possible to teleport to above 128, why are SLURLS clamped?>
[15:13] Alexa Linden: WB Squirrel
[15:13] WarKirby Magojiro: are slurl teleports different from normal?
[15:13] Daedalus Young: that's the issue yes, WK
[15:13] Boroondas Gupte: I think the website shouldn't do any clamps. if any are neccessairy the sim should do them.
[15:13] Gigs Taggart: yes this issue is with the slurl web site
[15:13] Gigs Taggart: havok should have no effect
[15:13] Soft Linden: Anyone against importing?
[15:13] Aric Linden: Nope
[15:13] Daedalus Young: they're the same, the poster says using a higher value directly in secondlife:// addresses work
[15:13] WarKirby Magojiro: please do
[15:13] Alexa Linden: noted
[15:13] Squirrel Wood: yes! teleport to -323312365456m
[15:14] Aric Linden: bleh
[15:14] Aric Linden: pjira is SLOOOOW today
[15:14] Squirrel Wood: it is even sloooower for us mortals ^^
[15:14] Harleen Gretzky: and secondlife:// URLs work, it is only slurl.com that is clamped
[15:14] Multi Gadget: v1.52.0: Azuruk Botha
[15:14] Aric Linden: VWR-2388
[15:15] Alexa Linden: Object Chat/IMs are untraceable
[15:15] WarKirby Magojiro: For those not aware, the spinning disc in the Centre is an URLer. Clicking it opens a webpage on the isse shown above
[15:15] WarKirby Magojiro: This is a very severe issue,
[15:15] WarKirby Magojiro: and is being exploited by many griefers
[15:15] Soft Linden: I think we want this fixed, but we can use Dale's patch when he submits it.
[15:15] Gigs Taggart: Is llLoadURL broken in linux for anyone else?
[15:16] WarKirby Magojiro: Dale hasn't updated his viewer in quite a while, though
[15:16] Gigs Taggart: Soft: I believe he's still waiting for CAPS
[15:16] WarKirby Magojiro: or responded to IMs
[15:16] Aric Linden: Soft, do you know how far away his patch is from being ready?
[15:16] WarKirby Magojiro: He mentioned requiring a key2name function for sims,
[15:16] Soft Linden: He was going to submit it with a "insert caps here" in the patch, last I knew.
[15:16] Harleen Gretzky: Dale's viewer has an issue in that the sim comes back as an UUID, he supplies an XML to translate the name
[15:16] Soft Linden: I'll ask him, Aric.
[15:16] Aric Linden: thanks
[15:16] WarKirby Magojiro: in any case, thogh
[15:17] WarKirby Magojiro: that's not the only solution
[15:17] WarKirby Magojiro: even without that functionalirty
[15:17] WarKirby Magojiro: it's still quite possible to get the owner name
[15:17] WarKirby Magojiro: and mute them
[15:17] WarKirby Magojiro: Knowing where the object is, isn't quite so important
[15:17] Squirrel Wood: I wonder if llGetObjectDetails will work on that UUID ?
[15:17] WarKirby Magojiro: as just eing able to mute the owner
[15:17] Daedalus Young: you should, it comes from an object, you should be able to know the owner of the object
[15:18] WarKirby Magojiro: I think it would be good to at least get interim functionality for that
[15:18] WarKirby Magojiro: til dale can finish his patch
[15:18] Harleen Gretzky: They can where it as an attachment to get around that, and llGetObjectDetails would only work smae sim
[15:18] WarKirby Magojiro: it really is a terrible vulnerability
[15:18] Harleen Gretzky: *waer
[15:18] Harleen Gretzky: *wear
[15:18] Alexa Linden: so the action on this Jira is?
[15:18] WarKirby Magojiro: I've seen it being used to crash a client
[15:18] WarKirby Magojiro: through sheer volume of IMs
[15:19] Daedalus Young: it's the same as the texture spam, that has prevention now
[15:19] Aric Linden: WarKirby, that's why I asked how far away dale's patch is
[15:19] Squirrel Wood: ye... 100 prims in an attachment, all spamming a given person... ouch
[15:19] Boroondas Gupte: action: assign to Dale :-P
[15:19] Alexa Linden: lol
[15:19] WarKirby Magojiro: We've been waiting weeks for it, though
[15:19] Aric Linden: If he's close, we should grab it asap, if he's far out still, we *should* explore interim or alternative choices
[15:19] Soft Linden: Well, we can import with a note to ask Dale. :)
[15:19] WarKirby Magojiro: I think we need an interim solution
[15:19] Harleen Gretzky: I am using Dale's viewer now, it is working in it's present state, just some sims come back as UUID instead of name
[15:20] WarKirby Magojiro: yeps
[15:20] Aric Linden: I agree with soft. With the caveat that we may need to revisit next week
[15:20] Multi Gadget: v1.52.0: Able Jameson
[15:20] Aric Linden: and reprioritize.
[15:20] WarKirby Magojiro: I find dale's viewer unuseable for perfpormance issues, sadly.
[15:20] Aric Linden: work for you, WarKirby?
[15:20] WarKirby Magojiro: alright
[15:20] WarKirby Magojiro: seems good
[15:20] Aric Linden: Thanks!
[15:20] Multi Gadget: v1.52.0: Gigs Taggart
[15:20] Entered chat: range: Gigs Taggart
[15:21] Alexa Linden: next is VWR-996
[15:21] Aric Linden: VWR-996
[15:21] WarKirby Magojiro: vwr 996 is next
[15:21] Alexa Linden: wrong visualisation of animations
[15:21] Gigs Taggart: 996 seems related to that inner loop bug
[15:21] Gigs Taggart: I don't know enough about animations to say if it's a duplicate
[15:22] WarKirby Magojiro: I've observed this, too
[15:22] WarKirby Magojiro: I think limbs that aren't moved
[15:22] WarKirby Magojiro: seem to take on a slightly random movement of their own
[15:22] WarKirby Magojiro: I managed to work around it by making sure every single joint was keyframed
[15:22] WarKirby Magojiro: and using priority 4
[15:22] WarKirby Magojiro: not ideal, though
[15:22] Gigs Taggart: yeah it seems there's a big mess with animations right now
[15:23] Soft Linden: It's likely that keyframes aren't generated for the loop/cut point
[15:23] Aric Linden: are you seeing other issues, Gigs?
[15:23] Gigs Taggart: Aric: yeah there's been a lot of bugs about animations recently.
[15:23] Aric Linden: nods
[15:24] WarKirby Magojiro: I would say to import this, personally
[15:24] Soft Linden: There are a lot of long-standing animation bugs. I think any like this that include a nice repro should come in for a look at least.
[15:24] Aric Linden: agrees with soft
[15:24] Aric Linden: let's take it
[15:24] Alexa Linden: noted
[15:24] Alexa Linden: next is patch VWR-2739
[15:24] Alexa Linden: time_t is assumed to be 32 bit when it is not on all systems
[15:25] Gigs Taggart: schedule this to be merged prior to 2037
[15:25] Gigs Taggart: if we import it now, it might make it in by then :P
[15:26] Soft Linden: Yeah, VWR-2739 is a bad assumption. We'll go 64-bit on the servers sooner or later, so we should fix that throughout the code.
[15:26] Harleen Gretzky: Apparently it effects 64-bit systems now though
[15:26] Gigs Taggart: the patch can't possibly be all that is needed
[15:27] Harleen Gretzky: It is more of a workaround
[15:27] Soft Linden: No. It should be a more general issue about checking time_t throughout the code.
[15:27] Gigs Taggart: in fact, I'm not sure what the patch does :)
[15:27] Soft Linden: If we import, I can clean up the description to suggest that.
[15:27] Daedalus Young: "Patch attached that inverts the maths and fixes the nasy date/time display issue on 64 but linux"
[15:27] Gigs Taggart: so it's just fixing a display issue
[15:27] Aric Linden: Might make sense to have it reviewed internally
[15:28] Boroondas Gupte: the patch replaces singed variables by unsigned to avoid a typecast
[15:28] Boroondas Gupte: (if I got it right)
[15:29] Daedalus Young: well I say at least have a good look at it and test it, you'll have to mess with time sooner or later
[15:29] WarKirby Magojiro: has insufficient knowledge to comment on this issue
[15:29] Gigs Taggart: just beware temporal chaos
[15:29] Alexa Linden: noted - import, have soft change descript.
[15:29] Alexa Linden: next is WEB-166
[15:30] Alexa Linden: Land Store map is extremely difficult to read
[15:30] Gigs Taggart: I spoke with Jack about this
[15:30] Gigs Taggart: Jack says there's a plan for a big overhaul on the land store
[15:30] WarKirby Magojiro: oh, good.
[15:30] WarKirby Magojiro: I had a look at it once, and couldn';t find anything very easily
[15:30] Alexa Linden: same
[15:30] WarKirby Magojiro: A thought...
[15:30] Gigs Taggart: So I'm not sure if this bug needs action specifically, it seems well known that the land store really sucks.
[15:30] WarKirby Magojiro: maybe something like that would bne better not done on the web
[15:31] WarKirby Magojiro: maybe a doownloadable program or somesuch
[15:31] WarKirby Magojiro: or even through the client, perhaps..
[15:31] Gigs Taggart: I'm not sure what to do with the bug, I mean, it's valid, but it should be fixed when this new land store, rewritten from the ground up comes out.
[15:31] Aric Linden: I think it's worth taking and passing to either RX oa
[15:31] Aric Linden: of a residents problem
[15:32] Alexa Linden: noted
[15:32] Squirrel Wood: mayhaps comment in that an overhaul is planned and close ?
[15:32] Soft Linden: Is there an existing JIRA for the landstore rework? It could be linked to that just to list the things that should be improved.
[15:32] Gigs Taggart: Squirrel, I wouldn't say close
[15:32] Gigs Taggart: The way he talked, it was just getting designed now
[15:33] WarKirby Magojiro: A jira for it would be good
[15:33] Dirk Talamasca: In Progress
[15:33] Squirrel Wood: then leave it open. but a comment it needs.
[15:33] Gigs Taggart: maybe assign to workingonit
[15:33] Aric Linden: That works, Gigs
[15:33] Gigs Taggart: soft: yeah we could create a metaissue too
[15:33] Aric Linden: I don't know if anyone is actively working on the land store re-write right now or if it's in the "under discussion" phase
[15:34] Aric Linden: I think it might be under discussion, in which case, adding fuel is a good thing.
[15:34] Gigs Taggart: Aric, it is badly needed in any case, if we need to collect the dozens of things seriously broken to help the case... we easily can :)
[15:34] Alexa Linden: next is SVC-120
[15:35] Alexa Linden: Objects -> Permissions -> Modify Rights -> affects Return ability
[15:35] Gigs Taggart: right so this is a prokofy bug, I filed for her
[15:35] WarKirby Magojiro: As per my last comment there
[15:35] WarKirby Magojiro: I think it would be good to have two seperate categories
[15:35] Gigs Taggart: The key here is that the UI says "modify" which the lay user doesn't understand to mean "return or delete", they are going to think modify means modify
[15:35] WarKirby Magojiro: one only allowing modification
[15:36] WarKirby Magojiro: and one allowing taking and returning, too
[15:36] Daedalus Young: I agree with that
[15:36] Soft Linden: I'm not sure the behavior should change, but the permission should be more clear.
[15:36] Gigs Taggart: yeah it's mainly a communication thing
[15:36] Boroondas Gupte: I don't quite see the use for splitting "can modify"
[15:36] Aric Linden: I think RX needs to weigh in here.
[15:36] Rob Linden: modify==ruin
[15:36] Squirrel Wood: either clarify or prevent return/delete ?
[15:36] WarKirby Magojiro: Say you want to do a custom building project with someone
[15:36] Aric Linden: there's clearly a workflow and expectations problem
[15:36] WarKirby Magojiro: you generally grant modify rights, and vice versa
[15:36] Soft Linden: Maybe a pop-up clarifying exactly what you're granting when you give someone this permission.
[15:37] WarKirby Magojiro: if they were malicious
[15:37] Boroondas Gupte: if you can edit an object you can shrink it to invisibility which is much worse than just returning it
[15:37] WarKirby Magojiro: they could suddenly run and steal your house
[15:37] Squirrel Wood: A pop up would work well methinks
[15:37] Soft Linden: But RX's call :)
[15:37] WarKirby Magojiro: I'm more worried about the take action, than anything
[15:37] Aric Linden: yeah, but then we need to figure out all the places where we might want to caution users for consistency
[15:37] Soft Linden: Import, assign to RX with a note about clarifying the UI?
[15:37] Rob Linden: when you're giving "modify" privs, you're giving "ruin" privs. I think it's most likely an education issue, with perhaps some inline help
[15:37] Squirrel Wood: cause it makes it clear that you have to make a conscious decision there
[15:37] Alexa Linden: noted
[15:37] WarKirby Magojiro: It allows that peerson to take any transferable objects you have
[15:38] Aric Linden: otherwise it's a sleigh ride to hades
[15:38] Alexa Linden: lol
[15:38] Alexa Linden: next is WEB-86
[15:38] Alexa Linden: Transaction History Total Bug when paying self owned object
[15:38] Aric Linden: Alexa, who are you assigning that last one to?
[15:38] Alexa Linden: RX team, I can ask you later which person
[15:38] Gigs Taggart: WEB-86 is ancient
[15:38] Aric Linden: perfect. thanks
[15:39] WarKirby Magojiro: this one is annoying
[15:39] Gigs Taggart: yeah
[15:39] WarKirby Magojiro: whenever there's an equal value in credit and debit columns
[15:39] WarKirby Magojiro: they should cancel out to 0
[15:39] Daedalus Young: web-86 I think is because the self-payment has one ID
[15:39] Gigs Taggart: this should be simple to supress
[15:39] Soft Linden: Ha - yeah, this is silly and wrong!
[15:39] Daedalus Young: so the Transactions thingy only performs one action on it
[15:40] Aric Linden: This is another area of the code that is being worked on.
[15:40] Aric Linden: Let's import this as a stimulant. :-)
[15:40] Soft Linden: grins
[15:40] WarKirby Magojiro: yay
[15:40] Daedalus Young: simply forgets to check if maybe it needs to do more things
[15:40] Boroondas Gupte: :-)
[15:40] Alexa Linden: got it
[15:40] Aric Linden: thanks
[15:40] Daedalus Young: cool
[15:40] Aric Linden: you can assign it to me and I'll, um, share with lux
[15:40] Alexa Linden: next up
[15:40] Alexa Linden: VWR-242
[15:40] Alexa Linden: k
[15:40] Daedalus Young: I'm surprised it has so few votes
[15:40] Gigs Taggart: VWR-2426
[15:40] WarKirby Magojiro: 2426
[15:41] Alexa Linden: Missing character in email sent with llEmail
[15:41] Gigs Taggart: we need a recent repro on this
[15:41] Gigs Taggart: anyone know if it still happens?
[15:42] WarKirby Magojiro: hmm
[15:42] Soft Linden: I'll real quick test
[15:42] WarKirby Magojiro: anyone care to test now?
[15:42] Daedalus Young: I haven't tried it no
[15:42] Squirrel Wood: doesn't a . at the beginning of a line tell the mailserver that this is the end of the mail body ?
[15:42] Gigs Taggart: k
[15:42] Gigs Taggart: squirrel, no, . on a line by itself is end of message
[15:42] Squirrel Wood: or that.
[15:42] Squirrel Wood: Which may be the reason it is filtered out ?
[15:42] Gigs Taggart: but it's likely some code to gaurd against premature end of message breaking this
[15:42] Gigs Taggart: yeah
[15:43] WarKirby Magojiro: oki.
[15:43] WarKirby Magojiro: emailing myself now
[15:43] Soft Linden: Still happens.
[15:43] Squirrel Wood: I'd just go and insert a space rather than eating the dor
[15:43] Squirrel Wood: dot
[15:43] Aric Linden: i think we should take this
[15:43] Alexa Linden: noted
[15:43] Gigs Taggart: squirrel that's dangerous, you'll break message signatures
[15:43] WarKirby Magojiro: yeps
[15:43] WarKirby Magojiro: confirmed
[15:44] Daedalus Young: just check if the line starts with a dot AND the line is 1 character
[15:44] Aric Linden: it's not big, i don't think. sort of perfect for a new blacklighter, don't you think, soft?
[15:44] WarKirby Magojiro: A dot is eaten immediately following a line break
[15:44] Soft Linden: Sure, this would be great for someone learning server code.
[15:44] Alexa Linden: next is SVC-128
[15:44] Alexa Linden: automatic deletion of group leaves any owned property in "limbo
[15:44] Gigs Taggart: SVC-128 is a sticky one
[15:45] Gigs Taggart: You all may want to go wontfix on that... I donno.
[15:45] WarKirby Magojiro: I think, in this case
[15:45] WarKirby Magojiro: some sort of alert should be added
[15:45] WarKirby Magojiro: to automatically notify a linden to come rectify the situation
[15:45] Soft Linden: I believe if an object is returned on group-owned land, it goes to the person who set it down/deeded it. So we do retain the last owner. We should revert it to that.
[15:45] Aric Linden: pjira is driving me nuts today
[15:46] Gigs Taggart: Soft: what about the abuse case of dumping tier on an unsuspecting person who is away from SL for a few months/
[15:46] Boroondas Gupte: I think groups shouln't expire at all. They seem to stay in the databse anyway (or why else can't the group's name be reused?)
[15:46] Soft Linden: Ah - I'm thinking of objects for that, not the parcels.
[15:46] WarKirby Magojiro: I don't think any technical solution should be used for this
[15:47] Squirrel Wood: Yep. definitely the objects should be set back to their owners
[15:47] WarKirby Magojiro: these are cases where intervention of an intelligent person is needed, I think
[15:47] Multi Gadget: v1.52.0: PulseBurst Flow
[15:47] Gigs Taggart: Yeah parcels get sticky because of the tier
[15:47] Gigs Taggart: giving land back to someone can cost them a lot
[15:48] Soft Linden: How do we handle groups with more land than there is tier donated? This just seems to be a degenerate case of that - 0 tier is donated at this point.
[15:48] Gigs Taggart: yeah it might be ok if the land reverts to gov linden before the group is dissolved in an undertier and undermanned group
[15:48] Aric Linden: it seems as though we need to import this and work through the use cases
[15:48] Aric Linden: present it back either to sldev or dev internally or both
[15:48] Alexa Linden: noted
[15:48] Alexa Linden: MISC-150
[15:49] Alexa Linden: When a child prim moves with llSetPos, any avatar sitting on it does not move
[15:49] Aric Linden: Does that work for y'all?
[15:49] Multi Gadget: v1.52.0: Soft Linden
[15:49] Gigs Taggart: Aric: yeah
[15:49] Entered chat: range: Soft Linden
[15:49] Gigs Taggart: MISC-150, I've reproduced personally
[15:49] Aric Linden: Thanks gigs. You want to help with the use cases?
[15:49] Squirrel Wood: Well, if land is dumped on someone then they should well be informed about it ?
[15:49] Aric Linden: grins sneakily
[15:49] Gigs Taggart: Aric if you want hehe
[15:49] WarKirby Magojiro: THis is reproducible
[15:49] Aric Linden: thanks. that'd be awesome.
[15:49] WarKirby Magojiro: but is it a bug?
[15:49] Daedalus Young: another case of "it's correct, but unexpected"
[15:50] WarKirby Magojiro: you don't really sit on a prim, as such
[15:50] Gigs Taggart: Warkirby: I don't know if havok4 changes it
[15:50] Gigs Taggart: but in any case it is unexpected
[15:50] WarKirby Magojiro: just on the linkset, at the location that prim determines, isn't it?
[15:50] Milo Linden: thats already in jira
[15:50] Milo Linden: SL-22956
[15:50] Daedalus Young: this would be solved by a hierarchy
[15:50] Soft Linden: If this has always been the case, it would break content to change it.
[15:50] Daedalus Young: you can't sit on a child prim
[15:50] Gigs Taggart: Soft: doubtful anyone relies on that
[15:50] Gigs Taggart: Daedalus you sure can.
[15:50] WarKirby Magojiro: no, soft is right
[15:50] Squirrel Wood: if the child prim defines the sit target?
[15:50] Daedalus Young: well yes, but technically you still sit on the root
[15:50] WarKirby Magojiro: this would cause poeople to be moved around
[15:50] WarKirby Magojiro: where they had previously stayed still
[15:51] Squirrel Wood: you sit at the far end of the linkset ;)
[15:51] Gigs Taggart: is anyone moving child prims people are sitting on?
[15:51] WarKirby Magojiro: We have the llSetLinkPrimitiveParams "hack" for moving sitting avatars
[15:51] Gigs Taggart: that seems unlikely
[15:51] WarKirby Magojiro: yes, Gigs
[15:51] Daedalus Young: afaik, there is one root and everything, including avatars, are linked to that
[15:51] WarKirby Magojiro: I do a lot of prim transformation work
[15:51] WarKirby Magojiro: And I can certainly forsee doing it with vehicles
[15:51] Soft Linden: Right. Everything is represented relative to the root internally. A sitting avatar is just tacked onto the end of that list.
[15:52] Gigs Taggart: well in any case we can just associate this with the internal bug milo mentioned and be done with it for now :)
[15:52] Alexa Linden: I can Gigs
[15:52] Daedalus Young: sounds good
[15:52] WarKirby Magojiro: I think we could do with a new, officially documented function for moving a seated avatar
[15:52] WarKirby Magojiro: but aside from that, I don;'t think this case should be changed
[15:52] WarKirby Magojiro: mark as won't fix, with an explanation of breaking content, perhaps
[15:53] Alexa Linden: next is SVC-141
[15:53] Alexa Linden: Restrict Pushing disallows pushes from objects set to group
[15:53] Squirrel Wood: llMoveAvatar(), technically a wrapper for llSetLinkPrimParams but with an additional check the link number is actually an avatar ?
[15:53] WarKirby Magojiro: that's not good
[15:53] WarKirby Magojiro: Ever visited "The Future" sim ?
[15:53] Alexa Linden: no
[15:53] Daedalus Young: yes
[15:53] WarKirby Magojiro: they have these neat transport tubes which push you around
[15:53] Daedalus Young: very fun
[15:53] WarKirby Magojiro: indeed
[15:54] Gigs Taggart: SVC-141, I haven't reproduced this specifically but I did notice the push rules got more strict later.
[15:54] WarKirby Magojiro: and a very good, benevolent use of llPushObject
[15:54] Aric Linden: I wonder what caused them to be restricted.
[15:54] Gigs Taggart: Cube might know
[15:54] WarKirby Magojiro: I think pushing needs a tiered setting, like building
[15:54] Aric Linden: let me rephrase that: was it accident or intent that made them change
[15:54] Gigs Taggart: right
[15:54] WarKirby Magojiro: choose whether to allow anyone, only group members/object, or nobody
[15:54] Squirrel Wood: there may have been a very valid reason as to why they got stricter
[15:55] Gigs Taggart: there was no changelog announcement about the rules changing that I remember
[15:55] Gigs Taggart: they just got tighter after a month or so
[15:55] WarKirby Magojiro: undocumented changes aren't nice
[15:55] Aric Linden: agreed.
[15:55] Aric Linden: wholeheartedly
[15:55] Aric Linden: let's take this and i'll get an internal discussion going
[15:55] WarKirby Magojiro: Like the change to physical opbjects using llTargetOmega
[15:55] Aric Linden: Alexa, please go ahead and assign this one to triage.
[15:55] Alexa Linden: done
[15:56] Squirrel Wood: bulk upload... I have to complain about not being able to upload text files into notecards ^^
[15:56] WarKirby Magojiro: that#s a good point, squirrel
[15:56] WarKirby Magojiro: it would be nice to have bulk upload for animations too..
[15:56] Gigs Taggart: VWR-558 - is confirmed a million times over. It's caused by the GTK UI blocking everything, including the network.
[15:57] Aric Linden: Gigs, do you know how complex the fix is?
[15:57] Gigs Taggart: not sure, it involved voodoo and threading :)
[15:57] Gigs Taggart: doesn't do concurrency that well
[15:57] Aric Linden: laughs
[15:57] Aric Linden: doesn't all coding involve voodoo and threading?
[15:58] Gigs Taggart: it could be done in open source, possibly, but I'm not sure how hard... Soft any idea?
[15:58] Boroondas Gupte: voodoo, yes, but there are one-treaded programs, too
[15:58] Boroondas Gupte: *threaded
[15:58] Aric Linden: laughs again
[15:58] Soft Linden: Sec...
[15:59] Soft Linden: Blegh. I think the OS-native file dialog runs in the main viewer thread, so it blocks everything - message handling, render updates, etc.
[15:59] Gigs Taggart: yeah that's what it is
[15:59] Gigs Taggart: it's blocking everything
[15:59] Soft Linden: This should run in its own thread. It could be fixed entirely viewer-side.
[15:59] Squirrel Wood: modal dialog ?
[15:59] Gigs Taggart: but how hard?
[16:00] Soft Linden: Shouldn't be very hard. It could be treated more like the regular dialogs, with just a stub interface that takes update calls like the normal dialogs, waiting for data to be committed.
[16:00] Soft Linden: Probably 2 days of some developer's time.
[16:01] Aric Linden: if it's crashing, we should probably address it
[16:01] Gigs Taggart: ok, I'll associate it with the open source metabug, but I don't know how many people will be able to do it
[16:01] Soft Linden: I guess it's not unreasonable to think that someone would take a few minutes to pick-and-choose files for bulk upload, so yeah - this would be frustrating to content developers.
[16:01] Gigs Taggart: it's frustrating to me with single files, if I have to dig for them
[16:01] WarKirby Magojiro: I've taken to putting all the filed in a folder beforehand
[16:02] Boroondas Gupte: one could look at how other programs handle it ... SL can't be the only application that requires GTK dialogs to be non-blocking
[16:02] Squirrel Wood: I would favor a drag & drop method - simply drag the files you want to upload into the client window
[16:02] Soft Linden: I don't think this is just GTK. I'm pretty sure this blocks on other viewers too.
[16:02] Soft Linden: Yeah, the message loop stops on my Mac too.
[16:02] Gigs Taggart: Soft isn't that dialog GTK on all platforms?
[16:03] Gigs Taggart: I didn't know it was native...
[16:03] Soft Linden: I thought just Linux was, but I could be way wrong.
[16:03] Gigs Taggart: I don't know for sure either
[16:03] Squirrel Wood: drag & drop ^^
[16:03] Soft Linden: It's definitely a native dialog, but that could be invoked via GTK I guess.
[16:04] Squirrel Wood: shouldn't be all too hard to get it working
[16:04] Aric Linden: I wonder if we should get RX input on this?
[16:04] Rob Linden: I would be /extremely/ surprised if we were using GTK on windows/mac
[16:04] Gigs Taggart: Aric: what for? It's pretty straightforward, no UI changes needed.
[16:04] Soft Linden: Well, the fact that waiting in a dialog disconnects you or crashes isn't really a usability issue. It's definitely a bug - just a question of priority.
[16:04] Alexa Linden: do we want to import this then and you can tell me who to assign to Aric?
[16:05] Aric Linden: I was addressing the workflow issues around drag and drop etc
[16:05] Gigs Taggart: oh
[16:05] Gigs Taggart: Scope creep :)
[16:05] Aric Linden: laughs
[16:05] Gigs Taggart: we should just fix the bug hehe
[16:05] Aric Linden: heh, yep.
[16:06] Alexa Linden: importing then
[16:06] Squirrel Wood: drag & drop files - "Do you rly want 2 upload the files #1, #2, ..., #n ? <yes><no>"
[16:07] Aric Linden: heh. I think that closes out the hour folks.
[16:07] Gigs Taggart: Squirrel that's a lot of platform specific code for not much benefit. :()
[16:07] Aric Linden: lovely session this week.
[16:07] Alexa Linden: I'll have everything posted tomorrow
[16:07] Aric Linden: Gigs, you doing the agenda for weds's meet?
[16:07] Dirk Talamasca: Thanks Alexa
[16:07] Gigs Taggart: Aric, I can

Bug triage/2007-10-22/Transcript

Navigation menu

Search