Yingzi Xue

That doesn't make sense, considering the code base is the same and they're both using OpenGL.

Ok, so I decided to give the official viewer 3 a chance today. I have been using Phoenix and Firestorm for over a year, after finally giving up my much coveted viewer 1. I don't understand why Firestorm runs so great on my ATI Radeon HD 5870 but whenever I try to run LL viewer 3 it lags so much. It boggles my mind that the official viewer runs so awful. I'm so glad I have a choice with Firestorm, because if I were forced to use viewer 3 from LL I think I'd go insane. Just venting. Thanks or listening.

This is a bug that has existed for some time. From what I was told at the time it seems to have something to do with the llPreloadSound function which has a bug that's never been fixed. One reply to one of the JIRA's was to use llTriggerSound instead to keep from having the problem.

Lear beat me to it, but this is how I design all of my scripts that require listens: I always like to have my script doing nothing when idle, including removing unnecessary listens. If I require a perpetual listen, I only use one listen and use the simplest method to verify if the messages are meant for my script--checking for a key, value or string within the received data before processing anything. By design, I try not to have perpetual listens, but sometimes it's unavoidable. Listens that don't need to be perpetual have timeouts (dialog menus, for instance) after x seconds, thus removing the listen. This keeps listens to a minimum. The general rule is to keep the script idle until interacted with by an avatar. If any listens need to be turned on/off repeatedly using the same channel, I use llListenControl. I hardly ever use states. I find I can achieve the same result (i.e. a switch) with boolean integers and much less code. Keep chat messages to a minimum by combining data into as few messages as possible. One message per interaction is what I always strive for. Multiplicity. As was stated earlier, you have to conceptualize how your script will be used and how many will be used in a sim. One script may not cause much of a dip in sim performance, but if you multiply that by 10, 20, 50, 100 what would the performance be? I always try to keep my functionality within one script rather than compartmentalizing in multiple scripts. Most of the time it's unnecessary to have multiple scripts. The memory usage will be slightly higher with multiple scripts. More often than not, if I have multiple objects that need to interact with each other, the client/server or one-to-many/many-to-one relationship seems to be the most efficient. Instead of having 20 clients listening, have one server listening; set the clients on timers for communication to the server. If I can close a listen that I don't need, or find a different way, I will. You just have to be creative. Writing efficient scripts isn't hard.

I have had an elevator script-set for builders on the market since 2008. In that time the product matured and this very feature was requested by one customer, so I set about writing a method to overcome the 64m distance limitation. The methods mentioned so far are for non-physical movement, which requires the person be seated in the elevator. You can get around the seated animation by stopping it and using a stand animation instead, but in my opinion this deviates from the fun and purpose of an elevator. My elevator script-set was based around physical movement, which was limited by the 64m distance from A to B. I got around it by having the script divide the distance into more manageable spurts, but due to the nature of physical movement (acceleration and deceleration), the movement was slightly herky jerky. I was able to buffer this to not be so dramatic using distance checking. It all seemed to work great... UNTIL... One of my customers tried to make a space needle. Going up the elevator worked fine, but on the way down the elevator would gain so much momentum that it would free-fall. What I hadn't known up until that point was that gravity, downward movement speed and distance caused the elevator object to accelerate to the point of breaking free from the move function and plummeting to the ground. I worked on methods to buffer the effects of gravity with speed modifiers, but I was never able to get it to work right. Ultimately, I removed the limitation bypass code completely and reversed the product back to 64m limitation. Is it possible to get it working correctly? Maybe, with the proper math, but to be honest the limitation is there for a reason, possibly LL foresaw the loss of control of physical objects moving at great distances, especially from a high point to a low point. At distances greater than 64m, I suggest non-physical movement. You lose the elevator ride effect, but it gets you where you need to go, which is the ultimate goal.

In my opinion, using dataserver whenever you want to pull a new animation is definitely not going to be as efficient as using a list. You'll notice a big difference with dataserver as opposed to lists. However, a script only has 64k memory, so you have to consider memory usage vs a sim. If you have 10 people using your dance HUD, that's 10 people using large amounts of sim memory. What happens when you have 20, 30 or 40? Huge memory usage for the sim, but you may not notice any lag per se, just memory inefficiency. As was said in the last reply, if you use the actual names you can't have custom names for the animations, but to me it's a small price to pay. I would rather be super efficient than cause sim performance degradation or be a memory hog. My choice would still be to do it dynamically instead of relying on notecards. Let me digress slightly. Most animation scripts typically load notecard settings at start, into a list for use from there on out. Right now it's the way things are, but I remember LL was talking about alloting script memory on a per parcel basis, which might come back to bite this method, if implemented.

Consider how a typical dance HUD works. Usually, it moves from one dance to the next after a period of time. Instead of storing the names of the dances from a notecard into a list, why not use llGetInventoryNumber(INVENTORY_ANIMATION) to acquire the number of dances, then use a pointer to keep track of the current dance? When combined with llGetInventoryName(INVENTORY_ANIMATION,number), you can acquire the name of the current animation, previous and next (if desired). Use a FOR loop with a temporary list if you want to populate a menu. This would take much less script memory and be much less laggy than trying to keep track of a list of dances in a notecard, which also has to match the ones in inventory. Use IF (llGetInventoryType(llGetInventoryName(INVENTORY_ANIMATION,number)==INVENTORY_ANIMATION) to determine if an animation exists before applying it.