Connecting swings using particle rope to a multi-prim base

[Saylan Remblai]

Hi everyone,

I've been working on building a swing ride (as seen in many canivals/amusement parks) and while I can make the top spin and connect my swing seat to a single prim using particle rope, I've been unable to find a way to get the swing to remain suspended when linking the tether point of the rope to the top. Once I unlink them, the seat once again acts like a swing.

I need the top base to be the focal point of the link so the rotation works correctly, but having the tether as the focal point has been the only way, so far, that I've been able to get the swing to remain swinging. Obviously that only works for the one tether point as well, rather than all of them so that has still turned out to be a dud.

Is this kind of scripting just not possible or am I just missing something (very likely)?

The rope code I'm using is one found on this forum, modified slightly through experimentation:

 

integer lockon = FALSE;
float rope_length = 3.0; // Obviously, the length of the simulated rope. (It will stretch slightly longer than this, though)
float dampening = 0.04; // This dampens a fraction of the object's velocity every 0.1 seconds, if the rope is stretched.
float bouncing = 1.5; // How much the object "bounces" back after stretching the rope to the limit of its length.
float constant = 16.0; // The force constant of the rope.
key target;
vector ropecolor;
list rope_effect = [];

default
{
    state_entry()
    {
        llListen(12345,"","","TEST123");
        llSetTimerEvent(5.0);
    }

    timer()
    {
        if ( !lockon )
        {  
            llWhisper(12345,"TEST123");
        }
    }
    
    listen(integer chan, string name, key id, string msg)
    {
        if (!lockon)
        {
            lockon = TRUE;
            llWhisper(12345,"TEST123");
            llSetTimerEvent(0.0);
            target = id;
            llSensorRepeat("", target, SCRIPTED, 20.0, PI, 0.1);
            rope_effect =
            [
                PSYS_PART_FLAGS,            PSYS_PART_FOLLOW_SRC_MASK | PSYS_PART_FOLLOW_VELOCITY_MASK | PSYS_PART_TARGET_LINEAR_MASK | PSYS_PART_TARGET_POS_MASK,
                
                PSYS_SRC_PATTERN,           PSYS_SRC_PATTERN_DROP,
                PSYS_SRC_TARGET_KEY,        target,
                
                PSYS_PART_START_COLOR,      ropecolor,
                PSYS_PART_END_COLOR,        ropecolor,
                PSYS_PART_START_ALPHA,      1.0,
                PSYS_PART_END_ALPHA,        1.0,
                PSYS_PART_START_SCALE,      <0.05,1.0,1.0>,
                PSYS_PART_END_SCALE,        <0.05,1.0,1.0>,
                PSYS_SRC_TEXTURE,           "",
                
                PSYS_PART_MAX_AGE,          0.5,
                PSYS_SRC_BURST_RATE,        0.001,
                PSYS_SRC_BURST_PART_COUNT,  1
            ];
            
            llParticleSystem(rope_effect);
        }
    }
    
    sensor(integer num_detected)
    {
        vector i_pos = llGetPos();
        vector u_pos = llDetectedPos(0);
        
        if (llVecMag(u_pos-i_pos)>rope_length)
        {
            llSetForce(constant*llGetMass()*llVecNorm(u_pos-i_pos)*(llVecMag(u_pos-i_pos) - rope_length),FALSE);
            llApplyImpulse( llGetMass() * llGetVel() * dampening * -1.0 , FALSE );
            vector wrongway = llVecNorm(i_pos - u_pos);
            float wrongmag = ( llGetVel() - llDetectedVel(0) ) * wrongway;
            if ( wrongmag > 0.0 )
            {
                llApplyImpulse( llGetMass() * ( ( -1.0 - bouncing ) * ( wrongway * wrongmag ) ) , FALSE );
            }
        }
        else
        {
            llSetForce( ZERO_VECTOR, FALSE );
        }
    }
    
    no_sensor()
    {
        llSetForce( ZERO_VECTOR, FALSE );
    }
}

[Ohjiro Watanabe]

I think the main problem is your target for the particle system.

You should put your particle system in one prim and position it where you want the chain to start from.

Then you put another prim where you want the chain to end. Get the key for this prim using llGetKey

 

llSay(0, (string)llGetKey())

now put that key in as the target, like this but using the key from your prim, not mine.

PSYS_SRC_TARGET_KEY,       (key)"e168c444-1360-d5e6-3a13-82329f220bbc",

if you want a second chain on the other side just do the same thing.

get it workig first and then link it with your swing, make sure that the current root prim stays as the root prim when you link.

 

[Saylan Remblai]

Yes, that works for the purpose of one swing, but I need to be able to link to a base multiple swings. I was planning to have a tether point (where the particles start from) for each and link those to the base. If I do that, the only one that works is the one that is root, none of the others. If I don't link the tether prims to the base, they won't rotate with the base.

[Qie Niangao]

---

Saylan Remblai wrote:

Yes, that works for the purpose of one swing, but I need to be able to link to a base multiple swings. I was planning to have a tether point (where the particles start from) for each and link those to the base. If I do that,

the only one that works is the one that is root

, none of the others. If I don't link the tether prims to the base, they won't rotate with the base. 

---

[emphasis mine] When you say "works" do you mean the particles, or the intended rotating and swinging motion?

The particles are easy. You can do it all from a single script in the root prim, just by running through all the elements of the linkset and matching names or descriptions you set according to some convention, such that your script then knows which specific links to emit prims targeting (the keys of) which specific other links, all using llLinkParticleSystem.

If, instead, the real problem is getting all the swing seats to move as intended, that may be more complicated. We'd need to understand whether they're each single elements of the linkset (single prims, or single meshes), because otherwise it's an application for prim-animation.

[Saylan Remblai]

It would most definitely be the second one, unfortunately. The 'works' in this case is the swinging motion.

I'm not sure I understand the question though (I'm still rather new with scripting). I'm going to take a stab at what I think you're asking so apologies if I misunderstood. The swing being swung is a linked combination of 7 normal prims (no mesh or scultped anything). I have a single point on the swing dedicated to be the receiver of the particle rope which is the 'root' for the link set. On the sending end right now is just a sphere that ideally will be linked to a simple spinning cylinder.

 

[Qie Niangao]

Okay, and just to be sure: The ride will consist of multiple of these swings, all linked together and linked to the spinning cylinder so they all will spin together, right? And the seats will also move up and out from that center cylinder as the whole contraption spins up, correct?

Assuming that's the case, you're discovering a deep limitation of SL linksets: they're not hierarchical. There's just one root. Hence, when linked together, the seven prims that make up Seat 1 and the seven prims that make up Seat 2 are all just fourteen linked prims, and there's no longer any built-in way to address Seat 1's prims as a unit and move them around independently of Seat 2's prims. Instead, you have to keep track of that association in the script that moves them. (And in this case, seated passengers will also come and go and must move around together with their seats.) This business of orchestrating the simultaneous motion of different parts of a linkset is often called "prim animation."

That's all possible, it's just a lot of bookkeeping. In your case, you don't need to capture the "animation" by hand, but rather exercise some solid geometry to derive all the prims' local positions and rotations as they move relative to the spinning root prim. It's do-able.

Or... there may be a radically different approach, if the seats don't need to be linked to each other. This is a little trickier, and might not work at all, but the idea would be to use keyframed motion to move separate seat assemblies, all at the same time. This would be less bookkeeping, but I suspect it may be impossible to keep all the seats' motions synchronized, viewer-side. Perhaps somebody will come along with more extensive KFM experience (cough Dora cough) . But you may not like that approach anyway because, among other things, packing up and taking the ride would involve corralling all the separate pieces.

[Saylan Remblai]

I wasn't intending to link the swing seats to the base. I hadn't tested yet what that does to the code, but my interpretation of what I read (very possibly wrong interpretation) is that the swinging motion would no longer function if the tether point and the seat were linked.

The intention was to have the seats separate from the base in terms of linking, so each would be it's own group of 7 in that regard, I think?

Otherwise, your description of the overall build concept is right, yes.

I'm wondering, given the limitations that appear to exist, would it be easier to simulate the movement rather than using the particle rope code? What I'm thinking is that the actual movement of the swings in an actual world version of this ride is pretty static (compared to your standard standalone swing). The chains are almost always fully extended and taught. Would it be simpler or more challenging to utilize staight prims for the chains and code them to rotate out when the top spins and lower back to resting position when it stops? Or would that still be along the same lines of prim animation and thus a lot of challenges? Would it have similar issues due to the lack of hierarchy you outlined? I'm thinking it might but I wasn't sure.

[Qie Niangao]

It's really a question of whether it looks better with particles or with a prim to represent the rope. With enough attention to timing parameters, the particles might give a nice, realistic arc instead of a straight line. In fact, the script you're using might do that, but I haven't tried it to see if it would have that effect. (To be honest, I haven't really looked at the script yet.)

The point is, it's not going to be difficult to string particles where you want them, once you get the motion to be what you want. And because you are keeping the seats as separate linkset assemblies, that may not be so difficult. To keep things sensible, you'll want each seat assembly's root prim to be somewhere along the common axis of rotation for all the seats, then adjust the rotation of the assembly so the seats move upward as the thing spins faster. Right now I'm thinking that could be accomplished with different spin vectors of llTargetOmega() instead of any keyframed motion, but maybe somebody else will have a better idea.

[Saylan Remblai]

So not linking the seats to the main base is the right idea then.

The script is a little unstable since right now; it's pretty chaotic when things swing (I have flung a few seats across my sim....). I'm not sure it's even all that accurate in terms of the motion but it's definitely better than a solid prim would be.

I think I lost you a bit on the common axis of rotation for the root prim. Not sure I followed what you were describing. Here's a picture of the seat right now. The white orb is where I have the code for the rope loaded that the particles connect to from the tether prim. It's not the root prim though. That would be the seat cushion due to how I have the animation coded into it.

[Saylan Remblai]

Let me see if maybe a different idea is feasible. I'm not sure it is, so maybe someone can let me know.

Since the issue is that the code stops behaving like a swing when the prim to which the particles from the seat lead to (the tether) is linked to another, is it possible to have a large rotating single prim but indicate different spots on the surface for the particles to tether to, so no linking is necessary?

[Qie Niangao]

Yeah, sure, but I'm still puzzled about how you're getting all the swings to simultaneously move the way you want them to. If that's already cured, then it's trivial to have them send particles from some prim in their linkset out to some other prim that's not part of the linkset.

That's not exactly the same as "different spots on the surface" of a single prim; you can't really do that, exactly, because a particle target is always the origin of a prim (or of an avatar, the origin of which is notoriously near the crotch). So either all the seats could target a single prim, or they could separately each target one of several linked prims.

But is this really the problem? I mean, the swings are already all moving as you want, and it's really just a matter of getting the particles to go where they should? Because Ohjiro sketches how to make that work, in the first reply to this thread. We can certainly elaborate on that if necessary, but that part seems (much) easier than getting all the seats to move together as desired.

[Saylan Remblai]

Having them send particles to a prim not of their linkset is the issue I was having when I posted. The swings work fine when it is one swing linkset connecting via particles to a single prim. But since I need say 4 swings moving on the same rotation, when I link each of those single prims bases whose ropes each lead to an individual swing, three of the swings stop working because the link somehow breaks the code that makes the particle ropes fluid.

If the prims the ropes tie to aren't linked, each swing works fine on it's own. Unless I can get the particle ropes to stop breaking when linking the single prim bases together or unless I can make a large single prim and say have the particle ropes of each swing attach at say opposite ends of the base, I'm kind of at a stale mate.

[Qie Niangao]

I hate to leave you in the lurch here, so I'm posting again just to "bump" this thread in hopes somebody else will see it and be better able to help.

Before giving up, I started hacking together a sample of how I'd approach what I understood to be the problem -- and then realized that I completely don't understand what you're trying to build. I was thinking that these seats just spun around appearing directly attached to a spinning (llTargetOmega) central shaft, the faster it goes, the higher they should spin... but now, having looked at the script (which incidentally I couldn't get to work except the particle system), I suspect they're actually supposed to swing back and forth or something -- and using physical motion, no less. So this is some kind of amusement ride with which I'm not familiar (which isn't that surprising).

Hopefully somebody else will have a clue.