Qie Niangao

Innula Zenovka wrote: Medhue Simoni wrote: Although, I think you are thinking about the transaction wrong. The value of bitcoin is based on other currencies. So, if you are billing some1 30 days later, you are billing them in the amount of dollars, or whatever currency you are using, compared to bitcoins. So, if the value of a bitcoin changes, you are still billing them for the dollar, or whatever currency. It is just the total amount of bitcoins that changes. This is why most merchants cash out their bitcoins as soon as they recieve them, to make sure they get the full amount back in their normal currency. Clearly I am misunderstanding, then. If I bill someone in £s and exhange any bitcoins I receive for pounds as soon as I receive them, what's the advantage to anyone of my accepting bitcoins in the first place? I can see it probably saves my overseas customers something on transaction costs as compared with their buying pounds, but are there any other advantages I've missed? Presumably because it makes bitcoin advocates feel good about themselves. Which, in fact, isn't a bad reason to do it. The customer is always right, etc. It's just a question of whether there are enough bitcoin afficionados feeling gratified enough to justify the overhead of accepting bitcoin. (And media attention notwithstanding, trade in bitcoin for goods and services is about as popular as bartering pork bellies.)

Yeah, I agree this framerate is probably due to hitting the wall in rendering performance, but I also have a sneaking suspicion that Preferences / Setup / Network: Maximum bandwidth got set to some absurdly high number. I'd try 500 kbps to start. If there are never any dropped packets when teleporting, perhaps try gradually raising it, but usually no higher than 1500 kbps. Going higher is much more likely to hurt performance than to improve it -- and yeah, connection speed is only very abstractly related to that setting.

I'm not sure if this is an exercise or something intended for use. If the latter (and if it's important to do the computation in-world), maybe look at an earlier open LSL bignum implementation. (A general observation: manipulating LSL strings to do bignum calculations seems doomed to extreme inefficiency, both in memory and especially in speed, but maybe there's a way. If, however, I were forced to use strings, I'd probably investigate using characters other than base ten digits.)

Oh, I expect something of value: I think we'll get some useful version of the jira back. Probably not wide-open comments, status quo ante, but something not so completely crippled as it is today. (On the other hand, I think last names are gone forever. Not that any of the BS quasi-technical excuses for not re-implementing them ever made any sense at all, but they always were a confusing part of new user signup. I know, I know, but that's why I think they're gone forever. Anyway, I'll be very surprised if Ebbe says anything about last names, and certainly that issue is distinct from "transparency" and the kind of "empowerment" I think he's championing here.)

Wow. A big thank you for following up on this and reporting what happened. I'd never heard of this, so knowing it's even possible could be useful to others who get tripped-up by it in future. And glad it worked out for you -- enjoy your land!

What I love best about this latest collapse is the claim by some bitcoin apologists that it's no big deal because the exchange's insolvency is really just a few insiders trying to get cheap bitcoin. Because it's always more fun to have one's currency debased by some anonymous clowns than regulated by a central bank.

Here's some fun. Both versions of the llScriptProfiler-using script contain these three lines: vector rot2 = llRot2Euler(rot); rot2 = <rot2.x,rot2.y,(rot2.z-0.105)>; rot = llEuler2Rot(rot2); Try commenting them out in both versions and watch the profile numbers again. I'm not claiming there's anything wrong with the memory measurement functions. Rather, it looks like some sort of alignment effect to me, although I sure don't claim to understand it.

Surely, I agree, now as he is CEO he should concentrate more in discussing in Linden Lab forums and blogs about Second Life matters. With the google ads and Indian whore spam. I'd be a bit embarrassed to post here, if I were CEO. Come to think of it, I am a bit embarrassed to post here, and I'm not CEO. And I'm not easily embarrassed.

Tenaar Feiri wrote: You can also use lists to store global variables in than defining each individual one as a global, but I'd be careful with that too. It can help you save space, but depending on what you put in it, it can also increase memory usage! Do we know an example of list storage saving space? It seems quite counter to (my) expectations.

Right, there's no such notification to scripts. I'm not sure it would be very useful anyway, especially not for the reason suggested: I know scripts generally just 'pause' when the server's down & resume again afterwards but I don't trust LL's servers to reliably retain my script data. Such data must be stored externally to SL. Storing it in atttributes of an object on a sim is no more reliable than just trusting the script to start again gracefully (and if they differed, I'd trust the script's state more than the object's). If you're recording stuff of significance outside the sim (e.g., financial transactions), then yeah, those need to be stored externally. One reason is that the sim may not restart at the point where it left off; i.e., it may be rolled-back to a previously saved state. As far as the scripts and objects on the sim, everything is internally consistent, but as if a chunk of history never happened.

This is the sort of thing with which the Lab generally doesn't involve itself. It's just a sure-fire lose-lose for them. It would be very difficult, error prone, and time consuming for them to figure out what's actually happened, with very little profit in it. So I think you're out of luck with that. It's not difficult to imagine what the estate manager might have been thinking. It's great if this quarter-sim tenant wants to keep renting with us because then we'll get paid something in future, but if not, they're just a hindrance, so kick them now and cut losses. It's not nice but it's good business -- but only if one has no reputation to lose. If I were you, I'd spare myself the futile frustration of trying to get the Lab to do anything about it, and instead simply post in another forum where you can name names. You won't get any money back, but you won't anyway, and at least you'll have the satisfaction of that estate paying some penalty for their action against you.

Kitty Pashinin wrote: I have a question about purchasing mainland parcels. When you purchase a parcel isn't by default it set not for sale after you purchase it? Don't you have to set it for sale yourelf for it to be up for sale? I recently purchased a parcel only to have someone buy it from me a few days later even tho I had not set it for sale. This really just does not happen. If there's one thing that has worked flawlessly for years, it's the buying of land without it then being on sale again. I assume you checked your transaction history to establish that you did, indeed, buy the land, and that the subsequent buyer did, indeed buy it from you. But, wow, I mean this just never goes wrong. The only thing I can think of -- and even then, it's a huge stretch -- would be if the sim got reverted after you bought the parcel, but then the subsequent buyer wouldn't be buying it from you, but rather from the previous owner (again). And that would be evident in transaction history. (And some other magic would have had to occur, too. I mean, this just does not happen.) Oh, and sorry to hear about the adfarm thing. You know about the official ad policy, right? Some of us in the Arbor Project had to do a recent round of Abuse Reports for some new and exceptionally blatant adfarming, after the problem had seemed largely dormant for years. (In fact, I think it was on Corsica; I should check the landmarks.)

Well, yeah, but the OP doesn't complain that the graphics card craps-out in SL, just that it's slow. And it shouldn't be, really. Although the R9 290 is absurdly overpriced (the performance of a GTX 770 for a hundred dollars more than a GTX 780, all for the privilege of ATi's gawdawful drivers -- seriously, WTF?), still, it should be able to run SL well enough that nobody would bother posting about how bad it seems. As suggested, switching to the compact version of chat should make a night-and-day difference, so maybe that's all that needs fixing. (The CHUI should never have had the expanded version as default. Yeah, it's all pretty and stuff, but both useless and just unbearably laggy.) I agree that such a high bandwidth setting is unlikely to be doing anybody any favours, and can easily cause trouble. On the other hand, making better use of whatever bandwidth you get is a win, and right now nothing comes close to the Lab's HTTP Release Channel viewer, 3.7.2.286708 (what I'd name the current "Performance Viewer" of the thread title). [EDIT: Oh, heh, the same RC viewer also fixes the expanded chat lag. I should have read Theresa's post more carefully!]

Which sim(s)? Usually this points to a problem with the content on the sim -- although sometimes that can be very hard to find, so it is often easier to just restart the sim and ignore the underlying problem. There do seem to be some sim memory leaks (that might still be associated with Pathfinding, or not), and so it's probably best if the Lab gets to hear of every such instance, which should help them identify and fix the problem(s)... and motivate them to do so, if it causes enough work to have to poke each affected sim individually.

I don't know about the effect of allocating the same variables in a different order. Earlier in Mono's history in SL, it was stupidly fussy about aligning bits of program (states, functions -- and aligned to 512 B blocks no less) but those seem to be gone now, and I don't recall ever hearing the same about data. And yet, it's frustrating to get consistent measurements of data size (see unofficial attempts on the wiki), so perhaps there are sequence effects buried in there somewhere. I agree that verbose llOwnerSay() calls can be much worse than you expect, and that global variables are more costly than locals (as if that were ever a choice, heh). A global list of strings in particular is just insanely memory-intensive (see the above link). (I'm not so enthusiastic about a rule-of-thumb to inline code instead of using functions that appear fewer than three times; it just so depends on the size of the code and on the function's argument list.)

Not sure this is at all helpful, but I just tried with no problem, using either Safari or Chrome. On the other hand, this is the very first time I've used my iPad to login, so maybe it's something that only goes wrong if one has logged in before, so... maybe try clearing the browser cache? (In Chrome that would be in Settings from the hamburger menu, Advanced/Privacy -> Clear Cache... and maybe even Clear Cookies, Site Data; for Safari it would be the iPad Settings / Safari and then... your guess is as good as mine.) Oh wait, there's a software update to iOS 7.0.6, wonder what this will do. "This security update provides a fix for SSL connection verification." Hmmm. Will this break me, or fix others? Downloading... ETA: Installed. Still works for me in both Safari and Chrome. Guess that's not very informative after all.

Possibly. Literature, however, is not just reading, but also writing. As is roleplay. I mean, it's fine if some people think their SL is all about teh sexors. That they'd presume to impose that view on others -- and impugn others' motives on that basis -- well, that's where it's wrong, sick, or both.

LaskyaClaren wrote: Qie Niangao wrote: I'm "quite confused" at this point. Is there seriously an argument being made that all roleplay of children is bad? Or is there just a shorthand for sexual roleplay? I mean, if it's all child roleplay, then Huckleberry Finn must be morally equivalent to child pornography -- and anyone who would assert that would have to be more corrupted than a child abuser. I don't think that the sexual/non-sexual distinction is being made here at all: I think all age play is being condemned in a blanket fashion. To quote Leia's first post here, "There is nothing sweet or innocent about a grown adult impersonating an 8 year old for any reason." I've heard this argument before, as, I know, have you. That's disappointing, and surprising in this case, but yes, I've heard it before. I guess a charitable interpretation might be that the view derives from a very limited appreciation of role play. That's more charitable, anyway, than the obvious interpretation, which I think applies to some others who've expressed that view in the past.

This is interesting. In some hypothetical universe, I might cast this slightly differently: that new (and old) "primitives" could be (re-)defined as geometry, and operations performed on that geometry. The operations would be defined by the platform a priori, but new "primitives" could be uploaded (almost) as Mesh is uploaded now. I don't think it's reasonable to allow new operations to be user-defined; that seems beyond what can be efficiently implemented. (It's very possible I could be wrong.) Even the new primitive geometry upload has some complexity. I mean, it's not exactly like Mesh upload (e.g., they couldn't include textures, specify rigging, etc.) and it would be a dreadful shame if they were as crippled as Mesh objects -- that is, as with prims and sculpties, it must be possible to switch an object from one sort to another by script and UI, not requiring one to rez a whole new instance as with different Meshes. [ETA: The new primitive geometries would also need to be tagged with some specifications on how the operations would apply to them. Simple example: what is the default hollow shape for the new prim type?]

I'm "quite confused" at this point. Is there seriously an argument being made that all roleplay of children is bad? Or is there just a shorthand for sexual roleplay? I mean, if it's all child roleplay, then Huckleberry Finn must be morally equivalent to child pornography -- and anyone who would assert that would have to be more corrupted than a child abuser.

Sy Beck wrote: In conclusion it will not be long till there is a feasible and practical hypergrid in operation for all virtual worlds apart from SL when all those little communities are all interlinked and TPing from one world to another with your inventory intact and attached will be no different than TPing around the grid in SL. LL remains though firmly against if not outright opposed to the hypergrid as it would be the death knell for their present business model. Mainly because it would terminally accelerate the process I've described above where I could live on the cheapest land in the metaverse and create there with my SL inventory and then TP to a merchant's shop in another world for new clothes, that world having the most favourable terms for cashing out before finally TPing to the hottest nightclub in the metaverse on another world. That pretty much summarizes the reasons the hypergrid has no value to Second Life as a business. Until there's some benefit to Linden Lab, it's a dead letter. There's magical thinking that LL must adapt the SL business model so it can benefit from a hypergrid. Presumably the theory is that the hypergrid is happening and LL better get on-board with it or get left behind. The problem is that the hypergrid isn't leaving anything behind, it's just picking up scraps as the whole virtual world market slowly declines. It's where some Second Lifers go before they die. If the Holy Hypergrid is ever going to matter, it will do so by bringing new people to virtual worlds, marketing itself and targeting users not already engaged in Second Life. Then there will be a business rationale for Linden Lab to engage. And until then, it's just an annoying parasite.

Right. For non-physical objects, llTargetOmega has nothing to do with the object's rotation, only with how it's rendered (as if spinning) on client viewers. So you're kind of stuck with some ugly choices. One might be to estimate what the object's apparent rotation would be on a viewer's screen when "homed", then move it accordingly when "centered." This is only viable for very short intervals, and intervals during which time you know the viewer will have the object constantly in its field of view. That's probably not your situation. Laggier than llTargetOmega is llSetKeyframedMotion which actually does update the object's rotation. That's probably your best bet if you're doing what I think you're doing. A last resort might be a timer loop of scripted llSetRot() or similar. Relying on script execution for every update, this tends to be jerkier and laggier than KFM but both approaches send a constant stream of object updates over the network.

You're sure the ball doesn't rez? Or is it that this particular avatar doesn't see a ball rez? There's no such thing, AFAIK, as an object blocking an avatar. An avatar can block an object, or a script can selectively ignore an avatar, but there's no way an object can be set to block a particular avatar's events and prevent them from reaching a script in the object.

Yeah, there are still some uses for the largest of the old megaprims. The current maximum dimension is 64m (used to be just 10m), but there are megaprims much larger than 64m, and so folks still use those. It's a bit of a lost art, however; in fact, prim-wrangling in general is a sport for us oldbies. (E.g., knowing two different ways to make a prim with five sides facing the same way is not so special when a perfect 8-sided Mesh is a minute's work.)

Do you really think the knowledge of how to create the one prim objects that linden can would cause people not to buy the larger land? Personally, I really don't think that; I've seen no indication that the Lab tries to inflate land impact to sell more land, but they do try for "fairness" to discourage over-use of features that lead to lag. The problem is that they have just the one lever, "land impact", but there's all different kinds of lag (viewer, network, sim, other servers) caused by a huge array of content factors. And they have adjusted land impact calculation when it penalized content inappropriately. When Mesh was first on the main grid, a single script had a prohibitive impact on a multi-element linkset. We complained and they fixed it. But they're also pretty locked-in to never increasing the land impact of anything already on the grid, lest stuff be spontaneously returned from over-full parcels. So, if Linden plants are actually laggier than they "should" be for their low land impact, there's not a lot the Lab can do about it -- just not introduce any new ones. (Well, that and reducing that excessive lag by removing the plants' wind response from the viewer.) EDIT to add: Oh, you also asked about Linden Homes. Yeah, they're a quite different product from regular Mainland -- kind of land ownership on training wheels. They're certainly not for me, but some people prefer the simplicity. The thing is, a Linden Home isn't just a free house, it's also a hugely subsidized sim. The Linden Homes continents have a lot of landscaped space that's not assigned to the home parcels, and the houses themselves are rooted off the home parcels so the owner gets a full 117 prims to use for decorating, not having to spend any on a house.