Wulfie Reanimator

I guess you can think of it exactly like a door script for uncut prims like you said, the differences being that the "door" is more like a pole that can change its length and the hinge is at one end of the pole. But I'm having trouble following the script you posted, mainly in state_entry where you assign the offset for the first time.

I actually do that whenever I can, it's extremely useful for indirectly optimizing scripts. However, sometimes path cuts are not an option, for example when trying to rotate flexi prims at the base. (Flexi cannot be sliced from beginning/end.) This is actually one of the cases I'm dealing with.

The three rotations shown in the image are only examples. The rotation could be anything between 0-359 on each axis at once. I also understand that the object's position has to change in addition to its rotation, but the math of it goes way over my head.

They're usually called just "clicky" or "clickable" scripts.

Here's a little visual for what I'm about to ask (I lied, there's only going to be a single picture): 1: First rotation at <0,0,0> (euler) 2: Second rotation 3: Third rotation Black dot: Object center White dot: Center of rotation Grey circle: Projected location for object center given any angle around the X axis. Given a prim (box/cylinder) with an abitrary size with one axis being longer and able to change its length while the script is running, how do I set an object's rotation while keeping one end "anchored" in its place? (Rotating around an offset point.) There's an example on the SL Wiki, but it results in relative rotation. For example, running the same code twice would cause two rotations with the same angle size. What I want to do is set the rotation in global coordinates so that running the same code twice would cause one rotation and no change the second time. In short, I want to know/understand the math required for this. I can script, I just can't do the math. Additional notes for context: - The rotation can be around multiple axes at once. (<45,90,30> euler) - The center of rotation or "anchor point" is known. - The prim is part of a link set and worn as an attachment. - The length of the Z axis can be anything above 0.1 and max prim size.

You cannot have an event (timer) inside of a conditional (if) or another event (like state_entry). If you're trying to turn the timer on and off, you can either: 1. Use llSetTimerEvent(x) to turn the timer on (x is seconds between each time the timer event happens) and then llSetTimerEvent(0) to turn the timer off, or.. 2. Use an on/off variable and an "if" check inside of the timer event to check whether or not a scan should happen.

Aren't dialogs just predetermined messages shown via UI, and sent to a "hidden" channel by the viewer? I say "hidden" because the channel is actually communicated to the viewer and it can be snooped. (Not via scripts though.) If you receive a script dialog and you know the channel, you don't have to click the buttons. You can manually type the message. Although, in the end, this does not help you script something that would call a dialog from another script and detect what messages can be sent.

From what I understood, he wants the same particle to move between several points during its path before disappearing. If that is the case, it's not possible, but what you could do in that situation, is create a particle effect with the flag PSYS_PART_FOLLOW_SRC_MASK and then move the source object through a set of coordinates.

You're already doing a good job at formatting your code properly! I'm noticing that you use all-caps for "constant" variables, which aren't meant to be changed. If you're using the Firestorm viewer, you could enable the pre-processor (Gears icon above the code area > Enable LSL preprocessor) in order to not spend memory assigning global variables that only ever have one value. Basically, you'd do this instead: #define BIANCO <1.0, 1.0, 1.0>#define GRIGIO <0.667, 0.667, 0.667>#define BLU <0.0, 0.0, 0.851>#define OPAQUE 1.0integer gSwitch = TRUE; // Switch is on.default[...] This way, whenever you type BIANCO into your code, the pre-processor replaces it with the text <1.0, 1.0, 1.0>. You can read more about it here if you're interested, it has even more helpful uses, but that would be most fitting for you: http://wiki.phoenixviewer.com/fs_preprocessor P.S. This is completely optional and nothing you need to concern yourself with as a beginner.

The "autoplay media" and similar options don't affect Youtube's video autoplay setting because they are completely different, and handled by completely different systems. Having media autoplay in your viewer/script only means that the prim media (URL page) will be shown to the client automatically. Anything within the page will not be affected, like videos, unless the site autoplays them by default. To have the video autoplay (on Youtube). you'll need to add &autoplay=1 to the URL itself.

Yes, when you sit on an object, you become a part of its linkset and the script will return the object's bounding box instead of the avatar. But this is not the same as wearing attachments on your avatar. As with animations, your physical shape is not affected as your arms and legs move. This applies to wearing attachments as well -- they do not affect your physical shape. Thus, your bounding box is unaltered as far as scripts are concerned. This is why I chose to ignore the metadata view for bounding boxes while working with scripts. I guess right now my question would be, can I get the rotation of an avatar without running into problems with the avatar being in mouselook? This is very likely to happen in my case.

After a good night's sleep and looking at the function again, I think I figured out why the rotation was happening. Before setting the linkset's parameters, I get the targets pos/rot/BB and then add the rotation with the linkset's root. This works fine for as long as the target isn't an avatar and doesn't enter mouselook. I can show the code for more clarity if you're curious. That aside, I know about the metadata, but I chose to ignore it since it doesn't properly display an avatar's bounding box to begin with. If you turn, your bounding box doesn't turn, but instead changes in size. Bounding boxes according to scripts do not change sizes as the object rotates. The attachments you wear also affect the size of the bounding box in metadata view. Wearing nothing: http://puu.sh/kMiho/a527dabbb1.png Wearing an attachment: http://puu.sh/kMijc/20ea6791be.png Scripted bounding box: http://puu.sh/kMijM/3e3d61f4fd.png

I've made a function that gets a target's (avatar/object key) position, rotation, and bounding box. It then sizes a linkset of 6 prims around the target, trapping it. But when I tested it with an avatar, the bounding box rotates in mouselook, according to the camera. The avatar's hitbox (or physics shape) does not correspond to the bounding box, though. The avatar can be standing normally, enter mouselook, look straight up, and the bounding box will rotate 90 degrees. There is probably a workaround to this, such as resorting to llGetAgentSize, but what I want to ask is why does it happen? Is there any purpose to having the bounding box rotate in mouselook, or is it simply a really glaring bug?

The problem has been solved, and the fix has been added to the original post.

Bumping for the sake of having the issue fixed. Nothing suggested so far has improved the situation.

Yes, others do see me bugged aswell. In fact, they see it alot worse. Stretched limbs/neck and the smallest possible head you can make with a shape. (Everything set to 0.) I can't get you a picture of what they see, right now, but I might come back with one later on.

I used to have one alt, but I've stopped using it long ago. I've done clean installs a few times since the problem occurred. As for multiple versions of a viewer, I have none. I only have two different viewers, and one of them I use rarely. I think the last time I used the second viewer was a month back or so, so I doubt that would be the problem. And like I said before, I've done clean installs. That means completely uninstalling both of my viewers before installing one of them back.

I've no plans on doing this again. But I realized that it would be alot better to make a topic of this issue on the forums so I can actually reply to people aswell, and better help others help me, and rewriting the whole thing felt extremely pointless.

-

-