Vulpinus

Yeah, and add to that "pay up front". You just have to laugh sometimes...

Perhaps the blog should have a rotating hourglass, or a swirly circle, or whataver the current "windows is busy" cursor is. You know, so we know something is actually happening. Except, nine times out of ten, it seems to mean that windows has crashed and doesn't know what else to do. Or even a status bar, yeah, with a slowly filling-up colour... which gets progressively slower as it nears the end, thus taking an infinite time to actually finish... and you reboot. Simplest of all, how about the time remaining counter that you get when copying a large folder from one HD to another... you know, the ones that start, "15 minutes remaining" and you go to get a coffee. On your return ten minutes later, it says "25 minutes remaining", so you make a snack and eat it, and log in to SL for a chat or whatever. Out of the corner of your eye, you see the message update to, "4 hours and 30 minutes remaining". So you go to bed, and cross your fingers that it's done by morning, and doesn't crash. ...or, maybe just update the blog when there's something to say...

... on 2017-03-28 ... I do wish they would give us a bit more notice, don't you think? I mean, I only have eight months to get some funds in my account now... :D

Coding issues aside (and yeah, it's frightening how changing one little thing somewhere can have ramifications in places you had forgotten even existed)... The worst thing LL did is enforce the "Resident" surname. My main account has a proper surname, but I really don't mind just having a username on my younger alts like this one. It's workable if not ideal. What I do mind is having that ridiculous "Resident" tag added to the end of it!

Zombie spawner... love it! I have got to get me one of those! Especially since I'm sat watching The Walking Dead right now. Glad your neighbour saw sense in the face of an impending zombie apocalypse!

Yes, that does look like texture thrashing; I used to get it a lot. Out of curiosity, when it happens to you, try TP'ing a few meters away. Do a double-click on the ground (if you have double-click TP enabled). For me, that seemed to cause the viewer to 'rethink' things and it nearly always stopped the thrashing immediately. I really think there have been changes behind the scenes because at some point it reduced a fair bit for me, with no local changes whatsoever. I did find (when it was bad) that using Black Dragon viewer mostly eliminated it. BD allowed much more of the graphic card's memory to be used for caching textures. If you are using Firestorm, on the graphics/hardware options there is a memory slider. I have mine set all the way up (it now allows 2GB) and I have not seen any texture thrashing since. I do not think that GPU memory is all there is to the issue though; I used to get it in places I am sure should not have been filling my GPU cache. Hence my 'changes behind the scenes' theory. So, check that memory slider. Obviously it can only go up as far as your GPU has memory.

Thanks Whirly. As you say, it's most annoying during combat, but also crops up using my other HUDs (home-made RLV-based weapon and clothing changer, AOs, etc) because they all use llTakeControls so I don't lose them in a no script sim. Even my cigar uses it! It's only a problem during combat though because I don't often use mouselook otherwise. As to switching to LL's viewer... not even this bug could make me leave Firestorm altogether I know the JIRA says there's no fix available, but I really hope it gets worked on some time soon. I like the new FS version very much, especially the quick-change graphics presets. I'll see how it goes and if I can train my fingers to do the back-into-and-out-of mouselook workaround quickly, before I get shot in the head while switching weapons.

Replying to myself (Well, best way to get sense sometimes, ) Apparently it's a bug in 4.7.9, to do with going into and out of mouselook. It's a real pain of a bug for me - keeps popping up and blocking my view in the middle of battles where I'm using mouselook a lot. Might actually have to downgrade for this one!

Is anyone else getting this? It's happened often enough now (including about five times in the last twenty minutes) that I know it's not me doing something silly. Specifically, left-clicking a HUD, any HUD it seems, sometimes causes the Edit box with the Move page selected to pop open. Not every time. I've not been able to spot a pattern that I can use to replicate it, other than just keep clicking HUDs and eventually it will happen again. Might be a day later, or the very next click. I hate intermittent faults. I have removed a few of FS's keyboard shortcuts so I could repurpose them in gestures. I removed them from the previous version and this new one, by editing the menu_viewer.xml and simply removing the shortcut="whatever" part. As far as I can tell this is not the cause; my edits work as expected, as they did in 4.7.7. Even if I did something wrong, how could it cause the menu to pop up when clicking a HUD? However, just in case, the changed build tool menu excerpt is below. Sorry about the weird formatting; UEStudio doesn't like these files for some reason. <menu create_jump_keys="true" label="Select Build Tool" name="Select Tool" tear_off="true"> <menu_item_call label="Focus Tool" name="Focus" shortcut="control|1"> <menu_item_call.on_click function="Tools.SelectTool" parameter="focus" /> </menu_item_call> <menu_item_call label="Move Tool" name="Move" shortcut="control|2"> <menu_item_call.on_click function="Tools.SelectTool" parameter="move" /> </menu_item_call> <menu_item_call label="Edit Tool" name="Edit"> <menu_item_call.on_click function="Tools.SelectTool" parameter="edit" /> </menu_item_call> <menu_item_call label="Create Tool" name="Create"> <menu_item_call.on_click function="Tools.SelectTool" parameter="create" /> </menu_item_call> <menu_item_call label="Land Tool" name="Land"> <menu_item_call.on_click function="Tools.SelectTool" parameter="land" /> </menu_item_call> </menu>

I'm not saying you're wrong about another variable (you're probably right) but with everything else set on Ultra and just turning off ALM and Water Transparency, it definitely stops me from rezzing. It's as if the viewer needs to see the land under the water, even though it rezzes on top of the water. I noticed that if I put a prim under water (on the sea bed, well under) and tried to rez on top of the water above the prim, I could rez there but not on either side. The cursor changed from the red no-entry sign to the usual 'drop your object here' cursor as I moved across where the hidden prim was. Also, I don't even get any context menu if I right-click the water (away from the hidden prim) but I do if I click the water above the prim. This is on my own parcel, but is the same on public-access sea where I first noticed that I couldn't rez my ship. A picture is worth a thousand words... or at least most of the above. Note I had to cheat to put the 'can't rez here' cursor in - my screen grab didn't grab it.  ETA: I just tried on another PC with a 'backup' installation of FS on. Different graphics card, lower settings, nothing really 'customised' about that config at all. I get exactly the same behavoiur on that PC.

Hmm... interesting. I tried many times to make sure I had tracked it down. Turning off both ALM and water transparency together prevented rezzing (I just got a red 'no entry' cursor when I tried). Turning either back on immediately allowed me to rez again. I'll go and see if I can identify the real cause...

If I set water to non-transparent, and Advanced Lighting Model off, I cannot rez on the water. Is this expected behaviour? LL or FS veiwer; same in both. If you wonder why I would do that, I can get an extra 20fps in sea battles like that. It's not often that I drop my graphics settings below ultra, but when battling pirates, I'll take any edge I can get. The work around is to switch graphics settings to rez, then back again. I'm just curious though if this is a 'feature' or a bug...

I still use LSL Editor 2.55, mostly because I can run a debug after a long scripting session and catch all the silly errors. Well... most of them... There are a few bits that are not quite right, or missing new features. For instance, a few llParticle options and occasionally either complaining about some syntax that is in fact OK, or not complaining about something that the SL compiler rejects. I can't remember exactly what those are but there are only a couple and easily spotted. Obviously I don't hit them often. So overall, I still like LSL Editor. Other than that, I use UltraEdit studio for programming in anything else; php, javascript, C++, whatever. I like the built-in communications functions too, for talking to various kit around here.

I thought I should put this post to rest, now I have my new 80/20 fibre. Not as fast as some have, but it's pretty good! It's FTTC and I actually get about 75/18. That might get better as things settle. So far, I have not had the issue this thread has been about since upgrading. Yay :smileyvery-happy: I have seen some very quick data coming from the content server connected to my ISP's network; easily sustaining 40Mb/s to 50Mb/s while a new place loads up, with occasional peaks at close to maximum. It really does make a huge difference when TPing somewhere busy. I once started another thread asking if extra internet bandwidth would be a benefit and never really got an answer (it's too 'personal' really - suck it and see is the only way). I have the answer now. There is another thing I have discovered that might have been partially responsible for my previous issues. Bufferbloat. My new kit seems to do very well, but when saturated my ping (not sim ping) rises from 16 ms to 100 ms average at times. That's actually not bad as bufferbloat goes, but I'm still trying some queuing tricks on my router to see if I can lower it. I'm not sure how much is caused by my end though, and how much at my ISP's end. My guess is that my old kit, when the line was saturated up and down, was suffering much worse with bufferbloat too which would go towards explaining my problems. So... problem solved and the local CDN server is impressive (thank you Monty ) ... Just for anyone curious, my new kit comprises: Zyxel VMG8324 modem/router, in modem-only/bridged mode. The chipset suits the FTTC cabinet I'm on. That feeds a Mikrotik RB850Gx2 router which splits out onto my various VLANs here and does firewalling etc. It's a very nice bit of kit for the price! Oh, and a new TP-Link T1600G-52TS Layer 2+ switch which replaced my perfectly functional but too noisy and hot Cisco 3560G. The TP-Link is fanless - a wonder (and I think unique) for a 52-port gig switch with basic L3 IPv4 and IPv6 routing!

ImojenSander wrote: Now the object is called hand and its in my objects folder with permissions copy no mod no trans, Do you mean that you are expecting to rez the "hand" while it is in your inventory objects folder? If so, that's not how it works. You cannot rez items directly from your inventory with a script. You have to put a copy of the item you want to rez into the item that is running the script along with the script itself. Drag it from your inventory and drop it into the button item's contents where the script is.

Spotted the reason... well, the cause of the servers losing the plot. After speed being mentioned above, I realised that I was accelerating it at one point, instead of decelerating. I got my vectors reversed when I copy/pasted during a small edit. That made it go a bit too quick and clearly the servers didn't like it if the missile crossed a region at that speed. I never spotted it because the missile was barely visible at the end of its range by the time that happened, and it only happened if there was no specific target set and no collision for a while. Plus I was testing just at the right (or wrong) distance from the boundary for the acceleration to happen just before the cross. After correcting that simple mistake, the missile doesn't go so far or fast and that itself has cured the issue, even when it crosses into the next region. As usual, the problem was really caused at layer eight.

Hmm... servers losing track of it seems exactly what is happening. It isn't flying all that fast (25-30m/s at rez) but obviously that's fast enough. STATUS_SANDBOX looks quite useful for testing things; I hadn't noticed that one before, thanks! It won't do here though as I want to have a useful range of at least 60m. My system works nicely and reliably from one side of a sim to the other if I don't restrict it to keep it 'realistic'. If I started the parrticles from the gun instead of the spear, I could at least kill them after a timeout and not be left with a rope disappearing into the distance. I tried it that way though and it often lags the spear, ruining the effect of it being tethered. Some thought and experimentation is required... (looks around for the bottle of Kraken rum to lubricate the cogs...)

I'm not certain if this belongs more in the Technology forums than here, but anyway... Can anyone shed any light on this, and/or offer a solution? Executive Summary Physical projectile, set as Temporary and with failsafe llDie() timer, does not die or get garbage collected if it gets too far away into a neighbouring region. The script works perfectly within the region, but seems to just stall outside, or still runs but the projectile refuses to die. Long-winded description I have a physical projectile spear, quite simply scripted for some actions on collision, and it runs a failsafe timer to llDie. It is also set manually (before putting in the gun) as Temporary. The spear is fired from a speargun and returns after collision or first timeout on the end of a ribbon particle rope. Tested within a region, it all works perfectly. It's really good! However, if it crosses a region boundary and doesn't get a collision quite quickly, it nearly always 'hangs' some distance away (as in a sim or more!) and often goes right through hills which it shouldn't be able to do. It does not llDie or get garbage collected even after five minutes. I've traced every step of the script and frankly it's simple enough. There's nothing wrong with the script. It simply seems to either completely stop running mid-flow, or the spear just refuses to die. Note: A key point is that the spear doesn't even get garbage collected. It is temporary. Even if the script were faulty, that should still happen if something external wasn't 'wrong' to prevent things happening. It isn't about going into a script-disabled parcel. If it does, it still doesn't get garbaged when it should. I checked. I've followed the particle rope and found the spear over two sims away, spinning in the air. If I right click on the spear, it instantly vanishes. I put llInstantMessage() calls all over the script to trace execution. I get the startup message, meaning the timer is set and everything is running. Within the region, everything happens correctly. On leaving the region and not hitting something quickly, I either get nothing at all (meaning the timer event didn't get called) or, occasionally, I'll get the manual 'kill' state being entered, but the thing still doesn't die. This is the manual kill state that gets entered from several places, including the timer. state Dead { state_entry() { llInstantMessage(llGetOwner(),"State Dead"); llRegionSay(vChannel,"MDead"); llDie(); } }Obviously the llRegionSay in there is pointless out of region. It's there for when things work, to signal back to the speargun for reloading. When I get the "State Dead" message out of region, the ribbon particles and spear still remain (and the spear doesn't get garbage collected) and I have to go searching for the spear to right-click it to kill it. Note that if I hit my target (or any llCollision event) and it's just over the boundary, that's not a problem. It works! It also works if I throw low and bounce it along the ground to stop its flight. That's not a collision event, and the failsafe timer kicks in as expected. It's not just a local viewer-side effect. I logged my alt on and could see the particales and stuck spear from there too. All I can think of to cure this is to detect new region and instatly die, but that means I can't use the weapon across a boundary, and it does work fine across the boundary if it hits something before it gets too far away, or whatever it is that causes it to stop working right.. Any ideas?

Monty Linden wrote: Bah! Easy way out. This could have been a journey of discovery! It still could be... how fast are the CDN servers? We'll soon find out.

Right then... I've just orderd 80/20 fibre and arranged some faster routing. Should be live within a couple of weeks so, unless anyone sees anything obviously wrong in the logs and wants me to check, I'll leave off the testing for now. 80Mbps... fill that SL!

You're all mean in this thread... ...but that doesn't make you wrong

You can get an attachment worn from inventory to delete on drop, but not on detach... If you drop an attachment, it seems to come out of your inventory (it no longer appears there) and exists only in-world. If you have a simple script in there with llDie() triggered on attach with no avatar key (i.e. triggered on detach) then the object deletes and still does not seem to reappear in the inventory. Not even in lost&found or trash, at least not immediately or after one relog. This is the documented behaviour of llDie(). The script is as simple as default { attach (key ID) { if (ID) {} else llDie(); }} I never knew about the above behaviour before, I've just done a few tests out of curiosity. Note that you cannot simply make the object delete if the user selects to detach it. It must be dropped to put it in-world, where llDie() works. You can't llDie() an object while it is attached either, so you can't try to catch the detach event and then run llDie() on the next attach. ... llAttachToAvatarTemp() is only for attaching a rezzed object to (usually) someone who doesn't own it. The object does not go into inventory at all and automatically deletes when detached. You cannot drop such an object.

No, my traffic shaping rules were disabled ages ago. I didn't see the point of keeping it on, wasting CPU time, when it was minimally effective. It was specific to my server's IP address anyway. I was checking my 1841's config a few days ago and thought to just check that after you mentioned trying it; I was right. I even tried putting my SL PC directly on my bridged public subnet for a while to mostly bypass the router... it made no difference. I've not done any SL investigations for a day or two but I'll be back by the weekend. I'm busy investigating router options and trialing RouterOS on ESXi to duplicate what my Cisco does for when (if) I go fibre. I can't justify the cost of a new Cisco box (1941 or similar) at the moment - or rather I can't afford their new G2 licensing on the security version of it!

Funny you should mention the Unacked data... I've just been sailing around Fanci's for thirty minutes. I had UDP BW set to 1Mbps and Mesh and Texture concurrency set to just 1. I experienced a few, very brief, saturation spikes but mostly my download rate stayed below a few Mbps. I captured one spike that lasted a few seconds and wireshark again showed a number of mesh gets and a ton of tcp segments. However... I then moored up and stayed that way for a few minutes. I noticed the Unacked data, which mostly seemed to be around a few 100KB or less, was jumping up and down continually. It did this for a least fifteen seconds and reached into MBs - I'm pretty sure I saw 12MB and 17MB pop up momentarily. Then it settled down. ... Strike the above - it's just started jumping again and gone up to 60MB. About five minutes later and still moored up, typing this. I have no idea what caused that - I had been sailing around that area for ages and didn't see anything happen to trigger it. Throughout that, my internet data was a trickle - less than 100Kbps. ... Other that the above spikes and weirdness, stats were 0.0% packet loss, sim ping around 170ms. As I'm sat here moored, typing this, the packet loss green bar is slowly creeping up... just at the right hand end of the scale now but still reading 0.0. Screenshot of texture console while moored:  To be continued... ETA: I have only had my alt logged on that once that I mentioned, so everything else is all my own fault.

Hey Monty, thank you for joining in the fun and for the information. Yeah - too much data - Seriously, if LL's kit can send it that fast, it has made me look at upgrading to 80Mbps down, 20Mbps up fibre. I'm currently exploring possibilities on that front re suitable hardware. My 1841 is old (about 9 years - not 90's ), but it has IOSv15 advanced IP services so it does *everything*. It's just too slow if I upgrade to fibre. It tops out at about 70,000pps. The saturation events really seem quite random. I can sometimes provoke them by camming a little away, or they sometimes seem linked to an avatar/vehicle arriving in the area. At others, there is nothing going on at all; just me floating along in a well-visited, quiet area. That log I gave Whirly was such an example. There doesn't seem a definite, reproducable cause on the face of it. I think the stats panel might be misleading during these saturation events. Maybe. I can well imagine that the UDP packet loss is entirely due to the saturation with tcp traffic. Also, the sim ping and unacked data both go to those sort of figures every time it happens, but are normal either side of the event. I'll try watching the texture console next time I'm there. I hadn't noticed it had a mesh line. From the wireshark logs, practically all the requests were for mesh and hardly anything for texture. The llmath/llvolume.cpp errors (100s of them) were just in that one log and haven't occured since. Just a localised, coincidental event that one. Pipelining is fun - I was tracing the conversations in the wireshark capture. Right then - Things to Try: I'll keep an eye on the texture console and stats and grab a few screen shots during and after events. My cache is already at maximum (10GBish) I had tried changing the mesh concurrency to just 1, and I still got the saturation. Quite impressive really that I'm getting that much data I'm pretty sure I restarted the viewer, but I will try again to be sure and see what can be done there. My 1841 does all of that. I used to have it configured to try to limit incoming nntp data to my server if other stuff was active too. It never really worked... like you say, downstream shaping is a bit late. I'll give it a try though, after I've played a bit with the above stuff.