Qie Niangao

Your solution will almost surely involve llGetAgentList and llOverMyLand in a timer loop to detect which avatars have come and gone. Other than that, it's a bunch of boring bookkeeping code to maintain a list of agent identities (and perhaps arrival timestamps, if you want to report duration of stay), and another list to contain the event log. These lists could get large, so you may want to use a separate script for the event log (or separate scripts for bulk memory storage, if you need even more capacity for a longer log). Depending on the application, you might want to serve the log by http instead of dumping it to chat.

I'm not sure why nobody tormented the thread's OP back in September for this information -- it would be extraordinarily valuable now, to compare with yours -- but it would be good to see your detailed machine configuration, from Help / About Second Life in the viewer. It may be worthwhile to look at some hardware monitoring data, specifically GPU and CPU temperatures, to see if things could be getting into a cycle of overheating, automatically going into slow-speed thermal protection mode, then recovering for a few minutes before overheating again. As the OP observed, it does seem to recover too quickly and completely on relog, but it should be easy to check. (The monitoring software to use depends on your machine's operating system, of course, but you may already have your favourite anyway.)

Okay, and just to be sure: The ride will consist of multiple of these swings, all linked together and linked to the spinning cylinder so they all will spin together, right? And the seats will also move up and out from that center cylinder as the whole contraption spins up, correct? Assuming that's the case, you're discovering a deep limitation of SL linksets: they're not hierarchical. There's just one root. Hence, when linked together, the seven prims that make up Seat 1 and the seven prims that make up Seat 2 are all just fourteen linked prims, and there's no longer any built-in way to address Seat 1's prims as a unit and move them around independently of Seat 2's prims. Instead, you have to keep track of that association in the script that moves them. (And in this case, seated passengers will also come and go and must move around together with their seats.) This business of orchestrating the simultaneous motion of different parts of a linkset is often called "prim animation." That's all possible, it's just a lot of bookkeeping. In your case, you don't need to capture the "animation" by hand, but rather exercise some solid geometry to derive all the prims' local positions and rotations as they move relative to the spinning root prim. It's do-able. Or... there may be a radically different approach, if the seats don't need to be linked to each other. This is a little trickier, and might not work at all, but the idea would be to use keyframed motion to move separate seat assemblies, all at the same time. This would be less bookkeeping, but I suspect it may be impossible to keep all the seats' motions synchronized, viewer-side. Perhaps somebody will come along with more extensive KFM experience (cough Dora cough) . But you may not like that approach anyway because, among other things, packing up and taking the ride would involve corralling all the separate pieces.

Saylan Remblai wrote: Yes, that works for the purpose of one swing, but I need to be able to link to a base multiple swings. I was planning to have a tether point (where the particles start from) for each and link those to the base. If I do that, the only one that works is the one that is root, none of the others. If I don't link the tether prims to the base, they won't rotate with the base. [emphasis mine] When you say "works" do you mean the particles, or the intended rotating and swinging motion? The particles are easy. You can do it all from a single script in the root prim, just by running through all the elements of the linkset and matching names or descriptions you set according to some convention, such that your script then knows which specific links to emit prims targeting (the keys of) which specific other links, all using llLinkParticleSystem. If, instead, the real problem is getting all the swing seats to move as intended, that may be more complicated. We'd need to understand whether they're each single elements of the linkset (single prims, or single meshes), because otherwise it's an application for prim-animation.

You can't really check them before they open it, but you certainly can distribute it using a script that first checks llSameGroup(). (Of course, that's in-world distribution, not through Marketplace, in case that's what you were thinking.)

You say you have the same lag as this report from back in September, but I just want to confirm: You, too, have this specific pattern of 3.5 minutes of perfectly normal performance, followed by a minute of dreadfully poor performance, and this all only starts after the session has lasted for an hour of perfectly good performance? Or you have some other kind of lag experience? If it's really the same as the OP's experience, it would definitely warrant investigation. If it's more general lag, then yeah, I think it's likely sim content that's overtaxing your system (a GT 230 is not a terrifically powerful GPU, so it could get swamped by rendering load pretty easily).

You think you've got it tough? Just try finding mesh dresses for boys!

I think you may be describing different textures. To get the emitted light to flicker, you'll want to shine it through an animated partially transparent (alpha channel) texture. That "filter" texture is handled a bit like an alpha mask; I'm not sure what the cutoff is, but each pixel is treated as either opaque or transparent, so that affects the filter texture design. At one point I encountered something not entirely intuitive: it seems that the surface on which the animated filter texture is painted must be at least theoretically exposed to the viewer. For example, you can't just animate the interior surface of a hollow sphere that has a complete opaque exterior -- but just a pinhole of dimple will let the light flicker through the entire animated interior.

Extremely unlikely, for if there were ever a dramatic difference in performance among the sim software versions, the weekly deploy thread (currently here) would echo with wailing and gnashing of teeth. There are different classes of server hardware, and if a sim is (temporarily?) hosted on a lesser-than-needed server, presumably performance would suffer, but that doesn't seem to happen much. Or, just maybe, this particular sim is actually a Homestead sim? Seems unlikely for a RP sim, however, because they have strict avatar-count limits, among others. Finally, if the lag improves when you switch to a TPV and adjust your graphics settings, then it's not the sim itself that's lagging, but rather it's content on the sim that's lagging your viewer. (Theoretically, there could be something sim-version-specific that's causing extra content to be delivered to viewers, or delivered extra slowly, or in the wrong order, etc., etc., but that would trigger the aforementioned wailing and gnashing of teeth.)

Can you be a little more specific about what Google API you're using, and how you're invoking it? If it happens to be the Maps API as used for SL maps, I can say it's a bit weird in that I don't seem to supply my key when invoking that API from an in-world MoaP javascript, and Google says such keys aren't used for recent Maps API versions, although I do seem to still be supplying it when accessing that API from a browser and it still works. That may need more investigation if starting a new Maps API project today. I'm guessing, however, that you're using a different, non-Maps API. In that case, it's just a string you'll need to include in each properly formatted http request you issue to the API (at least for the few Google APIs I've used).

Ricky40 wrote: How do you "reset scripts?" Right-click the object containing the scripts and select Edit, then from menubar Build / Scripts / Reset Scripts. (Might be slightly different terms in older and third-party viewers.)

The "specialness" of these things may reveal something interesting, but the history (going back to at least December's BUG-4635) is convoluted enough that I can't see below the surface, although others may know better, and server-side Lindens surely do. We have, however, learned from this that some objects bear hidden state that affects how they're handled by sims. By "hidden" I mean something not reflected in the object's details nor status bitfields, and something other than merely "selected/sat-upon." These guys are treated specially, somewhat "as if selected" -- possibly they actually were selected at some point -- but differently from objects one can recreate today. (Or, possibly, one can still create them, but we don't know how.) I doubt any of this is particularly useful to know in detail now, although I gather that at one point some variant may have aided griefers. What may someday have significance is the fact that objects can acquire state that's hidden to us but known to the sim. It's not something I'd ever considered before this, when trying to isolate bugs.

Aeromia wrote: Akeyo huds don't work like that. They run on a cloud system. The cards aren't even mod. He's just got to reset the scripts in them for it to recognize it. Probably added them in to quickly and confused the HUD. Right, the configuration is cloud-based (well, for small values of "cloud" ) but there's something else going on here, too, because there's no way for a script to play an animation that isn't present in the scripted object, so when those animations were removed from the AO, they simply cannot continue to play. ("Cannot", that is, except for built-in Linden animations, which seems unlikely in an Akeyo AO, although some of the built-in stands are actually quite useful.) So either they weren't completely removed, or something very odd is happening.

Yeah, but I'm not sure which script is expected to remember the data and for how long. It may be that simply keeping it in the server script is good enough -- I mean, 99.999% of the time, such data persists through sim restarts, etc. (but not through script resets). What's probably not going to work is to expect the HUDs to remember this dynamic state information all on their own. In particular, you need to handle the case where the values change while somebody isn't around wearing their HUD to get that new value, so I think instead the HUD, on_rez, sends a sim-wide query for the current settings and the server sends back what it remembers. So, yeah, that broadcast query to any server in the sim would use llRegionSay() on some obscure hugely negative channel, and the reply would use llRegionSayTo(). If the values can change while HUDs are rezzed on the sim (probably so), then that would be an llRegionSay() broadcast from the server to all HUDs. (This gets way more challenging if the information needs to be shared across many distant sims.) (Sorry, but I'm not understanding what's wanted with the "local scale" dialog boxes.)

Medhue Simoni wrote: Qie Niangao wrote: 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.) What overhead? When I signed up to accept bitcoins, I clicked 1 button from the business that does all my transactions. Then, I had to create a bitcoin wallet on my pc. Gosh, that was so much harder and more work than ........ sleeping. Oh, no, I hope I can make up the cost of ZERO. Seriously people, I fail to see why so many are so against bitcoins, and yet know NOTHING about it. I've been away for a week or so, and just beginning to catch up. Anyway, back when the first flurry of these bitcoin threads appeared (possibly in the scripting forum? I can't remember now), I tried to get from the OP what sort of transaction processing he was proposing to offer because he specifically wanted to offer it for in-world payments. Short of some pretty significant programming (i.e., somehow reimplementing BitcoinJS in LSL), I couldn't come up with any secure way to make that happen. The simplest way I could devise was to use a bitcoin payment processor, which seems to be what you're doing. The thing is, to use that for accepting in-world payment, the interface to the payment processor -- the "button" code to be embedded -- needs to be exposed in-world through the usual kludgy means (MoaP, probably, and/or llLoadURL). and then some programming would be needed to relay the transaction success back in-world to trigger product delivery or service provisioning or whatever was being paid-for. And I have to say, I'm still not convinced that this "simplest way" can ever be made perfectly secure (quite independent of any bitcoin currency risk, or risk of failure or fraud by the transaction processor). It just looked less perilous than actually taking on any deeper bitcoin protocol processing in an LSL script. But it seems that, unlike that earlier poster, you're not actually talking about accepting bitcoin in-world, unless it's by some means I don't understand (specifically, "the business that does all my transactions" would be... if in-world, Linden Lab, which doesn't accept bitcoin, so that's not it).

It's not really about skyboxes, though. It's perfectly possible to rent skyboxes and still give tenants full parcel permissions, or to deny those permissions while renting anything else besides a skybox. The challenge in giving tenants the abilitiy to return stuff from their rented parcels is that you don't want them returning stuff from other tenants' rented parcels. (Nor should they return "infrastructure" builds on their own parcels -- such as skyboxes -- but those can usually be rooted on other parcels to keep them safe... the same way Linden Homes work.) So the easiest way to give tenants full permission is to dedicate a separate landowning group to each rental. That is a tremedous pain, at scale, so it's rarely done for cheaper rentals (yeah, such as skyboxes). What's possible only recently -- and honestly, I don't know if anybody is doing it for rentals -- is to offer scripted return of objects on a per-object (or per-owner) basis, where the script could be owned by the landlord (to get the necessary permissions) and operate only on objects located on the tenant's rented parcel. This could be a fun script to write, using the newish llReturnObjectsByID() and maybe llReturnObjectsByOwner(). Unfortunately there's no really efficient way to identify all the individual objects on a parcel, but identifying all the owners is pretty easy with llGetParcelPrimOwners(), so tenants could theoretically identify griefers and clear it out themselves -- or accidentally return all their own stuff with a single click. [ETA: This is already more than anybody wants to read, but just for OCD: There's also the problem of stacked skyboxes or similar where the same parcel is divided among tenants by vertical separation only. The scripted functions might be adapted for such arrangements, maybe, but obviously the land-group-per-parcel approach doesn't work.]

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.