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.

A common mistake we all do from time to time. You just forgot an "=" in your if conditions. It should be : if (msg == "Fighter") and else if (msg == "Scout")

Nothing wrong with being concerned about losing market share to people who are stealing someone else's work and don't deserve to be merchants. Also, why should they be concerned about the I.P. rights when the authors themselves don't seem to care. Either way, it doesn't make it right and needs to be adressed one way or another.

Don't forget that it's a manual process, the more often people transfer out, the more likely it's going to take more than 5 days. I'm sure you can easily handle switching to a weekly or even monthly transfer rate. Also, transfering more often means more fees and less RL money for you in the end (not much but still).

Alexxis DeCuir wrote: If you had the decision to work at mcdonalds for minimum wage, or work from home whenever you want and make quadruple that.. which would you choose? This is why I rely on SL for my income. The "work from home whenever you want" is not a stable job though, in fact it's not a job at all, LL didn't hire you, if you can make money thanks to SL, that's great, I have a lot of admiration for deservedly successful people, but it can stop anytime, it's out of your control, nothing can give you the guarantee that you'll make as much money as usual the next month, even if you work hard for it, maybe someone else worked harder and took your spot, etc. That's what I meant. And not being prepared for it, or in other words, relying on SL for your RL money income without making sure you can handle earning less if it ever happens, is not a really bright idea. Although the problem here is different, you had to wait 9 days instead of 3 or 5, not only it isn't that big of a problem even though you almost make it sound like you're going to starve soon (especially if you make 4 times the minimum wage, which is really nice!), but I'm pretty sure it's also temporary. In the end remember that you are not losing any money. I could understand a topic where you would wonder why it took that long, but an aggressive message almost implying that they increased the delay on purpose to piss you off, is kinda weird to me. If I remember correctly, they said they're working on making the whole process faster, so it might just be an unfortunate side effect.

To be honest, relying on SL for your money income is not really a good idea... And while I would love it to be faster, all it takes is organization, it's not like you're not selling anything during those days. The amount of money you make in the end is exactly the same, it's not going to change because of this. Personally I never had to wait longer than 5 days and the last time was not too long ago, did waiting 9 business days just happen once or did it become the norm for you? Something's telling me it's just a temporary situation and way too early to complain about.

Sculpties are just unoptimized and very restricted meshes though, my guess is this bedroom set was made the same way meshes are being made, and anyone who made it definitely has the skills to make awesome meshes. Also, most people (especially merchants) can get a payment info on file, it hardly makes meshes "elitist" in my opinion...

To be honest, I'm pretty sure anyone who is an excellent artist and has mastered SL building tools to make awesome stuff will have no problem making good looking and optimized meshes too. It might require some patience and work at first in order to adapt but the idea that mesh is for professional only is really far from the truth... Personally I'm not a big fan of mesh clothes either for now, but globally meshes are pretty nice and, just like sculpties, it won't replace normal prims, it's just an alternative and in several cases normal prims still remain the best choice.

I'm not sure as I haven't been playing with llCastRay much, but I think the answer to your question might also depend on the length of the rays and the number of possible hits for each ray. The shorter and smaller these values are, the more you can have I guess.

The second value inside your llMoveToTarget function is the time it takes for the elevator to reach its target, try higher values than 0.2 (usually a value increasing with the distance is a good idea) and see how it goes.

For me it has been working perfectly for a few weeks at least now, it's fast and no more < 0, 0, 0 > problem.