Wulfie Reanimator
-
Posts
5,725 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Wulfie Reanimator
-
-
Here's my take on the "multiple timers" problem.
All you really need is two variables, I think using linked messages is unnecessarily complex -- and resource heavy, just like sensors.float timer1_start = 5; float timer1_duration = 5; float timer2_start = 10; float timer2_duration = 3; default { state_entry() { llSetTimerEvent(0.1); } timer() { llSetText((string)llGetTime(), <1,1,1>, 1); if(llGetTime() >= (timer1_start + timer1_duration)) // first ends in 10s { llOwnerSay("timer 1 ended!"); timer1_start = llGetTime(); // restart timer immediately, ends in 5s } if(llGetTime() >= (timer2_start + timer2_duration)) // first ends in 13s { llOwnerSay("timer 2 ended!"); timer2_start = llGetTime(); // restart timer immediately, ends in 3s } } }If you copypaste the script into a box, you'll see the script's internal timer as hovertext, and the chat output will be something like this:
[00:00:10] Obj: timer 1 ended!
[00:00:13] Obj: timer 2 ended!
[00:00:15] Obj: timer 1 ended!
[00:00:16] Obj: timer 2 ended!
[00:00:19] Obj: timer 2 ended!
[00:00:20] Obj: timer 1 ended!
[00:00:22] Obj: timer 2 ended!
[00:00:25] Obj: timer 1 ended!
[00:00:25] Obj: timer 2 ended!
[00:00:28] Obj: timer 2 ended!
[00:00:30] Obj: timer 1 ended! -
What you're talking about can't be done with just a script. You would have to create a large set of animations for the head to appear to be tracking the object, and scripts cannot turn an avatar directly.
-
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.
-
1
-
1
-
-
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_preprocessorP.S. This is completely optional and nothing you need to concern yourself with as a beginner.
-
1
-
-
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?
-
-
in Your Avatar
The problem has been solved, and the fix has been added to the original post.
-
-
in Your Avatar
Bumping for the sake of having the issue fixed. Nothing suggested so far has improved the situation.
-
-
in Your Avatar
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.
-
-
in Your Avatar
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.
-
-
in Your Avatar
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.
-
-
in Your Avatar
-
-
Facebook
Instagram
Twitter
YouTube
Flickr
Position HUD attachment over something in-world?
in LSL Scripting
Posted · Edited by Wulfie Reanimator
typos
I have a HUD that's only two default prims linked together (and attached to Center), the root is placed at <0,0,0>.
In-world, I have a target that I'm tracking. I want the child prim to be placed exactly over the target as I see it on my screen, but I'm struggling with it. Here's what I have so far:
key target = "ec85be1f-21b6-d989-6412-db165e53d5e7"; vector target_pos; default { state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_TRACK_CAMERA); } run_time_permissions(integer perm) { if(perm) { target_pos = llList2Vector( llGetObjectDetails(target, [OBJECT_POS]), 0); llSetTimerEvent(0.1); } } timer() { rotation camera_rot = llRotBetween( llRot2Fwd(llGetCameraRot()), target_pos - llGetCameraPos()); vector hud_pos = <1,0,0> * camera_rot; llSetLinkPrimitiveParamsFast(2, [PRIM_POSITION, hud_pos]); } }Sadly, this doesn't work. The placement isn't very accurate at any point, and if you turn your camera to face towards anything but the positive global X axis, the HUD's child prim either barely moves (while perpendicular), or moves in the reverse direction on the attachment's Z axis (while facing towards the negative global X axis).
Here is an image while perpendicular: http://puu.sh/wIwLU/94651c9ffd.png
And opposite: http://puu.sh/wIwKj/1d393a073b.png
And facing towards positive X: http://puu.sh/wIwN5/1b7e639472.png
The purple square is the HUD's root, at <0,0,0>
The yellow sphere is the HUD's child.