Profaitchikenz Haiku

I've seen a similar situation elsewhere. The Auran Trainz Simulator changed their Jet graphics engine a couple of times, between 2006-2009, then more recently for Tane. Although no existing content actually broke because of the changes to the graphics engine, a lot of older content looks very poor because texture usage changes, the billboard vegetation for example that was fine in 2006 looked awful in 2009. I would expect similar should SL go for an overhaul of their graphics, old stuff would still work, but you'd take one look at it and retch. The things in Trainz that did actually break weren't the result of the graphics engine changes as such, but other changes that were all bundled up in the general overhaul. Once you get going on upgrading a certain part of a software system it's almost impossible to prevent feature-creep and tagalongs adding to the order.

Very true, although I see Opensim largely following SecondLife's lead, not innovating. (Kitely's region-on-demand is a notable exception). As regards the slightly better physics engine, the only place I see this as significantly better in SecondLife is with the mesh upload stage. For actual inworld physics for moving objects, SecondLife's performance tends to be lower than that in an opensim region because of the poor performance issues that have been mentioned elsewhere in this thread. However, Opensim has the big advantage of not being tied to any company strategy, or hamstrung by asset/funding limitations. It also has the second and possibly bigger advantage of allowing people to connect standalones to the grid, (effectively Hiro's Office). OpenSim is to SecondLife as Linux is to Microsoft.

Possibly sculpts?

I have to query this. I just tried dropping my slider back from 1200 to 700, and went to a region I visit regularly, so all the textures are cached. It's very stable, nothing changes so there's few updates to worry about. It was grey when I arrived. (Not unusual these days). After 2 minutes hardly any textures had loaded, everywhere was grey, and the trick of moving forwards just a pace or two which normally triggers a rapid load of textures within the draw distance (64m) didn't make a difference. I moved the bandwidth slider back up to 1200 and the textures were instantly there. Test performed using Catznip R12,3 (32-bit) ETA There may be more to this: The first region is almost full up of prims, it's a private island (18900 used from 20000) I put the slider back to 700 and went to another regular, this loaded quite quickly. It's a homestead at 80% of it's prim allowance. But visually it's much sparser and has no underground tunnels or chambers, unlike the first. So does the time-critical information coming across UDP include the positions of all the objects in the region? ETETA The minimum bandwidth figure I established would get textures appearing within a few seconds of TP-arrival was 1000, less than this and large surfaces stayed grey even if I approached them and tried the right-click trick.

It was like that yesterday with the web profiles, trying to access them from inworld got a "heavy usage" response. I remember thinking "What on earth has caused half of SL to suddenly want to update their profiles?""

OK, I don't think I go for free stuff much so I've not realised that side of it before.

A couple of years ago I went back to the Blender Game engine with a view to seeing if it could be adaptable. I gather now though that it's not to be a part of the going-forwards Blender, and of course it had the big drawback of not being able to actually build inside the game-engine, just use things made in Blender. And, as I've said elsewhere, I find trying to use Blender very similar to the nano-tech assembly devices described in The Diamond Age, you're peering in through a viewport and trying to use manipulator gloves. I'm happy enough with what we currently have in principle, I'd be happier still if it all worked smoothly.

The closest to your requirement is finding the demo on the marketplace and buying it as a gift for the alt/friend/random person to be surprised.

I'm not even sure that's appropriate to the sort of problems mentioned through this topic: Most of the issue that are giving me headaches come from the SL (AWS) servers. I could be running on a state of the art gaming PC but I'd still be looking at 37% scripts running, three to four Keyframe movements failing for no reason each day, TP-crashes, ... Maybe I should put this another way: If SL were better-performing, I might feel inclined to squander some of my setaside for a better PC, but right now, I don't see it as worth the expense. The machines I have go around some of the other (outside SL) places without a hitch, I don't see grey textures or get TP-failures there, it's only SL that' become rather annoying over the past few months.

I'm seeing it sporadically, there are good days and there are days when every 6th TP crashes to desktop. The pattern I think I see is that it's more likely to happen at weekends, my suspicion are that it's not SL as such, more a lot of internet traffic that could be causing delays. I can't offer any better advice than reduce your scripted attachments to a minimum.

Wulfie is right, I'd not seen this before but object_rez also triggers in the object that called llRezObject. Very handy

Does this mean us old gits are going to come hobbling out of retirement to work again? Yippee! When I passed 60 I found I was having trouble getting contracts on software, I would be declined on the basis that I didn't have enough experience compared to a 30-year old. "How can than be?" I asked an agent with whom I had actually done some coding work years ago. "It's like this. There's you, with 30 years experience spread across several languages, let's say Fortran, C, Macro11. So you have 33% of your working life on C, which the client is keen on. Then there's a 30-year old who's done nothing else but C for 10 years, so he's got 100% of his working life on C, so he's got more experience than you."

That would be most of us in these forums, we're not jut here for the whinge, you know

Sort of Minecraft in Space?

Sometimes you have to say it thrice (As the Bellman said "What I tell you three times is true") I think the OP had in mind a more targetted approach, which I don't disagree with, but I do actually agree with you, LL has the funds, they should be the ones promoting it in an effective manner. The new website is obviously a step in the right direction, but the nextt step is going to be how to get non-SL-users drawn to it.

Quite right, but... On of the best marketing strategies is that of customer-referral. We could talk friends into coming along and seeing what it's like, but as Sid Nagy, Janet Voxel and others(*) have mentioned, we'd be trying desperately to explain crashes, grey textures, all sorts of little things that we are coping with but which a new pair of eyes will be seeing and wanting explanations. "Mummy Mummy, why is the sky purple?" ""Oh, it's EEP, but I haven't worked out how to turn it back to blue yet" (*) If I've spelled your name wrong it's just my tpoyes

Oh well, in that case - We're doomed!

The object worn on the shoulder needs to keep track of the objects it has rezzed: when an object is rezzed it announces it's key on a channel that the shoulder item listens to. The shoulder item keeps a list of the object key and object name. When a new object of that name is to be rezzed, the shoulder item looks to see if it already has an object of that type in the list. If so, it uses the stored key with llRegionSayTo() to tell the first object to derezz. The first object can then either call llDie() when it gets a "your time is up" message, or it can check with the owner if it should obey or persist. If it is told to persist it can then stop listening on the channel so that it won't get further messages to die. The shoulder object will have to remove from the list it keeps any instances that have been told to die. Complicated but mostly by the amount of book-keeping that is needed

Your saying they aren't a thing doesn't make it so in exactly the same way that my saying it's a thing spurs you on to disagreeing with me. Different people in SL have different desires. Saying it's always been like that and there's no hope is just Frazer saying "We're Doomed, Doomed!". In that case, why are statistics built into the viewer in the first place? They have a meaning and a purpose. To some extent, I agree with you, measuring too much of the wrong thing can degrade performance. Measuring enough of the right thing, on the other hand, can help t maintain or improve it.

There is some comfort to be taken from that, it's going to be around for as long as they can keep it paying out, but I agree with you, it gives me a sinking feeling about how much effort will be directed to fixing things that aren't really right but don't necessarily increase revenue.

Animesh hair? Internal organs for mesh bodies to complement the brains I see rezzing before the heads? (Note to others, colour me tongue-in-cheek)

I have no problem with the increase in Premium fees last year, it's important for a company to ensure it is on a sound financial footing if it is to continue. I don't have a problem with the experiments such a Sansar, it's important that a company looks at new direction from time to time. I am glad that things like BoM have been added to SL. Where I am struggling to see how the OP's suggestions could be embraced by us, the great un-herdable kittehs of teh SLife, is with the sustainability and maintainability of the essential hardware and software. I went to a server group meeting a couple of weeks ago because my parcel's region had come to a halt with the "unable to create object that has caused problems in this region" issue, which occurs when (amongst other things) the physics memory usage for the region creeps up over 900 Mb. I hadn't seen this for a long time but my landlord said it's quite common across their estate. It takes several hours until live support can address the problem, depending obviously on when it is noticed by users. I went to the meeting to ask if it would be possible to add the monitoring of this parameter to whatever regular region monitoring is done, in the hope that as the memory use approached a warning level, to either invoke the grid-poking-bot or some other mechanism to address the problem. The answer I got was "It's hard". Whilst there the issue of TP-crashes was also mooted and another of the Lindens present mentioned that they too had had a couple of those instances very recently and therefore they might have to take a look at it. I asked about the monitoring that a now-departed Linden had mentioned was going to be put in place to allow things like TP-crashes to be logged, but it seemed there hadn't been a lot of progress (that we could be told about) in the months/year or so since the idea was first mentioned. I left the meeting realising that well-meaning as the Lindens there were, it was out of their power to do much about the long-standing problems, the older explanations of "how meeroos come about" had now been replaced by "It's hard". There will still be attention paid to very specific Jira bugs, but the general operation was just going along on what I feel is a wing and a prayer. I'm not going to throw my toys or spit the dummy, I shan't storm out of SL for one of the other places, I shan't cancel my premium subscription (yet), but I have no real hope that things are going to get better any time soon, based on what I heard then and at previous meetings, nothing significant has changed since the transfer to a different platform. If there is anything that we as concerned uses could or should be doing to assist SecondLife, it should be making it very clear to Linden Lab that they really should be fixing the broken parts before rushing off into yet another glorious addition such as EEP. Fix the TP-failures, fix the vehicle-region-crossing problems, monitor the regions to catch problems before they halt the region, have a 2-hour response team to address stopped regions, give all regions adequate script performance... If they have the resources to overhaul the web page then they ought to have the resources to try and make sure that the inworld-performance lives up to the expectations the new web page will engender.

This to me sums up the problem: it's creaking. Things that I have been complaining about at Server User Group meetings are now getting worse, not better, and the answers from the Lindens there to my and others inquiries tends to be "It's Hard". I am seeing very erratic behaviour now for scripted moving items that will one week be perfectly-behaved, and the next week will be failing to start or end a movement. If it were always problematic I would accept that it's something in my code that could be improved, but it's random. One week good, one week diabolical. Yesterday I experienced TP-crash-to-desktop half a dozen times. What do we say to new users? "Get used to it" ? So what are we going to trumpet to encourage new users in? Looks good but works erraticly? Don't try TP-ing around on odd-numbered days of the week with a U in the name? If the textures go fuzzy buy a new PC? Sorry for those who agree with the OP, but I see a case of the Emperor's Clothes here.

By default qavimator sticks the files in the "data" folder in the "Program Files" directory entry or wherever you installed it. Having saved it as an AVM file, you then click on the files menu and choose "export for secondlife" to create a BVH. That also by default joins the AVM file in the program files data directory.

I can't help feeling acreage alone is meaningless, surely the content is a meaningful meaningful measure of the world? Anybody with a mind to replicate some film I vaguely remember sleeping through years ago about a race to get a mile of secondhand cars across a desert to a sales lot could just put up a million pinhead islands and demand they have the prize.