Jump to content

Particle Emission At a Fixed Location, Not Following Object!?


Maxbullet52
 Share

You are about to reply to a thread that has been inactive for 1842 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Greetings,

      I have a project in which a Particle is to be emitted showing a bounding box.

Desire to have particles emitted from an attached object and give a "range" for the player to set forth upon.

Can easily determine the start point as the players getPos but when I begin to emit the particles, they move with the player.

Want them to not leave the origin of emission.

Would like to know if this is possible.

Thank you all the brilliant minds out there that have answered so many of my questions here on these forums ❤️

Link to comment
Share on other sites

I thought about this, making the particles very slowly move to the 10m meter mark (for example) but then the player does not have an immediate circumference to move within.

They would have to wait for them to reach their endpoint which might take a while. Perhaps using PSYS_SRC_PATTERN might not be the right choice I'm just not sure...

Without rezzing another object on the sim... this is what I would love to know if this is even possible at present. 

Link to comment
Share on other sites

Maybe I'm missing the point of your question, but it sounds like it has two parts:

1.  Make the particles not follow the source.  You do that by not using PSYS_PART_FOLLOW_SRC_MASK and setting both PSYS_SRC_BURST_SPEED_MIN and PSYS_SRC_BURST_SPEED_MAX to zero.  That will create a static particle that just sits there.  [EDIT: and only create one particle in the burst.]

2. Make the particle persist longer than a brief instant.  You do that by setting PSYS_PART_MAX_AGE to some large value (like 30 seconds).

Edited by Rolig Loon
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Perhaps it is in multiple parts but all I really desire is:

         a ring of particles from the players start position to continue emitting the exact 10m, until the move within the particles range which is fixed is completed.

 

So instead of Emitting a large ring of pulsing particles that will visualize the boundary of 10 meters around the avatar.

What you are suggesting is that I instead emit a single particle 10m large that shows the boundary and give it a long life.

My issue then is what if I move a few feet and then need for the boundary to turn off?

I will have to wait the length of time the particles are rezzed (30 seconds or so) and not be able to remove them instantly.

 

the issue im having is the particles are emitted from an attached object and seem to follow the avatar. Is it possible to have them only rez where they begin rezzing.

Edited by Maxbullet52
Link to comment
Share on other sites

Ah, so now you added a new part to the puzzle.  In that case, you can't solve the problem that way at all.  After all, you cannot kill a particle that has already been emitted. You have to wait for it to die by itself.  Therefore, the only way to make the particle effect persist until you want it to die is to keep emitting new particles with a short lifetime until you decide to stop emitting them.  But you can't do that if the emitter isn't there any more.

Therefore, your only solution is to rez the emitter and leave it behind when you move away.  Script your emitter to listen for a kill signal (in chat maybe, or from a HUD button ...) and then llDie.  Make your emitter small, transparent, and phantom so that it doesn't attract attention if someone is using CTRL+Alt + T and so that nobody will get hurt bumping into it.  Oh, and make it self-destruct in, say, 5 minutes if it hasn't already heard your kill signal.  (Always clean up your garbage.)

That solution, of course, assumes that you have permission to rez objects. 

 

Edited by Rolig Loon
Link to comment
Share on other sites

That is the issue, not everyone has that right. Is there a way then to have an object "attached" that can remain in a position "move itself from the player" or anything that could be used as a work around this? I could just a easily rez an object with the boundaries i desire but im attempting to find a non-rez solution to this.

I guess i thought particles was my solve. There is no way to offset particles emissions from the object to a vector or anything like that?

Edited by Maxbullet52
Link to comment
Share on other sites

5 minutes ago, Maxbullet52 said:

There is no way to offset particles emissions from the object to a vector or anything like that?

No, afraid not.  The scripted prim is the emitter.  You're asking something like, "May I fire a gun and have the bullet come out of a barrel somewhere else instead?"  The universe doesn;t work that way, even in SL. At least not when you rule out rezzing bullets out of thin air. 

  • Haha 1
Link to comment
Share on other sites

Now... if you move a few meters away but stay there....... you could attach the emitter to yourself. You would have to do some very tricky scripting to keep the attachment in the same spot in region coordinates while it moves relative to your position.  You would need to stay within maximum link distance, and the calculation would be really tricky.

  • Like 1
Link to comment
Share on other sites

Yeah I'm so not going there lol, what I will do is calculate the 10m from the pos of the player and then maybe send shorter and shorter ranged pings from the players' attachment  of particles to the edge of where they could move. That is far less work and easily updated with the getpos of the player versus the starting pos, rounding the float to a whole and changing the PSYS_PART_MAX_AGE.

Link to comment
Share on other sites

On 3/13/2019 at 4:50 AM, steph Arnott said:

On a caution note, excessive particle emitters can be lag inducers. They are constantly updating the clients viewers.

Not typically. I mean, particles can certainly lag viewers as a function of the rendering complexity (texture size, alpha sorting, and especially particle volume) but unless there are repeated calls to change the particle system, no object updates are generated.

On 3/12/2019 at 8:29 PM, Rolig Loon said:

Now... if you move a few meters away but stay there....... you could attach the emitter to yourself. You would have to do some very tricky scripting to keep the attachment in the same spot in region coordinates while it moves relative to your position.  You would need to stay within maximum link distance, and the calculation would be really tricky.

So this seems like something that might be useful sometime, so I wanted to see how close I could get with minimal effort (using texture animation instead of particles out of sheer cussedness, and triggered by touch instead of... well, whatever was intended) :

vector savePos = ZERO_VECTOR;
rotation saveRot;
key owner;

default
{
    state_entry()
    {
        if (2 != llGetNumberOfPrims())
        {
            llSay(DEBUG_CHANNEL, "Nope. This needs two prims linked together.");
            return;
        }
        owner = llGetOwner();
        llSetLinkPrimitiveParams(2,
            [ PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT,<0,1,0>, 0.0, ZERO_VECTOR, <1,1,0> ,ZERO_VECTOR
            , PRIM_TEXTURE, ALL_SIDES, "1c4f7017-46dd-d77a-3811-96346f95c483", <1,1,0>, <0,0,0>, 0.0
            , PRIM_ROT_LOCAL, ZERO_ROTATION
            , PRIM_SIZE, <20, 20, 0.01>
            ]);
        llSetLinkTextureAnim(2, FALSE, ALL_SIDES, 0, 0, 0.0, 0.0, 0.0);
        if (llGetAttached())
        {
            if (PRIM_PHYSICS_SHAPE_NONE == llList2Integer(llGetLinkPrimitiveParams(2, [PRIM_PHYSICS_SHAPE_TYPE]), 0))
                return;
            llOwnerSay("You probably want to set the big disk to Physics Type: None");
        }
        else
            llSetLinkPrimitiveParamsFast(2, [ PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE ]);
    }
    changed(integer change)
    {
        if (CHANGED_OWNER & change)
            owner = llGetOwner();
        if (CHANGED_LINK & change)
            llResetScript();
    }
    touch_end(integer num_detected)
    {
        if (savePos == ZERO_VECTOR)
        {
            if (ATTACH_AVATAR_CENTER != llGetAttached())
            {
                llSay(DEBUG_CHANNEL, "Nope. This needs to be attached to Avatar Center.");
                return;
            }
            savePos = llGetPos();
            saveRot = llList2Rot(llGetObjectDetails(owner,[OBJECT_ROT]), 0);
            llSetLinkTextureAnim(2, ANIM_ON | PING_PONG | SCALE | SMOOTH| LOOP, ALL_SIDES, 1, 1, 0.75, 0.25, 0.25);
            llSetLocalRot(ZERO_ROTATION);
            llSetTimerEvent(0.1);
        }
        else
        {
            savePos = ZERO_VECTOR;
            llSetTimerEvent(0.0);
            llSetLinkPrimitiveParamsFast(2, [ PRIM_POS_LOCAL, ZERO_VECTOR ]);
            llSetLinkTextureAnim(2, FALSE, ALL_SIDES, 0, 0, 0.0, 0.0, 0.0);
        }
    }
    timer()
    {
        rotation newRot = llList2Rot(llGetObjectDetails(owner,[OBJECT_ROT]), 0);
        llSetLinkPrimitiveParamsFast(2, 
            [ PRIM_POS_LOCAL, (savePos - llGetPos())/saveRot
            , PRIM_LINK_TARGET, 1
            , PRIM_ROTATION, saveRot/newRot
            ]);
    }
}

Now this has all sorts of limitations, some simple (e.g., should be using world coordinates to behave while crossing region borders) and some that have me stumped. Notably, even though attached to avatar center, some animation glitches seem to inject rotations on the attachment that are not reflected in the avatar's own rotation. These are fairly small when just turning back and forth, but when walking backwards all hell breaks loose -- and I can't remember a way to detect when the avatar is walking backwards, short of taking controls and watching for CONTROL_BACK which seems crazy. Not sure if all this is a manifestation of the wiki caveat that "OBJECT_ROT will return an accurate facing for Avatars seated or in mouselook, but only a rough direction otherwise.)

It's undoubtedly too glitchy for this application, but I'm sort of interested in whether it might be improved.

Link to comment
Share on other sites

This is definitely cool, Qie.  It's what was vaguely in my mind but only as a fledgling concept. I'm going to log in today and see it in action. I'm not surprised by hearing that it goes wonky when you walk backwards.  In fact, I would expect it to do odd things if you move at all, which its why I emphasized staying put. Even a small avatar rotation will be telegraphed into wild swings in the position of a tethered object several meters away.  I really don't know how to beat that.

  • Thanks 1
Link to comment
Share on other sites

3 hours ago, Qie Niangao said:

Not sure if all this is a manifestation of the wiki caveat that "OBJECT_ROT will return an accurate facing for Avatars seated or in mouselook, but only a rough direction otherwise.)"

It is. (And it's not affected by animations.) Any script that relies on a free-standing avatar's rotation will be inevitably inaccurate in very noticeable ways. The only option would be to use a large area like you did, to estimate the general direction instead of being an accurate spot.

 

4 hours ago, Qie Niangao said:

but when walking backwards all hell breaks loose

This is caused by animations though. If you have "Turn around when walking backwards" disabled and start moonwalking, the attachment will position itself just like it would if you were walking forward. Relative positions and all that. But if you have this setting enabled (or move sideways with Shift+A/D), avatars have a procedural animation that turns them toward their horizontal velocity. The avatar's actual rotation doesn't change.

  • Thanks 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1842 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...