Simulator User Group/Transcripts/2013.10.22

From Second Life Wiki
Jump to navigation Jump to search
Prev 2013.10.15 Next 2013.10.29

List of Speakers

Adamburp Adamczyk Andrew Linden Annoying User
Duckie Dickins Ima Mechanique Inara Pey
Jenna Felton Kelly Linden Kennylex Luckless
Loki Eliot Lucia Nightfire Mona Eberhardt
Nalates Urriah Qie Niangao Rex Cronon
Simon Linden TankMaster Finesmith Whirly Fizzle
Yuzuru Jewell

Transcript

[12:02] Yuzuru Jewell: Hello, Andrew.

[12:02] Simon Linden: Hi everyone ... I can get started with the server release news

[12:02] Andrew Linden: hello

[12:02] Rex Cronon: hi simon

[12:02] Simon Linden: We updated the main server channel this morning

[12:02] Rex Cronon: hi andrew

[12:02] Simon Linden: The forum post is here: http://community.secondlife.com/t5/Second-Life-Server/Deploy-for-the-week-of-2013-10-21/td-p/2277913

[12:03] Simon Linden: Tomorrow the RC are NOT getting updated so we'll have the same version grid-wide, likely until next Wednesday

[12:03] Simon Linden: RC channels*

[12:03] Mona Eberhardt: And here's Kelly... Now we're waiting for Baker!

[12:03] Inara Pey: Will the RCs still be restarted?

[12:03] TankMaster Finesmith: so the grid wil e al equal for a week?

[12:04] Andrew Linden: Baker can't make it today.

[12:04] Adamburp Adamczyk: *CENSORED*

[12:04] Simon Linden: Exotix - no, there's no planned restarts

[12:04] Jenna Felton: hello all

[12:04] TankMaster Finesmith: feel free to restart it on your own though!

[12:05] Rex Cronon: hi

[12:05] Duckie Dickins crashes his mainland sim to restart it.

[12:05] Simon Linden: I know Baker has been working on getting his group ban work onto the beta grid, but am not sure when that will be available for testing

[12:06] TankMaster Finesmith: he's also busy with company

[12:06] Simon Linden: it's an interesting roll-out plan since it involves updates all over to servers, databases and viewers

[12:06] Whirly Fizzle: Yay! Hopefully soon.

[12:06] Andrew Linden: I don't have any news... except that I have finished rebuilding my Windows machine and successfully build the SL viewer this morning.

[12:06] Duckie Dickins: I would of thought you'd have a minion to do that for you. :)

[12:07] Duckie Dickins: err intern? :)

[12:07] Andrew Linden needs more minions.

[12:07] TankMaster Finesmith: can never have to many minions

[12:07] rcdsQueChatLog: Jenna Felton, you can read the log here:

http://rcds.nfshost.com/ques_view_chatLog.php?queOwner=llsl:Rex+Cronon&queName=chatLog&pg=1

[12:07] Simon Linden: So I think that's it for news ... the table's open for topics or questions

[12:07] Andrew Linden: No actually, I'm not sure I'd leave this to a minion.

[12:07] TankMaster Finesmith: lol

[12:08] TankMaster Finesmith: what could go wrong? :P

[12:08] Andrew Linden: I actually installed Cygwin python as well as the regular python install and had to do some extra work to make that work correctly.

[12:08] Mona Eberhardt: Any chance that we'll see materials (normal, specular maps) control via LSL as per MATBUG-359? As it is, it feels like it's been implemented only in half. Adding LSL functionality that'll allow creators to change normal and specular maps along with the main texture will be a godsend to content creators. I mentioned it yesterday at Nyx's meeting and he suggested that I bring it up here as well.

[12:09] Andrew Linden: My first thought about that is...

[12:09] Andrew Linden: One of the fundamental design flaws of SL was allowing textures on object faces to be specified by UUID only.

[12:10] Andrew Linden: I think that the material system is a bit different... not just a set of UUID's on faces.

[12:10] Andrew Linden: I'd have to read the code to know more...

[12:10] Simon Linden: hmmm that is an interesting one

[12:11] Andrew Linden: actually a question for those of you who use materials... how do materials exist in the inventory or object contents?

[12:11] Andrew Linden: Can they exist there as items?

[12:11] Andrew Linden hasn't used the feature yet at all.

[12:11] Rex Cronon: u can create TextureProperties2.0 object that has an uuid and u set the uuid for the texture on an object to the uuid of the TextureProperties2.0

[12:12] Nalates Urriah: There is no material asset. Materials are an atribute of objects as additional textures.

[12:12] Ima Mechanique: But the texture used for a "material" can be stored in a prim's contents though?

[12:13] Whirly Fizzle: Urs just 2 extra textures for the normal & specular maps. Set on the object in the same way you set the normal diffuse texture

[12:13] Whirly Fizzle: *its

[12:13] Nalates Urriah: Yes, Ima

[12:13] Kelly Linden: Has anyone that uses materials written up some ideas on what the LSL API would look like for them?

[12:13] Ima Mechanique: I think that was Andrew's question

[12:14] Andrew Linden: Well, what I was getting at is that I wouldn't want to provide an API that can just set the UUID's of textures to arbitrary values.

[12:14] Mona Eberhardt: Correct me if I'm wrong, but couldn't this be done by expanding llSetPrimitiveParameters?

[12:14] Kelly Linden: MATBUG-359 doesn't have any proposals for what it should look like just 'add lsl support for materials'.

[12:14] Mona Eberhardt: llSetPrimitiveParams*

[12:15] Kelly Linden: this is a case where at least I am not a user of materials and I don't have a clear idea of what you would do with materials with LSL, were the feature to exist.

[12:15] Jenna Felton: just a new property PRIM_MATERIAL that is similar to texture and color properties,

[12:15] Loki Eliot: PRIM_NORMAL

[12:15] Qie Niangao: Yeah, it's really pretty obvious, once you open the Texture tab of the build tool.

[12:15] Mona Eberhardt: Or PRIM_NORMAL and PRIM_SPEC

[12:15] Loki Eliot: PRIM_SPECULAR

[12:15] Mona Eberhardt: Yup, what Loki says.

[12:15] Jenna Felton: And talking about materials, is it possible to extend the material system also by a shadow map? That could make some mesh hacks obsolete

[12:16] Kelly Linden: jenna: that is something you may have to take back to nyx.

[12:16] Andrew Linden: I don't know how hard it would be to extend the material system.

[12:16] Andrew Linden: Yeah, best to ask someone who actually worked on that project.

[12:16] Mona Eberhardt: Now, as to what could be done with such a functionality...

[12:17] Mona Eberhardt: You guys know of the various colour/resize/texture-changing HUDs used in several products (shoes, for instance).

[12:17] Kelly Linden: generally speaking those are not some of my favorite uses of LSL, but I am aware of them.

[12:17] Jenna Felton: ok Kelly, Andrew

[12:17] Qie Niangao: The slightly tricky bit for Materials in LSL is the possibility of animating the material maps separately from the diffusemap texture.

[12:18] Loki Eliot: id find it usful for changing surfaces from looking dry to looking wet

[12:18] Mona Eberhardt: By extending LSL functionality, we'd be able to change the texture, the normal and the specular map at the same time, and you'd switch from, say, top-grain leather to velvet or suede or leatherette, and you'd also get the proper look. And yes, changing from a dry to a wet look, as Loki said, is another bonus.

[12:19] Loki Eliot: XD

[12:19] Lucia Nightfire: uh ohs

[12:19] Kelly Linden: andrew: it looks like we treat the specular/normal maps as just regular textures in inventory, so we could require they be in the object contents.

[12:20] Ima Mechanique: why require them to be in contents?

[12:20] Andrew Linden: That would be my preference -- limit the LSL API to set material textures to that are in object contents.

[12:20] Qie Niangao: um, yeah, why?

[12:21] Jenna Felton: yes, why, the viewr gets uuid anyways to show

[12:21] Andrew Linden: Because it makes it harder for someone to just use any texture that they happen to see in the world.

[12:21] Kelly Linden: uuids don't have permissions attached, inventory items do.

[12:22] Andrew Linden: So my proposed materials API would actually require the user to *have* the textures that they are using.

[12:22] Qie Niangao: well, sure, but we're worrying about that for NORMAL and SPECULAR maps, of all things??

[12:22] Nalates Urriah: Would storing it int he object let the caching get ahead of the need to have it download at use-time?

[12:22] Andrew Linden: yes

[12:22] Rex Cronon: i wasn't aware that i can use the texture on objecs that don't belong to me

[12:22] Ima Mechanique: which can actually limit your use. you can't distribute a texture in content as no copy, and still be able to show it on the prim can you?

[12:22] Lucia Nightfire: lol, Rex

[12:22] Lucia Nightfire: u so funneh

[12:23] Rex Cronon: :)

[12:23] Whirly Fizzle: Seems kinda strange when this isn't required for diffuse textures

[12:23] Qie Niangao: huh. okay, well, it's not a huge problem. just a little extra lag on sim crossings.

[12:23] Jenna Felton: There are scripts that set the texture saved inside the script as UUID. Those scripts would not work than. I'd suggest than to allows script to use the UUID that the script creator uploaded

[12:23] Jenna Felton: my skin for example was set to my avie by a script with stored skin texture UUID

[12:23] Qie Niangao: oh, right: can't do it remotely. Makes all objects a little nerfed like Mesh.

[12:25] Andrew Linden: I am in favor of making materials controllable by script. But I wonder when we'll be able to get it done.

[12:25] TankMaster Finesmith: what, you dont have loads of free time? :P

[12:25] Lucia Nightfire: heh

[12:25] Loki Eliot: he he

[12:26] Duckie Dickins: that's where having more minions comes into play....

[12:26] Simon Linden: I think the next small step would be laying out a clearer proposed API and the exact behavior

[12:26] Loki Eliot: if we haven't learnt by now to be patient users

[12:26] Andrew Linden: I've got a few LSL calls that I want to add and at the same time I'll try to look at the materials system to see how hard it would be to give script access to it.

[12:27] Simon Linden: Speaking of LSL, an idea came up recently about adding some llGetObjectDetails() parameters to get an object's pathfinding attributes

[12:27] Simon Linden: Does that sound useful to anyone?

[12:27] Lucia Nightfire: why not have a separate function for that

[12:27] Mona Eberhardt: Well, if you can think it, we can (ab/mis)use it. :P

[12:27] Simon Linden: because separate functions are more work

[12:27] rcdsQueChatLog: TankMaster Finesmith, you can read the log here:

http://rcds.nfshost.com/ques_view_chatLog.php?queOwner=llsl:Rex+Cronon&queName=chatLog&pg=1

[12:27] Jenna Felton: that seems usefull :)

[12:28] Loki Eliot: h yes pathfinding

[12:28] Simon Linden: sorry, I made a mistake - not pathfinding, but keyframe animation states

[12:28] Lucia Nightfire: how many llGOD() constants would be devoted?

[12:28] Lucia Nightfire: also, what data

[12:28] Ima Mechanique: generally speaking, being able to get dinformation is always useful ;-)

[12:28] Jenna Felton: true Ima

[12:29] Simon Linden: So it would be possible to get the step number, state (paused, looping, ping-pong, etc) and I'm not sure what else

[12:29] Qie Niangao: oh, hmm... KFM more interesting than pathfinding. Not sure when I'd use the obj details, though.

[12:29] Lucia Nightfire: I still say that would be more attractive in a separate function format

[12:29] Simon Linden: it would be most useful to see if you've reached a waypoint or the end, I think

[12:29] Lucia Nightfire: not multiple llGOD() devoted constants, lol

[12:29] Loki Eliot: i dont understand

[12:29] Nalates Urriah: Simon, I think I could build more AI into a script with those events... but, I haven't used keyframes much.

[12:30] Jenna Felton: i became desperate trying to make a particle effect that someone else made. I failed on it. Would love to have a function that delivers tehe particle parameters from a prim.

[12:30] Rex Cronon: if u get kmd data would be useful to know how many steps there r

[12:30] Rex Cronon: or starting point

[12:30] Kennylex Luckless: I has to go, try to behave good now Andrew, see ya all

[12:30] Rex Cronon: kmf*

[12:30] Whirly Fizzle: Jenna I think thats sitting in STORM with a patch, hang on....

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

[12:30] Rex Cronon: tc

[12:31] Simon Linden: That seems like data best extracted in your viewer

[12:31] Nalates Urriah: bye Rex

[12:31] Ima Mechanique: Speaking of more information... I'd like an giveInventory type function that returns a transaction ID like TransferDollars does

[12:31] Whirly Fizzle: Jenna https://jira.secondlife.com/browse/STORM-1972

[12:31] JIRA-helper: [#STORM-1972] Particle debug display went missing from menu - Second Life Bug Tracker

[12:31] Nalates Urriah: ...er Kenny

[12:32] Loki Eliot: is there a list of topics being discussed or are we just randomly talking about stuffs?

[12:32] Jenna Felton: thank you Whirly

[12:32] Rex Cronon: open table loki

[12:32] Andrew Linden: We're just randomly talking about stuffs.

[12:32] Simon Linden: We're random, Loki

[12:32] Loki Eliot: oh ok

[12:32] Ima Mechanique: random topics loki ;-)

[12:32] Simon Linden: We also often say the same thing

[12:33] Ima Mechanique: keyboard lag ;-)

[12:33] Loki Eliot: hehe well can i put forward an idea i had about animating mesh

[12:33] Ima Mechanique: i.e. how long it takes me to type it since I last looked at the screen

[12:33] Jenna Felton: my favorite, a mesh with sceleton

[12:33] Loki Eliot: no actually not skeleton

[12:33] Jenna Felton: ah ok

[12:33] Simon Linden: plus the tenancy to press return before reading chat :)

[12:34] Andrew Linden: Kelly, did you implement llTransferDollars?

[12:34] Ima Mechanique: yu

[12:34] Ima Mechanique: p

[12:34] Loki Eliot: Skeletons for mesh objects would be great but i doubt LL have time and resources to do that anytime soon

[12:34] Simon Linden: yeah, that would be a pretty big project

[12:34] Kelly Linden: Andrew: I did.

[12:34] Jenna Felton: UUID flipping for mesh was a bad bad idea, And banned by LL :)

[12:35] Loki Eliot: My own problems are with alpha flipping mesh, which i was told yesterday has to recieve a message everytime the alpha is turned visible and invisible

[12:35] Andrew Linden: How hard would it be to do a similar thing for llGiveInventory()?

[12:35] Loki Eliot: its refevered to in the SL wiki as "Method: Alpha Animation"

[12:36] Andrew Linden: I guess we'd need a new function name... llGiveInventory() is already taken.

[12:36] Kelly Linden: Andrew maybe not too hard. When giving to agents we have similar piping under the hood for giving inventory. That said, llTransferLindenDollars was harder to implement than I expected

[12:36] Ima Mechanique: llTransferInventory(0 llTransferInventoryFolder to be in line with TransferDollars

[12:36] Loki Eliot: i was wondering since mesh only is allowed 8 sides and that the method Alpha Flipping is generally used for looping animations, why cant it be like llSetTextureAnim

[12:36] Andrew Linden: could the transaction_result() event be overridden for llTransferInventory()?

[12:36] Lucia Nightfire: llInventoryTransactionUUIDLongFunctionNameIsLong()

[12:37] Kelly Linden: Transfering folders or multiple objects would make it much, much more difficult.

[12:37] Andrew Linden: that is... pipe the transactions through the same event

[12:37] Jenna Felton: And i'd love to have a variant of llGiveInventoryList() that is able to give a complete folder structure, like possible by receiving from residents and marketplace

[12:37] Kelly Linden: Andrew: I think it could.

[12:37] Loki Eliot: the objectr if a looped animation should not need to recieve a message about its state

[12:37] Ima Mechanique: Kelly isn't multiple items treated as a single transaction?

[12:38] Kelly Linden: The underlying systems for giving a single inventory item and multiple inventory items are significantly different.

[12:38] Ima Mechanique: if not, then just do a single item version. people know how to box stuff ;-)

[12:39] Kelly Linden: Andrew mentioned the mistake regarding LSL and texture IDs, but how we handle boxing and boxed things is higher on my list of 'mistakes' in sl. Hate boxes.

[12:39] Ima Mechanique: lol

[12:40] Ima Mechanique: I still miss seeing newbs wearing them ;-)

[12:40] Duckie Dickins: on their heads

[12:41] Ima Mechanique: well, I ask about TransferInventory as it doesn't seem likely we'll ever get access to the marketplace system by via LSL

[12:41] Ima Mechanique: but if you could do that instead, don't mind me ;-)

[12:41] Lucia Nightfire: heh, the ANS doesn't even have teh option to email an in-world server upon sale

[12:41] Jenna Felton: Would be a possibility to zip a folder inside inventory and transform it into a single item that can be given and unzipped into a folder, easier to implement? Than this would make the inventory smaller because you could zip the most unused folders into single archives. and the object could give that zipped archive instead of a folder, plus you could unbox stuff withougt needs of rezzing it

[12:42] Kelly Linden: that would probably be harder

[12:42] Jenna Felton: ok

[12:42] Nalates Urriah: We have colesed objects, might something like that work?

[12:43] Andrew Linden: Yeah. The folder organization already sorta encapsulates the notion of "bundled"... sorta.

[12:43] Nalates Urriah: coalesced^

[12:43] Andrew Linden: A zipped item in inventory would require a new inventory type.

[12:43] Kelly Linden: I kind of like the idea of a 'folder' or 'collection' asset but it would be decidedly non trivial to implement.

[12:44] Jenna Felton: yes, it needs a new inventoy type. because you can not rezz a zipped folder of clothes on ground

[12:44] Rex Cronon: u would need lsl functions that can search/create/edit forlders inside objects...

[12:44] Jenna Felton: but a collection of loose boxes you can

[12:45] Andrew Linden: Oh right I forgot. Object contents can't have folders.

[12:45] Ima Mechanique: welll, we call them boxes

[12:46] Jenna Felton: i must not be able to look into a zipped folder, until i unzip it. So it can behave like a simple box. but not rezzable on ground

[12:47] Whirly Fizzle: lol Id forget what was in all mine :D

[12:47] Ima Mechanique: I'm assuming a special folder in inventory couldn't hold collection folders that LSL could access? Mainly assuming that because MP didn't do it

[12:48] Lucia Nightfire: anyone looking into fixing the issue with people bombing regions? https://jira.secondlife.com/browse/SEC-1352 Starting to see and hear about several copycat type devices now too.

[12:48] Simon Linden: yes Lucy

[12:48] Jenna Felton: Ima, a direct delivery from owner's inventory by inworld vendors. that is a great idea

[12:48] Lucia Nightfire: I take it its not an easy fix, ya?

[12:49] Simon Linden: It rarely is :)

[12:49] Simon Linden: .... especially without breaking something else

[12:49] Rex Cronon: it would be a bad idea to wait until it spreads grid-wide to start fixing the bombing:(

[12:50] Lucia Nightfire: I think its sort of headed that way now, lol.

[12:50] Lucia Nightfire: its only a matter fo time, like most things

[12:50] Jenna Felton: Can one stop objects from rezzing stuff remotelly? I remember a fire that camoe out off contro, and spread over our sim and we had a bad time deleting it.

[12:51] Jenna Felton: Or return an object not being in the sim

[12:51] Ima Mechanique: Is it an Australian sim Jenna?

[12:51] Jenna Felton: "camoe out off contro," -> "came out of control"

[12:52] Jenna Felton: no, it was more than year ago.

[12:52] Jenna Felton: It was Endora

[12:52] Jenna Felton: we played a fire brigade and the fire was too much for us

[12:53] Rex Cronon: u run out of water?

[12:53] Whirly Fizzle: Is there any news yet about when viewer-interesting will be going to RC or a project viewer?

[12:53] Andrew Linden: You mean: an API for controlling your parcel settings/capabilities without loggin in?

[12:53] Andrew Linden: or region settings

[12:53] Jenna Felton: was interesting experiende. The fire was rezzed by some objects and we had to stop it by some toys

[12:54] Qie Niangao: would be *great* to have script control of parcel settings like that.

[12:54] Jenna Felton: yes, you go to another sim, and operate from there

[12:54] Jenna Felton: without lag or stress

[12:54] Rex Cronon: if there were lsl functions to do that, than u could do it from outside sl...

[12:55] Ima Mechanique: hehe sim remote control panel, like web servers

[12:55] Lucia Nightfire: you can do it with a bot too

[12:55] Jenna Felton: if we could stop rezzer remotely than we could find a plan what to do next and return to the sim and delete all the rezzed fires

[12:55] Andrew Linden: it would be neat if we could give parcels a RESTful API that could be controlled by authenticated https requests

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

[12:56] Ima Mechanique: yeah, bypassing the avatar and LSL levels would remove a lot of the lag and make it considerably easier to battle griefing

[12:56] Jenna Felton: probably that griefers would be fought than too

[12:56] Jenna Felton: yes

[12:56] Lucia Nightfire: stopping a rezzing remotely is one thing, returning the rezzer is another

[12:57] Lucia Nightfire: limiting the number of prims a guest can use is another yet, wink

[12:57] Ima Mechanique: true, but having access to remote tools to identify the object would be a good start

[12:57] Lucia Nightfire: everything mentioned I've filed a feature request on

[12:57] Jenna Felton: yes

[12:57] Jenna Felton: thanks Lucy

[12:58] Rex Cronon: well. a bobm needs just a few prims in order to stop all rezzing, and all scripts from running

[12:58] Rex Cronon: a bomb*

[12:58] Loki Eliot: is there a jira about this bomb issue?

[12:58] Jenna Felton: Can a sim recognize when such a bomb is on it?

[12:58] Lucia Nightfire: I just posted the SEC

[12:58] Andrew Linden: yes, Lucia mentioned SEC-1352

[12:58] Qie Niangao: well, careful. If scripts won't run, there's no guarantee the sim can do anything to save itself either.

[12:59] Loki Eliot: aww dont have perms to see it

[12:59] Lucia Nightfire: my security system in my sandboxes have detected it attempted to be used before

[12:59] Loki Eliot: how very helpful that turned out to be

[12:59] Rex Cronon: the scripts that were there before the bomb can still run

[12:59] Jenna Felton: i guess a sim has a wathcdog thread that gets notice the sim is not working properly

[12:59] Lucia Nightfire: yes, sadly, the bomb is effective by script alone

[13:00] Lucia Nightfire: no rezzing necessary, although if rezzing is possible the effects are sustainde indef

[13:00] Lucia Nightfire: and now I'm seeing throwaway accts using copycat devices

[13:00] Lucia Nightfire: so I have greater concerns, lol

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

[13:01] Ima Mechanique: the hour went fast this week!

[13:01] TankMaster Finesmith: have a good rest of the week, simon, andrew, and kelly

[13:01] Andrew Linden: Whirly you asked about the project interesting viewer -- it is currently scheduled for RC before the end of this month, but it has been delayed before so I can't put a lot of confidence into that estimate.

[13:01] Mona Eberhardt: Thanks Lindens!

[13:01] Simon Linden: Thanks everyone for coming today

[13:01] Qie Niangao: Thanks Lindens, all... have fun.

[13:01] Loki Eliot: ill try again next week

[13:01] Whirly Fizzle: Thanks Andrew

[13:02] Ima Mechanique: thanks guys

[13:02] Nalates Urriah: Thx Lindens

[13:02] Whirly Fizzle: Thanks Lindens :)

[13:02] Yuzuru Jewell: Thank you, Lindens.

[13:02] Jenna Felton: thanks for the meeting and have good week Lindens and all

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

[13:02] Andrew Linden: There's at least one crash bug, some performance work to do, and one problem with obejcts not showing up right on teleport -- in the Project Interesting viewer.

[13:03] Andrew Linden: The objects not showing up bug is a regression and will probably be easy to fix -- we've had a few bugs that cause that to happen so we know where to look.

[13:03] Whirly Fizzle: Ahhh I saw some fixed pushed for the objects not rendering after TP. Was hoping that was fixed heh

[13:03] Andrew Linden: It broke again in the latest build.

[13:04] Andrew Linden: Also, we've asked Torley to help us make a video showing some comparisons with how the scene used to load to how it loads now.

[13:04] Whirly Fizzle: I kept my object cache file for my region from a session where my house didn't render. If I use that cache file on a build with the bug fixed, should my house render fully? Atm if I replace that cache file pre login my house will never render.

[13:05] Andrew Linden: I took some of the initial video footage to see what the compirsons would likely look like -- the improvemen was pretty impressive.

[13:05] Andrew Linden: However, most of the work there has already shipped -- we're all reaping the benefits from the server work already.

[13:06] Andrew Linden: Whirly, that is right. That was the repo we used to track down the bad load.

[13:06] Andrew Linden: You save the objects_XXX_YYY.slc file for the relevant region when it happens

[13:06] Whirly Fizzle: Ya

[13:06] Andrew Linden: and then copy it back into place before you login

[13:07] Andrew Linden: Whirly one interesting thing you might also confirm...

[13:07] Andrew Linden: the project interesting viewer will save a larger cache file for the region

[13:08] Andrew Linden: the way to compare is this...

[13:08] Andrew Linden: login to a region with neighbors

[13:08] Andrew Linden: walk out of the region until your viewer no longer has a connection to it

[13:08] Andrew Linden: then logout and look at the size of the objectcache file

[13:09] Andrew Linden: the viewer-release file will be much smaller than the file for project interesting

[13:09] Whirly Fizzle: Okay

[13:09] Whirly Fizzle: You need to be totally disconnected from the region even as a child?

[13:09] Andrew Linden: the reason is that the server interestlist code actually behaves differently for the two cases

[13:09] Andrew Linden: yes, you wait until your child agent vanishes from that region

[13:09] Whirly Fizzle: Okay

[13:10] Andrew Linden: the details is that the server will send a KillObject message for objects that go out of view -- for viewer-release

[13:10] Andrew Linden: that is, "The object is out of view" and "The object is deleted" are the same message in the old protocol.

[13:11] Andrew Linden: But in viewer-interesting the server will not send KillObject for *cacheable* objects that go out of view.

[13:11] Whirly Fizzle: ahhh

[13:11] Andrew Linden: And the definition of "cacheable" has changed recently... it means any object that hasn't changed appearance or transform in the last two minutes.

[13:12] Ima Mechanique: sweet, so if you turn around and walk back, because you forgot your key for example, it is all still cached?

[13:12] Andrew Linden: The way the server distinguishes a viewer-interesting connection from a viewer-release is some flags set in the RegionHandshakeResponse message, or something like that -- I forget the exact name of the object.

[13:13] Andrew Linden: Yes Ima, for viewer-interesting the cache will be much larger -- the entire region basically.

[13:13] Andrew Linden: Even stuff that was never in view (skyboxen for example).

[13:13] Ima Mechanique: excellent

[13:13] Andrew Linden: The server now tries hard to send what is visible first (in view frustum) and then eventually gets around to sending non-visible stuff

[13:14] Andrew Linden: and continues to send it until done.

[13:14] Andrew Linden: But in order to make this work the viewer has to be a bit smarter about what is visible and what is not

[13:14] Andrew Linden: it used to rely on the server to tell it what was not in view (via a KillObject message)

[13:15] Rex Cronon: the interest list is made based on draw distance. right?

[13:15] Andrew Linden: Not just draw distance, it also uses the camera frustum.

[13:16] Andrew Linden: The visibility logic for objects now pivots on the camera position (several months ago it was still sometimes using the avatar position for some of the logic).

[13:16] Andrew Linden: But that work has been out for months.

[13:17] Inara Pey: "cacheable" is objects which have not changed outward appearance or transformed in the last two minutes? I was under the impression from Richard it was a minute?

[13:17] Annoying User: Andrew

[13:17] Annoying User: !@#$%^&*()

[13:17] [Second Life: Entering god mode, level 200]

[13:17] rcdsQueChatLog: Rex Cronon, you can read the log here:

http://rcds.nfshost.com/ques_view_chatLog.php?queOwner=llsl:Rex+Cronon&queName=chatLog&pg=1

[13:17] Ima Mechanique: looking forward to seeing the interest-viewer

[13:17] Ima Mechanique: hmm, someone just asked for a banning lol

[13:17] Andrew Linden: Heh, I get to use the eject and ban

[13:17] Rex Cronon: wow

[13:17] Andrew Linden: although I think it just worked for this parcel

[13:18] Inara Pey: lol!

[13:18] Ima Mechanique: however, I don't see any male chicken about

[13:18] Mona Eberhardt: Maybe also a permaban from SL.

[13:18] Ima Mechanique: hmm, good job Baker wasn't here

[13:18] Andrew Linden: ok gotta go

[13:18] Andrew Linden: Thanks for coming

[13:18] Rex Cronon: tc andrew

[13:18] Ima Mechanique: bye Andrew

[13:18] Inara Pey: Andrew, quick Q

[13:18] Nalates Urriah: thx Andrew

[13:18] Yuzuru Jewell: Thank you, Andrew.

[13:18] Inara Pey: "cacheable" is objects which have not changed outward appearance or transformed in the last two minutes? I was under the impression from Richard it was a minute?

[13:18] Nalates Urriah: bye all

[13:19] Rex Cronon: u guys do have permanent ban hammer

[13:19] Andrew Linden: Inara,I made it two minutes because temp-on-rez objects are returned after 1 minute with about 10 sec of slop

[13:19] Inara Pey: Cool

[13:19] Inara Pey: That answers the other question

[13:19] Andrew Linden: that way I didn't have to add any special logic for checking for temp-on-rez objects

[13:20] Andrew Linden: but most objects don't change very often

[13:20] Andrew Linden: and the old definition of "cacheable" was more restrictive -- some objects were not cacheable if they had certain script calls inside

[13:20] Andrew Linden: even if they never changed appearance

[13:20] Inara Pey nods

[13:20] Mona Eberhardt: Andrew, did you see what kind of blog this person that came here has?

[13:20] Ima Mechanique: bye all

[13:21] Inara Pey: Great info, thank you, Andrew

[13:21] Rex Cronon: tc

[13:21] Andrew Linden: No Mona

[13:21] Mona Eberhardt: He's been posting RL information and pictures of other SL users.

[13:21] Inara Pey: Ciao, Ima

[13:21] Mona Eberhardt: See you, Ima.

[13:21] Mona Eberhardt: And possibly hacking accounts.

[13:21] Mona Eberhardt: it's at [edited]

[13:21] Mona Eberhardt: I think your abuse handling team would love to go after him.

[13:22] Andrew Linden: interesting Mona, I'll ask them to take a look

[13:22] Mona Eberhardt: Good call, Andrew.



Simulator_User_Group

Prev 2013.10.15 Next 2013.10.29