Acheron Gloom

Without the LL viewer we wouldn't have third party viewers... If only I could rate posts 'dumb'...

Pretty unrelated to the original thread, but oh well... I personally think viewer 2 is great once you get used to the UI changes, and It hink that the code-base itself is much better than the v1 code base, just I prefer firestorm/phoenix for the features that the linden lab viewers don't have. Considering that third party viewers are always based around the LL viewers, I kind of see the LL viewer like a factory stock engine or car without the little accesories and add ons, but still a vital part of viewer development as all the core parts come from it, and without it we wouldn't even have the TPVs.

Rolig Loon wrote: Begin by spending some time with the tutorials at https://wiki.secondlife.com/wiki/LSL_Tutorial . Most of us were able to get started that way with no further help. It is smart to get hold of free scripts and start taking them apart to see what makes them tick. Modify the heck out of them. And make heavy use of the LSL wiki and its embedded examples. If you still need a jump start after all of that, check your Search function in world to look for Events >> Educational to see what scripting classes are being offered this week. Builder's Brewery usually has some, and so does NCI. That and choosing something you want to try to make are both some of the best posts. I learned actually by purely choosing to script something I liked (a gun) and using the wiki to do just that. Actually, a gun is a pretty good thing to script since it can teach cross-script communication, agent-script communication, rezzing objects, rotations and positions, control event, etc. Then you also have the popgun and plenty of gun scripts for free online to help start, and its something that is tangible and you can actually /play/ with, so its fun to make!

Impressive. I'm curious what these fixes were?

It would probably count as a non-commercial fair-use item, purely for research. I'm sure Roxie has no intention of selling it, or even using it for anything other than purely testing. However I'm not a lawyer, so thats really my uneducated opinion.

Doing what Lexie suggested is probably the best idea. Nothing similar has happened to me since the updates, and I highly doubt a server update would do something like that to only a single viewer (your own), then again perhaps it was something about being logged out during the server updates.

Instant message has a two second delay and you can't talk to objects. Instant message can IM agents outside of the sim, llRegionSayTo cannot. llRegionSayTo can be higher performance as you can target specific objects/agents instead of having every single object int he sim hear your message. This would be useful for things like combat systems. I am unsure if llRegionSayTo is any better on the sim when used in similar ways to llRegionSay and only one listening object.

Void Singer wrote: Binary trees don't begin to really shine until you get over 4 items, at which point they surpass all the others for roughly equal likelihood paths. they get more efficient the larger they get, only adding one test processed for each power of two more options. largest code size, smallest test waste (none). Except you have to run the list function which also gets proportionally slower as the list gets longer, and as I said I did test a straight set of if/else-ifs versus a list, and I think it was around a 16 command long list, and the straght if/else-ifs were faster. And yes I did use a binary tree.

The latest Mono2-Perf release notes stated that the removal bug would be fixed as well. Also the quote I added in my post is from Kelly saying that Mono will be better on region entry/exit than LSL. As I said before though, I'm still crossing my fingers.

Are you sure its much faster? I've done tests before and its usually slower, I've found, and then since you're using trees + the list stuff it takes up even more memory. However, it can take up less memory if the list is a local list since local lists take up less memory per character than local strings.

Thats true.

It probably wouldn't be too noticable, I think. One thing though is that... you could probably cut down on those 38 prims by using various functions like llDetectedTouchST, llDetectedTouchFace, llSetTextureAnim, llSetLinkTextureAnim, llSetLinkPrimitiveParamsFast, and clever texturing. Anyway, it probably be too noticable, especially if you're using Mono which would run quite a bit faster. I did a quick test and mono can run this line: llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_TEXT,"TESTETSET",<llFrand(1.0),0.0,0.0>,1.0]); about 1,000 times per second.

Well, for one, a simple function barely is anything for the server to calculate. Events are actually a bit more script time, and operations, than just running a function or two. By that I mean you could just use a quick touch_start event and it'd be much more efficient for the sim. Second is that Mono, right now, does dynamically allocate memory. "Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. LSL2 allocates a full 16KB for all scripts, even simple "Hello, Avatar" ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes." That means that a very short script like this would only take 1,000 bytes of memory in Mono, but in LSL it would take 16,384. Third is that the mono rezzing in/out bug is being fixed quite soon, and Kelly has said: [16:06:10] Kelly Linden: mono will be better on sim performance. Though, yes, I am crossing my fingers Fourth is that if you use the script multiple times on multiple pieces of clothing, Mono has bytecode sharing: "Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script's size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory."

Kind of. Something like this may work for you, but if you give me more info about the application Ic ould probably help more: rotation rDefault;rotation rTwo = <-0.000, 1.00000, 0.00000, 0.000>;SmoothRotate3(rotation One,rotation Two){ rotation Temp = Two / One; vector DTemp = llRot2Axis(Temp); float Speed = 15.0;float Dist = llAngleBetween(One,Two) * RAD_TO_DEG; llTargetOmega(DTemp,Speed * DEG_TO_RAD,1.0); llSleep( (Dist / Speed) ); llTargetOmega(<0,0,0>,1.0,1.0); llSetRot(Two);}default{ state_entry() { rDefault = llGetRot(); SmoothRotate3(rDefault,rTwo); llSleep(2.0); state two; }}state two{ state_entry() { SmoothRotate3(rTwo,rDefault); llSleep(2.0); state default; }}

Thats a surprise to me ;o. Does it do that for all permissions? And when would they dissapear? Could be slightly useful for me since almost everything I make uses permissions, and I always request on attach, when I can just request once on state_entry (due to the way my scripts work). I still think, however, that even having the attach event in the first place would be overall less efficient than only a touch event, since the event activating for attach/detach is much more to do than a quick and simple function, and it would take up more memory/bytecode. And if you're running in mono, the additional memory makes a difference (since mono dynamically allocates and LSL doesn't).

Innula Zenovka wrote: But there's no need to keep on requesting permissions, even though they're granted automatically. They persist, after all, so just asking for them when you attach the object (or even checking, when you attach the object, and asking for them if you haven't got them) would be sufficient. Having said that, I'd always -- as a safety measure -- check I've got the right permissions before actually doing anything, and request them if I haven't got them. Whenever I don't bother, someone always finds a way to lose the permissions, thus breaking things. No, because permissions DO NOT persist after detach, so you do need to ask every single time, and it uses less memory, less bytecode, and less overall operations to use a single event rather than also throw in an attach event. The only way it would break is if it wasn't attached to the avatar, in which case you wouldn't expect it to work anyway... and if you want to add in error checking for that you would just do: if(llGetAttached()){ llRequestPermissions(llGetOwner(), PERMISSION_ATTACH); llDetachFromAvatar(); } And you can't lose the permission considering its requesting it miliseconds before detaching, but if you want to be redundant: if(llGetAttached()){ llRequestPermissions(llGetOwner(), PERMISSION_ATTACH); if(llGetPermissions() & PERMISSION_ATTACH){ llDetachFromAvatar(); } }

The attach permission is auto-granted on... attachments. So you wouldn't be bothered by anything, it would just do: llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); llDetachFromAvatar(); and that'd be the end of it.

You can use llDetachFromAvatar. https://wiki.secondlife.com/wiki/LlDetachFromAvatar I can put something together for you if you want, or if you have any knowledge of LSL I'd suggest you try to make it on your own.

Ah, alright thanks. I was just confirming. Thanks again for posting your results.

Great topic, I realy enjoyed reading it, however...  Doesn't that kinda show that theres been a huge increase in lag spikes since the update ? Or was that from you messing around and testing it? I'd assume the latter, since if it was the former you would've made a note. I'm also curious about the collision tolerance setting.

I think everyone is probably jumping to conclusions. I've accidently unchecked the box for multiple friends on numerous occasions, especially since (for me at least) the friends list boxes seem pretty buggy. One time I even did it to my partner D:

I may be able to help, depends on how much the payment is. I don't say this to be greedy, but rather I'm also working on a bunch of other scripts at the moment. Also depends on how much work you actually need done. Contact me in-game as Acheron Gloom if you'd like.

http://wiki.secondlife.com/wiki/LlAllowInventoryDrop AKA default { state_entry() { llAllowInventoryDrop(TRUE); } }

Yep, please stop trying to make things better for us Lindens. It surely must be /you/ causing any issues? Right? Right...?

I don't know many content creators at all who aren't happy about mesh coming. These content creators sure aren't bad content creators either, they're the best I know of, and can make whole items in a single prim in terms of optimization and efficiency. As for textures, their textures are also some of the finest I've seen and using a single hand-made 128x128 texture and some brilliant modeling work they can make the texture look better than a 1024x1024. As for texturing being 90% of the building, I also disagree with that. Texturing is a large part, but not nearly 90%, its more like 50 or 60%. Now if you can find an artist who can make a model like this in only a few sculpties and isn't excited about mesh, then I'd gladly entertain the argument a bit more.