Erik Verity

Maybe I am thinking too simple but: In Object mode, you see all of the objects in a scene. In Edit mode, you can see and edit only the object that was selected while in Object mode. Sounds like you have an extra object that can be selected and deleted in Object mode.

This was the subject of a disagreement in this forum in an earlier thread. It will depend on what is important in a case by case basis. I'll repeat a method I prefer: only allow a single user at a time for an easy remedy if multiple, simultaneous users are not necessary. Do this by assigning the variable value inside the llSetTimerEvent() function, and checking it first when clicked. float timerValue;default{ touch_start(integer total_number) { if (timerValue) { llDialog(llDetectedKey(0),"/nSomeone is using the menu.",["OK"],-10000); } else { //Send menu and whatever else you want to do llSetTimerEvent(timerValue = 30.0); } } timer() { //Remove/disable open listener and anything else llSetTimerEvent(timerValue = 0.0); }} Just include the variable assignment everytime the timer is set, including inside your listen event handler. You could add a check to handle cases where the active user clicks it again if you like. Handling more than one user at a time can get a little trickier, but not too hard to use a list. ETA: Actually your method for multiple users probably is best.

Convex hull is not a "trick", nor is there a "prim allowance" per region or parcel anymore at all. There is a land impact allowance only, and objects can use the new accounting system or the old accounting to determine its LI. Setting a standard root prim to prim type CONVEX HULL is the means to opt in to the new accounting for the whole linkset (along with physics results from the setting). With mesh, the new accounting is always used, even if the root prim is prim type PRIM. No matter which accounting system your object is using, its LI is not a value that will change depending on where it is checked from.

Sassy Romano wrote: The effort would be better expended in educating those griefer script writers, the script scanners that tell you you're wearing xxx KB and are thus lagging the sim when in fact you're using mono compiled scripts which always report as 64KB regardless if they even just using 1KB, yet the 16KB LSL script appears better by comparison when it's not! I've tried educating a few, even pointing them to the wiki where Kelly Linden states that mono scripts only use what they need but no, they insist that the script scanner cannot be wrong. We know that the function returns 64KB, only because it knows no better. I refuse to waste my time adding in unnecessary code to fake a lesser used figure (which isn't needed in the first place!), just to appease some retarded script scanner, when doing so could subsequently cause a script with dynamic memory requirements to blow up later down the line. My customers don't appreciate that. I agree with part of this. Why is an unmutable immutable chat spammer script allowed in the script library? Wouldn't that be a TOS violation itself, no matter what reason someone might want to use it? I also agree that other scripts can't tell exactly how much memory your scripts are using, but they can tell how much is reserved for your scripts. I don't know what kind of impact there is for reserving memory the script does not need. I don't think it is fair to call a script limit a fake figure since that really is how much memory would be reserved instead of the full 64KB. It's also not just scanner scripts that use that figure; it comes from land controls. Can't really blame land managers for using the tools LL gave them. Also, if it really is a small script with little or no dynamic memory needs, it doesn't take much time to get and set a reasonable limit. It gives your product a quality boost IMO. If your script has dynamic memory requirements keeping you from setting a limit, then you can't claim that it isn't or won't be using the amount being reserved. I can see playing it safe if a dynamic memory requirement can be hard to predict, but it is possible for the limit that is set to be dynamic also. ETA: At least I believe it is possible - haven't tried it myself but I don't see why not. ETA again: lol ok, FIFY but I'm not awake enough to add humor on purpose. What slipped in unintentionally will have to do. :matte-motes-big-grin:

I have noticed two things that causes a snap back to zero (most likely other things can cause it as well): Using more than one state - upon re-entering the default state, the snap back would happen. I don't remember if I also reset to ZERO_ROTATION inside the state entry or not, but I might have - I believe it was happening either way; Upon reset of a script in the prim - doesn't have to be the same script that is setting the rotation. I was resetting a script to release animation permission when an avatar stood which then caused the snap back even though it was a different script.

Guessing that the link numbers in your linkset have changed, and the script is setting a sit target using llLinkSitTarget. The animation only needs to be in the inventory of the same prim the script is in, regardless which prim is sat on.

If I were informed of that acronym it was long enough back that I just don't remember it, although I suppose I could have found it online if I looked for it. The earlier languages were before my time, but then so was Basic and Visual Basic technically. When I first studied VB it was .Net with the boasting of being recreated as object-oriented as opposed to its procedural origin. I do realize the name had no relevance to not being object-oriented, as there were no . languages back then to compare with. I believe Java was the first . language developed (correct me if I'm wrong). @Peter: For learning/teaching programming (and animation), have you seen Alice?

I would add to what Rolig said at the bottom of her post. Any tenant close to their limit can go over unintentionally just by rezzing something with an LI higher than they realize while it is in their inventory. They might have to experiment a little bit to decide which things to keep rezzed. If they get all of their objects returned automatically, that easily, (and risk a ban too), they will probably look for a new home. I can see having limits and enforcing them but I'm not sure if automatic bans and quick auto-returns should be used against rent-paying tenants.

Actually, Nova could have added still another "No". The reasoning behind the 'Basic' name is because of its use of basic English keywords. In wide usage now is Visual Basic.Net which, as one of the powerful and (arguably) equal .Net languages using the CLR, is 100% object-oriented.

Actually, yes. Cashout is broken right now. The system was sending out duplicate payments and of course that had to be stopped. http://status.secondlifegrid.net/2013/10/09/post2076/

Actually, you didn't catch the significance of the notification requirements - it is illegal to takedown content for the reason of it being infringing without disclosing that as the reason to the party having their content removed. Service providers are also required to keep records of those whose content is removed as infringing IP rights in order to identify repeat offenders. I know you have said in other posts that they ignore repeat offenders, and that's why I argued it. If you believe that, you should reporting it to the law, not simply claiming it on a forum.

I never said they had to host anyone's content, nor that they do not have that right. I AM saying they cannot sell the services to a specific party and then just change their mind (there are ways a user can place a large investment with SL beforehand) - that wording protects them as it does most, but they publish guidelines for a reason. You can't just sell someone your car and then decide you won't sell it to them after you take their money either. Red flag takedowns are not simply taking the word of anyone who happens to think "that's an obvious infringement". A user creating cars cars called Mustang or Chevrolet who are also not accounts owned by Ford or GM can be a red flag takedown. I've contested this argument with you before, and you still haven't read Title II laws yourself, evidently. DMCA protection absolutely does come with restrictions of minimum requirements, and protect against open ended actions.

Yes, it does mean that. Most of the time, those with content removed can sue for damages when their content is wrongly removed. That is the reason that there is a counter filing process - to allow it to be restored. Even a wrongful takedown can be used to identify someone as a repeat offender, which can subject them to further restrictions and actions. Creators are allowed to protect themselves from this. Service Providers are also required to inform them when IP infringement is the reason that their content was removed. LL was never the party who would file in the first place. You really should take an hour and search what the DMCA process is and how it works.

Dartagan Shepherd wrote: Yes it most certainly is legal for a company to accept, decline, reject or remove any content for any reason they see fit. I'm not sure why you would think otherwise. They don't need to claim that it's IP. When selling a service, including and especially MP services, there are terms and legal agreements going beyond simply selecting what you want to allow or not. You cannot sell a service or product, require an investment from the buyer, and then change your mind afterwards. It's not the same thing as simply allowing what you want and disallowing whatever you choose. There actually are guidelines that LL publishes to decide this anyway - basically, they took that privilege of choosing already, and published their guidelines. Dartagan Shepherd wrote: Although if they did claim that, they're still within their rights. They now have legal rights over the content. You have to discern whether or not you are referring to DMCA here or not - you are mixing up different subjects. DMCA laws and eligibility guidelines are also published - and they strictly prohibit accepting DMCA takedown requests from anyone other than creators and their representatives. The rights LL is claiming now do not claim to take away yours as a creator, - they do claim to have as much rights as you though. For a completely different subject (which I won't try to start other than this mention), I am not sure they can still qualify for DMCA protection themself because their far-reaching hand now, but that would be up to others to figure out and decide. Dartagan Shepherd wrote: And they're certainly capable of handling those bazillion objects, they already do handle them in many ways every day. "handle" ? There is no way to "handle" content manually without a million or more people. There really shouldn't be a disagreement there either if you take a few minutes to search and find out the reason DMCA was enacted. Its entire creation came shortly after the birth of the internet era - when OSPs had to approach the US congress for help and guidance after proving that it was impossible to comply with present copyright and IP law in the new Digital Age. If you do just a little bit of reading, you will find that that last statement is completely false.

Dartagan Shepherd wrote: It's LL's world. Everything is allowed at the companies discretion, especially now. Answer: LL puts down the breakfast burrito and removes the content in such obvious cases. No DMCA or legal battles needed. And that would be illegal. There really is no such thing as obvious cases - what you think is obvious could very well be someone with permissions from the creator, the creator themselves with a new name or storefront, or even the possibility that they are the true creator instead of who you might think. Investigating each case like that is not even possible for an Online Service Provider to do with millions (billions or trillions?) of objects, textures, models, etc. uploaded continuously. That's the reason for the DMCA. The law requires them to accept a complaint only from the creator or their legal representative. Any legal battle that might follow is up to the idividual parties; it always has been up to creators to protect their own IP Rights, before DMCA laws and after.

Yes, and you're welcome. You aren't alone - I've been there not long ago. Had to ask a friend what could be wrong when I couldn't get graphics working right just to get told this same thing which made it all work.

Offhand, I would say the options available might simply confused - I've had them look weird like that before after checking and unchecking a few things. Have you tried to simply close the preferences and then just re-open them again to see what the options are? Also, try enabling ultra even if you just change it back to high afterwards, closing the pref's window in between. As long as you have Atmospheric Shaders selected, and your system can support the other options, they should be available to you. To answer your question, the bump map and shiny settings there do not refer to the new materials which are also bump (normal) map and shiny (specular) map. They are the same as the generic bump and shiny settings that were always available from the edit window when applying textures. Most creators only used them rarely, because they just only adequate for very few texture patterns. To be able to see new materials, you need to have Advanced Lighting enabled, which although checked in your screenshot, most likely is not enabled since it is grayed out. I would just try toggling your settings, (the quality slider - between mid, high and ultra), which should enable or disable other settings automatically even though you can check or uncheck them individually otherwise.

Madeline Blackbart wrote: I will admit I am a horrible person with this. I were upwards of 200 scripts or more at a time. To be fair they general seem to be well written scripts and come under the 2mb of run time or so... I think one needs to consider more then just number of scripts but quality. As one script that's poorly written can be as laggy as 10 or more. And this brings the subject back in line with the OP. Number of scripts can very much be a problem also, even when well written. Every script has to be accounted for by the simulator, and takes a slice of time, even if it is empty. When you get high numbers of scripts, even with low memory usage, they start to make a real difference in slowing down all of the scripts on a region. The newer scripting functions that allow a single script to affect other prims in a linkset were specifically created to cut down on the number of scripts; not just their memory usage. Deleting resize scripts really is not very important at all if it only addresses a single, small, well written script. Even with 40 avatars in a region, if each deleted a single resize script they had for an item they were wearing, you probably would not notice any difference at all from a case where they each kept that single script included in their attachment. Deleting them when each link in the set has its own script absolutely makes a huge difference. I have a pair of shoes I consider useless because they are no mod and I cannot delete their resizers - there is a script in each of the prims and I believe they are over 90 prims in each shoe. I bought them when I was new and knew no better. I don't see anything wrong with having a lot of scripts or otherwise being script-heavy sometimes - if we can never go all out once in a while for the purpose of having fun with some nice abilities, there would have been no reason for most users to have ever signed up in the first place. But a lot of avatars in a busy sim can't possibly do it at the same time and expect the sim to keep running.

I do understand the difference you're demonstrating here, and never made any attempt to distinguish between memory use recognized only at compile time and that during run-time. I have seen the limit set a little too low just to have it show using the full 64k and run fine. Considering there is no hint of this behavior mentioned in the wiki, and it could only show up if you set a limit between that (almost surely small amount) between max potential identified at compile time and max possible at run-time, it would be worth editing the wiki to clarify. Every indication is given that a limit set by the script is only for use by script checkers and ignored otherwise; I don't think anyone would normally be estimating a limit in state_entry beforehand in the first place, which might be about the only way to set a value too low and still be unrecognized. Edit: I realize limits are set in state_entry - but it wouldn't make sense to get a useful value from llGetUsedMemory() from there - it kind of defeats the purpose of that function call altogether to try to get a value of memory used before the script has even run.

Without being in-world or right there with you, I can't possibly answer or verify that. I can say that I have tested it myself and know very well that it is true. The limit basically is only for what it shows to be using when checked by land tools, other scripts, checking your av script info, etc. The script will use what it needs. It is also well documented in the wiki - and again, I have tested it myself. Set a limit too low and the script will run fine as long as it does not go over the 64k limit. This is only for mono scripts in the first place - are you using LSO instead? I think you almost surely must be. http://wiki.secondlife.com/wiki/LlSetMemoryLimit Edit: Or are you clicking it a hundred times?

It has not changed, nor is that the way it works. The memory limit set will be honored only if the script can run within it. A stack/heap collision will only occur if it goes over the 64kb limit. If you set the limit too low, it will simply be ignored. There is no problem with a low limit either. Many scripts run fine at only 4k, which I believe is the minimum you can get it to show using. It depends on what the script does; some simple scripts will always run using the exact same amount of memory, some will vary depending on what it needs to do.

After reading that again, carefully, you might be right in that I am misinterpreting it. I can see it being taken either way - permissions system might allow and limit permissions inside the service only, but seller/creator terms are still valid (to the extent they do not violate the TOS or the law). ETA: How deep is my foot after that? I would still say permissions system is closer to abilities even with permissions allowed inside SL - they can still be rescinded if an IP Rights violation is declared. That still aligns it more as a privelege as opposed to a right.

Actually a lot of what Amethyst said is also true - it gets confusing when you have to separate if something is being sold for use by an end user or not - and the meaning of the Permissions System, which only grants you abilities, not legal permissions. You can create content that can be used in Second Life, but you don't even have to go through Second Life to create or sell it unless you choose to. You can always state your own terms when you license something for others to use, but if you use the SL service for uploading/selling content, you have to either choose what other users are able to do with it or accept the default settings. When something is created for an end user inside Second Life, they are granted Right of First Sale if the item is not able to be copied. Full Perm can actually be the most restrictive of permissions - while you have the ABILITY to do more with the content, your legal permissions are only what the creator allows.

The rest of the paragraph is separated with the word "or" for a reason. It doesn't change the meaning of what I highlighted at all. ETA: It simply means the permission system does not grant you any rights to use content outside of Second Life either.

I know I limited that last response a little bit, and wondering if I should have added more. Amethyst Jetaime wrote: This is all factually incorrect [...] ALL factually incorrect? I believe it is ALL factually correct, including this: Erik Verity wrote: [...] Even Permissions is misnamed for what its description implies - Abilities might have been a better choice. You often buy things from a creator with the ability to do things with it that you don't necessarily have the permission to do. The TOS acknowledges that many things will be sold full perm solely to allow builders to be able to use them in their builds without being allowed to redistribute them with the same permissions. In the third paragraph of sec 2.7 Linden Lab and other Content Providers may use the normal functionality of the Service, including the permissions system and the copy, modify, and transfer settings, to indicate how you may use, reproduce, distribute, prepare derivative works of, display, or perform their respective Content solely In-World. You acknowledge and agree that the permissions system and other functionality of the Service do not grant you any license, consent, or permission to copy, modify, transfer, or use in any manner any Content outside the Service. The Permissions system is the name of one of the software's functionality settings, but specifically does not give actual, legal permission to do a single thing.