Innula Zenovka

Take a look at your crash logs -- go right to the end of the very long text file and then start scrolling back to when things seem to start going wrong (when the log starts saying "Error"). Does that give any indication what the problem is?

Voreian wrote: I don't get why everything on SL isn't free,.. get a real damn job ya losers Doesn't matter if it's free or not. If I've made it, it's for me to decide what to do with it, not for you to take a copy if you feel like it.

As the others have said, more information is needed. "My viewer keeps on crashing" is a bit like "my car won't start" -- could be anything. If you're using 2.7 or .2.8, then try turning off dynamic shadows before you log in. Those can cause issues, I know, on log in with some systems, no matter how good the graphics card.

Thanks, Void. I've always wondered why the volume detect trick isn't more widely used. I only found out about it by accident, and, because it's so much simpler than the normal "phantom child" script, I wondered if it was unpopular because it's unreliable. I know you can't toggle between phantom and non-phantom using it, but, other than that, it's always seemed to me a much easier way of doing the same thing.

Coincidentally, this bit me yesterday when I made something that uses the Advanced version of the Phantom Child script in the wiki library. This tries to preserve the prim's texturing when it works its magic, by reading and then reapplying llGetPrimitiveParams(PRIM_TEXTURE), but if the object isn't full perms it removes the texture altogether. I'd been thinking of trying to revise that script using llGetLink and llSetLinkPrimitiveParamsFast, so I didn't have to put a script in each child, but I guess this rather snookers me.

Assuming you want the prim to rotate around its own local z axis (that is, around the blue arrow when the ruler is in local mode, rather than world mode, and you're looking at that particular prim using "edit linked parts" rather than the whole object), try llTargetOmega(<0.0,0.0,1.0>*llGetLocalRot(),1.0,1.0);

If you make any prim other than the flywheel the root prim, then the flywheel should behave as you want. llTargetOmega makes the individual prim rotate unless it's called from the root prim, in which case it turns the whole object.

From what they have been saying in their respective forums and blogs, the developers of both Cool VL and Singularity (both based on the old 1.2n code) seem pretty confident that they will be able to display mesh reasonably soon. Only time will tell if they are correct, of course, but it's by no means certain that 1.2n viewers will vanish from the scene if people want to use them.

llDetectedTouchFace

There are several in-world classes. NCI and Builders Brewery both offer them, to name but two. For what it's worth, I got started by doing some of the self-paced introductory tutorials at the College of Scripting http://slurl.com/secondlife/Horsa/43/236/84 and then finding a simple project that interested me (at the time, as I recall, I was trying to make windows switch between being visible and invisible and getting doors to open and close) and asking lots and lots of questions in the College of Scripting's in-world group and the Scripting Tips Forum. And I studied -- still do -- both the old LSL wiki and the "Official Wiki". I don't mean to be discouraging, but I really think making decent breedables might be an over-ambitous first project for a beginner. They really are rather complex pieces of work, requiring a very detailed knowledge of a lot of different types of scripting.

The message you're getting, I think, means the script is trying to play an animation without having the necessary script permissions. It's nothing to do with your AO or anything like that. Scripts need permission animate your avatar. If the script is in something you're wearing (or sitting on), the request is granted silently and automatically, but the request still has to be made in the script. Normally, a script in an attachment will request PERMISSION_TRIGGER_ANIMATION in the attach event, which fires when you attach the object, not unsurprisingly. Off the top of my head, the most likely reason you'd suddenly start getting this sort of error is if you've reset the script while you're still wearing the object (it shouldn't happen if the script had proper error handling but not all scripts do). But detaching it and then reattaching it should fix that, I would have thought. If it doesn't, try rezzing it on the ground, then resetting the scripts (and ignoring any error messages) and then take it back into your inventory and wear it. If that doesn't work, you might ask about it in the scripting tips forum, and see if anyone there can suggest anything.

Quite how you synchronise the two animations depends, I guess, on whether you're intending to start both animations simultaneously or to synchronise them if you're already dancing and then invite someone to join you. Either way, I would have the main script -- the one that handles the sensor and dialog -- also get permission to animate the wearer when it's attached, so that's one less thing to worry about. Then, send a link message to the second script, when you've selected your prospective dance partner, with the uuid of the avatar with whom you want to dance. In the run_time_permissions event of the second script, if the invitation's been accepted, start the animation and send a link message to the first script telling it that the invitation has been accepted, so do stuff to start the wearer dancing/synchronise the two, or, if the invitation's been declined, send a link message to pop up a dialog asking the wearer what to do next. ETA --come to think of it, probably it would be better, when the second script obtains permission to animate your partner, to have it send a link message to LINK_THIS and then start (or try to synchronise) both animations in the link_message event.

Just in case it's not clear, this means you'll need at least two scripts in the hud, since a script can only hold permissions for one avatar at a time.

Come to think of it, Phoenix sets its own cache by default -- go to Edit-Preferences-Network & Folder, and it's Disk Cache Location (by default, in Windows 7, Phoenix uses C:\Users\<your windows name>\AppData\Local\PhoenixViewer). In V2, it's Me-Preferences-Advanced, and I can't remember what the default is because I always change mine as soon as I install it. But I really think your issues with crashing were more likely to do with bugs in 2.7n, which certainly could be rather crashy for some people (though I found it pretty stable), and which seem to be resolved, by and large, in 2.8. Turning off shadows usually fixes most problems I've encountered.

One of my friends once IM-d me saying her skybox had been invaded by three characters demanding money with menaces. I tp-d over, whereupon they caged me and started making similar demands. I just stood there quietly in my cage, ignoring them as I filed ARs on all three, then returned their cages and whatever, sent them home and sim banned them. She could have done the same, but was, understandably enough, sufficiently surprised by their sudden home invasion not to think so to do.

2.8 is the now the beta download -- it's fixed in that.

I think the sequence -- and I could be wrong -- was that someone (probably Phoenix) first introduced this feature separately from RLV. Henri Beauchamp adopted it for Cool VL, and, when he did that, realised that RLV could be used to adjust the offset by script, per animation, if an extra command or two were added. Marine clearly agreed with him, and added @adjustheight (written, I think, by Henri)  to RLV 2.5, commenting, "This value can already be changed through a debug setting in most third party viewers, this command allows to automate the change according to the animation." And if you want to know how to calculate the adjustment the script should apply, Henri explains how in his forum. So, in short, most (if not all) TPVs had this feature before RLV adopted it. Now that @adjustheight is part of RLV, any RLV viewer has to have this feature, whether accessed via the debug settings or the UI. In practice, they'll almost certainly have had it anyway, RLV or not, but if you want to access it by script, to change the offset automatically when your AO plays the animation, you'll need to turn on RLV for the automatic bit to work.

Your two main options are to make the laptop rez in position when the appropriate animation(s) are being played or, if the laptop is the only prop that's sometimes needed and sometimes not, to make the laptop part of the desk and to use llSetLinkAlpha to turn it visible or invisible as needed. I'd be very much inclined to go with the latter, I think, on the grounds it's a lot simpler. Unless, that is, you particularly want to move the laptop round the desk depending on the pose selected, in which case it's a bit more complicated, and I'd probably go for rezzing it in different positions. But I think I would try very hard to keep the laptop in the one place, because both ways of moving it are going to look a bit odd in practice.

I had llDetectedTouchST on the brain because I'd been using it for something. You're right, of course; llDetectedTouchPos would give you the region position exactly. Though, come to think of it, I've got a feeling llDetectedTouchST might be useful, too, when you're trying to figure out which cell was touched, so you know how to centre the child prim. A friend of mine made something like this that he showed me recently -- if I can find him, I'll ask him how he centered the child prim.

I think the solution is to use llDetectedTouchST to detect where on the prim's face you've touched it and then use llSetLinkPrimitiveParamsFast to move a small child prim to that position to highlight it. You'd need to figure out a formula to tell the child prim where to go so it centres itself on the box you've touched rather than the actual position, of course. I'm not very good at calculating that sort of thing, and I'm too tired to try to figure it out (the details would depend on how you're dividing the texture up anyway), but maybe someone else could assist there. But I think llDetectedTouchST and llSetLinkPrimitiveParamsFast are, between them, going to hold the key to your problem.

You can certainly have several different viewers installed on your machine without problems. I have 6 or 7 different viewers at any one time, because I need to test my scripted stuff on everything people are likely to be using it with, and I've never had any trouble because of it. The "Phoenix and V2 conflict" idea stems from the fact it's a seriously bad idea to have them share a common cache -- it's a bad idea to have different viewers using the same cache anyway, but Phoenix and V2 really don't like sharing them. That shouldn't crash your viewer, though (or at least I don't think it should). It may very well cause your inventory not to load properly, or you may find yourself wearing bits of pieces of several different outfits when you log in with one, having used the other the previous time, but it shouldn't crash anything. I'm told there are several issues with the current official download, at least for some graphics cards at some graphic settings, that are now fixed in the latest beta version, 2.8 -- that might worth checking out.

It would be easier to advise if I knew a bit more about the script you're using. How does it know when you want to play the animation and stop the avatar from using the movement keys?

No, llGiveInventoryList gives everything in the list you've specified. How you make up the list at run-time is up to you. So if, for example, you wanted to give someone a folder comprising a landmark and a notecard, the names of which you'd already assigned to variables, and that the string "item" holds the name of the selected item, you could say, llGiveInventoryList(id,"a folder of stuff", [notecard+landmark+item]);

There's a New Products forum over the road at SLU, and doubtless other independent forums have theirs, too. Maybe LL think that's sufficient.

Toysoldier Thor wrote: YUP thanks for the heads up Snickers.... I looked and sure enough a ton of my PRIMS in my inventory - like my selling vendors and countless other prims are set to unknown creator now too! I guess this was the outcome of today's ASSET SERVER snafu. Isnt this marvolous! I dont even know how LL will fix this one! we could open a JIRA but that is like buying a ticket on the titanic with LL - you know the boat wont make it to the other port... most JIRAS just sit idles and not looked at. This will be one of them. Thankfully my sculpty maps - which are textures - do not seem to be buggered up by this screwup. You probably know this, but others might not .. if a prim or object contains anything (e.g. a script or animation) that's not made by the same person who made the prim itself, it's going to show up as "Creator Unknown" when you look at it in your inventory. If you rez it on the ground (or wear it) and then look at it, it should show the creators of the various elements, and if it doesn't, there's something wrong, but while objects are still in your inventory, "Creator Unknown" isn't necessarily anything to worry about (unless you know you made the object and everything in it). Obviously, this can't apply to items other than prim objects, so shapes and scripts and so on should always show a creator.