Vulpinus

Another option, thanks! There are a few useful bits on that page that I'll squirrel away.

Oooh, that's easy. I'm so glad I asked, thank you! Never occured to me that there wouldn't be a corresponding detach at log off.

Since google hasn't helped, I'm guessing the answer is "no", but I had to ask before I embark on a work-around. Basically I want to detect the differece between an item being already attached at the point of log in, and being attached from the inventory. I'm building a system which uses RLV. The system HUD needs to detect already-worn items from the shared folders, when the HUD itself is attached to the avatar. A table of these already-worn items is then populated. Simple enough and everything works perfectly, except if the HUD is already attached when the avatar logs in. Then, sometimes, not all of the worn items get detected. I guess items are attached in some order during login so my HUD misses any that get attached after the HUD asks RLV for the data. That's just a guess, mind, but it seems to be the case. I'm thinking that the only ways around this are: 1) Delay requesting data through RLV for a while after rez/attach, which I don't like because a user might attach the HUD manually and try to use it quickly. Like me, I hate waiting! Besides, how long a delay...? (experiment... lol) 2) Repeat the reading at some time later and quietly update. I don't like this because it would again cause delay if the user is trying to interact at that point in time, and it is wasteful of processing time. It does take a noticable length of time to parse the data for a lot of shared folders and I'm trying to minimise delays, not increase them. Any hints???

lol, like it. Not so much obsessive preservation, but it did cause me major grief last time I did a clean install even though I followed the guide to the letter. Firestorm wouldn't even run at first. Yeah, I'll bite the bullet later.

Thanks for that. Yes, other people see me running as expected. I should have thought of checking that (Excuse for stupidity: total six hours sleep in the last three nights, lol) I tried recreating the bridge, and I had laready been through the other things in 'Avatar Health'. So it's a local cache issue, obviously the file is reference by a single key across all instances of it. Makes sense. A quick google hasn't revealed anything about fiddling with cache at a granular level, so it looks like I'll have to clear it. D'oh! Either that, or just find another running animation that I like (which I haven't so far)... I'm looking...

Wierd one... I use Firestorms client-side AO, loaded with my favourites. My running animation is run_rookie from the Akeyo NanoAO Rookie HUD. It's always done the job for me despite having more expensive ones. Yesterday I noticed that I had no running animation; my avatar just slid forward in a static pose when I ran. The pose appears to be whatever standing animation was active. I've checked that the run_rookie file is still where it should be, and tried to play the animation directly. Nothing happens when I play it; no animation whatsoever. All other animation files work normally. Obviously I have made sure that I'm not wearing any other animations; I've gone down to completely naked. Next I found another copy of that animation file in my inventory and tried it; again nothing. Then I attached the Akeyo HUD that I pulled the file from and ran. This time, I got the default "I've got a bug up my ass" system run animation, not the one that is in the HUD. I pulled the file from the HUD (again) and tried it directly; no animation played. So, it's as if that animation file, wherever it exists, no longer has anything in it. A corrupt resource on the server perhaps? I'm sort of assuming that since I've tried different instances of the file that it isn't a corrupt cache locally, but could they all point to the same cache entry? Is there any way to just clear certain parts of the cache, even a single file, even if I have to write a script to do it? Last time I did full clear Firestorm threw a complete wobbler and it took me a full day to get things working again.

Thanks for all the replies folks. A region issue certainly makes some sense from what I've noticed. The sim I'm in seems to be restarted quite often, even when nothing is on the notice blog. I'm often kicked out or not able to tp in due to restarts. Oh well, such is life. I've got my script done now anyway, and I'm not moving because I like the view!

Yeah, I suppose the region issue fits. I noticed earlier when I used a premium sandbox for a while that the error never happened. Sometimes it's fine for ages at home though; just not enough. I'm on mainland, Saena, by the way. Hmm... I've just remembered running a script monitor for a while a few weeks back. I did notice a couple of residents near me that have ridiculous numbers of scripts running on their avatars. Like 300-400, several to low tens of megabytes and 100's of us of runtime. I wonder if that affects the issue. Funny thing is on the odd occasion that I've cammed over there out of sheer incredulous noseyness, they've always been mostly naked! Where on earth are all those scripts...?

Thanks, I use LSL Editor Community Edition. It's just done it again at the next little script change I tried to put in; three times before a successful save, as fast as I could possibly click the mouse. The error response is immediate. If I am simply getting very frequent, corrupted outgoing packets causing the issue, then it doesn't happen with any other internet use. My server runs all sorts of heavily-two-way protocols here when I need to turn them on for work; SSH, FTP, SFTP, HTTP, all sorts of stuff. I even run an IPv6 routed connection into here. If I had upstream issues myself bad enough to cause this much trouble in SL, it would be most obvious! It is only in SL that I seem to get network issues. That's why I say that it makes me feel the way LL uses the protocols, or the way the servers handle requests, is far more suspect than my own network. If SL can't handle my internet connection, SL has issues. I know it's along way from the UK to SL's home, but I can talk to anything else, anywhere, without such issues. Even the error messge itself says it's the server... *I should add, the witching hour is the only time I struggle with my internet feed, due to all the people who won't pay for proper access and flood the wires with p2p traffic at midnight. That grinds most of the public UK internet to a crawl at that time, lol.

I am so sick of seeing this... I seem to spend more time having to reopen scripts (either in-object or from inventory), repasting the contents (if I remembered to copy them) and hitting 'Save' again in the hopes it will actually save this time than I do writing the scripts in the first place. Is it just me??? It's just happened three times in a row: This happens more often that it saves successfully and it is really frustrating. The error usually pops up pretty much instantly after I click save. It's not like it is trying for ages and failing, more like there's an instant 'no, go away' response from the server. It's been doing this for as long as I've veen writing scripts (several months) and through different clean installs of the viewer. If it's related to 'my' internet connection, then there is something amiss with the way LL uses the internet because I have no issues doing anything else on my connection from downloading nntp or p2p at 20Mbps, skyping, streaming TV or playing UT on a server on the other side of the world. I have zero packet loss every time I check, ping is 120ms-ish, time dilation is .999, etc. My connection on this PC is a static-NAT through a dedicated public IP with a Cisco 2851 router! And no, I'm not doing those things at the same time as using SL. I know it hits the network hard with multiple streams; at most I might have a browser window open looking up some command parameters... or this forum. ARGHHH... IT'S DONE IT AGAIN...AND AGAIN... - FIVE TIMES BEFORE IT SAVED SUCCESSFULLY!

Underneath the base terrain level? No. You can't have anything with its origin below the terrain at that point, even if the terrain either side of it is lower. The only solution is to lower the terrain level then build an artificial terrain over it, with the tunnel in that of course. I know, I wanted to do something similar myself.

Yeah... thanks for that. I was coming to that conclusion. Easy enough to do. Thanks!

I've made a 'box' that uses llAttachToAvatarTemp* to give out and attach its contents as temporary items to avatars that click on the box. Like those things that give out food or drinks when clicked. It works great (after a lot of reading and playing) but... If I give the box itself to someone else, the box cannot then give out its items to other avatars unless I make the items transferable in the next-owner permissions. They also need to be copyable of course. Is there a way around this? I wanted to sell the thing, but if I have to have all the box's contents as copy/trans then there's nothing to stop some unscrupulous person reselling the contents. The contents are the clever bits! It seems a little contradictory, given that the wiki says that transferring ownership of the items sort of negates the point of llAttachToAvatarTemp, but later on says that the function fails if the items are non-transferable. I get that it's the difference between a third-party being able to own the given items, and the owner (second party) having access to them, but still... Am I missing something here? (wouldn't be the first time, lol) *Edit to clarify: the box temp-rezzes the items which then llAttachToAvatarTemp themselves to the avatar, of course.

Thanks Dora, but I'm not simply spinning it, I'm making it orbit about another object and rotate on it's axis at a specific rate. While I might be able to do the rotation alone with llTargetOmega, I've seen viewer-related issues with that which make it unreliable for an accurate system. I have used llTargetOmega in other parts of the build. I reported the issue as a bug last night. Unfortunately it was closed on the incorrect grounds that the issue was caused by moving another prim at the same time... I had already stopped that prim and even removed the movement of it completely from the code. Oh well.

No I didn't use llSetTextureAnim (might investigate doing it that way though...). I'm still finding my feet in terms of what LSL offers. I simply(?) used sin/cos formulae to calculate the position of the moon, and updated the object's rotation along with its position in a call to llSetLinkPrimitiveParamsFast(), like this: llSetLinkPrimitiveParamsFast(moon, [PRIM_POSITION, <Y, X, 0.504742*scale>, PRIM_ROT_LOCAL, sunrot*<0, -1, 0, 1>]);

Bump/Brighness does seem to work well with my planet textures. It's an easy way to give them surface detail. Just a final update on the issue: keeping the planet in edit mode stops the issue occuring. The planet continues to orbit normally as per the script with the bump mapping correctly applied. As soon as I close the edit window, the flickering issue returns with the bump mapping being removed/reapplied to the texture with every movement of the planet. Looks like a bug somewhere to me. C'est la vie!

I must have missed the very lowest setting on the slider, it does indeed disable bump mapping and thus stop the issue. Everything above that keeps bump mapping enabled. It happens on the other PC too, just the same, on both Firestorm and SL Viewer. It's a different (older) PC that I use as a media server in the house. Firestorm's Info: CPU: Intel® Core2 CPU 6600 @ 2.40GHz (2400.03 MHz) Memory: 4095 MB OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7600 GT/PCIe/SSE2 Windows Graphics Driver Version: 9.18.0013.0697 OpenGL Version: 2.1.2 ... Anyway, like I said I'm not bothered by it now I know I can't really fix it myself. Thank you for your help.

SL runs fine on either panel. main and secondary. I often have two logins simultaneously (mine and my wife's) with one on each panel;.when I want to duel my Fennux for example and my wife's not here. Now that makes things run slowly locally (to say the least, lol) but things still run normally if I minimise either instance. I added to the previous post that the issue is the same in SL viewer too. Oh well, I'm not too bothered about the issue now I know where it's coming from. I'll watch out for similar instances though and try another graphics driver next time I have to reinstall (I do that about every year on average) I'm just firing up another PC to see what happens there...

Oohh... big correction to what effects the texture issue: Turning off the 'bumpiness' texture setting on the planet stops the issue as well. I had it set to 'brightness' as that gave a good 3D look to the surface texture on the (smooth spherical) planet. Setting bumpiness to None immediately stopped the issue, even while the rotating outer was still rotating. So, it looks like it's not the texture being softened/sharpened, but the bumpiness application being delayed when the planet is moved (while the outer 'universe' is rotating at the same time). Watching the planet very closely seems to confim that.... changing the Bumpiness to something that looks out of place (I used Woodgrain) makes it obvious that this is indeed the case. Edit to add, the issue is identical in SL viewer, it's not just Firestorm.

I just tried sliding the quality slider, in steps, all the way to the bottom. It made no difference to the issue. Only stopping the rotating outer stops the flickering/softening effect. The issues on the HTTP Fetching Issues page don't really effect me; vary rarely I will get a grey face (my own or another's). I did notice the lost packets on the output I just posted; that surprised me as I occasionally check for that and have never seen anything other than 0% before. I think it was probably while I was playing with a squid proxy the other day. My router can handle many times the traffic I can generate; It's a Cisco 2851 and routes my connection for SL through static-NAT to a dedicated public IP address. It's hardly taxed at all. My internet connection is 21Mbps ADSL and usually very good; I can saturate it with NNTP, FTP, HTTP downloads easily. The internet is a fickle beast though, lol. Yes, the 560Ti is quite a nice card although a bit old now. I have it running a pair of 1920x1200 panels which taxes it a little but it handles things well most of the time. SL taxes it harder than anything else... the fans power up to full as soon as I log in. It manage a good frame rate at the nearly-highest quality setting, generally around 40+, sometimes down to 25-ish and rarely down to single figures if I TP somewhere new or very busy. I run Firestorm maximised on one panel (not 'Full Screen') and the other panel has just normal PC stuff like my web browser and file manager.

Here's the full info. My graphics driver is most likely not up to date but not that old. I end up with so many issues when I do update it that I only do so if I really need to. I run a few 3D-intensive programs like Accelrys Discovery Studio (3D biochemistry molecular visualisation) and each one seems to have graphics 'issues'. Compatibility is a great thing, lol. Firestorm 4.6.5 (40833) May 5 2014 06:27:24 (Firestorm-Releasex64) with OpenSimulator support Release Notes Second Life RC LeTigre 14.06.06.290709 Release Notes CPU: Intel® Core i7-2600K CPU @ 3.40GHz (3392.3 MHz) Memory: 16368 MB OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 560 Ti/PCIe/SSE2 Windows Graphics Driver Version: 9.18.0013.3182 OpenGL Version: 4.4.0 RestrainedLove API: RLV v2.8.0 / RLVa v1.4.10a libcurl Version: libcurl/7.24.0 OpenSSL/1.0.1g zlib/1.2.6 c-ares/1.10.0 J2C Decoder Version: KDU v7.3.2 Audio Driver Version: FMOD Ex 4.44.32 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Not Connected Settings mode: Viewer 3 Viewer Skin: Starlight (Silver Blue) Font Used: Deja Vu (96) Draw distance: 192 Bandwidth: 1500 LOD factor: 6 Render quality: High-Ultra (6/7) Texture memory: 512 MB (1) Built with MSVC version 1600 Packets Lost: 901/705,409 (0.1%)

@Nova, no I haven't run any measurements, but I can say with certainty that my code reduces the calls to llSetLinkPrimitiveParamsFast by 75% and greatly reduces the overall number of calculations each cycle, compared to the original code I borrowed as a proof of concept. I'm a newbie to SL and graphics-related stuff, but was earning a living as a (very good!) consultant system analyst/programmer in assembly language and C++ many moons ago. These days I design high-availability virtual server and network infrastructures, lol. In short, I'm a bit of a computer :matte-motes-nerdy: So, I can say my code is more efficient :matte-motes-wink: ... Anyway, after playing with my viewer settings as suggested (thanks Freya), and not seeing any change in the issue, I found something that did make a difference... stopping a larger spherical, rotating background (the universe around the system) that was simply done with llTargetOmega. When I stopped that, the texture on the planet immediately stayed sharp. So that's definitely a display issue on my PC. I'll try another PC setup later, and a different viewer, but it seems there's nothing to continue here. Thanks for the pointers!

I have a simple script that causes a planet to orbit smoothly about another and rotate on its axis. Originally I used an existing script from somewhere else which I then mostly rewrote to make it more efficient for the server to run. My script uses sin/cos functions to calculate the position, improves the efficiency of each position update cycle and minimises updates to the objects. I'm guessing this is more a script-related discussion that a texture-related discussion. With my improved code, I notice that the orbiting planet texture seems to flicker continually. What is happening is that the high resolution texture is being 'softened' on each little movement, then sharpened momentarily before the planet is moved again. Like when a texture is first displayed in the viewer at a lower-appearing resolution and then sharpens a moment later. This did not happen on the original code. On close examination I can see that the texture in that case never gets chance to be sharpened; it is always soft. Stopping the old script (and hence movement) allows the texture to sharpen. At least it proves (I think) that my improved code is running more efficiently! Is there a way to avoid this issue and keep the texture sharp as the planet moves?

Thanks Jenni, what you say is exactly what I have discovered over the last few days as I've watched the traffic, looked at the headers and done more reading. That, and the issue of some objects simply never loading which went away as soon as I removed the proxy. While I do occasionally have up to three active clients here, I think the effort required to implement a better solution isn't worth it. My network connection is quite good. I just have a habit of trying to optimise everything. As of last night, I removed squid from the chain. I reprogrammed the router to still use a dedicated public IP for SL with static NAT. So, no NAT/PAT translations to get in the way. So far the only benefit I'm sure of is the lower CPU use on my router, lol. Not that is was exactly overloaded in the first place, the thing is good for far more traffic than my WAN connection can give it.

I recently set up the squid caching proxy on my server and have been caching SL on it for two days now. Just wondering if anyone else is using squid and has any SL specific configuration tips. I basically followed the guide here: http://wiki.phoenixviewer.com/squid_proxy_cache although I've set up squid before for general caching. Squid seems to be working OK, it's certainly caching and is up to 1.3GB now, out of the 500GB partition I cleared for it. I only use it for SL. A side benefit of the above is that my connection on the internet side of the cache is a dedicated public IP address with no NAT or anything to slow things down. Just simple (but effective) firewalling with a proper Cisco router. It's a bit hard to tell yet if it is actually beneficial because I had to do a clean install of Firestorm so lost my local caches. Everywhere is now taking an age to render first time I visit. 'Texture Refresh' often seems to lose as much as it refreshes, lol. Oh, and an odd issue of some objects simply refusing to render for my wife's account, at all, no matter what I try. I know they are there because I can see them in my main account, but my wife's account can't see them or click them etc... they just don't exist for her.