Simulator User Group/Transcripts/2011.12.06

From Second Life Wiki
Jump to: navigation, search

Simulator_User_Group

Prev 2011.12.02 Next 2011.12.09

List of Speakers

Andrew Linden Arawn Spitteler Ardy Lay
Elisha Richez Jonathan Yap JoyofRLC Acker
Kadah Coba Kelly Linden Latif Khalifa
Leonel Iceghost Liisa Runo Motor Loon
note Genesis Pauline Darkfury Qie Niangao
Rex Cronon Sahkolihaa Contepomi Simon Linden
Squirrel Wood TankMaster Finesmith Yuzuru Jewell
Zi Ree

Transcript

[12:00] Sahkolihaa Contepomi: Hey Simon. Table needs resetting. :p

[12:00] Sahkolihaa Contepomi: And, hey Andrew.

[12:00] Arawn Spitteler: Oh, good, let's all sit on this same chair, and let Simon kick us off.

[12:00] Meeter: Welcome to the Server User Group

[12:01] Simon Linden: yeah, I think it needs a server update ... should happen tomorrow

[12:01] Sahkolihaa Contepomi: I thought LeTigre got rolled back?

[12:01] Sahkolihaa Contepomi: Kadah's table here works.

[12:01] Motor Loon: We'll just sit here until tomorrow... no problem

[12:01] Arawn Spitteler grabs any piece of broken content and dances around

[12:01] Motor Loon: xmas latex eh Pauline hehe

[12:02] Pauline Darkfury: Yup :)

[12:02] Pauline Darkfury: Hi all :)

[12:02] Motor Loon: cute shoes

[12:02] Yuzuru Jewell: Hello

[12:03] Andrew Linden: Ah, this crate table/chair system doesn't use the on_rez() event

[12:03] Sahkolihaa Contepomi: I think this table may get autoreturned before the end of the user group.

[12:03] Motor Loon: bugs in SL? who knew it could happen....

[12:03] Kadah Coba: I wouldnt know

[12:03] Andrew Linden: Oh that reminds me... I need to change the autoreturn of that nearby parcel back to 5 min

[12:04] Sahkolihaa Contepomi: It seems Simon got pushed below.

[12:04] Pauline Darkfury: Heh, this one works ;)

[12:04] Andrew Linden: I bumped the autoreturn on this parcel a bit... this table should survive the hour

[12:04] Pauline Darkfury: Oops, sorry, simon, that was possibly me rezzing the big table before realising it was much too big

[12:04] Andrew Linden: assuming it was rezzed less than 20 min ago

[12:05] Rex Cronon: hello everybody

[12:05] Yuzuru Jewell: Helllo

[12:05] Andrew Linden: Regarding SVC-7499 ... the fix appears to work and we'll try to roll it tomorrow

[12:05] JIRA-helper: http://jira.secondlife.com/browse/SVC-7499

[#SVC-7499] Poseball rezzing items are either not giving poseballs or rezzing balls in wrong positions

[12:05] Yuzuru Jewell: Table test?

[12:06] Andrew Linden: also, there are two regions with the fix already deployed...

[12:06] Jonathan Yap: Is this one of them?

[12:06] Andrew Linden: where you can rez your stuff to test

[12:06] Andrew Linden: LeTigre Sandbox 3 and 4

[12:06] Andrew Linden: er... maybe not. I'm getting verification

[12:07] Kelly Linden: Should be LeTigre Sandbox 3 and LeTigre Sandbox 4

[12:07] Andrew Linden: Ok yeah, those region names are right.

[12:08] Andrew Linden: However, you have to be a member of a particular group to access those sandbox regions.

[12:08] Andrew Linden: As per the comments in SVC-7499

[12:08] Pauline Darkfury: SL Beta group

[12:08] Pauline Darkfury: it's open-enroll

[12:08] Andrew Linden: Thanks Pauline.

[12:08] Pauline Darkfury: Second Life Beta

[12:09] Leonel Iceghost: I think it is not open anymore

[12:09] Liisa Runo: Second Life Beta

[12:09] Pauline Darkfury: If you want access to the group chat, an existing chat member has to promote you

[12:09] Leonel Iceghost: ah you just changed

[12:09] Jonathan Yap: Is there a relay to IRC for that group?

[12:10] Pauline Darkfury: In-world only, I think. Best to ask Oskar for permission before doing something like that - it's his group

[12:10] Latif Khalifa: Jonathan, nope

[12:10] Kadah Coba: It was getting spammed badly

[12:11] Andrew Linden: That's all the news I've got.

[12:11] Simon Linden: I don't have much, but was looking at the ancient SVC-5399 yesterday

[12:11] JIRA-helper: http://jira.secondlife.com/browse/SVC-5399

[#SVC-5399] llGetSunDirection() not accurate

[12:11] Andrew Linden: I haven't looked into the rotation bug that Mike Denneny brought up

[12:12] Latif Khalifa: Is poseball breakage on LeTigre going to get fixed in tomorrows RC update?

[12:12] Pauline Darkfury: SVC-7026 and older Jiras. Could we please have all-estates bans succeed for all except the full estate, and give a useful diag to tell us which is full in local chat.

[12:12] JIRA-helper: http://jira.secondlife.com/browse/SVC-7026

[#SVC-7026] Error when banning across multiple Estates

[12:12] Simon Linden: It's uglier than I thought, but may be do-able if I dig into more viewer code

[12:12] Andrew Linden: or the change to default group liability for the Everyone role

[12:12] Pauline Darkfury: Or, just raise the limit to 5000 on the ban list

[12:12] Liisa Runo: viewer code? what it got to do with viewer?

[12:13] Andrew Linden: Latif, yes the poseball breakage should be fixed tomorrow (SVC-7499)

[12:13] Latif Khalifa: good to hear

[12:13] Simon Linden: It tells you where the sun is drawn ... there's definitely something odd going on between the two, Liisa

[12:13] Leonel Iceghost: Andrew your animation is another reason why we need llGetDisplayedGender(), not only comunication to the user :P

[12:14] Latif Khalifa was swamped with angry customers the whole week re. SVC-7499, cost me a lot of $L too

[12:14] Liisa Runo: i could imagine it would be just between server and LSL, and work even when no one is viewing the script

[12:14] Andrew Linden: Hrm... SVC-5399, probably introduced by the windlight sky render stuff from a long time ago

[12:15] Liisa Runo: it is

[12:15] Jonathan Yap: Andrew, did you see Oz's comments about get sun position?

[12:15] Kadah Coba: I think Oz was testing llGetSunDirection() when region WL when live

[12:15] Andrew Linden: I see it now Yap. That confirms my suspicions.

[12:16] Kadah Coba: I remember seeing him playing with a sun tracker back then

[12:16] Andrew Linden: The simulator used to tell the viewer where the sun was located.

[12:16] Andrew Linden: Somone broke that a long time ago.

[12:16] Sahkolihaa Contepomi: Heh...

[12:16] Simon Linden: yeah, I thought it would be pretty simple ... it should be ... but I'm suspicious about the server and viewer's code matching up. And the server definitely doesn't know about windlight

[12:16] Simon Linden: The sim is still sending the sun position regularly ... I checked. IT's sending the value it returns from that function

[12:16] Latif Khalifa: doesn't it persist the settings now?

[12:17] Andrew Linden: Yeah, the viewer stopped paying attention,.

[12:17] Sahkolihaa Contepomi: Well, unticking atmospheric shaders disables Windlight, same with basic shaders, no?

[12:17] Simon Linden: But it has some oddities ... it sends an angular velocity (non-zero) when the sun is fixed, for example

[12:17] Kadah Coba agrees with Oz's comment that its very low priority compared to many other things like crossings.

[12:17] Simon Linden: Exactly Kadah - I spend a bit of time yesterday on it, and found it wasn't going to be simple, unfortunately. I doubt I'm going to dig deeper

[12:19] Kadah Coba: Crossings/TP, bake issues, http/cap/textures should be top of the list

[12:19] Andrew Linden: Regarding SVC-7026... the original 50 avatar limit in the access lists was related to the data that could be packed into the 1.5kB MTU of a UDP packet

[12:19] Leonel Iceghost: low priority means it will never work? why don't you just deprecate the function.. it has been years and years... how much time it has to pass to fix low priority stuff?

[12:19] Andrew Linden: if the Estate banning has been moved off of the UDP message system then the number could be increased

[12:19] Kadah Coba: "Deprecate" in LSL means "edit the wiki"

[12:20] Zi Ree: Has llGetStartParameter() been fixed after a region restart? I ran into that a while back and never checked if it works now.

[12:20] Andrew Linden: I'm sure some content still uses the function. That content would cease to work.

[12:20] Leonel Iceghost: Andrew that content doesn't work well

[12:20] Sahkolihaa Contepomi: What do the Meeroos use to figure out if it's light/day?

[12:20] Leonel Iceghost: since years..

[12:20] Liisa Runo: some day LL take a pause in making new stuff (and new bugs) and will fix all the bugs, also the low priority bugs

[12:20] Arawn Spitteler: Has anyone posted a warning to the wiki?

[12:20] Simon Linden: Yeah, I was wondering what would break if I fixed it :P

[12:20] Zi Ree: The meeroos use llGEtSunPosition().z<0

[12:20] Simon Linden: That would be a very long day, Liisa

[12:21] Leonel Iceghost: nothing would break.. everything using sun is alredy broken Simon

[12:21] Pauline Darkfury: Sorry, but completely wrong to say "why not just deprecate it if it's not going to be fixed quickly"

[12:21] Andrew Linden: Well Simon, nothing should break if we made the viewr render the sun in the correct position.

[12:21] Leonel Iceghost: quickly? it has passed years and years Pauline

[12:21] Pauline Darkfury: It's only appropriate to deprecate it when there's a replacement and the replacement has been around for a very long time

[12:21] Liisa Runo: and yes, plenty of stuff still use it, even when lil inaccurate, it is still the only way to know when to automatically turn lights on/off

[12:21] Leonel Iceghost: it is completelly inaccurate

[12:22] Simon Linden: Right, I suspect a lot use it for basic day/night detection, so we don't want to just shut it off

[12:22] Jonathan Yap: The question is which sun to report on--the non-WL one, or the region WL one, etc?

[12:22] Pauline Darkfury: I've used it for stuff before. Can't say for sure it works right now, but it used to be just fine on the default day cycle, within the last 12 months

[12:22] Sahkolihaa Contepomi: What Simon said.

[12:22] Zi Ree: I find the start parameter issue worse.

[12:22] Andrew Linden: Either the viewer needs to follow the simulator, or the other way around. It doesn't really matter which position is used.

[12:22] Pauline Darkfury: By all means note in the wiki that there's an unresolved bug with it, and ideally what circumstances trigger the bug, but no deprecation, please

[12:22] Andrew Linden: The simulator does some trickery to make a 3 hour day, 1 hour night, with some seasonal variation.

[12:23] Andrew Linden: Dunno what the viewer does.

[12:23] Simon Linden: Yeah, I was surprised to see we tilt the sun angle on an annual cycle

[12:23] Jonathan Yap: I've seen a code snippet where it bumps the sun up a bit in altitude

[12:23] Sahkolihaa Contepomi: I remember Oz mentioning something about some sort of interpolation on the viewer so the sun/moon movement was smooth, mostly to help when shadows are enabled.

[12:25] Object: Hello, Avatar!

[12:25] Zi Ree: Hello, Object!

[12:25] Jonathan Yap: It seems the viewer has to be able to send back to the server where the sun is and at what rate it is moving if region WL is enabled

[12:25] Andrew Linden: I wonder who knows if the Estate Banning system goes through newer Web Services (Caps) or the old UDP packets.

[12:25] Zi Ree: The region should know that :P

[12:25] Andrew Linden: Anyone here know?

[12:25] Jonathan Yap: or maybe not the viewer, but some server check of the database

[12:26] Kelly Linden: Old UDP, I believe.

[12:26] Ardy Lay: WHich viewer in region will be authoratative if many are present in the region?

[12:26] Jonathan Yap: Ardy, if region WL is on that would override the default day/night cycle

[12:26] Liisa Runo: no need to mix the viewer in to it, just need to tell the server how to calculate the WL sun

[12:26] Squirrel Wood: hELLOLS1

[12:26] Pauline Darkfury: If the limit can't be raised, a great short term fix would be to get system chat in local to tell you which estate(s) is full. When you have hundreds of estates, it's impossible to keep track of which might be full.

[12:27] Squirrel Wood: and Hellols! for those who can't read that :p

[12:27] Rex Cronon: hi

[12:27] Andrew Linden: It is a novel thought (server listening to viewer for sun direction) but that won't work.

[12:27] Pauline Darkfury: The other short term fix would be for it to succeed for every estate that isn't full, rather than failing for all because 1 is full

[12:28] Simon Linden: I don't thing we'd want to bother adding any new communications for the sun position, but it really should match whatever the region setting is, and the viewer and server calcultions on the position need to match

[12:28] Zi Ree: Obvious solution: Fix the viewer.

[12:28] Jonathan Yap: I was wrong about the viewer being involved. The server should check for region WL and if that is defined use that for its calculations

[12:29] Ardy Lay: Lindens, I have a question about ad hoc conferencing.

[12:29] Squirrel Wood: how about calculating the stuff based on the users local position on the planet ?

[12:29] Simon Linden: What's that, ARdy?

[12:29] Andrew Linden: Go ahead Ardy.

[12:29] Ardy Lay: When the initiator of an ad hoc conference session is in my blocked list, I do not see his initial or subsequent messages. I still get added to the session and if anybody else added to this session by the initiator sends any messages to the session then I see those messages. This is currently being used by several people to be annoying to large numbers of residents at a time by initiating sessions with them and asking a question or saying something inflamatory.

[12:29] Motor Loon lives on the moon

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

[12:31] Jonathan Yap: You want a blocked person's ad-hoc initiation message to you blocked -- that would probably be an easy viewer change

[12:31] Arawn Spitteler: Couldn't you just close the window?

[12:31] Squirrel Wood: the way I understand this is that the message IS blocked, but answers still reach the recipient

[12:31] Kadah Coba: It would like be possible for the region to read the regionWL settings extract the sun position for the key frames, and intopolate the position for the time between the key frames close enough to appear correct.

[12:31] Simon Linden: Most of that blocking happens in the viewer, right?

[12:31] Andrew Linden: Right. I guess the viewer should not add them to the session, or at least keep that session out of sight... in case the person is suddenly unblocked.

[12:31] Ardy Lay: WOuld that prevent responses to the initiator by other persons from opening windows in my viewer?

[12:31] Latif Khalifa: unless the uuid is not sent and jonathan get temptet to suggest another improved instant message change

[12:32] Jonathan Yap: Yes Simon, I have done a lot of mute fixes in the last year

[12:32] Ardy Lay: Arawn, try having about 90 sessions a minute to close.

[12:32] Rex Cronon: if somebodyis on your mute list why would u want to have a session with them?

[12:32] Jonathan Yap: Ardy, do you have a jira number?

[12:32] Arawn Spitteler: Closed chat sessions should not reopen

[12:32] Andrew Linden: But it is too bad that people can open ad-hoc conferences with impunity as a form of grief.

[12:33] Jonathan Yap: I would like to look into this

[12:33] Ardy Lay: Arawn, you are not comprehending the situation. The initiator is initiating many new sessions a minute.

[12:33] Arawn Spitteler: If blocked, why on your friends list?

[12:34] Rex Cronon: the server ignores your mute list

[12:34] Pauline Darkfury: Well, for a scenario like that, seems like the best fix is for the initiator's account to go poof temporarily or permanently, tbh

[12:34] Arawn Spitteler: Can you open ad-hoc to non-friends?

[12:34] Zi Ree: Calling cards.

[12:34] Jonathan Yap: Ardy, give me a jira number please, I will see what I can do

[12:34] Jonathan Yap: Yes Arawn

[12:34] Andrew Linden: Anybody have ideas on how to throttle/prevent grief conference initiations from griefers?

[12:34] TankMaster Finesmith: yes, arawn

[12:34] Leonel Iceghost: automatically banning them?

[12:34] Arawn Spitteler: If blocked, Calling Card shouldn't give access.

[12:34] Pauline Darkfury: Rate limit on the group chat servers

[12:35] Zi Ree: The initiator is blocked but the people who answer still show.

[12:35] Pauline Darkfury: Max 1 new conf every 60s

[12:35] Rex Cronon: have server check if the initiator of a conferece is not on the mute list of any of those in the conference

[12:35] Kadah Coba: Dont allow ad-hoc from muted?

[12:35] Pauline Darkfury: But equally, governance need to suspend or ban people doing stuff like that

[12:35] Jonathan Yap: A muted initiator should not allow an ad-hoc to start on your viewer

[12:35] Pauline Darkfury: If they think that sort of thing is amusing, they will just harass in other ways if that is blocked

[12:35] Arawn Spitteler: Respondants wouldn't be opening the chat, so muted only need be blocked from accessing with calling card.

[12:36] Latif Khalifa: yeah this can be fixed viewer side

[12:36] Andrew Linden: Well, failing the whole ad-hoc session could be a way to grief... You just mute someone yourself so thier sessions fail.

[12:36] Arawn Spitteler: Be careful that muting doesn't become a grief form.

[12:36] Andrew Linden: If you give them feedback "Failed because Joe Resident has muted you" then they can just remove Joe... minor inconvenience.

[12:36] Arawn Spitteler: We shouldn't see animations of the muted either.

[12:36] Zi Ree: Logical conclusion.

[12:36] Zi Ree: Just leave the person who muted the initiator out of the conference.

[12:37] MLCC Giftcard whispers: Voucher Value: L$6000.

[12:37] Latif Khalifa: your viewer should just ignore sessions initiated by people on your mute list

[12:37] Pauline Darkfury: Yeah, there's no grief in failing the whole thing as long as you tell them which person they are not allowed to talk to

[12:37] Andrew Linden: Yeah, Zi might be right

[12:37] Arawn Spitteler: Do we even know, when we've been muted?

[12:37] Andrew Linden: the server might be able to throttle session creates when attempts are made to connect to muted residents

[12:38] Jonathan Yap: The issue is not from having a blocked person in an ad-hoc session, that block probably works properly now, it is that they can initiate and cause trouble

[12:38] Rex Cronon: if the viewer has to do it, u can still have a problem if lots of drones do it to u at the same time

[12:38] Pauline Darkfury: Putting in a sane throttle on the rate you can start conf chat seems like a good step

[12:38] Jonathan Yap: <--still needs jira #

[12:38] Kadah Coba: Ad-hoc creation should be throtled anyway.

[12:38] Andrew Linden: I think Kadah is right.

[12:38] Simon Linden: We're definitely going to need a jira to describe this in good detial - how it is initiated, etc

[12:38] Arawn Spitteler: So, if they join you to a session, the session shoulnd't be received by those blocking.

[12:38] Pauline Darkfury: That might, I guess, help the chronic group chat lag problems as well

[12:38] Jonathan Yap: Rex, you can have trouble from drones for many reasons

[12:39] Ardy Lay: One a minute from a griefer would still be too many. Must be able to completely block them.

[12:39] Rex Cronon: this is one of them:)

[12:39] Latif Khalifa: i doubt thtottle would be a good solution. i can imagine being annoyed if the person i muted started one every 10 min

[12:39] Kadah Coba: The only reason to create more than like 1 ad-hoc per minute cannot be too legit.

[12:39] Ardy Lay: Throttling is NOT the answer.

[12:39] Simon Linden: I'm guessing teh viewer could monitor who initiates it, and block all subsequent messages from that chat, regardless of who sends it

[12:39] Pauline Darkfury: Yeah, mute should work as well, but throttle is also appropriate

[12:39] Rex Cronon: by drones i mean bots(avatars controlled by script)

[12:39] Simon Linden: but if it's to a group, that has to shut down at some point

[12:39] Zi Ree: The server can just leave people out who have the initiator blocked. Problem solved.

[12:39] Arawn Spitteler: Why would the chat invite be acknowledged?

[12:40] Ardy Lay: Viewer does still display the blocked initiator's name on the icon but the title of the window gets the name of the first unblocked responder.

[12:40] Arawn Spitteler: Do respondants send invisible invites?

[12:40] Jonathan Yap: Zi, the same thing can be done on the viewer, where it traditionally is handled

[12:40] Zi Ree: Yes, but the viewr has to handle the load.

[12:40] Zi Ree: Why not just blocking server side?

[12:40] Jonathan Yap: There is not much load, 1 server packet

[12:41] Zi Ree: That would fix all viewers simultaneously.

[12:41] Rex Cronon: viewer having to do the blocking can lead to congested pipes

[12:41] Zi Ree: Viewer side means, all viewers need to implement it.

[12:41] Pauline Darkfury: blocking and throttling server side should help the overloaded group chat servers (they are used for ad-hoc confs, are they not?)

[12:41] Simon Linden: Most work that can be offloaded from the server to the viewer is a good thing

[12:41] Zi Ree: And a Mute list is server side anyway.

[12:41] Jonathan Yap: Zi, that has been the case for all my mute fixes, this is really no different

[12:41] Motor Loon: I'd think these things would be better handled serverside too

[12:41] Latif Khalifa: zi you are wrong

[12:41] Latif Khalifa: all muting is done viewer side

[12:41] Kadah Coba: Well where is the unmuting happening on this anyway?

[12:41] Zi Ree: The mute *list* is server side.

[12:42] Latif Khalifa: the server just sends you the list of muted ids, and viewer does the work

[12:42] Zi Ree: Is it not?

[12:42] Zi Ree: There.

[12:42] TankMaster Finesmith: Zi is right, the mute list is stored on the server

[12:42] Zi Ree: That's what I sdaid.

[12:42] Latif Khalifa: it's more like a notecard in reallity

[12:42] Kadah Coba: If a muted person adding the muter to an ad-hoc causes the server to remove them from the mute list....

[12:42] Latif Khalifa: all the work is done on the viewer

[12:42] Simon Linden: The mute _list_ is stored in our system, but the actual stopping of displaying the messages is up to the viewer, which checks that list

[12:42] Leonel Iceghost: even animations and sounds? it means a muted avatar can fill your bandwidth?

[12:43] Jonathan Yap: Except for a jira number I think this issue is now well understood

[12:43] Arawn Spitteler: Does a calling card show a person as on line?

[12:43] Ardy Lay: So, if I exit an ad hoc conference I still get the messages from it?

[12:43] Zi Ree: So have the viewer cancel the ad-hoc automatically would be a fix, too.

[12:43] TankMaster Finesmith: the viewer requests the sound to play, its not automatically sent to the viewer

[12:43] Jonathan Yap: Zi, that is what latif and I have been saying

[12:43] Latif Khalifa: yes. auto closing ad-hoc conferences initiated by muted people is the way to go

[12:43] TankMaster Finesmith: plus its cacged, so in thery its only downloaded once

[12:43] Andrew Linden: brb. I gotta look up something for someone...

[12:44] TankMaster Finesmith: cached*

[12:44] Kadah Coba: I think ad-hocs work similar to group chat, the viewer has to tell the server that it wishs to disconnect from the chat. The server may or may not actually do that in a timely manner though.

[12:44] Jonathan Yap: I think I saw a jira update for this go by recently

[12:44] Zi Ree: I understood that it was done viewer side. My point was, it shouldn't be, since the list is already on the server and could be checked there before network packets are sent.

[12:45] Jonathan Yap: Zi, it is only 1 packet among thousands

[12:45] Ardy Lay: I would think checking the list would be less work that sending the packets.

[12:45] Kadah Coba: Depending on the viewer, receiving messages from a closed group chat may recreate that chat's window.

[12:45] Pauline Darkfury: Not sure if the bug is still there, but group chat used to have a bug where you couldn't close it until you'd received 2 messages. If you closed it after 1, it kept popping open again, ad nauseam

[12:45] Simon Linden: OK, so we need a jira, Jonathan has done a bunch of viewer work in this type of blocking, so if we can get the problem laid out I think it has a good chance of getting attention

[12:45] Latif Khalifa: Pauline, it still happens occasionaly. You close group chat but it keeps re-opening

[12:46] Kadah Coba: Is it known where the unmuting on this issue is occuring?

[12:46] Latif Khalifa: not that often though

[12:46] Zi Ree: That happens when the group chat packet was already on its way to you when you closed the window.

[12:46] Zi Ree: Most of the time it's slow group chat.

[12:46] Latif Khalifa: sometimes it happens repeatedly. group chat just won't close

[12:47] Ardy Lay: These initiators are able to initiate multiple ad hoc conference sessions. I have had many of them active from a single initiator at a time.

[12:47] Pauline Darkfury: My characterisation of the bug might not be 100% accurate. Just in terms of end user experience, closing after 1 message failed fairly reliably. Closing after 2 or more generally worked reliably.

[12:47] Pauline Darkfury: Could also be a time factor in there

[12:49] Simon Linden: Are there any other new topics or questions for the group?

[12:49] Pauline Darkfury: SVC-7265

[12:49] JIRA-helper: http://jira.secondlife.com/browse/SVC-7265

[#SVC-7265] PosJump breaks if object-entry is disabled

[12:49] Elisha Richez: oops sorry about the caps keys

[12:49] Pauline Darkfury: warpPos fails for some scenarios, posJump fails for others. Right now, we have no universal TP pad solution for sim-wide TPing

[12:50] Zi Ree: llSetLinkPrimitiveParamsFast() in a loop is pretty fast.

[12:50] Qie Niangao: llTeleportAgent() FTW

[12:50] Pauline Darkfury: Zi, that fails of there's a no-object-entry parcel in the way

[12:50] Qie Niangao: (doh. for agents. sorry)

[12:50] Zi Ree: True.

[12:50] Latif Khalifa: didn't warpPos always fail when there was no object entry parcel in the path?

[12:51] Pauline Darkfury: We need a llPosJump() which works region wide, is supported, and as lenient as possible on parcel perms, but doesn't enable grief

[12:51] Zi Ree: Make the treleporter a vehicle :D

[12:51] Pauline Darkfury: Yeah, warpPos failing that way is not new

[12:51] Pauline Darkfury: posJump used to be the solution, but it now has new failure modes introduced recently

[12:51] Zi Ree: Well, posJump is a hack ... I wouldn't expect it to be stable.

[12:51] Simon Linden: Are all these concerns for situations within the same region?

[12:51] Pauline Darkfury: Yup, talking same-region stuff only

[12:52] Pauline Darkfury: Cross-region has never been reliable anyway

[12:52] JoyofRLC Acker: In the alternative, an intelligent path seeking function that will find a safe route?

[12:52] Zi Ree: If tehre is one

[12:52] Pauline Darkfury: There's not always any safe route

[12:52] Simon Linden: in any case, we really should get llTeleportAgent() going for within the same region ... that seems like the best solution

[12:52] Zi Ree: llTeleportAgent() only if source and destination parcels are owned by the same agent/group?

[12:52] Jonathan Yap: You have that for Linden Realms, yes?

[12:52] Liisa Runo: TPAgent not going to fix the warp problems, we need to move them prims too

[12:52] Pauline Darkfury: Someone can own land on the north and south borders of a region, their TP pads can be blocked by someone who owns a 256m wide strip across the middle

[12:53] Pauline Darkfury: And yeah, we also need posJump for stuff beyond TP pads, such as big build rezzing

[12:53] Simon Linden: I think permissions is the biggest issue with it

[12:53] Rex Cronon: we also need telepor object and the avatars sitting on it:)

[12:53] Latif Khalifa: Pauline, i think they should be blocked with the current method used. What we need is legit way to position stuff within a sim without silly limitations

[12:53] Rex Cronon: teleport*

[12:54] Kadah Coba: Why not make llTeleportAgent() use the same prompts as normal lures?

[12:54] Pauline Darkfury: In terms of a cool user experience, it's nice to have them sitting on a beam object, as you can do departure and arrival anims and fx

[12:54] Leonel Iceghost: llTeleportObject(Id) <- includes avatars

[12:54] Zi Ree: A cool user experience woudl be jsut walking into the beam.

[12:54] Pauline Darkfury: We had that working very nicely until it got broken around the time of SVC-7265

[12:55] Jonathan Yap: Zi, to see that working now visit Linden Realms

[12:55] Pauline Darkfury: You already can just walk into the beam with RLV-enabled beams (and a RLV-enabled viewer)

[12:55] Andrew Linden: back

[12:55] Zi Ree: I do that with RLV, yes ;)

[12:55] Zi Ree: I'll do that Jonathan!

[12:55] Kadah Coba: The problem with llTeleportAgent() is that it has great potential to be extremely annoying.

[12:55] Jonathan Yap: Don't be wearing any huds if you walk into the transporter

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

[12:56] Pauline Darkfury: Yeah, llTeleportAgent needs a lot of perms checks and the ability to refuse it

[12:56] Zi Ree: llRequestPermissions(llDetectedKEy(0),PERMISSION_TELEPORT)

[12:56] note Genesis: why to do a llTeleportAgent ? the agen can use his/her map

[12:57] Pauline Darkfury: Map is slow and annoying

[12:57] Zi Ree: Map teleport doesn't work if you want a telehub.

[12:57] Simon Linden: IT's for objects or scripts that can send you to a specific place

[12:57] Jonathan Yap: note, because it would be a lot more seamless and a better experience

[12:57] Qie Niangao: usual perms should be fine. If you're wearing the script, or sitting on it, the perms granted implicitly, otherwise ask.

[12:57] Pauline Darkfury: And yeah, map TP can't work on forced landing points

[12:57] Liisa Runo: ppl. focus, we are talking about moving prims

[12:57] Zi Ree: Qie^

[12:57] Kadah Coba: That could be as annoying, Zi. Get it once then throws you all over

[12:57] Rex Cronon: there is no teleportobject function here: http://wiki.secondlife.com/wiki/Category:LSL_Functions

[12:57] Andrew Linden: Some content is much cooler with automatic teleport -- we're trying to make that possible.

[12:57] note Genesis: anyway , i am sure i can teleport in changging my slurl in the bar of navigation

[12:57] Pauline Darkfury: Well, it's both moving prims and moving people, Liisa

[12:58] Pauline Darkfury: There's many different legit scenarios broken by SVC-7265

[12:58] Zi Ree: KAdah, that's another thing. Permissions should be properly cleared server side.

[12:58] Andrew Linden: So we put that into the Linden Realms demo, a demo for ourselves as well as for residents.

[12:58] Jonathan Yap: hmmm, what if I drive a kart into the gateway?

[12:58] Kadah Coba: I wish, Zi. There could be a lot improved there.

[12:58] Pauline Darkfury: You can't TP like that, note if there's a forced landing point

[12:58] Liisa Runo: warp and posjump only move prims, some agents just happen to sometimes sit on a prim, but finding a fix to warp and jump is not going to get invented if we talk about TP

[12:58] Pauline Darkfury: And that's also slow and annoying compared to TP pads

[12:59] Pauline Darkfury: Right, but being able to use TP pads is one of the top applications of that feature

[12:59] Pauline Darkfury: The reason for mentioning it is to include the "why is it needed?" aspect

[13:00] Pauline Darkfury: Rezzing stuff, dynamic builds, etc, are all also very valid and needed reasons

[13:00] Leonel Iceghost: we are talking a lot, but lindens already have a llSetPos with proper checks and everything.. they can make another with another name taking the 10m part when they want

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

[13:01] Pauline Darkfury: Making llSetPos useful for the needed scenarios would also be a valid fix

[13:01] Liisa Runo: so, we get it for next server roll or the one after it?

[13:01] Andrew Linden: I've got to run at the hour. I've got another meeting that starts now.

[13:01] Andrew Linden: Thanks for coming everyone.

[13:01] Pauline Darkfury: Right now, llSetPos is unusable for a great many cases

[13:01] Jonathan Yap: Take care everyone

[13:01] Qie Niangao: thanks Andrew

[13:01] Liisa Runo: thanks everyone

[13:01] Pauline Darkfury: Thanks, Andrew, Simon, Kelly. Take care :)

[13:01] Rex Cronon: tc andrew

[13:01] TankMaster Finesmith: thx for everything, andrew, simon, kelly

[13:01] Pauline Darkfury: Have a good afternoon

[13:01] Rex Cronon: tc all those leaving



Simulator_User_Group

Prev 2011.12.02 Next 2011.12.09