Anti-push with LSL?

[MelodicRain]

Is there anything you can achieve with LSL that you can't do with Firestorm's native "move-lock" function? The only thing I don't like about FS's native function is you still move, but you simply walk back to original spot afterwards. I would prefer it if you stayed completely stationary. Not looking for scripts that require you to rez something cause that would completely defeat the purpose. I did a quick search and it seems SL no longer allows anti-push since it can be used for griefing or something? There are some listings in marketplace, but I have a strong feel most of them don't work at all.

Edited September 26, 2020 by MelodicRain

[Mollymews]

to remain perfectly still (not able to be bumped away) then we can right-click on our avatar and menu: Sit Down. Then play a standing animation on our avatar

[animats]

I've seen anti-push HUDs. They seem to be rare today. Search Marketplace for "Movelock HUD" if you want to try one. There are ancient freebies. I think they're turning physics off for the avatar until the user requests movement.

The first avatar other than mine to try one of my escalators was wearing one. It took a while to figure out whey they weren't moving. Those work by friction, so if you turn physics off, you go nowhere. That kind of HUD should also break most SL elevators, and little stuff like those things that move incoming avatars off landing points.

Edited September 26, 2020 by animats

[Mollymews]

1 hour ago, animats said:

"Movelock HUD" if you want to try one. There are ancient freebies. I think they're turning physics off for the avatar until the user requests movement..

the history of movelocks is pretty interesting

back in the day Phoenix viewer exploited a hole which allowed a viewer to set an avatar to phantom. Linden closed that hole

then there was the hole in llSetStatus(STATUS_PHANTOM, TRUE) which would also be applied to an avatar sitting on it.  Linden closed that hole also

(edit add: this was a hole as on a damage-enabled parcel, a person could sit on the box and be invulnerable, as being phantom then no collision damage could be inflicted on them)

old school movelocks generally use llMoveToTarget() slaving to the current (llGetPos()) position of the avatar when it stops moving. Disable when a movement control key is pressed. Enable when no movement key is pressed

some movelocks also play a standing or hovering animation when the avatar stops moving, which is offset from its actual position. Which gives the illusion that the avatar is phantom when we bump in it.  This technique was quite prevalent in the long gone days of non-roleplay weapons.  Avatar tracking followers and bullets would go to the actual position not to the animated position

once upon a time llMoveToTarget() was quite weak when compared to the force that could be applied with llPushObject(),  llApplyImpulse() and llSetForce().  Then Linden closed that hole as well.  llMoveToTarget() is the strongest force of them all now.  In a straight contest between all the methods then llMoveToTarget() will eventually prevail within the 64 meter limit of llMoveToTarget()

note that llMoveToTarget can still be defeated by inserting rezzed objects (deflectors/blockers/pushers) between the avatar and its move to target. And is still possible using blocking pushers to push an avatar beyond the llMoveToTarget limit. At which distance llMoveToTarget() will stop functioning     

Edited September 26, 2020 by Mollymews
old school

[Lucia Nightfire]

2 hours ago, Mollymews said:

the history of movelocks is pretty interesting

back in the day Phoenix viewer exploited a hole which allowed a viewer to set an avatar to phantom. Linden closed that hole

then there was the hole in llSetStatus(STATUS_PHANTOM, TRUE) which would also be applied to an avatar sitting on it.  Linden closed that hole also

(edit add: this was a hole as on a damage-enabled parcel, a person could sit on the box and be invulnerable, as being phantom then no collision damage could be inflicted on them)

old school movelocks generally use llMoveToTarget() slaving to the current (llGetPos()) position of the avatar when it stops moving. Disable when a movement control key is pressed. Enable when no movement key is pressed

some movelocks also play a standing or hovering animation when the avatar stops moving, which is offset from its actual position. Which gives the illusion that the avatar is phantom when we bump in it.  This technique was quite prevalent in the long gone days of non-roleplay weapons.  Avatar tracking followers and bullets would go to the actual position not to the animated position

once upon a time llMoveToTarget() was quite weak when compared to the force that could be applied with llPushObject(),  llApplyImpulse() and llSetForce().  Then Linden closed that hole as well.  llMoveToTarget() is the strongest force of them all now.  In a straight contest between all the methods then llMoveToTarget() will eventually prevail within the 64 meter limit of llMoveToTarget()

note that llMoveToTarget can still be defeated by inserting rezzed objects (deflectors/blockers/pushers) between the avatar and its move to target. And is still possible using blocking pushers to push an avatar beyond the llMoveToTarget limit. At which distance llMoveToTarget() will stop functioning     

Phoenix client phantom mode did not send avatar position updates to your viewer and other viewers and did not send camera updates to your viewer.

Engaging this mode while standing still allowed your actual avatar's position to be change by collision/push, it's just no one saw the visual effects. Scripts still saw the position correctly. A typical piggyback of llMoveToTarget() was used to keep your actual body nearby if it was being bumped/pushed/orbited because when you disengaged client phantom, you'd immediately appear where your body actually was in the region, which could be anywhere after being attacked.

LL broke Phoenix client phantom when they implemented pathfinding.

The fall back was then an old hack where if you sit on an object, applied llVolumeDetect(TRUE) to the linkset then deleted the object while still sitting on it, you remain without a physics shape which prevented collisions with objects and even the ground as you would constantly fall through it and be moved back above. Most people then either floated in the air or sat. This method was still susceptible to damage from pushes. LL later broke this, too.

LL didn't close any hole because llMoveToTarget() was weak against push/force. They lowered the amount of energy transfer collisions and pushes can have as well as the amount of pending physics requests that can be present at any one time before all object physics motion is halted in preparation for pathfinding. There may have also been vectors that still  needed to be fixed that allowed transfer of "Infinity" energy which could corrupt the ground collision "mesh" and any physics objects touching it. This was done over a two month period before pathfinding was released.

 

[Wulfie Reanimator]

8 hours ago, MelodicRain said:

Is there anything you can achieve with LSL that you can't do with Firestorm's native "move-lock" function?

Firestorm's "native" move-lock is just an LSL script.

When you log in with Firestorm, it automatically attaches the "LSL Bridge" to you. It's full-perm, you can look inside it.

//
// Movelock
//

    movelockMe(integer lock)
    {
        if (lock)
        {
            llMoveToTarget(llGetPos() - <0, 0, 0.1>, 0.05);
            llSetVehicleType(VEHICLE_TYPE_SLED);
            llSetVehicleFloatParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, 0.05);
            llSetVehicleFloatParam(VEHICLE_ANGULAR_FRICTION_TIMESCALE, 0.05);
        }
        else
        {
            llStopMoveToTarget();
            llSetVehicleType(VEHICLE_TYPE_NONE);
        }
    }

 

[Mollymews]

1 hour ago, Lucia Nightfire said:

LL didn't close any hole because llMoveToTarget() was weak against push/force. They lowered the amount of energy transfer collisions and pushes can have as well as the amount of pending physics requests that can be present at any one time before all object physics motion is halted in preparation for pathfinding. There may have also been vectors that still  needed to be fixed that allowed transfer of "Infinity" energy which could corrupt the ground collision "mesh" and any physics objects touching it. This was done over a two month period before pathfinding was released.

agree with this, as how Linden went about it and why

the work of fixing vectors that up until then allowed transfer of infinite energy resulted in what we have now. I didn't mean to imply that Linden made llMoveToTarget stronger. The fixes weakened the other methods relatively as you have pointed out

[rose9991sl]

will this work

On 9/27/2020 at 12:00 PM, Wulfie Reanimator said:

Firestorm's "native" move-lock is just an LSL script.

When you log in with Firestorm, it automatically attaches the "LSL Bridge" to you. It's full-perm, you can look inside it.

//
// Movelock
//

    movelockMe(integer lock)
    {
        if (lock)
        {
            llMoveToTarget(llGetPos() - <0, 0, 0.1>, 0.05);
            llSetVehicleType(VEHICLE_TYPE_SLED);
            llSetVehicleFloatParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, 0.05);
            llSetVehicleFloatParam(VEHICLE_ANGULAR_FRICTION_TIMESCALE, 0.05);
        }
        else
        {
            llStopMoveToTarget();
            llSetVehicleType(VEHICLE_TYPE_NONE);
        }
    }

 

will this work and let people not to kick me if i put into a box and put in my body?

 

Edited October 11, 2020 by rose9991sl
question blur