Yingzi Xue

Yes, it's possible to do in-world as you described, especially if growth requirements are small. However, the negatives of a completely in-world system should be pointed out: Keeping track of URL lists within SL by the very objects that have URL's can fail, possibly requiring yet another script/scripted object as backup to keep track of URL's independently or face complete loss of communication. Keeping track of URL's and texture keys vs memory. The current week in events would be small, but what if the customer wants to configure six months or up to a year in advance? Add in texture cycling and your memory requirements grow exponentially. The chance that llEmail will fail. Limited script memory for growth. Potential adverse impact on region memory usage. Events are time sensitive. The last thing you want is to find out your ad board system failed and your potential customers didn't know the event was taking place. Having to reset or kick start a clunky in-world system repeatedly isn't good customer service and isn't indicative of a good product. Granted, some of these are dependent on the needs of the customer for the ad board system, but all are good reasons to do the lionshare of the data storage externally, for efficiency, stability and expandability. Not saying it couldn't be done, because it can... but at what impact to the owner, users and the region(s) involved? It all comes down to what the customer needs and what they're happy with, but as scripters we should be concerned about efficiency, for the sake of the grid. Hopefully they find a solution that works, is efficient and grows with their needs.

This forum is for scripters to seek help with scripts they're writing/working on. The answers to your questions are multi-faceted and beyond the scope of this forum, considering the complexity of the project. If you have existing scripts you need help with, post them here and we'll help you through them, but if you don't have scripts and need them made for you, the forum you should post in is Wanted. You can find examples of everything you need in the LSL Library forum and the wiki library. You can also find excellent vehicle example scripts at Vehicle Laboratory in-world. Seating requires sit configuration for every seat you want to incorporate into your vehicle, along with animations. You can find any number if sit configuration tools on the marketplace. Tire rotation can be achieved, dependent on your tire prims and texture layout. A quick search on the marketplace pulled up this vehicle making toolkit: https://marketplace.secondlife.com/p/ACS-Vehicle-Operating-System-v605-mesh-enabled-bestselling-vehicle-scripting-system-for-motorcycles-cars-and-boats/914566.

How would you handle inter-region communication across the grid? The only in-world option I know of is llEmail between prims, which is unreliable... Due to the bug SVC-23 (present since 2005), objects may stop receiving emails completely until either the region is restarted or the object crosses a region boundary (resetting the script doesn't help). Emails sent may eventually be received after a restart/region-cross. Hence, don't rely on this function for reliable inter-region messaging. Due to the bug SVC-391 llEmail will silently fail (no mail will arrive) when non-ascii characters are present in the subject. However, non-ascii characters in the message body will be replaced by "?". Both of these bug reports were closed a long time ago as "won't finish". Some people have found success with llEmail. I wouldn't trust it for any of my projects, as a reliable solution for inter-region communication. llGiveInventory may be possible for avatars, but only works for objects in the same region. XML-RPC is a solution which requires an external server/service (web site, etc.), but... Important: XML-RPC requests often time-out due to the front-end server being overloaded. LL has continued to upgrade the server hardware periodically, but it has remained unreliable. LL developers have advised that the XML-RPC design isn't scalable (due to the single server bottle-neck) and that the service is "deprecated". They suggest using LSL HTTP as an alternative. If an XML-RPC request does time-out the script's remote_data event may or may not be triggered (and any script response is lost). See this blog entry for more about the future of XML-RPC. The only thing you're left with is HTTP functions and an external solution, at the minimum a web space. Reliability is something I won't skimp on.

If the people you plan on giving the ad board to are going to be in a different region than the master, you're going to need an external server to transmit data back and forth between the master and the slaves. Even if you get someone to write you the script, this would require that someone somewhere has a dedicated external server that would perform the tasks you need on an ongoing basis. Not only would you be paying for the initial script development, but there will likely be additional costs involved for the use of the server involved, or a larger upfront cost to cover server usage. As per above, this goes in the Wanted or Inworld Employment forums.

Side note, since it's along these same lines... In a situation where you may be using a vendor script that doesn't support splitting profits, you can use a second script that does the profit splitting, because multiple scripts can trap the money event (Pay) and react accordingly. I've done this with a tip jar pay tracker before.

I found this script on the wiki under llSetHoverHeight. I modified it to work, not as an attachment, but as an object. // Put in an attached prim and touch to start it floating.// Touch again to drop to the ground. integer gHovering = FALSE; // are we supposd to be hovering now? default { touch_start(integer total_number) { if (gHovering) { llOwnerSay("Hover off."); llStopHover(); } else { llOwnerSay("Hover on."); // Start hovering 5 meters over our current location. vector myPosition = llGetPos(); llSetStatus(STATUS_PHYSICS,TRUE); llSetHoverHeight(myPosition.z - llGround(ZERO_VECTOR) + 1.0, FALSE, 1.0); } gHovering = !gHovering; // flip the switch }} Addition options for other functionality: The Vehicle Laboratory (http://maps.secondlife.com/secondlife/Slate/188/84/2) has a lot of good basic vehicle scripts to learn from. The anti-grav vehicle example is an excellent starting point for a hovercraft project. Although vehicles are meant to be driven, they react realistically and a hovercraft vehicle in a ball would react in a realistic manner. Another option, if you want the ball to bounce back to its position after collision, is to simply put a script in the ball to turn it physical and set it to llMoveToTarget for the position you want it to stay at. Whenever something collides with it, it will move back to its home position automatically, as long as it's within 60m or so. Here's an example I wrote: UPDATE: Strange behavior. After the fourth or fifth collision, the object bounces away like normal, but comes right back and bounces off your avatar like it's throwing the prim at you. lol I think it's just stored energy that gets released, but it's neat to see how "alive" it seems to have a prim you bump into jump back and hit your avatar. Fun experiment. // Anchored reactive physical object// By Yingzi Xue// // Uses llMoveToTarget to maintain default position.// Reacts to a collision for x.x seconds, then moves to default position.// The result is a rubber-band effect that reacts to collisions, but recovers.float time_until_recovery = .25; // Time after collision to wait before recovery/bounce back.float tau = .25; // How fast the object rubber-bands back to default position, after time_until_recovery; larger number = slower.vector pos; // Stored position (at script reset); this is the position the object will maintain.default{ state_entry() { llSetStatus(STATUS_PHYSICS,FALSE); // Turn physical off. pos = llGetPos(); // Store position of object at script start. llMoveToTarget(pos,tau); // Set the position to hold the object to; as long as object is physical it will always try to maintain this position. llSetStatus(STATUS_PHYSICS,TRUE); // Set object physical. } collision_start(integer c) { llStopMoveToTarget(); // Turn off llMoveToTarget, so that object reacts to collision and doesn't try to move back. llSetTimerEvent(time_until_recovery); // Start a timer count to x.x seconds. } timer() { llSetTimerEvent(0); // Turn timer off. llMoveToTarget(pos,tau); // Move to stored position (recovery). }}

I agree. The marketplace is a distraction and ever since LL bought it and made it their own there has been a decline in in-world stores.

This is the first script you posted: list colorChoices = ["-", "Red", "Green", "Yellow"];string message = "\nPlease make a choice.";key ToucherID;integer channelDialog;integer listenId; // OUR NEW HANDLEdefault{ state_entry() { channelDialog = -1 - (integer)("0x" + llGetSubString( (string)llGetKey(), -7, -1) ); } touch_start(integer num_detected) { ToucherID = llDetectedKey(0); llDialog(ToucherID, message, colorChoices, channelDialog); listenId = llListen(channelDialog, "", ToucherID, "");// OUR NEW LISTEN }} The problem with this script is there is no listen event to process the dialog menu buttons. ... As for the second script, you had numerous syntax errors, missing brackets and disorganized code, plus your "DROP THE BASS" menu button had an apostraphe at the end of the text while your if statement didn't contain the apostraphe; it never would've worked. I added in a dialog listen timeout (timer) with optional message, to remove listen after 60 seconds or a response. It's a good idea to check to see if a sound exists in your object's inventory before trying to play it, to keep from getting a script error, so I added code for that. integer CHANNEL = 42; // dialog channel integer DIALOG_CALL; // store dialog listen handler (a unique number) so we can remove it later on timeout or response float DIALOG_TIMEOUT = 60.0; // time out dialog listen in 60 seconds list MENU_MAIN = ["Light Show", "Heart", "Ping-Pong", "Cheat", "Options..."]; // the main menu list MENU_OPTIONS = ["Chill", "Hardcore", "Dance", "Techy", "Chips", "DROP THE BASS", "...Back"]; // a submenu // A function to silently remove dialog listen, which is unnecessary if script is idle. // It can save script memory to declare a function to do tasks that are repeated more than // once in your script. You call the function instead to perform the snippet of code. // If passed integer == TRUE, timeout whisper message is sent to local chat. dialog_listen_remove(integer speak) { if (speak == TRUE) llWhisper(0,"Menu timed out."); // timeout message llSetTimerEvent(0); // turn timer off llListenRemove(DIALOG_CALL); // remove unnecessary listen using the handler we stored in state_entry } default { state_entry() { DIALOG_CALL = llListen(CHANNEL, "", NULL_KEY, ""); // start listening, store handler to our listen in DIALOG_CALL } touch_start(integer total_number) { llDialog(llDetectedKey(0), "What do you want to do?", MENU_MAIN, CHANNEL); // present dialog on click llSetTimerEvent(DIALOG_TIMEOUT); // start dialog listen timeout timer } listen(integer channel, string name, key id, string message) { if (llListFindList(MENU_MAIN + MENU_OPTIONS, [message]) != -1) // verify dialog choice { llWhisper(0, name + " picked the option '" + message + "'."); // output the answer if (message == "Options...") { llDialog(id, "Pick an option!", MENU_OPTIONS, CHANNEL); // present submenu on request llSetTimerEvent(DIALOG_TIMEOUT); // start dialog listen timeout timer } else if (message == "...Back") { llDialog(id, "What do you want to do?", MENU_MAIN, CHANNEL); // present main menu on request to go back llSetTimerEvent(DIALOG_TIMEOUT); // start dialog listen timeout timer } else if (message == "DROP THE BASS") { dialog_listen_remove(FALSE); // remove dialog listen without a message // It's a good idea to check to see if a sound exists before trying to play it // otherwise you'll get a script error if it doesn't exist. if (llGetInventoryType("Drop the bass")>-1) // sound exists if result is greater than -1 { llPlaySound("Drop the bass",1.0); } else { llWhisper(0,"'Drop the bass' sound missing."); } } } } timer() // this runs after DIALOG_TIMEOUT (in this case 60 seconds) { dialog_listen_remove(TRUE); // remove dialog listen with a message } }

I use it regularly to find locations. If you know the name or the theme, it can be fairly useful. If you're just looking for random results for a specific category, it can be next to impossible to find new locations. It's a mixed bag. The old search that wasn't web-based was much more intuitive and you could find exactly what you were looking for. I wish they would bring it back without traffic as a factor, it would work a lot better and much faster.

Having never owned more than a mainland region, I was under the assumption that tier capped at $195, since that's all it shows on the Land Use Fees page, until such a time you go over. A quick search found the answers that eluded me. Land tier does indeed increase beyond $195/65536. Learn something every day. It's not a complaint about the auctions, it's about giving a person/group that owns half a region first dibs if they're first to ask, since they are so invested in the region already. (Knowledge Base excerpt) How to request purchase of abandoned land There are cases in which Linden Lab sells abandoned land directly to a Resident who has a solid claim on it. We attempt to give priority to those who already have land in the region. If two neighboring parcels both have a reasonable claim on the parcel, it will likely not qualify for direct sale. In some cases, we can assist with subdividing larger parcels for those with a strong claim. A strong claim for a direct sale includes but is not limited to the following: Land you own borders three sides of an abandoned parcel. Land you own completely encircles the abandoned parcel. The requested land is awkward or irregularly shaped. The requested land does not neighbor yours, but you are an established resident of the same region. Per above, we had a strong claim. In the end, profit won over community, that's how I see it. That parcel I wanted? It sold on auction for 70k, went on sale by the realtor for 180k. It's now down to 160k. The realtor will be lucky to make any profit. Karma wins out after all. :matte-motes-big-grin: As for auction strategies, I appreciate you trying to teach me the finer points of how to play/win auctions (albeit snide and condescending), but I've been using E-bay since the mid 90's, I think I know a thing or two about auctions. Back to the thread topic: The OP asked the question... how can they afford it? I am wondering the same thing and the question is still not answered. My personal opinion, there's an inside deal or the largest realtor(s) are actually <insert virtual world company name of choice here>. Take a look at Zindra and think about it. Mind blown yet?

If you look at land on Zindra (the adult continent), most of it is owned by one "realtor". The tier for the amount of land this person owns must be ungodly. I can't imagine they're making even a fraction of the profit to pay for it all. Which begs the question... is this really a "realtor" or something more sinister? You decide. One only has to look. You can only have so much tier per avatar, which means they must have a long line of avatars to pay for their tier. I just don't see how it's possible, unless... (like I said, you be the judge). I recently wanted to purchase a 12k parcel on Zindra. It was newly abandoned. I sent in a ticket requesting to purchase the land since I owned half the region. Guy Linden shows up a day later and says, "Oh we can't do that..." then puts it on auction, of course a realtor wins over us at the last second and puts it on sale 2 1/2 times the price it's worth (and it still hasn't sold). I can point you to parcels of equal size on the non-adult mainland that have been abandoned since 2010, yet they haven't been auctioned off. A might bit fishy if you ask me; that one realtor owns most of Zindra, which is the most populated continent in SL and was to be the savior of LL a few years ago, just happens to be monopolized by one "realtor", which has a name that has an uncanny resemblance to (well, you decide). I don't see how one person can dominate the whole continent, paying tier and making money on rentals to break even. But hey, I'm just a lowly peon.

MOAP is like using a browser on a prim face. LSL has no way of knowing what you're clicking on. The only way to get feedback is to have it sent to your script from the page you're interacting with. Examples: http://wiki.secondlife.com/wiki/LSL_HTTP_server/examples HTTP functions: http://wiki.secondlife.com/wiki/Category:LSL_HTTP

The only solution is to have a store on your own land and refer your customers to your "main store" if they want to use the gift option on your vendors, or find a rental that does not have auto return enabled and allows you to use your own group.

I did this back in 2009. There was nothing fancy to the design. Here's how I did it... Two vectors... min and max are all you need. I made a bounding box detector unit to acquire the bounding box. You place it in the middle of your room (i.e. there has to be four walls, a ceiling and floor/ground; if in the open, set up four temporary walls, ceiling and floor first; N, S, E, W, Up, Down). Detector unit moves by physical movement. Assume there are no obstacles in the room to run into. If bounding box detector goes outside of the region, it auto dies with a message (llGetRegionName). The detector unit moves until it collides with a wall, then it waits a couple seconds while still applying force against the wall, to ensure a good reading. It does this for all six directions and stores appropriate position float for the specific direction like this.. Move positive in the x direction to a wall = max.x Move negative in the x direction to a wall = min.x Move positive in the y direction to a wall = max.y Move negative in the y direction to a wall = min.y Move positive in the z direction to a ceiling = max.z Move negative in the z direction to a floor = min.z vector min = <min.x,min.y,min.z> and vector max = <max.x,max.y,max.z> I used notecard config, so the min, max vectors were given in local chat for the notecard. While editing the notecard, set your sensor setting for the necessary range from the middle of the room (where you put your security unit) (i.e. as calculated in previous post). In the sensor event, check for llOverMyLand(llDetectedKey(x)) and for llDetectedPos(x) being within low and high x, y and z ranges as specified in min, max vectors. React as needed. Set unit to disappear and be phantom when armed since it will be in the middle of the room. It worked quite well. I still use it from time to time. My partner and I used it to secure our second floor of our house. Someone came along one day and tried to get upstairs. They tried several times, but kept getting kicked. Loads of fun and an easy way to secure your bounding box.

The wiki has everything you need for reference, but programming basics are what you need to learn first. Most of the same concepts apply from one language to another. My own personal opinion--the College of Scripting in SL is great place to learn about individual functions, but it's not a good place to start to learn how to write your own scripts or to learn the fundamentals. I visited the College of Scripting recently and found it to be disorganized. Anyone new to scripting would be thoroughly confused by the place and anyone with some programming experience would benefit from referencing the wiki rather than the in-world College. I'm not trying to diminish the amount of effort that was put into the place, but I can't recommend it to someone just getting started. As an in-world function reference, it might be useful. Again, this is my own personal opinion.

The llTeleportAgent bug still exists. I abandoned a teleport HUD project the first time my dance HUD crashed. The other suggestions are better alternatives to llTeleportAgent.

The best argument for constants, for future compatibility, is the winning argument for using them. However, allow me to digress... I admit, I prefer to use 0 instead of PUBLIC_CHANNEL. For me personally, since I'm the only one that ever sees the actual code, I can read it just as easily as I can PUBLIC_CHANNEL. In fact, I prefer the code to be a bit obscure, because it's a good reading exercise to be able to scour through code that might not have everything labeled and perfect and get the gist of what's going on. It's like word find puzzles; the more you do them the better you get at picking things out of obscurity. Don't get me wrong, the merits of using ALL constants (I use quite a few, just not PUBLIC_CHANNEL) far outweighs what I just described, but hey... I like to be difficult and set in my ways. LOL Sometimes we can take LSL so seriously (and programming in general) that we become stuffy and set in our ways. Constants are there for ease of use. They're optional. You may have just convinced me to make a change though, for the best of 0... er I mean PUBLIC_CHANNEL.

That's exactly what I was going to suggest, a delay to allow catch-up. Good work finding the solution. I had a script recently that uses llRemoveInventory to clear a prim's contents. I found that if you don't put a delay between cycles it will miss some items. I was able to find success with .2 delay, but I decided to give it wiggle room and made it .5 instead.

Some bad practices and ways to test your scripts for efficiency: Performance - If a script causes a performance hit, you know you're doing something wrong. Built-in viewer features and scripted performance monitoring gadgets give you a quick and easy way of monitoring performance dips caused by scripts. Memory - How much memory is your script using? What impact is there if the object is rezzed 10 times or 100 times? Land info provides a script usage window so you can easily see memory impact of your scripts. llGetFreeMemory to gauge impact; it's great for checking memory usage within the script at various places. Working vs Idle - A script should be designed to be as idle as possible. Most scripts can sit by and wait for something to happen. Some use timers for various tasks. Keeping actual working time to a minimum and idle time to a maximum frees up processing power for other tasks. Repeating Code - If you have repeating code, it may be more efficient to make a user-defined function. Check memory usage of each and weigh the differences. Flow Control - Bad flow control practices like unnecessary use of a timer or allowing a timer to accrue more event queue hits than it can process; easy fix, stop the timer at the beginning of the timer event, start it at the end. Excessive looping (for/while/do) and using states for changes in functionality when global integers within the same state would be more efficient (i.e. boolean TRUE/FALSE or bit fields). Listens - Leaving channel listens open when they're no longer needed; quick fix is to use a timer to timeout and remove the listen. Listening to local chat (channel 0) all the time (causes lag). Chat spamming is also a bad practice, even if it's on a negative channel (causes lag). Any type of unnecessary messaging whether it be chat or link message is a bad thing. Global vs Local - Using global variables when local ones will do nicely. Determine what values can be temporary and what values need to be available globally. Keep text in your scripts under control. A lot of strings and text in quotes eats up script memory. Keep text to the point. These are just a few ways to script more efficiently. If you look through the forum archives, you'll find a lot of information about what causes performance hits in scripts. I never did answer the question.. Is scripting an art or just mathematical logic? To me, scripting is a creative outlet. A blank canvas to express yourself; much like a writer and his word processor or pen and paper, or a painter and his canvas. It's a perfectionists pastime, because you're always pushing yourself to do something better than you did before. As for mathematical logic... of course math is involved, so is logic, but each can be mutually exclusive, depending on what your script does. I'll be the first to admit, I got B's in my high school algebra class, but math isn't my strong suit. Even so, I've been able to accomplish whatever I've set out to do because I can always find the answer somewhere if I don't know it myself. I'm not one of those programmers that tries to squeeze bytes out of a line of code by ordering it differently or using loopholes. It simply doesn't interest me. My point, you don't have to be a math whiz to program. You can find math formulas all over the place that will fit what you're trying to accomplish. Getting to logic... it's a main component of flow control of your script. Thankfully, most people are familiar with logical deduction, so it should come easy. Scripting is what you want it to be and each person has their own unique perspective on it. I think the best part about scripting is when you get in that zen mode where time flies and you are lost in it.

In reply to the OP. From what it sounds like, you've been scripting since 2010, but don't have any prior programming or scripting experience. Am I right? If this is true, then I can understand why you lack a sense of direction as to how you should script. To specifically address your questions: As has been explained in another thread, there are times when you shouldn't make a user-defined function for a few lines of code. Only you can determine whether it's better or not. Easy way to tell if you're doing it right... check free memory with your function and without it. Go the route that uses the least memory. As for modular, some of the top businesses use modular scripts in their products. Does that make it right? Not necessarily. It all boils down to efficiency. The opinions you're getting on this forum are from experienced programmers and scripters who strive for efficiency; something that comes with time and experience. Thus, it is encouraged that you choose the most efficiency practices with your own scripts. I can think of a lot worse things to do than making an extra user-defined function that uses slightly more memory or a modular script-set that has more overhead on a server but are very small individually. One factor to consider is how many of your scripted objects a person might rez in a region. Common sense stuff that you should think of. Don't sweat the details too much, there's a lot worse you could be doing. Just know that the community encourages efficiency in your scripts, because it only takes one inefficient script to cause performance issues. Many products probably wouldn't meet the grade of the most experienced persons here on the forums, but standards are something to strive for, for the sake of the grid. That's all they are trying to instill in you, good sound efficient scripting practices. As for a deeper understanding... Where should you begin? Fundamentals of programming are the same for any language. Learn programming fundamentals like efficiency, readability, naming conventions, documentation, proper use of operators and flow control, when to use local and global variables... and the list goes on. Back in the day they taught you to create a flow chart of your program before you started programming. I always considered flow charts tedious, but the concept isn't; writing down your concept, along with notes and ideas, goes a long way and may help you conceptualize better. Read/study other programming languages. Find the common themes (again, back to fundamentals) in all programming languages. If you have more than just one language under your belt, a clearer picture starts to form in your mind and things come easier. I've been programming since the early 1980's as a hobby. I can tell you that there's no substitute for hunkering down and reading, learning, experiencing. There are countless scripts in the forum archive as well as the wiki library which should give you some good sound scripting techniques. What you need is a foundation (fundamentals) to build upon. Once you have that in place, everything else follows. It can literally take many long years to get to the point where you can conceptualize your project, from start to finish, in your head. It was easy for me to learn LSL because I had all of that programming experience under my belt. For someone just starting out, who is new to programming, it can be a big hurdle to overcome. As far as I know, there really aren't any LSL scripting classes that teach you basic programming fundamentals. Learn as much as you can from a variety of programming languages. You don't need to master any of them, but learning what all programming languages have in common will lay that foundation you need brick by brick and empower you. If you don't want to go that route, there is plenty of information in the wiki on the LSL language, as well as countless examples you can peruse to garner a better understanding. I'll leave you with a couple sayings... "Garbage in, garbage out." It's an old programming saying, meaning if you input junk you get junk back. Likewise, there's another saying... you get out of life what you put into it. In the case of scripting and programming this is especially true, meaning you should be hungry for knowledge on the subject and actively work toward improvement and betterment, otherwise you won't get anywhere with it if you sit and wait for it to come to you. Unfortunately, scripting and programming requires some work to be proficient at. If you keep at it, there is a point on down the road where things click and you're over the hump. Best of luck to you.

Sure, there are situations where multiple scripts are a necessity. E-mail and IM's might be one, if you need to free up your main script to do other things. Memory is a consideration, but if I can do it without multiple scripts (most of the time I can), there's really no need for multiple scripts. By the way, I've never seen one large script perform badly because it wasn't segmented into multiple scripts.

Ela is correct. With individual item give scripts, the problem you're having is that, even though SL's own wiki states you can move 42 items at a time, it's more like 10 at a time (safely). Anything more than that and you may get failures. If your script is giving items individually, the llSleep(0.5); statement after llGiveInventory will minimize the chance of give failures. My recommendation is to use a folder giving script instead. I have been using a folder give script in my boxed products since 2007 and I've never had a failure, even with 30 items, so I am confident in its ability to give folders of my boxed products. This one is obvious, but it needs mentioned: If your customer is on land that doesn't allow scripts to run, the script won't be able to give any items because it won't be running.

I wouldn't recommend writing scripts in a modular fashion. White it does compartmentalize, it's inefficient and just adds more for the server to do (namely running more than one script). The goal of any scripter should be to be as efficient as possible. One only has to look around at popular products on the marketplace to see the waste and inefficiency some scripters put out there. I try to keep everything within one script and when possible I use link functions to do what used to require a script in a child prim. If I run out of space (and I do sometimes), I use a second "slave" script to off-load some of the functionality. That's only in the more complex projects though. I rarely, if ever, use states in my scripts, the exception being a notecard reader. My suggestion is to refine the way you write your scripts, so that you can easily understand what it's doing. Comments, tabs and the ability to have white space within statements, those are invaluable for readability; the tools are right there for you to use. Years ago, LL was considering memory restrictions based on the size of the parcel. They haven't implemented those restrictions yet, but if they do come down the pike, I'd want to be in such a position where my products meet the grade for efficiency. Best to start now and prepare for that eventuality, which means modularization will be a bad practice for scripting in SL. Just my opinion, of course.

Everything LepreKhaun said is spot on. I've set up such a system for my SL business needs. It isn't something I would recommend you pay someone else to do for you. The main reason, it's perpetual. What that means is, once you have it set up, you need to maintain the server, modify code internally and externally to accommodate new data and new/changing products. Not only that, you have to pay for a server, be familiar with all of the above (as LepreKhaun listed) and be capable of doing what needs to be done as necessary. If you're lucky enough to find a person willing to set it all up for you, even rent you server space, you would pay through the nose for their expertise and the continued work that would be needed for your project. If you're technically inclined and want to do this yourself then reference the list and get started. You can find LSL examples here for HTTP functions, but the external side is beyond the scope of this forum. Again, this is a technical project with many facets. I don't recommend you attempt it if you're not willing to invest the time and effort beyond having someone else do it for you.

Sounds like an issue with the scripts themselves and/or how they've been configured. The amount of scripts being used shouldn't be an issue. As per the other reply above, if scripts are fighting each other (using the same comm channel, for instance), you'll have strange results. Lag can rear its ugly head at times, but lag and x amount of scripts in a region aren't going to cause an animation to be flipped backwards or a prop not to rez (unless said lag is causing chat or link messages to be dropped or missed; rare and unlikely), those are configuration/script issues that need to be resolved. My advice, try going through the config process again with the problem animation and prop. If it does the same thing, contact the script author and request help. The only time I've ever seen an animation cause issues is when they are uploaded without a loop setting, which can cause the animation to play once then end, thus your pose may not stay constant, but just stop altogether and go back to your AO or sit or whatever animation is the default.