Profaitchikenz Haiku

My view is the Metaverse is what we create, ourselves. It's not what somebody else thinks we want, Sansar was a classic example of what happens when you think you know what everybody wants. We're making the metaverse now, every minute we're either logged in or thinking about it or talking about it. If one platform folds, there'll be a diaspora to whatever suitable alternatives there are.

I shouldn't have attempted to swerve us into the "SL is doomed" area, but I couldn't resist it. Madam is most definitely alive, else I would not attempt to swerve madam. Sing "Cockles and Mussels"

Does this mean we're doomed ? ( )

There might be an internal one that isn't for the likes of us. After their experience of Sansar they might now have thought twice-thrice... about trying to give us what they think we want and have settled to seeing what we currently like and just extrapolating a bit - such as - they spend lots of time beautifying themselves for pictures, so lets give them a way of super-enhancing their visual surroundings... The metaverse is still a new concept, the closest to it is probably the Victorian-Edwardian theosophy ideas of how mankind fits into a greater spirit world. That took a while to peak and then fizzle out when the demand for it waned (and the evidence failed to appear). The metaverse is still on the rise, but that doesn't mean it can be road-mapped, monetarised, advertised, incentivised. Nobody really knows what it is going to be, but apparently everybody thinks they do.

Actually, I feel that's a little harsh. As others have pointed out, people going to work for Linden Lab are expecting to be working on cutting-edge tech, not providing geriatric-care, and as I knew as a freelancer, you struggle to get a fresh contract that isn't exactly what you were working on at your last place, so wise-head freelancers might tend to avoid anywhere that suggests they're going to be involved dead-heading old flowers instead of growing new ones for fear of then doing nothing but that for the rest of their lives. I suspect the reality is they've been advised not to break stuff trying to fix things. It's possible I've misinterpreted the response "It's hard" as an actual description of the conditions they face, maybe they just switched from "This is the way Meroos come about" as their response to probing question to a less dismissive one. "It's hard" could cover a multitude of situations.

It is ironic that I spent a large part of my working life maintaining or porting legacy systems, the conditions you mention were just part of the environment, and now, when I'm retired, the place I would have hoped to have settled into is plagued by the problems which I was accustomed to having to cope with butt the people aren't around anymore. I can't believe I was *that* unique. You're right about Sansar though, starting afresh is like rotavating the ground for planting seeds, the weeds - sorry - indigenous vegetation - outgrows the seeds you plant. Feature-creep, I've heard it called in the past.

Colour me surprised, I've not know this until now. I can offer an insight though into why I and possibly many other users don't go happily pressing every button here in there in true Alexie-Sayle style(*) - there's no undo. Accidentally prod a button here or there and suddenly your interface is foreign ground, your old familiar sighting marks are gone, and if only you could click "edit - undo last action". It would be nice to have a "undo last command" button, or at the least a "revert UI to default" Other places where I have wished for an undo - Accidentally set a texture on all faces of all children because although you had clicked on edit-linked-parts or select-face and thought it had stuck but it hadn't, and you're scrooged. * "What's this button do 'ere? what's this button do 'ere?" - (Hello John got a new motor?)

I would (do, actually) agree with you, except the responses I kept hearing at the Server User Group meetings from the Lindens regarding such problems was "it's hard". How to get over that mountain and find our way to happy-valley?

But would it be fast enough? Imagine you have position and rotation coordinates stored for a journey, in a script you'd possibly use link messages to get the next sets, and the delay is trivial. If you read them from a notecard there's the inherent delays of llreadNotecardLine, but if you have to make a call to an outside web service there's not just the internet transits but the issue of what to do if the request just doesn't get answered? I realise the other inherent problem with notecards is that they too are capped at an upper limit, but as they don't need to get bytecoded or thrown across the wires by http requests they do seem the most convenient option to look at for better data access.

That would obviously work but I was thinking more along the lines of speeding up notecard reads, ie find a way of improving what's already implemented. My thinking is that whilst scripts are server-side and possibly need re-compiling with each TP because it's going to a different server, notecards just need to transit as an asset with no additional work required during the handover.

Are they faster just because they're a quarter the size of Mono? Or is there some other aspect to the way Mono scripts are loaded that is the reason? It seems to me that the need for larger scripts (and I accept there is a case for wanting more memory) is mostly for storing data, and in this case, perhaps there could be a more efficient way of storing data?

Is increasing script memory going to have an effect on Sim-crossings and TPs?

I don't view it as trouble, I think it's a healthy situation. We get choices because there are differences. I've learned to appreciate the features and function variations in all the viewers available, with perhaps one exception. The enormously chunky camera controls in the V3-derivative viewers that won't let you collapse them to a convenient little block with just the three principal rotate, zoom pan controls. I have yet to see the micro-stuttering others have mentioned, but as I posted earlier, I am concerned that FS doesn't seem to let go of RAM it's had to grab in one region when you TP to a quieter region. (This is on Linux, maybe it does it differently on Windows).

If the probability of something happening increases with time as you have described then you are more likely to find an exponential function fitting your needs. this is a fudge, I know, but it should simulate what you want to achieve. have a predetermined trigger level somewhere around 90, determined by a random number added to a minimum level. start your timer counter at -10, increase by one until it is greater than 0. Once greater than 0, increase it by e to the power of the last increment, obviously save the new increment for the next timer calculation. Check and take action when it exceeds the trigger. Lots of scope for setting the timer value to a variable amount each time to add to the uncertainty

It could be slightly complicated if the attachments the Avatar has might then not fit and also need to be resized... Mesh clothes obviously would resize with the avatar but things like shoes and hats wouldn't. Some items of furniture offer an adjustment menu to allow you to reposition yourself and obtain an optimal fit too the furniture.

Don't worry about other people or trying to fit in, go out and explore, and see what comes your way. Trying to conform to other's expectations is always going to be a rollercoaster of highs and lows, try and find the middle-ground.

Have you made sure Microsoft Security essentials is set to not monitor the Cache location, the chatlog location, and also excludes the SL processes, especially Dulluhan.exe? It sounds to me very like an over-aggressive realtime protection process is kicking in.

Just a thought, if the scriptng language could accept optional arguments, why not add an optional argument that when present allows unlimited line length during reads but if not present, clamps the line length to a 255 maximum? llGetNoteCardLine(name,line) works as normal llGetNoteCardLine(name, line, optional integer toMax) returns up to a maximum length, so specifying 1024 reads a full line, 255 redundantly specifies existing behaviour Or even make the optional argument true/false, if not present it will default to false in the way uninitialised varibles default to 0 ?

I'll vote for increasing the line length that can be read and praying existing content doesn't break. The only instance I can see of it breaking stuff is very far-fetched, somebody is reading a notecard line and assuming that they're only getting the first 255 characters and therefore might get more to process than they were expecting. (An aside, I think we're being a little too tremulous about breaking existing content, take two actual examples ) Python 2 to python 3, the developers decided they were going to break older python 2 scripts regardless Processing 2 to Processing 3, the developers not only decided they were going to break older processing 2 scripts and libraries, but justified part of it by "some people have been doing things they shouldn't have been, so we're going to put a stop to it" (paraphrased) The gist of it is, It's Ok to break a small proportion of older content if it's a) not going to affect too many people and b) the improvements justify the pain. ETA (colour me tongue-in-cheek fr that last part

She's there, that's her laptop at the closer end of the table, she's taking the picture.

I dream of arrays.

I believe they're Transylvanian bagpipes

Forth could do it.

Have you looked behind the fridge?

Because you iniialise fade_steps to steps, the while loop body will never execute, because the ++ before testing will immediately make it exceed the value of steps. I know it's a pain going for a total rewrite, but why not try it this way Have a global integer called direction. It it's -1 you will be fading down from opaque to transparent, if it's 1 you will be fading up from transparent to opaque. Make fade_steps a global; Ditch the sleeps in the timer. Call the timer more frequently and only do one incement/decreent of the alpha value inside the timer event. When the timer is called it first tests ti see if fade_value is either <0 or > maximum, If so, it does what it must and stops further timer clls. If fade_value is in the middle of 0 and max, it tests the value of direction. If direction == -1, it decrements the alpha value (simply adding direction to fade_value will do this) if direction == 1, it increments the alpha value (again, just add the two) It then does any stuff that might be necessary. This method worked well for a cinema slideshow screen I made ages ago. You could preload the next texture onto the trasnaprrent screen while the opaque one was doing the displaying, and there were never any grey blurry textures. (Oh for ths days to come back)