Extrude Ragu

Regarding stuttering: Just because you set a timer event for every 0.05 seconds doesn't mean that's when the timer will run. Better to calculate the elapsed time each timer event by using llGetTime() and llResetTime() and calculate the true rotation needed based on that. It will look smoother and correct for timer inconsistency. You could set timer event to 1/llGetRegionFps() to ensure that each simulation frame of the simulator the rotation is calculated making it as smooth as can be. Regarding seats in car: I would discourage having a separate script in each car as it introduces latency between the movements and requires parsing strings which is not optimal. I recommend instead using llSetLinkPrimitiveParamsFast from the root prim in conjunction with PRIM_ROTATION, to control each car link during every timer event to correct for the rotation of the main wheel.

So you're me, and you make a model that's big, really big. 238meters, by 69 meters by 155 meters big. The maximum size a mesh can be in SL is 64m in any direction. How would you go about breaking up the model into chunks that fit into the bounding box, is there a non-destructive way to do that?

I am curious about the internal nature of how llSleep is handled on LL Servers. Coming from a background in software engineering, usually to 'Sleep' in programming implies blocking the thread, something that is quite undesirable because it causes the system to no longer be able to use that thread to perform other tasks, which is why we usually prefer to turn to a more asynchronous model of programming, preferring events (eg, timers) so as to keep the thread open for other tasks to use. So that got me wondering, is llSleep actually blocking a thread in the server side code whenever it is being called? It would seem that, if this were true, it would make servers vulnerable to being completely thread-blocked. It seems unlikely to me that LL would want people to actually be able to sleep in threads. So I wonder perhaps does llSleep when compiled, actually generate a state machine similar to async/await model in C#?

Oops! seems I misread, my apologies

I don't think it's necessarily just about sexualization although I am sure it is a part of it. Making good looking long skirts in Secondlife is basically impossible due to the fundamentals of how clothes rigging works in Secondlife. Even once you start to approach the knees you are basically signing your creation up for a bunch of clipping or some really weird deformations during movement. There is a low incentive for creators to take the time to make long skirts when they know that 1. They're not going to deform as realistically as short skirts and 2. They won't sell as much. Other games usually get around this issue by either giving their female protagonists pants, or implementing some kind of clothing physics. Which LL could do, but are probably not keen to do due to new technology requirements/software development/testing etc that goes into getting something like that working.

When I started playing SL in like 2008 I set up a headquarters out of prims on I think yumix's land, we had those prim police cars that could fly if you held page up/down at the same time. Went around making a racket and having a blast with a friend for a while like this. Our headquarters was like 12 stories high too, it had one of those scripted elevators that were the fascination of SL at the time. Great times

Hay Bale

I've actually been around on SL since about 2008 but I've never really introduced myself. Some things about me:- I love to create stuff. I run the anime themed roleplay school, Kokoro Academy, which I've been building since 2014! In RL I work as a software engineer, and I can reach >100 Words per minute 🔥 I'm a dude, and I live in London! Best, ~Captain Ai, At your service ( `∀´)ゝ”

Natural Harbor

That the next generation of people won't discover the joys of creating and sharing content and worlds on computers in virtual worlds, instead the height of creative experience becoming sharing meme's on Snapchat or whatever happens to be popular in 2029.

The thing is, if we just made the same prim builds we made out of mesh today, with the same level of detail, the efficiency improvement is 10 fold, as mesh is far more efficient in terms of performance to detail than prims. It's not the technology, it's the economics. Commercial creators are heavily incentivized to cram as much detail as possible, into as low an LI as possible. They do this by 'cheating' the Level of Detail System by supplying a single tri to Medium, Low and Lowest Models(A mesh has different levels of detail based on zoom level) to get lower LI, whilst still having poorly optimized highest model and demanding users set their LoD factor up to max or even changing debug settings in their viewer. With the right economics, mesh is less laggy than Prims Take for example, my simulator, Kokoro Academy. I own the sim, and I create everything in it. I'm not trying to sell the content to anyone, I just want people to enjoy themselves, because of this, it's in my interest to create highly optimized models, proper LoD models, using alpha blending, large textures very sparingly, etc. Users in my sim regularly tell me that they are confused why their computer runs smoother in my sim than another sim that has the same apparent amount of detail. What needs to be done is we need to find a tangible way to incentivize commercially motivated creators to optimize their products. The average consumer generally does not consider efficiency in their purchase, only how good the product looks. Personally I'm not 100% sure what we could do, but I know this is the area that needs solving.

( `∀´)ゝ”

Ok so, scratch my previous thread, offline rez-rights do not appear to be working at all, which is a showstopper for the development of my Experience as it depends on being able to rez HUDs to attach to visitors of the sim along with the rezzing of rooms etc. My JIRA: https://jira.secondlife.com/browse/BUG-10520 llRezObject Wiki: http://wiki.secondlife.com/wiki/LlRezObject Following the LSL Wiki closely, I deeded my land to my group (of which I created/remain in owner role), and deeded my object rezzer also to the group. The rezzer is not only deeded to my group but it's group is also set to my group. In my land settings, I have tried both setting to 'Everyone' and 'Group' - Neither work. The script is set to Mono and using my Experience also.. Please can someone investigate this, this is a huge showstopper!!

Ok, I finally got this working, here's what I did incase it helps someone else: ❤ As Rolig Suggested: - - ❤ Set the Rezzer Object to be Shared to the group - - ❤ Set the Script inside the Rezzer Object to Shared to group - - ❤ Additionally, I set the object to be rezzed (the HUD) inside the rezzer, to shared to group ❤ I also had a big GOTCHA :- - - ❤ In my script, inside the attach() event I was calling through to llRequestExperiencePermissions - - ❤ Inside ExperiencePermissionsDenied event, I was calling through to llDie() after llDetachFromAvatar() - - ❤ attach() event was being called onRez, even though not attached, and ofcourse object llDie's silently ❤ To fix my GOTCHA :- - - ❤ Inside attach(key id) event, I put my call to llRequestExperiencePermissions to be inside if(id) { . . . }

Hello, I ,encountered a sneaky limitation that I was unaware of the other day, and I'm wondering if anyone can advise me how to work around this problem; My Experience has a central prim that rezzes HUD's that attach to the user - This works fine, except, I found out, it doesn't, when I'm offline. When I'm offline, apparently this fails, with no trace of failure for me to see other than someone asking me why nothing happened (This is pretty bad) - So I read into llRezObjects and found out about 'offline rez rights' Here's the thing about my object - It's in land I own, it's in the group I own which is also the group for the land, it should be able to rez, right? My land is set to group can rez also. But apparently, it can't. I tried making a copy of the object, and deeding the object to my group, however, I then lost edit rights to my own script, even though the group I deeded the object to is mine, the object is created by me.. I mean, I'm totally bewildered how I am supposed to work with these permissions. Has anyone sussed out the secret sauce for getting this to work? The documentation clearly has some weak spots in this regard

I'm building an anime themed school that doubles up as a place to roleplay and learn together. One of the more interesting ways I've thought about using KVP's, is to aid learning at the school through the use of KVP operated books. Teachers would be able to 'write' to books by putting an image on each page and the book stores it's name, how many pages its got, and the uuid for the texture of each page in KVP's These books could be distributed to students and would load their contents through KVP, enabling the editing of books by the author post-distribution (without having to send out new books) and also allow for collaboration if multiple authors want to edit the same book.

Hello I searched around but I was unable to find any information related to the limitations of Key-Value Pair storage? I want to know what limits there are (in terms of how much data my Experience can store), and if there are things I am not allowed to track with KVP's Example: I could using KVP's store a users point-score in a game, or perhaps a HUD-position preferrence For example KEY = avKey + "|pointscore" VALUE = 10 However If there was a data-storage limit and my experience hit it, I wouldn't be able to delete those key-value pairs because I do not know the key of every Avatar that has entered my Experience, and thus the only way to get around the problem at that point would be to delete the entire experience (very bad) So.. Is there a limit? Can the limit be expanded if needed? Kind regards

Hi There. I am working with a kinda lousy sliding door script I want to improve. See, the door when opens, it moves in a set direction. What I want to do is change this so that the door moves relative to it's current orientation, without having to change the script every time I reorientate the door to face another way. The current script if you want to see. The door is controlled by an external command on channel 6789 that says 'door'; float NorthSouth =1.0; //Positive = move east, negative = move west float EastWest =0.0; //Positive = move up, negative = move down float UpDown = 0.0; //The amount in seconds to stay open, set to 0 to not autoclose float Timer = 15.0; //Sound to play on open, either a UUID or a name in the door contents //if a name, it must be exact. Leave at "" for no sound string OpenSound = "50dceba2-cb07-6577-1fd7-ca288abdf921"; //Volume to play open sound, 0.0 is same as no sound, 1.0 is max float OpenVol = 1.0; //Sound to play on close, either a UUID or a name in the door contents //if a name, it must be exact. Leave at "" for no sound string CloseSound = "50dceba2-cb07-6577-1fd7-ca288abdf921"; //Volume to play close sound, 0.0 is same as no sound, 1.0 is max float CloseVol = 1.0; //misc variables vector Pos; vector Offset; integer Open; integer x; default { state_entry() { Offset = <EastWest, NorthSouth, UpDown>; llListen(6789, "", NULL_KEY, "" ); } on_rez(integer num) { } listen(integer number, string name, key id, string message) { if (message == "Door") { Pos = llGetLocalPos(); if(OpenSound != "") llTriggerSound(OpenSound, OpenVol); llSetPos(Pos + Offset); state open; } } } state open { state_entry() { llListen(6789, "", NULL_KEY, "" ); } on_rez(integer num) { } listen(integer number, string name, key id, string message) { if (message == "Door") { if(CloseSound != "") llTriggerSound(CloseSound, CloseVol); llSetPos(Pos); state default; } } }

Hi There. I am working with a kinda lousy sliding door script I want to improve. See, the door when opens, it moves in a set direction. What I want to do is change this so that the door moves relative to it's current orientation, without having to change the script every time I reorientate the door to face another way. The current script if you want to see. The door is controlled by an external command on channel 6789 that says 'door'; float NorthSouth =1.0; //Positive = move east, negative = move west float EastWest =0.0; //Positive = move up, negative = move down float UpDown = 0.0; //The amount in seconds to stay open, set to 0 to not autoclose float Timer = 15.0; //Sound to play on open, either a UUID or a name in the door contents //if a name, it must be exact. Leave at "" for no sound string OpenSound = "50dceba2-cb07-6577-1fd7-ca288abdf921"; //Volume to play open sound, 0.0 is same as no sound, 1.0 is max float OpenVol = 1.0; //Sound to play on close, either a UUID or a name in the door contents //if a name, it must be exact. Leave at "" for no sound string CloseSound = "50dceba2-cb07-6577-1fd7-ca288abdf921"; //Volume to play close sound, 0.0 is same as no sound, 1.0 is max float CloseVol = 1.0; //misc variables vector Pos; vector Offset; integer Open; integer x; default { state_entry() { Offset = <EastWest, NorthSouth, UpDown>; llListen(6789, "", NULL_KEY, "" ); } on_rez(integer num) { } listen(integer number, string name, key id, string message) { if (message == "Door") { Pos = llGetLocalPos(); if(OpenSound != "") llTriggerSound(OpenSound, OpenVol); llSetPos(Pos + Offset); state open; } } } state open { state_entry() { llListen(6789, "", NULL_KEY, "" ); } on_rez(integer num) { } listen(integer number, string name, key id, string message) { if (message == "Door") { if(CloseSound != "") llTriggerSound(CloseSound, CloseVol); llSetPos(Pos); state default; } } }

Perrie Juran wrote: Extrude Ragu wrote: What makes you so privileged just because you are flying? The linden labs parcel banlines only extend up to 100M above the ground because the lindens clearly wanted people to be able to explore, that is how I see it. They made banlines visible so that people knew where not to go. That is why I feel I should be priveleged about flying, and security orbs are used as a way to take away that privelege by not warning me, and stopping me from flying in places I should be allowed to fly. The lindens gave people the power to use scripts to eject people to detect and remove griefers remotely, but I do not feel the lindens gave people the power to use scripts to eject people just because they flew over their home. If the lindens had thought that people should not be allowed to fly over their homes, banlines would have extended up all 4000m, but instead the lindens restricted it to 100. That is why I feel I should be priveledged as a flyer, and I'm not talking airvehicles but the same should apply to airvehicles too as it is just another way of transportation. On the ground in SecondLife is clearly treated as a different manner, vehicles and people should in my opinion have clear ways to identify where they can and can't go. Currently it is a minefield and totally discourages community as you are scared away from exploring and meeting new people. There are no walkways between homes, it becomes like a 'great wall', except, there is no wall. You can't see it. There's no warning. It is a scary minefield. Dare you to explore second life and risk getting sent thousands of miles back to your home just for stepping into invisible zero second warning auto-eject territory?

as long as those that would send you Home give you fair warning, you have no cause for complaint whatsoever. But they DON'T give you fair warning, that is my issue here, they DON'T. 0 Second Warning Auto-Eject scripts are a thing that exist and cause grief and are actively used, if you have taken the time to explore the mainland for more than 10 minutes I gauruntee you you will be very, very aware of this. Phil Deakins wrote: If all the parcels around my land set up ban lines, then yes I'd moan. I believe that LL would act on it too. A land owner has a right to go to his/her land on the ground. >>>Then you should be moaning right now, because everyone around you has the right to set up a banline, it could happen to you at any second, and LL would NOT act on it, because they have made it so that people are allowed to do something, that takes away your rights, and I think it is wrong.<<<

Second life gives users the ability to build at any height and I am fine with that, you are missing the point; People should not be allowed to automatically and instantly eject people for flying around in the mainland! It spoils the experience, in my opinion, why make the mainland a connected land when traversing it is like a minefield? I am of the opinion that work should be put in to prevent people abusing the mainland for what it's not, and move these skybox owners who demand privacy to private sims, the mainland was not built with the idea that skybox owners would prevent people from traversing and that the ground would be left barron and bare. The mainland was built with community in mind and I personally think that work should be put in to restore that original idea. I am, and this is my strongest opinion, that will definately hit a few people hard, of the opinion that skybox owners who want security devices and for nobody to ever come near their land, be forced to be moved to private sims, where nobody will ever come near their land (sky) I think the mainland should not be treated like a wild west, it should be a pleasant place to explore, a community. Griefers are the minority, not the majority. I think if you want the right to insta-eject people with no warning, you should be moved to somewhere where that does not interfere with my right to explore and be involved in the community.

The thing is, Pamela, is that what I fly into, often does not look private. It is an open space, there are no visual ques. Pamela, You are right, private land is private land.I would never intrude on someones property like that. A locked door is a locked door and it's inexcusable to break through it. But the mainland is a different nature, it was designed to be explored. There are often no visual cues, and as you said, the Lindens don't respond to AR's. But, you are also wrong, Private land is not private land, until it is clearly marked as so, and also, private land is Land, not Private Air.For example, when I brought my house in the real world, I didn't buy the right to stop harry in his piper club from flying over, or John in his Jet. When I brought my home in the real world I also didn't buy the right to vaporize my neighbour when he stepped onto my drive with no warning, or to detain some guy who tripped and stepped foot in my drive, and because he so much as touched my land, drive him all the way back to his home in Alaska. You know? It's rediculous that there is no warning, and that you are teleported so far away. It is nasty and really sets a bad tone in second life. When you buy a house in the middle of a street you should expect people to walk past, this is what mainland owners seem to forget, they brought a parcel to develop on, where they have the right to ask people to leave, but they don't have the right to disturb everyone around them unnessacarily just for passing by, they should get off their high horse.

I'll warn you now that this is my opinion, it is very strong and opinionated, you might even take it offensively, if you are easily offended, I suggest you click back. The SecondLife world is supposed to be an exciting place to explore, and feel free to do whatever you want right? Within reason, ofcourse. I personally beleive that automatic ejection systems ruin that. Do you know how it feels to fly over the mainland, and even though you're 200m up, not near anybodies home, in a zone where banlines shouldn't effect you, someone's orb decides to kick you out, and teleport you miles away to your home? When somebody who owns a parcel with a small insignificant house on the mainland thinks that nobody should pass over it? not even at 4000m, nowhere near it? With a 0 second warning, often there is nobody even in the house! I'll tell you how it feels to be ejected and sent miles back home for no good reason, it feels Infuriating. Like, seriously infuriating! I beleive that automatic ejection shouldn't be allowed on the mainland, above the banline zone, it just shouldn't. The mainland is SUPPOSED to be joined together, when you buy the mainland, you sign up to become a part of the surroundings, not to take your part and use it as a solid avatar wall designed to simply infuriate people wanting to pass by as they explore. I beleive that automatic ejection encourages people to be Selfish, and removes the feeling of community in second life. What you end up is with this wild west feeling, where you think that everybody around you is introverted, and has this massive metal pipe jammed within their rear hind, because they seem to be so stuck in an upright position that the thought that somebody flying over their home at any given time is worth stopping them, kicking them out, and deporting them thousands of miles away back to their own home, I mean heaven forbid we behave like human beings and have a conversation, right? I beleive that if people truly wanted privacy, and to not be included in the mainland community, they should not be allowed to be on the mainland where they ruin it for everyone else, they should be buying houses on private sims designed for privacy, not the mainland! This is just my view, take and discuss as you will.