Bug triage/2007-10-22/Transcript

From Second Life Wiki
< Bug triage‎ | 2007-10-22
Revision as of 13:37, 24 November 2008 by Zai Lynch (talk | contribs) ({{Bug triage}})
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Agenda

  • [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