You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While checking the code in oc_particles.lsl it seems that the current implementation does not handle repeated [command variable(s)] sections correctly. So this post is to check my understanding of the protocol before trying to create a working patch.
According to https://wiki.secondlife.com/wiki/LSL_Protocol/LockGuard, the only command that should send the target prim key is "link", this means that the lacking link target discussed in #965 is according to the protocol specifications. This is also means that size, color, texture and gravity can be expected in the same command as the link command, this corresponds to observed behaviour from some LG furniture I tested, or can be sent in separate commands, currently not handled by the code since it assumes key kLGTarget = llList2Key(lLGCmd,4) for all commands and uses this to get the distance.
Do we want to accept parameter commands, even if kLGTarget is not known, but the leash point is correct ?
For the code in oc_particle this means
?? kLGTarget should be made global, or one copy for every leash point. ??
LG handling should loop over the command line, or check the complete set of commands one by one.
"link" and the call to Particle() should be handled last in order to parse eventual parameters first.
Update:
There is a test version of updated Lock Guard implementation in NikkiLacrima@ff098a1
The text was updated successfully, but these errors were encountered:
While checking the code in oc_particles.lsl it seems that the current implementation does not handle repeated [command variable(s)] sections correctly. So this post is to check my understanding of the protocol before trying to create a working patch.
According to https://wiki.secondlife.com/wiki/LSL_Protocol/LockGuard, the only command that should send the target prim key is "link", this means that the lacking link target discussed in #965 is according to the protocol specifications. This is also means that size, color, texture and gravity can be expected in the same command as the link command, this corresponds to observed behaviour from some LG furniture I tested, or can be sent in separate commands, currently not handled by the code since it assumes key kLGTarget = llList2Key(lLGCmd,4) for all commands and uses this to get the distance.
Do we want to accept parameter commands, even if kLGTarget is not known, but the leash point is correct ?
For the code in oc_particle this means
Update:
There is a test version of updated Lock Guard implementation in
NikkiLacrima@ff098a1
The text was updated successfully, but these errors were encountered: