Content Creation/Scripting User Group/Transcripts/2011 10 24
List of Speakers
| Jeremy Duport |
| Leonel Iceghost |
| Motor Loon |
| Script Counter |
Transcript
[08:59] Koli Contepomi (sahkolihaa.contepomi): Hey Kelly & Charlie.
[08:59] Kallista Arliss (kallista.destiny): Ave Kelly Ave Charlar
[09:01] tehKellz (kelly.linden): Good morning. Hope everyone had a good weekend.
[09:01] Wolfie Fox (wolfie.waves): Yes thanks :)
[09:02] Wolfie Fox (wolfie.waves): Yourself?
[09:02] tehKellz (kelly.linden): Wasn't too bad.
[09:02] Leonel Iceghost: Kelly do you know where I can find a BNF of LSL?
[09:03] Kallista Arliss (kallista.destiny): http://wiki.secondlife.com/wiki/LSL_Portal
[09:03] Kallista Arliss (kallista.destiny): Everything you ever wanted to know, and then some
[09:03] Leonel Iceghost: it is a bit wrong the operators precedance
[09:04] Leonel Iceghost: it the wiki
[09:04] tehKellz (kelly.linden): Really?
[09:04] Leonel Iceghost: yes http://wiki.secondlife.com/wiki/LSL_Operators
[09:05] Leonel Iceghost: || and && should be the same
[09:06] Leonel Iceghost: anyway, do you think is there a proper grammar?
[09:06] tehKellz (kelly.linden): Unfortunately that part of LSL is very frozen. It appears to be documented that they aren't the same
[09:06] tehKellz (kelly.linden): I don't think we have published one, unless it was in the old source.
[09:07] Leonel Iceghost: do you think you could publish it in the future, or it is not something we shall ask?
[09:07] tehKellz (kelly.linden): I don't think there would be harm in publishing what we have, and I suspect it was probably in our very early viewer source releases.
[09:08] tehKellz (kelly.linden): Lets cover what little news I have and then get back to general discussion today.
[09:08] tehKellz (kelly.linden): The estate access list LSL functions are expected to be promoted to release this week.
[09:09] tehKellz (kelly.linden): I'm not sure what is going into RC - nothing new LSL related as far as I'm aware this week.
[09:10] tehKellz (kelly.linden): I'm moving back into server-maintenance this week after a few weeks of helping out other projects.
[09:10] tehKellz (kelly.linden): I did run into an interesting little effect regarding script sleeps, and will be tweaking it in an upcoming release
[09:11] Kallista Arliss (kallista.destiny): Yes?
Total Avatar Scripts - 318
Highest - Kallista Destiny: 80 (25%)
Lowest - Jeremy Duport: 3 (1%)
[09:11] tehKellz (kelly.linden): I was playing with some scripts this weekend and I wanted to set up a basic i/o channel polling a resource. I *know* that resource isn't going to change while the script runs
[09:12] tehKellz (kelly.linden): So a while(not_changed()); seems particularly wasteful
[09:12] tehKellz (kelly.linden): Since it will force the script to run for the full time.
[09:12] Kallista Arliss (kallista.destiny): yeah
[09:12] Kallista Arliss (kallista.destiny): 100%
[09:12] tehKellz (kelly.linden): However if I did the really small sleep - whie(not_changed()) sleep(0.00001); trick the performance dropped in half.
[09:13] tehKellz (kelly.linden): In theory that should let it just check once per sim frame (ie when it might have actually changed)
[09:13] tehKellz (kelly.linden): I dug into the sleep code and found that the way we are doing it will cause a sleep, no matter how small, to skip a frame.
[09:14] Motor Loon: I also though llSleep was kinda of a resource hog?
[09:14] tehKellz (kelly.linden): I'd like a really small sleep to ack as a yield.
[09:14] tehKellz (kelly.linden): llSleep is not a resource hog.
[09:14] Motor Loon: ok, that's good
[09:14] Motor Loon: perhaps it was just a silly rumor
[09:14] tehKellz (kelly.linden): So a super small sleep would say 'I'm done this frame, but I want to continue the next frame'
[09:14] Ash Weststar (ash.qin): Would be nice if llSleep(-1); would just skip a frame as opposed to do any sort of sleep calculation
[09:14] Kallista Arliss (kallista.destiny): Skipping a frame is not good. llSleep should at a minimum 'release the processor for the rest of this frame
[09:15] tehKellz (kelly.linden): (assuming every script gets run every frame)
[09:15] tehKellz (kelly.linden): So .... that is the change I will be making.
[09:15] Kallista Arliss (kallista.destiny): which it should in a non pathological region
[09:15] tehKellz (kelly.linden): I think the general effect will be minimal.
[09:16] Qie (qie.niangao): Difficult to think of even an accidental reliance on the old frame-skipping timing.
[09:16] tehKellz (kelly.linden): But it means that while(llGetObjectDesc() == "") llSleep(0.00001); will be just as fast as while(llGetObjectDesc() == "");
[09:16] tehKellz (kelly.linden): but the former will be much nicer to the simulator / other scripts.
[09:17] Kallista Arliss (kallista.destiny): but will use a lot less processor time
[09:17] Motor Loon: Yep, that'll be useful to remember
[09:17] Leonel Iceghost: so to skip a frame we will need to put 0.22?
[09:18] Ash Weststar (ash.qin): I make use of frame skipping to deal with objects that do llDie(); immediately after doing a regionsay so things like the id in the listen event doesn't rerturn a null key
[09:18] tehKellz (kelly.linden): You will need > 0.022
[09:18] Leonel Iceghost: that
[09:18] Leonel Iceghost: still it was a nice feature
[09:18] Leonel Iceghost: to check positions and stuff that don't change while the frame is the same
[09:19] tehKellz (kelly.linden): It will still skip to the next frame, it just won't skip to the frame after the next.
[09:19] Kallista Arliss (kallista.destiny): hmmmm I wonder if negative llSleep values could be how many frames to skip?
[09:19] Nal (nalates.urriah): So... <0.022 will skip to every other frame now? ?
[09:20] Kallista Arliss (kallista.destiny): is the operation on negative vlaues defined?
[09:20] tehKellz (kelly.linden): Less than 0.022 will probably get you a chance to run again next simulator frame
[09:20] tehKellz (kelly.linden): I don't think it is.
[09:20] Ash Weststar (ash.qin): Is there no chance we could just get a dedicated frame skip function?
[09:20] Motor Loon: so llSleep(0); has no effect?
[09:21] draconis.neurocam (draconis.neurocam): im guessing the limit for the sleep change wont take into consideration the current performance of the sim, as in what if the sim is normally running with lower fps than usual
[09:21] tehKellz (kelly.linden): llSleep(0) has no effect.
[09:21] Kallista Arliss (kallista.destiny): llSkip(integer frames_to_skip);
[09:21] Motor Loon: seems overkill Kallista
[09:22] Leonel Iceghost: I'm sure some content use 0.0001 as a feature, they will sudently use a lot more cpu
[09:22] Kallista Arliss (kallista.destiny): Dies it at least give up the processor for this frame?
[09:22] tehKellz (kelly.linden): This change will basically just make sleeps more accurate: right now if you sleep the script will continue running the frame *after* it is determined the sleep is over.
[09:22] tehKellz (kelly.linden): Not significantly Leonel, but I will be testing that. If you have some examples besides what I have stated please let me know.
[09:23] Kallista Arliss (kallista.destiny): Good find though
[09:23] tehKellz (kelly.linden): Yes, llSleep will still give up the cpu for this frame.
[09:23] Kallista Arliss (kallista.destiny): no llSleep(0.) does it give up the frame.
[09:23] Leonel Iceghost: old content before llSetMotion uses that for rotations and vectors.. other than that I can't thing something else
[09:24] tehKellz (kelly.linden): let me check kallista
[09:24] Ash Weststar (ash.qin): I think a dedicated frame skip function be good for those of us that end up having to trap things in loops or to work around odd behaviours in LSL
[09:25] tehKellz (kelly.linden): I don't think llSleep(0) gives up the frame
[09:25] Motor Loon: Oh Kelly, what would you consider the least "proper" llSetTimerEvent() value?
[09:25] tehKellz (kelly.linden): What do you mean?
[09:26] Squirrely Wrath (squirrel.wood): 0.05
[09:26] Motor Loon: from a resource standpoint..... any value thats so small it'd not do as intended anyway, or use more resources than we "should" ..
[09:27] Motor Loon: I've used llSetTimerEvent(0.001); before thinking it was less agressive than such a while() method you mentioned earlier...
[09:27] Ash Weststar (ash.qin): Can llSetTimerEvent() even be executed multiple times in a single frame?
[09:28] tehKellz (kelly.linden): Ash - yes.
[09:28] Kallista Arliss (kallista.destiny): Ahhhhhh
[09:28] Leonel Iceghost: what? isn't the minimum capped at 0.04?
[09:28] tehKellz (kelly.linden): Motor: Yes, llSetTimerEvent(0.001) is less aggressive than while(). Anything less than ~0.02 is the same
[09:29] Motor Loon: ok
[09:29] tehKellz (kelly.linden): Leonel: minimum what?
[09:29] Motor Loon: minimum rate at which timer() will be run...
[09:30] Leonel Iceghost: I thought llSetTimerEvent(0.001) works at is 0.04
[09:30] tehKellz (kelly.linden): It probably has a similar check to sleep - a 2 frame minimum or 0.045s
[09:31] tehKellz (kelly.linden): I'm a little more hesitant to play with that one as fast-as-you-can timers are more common than really low sleeps.
[09:31] Leonel Iceghost: isn't there maximum 25 script events per second?
[09:32] Leonel Iceghost: that is why I thought llSetTimerEvent less than 0.04 had no effect
[09:32] tehKellz (kelly.linden): I think there is a maximum of ~45 or 1 per frame, but I'd have to verify that.
[09:33] Xentha Contepomi (questar.utu): Is that events like touch_start or functions like llGetPos?
[09:33] tehKellz (kelly.linden): events like touch_start
[09:33] Xentha Contepomi (questar.utu): Do functions have a particular limit?
[09:33] tehKellz (kelly.linden): No
[09:33] Xentha Contepomi (questar.utu): Ah.
[09:33] Jeremy Duport: There's a maximum number of timer events a single script can have per second, but that's directly because of the minimum value enforced on timers rather than because of an event cap.
[09:34] Motor Loon: so the real difference is that while() would block any events from happening while it loops, and timer() would allow them?
[09:34] Ash Weststar (ash.qin): That and while is far more intensive if there is no sleep.
[09:35] Motor Loon: with sleep ofcourse, and at same rates
[09:35] tehKellz (kelly.linden): There is no explicit limit on timer rate.
[09:35] Jeremy Duport: :o
[09:35] Object: Hello, Avatar!
[09:35] Object: Hello, Avatar!
[09:37] tehKellz (kelly.linden): There is no explicit limit on number of timer events a single script can have per second. I'm sure there is an implicit limit.
[09:38] tehKellz (kelly.linden): The "0.04s" makes me think it is a similar off-by-one issue as sleeps - otherwise it would be 0.02s
[09:38] Leonel Iceghost: testing gives 22 scripts events with timer at 0.00001
[09:40] Jeremy Duport: [09:39] Object: 4.468671 101 22.601800e/s
[09:40] Object: 4.466899 101 22.610770e/s
[09:40] Object: 4.468441 101 22.602960e/s
[09:40] Squirrely Wrath (squirrel.wood): the limit is that a timer running at 0.04 requires you to use only few lines of code. Essentially not more than can be handled within the time. Otherwise things will be slower :)
[09:40] tehKellz (kelly.linden): Hrm. Okay we won't queue a timer event if you are in a timer event or have one pending. I think this leads to a cycle of one frame add, next frame run, next frame add.
[09:40] Squirrely Wrath (squirrel.wood): Like, using commands that force a script to sleep for a certain time
[09:42] Leonel Iceghost: kelly it would be great to have a new timer event that works 45 times per second.. there are very difficult workarounds for testing things every frame that could be fixed
[09:42] Object: Hello, Avatar!
[09:42] ?????-----o-----????? (imaze.rhiano): where in testing you need timers?
[09:43] Leonel Iceghost: to check the pos of something in a game, that moves 15m/s its like 0.75m.. for a game it is a lot.. the workaround is a while and modify the desc of the object to comunicate with other scripts
[09:43] tehKellz (kelly.linden): With the sleep change an llSleep(0.001) will let you run every frame. It will be just as performant as an every-frame timer would be.
[09:44] tehKellz (kelly.linden): I'm managed to use nearly 3/4 of the time with this. Much more than I expected, but the discussion is very good. Before we run out of time - are there any other hot topics or general issues to discuss?
[09:45] Jeremy Duport: My coffee is cold :(
[09:45] tehKellz (kelly.linden): You need a better mug! Mine is still warm and I made it at 7:15 this morning.
[09:46] Kallista Arliss (kallista.destiny): Loading scripts from objects that you don't own.
[09:46] Motor Loon: ooh I need a mug like that
[09:46] Kallista Arliss (kallista.destiny): as opposed to requiring that you own the prime
[09:46] Jeremy Duport: ... Huh. I -do- need a mug like that.
[09:46] tehKellz (kelly.linden): What do you mean Kallista?
[09:46] tehKellz (kelly.linden): Ah for llRemoteLoadScriptPin?
[09:47] Kallista Arliss (kallista.destiny): currently to yuse the load script call you hve to own the prime that is th source of the script.
[09:47] Kallista Arliss (kallista.destiny): Yeah
[09:47] Kallista Arliss (kallista.destiny): it turns out that it would be really really useful to have a single prim with the scripts in a region that everyone could load from
[09:48] Jeremy Duport: Is that in reference to editing scripts in other user's objects with the viewer, or specifically loading scripts via other scripts?
[09:48] tehKellz (kelly.linden): It would require a new system - a single integer isn't enough to prevent brute force attacks, especially when they could be happening just wherever you are
[09:48] Kallista Arliss (kallista.destiny): The publishing of the pin and name should be sufficient
[09:48] Leonel Iceghost: Kelly checking the creator would be nice
[09:48] Ash Weststar (ash.qin): Generate a UUID on the fly
[09:49] Ash Weststar (ash.qin): Would be pretty tough to bruteforce
[09:49] Kallista Arliss (kallista.destiny): Well that would be a different call
[09:49] tehKellz (kelly.linden): Yes, a UUID would be much harder to brute force.
[09:49] Kallista Arliss (kallista.destiny): llRemoteLoadScriptUUID()
[09:49] Motor Loon: Hournest it sounds kinda scary
[09:49] Qie (qie.niangao): But still, one would want to force an explicit permissions query, I think.
[09:49] Motor Loon: oh yes
[09:50] Kallista Arliss (kallista.destiny): No because the owrn of the deliverying prime would not be the creator of the cripts
[09:50] Wolfie Fox (wolfie.waves): Is there any news on llSetMemoryLimit?
[09:50] Kallista Arliss (kallista.destiny): but the
[09:51] tehKellz (kelly.linden): Wolfie: What word are you looking for? That function is available now.
[09:51] Motor Loon: is there a problem with setmemorylimit ?
[09:51] Xentha Contepomi (questar.utu): I use it in a few of my scripts and it works fine. :o
[09:51] Wolfie Fox (wolfie.waves): As I remember it was broken where it would not persist when region crossing
[09:51] Xentha Contepomi (questar.utu): That was fixed weeks ago.
[09:51] tehKellz (kelly.linden): Yes, that should be fixed.
[09:51] Motor Loon: oh thank god... I've been using that alot too
[09:51] Wolfie Fox (wolfie.waves): Oh, guess no one told me about it :(
[09:52] Xentha Contepomi (questar.utu): Y' probably never asked. :p
[09:52] Leonel Iceghost: any notice of those plans for using it for more than 64k?
[09:52] Qie (qie.niangao): Oh, speaking of llSetMemoryLimit()... just to confirm, this really has no beneficial effect for the sim, right? It just helps us "promise" others about what our scripts use -- the sims can't actually do anything with that to save on garbage collection or anything, right?
[09:53] tehKellz (kelly.linden): Not right now Leonel.
[09:53] Jeremy Duport: It's not a feature I've really used much, but is XML-RPC safe to use? There's still a note on the wiki that says it's sort of deprecated, and a blog post of yours (Kelly) from 2009 saying that it was being worked on at least in some capacity.
[09:53] tehKellz (kelly.linden): Correct Qie. Except your script will crash if it goes past it.
[09:53] Qie (qie.niangao): right. thanks.
[09:53] Motor Loon: sorry what?
[09:53] Motor Loon: setting the limit wont actually make the script use less memory on the server?
[09:53] Xentha Contepomi (questar.utu): I use it for scripts that use less than 16kb while on Mono. That way it uses less than an LSO script. :3
[09:53] tehKellz (kelly.linden): It works as good now as it ever will and I have no announcements to make about really deprecating it Jeremy.
[09:54] tehKellz (kelly.linden): Xentha: yes, that is the intent.
[09:54] Jeremy Duport: Okay! :D
[09:54] Leonel Iceghost: it can use more resourses if it hits the garbage collector actually
[09:54] Leonel Iceghost: I guess..
[09:54] Motor Loon: are you kidding me?
[09:55] Xentha Contepomi (questar.utu): So long as you get yourself a reliable reading of how much memory the script is likely to use, and give it a little extra, it shouldn't go past the limit / crash / revert.
[09:55] Jeremy Duport: Oh, I know. I've used xml-rpc for one project, something like four years ago. I was just interested.
[09:56] tehKellz (kelly.linden): Right. Motor: Mono scripts use only the memory they need, unlike LSL which always uses a fixed 16k. The 'limit' is the promised cieling.
[09:56] Motor Loon: so basically using setmemorylimit is a waste of time...
[09:56] Motor Loon: I heard mono reserved the full amount of memory on the server
[09:56] tehKellz (kelly.linden): That is not the case.
[09:57] Koli Contepomi (sahkolihaa.contepomi): Mono is dynamic in terms of memory usage.
[09:57] Jeremy Duport: setmemorylimit affects the value returned by the getobjectdetails OBJECT_SCRIPT_MEMORY flag, yes?
[09:57] Motor Loon: hm.. I thought "they" never got that working and it just reserved the full amount anyway... damn..
[09:57] tehKellz (kelly.linden): Correct Jeremy
[09:58] Xentha Contepomi (questar.utu): That's LSO/LSL scripts that reserve their full amount, Motor.
[09:58] Jeremy Duport: Then it has psychological worth. :)
[09:58] tehKellz (kelly.linden): Motor: No, mono memory use has always been dynamic.
[09:58] tehKellz (kelly.linden): Correct Jeremy.
[09:58] Motor Loon: okies... I'll just use mono and stop worrying about memorylimit then
[09:59] Motor Loon: that actually saves alot of time on my end
[09:59] Leonel Iceghost: it will be a concern when they implement per avatar limits or like that
[09:59] tehKellz (kelly.linden): Also, when/if we move forward with memory pooling and memory limits the reported cieling for mono scripts is what will be used in the accounting - same as the reporting now.
[09:59] Motor Loon: I was running profilers and crap in my stuff to find memory use and setting the limits to use the least possible resources...
[09:59] Motor Loon: pointless then
[10:00] Kallista Arliss (kallista.destiny): Actually setting the memory limit keeps the script nazis (much like ARC nazis) from getting on your customers case.
[10:00] Koli Contepomi (sahkolihaa.contepomi): ^
[10:00] Jeremy Duport: Exactly. :D
[10:00] Koli Contepomi (sahkolihaa.contepomi): That's why I use it.
[10:00] Nal (nalates.urriah): Any odds on whether LL will move to meory limits or just stay with Land Impact to limit it?
[10:00] Motor Loon: well, true
[10:00] Turn off display names scrub. (wolfgang.senizen): but but ARC means soooo much
[10:00] Kallista Arliss (kallista.destiny): So it is a worthwhile effort
[10:00] tehKellz (kelly.linden): And it is 10!
[10:00] tehKellz (kelly.linden): Thank you everyone for coming out.
[10:00] Motor Loon: but if it wont make my simcrossing faster... there's not much point for my point of view
[10:01] tehKellz (kelly.linden): Good discussion today.