Qie Niangao

Sharie Criss wrote: If you read the documentation you linked to.... "the decision to allow or block the request is persistent" That fits 100% with my statement Once you have permission, you have it for everything requested, you don't have to keep requesting it over and over. It doesn't actually work that way. I too got a little confused about this at first, and even after I figured it out, I couldn't come up with improved wording for the wiki articles. In short, an Experience-enabled script still has active permissions for only one agent at a time. If it wants to switch to another avatar in the Experience, it must switch that permission target, too. The script can still use llGetPermissionsKey() to find which agent for which it currently has permissions, so it knows when it needs to switch, but when it does, it needs to call one of the llRequest*Permissions functions. On the other hand, that bit about Estate Managers and God Mode users always seeing the permissions dialog seems very odd indeed. I can't actually test what that means because I'm not an Estate Manager (my beta Experience is deployed only on Mainland). If that means what it seems to say, maybe Experience scripts really do need to check to see if they can get away with calling only llRequestPermissions, not llRequestExperiencePermissions, when deployed on Estates, despite the extra code needed for that logic. (I actually had all that code in my script at one point, then decided it was wasteful and blew it all away.) There's not a lot of sample code yet, so I'll post a question in the beta forum and see what folks are doing. [ETA: Oh, I forgot to mention, what seemed to be the issue at hand was the way FIrestorm can revoke animation permissions on stand, so I took the "always allow" aspect of Experience Tools to refer to scripts being able to assume that they retain permissions they've been granted; I wanted to point out that in fact Experience scripts have even more vulnerability to those permissions being pulled out from under them by the user revoking the whole Experience, and that's still correct. I have always thought that not getting a run_time_permissions() event when permissions are lost is a design flaw of the SL permissions system, and so it may be of interest that Experience scripts get a related feature, the experience_permissions_denied event, which is more useful than it sounds.] [ETA2: Actually, never mind the idea of using llRequestPermissions instead of llRequestExperiencePermissions; I was misremembering something, and that just won't work. One can, however, avoid requesting experience permissions if the last avatar to use the script is the same as the one it wants to operate on again, and that may be a good thing to do, assuming that avatar hasn't revoked permissions in the meantime. I doubt that actually saves any processing, and certainly adds to the code size, but would be worth it to avoid bugging an Estate Manager over and over, if that really happens.]

i tryed it in the terminal but noting it try's to open the prgram Those words do not a sentence make. I'm not playing grammar nazi here, but allowing for misspelling and random apostrophes, there's still just no sense to be made of that text. If you want more help, you'll likely have better results quoting what you typed to the command prompt and what output the program generated in response. if i dont get it working in backtrack, Could i edit the viewer and use it on my server and access it via browser ? The viewer is not an in-browser program, so I don't know what this means either. Maybe you could get it to work with something like Splashtop streamer running on your server and the Splashtop client on another machine's display, but that's going to involve a lot more configuration (and a display-capable server, at least), so at some point, if you have reasonable internet connectivity and a decent Android device, it may be more cost-effective and a better experience to just use OnLive's SL Go

Sharie Criss wrote: Experience Keys goes even farther with the "always allow" if you read up on it. Actually it's the other way 'round. Experience permissions can be revoked in the Linden (Experience Tools beta) viewer -- the agent can forget or block the whole Experience. On the other hand, the whole way scripts use permissions changes dramatically for Experience Tools scripts because a single script will interleave many different avatars through different parts of the Experience simultaneously. As a result, Experience scripts call llRequestExperiencePermissions (much) more often than non-Experience scripts call llRequestPermissions().-- but on the plus side, there's no need for a proliferation of scripts each holding one agent's permissions. (To the larger topic, I'm not really sure it's the Firestorm viewer's permission-revocation that's causing the OP's problem. I've never liked that feature because its effectiveness is necessarily so limited by being viewer-side only. Still, it's not obvious why this should suddenly cause the OP problems more than or different from before.)

Try to think of the experience as just a more time-efficient way of playing a skill game.

Bobbie Faulds wrote: Transfer..if it was no transfer...you wouldn't be able to use it and sell or give away what you used it on. [Emphasis mine.] This may be what most befuddles people new to texture permissions, and IMHO is one of the greatest blunders in the design of SL's DRM system. The no-transfer permission setting on a texture affects not just the texture but also any objects on which the texture is painted. (If you look at such an object's contents you can see the kludge that makes this work -- and beware of the consequences of removing what's inside!) The reason this is such bad DRM semantics is that it forces texture sellers to protect their products with EULAs, because they can't use a no-transfer permission for the one occasion for which it would actually be useful for textures, if only it were allowed to mean the same as every other asset type: that the texture itself can't be transfered, but that restriction doesn't virally contaminate everything on which the texture is painted. But it's too late to undo that now. Maybe in SL2.

Amethyst Jetaime wrote: The exchange rate has remained pretty stable for years now. Stable against the US dollar. I suspect, in order to write such a thing, the poster has experienced increased exchange rates against a currency that has itself devalued in US dollar terms -- which would be most currencies, in fact. (Note, I'm definately not suggesting that the L$ needs to be pegged to some market-basket of global currencies -- nor, god forbid, to float. Existing practice managed the L$ remarkably well over the years. I'm merely suggesting how some residents might have perceived L$ deflation relative to their local currencies.)

"Done" sounds so final, but I don't have anything further planned immediately for "VRC's Rail Ring Around the Atoll", which can be started at the VRC Headquarters in Tuliptree. Step inside a telepad portal -- a glass dome topped by a hoverclock -- and then step out to another train station until you make your way around the SLRR. (It's not a game or anything, just a bunch of teleporters, and that's the only permission it actually uses.)

Is it considered griefing or negative ... Considered by whom? If your girlfriend objects, you'll want to moderate your stance. Obviously. If it's the nudey-picture pushers putting up a fuss, frankly, who cares?

ChinRey wrote: SL still is noticeably slower than it was just a few months ago (visiting the same sim with the same computer and the same pref settings) but the speed improvements 3.7.14.29638 introduced means is enough that it is possible again to visit SL with a two or three years old MacBook Pro. [Emphasis mine.] Really? Because I'm seeing rather the opposite in both Windows and Linux. Did you happen to update or install any MacOS patches that could account for the slowdown? (That's not to say there isn't a real tension between SL's graphics performance with ever more realistic content and its suitability for a wide range of hardware, but I'm just struck by a recent decline in performance, when that's not at all my experience on the other supported client systems.)

It seems the Lab realizes they've got it somewhat wrong in Second Life, and are planning to adjust the balance between costs for Land and those for Content in the next-generation platform. In the years since Second Life was introduced, a kind of standard fee (30%) has emerged for digitally-distributed app-store content, so that seems to be what the market will bear. At the same time, the constant decline of sim populations and the emptying-out of Mainland shows that the Land fees in SL are simply too high. The resulting hollowing-out of SL is hurting content creators a lot more than would a higher "tax" on their Marketplace-delivered goods. One problem with hiking Marketplace fees, however, is that in-world distribution can compete with Marketplace, so either they have to impose some direct fee on both Marketplace and in-world transactions (a mechanism they probably won't invest in developing for SL Classic), or the Marketplace fee would have to stay low enough to compete with in-world sales. That could be higher than the absurdly low 5% currently charged, but probably still much lower than the 30% standard. Hence, in SL Classic, the Lab probably can't replace the Land-based revenue with enough Content fees to be able to really slash tiers. On the other hand, if they do nothing, the bleeding will continue, and they could lose the whole business before the new platform is profitable. The best I could suggest at this point would be to raise those Marketplace fees as much as they dare, trim a bit off Estate fees where they can (free OpenSpaces? something), and some kind of Mainland retention bonus that doesn't encourage existing landowners to tier-down.

You can create a jira and make clear that it's a feature request, not a bug report. (This link might take you to the form after a login, I hope.) As set up here, jira is not exactly friendly to end users, but with enough patience, it works.

Unfortunately he didn't issue anything except vague threats. In that case, I really don't think this is something to pursue. Maybe, if he were not blocked, he might eventually get specific enough that you'd have evidence worth bringing to the attention of RL authorities. Even then, though, it would seem to depend on the terms of the threat. It could be serious enough, but I mean, if he's demanding the L$ equivalent of fifty bucks to stop him from showing Photoshopped screenshots to the Internet equivalent of your dog-sitter, it would be pretty difficult to justify spending the time to take a report.

One thing that's changed in the years since this thread started is the availability of LSL functions for returning objects. So, if the offending Strawberry is rezzed free-standing, not attached, and if it's on a parcel with appropriate ownership, a script might run a sensor to find it, then use llReturnObjectsByID to get rid of it, without anybody having to capture the thing in the Build Tool.

Right, we're venturing into yet another case where too much functionality has been conflated into a single operation, in this case, "sitting." The primitive you really need here is the ability to move around an Experience-engaged avatar completely at will. We really don't need all the rest of the "sitting" baggage (e.g., tacit permissions, and even the existence of a sat-upon object), but all that stuff is bundled together, presumably because it's all handy to have for actual seats. I don't know what would be the easiest way to disentangle this long-confounded functionality now. Maybe, as we have a TempAttach, we now need a TempSit of some sort. [EDIT: Or, Plan B, we add a full avatar positioning and rotating functionality to objects that are TempAttached. On the plus side, maybe, that same functionality could be acceptable for *all* attachments, not limited to the temp ones. Off the top of my head, I'm not seeing a downside, although it is a very significant expansion of the attachment functionality. Practically speaking, though, there's a lot of pre-existing sittable content that would need substantial re-work to conform to the geometry of attachments -- whereas a "TempSit" would be easier, but still require new scripts, not re-use of existing scripted sittable objects. Also, an expansion of attachment semantics is falling into the same trap as the age-old overloaded "sit" semantics.]

You need to decide what is supposed to cause all this sound and animation to start, and on whose avatar you'll be playing those animations. Simplest case, you might trigger it all by a touch_end event, which is handy because then, in the touch_end() handler, the llDetectedKey(0) will refer to something useful: the toucher. That way you'll know of whom to request permissions, and once you've got permissions, llGetPermissionsKey() will have the avatar you want. (You may later want to handle the case of that avatar leaving the sim before you play an animation on them, and I suspect you may end up with a more elaborate timing loop instead of the llSleep()s, but you'll want to get something working first.)

cibernut wrote: I suppose using building tools in future would pose even more probs Not really. The in-world building tools don't really cause much extra demand on rendering performance, and very little on network because as much as possible is done within the viewer before syncing with the sim. I'll be surprised if you see that much difference with a 64-bit viewer on your rig. Increasing cache may help, but it's not going to be night-and-day for you either. Looking at your machine spec, it's really your graphics card that's going to be a bottleneck, assuming you have enough network to keep it fed. That HD 5450 isn't too dreadful at 2D graphics (like video), but it's pretty gawdawful at 3D. Check it out on http://www.videocardbenchmark.net/gpu_list.php and compare it to even the GeForce GTX 650 mentioned earlier: your card is like nine times slower on 3D operations. None of this is to say Second Life doesn't suffer by making such heavy demands on graphics hardware. It's a problem, and not one with any easy solution.

What is so hard to understand about "don't ask people for bites who haven't given prior permission to be involved in the game"? If you have that permission, granted a priori without anybody having to ask for it, then it's cool. Otherwise nothing else about the "game" matters to civilians: we're gonna hate it, just as we hate Bloodlines and all the other spammy scammy scum that's come since. Again, you all may like playing vampires, or vampire victims, or whatever, and that's perfectly fine. Others of us, however, find the whole blood-slurping mythos utterly laughable, excrable, or offensive. Please cut us a break here and limit the roleplay to other pre-enrolled players. Or ignore our opinions -- but let's not hear how our opinions are too tough on your delicate sensibilities. You asked, after all. And let's not hear about how it's "0 like Bloodlines but vampires bite." If it adopts the exact same scummy form of coercive "bite" marketing, it's garbage, and absolutely nothing else about it matters.

There are several problems here, but I'll stick to my personal bugaboo: One other thing about script memory that most people don't realise is that scripts ALWAYS use 64k of memory.......unless you manually specify for them to use less memory. Limiting the memory where not necessary is a great way to reduce sim lag. http://wiki.secondlife.com/wiki/LlSetMemoryLimit In fact, Mono scripts never use more memory than they need, nor do they "allocate" the quota that is reported to external measurements. llSetMemoryLimit merely adjusts that quota from the 64KB default, which of course causes the script to crash if it tries to allocate beyond the quota. Hence, it only reduces memory usage or lag to the extent that it prematurely crashes some scripts that contain it. (They're rarely relevant anymore, but non-Mono, aka "LS0" scripts, always use 16KB, no matter what. Within that 16K, they're quite a bit more memory-efficient than Mono scripts, but that comes at a dramatic performance penalty for anything compute-intensive.) Here's a completely unrelated suggestion: Inline single-use user-defined constants. You know, the constant values with ALL_CAPS variable names we all inherited from programming in languages that preprocess source before it goes to the compiler. In LSL, there's no (native) preprocessor, so those are all global variables and use memory accordingly. I generally leave some ALL_CAPS constants in comments at the top of the file, as tags to find the corresponding values similarly commented in the program itself. (This tip obviously doesn't apply to source that's only shown in an external editor and passed through a preprocessor on upload to SL.) Also, here are a couple of sources in the wiki that may be of interest: http://wiki.secondlife.com/wiki/User:Becky_Pippen/Script_Memory_Limits (from back when there was a plan to limit total memory use on land and in attachments). http://wiki.secondlife.com/wiki/LSL_Script_Memory (From personal experience, I can vouch that it's very difficult to get consistent numbers for these measurements, but they give some idea of relative memory costs.)

Tarina Sewell wrote: I just paid the tier and it will not be due until 9/13/14 This is Mainland, so the buyer assumes responsibility for the tier as soon as the land is purchased, although it is billed in arrears. You, too, will be billed for it again at the end of your current 30-day billing cycle, because you owned it at one point in this cycle. (Also, this sort of post generally belongs in Parcels for Sale: Mainland, but I'll let somebody else worry about asking for it to be moved over where somebody in the market for land might actually see it.)

SaraCarena wrote: What is your draw distance set to cibernut? That`s a BIG factor in scene drawing. Right, and not just drawing, but also download: It's necessary to make the best of a not altogether optimal situation. The thing is, stuff is loading much faster now that it was a year or so ago, before the Lab invested considerable resources in development projects to improve what was a really bad situation. It's still nowhere nearly as fast as it was when I began SL, back in 2006, and creators used much fewer textures on simple parametric shapes (prims) that download hundreds or thousands of times faster than Mesh or even worse, sculpties. The thing is, the world was very much simpler and less impressive back then. Stuff was so sparse that we could even afford the wind flexing the Linden trees. Now, the world is so much more complex (who even uses Linden trees anymore?) that the prim's massive download advantage is more than offset by the fact that their rendering geometry is slightly more complex than comparable Mesh. Still, the gradual filling-in of detail described here certainly seems to be network delay. Best thing for that, for any given bandwidth, is reducing the draw distance, as suggested. It may be of interest that SL was founded by an ex Real Networks guy, and derives from the then-common assumption that by now bandwidth would be too cheap to meter -- that everybody would have gigabit connectivity to the cloud for negligible cost. Obviously, we're still waiting for that, along with those flying cars we were promised.

TheG0t wrote: My best idea was to remove any reward with biting and add the ability to simply suck a little physic energy out of people with out them even knowing or having to take part if they lack the skills to talk a person into sharing blood. So your "best idea" would only work on a platform other than SL. Might be a good idea, at that.

The only acceptable approach is for the victim of the bite to have already enrolled in the game, voluntarily, without any prompting of any kind, before a bite can be offered. Anything else is spam. Granted, for purely commercial reasons Linden Lab has long elected to allow such spam, but it's still extraordinarily offensive to some SL users. You may like vampires and all, but you need to keep in mind that some folks find the prospect of a vampire bite on a par with being used as a human toilet. Just don't do that to those folks.

Hmm. That's a pretty common error anyway. Are you sure it hasn't always happened when Dropping that particular item? I suppose it's possible that something has changed in the retention of permissions by scripts when detached. It wouldn't be a viewer-specific thing. Those are sim-side errors, usually generated by buggy scripts.

AnneMarie Alcott wrote: ... a lecture about it being a real museum. Okay, that's a dead give-away: you were being trolled. At first I thought it was somebody who was looking for a virtual sex partner into humiliation-play, but this "real museum" -- of Star Trek, no less, hence absurd on multiple levels -- that's just somebody out to f^ck with trekkies.

Innula, this is not at all the question you asked, but for you and others dealing with teleporting agents: I've been struggling with https://jira.secondlife.com/browse/SVC-7987 and I think I know what's going on, so before I further confuse that jira, I'd like to see what others may have seen. It seems to me that the look_at argument to llTeleportAgentGlobalCoords() is not the "location avatar will face after completing the teleport, given in local coordinates" as in the wiki, but rather a vector in the direction the avatar will face. So, for example, to face southwest, the look_at must have negative X and Y coordinates, not merely be the coordinates of a region location to the southwest of the avatar's position. At least this is how it seems to work for me. And at least I was surprised it worked this way, given the wiki. So... Has anybody else observed that this is how it works? If so, do we change the wiki, or do the functions need to change to match the wiki's description? (There must be content depending on the current behaviour, right?)