Berksey

Rolig, thank you for the bit on getting prims by name, the information was there but I didn't know how to make it go. That just helped me a whole lot!

Good practice is to make sure every item in the object's inventory has its own next owner permissions set independently in the Content tab. Setting an object's permissions doesn't necessarily keep people from stealing the object's innards. I've got at least a dozen items in my inventory that swear up and down they're no copy, no mod, and no transfer, but everything inside of them is fullperm and could be extracted when the objects are rezzed. I'm pretty sure that wasn't their makers' intent in setting the permissions on the obects, so yeah. Minor oversight, major flaw. Always check to make sure each thing you don't want messed with is set not to be messed with, or the illusion of security could get your hard work distributed freely by unethical persons.

This. Spot on. So often when going for realism we forget that RL rules do not apply to our reality in SL. I love it when people get that we're all artists working with illusions in here... The whole point of VR as an art form is not having to cast a piece of rubber and fit it to an axle and make it spin with a motor and all of that; if it looks good, it works. When I first realized how much animation in SL is literally animation like in cartoons, and can be done way easier using textures than actual "movement", it changed my whole approach to scripting. It's good to see other people thinking the same way. ^-^

The only potential problem I see is sending the message before listening for it. It would explain the chat command working while the llSay is ignored. So rather than llSayblahblahblah llListenblahblahblah I'd go llListenblahblahblah llSayblahblahblah. I mean theoretically, at least. I've never put the one before the other, so yeah...

One thing that helps me, and I'm not privy to your code so I can't say if it'd be an issue in this case at all (but I throw things out there anyway, just in case it helps), is to make sure the notecard really only has data in it that needs to be in a notecard, too. For a long time I had a script reading a lot of lines that it didn't need to, just because I put ALL of the configuration data in the config notecard, and not just the stuff a later user might want to be able to edit. It's important to make sure you're not "putting legs on a snake", as it were... Not necessarily in your case, but generally speaking, Rolig's second given method way up there makes a lot of sense to me, for a lot of reasons. Having a tiny little script read your notecard while the main script does its other things can be the difference between a moving object actually moving about while figuring out its other functions' configurations, or sitting there for a minute saying something like, "Loading config, please wait..." Sometimes you just don't want to have to wait. So, thanks for pointing out that obvious little thing, it helps me. And yeah, I agree, a tenth of a second per line is a long wait, and can really slow things down. I get the feeling the notecard reading function is something they sort of cobbled together and made work because there was a need for it, and then stopped bothering with it once it was "good enough"... Thank you, Rhiannon, for posting this topic, and for asking about this stuff; the more people ask, the more I get to read about it and learn! ^-^

Adding my own thanks for sharing, because it really helps other people later. That was thoughtful. Worst thing in the world is when someone says "Aha! I've solved it!" and then they leave without telling anyone what the solution was... Thanks for not being one of those people!

Holy moly. Please excuse the horrid pun, but that just floored me. LOL

I agree that better usage and actually learning how to use the Prefs would be superior. The same way learning all of the other ins and outs of whatever viewer is being used could save a lot of people buying utterly unnecessary things that add to CPU and script count or whatever, and a way better overall user experience. Then again, the majority of newer users also end up in places like Social Island... <-<; Some of them never go beyond learning basic things, or even explore the larger world... I've never understood why. It's like going to an amusement park and staying next to the ticket booth and just buying tickets all the time instead of going in and enjoying all the rides, because it might involve walking somewhere. On the subect of mirrors and water and reflections, yeah, it seems it's a camera trick. I've also seen really well-done reflective floors and other surfaces, though how to make it work myself is beyond me at the moment.

I've had this problem with even non-rigged objects. The only thing that fixed it was re-exporting the mesh and re-uploading it. One thing that might help is making sure to set the origin to somewhere within the object; not saying this was a mistake you made, but I've forgotten before and had the origin point several "meters" away from the obect I was working on. I'm not sure how much difference it makes, but I try to remember it anyway... Not sure if this will help you any, but if it does, hey. Good luck~! ^-^

I'm starting to see that maybe a really thorough grasp of the Wiki, though it's extensive, could save a whole lot of trial and error, writing of rubbish scripts, and assorted other poopydoo. Especially in areas such as built-in functions, and the setting of prim properties! I've gotten into the habit of keeping bookmarks for all of the most useful pages handy, such as the llSetClickAction page, etc. It's actually faster and easier sometimes than looking through folders full of code snippets (depending on which folder I'm in). It doesn't just save time, it helps me to learn more as I go and even make better choices sometimes, because every possible option is listed on the same page. I've always been an advocate of "Read The Wiki!", but now I'm definitely more like, "USE The Wiki!"

That's a really pretty script, thanks for sharing it! Moving the linkset is fast enough it's practically instantaneous. Good stuff. On a side note, having the same texture on both sides of the root prim, and if you've positioned it all so that the root prim seems not to move when it happens, I'm wondering if you can simply flip the entire thing on its Z axis, and achieve the same effect...? The button would appear the same, and the HUD would effectively vanish..., right?

LOL, I'm sorry it hasn't changed much, but OMG you said that so well I had to laugh! Good one!

When uploading animations or static poses, there's an option for a smooth(er) lead-in and -out, and using it seems to help with quelling some of the jerky movement, IMO. Not everyone necessarily sets those on upload, though. But from what I've seen, even a static, one-frame pose can play as a smooth short animation if it's got the ease-in and -out set. It sounds like you're talking about the sort of thing where, say, a piece of furniture has multiple anims and you want to switch how you're sitting (or whatever <-<;), though. I've seen some fairly smooth transitions in sits, but there does seem to be an awful lot of the "jumping up to sit down again" phenomena as well. So Iunno... I guess it depends on the animations, maybe. Most people I know just use their imagination and pretend around it, or ignore it.

My old Akeyo HUD and the MystiTool used to get me yelled at in places like that... >.<; I've since learned to easily do without them, but yeah, a lot of places do that in an attempt to reduce lag (of debatable value, as noted above). Some do the kicky-outy, some just spam you until you submit. Once you get into the habit of de-scripting things that don't need scripts in them, it stops. I know it's annoying, but if it's their sim, they're going to do whatever they think is best for them... I know it kept me from visiting a lot of places I might otherwise have enjoyed, though.

Oooooh, thank you! That looks even better! I really appreciate all of the help, you're awesome people!

This is good information to have; I've been in the habit of simply having my scripts blurp out and listen to chat commands, this looks way cleaner, saves running unnecessary listening events and all kinds of other bulldoodoo. To the OP, thanks for asking this, it made it possible for me to read the answers and learn something! And thanks to the others for answering!

Nice! Here's a little quandary I've been puzzling over, and it's related, so maybe there's something for it, as well. When detecting an agent, and having determined it is, in fact an avatar, is it possible (without a gigantic wall of scripty innards being added to a 16-line script) to tell if the avatar is the prim owner? This might solve something I've been puzzling over for a looooong time, namely how to avoid a collision event on rezzing a projectile, without having to place it a distance away from myself (which would defeat my purposes in this specific case (prim-based close-up melee combat with particle effects)). Just wondering, and thanks so much for the input, it's been incredibly helpful! EDIT: I solved my own dilemma, but I'll leave the question and post what worked for me, just in case it helps anyone else... if (llDetectedType(0) & AGENT & !OBJECT_OWNER) ^-^;

Ah, cool! Thanks! You rock!

OMG, I tried it hours ago but with two &&'s... I was using AGENT_BY_USERNAME, though... I'll try it the way you posted. Also, how would the llGetAgentSize work? If you know, just wondering is all... I like to know how things actually work when possible, so I know better what I'm doing with it all... Either way, thanks so much for the quick reply, and I'll check back just in case! EDIT: Issue Resolved. Thanks so much! I knew I could count on the Scripting Forum! ^-^ <3

Okay, I've scoured the wiki and searched the forums, and I'm finding pretty much nothing on how to differentiate between an avatar and an ordinary physical object colliding with something. If it can be done, I know at least three people (not naming any names, I don't need to) here will know how to do it. I can use the speed of the object to filter out avatars, because they only move so fast, but this is a dodgy workaround for my purposes. All I need is a way to prevent something happening if the collision is the result of an avatar bumping into my target object, but allow the event to occur if the target is hit by something other than an avatar. I've tried several things so far, but with no success; it either stops all collision events or allows them all. How (if possible) can I differentiate between whether the collision is with an avatar or just a moving object? I'm stumped! Is there any help for this?

Klytyna is making a really good point, IMO. Especially if you tend to (like I do sometimes) have more than one item (such as ranged and melee weapons) attached, and they both use the same commands (which I tend to script them to use out of habit)... Scripting each to use its own channel out of thousands and thousands makes it a lot easier to ensure there's no overlap between items. And gestures can say anything on any channel with a single keystroke, so hey. Thanks for bringing that up!

Are you saying you want to get a kemono skin texture to work on some non-kemono legs? If you have The UV map for the legs, you can try cutting and pasting the leg part of the body texture on a layer under the UV map for the legs, and fudge it into shape from there... I'm sure someone would be willing to do it for pay if it's worth their while, but I'd try seeing what you can do from there, first. I mean, if you're more interested in learning it yourself, of course. If you want to find someone who'll do it for you, about one in four people at Annie May Haven would probably either be able to do it for you or know someone who can and who needs the $L.

While I do agree that a touch trigger is best for a lot of things, looking at reviews for a classic switchblade knife on the MP was enough to tell me that sometimes it's just best to be able to tell something to do something in chat. Almost every review said the item was great but they had trouble clicking on the button, and why couldn't the script have a chat option... As for gestures, I like them because you can use them in mouselook. It's not just because you don't have to preface a chat command with a channel number, but because when you're in mouselook you can trigger your chat commands with hotkeys via the gestures. Also yeah, how you intend to make the object move or appear to move is worthy of consideration. Whole other can of worms, though.

What Rolig said is absolutely true, no matter how you script (and there's lots of ways to go about it) you'll find it really helps to save precious time if you can tell at a glance what a variable (for instance) actually represents in terms of its function, or at least include notes/comments as you go. You're definitely going to be looking at the innards of your scripts again someday, and being able to read what's there saves a LOT of otherwise wasted time. I also agree with getting into the habit of considering more than just the linear flow of what you're trying to get a script to do; anticipating as many possible outcomes or variants on what you're actually telling the script to do can give you a better sense of how to structure your scripts to avoid errors. LSL might all be in neat little rows visually down the text file, but those rows are full of wiggles, if you notice. Learning the basics of structure and syntax are certainly important from the beginning, and you can read about them and know them fairly quickly, but the best advice I can give on a shortcut to intuitively "getting" LSL is to get ahold of as many examples as you can find, pick some that seem interesting, and get your hands dirty. Make it fun and it'll get easier the more you do it.