Qie Niangao

FangXiLi Xue wrote: I clean out my pc inside once in a while, like every 3 or sometimes 4 months, with the vacuumcleaner, very carefully. I just open the pc and make that carefully, the fan is always a bit dusty. and when its too dusty, the pc shuts down by itself. Then i know i have to clean it again, but mostly i clean it before that happens. I did that about 2 weeks ago for the last time. Any idea how i could cool it down more? Im scared to leave the pc open coz i think more dust will affect the pc then sooner, but maybe there are other ways? Well, I'm not 100% sure that the over-temp condition is what's causing the weird lag spikes, so I don't want to get too obsessed with cooling, but that GPU temp does seem high enough to be worth a bit more effort, even if it doesn't ultimately solve the lag spike problem. And since nobody seems to have any better ideas anyway, we may as well spend a little more time on cooling. I don't think you should leave the PC open. In fact, some cases cool better all sealed-up except for the designed-in fan vents. I'll tell you what I do and you can decide if you want to do something similar. About twice a year, I remove the graphics card from the machine and carefully use a large fluffy artist's brush to dislodge the dust from its fan and heatsink. For me, this seems to work better than compressed air (and much better than a vaccuum), although it's slightly delicate work. (I try to keep myself grounded to some metal on the card to prevent static, but that may be superstitious.) Longer term, you probably want to be planning on a more capable graphics card. It really makes a massive difference in the SL experience. But you may also be considering a whole replacement machine -- I mean, everybody has to upgrade eventually -- so I get it that we really want to get this one working better for now.

I kinda wonder if your graphics card fan is spinning at all, or if it is, whether any air is getting through. That GPU -- the one with the flame beside it -- seems very hot, but I'm no expert. (Mine seems to spin up the fans to keep GPU temps below about 65C, but not sure that's comparable.) Have you blown the dust out of the graphics card fan and heatsink lately? If not, I'd give that a try.

I hope somebody who knows Windows comes along and suggests a decent hardware temperature-monitoring program to use on 64-bit Vista. (Sorry, I've used Linux too long to remember anything useful about Windows any more.) That said, you probably already have some nVidia Control Panel that installed with your graphics card drivers, and if you snoop around, you may find it has some temperature readouts. It may even confess to having throttled back GPU speeds to protect itself from the heat. It's worth a look (wherever Windows puts control panels). One quick suggestion: That 368 is a monstrous long draw distance, especially while trying to build. I know you've already tried cranking back your graphics preferences, so that's probably not your real problem, but it can't be helping anything either. (For whatever it's worth, I keep my draw distance under 100m almost all the time -- and my graphics card is roughly ten times as fast as yours.)

I'd assume you'd simply replace the "APIKey" part of the string with the key you got from Google when you created your project in the developers console. I've never used the Translate API, but I understand it to be a paid service these days, and AFAIK these services are all RESTful which suggests a lot more stuff would go into that http request, so I may be missing the point of that code sample.

It's really a question of whether it looks better with particles or with a prim to represent the rope. With enough attention to timing parameters, the particles might give a nice, realistic arc instead of a straight line. In fact, the script you're using might do that, but I haven't tried it to see if it would have that effect. (To be honest, I haven't really looked at the script yet.) The point is, it's not going to be difficult to string particles where you want them, once you get the motion to be what you want. And because you are keeping the seats as separate linkset assemblies, that may not be so difficult. To keep things sensible, you'll want each seat assembly's root prim to be somewhere along the common axis of rotation for all the seats, then adjust the rotation of the assembly so the seats move upward as the thing spins faster. Right now I'm thinking that could be accomplished with different spin vectors of llTargetOmega() instead of any keyframed motion, but maybe somebody else will have a better idea.

Sorry 'bout that. Let's start with "Getting your system information" as described in this Knowledge Base article. Maybe somebody will come along and suggest a free temperature monitoring program, once we know what kind of machine you have (or you may be able to just use the graphics card's control panel, which might already include a GPU temperature read-out).

Oh yeah. Thanks! Forgot about that.

Drake1 Nightfire wrote: Ibet there are a ton of over scripted lag monster weapon and hud bearing people running around. When i say sim side i mean thing on the sim that will lag each person differently. I have been in laggy sims that had no affect on my enjoyment but others could barely move. But then those laggy sims weren't laggy because of scripts; scripts necessarily affect everybody the same because they're affecting the sim itself. That's slightly overstating the case, and the exceptions are informative: Scripts can affect different users differently if the scripts' effects are differentially laggy on different viewers. That is, they're not lagging the sim itself any differently between users (that's not even meaningful), but rather those scripts are doing stuff like causing object updates that may lag some viewers more than others, because of different network latencies, graphics processing capacity, memory availability, etc., etc. That's typically not the problem with combat meters and sim damage systems; those things just add to overall sim script demand without affecting different users any differently. On the other hand, if the sim has a lot of animated textures, particles, smooth-rotating objects (set by scripts that may not even be present anymore but still demanding a lot of rendering effort), or pathfinding and other keyframed motion (requiring scripts but using very little script time -- and sending tons of object updates), the sim may have spare time to burn and yet users with limited capacity can be swamped compared to others with better machines or network connections. Same with downloading lots of fat textures and other building practices.

Drake1 Nightfire wrote: Just a quick thought, is the sim you RP on a scriptastic lag fest for anyone else? Most RP sims have more scripts running than carter has little yellow liver pills. Yeah, but two things: It's hard to lag a sim with scripts. Not impossible, but surprisingly difficult, especially these days. Even in super-laggy sims, you'll often find spare time in the frame, which means that there's even more time that could be spent on scripts (and anything else). And in those cases, the sim itself is not lagging, but rather its content is causing viewers to lag. And that's the second thing: The OP reports that cutting back graphics preferences and using a TPV somewhat improves the situation. That simply wouldn't matter at all if the lag were sim-side. God knows there are still overscripted RP sims, especially when infested by meter- and other attachment-crazed RP avatars... but there are even more RP sims full of high-resolution textures and hyper-complex object geometry that downloads slowly and lags rendering on all but the fastest GPUs. That's what I strongly suspect is happening in this case -- and might be confirmed by a little on-site snooping with the statistics bar open.

Kwakkelde Kwak wrote: Not "every1 takes their cut" in SL. I'm pretty sure the vast majority of users makes a loss. If that's not the case, we're headed for disaster, since if somehow everyone pulls money from SL, there won't be any left in SL itself to go around. Yeah, and that's putting it mildly. Every L$ that gets cashed-out, plus every fee paid to L$ sinks*, plus (especially) every estate fee and Mainland tier payment -- every bit of that -- comes from RL money infused into the SL economy by folks paying-in more than they take out of SL. Merchants may suppose that they're spending and cashing-out L$s earned in-world -- and, indeed, they earned those L$s in-world, but every single one of those L$s must ultimately derive from RL funds injected into the SL economy. Otherwise, the entire L$ supply would be exhausted quickly, like a leaky balloon. Certainly merchants and creators generate revenue for LL and expand the SL economy, but they do so only indirectly, by luring others to spend their hard-earned RL money on virtual goods and services in SL. There may be an invisible hand, but there's no free lunch. *L$ sinks are slightly messy because not all L$s ultimately derive from LindeX purchases from Supply, which are RL money infusions; rather, some L$s are sourced from stipends, which are ultimately paid for by membership fees -- again RL money infusions, but the stipend is just part of the value purchased with those membership fees, so the accounting isn't quite precise.

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).