Mabarial

The animations in the AO are of the same priority as the animation in the script, if not less. I uploaded the animation myself so I know it's priority 4. The item this is going in is going to be mass-used, so requesting customers to turn their AO off isn't really an option. If I have to go with my current workaround, I will, but it's not preferable.

I've found a workaround by removing the animation() function and instead changing my timer to: timer() { if (count == 3) { llOwnerSay("3"); llStartAnimation(anim); } x+=step; bobthrust = <0,0,llCos(x)*d+1>; llMoveToTarget(pos+bobthrust,0.8); ++count; } That causes the animation to start at 1.5 seconds into the timer, just after it passes where all the animation problems were occuring. However, it doesn't look as good as it would if the animation were playing the whole time. Is there a better workaround for this? I've even tried using llStopAnimation(llGetAnimationOverride("Falling Down")) but to no avail.

Hoy hoy! I'm having an issue with some AOs where after being moved by an attached physical object using llMoveToTarget(), the AO's animation keeps playing over my own. Code here: // Variables for the timer (bobbing motion.) // float d=0.25; float step = 0.8; vector pos; float x=0; vector bobthrust; // Variables for other calls // integer count; string anim; // Functions // animation() { llStopAnimation("sit_generic"); llStopAnimation("sit"); llStopAnimation("walk"); llStopAnimation("stride"); llStopAnimation("falldown"); llStartAnimation(anim); } default { touch_start(integer num_detected) { llRequestPermissions(llGetOwner(), PERMISSION_ATTACH); } attach(key avatar) { if (avatar) { anim = llGetInventoryName(INVENTORY_ANIMATION, 0); llRequestPermissions(avatar, PERMISSION_TRIGGER_ANIMATION); llSay(0, "Attached"); pos=llGetPos(); llSetStatus(STATUS_PHYSICS, TRUE); } else { llSay(0, "Detached"); } } run_time_permissions(integer perm) { if (perm & PERMISSION_ATTACH) { llAttachToAvatarTemp(ATTACH_LHAND); } if (perm & PERMISSION_TRIGGER_ANIMATION) { llSetTimerEvent(0.5); } } timer() { x+=step; bobthrust = <0,0,llCos(x)*d+1>; llMoveToTarget(pos+bobthrust,0.8); animation(); } }Pop this script and any animation into the contents of it, then click the prim, accept the attachment. While wearing an AO, the animation starts, then you start bobbing up and down, and then animation cancels and gets replaced by your default AO animations for falling. This only happens while wearing an AO. Here's a video of what's happening: The cube on the left just tells me the name of the animation playing. But you can see, the moment I disable my AO, the correct animation resumes playing. It doesn't happen for all AOs, and so I assumed this was an issue with AO makers using priority 4 animations. So I went and even made my own priority 4 animation for my item. Spent an entire day learning how and then making it perfect. But it still gets cancelled. Even when recalling llStartAnimation() in a loop, the animation doesn't resume. But oddly, the animation doesn't fail if the cube doesn't move. I'm a bit stumped on how to continue, and this is one of the last things holding me back from finishing my item. Does anyone know what's going on here?

Found an interesting workaround after reading a comment by Innula Zenovka from a thread in 2013. According to Innula, there's a known bug for minor movement updates to not be updated visually in attachments. I'm guessing that the transparency somehow exacerbates this issue, so I went through some testing, and sure enough: Transparent objects passing through one another have to be moved a certain distance for the engine to properly register an update to the attachment. A distance of 11.9m is too minor, and > 11.9m but < 12m is rather iffy. I did have a few times where distance > 12m but < 20m failed, but generally 12m and up was reliable. That's a rather large distance to still be considered "minor", though.

revochen Mayne wrote: Now the solution which might helps you: Try to either rotate or scale the prim when applying the texture on it. The prim being failed to update visually can happen with no textures on it, with just the prim alphas set to something above 0 but below 100%. But I went ahead and tried making a call to rotate after each movement of the prim, and found something interesting: Setting PRIM_ROTATION causes it to visually fail to update 100% of the time. Even if I set a ridiculously long llSleep() function after the rotation is called (separately from the movement), it will fail to update every time. But here's the kicker: You can still see it rotate. You can visually see the object rotate, but the position on the X axis does not change visually. So this bug is even weirder than I first thought. revochen Mayne wrote: And another workaround for this bug: Put a solid prim with a blank texture on it between the conflicting transparent textures. Just show this solid prim for a very short moment after applying the button textures and hide it again then. Toyed around with this, too, and it does work, but only if you put in an llSleep() function > 0.25 seconds in between making the blank solid prim visible and invisible again. That's a really long time for that prim to be visible in most use-cases. Thanks for both of the suggestions!

I sent it along, hope you have fun with it! I've tried using other calls like llSetPos() and llSetLinkParams(), but the same result. I have an easy way around it by just not making my buttons transparent, but I always thought it was nice to try to solve things for other people who come along, so I'll be keeping at the puzzle, too.

Hey Rolig! Thanks for the reply. No difference when using that script. I can send you a test object in-world if you'd like to play around with it.

Hoy folks! I encountered a rather odd bug when making my first HUD. Basically, any time a partially transparent prim passes through another partially transparent prim, the HUD has issues visually updating the change. This works the same with both SL transparency and texture transparency (masking). Here's a video demonstrating the problem: The two HUDs you see are the same object. The one on the left has no textures, the one on the right has a single transparent texture. The red cubes are transparent themselves, using SL's built-in prim transparency. They are being moved through the transparent background object using the following script: integer gmakeVisible; default { on_rez(integer start_param) { gmakeVisible = 0; } touch_start(integer total_number) { if (gmakeVisible == 0) { llSetLinkPrimitiveParamsFast(3,[PRIM_POS_LOCAL,<-0.327080,0.150024,-0.103272>]); llSetLinkPrimitiveParamsFast(4,[PRIM_POS_LOCAL,<-0.327080,0.050018,-0.103272>]); llSetLinkPrimitiveParamsFast(5,[PRIM_POS_LOCAL,<-0.327080,-0.049988,-0.103272>]); llSetLinkPrimitiveParamsFast(6,[PRIM_POS_LOCAL,<-0.327080,-0.149963,-0.103272>]); gmakeVisible = 1; } else { llSetLinkPrimitiveParamsFast(3,[PRIM_POS_LOCAL,<-0.127080,0.150024,-0.103272>]); llSetLinkPrimitiveParamsFast(4,[PRIM_POS_LOCAL,<-0.127080,0.050018,-0.103272>]); llSetLinkPrimitiveParamsFast(5,[PRIM_POS_LOCAL,<-0.127080,-0.049988,-0.103272>]); llSetLinkPrimitiveParamsFast(6,[PRIM_POS_LOCAL,<-0.127080,-0.149963,-0.103272>]); gmakeVisible = 0; } } }You can see later on in the video that right clicking the prim instantly updates it, making the visually bugged red cubes appear at the correct position each time. This visual error only happens with HUD-attached prims, it doesn't occur when it's actually rezzed in-world. Just something I thought was odd. Have any of you ever encountered this before? If so, what was your solution? I luckily have an easy workaround, which is just to make my cubes opaque, but I imagine there's others out there who aren't so lucky.

Gaia: I've never even launched the debug menu before, but did just now to be sure - both of my RenderAvatarLODs are the same. I've uploaded the photos I took: (censored nudity warning: http://imgur.com/a/kNIZC#0 ) I know it looks like the camera is rotated between the two images, but if you pay attention to the hands you can tell they are from the same angle. I've tripled checked and do still have on identical body shapes, sliders, and mesh avatars in both images.

So I've been working on fitting a karada (rope dress) to a popular mesh avatar, and while the model fit perfectly in Blender, every time I uploaded to Aditi (beta) I'd have some issue fitting round the neck and shoulders. I tweaked and I tweaked, and finally I got it to look right on Aditi, but then when I uploaded (from the same file) to Agni, the live server, the shoulders and neck were off in the opposite direction. I double checked and made sure it wasn't my shape, using the same shape on both servers. I double-checked all my morph sliders. I reuploaded the file again just to be sure. Finally I pulled out the camera on both servers, used the camera controls to swing the camera around to the front to make sure there was no difference in view, and sure enough - The shoulders on Agni were higher! Not just that, but they were closer together as well, and the chest was more forward, and legs slightly longer and further apart. This was all using the same mesh body, in the same body shape, from the same camera view. I figured they were testing out a new skeleton system so I googled, but I couldn't find anything definitive on it: Are the bones different on Aditi than on live?