Qie Niangao

I suggest just not using Marketplace any more. Solves a lot of problems.

I hate to leave you in the lurch here, so I'm posting again just to "bump" this thread in hopes somebody else will see it and be better able to help. Before giving up, I started hacking together a sample of how I'd approach what I understood to be the problem -- and then realized that I completely don't understand what you're trying to build. I was thinking that these seats just spun around appearing directly attached to a spinning (llTargetOmega) central shaft, the faster it goes, the higher they should spin... but now, having looked at the script (which incidentally I couldn't get to work except the particle system), I suspect they're actually supposed to swing back and forth or something -- and using physical motion, no less. So this is some kind of amusement ride with which I'm not familiar (which isn't that surprising). Hopefully somebody else will have a clue.

Yeah, maybe, but I don't think any amount of New Avatar Wonderfulness will discourage people from replacing it wholly with lagmonster AVs bigger (or smaller), with more (or fewer) tails, and somehow always an order of magnitude more geometry than whatever is offered. It's just the way of avatar-conscious SL users, so I don't see much benefit of introducing another avatar mesh that will get even less use than the junky one we've got now. If they really feel compelled to make a more extensible skeleton, okay, maybe one developer part-time on that, as long as it won't break any existing content (animations, especially). Or if they want to support arbitrary rigging deformation of unattached Mesh, I can see some value in that. But I'd much rather have anti-water surfaces. Followed by Linden-water surfaces.

2048 sq mtr (or close anyway) As I recently mentioned elsewhere, 2048 is a really bad parcel size to purchase. It's okay to rent, as long as somebody else is paying the tier. Here's why: Ignoring group bonus for the nonce, let's look at the effect of the 512 sq.m. premium bonus, combined with various tier levels, on per-square-meter costs. (In all cases, the owner is paying the premium membership fee, so we don't need to calculate the cost of that 512 bonus -- which is handy because there are different premium plans, although anyone with the hint of a clue chooses the annual plan.) A 1536 sq.m. parcel uses that 512 bonus plus the 1024 tier level for US$8 per month. That's $2.67 per 512 per month. A 2048 sq.m. parcel requires the full 2048 tier level, but leaves 512 unused. This costs US$15 per month, so that's a whopping $7.00 per month for that extra 512 above the 1536, and even overall it costs $3.75 per 512 per month. A 2560 sq.m. parcel fully uses both the bonus 512 and the 2048 for that US$15 per month. That's $3.00 per 512 per month. (To squeeze the absolute most land out of a tier level, the group bonus adds about 10%, rounded down to multiples of 16 sq.m., the smallest possible unit of land ownership. So that 1536 can actually be 1680, and the 2560 can be 2816.)

But invisiprims are really quite awful for removing water because they remove all other alpha textures behind their surface. This is also why they were such eyesores as shoe parts, back before the avatar got alpha masks. The thing is, we got that much-improved way to de-render avatar parts, but have no substitute for invisiprims when trying to de-render water. Not yet. But one can imagine "anti-water" that's way better than invisiprims. There have been requests and at least one jira for it, since long before invisiprims went away. I dunno what it would take to get it made. Maybe if we all show up at Nyx's office hour and exclaim that we don't want anything else -- no more fitted Mesh fluffery, no more futzing-about with outfits, no more next-avatar nonsense, nothing -- until we get our anti-water. Maybe then they'd listen, or maybe not. I get the impression that some adult supervision is needed at Nyx's office hour to remind them that there's more to SL than avatars. Last I checked, the attendance has pretty much shifted to avatar-builders only, which happened naturally because Mesh was originally such a fustercluck for avatars. But at this point it would be better to declare that "mission accomplished" and get on with other, non-avatar stuff for a few years. (Oh, and the "power user" discussion is just too silly. Power users do not run somebody else's TPV. Duh.)

It could be that due the higher population the -avatars- on that sim cause the lag? Yeah, it sure could, but again that should affect everybody else more or less the same. Well, you'd want "Avatar imposters" enabled in your graphics preferences, and probably "Hardware skinning", but they probably already are; without them, yeah, you'd get more avatar-rendering lag than others who had those options enabled. (I'd be very surprised, however, if that's the problem here.) This does seem worth pursuing further because your PC configuration looks pretty good to me; I'm sure not seeing any obvious reason why you should be experiencing disproportionate lag. It may be that a site visit would give some clues (not to pry)... or, I wonder, have you compared actual viewer framerates with others who claim not to be experiencing the extreme lag on that sim?

Yeah, I guess it's too late, at least for full-scale viewer plug-ins. I still expect that some future virtual world will have compelling viewer-side scripting, or at the very least a more featured UI toolkit for scripts. [ETA: Although, ya know... it would be possible for a TPV to architect itself to support third-party plugins. That's actually the kind of project I could get interested in -- but not for virtual reality, unless there's some sudden burst of interest following all this new hardware. Augmented reality seems to have a brighter future, and there is the Google Glass Mirror API. Hmmm.]

Tonya Souther wrote: Have you looked at the Firestorm codebase? (Or that of any other viewer?) It's not that neatly divided. It's one big 1MLOC mess. It's grown by accretion over a period of years, and to get to the point where we could neatly separate LL work from FS enhancements would take a major rearchitecting of the code. I think it's not so much a feature of Firestorm's code that causes it to be so intricately intertwined with the LL viewer source as it is the fact that LL simply threw open the viewer source without any consideration for how contributors might sensibly contribute. Granted, that's just what an open source True Believer would want and all, but I suspect we'd have more interesting TPV features if instead LL had circumscribed the areas where third-party contributions were possible, with a plug-in architecture for their viewer. Or, anyway, that would have been a different course that might have turned out better, which was something that popped in my head when I learned that Google just released a new Docs plug-in capabiity.

But I don't see Pussycat saying anything about fitted mesh specifically. The Phoenix team says at the top of their announcement that the new release "has been a long time coming" and lists a few of the highlights that have been in Linden viewers for quite some time -- perhaps most notably, Monty's HTTP changes, and by adopting those the Firestorm viewer should again approach the Linden viewers' performance. [ETA: Although, to be honest, I've been using Linden beta and RC viewers almost exclusively for a long time, just to try to catch bugs before they spread to TPVs and everywhere else, so my recollection of when features are introduced tends to skew toward earlier-than-release dates. Also, I don't mean to belittle the achievement of releasing a new, stable Firestorm viewer. There's a tremendous amount of source to merge when there are so many wide-ranging updates in the Linden code base. It seems the viewer has been getting a lot of fixes lately, with a lot more in progress right now, too.]

I'd just warn that Linden Homes are really showing their age these days, so the idea of renting one out -- or even using it for oneself, if one is watching developments elsewhere in SL -- may be a bit optimistic. On the plus side, those developments have made possible compelling furnishing with very low land-impact (given careful shopping of newer Mesh+materials creations). But that same development has left the prim+sculpty shells of Linden Homes and their built surroundings looking pretty old and tired. (Also, the "renting out" thing might not be permitted, exactly, but I don't think anybody is going to fuss about an informal arrangement. On the other hand, it may not be a very nice rental arrangement anyway because, as far as I know, you can't transfer land on Linden Homes regions, so you can't make it group-owned, so a renter can't have quite all the parcel management abilities they might expect.)

Yeah, sure, but I'm still puzzled about how you're getting all the swings to simultaneously move the way you want them to. If that's already cured, then it's trivial to have them send particles from some prim in their linkset out to some other prim that's not part of the linkset. That's not exactly the same as "different spots on the surface" of a single prim; you can't really do that, exactly, because a particle target is always the origin of a prim (or of an avatar, the origin of which is notoriously near the crotch). So either all the seats could target a single prim, or they could separately each target one of several linked prims. But is this really the problem? I mean, the swings are already all moving as you want, and it's really just a matter of getting the particles to go where they should? Because Ohjiro sketches how to make that work, in the first reply to this thread. We can certainly elaborate on that if necessary, but that part seems (much) easier than getting all the seats to move together as desired.

ziicutie wrote: This land should be acessable by the main grid or test grid by your choice. This is what killed the idea of the "metaverse" back in the heady days of, say, 2008. The problem is that by hosting your own sim, you are also hosting all content on that sim, which is to say you have your very own copy of all intellectual property that happens to be rezzed on or stumble upon your sim. It doesn't matter what LL may want, they are legally forbidden from allowing that to happen to any user-generated content currently on the Second Life grid. So any inter-grid movement would have to be without any assets at all -- no clothes, no skin, no avatar of any kind, and of course absolutely no inventory.

Right, or if you just need those coordinates for a specific sim (not in LSL), can call the cap with a URL like this: https://cap.secondlife.com/cap/0/d661249b-2b5a-4436-966a-3d3b8d7a574f?var=coords&sim_name=Ahern as documented on the Map API Reference page. (The "opposite" cap was broken for a long, long time, but they both seem to work again at the moment.) Also, a minor detail about using LSL to find the map grid coordinates of a region: those are actually the global coordinates of the region's corner divided by 256 -- that is, llGetRegionCorner() and llRequestSimulatorData() return global coordinates in 1-meter units, and the map grid uses global coordinates in one-region units.

True, but it's a waste of resources just leaving the script in the object once the hovertext is set. So that raises the question of what the OP is actually doing such that a hovertext label is useful. Maybe we can get by with dropping a script in the object each time it's to be named, just chat the name and description (or use llGetText to collect them), then have the script change the name, description, and hovertext accordingly, then remove itself. It's quicker and easier to drop a script on an object and answer a couple llGetText dialogs than it is to right-click and edit the object and change those name and description fields in the build tool. But we don't really know what the OP is doing. For example, maybe these objects get their names and descriptions through some other script, or something else that would make this even easier.

....my parcel is a little larger than 1024 by about 100m... and in the snow country of Boreal.... I want to upgrade to the 2048 size but would want to trade my parcel as part of the deal.... We're talking about Mainland ownership here, so it's cost-effective to match total land ownership with tier levels -- but keeping in mind that the premium membership comes with 512 sq.m. "bonus" tier that you can use to augment all the tier levels. Hence, for the same US$15 monthly fee as a 2048 sq.m. parcel, you can have up to 2560 (2048 + 512) sq.m. Or, at the US$8 monthly tier level, you can have 1024 + 512 = 1536 sq.m. -- and maybe spend the US$7 you saved on L$1750 more stuff in-world. (With the 10% "group bonus" you can actually do slightly better than those sizes, too, by always buying the land "for group." Group land is in fact quite useful, but also a tiny bit tricky at first, so maybe put that aside until you're looking at a specific parcel that needs some of that extra 10%).

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.