Simulator User Group/Transcripts/2012.07.06
| Prev 2012.07.03 | Next 2012.07.10 |
List of Speakers
| Ardy Lay | Chieron Tenk | Dahlia Trimble |
| Draconis Neurocam | Fox Oxbar | Jane1 Bookmite |
| Jonathan Yap | Kelly Linden | Krashnburn Hillquit |
| Martinrj Fayray | Michi Lumin | Rex Cronon |
| Sahkolihaa Contepomi | Siana Gearz | Simon Linden |
| Squirrel Wood | Valinye |
Transcript
[16:03] Simon Linden: I guess I can start with the news ... we aborted the main grid roll out Thursday morning
[16:03] Sahkolihaa Contepomi: Squirrel, that doesn't help. At all.
[16:03] Ardy Lay: Simon, do we want to know why?
[16:03] Simon Linden: I don't think you do, actually
[16:03] Sahkolihaa Contepomi: Hooooboy.
[16:04] Michi Lumin: c_c
[16:04] Ardy Lay: Heh, okay
[16:04] Rex Cronon: .
[16:04] Dahlia Trimble: now we really want to know
[16:04] Simon Linden: I'm not sure what we've annoucned, but I can at least say it wasn't the SL code
[16:04] Jonathan Yap: Oskar told us more, see what you get for missing meetings peeps :)
[16:04] Simon Linden: You may have noticed some some grid problems that morning, they were what made us stop
[16:04] Ardy Lay: This is the only meeting that doesn't conflict with my work schedule.
[16:04] Michi Lumin: Related to the new Debian version?
[16:05] Simon Linden: Yeah, so whatever Oskar said. I apologize that I don't know what's OK to talk about or not here, but the new code should be going out on Tuesday
[16:05] Dahlia Trimble: same code?
[16:05] Simon Linden: We'll get some more new code on Wednesday for the RC channels, including one with a bunch of server bug fixes
[16:06] Kelly Linden: woot
[16:06] Squirrel Wood: It will be fixed. that's all that matters :)
[16:07] Simon Linden: Some of those are ...
[16:07] Simon Linden: SVC-7792
[16:07] JIRA-helper: http://jira.secondlife.com/browse/SVC-7792
[#SVC-7792] HUD Attachments Receive Infrequent Updates when Camera is Zoomed Out
[16:07] Simon Linden: SVC-7853
[16:07] JIRA-helper: http://jira.secondlife.com/browse/SVC-7853
[#SVC-7853] Newly created notecards dont auto open in the viewer on 12.04.12.253726
[16:07] Simon Linden: SCR-311
[16:07] JIRA-helper: http://jira.secondlife.com/browse/SCR-311
[#SCR-311] llGetAgentList() with scope AGENT_LIST_PARCEL or AGENT_LIST_PARCEL_OWNER returns empty list when attached to avatar
[16:07] Simon Linden: SVC-378
[16:07] Draconis Neurocam: yay
[16:07] JIRA-helper: http://jira.secondlife.com/browse/SVC-378
[#SVC-378] Role 'Everyone' in new groups should not have ability "Pay group liabilities and receive group dividends"
[16:07] Simon Linden: SVC-7847
[16:07] JIRA-helper: http://jira.secondlife.com/browse/SVC-7847
[#SVC-7847] Top Scripts Refresh in Region/Estate Tools Broken
[16:07] Simon Linden: SVC-7793
[16:07] JIRA-helper: http://jira.secondlife.com/browse/SVC-7793
[#SVC-7793] Scripted agents can't abandon land on private estates
[16:07] Sahkolihaa Contepomi: Yay at 7847!
[16:07] Simon Linden: SVC-7792
[16:08] Simon Linden: SVC-7837
[16:08] JIRA-helper: http://jira.secondlife.com/browse/SVC-7837
[#SVC-7837] Filtering by object name or owner name in top scripts/top colliders no longer works
[16:08] Simon Linden: SVC-6894
[16:08] JIRA-helper: http://jira.secondlife.com/browse/SVC-6894
[#SVC-6894] Excessive EnableSimulator message spamming to viewers
[16:08] Simon Linden: SVC-7917
[16:08] JIRA-helper: http://jira.secondlife.com/browse/SVC-7917
[#SVC-7917] Please automatically unmute avatars who have muted themselves, and prevent this from occuring server-side.
[16:08] Simon Linden: I think that's it
[16:08] Squirrel Wood: not bad :)
[16:09] Simon Linden: We have another batch going into QA soon, so it's nice to see some fixes making it out
[16:10] Simon Linden: Kelly - any other news?
[16:10] Kelly Linden: No, no news here.
[16:11] Simon Linden: OK -- Andrew sent me a note saying he can't make it today, I think he's heads-down in pathfinding code
[16:11] Simon Linden: So the invisible table is open for topics ...
[16:12] Michi Lumin: (trying to think of any burning region/serverside issues. heh...)
[16:12] Dahlia Trimble: speaking of pathfinding, will scripts or viewers eventually be able to submit path queries and retrieve a path?
[16:12] Martinrj Fayray: can we have a checkbox for objects so that they don't cast shadows?
[16:13] Dahlia Trimble: lots of games allow viewers to pathfind their way aroiund
[16:13] Jonathan Yap: I thought there already was such a lsl function
[16:13] Dahlia Trimble: oh ok I need to look again,m there wasnt last time I looked
[16:14] Simon Linden: Martin - it might be worth making a jira for that feature request. I'm not sure how difficult it would be to add a new flag for the object, and how we'd sort out linked prim issues, but if it helps rendering, that'd be great
[16:14] Sahkolihaa Contepomi: Martin, that would be a viewer-thing.
[16:14] Michi Lumin: Actually, there used to be a shadow option and Runitai removed it, but - yeah, not serverside.
[16:14] Martinrj Fayray: no, Koli you have to store the value
[16:14] Sahkolihaa Contepomi: Server would just need the extra option, but it's mostly viewer-side.
[16:14] Jonathan Yap: http://wiki.secondlife.com/wiki/LlGetStaticPath
[16:14] Sahkolihaa Contepomi: You'd have to poke Runitai about it. :p
[16:14] Dahlia Trimble: ty
[16:15] Michi Lumin: It existed in some legacy code, Martin. (nods) that's Runitai's house.
[16:15] Simon Linden: Right, there would be an extra bit of data for the object for "no shadows" but almost all the work is on the viewer
[16:17] Ardy Lay: We have discussed the great pains involved in changing database schema.
[16:17] Simon Linden: It's a real pain, but we may have space for an extra bit somewhere
[16:18] Draconis Neurocam: i wonder if you could hijack the place where the check for collision particles used to be
[16:18] Martinrj Fayray: https://jira.secondlife.com/browse/SVC-8044
[16:18] JIRA-helper: [#SVC-8044] Don't Cast Shadows-checkbox: Add an option for objects (checkbox in the build-tools floater), so that they don't cast shadows
[16:18] Martinrj Fayray: here is the Jira.
[16:19] Simon Linden: Thanks Martin - we do the bug sorting twice a week so that'll show up at the next one
[16:19] Martinrj Fayray: thank you
[16:19] Sahkolihaa Contepomi: Eh, the thing you want to fix isn't really a good idea.
[16:19] Michi Lumin: Gonna go out on a limb on this one. But: We've got scads of 5 year old (or older) bans on our regions... Would there ever be any way to... clean those up, say if the accounts themselves are gone? Maybe an "audit" or "cleanup" function? Right now, it's hundreds of manual "search, check, remove, etc." ...
[16:19] Sahkolihaa Contepomi: The way the shadow casting works could really just be changed in general.
[16:19] Sahkolihaa Contepomi: Aka, only cast shadows from objects being rendered.
[16:20] Jonathan Yap: +1
[16:20] Martinrj Fayray: that would be an option, but there are other ways where this is needed
[16:20] Martinrj Fayray: (a spherical skybox is always dark)
[16:20] Simon Linden: Hmm, that's interesting, Michi. I can definitely see the need for that cleanup
[16:21] Chieron Tenk: yes, something like privacy screens in skyboxes would always be in the shade, which is unfortunate
[16:21] Michi Lumin: Yeah, it can 'accumulate cruft'...
[16:21] Squirrel Wood: hmm.. furnation regularly clears the banlist and admins need to keep track of who needs to be readded..
[16:21] Simon Linden: I'm not sure how you'd filter that -- accounts _usually_ aren't totally gone or blocked, unless we shut them down for a reason
[16:21] Chieron Tenk: not rendering shadows from nonrendered objects is a good idea, too, though
[16:21] Sahkolihaa Contepomi: Yeah but Corsi doesn't care and just deletes every single ban placed. So let's leave FN out of it.
[16:21] Ardy Lay: Sounds like a job for software, not already busy people.
[16:22] Squirrel Wood: perhaps you can use the last logged in date for cleanups ?
[16:22] Michi Lumin: Well, sometimes people even remove their own accounts.... Lots of reasons, I usually find 5-10 every few months that simply are not extant anymore.
[16:22] Michi Lumin: Well, Squirrelly, -we- can't find that out unless we're in a group with said resident.
[16:22] Jonathan Yap: Record and display the date a ban is created, then you can get an idea of "old" ones
[16:22] Michi Lumin: So yeah as I said it'd likely be "issueful", but there definitely is an accumulation problem.
[16:22] Squirrel Wood: place bans via script (which, I believe, can set a limit on them) ?
[16:22] Ardy Lay: "Old ones" come back, over and over again.
[16:23] Simon Linden: I know some that are shut down can come back easily - I think it's just a call to customer service
[16:23] Michi Lumin: Squirrely: that's a max of 6 days. Life sometimes requires more.
[16:23] Ardy Lay: Would be nice if service could remove the ones that cannot be reactivated from ban lists.
[16:24] Ardy Lay: Residents cannot make that determination, can they?
[16:24] Michi Lumin: pretty sure that's a no, ardy.
[16:24] Simon Linden: Yeah, I wonder how many that would catch ... it is more likely that someone you banned might get shut down for other reasons
[16:25] Michi Lumin: I'm not really trying to wander into governance here, just practicality :P
[16:25] Simon Linden: It's a good point, however -- managing those can be a pain
[16:26] Simon Linden: Is the list size a big factor? I mean, if it could be twice the size, would you just fill it and have the same problems again?
[16:26] Jonathan Yap: Would it be useful to have a number showing how many ban slots are open?
[16:26] Michi Lumin: over the years, yes, usually I have to dedicate an occasional weekend to an audit-per-region.
[16:26] Michi Lumin: Simon, I think doubling the size would certainly mitigate the issue.
[16:26] Michi Lumin: And yes Johanathan, showing statistics as to where we 'are' on the list would be -great-.
[16:26] Michi Lumin: because right now I literally have to count screen by screen.
[16:26] Ardy Lay: Sors would be nice too
[16:26] Ardy Lay: sorts
[16:26] Martinrj Fayray: Something off-topic: The SL-population will reach 30 million in the next days!!!
[16:26] Jonathan Yap: Michi, can you copy and paste the entire list to an editor?
[16:27] Ardy Lay: Martin, "population"?
[16:27] Martinrj Fayray: registered accounts
[16:27] Ardy Lay: Yeah
[16:27] Michi Lumin: No Johnathan, it 'doesn't scroll that way'
[16:27] Rex Cronon: and half of us r just doubles:)
[16:27] Valinye: accounts *ever* I'm assuming.
[16:27] Ardy Lay: Aurora, yes
[16:27] Simon Linden: Those numbers shouldn't be too hard to add to the viewer, if you can find the screen realestate. It should know how large the list is, and figure out where the scrolling position is set
[16:27] Ardy Lay: jcool410 Wildcat is still counted
[16:27] Dahlia Trimble: and some of us are slghtly more than doubles.. <.< >.>
[16:28] Jonathan Yap: I could squeeze in a number <nn> slots remain
[16:28] Rex Cronon: :)
[16:28] Sahkolihaa Contepomi has one account.
[16:28] Michi Lumin: Simon, having a larger list (if space on the backend allows) and showing that statistic would be a big help, to say the least. Doesn't solve the audit issue but would be of -great- assistance.
[16:28] Simon Linden: Would a "copy list to clipboard as text" function be useful?
[16:28] Draconis Neurocam: it would be nice if there was some sort of ban list download available for parcels or regions, same with prim counts by person/group, as scripts can grab all of the numbers, though i still think in terms of the who owns prims, that it would be a good idea if you let people return your own prims rather than have someone with return rights do it, other than just manually clicking on them
[16:28] Michi Lumin: Probably, yes. I'd like to see the count nnn of xxx used, though, in the viewer, if possible.
[16:28] Sahkolihaa Contepomi: Simon - yes. Much easier to filter out big listts.
[16:28] Sahkolihaa Contepomi: lists*
[16:29] Draconis Neurocam: scripts can't*
[16:29] Jonathan Yap: Does the server send a cap of some type with the current ban list size for that region?
[16:29] Michi Lumin: I believe right now it's 300/parcel, 500/region.
[16:29] Michi Lumin: (we're mainland, we've got to rely on parcel, so i'd like to see the counts/options there as well)
[16:29] Sahkolihaa Contepomi: Right now, the estate ban list doesn't seem to sort alphabetically, which is a major pain.
[16:29] Rex Cronon: sadly scripted items can't return themselfves
[16:29] Simon Linden: I think the list sizes are just hard-coded, not part of any cap, but I'm guessing
[16:30] Meeter: Timecheck : User Group is half over
[16:30] Kelly Linden: I fixed that Koli
[16:30] Jonathan Yap: Koli, the names will be sorted soon; someone on the server team fixed that viewer issue :P
[16:30] Kelly Linden: It is somewhere in the viewer dev pipeline
[16:30] Sahkolihaa Contepomi: Ah, thank you!
[16:30] Michi Lumin: (will that be fixed in parcel ban too -- the sorting? Or just estate...)
[16:30] Sahkolihaa Contepomi: That'll save me headaches. >.<
[16:30] Kelly Linden: Michi: I fixed it in both
[16:30] Michi Lumin: excellent
[16:30] Ardy Lay: Thanks Kelly
[16:30] Sahkolihaa Contepomi: Yay Kelly to the rescue!
[16:31] Michi Lumin: anyways I suppose I can jira a 'count nnn of xxx' display option.
[16:31] Michi Lumin: Related: A corrolary here would be the ability to ban from groups; (since a lot of 'open enroll' groups would _love_ to be 'open enroll to all but spam/ad bots'.)
[16:31] Jonathan Yap: Michi, the convention in other places I have added a count is to have <nnn> slots remain
[16:31] Michi Lumin: Johnathan: That'd be fine.
[16:31] Kelly Linden: The estate lists say (X, max Y)
[16:31] Squirrel Wood: perhaps.... for the ban lists... a "last logged in" bit of info could help too ?
[16:32] Simon Linden: Yes, please create a jira for that. Since it shows up in the estate lists, it makes sense to do the same elsewhere
[16:32] Kelly Linden: So 'Banned residents: (1, max 500)
[16:32] Squirrel Wood: so you could sort it based on that
[16:32] Michi Lumin: Squirrely: Historically that's been restricted to group membership. That has privacy implications.
[16:32] Michi Lumin: yes Kelly <nods>
[16:32] Sahkolihaa Contepomi: Yeah, I see people screaming 'OMG MY PRIVACY' over that.
[16:33] Squirrel Wood: point them to facebook for privacy violations :p
[16:33] Jonathan Yap: you should be able to copy and paste the ban list, maybe that is just an xml change
[16:33] Ardy Lay: SL isn't Faceboook, thanks
[16:33] Michi Lumin: "just because your brother does it doesn't mean it's OK."
[16:33] Kelly Linden: I need to head out early. Have a good weekend all.
[16:33] Valinye: Secondface Booklife
[16:33] Simon Linden: Putting a copy into the clipboard should be pretty easy, I'm not so sure about pasting back
[16:33] Michi Lumin: We'll take what we can get <:}
[16:34] Jonathan Yap: Simon, you'd paste into some text editor; I meant it as a one way viewer->something else solution
[16:34] Draconis Neurocam: that copy into the clipboard thing would be wonderful for who owns prims in about land as well
[16:34] Valinye: Have a great weekend Kelly
[16:34] Michi Lumin: On the other thing I've just mentioned though. I always wondered why groups did -not- have a ban function. Open enroll is needed for a lot of say, community groups but -- keeping spammers out is pretty much impossible.
[16:34] Michi Lumin: Ok Kelly <Salutes> have a good one.
[16:35] Jonathan Yap: If the contents of a display is plain text sending it to the clipboard is easy
[16:35] Valinye: We've been doing a lot of group management via external systems and bots... Complex solution for a simple problem.
[16:35] Ardy Lay: Sounds like a region console application
[16:35] Michi Lumin: (just wondering if there are any thoughts on that...)
[16:35] Michi Lumin: Yeah.
[16:36] Simon Linden: Right - the list isn't just text, but copying what's there into the clipboard as text would be easy just be looping over everything in the list. WIth it sorted, it'll be nice and neat
[16:36] Ardy Lay: Unfortunately needs to be per-parcel too
[16:36] Draconis Neurocam: i think the issue with group management in general has just always been one of those things where the nice to have features were thought of later, and shoe horning them into the current system would not be fun
[16:36] Simon Linden: Putting it back via paste sounds like a lot more work and open to the possibility of major damage if you did the wrong thing
[16:36] Jonathan Yap: I have an idea how to block people from open groups
[16:36] Michi Lumin: Maybe, Draconis, but really it would be as simple as putting them into a 'null role', really.
[16:36] Valinye: Yes
[16:36] Jonathan Yap: You use the mutelist, and the list is based on the UUID of the group
[16:37] Jonathan Yap: So it would just be another database entry, as it is with avatars
[16:37] Jonathan Yap: LIke my mute list is based on my UUID
[16:37] Martinrj Fayray: isn't the mutelist client-side?
[16:37] Jonathan Yap: no
[16:37] Michi Lumin: ah, so [group]--> mutelist, vs [avatar]--> mutelist?
[16:37] Sahkolihaa Contepomi: The list is grabbed from the sim.
[16:37] Jonathan Yap: yes Michi
[16:38] Martinrj Fayray: hmm
[16:38] Jonathan Yap: You'd have the mutelist headed by the group's UUID
[16:38] Draconis Neurocam: that is actually another issue, it would be nice to see who is muted in group chats in some other window than the actual chat itself, sort of a group moderation panel or something
[16:38] Simon Linden: You'd then have to fetch all the group's members to expand it to your full mutelist, right?
[16:38] Michi Lumin: Either way. That, or a 'null role', would be ... a real burden off. The spam bots are pretty much set to scan for group numbers, and open-join. And if you eject them, they will rejoin again, until you turn off group chat all together, wihch... obviously is not what we want to do.
[16:39] Jonathan Yap: No Simon, you would have the group UUID and do a "is_muted" type query against that UUID, checking to see if the supplied avatar UUID is in that list
[16:39] Martinrj Fayray: The mutelist blocks things like IMs viewer-side afaik. Not server-side. So with some third-party client the IMs could still get through
[16:39] Michi Lumin: Johnathan: We'd want them to not be able to speak, but also not be able to hear/receive. Would that be more complex?
[16:39] Jonathan Yap: It would be the same as checking to see if someone is in my mutelist, except the viewer code would check with the group's UUID as the index into the database
[16:40] Michi Lumin: A role that simply had "zero abilities" (to receive or transmit) - unlike 'everyone', which has some inherent defaults that can't be rejected -- might be a simpler way to go?
[16:40] Jonathan Yap: yes, a little server work would have to be done here, but not much
[16:40] Simon Linden: Well, that's a check of "is Someone in a Group", which needs either the group member list, or the list of groups that person is in
[16:41] Ardy Lay: Would preventing them from joining the group be less intense?
[16:41] Michi Lumin: "no join if in mutelist", sort of thing
[16:41] Martinrj Fayray: preventing them from joining doesn't work this way
[16:42] Simon Linden: I should probably understand what you're trying to solve, lol ... what exactly is the problem?
[16:42] Squirrel Wood: What about having the everyone role only be able to listen in and use a separate role to enable the ability to post ?
[16:42] Michi Lumin: Simon: We'll have an open-enroll group.
[16:42] Simon Linden: ok
[16:42] Martinrj Fayray: we want a ban-list for groups.
[16:42] Jonathan Yap: Simon, we want to block people from joining open groups
[16:42] Michi Lumin: A spam bot will join and begin spamming the chat, or a troublemaker will join.
[16:42] Martinrj Fayray: So that residentA cannot join group B
[16:42] Michi Lumin: We eject them -- and they simply re-join.
[16:42] Michi Lumin: And continue the bad behavior.
[16:42] Squirrel Wood: perhaps a delay before you can rejoin... increasing over time ?
[16:42] Martinrj Fayray: the only way to do this at the moment is with group bots
[16:42] Michi Lumin: The only options we have are A) turning off open enroll on the group (not feasible for large community groups) or B) turn off things like chat, alltogether.
[16:42] Squirrel Wood: a discouragement delay.
[16:43] Simon Linden: Is the default role and perms set so they can post group chat?
[16:43] Michi Lumin: Simon, either 'everyone' can or 'everyone' can't.
[16:43] Michi Lumin: if "Everyone" is set to be able to join group chat
[16:43] Ardy Lay: We only want to eject a spambot once. They do not reform.
[16:43] Rex Cronon: i think an "exclude" list is needed
[16:44] Simon Linden: and if you make it "everyone" can't, you have to manually pick and promote the people who get to chat, right?
[16:44] Michi Lumin: there is no way to make an individual NOT able to join group chat.
[16:44] Michi Lumin: Right.
[16:44] Michi Lumin: And some of our groups expand by 30, 40 people a day.
[16:44] Michi Lumin: Individual promotion is just not doable.
[16:44] Michi Lumin: Nor is individual invite.
[16:44] Chieron Tenk: simon, that is not feasible for some groups or group sizes
[16:44] Sahkolihaa Contepomi: Yeah, FN group is at 2,904 right now.
[16:45] Draconis Neurocam: the midian city group has over 4000
[16:45] Simon Linden: pfft, that's minor leagues - Baker was working on a group with 90k members :P
[16:45] Valinye: Bronies is 4k+
[16:45] Simon Linden: That one is insane, btw
[16:45] Sahkolihaa Contepomi: Heh.
[16:45] Sahkolihaa Contepomi: Mesh group, by any chance? ;)
[16:45] Michi Lumin: so if the 'general state' is "join the group and join chat"; really there is no way to -exclude- someone from either joining or chatting.
[16:45] Ardy Lay: We need a "get out and stay out" button that is processed by service when a group join is attempted.
[16:45] Simon Linden: I'm not sure anythign works with it
[16:46] Simon Linden: Wel, I'm not sure how you reconcile this ... on one hand, a bot joining and spamming is definitely bad. But you're also telling me you want anyone to be able to join and chat, without manual promotion
[16:46] Michi Lumin: Simon we're just asking for a group ban/blacklist function.
[16:46] Michi Lumin: Yes, they can join.
[16:46] Sahkolihaa Contepomi: As Ardy said, we just basically want a ban function for groups.
[16:46] Michi Lumin: The RE-join is the issue.
[16:46] Michi Lumin: the "infinite rejoin"
[16:47] Simon Linden: ah, ok
[16:47] Michi Lumin: Eject from an open-enrollment group is basically nothing more than a symbolic gesture at this point.
[16:47] Rex Cronon: some people can't take no for an answer
[16:47] Ardy Lay: bots
[16:47] Michi Lumin: right, some people aren't people at all :)
[16:47] Sahkolihaa Contepomi: Of course not. This is the Internet.
[16:47] Ardy Lay: It's hard to keep up with software working against you.
[16:48] Squirrel Wood: Like I said, an increasing delay before one can rejoin may be a viable solution
[16:48] Michi Lumin: A lot of what I get is "Michi, ban that spambot, it opens group chat all the time!" / "Sorry, I can't."
[16:48] Simon Linden: hhmmm, ok, I don't mean to kill the discussion, but please make a jira for it. We have the DB for for some list management, so maybe we could add a new type for "banned from group"
[16:48] Michi Lumin: We have. :)
[16:48] Rex Cronon: and for each rejection have the delay increase:)
[16:48] Squirrel Wood: correct Rex
[16:48] Martinrj Fayray: https://jira.secondlife.com/browse/SVC-7071?
[16:48] JIRA-helper: [#SVC-7071] Ban list for Groups
[16:49] Michi Lumin: (though I don't remember the number of it off of the top of my head - its old)
[16:49] Michi Lumin: yes.
[16:49] Martinrj Fayray: this is pretty old
[16:49] Michi Lumin: thats the one.
[16:49] Squirrel Wood: start with 24 hours, move up to one week, one month, a year.
[16:49] Michi Lumin: I tried to bring it back to life recently.
[16:49] Michi Lumin: But it has been an ongoing need.
[16:49] Martinrj Fayray: https://jira.secondlife.com/browse/SVC-2825
[16:49] JIRA-helper: [#SVC-2825] New Feature -> Dialog -> Group Information -> Ban List
[16:49] Martinrj Fayray: from 2007
[16:49] Simon Linden: Got it, thanks. I'm guessing this would take a bunch of UI work in the viewer to manage the list, but that's basically the same as what we have for parcels, regions or estates
[16:49] Ardy Lay: Squirrel, that would be pointless against bots, harder to implement for LL and way more work for residents moderating groups.
[16:49] Michi Lumin: Yeah. It'd be pretty consistent as far as 'access norms' go, Simon.
[16:49] Martinrj Fayray: Jonathan is good at it *hint*
[16:49] Rex Cronon: a ban list sounds better
[16:49] Simon Linden: Probably some new messaging between the simulator and viewer too
[16:50] Simon Linden: ....and maybe a few database things. At least all the pieces of tech seem to be there already, so it's not too scary
[16:50] Ardy Lay: Simon, sometimes I wonder what is available in the region console. I suppose that's documented somewhere.
[16:51] Michi Lumin: Simon do you think a 'banned' or 'jailed' "role" would be easier to implement? or just not worth it due to UI/function inconsistency with other access paradigms.
[16:51] Simon Linden: Do you mean the debug console, with a command line?
[16:51] Ardy Lay: Simon, yes
[16:51] Jonathan Yap: Michi, it is easier to deal with a new type of list than adding more roles
[16:52] Michi Lumin: ok Johnathan, understood. (And I certainly take your word for it.)
[16:52] Ardy Lay: Simon, "help" is available. So never-mind my question, I guess.
[16:53] Simon Linden: Hmm, that's an interesting one, Michi - if there's an "in jail" role (possibly already used for other reasons by some groups) and we made that a special case that only admins could change, you could block chat
[16:53] Jonathan Yap: You'd want this enforced at the server; that is, the ban list should be checked on the server when someone goes to join a group
[16:53] Simon Linden: But I"m not sure about blocking them from leaving the group
[16:53] Jonathan Yap: Who manages that list would probably be the group Owners
[16:53] Michi Lumin: right, and then re-joining. Hmm. Complexity around every corner indeed.
[16:53] Jane1 Bookmite: I manage a group of over 12,000 , with a group that large you simply must look at how you manage it differently
[16:53] Sahkolihaa Contepomi: Jonathan - I'd put officers with owners, too.
[16:54] Krashnburn Hillquit: only when you try nd use side effects, it boils down to a feature request for a group ban list,
[16:54] Jonathan Yap: good point Koli
[16:54] Rex Cronon: if they cancel group membership, and rejoin again, they will no longer be in the jail group
[16:54] Simon Linden: If they were "in jail" you'd want to keep them in the jail role, but let them leave the group -- I'm not sure the database supports that
[16:54] Jonathan Yap: easier to have a separate list
[16:54] Michi Lumin: yeah. That'd be difficult. So, yes, my bad :P
[16:54] Jane1 Bookmite: AS far as I am concerned, it is not a good idea to allow 'Everyone' to chat.
[16:54] Simon Linden: I mean not have that gruop count against their 42 group limit
[16:55] Meeter: Timecheck : User Group is almost over
[16:55] Ardy Lay: Spambots already join spew and bail
[16:55] Sahkolihaa Contepomi: Jane - In big groups, it has to be like that.
[16:55] Jane1 Bookmite: Agree
[16:55] Simon Linden: I think you're right Jane, but that changes as a group grows. I'm sure it's fine for small groups, but eventually they get too popular
[16:55] Jane1 Bookmite: Agree again
[16:56] Michi Lumin: <nods to Simon> Not really a one size fits all situation, however a banlist would be.
[16:56] Ardy Lay: Part of the purpose of our groups is to allow group chat
[16:56] Siana Gearz: whoops
[16:56] Siana Gearz: need to adjust my aim -.-
[16:56] Valinye: [7/6/12 5:44:49 PM] OldVamp: i want an lsl tie in if that happens so it can be automated check that the object is owned by group, then llGroupBan(CONSTANT_ADD, "UUID");
[16:57] Martinrj Fayray: Simon before the meeting is over, couldn't you fix the broken vendor (replace the Asset server-side) that prevents the fix of https://jira.secondlife.com/browse/SVC-914 ?
[16:57] JIRA-helper: [#SVC-914] CHANGED_TEXTURE is not triggered when texture is changed via script
[16:58] Martinrj Fayray: maestro wrote they can't fix it because a popular vendor uses the broken behavious
[16:58] Martinrj Fayray: *behaviour
[16:58] Simon Linden: ah, that brings up a good point, and a reason why the "jail" role would be difficult ... it might bump into other group functionality
[16:58] Michi Lumin: yeah Simon. The more I think of it, the more it wasn't a good idea. :P Was just looking for simpler implementations. But yeah, it could cause complexities unforseen.
[16:59] Fox Oxbar: I got here late, but I was told my bot-based solution for open-enrollment group chat moderation was mentioned... if anyone wants an explanation on that after the meeting, just IM me :)
[17:00] Simon Linden: It was definitely worth exploring, because it would have been easier if it worked out
[17:00] Meeter: Thank you for coming to the Server User Group
[17:00] Simon Linden: Pony - we've been talking about groups and the problems of bots joining and spamming, or how to block someone from joining an open group
[17:00] Michi Lumin: only thing about bots is, lots of IO, have to be online, etc...
[17:00] Ardy Lay: Thanks Simon
[17:00] Martinrj Fayray: (I have the changed_texture bug on your agenda, I'm gonna bring it up next time when we have more time)
[17:01] Valinye: Thank you everyone. Have a great weekend.
[17:01] Michi Lumin: (and not many people have access to such bots)
[17:01] Michi Lumin: thanks Simon, and, thanks for discussing
[17:01] Michi Lumin: (and everyone else, yes)
[17:01] Simon Linden: ok Martin, we can get into that next time
[17:01] Martinrj Fayray: ty
[17:01] Rex Cronon: tc everybody leaving
[17:01] Simon Linden: Thanks everyone for coming today, and the good talk
| Prev 2012.07.03 | Next 2012.07.10 |