Ela Talaj

It's not that simple Sassy. You can hash the keys but you cannot unhash them back so you will not have any log available who is paid what. I would recommend a web page too, because if a script gets reset all the data will be gone, so if in-world got to run a duplex.

It appears that a mono script can store a lot but whatever memory you have there available for storage you must divide by 2 cuz a list or a string operation takes double list/string size memory. My experience shows that the limit is about 500 entries of 50 bytes each.

What's a static boat? The one that has a fixed position and doesn't move anywhere? The script to "rock" should be easy to write indeed along the lines you have suggested, just write it and test it

In-world objects would always send messages to website and receive messages back in HTTP. On the in-world side the engine assembling HTTP messages to send and processing those received must be written in LSL. On the web page side the processing engine could be written in any language that the web site supports. It could be PHP, it could be C++, it could be Java or it could be Javascript. PHP is used most often only because it is supported by most websites and has convenient methods to talk to databases.

A wave is not really nothing more then a object pushing across the water. Where is this object supposed to come from and what water are you talking about? Is it Linden water?

If you set for sale a copy of an object instead of its content, the changed event will execute in the original object, not in the copy sold (a copy sold goes into the buyer's inventory so no scripts are running there until it is rezzed). That's just how the LSL state machine works. So the script will be deleted in the original object. To avoid this, set content for sale, not the object copy.

Everything Rolig said is true and yet the script you want is possible and even easy to write. Either specify a "right" group key as a global variable or read it from a notecard. On attach event call llGetObjectDetails() with OBJECT_GROUP as a parameter. As Rolig poited out, the object group key would be the same as the wearer's group key, so if the returned key doesn't match the "right" key, detach the object. If still have problems writing, call me in world and I'll write you one for a reasonable price.

Why can't you put a script in the ball that would detect collision with the wall and apply a random backward impulse?

Go to the Marketplace and get my Developer Resource Kit A. It is free and open source. It includes an API to make a whatever pages alphabetical menu. https://marketplace.secondlife.com/p/Scripter-Resource-Kit-A/1932506

If you look at your sensor event code carefully you would see that your condition translates to this: for(num = 0; num < found; num++) { //Test if avatar is on the access list if(llListFindList(accessList, [llDetectedKey(0)]) < 0 && llDetectedKey(num) != llGetOwner()) { llWhisper(0, "You are not on the access list. Ask " + owner + " if you are allowed here."); .... } else { //llInstantMessage(llGetOwner(), llDetectedName(num) // + " is granted access."); } So your condition is always TRUE unless the owner happens to be the first agent scanned. This is what usually happens when one declares too many unnecessary variables: one loses track of them.

A programming technique to avoid writing the same block of code many times is called a loop (http://wiki.secondlife.com/wiki/For) In your instance we would like to make a list of 10 colors as RGB vectors like: list colors = [ <1.0,1.0, 1.0>, // white <1.0,0.0, 0.0>, // red // ....... // and so on <1.0, 1.0,1.0> // white ]; then we could write: for(i=0; i<llGetListLength(colors); i++) { llSetLinkTexture(2,llList2Vector(colors,i),ALL_SIDES); llSetLinkTexture(4,llList2Vector(colors,i),ALL_SIDES); llSetLinkTexture(6,llList2Vector(colors,i),ALL_SIDES); llSetLinkTexture(8,llList2Vector(colors,i),ALL_SIDES); llSleep(1.0); } We can further make a list of links to change color sumultaneously (how to do it in a generic case is another matter): list links = [ 2,4,6,8]; so we arrive to a construct called a nested loop: for(i=0; i<llGetListLength(colors); i++) { for(j=0; i<llGetListLength(links); j++) llSetLinkTexture(llList2Integer(links,j),llList2Vector(colors,i),ALL_SIDES); llSleep(1.0); }

On detach event (attach event with null id) store unix time in a variable. On attach event (attach with non-zero id) get unix time again and subtract from it the stored one. If you now divide the result by 3600 you will know how many hours passed while the object was derezzed. Compare with your expiration period. Do not reset script on rez or attach, you will lose the time variable, there are other ways to reset if needed. That's all there is to it. If you are hoping for a complete script, call me first for an estimate.

An LSL run-time error comes only on debug channel, in which case it would be in red and there is also a lil red icon appearing over the object. To see the error the SL debug channel must be enabled in preferences (or wherever its toggle is, don't remember exactly) but the lil red icon would be visible regardless. If the above not occuring it is not a run-time LSL error.

Great answer! It is long overdue to stop providing free code

Basically you have a real time problem. An event is processed until it completes, only then the next event could be processed. So by the time sensor event is raised your typeConst was already reset to 1 in the touch event. So it counts only objects both times. Try something like below. If want to count more than 16 items, buy my moving probe. integer type; default { touch_start(integer total_number) { type = SCRIPTED; llSensor("", "", type, 96.0, PI); } //Use the sensors to keep a count of the total objects and scripts sensor(integer detected) { integer i; integer num; for(i=0; i<detected; i++) num++; if(type == SCRIPTED) { llOwnerSay("There are " + (string)num + " scripts in this area."); type = PASSIVE; llSensor("", "", type, 96.0, PI); } else llOwnerSay("There are " + (string)num + " objects in this area."); } }

Don't you think they know all that? Let's say you're an LL executive in charge. Here's the marketplace group apparently trying their best (which I believe they do) yet they simply can't; they fix one thing, another one breaks apart so round and round it goes... Let's say money is not a problem (which is a very big assumption). What would you do? Obviously it is not junior programmers fault, so what you need is to bring in a cpl senior people, perhaps on a contract basis. It would take weeks for these people to come up to speed, not to mention a month or more to hire them in the first place. And here are the customers rioting, want it all today... What would you do?

Well, you see, you're kinda trying to break an open door here I totally agree with you that SL is a specific game where users create their own content, otherwise there would be no value in it at all, it would be just another videogame. the content doesn't have to be tangible, for instance roleplays are content too. However most of them do require virtual artifacts. Most users for whatever reasons do not create artifacts but prefer to pay for them to a not so numerous group of merchants. This discussion is not about that. It is about a point of contact between merchants and customers. You and I are both old enough to remember times when XStreet had just a few hundred users. All business except for an insignificant fraction was conducted in-world yet whatever content users wished to buy they could. The Lab provided point of sale - on merchant's land - and it still provides the same, it did not change. However even then The Lab gave no assurances that even some of merchants would make real life income. As time passed more and more users would vote with their mice for e-shopping because it is simply more convenient for a variety of reasons so XStreet was growing. Yet even after XStreet purchase The Lab never forced a single user to shop in the Marketplace instead of in-world. The users decided it themselves. Current Marketplace problems are deplorable and yet they do not deprive merchants of a point of contact with customers. It is right there, where it has always been - in world. My own sales are heavily Marketplace and when it is slow or malfunctioning they decrease. Yet I cannot honestly blame the Lab; it is still gives me the same in-world point of contact as it always have. It is not The Lab's fault that the users don't want to shop in-world. It is our fault as merchants that we started almost totally relying on the Marketplace and don't maintain or expand in-world stores as we used to. When one puts all eggs in one basket someone just might step on it while passing by...

I cannot speculate on The Lab's profits because I don't have the data. If you have I'd appreciate having a link to your source. I suppose most income comes from subscription fees and bandwidth fees (tiers). From the last available published report for the 3rd quarter of 2011 it could be calculated that The Lab's income from 10% marketplace commissions comes to about 32K per month USD. This looks like a drop in the bucket.

It is indeed strange to say the least that The Lab which pioneered a 3D environment of such complexity cannot efficiently debug a trivial e-commerce application. However you must agree that The Lab has no obligation expressed or implied to support income for its users. SL was originally envisioned, designed and implemented as a game and a means of social interaction not as an income opportunity.

while (msg = "ON") is simply bad syntax. Intent is clear but would never pass code review anywhere. There are 2 common ways to make an endless loop: while(1) and for ( ; ; ) vector cpos = (llGetPos()); is also bad syntax: excessive brakets. If things compile it does not necessarily means syntax is good. All compilers will let you get away with excessive brakets and it would not affect the executable but... hmm... just hurts the eye Al lthe rest is what ppl told you already

Dora is correct but on the other hand, llDetectedTouchST() has nothing to do with the face texture and a lot to do with a vectoral position of the touch.

You may scan for agents in your sim and then determine if each one is walking or flying or sitting, attached to obect, etc. via llGetAgentInfo(). There is no parameter to find out if an agent is building. To get all agents in the sim regardless of their number either wait for llGetAgentList() being implemented or buy a moving scanner from me.

Maybe the CEO of LL does not respond because of you and your fellow drama queens around here. The CEO of LL could've perhaps spared some time for a productive discussion but surely not for mindless drivel.

a bot is a text client installed on your PC just like a graphic client (viewer). There are several on the market, including Metabolt, Pikkabot (or something close), etc. Can find via search in the Marketplace. The text client is an avatar so must have an account like a regular user, but it can run unattended that's why it is called a bot. A region server makes no distinction between a bot and an "live" avatar. That's why among other things a bot can auto-invite to a group (an LSL script cannot). In your scheme an object with a script in it would accept L$300 or whatever payment and then send a message to the bot, upon receiving the msg, the bot will auto-invite to group.

Ranking by relevance doesn't work at this time anyways