Simulator User Group/Transcripts/2012.01.03
| Prev 2011.12.20 | Next 2012.01.06 |
List of Speakers
| Andrew Linden | Davido Chrome | Flip Idlemind |
| Kallista Destiny | Melvin Starbrook | Morgaine Dinova |
| Qie Niangao | Renae Daines | Rex Cronon |
| Sahkolihaa Contepomi | Simon Linden | Talarus Luan |
| Techwolf Lupindo | Vincent Nacon |
Transcript
[12:03] Kallista Destiny: There is a new one with Script performance
[12:03] Simon Linden: I'm not sure when Andrew will arrive, so we can get going in a second...
[12:03] Sahkolihaa Contepomi: Hey Andrew.
[12:03] Talarus Luan: He's here :P
[12:03] Simon Linden: good timing :)
[12:03] Davido Chrome: The Fancy greeter said he is here.
[12:03] Morgaine Dinova: Hi Andrew. Happy New Year :-)
[12:03] Melvin Starbrook: tala Andrew, happy new year too :))
[12:03] Andrew Linden: Hello. Yes, happy 2012.
[12:03] Flip Idlemind: Woooo!
[12:04] Davido Chrome: What's the diffrerence between the blue and pink graph?
[12:04] Vincent Nacon: wooot! and it's the END OF THE (mayaian) WORLD!
[12:04] Sahkolihaa Contepomi: Blue is smoothened out.
[12:04] Sahkolihaa Contepomi: 'Average' basically.
[12:04] Davido Chrome: I looked that up on new years eve, apparantly it's just the end of 52 yea<r cycle...
[12:04] Melvin Starbrook: dd 200
[12:04] Talarus Luan: Simon, SVC-7556 for Falcon
[12:04] JIRA-helper: http://jira.secondlife.com/browse/SVC-7556
[#SVC-7556] Objects with llSetKeyframedMotion() stop running after grid-wide (rollout) restarts
[12:04] Andrew Linden: Blue is a running average, I believe.
[12:05] Renae Daines: Blue appears to be a 3 second running average
[12:05] Simon Linden: I pinged him about that before vacation, Talarus ... are you still seeing it?
[12:05] Talarus Luan: yup
[12:05] Simon Linden: ok, I'll let him know
[12:05] Talarus Luan: I didn't check it yet today, but after the rolling restarts last Thursday, it was still failing.
[12:06] Talarus Luan: It is weird.. rotations don't stop, but positions do
[12:06] Simon Linden: That is strange
[12:06] Andrew Linden: I'll try to remember to mention it to Falcon too. I should be meeting with him later today.
[12:06] Davido Chrome: The last restart seemed to have improved vehicles getting stuck i9n prims, but don't take my word for it.
[12:07] Vincent Nacon: must be some conflict between position and the function or such..
[12:07] Andrew Linden: Hrm... the kernel upgrade was ongoing during the end of December. It should have completed
[12:07] Andrew Linden: which may have finally had an impact on region crossings across the world.
[12:08] Andrew Linden checks his email for a status update on that...
[12:08] Davido Chrome: Andrew, thank you very much for the link. Explains a whole lot of bugs I never figured out how I fixed...
[12:09] Davido Chrome: ( http://lslwiki.net/lslwiki/wakka.php?wakka=boolean )
[12:09] Andrew Linden: You're welcome Davido.
[12:10] Andrew Linden: The word is that the kernel upgrade completed around the 23rd.
[12:10] Simon Linden: Hmm, the forum / blog seems to be out-of date on the server rollout this morning
[12:10] Andrew Linden: well, "before Christmas" anyway. The planned schedule was to be complete on the 23rd.
[12:10] Techwolf Lupindo: and that new how? ;-)
[12:10] Techwolf Lupindo: (lag)
Total Avatar Scripts - 575
Highest - Morgaine Dinova: 92 (16%)
Lowest - Vincent Nacon: 0 (0%)
[12:12] Davido Chrome: The rollout -seemed- to do good things to Simboards getting stuck in Prims.
[12:12] Andrew Linden: the secondlifegrid.net status page appears to be more up to date.
[12:12] Davido Chrome: We were playing games when it happened. Had to change arenas two times cause the sims restarted. XD
[12:13] Davido Chrome: Afterwords, prims were less sticky. Could be that I managed to avoid the pegs though.
[12:13] Andrew Linden: "Simboards"? You mean for the Vetox Simball game?
[12:13] Davido Chrome: Yeah.
[12:13] Talarus Luan: Someone cleaned the molasses out of the simulation :P
[12:13] Andrew Linden: Someone pinged me about simball over vacation. I didn't read it unitl today. This is the first I've heard of Simball
[12:14] Davido Chrome: Must have been Lewis.
[12:14] Andrew Linden: although I noticed that it had been listed by some SL.com promotion pages already. Yeah, lewiz Zsun
[12:14] Davido Chrome: Oh, when I first saw Simball I hadn't thought SL was capable of maintaining such a game. But somehow, it works,
[12:14] Andrew Linden: er... I mean secondlife.com
[12:15] Rex Cronon: happy new year everybody:)
[12:15] Vincent Nacon: and happy doom-kind!
[12:15] Rex Cronon: what doom?
[12:15] Talarus Luan: Yus.. soon to be the year of the Dragon, so watch out! :P
[12:15] Vincent Nacon: Mayaian's doom, of course
[12:16] Rex Cronon: oh. lol
[12:16] Andrew Linden: Well, since we've been on vacation for the last week or more we don't have much news, so the table is open.
[12:16] Davido Chrome: Status on llSetRegionPos or what it was?
[12:16] Talarus Luan: How did your "Secret Project" go last week, Andrew? :D
[12:17] Rex Cronon: how our lindens this new year? ready to make sl even more exciting? ready to make lsl more powerfull:)
[12:17] Andrew Linden: Simon may have news about llSetRegionPos().
[12:17] Vincent Nacon: or give SL more life with AI bots
[12:17] Andrew Linden: Talaraus, I didn't manage to get to my secret project unfortunately. I ended up vacationing harder than I thought I would.
[12:17] Talarus Luan: Hehe.
[12:17] Simon Linden: Hmm, let me check where llSetREgionPos() is in the release pipeline
[12:17] Talarus Luan: Well, I TOLD you to do that. :P
[12:18] Talarus Luan: Glad you took my advice to heart. :D
[12:18] Davido Chrome: Oh, if I reach the third year in this candidate program I would love to make that my grad project.
[12:18] Andrew Linden: I spent my days working on motorcycles, playing Skyward Sword, and playing around with the pyglet python module, and kytten GUI module
[12:18] Davido Chrome: AI that is.
[12:18] Vincent Nacon: btw, did llSetRegionPos come with REGION_POS flag for llSPP / llSPPF?
[12:19] Flip Idlemind: Was it determined if llSetRegionPos() is also going to come with...
[12:19] Flip Idlemind: Vincent beat me
[12:19] Talarus Luan: Ninja!
[12:19] Vincent Nacon: stop reading my mind!
[12:19] Simon Linden: No Vincent, it just works as the stand-alone function
[12:19] Flip Idlemind: What about in the future?
[12:19] Vincent Nacon: hang on... making tinfoil hat
[12:20] Simon Linden: It has passed QA, and there's a chance it will be in an RC channel tomorrow. If not this week, then I'd expect it next week
[12:20] Vincent Nacon: well it should evenfully be added in at some point, Simon
[12:20] Qie Niangao: I've lost track: Is encroachment control enabled on Mainland yet?
[12:20] Talarus Luan: Awesome. :)
[12:20] Andrew Linden: Not enabled yet Qie, as far as I know.
[12:20] Qie Niangao: thanks.
[12:20] Davido Chrome: How will it work? I am hoping to use it in a ball clock that contains a peg script. If a player has the ball more than set seconds it TPs over and you loose the ball. Todays version uses one of those warp hacks.
[12:20] Vincent Nacon: to make LIST sorting easier
[12:21] Rex Cronon: is good that u relaxed a little adrew. now u r ready to fix all the problems in sl;)
[12:21] Rex Cronon: andrew*
[12:21] Simon Linden: The API is: integer llSetRegionPos( vector anywhere_in_region_or_10m_into_neighbor );
[12:22] Vincent Nacon: ahh 10m buffer
[12:22] Flip Idlemind: I would love to be able to do the same thing in llSetLinkPrimitiveParamsFast though, so I can do as many things "at once" as possible
[12:22] Simon Linden: It only applies to the root prim (It moves the whole object), has no sleep penalty, and doesn't require a path to reach that point, but does require parcel perms, etc
[12:22] Kallista Destiny: The vector is relative to your current position?
[12:23] Davido Chrome: Does that mean you can build a Tardis with it?
[12:23] Talarus Luan: absolute to sim corner
[12:23] Simon Linden: No, it's region coordinates
[12:23] Talarus Luan: relative to sim corner :P
[12:23] Rex Cronon: so, no more warp3d simon? now wee use llsetregionpos?
[12:23] Talarus Luan: Yus
[12:23] Davido Chrome: And rollout is possibly tomorrow?
[12:23] Talarus Luan: WarpPos/PosJump will now be made redundant.
[12:23] Vincent Nacon: I wasn't aware that 10m buffer was added in but I still think that's a bad idea, potential griefing
[12:24] Talarus Luan: No more griefing than already is possible with WarpPos
[12:24] Vincent Nacon: errr correction... potential grid attack
[12:24] Andrew Linden: Davido, it might show up in an RC channel tomorrow, not on the main channel.
[12:24] Flip Idlemind: Not exactly Talarus because, as we've been saying, there's no matching llSetLinkPrimitiveParamsFast flag
[12:24] Vincent Nacon: or grid spamming
[12:24] Vincent Nacon: even if it's slow
[12:24] Vincent Nacon: but I guess we'll find out soon enough
[12:25] Talarus Luan: Doesn't need to be in llSLPP/llSLPPF for warppos/posjump replacement
[12:25] Simon Linden: If anyone figures out a new griefing problem with it, definitely let us know
[12:25] Vincent Nacon: you can't use it in Linkset
[12:25] Davido Chrome: Question, llSetRegionPos() will be less laggy then list l=[PRIM_POSITION,llDetectedPos(vIntCounter)];
l+=l;l+=l;l+=l;l+=l;l+=l;l+=l;l+=l;l+=l;l+=l;
llSetPrimitiveParams(l);
[12:25] Flip Idlemind: It does if you want to move something at change another param at the same time
[12:25] Vincent Nacon: only applied on root
[12:25] Davido Chrome: Right?
[12:25] Flip Idlemind: and change*
[12:25] Simon Linden: but I think you can't really do anything new with it, but it cleans up the hacks currently needed
[12:26] Vincent Nacon: Yes Kat
[12:26] Talarus Luan: So, you change the rest of the params after you call llSetRegionPos; the difference in speed should be unnoticeable.
[12:26] Davido Chrome: Goody!
[12:26] Talarus Luan: Since there are no delays
[12:26] Flip Idlemind: But there would still be a difference in speed
[12:26] Talarus Luan: No there won't
[12:26] Vincent Nacon: and to avoid such a high packet loss in the viewer when changing height from ground level to the sky
[12:26] Flip Idlemind: It's the same reason PRIM_LINK_TARGET was invented
[12:26] Flip Idlemind: Yes there will! 2 functions takes longer than 1 function
[12:27] Talarus Luan: The updates to the viewers do not go at script speed.
[12:27] Flip Idlemind: Yeah, they go slower
[12:27] Talarus Luan: The majority of the time, the updates are aggregated
[12:27] Vincent Nacon: but better at handling it
[12:28] Davido Chrome: So, uh, does that the answer to my question is disputed?
[12:28] Talarus Luan: You *won't* notice the difference. I certainly can't tell the difference.
[12:28] Vincent Nacon: more or less, not really
[12:28] Simon Linden: Right, the updates sent to the viewer are not directly tied to teh script ... script movement or changes will cause updates to happen, but there's no guaranteed 1-to-1 relationship
[12:28] Flip Idlemind: And more than that, I want a llSetLinkPrimitiveParamsFast flag simply from a "making scripting easier for me" point of view
[12:28] Vincent Nacon: let's just say, it's not really much to worry about, depends on what you need it for
[12:29] Melvin's Windup key TO whispers: Melvin Starbrook winds up the key unassisted.
[12:29] Davido Chrome: Vincent, in my case a prim that is supposed to catch a player that holds the ball too long.
[12:29] Talarus Luan: That's fine, but that doesn't alter the fact that llSetRegionPos makes WarpPos/PosJump redundant.
[12:29] Flip Idlemind: I like to put as many parameter changes into 1 function call as possible
[12:29] Vincent Nacon: but it'll be better than ending up at 0,0,0 for short moment
[12:29] Vincent Nacon: ahh... sounds like you need something else, Kat
[12:29] Flip Idlemind: WarpPos/PosJump can be used in llSLPPF
[12:29] Qie Niangao: It would be tidier, to have the llSLPP flag, but this is hardly the most urgently needed prim parameter. (slice, for example, and all the projected texture settings)
[12:29] Simon Linden: We'll have to re-visit how this might be added to the other functions. It doesn't make a lot of sense to me to add it to a link-oriented function since it only works on the root, but that's the kind of thing to sort out
[12:30] Flip Idlemind: So it's not *exactly* a replacement
[12:30] Andrew Linden: Right, until we support the region-wide object movement in llSPP*() then simultaneous rotation+region-wide-position changes won't be possible.
[12:30] Kelly Linden: Doing too much in a single llSPPF call can actually hurt sim performance as we can't split up the work across frames. Right now there is an implicit reasonable limit due to script size. However if script sizes change in the future we may actually need to add a limit on list length passed to llSPP*
[12:30] Talarus Luan: I didn't say it was an "exact" replacement. I said it made them redundant. There's a difference.
[12:30] Vincent Nacon: what's the limit again? 10m or 64m range?
[12:30] Meeter: Timecheck : User Group is half over
[12:30] Talarus Luan: The functionality is there
[12:30] Flip Idlemind: Ok, but Simon, what you have to realize is, the only reason I'm specifically referencing llSetLinkPrimitiveParamsFast is because it's the only function with "FAST" in it
[12:31] Flip Idlemind: There was no llSetPrimitiveParamsFast (without "LINK")
[12:31] Vincent Nacon: err not 64m ...54m
[12:31] Simon Linden: Right, Flip
[12:31] Flip Idlemind: For the following reason: You can use llSetLinkPrimitiveParamsFast on the root prim, so 2 functions weren't needed
[12:32] Flip Idlemind: So to suggest a REGION_POS flag isn't needed in llSetLinkPrimitiveParamsFast because it can't be applied to linksets is wrong. It's the "fast" part I'm after
[12:32] Davido Chrome: Ranges, makes me think about another question. llDetected, and I think the wiki says that senors have a max range of 92. Is there a way to overcome that?
[12:32] Vincent Nacon: oh that's right, my bad, I was the one who said llSPPF
[12:32] Talarus Luan: llSetRegionPos is as fast as including it in llSLPPF
[12:33] Talarus Luan: Speed isn't an issue in that case
[12:33] Flip Idlemind: True, IF you're only changing position
[12:33] Talarus Luan: There are no delays
[12:33] Talarus Luan: Even if you change other things
[12:33] Simon Linden: I can understand your arguement ... and it makes sense that you should be able to do a move + rotation in one operation, which will result in one update
[12:33] Vincent Nacon: senors goes up to 100m
[12:33] Talarus Luan: Script speed >>> update speed
[12:33] Andrew Linden: Good question... would it be possible to expand the sensor range without breaking some content?
[12:33] Vincent Nacon: not sure why it says 92
[12:33] Simon Linden: With the new code, you'd do llSetRegionPos(), possibly an update, rotate, another update
[12:33] Vincent Nacon: well Andrew, for sure, I know it will break contents
[12:34] Vincent Nacon: I've seen a lot of trick working around that range
[12:34] Davido Chrome: My imagination needs can't think of anything it would break ad-hoc, but that doesn't mean anything...
[12:34] Talarus Luan: Simon, what's the percentage chance of an update between a llSetRegionPos() call and a succeeding llSLPPF() call?
[12:34] Leonel Iceghost: not break, but make old content give more results
[12:34] Talarus Luan: Roughly
[12:34] Simon Linden: At minimum, we'd get new behavior as scripots picked up more results, I think
[12:34] Calcite Serendipity: Right now if you specify a range that is too big do you get an error or does the scanner just stop at the limit?
[12:34] Flip Idlemind: Suppose there's a scenario where I want to change an objects position, rotation, color, etc... If the position is within 10 meters, great, I can throw it all into 1 llSLPPF call. BUT, if it's not, then I have to use llSetRegionPos() as well. PLUS, I would have to check that every time
[12:34] Flip Idlemind: if(dist < 10)
[12:34] Flip Idlemind: Or something
[12:35] Simon Linden: yep
[12:35] Vincent Nacon: I mean, there are scripts that are expecting the limit range to work around, which will break if they get result beyond their given work around
[12:35] Talarus Luan: If there is a chance of it being >10m, then always do a llSetRegionPos and don't try to condition it into the llSLPPF call
[12:36] Andrew Linden: Yeah, so I'm not inclined to expand the sensor range. I'm sure I'd break something.
[12:36] Vincent Nacon: there are some scripts that does it... like mostly in weapons, shields, HUD target tracking... etc etc
[12:36] Davido Chrome: How does such a workaround work? Does the sensor prim teleport about, or what?
[12:36] Flip Idlemind: In that case, there would always be multiple function calls, when there could just as easily be one
[12:36] Talarus Luan: So?
[12:36] Talarus Luan: One extra function call
[12:36] Vincent Nacon: well it's a complex one like HUD target tracking
[12:36] Talarus Luan: Less code, more than likely.
[12:36] Davido Chrome: So a new function then? llLongRangeSensor?
[12:36] Simon Linden: We really need script versioning and then we could raise it
[12:37] Leonel Iceghost: Andrew is there a way you can start to add "new events revisited"? with its functions?.. it is ridicolous, a half of the things cannot be improved because old content breaking
[12:37] Talarus Luan: Because you don't have the if statement, and you aren't adding it to a list.
[12:37] Vincent Nacon: naa... that sounds bit silly
[12:37] Vincent Nacon: if we can have a full region scan.
[12:37] Davido Chrome: llSenorThatSeesReallyFar then?
[12:37] Flip Idlemind: If I want to use as few function calls as possible, what exactly is the argument against that?
[12:37] Draconis Neurocam: i think it would be nicer to extend rez distance beyond 10 meters now that we have larger prims
[12:37] Vincent Nacon: I'd suggest something like regional sensor
[12:38] Talarus Luan: Efficiency, availability?
[12:38] Vincent Nacon: llScanRegion ?
[12:38] Renae Daines: Regional sensor with a built in 2 second (+?) delay
[12:38] Talarus Luan: Fewer function calls does not necessarily equate efficiency.
[12:38] Flip Idlemind: Oh, Oh! llListRegionAgents() !!!
[12:38] Flip Idlemind: Or something
[12:38] Flip Idlemind: would be nice
[12:38] Vincent Nacon: well why the delay? once you have the key, you still can track that agent/object with other function without delay
[12:38] Kallista Destiny: That would be very useful
[12:39] Davido Chrome: Another question, is there a good reason why there isn't an official llName2Key?
[12:39] Renae Daines: that would be the reason for the delay, but i think Flip has the right idea
[12:39] Flip Idlemind: That's on Kelly's todo list, I know
[12:39] Flip Idlemind: I bug him about it all the time
[12:39] Kelly Linden: :)
[12:39] Flip Idlemind: llName2Key I mean
[12:39] Calcite Serendipity: There is a name2key call in the viewer code
[12:39] Vincent Nacon: yeah and I'm tired of seeing llName2Key kept coming up at meeting
[12:39] Vincent Nacon: :P
[12:40] Talarus Luan: heh.. llTeleportAgent has been brought up just about as long. :P
[12:40] Qie Niangao: ahem. Speaking of llTeleportAgent. Any timeline?
[12:40] Vincent Nacon: well yeah except that doesn't have potential flaw
[12:40] Vincent Nacon: ...oh wait
[12:41] Andrew Linden: No Qie, we don't know the timeline on that.
[12:41] Talarus Luan: llName2Key... which name?
[12:41] Rex Cronon: we should call it name2kelly ;)
[12:41] Talarus Luan: user or display?
[12:41] Vincent Nacon: yeah, can't be "name"
[12:41] Kallista Destiny: User
[12:41] Qie Niangao: thanks. (drat, but thanks)
[12:41] Renae Daines: user... display has no point tbh
[12:41] Vincent Nacon: llUsername2Key then
[12:41] Kallista Destiny: Display is not guarenteed to be unique
[12:42] Davido Chrome: Would I need to write a parser for that?
[12:42] Vincent Nacon: firstname.lastname?
[12:42] Flip Idlemind: There's a third option. What about legacy name to key?
[12:42] Davido Chrome: I.e. that turns Davido Chrome to davido.chrome.
[12:42] Vincent Nacon: how's that different, Flip?
[12:43] Flip Idlemind: It's different in the following way:
[12:43] Qie Niangao: Newusername123 Resident
[12:43] Kallista Destiny: firstname<space>Lastname
[12:43] Vincent Nacon: all legacy name breaks down with a "dot" in between two name
[12:43] Kelly Linden: Should be able to handle username and legacy names with the same function.
[12:43] Flip Idlemind: If I script a vendor and someone wants to give me a gift, they're going to type "Flip Idlemind", not "flip.idlemind"
[12:43] Kallista Destiny: if <space> is missing assume Resident
[12:43] Vincent Nacon: hmm
[12:43] Calcite Serendipity: Does everyone know that having some kind of pickable last names for new accounts is coming back soon?
[12:43] Vincent Nacon: muhaha! no
[12:44] Talarus Luan: I'd bet there will be some people typing "F L I P" :P
[12:44] Calcite Serendipity: Rodvik announced that recently
[12:44] Kallista Destiny: I will believe that when it actually happens
[12:44] Qie Niangao: You get your choice of last names... as long as you choose "Resident"
[12:44] Talarus Luan chuckles
[12:44] Davido Chrome: Just writing Parsers is one of those things that I believe might be fun the first time, but gets old fast.
[12:44] Kallista Destiny giggles
[12:44] Calcite Serendipity: Qie, it is supposed to change this quarter, maybe even this month
[12:45] Flip Idlemind: Well that would be unfortunate. But if someone were instructed to "type the recipient's full name" or something like that, they probably wouldn't type my display name, but they probably wouldn't type my username either
[12:45] Qie Niangao: Calcite: I know, I read that somewhere too. I'm just being a pest.
[12:45] Talarus Luan: You've never dealt with customer service before. :P
[12:45] Renae Daines: that's why you default it down to the username :P
[12:45] Davido Chrome: The ball clock uses the names that the Simball server shouts.
[12:46] Davido Chrome: Which is in the format Davido Chrome.
[12:46] Talarus Luan: "But it said type their name, and I typed it exactly as it showed up in chat!"
[12:46] Kallista Destiny: The question is "Are users named Rgoing to gt an option to elect a new last name>"
[12:46] Flip Idlemind: Funfact: It's actually not even possible to type my display name
[12:46] Flip Idlemind: There are 2 spaces between the letters
[12:46] Vincent Nacon: Kall, with a question like that sounds like a nightmare to deal with
[12:46] Andrew Linden: yeah, llName2Key() sounds tricky. I've never really thought about that one before.
[12:47] Talarus Luan: Display names should have been taken out back and given the Ol' Yeller treatment. :P
[12:47] Kallista Destiny: No kidding
[12:47] Leonel Iceghost: you don't have a database?
[12:47] Kallista Destiny: No Display Names are useful
[12:47] Renae Daines: llUsername2Key would be far more useful
[12:47] Calcite Serendipity: Andrew, there is a viewer function that does that, but you have to do a test and remove "Resident" last names
[12:47] Vincent Nacon: nope, only username and key, no need for silly displayname
[12:47] Vincent Nacon: but the damage is done....
[12:48] Draconis Neurocam: i still don't understand why i am able to set my display name as draconis.neurocam, and it show my 'username' as draconis.neurocam under it, it seems redundant
[12:48] Kallista Destiny: vis Mine I could not gt my RP father's last name
[12:48] Andrew Linden: There is a database, and a name cahce lookup table in simulator RAM too.
[12:48] Flip Idlemind: Not only llUsername2Key but also llRequestAgentUsername
[12:48] Flip Idlemind: Or something
[12:48] Flip Idlemind: to use with dataserver()
[12:48] Davido Chrome: Doesn't thatone exist allready?
[12:48] Kelly Linden: It would have to work async w/ dataserver. key llUsername2Key wouldn't work.
[12:48] Flip Idlemind: Or requestagentkey
[12:49] Flip Idlemind: Whatever we're talking about
[12:49] Kallista Destiny: The trick is that you have a Display name set at all, I think.
[12:49] Kelly Linden: It would need to be key llRequestAvatarKey(string name) or something.
[12:49] Simon Linden: draconis : do you mean in the viewer chat, the double names? I can't stand that either
[12:49] Renae Daines: as long as you could pull the uuid from a username it would be a step in the right direction.. dataserver or not
[12:49] Andrew Linden: However, handling the display name issue is a problem: you just have to decide one way or the other to support it or not... and it appears that the system just wouldn't work for display names... name collisions as was mentioned
[12:49] Draconis Neurocam: yeah, and over my head simon
[12:49] Kallista Destiny: if ( DN != "")
[12:50] Andrew Linden: so it would have to be by legacy name only
[12:50] Simon Linden: It's a viewer problem - and seems like an easy fix to just do the display right
[12:50] Talarus Luan: Speaking of Viewer issues.. is there a bona fide complement of this user group for the viewer?
[12:50] Andrew Linden: and then there is the issue of when the name is not in the cache then the id can't be returned in real-time
[12:50] Vincent Nacon: so.... let's go yank Display name function out quickly like you guys did with Joint function? muhaha!
[12:50] Talarus Luan: Oz's sounds like just Open Source chat and contributions
[12:50] Andrew Linden: the cache has to ask for it from the aforementioned database
[12:50] Andrew Linden: which takes finite time
[12:51] Qie Niangao: A dataserver event beats heck out of an http_response from a third party that could poof tomorrow.
[12:51] Leonel Iceghost: isn't it the same than llkey2name?
[12:51] Sahkolihaa Contepomi: Talarus - I think the closest one to that would be the content creation user group.
[12:51] Talarus Luan: The cache is either very small, or it has Alzheimer's
[12:51] Flip Idlemind: I'm fine with it taking finite time, as long as it's "official". External database take infinite time, in some cases
[12:51] Kallista Destiny: it's not a 'fast' I/O operation
[12:51] Flip Idlemind: IE they don't work
[12:51] Davido Chrome: llName2Key used in games wouldn't have that problem, because everyone present is in said Cache, right?
[12:51] Calcite Serendipity: Andrew, I did some testing with the viewer function and couldn't get it to not always return the agent's UUID (but I did code in case of a failure to return the data immediately)
[12:51] Renae Daines: it could return useful information like "pending" instead of the id, so we know to recall that request a second time
[12:51] Renae Daines: instead of ""
[12:52] Talarus Luan: Thanks, Sahkohlihaa. :)
[12:52] Leonel Iceghost: "(pending)...???"
[12:52] Flip Idlemind: It's possible to try to use an external database to lookup the key of an extremely anti social person who's never been in range of a sensor
[12:53] Andrew Linden: huh, yeah we already have a llKey2Name() method, and it has a "must already be present or known" caveat
[12:53] Vincent Nacon: yeah FLIP
[12:53] Leonel Iceghost: yeah, that is what we ask
[12:53] Leonel Iceghost: llName2Key for present avatars, and a database llRequest
[12:53] Vincent Nacon: if you got a server to run through searches by KEY instead of by name
[12:53] Vincent Nacon: muhaha!
[12:53] Renae Daines: external databases aren't very secure (or reliable for that matter) but then again neither is the dataserver from time to time lol
[12:53] Rex Cronon: since we all already have a web page, we could go to that page using a user key
[12:53] Andrew Linden: so... a reverse lookup with the exact same caveat would be theoretically possible... but not for objects
[12:54] Andrew Linden: hrm... that would be an expensive lookup in the RAM cache
[12:54] Andrew Linden: since it isn't sorted by avatar name
[12:54] Draconis Neurocam: even it being only in sim would be a step in the right direction, as of now we still have to do an http look up for that andrew
[12:55] Leonel Iceghost: I'm fine with only avatars, where would I get names of prims from, if they are mine I can already comunicate
[12:55] Renae Daines: from a vendor stand point, looking up the users ID via their username (easily workable with legacy names provided) then its able to bypass the hacked together function of grabbing a username's uuid for delivery or payment
[12:55] Vincent Nacon: maybe two servers? one in sort by key and other sort by name?
[12:55] Andrew Linden: so... possible, but it puts a new load on the simulator, either CPU load for a slow cache scan or memory load for a dupe cache sorted by avatar name
[12:55] Meeter: Timecheck : User Group is almost over
[12:56] Andrew Linden: I can see why we haven't tackled that one yet.
[12:56] Davido Chrome: If you don't mind me being onetracked, imagine a Simball game, where the keeping track of balls can use UUID that it looks up upon registration with the server at start, would be much less laggy than other methods, right?
[12:56] Qie Niangao: in the meantime: just the dataserver request would be a huge win.
[12:56] Vincent Nacon: either way... I'd just stick with Key. I can't really see how llName2Key is a must.
[12:56] Leonel Iceghost: there are 100 avatars maximum in a sim.. how bit can be that cache
[12:56] Leonel Iceghost: how big
[12:56] Renae Daines: right now people are using a jerry rigged version of viewer search to acquire the username uuid =/
[12:56] Rex Cronon: btw. can we a have a new lsl function that given a uuid returns what is it. like llGetType(key uuid) return texture, object, script...
[12:57] Calcite Serendipity: Andrew, how is the lookup any less intense than calls to check the mute list?
[12:57] Andrew Linden: ha! that's a funny one Rex.
[12:57] Vincent Nacon: Name2Key may possibility open door for new type of marketing/group invite spam
[12:58] Talarus Luan: Is there a single database anywhere for all UUIDs?
[12:58] Talarus Luan: I don't think there is
[12:58] Andrew Linden: I was thinking about the name cache which is more general than the list of avatars online
[12:58] Rex Cronon: is very useful. sometimes i really need to know who/what has that uuid
[12:58] Draconis Neurocam: vincent its not like someone couldnt already do that with the name2key servers residents have made
[12:58] Simon Linden: The cache has all the key / name combinations from profiles, friends lists, etc
[12:58] Talarus Luan: Yeah, it would be useful. The issue is that it would be a coordinated query among multiple disparate databases
[12:59] Vincent Nacon: the problem is, spammer can easily make list of name by guessing possible variation of it and then run search in name combination. The same way how spammer find your email without actually knowing your email first.
[12:59] Renae Daines: they can also crawl through open groups achieving a similar result with uuids =/
[13:00] Davido Chrome: Name2key could replace llSensor. You can then get agent or object details via key.
[13:00] Leonel Iceghost: it is easier to get a database of Name2Key services Vincent
[13:00] Vincent Nacon: and yes, i know about that... but let's not open the door just because it's leaking bit of water
[13:00] Andrew Linden: Rex, I don't understand how a general key2info lookup would be useful/needed. Really you end up with a key totally without context?
[13:00] Andrew Linden: The space of possible keys is big.
[13:00] Meeter: Thank you for coming to the Server User Group
[13:01] Talarus Luan: More than all the protons in the entire universe, supposedly.
[13:01] Andrew Linden: There is even a possibility of key collision across contexts... a texture_id the same as an object_id wouldn't cause a problem.
[13:01] Vincent Nacon: but think logically... if you need their Key... use scan because they're "there" for something, like buying or to play a game or whatever.... but how do you sort that out from spammers?
[13:01] Vincent Nacon: for whom was not in range nor in the same sim?
[13:01] Davido Chrome: Scan?
[13:01] Rex Cronon: lets say i have key. i want to know if that key is a object, sound texture. sometimes my viewer crashes and the last thing i see in the dos windos is a listof keys. i want to know if it was a texture a sound or an object
[13:02] Kelly Linden: Have a good week everyone. :)
[13:02] Vincent Nacon: ahh time's up
[13:02] Sahkolihaa Contepomi: See you Kelly, Simon & Andrew.
[13:02] Rex Cronon: tc kelly
[13:02] Vincent Nacon: take care Kelly
[13:02] Draconis Neurocam: take care everyone
[13:02] Calcite Serendipity: Thank you everyone
[13:02] Qie Niangao: thanks Kelly, everyone. Have fun
[13:02] Leonel Iceghost: you too Kelly, happy new year for all
[13:02] Talarus Luan: Ciao Lindens :D
[13:02] Rex Cronon: just interested in keys in the same sim
[13:02] Rex Cronon: tc all those leaving
[13:02] Melvin Starbrook: script version sounds as a great idea
[13:02] Davido Chrome: Rex, a debug option? Must be other ways to get verbose crash reports.
[13:02] Kallista Destiny: Tahnks for an intresting meeting, and Happy New Year
[13:02] Andrew Linden: Well, a general purpose key2info lookup would be a very hard project
[13:02] Melvin Starbrook: hihi thank you
[13:03] Andrew Linden: oh right... I've got a meeting to attend now
[13:03] Andrew Linden: gotta run
[13:03] Andrew Linden: Thanks for coming everyone.
[13:03] Calcite Serendipity: How does Object Details work in the viewer right now?
[13:03] Rex Cronon: i undesrtand is hard. but it might be easier if only for things in same sim
[13:03] Vincent Nacon: take care Andrew and Simon
[13:03] Davido Chrome: Thanks Andrew.
[13:03] Leonel Iceghost: bye Andrew, thank you
[13:03] Morgaine Dinova: Tc Lindens, and everyone else.
[13:03] Rex Cronon: tc andrew
[13:04] Melvin's Windup key TO: Melvin Starbrook's windup key has run out.
| Prev 2011.12.20 | Next 2012.01.06 |