Simulator User Group/Transcripts/2012.04.17

From Second Life Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Simulator_User_Group

Prev 2012.04.13 Next 2012.04.20

List of Speakers

Chieron Tenk Davido Chrome Flip Idlemind
Kaluura Boa Kelly Linden Kitto Flora
Martinrj Fayray Motor Loon Nalates Urriah
Qie Niangao Rex Cronon Simon Linden
Slee Mayo Tankmaster Finesmith

Transcript

[12:03] Simon Linden: So news ...

[12:03] Simon Linden: There wasn't any new version of the server rolled to the main channel this morning, as the whole grid was on the same code

[12:04] Simon Linden: Tomorrow the RCs will be updated with two new versions

[12:04] Tankmaster Finesmith: tomorrow the mayhem begins

[12:04] Tankmaster Finesmith: ?

[12:05] Simon Linden: Right!

[12:05] Simon Linden: There is a post at http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2012-04-16/td-p/1489453

[12:05] Simon Linden: but it's skimpy on details

[12:05] Simon Linden: I think 2 channels have internal changes around the inventory system, so keep your fingers crossed there

[12:06] Tankmaster Finesmith doesnt see any details

[12:06] Simon Linden: Right, really skimpy on the details

[12:06] Tankmaster Finesmith: heh :D

[12:06] Simon Linden: The other channel will have bug fixes

[12:06] Kelly Linden: And llGetAgentList

[12:07] Flip Idlemind: woooooo!

[12:07] Simon Linden: Also the new llGetAgentList, right

[12:07] Kitto Flora: Any fix for the Physical Memory problem?

[12:07] Motor Loon: llGetAgentList... yeah... yeah... woohoo

[12:07] Simon Linden: There are a few tweaks in llGetLinkPrimitiveParams() and related functions -- a new PRIM_SLICE option can be used

[12:08] Motor Loon: oh.. could I suggest an option to change texture settings via SetlinkprimitiveParams etc.. without the need to specify a texture UUID ?

[12:09] Simon Linden: Also llHTTPRequest() can use HTTP_BODY_MAXLENGTH to get larger response bodies if you're sure you've got the script memory space

[12:09] Simon Linden: Let's talk about that in a bit, Motor

[12:09] Motor Loon: kk

[12:09] Kaluura Boa: Is there any reliable function which tells us the available free memory?

[12:09] Simon Linden: Andrew says he's deep in a blocking bug for pathfinding, which needs to get fixed for the next update

[12:10] Simon Linden: That's it for my news ... Kelly, do you have anything else?

[12:10] Kelly Linden: I don't have any other news.

[12:11] Nalates Urriah: Did the Flight Limit change gridwide?

[12:11] Davido Chrome: I am having trouble with the Beta grid. Place won't let me rez certain things from inventory after I tried to update it via changing my password. And I am not recieving the group invites Gez keeps sending me.

[12:11] Tankmaster Finesmith: isnt that in the RC tomorrow? (the flight hight change)

[12:12] Slee Mayo: kelly, on that chat type exploit i submitted, is there something we can do on our end to block it before the fix?

[12:12] Simon Linden: oh right, the flight limit ... we're going to try to raise that on the RC channels tomorrow again

[12:12] Kelly Linden: Slee: I don't really know Slee, sorry.

[12:13] Simon Linden: It won't be _exactly_ when the new code is rolled out, but a little later. We're using a new technique to change settings around the grid

[12:13] Davido Chrome: What about the sound bug?

[12:13] Nalates Urriah: Alve, Nyx was going to pass along our request for a look at SVC-7727

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

[#SVC-7727] Aditi grid problem. After changing my password to cause my inventory on Aditi to update, my inventory no longer saves changes made to it from session to session.

[12:13] Simon Linden: That didn't work last week due to a minor oversight

[12:14] Davido Chrome: Nal, that doesn't describe my current problem. Is it the same thing?

[12:15] Flip Idlemind: I'm having Aditi problems too. On an alt I changed my password, and almost everything changed, but a few of my attachments fail to rez. And my "last location is unavailable" every time I log in ?.(?)

[12:15] Davido Chrome: Same here.

[12:15] Nalates Urriah: That prob is in the list of stuff in comments.

[12:15] Davido Chrome: Ok.

[12:15] Nalates Urriah: So, is FLIP's prob.

[12:15] Motor Loon: Flip broke it!

[12:16] Davido Chrome: It's weird, I tried to change my password and my belt wouldn't rez. I did it again, and the my necklace wouldn't rez. It's being weird.

[12:16] Davido Chrome: But the other one did in both instances.

[12:17] Davido Chrome: I have the very problem Flip describes.

[12:17] Flip Idlemind: My attachment that won't rez is a belt too ?.(?)

[12:17] Rex Cronon: u guys don't know? each time u change your pass it takes a pice of clothing away;)

[12:17] Flip Idlemind: Maybe the pelvis attach point isn't liked by Aditi

[12:17] Simon Linden: I'm not sure what's going on there ... I think there was some work yesterday on Aditi, but I just heard the chatter about it. So you're still having problems today?

[12:17] Rex Cronon: piece*

[12:17] Davido Chrome: Yeah, but now the belt works. And the necklace don't.

[12:18] Qie Niangao: that's what you get for wearing your necktie on your pelvis, duh.

[12:18] Davido Chrome: I have tried Updating my Billing details and my password. So I thought I would wait 24 hours till next login there.

[12:18] Qie Niangao: necklace, even. :p

[12:18] Flip Idlemind: I haven't tried changing my password again since the first time, so maybe I should

[12:18] Nalates Urriah: In ADITI I can't change appearance, it reverts back to appearance I had when I changed password. All the attachments reattach. Can't save to inventory, can't rez from invenotry... its a pain.

[12:18] Davido Chrome: FLIP, I tried it two times. This will be the third.

[12:18] Simon Linden: ok, so the table is open ... what was that option you were thinking about, Motor?

[12:19] Tankmaster Finesmith: oh, fyi, I remember earlier there was talk that you can get around ban lines after they get raised to 5k, which is false with the LL v2/3 viewer (and other viewers based on it). There is a viewer side limit to 4096 which will knock the avatar back to that value if they try to go higher.

[12:19] Nalates Urriah: I plan to change password and wait 48 hours. I usually change and go in shortly after...

[12:20] Davido Chrome: When we are done with Motors, I want to know if the Sound bug where sounds never play on the first try is among the bug fixes. That it makes gestures kinda not work is nice. But there are other stuff...

[12:20] Simon Linden: I don't know why such a long wait would make a different, fwiw. I think the password change triggers the import right away

[12:20] Simon Linden: Alve - no, it is not in the fixes

[12:21] Tankmaster Finesmith: thats a viewer issue anyway

[12:21] Flip Idlemind: I think Firestorm fixed the sounds-not-playing problem

[12:21] Nalates Urriah: Simon, its the only thing I haven't tried yet... :(

[12:21] Davido Chrome: Not on 4.0.1.27000 it didn't...

[12:21] Tankmaster Finesmith: i thing so to, flip, but i dont really remember

[12:21] Tankmaster Finesmith: no, after the release

[12:21] Davido Chrome: There is a new one out?!

[12:22] Flip Idlemind: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/fd2494436720

[12:22] Motor Loon: Oh yes... I was hoping for a way to change texture settings (like repeats and offset) in a linkset with the llSetLinkPrimitiveParamsFast function, but it's to be in a no-mod object so I won't be able to pull the texture key from it, nor have it in the objects inventory... I belive there's no way to execute these settings via the fast command without knowing/specifiying a texture UUID also right?

[12:23] Motor Loon: (I know you can use the regular commands, like llOffsetTexture and such, but they come with a delay)

[12:23] Simon Linden: well, if it's no-mod, it's no-mod. You shouldn't be able to change it

[12:23] Motor Loon: well, I can change it since it'll be my creation... problem is once I sell it - it'll be no-mod for the next user... causing my script to misfunction suddenly

[12:24] Motor Loon: then the script can nolonger "read" the current texture UUID from it's links

[12:24] Davido Chrome: can't you just save them in Strings?

[12:25] Simon Linden: hmm, that sounds like the basic problem. If it's your script, then I'd _think_ it should be able to read the ID

[12:25] Motor Loon: Yes, that was my workaround... but it's a waste of memory in my world

[12:25] Simon Linden: can you make a simple example and throw it in a jira?

[12:25] Motor Loon: well, I guess its not really a bug... I'm kinda requesting a new feature °?°

[12:26] Kaluura Boa: There is already a jira about this... It's called "Unbundle the prim params" or something...

[12:26] Qie Niangao: right

[12:26] Motor Loon: I assume it's on purpose that scripts cannot read UUIDs from links if the object is no-mod

[12:26] Flip Idlemind: It is a bug if it causes llSetPrimitiveParams to not be usable the way it's meant to be

[12:26] Motor Loon: got a link Kaluura... I'd sure give it a vote

[12:27] Qie Niangao: https://jira.secondlife.com/browse/SCR-4 I think

[12:27] JIRA-helper: [#SCR-4] Unbundle PRIM_* rules for llSetPrimitiveParams and similar functions to allow for individual parameter settings for all possible parameters.

[12:27] Simon Linden: It may be blindly blocking everything, but your example sounds like something it should be able to do

[12:27] Motor Loon: scr-4 damn... thats sounds like an old one

[12:27] Rex Cronon: is kind of weird. if an script is in an object it should be able to read/write any of its attributes

[12:27] Flip Idlemind: It sounds like an old one but the SCR category is relatively new

[12:27] Motor Loon: ok

[12:28] Motor Loon: yeah it really came as a surprice to me that the script couldn't ... and took a while to pinpoint the problem with my products °?°

[12:28] Motor Loon: since everything worked perfectly for myself... until it changed owner

[12:29] Motor Loon: it's ok too... with that limit... I'd just like access to those texture settings without having to specify a UUID for the command

[12:29] Rex Cronon: why can't it read/write textures? it can certainly change shape and size

[12:29] Davido Chrome: You should update the wiki, under Caveats?

[12:29] Simon Linden: Right - it really seems like it should continue working if the script creator matches the object creator, but permissions can be really complex so I might be missing some other case

[12:29] Rex Cronon: if u really want to, u can find the uuid of any texture

[12:29] Qie Niangao: texture perms are hyper-paranoid. watch what happens to a prim when you paint it with a no-transfer texture some time.

[12:30] Motor Loon: yeah... it dont gives errors or anything ... just returns a null-key

[12:30] Motor Loon: well, I dont mind LL being anal about permissions °?°

[12:31] Motor Loon: Infact I'd expect it

[12:31] Kitto Flora: https://jira.secondlife.com/browse/SVC-7749 Is this a HAVOK bug? What's the prognosis?

[12:31] JIRA-helper: [#SVC-7749] Rez of vehicle gets message "Unable to create item '<object name>' that has caused problems on this region. Other vehicles are forced non-phys on enter.

[12:32] Simon Linden: fwiw there's a dialog about llGetTexture() in http://forums-archive.secondlife.com/54/a1/47066/1.html

[12:32] Flip Idlemind: You just need a (fast, easy) way to change other texture params without needing to know the texture UUID (which I assume is what's been suggested)

[12:32] Simon Linden: oh wait, that's ancient

[12:32] Motor Loon: thanks simon

[12:32] Motor Loon: oh yeah... that IS a bit aged

[12:34] Davido Chrome: So basically just a way to change texture parameters to an allready applied texture?

[12:34] Motor Loon: Yep flip

[12:35] Simon Linden: Looking at the code, it's definitely checking for it to be mod/copy/trans, so this sounds like a new exception to that check

[12:35] Motor Loon: I just want be able to set [ vector repeats, vector offsets, float rotation_in_radians ] with PRIM_TEXTURE ..... without having to give a [ string texture ] also

[12:36] Motor Loon: perhaps a good option could be: PRIM_TEXTURE, CURRENT_TEXTURE, etc, etc

[12:36] Kaluura Boa: And there isn't any llSetLinkTextureAnything()... Except llSetLinkTexture()

[12:36] Motor Loon: possible?

[12:37] Davido Chrome: So it's texture animation that doesn't work?

[12:37] Davido Chrome: Wait sec, that would mean my chains don't work either....

[12:37] Motor Loon: Things work fine... aslong as you know the texture UUID

[12:38] Simon Linden: I'd have to dig deeper, Motor. Fiddling with permisisons scares me, I've managed to do work there that's required a rollback in the past, so I go very carefully

[12:38] Motor Loon: but a CURRENT_TEXTURE (just use whatever is already on it or do change anything) seems like a nondangerous thing?

[12:38] Motor Loon: "or dont change anything"

[12:38] Chieron Tenk: but here only the texture properties would be changed, not ne texture itself.

[12:39] Motor Loon: yes

[12:39] Davido Chrome: llSetLinkTextureAnim(20, ANIM_ON | SMOOTH | LOOP, 0, 0, 0, 0, 1, -vel*3);

[12:39] Davido Chrome: Does this problem affect this line:

[12:39] Simon Linden: I think it's more of a permissions question than how it's done with a new constant or slightly more permissive llGetTexture()

[12:39] Davido Chrome: ?

[12:40] Qie Niangao: no, because llSetLinkTextureAnim doesn't specify texture

[12:40] Davido Chrome: Ah. OK, Phew.

[12:40] Motor Loon: or mabye if we gave it this : llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_TEXTURE, ALL_SIDES, "", repeats, offsets, rotation ]);

[12:40] Motor Loon: "" could be = use whats already there

[12:41] Kaluura Boa: No can do... A script would complain that texture "" is missing from inventory.

[12:41] Motor Loon: yes now

[12:41] Chieron Tenk: or add another identifier PRIM_TEXTURE_PROPERTIES

[12:41] Kaluura Boa: Can't change this behavior without breaking things...

[12:41] Motor Loon: Im suggesting a change °?°

[12:41] Chieron Tenk: which would then be just the same, b ut without the UUID

[12:41] Motor Loon: also an option Chieron... but Im guessing LL arent fond of that option

[12:42] Qie Niangao: I think adding new, more specific params, a la SCR-4, is the best approach.

[12:42] Simon Linden: Right, changing existing behavior is always risky. It's much safer to add something new

[12:43] Motor Loon: A "" solution would cause existing content break and would solve the problem in a very simple way

[12:43] Motor Loon: wouldn't

[12:43] Davido Chrome: I am curious why Kaluura thinks it would break things?

[12:43] Motor Loon: I'll rephrase... A "" solution wouldn't cause existing content break and would solve the problem in a very simple way

[12:44] Kaluura Boa: Hmmm... Actually, the "" solution wouldn't break anything... If the texture is missing, nothing change... And if "" doesn't change the texture... It's the same... Without the debug message...

[12:44] Motor Loon: yep

[12:44] Rex Cronon: wouldn't be more easier just to add a check like this: if script is in a nomod object than it can read/write texture?

[12:44] Simon Linden: So if you want to move this forward, please create a SCR jira with a simple example, and maybe add some of these suggested solutions. It will be picked up with our bug triage

[12:44] Motor Loon: can we have it Simon... pretty please with sugar and stuff?

[12:44] Motor Loon: will do

[12:44] Kaluura Boa: ...with the cherry on top! Please...

[12:45] Simon Linden: You should be trying to bribe Kelly for LSL language changes :)

[12:45] Motor Loon: oh the blingmonster eh?

[12:45] Motor Loon: I'll just marry her... him.... err...

[12:45] Davido Chrome: Kelly does remind me of that old HTML blink tag.

[12:46] Simon Linden: ok ... are there any other topics someone would like to bring up?

[12:47] Motor Loon: well, that was all the whining I had today... I'll make the jira and whine about it next time

[12:47] Qie Niangao: Kitto asked about https://jira.secondlife.com/browse/SVC-7749

[12:47] JIRA-helper: [#SVC-7749] Rez of vehicle gets message "Unable to create item '<object name>' that has caused problems on this region. Other vehicles are forced non-phys on enter.

[12:47] Tankmaster Finesmith: the % of logins on a mesh capable viewer is now up to about 86%

[12:48] Motor Loon: ooh

[12:48] Motor Loon: nice

[12:48] Kaluura Boa: I don't know if that's related to the viewer or the servers but I feel that the error messages related to mesh upload need to be improved...

[12:48] Nalates Urriah: Tank, where does that number come from?

[12:48] Kaluura Boa: Especially when the viewer is stuck in calculating the fees and never comes back... from where it goes to ask the fees.

[12:48] Tankmaster Finesmith: the weekly stats TPVs get from LL

[12:48] Nalates Urriah: Thx

[12:49] Simon Linden: There hasn't been any progress on that problem, Kitto. It looks like Maestro was able to reproduce it, or something similar, but nobody has started work on it yet

[12:49] Simon Linden: It definitely seems to be related to the physics performance

[12:50] Motor Loon: It's another... "when pathfinding works" issue °?°

[12:50] Kitto Flora: Simon - is it a HAVOK bug? - i.e. HAVOK would have to fix it?

[12:51] Simon Linden: It may be related to havok - that "unable to create item that has caused problems in the region" is from a system that looks at objects as they are rezzed

[12:52] Simon Linden: If it's rezzed and it caused a huge lag event, it's blocked for a while from rezzing again

[12:52] Motor Loon: That sounds like a good thing

[12:53] Simon Linden: Right ... until you get a false positive. There might be a big delay or lag here, but it may not be that object's fault

[12:53] Kitto Flora: Simon - the real problem is that "Physical Memory" has run out. It looks like thats memory used by Havok, and is limited to 1 Gig. When use is 950Megs + then physical stuff cannot be entere int othe region

[12:53] Simon Linden: That's definitely way too much physics memory

[12:54] Qie Niangao: the bug seems to be an exploit that triggers a huge memory leak in physics... the issue is whether the expoit is inherent to Havok or to the sim's use of Havok

[12:54] Motor Loon: if objectname == "object" { llBlockTheDamnThing(); }

[12:54] Kitto Flora: If there's no fox coming soon could you please Memo GRID MONKEYS about the bug - mentioning that Wengen will need to be restarted often?

[12:54] Kitto Flora: No fix either :)

[12:54] Motor Loon: what the heck are you using 950mb for??

[12:54] Davido Chrome: Do you have one of those damn griefer objects that lower the physics FPS to a crawl hidden in a corner somewhere, maybe?

[12:54] Simon Linden: ok, I'll pass that along

[12:55] Motor Loon: you mean those breedable chickens Davido? °?°

[12:55] Davido Chrome: Could be. XD

[12:55] Kitto Flora: Motor - its a resident griefer who rezzes a griefer object that rapidly eats up all the memory. Nothing "normal' usues that much. Typical max is 30 megs

[12:56] Motor Loon nods

[12:56] Simon Linden: Usually a huge burst of physics memory like that is caused by lots of collisions between complex shapes. Take a bunch of objects, put them all in the same space so they overlap, then turn them physical. There's a geometric explosion of collisions

[12:56] Rex Cronon: one object that eats all the memory?

[12:56] Davido Chrome: I remember some kind of physical object made out of huge tortured toruses that hit Anaconda valley. I think they had a move script in them that made sure they were constantly trying to be in the same place and colliding.

[12:56] Motor Loon: I'd have though there'd be some throttles on that kind of stuff?

[12:57] Simon Linden: You need to make a real special effort to use up that much

[12:57] Kitto Flora: And prior to hitting the ~950Meg limit , physics operation is not much impacted

[12:57] Tankmaster Finesmith: like that :P

[12:57] Motor Loon: tank... you greifer

[12:57] Kitto Flora: That didnt cause a mem leak

[12:57] Tankmaster Finesmith: hehe :D

[12:57] Simon Linden: oh, there definitely are throttles, Motor. We've been working on stuff like that for years

[12:57] Rex Cronon: how many prims does this "magic" memory eating object have?

[12:57] Motor Loon: yeah I thought so

[12:57] Kitto Flora: Phoenix - not like that

[12:58] Davido Chrome: Simon, that griefer object I mentioned did the work it was meant to do without being throttled.

[12:58] Motor Loon: this is almost like being a McDonalds

[12:58] Qie Niangao: except that the food is better here.

[12:58] Simon Linden: yeah, it must be doing something that sneaks by the current limit

[12:58] Davido Chrome: I made 600 prim sea of balls once. Didn't lag the sim too much. But they are more fun IRL.

[12:59] Kitto Flora: Maestro Linden has a copy of the offending Griefer object

[12:59] Kitto Flora: I have never seen it - the offender runs when I show up ;)

[12:59] Davido Chrome: If only MCd didn't makesuch crappy hamburgers....

[12:59] Tankmaster Finesmith: its the cheep cows

[13:00] Motor Loon: well, you ARE very scary looking Kitto

[13:00] Davido Chrome: Sheep cows? o.O

[13:00] Chieron Tenk: I've been in Wengen 2 weeks ago and was stunned by the lag via physics memory usage, couldnt see the object either, but this explains that at least

[13:00] Rex Cronon: it can't be just one objects

[13:00] Rex Cronon: object*

[13:00] Kitto Flora: Chieron - theobject is long gone. Only the leaked memory remains :)

[13:01] Motor Loon: where can you see physics memory usage?

[13:01] Davido Chrome: Oh well. Thank you for today. I need to go hang my laundry.

[13:01] Rex Cronon: it might be a replicator

[13:01] Chieron Tenk: ah. still was defacto physicless.

[13:01] Martinrj Fayray: ctrl+shift+1

[13:02] Simon Linden: Thanks everyone for coming today and the discussion

[13:02] Davido Chrome: Thank you!



Simulator_User_Group

Prev 2012.04.13 Next 2012.04.20