Yingzi Xue

A quick side note along the lines of this subject. I have an elevator script-set that I developed from 2008 to 2012. At one point a customer asked me to bypass the 64m limit, which I did. When dealing with horizontal movement, the method works fine (I did the same as you). When dealing with vertical movement, up works fine as well, but down does not. What I found was that when a physical object is moving down from a given height, gravity and acceleration combine to cause the physical object to free-fall, not move in a controllable manner. My customer made a space needle elevator. The way up worked fine, but the way down was a ride of death. LOL Anyone attempting to bypass the 64m limit should keep in mind, the greater the distance between current position and destination position, the faster the object moves to get there. This can be mitigated somewhat with the tau setting but not completely. Free-fall occurs when distance is so great that the object breaks free from control and just falls like a rock. One other tidbit... if you are particular about the object jittering when sitting at its destination, just toggle physical off. I also like to use a jump-to range of a fraction of a meter; if the object gets within that range of the destination, it goes non-physical and llSetPos, this making for a smooth stop and eliminating jitter at the end.

There are a few instances where multiple scripts would be beneficial... If you have plans for your script to grow over time; additional functionality/features. Ease of support; separating code into smaller pieces makes editing it easier, especially if you have long-term products that grow over time. Functionality that pauses the main script, like e-mail and instant message. Compartmentalization/modulization of functionality, so that a script can be added or taken away for additional features. The down side of multiple scripts is that each container (either 16k or 64k) also takes up a bit of memory on top of its container size. Yes, it's small, but it adds up. Keep in mind, 16k containers take full 16k no matter the size of your script. 64k containers scale according to the actual memory used in the container. In 2008, I noticed some popular vendor objects had upwards of 10 scripts in them. Multiply that by 100 vendor objects and you have 1000 scripts in a region. 10 scripts in any object is insane and overkill. In a few of my own products, many of which have been long lasting and have grown over the years, I've had to offload functionality to a slave script just to be able to fit everything. I even moved the notecard reader to a separate script to free up some more memory in the main. Rarely do I use more than one script, only if necessary. When a project gets so big that you have no choice then there's nothing you can do but offload to a second script. What I've learned is that if you're designing a project and you know it's going to be big, the best bet is multiple scripts and compartmentalization. It makes it much easier to come back to after a year or two of not looking at the code. That said, if your project is way less than 64k, there's really no reason for multiple scripts (excluding the need for scripts in child prims, of course... but use link functions when available to prevent the need for child prim scripts). As for sim crossings... the more scripts a sim has to poll, the more lag, which will vary depending on script efficiency in the sim you're arriving and various other factors.

llGetSunDirection(); will return a vector of x, y and z. All you're concerned about is whether the sun is above or below the horizon and to what degree. You'll want to set up a timer. I suggest 60 seconds, which will make it accurate to a minute. default{ state_entry() { // Add this to your state_entry() event so it starts a timer when // your script starts. The timer immediately starts counting to // 60 seconds. After 60 seconds the timer event (below) triggers. // The timer continues to count 60 seconds indefinitely and // trigger the timer event unless you llSetTimerEvent(0); llSetTimerEvent(60); } // Timer event which triggers after counting every x seconds. timer() { // Use a local vector since we don't care to store the sun's // direction. Once the timer event runs the memory used by the // temp vector is emptied. vector temp = llGetSunDirection(); // Get sun direction x, y, z // Check z, which is sun's vertical position; 0 = at horizon. // If you want you can get fancy and add more if statements to // open door gradually as sun moves but you will have to have a // faster timer because the sun moves quicker than 60 seconds // per tick. if (temp.z < 0) { // Less than zero means sun is below horizon. // Add code here to open window. } else { // Greater than zero means sun is above horizon. // Add code here to close window. } }}

**UPDATE** After much struggle with my current method (namely the second snippet above), there's no way to make it work because you're trying to combine data from multiple sources and make a position and rotation. It works if you are using the right rotation to begin with, but start moving prims around and the rotations get all out of whack. The solution is to restrict rotation based on the rezzer and use positional offsets while keeping rotation of the rezzed prims intact.

That wouldn't work for what I am trying to do. I've almost got it licked, I can move my master prim (not the rezzer) and the other prims move in kind, but when I do a rotation the other prims get off by a bit, especially if I send an updated pos/rot when my master prim is at an angle and not straight with an axis. It goes very wrong from there, but I'm close to getting it.

I am working on a symmetrical rezzer. The base object rezzes prims around it in a circle. The objects move with the rezzer when I move it, as per design. I want to be able to move one of the rezzed objects and have the other objects move the same way, but in relation to their own rotation and that of the rezzer prim. If I move the object closer to the rezzer, all objects should move closer to the rezzer. If I rotate the object all other objects should rotate in kind but in relation to the rezzer so that all objects stay in a symmetrical pattern around the rezzer. I have tried getting the offset of the distance between the moved object and the rezzer, then applying that to the other objects vs the rezzer object position, then applying each object's rotation and that of the moved object. Every combination I've tried fails to get the desired results. The moved object's position and rotation are key, so is the rezzer prim's position and rotation. Combining the two and applying them to every other object to mimic the moved object in a mirror fashion is what I'm looking to do, but I can't find anything anywhere to give me an idea how to do it. Your help is appreciated.

I am using Windows 8. I had to uninstall Skydrive to get Firestorm to be able to upload at all. Now I have the same problem as the above post, I can upload once if I do it soon after I log in. After that I might get lucky to be able to upload a second time before it freezes on the file dialog. It's a bug that can be duplicated in the SL viewer. It's driving me nuts. No other app I use has issues with file dialogs in Windows 8. It has to be an SL bug or a compatibility issue with Windows 8. I am going to try run as administrator and see if that helps. If that doesn't work I'll try running in compatibility mode.

Loki was nice enough to send me a copy of the sling shot project. It's loads of fun shooting those cans. Great product Loki. Just need a little tweaking to keep those script error messages ("Invalid force in llApplyRotationalImpulse.") from popping up. Also, if you play near a parcel border you can potentially lose a can here and there, but no biggie.

Ok, here's the problem. When you send the "request:Radio" message from the first script, the radio plugin script is receiving the key of the object the script is in, not the key of the person who touched the object. The touch isn't passed to the radio plugin script, so you have to send the user's key and use it to get the dialog to pop up for the user.

Just a tip - I rarely use states unless I need to isolate events or toggle script functionality altogether. Most of the time separate states are not necessary. I do use a separate state to load notecards, just to keep that aspect of the script separate.

Getting back on topic... I've beein doing custom script projects for almost 5 years now. I've learned quite a bit about how to negotiate. Here are some pointers: There is no going rate. Each project is different and the numerous factors involved require the rate be adjusted on a per customer basis. Most people have no idea the amount of work it takes to author a script solution, therefore you will find that most of the time they lack appreciation for the amount of work involved. It might take you five minutes to write a script, but think of the effort it took to get to that point. I will only take on a project if I know I'll enjoy it. There are some projects I won't do, simply because I have no interest in them. It's ok to say no. Gather the parameters of the project and, taking all factors into account, come to a ballpark figure for the job. State any possible increases ahead of time. Make sure you leave a clearly defined picture for the customer and that you see clearly the result they're looking for. This goes without saying, but script as efficiently as possible. It's your responsibility to think of adverse effects on sim performance. Protect your work. Make sure your customer knows that you maintain your rights to the work and how it's ultimately used. Never give out full permission scripts unless you want them in the public domain.

Nice additions. If the colliding object is going fast enough, with enough mass, I would think the engine would react in a realistic fashion without the need for additional theatrics, but I haven't tried it so I'm just guessing.

Loki Eliot wrote: Thank you so much for cleaning up my script. Unfortunitly what i originally thought was the reason for Cans not returning to their original place is incorrect. Even with this tidied up script the cans after a while stop returning to original place, so im not sure why that is. :-s a mystery to me. Could it be something to do with cans rolling more than 10 metres away? Yes, that is most likely the case. llSetPos can only move an object 10m from its current location. Use llSetRegionPos instead.

Use an integer as a boolean for true/false, so you can toggle between hit/not hit. Add a check for the integer in your collision to ensure the can hasn't been hit, then react accordingly; if hit nothing happens. Set the timer for 15 seconds and then execute the code to place the can back where it needs to go. No need to reset the script if you set the integer to false (not hit). Since the pos and rot variables are referenced from both the timer and collision events, they have to be made global for the script. All added lines have // comments. // globals, for use throughout the script integer already_hit; // boolean toggle (true/false)vector pos; // position rotation rot; // rotation default{ state_entry() { llSetStatus(STATUS_PHYSICS, FALSE); llSetAlpha(100,ALL_SIDES); llSetAlpha(0,1); } collision(integer total_number) { if (llDetectedName(0) == "shot" && already_hit == FALSE) // if not already hit { already_hit = TRUE; // set as hit pos = llGetPos(); rot = llGetRot(); llSetStatus(STATUS_PHYSICS, TRUE); llApplyImpulse(llGetMass()*<0,0,10>,TRUE); llSleep(0.3); llSetAlpha(100,ALL_SIDES); llSetAlpha(0,0); llTriggerSound("tincans", 10.0); llSetTimerEvent(15); // start timer (count to 15) } } timer() // timer event (triggers after count to 15) { llSetTimerEvent(0); // stop timer, no further need for it // can reset lines, moved from collision event llSetStatus(STATUS_PHYSICS, FALSE); llSetRegionPos(pos); // just in case object is over 10m from original pos (llSetPos limited to 10m) llSetRot(rot); llSleep(0.6); llSetAlpha(100,ALL_SIDES); llSetAlpha(0,1); llSleep(0.6); already_hit = FALSE; // reset as not hit } }

On a side note... An integer in LSL can have 32 bits max (per the wiki), which means you have potentially 32 "flags" or bits at your disposal in one integer. One of the best examples of the use of "flags" is the llParticleSystem() function which uses them to toggle particle features for a prim. A simple explanation would be having 32 switches mounted on a wall, each has an on and off position. You can use them independently or check for more than one active at the same time, for a specific outcome in your scripts. It's an efficient way of switching things on/off in your scripts, whether it be status or functionality or what not. Since you're dealing with binary, special operators (AND, XOR, NOT) have to be used, if you're using an integer for bitwise.

I've had a successful elevator script-set on the market for a few years (recently pulled to focus on something else). I've learned a lot from customer feedback and what not. The way I designed mine was to have the base of the elevator be the root prim, which contains the "elevator" script. Having the elevator base be the root puts it at floor level and allows for subsequent floor positional data to be acquired easily. The elevator script has a notecard that has relative height values for each floor (starting with floor 2), based on the first floor position, which is always where the elevator is when the script loads. I read in the floor position data into a list at elevator script start, then store the elevator's initial position (first floor). I then listen for buttons via link messages (the buttons in the elevator object) as well as external buttons via chat (call buttons, call floor plates). Each button is notecard configured with its floor number and a few other settings. The user key and and destination floor number are received by the elevator. If the user is valid, the destination offset referenced from the list and the elevator moves to the floor. To pack the elevator with a build you simply move it to the first floor and put it in a hold state so that it is waiting for touch. The next owner positions their build and touches the elevator to reset the script. The offsets are always right because they're based on the first floor position. Elevator doors are a little more tricky. Each door needs to know its floor number and have an option to ignore all other floors, this way they open on their assigned floor but not any other. The elevator needs to send out an arrival message when it arrives at a floor, to open the door. Hope this helps in your design.

Keep in mind also that if you run into a null key or a null value and you try to send it, if a specific order is expected on the receiving end your values will be out of sync (missing the null values). Always check for null values before sending the string to the receiving end. Replace null values with a place-holder value so that the receiving end knows what it is.

It would be way more efficient to have the parent send out a keep-alive signal rather than each child send to the parent.

The beta viewer is as smooth as butter. Must've been a problem in the current release that they fixed. Problem solved.

Innula Zenovka wrote: No, she's using the latest LL beta (well, not quite because, there's a new one today, I've just discovered) , That certainly fixed a lot of Nvidia issues, but that's not what she's using. I'll check out the beta.

Both are the latest viewers. As you can see, the Firestorm viewer had an update in late November, the LL viewer had an update on January 5th. Second Life 3.2.5 (247236) Jan 5 2012 12:10:23 (Second Life Release) Firestorm 3.2.2 (24336) Nov 27 2011 17:05:37 (Firestorm-Release) Great performance on ultra using FIrestorm. Laggy on low using LL. @ Innula - If those are fixes, roll me back. hehe

Ok, here's what I did... I switched to the low graphics setting, turned off anti-aliasing and still when I rotate around in a circle it's not smooth, it's laggy. So either the viewer has an issue with ATI cards or the driver and the viewer are having issues. Either way, I shouldn't have to revert back to an old graphics driver (which will break some of the latest games I play) to get the viewer to work properly. Firestorm runs lightning fast on ultra, so it has to be an issue with LL's viewer vs ATI. The fact that Firestorm runs great means their team is doing something right and LL is doing something wrong. I'm not going to revert drivers just to fix a problem that shouldn't exist. I'll just use Firestorm until LL fixes their issues. It looks like LL needs to consult with the Firestorm team and find out how their viewer runs so great with ATI. lol

Ceka Cianci wrote: Yingzi Xue wrote: Ceka Cianci wrote: Yingzi Xue wrote: That doesn't make sense, considering the code base is the same and they're both using OpenGL. as i said it's just something i heard..mostly in threads here and there in the forum.. for my system..all i know is my nividea card seem to run better for me in V3 than FS.. i was using phoenix when it first came out until pre-alpha FS came out..then when they changed to that rushed mesh version i jumped on beta V3 untill FS came out with the mesh release they wanted for their V2 ..then tried that and went back to V3.. i'm not saying what i heard was fact or makes sense..i don't use ATI myself.. i just know what my card does in all those so far.. hopefully this time next month it won't matter what viewer i'm in..i'm going all out on a new system LOL Congrats on the new forthcoming system. I guess I'll just have to use Firestorm, which I like better anyway. Can't say I didn't try to give it a go. Maybe someone will find a solution at some point, or possibly LL will fix it in the future. *cough* i did see they had an update just the past couple of days..i don't know if you had maybe used that one or an earlier one..i will say i haven't tried the newest update yet ..so i may be back in here with you later today screaming about it..lol I downloaded the latest yesterday. Graphics card drivers are up to date.

Pussycat Catnap wrote: My iMac uses AMD Radeon HD 6750M 512 MB and it runs amazingly well on the official viewer 3. Odd. I'll do some digging and see what I can come up with.

Ceka Cianci wrote: Yingzi Xue wrote: That doesn't make sense, considering the code base is the same and they're both using OpenGL. as i said it's just something i heard..mostly in threads here and there in the forum.. for my system..all i know is my nividea card seem to run better for me in V3 than FS.. i was using phoenix when it first came out until pre-alpha FS came out..then when they changed to that rushed mesh version i jumped on beta V3 untill FS came out with the mesh release they wanted for their V2 ..then tried that and went back to V3.. i'm not saying what i heard was fact or makes sense..i don't use ATI myself.. i just know what my card does in all those so far.. hopefully this time next month it won't matter what viewer i'm in..i'm going all out on a new system LOL Congrats on the new forthcoming system. I guess I'll just have to use Firestorm, which I like better anyway. Can't say I didn't try to give it a go. Maybe someone will find a solution at some point, or possibly LL will fix it in the future. *cough*