The Backstory
I am a software engineer IRL so I seem to target most creation problems from a scripting POV. My first creation was a back halo that scripts some rotation; works well. To give it some more depth, I wanted to make the smaller inside disks float backwards and forwards through the bigger outside disks. I'm relatively new getting back into SL after many many years and I've researched the heck out of this problem and prototyped a lot as well but still to no avail.
The Goal
The goal is to have a set of linked attachments sliding forwards and backwards out of sync.
The Attempt Log
Attempt #1: llSetPos on a loop Explanation: The idea is simple, we figure out how much movement along a given axis we'd need to get from A to B in the desired time. We would then use llSetPos to do the moving inside a loop. Problem: Super visibly clunky. The prim would obviously jolt-hop along each axis no matter how many steps I made it travel to smoothen it out. TL;DR: Transition is not smooth; too clunky.
Attempt #2: Import an animation from Blender Explanation: To help figure this out, I started to analyze objects that did what I wanted, and what I noticed was that they all had an animation attachment and a script to probably kick-start it. That makes sense, no way all those complex animations happened through scripting alone. Problem: When I went to export the animation, it exported as an FBX extension which you all probably predicted ahead of time would be useless because SL only allows the import of BVH & Anim extensions. TL;DR: Can't import .fbx files.
Attempt #3: Format the extension Explanation: My next train of thought was to see if I could just cram it into a different file type or converter and watch what happens. Problem: Obviously this didn't work, I also went as far as to import an open source second life animation export extension from github and no surprise it threw an error when I tried to export my fbx animation as that. TL;DR: Don't try to push the cube in the circle hole.
Attempt #4: llSetKeyframedMotion Explanation: I stumbled across some amazing performance from the llSetKeyframedMotion scripting function. After running my tests on a rezzed prim, it seemed perfectly smooth; much smoother than llSetPos. Problem: It was wishful thinking, because although I read on the documentation page for llSetKeyframedMotion that it wouldn't work for attachments, I just wanted to rule it out. Low and behold, when I equipped the item, the animation didn't function. TL;DR: Not compatible with attached items.
Attempt #5: llSetLinkPrimitiveParamsFast Explanation: I came across a forum post that sort of addressed this by setting the primitive params in a while loop. This kinda goes against my philosophy because I'm pretty sure this function is only supposed to be used on initialization, not as a hack to mimic llSetPos. After attaching it to my regular back piece, I was surprised to see it function so fluidly: I had finally achieved a lateral floating effect. Problem: The problem came once I tried to apply the effect to more than one link in the group of linked prims on the back piece. After going to a scripting island, I bought a book that contained all the tutorials, and after some skimming I managed to find some scripting that worked on linked nodes and quickly realized how this could help performance by requiring only one script. TL;DR: Misusing code. Mysterious malfunction across linked family members.
I could theoretically set a single script on my back piece that references each prim in the collection of links, and asks them to move forward and back.
The Root Node
In practice this gave me more hell than I wanted. By attaching the script to the root node and calling the script like this:
llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);
The entire set of prims moved forward and back. But if I was to say link 2 instead of LINK_THIS, then the second link wouldn't move at all (which seems weird but might have to do with the whole initialization misuse thing I was talking about earlier).
A Child Node
Next plan of attack was to try and attach the script to a linked child node. This actually worked great because when I set it to the 2nd link, and updated the script to talk to link 2, it became isolated and the second link hovered. However, when I then set a second reference of the line (and even experimented with just one line to get the same result) to the LINK_THIS (the root node), the entire script ignored the llSleep that enforced the delay, and sped off into the horizon. Removing the "Fast" from the function call let me watch helplessly as it just block-hopped away lol. This seemed dumb to me and I still don't know why neither link could house a script that spoke to another link (so any answers on that would be helpful)
Separate Nodes
At this point I was going completely against what I set out to do - which was having one script to rule them all. I added a script to each individual link and made it refer to each individual link. Now the problem was that there's a performance dip although both links do their own individual movement. The performance drop was far too much to be considered acceptable.
I found this frustrating and called my friend into a sandbox to demonstrate the bizarre phenomenon. However once they came in, the script didn't work at all. I tried relogging, I tried resetting the script, I tried changing sandboxes, nothing seemed to make it run although it was running fine on my current back piece. After looking it up, there were a few forum posts about sketchy halting performances relating to this function.
Because of all this, I had to abandon the use of llSetLinkPrimitiveParamsFast to move on.
Attempt #6: "Nah I don't buy it, it has to be an animation thing" Explanation: So my friend showed me their back halo(linked here) and I was flabbergasted at how beautiful and elegantly it did what I intended to do, but not only what I intended to do, but it was resizing and gently transitioning all over the place like I had dreamed of. I asked them immediately to tell me what they saw in the content section of the item. It revealed 2 scripts (anim script and texture script by creator definition) and 5 animations. At this point I convinced completely that it had to be an animation thing. Problem: I'm stuck in my head about what second life wants and what I can do to get around it. Second life clearly allows animations, but what it considers an animation is specifically motion capture data. This really really confuses my way of thinking and so I was convinced that my best bet was to reach out to a forum and get help from the great minds lingering around online. TL;DR: Please for the love of god I'm loosing my marbles.
So yeah, I guess at this point you get how it's all going. If I can't get detailed help from anyone here, are there any in-game seminars I can attend to learn all this information because it's completely halting my creative process.
Thank you,
Marty ❤️