Ela Talaj

I don't see in which way your mcard differs from a notecard. Seems to me your suggested methods would be just wrappers for writing to a notecard. Writing to a notecard is entirely implementable, uuid change or not (after all, an object changes it uuid as well on each rez) but I doubt LL would do it in near or not so near future.

I can make you the scripts but it would most probably cost you more than L$8K

I'm not aware of a case SL- or RL- wise when a customer would posit satisfaction with a product that does not perform a function a customer bought it to perform. So unless you could cite such instance my opinion would be that any positive review is specific enough because it tells that a product did what a customer expected it to do. On the other hand any negative review which only tells that a customer is not happy is non-specific because we don't know why the customer is not happy: the product did not perform? the customer did not understand how to use it? the customer expected it to do more than the product page specified? the customer had a bad hair day? all of the above? Go figure. By the same token, consumers have powerful means to tell a merchant that a product is overpriced: they go and buys from someone else. To buy a product and then place a non-specific bad review saying nothing of product performance but alleging it costs too much is rather immature and simply should not be allowed.

Sure you can make a periodic scanner (via llSensorRepeat() method) which would scan for an object with a specific name within let's say a 5m sphre around your avatar. If that object is being detected while you're moving around the sim it is a follower.

I've a product just for that

It is possible to send several HTTP responses for a single request, either intentionally or as a bug, especially in multithreaded Java server. Whether or not the LSL http_response event would only fire on the first response and ignore the rest I simply don't know.

And the reason most prolly is L$10 that they charge for each texture upload and would lose if one could display textures from a webside

I've a product like that in the Marketplace. https://marketplace.secondlife.com/p/Public-AnnouncerAlarm/593155

The problem with responding to reviews is that LL does not give enough detailed reason categories to select from when flagging a review. There should be at least one more category: "non-specific". The reason to review a scripted product is to tell other customers whether or not this product works as is stated in its description page. The review as per your quote: " Nice freebie but not free Posted xxx xx, xx by xxxxxxxx 1 star For this price i waiting a good quality scripts and build but all is like freebie.. Want my money back!! " does not even address this matter. After reading it I still have no idea whether the product works as advertised or it does not. What it presents is a customer's opinion how the product should be priced, which is not customer's business to speculate upon. Therefore such review is totally worthless and a merchant should have an option to flag it as non-specific.

Script memory usage depends not that much on a code but on types and quantity of data the code operates upon. For example, a script may include 10-12 lines of code for a couple K of memory but would operate on a large list containing 20K of data. Do not forget that in LSL all function arguments are objects passed by value as there is no concept of pointer. That includes LSL methods themselves so for instance every time when llListFindList(mylist, [findthis]) is called it creates a copy of the original mylist so the memory usage increases while the method is executed. This considered, terms normal memory usage and usual memory usage are rather meaningless unless one identifies a specific application.

You can trigger a sound on "bump" but you cannot trigger a gesture. There is no LSL method to start /stop a gesture

It is indeed possible for an object to bring up a menu from another object. For that the objects must communicate with each other via Say/Listen mechanism. A menu is just a list: list menu = [button1, button2,... button12]. So on touch object B sends a query to object A via llRegionSayTo() and object A responds with converting this list to string and sending it to B via the same llRegionSayTo(). The B converts back to list and displays to user. Now depending on distance between objects A and B, a button pressed by user in the B-object menu could be directly responded by object A. This endevour however is not totally trivial because there must be an original handshake between objects A and B.

It may depend on the value of TIMEOUT_SELECTION variable. If the timing period is too short may start lagging behind. Btw, llSetTimerEvent(STOP_TIMER) is meaningless because the only value that stops the timer is 0.0 so if STOP_TIMER is set to some other value it is a misleading name, and if it is indeed 0.0 you don't need a variable for that.

I have my email address in my profile and encourage regular customers to use it. As for large custom scripting projects which may cost hundreds or even thousands USD, I would not start working on such project unless a potential client submits specifications by email.

Sorry Pamela, I quit reading upon encountered this sentence on the very first page: "And many regions in SL are usually emptier than gun-crazy crap-rocker Ted Nugent’s skull" A writer of this level cannot possibly come up with anything comprehensive.

If you're correct in your understanding of the MP database architecture and I think you are, we would be looking at a major development to support an extra key even for a native system not to mention COTS. Modifying tables is a half of the deal. The whole DB would have to be re-optimized, that's another half. So I wouldn't hold my breath awaiting such a feature even though it would've indeed been useful.

I'm not clear what the problem is. It is rather trivial to make a script that would on owner's (your) touch prompt for a name and when you enter the name in chat or on a specific channel, store it. When a non-owner touches the box, it will send a message to their HUD on whatever high channel with the name to search for. What I see is a problem is that you may misspell the name or enter it in the wrong case so the object is not on the parcel at all. A check if the entered name is indeed valid is where the problem is because a sensor will return only 16 closest objects so the result is always inconclusive. There are ways around it but they are not trivial.

If you have specific scripting projects in mind I'd be happy to consider and provide you estimates upon learning the details. However, keep in mind that the only reason the LSL language is called "scripting" is because it is not portable to platforms other than SL (and similar 3D grids). Otherwise it is a full blown object-oriented language and SL "scripting" is a bona fide real-time programming with all its pitfalls. Accordingly most scripts of levels higher that trivial are done by professional programmers who charge professional wages.

When you call llSetTimerEvent() you basically request the server OS to add your script to a software timer queue. There are several of these queues fed from OS software timers: 1sec timer, 100 msec timer and in certain cases 10 msec timer. All these timers are in turn fed from the hardware clock, which is much much faster so they just count the ticks. When for instance 1sec timer counts enough ticks for 1 sec to expire, it checks the queued elements and subtracts 1sec from their timing periods. If some now have zero, it sends signals to those scripts (that is what the script timer event receives) and restores the original timing periods (which does require some queue manipulations). It may seem that the OS software timer's accuracy would depend on how many scripts are queued but that is not correct. In real-time programming there are several ways to construct timing queues in such a way that it does not matter how many elements are queued. What matters is that each task in the server is assigned a certain priority and those with higher priorities pre-empt lower priority ones. Application timers are usually medium priority so when the server has more important things to do the timers may be pre-empted and don't get to run unless those more important things are completed. That is a primary cause of time dilation.

A private estate manager can tell you an individual script run time in msec. On mainland this tool is not available. You can retrieve mainland sim statistics including total scripts runtime within the frame via Ctrl-Shift-1 but it's not very useful as pertains to all scripts run in the region. Usually sims with high traffic would be laggier due to the cost of rendering avatars which usually requires server resources much exceeding resources required to run scripts.

An LSL "event" is basically a signal processing function. When you declare an event in your code you request the server OS to send a signal to your script when the specified event happens. This signal is then processed by the code which you write within this event body. The OS will call the signal processing function with certain OS-defined arguments just like a user function is called with user-defined arguments. In the touch_start event the argument is the number of touches the OS registered prior to sending the signal. Usually it would be 1 but not necessarily. In rare instances it may be more than one. Just like in a user-defined function argument(s) must be of specific type(s) but can be called anything: touch_start(integer x) is perfectly legitimate; doesn't have to be touch_start(integer total_number)

There is no difference whether a strided list is static or dynamic. It never takes more OS resources than a regular list for a simple reason that for a compiler there is no such thing as a strided list, it is a purely logical concept for a programmer to group items in regular lists.

You're correct. When using sit, an avatar's position relative to the animating object is determined by a "target" point which may be modified via a script. When using attach the relative positions of the avatar and the animating attachment are determined via an attachment point, which may be modified only manually via editing the attachment.

Have you thought of interactive questionnaire? I have a new product which does just that. It is fully field-tested over several months by now but not yet listed in the MP. You can call me in-world about it.

I have a book with preloading pages textures.