Jump to content
You are about to reply to a thread that has been inactive for 1511 days.

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

Recommended Posts

Posted (edited)

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 by MelodicRain
Posted (edited)

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 by animats
Posted (edited)
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 by Mollymews
old school
  • Like 1
  • Thanks 1
Posted
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.

 

  • Like 1
Posted
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);
        }
    }

 

  • Thanks 1
Posted
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

  • 2 weeks later...
Posted (edited)

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 by rose9991sl
question blur
You are about to reply to a thread that has been inactive for 1511 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
×
×
  • Create New...