Jenny Siddeley

The affirmation that increasing the limit to 128k will make things less laggy may seem unintuitive, but ultimately this is true. The amount of lag isn't directly related to the size of a script. In fact, having a limit at all (even 128k) makes no sense when you can almost have as many scripts as you want inside a single prim, which will all run at the same time when a single script will be limited to one event at a time. And even a cap on the total memory used by a linkset wouldn't be perfect because then you might force many scripters to use several linksets listening to each other (sounds like a nightmare if you ask me). An idea could be, however, to have bigger scripts use more Land Impact just like having several scripts do? Also, as Strife suggested many years ago, LL could have scripts use 64k by default and make llSetMemoryLimit finally relevant by allowing it to also increase that value, rather than just decreasing it. Personally I like that idea.

If you just copy/pasted, the compiler is probably asking for one more } to close the default state at the end of the first script. An easy oversight.

You put a comma instead of a dot in the last float value, it should be "0.0" .

As you've found out, the name of a variable of any kind can't be a variable itself. To create a list, just type : list MyList = []; Of course, you can replace MyList by anything you want when writing your script but that name can't be a string variable.

I think he meant the llOwnerSay line which is being displayed in chat like any other llOwnerSay if RLV is off completely, which would still be displayed even with a relay. And I don't think it's possible to prevent it from being displayed at least once (to check if RLV is on or not), you can only filter it out once the script knows it's off. I haven't checked the RLV updates in a while though, so I could be wrong.

Optionally you can also decrement idx if it's higher than 0, and if you want to remove the extra space at the end.

Last week there was nothing left on 258 at one point, and the highest was 257. And now back to 90 millions on 258! I think part of it comes from the people who accumulated a lot of L$ on the lower rates and moved their orders up, there's not much left between 248 and 257 now though, but those rates sure keep getting thinner and thinner. Added to big sellers, it can move up pretty fast even without any help from LL.

Interesting to see how some people assume there can't be any games at all because of this new rule. If they really have skill games, they can get approved by LL and keep it running the same way as before. If not, they can have the L$ payout part removed from their games. The games themselves are not going anywhere.

From that point of view, there are no solution that does not include a "loss" for somebody at some point. Also in that case, LL is not stealing your bike, in fact they will be offering you a whole new and better bike, while allowing you to keep your old one. If and when you will switch from the old to the new one is entirely up to you and the users as a whole, not LL.

I don't think anyone believes SL is going to last forever, it's pretty obvious that on the long term SL2 is going to progressively replace SL but that's going to take years after SL2 initial release. Then SL will be closed once the big majority of people and businesses has moved to SL2 and there's no point keeping it up. Which then shouldn't much of a problem. I don't think SL was going to last forever regardless of LL making a new gen SL anyway, the real deciders are the people, not LL. If everyone gets bored or decides to move somewhere else, then SL will be closed, but before that, SL closing is very unlikely. As for now, we still got years to spend and enjoy in SL, we still got years to make our purchases worthwile, to have our newly created products being enjoyed by others, etc... absolutely no reason to panick and stop everything. At one point it will obviously slow down and stop but it's not going to happen anytime soon. Like someone else said, there's no point stopping to live just because we know we're going to die one day.

You can't do mathematics when creating global variables, so in this script color_blended will always give an error, and is not actually needed since the calculation is done in the llSetColor function, I think you can delete the color_blended line completely. Also you have to specify the face to be colored, and close the second parenthesis at the end of the llSetColor function: llSetColor(0.5*( color1 + color2), face); You can replace face with the face number, or with ALL_SIDES if you just need to change the color of the whole object. With those corrections you shouldn't get any error, although I'm not sure how the color1 and color2 variables will be filled, so far this script will only turn your object black, you might eventually need a listen event if your objects are not linked.

I assume you made sure "added_prim" is the correct value for the link number so the only thing I can think of is the rotation of the rezzing prim/linkset, if it is rotated even just slightly, it might be the reason. Don't forget the position in llRezObject is relative to the world (ZERO_ROTATION), while PRIM_POS_LOCAL will give a position relative to the linkset rotation value, so chances are it's gonna be different if you rotated the linkset.

Strange but to be honest, when it comes to object inventory, nothing really surprises me. :smileyhappy: About it working in the state_entry event, I think it was giving you the debug message because you were making a copy of your object, so making a copy of its inventory too, which also takes a fraction of a second before it's ready. If you try adding your script after the script supposed to be turned off, you shouldn't need a llSleep function in your state_entry.

Your script will detect a change as soon as another script is added inside but the contents are really updated a fraction of a second later, so it might be better to just add, if possible, a short llSleep function at the beginning of the changed event. As short as 0.5 or even 0.25 should do the job.

Merchants getting instant cashouts were using third party cashout systems, as far as I remember LL always took at least 3 to 5 working days when it was faster. Now it's better to expect it to take 7 working days (saturday, sunday and holidays not counted) and organize ourselves around it, which is not very complicated to be honest. Being able to pay your bills is your responsability, not LL's.