Rick Nightingale

Hmm... thank you. I'll do it like that then. I usually do anyway, on the basis of "just in case" but I couldn't help wondering.

I sometimes use the exact same model for High and Medium LOD models, or Low and Lowest. Does it make any difference if I choose "Use LOD above" versus "Load from file" with an identical dae file? The difference I wonder about is when subsequently viewing the uploaded mesh, if the LOD models on the asset server are indicated as identical... so the viewer knows it doesn't have to download both models and switch between High and Medium because they are the same. I'm guessing that's not the case and the LOD models are all individual once uploaded, so it makes no difference.

Back when I first had it I changed the oval to a rectangle (just change the prim shape) and got rid of the outer, bright ring. Then put it in a proper door frame in a wall. Yeah, there are a set of projectors with parts of the image on them arranged in front and hidden. Not so mysterious to me as it was five years ago, lol. (I knew what projectors were, but had no idea you could do a trick like that with them)

It's OK Wulfie - check a couple of posts up

For those wondering what it is... here's a video: And yes... it's done with projectors.

Yes - that's it! Portal Effect - and I found it in my inventory in an old hunt folder (really helps knowing the name). Thank you! @Ardy Lay I just realized you gave it to me as well... spotted it in my objects folder (I have auto accept on so didn't notice it arrive). Thank you very much indeed! Me too - Fantastic devices for camming around in SL. Got mine (SpaceMouse Wireless) years back for use in Blender (don't know how folks manage to navigate in that with the keyboard!) I sit with my right hand on the mouse and left on the SpaceMouse when in SL. Click a button on the Space to enter flycam mode, and another to return to avatar view and move.

Thank you for the replies. Nothing on the MP looks like what I had (it was a 'doorway' to an illusionary corridor) but it's probably the same technique. The idea of using a projector like that though... that might do it. Hadn't thought of that but I get how that works. Hmm. Oh, and yes... reflection probes in SL. Would be nice to be able to do a mirrored floor without duplicating the entire build below a translucent floor.

Years back I happened upan a free optical illusion, not sure if it was on the MP or a freebie from a hunt (my faulty memory says both)... It's a door-ish-sized thing you can rez, that when you look through the opening, gives the appearance of there being a corridor down it with a door at the end. The corridor appears 'real', you can move about looking into it and see either side of its walls, just as if it was really there. But it isn't. There is no corridor, the thing isn't that long, and you can walk around it but not into the optical illusion corridor. Despite searching the inventory of all my alts, I can't find it and, of course, cannot remember what it might be called. Nor can I remember at all how the trick was done, although I did figure it out by taking the thing apart. It was years ago though and I've forgotten and cannot recreate it, which I want to do in a build if I can replicate the way it was done. Anyone have any idea what I'm talking about? It might not be as good or useful as I remember... or it might.

Same as above. I've moved around in SL like that for as long as I can remember. So much easier and more natural movement than using keys. It's also why I dislike weather effects or 'darkness' areas that use transparent panes all over the place. Can't click on my avatar with those in the way and have to (shock, horror) use the keyboard momentarily to escape.

I get the feeling that your uploaded 30s sound clip is going to be the equivalent of a megaprim.

Sure - I'll PM you a link. The 14.5s clip is exported from Audacity as standard WAV format PCM, 16-bit signed, 44.1kHz sample rate. I've tried uploading (with Firestorm) the stereo version since the SL doc says it will be converted, and the downmixed in Audacity single channel version. Neither will upload ("sample too long"). The single channel file size is exactly as expected for the duration at those specs.

Yeah, 9.9s is what I always used. I thought from the above post about 30s that things had changed. Apparently not... back to the 9.9s drawing board and dealing with broken sound queueing. I got all exceited about it too, lol.

I can't upload anything longer than 10s. I just tried with a 14s clip and got the message "Sample too long". Crop it to 9.9s and it uploads. Do you know something I don't - any way to get a 30s clip uploaded? I've checked here: https://wiki.secondlife.com/wiki/Limits#Sound and it does say 30s, although the 'uploading assets' guide still says <10s.

It certainly is! 30 seconds? Flippin' 'eck - when did that happen? Well that would mitigate most of my trouble if I reupload my sounds. I could live without the queueing.

Ha - I have no memory of posting that!

I've used a script for ages that simply plays assorted sound bites when I click buttons. It uses sound queueing because some of them are >10s long, to get them played in sequence, and so I can play more than one without waiting to press the button. Simple, right? Of course not, this is SL. There is only one llPlaySound() in the script, and I have an llOwnerSay() telling me what it plays when it's called. As soon as I have a queued sound, the last queued and played sound will often be repeated, especially if I subsequently teleport. Even though it has already played, finished, and no other llPlaySound() has been executed. Sometimes it will be repeated two to four times. Every time I TP, it starts repeating again. Sometimes playing a short silence sound that I use (for going between deliberately repeated sound bites when I press its button twice, since that won't queue) will stop the unwanted repeating. Thinking about it, for all I know that silence is then being repeated! Probably is. As I type this, I haven't played the 'stop' silence and the last sound bite is still repeated every time I TP after 20 minutes and ten TPs! TP doesn't even have to be out of the region, from tests I've just done. Repeats seem to come randomly timed; they can be a full minute after the last time. I'll reiterate: Only one instance of the (final) sound is played/queued with one call to llPlaySound(). It only exists in one place in the script and my llOwnerSay() tells me when it is called so I know the script is working correctly. It's hardly complicated. I've tried disabled and re-enabling sound queueing after the last sound is played; it made no difference. If I detach the worn object that plays the sounds, the repeating stops. Resetting the script does not stop it. Other avatars can hear the sound repeated too (at least, another viewer instance with an alt logged on can). It happens in Firestorm and LL's viewer just the same. Thoughts, advice... ? (Not sure if this is a scripting thing or a viewer thing, really, but I'll start here).

Yes, so was I at first; it felt uncomfortable.

We'll have to agree to disagree on this. My point is that the situation doesn't need to arise in the first place. Plenty of applications are capable of telling Windows "Wait a moment" when it sends the shutdown message/query. They don't lose data if I tell my PC to shut down after closing the program, or even if I forget to close them because they are minimised and shut down Windows first. They stop the shutdown process and tell me! A user should not have to guess that an application is still processing in the background or for how long, after it looks like it has closed. That is simply poor programming, and a poor excuse for it. They should be able to tell the OS to shut down immediately, even if the application is still running! I've been involved in computers for 40 years... developed things like multitasking/user networking and database software for systems before Windows even existed, to bespoke whole-plant manufacturing control and management suites. I've done some development in Windows applications. I'm not trying to boast (plenty of people on this forum know more than me), just saying I do know a bit about software development even if I'm out of practice now. I think it's important to design robust software that doesn't depend on a user knowing that shutting Windows down immediatly after an application apparently closes is bad. Because it should not be bad. It isn't for Photoshop, Blender, etc. etc. Final points, since this is starting to be flogging a dead horse: 1. My <70k inventory is not flat, very far from it. 2. Just because 'the masses' like a feature, doesn't make it a good feature if it is basically a potentially data-losing 'cheat'. Even if only for some. Perhaps if it was done right...

The trick is... how on Earth is the average user supposed to know when an application that has apparently closed, has actually stopped all its processing? Do you wait five seconds? Ten? What if something else goes on (that you can't see) and slows things down more? When I'm closing the viewer, I have almost always finished with that PC so naturally I am going to shut it down next. I've done so for many years and have never experienced loss in any application until this change to the viewer's shutdown. I'm not going to leave it on... that wastes energy and costs money even if shut down if it's still on at the wall switch (about 5W on most I've measured from just being connected to the mains). I'm still in the habit of quickly shutting down when what I have been using has visibly finished. Did it again last night, swore as I did it in realisation, and remembered to delete my chache this morning before starting FS. Note that I do this regardless of what I have been using... photoshop, blender, altium, chemoffice... anything. Nothing else has ever had a problem. Operating systems have a mechanism (e.g. WM_QUERYENDSESSION) for pausing shutdown while critical tasks finish. OSs send 'tentative terminate' signals to running processes and there is a handshake; the OS doesn't just kill all running processes the instant you say shut down unless those processes allow it to. Otherwise... how could MS Word ask if you want to save that minimised document you forgot about? How could any task save its state for next time? I can only guess that the viewer isn't taking advantage of these mechanisms, and by 'pretending' to shut down more quickly than it really does (because it looks nicer - a trend started by MS themselves in Windows) at the same time... it's a recipe for disaster. If I had the time I would be tempted to look at the code myself, but I don't (and I'm hardly 'current' in my knowledge so it would take some getting back into). It's not a case of a timing issue between the application, cache, SSD, Windows, whatever... it's a case of an application not managing its shutdown properly and the user being blamed for 'rushing' or shutting down when they shouldn't instead of fixing what is actually the problem.

Agreed. My gas/electric bill has risen more this year than the cost of setting up a homestead. Food and everything else has risen by as much and taken my financial comfort buffer away (and more). If it wasn't for that, I would probably have jumped at the chance. Maybe when (hopefully) things settle back down I'll jump aboard. I would love a full region to play with, even just a homestead.

Has anyone else ever typed a bit of text into notepad, or your word-processor of choice, or indeed entered data into any sort of application which does not automatically save that data? And then tried to shut down your PC? You get a nice little notice that you need to save the data and your PC stops shutting down and sits there waiting. Even my mouse cursor being over on the screen of another PC will stop this PC shutting down (it's a tiny remote keyboard/mouse utility from MS Garage to control another PC that you can see the screen of - in my case a media player PC on the TV). Add to that the common occurrence of a brief, pop-up message when Windows is shutting down to the effect of, "Windows is being prevented from shutting down by [some thread that hasn't finished its housekeeping]". Those generally disappear as quickly as they appeared, as their threads finish. Apparently Firestorm doesn't do anything like that even though it is saving critical data after pretending to close. Don't know about the official viewer because I don't use it; maybe it's the code in that and it does it too so it's an LL issue, not a FS one. Seems as far as support goes... I just have to guess when it's safe to shut my PC down and if I shut it down before a program that looks finished, is really finished, of course I will lose data. It's my fault, or Microsoft's. Nothing to see here, move along.

Yes, interesting opposing experiences. The quick shutting down is certainly the key, for me. It reproduces the exact fault every time, now I've cottoned on to it. No wonder me sitting here watching the cache files being written, waiting for a glitch, was unproductive. When I restart, there is a remnant, partial, uncompressed cache file left behind, truncated at whatever point its thread got killed I guess (or the write cache did). I'll have to investigate the write caching on that SSD out of curiosity. The fix for me, at least, is now easy. Give it a minute before shutting down. I liked the new, quicker viewer close too, lol. Edit to add re. the SSD cache: Write caching is enabled, and Windows cache-flushing is also enabled. That should be OK; Windows should be telling the SSD to flush cache anyway when it shuts down. Write caching should only be able to cause data loss if the system crashes or loses power. I do not think it is SSD cache related for the following reason: While watching the inventory cache file being written after logoff, which I have been doing for weeks now, I have got a pretty good feel for how long it takes to create and gzip that cache file. When Windows shuts down, it shuts the PC off more quickly than I think those inventory cache files take to write. So flushing a hardware cache isn't the issue; it's the Firestorm thread trying to create the cache in the first place which is being killed during Windows shutdown. I'm never really done much inside the inner workings of Windows, but surely there should be a way to tell Windows "this thread is important... don't go away until it's finished." As final evidence, I have just run a test with SSD write-caching disabled, so writes go straight there (supposedly, anyway). The inventory loss still happened just as before, with the remnant, truncated cache file when I restarted. Looks like the thread is being killed.

Yes - reliable reproduction! It is Windows shutting down before FS has finished writing files. I felt it from the start. It's that faster (apparently) closing of the viewer. It used to take a good number of seconds to close the viewer. Since the latest release version, it closes almost instantly but clearly (from watching the cache folder) has certainly not finished what it needs to do. No wonder I couldn't catch it happening by watching the cache. It needed me to shut down my PC quickly after closing the viewer. Even with Windows winding up a couple of sleeping, spinning rust drives (only to shut them down again - as it does) it still doesn't finish Firestorm's threads (or maybe the write cache doesn't get flushed - not even sure it's on or how it works with an SSD). Whatever, it is the change in Firestorm's shutdown that has caused this. I have always shut down my PC quickly like this after logging off, after Firestorm had closed.

@Lyndka CochraneAll of that makes a lot of sense - they are the sort of things I've been thinking. It does seem as if the cache file is not finished writing, and I do often shut down the PC quickly after exiting FS. I am now on the very latest beta and it has happened twice in four days. I've been trying to provoke it with a lot more relogs that usual. Support, at the moment, think it is a connection/network issue as I log on (thus not getting a full inventory from LL at that point???), but I really don't think so. I'm 99% sure that I have observed the cache file being written when I log off, and it being written smaller than it should be. If the inventory loss happened at log on, I would have the missing wearables and truncated inventory immediately then, not have it happen at the next log on. I'm watching every time I log off now, trying to catch that again so I can be 100% sure and report that.

I've reverted to an older version on request from support, to see if it happens there. Wow - it certainly makes me realise just what an improvement the latest FS version brought. My framerate has dropped by 75%!