Profaitchikenz Haiku

"Time passes slowly, just this side of paradise..." (Manfred Mann)

Be wary of getting the idle status too frequently, during my experiments with region monitoring I found that asking for this status once every ten seconds sometimes got and idle indication and sometimes not, the sim is not idled in a long continuous session but in a series of short bursts instead.. Although you could try to predict when a region is going to be idled by testing presence and finding zero avatars present, it can go off idle if if empty but somebody in an adjacent region looks into it. Quite how this is implemented by LL I don't know and so it's not possible to try and sense when it might occur unless you are able to put detection scripts in all adjacent regions.

It is good practice to stop animations when an avatar stands up from or detaches an object. You have very little time in the attach event when it's a null key but what you've posted looks close enough to what I would do. (How many different viewers have you tried this won?) I would test this with one animation at a time, attaching and detaching it, and using llGetAnimationList(avatar) watch what happens prior to attach, on attach, and on detach. When happy with each individual attachment and the animation, try two and see what happens. I can't reproduce what you've said about opening an animation from inventory and the effect on currently playing animations, but I was only able to test with P4 or lower priorities.

Leaving aside the obvious answers (fun, profit, avoiding the issues) there are a lot of graphics cards on the market that came out of China with a fiddled bios telling the OS "I'm a this" when the actual hardware isn't that at all. A utility called GPU-tech will identify such fakes as "Fake" although it can't actually tell you what the base GPU is that the cunning little (Prince Phillip Pejorative) modded. I've played around with a couple of these cards out of curiosity, and what I found is interesting: What I would regard as GPU-heavy programs like the TC3-TS2009-TS2012 Auran Train Simulators run perfectly fine on them, but go into a region in SL with a few pretty-pretty mesh avatars and watch the black screen arrive. Even just turning around too quickly in an unpopulated region will cause them to crash, where an old but genuine GT520 can manage to hold it all together. This isn't a texture-size problem, many of the Auran assets have 1024x1024 textures, the mesh in there is also quite complex, and the size of the area being scanned and displayed can be three times the area of a typical SL region. Some of the Devs who've posted above might know more on this.

It looks like you have two closing braces on the very last line (in the screen snapshot, the cursor is between them) that would generate a syntax error default { attach(key attached) { if(attached) {//each time I'm attached owner = attached;//can only wear things that belong to you, so store the wearer's uuid toggle = FALSE; llRegionSayTo(owner,secret_channel,"show"); }//start off showing stuff } touch_start(integer total_number) { toggle = !toggle; if(toggle) { llRegionSayTo(owner,secret_channel,"show"); } else { llRegionSay(owner,secret_channel,"hide"); } } } // } one brace too many

Builders Brewery had the syntax file for the Context editor I use, they might also be the source of other editor highlighters.

Yes, it is possible and you might not even need Blender as you could make the textures in Paint.net or Gimp. The broad workflow is 1 Make your prim build 1a Optional Make the texture(s) and map them to the individual faces to help with subesquent texturing 2. Set hidden prim faces to transparent so that they do not appear in the final mesh (This stage is not, I believe, possible with the TPV export trick Chin describes?) 3 Identify all the faces that want to have different textures, or parts of an overall texture applied to them, and colour each one differently (or map your own alignment or final texture to them) 4. Create your mesh model with the tool 4a (optional) Make a simpler build from prims to represent the required physics, same trick with removing hidden faces, and create the required mesh from it. 5. Upload to the Beta Grid or a standalone to play around with textures.

You will have to post the script here for anybody to give any sensible advice.

I wonder if you could play around with CHANGED_REGION to try and make it do the same when you log in as when you attach it from inventory? As far as I know, attach from inventory restores all the saved script details from when you detached it last, but TP-ing (and hence logging in) might not have the same access to stored last state as attach. Just guessing, but I am struggling with similar problems in other Grids when Hypergrid arrival results in attached scripts arriving in a dead state, they only resume operation when detached and re-attached.

This is something that has been puzzling me for a while., I would often log in and then be met with one or two error IMs from a couple of scripted objects. Adding extra diagnostics to them to send me offline reports showed though that it was happening at rare intervals and I was getting the delayed error messages when I logged in. Are you sure this isn't the same in your case? Is the culprit an attachment? All I can think of is that when you log in you effectively enter a region just as if you TP there when already logged in, and so there is an initial region loading as it tries to get all your scripts up and running.

If the OP is comfortable with using scripts, then this post describes how to stop animations that might have been set running by means of the old permissions hole.

It could be a left-over animation from something you've used in that retgion. Go to a different region, preferably a low-populated one. Under things like "avatar health" or the world menu look for "stop animating me" and click it. Check to see if the problem has stopped. If not, remove all the things you have on and start replacing them one at a time until the problem re-appears.

Try removing the name of the desired object from the listen setup. Then, just inside the listen, llOwnerSay(name + " " + msg) to see exactly what is being received. It's possible that the touched object isn't sending any message, so again, in that script, llOwnerSay() exactly what is being said on that channel so you can compare the results of the touch with the results of the listen events.

Save it as a png but make sure it's only 24-bits. Transparency requires a 32-bit save.

Try a different region in case there are issues with the one you were at. If you haven't changed anything in your settings then it is more likely to be a region. Additionally, check what is happening on your PC, a virus scan or a windows update going on in the background could cause similar issues.

I got interested into the way key2chan works, especially since the wiki says this : Keys cannot be converted to integers, So what seems to happen is (integer) ("0x" + (string) key) generates a 32-bit integer by grabbing as much of the key as will not overflow 32 bits before then turning on the top (-ve sign) bit just in case it wasn't already on. Which then fits into Suggesting that one day (out of how many?) one of my scripts is going to say something to the wrong person

Given that any other method is going to require processing AND as has been pointed out, still runs a risk of getting it wrong, I'd personally go for the whole key. That said, I've used that key2chan method and never (yet) had it talk to the wrong person.

The closest to what Love is contemplating I am aware of is a library function key2chan, which takes an avatar key and generates a -ve channel number from 8 bits of the key, but I can't recall if it's the top 8 or bottom 8. eta it uses 0x80000000 | (integer) ("0x" + (string) key)

Just to add, the latest Catznip has now got the "save scripts in inventory as mono" checkbox so it works.

Muy Bhad, Thanks Wulfie

Experiment with taking the desired target vector and multiplying it by the local rotation, or an empirically-determined correction factor. vector sitPos; vector target = <0.0, 0.0, -3.0>; // then in the state_entry when initialising the sit target rot tweakMe = llEuler2Rot(<0.0, 90.0, 90.0> * DEG_TO_RAD); // example for an oddly-rotated child prim sitPos = target * tweakMe;

I encountered a similar problem when I was working on trying to measure region performance in-world using scripts instead of the metrics provide in the viewer statistics. Any such measuring scripts are subject to the same performance issues that they are trying to assess. They add to the load, if the region is not subject to any underlying issues they impose no extra load, but otherwise, they add to the problem. The resulting measurement is effectively "for indication only" because they are not independent. As with your other comment on Target Omega, it would be useful to show people where optimisation isn't possible'

I'm seeing two different areas being discussed here: Memory, and Speed. Memory efficiency is vital for avatar attachments so that arriving avatars get assimilated into the region with little bother. Speed is more important to stuff that's happening all the time in a scripted object or set of objects where delays will have observable effects. I've tried to measure them both using in-world tools and it's a real pain. We really need access to the top-scripts menu that is only available to estate managers on private regions to be able to properly assess the results of tuning scripts for speed or memory efficiency.

I can't help with what Innula decided on, but the simplest way to do what you want to do is to call llAvatarOnLinkSitTarget for the particular child number. If it doesn't return NULL_KEY then you have found an avatar on that particular prim.

Power-on failure is a very common phenomenon, and as Coffee mentioned, it's usually the inrush current that on-board capacitors are demanding that is the culprit. Simply upping the power supply won't stop that happening though. Most electronic devices have a shorter lifespan when worked at an elevated temperature.