Simulator User Group/Transcripts/2011.03.15

From Second Life Wiki
Jump to navigation Jump to search

Simulator_User_Group

Prev 2011.03.11 Next 2011.03.18

List of Speakers

Andrew Linden Ardy Lay Chalice Yao
Cummere Mayo Draconis Neurocam Fancy Greeter
Flip Idlemind Hope Dreier Jessica Lyon
Joke Bubble Joshua Linden Joshy Aulder
Kelly Linden Moy Loon Omega Flux
Oskar Linden Patnad Babii Pauline Darkfury
Qie Niangao Rex Cronon Sebastean Steamweaver
SilverbackMale Looming Simon Linden Stickman
Stickman Ingmann TankMaster Teichmann TheBlack Box
Tomkin Euler Zwagoth Klaar

Transcript

[12:00] Stickman Ingmann: Hi Andrew, Joshua!

[12:00] Pauline Darkfury: Afternoon, Andrew :)

[12:00] Andrew Linden: Hello

[12:00] Moy Loon: Hey!

[12:00] TheBlack Box: 'ello

[12:01] Joshy Aulder: Hai Andrew and Joshua

[12:01] Joshua Linden waves

[12:01] Ardy Lay: Hello

[12:01] Andrew Linden: Alright, let's get started...

[12:01] Fancy Greeter: Simon Linden has arrived!

[12:01] Sebastean Steamweaver: Hey Simon :)

[12:01] Sebastean Steamweaver: And Joshua, who I missed.

[12:02] Simon Linden: Hello everyone :)

[12:02] Andrew Linden: Today the "faster UDP" project was promoted to the main channel.

[12:02] Rex Cronon: hi simon, andrew

[12:02] Rex Cronon: hi everybody

[12:02] Flip Idlemind: Luckily my Fancy Greeter sees all :O

[12:02] Moy Loon: Wow!

[12:02] Andrew Linden: which has Simon's UDP message optimization in it, and a few small bug fixes

[12:03] Fancy Greeter: Oskar Linden has arrived!

[12:03] Andrew Linden: We don't have a project to replace the LeTigre RC channel

[12:03] Andrew Linden: so we'll probably put the main channel there, or one of the other RC's. I don't think we've decided yet.

[12:03] Flip Idlemind: You're out of projects? :O

[12:03] Oskar Linden: hah

[12:03] Oskar Linden: as if

[12:03] Moy Loon: Oh no, I thought Oskar was segragated to his own grid

[12:04] Stickman Ingmann: He's escaped!

[12:04] Jessica Lyon: lol

[12:04] Andrew Linden: I've been working on some stuff that didn't get done in time for this week's RC

[12:04] Oskar Linden: I am the grid

[12:04] Pauline Darkfury: lol

[12:04] Sebastean Steamweaver: They've been having trouble keeping him contained recently.

[12:04] Moy Loon: Golly!

[12:04] Ardy Lay: Hasn't Oskar taken over a "release manager"?

[12:04] Sebastean Steamweaver: He's the MCP of SL.

[12:04] Ardy Lay: He released himself from beta?

[12:04] Andrew Linden: I think I've found some potential (rare or occasional) memory leaks and have a fix that should be bundled up for testing soon.

[12:04] Oskar Linden: :-D

[12:05] Stickman Ingmann: Most Coy Person?

[12:05] Fellony Lock Pick Hud: Reading pickconfig note card....

[12:05] Fellony Lock Pick Hud: Reading pickconfig note card....

[12:05] Draconis Neurocam: nice andewq

[12:05] Sebastean Steamweaver: TRON reference

[12:05] TheBlack Box: really? a gattling-gun at the discussion-table ? have we already complained too much ? :)

[12:05] Oskar Linden: :-)

[12:06] Chalice Yao: Oskar is ready to make demands.

[12:06] Andrew Linden: I found a fix for SVC-6544 at the end of last Friday

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

[#SVC-6544] In "About Land" dialog, "Most Recent" objects show a date of 1970/01/01 00:00 UTC

[12:06] Oskar Linden: nice

[12:06] TheBlack Box: Osker just came from bug-hunting ;)

[12:06] Oskar Linden: epoch win andrew

[12:06] Joshua Linden hates on oskar

[12:06] Pauline Darkfury: Cool. Have observed that the (time_t)0 objects seem to be immune to auto-return, not sure if that had already been noted

[12:06] Andrew Linden: and will soon be starting SVC-2283

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

[#SVC-2283] Sending postcards severely slows simulator performance

[12:06] Oskar Linden less than three's josh

[12:07] Andrew Linden: really Pauline? hrm... I'll make a note of that and try to look into it.

[12:07] Flip Idlemind: You'd think they'd be returned unless auto return was set to something less than 40 years

[12:07] Oskar Linden: sorry about your regions this morning Pauline

[12:07] Oskar Linden: I blame Comsys

[12:07] Pauline Darkfury: I've seen it with ramdom non-group stuff on BlueSteel

[12:08] Fancy Greeter: Kelly Linden has arrived!

[12:08] Sebastean Steamweaver: Hey Kelly

[12:08] Pauline Darkfury: Thanks, Oskar, was just a bit surprising when the rug got yanked bankwards mid-edit ;)

[12:08] Tomkin Euler: /ao off

[12:08] Andrew Linden: I think that is all the news that I've got. Go ahead Simon, Kelly, or Oskar.

[12:08] Flip Idlemind: "Arrived" is misleading..it means they arrived in this sim, but they could be way over there

[12:08] Simon Linden: I don't have anything new to add

[12:09] Andrew Linden: ok then we can open the table to general discussion

[12:09] Chalice Yao: Heya Kelly.

[12:09] Hope Dreier: SVC-5927 ?

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

[#SVC-5927] Temp on Rezzed objects get queued

[12:10] Andrew Linden: I'll hunt for my notes from last Friday, but I think I've forgotten to follow up on whatever it was I was supposed to look into.

[12:10] Flip Idlemind: Make a note to not lose your notes

[12:10] Stickman Ingmann: You probably did, yes.

[12:10] Andrew Linden: Oh right, I was supposed to talk to Richard about animations (for Stickman).

[12:10] Sebastean Steamweaver: Animations were one - I was also going to ask about llSetObjectScale

[12:10] Andrew Linden makes another note of it (sigh)

[12:10] Pauline Darkfury: Physics Other, you said you'd probably got that one identified, not sure if we got a timescale for deployment of the fix

[12:11] Andrew Linden: Yes that is fixed Pauline -- in the next "maint-server"

[12:11] Jessica Lyon: Just an update, SVC-6766 seems to have calmed down a lot.. apparently all by itself. Any updates on this on your end?

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

[#SVC-6766] Since Feb 8th Server Rollout to main simulator isn't reliably sending inventory item UUID for attachments

[12:11] Andrew Linden: I just merged that fix into kelly's sandbox repo which is what will be the next maint-server project

[12:11] Andrew Linden: repo = repository

[12:11] Flip Idlemind: Speaking of things from the statistics bar, anyone know off the top of their head what might cause "Pump IO" to randomly jump to like 100ms?

[12:12] Pauline Darkfury: cool, so RC next week, maybe?

[12:12] Moy Loon: SLVoice

[12:12] Andrew Linden: Flip, maybe SVC-2283? Just guessing.

[12:12] Andrew Linden: TP arrival?

[12:12] Simon Linden: FLIP - that can be a lot of things

[12:13] Sebastean Steamweaver: It can even be people opening the map.

[12:13] Moy Loon: After a day or so, of being logged in, my pump IO goes way up, restarting voice tends to fix it

[12:13] Simon Linden: Pump IO will include things that happen when we get some data or a message about something

[12:13] Andrew Linden: Jessica, no we don't know what was causing SVC-6766

[12:13] Jessica Lyon: ok ty.

[12:13] Pauline Darkfury: maybe the reduced UDP overhead might be helping the UUIDs get to where they are needed in time?

[12:13] Andrew Linden: there wasn't anything in the simulator code that looked like it was relevant -- I suspect backend problems (inv db, network, asset system) rather than simulator code.

[12:14] Jessica Lyon: very strange how it cropped up out of no where and then just kind of resolved itself.

[12:14] Jessica Lyon: Gremlins

[12:14] Joke Bubble: hi

[12:14] Flip Idlemind: Well Im sure someone will let you know if it starts happening again

[12:14] Andrew Linden: No Pauline, the AttachItemID problem cleared up before the "faster UDP" project hit the grid.

[12:14] Hope Dreier: That would be a temporaty infrastructure problem.

[12:15] Andrew Linden: Yeah, that is what we

[12:15] Andrew Linden: we're afraid of Flip, the problem will probably come back.

[12:15] Stickman Ingmann: [12:15] Andrew Linden: we're afraid of Flip

[12:15] Stickman Ingmann: Who isn't.

[12:15] TankMaster Teichmann: lol

[12:15] Moy Loon: ;)

[12:15] Pauline Darkfury: Some people seemed to have more pain from it that others. I think it only hit me once, maybe twice, other folks seemed to get it rather often

[12:16] Sebastean Steamweaver chuckles.

[12:16] Draconis Neurocam: I know Ive mentioned it before, and kelly said it need to be rewritten, but any idea on public urls never working at all in the estate debug floaters?

[12:16] Andrew Linden: woops. yeah that is ripe...

[12:16] Andrew Linden: for being pulled out of context ;-)

[12:16] Jessica Lyon: A question I posed last week to Oz, I'll ask here as well as he didn't have the answer. When infrastructure estimates load for upcoming features/changes/improvements. Do they base those estimates on LL viewer usage alone? or do they also take into account third party viewer usage?

[12:16] Joshy Aulder: Im not, he watches me in my sleep, so I feel safer :D

[12:16] Fancy Greeter: Oskar Linden has arrived!

[12:16] Flip Idlemind: I blame whoever put the apostrophe next to Enter

[12:16] Stickman Ingmann: Kelly, I undersatnd you're working on non-scripting stuff at the moment? Do you know when scripts will be worked on again -- there are several functions, such as the missing link functions, that would be very useful to get. Such as llLinkPlaySound, etc.

[12:16] Hope Dreier: welcome back Oskar

[12:17] Jessica Lyon: Phoenix adopting display names and overloading the display name servers indicates they didn't take into account third party viewer usage.

[12:17] Kelly Linden: Stickman I do not.

[12:17] Jessica Lyon: or at least suggests it

[12:17] Oskar Linden: doh

[12:17] Andrew Linden: hrm... infrastructure estimates for upcoming features/changes/improvements...

[12:17] Oskar Linden: crash

[12:17] Oskar Linden: :-(

[12:17] Pauline Darkfury: llLInkTargetOmega() as well

[12:17] TankMaster Teichmann: your doing it wrong

[12:17] Flip Idlemind: Crash? On Viewer 2?

[12:17] Simon Linden: Jessica - from what I know, the estimates are based on 3rd party usage too. We know it takes time for fixes to propigate out to other viewers.

[12:17] Rex Cronon: wb

[12:17] Sebastean Steamweaver: There's an entire list of them.

[12:17] Andrew Linden: I can't think of many such estimates that I've been involved in recently.

[12:18] Omega Flux: llLinkSounds please

[12:18] Sebastean Steamweaver: Don't forget llLinkTriggerSound

[12:19] Jessica Lyon: ok Ty Simon, we do try to keep Oz up to date with what features/changes/improvements we're releasing and when. It just seemed odd that Phoenix display name release in version 818 overloaded the display name servers so easily.

[12:19] Hope Dreier: Moy youre sitting on Oskar *grins*

[12:19] Pauline Darkfury: lol

[12:19] Qie Niangao: (tbh, Jess, the Display Name backend seemed pretty stressed even before TPVs started using it. )

[12:19] Stickman Ingmann: llLinkTriggerSound is low priority. You can llTriggerSound() with no delay as many times as you want.

[12:19] Andrew Linden: Kelly, when things get slow these meetings transform into LSL wishlists and brainstorms.

[12:19] Jessica Lyon: Qie.. yes.. point taken.

[12:19] Stickman Ingmann: The only advantage to the link is point of origin.

[12:19] Andrew Linden: Are you ready to talk about when we might actually add some new LSL functions?

[12:20] Sebastean Steamweaver: That's a pretty big advantage, heh.

[12:20] Jessica Lyon: new LSL Functions? o.0

[12:20] Omega Flux: no the advantage is that you wont have to use a extra script for the linked object

[12:20] Sebastean Steamweaver: Yes please :)

[12:20] TheBlack Box: wishlist: hierarchical linking ... pleeeeease :)

[12:20] Kelly Linden: I really don't know when that will happen.

[12:20] Chalice Yao: [12:19:27] Stickman Ingmann: llLinkTriggerSound is low priority. You can llTriggerSound() with no delay as many times as you want. <- the point is not needing additional scripts for those points of origin, yes.

[12:20] Stickman Ingmann: Hah. Yes, restructure the base functionality of all prims!

[12:20] Kelly Linden: Hierarchical linking is more up andrew's alley.

[12:20] Joshua Linden: While we're tossing things out: Any help in reproducing "stuck presence" issues (e.g. SVC-6193, SVC-3181 - probably multiple symptoms and causes) would be appreciated. Even correlation e.g. with sim load, number of attachments, etc. Any leads would be helpful.

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

[#SVC-3181] 'Phantom' avatars serverside, requiring a sim restart to remove.

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

[#SVC-6193] Avatar gets stuck in world after user logs out

[12:20] Chalice Yao: I am still rooting for llLinkInventory* scripts, too. :<

[12:20] Pauline Darkfury: llGetParcelScriptCount() and llGetParcelScriptOwners() for landloard/rental systems as well, akin to llGetParcelPrimCounts(), etc

[12:20] Chalice Yao: er, functions.

[12:20] Sebastean Steamweaver: I think we'll get new LSL functions before we get hierarchical linking.

[12:21] Jessica Lyon: Josh... we would LOVE to see that looked at!

[12:21] Andrew Linden: True object heirarchy is on our big backlog. Falcon Linden is pushing for progress there, but not until he's off the mesh project.

[12:21] Kelly Linden: If the point is to consolidate scripts into a single prim I'm not clear on the need for managing the inventory of other prims

[12:21] Omega Flux: not sure why you would do all the link stuff without the sounds one

[12:21] TheBlack Box: LSL 3.0 + Prims 2.0 = hierchical linking ... pleeeeease :)

[12:21] Stickman Ingmann: Here it is: https://jira.secondlife.com/browse/SVC-5165 Efficient scripts Jira.

[12:21] JIRA-helper: [#SVC-5165] Efficient Scripts

[12:21] Cummere Mayo wants to see a LSL script called llcthula which comes around and sucks out stupidly overmassive scripts from attachments as well as the souls of their creators >.>

[12:21] Flip Idlemind: Ah yes, that doesn't happen very often but it is frustrating when you can't log in because you can't log out

[12:21] Kelly Linden: There is unlikely to be another iteration of LSL.

[12:22] Hope Dreier: To be honest I'd rather see older problems fixed than new stuff added.

[12:22] Moy Loon: Arrays/objects/pointers!

[12:22] Jessica Lyon: The ghosting of avatars is a real problem.. and isn't viewer biased.

[12:22] Chalice Yao: Kelly: All the texture organizers out there use one script per 'category' prim currently due to a lack of linkInventory* functions.

[12:22] Stickman Ingmann: llLinkInventory* would be awesome, yes. One of the things I find myself wanting a lot. If nothing else, to clean out all of the child inventory I don't need anymore, since I have proper functions. But also as a tool to manage child-prim inventory while dealing with link messages to specific prims to save on overhead.

[12:22] TheBlack Box: hierachical linking would be new stuff that can fix (or imrove) quiete a lot of older issues ....

[12:22] Fancy Greeter: Oskar Linden has arrived!

[12:23] Flip Idlemind: More crashy?

[12:23] Oskar Linden: this is not my day

[12:23] Oskar Linden: that's what I get for using Phoenix

[12:23] Sebastean Steamweaver: Hierarchical linking would lead to an absolutely necessary change in LSL to support it.

[12:23] Oskar Linden snickers

[12:23] Andrew Linden: Somehow I have trouble seeing llCthula being a benevolent master.

[12:23] Joshy Aulder: Having https://jira.secondlife.com/browse/SVC-5488 would be a dream come true for me :D

[12:23] JIRA-helper: [#SVC-5488] llGetRegionAgents() -- returns list of agent keys in the current region

[12:23] Rex Cronon: switch computers

[12:23] Jessica Lyon: haha Oskar

[12:23] Moy Loon: Macs are so much more stable I thought, Oskar ;)

[12:23] Hope Dreier: What jessica said, and ghosting is a very old problem dating bact to 1.16 or eariler

[12:23] Sebastean Steamweaver: llMatchGroup would also be handy.

[12:23] Oskar Linden: the mac hasn't crashed. just the vwr.

[12:23] Oskar Linden closes StarCraft2 in the background

[12:24] Chalice Yao: That's because the viewer is not an Apple approved App.

[12:24] Pauline Darkfury: Talking of textures in child prims, SVC-3199, to avoid script per prim for copy+mod (needed to avoid leaking texture UUIDs), for texture changers on furniture, etc

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

[#SVC-3199] llSetLinkTexture(LINK_THIS, foo, bar) permssions handling broken for given objects

[12:24] Chalice Yao ducks

[12:24] Joke Bubble: yeey starcraft

[12:24] Jessica Lyon: lol

[12:24] Qie Niangao: Well, lacking llCthula(), then... some prospect of script memory limits would be progress.

[12:24] Joshy Aulder: Ive never had a computer crash in my life that wasnt in a school

[12:24] Cummere Mayo grins at andrew

[12:24] TheBlack Box: yeah .. thats the problem .. hierarchical linking requires a lot of changes in a lot of areas ... but it is a bit emberassing to be in a 3d world that doesnt support it .... a bit like using Photoshop without layers :/

[12:24] Moy Loon: Script limit stuff would be nice

[12:24] Cummere Mayo: its not meant to be thats the point lol

[12:25] Zwagoth Klaar: Mmm script limits.

[12:25] Andrew Linden: Kelly, you don't think we would add a few LSL calls to help reduce the number of scripts necessary for some content?

[12:25] Stickman Ingmann: Kelly, question about Mono that Latif brought up last week. A mono script is reported as having 64KB allotted at all times. But does it actually use that RAM when it's not taking up the total amount of memory? Or would 100 copies of the same simple Mono script share the bytecode, and only use minimal extra resources, contrary to what's reported?

[12:25] Andrew Linden: Such as the SVC-3199 and Sebastean's llUniformScale() idea?

[12:25] Joshy Aulder: Pardon my stupidity, but what IS hierarchial linking?

[12:25] Moy Loon: Think of a tree brange Bubbleface

[12:25] Andrew Linden: brb...\

[12:26] Moy Loon: Branch *

[12:26] Flip Idlemind: The closest thing we have to script memory limits is this in-your-face script counter box that makes people go "Wow, I have way too many scripts on.."

[12:26] Stickman Ingmann: Joshy: https://jira.secondlife.com/browse/SVC-6201

[12:26] JIRA-helper: [#SVC-6201] [hierarchical linking] Requiered additions and changes to objects and scripting, for improving content-creation capabilities.

[12:26] Omega Flux: orr

[12:26] Moy Loon: You have too many scripts on, Flip ;)

[12:26] Simon Linden: ... or being able to link things more naturally, like a hand to an arm

[12:26] Chalice Yao: Flip: And it can't show Mono memory properly. AFAIK.

[12:26] Rex Cronon: nr of scripts is part of the problem. what each script is doing is another part.

[12:26] Chalice Yao: So people shy away from it, still.

[12:26] Kelly Linden: We might be able to get some of the LSL link requests in a maintenance sprint, but I really could not promise anything.

[12:26] TheBlack Box: Joshy:currently all child-prims are child to the root prim .. hierarchical linking would be a tree-structure .. inner nodes could serve as joints ..

[12:26] Omega Flux: you are useing way to menny lines of settext!

[12:26] Flip Idlemind: I have the perfect amount of scripts on :P

[12:27] Pauline Darkfury: A step I'd love to see before script limits is actually exposing the real memory usage to EMs via SimConsole, possibly VM swapping stats as well

[12:27] Moy Loon: >15 is unneeded!

[12:27] Sebastean Steamweaver: No Flip, that would be 42.

[12:27] Kelly Linden: stickman: mono scripts use only the memory they need, and they share bytecode if the script asset ids are identical.

[12:27] Andrew Linden: back

[12:27] Moy Loon: I'd like to be able to use more than 64KB for some things

[12:28] Chalice Yao: Yeah, but the current script memory display settings always display 64kb. So people tend to shy away from mono scripts still, due to always seeing max mem. Well, that and the rez thing..

[12:28] Chalice Yao: Which reminds me..how goes the whole Mono 2 thing?

[12:28] Flip Idlemind: So if I have a script in my inventory, and I drag it into an object 12 times, it's kinda like only 1 script?

[12:28] Stickman Ingmann: So 100 1k Mono scripts wouldn't use 6MB of memory unless they actually had that much non-bytecode data stored, like a huge list.

[12:28] Moy Loon: No, It'd be 12 scripts, Flip

[12:28] Pauline Darkfury: Yes, some people are wrongly converting Mono to non-Mono for static-rezzed stuff, believing it's helping

[12:28] Joshy Aulder: Wow, this wasnt implemented instead of this root prim method why?

[12:28] Flip Idlemind: I said "kinda like"

[12:28] Kelly Linden: Moy: so first we need to be able to set mono scripts to something smaller than 64k (so we can reflect in the accounting somethign closer to their actual use) then we need region/parcel wide limits on total memory scripts can use, and only after both of those can we let mono scripts set a higher limitt than 64k on their memory

[12:29] Moy Loon: Get workin' then! ;)

[12:29] Andrew Linden: Flip, that is something I was thinking about working on as a sekret project: bitecode sharing of scripts with identical code.

[12:29] Kelly Linden: Flip there is some savings, but it is less than you probably expect. A fair bit of the data is state data

[12:29] Chalice Yao: [12:29:14] Andrew Linden: Flip, that is something I was thinking about working on as a sekret project: bitecode sharing of scripts with identical code. <- I thought Babbage implemented that?

[12:29] Kelly Linden: Andrew: we do that with mono scripts already.

[12:29] Andrew Linden: But then, I've already got too many sekret projects that don't get any love.

[12:29] Kelly Linden: The accountind just doesn't reflect it.

[12:29] Andrew Linden: oh really for Mono? good

[12:30] Joshy Aulder: Ill brb

[12:30] Joshua Linden: As always, the first project should be to build the cloning machine...

[12:30] Pauline Darkfury: Kelly, we need a fairly long period between "small scripts" and "script limits" going live. It's going to take months for some regions to swap stuff out, find alternatives where the creator has left SL (or just is slow/busy), etc

[12:30] Kelly Linden: it is a little hairy to convey appropriately

[12:30] Joshy Aulder: Hopefully Ill be back before the meeting ends

[12:30] Kelly Linden: Pauline I agree

[12:30] Flip Idlemind: Well Kelly said there's bytecode sharing of scripts with the same asset id. If it's one script dragged into an object 12 times, do they have the same asset id?

[12:30] Chalice Yao: Kellz: Any ETA on the full Mono 2 rollout to fix the serialization hangups?

[12:30] Kelly Linden: I'd also like to get the ability to delete scripts from objects in there if possible.

[12:31] Stickman Ingmann: Flip, if they have the same UUID, then they share bytecode. If you recomiple, they don't.

[12:31] Kelly Linden: Chalice: working with the mesh team to get aditi updated. Once that happens I'll hijack half aditi to test it for a few weeks

[12:31] Kelly Linden: and let everyone here know

[12:31] Chalice Yao: kk :3

[12:31] Stickman Ingmann: Recompiling gives you a new UUID for a script.

[12:31] Hope Dreier: YES on deleting scripts even from nomod objects.

[12:31] Sebastean Steamweaver: Efficient functions first - then memory limits. Give us efficient tools and we can start moving to more efficient scripts so the impact of memory limits, whenever that happens, is less drastic.

[12:31] Rex Cronon: u can already delete scripts from objects

[12:31] Chalice Yao: [12:31:23] Hope of Tentium (hope.dreier): YES on deleting scripts even from nomod objects. <- ohgodthis

[12:31] Moy Loon: Mmm

[12:31] Jessica Lyon: ^^^ that

[12:31] Chalice Yao: 100 script nomod resizer boods make people sad.

[12:31] Chalice Yao: *Boots

[12:31] Jessica Lyon: really...

[12:31] Hope Dreier: dresses and hair

[12:32] Pauline Darkfury: I'd also like to see the bytecode sharing reflected in some way in the limits. E.g. if a store has 100 hippoVEND v2.71 single-script, single item vendors (or just maybe 10 multi-script, multi-item), they shouldn't be charged for 100 or 10 * the bytecode when they clearly are not putting that memory load on the region

[12:32] Jessica Lyon: please bring back the ability to delete scripts from no mod! PLEASE!

[12:32] Ardy Lay: I found a 1200 script prim bikini.

[12:32] Kelly Linden: just to be clear - it would permantently remove the scripts and not add them to your agent inventory - it would permanently break the object.

[12:32] Jessica Lyon: that's great!

[12:32] Chalice Yao: Kelly: I so could live with that.

[12:32] Jessica Lyon: perfect! lol

[12:32] Hope Dreier: We understand that

[12:32] Rex Cronon: is not right to allow deletion of scripts from no-mode objects. some of those scripts were put there for a reason

[12:32] Qie Niangao: yeah, break away

[12:33] Kelly Linden: Rex: well, that is part of the design discussion.

[12:33] Stickman Ingmann: It'd upset some people who add in "copy protection" of some kind if you could delete scripts from nomod objects. But didn't we used to be able to do that?

[12:33] Pauline Darkfury: Yup, Kelly, give us the choice to break stuff or risk breaking it, just give clear warnings when that could happen

[12:33] Hope Dreier: Well you have to wne th object clearly.

[12:33] Jessica Lyon: else, Force content creators to provide a dialog ability to delete scripts BANHAMMER if they do not comply!

[12:33] Jessica Lyon: >.>

[12:33] Chalice Yao: Rex: Originally the sudden lack of removal possibility was a -bug- til people started to abuse that bug as a feature.

[12:33] Qie Niangao: scripted copy protection is dopey anyway.

[12:33] Stickman Ingmann: Agreed, Qie.

[12:33] Chalice Yao: i.e. for false security.

[12:33] Patnad Babii: is the C# project dead? or is it something that we might see with the Mono 2 project ?!

[12:33] Sebastean Steamweaver: I'm afraid I have to agree with Rex there. There are more reasons for putting scripts in objects than just resizers that I've seen.

[12:33] Rex Cronon: really challice?

[12:33] Pauline Darkfury: e.g. give us the ability to force a smaller memory footprint on a Mono script in a no-mod prim, so that we don't have to junk nice content where the creator has gone

[12:33] Flip Idlemind: It'd be better if people would just stop making / wearing "u need a script in every prim guize!" hair / shoes / etc.

[12:34] TheBlack Box: "no mod" on prims .. and "no copy" in general desevre to get abbolished anyway :)

[12:34] Sebastean Steamweaver: And more reasons than copy-protection. There are a few more practical purposes.

[12:34] Jessica Lyon: Hair, 254 prims, with 800 scripts.. breaks SL

[12:34] Kelly Linden: The C# project is on hold and dependent on mono2, small scripts, script limits, big scripts and maybe more.

[12:34] Pauline Darkfury: Let us see the real memory high water mark, make our own judgement on how tight we want to risk pushing the memory limit

[12:34] Jessica Lyon: OR, let script limits break anything with stupid high script counts

[12:34] Stickman Ingmann: Flip, llUniformScale or llSetObjectScale or whatever it is would solve that problem. llSetLinkPrimitiveParamsFast was supposed to, but didn't make it easy, and still has a number of issues.

[12:35] Flip Idlemind: I think I have fewer color changers in my whole av than some people have in their left shoe :O

[12:35] Kelly Linden: Rex: would it be possible to add some permissions check restrictions on the scripts themselves that would allow the content management systems to still work will allowing the grievous 100 script resizers to be cleaned up?

[12:35] Jessica Lyon: what FLIP said. Really.. this is what's wrong with SL and script lag.

[12:35] Flip Idlemind: And I can do this

[12:35] Flip Idlemind: theme.preset.blackgreen

[12:35] Jessica Lyon: OR, force content creators to advertise script counts in their products!

[12:35] Kelly Linden: In other words: do scripts that are used in no-mod objects for content management have a permissions signature that identifies them from common resize scripts?

[12:36] Jessica Lyon: but really, something needs to be done guys

[12:36] Sebastean Steamweaver: You can't force people to advertise that, but it could be similar to mesh: people start advertising low script counts as a "Feature" - positive pressure.

[12:36] Cummere Mayo: I try not to use more then one or two scripts and very small ones at that

[12:36] Jessica Lyon: Right

[12:36] Hope Dreier: You could certinally put a call inthere to something that marks a script as non deletable

[12:37] Jessica Lyon: A good pportion of my inventory is items I simply cannot morally wear because of their script counts.

[12:37] Cummere Mayo: maybe the stuff i sell boxed i should advertise lowscripts... but ild feel more comfrotable if there was a good way to caluculate script usage (as kelly pointed out before)

[12:37] Zwagoth Klaar: Script should ALWAYS be deletable. ALWAYS.

[12:37] Stickman Ingmann: That's genocide, Zwagoth!

[12:37] Hope Dreier: Weapons makers for the Gorean community do advertise low script counts

[12:37] Zwagoth Klaar: Even in no mod :<

[12:37] Cummere Mayo: I totally agree zwagoth but unfortuneately that bug was never fixed

[12:38] Hope Dreier: scripocide not genocide

[12:38] Rex Cronon: what it would be possible it depends on u guys. but is not right to allow any scripts to be removed by anybody from no-mod objects.

[12:38] Cummere Mayo: because some certain people who unfortuneately seem to have LL's ear on every bad idea said that it would break too much stuff if that was fixed

[12:38] Jessica Lyon: Rex, it was intended behavior for a great many years that users could del scripts from no mod

[12:38] Sebastean Steamweaver: I still agree with Rex - I don't see a good reason for forcing script removal, just because we want to change what someone else built.

[12:39] Andrew Linden: The sticking point for deleting scripts on no-mod objects is that some people have implemented complicated multi-script permissions systems.

[12:39] Zwagoth Klaar: You could delete anything from no mod.

[12:39] Hope Dreier: it's not forcing, it's allowing

[12:39] Jessica Lyon: The idea isn't to change your hair, the idea is.. once you've set the size and color.. you can delete the 9000 scripts from it

[12:39] Joshy Aulder: back

[12:39] Jessica Lyon: as you won't be needing them again

[12:39] Andrew Linden: when you can delete one but not the others is may be possible to corrupt their system

[12:39] Pauline Darkfury: How about a llSetScriptLoaded(string name, integer on_off) to allow creators to have some scripts completely out of the sim (and limits) until needed?

[12:39] Stickman Ingmann: I believe the benefit for deleting things from a nomod object outweight the problems.

[12:40] Jessica Lyon: let me put it this way, 99% of the tp failures our support team deal with, are users who have 1000+ scripts worn and not even aware of it.

[12:40] Andrew Linden: so maybe it should be: allow delete of scripts, but then must delete ALL ?

[12:40] Zwagoth Klaar: Well, that is the problem of the scripter/user. As long as it gives a warning. and it always has.

[12:40] Chalice Yao: [12:40:11] Andrew Linden: so maybe it should be: allow delete of scripts, but then must delete ALL ? <- I can agree with that

[12:40] Hope Dreier: that is fine much like delet all in selected

[12:40] Sebastean Steamweaver: That's the fault of the maker, and an unfortunate one Jessica. Everyone here knows I hate resize systems most likely. But I'd put pressure on the maker to update the hair, rather than remove a 'Feature" which other people use for legitimate purposes.

[12:40] Omega Flux: llsetlinkscale

[12:40] Jessica Lyon: right, delete all.

[12:40] Qie Niangao: oh... I get it. some existing no-mod objects rely on a no-copy script to trump copy-perm on a no-transfer object

[12:40] Stickman Ingmann: Good compromise, Andrew. I would prefer more flexibility, but I can see the need for such a requirement.

[12:41] Cummere Mayo: its nto a feature though

[12:41] Andrew Linden: No Zwagoth, I'm saying that if you can break one script but not others it may be possible to produce exploits within the scripter's system.

[12:41] Sebastean Steamweaver: And I'm not talking about dopy "copy-protection" systems.

[12:41] Cummere Mayo: orriginally you could delete crap from no mod objects

[12:41] Andrew Linden: Perhaps L$ exploits, or permissions exploits.

[12:41] Pauline Darkfury: no-copy+no-trans objects are an abomination anyway

[12:41] Jessica Lyon: Seb, yes.. I've been spending a lot of time trying to educate users to pressure content creators to lower script counts but it isn't working.

[12:41] Hope Dreier: Qie tha so doesnlt work

[12:41] Rex Cronon: when an object says no-mod. that means u can't mod it. by allowing to remove scripts u break the contract

[12:41] Jessica Lyon: It's just 'easier' to put a resize and recolor script in every prim

[12:42] Cummere Mayo: no mod should go back to what it was when i joined sl

[12:42] Jessica Lyon: ^

[12:42] Sebastean Steamweaver: Jessica: that's exactly the thing. That's also why I believe we still need llSetObjectScale/llGetObjectScale, because the llSetLinkPrimitivePAramsFast (1) still has issues and (2) is "too much effort" for most scripters to want to make the change.

[12:42] Andrew Linden: So... one reason people want to remove scripts is... to resize/color their prim hair just right, then remove the script overhead?

[12:42] Stickman Ingmann: https://jira.secondlife.com/browse/SVC-421

[12:42] JIRA-helper: [#SVC-421] Cannot delete contents from no-modify objects

[12:42] Hope Dreier: there is alos legacy content, I have hair from makers that are long gone, I donlt use it because there are 50-90 scripts in them.

[12:42] Jessica Lyon: Anrew, yes

[12:42] Kelly Linden: I hear with the link rule changes and Simon's messaging optimizations llSetLinkPritimitiveParamsFast is really fast now

[12:42] Omega Flux: to much effort ?!?!

[12:42] Zwagoth Klaar: I guess. It just seems odd that somebody would rely on multiple scripts for DRM though. You cannot add another script either.

[12:42] Stickman Ingmann: Jira's from 2007.

[12:42] Omega Flux: thats just silly

[12:42] Sebastean Steamweaver: Omega: for people who think the system they have is "good enough."

[12:43] Rex Cronon: there r lots of demos around that would become fully functional if scripts were to be removed

[12:43] Jessica Lyon: Historically, you could delete object contents from no mod objects... just not add to them. This is what i'd like to see come back

[12:43] Flip Idlemind: This is tricky. On one hand, if you make something no modify, it's because you don't want it modified (even by taking things out.) On the other hand, it could cut down on the number of people who wear 256 scripts on their head, and file support tickets about how they can't teleport

[12:43] Sebastean Steamweaver: Unless there is a drastic change in "ease" of switching the system, most won't want to.

[12:43] Omega Flux: sounds some "people" are lazy

[12:43] Omega Flux: sounds like

[12:43] Sebastean Steamweaver: I agree Omega - but it's a factor nonetheless.

[12:43] Moy Loon: I think even if you DO add a delete all, the pubbies won't use it

[12:43] Stickman Ingmann: Kelly, you're talking about Simon's UDP optimizations? Have there been any tests done?

[12:44] Moy Loon: So, you'll still have the same 400+ scripts people

[12:44] Sebastean Steamweaver: The thing is, people wearing resizers with huge numbers of scripts is an entirely different problem. You've found a possible solution (delete from no-mod) without considering other uses that delete from no-mod current is used for.

[12:44] Cummere Mayo: one person ademantly screams agaisnt it because if people could delted the scripts on her shoes she makes she would not be able to track who rezzes them

[12:44] Andrew Linden: Does anyone think that the ability to only delete ALL (if any) scripts on a no-mod object is a bad idea?

[12:44] Kelly Linden: Stickman: I only have what maestro told me after playing with it. No concrete tests

[12:44] Pauline Darkfury: One of the issues with no-mod hair and the like is the myth that no-mod somehow prevents copybots from copying. Dispelling that myth from very credible sources might help a lot (also the insulting nag scripts that accuse you of theft if you rez the object in-world instead of wearing it)

[12:44] Cummere Mayo: which to me is stupid

[12:44] Omega Flux: i think you should just drop the script limmit bomb overnight

[12:44] Jessica Lyon: well, something needs to be done to reduce script counts on worn items. Whether that be pressuring content creators, or allowing people to remove them.. something needs to be done really.

[12:44] Sebastean Steamweaver: I think it's a bad idea, because resizers, and "copy protection" are the only uses.

[12:45] Cummere Mayo: andrew ild prever to pick and choose but all would be btter then nothing

[12:45] Sebastean Steamweaver: are NOT* the

[12:45] Simon Linden: I grabbed some data today and the faster UDP message building hasn't cured all the performance problems :)

[12:45] Andrew Linden: Omega says that because the complaints won't be showing up in his mailbox.

[12:45] Cummere Mayo: seb copy protection is already broken by rezzing in a no script area

[12:45] Joshua Linden: lol simon

[12:45] Kelly Linden: If the permissions on the scripts effect the permissions (ie transferability or copyability) of the whole, than removing them would have an undersired effect andrew.

[12:45] Stickman Ingmann: Andrew: I understand the negative sides, but I believe it would have more advantage than not. It's a compromise on an old bug fix that was never completed.

[12:45] Omega Flux: fwd them to my email

[12:45] Cummere Mayo: and theres LOTS of other scripts that could be deleted

[12:45] Pauline Darkfury: I'd rather be able to cull scripts individually, that's the better solution overall, but cull-ALL vs. none is better

[12:45] Omega Flux: i can take it

[12:45] Sebastean Steamweaver: Cummere - I've never supported "copy-protection" as a purpose. I think the copy-protection is bunk.

[12:45] Sebastean Steamweaver: I'm saying it's not the only reason people use it.

[12:45] Andrew Linden: Kelly, for no-mod objects we could bake the perms.

[12:46] Chalice Yao: Sebastean: So state the reason already.

[12:46] Rex Cronon: offef incentives for people to wear less scripted items, and for creators to make such things, but don't fore down everybodys throat the deletion of scripts from non-mod

[12:46] Omega Flux: the fact that the "system" allows people to have on 1200+ scripts is outrageus

[12:46] Kelly Linden: Andrew: I suppose we could at that.

[12:46] Jessica Lyon: what Omega said ^

[12:46] Moy Loon: More script limits!

[12:46] Omega Flux: you guys have had years AND YEARS to handle this sorta stuff

[12:46] Andrew Linden: What is a reasonable limit for total script count Omega?

[12:46] Moy Loon: Give us our 1.5MB, and those 1000+ script people will go away!

[12:47] Cummere Mayo: if i could get rid of the scripts from my horses i would keep some of them .... for example... the scripts that force you to feed a horse you can no longer breed? ugh... it would require breedables to clean up their act if they wanted to keep customers...

[12:47] Omega Flux: Max 100

[12:47] Omega Flux: MAX

[12:47] Hope Dreier: 150

[12:47] Jessica Lyon: no more than 200 scripts, imo.

[12:47] Pauline Darkfury: No, max 250

[12:47] Moy Loon: 25

[12:47] Cummere Mayo: 200

[12:47] Kelly Linden: I need 300 at least

[12:47] Moy Loon: One per attachment ;)

[12:47] TankMaster Teichmann: 666 max!

[12:47] Jessica Lyon: 300?

[12:47] TankMaster Teichmann: :P

[12:47] Hope Dreier: Pfffft myst -tool has 50 all by it's self

[12:47] Jessica Lyon: for what? lol

[12:47] Omega Flux: facter in the script times per script

[12:47] Sebastean Steamweaver: Chalice: I have, but I think it got lost in the flood. Things like games which rez specific objects, or objects that rely on scripts to work in games or utilities, which people then delete and then "call home" to the creator wondering why their object doesn't work anymore, etc.

[12:47] Andrew Linden: Hrm... that would kill the 255-prim objects with per-prim script strategies

[12:47] Omega Flux: factor

[12:47] Jessica Lyon: hope.. exactly!

[12:47] Omega Flux: 300 scripts at what

[12:47] Flip Idlemind: Sure we all agree we need limits. Now we get to fight about what the limit should be

[12:47] Kelly Linden: (I was joking jessica, everyone was going up by 50 each line)

[12:47] Omega Flux: 0.03 ?

[12:47] Omega Flux: each

[12:47] Stickman Ingmann: Number of scripts is not a proper limit. The RAM and CPU are the actual limits that should be placed on the scripts.

[12:48] Jessica Lyon: lol orite

[12:48] Andrew Linden: I was curious what kinds of numbers people would suggest.

[12:48] Pauline Darkfury: It should also be something which has a degree of EM control on full sims. Give us that 150% value over mainland by letting us set the value and take the risk of our sim swapping, just give us proper isolation from adjacent sims

[12:48] Kelly Linden: reserved RAM is the limit we would implement.

[12:48] TheBlack Box: 255-prim objects with 1-scipt-per-prim-strategy is exactly the suff we need to get ridof ;)

[12:48] Sebastean Steamweaver: I agree with Stickman, though I still say we need efficient functions before we limit scripts, not after.

[12:48] Jessica Lyon: what TheBlack said

[12:48] Omega Flux: script limmits premote smarter scripting

[12:48] Jessica Lyon: many creators have a seperate color change script and resize script, that's 255 scripts X2

[12:48] Andrew Linden: Perhaps true TheBlack, but I'm leary of championing changes that are going to get a bunch of people complaining to me directly

[12:48] Zwagoth Klaar: Memory is the proper way to limit it. Although it is going to give people reason to use the older LSL2 system.

[12:49] Sebastean Steamweaver: Yes, with an iron fist. I think most people would script smarter if they had "smarter" (more efficient) functions.

[12:49] Pauline Darkfury: Some of us don't have any interest in our US$295 sim being able to support 100 AVs, we'd rather have very rich interactivity with just 20 AVs, for example

[12:49] Jessica Lyon: and result is failed to tp

[12:49] Flip Idlemind: If reserved RAM is the limit, then as long as all (Mono) scripts reserve 64kb, script count will be the limit

[12:49] Hope Dreier: script limits break legacy items

[12:49] Andrew Linden: such as breaking PosJump and WarPos

[12:49] Kelly Linden: Sebastean: we covered the highest nails in "efficient scripts" there are still a few cases, and we will get more as we go.

[12:49] Omega Flux: there is tons of junk out there that needs to be broken

[12:49] Sebastean Steamweaver: There's not need to slap people around with script limits and then give them better functions to work within it.

[12:49] Omega Flux: if they want to fix it they can

[12:49] Stickman Ingmann: I feel like we're sitting here decided some things LL already has internally. We want a solution to a problem, and a proper solution has so many dependancies, and a quickfix has so many problems.

[12:49] Kelly Linden: if you have any not in jira add them and link them to SVC-5165

[12:49] Omega Flux: but people with 300 400 500 scripts brake sims

[12:49] Omega Flux: 300 scripts Times 40 is alot

[12:50] Pauline Darkfury: People with 500 scripts don't always break sims

[12:50] Omega Flux: Yes they do

[12:50] Cummere Mayo: with 500? yes they do

[12:50] Hope Dreier: Folks with 500 scripts have difficulity arriging in your sim

[12:50] Stickman Ingmann: Scripts don't break sims. People break sims. Support people control.

[12:50] Sebastean Steamweaver: We're listing off huge numbers. I'd like to see statistics on how many people actually have that many.

[12:50] Joshy Aulder: Wasnt PosJump gonna be replaced with "PRIM_REGION_POS" for llSetPrimitiveParams?

[12:50] Kelly Linden: it doesn't appear that anyone here has more than 200, according to flips attachment

[12:50] Rex Cronon: they were fully aware when they bought their stuff. and if they weren't they should go back to seller asking for their money back

[12:50] Pauline Darkfury: No, if I'm content to have just 10 people for my US$295, I can easily arrange my region to cope with 500 scripts per AV

[12:50] Sebastean Steamweaver: Bubble, that was an idea, but it never came to pass.

[12:50] Jessica Lyon: Seb... a LOT, i mean.. a lot a lot

[12:50] Omega Flux: but really send the hate mail to me

[12:50] Stickman Ingmann: Statistics we saw were for RAM. I believe it was 1.5MB median.

[12:50] Cummere Mayo: at a recent derby event the avearge of our spectators was 120 scripts

[12:50] Andrew Linden: yes probably Joshy, I forget.

[12:50] Sebastean Steamweaver: Jessica: I'm thinking back to Babbage's office hours.

[12:51] Cummere Mayo: we had people that came as high as 700

[12:51] Jessica Lyon: Like I said, 99% of phoenix support that deals with TP fialures are people with more than 500 scripts worn and having no clue

[12:51] Pauline Darkfury: People with 500 scripts break _some_ sims, I'll agree with that

[12:51] Pauline Darkfury: They don't break all sims

[12:51] Zwagoth Klaar: I see tons of people with 4MB of RAM.

[12:51] Jessica Lyon: and we deal with a LOT of tp failures

[12:51] Cummere Mayo: the MOMENT they came into the sim it would slow 15-20 frames per second

[12:51] TheBlack Box: Andrew: i like that .. because it makes my life easier too ... but we are in a dilemma .... we cant have legacy content working properly outside of any script-limits and at the same time expect the overuse-issue to go away .. i am afraid

[12:51] Flip Idlemind: People with 500 scripts definitely make sims freeze up when they enter them

[12:51] Sebastean Steamweaver: RAM isn't possibly to accurately calculate right now because it always gives the largest possible amount available.

[12:51] Pauline Darkfury: That's why we need a degree of EM control over it. If someone is above the EM set limit, treat it the same as a no-script parcel

[12:51] Sebastean Steamweaver: possible*

[12:52] Zwagoth Klaar: thank you moy

[12:52] Pauline Darkfury: So, and EM for a conference area that wants 100 people could set a limit of 10 scripts per person, someone who wants a highly interactive region with just 20 people could set 250-400 per person, depending on how much they feel the land needs

[12:52] Zwagoth Klaar: It also shows that script count often has nothing to do with memory usage.

[12:52] Rex Cronon: allow sim owners to deny access to those that have lets say over 250 scripts

[12:52] Omega Flux: moving tords the script limmits will do alot to improve the grid

[12:52] Stickman Ingmann: No-script parcel is circumventable, and graceful degradation is preferable over a confusing non-working state.

[12:52] Omega Flux: ALOT

[12:52] Stickman Ingmann: Principle of least confusion.

[12:53] Hope Dreier: fkip people with 20 script caus sim hqnging, albeit small hangs (fractions of a scrond)

[12:53] Omega Flux: so add limmits make new functions that help lower script counts

[12:53] Pauline Darkfury: Yes, you can circumvent no-script, but it gives us a basic model for how an EM could control per-AV limits (with the ability to circumvent disabled)

[12:53] Andrew Linden: Yeah, I'm in favor of EM control over max script counts./

[12:53] Sebastean Steamweaver: Like I said, give people more efficient means first. Then add the limits.

[12:53] Rex Cronon: what is EM?

[12:53] Jessica Lyon: EM controls is a good start

[12:53] Pauline Darkfury: Estate Manager

[12:53] Jessica Lyon: Estate Managment

[12:53] Hope Dreier: Estate Manager

[12:53] Rex Cronon: ok

[12:53] Omega Flux: it wont matter if you give them to people

[12:53] Zwagoth Klaar: I'm all for EM controls

[12:53] Sebastean Steamweaver: There are still more things that can be done - and I will add them to the JIRA when I have time, heh. Right now I have a hard enough time just remembering to get 3 meals in a day I'm so busy.

[12:53] Pauline Darkfury: SOmeone who pays or represents payment for n * US$295/month

[12:54] Omega Flux: like YOU said people are lazy

[12:54] Omega Flux: and wont use them

[12:54] Kelly Linden: There will probably have to be multiple parts to the memory limits. Because we are talking about common resources (shared server hosts) there will have to be an absolute cap - probably rather high - and then as another question the ability for estate owners to adjust caps in their regions.

[12:54] Omega Flux: but if you rip the bandaid off it will be better

[12:54] Sebastean Steamweaver: Omega, it will always matter. You can't simply say "No one will use them." People will. People have been waiting and itching for them. I'm saying that making it easier will get more people to change their systems in regard to resizers.

[12:54] Flip Idlemind: You took steps in the right direction with ParamsFast() and such but that was, what? Almost a year ago? We need more stuff like that

[12:54] Omega Flux: hell give a month warning

[12:54] Sebastean Steamweaver: I never said "Everyone" is lazy.

[12:54] Rex Cronon: if the sim owner wants to be able to attach 1000 scripts, let them:)

[12:54] Stickman Ingmann: A month? Heh.

[12:55] Hope Dreier: For some value of Everyone.

[12:55] Pauline Darkfury: Kelly, let us push the limit as EMs, just give us hard isolation between adjacent full sims (ignore homesteads here, clamp them down hard if you want)

[12:55] Stickman Ingmann watches content creators with hundreds of products try to update them all in a month.

[12:55] Kelly Linden: there will have to be a region cap

[12:55] Pauline Darkfury: So, let me as EM take the risk to push my region close to swapping, just adjust the virtual machine setup so that I can't impact the 3 or 7 adjacent regions

[12:55] Draconis Neurocam: stickman that would be nothing but good honestly

[12:55] Cummere Mayo: acutually homsteads if anything should be the same limits as a full sim

[12:55] Chalice Yao: Pauline: The problem is that swapping affects all four regions on a sim.

[12:55] Draconis Neurocam: more revenue, more people buying, more sl traffic

[12:55] Sebastean Steamweaver: Draconis, that would be nothing but impossible.

[12:55] Kelly Linden: if it only effected your region that would make sense. Since it doesn't though, we can't do that.

[12:56] Hope Dreier: wHY THEY ARE NOT PAYING FOR A FULL SIM.

[12:56] SilverbackMale Looming: howdy all :)

[12:56] Pauline Darkfury: The swapping doesn't have to impact all 4 or all 7/8 regions

[12:56] Rex Cronon: hi

[12:56] Hope Dreier: \Sorry didn't mean to shout

[12:56] SilverbackMale Looming: help island public has been down for long

[12:56] Cummere Mayo: hope not all of us can afford a full sim and it would still be a lighter load on the hosting comp

[12:56] Cummere Mayo: even on the cpu

[12:56] SilverbackMale Looming: ?

[12:56] Pauline Darkfury: Modern VM technology should be able to cope with preventing one virtual machine from swamping the disk I/O of all others

[12:56] Qie Niangao: And need some pre-screening for TP. If you have more than X script mem attached, no black screen, just a message: "detach stuff first"

[12:56] Rex Cronon: what qie says

[12:57] Jessica Lyon: what Qie said !

[12:57] Jessica Lyon: Totally entirely 200% in favor of that

[12:57] Pauline Darkfury agrees with Qie wholehartedly

[12:57] Andrew Linden: Qie is right. There are UI issues to deal with which makes it harder to get done.

[12:57] Hope Dreier: Talking to the destination Region?

[12:57] Andrew Linden: Still should be done IMO.

[12:57] Cummere Mayo: thats not an issue

[12:57] Kelly Linden: Pauline: while theoretically possible that is a huge change to our infrastructure.

[12:57] Jessica Lyon: It would, if no thing else.. help educate users as to script usage

[12:58] Jessica Lyon: Education is a HUGE key in this

[12:58] Stickman Ingmann: One of my biggest issues with LL is a lack of education about the system and it's reasonable limits. Freedom is great -- education about the limits to use that freedom and still be able to move are better.

[12:58] Cummere Mayo: andrew any ui work can be outsourced to any snowstrom dev and they can work with wolf linden to get it aproved

[12:58] Jessica Lyon: people simply don't understand wearing 500+ scripts is a problem

[12:58] Cummere Mayo: we're doing that already

[12:58] Stickman Ingmann: We have no building guidelines, script, prims, textures, or otherwise.

[12:58] Cummere Mayo: and it works VERY well

[12:58] Jessica Lyon: Right, Me too Cummere.. but even we don't have the reach LL has for educating users on script usage

[12:58] Sebastean Steamweaver: All they know is, "Wearing this lets me do this! Why should I change?"

[12:58] Pauline Darkfury: Kelly, script limits are a huge change in our world. Interactivity is key to driving SL forwards and growing in the future. If the infrastructure needs to change to ensure we can keep max interactive content, then it should change

[12:59] Omega Flux: like i said

[12:59] Stickman Ingmann: People are stupid. Strapping a yoke on them doesn't help. Educating them might. At the very least, educating the content creators should let them make the choices to do something stupid, rather than doing something stupid without even knowing.

[12:59] Omega Flux: rip the bandaid OFF

[12:59] Omega Flux: and people will learn

[12:59] Sebastean Steamweaver: Dittos with Stickman

[12:59] Stickman Ingmann: "My stuff is good enough to use 500% standard resources" is a choice. "I want it to do this, and I only know how to do it this way" is not.

[12:59] Flip Idlemind: So last minute question (literally) are the Mesh sims on Aditi any closer to becoming aware of Mono2?

[12:59] Pauline Darkfury: Yes, education is the key

[13:00] Andrew Linden: Yes a little closer Flip.

[13:00] TheBlack Box: asking non-scripter to only use reasonable content wont work. Even Scripters get confised about what is efficiant and what isnt .... as we already seen the pure number of scripts running is not the best metric even ...

[13:00] Jessica Lyon: Stick, there are free scripts on marketplace using pparamsfast which allow content creators to just use that ONE script for resizing all chilc prims.

[13:00] Andrew Linden: I think Falcon had an update for mesh today... dunno the state of that though.

[13:00] Omega Flux: 70% if not more wont seek education

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

[13:00] Stickman Ingmann: It's not a matter of seeking it. It's a matter of giving it to them.

[13:00] Pauline Darkfury: I've noticed a marked improvement via simple deployment of a white / green /yellow / red script counter in the main hangout area of my play sim where people tend to have some rather heavily scripted stuff

[13:00] Jessica Lyon: right

[13:00] Andrew Linden: There is a current problem with mesh... mesh obj's can't cross region boundaries (in the update) I think.

[13:00] Stickman Ingmann: Interface changes, tutorials, certification -- something. Anything!

[13:00] Omega Flux: even if you give it to them they wont do it

[13:01] Andrew Linden: That is a temporary problem and will be worked out soon.

[13:01] Kelly Linden: I need to headout, bye!

[13:01] Pauline Darkfury: The education is along the lines of take things off if you don't really need them right now, that way other people who do want to play with their toys can get better performance

[13:01] Rex Cronon: tc kelly

[13:01] Jessica Lyon: Thanks for coming Kelly!

[13:01] Qie Niangao: thanks Kelly.

[13:01] Sebastean Steamweaver: Certification is an interesting idea, but would be difficult to implement while still allowing people to learn.

[13:01] Hope Dreier: Thank you Kelly

[13:01] Sebastean Steamweaver: Thanks Kelly

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

[13:01] Pauline Darkfury: Thanks, Kelly

[13:01] Jessica Lyon: oh wow, it's over

[13:01] Pauline Darkfury: Ahh, 1pm already

[13:01] Stickman Ingmann: I need to run myself. I think Linden Lab has the right idea about things -- it's just going to take a while to get there.

[13:01] TankMaster Teichmann: tc everyone

[13:01] Jessica Lyon: bummer, thanks for your time guys!

[13:02] Pauline Darkfury: Thanks, Lindens

[13:02] Sebastean Steamweaver: I need to get going too. Work calls

[13:02] Pauline Darkfury: Take care all, have fun :)

[13:02] Rex Cronon: tc everybodyand have fun:)

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

[13:02] Chalice Yao: Ciao!

[13:02] TheBlack Box: bye all

[13:02] Stickman Ingmann: Thanks for the office hours, Andrew, Simon.

[13:02] Hope Dreier: Sebastiean? Like Micro$oft certification? Bah

[13:02] Pauline Darkfury: I'd also like to say that was refreshingly energetic without getting bitchy :)

[13:02] Andrew Linden: I'm trying to publish these meetings in a timely manner at: http://wiki.secondlife.com/wiki/Simulator_User_Group#Archive

[13:02] SilverbackMale Looming: that table is great lol think i said that last time

[13:02] Andrew Linden: I'll try to publish today's and last Friday's today.

[13:03] Qie Niangao: Thanks Andrew :)

[13:03] Jessica Lyon: Thanks Andrew

[13:03] Hope Dreier: It appears to be the table from a Myst tool

[13:03] Joshy Aulder: I want one, but I also wanna make my own :D

[13:03] Pauline Darkfury: There's a similar on in emDash

[13:03] SilverbackMale Looming: cool i have a mysti tool had no idea that is in there lol


Simulator_User_Group

Prev 2011.03.11 Next 2011.03.18