Ela Talaj

This really requires a long article but I have neither time nor strength to write one so I'll just list points without much elaboration; who knows, maybe someone would expand on it. 1. SL products regardless how they are bought are utterly worthless unless used in-world. They cannot be used anywhere else. So if ppl buy them it means these products enrich their SL experiences. I somewhat doubt that these experiences consist mainly of in-world shopping. One does not need to buy in one store in order to go to another store to buy more. For as long as the above is true no Marketplace is going to kill SL or even diminish it. 2. People vote with their feet (or in our case mouseclicks). The Marketplace gained popularity because shopping there is uncomparably more convenient than shopping in-world. To mention just one thing, people can shop while not having in-world access <from work? > and then use their in-world time for other activities, those they came to SL for in the first place. 3. Merchants feel bad about the Marketplace because they have no control over it - everything is done by the Lab. It is however true in-world as well. The latest example would be an ill-conceived attempt (fortunately appearing aborted) to modify LSL in a way that would basically render useless all in-world "user on-line" indicators. Yet in-world there is an appearance that users have free will outside the Lab control. 4. The Marketplace problem is not so much in poor software but in the commerce team's failure to create the same appearance of free will that exists in-world.

on 03/28/12 at 12:59 a.m. Pacific time.

Ahh...so what ya saying is that there is no translation now from the web product name to the folder name and the folder must be named exactly as the web product... I wouldn't know, I haven't tried to upgrade from magic boxes yet... Hmm, if so it would be a major design flaw.

Imagine that every shop you ever bought something at suddenly sent you newsletters about upcoming releases, may it be the grocery store around the corner or the large store down the street. In fact they do. They put it in my mailbox (physical) and they put it in my newspaper. Dozens of pages, every week, all grocery chains and all large stores that are around. I guess if it didn't increase sales they wouldn't be doing it, costs them a lot prolly.

If the inventory doesn't support non-ascii characters how could you load anything with Boötes in its name into the magic box before DD? If you did not but were able to associate Boötes in the product name in the marketplace page with the ascii name in the magic box, then the non-ascii characters were read correctly by the web page processing.

Why not block the reviews altogether at this time and see what happens? There is a possibility it may speed up things. They are useless at this time anyways because one cannot put a review unless bought a product and people are not going to wait for a dial-up speed loading to buy.

There are separate issues here and sadly appears too many of them. I don't think the page load dial-up speed is caused by the alleged unicode bug. In fact I don't even think it is caused by the direct delivery upgrade. The marketplace was somewhat slow as compared to other websites loading time weeks before March 21. My personal feeling is that the database is not indexed correctly and the traffic increase (mostly by merchants) after the upgrade aggravated the problem but the upgrade itself is not the root of it.

Spam, schmam... It's just a simple matter at what point medicine becomes poison, which is up to an individual merchant to figure out. I send one or two messages a month to my mailing list which is rather large but includes only those who bought something either in-world or in the marketplace. I don't include those who just visited the store or touched the vendors for info (though I could've because I have all this information). Anyways I don't consider it spam. My feeling is that whoever bought a product might be interested in new releases and apparently a reasonable percentage does, judging by repeat sales. It takes one click to discard a message so if someone wants to spend hundred-fold that much time to get loudly upset they simply have nothing to do in the first place so could've read the newsletter as well So far I had under ten complains about "spam" and whoever complains gets removed from the list, no questions asked.

If you want chains, it could be accomplished via either lockguard or lockmeister. While ago I've done it for MLPV2 via lockguard. Call me in-world to discuss specifics.

The problem with lists (as well as strings) is that the LSL doesn't support either pointers or references to objects (which on the low level is the same thing). It puts the whole objects on the stack. So if you have a list or a string taking a certain amount of memory, the memory usage doubles each time you pass this object as an argument to a function. This applies as well to LSL system calls which operate with lists or strings as they are also put on the stack. So each time you call a list or a string operating LSL method, such as for instance llListFindList() or llSubStringIndex() and such you should make sure that you have double memory available. It is of course meaningless to have lists if you cannot use LSL lists operations, so if your code takes let's say 14K of memory, your list (or string) maximum size is not 50K but only 25K. With this understanding, using lists is just fine, moreover meaningful data-driven programming would be very hard to accomplish without them. I wouldn't worry much about a list of just a few variables, like for instance 5, whatever these variables may be, unless very long strings.

You actually paid for it??

Spoken like a C adept Arrays are actually a very low level of memory management. Even in C++ if you use STL you don't really need them.

The only reason SL scripts are called "scripts" is because the LSL language they are written in is not portable to a platform other than the SL server. In all other aspects it is a full-featured object-oriented programming language. The key word here is "programming". Attempting to learn a computer language without basic understanding of computer programming fundamentals is a way of frustration and failure. So I would suggest Programming 101 at a local community college.

Your "network" is poorly designed to begin with so you should prolly redo it. If don't know how, pay someone who does. Let's consider this. The Internet is just a bunch of servers and routers and user stations. You take out any part of it and it is going to adjust very fast and will do without (unless of course you take out all DNS servers but this is not going to happen any time soon). On a smaller scale, the SL is a grid of servers, talking to each other all the time. But if several servers go down, it affects only the regions they support, not the whole grid. On an even smaller scale any script talking to other scripts, either local or remote should gracefully handle a situation when there is no one to talk to. In such case it may for instance switch to a stand-alone mode. Yet you don't owe anything to a customer and LL would not get involved.

Can you possibly quote a source for your "1000" number? Nicely rounded numbers kinda always look suspicious without an attribution.

That is exactly right: so long as the central server remained rezzed. And that is why it is not totally-reliable. True, cases when both communicating objects simultaneously (within the meaning of the protocol) change uuids are rare but it might happen and if it might happen it will happen

https://marketplace.secondlife.com/p/Scripter-Resource-Kit-A/1932506

#2 is not trivial at all. Staff members could be in another sim. There is no inter-sim communiations between objects except for email. Object email requires knowledge of objects keys (uuids). As an object key, in difference with an avatar key, is not static and changes with each rez a totally in-world reliable handshake protocol cannot be implemented.

When making my MPV series vendors I considered checking a gift recipient's on-line status prior to delivery and decided that while it may appear "advanced" it is actually counterproductive. What is a vendor supposed to do if off-line status is returned? There are only 2 things it can do: (a) refuse the gift purchase and refund the money to the payer or (b) store the recipient key and product name and keep checking when the recipient is on-line. Option (a) would only hurt vendor's owner receipts so totally out of question. Option (b) would create more problems than it solves. A vendor would have to keep the above strided list and keep checking on-line statuses. What if meanwhile the merchant replaces products in the vendor? Or what if for whatever reason the merchant disables the vendor altogether? All this could of course be addressed one way or another but adds unnecessary complexity. It is much simpler to send immediately and if a giftee doesn't receive either the giftor or a giftee can always contact for redelivery. Where the on-line status is really needed is not in vendors but in ad boards and business alarm devices.

Would it be possible to make a new LSL function which would be just a wrapper for llRequestAgentData() ? This function would consider OP-suggested flag and nothing else in deciding whether or not to call llRequestAgentData() or return false.

Keep forgetting that everyone in SL is a superhero:) In real life however "[t]he M67 can be thrown 30 to 35 meters by the average male soldier. It has a 4.0–5.5 second fuse that ignites explosives packed inside a round body."

You are not going to throw your projectile by hand with a speed greater than 10m/s and even for that you should have an enormous strength. So discounting deceleration, which should be negligible, it will take your hand grenade 4 sec to fly 40 meters. so put on timer for 4 sec and llDie() after it. There is no unreliability in llDie(). what you've heard but didn't understand is that it takes undetermined number of microseconds for a server to fully process llDie() and delete the object so some code lines immediately following llDie() in the script still can be executed. That is why it is recommended to follow llDie() with llSleep(0.5)...that creates a time buffer for an object to die peacefully without executing any additional code.

I would submit that reading from notecards is the second most elegant way because that's what data-driven programming is. The most elegant way would be to write an API module, that would define messages as a list of strings and ship them to the processing module. However if you're making it for sale, experience shows that most users are unaccustomed to APIs and are afraid to modify anything in a script, so in such case I'd say notecards are the best bet.

Would disagree, Lucinda. There is nothing "bad" about this script, it has no gasping holes and it doesn't eat up server time with inept code. It is...hmm... just simple, no options, no thrills Actually it is on the good end of what one may get hunting for free scripts. And that brings up a point for Eli.. so @Eli. You are a business owner. Looking for L$0 items regardless whether scripts or something else is the best way to ruin your business. Anyone telling you of success without investing some money is either a fool or tries to make a fool out of you. That's all there is to it. As to the question itself, as was suggested above, deed to a group. The receipts would be distributed to group members as dividends by LL. If you want to distribute yourself, either buy a good tipjar with applicable options at the marketplace or have a custom script written for you. I wouldn't charge less than L$5K for a good custom script, but there are cheaper scripters.

Hey, I'm the one who told him to write an RFC for whatever his idea might be. Not my fault he wrote a bad one... maybe it would improve with age For now I still don't know what the device in question is... yeah prolly something modular. The point however is that there is nothing wrong with posting a well-defined RFC for a product, as you seem to imply. Done all the time in the industry and I don't see any reason why it would not be permissible and moreover welcome in here.